From hotz@jpl.nasa.gov Mon Aug 1 14:24:21 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0D1F0C49 for ; Mon, 1 Aug 2011 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWomK7We8GQM for ; Mon, 1 Aug 2011 14:24:21 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 60E3B1F0C3B for ; Mon, 1 Aug 2011 14:24:21 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p71LORBS028368 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 1 Aug 2011 14:24:27 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 1 Aug 2011 14:24:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004001cc4210$b3cb3210$1b619630$@eu> To: Kyle Hamilton X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:24:21 -0000 On Jul 20, 2011, at 2:02 AM, Kyle Hamilton wrote: >> I think that there should be a mandatory to support TA format for = PKIX, >> and that should be X.509. >=20 > There are additional ways that trust anchors can be encoded, such as = OpenPGP. I'm also wary of MUST-encoding policies into technical = standards, as I suggest above. >=20 > You can't know what the next generation of protocol improvements is = going to entail, and after 3 or 4 iterations still being required to = support the legacy X.509 format when there were alternative, preferable = ways of encoding the same information in common use. (also, there's the = concept of "how much and for what do we have to trust the CA?" I think = it's 'authoritative identity'.) I was going to ask if there were any reason *NOT* to encode a TA in an = X.509 cert. I guess this is one answer to the question. However I don't find it a convincing one. If the primary goal of = interoperability is to be achieved, then I think *some* = mandatory-to-implement format for a TA is needed. If it means = supporting a deprecated format long after a better alternative is = available, well, everyone else has to deal with that too. Why should = PKIX be exempt from the pain of success? ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From kyanha@kyanha.net Mon Aug 1 20:24:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191445E800B for ; Mon, 1 Aug 2011 20:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkTqrxesU4or for ; Mon, 1 Aug 2011 20:24:51 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id CC4F15E8015 for ; Mon, 1 Aug 2011 20:24:45 -0700 (PDT) Received: by pzk6 with SMTP id 6so11713807pzk.26 for ; Mon, 01 Aug 2011 20:24:53 -0700 (PDT) Received: by 10.68.35.136 with SMTP id h8mr5980140pbj.319.1312255492793; Mon, 01 Aug 2011 20:24:52 -0700 (PDT) Received: from penango (ip68-96-191-113.lv.lv.cox.net [68.96.191.113]) by mx.google.com with ESMTPS id v1sm6257330pbg.15.2011.08.01.20.24.50 (version=SSLv3 cipher=OTHER); Mon, 01 Aug 2011 20:24:51 -0700 (PDT) From: "Kyle Hamilton" To: "Henry B. Hotz" Date: Mon, 1 Aug 2011 20:25:06 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <004001cc4210$b3cb3210$1b619630$@eu> References: <004001cc4210$b3cb3210$1b619630$@eu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.8.1eqgqub1pgxp5gc02w7s52 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 03:24:53 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.8.1eqgqub1pgxp5gc02w7s52 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIE1vbiwgQXVnIDEsIDIwMTEgYXQgMjoyNCBQTSwgSGVucnkgQi4gSG90eiA8aG90ekBq cGwubmFzYS5nb3Y+IHdyb3RlOg0KPiBJIHdhcyBnb2luZyB0byBhc2sgaWYgdGhlcmUgd2VyZSBh bnkgcmVhc29uICpOT1QqIHRvIGVuY29kZSBhIFRBIGluIGFuIFguNTA5IGNlcnQuIKBJIGd1ZXNz IHRoaXMgaXMgb25lIGFuc3dlciB0byB0aGUgcXVlc3Rpb24uDQoNCklzIHRoZXJlIGFueSByZWFz b24gKlRPKiBtYW5kYXRlIHRoYXQgY29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbnMgYWNjZXB0IGFu IFguNTA5LWZvcm1hdHRlZCB0cnVzdCBhbmNob3I/DQoNCj4gSG93ZXZlciBJIGRvbid0IGZpbmQg aXQgYSBjb252aW5jaW5nIG9uZS4goElmIHRoZSBwcmltYXJ5IGdvYWwgb2YgaW50ZXJvcGVyYWJp bGl0eSBpcyB0byBiZSBhY2hpZXZlZCwgdGhlbiBJIHRoaW5rICpzb21lKiBtYW5kYXRvcnktdG8t aW1wbGVtZW50IGZvcm1hdCBmb3IgYSBUQSBpcyBuZWVkZWQuIKBJZiBpdCBtZWFucyBzdXBwb3J0 aW5nIGEgZGVwcmVjYXRlZCBmb3JtYXQgbG9uZyBhZnRlciBhIGJldHRlciBhbHRlcm5hdGl2ZSBp cyBhdmFpbGFibGUsIHdlbGwsIGV2ZXJ5b25lIGVsc2UgaGFzIHRvIGRlYWwgd2l0aCB0aGF0IHRv by4goFdoeSBzaG91bGQgUEtJWCBiZSBleGVtcHQgZnJvbSB0aGUgcGFpbiBvZiBzdWNjZXNzPw0K DQpJIGRvbid0IGZpbmQgYW55IGNvbnZpbmNpbmcgYXJndW1lbnRzIHRvIGRvIHNvLCBwYXJ0aWN1 bGFybHkgYXMgaXQgbWFuZGF0ZXMgYWRkaXRpb25hbCBjb2RpbmcgLS0gdGhhdCBpcywgZXhwZW5z ZSB0byBwcml2YXRlIGluZHVzdHJ5IC0tIGF0IHRoZSBzdWdnZXN0aW9uIG9mIFVTIGZlZGVyYWwg Z292ZXJubWVudC4NCg0KU2FpZCBnb3Zlcm5tZW50IG5vdC1zby1jb2luY2lkZW50YWxseSBhbHNv IHRoaW5rcyB0aGF0IGl0IGhhcyBhbiBpbnRlcmVzdCBpbiBwcmV2ZW50aW5nIHByaXZhdGUgYW5k IGNvbmZpZGVudGlhbCBjb21tdW5pY2F0aW9ucyB0aGF0IGl0IGNhbid0IHJlYWQgKGMuZi4gdGhl IENsaXBwZXIgY2hpcCBhbmQgU2tpcGphY2spLg0KDQpBcyBmb3IgIndoeSBzaG91bGQgUEtJWCBi ZSBleGVtcHQgZnJvbSB0aGUgcGFpbiBvZiBzdWNjZXNzPyIsIEkgc3VnZ2VzdCB0aGF0IHBlcmhh cHMgd2UgY2FuIGFjdHVhbGx5IGxlYXJuIGZyb20gdGhlIG1pc3Rha2VzIG9mIHRoZSBwYXN0IGFu ZCBub3QgZmFsbCBpbnRvIHRoZSBzYW1lIHBpdGZhbGxzLg0KDQpUaGVyZSBpcyBhbHJlYWR5IG5v IHdheSB0byBzdXBwb3J0IGV2ZXJ5IE1VU1QgaW4gZXZlcnkgUEtJWCBwcm90b2NvbCB3aXRob3V0 IGJyZWFraW5nIHNvbWUgcGllY2Ugb2YgdGhlIGdlYXJpbmcuICBUaGVyZSBhbHJlYWR5IGV4aXN0 IG5lZWRzIHdoaWNoIGFyZSBub3QgbWV0IGJ5IFBLSVggcHJvdG9jb2xzIC0tIHRoZSBwZXJlbm5p YWwgZXhhbXBsZSBpcyB0aGF0IHdlIG5lZWQgInRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBh bmQgaXMgbm90IHJldm9rZWQiLCBub3QgIndlIG5ldmVyIHJldm9rZWQgdGhpcyBjZXJ0aWZpY2F0 ZSAocG9zc2libHkgYmVjYXVzZSB3ZSBuZXZlciBpc3N1ZWQgaXQpIi4gIFRoZSBtb3JlIE1VU1Rz IGluIGEgc3RhbmRhcmQgdGhhdCBhcmUgaWdub3JlZCBieSBpbXBsZW1lbnRhdGlvbnMgKGZvciBn b29kIHJlYXNvbnMhKSwgdGhlIGxlc3Mgc3RhbmRhcmRpemVkIHRoZSBzdGFuZGFyZCBhY3R1YWxs eSBpcy4NCg0KSSBleHBlY3QgdGhhdCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBpbXBsZW1lbnQgWC41 MDkgdHJ1c3QgYW5jaG9ycyB3aGVuLCB3aGVyZSwgYW5kIGhvdyB0aGV5IGFyZSBhcHByb3ByaWF0 ZSBmb3IgdGhlIGltcGxlbWVudGF0aW9uLCBhbmQgSSBleHBlY3QgdGhhdCB0aGV5IHdpbGwgZHJv cCBzdXBwb3J0IHdoZW4gYW5kIGlmIGl0J3Mgbm8gbG9uZ2VyIHVzZWZ1bC4gIFBLSVggaGFzIGFs cmVhZHkgYWx0ZXJlZCB0aGUgdW5hbHRlcmFibGUsIGNoYW5nZWQgdGhlIGltbXV0YWJsZSwgYWx0 ZXJlZCB0aGUgc2VtYW50aWNzIG9mIE9JRHMgd2hpY2ggd2VyZSBhbHJlYWR5IHNwZWNpZmllZCwg YW5kIGZvcmNlZCB1cyBpbnRvIHVuc3VzdGFpbmFibGUgYW5kIHV0dGVybHkgdXNlbGVzcyBwYXJh ZGlnbXMgYnkgbWFuZGF0aW5nIHBvbGljeSBpbiB0ZWNobmljYWwgc3RhbmRhcmRzLg0KDQpQb2xp Y3ktYmFzZWQgTVVTVHMgaW4gUEtJWCdzIHRlY2huaWNhbCBzdGFuZGFyZHMsIGluZm9ybWVkIGJ5 IHRoZSBzdGF0aXN0IHZpZXdwb2ludCBvZiAidGhpcyBpcyBzaW1wbHkgaG93IHRoaW5ncyBhcmUi LCBoYXZlIGluaGliaXRlZCBvciBjb21wbGV0ZWx5IHByZXZlbnRlZCB0aGUgYWRvcHRpb24gKmFu ZCBldm9sdXRpb24qIG9mIHNlY3VyaXR5IHRlY2hub2xvZ2llcyB0aGF0IGFyZSB1c2VmdWwgdG8g dGhlIGxhcmdlc3Qgc2VnbWVudCBvZiBJbnRlcm5ldCB1c2VyczogdGhlIHByaXZhdGUgaW5kaXZp ZHVhbC4gIEkndmUgZm91bmQgZW5vdWdoIHJlYXNvbnMgdG8gaWdub3JlIHBvbGljeS1iYXNlZCBN VVNUcyBhcyBhIG1hdHRlciBvZiBwcmluY2lwbGUuDQoNClRoZXJlIGV4aXN0IGdvb2QgcmVhc29u cyB3aHkgQVJQQS9EQVJQQSwgdGhlIFVTIGdvdmVybm1lbnQgYXMgYSB3aG9sZSwgYW5kIHRoZSBJ VFUtVCBkb24ndCBoYXZlIGNvbnRyb2wgb3ZlciB0aGUgSW50ZXJuZXQgc3RhbmRhcmRzIHByb2Nl c3NlcywgYW5kIG9uZSBvZiB0aGVtIGlzIHRoaXMga2luZCBvZiBjbG9zZWQtbWluZGVkICJnb29k IGlkZWEgdG8gbWFuZGF0ZSIgdGhhdCB0dXJucyBhcm91bmQgdG8gYml0ZSB1cyBhbGwuDQoNCkZv ciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMsIGFuZCBhZGRpdGlvbmFsIHRob3VnaHRzIG9uIHdo eSB0aGUgc3RhdGUgb2YgUEtJIGlzIHNvIG1lc3NlZCB1cCwgSSBkaXJlY3QgeW91IHRvIGh0dHBz Oi8va3lhbmhhLm5ldC93b3JkcHJlc3MvP3A9ODMgLg0KDQotS3lsZSBIDQo= --gmsm1.8.1eqgqub1pgxp5gc02w7s52 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwODAyMDMyNTA2WjAjBgkqhkiG9w0BCQQxFgQUvDxMHqFWqWhhDo7C2WRLAp3c EQwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAGiRRe4wHWRga8B+e+IIXuuc5Gg8+s+NIalPketjE3qqpRayLFPQ/jZE//mR3DlZdMoLw57l dc9ayqP11bq4bSmye6eksVPQS5Cndt51fjQEmvYkFdrMajbFUnVI9YGFJNecV3mc1BoWpJGOMcVo mQiBATWIbT+Zjtp2VMTC9+aT2Yff8BGAxS7JompYAkpI8ZT3sLm1gEfdY7+6tEa/E1VcU8/1Yj2d HyNTct5tGcQq9S70f+vMVG9EFxdOXTqzjUZ3D3xkhUXdQT+Gu0Kzh5Oij4ZEBBBOu3/MSJBkJFKk HKufSXVS3Hvlq+T20qcUTcS7/RGfvFa8QXndJkcWYpoAAAAAAAA= --gmsm1.8.1eqgqub1pgxp5gc02w7s52-- From koichi.sugimoto@globalsign.com Tue Aug 2 03:41:09 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED3821F8EE8 for ; Tue, 2 Aug 2011 03:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkzdRRfrhTPi for ; Tue, 2 Aug 2011 03:41:09 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 399F421F8EE6 for ; Tue, 2 Aug 2011 03:41:08 -0700 (PDT) Received: by wyj26 with SMTP id 26so2116604wyj.31 for ; Tue, 02 Aug 2011 03:41:17 -0700 (PDT) Received: by 10.216.172.201 with SMTP id t51mr1003372wel.79.1312281677206; Tue, 02 Aug 2011 03:41:17 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by mx.google.com with ESMTPS id n33sm3915751weq.36.2011.08.02.03.41.16 (version=SSLv3 cipher=OTHER); Tue, 02 Aug 2011 03:41:17 -0700 (PDT) Received: by wwe5 with SMTP id 5so4388363wwe.13 for ; Tue, 02 Aug 2011 03:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.81.7 with SMTP id l7mr1582674wee.69.1312281676384; Tue, 02 Aug 2011 03:41:16 -0700 (PDT) Received: by 10.216.21.9 with HTTP; Tue, 2 Aug 2011 03:41:16 -0700 (PDT) Date: Tue, 2 Aug 2011 19:41:16 +0900 Message-ID: From: koichi sugimoto To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] Private information extension on X.509 certificate X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 10:41:10 -0000 Dear Sirs, I've been considering about some security problems among internet in relation to X.509 certificate. 1) If client certificate has some personal private information (e.g. name, address, national ID etc.), the certificate leaks the personal information to the internet. But some situations force us to disclose the information with certification. 2) Many spam mails are sent to publicly opened email address. If our s/mime certificate are opened to internet, the number of the spam mails may inclease extremely. - This was alredy argued in this community. 3) Many information leakage incidents were occueered by hacking the web sites. Leackage of personal information, credit card number is the most critical damage for the site owner. If these kind of informations are protected by encryption or access control, what will be happened? Suppose that these infomations are embeded as certificate extensions. For example: A) Fully certified and encrypted infomation This information is sent to CA and encrypted by end-entity's public key The hashed value of the encypted data and the pointer (URI or something) are put in the certificate. - name, national ID, address, e-mail address, pictures etc.. are categolized to this group. B) Personally encrypted information This information is encrypted by end-entity or something, and only hashed value of the encrypted data and the pointer are put in the certificate. This information is not certified by CA. - credit card number etc. are categolized to this group. C) Access controlled information This infomation is access-controlled by some site. Only the URI is put in the certificate. - profile, pictures etc. are categolized to this group. This kind of data is shared to some closed group. Sorry for my poor english. Regards, Koichi Sugimoto. From kent@bbn.com Tue Aug 2 13:14:56 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098EF21F86AF for ; Tue, 2 Aug 2011 13:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FidEN4sW9-OZ for ; Tue, 2 Aug 2011 13:14:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 79D2021F869D for ; Tue, 2 Aug 2011 13:14:55 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:42166 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QoLMg-000Apb-6i; Tue, 02 Aug 2011 16:14:58 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004001cc4210$b3cb3210$1b619630$@eu> Date: Tue, 2 Aug 2011 16:04:46 -0400 To: "Henry B. Hotz" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:14:56 -0000 At 2:24 PM -0700 8/1/11, Henry B. Hotz wrote: >On Jul 20, 2011, at 2:02 AM, Kyle Hamilton wrote: > >>> I think that there should be a mandatory to support TA format for PKIX, >>> and that should be X.509. >> >> There are additional ways that trust anchors can be encoded, such >>as OpenPGP. I'm also wary of MUST-encoding policies into technical >>standards, as I suggest above. >> >> You can't know what the next generation of protocol improvements >>is going to entail, and after 3 or 4 iterations still being >>required to support the legacy X.509 format when there were >>alternative, preferable ways of encoding the same information in >>common use. (also, there's the concept of "how much and for what >>do we have to trust the CA?" I think it's 'authoritative >>identity'.) > >I was going to ask if there were any reason *NOT* to encode a TA in >an X.509 cert. I guess this is one answer to the question. > >However I don't find it a convincing one. If the primary goal of >interoperability is to be achieved, then I think *some* >mandatory-to-implement format for a TA is needed. If it means >supporting a deprecated format long after a better alternative is >available, well, everyone else has to deal with that too. Why >should PKIX be exempt from the pain of success? Henry, We also do not have a mandatory to implement set of algorithms, and that is intentional. Absent a universal alg suite mandate, there is no need for a mandated TA format either, as the second would not guarantee interoperability without the first. Steve From hotz@jpl.nasa.gov Tue Aug 2 14:54:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8309B11E80A1 for ; Tue, 2 Aug 2011 14:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ1TUb1cbYa4 for ; Tue, 2 Aug 2011 14:54:37 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id CC03321F85B9 for ; Tue, 2 Aug 2011 14:54:33 -0700 (PDT) Received: from dhcp-137-79-177-24.jpl.nasa.gov (dhcp-137-79-177-24.jpl.nasa.gov [137.79.177.24]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p72LsdFh011888 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 2 Aug 2011 14:54:39 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Tue, 2 Aug 2011 14:54:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004001cc4210$b3cb3210$1b619630$@eu> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-Source-IP: dhcp-137-79-177-24.jpl.nasa.gov [137.79.177.24] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:54:37 -0000 On Aug 2, 2011, at 1:04 PM, Stephen Kent wrote: > At 2:24 PM -0700 8/1/11, Henry B. Hotz wrote: >> On Jul 20, 2011, at 2:02 AM, Kyle Hamilton wrote: >>=20 >>>> I think that there should be a mandatory to support TA format for = PKIX, >>>> and that should be X.509. >>>=20 >>> There are additional ways that trust anchors can be encoded, such=20 >>> as OpenPGP. I'm also wary of MUST-encoding policies into technical=20= >>> standards, as I suggest above. >>>=20 >>> You can't know what the next generation of protocol improvements=20 >>> is going to entail, and after 3 or 4 iterations still being=20 >>> required to support the legacy X.509 format when there were=20 >>> alternative, preferable ways of encoding the same information in=20 >>> common use. (also, there's the concept of "how much and for what=20 >>> do we have to trust the CA?" I think it's 'authoritative=20 >>> identity'.) >>=20 >> I was going to ask if there were any reason *NOT* to encode a TA in=20= >> an X.509 cert. I guess this is one answer to the question. >>=20 >> However I don't find it a convincing one. If the primary goal of=20 >> interoperability is to be achieved, then I think *some*=20 >> mandatory-to-implement format for a TA is needed. If it means=20 >> supporting a deprecated format long after a better alternative is=20 >> available, well, everyone else has to deal with that too. Why=20 >> should PKIX be exempt from the pain of success? >=20 > Henry, >=20 > We also do not have a mandatory to implement set of algorithms, and = that > is intentional. I have to say that sounds really weird to me. It means that you're = writing spec's which are deliberately insufficient to guarantee = interoperability. I thought interoperability was the whole point of the = IETF. Pragmatically, there must be some small set of algorithms which are = mandatory to implement in the real world or PKIX and TLS wouldn't work. = If we abdicate responsibility for documenting what those are, then we = also abdicate authority for coordinating improvements, do we not? > Absent a universal alg suite mandate, there is no > need for a mandated TA format either, as the second would not = guarantee > interoperability without the first. No argument in general, but one could (and probably should) write a TA = spec which delegates the algorithm suite to other, more appropriate = spec's. > Steve ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From housley@vigilsec.com Tue Aug 2 15:02:43 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2509E11E80C1 for ; Tue, 2 Aug 2011 15:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh7adnmLHzRE for ; Tue, 2 Aug 2011 15:02:42 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id A69D611E8095 for ; Tue, 2 Aug 2011 15:02:42 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id F1D0CF241B3; Tue, 2 Aug 2011 18:03:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id SJQNHWO3kGUx; Tue, 2 Aug 2011 18:02:44 -0400 (EDT) Received: from [192.168.2.107] (pool-96-241-176-45.washdc.fios.verizon.net [96.241.176.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 87DFEF24119; Tue, 2 Aug 2011 18:03:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 2 Aug 2011 18:02:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004001cc4210$b3cb3210$1b619630$@eu> To: "Henry B. Hotz" X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:02:43 -0000 Henry: >> We also do not have a mandatory to implement set of algorithms, and = that >> is intentional. >=20 > I have to say that sounds really weird to me. It means that you're = writing spec's which are deliberately insufficient to guarantee = interoperability. I thought interoperability was the whole point of the = IETF. PKIX is used in other applications, and those applications sate the = mandatory to implement. Consider S/MIME as one example. This approach = allows the same signature algorithm to be mandatory for the message = signature and the certificate signature. Russ= From mrex@sap.com Tue Aug 2 15:10:05 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C99221F8546 for ; Tue, 2 Aug 2011 15:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.946 X-Spam-Level: X-Spam-Status: No, score=-9.946 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFmTe1LS8v25 for ; Tue, 2 Aug 2011 15:09:44 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id AA44E21F8545 for ; Tue, 2 Aug 2011 15:09:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p72M9UfP018286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2011 00:09:35 +0200 (MEST) From: Martin Rex Message-Id: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Wed, 3 Aug 2011 00:09:30 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Aug 2, 11 04:04:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:10:05 -0000 Stephen Kent wrote: > > We also do not have a mandatory to implement set of algorithms, and that > is intentional. Absent a universal alg suite mandate, there is no > need for a mandated TA format either, as the second would not guarantee > interoperability without the first. Such a rationale for a lack of mandatory to implement trust anchor format scores "lame" on my personal scorecard. PKIX has a mandatory certificate (X.509), so it is far from unusal to mandate that this format is supported for trust anchors as well. (keep in mind that mandatory to implement is not the same as mandatory to use for the consumers of the technology). The algorithms issue is a whole different can of worms. ... but actuallly recommending what algorithms might be sensible to support for obtaining interop with the majority of installed base would not hurt, either -- even if the "mandatory to implement" part is skipped. The current defacto interoperable algorithms are rsaEncryption { 1, 2, 840, 113549, 1, 1, 1 } sha1 { 1, 3, 14, 3, 2, 26 } sha1WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 5 } and it would probably be sensible to also include sha256 { 2,16,840,1,101,3,4,2,1 } sha256WithRsaencryption { 1, 2, 840, 113549, 1, 1, 11 } in all newly shipped products and product updates & fixes -Martin From paul.hoffman@vpnc.org Tue Aug 2 15:12:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB99021F854E for ; Tue, 2 Aug 2011 15:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj0wyQ0dkJEi for ; Tue, 2 Aug 2011 15:12:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E91C321F8549 for ; Tue, 2 Aug 2011 15:12:13 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p72MC3F0030645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2011 15:12:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> Date: Tue, 2 Aug 2011 15:12:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <302B0530-092F-439C-99CD-2B69F7D830DF@vpnc.org> References: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: PKIX Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:12:14 -0000 On Aug 2, 2011, at 3:09 PM, Martin Rex wrote: > Such a rationale for a lack of mandatory to implement trust anchor > format scores "lame" on my personal scorecard. And your -00 draft of such a document is where? :-) Seriously, though, = it sounds like some people want this, and it could be useful to have a = specific target to discuss. --Paul Hoffman From hotz@jpl.nasa.gov Tue Aug 2 17:02:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310D511E8107 for ; Tue, 2 Aug 2011 17:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1lO9UEldQNh for ; Tue, 2 Aug 2011 17:02:13 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id B240511E8095 for ; Tue, 2 Aug 2011 17:02:13 -0700 (PDT) Received: from dhcp-137-79-177-24.jpl.nasa.gov (dhcp-137-79-177-24.jpl.nasa.gov [137.79.177.24]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7302LM8007878 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 2 Aug 2011 17:02:22 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Tue, 2 Aug 2011 17:02:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004001cc4210$b3cb3210$1b619630$@eu> To: Russ Housley X-Mailer: Apple Mail (2.1084) X-Source-IP: dhcp-137-79-177-24.jpl.nasa.gov [137.79.177.24] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: IETF PKIX Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:02:14 -0000 So it's intentional in order to allow (for example) m-t-i for S/MIME to = be different from m-t-i for TLS? That's at least potentially = reasonable. =20 But what if I want to deploy client certs that are good for both S/MIME = and TLS? Is that an intentionally unsupported use case? I'll grant = that the world is a complex place and there are a lot of different = things in it. A cert identifying a phone must have different = requirements from one identifying a person from one identifying a = service. The supportable applications for those are also different. However I think there is still an interoperability argument. On Aug 2, 2011, at 3:02 PM, Russ Housley wrote: > Henry: >=20 >>> We also do not have a mandatory to implement set of algorithms, and = that >>> is intentional. >>=20 >> I have to say that sounds really weird to me. It means that you're = writing spec's which are deliberately insufficient to guarantee = interoperability. I thought interoperability was the whole point of the = IETF. >=20 > PKIX is used in other applications, and those applications sate the = mandatory to implement. Consider S/MIME as one example. This approach = allows the same signature algorithm to be mandatory for the message = signature and the certificate signature. >=20 > Russ ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Tue Aug 2 17:44:54 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B57711E80F0 for ; Tue, 2 Aug 2011 17:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sCNZzJX41as for ; Tue, 2 Aug 2011 17:44:54 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 027DF11E80A1 for ; Tue, 2 Aug 2011 17:44:53 -0700 (PDT) Received: from dhcp-137-79-177-24.jpl.nasa.gov (dhcp-137-79-177-24.jpl.nasa.gov [137.79.177.24]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p730ixBj003279 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 2 Aug 2011 17:45:00 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> Date: Tue, 2 Aug 2011 17:44:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> To: "mrex@sap.com" X-Mailer: Apple Mail (2.1084) X-Source-IP: dhcp-137-79-177-24.jpl.nasa.gov [137.79.177.24] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:44:54 -0000 On Aug 2, 2011, at 3:09 PM, Martin Rex wrote: > The algorithms issue is a whole different can of worms. > ... but actuallly recommending what algorithms might be sensible > to support for obtaining interop with the majority of installed base > would not hurt, either -- even if the "mandatory to implement" > part is skipped. >=20 > The current defacto interoperable algorithms are >=20 > rsaEncryption { 1, 2, 840, 113549, 1, 1, 1 } > sha1 { 1, 3, 14, 3, 2, 26 } > sha1WithRsaEncryption { 1, 2, 840, 113549, 1, 1, 5 } >=20 > and it would probably be sensible to also include >=20 > sha256 { 2,16,840,1,101,3,4,2,1 } > sha256WithRsaencryption { 1, 2, 840, 113549, 1, 1, 11 } >=20 > in all newly shipped products and product updates & fixes >=20 >=20 > -Martin I'm in no position to help, but I think a BCP which specifies = rsaEncryption, sha256, and sha256WithRsaencryption as m-t-i for PKIX = would be a good thing. Add some weasel-words allowing applications to = further specify if they have reason. Absent PKIX guidance, are there some saag doc's which kick in? I'm = guessing not, but have to ask. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From tmiller@mitre.org Wed Aug 3 06:32:04 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F51221F8ACC for ; Wed, 3 Aug 2011 06:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqvGq3tR5F+v for ; Wed, 3 Aug 2011 06:32:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 865E421F8A7B for ; Wed, 3 Aug 2011 06:32:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 31DA321B0C31; Wed, 3 Aug 2011 09:32:15 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2042221B0BF4; Wed, 3 Aug 2011 09:32:15 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 3 Aug 2011 09:32:14 -0400 From: "Miller, Timothy J." To: "Henry B. Hotz" Date: Wed, 3 Aug 2011 09:32:16 -0400 Thread-Topic: [pkix] Certification path Thread-Index: AcxR4cE5Tx20ckyfQwqgMaDnjzypog== Message-ID: References: <004001cc4210$b3cb3210$1b619630$@eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2--936311936"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:32:04 -0000 --Apple-Mail-2--936311936 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 2, 2011, at 7:02 PM, Henry B. Hotz wrote: > But what if I want to deploy client certs that are good for both = S/MIME and TLS? Is that an intentionally unsupported use case? I'll = grant that the world is a complex place and there are a lot of different = things in it. A cert identifying a phone must have different = requirements from one identifying a person from one identifying a = service. The supportable applications for those are also different. > However I think there is still an interoperability argument. Stop that! Thinking like an Enterprise Architect is verboten! (Plus it = will get you nothing but high blood pressure and thinning hair. :) -- T --Apple-Mail-2--936311936 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA4MDMxMzMyMTdaMCMGCSqGSIb3DQEJBDEWBBS3m9of0dGrdm6cgDek HBEIzHubNTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgJZZ6z4BQ5YuyrstNTXN6KsmzsHjyylh1z4d 4aXnVzB77SNvu58A+rFK4Jg62niPkCc1sWMAQJEnRBgalaM4bZpVsqRd8D72dnnCq0pQcW2Sxm2s HKXM8H+YyivpRZf+Falq8VQG+dhs6lIoDoroTUb5yNN2F6iDuOpPUEXVRbeAAAAAAAAA --Apple-Mail-2--936311936-- From era@x500.eu Wed Aug 3 06:40:04 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D779721F8B51 for ; Wed, 3 Aug 2011 06:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuBOGyUnDbCe for ; Wed, 3 Aug 2011 06:40:04 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9136021F8B2E for ; Wed, 3 Aug 2011 06:40:03 -0700 (PDT) Received: from Morten ([212.27.16.230]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id MVR63413; Wed, 03 Aug 2011 15:40:13 +0200 From: "Erik Andersen" To: "'Stephen Kent'" References: <000c01cc49e6$88d15e30$9a741a90$@eu> In-Reply-To: Date: Wed, 3 Aug 2011 15:40:14 +0200 Message-ID: <002e01cc51e2$e20e2ba0$a62a82e0$@eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002F_01CC51F3.A596FBA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNLtXveIfZ1I9xSk+hdA/y4aWtlgEszv8g Content-Language: da Cc: 'Directory list' , 'SG17-Q11' , 'PKIX' Subject: Re: [pkix] Intermediate CA vs. subject CA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:40:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002F_01CC51F3.A596FBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Steve, It seem you are not in agreement with Peter Sylvester. I also came across a page (http://zvon.org/comp/r/ref-Security_Glossary.html#Terms~subject_CA) claiming the term "subject CA" is a deprecated term. I have been wondering whether we need that term as a specific, defined term. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Stephen Kent [mailto:kent@bbn.com] Sendt: 28. juli 2011 16:01 Til: Erik Andersen Cc: Directory list; SG17-Q11; PKIX Emne: Re: [pkix] Intermediate CA vs. subject CA At 11:46 AM +0200 7/24/11, Erik Andersen wrote: >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_000D_01CC49F7.4C5A2E30" >Content-Language: da > >The terms intermediate CA and subject CA are used in the PKIX >publications and in X.509. I have not found any exact definitions of >those term in any PKIX document, but found some in 8.1.2 of X.509, >but I am not sure that these definition are generally accepted in >the PKI community. > >According to an intermediate CA is an CA issuing cross-certificate, >while the subject CA is the one for which the cross-certificate is >issued. However, the two CAs could have both roles. > >Erik Andersen Erik, In PKIX, I think we use these terms relative to a given cert in the context of a specific cert path. Thus the "subject CA" is the CA that issued the cert to the indicated subject, which might be an EE or a CA. An "intermediate CA" is a CA that lies between a TA and a subject CA, in the context of a cert path and a specified CA. Steve ------=_NextPart_000_002F_01CC51F3.A596FBA0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 38DE37FE1 for ; Sun, 24 Jul 2011 15:37:12 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id DDB0B1702C for ; Sun, 24 Jul 2011 15:37:10 +0200 (CEST) Received: from [78.251.32.190] (unknown [78.251.32.190]) by smtps.on-x.com (Postfix) with ESMTP id ADC17782B for ; Sun, 24 Jul 2011 15:37:10 +0200 (CEST) Received: from mx1.on-x.com ([92.103.215.13]) by mail03.dandomain.dk (DanDomain Mailserver) with ESMTP id HUJ59815 for ; Sun, 24 Jul 2011 15:37:15 +0200 From: "Peter Sylvester" To: "Erik Andersen" References: <000c01cc49e6$88d15e30$9a741a90$@eu> In-Reply-To: <000c01cc49e6$88d15e30$9a741a90$@eu> Subject: Re: [pkix] Intermediate CA vs. subject CA Date: Sun, 24 Jul 2011 15:36:59 +0200 Message-ID: <4E2C1FFB.7020205@edelweb.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01CC51F3.A5963850" X-Mailer: Microsoft Office Outlook 12.0 X-MSK: CML=1.401000 Thread-Index: AcxKBsycF4yTqf9JReWZdTFFo3Hf7Q== This is a multi-part message in MIME format. ------=_NextPart_000_002A_01CC51F3.A5963850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit personal On 07/24/2011 11:46 AM, Erik Andersen wrote: The terms intermediate CA and subject CA are used in the PKIX publications and in X.509. I have not found any exact definitions of those term in any PKIX document, but found some in 8.1.2 of X.509, but I am not sure that these definition are generally accepted in the PKI community. an intermediate CA is any CA that is issuing certificates for other CAs and which is not a/the root CA. it seems that a root CA (at least in x509) cannot create cross certificates (makes sense) in the x500 naming hierarchy thus the picture in 8.1.2 is ok. the real problem is that essentially most non directory related pkis are all cross certificates, none of tem is hierarchical. "hierarchical" only means 'following the directory hierarchy' According to an intermediate CA is an CA issuing cross-certificate, while the subject CA is the one for which the cross-certificate is issued. However, the two CAs could have both roles. it could have been called 'issuing CA" instead of intermediate CA, but since the fictive root CA has an empty DN the certs created by that would not be cross certificates. cross certification that you leave the transitivity of the naming hierarchy. only "intermediate" CAs have (or originally had in V1) the implied restriction that they could only create certs with their own name as prefix. ------=_NextPart_000_002A_01CC51F3.A5963850 Content-Type: text/html; boundary="------------010603030103070201000308"; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable personal

On 07/24/2011 11:46 AM, Erik Andersen wrote:

The terms intermediate CA and subject CA are used in the PKIX publications and in X.509. I have not found any exact definitions of those term in any PKIX document, but found some in 8.1.2 of X.509, but I am not sure that these definition are generally accepted in the PKI community.

an intermediate CA is any CA that is issuing certificates for other CAs and which is not a/the root CA.
it seems that a root CA (at least in x509) cannot create cross certificates (makes sense)
in the x500 naming hierarchy thus the picture in 8.1.2 is ok.

the real problem is that essentially most non directory related pkis are all cross certificates,
none of tem is hierarchical.  "hierarchical" only means = 'following the directory hierarchy'


 

According to an intermediate CA is an CA issuing cross-certificate, while the subject CA is the one for which the cross-certificate is issued. However, the two CAs could have both roles.

it could have been called 'issuing CA" instead of intermediate CA, but since the fictive
root CA has an empty DN the certs created by that would not be cross certificates.

cross certification that you leave the transitivity of the naming hierarchy.
only "intermediate" CAs have (or originally had in V1) the implied restriction that they could
only create certs with their own name as prefix.  

------=_NextPart_000_002A_01CC51F3.A5963850-- ------=_NextPart_000_002F_01CC51F3.A596FBA0-- From era@x500.eu Wed Aug 3 08:30:16 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ED021F8B26 for ; Wed, 3 Aug 2011 08:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrX34CRPLxXo for ; Wed, 3 Aug 2011 08:30:15 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6033321F8ACE for ; Wed, 3 Aug 2011 08:30:15 -0700 (PDT) Received: from Morten ([212.27.16.230]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id MXH95125; Wed, 03 Aug 2011 17:30:25 +0200 From: "Erik Andersen" To: "'Stephen Kent'" References: <000c01cc49e6$88d15e30$9a741a90$@eu> <002e01cc51e2$e20e2ba0$a62a82e0$@eu> In-Reply-To: <002e01cc51e2$e20e2ba0$a62a82e0$@eu> Date: Wed, 3 Aug 2011 17:30:25 +0200 Message-ID: <004b01cc51f2$475f5fb0$d61e1f10$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNLtXveIfZ1I9xSk+hdA/y4aWtlgEszv8gAAPpTuA= Content-Language: da Cc: 'Directory list' , 'SG17-Q11' , 'PKIX' Subject: Re: [pkix] [Spam] Re: Intermediate CA vs. subject CA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:30:17 -0000 Hi, I just realised that it is the Informational RFC 4949 that deprecates = the term "subject CA". However, it also deprecates the term "intermediate CA".RFC 4949 is not a PKIX document, and I have the feeling that PKIX = uses the term "intermediate CA" quite a lot. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Erik Andersen Sendt: 3. august 2011 15:40 Til: 'Stephen Kent' Cc: 'Directory list'; 'SG17-Q11'; 'PKIX' Emne: [Spam] Re: [pkix] Intermediate CA vs. subject CA Hi Steve, It seem you are not in agreement with Peter Sylvester. I also came = across a page = (http://zvon.org/comp/r/ref-Security_Glossary.html#Terms~subject_CA) claiming the term "subject CA" is a deprecated term. I have been = wondering whether we need that term as a specific, defined term. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Stephen Kent [mailto:kent@bbn.com] Sendt: 28. juli 2011 16:01 Til: Erik Andersen Cc: Directory list; SG17-Q11; PKIX Emne: Re: [pkix] Intermediate CA vs. subject CA At 11:46 AM +0200 7/24/11, Erik Andersen wrote: >Content-Type: multipart/alternative; > boundary=3D"----=3D_NextPart_000_000D_01CC49F7.4C5A2E30" >Content-Language: da > >The terms intermediate CA and subject CA are used in the PKIX=20 >publications and in X.509. I have not found any exact definitions of=20 >those term in any PKIX document, but found some in 8.1.2 of X.509, but=20 >I am not sure that these definition are generally accepted in the PKI=20 >community. > >According to an intermediate CA is an CA issuing cross-certificate,=20 >while the subject CA is the one for which the cross-certificate is=20 >issued. However, the two CAs could have both roles. > >Erik Andersen Erik, In PKIX, I think we use these terms relative to a given cert in the = context of a specific cert path. Thus the "subject CA" is the CA that issued the cert to the indicated subject, which might be an EE or a CA. An "intermediate CA" is a CA that lies between a TA and a subject CA, in = the context of a cert path and a specified CA. Steve From kent@bbn.com Wed Aug 3 10:35:44 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EDA21F8AC9 for ; Wed, 3 Aug 2011 10:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.622 X-Spam-Level: X-Spam-Status: No, score=-106.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Cv0JPY70Cy5 for ; Wed, 3 Aug 2011 10:35:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id ED23421F8ABD for ; Wed, 3 Aug 2011 10:35:43 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49200) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QofMI-000LVP-Vs; Wed, 03 Aug 2011 13:35:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004001cc4210$b3cb3210$1b619630$@eu> Date: Wed, 3 Aug 2011 13:16:23 -0400 To: "Henry B. Hotz" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:35:44 -0000 At 2:54 PM -0700 8/2/11, Henry B. Hotz wrote: >O... > > Henry, >> >> We also do not have a mandatory to implement set of algorithms, and that >> is intentional. > >I have to say that sounds really weird to me. It means that you're >writing spec's which are deliberately insufficient to guarantee >interoperability. I thought interoperability was the whole point of >the IETF. PKIX defines PKI specs for a very wide range of apps, which is why we do not mandate any alg suite. Different apps may use different alg suites. TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself. >Pragmatically, there must be some small set of algorithms which are >mandatory to implement in the real world or PKIX and TLS wouldn't >work. If we abdicate responsibility for documenting what those are, >then we also abdicate authority for coordinating improvements, do we >not? Note that you cited one, of many, security protocols above. That's the catch, i.e., each app gets to make these decisions. > >> Absent a universal alg suite mandate, there is no >> need for a mandated TA format either, as the second would not guarantee >> interoperability without the first. > >No argument in general, but one could (and probably should) write a >TA spec which delegates the algorithm suite to other, more >appropriate spec's. > We have a TA format spec: RFC 5914. Steve From kent@bbn.com Wed Aug 3 10:35:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4AB21F8ADC for ; Wed, 3 Aug 2011 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.621 X-Spam-Level: X-Spam-Status: No, score=-106.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDaSaizyPE5W for ; Wed, 3 Aug 2011 10:35:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A41CD21F8ACC for ; Wed, 3 Aug 2011 10:35:45 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49200) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QofMK-000LVP-6a; Wed, 03 Aug 2011 13:35:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> References: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> Date: Wed, 3 Aug 2011 13:12:42 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:35:46 -0000 ... >PKIX has a mandatory certificate (X.509), so it is far from unusal >to mandate that this format is supported for trust anchors as well. not very high on my scorecord :-). > >(keep in mind that mandatory to implement is not the same as mandatory > to use for the consumers of the technology). I've been involved with te development of Internet standards since before the IETF was created, so I have a pretty good grasp of that subtle difference. > >The algorithms issue is a whole different can of worms. >... but actuallly recommending what algorithms might be sensible >to support for obtaining interop with the majority of installed base >would not hurt, either -- even if the "mandatory to implement" >part is skipped. no. Steve From tmiller@mitre.org Wed Aug 3 11:40:49 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988EA11E807C for ; Wed, 3 Aug 2011 11:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLjsKF25l4SO for ; Wed, 3 Aug 2011 11:40:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9E80E11E8078 for ; Wed, 3 Aug 2011 11:40:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A29A621B0E1F; Wed, 3 Aug 2011 14:41:00 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 99FE521B0935; Wed, 3 Aug 2011 14:41:00 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 3 Aug 2011 14:41:00 -0400 From: "Miller, Timothy J." To: Stephen Kent Date: Wed, 3 Aug 2011 14:40:59 -0400 Thread-Topic: [pkix] Certification path Thread-Index: AcxSDONhB7nVDF7ETcWaPcgwNMHlLQ== Message-ID: <1E1C4885-C32A-4DD4-B0EE-9347A0939E10@mitre.org> References: <004001cc4210$b3cb3210$1b619630$@eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1--917789338"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:40:49 -0000 --Apple-Mail-1--917789338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 3, 2011, at 12:16 PM, Stephen Kent wrote: > Note that you cited one, of many, security protocols above. That's = the catch, > i.e., each app gets to make these decisions. Let's be clear: Each standard, protocol, or implementation importing = PKIX definitions makes these decisions in part because PKIX = intentionally does not. =20 This choice can be made differently. Whether other WGs would follow = such a change is still their decision, but the guidance could be helpful = to implementors if no-one else. -- T --Apple-Mail-1--917789338 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA4MDMxODQwNjBaMCMGCSqGSIb3DQEJBDEWBBQpuwG44NpQRE7y8JRM Jv4u8upHkjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgFH5yXBfdTqEWtQZEMPnnsmV/0q1Mz4lUQIW 6xIdUontWE66A1Q4PAudTGKjlcNdX6upgjv4CdXDeECVw43zzUB0VZyNVg/ik10LEyd1Zvs8sgX9 KXGZkpCD8mcbaTsSQUIky5bD31kh3VXQWKPdITZMesRrJ+pQxIvHFQ4CvEuSAAAAAAAA --Apple-Mail-1--917789338-- From kent@bbn.com Wed Aug 3 12:00:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E921F0C5C for ; Wed, 3 Aug 2011 12:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.618 X-Spam-Level: X-Spam-Status: No, score=-106.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UpIpjjXwC03 for ; Wed, 3 Aug 2011 12:00:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C95245E802D for ; Wed, 3 Aug 2011 12:00:29 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49154) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QoggL-000OeD-UV; Wed, 03 Aug 2011 15:00:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1E1C4885-C32A-4DD4-B0EE-9347A0939E10@mitre.org> References: <004001cc4210$b3cb3210$1b619630$@eu> <1E1C4885-C32A-4DD4-B0EE-9347A0939E10@mitre.org> Date: Wed, 3 Aug 2011 14:47:33 -0400 To: "Miller, Timothy J." From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:00:48 -0000 At 2:40 PM -0400 8/3/11, Miller, Timothy J. wrote: >On Aug 3, 2011, at 12:16 PM, Stephen Kent wrote: > >> Note that you cited one, of many, security protocols above. >>That's the catch, >> i.e., each app gets to make these decisions. > >Let's be clear: Each standard, protocol, or implementation >importing PKIX definitions makes these decisions in part because >PKIX intentionally does not. true, but we intentionally do not because we believe that no single alg suite fits all. The same is true for EKUs. >This choice can be made differently. Whether other WGs would follow >such a change is still their decision, but the guidance could be >helpful to implementors if no-one else. If you ask prior Sec ADs, several of whom were very active PKIX members (including one co-chair), I think you'll find that they endorse this separation of protocol specs vs. mandatory to implement alg suites. Steve From mrex@sap.com Wed Aug 3 12:15:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074EF21F885E for ; Wed, 3 Aug 2011 12:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.956 X-Spam-Level: X-Spam-Status: No, score=-9.956 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceuGPlkry2h6 for ; Wed, 3 Aug 2011 12:15:00 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 254D921F885A for ; Wed, 3 Aug 2011 12:14:59 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p73JF3Jc005943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2011 21:15:03 +0200 (MEST) From: Martin Rex Message-Id: <201108031915.p73JF37o018689@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Wed, 3 Aug 2011 21:15:03 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Aug 3, 11 01:16:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:15:01 -0000 Stephen Kent wrote: > > We have a TA format spec: RFC 5914. But that is about as lame as TLSv1.0 mandating the DH-DSS cipher suite (fixed in TLSv1.1), i.e. completely ignoring the installed base. -Martin From carl@redhoundsoftware.com Wed Aug 3 12:18:17 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554D021F8A4B for ; Wed, 3 Aug 2011 12:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YspTfIT46R7z for ; Wed, 3 Aug 2011 12:18:16 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id B3F1F21F8538 for ; Wed, 3 Aug 2011 12:18:16 -0700 (PDT) Received: by qyk35 with SMTP id 35so387493qyk.10 for ; Wed, 03 Aug 2011 12:18:29 -0700 (PDT) Received: by 10.224.211.134 with SMTP id go6mr5631556qab.193.1312399108833; Wed, 03 Aug 2011 12:18:28 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id du3sm561983qab.1.2011.08.03.12.18.26 (version=SSLv3 cipher=OTHER); Wed, 03 Aug 2011 12:18:27 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 15:18:22 -0400 From: Carl Wallace To: , Stephen Kent Message-ID: Thread-Topic: [pkix] Certification path In-Reply-To: <201108031915.p73JF37o018689@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:18:17 -0000 On 8/3/11 3:15 PM, "Martin Rex" wrote: >Stephen Kent wrote: >> >> We have a TA format spec: RFC 5914. > >But that is about as lame as TLSv1.0 mandating the DH-DSS cipher suite >(fixed in TLSv1.1), i.e. completely ignoring the installed base. > >-Martin The default untagged trust anchor option is a certificate. How is that ignoring the installed base? From mrex@sap.com Wed Aug 3 12:58:16 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ABB21F861E for ; Wed, 3 Aug 2011 12:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.962 X-Spam-Level: X-Spam-Status: No, score=-9.962 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tF9sb9vH2n9 for ; Wed, 3 Aug 2011 12:58:15 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6354821F8564 for ; Wed, 3 Aug 2011 12:58:14 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p73JwJN3020010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2011 21:58:19 +0200 (MEST) From: Martin Rex Message-Id: <201108031958.p73JwIAE021157@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Wed, 3 Aug 2011 21:58:18 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Aug 3, 11 01:16:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:58:16 -0000 Stephen Kent wrote: > > Henry B. Hotz wrote: > > > > I have to say that sounds really weird to me. It means that you're > > writing spec's which are deliberately insufficient to guarantee > > interoperability. I thought interoperability was the whole point of > > the IETF. > > PKIX defines PKI specs for a very wide range of apps, which is why we > do not mandate any alg suite. Different apps may use different alg suites. > TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself. You probably know pretty well that there is a significant difference between the alg suites used by specific protocols such as TLS, S/Mime, IPsec, etc. and the alg suites used by the certificate path validation algorithm described in Section 6.1 of RFC-5280. Normally, these algorithms should be cleanly seperated in order to minimized negative consequences and allow code modularization and independent maintenance of the stuff that performs certificate path validation according to PKIX and the stuff that runs protocols such as TLS, S/Mime, IPsec, etc. You might be aware that Microsoft updated the Crypto-API components of Windows XP to allow sha256WithRsaEncryption for X.509 certificates, but that does not automatically imply that sha256 is available for S/Mime in Outlook, for TLS in SChannel or for IPsec on this platform. Similarly, there is a Hotfix available to make AES available for TLS/SChannel SSP on Windows2003, but that does _not_ add AES enctypes to Kerberos SSP. There is, however one fallacy of RFC on the standards track (rfc5246, TLSv1.2) with the flawed concept of requiring a cryptographic algorithm being registered with TLS and assigned a TLS-specific algorithm code point, before it can be used with TLSv1.2 in the X.509 certificate path validation of the underlying PKI software. There is no such restriction in previous of TLS (v1.0,v1.1) where things work just fine, and is one of the reasons why 99.9% of the world is still happily using TLSv1.0&TLSv1.1 3 years later. There is no problem with recommending (and in some cases mandating) algorithms for the pupose of interop, but unnecessarily imposing algorithm dependencies across independent technologies seems like a very bad idea. And mandating certain data formats, such as support for X.509 for trust anchors in PKIX, would be quite sensible, significantly improve interop and be generally useful. -Martin From mrex@sap.com Wed Aug 3 13:19:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6136B21F8779 for ; Wed, 3 Aug 2011 13:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.965 X-Spam-Level: X-Spam-Status: No, score=-9.965 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIFIEJKyOwxU for ; Wed, 3 Aug 2011 13:19:46 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9AB21F8548 for ; Wed, 3 Aug 2011 13:19:46 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p73KJmg6018712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2011 22:19:48 +0200 (MEST) From: Martin Rex Message-Id: <201108032019.p73KJl65022194@fs4113.wdf.sap.corp> To: carl@redhoundsoftware.com (Carl Wallace) Date: Wed, 3 Aug 2011 22:19:47 +0200 (MEST) In-Reply-To: from "Carl Wallace" at Aug 3, 11 03:18:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:19:47 -0000 Carl Wallace wrote: > > Martin Rex wrote: > > > Stephen Kent wrote: > > > > > > We have a TA format spec: RFC 5914. > > > >But that is about as lame as TLSv1.0 mandating the DH-DSS cipher suite > >(fixed in TLSv1.1), i.e. completely ignoring the installed base. > > The default untagged trust anchor option is a certificate. How is that > ignoring the installed base? That is a funny way to describe the situation. I do not see anything like a default, the TrustAnchorChoice and the accompanying text describes this as three equal options, and the tags are to make that thing parsable to the ASN.1 decoder. The tbsCert represents problem number one, and the TrustAnchorInfo not being able to carry along a regular X.509 certificate is an even worse problem of that specification. While you can convert TBSCertificate <-> TrustAnchorInfo, converting Certificate -> TBSCertificate and converting Certificate -> TrustAnchorInfo are clear "one way / no return" routes. And that is why I consider 5914 broken and generally harmful. -Martin From carl@redhoundsoftware.com Wed Aug 3 13:42:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FE321F8515 for ; Wed, 3 Aug 2011 13:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LshjT8KTra0d for ; Wed, 3 Aug 2011 13:42:48 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4776221F8500 for ; Wed, 3 Aug 2011 13:42:48 -0700 (PDT) Received: by qyk35 with SMTP id 35so432527qyk.10 for ; Wed, 03 Aug 2011 13:43:00 -0700 (PDT) Received: by 10.224.30.209 with SMTP id v17mr1281644qac.122.1312404180563; Wed, 03 Aug 2011 13:43:00 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id o4sm582145qaz.5.2011.08.03.13.42.58 (version=SSLv3 cipher=OTHER); Wed, 03 Aug 2011 13:42:59 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 16:42:56 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: [pkix] Certification path In-Reply-To: <201108032019.p73KJl65022194@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:42:49 -0000 On 8/3/11 4:19 PM, "Martin Rex" wrote: >Carl Wallace wrote: >> >> Martin Rex wrote: >> >> > Stephen Kent wrote: >> > > >> > > We have a TA format spec: RFC 5914. >> > >> >But that is about as lame as TLSv1.0 mandating the DH-DSS cipher suite >> >(fixed in TLSv1.1), i.e. completely ignoring the installed base. >> >> The default untagged trust anchor option is a certificate. How is that >> ignoring the installed base? > > >That is a funny way to describe the situation. > >I do not see anything like a default, the TrustAnchorChoice >and the accompanying text describes this as three equal options, >and the tags are to make that thing parsable to the ASN.1 decoder. Default was a poorly chosen word. The point is that the untagged option is a certificate, which can be parsed by the installed base. All certificates are valid TrustAnchorChoice objects. The structure was defined this was specifically because of the installed base. >The tbsCert represents problem number one, and the TrustAnchorInfo >not being able to carry along a regular X.509 certificate is >an even worse problem of that specification. Why is the tbsCert option a problem? It was added at the request of working group members who wanted to add constraints while reusing existing parsing logic. The TrustAnchorInfo structure can wrap a certificate, in the TrustAnchorInfo.certPath.certificate field. Generally, this structure is a form of "X.509 plus X", which you cited several times but never defined earlier in this thread. >While you can convert TBSCertificate <-> TrustAnchorInfo, >converting Certificate -> TBSCertificate and converting >Certificate -> TrustAnchorInfo are clear "one way / no return" routes. >And that is why I consider 5914 broken and generally harmful. If you want to preserve the certificate, wrap it inside a TrustAnchorInfo don't convert it. Why is that harmful? The whole point is to enable the relying party to express and enforce some constraints. You can't do that without making some form of a change. This spec provides two ways to add constraints. Simply issuing a certificate from a TA you control is another available option. Including constraints in a self-signed cert is another way. What are you looking for that cannot be satisfied with these options? From tmiller@mitre.org Wed Aug 3 13:45:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0558311E808C for ; Wed, 3 Aug 2011 13:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRaSylu5OxIj for ; Wed, 3 Aug 2011 13:45:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0A711E8084 for ; Wed, 3 Aug 2011 13:45:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DAC1721B0EF4; Wed, 3 Aug 2011 16:45:31 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D4A4721B007D; Wed, 3 Aug 2011 16:45:31 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 3 Aug 2011 16:45:31 -0400 From: "Miller, Timothy J." To: "mrex@sap.com" Date: Wed, 3 Aug 2011 16:45:29 -0400 Thread-Topic: [pkix] Certification path Thread-Index: AcxSHkiTAzrrQKfuQMmO+NBgQlV4+Q== Message-ID: References: <201108031958.p73JwIAE021157@fs4113.wdf.sap.corp> In-Reply-To: <201108031958.p73JwIAE021157@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1--910319451"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:45:20 -0000 --Apple-Mail-1--910319451 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 3, 2011, at 2:58 PM, Martin Rex wrote: > You might be aware that Microsoft updated the Crypto-API components > of Windows XP to allow sha256WithRsaEncryption for X.509 certificates, > but that does not automatically imply that sha256 is available for > S/Mime in Outlook, for TLS in SChannel or for IPsec on this platform. Which MS, nevertheless, set as the default for Outlook 2010. Just = sayin'. :) -- T --Apple-Mail-1--910319451 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA4MDMyMDQ1MjlaMCMGCSqGSIb3DQEJBDEWBBQD2qfTAjZvuvgHOqGF 7746b9OA/DByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgAG9I9aSjhu0GlmoSLmXVORKkvynjUJ4gFNQ RjFWWYopEUN8pJLVzmQLjirgIKABr3Ewr12Ak2340mvv7E7Jbcw/lixdrzK/Djx9rn+woHHlS724 EI+Rt6BgSB+UHu3obzgKyI1pxHNWIORrSAXik2b1CnUMKPOuxe80syRyEv07AAAAAAAA --Apple-Mail-1--910319451-- From kent@bbn.com Wed Aug 3 15:19:29 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE90221F865E for ; Wed, 3 Aug 2011 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.616 X-Spam-Level: X-Spam-Status: No, score=-106.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOli6JKAxoJu for ; Wed, 3 Aug 2011 15:19:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4C42321F865B for ; Wed, 3 Aug 2011 15:19:29 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49227) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qojmq-0000tH-U6; Wed, 03 Aug 2011 18:19:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <004b01cc51f2$475f5fb0$d61e1f10$@eu> References: <000c01cc49e6$88d15e30$9a741a90$@eu> <002e01cc51e2$e20e2ba0$a62a82e0$@eu> <004b01cc51f2$475f5fb0$d61e1f10$@eu> Date: Wed, 3 Aug 2011 18:19:31 -0400 To: "Erik Andersen" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: 'Directory list' , 'SG17-Q11' , 'PKIX' Subject: Re: [pkix] [Spam] Re: Intermediate CA vs. subject CA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 22:19:29 -0000 At 5:30 PM +0200 8/3/11, Erik Andersen wrote: >Hi, > >I just realised that it is the Informational RFC 4949 that deprecates the >term "subject CA". However, it also deprecates the term "intermediate >CA".RFC 4949 is not a PKIX document, and I have the feeling that PKIX uses >the term "intermediate CA" quite a lot. > >Erik Andersen Yep. Steve From mrex@sap.com Wed Aug 3 16:05:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00011E80AD for ; Wed, 3 Aug 2011 16:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.968 X-Spam-Level: X-Spam-Status: No, score=-9.968 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKMkZpMr5wEy for ; Wed, 3 Aug 2011 16:05:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8763311E809B for ; Wed, 3 Aug 2011 16:05:50 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p73N5wIG001367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 01:05:58 +0200 (MEST) From: Martin Rex Message-Id: <201108032305.p73N5vHa002130@fs4113.wdf.sap.corp> To: carl@redhoundsoftware.com (Carl Wallace) Date: Thu, 4 Aug 2011 01:05:57 +0200 (MEST) In-Reply-To: from "Carl Wallace" at Aug 3, 11 04:42:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 23:05:51 -0000 Carl Wallace wrote: > > On 8/3/11 4:19 PM, "Martin Rex" wrote: > > > >The tbsCert represents problem number one, and the TrustAnchorInfo > >not being able to carry along a regular X.509 certificate is > >an even worse problem of that specification. > > Why is the tbsCert option a problem? It was added at the request of > working group members who wanted to add constraints while reusing existing > parsing logic. I think it is bad because you can not produce a (valid self-signed) X.509 cert from just a tbsCert -- but it is easy and straightforward to extract a tbsCert from an X.509 cert in case that may be necessary for a specific temporary purpose. > > The TrustAnchorInfo structure can wrap a certificate, in the > TrustAnchorInfo.certPath.certificate field. Generally, this structure is > a form of "X.509 plus X", which you cited several times but never defined > earlier in this thread. Admittedly, I had not noticed that carefully buried certificate in that struct. The certificate element in that structure, however, is tagged as "OPTIONAL" in ASN.1, so that this is nothing like "X.509 plus X", it is acutally just "X" (and optionally, if you are very lucky and all planets line up in a row, there may be a certificate present). I know that there is still software around which stores trust anchors as only tbsCert. But most of that software should support adding new trust anchors distributed as X.509 (by extracting and persisting only the tbsCert part from the outer ASN.1 sequence). The thing that I believe should be banished entirely is the distribution of trust anchors with _less_ than X.509. And 5914 fails that. > > If you want to preserve the certificate, wrap it inside a TrustAnchorInfo > don't convert it. Why is that harmful? It is harmful to recommend distribution of TrustAnchor information that is less-than-X.509. And it was entirely unnecessary. -Martin From mrex@sap.com Wed Aug 3 16:30:06 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E620321F8A7D for ; Wed, 3 Aug 2011 16:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.97 X-Spam-Level: X-Spam-Status: No, score=-9.97 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Icjf+ZnO9Ng7 for ; Wed, 3 Aug 2011 16:30:06 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CB0B021F8A7B for ; Wed, 3 Aug 2011 16:30:05 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p73NUAZ3003319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 01:30:10 +0200 (MEST) From: Martin Rex Message-Id: <201108032330.p73NUAPl003821@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 4 Aug 2011 01:30:09 +0200 (MEST) In-Reply-To: <201108032305.p73N5vHa002130@fs4113.wdf.sap.corp> from "Martin Rex" at Aug 4, 11 01:05:57 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 23:30:07 -0000 Martin Rex wrote: > > > The TrustAnchorInfo structure can wrap a certificate, in the > > TrustAnchorInfo.certPath.certificate field. Generally, this structure is > > a form of "X.509 plus X", which you cited several times but never defined > > earlier in this thread. > > Admittedly, I had not noticed that carefully buried certificate in that > struct. The certificate element in that structure, however, is tagged > as "OPTIONAL" in ASN.1, so that this is nothing like "X.509 plus X", > it is acutally just "X" (and optionally, if you are very lucky and all > planets line up in a row, there may be a certificate present). more precisely, in rfc5914, certificate is an OPTIONAL member of CertPathControls, which itself is an OPTIONAL member of TrustAnchorInfo. That is an "Beware of the leopard" approach to deprecate rather that promote "X.509 plus X" trust anchors. -Martin From carl@redhoundsoftware.com Wed Aug 3 17:14:59 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E24B11E80AD for ; Wed, 3 Aug 2011 17:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBxGJD8IbC2M for ; Wed, 3 Aug 2011 17:14:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8521F8757 for ; Wed, 3 Aug 2011 17:14:58 -0700 (PDT) Received: by vws12 with SMTP id 12so85095vws.31 for ; Wed, 03 Aug 2011 17:15:10 -0700 (PDT) Received: by 10.52.182.164 with SMTP id ef4mr183635vdc.319.1312416910221; Wed, 03 Aug 2011 17:15:10 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id o3sm522027vca.26.2011.08.03.17.15.07 (version=SSLv3 cipher=OTHER); Wed, 03 Aug 2011 17:15:09 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 03 Aug 2011 20:15:02 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: [pkix] Certification path In-Reply-To: <201108032330.p73NUAPl003821@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 00:14:59 -0000 On 8/3/11 7:30 PM, "Martin Rex" wrote: >Martin Rex wrote: >> >> > The TrustAnchorInfo structure can wrap a certificate, in the >> > TrustAnchorInfo.certPath.certificate field. Generally, this >>structure is >> > a form of "X.509 plus X", which you cited several times but never >>defined >> > earlier in this thread. >> >> Admittedly, I had not noticed that carefully buried certificate in that >> struct. The certificate element in that structure, however, is tagged >> as "OPTIONAL" in ASN.1, so that this is nothing like "X.509 plus X", >> it is acutally just "X" (and optionally, if you are very lucky and all >> planets line up in a row, there may be a certificate present). > >more precisely, in rfc5914, > > certificate is an OPTIONAL member of CertPathControls, > which itself is an OPTIONAL member of TrustAnchorInfo. > >That is an "Beware of the leopard" approach to deprecate rather >that promote "X.509 plus X" trust anchors. The TrustAnchorInfo structure serves two purposes, minimal representation and wrapping constraints around a certificate. That one purpose does not require a certificate is not an attempt to deprecate the usage of certificates. On 8/3/11 7:05 PM, "Martin Rex" wrote: >I think it is bad because you can not produce a (valid self-signed) >X.509 cert from just a tbsCert -- but it is easy and straightforward >to extract a tbsCert from an X.509 cert in case that may be necessary >for a specific temporary purpose. Simply cracking out the tbsCert is not a goal. Enabling the representation of constraints is a goal. The signature on the (probably self-signed) cert is an obstacle. The spec offers two ways around the obstacle to achieve this goal: remove the signature and wrap the entire structure. >Admittedly, I had not noticed that carefully buried certificate in that >struct. The certificate element in that structure, however, is tagged >as "OPTIONAL" in ASN.1, so that this is nothing like "X.509 plus X", >it is acutally just "X" (and optionally, if you are very lucky and all >planets line up in a row, there may be a certificate present). >>I know that there is still software around which stores trust anchors >as only tbsCert. But most of that software should support adding >new trust anchors distributed as X.509 (by extracting and persisting >only the tbsCert part from the outer ASN.1 sequence). I am confident this structure can be used without planetary alignment and to represent "X.509 plus X". >The thing that I believe should be banished entirely is the distribution >of trust anchors with _less_ than X.509. And 5914 fails that. 5280 requires presentation of a trust anchor name and key as input for path validation. The spec aims to align with this minimal representation. >>If you want to preserve the certificate, wrap it inside a TrustAnchorInfo >>don't convert it. Why is that harmful? > >It is harmful to recommend distribution of TrustAnchor information that >is less-than-X.509. And it was entirely unnecessary. There is no harm in representing a TA as a name and a key, or tbsCert. Whether or not these structures are an unnecessary components of the spec is a matter of opinion. From hotz@jpl.nasa.gov Wed Aug 3 19:30:55 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F90521F8781 for ; Wed, 3 Aug 2011 19:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bpC5-XYzKQy for ; Wed, 3 Aug 2011 19:30:54 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id E7EAD21F8782 for ; Wed, 3 Aug 2011 19:30:54 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p742V7Aq015211 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 3 Aug 2011 19:31:07 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Wed, 3 Aug 2011 19:31:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Carl Wallace X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 02:30:55 -0000 On Aug 3, 2011, at 5:15 PM, Carl Wallace wrote: >> Admittedly, I had not noticed that carefully buried certificate in = that >> struct. The certificate element in that structure, however, is = tagged >> as "OPTIONAL" in ASN.1, so that this is nothing like "X.509 plus X", >> it is acutally just "X" (and optionally, if you are very lucky and = all >> planets line up in a row, there may be a certificate present). >>=20 >> I know that there is still software around which stores trust anchors >> as only tbsCert. But most of that software should support adding >> new trust anchors distributed as X.509 (by extracting and persisting >> only the tbsCert part from the outer ASN.1 sequence). >=20 > I am confident this structure can be used without planetary alignment = and > to represent "X.509 plus X". I think that misses Martin's point. ------ More generally, what I'm getting from this discussion is that the RFCs = do in fact allow you to do sensible things, but they fail to provide = useful guidance as to what things are sensible in areas where I (for = one, anyway) would expect. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From era@x500.eu Thu Aug 4 02:57:03 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4591821F8B7B for ; Thu, 4 Aug 2011 02:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA+fGN+gBkup for ; Thu, 4 Aug 2011 02:57:02 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4143021F8591 for ; Thu, 4 Aug 2011 02:57:01 -0700 (PDT) Received: from Morten ([95.209.225.199]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id NRJ87311; Thu, 04 Aug 2011 11:57:11 +0200 From: "Erik Andersen" To: "PKIX" References: from "Carl Wallace" at Aug 3, 11 04:42:56 pm <201108032305.p73N5vHa002130@fs4113.wdf.sap.corp> In-Reply-To: <201108032305.p73N5vHa002130@fs4113.wdf.sap.corp> Date: Thu, 4 Aug 2011 11:57:08 +0200 Message-ID: <000001cc528c$e494ae30$adbe0a90$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxSMfjsJvWwsp4HQJ6t7+V9Ipru3AAWcPGg Content-Language: da Cc: Directory list , SG17-Q11 Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 09:57:03 -0000 Hi, It seems to me that the PKIX community has some problems in getting to = an agreement whether tbscerts and other non-certs are beneficial for the community or not. I have made some suggestion for updating X.509 that = takes RFC 5914 into account. We will discuss that at our coming Geneva = meeting. The discussion here on this list may introduce some changes to that proposal.=20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Martin Rex Sendt: 4. august 2011 01:06 Til: Carl Wallace Cc: pkix@ietf.org; paul.hoffman@vpnc.org Emne: Re: [pkix] Certification path Carl Wallace wrote: >=20 > On 8/3/11 4:19 PM, "Martin Rex" wrote: > >=20 > >The tbsCert represents problem number one, and the TrustAnchorInfo > >not being able to carry along a regular X.509 certificate is > >an even worse problem of that specification. >=20 > Why is the tbsCert option a problem? It was added at the request of > working group members who wanted to add constraints while reusing = existing > parsing logic. =20 I think it is bad because you can not produce a (valid self-signed) X.509 cert from just a tbsCert -- but it is easy and straightforward to extract a tbsCert from an X.509 cert in case that may be necessary for a specific temporary purpose. >=20 > The TrustAnchorInfo structure can wrap a certificate, in the > TrustAnchorInfo.certPath.certificate field. Generally, this structure = is > a form of "X.509 plus X", which you cited several times but never = defined > earlier in this thread. Admittedly, I had not noticed that carefully buried certificate in that struct. The certificate element in that structure, however, is tagged as "OPTIONAL" in ASN.1, so that this is nothing like "X.509 plus X", it is acutally just "X" (and optionally, if you are very lucky and all planets line up in a row, there may be a certificate present). I know that there is still software around which stores trust anchors as only tbsCert. But most of that software should support adding new trust anchors distributed as X.509 (by extracting and persisting only the tbsCert part from the outer ASN.1 sequence). The thing that I believe should be banished entirely is the distribution of trust anchors with _less_ than X.509. And 5914 fails that. >=20 > If you want to preserve the certificate, wrap it inside a = TrustAnchorInfo > don't convert it. Why is that harmful? It is harmful to recommend distribution of TrustAnchor information that is less-than-X.509. And it was entirely unnecessary. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From era@x500.eu Thu Aug 4 04:10:56 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C57821F8B42 for ; Thu, 4 Aug 2011 04:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcHBot9mILd9 for ; Thu, 4 Aug 2011 04:10:49 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6B87C21F8B47 for ; Thu, 4 Aug 2011 04:10:42 -0700 (PDT) Received: from Morten ([95.209.225.199]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id NTO89753 for ; Thu, 04 Aug 2011 13:10:53 +0200 From: "Erik Andersen" To: "PKIX" References: In-Reply-To: Date: Thu, 4 Aug 2011 13:10:51 +0200 Message-ID: <000701cc5297$3085dbc0$91919340$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxSTp18+NJjZ7WaS9SUtNxhowt9lgAR4K6A Content-Language: da Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:10:56 -0000 OK - I am a little confused. We have definition of a certification path to be: An ordered list of public-key certificates starting with the public-key certificate to be validated, optionally followed by an ordered list of CA certificates, = the last one being signed by a trust anchor. However, if it is important to add restrictions to trust anchor = information, it appears to me that the trust anchor should be part of the = certification path. This a little in conflict with the ASN.1 definition of a = certification path. The ASN.1 could be amended to take trust anchor information into account. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Henry B. Hotz Sendt: 4. august 2011 04:31 Til: Carl Wallace Cc: pkix@ietf.org Emne: Re: [pkix] Certification path On Aug 3, 2011, at 5:15 PM, Carl Wallace wrote: >> Admittedly, I had not noticed that carefully buried certificate in = that >> struct. The certificate element in that structure, however, is = tagged >> as "OPTIONAL" in ASN.1, so that this is nothing like "X.509 plus X", >> it is acutally just "X" (and optionally, if you are very lucky and = all >> planets line up in a row, there may be a certificate present). >>=20 >> I know that there is still software around which stores trust anchors >> as only tbsCert. But most of that software should support adding >> new trust anchors distributed as X.509 (by extracting and persisting >> only the tbsCert part from the outer ASN.1 sequence). >=20 > I am confident this structure can be used without planetary alignment = and > to represent "X.509 plus X". I think that misses Martin's point. ------ More generally, what I'm getting from this discussion is that the RFCs = do in fact allow you to do sensible things, but they fail to provide useful guidance as to what things are sensible in areas where I (for one, = anyway) would expect. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From carl@redhoundsoftware.com Thu Aug 4 04:20:39 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F39D21F8AD1 for ; Thu, 4 Aug 2011 04:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfnKFiAOPs86 for ; Thu, 4 Aug 2011 04:20:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9E21F8B47 for ; Thu, 4 Aug 2011 04:20:36 -0700 (PDT) Received: by vws12 with SMTP id 12so493336vws.31 for ; Thu, 04 Aug 2011 04:20:51 -0700 (PDT) Received: by 10.52.21.176 with SMTP id w16mr664771vde.271.1312456850946; Thu, 04 Aug 2011 04:20:50 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id gi16sm706117vcb.1.2011.08.04.04.20.47 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 04:20:49 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Thu, 04 Aug 2011 07:20:39 -0400 From: Carl Wallace To: Erik Andersen , PKIX Message-ID: Thread-Topic: [pkix] Certification path In-Reply-To: <000701cc5297$3085dbc0$91919340$@eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 11:20:39 -0000 On 8/4/11 7:10 AM, "Erik Andersen" wrote: >OK - I am a little confused. > >We have definition of a certification path to be: An ordered list of >public-key certificates starting with the public-key certificate to be >validated, optionally followed by an ordered list of CA certificates, the >last one being signed by a trust anchor. > >However, if it is important to add restrictions to trust anchor >information, >it appears to me that the trust anchor should be part of the certification >path. This a little in conflict with the ASN.1 definition of a >certification >path. The ASN.1 could be amended to take trust anchor information into >account. The trust anchor resides in the relying parties environment and need not be encoded in a certification path that is transmitted with a message. TA constraints are similar to the inputs to the path validation algorithm. From era@x500.eu Thu Aug 4 05:29:12 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D3821F8B2E for ; Thu, 4 Aug 2011 05:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00gt5TqJ9kw6 for ; Thu, 4 Aug 2011 05:29:11 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5521F8B15 for ; Thu, 4 Aug 2011 05:29:10 -0700 (PDT) Received: from Morten ([95.209.225.199]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id NUH94722; Thu, 04 Aug 2011 14:29:22 +0200 From: "Erik Andersen" To: "'Carl Wallace'" , "'PKIX'" References: <000701cc5297$3085dbc0$91919340$@eu> In-Reply-To: Date: Thu, 4 Aug 2011 14:29:22 +0200 Message-ID: <000b01cc52a2$270f5e80$752e1b80$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxSmJN/fur5Ea22Q1yPkEy8+LU6HQACQApg Content-Language: da Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 12:29:12 -0000 Hi Carl, Thanks for the clarification. So, the trust anchor information is not part of the certification path, but the trust anchor information still has to be considered by the validation procedure. Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: Carl Wallace [mailto:carl@redhoundsoftware.com] Sendt: 4. august 2011 13:21 Til: Erik Andersen; PKIX Emne: Re: [pkix] Certification path On 8/4/11 7:10 AM, "Erik Andersen" wrote: >OK - I am a little confused. > >We have definition of a certification path to be: An ordered list of >public-key certificates starting with the public-key certificate to be >validated, optionally followed by an ordered list of CA certificates, the >last one being signed by a trust anchor. > >However, if it is important to add restrictions to trust anchor >information, >it appears to me that the trust anchor should be part of the certification >path. This a little in conflict with the ASN.1 definition of a >certification >path. The ASN.1 could be amended to take trust anchor information into >account. The trust anchor resides in the relying parties environment and need not be encoded in a certification path that is transmitted with a message. TA constraints are similar to the inputs to the path validation algorithm. From turners@ieca.com Fri Aug 5 13:21:29 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE521F86D2 for ; Fri, 5 Aug 2011 13:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KtlAdqNi5ra for ; Fri, 5 Aug 2011 13:21:27 -0700 (PDT) Received: from nm15.access.bullet.mail.mud.yahoo.com (nm15.access.bullet.mail.mud.yahoo.com [66.94.237.216]) by ietfa.amsl.com (Postfix) with SMTP id F0BBE21F8669 for ; Fri, 5 Aug 2011 13:21:26 -0700 (PDT) Received: from [66.94.237.200] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Aug 2011 20:21:41 -0000 Received: from [98.139.221.60] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Aug 2011 20:21:41 -0000 Received: from [127.0.0.1] by smtp101.biz.mail.bf1.yahoo.com with NNFMP; 05 Aug 2011 20:21:41 -0000 X-Yahoo-Newman-Id: 187700.44788.bm@smtp101.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: p7mS0hEVM1n14qxnljgTmsAO9s9yyn31QgRo.J2jJ8tLWl3 ObuF3LdrslUFllPY6nG9a_uhN_wE.6fQiGR9Xah03RZTaskVghsJJalJZPoM MMGt2jN1fb5JKTQ0PaJBL9oH55_NCAGtgZod6oqxn0TCPBDgBREqmcSCtqB0 luBqtyCo42Zg8cwoRUVOLsbuvEtl1Ey_cWRLEwd0cYIxwusxNkKDuE0TMySa 1vyh0CWhm0akgH7aCMc1HRw8UjF7nu5K9E1gUQpIV4VtFSGdqZf3tTwBKKby ECQsm2m26uVyGF77zdp5XIGPf5KIbqp4MfMZspVBT0kUt8zCR7mjMlMs8slU 4a_7F._zTSpSzb1Dn.k50I12KnvakOPCJUv8qCrcZ.l9vKGMmitPZ8Kltg5C EPTf7_Vn_UeWEyc_klA-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.124.70 with plain) by smtp101.biz.mail.bf1.yahoo.com with SMTP; 05 Aug 2011 13:21:40 -0700 PDT Message-ID: <4E3C50D4.2050607@ieca.com> Date: Fri, 05 Aug 2011 16:21:40 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] another doc for WG consideration X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:21:29 -0000 As author, I support adoption of this work. spt On 7/25/11 5:26 PM, Stephen Kent wrote: > There was a presentation on extending CMC to accommodate scenarios > in which a CA/AR generates the key pair for the subject. I'd like to > hear comments from the WG about adopting this as a work item as well. > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From anders.rundgren@telia.com Fri Aug 5 13:57:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4A511E80C3 for ; Fri, 5 Aug 2011 13:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu5oi4UnMnGD for ; Fri, 5 Aug 2011 13:57:20 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id CE1B411E80C1 for ; Fri, 5 Aug 2011 13:57:19 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B010AD646; Fri, 5 Aug 2011 22:57:31 +0200 Message-ID: <4E3C5932.9060605@telia.com> Date: Fri, 05 Aug 2011 22:57:22 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Sean Turner References: <4E3C50D4.2050607@ieca.com> In-Reply-To: <4E3C50D4.2050607@ieca.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] another doc for WG consideration X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:57:20 -0000 On 2011-08-05 22:21, Sean Turner wrote: > As author, I support adoption of this work. I have no objections to this work, but you should be aware of SKS/KeyGen2 that in addition to offering the mentioned feature also provides support for - Key agility through negotiation - Symmetric keys (like DSKPP/RFC 6063) - Permitted key algorithms - Arbitrary key attributes including . OTP parameters (digits, username) . Information Cards (resurrection of Microsoft's failed project) . Application ACLs (restrict application access) . Executable code (like JavaCard) . VPN parameters (like Apple already have in their iPhone enroll) . etc etc - Key PIN and PUK deployment (standard bank requirement) - Logotypes (a completely different take than RFC 6170) - Password-free but secure enrollment through device certificates all running in and E2ES (End-to-End-Secured) transaction. The latter means that you either get all or nothing. The E2ES session terminates with a signed receipt to issuer in the case of a success. To be hosted in a browser near you using tokens you can buy at Wal-Mart in the form of moderately upgraded USB memory sticks. Anders > > spt > > On 7/25/11 5:26 PM, Stephen Kent wrote: >> There was a presentation on extending CMC to accommodate scenarios >> in which a CA/AR generates the key pair for the subject. I'd like to >> hear comments from the WG about adopting this as a work item as well. >> >> Steve >> _______________________________________________ >> 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 housley@vigilsec.com Fri Aug 5 14:01:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9821F8754 for ; Fri, 5 Aug 2011 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV5Dy9MkcbNp for ; Fri, 5 Aug 2011 14:01:08 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1259D21F874E for ; Fri, 5 Aug 2011 14:01:08 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 6247EF2407D; Fri, 5 Aug 2011 17:01:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id vQEYL4QfbIkg; Fri, 5 Aug 2011 17:01:19 -0400 (EDT) Received: from [192.168.2.101] (pool-96-241-176-45.washdc.fios.verizon.net [96.241.176.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7AF8FF2407A; Fri, 5 Aug 2011 17:01:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Fri, 5 Aug 2011 17:01:24 -0400 Content-Transfer-Encoding: 7bit Message-Id: <157F34E1-C038-4917-AF2D-485E5728EAC6@vigilsec.com> References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] draft-ietf-pkix-rfc5272-bis-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 21:01:08 -0000 I have skimmed this document, and I think we should accept it. Russ On Jul 25, 2011, at 9:39 AM, Stephen Kent wrote: > Folks, > > Jim has posted a revised version of this doc, with a brief secruity > considerations section. The SC section cites 5273 and 5274, and notes that > a few change appear in section 2.12 of this version. > > Please review this SC section and section 2.12 and comment on the list > if there are any concerns. > > Thanks, > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Fri Aug 5 14:26:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C4B11E8082 for ; Fri, 5 Aug 2011 14:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIeaDBmsWVKi for ; Fri, 5 Aug 2011 14:26:46 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 27EF111E8077 for ; Fri, 5 Aug 2011 14:26:46 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 4D498F2419F; Fri, 5 Aug 2011 17:27:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id lxcNQmevxJ2S; Fri, 5 Aug 2011 17:27:02 -0400 (EDT) Received: from [192.168.2.101] (pool-96-241-176-45.washdc.fios.verizon.net [96.241.176.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D9321F24187; Fri, 5 Aug 2011 17:27:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <4E3C50D4.2050607@ieca.com> Date: Fri, 5 Aug 2011 17:27:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E3C50D4.2050607@ieca.com> To: Sean Turner , Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] another doc for WG consideration X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 21:26:46 -0000 Key generation by the CA is real in some very important situations = today. Our protocols need to support it, Russ On Aug 5, 2011, at 4:21 PM, Sean Turner wrote: > As author, I support adoption of this work. >=20 > spt >=20 > On 7/25/11 5:26 PM, Stephen Kent wrote: >> There was a presentation on extending CMC to accommodate scenarios >> in which a CA/AR generates the key pair for the subject. I'd like to >> hear comments from the WG about adopting this as a work item as well. >>=20 >> Steve From anders.rundgren@telia.com Sat Aug 6 09:39:13 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693021F8736 for ; Sat, 6 Aug 2011 09:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBMYlRTSVHMq for ; Sat, 6 Aug 2011 09:39:13 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id D143521F86F4 for ; Sat, 6 Aug 2011 09:39:12 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0098D322 for pkix@ietf.org; Sat, 6 Aug 2011 18:39:32 +0200 Message-ID: <4E3D6E3A.60301@telia.com> Date: Sat, 06 Aug 2011 18:39:22 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] PKCS #11 standard in progress X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 16:39:13 -0000 Locating and enumerating PKCS #11 providers has always been a hassle compared to using Microsoft's CSP. This should have been addressed years ago by the responsible SDO (RSA), but they didn't. The faster and (often) better alternative emerged anyway: http://p11-glue.freedesktop.org/p11-kit.html code + spec = standard Token provisioning is still not covered by CSPs and PKCS #11 so in this case there will a brand new "companion" API for this very purpose. code + spec = standard Anders From denis.pinkas@bull.net Tue Aug 9 01:24:12 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8750F21F8B14 for ; Tue, 9 Aug 2011 01:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm67BT80tpIg for ; Tue, 9 Aug 2011 01:24:12 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id AEB4221F8B12 for ; Tue, 9 Aug 2011 01:24:11 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 314481C2E4 for ; Tue, 9 Aug 2011 10:34:40 +0200 (CEST) In-Reply-To: <302B0530-092F-439C-99CD-2B69F7D830DF@vpnc.org> References: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> <302B0530-092F-439C-99CD-2B69F7D830DF@vpnc.org> To: PKIX MIME-Version: 1.0 X-KeepSent: B6A51DE4:44836E98-C12578E7:002BA2F6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 9 Aug 2011 10:24:37 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 09/08/2011 10:24:37, Serialize complete at 09/08/2011 10:24:37 Content-Type: multipart/alternative; boundary="=_alternative 002E2CD8C12578E7_=" Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 08:24:12 -0000 Message en plusieurs parties au format MIME --=_alternative 002E2CD8C12578E7_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable A few comments about this thread. 1) Since a certification path, as currently defined, does not include the=20 trust anchor,=20 it would be useful to define and name a new ASN.1 construct which would=20 allow=20 to incorporate the trust anchor.=20 A strawman proposal for the name would be: "certification chain". A strawman proposal for the format would be : CertificationChain ::=3D SEQUENCE OF Certificate=20 but this does not say whether the path is forward or backwards. Since=20 X.509 defines: CertificationPath ::=3D SEQUENCE {=20 userCertificate Certificate,=20 theCACertificates SEQUENCE OF CertificatePair OPTIONAL }=20 An alternative strawman proposal for the format would be : CertificationChain ::=3D SEQUENCE {=20 certificationPath CertificationPath,=20 trustAnchor Certificate } The certificate of the trust anchor would be either a self-signed CA=20 certificate or an intermediate CA certificate. Once (or if) there would be some consensus on some approach, then it=20 would be worthwhile to draft a proposal. 2) It is good to maintain the separation of data formats from algorithms:=20 data formats last longer than algorithms. Denis =20 De : Paul Hoffman A : mrex@sap.com Cc : PKIX Date : 03/08/2011 00:12 Objet : Re: [pkix] Certification pathx Envoy=E9 par : pkix-bounces@ietf.org On Aug 2, 2011, at 3:09 PM, Martin Rex wrote: > Such a rationale for a lack of mandatory to implement trust anchor > format scores "lame" on my personal scorecard. And your -00 draft of such a document is where? :-)=20 Seriously, though, it sounds like some people want this, and it could be=20 useful to have a specific target to discuss. --Paul Hoffman =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 002E2CD8C12578E7_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable A few comments about this thread.

1) Since a certification path, as cu= rrently defined, does not include the trust anchor,
it would be useful to define and name a new ASN.1 construct which would allow
to incorporate the trust anchor.

A strawman proposal for the name wou= ld be: "certification chain".

A strawman proposal for the format w= ould be  :

CertificationChain  ::=3D SEQU= ENCE OF Certificate

but this does not say whether the pa= th is forward or backwards. Since X.509 defines:

CertificationPath    ::=3D SEQUENCE {
  userCertificate        Certificate,
  theCACertificates   &nb= sp;  SEQUENCE OF CertificatePair OPTIONAL }

An alternative  strawman propos= al for the format would be  :

CertificationChain    ::= =3D SEQUENCE {
  certificationPath   &nb= sp;  CertificationPath,
  trustAnchor     &n= bsp;              Certificate }

The certificate of the trust anchor would be either a self-signed CA certificate or an intermediate CA certific= ate.

Once (or if) there would be some con= sensus  on some approach, then it would be worthwhile to draft a proposal.


2) It is good to maintain the separa= tion of data formats from algorithms: data formats last longer than algorithms.<= /font>


Denis

 



De :     &= nbsp;  Paul Hoffman <paul.hoffm= an@vpnc.org>
A :     &n= bsp;  mrex@sap.com
Cc :   &nb= sp;    PKIX <pkix@ietf.o= rg>
Date :    =    03/08/2011 00:12
Objet :        Re: [pkix] Certifica= tion pathx
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



On Aug 2, 2011, at 3:09 PM, Martin Rex wrote:

> Such a rationale for a lack of mandatory to implement trust anchor
> format scores "lame" on my personal scorecard.

And your -00 draft of such a document is where? :-)
Seriously, though, it sounds like some people want this, and it could be useful to have a specific target to discuss.

--Paul Hoffman

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 002E2CD8C12578E7_=-- From era@x500.eu Tue Aug 9 01:42:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCBB21F8891 for ; Tue, 9 Aug 2011 01:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwuQjs4v6FXd for ; Tue, 9 Aug 2011 01:42:48 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3F021F8876 for ; Tue, 9 Aug 2011 01:42:47 -0700 (PDT) Received: from Morten ([94.191.141.172]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id SQA34013 for ; Tue, 09 Aug 2011 10:43:13 +0200 From: "Erik Andersen" To: "PKIX" References: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> <302B0530-092F-439C-99CD-2B69F7D830DF@vpnc.org> In-Reply-To: Date: Tue, 9 Aug 2011 10:43:13 +0200 Message-ID: <001e01cc5670$642da2a0$2c88e7e0$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01CC5681.27B672A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxWbdfeBskr9Zi2SfGmNvQA3GLe0gAAhd/g Content-Language: da Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 08:42:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01CC5681.27B672A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Denis, =20 I like your proposal, but you seem to ignore RFC 5914. Is that = intentional? =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik =20 Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af denis.pinkas@bull.net Sendt: 9. august 2011 10:25 Til: PKIX Emne: Re: [pkix] Certification pathx =20 A few comments about this thread.=20 1) Since a certification path, as currently defined, does not include = the trust anchor,=20 it would be useful to define and name a new ASN.1 construct which would allow=20 to incorporate the trust anchor.=20 A strawman proposal for the name would be: "certification chain".=20 A strawman proposal for the format would be :=20 CertificationChain ::=3D SEQUENCE OF Certificate=20 but this does not say whether the path is forward or backwards. Since = X.509 defines:=20 CertificationPath ::=3D SEQUENCE {=20 userCertificate Certificate,=20 theCACertificates SEQUENCE OF CertificatePair OPTIONAL }=20 An alternative strawman proposal for the format would be :=20 CertificationChain ::=3D SEQUENCE {=20 certificationPath CertificationPath,=20 trustAnchor Certificate }=20 The certificate of the trust anchor would be either a self-signed CA certificate or an intermediate CA certificate.=20 Once (or if) there would be some consensus on some approach, then it = would be worthwhile to draft a proposal.=20 2) It is good to maintain the separation of data formats from = algorithms: data formats last longer than algorithms.=20 Denis=20 =20 De : Paul Hoffman =20 A : mrex@sap.com=20 Cc : PKIX =20 Date : 03/08/2011 00:12=20 Objet : Re: [pkix] Certification pathx=20 Envoy=E9 par : pkix-bounces@ietf.org=20 _____ =20 On Aug 2, 2011, at 3:09 PM, Martin Rex wrote: > Such a rationale for a lack of mandatory to implement trust anchor > format scores "lame" on my personal scorecard. And your -00 draft of such a document is where? :-)=20 Seriously, though, it sounds like some people want this, and it could be useful to have a specific target to discuss. --Paul Hoffman _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_001F_01CC5681.27B672A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Denis,

 

I like your proposal, but you seem to ignore RFC 5914. Is that = intentional?

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark

Mobile: = +45 2097 1490

e-amail: = era@x500.eu=

Skype: = andersen-erik

http://www.x500.eu/

=

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik=

 

Fra:<= /b> = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = denis.pinkas@bull.net
Sendt: 9. august 2011 = 10:25
Til: PKIX
Emne: Re: [pkix] Certification = pathx

 

A few = comments about this thread.

1) Since a = certification path, as currently defined, does not include the trust = anchor,
it would be = useful to define and name a new ASN.1 construct which would allow
to = incorporate the trust anchor.

A strawman = proposal for the name would be: "certification chain". =

A strawman = proposal for the format would be  :

CertificationChain =  ::=3D SEQUENCE OF Certificate =

but this = does not say whether the path is forward or backwards. Since X.509 = defines:

CertificationPath =    ::=3D SEQUENCE {
  = userCertificate        Certificate,
  = theCACertificates      SEQUENCE OF CertificatePair = OPTIONAL }

An = alternative  strawman proposal for the format would be =  :

CertificationChain =    ::=3D SEQUENCE {
  = certificationPath      CertificationPath, =
  trustAnchor         =            Certificate = }

The = certificate of the trust anchor would be either a self-signed CA = certificate or an intermediate CA certificate.

Once (or if) = there would be some consensus  on some approach, then it would be = worthwhile to draft a proposal.


2) It is = good to maintain the separation of data formats from algorithms: data = formats last longer than algorithms.


Denis =

 =



= De :        Paul Hoffman = <paul.hoffman@vpnc.org>
= A :        mrex@sap.com
= Cc :        PKIX = <pkix@ietf.org>
= Date :        03/08/2011 = 00:12
= Objet :        Re: [pkix] = Certification pathx
= Envoy=E9 par :        pkix-bounces@i= etf.org




On Aug 2, 2011, at 3:09 PM, Martin Rex = wrote:

> Such a rationale for a lack of mandatory to = implement trust anchor
> format scores "lame" = on my personal scorecard.

And your -00 draft of such a = document is where? :-)
Seriously, though, it sounds like = some people want this, and it could be useful to have a specific target = to discuss.

--Paul = Hoffman

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

------=_NextPart_000_001F_01CC5681.27B672A0-- From denis.pinkas@bull.net Tue Aug 9 02:23:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC83221F8B2B for ; Tue, 9 Aug 2011 02:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmVsT80h-TQj for ; Tue, 9 Aug 2011 02:23:37 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8482E21F8B3C for ; Tue, 9 Aug 2011 02:23:36 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id E42C31C2BD for ; Tue, 9 Aug 2011 11:34:06 +0200 (CEST) In-Reply-To: <001e01cc5670$642da2a0$2c88e7e0$@eu> References: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> <302B0530-092F-439C-99CD-2B69F7D830DF@vpnc.org> <001e01cc5670$642da2a0$2c88e7e0$@eu> To: "PKIX" MIME-Version: 1.0 X-KeepSent: 1C6F6E10:CD679205-C12578E7:0032C989; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 9 Aug 2011 11:24:04 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 09/08/2011 11:24:04, Serialize complete at 09/08/2011 11:24:04 Content-Type: multipart/alternative; boundary="=_alternative 00339B68C12578E7_=" Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 09:23:37 -0000 Message en plusieurs parties au format MIME --=_alternative 00339B68C12578E7_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Erik, It's good to know that you like the proposal. I am well aware of RFC 5914 and at several times I have mentioned on the=20 PKIX list=20 why the content of this document was not (IMO) adequate. This is why I=20 have not proposed=20 to import any data structure defined in RFC 5914. Denis De : "Erik Andersen" A : "PKIX" Date : 09/08/2011 10:43 Objet : Re: [pkix] Certification pathx Envoy=E9 par : pkix-bounces@ietf.org Hi Denis, =20 I like your proposal, but you seem to ignore RFC 5914. Is that=20 intentional? =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik =20 Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af=20 denis.pinkas@bull.net Sendt: 9. august 2011 10:25 Til: PKIX Emne: Re: [pkix] Certification pathx =20 A few comments about this thread.=20 1) Since a certification path, as currently defined, does not include the=20 trust anchor,=20 it would be useful to define and name a new ASN.1 construct which would=20 allow=20 to incorporate the trust anchor.=20 A strawman proposal for the name would be: "certification chain".=20 A strawman proposal for the format would be :=20 CertificationChain ::=3D SEQUENCE OF Certificate=20 but this does not say whether the path is forward or backwards. Since=20 X.509 defines:=20 CertificationPath ::=3D SEQUENCE {=20 userCertificate Certificate,=20 theCACertificates SEQUENCE OF CertificatePair OPTIONAL }=20 An alternative strawman proposal for the format would be :=20 CertificationChain ::=3D SEQUENCE {=20 certificationPath CertificationPath,=20 trustAnchor Certificate }=20 The certificate of the trust anchor would be either a self-signed CA=20 certificate or an intermediate CA certificate.=20 Once (or if) there would be some consensus on some approach, then it=20 would be worthwhile to draft a proposal.=20 2) It is good to maintain the separation of data formats from algorithms:=20 data formats last longer than algorithms.=20 Denis=20 =20 De : Paul Hoffman =20 A : mrex@sap.com=20 Cc : PKIX =20 Date : 03/08/2011 00:12=20 Objet : Re: [pkix] Certification pathx=20 Envoy=E9 par : pkix-bounces@ietf.org=20 On Aug 2, 2011, at 3:09 PM, Martin Rex wrote: > Such a rationale for a lack of mandatory to implement trust anchor > format scores "lame" on my personal scorecard. And your -00 draft of such a document is where? :-)=20 Seriously, though, it sounds like some people want this, and it could be=20 useful to have a specific target to discuss. --Paul Hoffman =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00339B68C12578E7_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Erik,

It's good to know that you like the proposal.

I am well aware of RFC 5914 and at s= everal times I have mentioned on the PKIX list
why the content of this document was not (IMO) adequate. This is why I have not proposed
to import any data structure defined in RFC 5914.

Denis



De :     &= nbsp;  "Erik Andersen" <era@x500.eu>
A :     &n= bsp;  "PKIX" <pkix@i= etf.org>
Date :    =    09/08/2011 10:43
Objet :        Re: [pkix] Certifica= tion pathx
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



Hi Denis,
 
I like your proposal, b= ut you seem to ignore RFC 5914. Is that intentional?
 
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490<= /font>
e-amail: era@x500.e= u
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
 
Fra: pkix-bounces@ietf.org [m= ailto:pkix-bounces@ietf.org] P=E5 vegne af denis.pinkas@bull.net
Sendt: 9. august 2011 10:25
Til: PKIX
Emne: Re: [pkix] Certification pathx
 
A few comments about this thread.<= font size=3D3 face=3D"Times New Roman">

1) Since a certification path, as currently defined, does not include the trust anchor,
it would be useful to define and name a new ASN.1 construct which would allow
to incorporate the trust anchor.

A strawman proposal for the name would be: "certification chain".=

A strawman proposal for the format would be  :

CertificationChain  ::=3D SEQUENCE OF Certificate

but this does not say whether the path is forward or backwards. Since X.509 defines:

CertificationPath    ::=3D SEQUENCE {
 userCertificate        Certificate,
 theCACertificates      SEQUENCE OF CertificatePair OPTIONAL }

An alternative  strawman proposal for the format would be  :

CertificationChain    ::=3D SEQUENCE {
 certificationPath      CertificationPath,
 trustAnchor                    Certificate }

The certificate of the trust anchor would be either a self-signed CA certif= icate or an intermediate CA certificate.

Once (or if) there would be some consensus  on some approach, then it would be worthwhile to draft a proposal.


2) It is good to maintain the separation of data formats from algorithms: data formats last longer than algorithms.


Denis

 



De :        Paul H= offman <paul.hoffman@vpnc.org>
A :        mrex@sa= p.com
Cc :        PKIX &= lt;pkix@ietf.org>
Date :        03/0= 8/2011 00:12
Objet :        Re: [pkix] Certification pathx <= /font>
Envoy=E9 par :        pkix-bounces@ietf.org





On Aug 2, 2011, at 3:09 PM, Martin Rex wrote:

> Such a rationale for a lack of mandatory to implement trust anchor
> format scores "lame" on my personal scorecard.

And your -00 draft of such a document is where? :-)
Seriously, though, it sounds like some people want this, and it could be useful to have a specific target to discuss.

--Paul Hoffman

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/list= info/pkix=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 00339B68C12578E7_=-- From era@x500.eu Tue Aug 9 03:52:26 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F4321F8B0E for ; Tue, 9 Aug 2011 03:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oOjg-qya46e for ; Tue, 9 Aug 2011 03:52:25 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20D21F8747 for ; Tue, 9 Aug 2011 03:52:20 -0700 (PDT) Received: from Morten ([94.191.141.172]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id SSJ82845; Tue, 09 Aug 2011 12:52:45 +0200 From: "Erik Andersen" To: "'PKIX'" References: <201108022209.p72M9UIm007166@fs4113.wdf.sap.corp> <302B0530-092F-439C-99CD-2B69F7D830DF@vpnc.org> <001e01cc5670$642da2a0$2c88e7e0$@eu> In-Reply-To: Date: Tue, 9 Aug 2011 12:52:44 +0200 Message-ID: <002f01cc5682$7ced5e90$76c81bb0$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CC5693.40762E90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxWdivtufNs0pFXT0C2Rzu31zyDZAAC5lhw Content-Language: da Cc: Directory list , SG17-Q11 Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 10:52:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0030_01CC5693.40762E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Denis, =20 You are not the only one express concern with RFC 5914. I wonder whether = it should be mentioned in X.509 at all. We will take that discussion up in Geneva. =20 Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik =20 Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af denis.pinkas@bull.net Sendt: 9. august 2011 11:24 Til: PKIX Emne: Re: [pkix] Certification pathx =20 Hi Erik,=20 It's good to know that you like the proposal.=20 I am well aware of RFC 5914 and at several times I have mentioned on the PKIX list=20 why the content of this document was not (IMO) adequate. This is why I = have not proposed=20 to import any data structure defined in RFC 5914.=20 Denis=20 De : "Erik Andersen" =20 A : "PKIX" =20 Date : 09/08/2011 10:43=20 Objet : Re: [pkix] Certification pathx=20 Envoy=E9 par : pkix-bounces@ietf.org=20 _____ =20 Hi Denis,=20 =20 I like your proposal, but you seem to ignore RFC 5914. Is that = intentional?=20 =20 Erik Andersen=20 Andersen's L-Service=20 Elsevej 48,=20 DK-3500 Vaerloese=20 Denmark=20 Mobile: +45 2097 1490=20 e-amail: era@x500.eu=20 Skype: andersen-erik=20 http://www.x500.eu/=20 http://www.x500standard.com/=20 http://dk.linkedin.com/in/andersenerik=20 =20 Fra: pkix-bounces@ietf.org [ mailto:pkix-bounces@ietf.org] P=E5 vegne af denis.pinkas@bull.net Sendt: 9. august 2011 10:25 Til: PKIX Emne: Re: [pkix] Certification pathx=20 =20 A few comments about this thread.=20 1) Since a certification path, as currently defined, does not include = the trust anchor,=20 it would be useful to define and name a new ASN.1 construct which would allow=20 to incorporate the trust anchor.=20 A strawman proposal for the name would be: "certification chain".=20 A strawman proposal for the format would be :=20 CertificationChain ::=3D SEQUENCE OF Certificate=20 but this does not say whether the path is forward or backwards. Since = X.509 defines:=20 CertificationPath ::=3D SEQUENCE {=20 userCertificate Certificate,=20 theCACertificates SEQUENCE OF CertificatePair OPTIONAL }=20 An alternative strawman proposal for the format would be :=20 CertificationChain ::=3D SEQUENCE {=20 certificationPath CertificationPath,=20 trustAnchor Certificate }=20 The certificate of the trust anchor would be either a self-signed CA certificate or an intermediate CA certificate.=20 Once (or if) there would be some consensus on some approach, then it = would be worthwhile to draft a proposal.=20 2) It is good to maintain the separation of data formats from = algorithms: data formats last longer than algorithms.=20 Denis=20 =20 De : Paul Hoffman =20 A : mrex@sap.com=20 Cc : PKIX =20 Date : 03/08/2011 00:12=20 Objet : Re: [pkix] Certification pathx=20 Envoy=E9 par : pkix-bounces@ietf.org=20 =20 _____ =20 On Aug 2, 2011, at 3:09 PM, Martin Rex wrote: > Such a rationale for a lack of mandatory to implement trust anchor > format scores "lame" on my personal scorecard. And your -00 draft of such a document is where? :-)=20 Seriously, though, it sounds like some people want this, and it could be useful to have a specific target to discuss. --Paul Hoffman _______________________________________________ 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 ------=_NextPart_000_0030_01CC5693.40762E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Denis,

 

You are not the only one express concern with RFC 5914. I wonder = whether it should be mentioned in X.509 at all. We will take that = discussion up in Geneva.

 

Erik = Andersen

Andersen's = L-Service

Elsevej = 48,

DK-3500 = Vaerloese

Denmark

Mobile: = +45 2097 1490

e-amail: = era@x500.eu=

Skype: = andersen-erik

http://www.x500.eu/

=

http://www.x500standard.com/

http://dk.linkedin.com/in/andersenerik=

 

Fra:<= /b> = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = denis.pinkas@bull.net
Sendt: 9. august 2011 = 11:24
Til: PKIX
Emne: Re: [pkix] Certification = pathx

 

Hi = Erik,

It's good to = know that you like the proposal.

I am well = aware of RFC 5914 and at several times I have mentioned on the PKIX list =
why the content of this document was not (IMO) adequate. This is why = I have not proposed
to import any data structure defined in RFC = 5914.

Denis =



= De :        "Erik = Andersen" <era@x500.eu>
= A :        "PKIX&quo= t; <pkix@ietf.org>
= Date :        09/08/2011 = 10:43
= Objet :        Re: [pkix] = Certification pathx
= Envoy=E9 par :        pkix-bounces@i= etf.org




Hi = Denis,
  =
I = like your proposal, but you seem to ignore RFC 5914. Is that = intentional?
  =
Erik = Andersen
Andersen's L-Service =
Elsevej = 48,
DK-3500 Vaerloese =
Denmark =
Mobile: +45 2097 = 1490
e-amail: era@x500.eu
Skype: andersen-erik =
http://www.x500.eu/
http://www.x500standard.com/ =
http://dk.linkedin.com/in/andersenerik
  =
Fra: pkix-bounces@ietf.org = [mailto:pkix-bounces@ietf.org<= /span>] P=E5 = vegne af denis.pinkas@bull.net
Sendt: 9. august 2011 = 10:25
Til: PKIX
Emne: Re: [pkix] Certification = pathx
 
A few comments about this = thread.

1) Since a certification = path, as currently defined, does not include the trust anchor,
it = would be useful to define and name a new ASN.1 construct which would = allow
to incorporate the trust anchor.

A strawman proposal for = the name would be: "certification chain".

A strawman proposal for = the format would be  :

CertificationChain  ::=3D = SEQUENCE OF Certificate

but this does not say = whether the path is forward or backwards. Since X.509 defines: =

CertificationPath =    ::=3D SEQUENCE {
 userCertificate     =    Certificate,
 theCACertificates     =  SEQUENCE OF CertificatePair OPTIONAL }

An alternative =  strawman proposal for the format would be  :

CertificationChain   =  ::=3D SEQUENCE {
 certificationPath     =  CertificationPath,
 trustAnchor       =     =          Certificate }

The certificate of the = trust anchor would be either a self-signed CA certificate or an = intermediate CA certificate.

Once (or if) there would = be some consensus  on some approach, then it would be worthwhile to = draft a proposal.


2) It is good to maintain = the separation of data formats from algorithms: data formats last longer = than algorithms.


Denis

 


<= span style=3D'font-family:"Arial","sans-serif";color:#5F5F5F'>
De : =        Paul Hoffman = <paul.hoffman@vpnc.org>
A :   =      mrex@sap.com
Cc :   =      PKIX = <pkix@ietf.org>
Date : =        03/08/2011 00:12
Objet : =        Re: [pkix] Certification = pathx
Envoy=E9 = par :        pkix-bounces@ietf.org =

 





On Aug 2, 2011, at 3:09 PM, = Martin Rex wrote:

> Such a rationale for a lack of mandatory = to implement trust anchor
> format scores "lame" on my = personal scorecard.

And your -00 draft of such a document is = where? :-)
Seriously, though, it sounds like some people want this, = and it could be useful to have a specific target to = discuss.

--Paul = Hoffman

_______________________________________________
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

------=_NextPart_000_0030_01CC5693.40762E90-- From mrex@sap.com Tue Aug 9 07:17:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAB021F86C3 for ; Tue, 9 Aug 2011 07:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.983 X-Spam-Level: X-Spam-Status: No, score=-9.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqiOWKIBOkIc for ; Tue, 9 Aug 2011 07:17:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 50A0321F863E for ; Tue, 9 Aug 2011 07:17:19 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p79EHjwh015624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Aug 2011 16:17:45 +0200 (MEST) From: Martin Rex Message-Id: <201108091417.p79EHjXw027492@fs4113.wdf.sap.corp> To: denis.pinkas@bull.net Date: Tue, 9 Aug 2011 16:17:45 +0200 (MEST) In-Reply-To: from "denis.pinkas@bull.net" at Aug 9, 11 10:24:37 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 14:17:20 -0000 denis.pinkas@bull.net wrote: > > 1) Since a certification path, as currently defined, does not include the > trust anchor, it would be useful to define and name a new ASN.1 > construct which would allow to incorporate the trust anchor. > > A strawman proposal for the name would be: "certification chain". > > A strawman proposal for the format would be : > > CertificationChain ::= SEQUENCE OF Certificate > > but this does not say whether the path is forward or backwards. Since > X.509 defines: > > CertificationPath ::= SEQUENCE { > userCertificate Certificate, > theCACertificates SEQUENCE OF CertificatePair OPTIONAL } There is a newer definition: X509PKIPathv1 -- which is described in X.509 Defect Report 279 and is already used by the Web Service Security -- Security Token Profile. e.g. http://ftp.sunet.se/pub/security/dfnpca/docs/X509/DefectResolution/DefectReports/X.509andRelated/DR_279Rev1.pdf a) In clause 7, add the following immediately after the ASN.1 CrossCertificates production: PkiPath ::= SEQUENCE OF Certificate PkiPath is used to represent a certification path. Within the sequence, the order of certificates is such that the subject of the first certificate is the issuer of the second certificate, etc. -Martin From denis.pinkas@bull.net Tue Aug 9 07:27:03 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4D421F8726 for ; Tue, 9 Aug 2011 07:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkIcJoKi5OeH for ; Tue, 9 Aug 2011 07:27:03 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id DF21D21F86EC for ; Tue, 9 Aug 2011 07:27:02 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 2166A1C28C for ; Tue, 9 Aug 2011 16:37:34 +0200 (CEST) In-Reply-To: <201108091417.p79EHjXw027492@fs4113.wdf.sap.corp> References: from "denis.pinkas@bull.net" at Aug 9, 11 10:24:37 am <201108091417.p79EHjXw027492@fs4113.wdf.sap.corp> To: pkix@ietf.org MIME-Version: 1.0 X-KeepSent: ED3D6ACE:39110C11-C12578E7:004EEF4F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 9 Aug 2011 16:27:31 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 09/08/2011 16:27:31, Serialize complete at 09/08/2011 16:27:31 Content-Type: multipart/alternative; boundary="=_alternative 004F5D22C12578E7_=" Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 14:27:04 -0000 Message en plusieurs parties au format MIME --=_alternative 004F5D22C12578E7_= Content-Type: text/plain; charset="US-ASCII" Martin, PkiPath does not solve the concern, since the text states: pkiPath is used to represent a certification path The use of the wording "certification path" mandates that the certificate of the trust anchor is NOT included. Here we are looking for a structure which includes it. Denis De : Martin Rex A : denis.pinkas@bull.net Cc : pkix@ietf.org Date : 09/08/2011 16:17 Objet : Re: [pkix] Certification pathx denis.pinkas@bull.net wrote: > > 1) Since a certification path, as currently defined, does not include the > trust anchor, it would be useful to define and name a new ASN.1 > construct which would allow to incorporate the trust anchor. > > A strawman proposal for the name would be: "certification chain". > > A strawman proposal for the format would be : > > CertificationChain ::= SEQUENCE OF Certificate > > but this does not say whether the path is forward or backwards. Since > X.509 defines: > > CertificationPath ::= SEQUENCE { > userCertificate Certificate, > theCACertificates SEQUENCE OF CertificatePair OPTIONAL } There is a newer definition: X509PKIPathv1 -- which is described in X.509 Defect Report 279 and is already used by the Web Service Security -- Security Token Profile. e.g. http://ftp.sunet.se/pub/security/dfnpca/docs/X509/DefectResolution/DefectReports/X.509andRelated/DR_279Rev1.pdf a) In clause 7, add the following immediately after the ASN.1 CrossCertificates production: PkiPath ::= SEQUENCE OF Certificate PkiPath is used to represent a certification path. Within the sequence, the order of certificates is such that the subject of the first certificate is the issuer of the second certificate, etc. -Martin --=_alternative 004F5D22C12578E7_= Content-Type: text/html; charset="US-ASCII" Martin,

PkiPath does not solve the concern, since the text states:
pkiPath is used to represent a certification path
The use of the wording "certification path"  mandates
that the certificate of the trust anchor is NOT included.

Here we are looking for a structure which includes it.

Denis




De :        Martin Rex <mrex@sap.com>
A :        denis.pinkas@bull.net
Cc :        pkix@ietf.org
Date :        09/08/2011 16:17
Objet :        Re: [pkix] Certification pathx



denis.pinkas@bull.net wrote:
>
> 1) Since a certification path, as currently defined, does not include the
>    trust anchor, it would be useful to define and name a new ASN.1
>    construct which would allow to incorporate the trust anchor.
>
> A strawman proposal for the name would be: "certification chain".
>
> A strawman proposal for the format would be  :
>
> CertificationChain  ::= SEQUENCE OF Certificate
>
> but this does not say whether the path is forward or backwards. Since
> X.509 defines:
>
> CertificationPath    ::= SEQUENCE {
>   userCertificate        Certificate,
>   theCACertificates      SEQUENCE OF CertificatePair OPTIONAL }


There is a newer definition:  X509PKIPathv1
-- which is described in X.509 Defect Report 279 and is already used by
the Web Service Security -- Security Token Profile.

e.g. http://ftp.sunet.se/pub/security/dfnpca/docs/X509/DefectResolution/DefectReports/X.509andRelated/DR_279Rev1.pdf

 a) In clause 7, add the following immediately after the
    ASN.1 CrossCertificates production:

        PkiPath ::= SEQUENCE OF Certificate

    PkiPath is used to represent a certification path. Within the sequence,
    the order of certificates is such that the subject of the first
    certificate is the issuer of the second certificate, etc.



-Martin
--=_alternative 004F5D22C12578E7_=-- From mrex@sap.com Tue Aug 9 07:40:31 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51D321F8764 for ; Tue, 9 Aug 2011 07:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.985 X-Spam-Level: X-Spam-Status: No, score=-9.985 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RtKEY82hBXO for ; Tue, 9 Aug 2011 07:40:31 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3637421F8500 for ; Tue, 9 Aug 2011 07:40:30 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p79EexQh021812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Aug 2011 16:40:59 +0200 (MEST) From: Martin Rex Message-Id: <201108091440.p79EewRQ029234@fs4113.wdf.sap.corp> To: denis.pinkas@bull.net Date: Tue, 9 Aug 2011 16:40:58 +0200 (MEST) In-Reply-To: from "denis.pinkas@bull.net" at Aug 9, 11 04:27:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 14:40:32 -0000 denis.pinkas@bull.net wrote: > > PkiPath does not solve the concern, since the text states: > pkiPath is used to represent a certification path > The use of the wording "certification path" mandates > that the certificate of the trust anchor is NOT included. Primarily I want to completely avoid the CertificatePair nonsense. I don't have access to the X.509 spec itself, but the Defect Report itself does _not_ contain words to the effect that a TA cert is not allowed as the first certificate in the path. Which of the missing parts of X.509 explicitly requires that there must not be a self-signed certificate included as the first cert in PkiPath? > > Here we are looking for a structure which includes it. You could still compose a sequence from X509PKIPathv1 plus a TA cert. -Martin From era@x500.eu Wed Aug 10 00:45:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A552021F86DE for ; Wed, 10 Aug 2011 00:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3ODmEOxbxCj for ; Wed, 10 Aug 2011 00:45:19 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id 027B121F86DC for ; Wed, 10 Aug 2011 00:45:18 -0700 (PDT) Received: from Morten ([94.191.138.107]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id TPD68647 for ; Wed, 10 Aug 2011 09:45:47 +0200 From: "Erik Andersen" To: "PKIX" References: from "denis.pinkas@bull.net" at Aug 9, 11 04:27:31 pm <201108091440.p79EewRQ029234@fs4113.wdf.sap.corp> In-Reply-To: <201108091440.p79EewRQ029234@fs4113.wdf.sap.corp> Date: Wed, 10 Aug 2011 09:45:48 +0200 Message-ID: <001201cc5731$891c9eb0$9b55dc10$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxWomSj0IOjMRCIQK6dZdK9LW0oeAAjDqmw Content-Language: da Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 07:45:20 -0000 Hi Martin, As to your question about self-signed certificate. I do not see that restriction in X.509. However, a to-be-signed certificate cannot be = included using the current definition. Neither can the structure defined in RFC = 5914. One problem with PkiPath is that it points in the opposite direction = than our current definition (down vs. up). I also have a problem with CertificatePair. If not coded correctly, the = path could be broken. X.509 may be freely downloaded (http://www.itu.int/rec/T-REC-X.509-200811-I/en). Erik Andersen Andersen's L-Service Elsevej 48, DK-3500 Vaerloese Denmark Mobile: +45 2097 1490 e-amail: era@x500.eu Skype: andersen-erik http://www.x500.eu/ http://www.x500standard.com/ http://dk.linkedin.com/in/andersenerik -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Martin Rex Sendt: 9. august 2011 16:41 Til: denis.pinkas@bull.net Cc: pkix@ietf.org Emne: Re: [pkix] Certification pathx denis.pinkas@bull.net wrote: >=20 > PkiPath does not solve the concern, since the text states:=20 > pkiPath is used to represent a certification path > The use of the wording "certification path" mandates=20 > that the certificate of the trust anchor is NOT included. Primarily I want to completely avoid the CertificatePair nonsense. I don't have access to the X.509 spec itself, but the Defect Report itself does _not_ contain words to the effect that a TA cert is not allowed as the first certificate in the path. Which of the missing parts of X.509 explicitly requires that there must not be a self-signed certificate included as the first cert in PkiPath? >=20 > Here we are looking for a structure which includes it. You could still compose a sequence from X509PKIPathv1 plus a TA cert. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Wed Aug 10 09:10:41 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584FC21F8ABC for ; Wed, 10 Aug 2011 09:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.613 X-Spam-Level: X-Spam-Status: No, score=-106.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z11gRZH21rPO for ; Wed, 10 Aug 2011 09:10:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 58E7121F8AA8 for ; Wed, 10 Aug 2011 09:10:40 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49215) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrBN9-000NpJ-Nb; Wed, 10 Aug 2011 12:11:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <001201cc5731$891c9eb0$9b55dc10$@eu> References: from "denis.pinkas@bull.net" at Aug 9, 11 04:27:31 pm <201108091440.p79EewRQ029234@fs4113.wdf.sap.corp> <001201cc5731$891c9eb0$9b55dc10$@eu> Date: Wed, 10 Aug 2011 12:09:45 -0400 To: "Erik Andersen" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: PKIX Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 16:10:41 -0000 At 9:45 AM +0200 8/10/11, Erik Andersen wrote: >Hi Martin, > >As to your question about self-signed certificate. I do not see that >restriction in X.509. no, but a cert path is processed relative to the cert path validation alg, and that alg starts at a TA. Steve From mrex@sap.com Wed Aug 10 12:12:44 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE511E8089 for ; Wed, 10 Aug 2011 12:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.99 X-Spam-Level: X-Spam-Status: No, score=-9.99 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ubHyIZAkokV for ; Wed, 10 Aug 2011 12:12:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1BE11E8081 for ; Wed, 10 Aug 2011 12:12:38 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p7AJD8VO005232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2011 21:13:08 +0200 (MEST) From: Martin Rex Message-Id: <201108101913.p7AJD8rW020410@fs4113.wdf.sap.corp> To: era@x500.eu (Erik Andersen) Date: Wed, 10 Aug 2011 21:13:08 +0200 (MEST) In-Reply-To: <001201cc5731$891c9eb0$9b55dc10$@eu> from "Erik Andersen" at Aug 10, 11 09:45:48 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 19:12:45 -0000 Erik Andersen wrote: > > As to your question about self-signed certificate. I do not see that > restriction in X.509. Great! > > However, a to-be-signed certificate cannot be included using the > current definition. Neither can the structure defined in RFC 5914. I believe it would be unreasonable to include anything else than a valid self-signed certificate in the PkiPath. "TrustAnchor" is a purely local concept. When including a self-signed certificate as first element in a PkiPath, it just makes the path complete while the data is still integrity protected (and covers the situation where the communication peer might be using a self-signed X.509 certificate, so that trust can not be derived from any CAs at all. Neither the TBSCertificate nor the TrustAnchorInfo data is integrity protected, so it would be pretty useless to make _that_ data part of pkiPath. The only sensible information to include is a self-signed X.509 TA cert -- which for the purpose of pkiPath is just a cert with integrity-self-protection, not a TrustAnchor. If the recipient of the pkiPath does not recognize a TrustAnchor identified by the selfsigned TA cert, there two options to proceed involving human interaction, either perform an out-of-band validation, like checking the public key fingerprint of the TA cert or checking the TA cert certificate fingerprint, or make the TA cert a valid TrustAnchor in a leap-of-faith (similar to how PGP, SSH and most software distribution does key bootstrapping). > > One problem with PkiPath is that it points in the opposite direction than > our current definition (down vs. up). While I personally also favor the TLS approach (signer cert first) to the pkiPath approach, I don't think that should be show-stopper. Adding another ASN.1 structure (SEQUENCE OF Certificate) with the opposite direction will probably make things worse. http://xkcd.com/927/ > > X.509 may be freely downloaded > (http://www.itu.int/rec/T-REC-X.509-200811-I/en). Big Thanks for that URL!! -Martin From kent@bbn.com Wed Aug 10 12:12:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757FC11E8090 for ; Wed, 10 Aug 2011 12:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.612 X-Spam-Level: X-Spam-Status: No, score=-106.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmdyrTV6Coxv for ; Wed, 10 Aug 2011 12:12:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E8EF211E808E for ; Wed, 10 Aug 2011 12:12:50 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49222) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrEDR-00008Z-9H; Wed, 10 Aug 2011 15:13:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201108032305.p73N5vHa002130@fs4113.wdf.sap.corp> References: <201108032305.p73N5vHa002130@fs4113.wdf.sap.corp> Date: Wed, 10 Aug 2011 15:13:11 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 19:12:51 -0000 >... >It is harmful to recommend distribution of TrustAnchor information that >is less-than-X.509. And it was entirely unnecessary. > >-Martin IF RPs were required to make use of the various fields & extensions in a self-signed cert as constraints in path validation, your assertion might be appropriate. But, the base X.509 and PKIX standards do not mandate that. (RFC 5914 addresses this issue and provides a basis for use of such data.) Moreover, implementations are quite varied in their support for making use of these values (in path validation). Thus there is no solid basis for arguing that a self-signed cert is the MUST be supported TA format. Steve From mrex@sap.com Wed Aug 10 12:31:57 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397DE21F8596 for ; Wed, 10 Aug 2011 12:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.992 X-Spam-Level: X-Spam-Status: No, score=-9.992 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+JOx6bG0GWK for ; Wed, 10 Aug 2011 12:31:54 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8684521F8A55 for ; Wed, 10 Aug 2011 12:31:54 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7AJWJ98019298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2011 21:32:20 +0200 (MEST) From: Martin Rex Message-Id: <201108101932.p7AJWJ56021400@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Wed, 10 Aug 2011 21:32:19 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Aug 10, 11 12:09:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 19:31:57 -0000 Stephen Kent wrote: > > At 9:45 AM +0200 8/10/11, Erik Andersen wrote: > >Hi Martin, > > > >As to your question about self-signed certificate. I do not see that > >restriction in X.509. > > no, but a cert path is processed relative to the cert path validation alg, > and that alg starts at a TA. The description of the path validation algorithm is significantly and needlessly convoluted in that area, that it ought to be fixed anyway. While rfc5280 Section 6.1 says that the path validation starts with a prospective(!!) certification path, and policy and constraints processing does not seem to have a problem specifying to skip self-issued certs on the _prospective_ path, the algorithm as described in rfc5280 Section 6.1 fails to provide a sensible guidance how to deal with a TA cert appearing at the beginning of a prospective certification path. http://tools.ietf.org/html/rfc5280#page-73 To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (b) certificate 1 is issued by the trust anchor; (c) certificate n is the certificate to be validated (i.e., the target certificate); and (d) for all x in {1, ..., n}, the certificate was valid at the time in question. A certificate MUST NOT appear more than once in a prospective certification path. When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors is provided as inputs to the certification path validation algorithm But this flaw _only_ affects the description of the algorithm in rfc5280, implementations of this algorithm, such as TLS clients, seem to cope with that situation sensibly do not exhibit a problem. The words "this self-signed certificate is not included as part of the prospective certification path" is not only non-sensical, but also self-contradictory for an algorithm(!!) that is supposed to describe processing of a prospective(!!!) certification path. -Martin From mrex@sap.com Wed Aug 10 12:45:51 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3189721F8B6D for ; Wed, 10 Aug 2011 12:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.994 X-Spam-Level: X-Spam-Status: No, score=-9.994 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-7kg2Kwbk8P for ; Wed, 10 Aug 2011 12:45:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDEF21F8B68 for ; Wed, 10 Aug 2011 12:45:50 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7AJkDYb025635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2011 21:46:13 +0200 (MEST) From: Martin Rex Message-Id: <201108101946.p7AJkCmp022191@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Wed, 10 Aug 2011 21:46:12 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Aug 10, 11 03:13:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 19:45:51 -0000 Stephen Kent wrote: > > >... > >It is harmful to recommend distribution of TrustAnchor information that > >is less-than-X.509. And it was entirely unnecessary. > > > >-Martin > > IF RPs were required to make use of the various fields & extensions in a > self-signed cert as constraints in path validation, your assertion might > be appropriate. But, the base X.509 and PKIX standards do not mandate that. > (RFC 5914 addresses this issue and provides a basis for use of such > data.) Moreover, implementations are quite varied in their support for > making use of these values (in path validation). Thus there is no > solid basis for arguing that a self-signed cert is the MUST be > supported TA format. That description is confusing things considerably. As I just wrote in a previous Email, rfc5280 Section 6.1 describes an (evendentally incomplete/flawed) algorithm to process a prospective certification path, and while the processing of policies and constraints special cases processing of self-issued certificates, the processing of TA certs that might appear at the beginning of a prospective(!!) certification path are obviously underspecified (in the document), although implementations seem to cope with the situation quite well. Mandating that a trust anchor be distributed as X.509 plus X (in a trust anchor distribution protocol) is entirely independent from the processing of any potential TA cert appearing as the first certificate of a prospective certification path. Just as it seemed useful or necessary to specify skipping of self-issued certs under certain conditions in policy and constraints processing, it should be a no-brainer to exempt a TA cert at the beginning of a _prospective_ certification path from processing. -Martin From david.cooper@nist.gov Wed Aug 10 13:21:16 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713A311E80A3 for ; Wed, 10 Aug 2011 13:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6PeAKA+xQ1U for ; Wed, 10 Aug 2011 13:21:15 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9B77111E8094 for ; Wed, 10 Aug 2011 13:21:15 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p7AKLckN020582; Wed, 10 Aug 2011 16:21:39 -0400 Message-ID: <4E42E852.1020305@nist.gov> Date: Wed, 10 Aug 2011 16:21:38 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Mandriva/3.1.11-0.1mdv2010.2 (2010.2) Thunderbird/3.1.11 MIME-Version: 1.0 To: "mrex@sap.com" References: <201108101946.p7AJkCmp022191@fs4113.wdf.sap.corp> In-Reply-To: <201108101946.p7AJkCmp022191@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 20:21:16 -0000 Martin, Are you saying that you believe that the path validation algorithm in Section 6 needs to include a statement similar to the one that appears in X.509: X.509, Clause 10.5.1: The following checks are applied to a certificate. Self-signed certificates, if encountered in the path, are ignored. X.509, Clause 10.5.2: For an intermediate certificate, the following constraint recording actions are then performed, in order correctly to set up the state variables for the processing of the next certificate. Self-signed certificates, if encountered in the path, are ignored. The closest text that seems to appear in RFC 5280 is: When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. The main difference is really just that RFC 5280 doesn't seem to consider the possibility that a self-signed certificate might be encountered in the middle of a certification path. Otherwise, RFC 5280 obtains the same result as X.509 by imposing a pre-processing requirement to ensure that the first certificate in the prospective certification path isn't a self-signed certificate. Is there anything wrong with that? Is it really any different than: A certificate MUST NOT appear more than once in a prospective certification path. On 08/10/2011 03:46 PM, Martin Rex wrote: > Stephen Kent wrote: >>> ... >>> It is harmful to recommend distribution of TrustAnchor information that >>> is less-than-X.509. And it was entirely unnecessary. >>> >>> -Martin >> IF RPs were required to make use of the various fields& extensions in a >> self-signed cert as constraints in path validation, your assertion might >> be appropriate. But, the base X.509 and PKIX standards do not mandate that. >> (RFC 5914 addresses this issue and provides a basis for use of such >> data.) Moreover, implementations are quite varied in their support for >> making use of these values (in path validation). Thus there is no >> solid basis for arguing that a self-signed cert is the MUST be >> supported TA format. > > That description is confusing things considerably. > > As I just wrote in a previous Email, rfc5280 Section 6.1 describes an > (evendentally incomplete/flawed) algorithm to process a prospective > certification path, and while the processing of policies and constraints > special cases processing of self-issued certificates, the processing > of TA certs that might appear at the beginning of a prospective(!!) > certification path are obviously underspecified (in the document), > although implementations seem to cope with the situation quite well. > > Mandating that a trust anchor be distributed as X.509 plus X > (in a trust anchor distribution protocol) is entirely independent > from the processing of any potential TA cert appearing as the first > certificate of a prospective certification path. Just as it seemed > useful or necessary to specify skipping of self-issued certs under > certain conditions in policy and constraints processing, it should > be a no-brainer to exempt a TA cert at the beginning of a _prospective_ > certification path from processing. > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Wed Aug 10 13:24:34 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CEC228014 for ; Wed, 10 Aug 2011 13:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUzOU0RiE4bY for ; Wed, 10 Aug 2011 13:24:34 -0700 (PDT) Received: from mail165.messagelabs.com (mail165.messagelabs.com [216.82.253.147]) by ietfa.amsl.com (Postfix) with ESMTP id EF7BA228012 for ; Wed, 10 Aug 2011 13:24:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: SChokhani@cygnacom.com X-Msg-Ref: server-2.tower-165.messagelabs.com!1313007869!14829762!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [216.191.252.22] Received: (qmail 4323 invoked from network); 10 Aug 2011 20:24:30 -0000 Received: from sottexche2.entrust.com (HELO sottexchE2.entrust.com) (216.191.252.22) by server-2.tower-165.messagelabs.com with AES128-SHA encrypted SMTP; 10 Aug 2011 20:24:30 -0000 Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 10 Aug 2011 16:24:09 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 10 Aug 2011 16:24:27 -0400 From: Santosh Chokhani To: "David A. Cooper" , "mrex@sap.com" Date: Wed, 10 Aug 2011 16:24:24 -0400 Thread-Topic: [pkix] Certification path Thread-Index: AcxXmye5nkLQSIIVSdeI+cjqAkumPgAAESMw Message-ID: References: <201108101946.p7AJkCmp022191@fs4113.wdf.sap.corp> <4E42E852.1020305@nist.gov> In-Reply-To: <4E42E852.1020305@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 20:24:34 -0000 Dave, Do you mean self-issued? Why would you encounter or use a self-signed cert= ificate in a path? -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Dav= id A. Cooper Sent: Wednesday, August 10, 2011 4:22 PM To: mrex@sap.com Cc: pkix@ietf.org Subject: Re: [pkix] Certification path Martin, Are you saying that you believe that the path validation algorithm in=20 Section 6 needs to include a statement similar to the one that appears=20 in X.509: X.509, Clause 10.5.1: The following checks are applied to a=20 certificate. Self-signed certificates, if encountered in the path,=20 are ignored. X.509, Clause 10.5.2: For an intermediate certificate, the following constraint recording actions are then performed, in order correctly to set up the state variables for the=20 processing of the next certificate. Self-signed certificates, if=20 encountered in the path, are ignored. The closest text that seems to appear in RFC 5280 is: When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. The main difference is really just that RFC 5280 doesn't seem to=20 consider the possibility that a self-signed certificate might be=20 encountered in the middle of a certification path. Otherwise, RFC 5280=20 obtains the same result as X.509 by imposing a pre-processing=20 requirement to ensure that the first certificate in the prospective=20 certification path isn't a self-signed certificate. Is there anything=20 wrong with that? Is it really any different than: A certificate MUST NOT appear more than once in a prospective certification path. On 08/10/2011 03:46 PM, Martin Rex wrote: > Stephen Kent wrote: >>> ... >>> It is harmful to recommend distribution of TrustAnchor information that >>> is less-than-X.509. And it was entirely unnecessary. >>> >>> -Martin >> IF RPs were required to make use of the various fields& extensions in a >> self-signed cert as constraints in path validation, your assertion might >> be appropriate. But, the base X.509 and PKIX standards do not mandate th= at. >> (RFC 5914 addresses this issue and provides a basis for use of such >> data.) Moreover, implementations are quite varied in their support for >> making use of these values (in path validation). Thus there is no >> solid basis for arguing that a self-signed cert is the MUST be >> supported TA format. > > That description is confusing things considerably. > > As I just wrote in a previous Email, rfc5280 Section 6.1 describes an > (evendentally incomplete/flawed) algorithm to process a prospective > certification path, and while the processing of policies and constraints > special cases processing of self-issued certificates, the processing > of TA certs that might appear at the beginning of a prospective(!!) > certification path are obviously underspecified (in the document), > although implementations seem to cope with the situation quite well. > > Mandating that a trust anchor be distributed as X.509 plus X > (in a trust anchor distribution protocol) is entirely independent > from the processing of any potential TA cert appearing as the first > certificate of a prospective certification path. Just as it seemed > useful or necessary to specify skipping of self-issued certs under > certain conditions in policy and constraints processing, it should > be a no-brainer to exempt a TA cert at the beginning of a _prospective_ > certification path from processing. > > -Martin > _______________________________________________ > 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 david.cooper@nist.gov Wed Aug 10 13:38:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C6311E80AA for ; Wed, 10 Aug 2011 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjuWS+kRpwA4 for ; Wed, 10 Aug 2011 13:38:17 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id 493BA11E807F for ; Wed, 10 Aug 2011 13:38:17 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p7AKcehd022606; Wed, 10 Aug 2011 16:38:41 -0400 Message-ID: <4E42EC50.4080004@nist.gov> Date: Wed, 10 Aug 2011 16:38:40 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Mandriva/3.1.11-0.1mdv2010.2 (2010.2) Thunderbird/3.1.11 MIME-Version: 1.0 To: Santosh Chokhani References: <201108101946.p7AJkCmp022191@fs4113.wdf.sap.corp> <4E42E852.1020305@nist.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 20:38:18 -0000 On 08/10/2011 04:24 PM, Santosh Chokhani wrote: > Do you mean self-issued? No, I mean self-signed. The discussion was about TA certificates (which I take to mean self-signed certificates) appearing in a prospective certification path. > Why would you encounter or use a self-signed certificate in a path? You wouldn't use them, which is why X.509 says to ignore them if they are encountered in a prospective certification path. I don't know why you'd encounter a self-signed certificate in a path, but Martin's objection appears to be that RFC 5280 doesn't say what to do if a self-signed certificate appears at the beginning of a prospective certification path (it just says that self-signed certificates are not to appear at the beginning of a prospective certification path). > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of David A. Cooper > Sent: Wednesday, August 10, 2011 4:22 PM > To: mrex@sap.com > Cc: pkix@ietf.org > Subject: Re: [pkix] Certification path > > Martin, > > Are you saying that you believe that the path validation algorithm in > Section 6 needs to include a statement similar to the one that appears > in X.509: > > X.509, Clause 10.5.1: The following checks are applied to a > certificate. > Self-signed certificates, if encountered in the path, > are ignored. > > X.509, Clause 10.5.2: For an intermediate certificate, the following > constraint recording actions are then performed, in order > correctly to set up the state variables for the > processing of the > next certificate. Self-signed certificates, if > encountered in the > path, are ignored. > > The closest text that seems to appear in RFC 5280 is: > > When the trust anchor is provided in the form of a self-signed > certificate, this self-signed certificate is not included as part of > the prospective certification path. > > The main difference is really just that RFC 5280 doesn't seem to > consider the possibility that a self-signed certificate might be > encountered in the middle of a certification path. Otherwise, RFC 5280 > obtains the same result as X.509 by imposing a pre-processing > requirement to ensure that the first certificate in the prospective > certification path isn't a self-signed certificate. Is there anything > wrong with that? Is it really any different than: > > A certificate MUST NOT appear more than once in a prospective > certification path. > > On 08/10/2011 03:46 PM, Martin Rex wrote: >> Stephen Kent wrote: >>>> ... >>>> It is harmful to recommend distribution of TrustAnchor information that >>>> is less-than-X.509. And it was entirely unnecessary. >>>> >>>> -Martin >>> IF RPs were required to make use of the various fields& extensions in a >>> self-signed cert as constraints in path validation, your assertion might >>> be appropriate. But, the base X.509 and PKIX standards do not mandate that. >>> (RFC 5914 addresses this issue and provides a basis for use of such >>> data.) Moreover, implementations are quite varied in their support for >>> making use of these values (in path validation). Thus there is no >>> solid basis for arguing that a self-signed cert is the MUST be >>> supported TA format. >> That description is confusing things considerably. >> >> As I just wrote in a previous Email, rfc5280 Section 6.1 describes an >> (evendentally incomplete/flawed) algorithm to process a prospective >> certification path, and while the processing of policies and constraints >> special cases processing of self-issued certificates, the processing >> of TA certs that might appear at the beginning of a prospective(!!) >> certification path are obviously underspecified (in the document), >> although implementations seem to cope with the situation quite well. >> >> Mandating that a trust anchor be distributed as X.509 plus X >> (in a trust anchor distribution protocol) is entirely independent >> from the processing of any potential TA cert appearing as the first >> certificate of a prospective certification path. Just as it seemed >> useful or necessary to specify skipping of self-issued certs under >> certain conditions in policy and constraints processing, it should >> be a no-brainer to exempt a TA cert at the beginning of a _prospective_ >> certification path from processing. >> >> -Martin >> _______________________________________________ >> 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 kent@bbn.com Wed Aug 10 13:45:13 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BF55E8004 for ; Wed, 10 Aug 2011 13:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.611 X-Spam-Level: X-Spam-Status: No, score=-106.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ms-OO3ZEnuM for ; Wed, 10 Aug 2011 13:45:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D77B25E8003 for ; Wed, 10 Aug 2011 13:45:12 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49225) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrFeq-000Arv-Tu for pkix@ietf.org; Wed, 10 Aug 2011 16:45:45 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 10 Aug 2011 15:55:40 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 20:45:13 -0000 Folks, On 7/25 I requested a show of interest for adopting two new WG items: - Enrollment over Secure Transport (EST) (which I misspelled as ETS) - extending CMC to accommodate scenarios in which a CA/AR generates the key pair for the subject The PKIX list had several messages in favor of EST, and no significant objections, so I declare EST to be a new WG item. I am still waiting for comments on the CMC topic. Steve From kent@bbn.com Wed Aug 10 13:45:16 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBA05E8005 for ; Wed, 10 Aug 2011 13:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.611 X-Spam-Level: X-Spam-Status: No, score=-106.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f+0c2Zz6CK6 for ; Wed, 10 Aug 2011 13:45:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3185E8009 for ; Wed, 10 Aug 2011 13:45:15 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49225) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrFet-000Arv-Mp for pkix@ietf.org; Wed, 10 Aug 2011 16:45:47 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 10 Aug 2011 16:02:48 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] more status X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 20:45:16 -0000 Folks, Enough time has passed since I asked for comments on the adequacy of Jim's CMC updates Security Consideratins section. Since there were no objections, and since the SC section was based on the prior RFC, I declare this doc to have completed WGLC. Steve From kent@bbn.com Wed Aug 10 13:52:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3892B5E800F for ; Wed, 10 Aug 2011 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.61 X-Spam-Level: X-Spam-Status: No, score=-106.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9EMsur5Zeee for ; Wed, 10 Aug 2011 13:52:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A540F5E8004 for ; Wed, 10 Aug 2011 13:52:36 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49227) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrFlz-000Ax3-0R; Wed, 10 Aug 2011 16:53:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201108101932.p7AJWJ56021400@fs4113.wdf.sap.corp> References: <201108101932.p7AJWJ56021400@fs4113.wdf.sap.corp> Date: Wed, 10 Aug 2011 16:53:04 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Certification pathx X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 20:52:37 -0000 At 9:32 PM +0200 8/10/11, Martin Rex wrote: >Stephen Kent wrote: >> >> At 9:45 AM +0200 8/10/11, Erik Andersen wrote: >> >Hi Martin, >> > >> >As to your question about self-signed certificate. I do not see that >> >restriction in X.509. >> >> no, but a cert path is processed relative to the cert path validation alg, >> and that alg starts at a TA. > >The description of the path validation algorithm is significantly >and needlessly convoluted in that area, that it ought to be fixed >anyway. Thanks for your suggestion. >While rfc5280 Section 6.1 says that the path validation starts >with a prospective(!!) certification path, and policy and constraints >processing does not seem to have a problem specifying to skip >self-issued certs on the _prospective_ path, the algorithm as >described in rfc5280 Section 6.1 fails to provide a sensible guidance >how to deal with a TA cert appearing at the beginning of a prospective >certification path. because a TA (which need not be represented by a cert!) does not appear in the path. That's intentional. >But this flaw _only_ affects the description of the algorithm in rfc5280, >implementations of this algorithm, such as TLS clients, seem to cope with >that situation sensibly do not exhibit a problem. Many TLS clients do a lot of things that do not comply with 5280 :-), so it's odd to use the phrase "... implementations of this algorithm, such as TLS clients ..." >The words "this self-signed certificate is not included as part of >the prospective certification path" is not only non-sensical, but >also self-contradictory for an algorithm(!!) that is supposed to >describe processing of a prospective(!!!) certification path. The alg is intended to describe how to validate a sequence of certs that is initialized with data from a TA, i.e, cert #1 is issued under a TA. So there is nothing nonsensical about the wording. Steve From kent@bbn.com Wed Aug 10 13:52:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B227E5E800F for ; Wed, 10 Aug 2011 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.61 X-Spam-Level: X-Spam-Status: No, score=-106.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb6paNTjdX9c for ; Wed, 10 Aug 2011 13:52:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 43D405E8004 for ; Wed, 10 Aug 2011 13:52:37 -0700 (PDT) Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49227) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QrFm0-000Ax3-NO; Wed, 10 Aug 2011 16:53:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201108101946.p7AJkCmp022191@fs4113.wdf.sap.corp> References: <201108101946.p7AJkCmp022191@fs4113.wdf.sap.corp> Date: Wed, 10 Aug 2011 16:51:51 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 20:52:37 -0000 At 9:46 PM +0200 8/10/11, Martin Rex wrote: >Stephen Kent wrote: >> >> >... >> >It is harmful to recommend distribution of TrustAnchor information that >> >is less-than-X.509. And it was entirely unnecessary. >> > >> >-Martin >> >> IF RPs were required to make use of the various fields & extensions in a >> self-signed cert as constraints in path validation, your assertion might >> be appropriate. But, the base X.509 and PKIX standards do not mandate that. >> (RFC 5914 addresses this issue and provides a basis for use of such >> data.) Moreover, implementations are quite varied in their support for >> making use of these values (in path validation). Thus there is no >> solid basis for arguing that a self-signed cert is the MUST be >> supported TA format. > > >That description is confusing things considerably. > >As I just wrote in a previous Email, rfc5280 Section 6.1 describes an >(evendentally incomplete/flawed) algorithm to process a prospective >certification path, and while the processing of policies and constraints >special cases processing of self-issued certificates, the processing >of TA certs that might appear at the beginning of a prospective(!!) >certification path are obviously underspecified (in the document), >although implementations seem to cope with the situation quite well. the alg is not flawed, but your understanding may be :-). TAs are not part of a cert path; they are initialization data for path processing. Steve From mrex@sap.com Wed Aug 10 14:56:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7397321F8B58 for ; Wed, 10 Aug 2011 14:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.696 X-Spam-Level: X-Spam-Status: No, score=-9.696 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqYHGQfFQ4JG for ; Wed, 10 Aug 2011 14:56:13 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 929D721F8B57 for ; Wed, 10 Aug 2011 14:56:13 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p7ALuKdG007757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2011 23:56:21 +0200 (MEST) From: Martin Rex Message-Id: <201108102156.p7ALuKBt029557@fs4113.wdf.sap.corp> To: david.cooper@nist.gov (David A. Cooper) Date: Wed, 10 Aug 2011 23:56:20 +0200 (MEST) In-Reply-To: <4E42EC50.4080004@nist.gov> from "David A. Cooper" at Aug 10, 11 04:38:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:56:14 -0000 David A. Cooper wrote: > > On 08/10/2011 04:24 PM, Santosh Chokhani wrote: > > Do you mean self-issued? > > No, I mean self-signed. The discussion was about TA certificates (which > I take to mean self-signed certificates) appearing in a prospective > certification path. > > > Why would you encounter or use a self-signed certificate in a path? > > You wouldn't use them, which is why X.509 says to ignore them if they > are encountered in a prospective certification path. I don't know why > you'd encounter a self-signed certificate in a path, but Martin's > objection appears to be that RFC 5280 doesn't say what to do if a > self-signed certificate appears at the beginning of a prospective > certification path (it just says that self-signed certificates are not > to appear at the beginning of a prospective certification path). (Maybe we're just differing in opinion whether dealing sensibly with TA certs appearing at the beginning of a pkiPath should be dealt with in "certificate path validation" or require a full-fledged "certificate path discovery" (what some TLS implementations seem to be doing). I'm neither happy with either X.509-2008, 10.5.1, first sentence The following checks are applied to a certificate. Self-signed certificates, if encountered in the path, are ignored nor with rfc5280 Section 6.1 When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors is provided as inputs to the certification path validation algorithm (Section 6.1.1). While X.509-2008 is still specifying an algorithm, rfc5280 is thoroughly lame. What both specs should do is deal sensibly with the situation that a pkiPath (prospective certification path) may have a TA cert at the beginning, and how to cope sensibly with that situation. First of all, I fully agree that a certificate from the prospective certification path is _not_ a "trust anchor" for the purpose of performing the certificate path validation. It may, however, match the trust anchor that is used for the certificate path validation -- and should it match, it should be *ignored*. IMHO, the guidance in X.509-2008 10.5.1 to unconditionally ignore all self-signed certificates _anywhere_ in the prospective certification path is overly broad and misses the point (about ignoring a possible TA cert at the beginning of the pkiPath). rfc5280 is flawed, because it does not specify an algorithm to deal with such a cert, and it makes the non-algorithem implementations specific on top, because it applies only when the TrustAnchor (and that refers to the seperate TrustAnchor input) is provided as a self-signed certificate -- and the way it is worded, this does _not_ apply when the implementation passes the TrustAnchor as ToBeSigned or as TrustAnchorInfo to the certificate path validation algorithm -- which is why I believe this is lame. Look at the real world. These days, most commercial CAs have switched to distributing TrustAnchors with 2048-bit RSA keys. But when customers obtain TLS server certificates as cert chains (PKCS#7), they might receive a "chain" that instead of the 2048-bit RSA self-signed TA cert contains instead an intermediate cert containing the trustanchors Subject and public key, but issued&signed by an old 1024-bit RSA trust anchor. Now if you get that in a pkiPath as first cert, it is not a self-signed TA cert, but it is still a "TA cert", because Subject&Public Key usually matches the Trust Anchor from a new clients trust anchor store. And I'd really like to see the "certificate path validation" algorithm to be clarified rather than this question being declared out-of-scoped and relegated to the black arts of "certificate path construction". -Martin From peter.yee@rsa.com Wed Aug 10 14:42:25 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBB511E80AA for ; Wed, 10 Aug 2011 14:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPe0nzDjG7bD for ; Wed, 10 Aug 2011 14:42:25 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 641A311E8094 for ; Wed, 10 Aug 2011 14:42:23 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7ALgnHa009561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2011 17:42:49 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 10 Aug 2011 17:42:38 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7ALgao4031208; Wed, 10 Aug 2011 17:42:36 -0400 Received: from mx22a.corp.emc.com ([169.254.1.53]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Wed, 10 Aug 2011 17:42:36 -0400 From: To: , Date: Wed, 10 Aug 2011 17:42:04 -0400 Thread-Topic: [pkix] status update Thread-Index: AcxXnovBwZ1hgHFgTpyuBMn9F8k4EgABu9NA Message-ID: <13AF887ED681B04293B688A6D79E8256EA8AC5C6@MX22A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 10 Aug 2011 15:04:29 -0700 Subject: Re: [pkix] status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:51:02 -0000 I'm in favor of pursuing CMC extensions for accommodating authority- generated key pairs. I've already worked customer scenarios where such extensions would have been useful. -Peter Yee >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Stephen Kent >Sent: Wednesday, August 10, 2011 12:56 PM >To: pkix@ietf.org >Subject: [pkix] status update > >Folks, > >On 7/25 I requested a show of interest for adopting two new WG items: > - Enrollment over Secure Transport (EST) (which I misspelled as ETS) > > - extending CMC to accommodate scenarios in which a CA/AR >generates the key pair for the subject > > >The PKIX list had several messages in favor of EST, and no >significant objections, so I declare EST to be a new WG item. > >I am still waiting for comments on the CMC topic. > > >Steve > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Thu Aug 11 00:02:40 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B2E21F865F for ; Thu, 11 Aug 2011 00:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hqUO6h4UUoq for ; Thu, 11 Aug 2011 00:02:40 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 07B5F21F85F1 for ; Thu, 11 Aug 2011 00:02:39 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F00A95BC0; Thu, 11 Aug 2011 09:03:08 +0200 Message-ID: <4E437E9D.8000504@telia.com> Date: Thu, 11 Aug 2011 09:02:53 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 07:02:40 -0000 "EST is a certificate enrollment protocol that operates over HTTPS, and thus should be trivially accessible by modern clients" This is essentially the rationale in the current I-D (02). "Modern clients" presumably (?) does not include the most popular client of all, the Internet browser. It seems that the most appropriate description of EST is "A SCEP upgrade and RFC effort". That's fine with me. If the implicit ambition is something else, I would be somewhat cautious. Anders On 2011-08-10 21:55, Stephen Kent wrote: > Folks, > > On 7/25 I requested a show of interest for adopting two new WG items: > - Enrollment over Secure Transport (EST) (which I misspelled as ETS) > > - extending CMC to accommodate scenarios in which a CA/AR > generates the key pair for the subject > > > The PKIX list had several messages in favor of EST, and no > significant objections, so I declare EST to be a new WG item. > > I am still waiting for comments on the CMC topic. > > > Steve > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From internet-drafts@ietf.org Thu Aug 11 07:53:31 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4553C21F87FA; Thu, 11 Aug 2011 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt218cPaH6CE; Thu, 11 Aug 2011 07:53:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D370D21F86D8; Thu, 11 Aug 2011 07:53:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811145330.16751.40936.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 07:53:30 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 14:53:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Clarifications to the Internet X.509 Public Key Infrastr= ucture Certificate and Certificate Revocation List (CRL) Profile Author(s) : David Cooper Filename : draft-ietf-pkix-rfc5280-clarifications-03.txt Pages : 5 Date : 2011-08-11 This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc5280-clarifications-= 03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc5280-clarifications-0= 3.txt From mrex@sap.com Thu Aug 11 08:36:53 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812A321F8B0D; Thu, 11 Aug 2011 08:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcVUwQA3MptQ; Thu, 11 Aug 2011 08:36:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C226421F8B0C; Thu, 11 Aug 2011 08:36:52 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7BFbKIg000871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2011 17:37:25 +0200 (MEST) From: Martin Rex Message-Id: <201108111537.p7BFbKR5029556@fs4113.wdf.sap.corp> To: internet-drafts@ietf.org Date: Thu, 11 Aug 2011 17:37:20 +0200 (MEST) In-Reply-To: <20110811145330.16751.40936.idtracker@ietfa.amsl.com> from "internet-drafts@ietf.org" at Aug 11, 11 07:53:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, i-d-announce@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:36:53 -0000 internet-drafts@ietf.org wrote: > > Title : Clarifications to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Author(s) : David Cooper > Filename : draft-ietf-pkix-rfc5280-clarifications-03.txt > Pages : 5 > Date : 2011-08-11 > > This document updates RFC 5280, the Internet X.509 Public Key > Infrastructure Certificate and Certificate Revocation List (CRL) > Profile. This document changes the set of acceptable encoding > methods for the explicitText field of the user notice policy > qualifier and clarifies the rules for converting internationalized > domain name labels to ASCII. With respect to section 2 2. Update to RFC 5280, Section 4.2.1.4: Certificate Policies I don't like this: The explicitText string SHOULD NOT include any control characters (e.g., U+0000 to U+001F and U+007F to U+009F). and would strongly prefer if it said Implementations SHOULD reject certificates that include the control character U+0000 in the explicitText string, and implementations MAY reject certificates that include control characters from the range U+0001 to U+001F) in the explicitText string independent of the attribute encoding that is used. If you believe that any control characters from the range U+0000 to U+001f should be tolerated, please provide a convincing rationale for each character individually. -Martin From mrex@sap.com Thu Aug 11 08:41:10 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542A221F8B0D for ; Thu, 11 Aug 2011 08:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.002 X-Spam-Level: X-Spam-Status: No, score=-10.002 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIuHE6gMLrbn for ; Thu, 11 Aug 2011 08:41:09 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7D91521F85C6 for ; Thu, 11 Aug 2011 08:41:09 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7BFfh15001499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 11 Aug 2011 17:41:43 +0200 (MEST) From: Martin Rex Message-Id: <201108111541.p7BFfhOF029787@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 11 Aug 2011 17:41:43 +0200 (MEST) In-Reply-To: <201108111537.p7BFbKR5029556@fs4113.wdf.sap.corp> from "Martin Rex" at Aug 11, 11 05:37:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:41:10 -0000 Sorry, I goofed the recipients on my reply. (Please be careful before replying to my last Email) Martin Rex wrote: > > internet-drafts@ietf.org wrote: > > > > Title : Clarifications to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > > Author(s) : David Cooper > > Filename : draft-ietf-pkix-rfc5280-clarifications-03.txt > > Pages : 5 > > Date : 2011-08-11 > > > > This document updates RFC 5280, the Internet X.509 Public Key > > Infrastructure Certificate and Certificate Revocation List (CRL) > > Profile. This document changes the set of acceptable encoding > > methods for the explicitText field of the user notice policy > > qualifier and clarifies the rules for converting internationalized > > domain name labels to ASCII. > > With respect to section 2 > 2. Update to RFC 5280, Section 4.2.1.4: Certificate Policies > > I don't like this: > > The explicitText string SHOULD NOT include any control > characters (e.g., U+0000 to U+001F and U+007F to U+009F). > > and would strongly prefer if it said > > Implementations SHOULD reject certificates that include the > control character U+0000 in the explicitText string, and > implementations MAY reject certificates that include control > characters from the range U+0001 to U+001F) in the explicitText > string independent of the attribute encoding that is used. > > If you believe that any control characters from the range > U+0000 to U+001f should be tolerated, please provide a convincing > rationale for each character individually. > > -Martin From housley@vigilsec.com Thu Aug 11 09:16:01 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E5A21F8C29 for ; Thu, 11 Aug 2011 09:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKZFKeecd92r for ; Thu, 11 Aug 2011 09:16:00 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id B073321F8B65 for ; Thu, 11 Aug 2011 09:16:00 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 919B7F24199; Thu, 11 Aug 2011 12:16:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ZbRII9WmQ3QC; Thu, 11 Aug 2011 12:16:34 -0400 (EDT) Received: from [192.168.2.101] (pool-96-241-176-45.washdc.fios.verizon.net [96.241.176.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2C7F0F2408F; Thu, 11 Aug 2011 12:16:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <201108111537.p7BFbKR5029556@fs4113.wdf.sap.corp> Date: Thu, 11 Aug 2011 12:16:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14FB44D8-FDB3-4FB7-AE87-8BCF6AFAA3B8@vigilsec.com> References: <201108111537.p7BFbKR5029556@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:16:01 -0000 Martin: >> Title : Clarifications to the Internet X.509 Public = Key Infrastructure Certificate and Certificate Revocation List (CRL) = Profile >> Author(s) : David Cooper >> Filename : draft-ietf-pkix-rfc5280-clarifications-03.txt >>=20 > With respect to section 2=20 > 2. Update to RFC 5280, Section 4.2.1.4: Certificate Policies >=20 > I don't like this: >=20 > The explicitText string SHOULD NOT include any control > characters (e.g., U+0000 to U+001F and U+007F to U+009F). >=20 > and would strongly prefer if it said >=20 > Implementations SHOULD reject certificates that include the > control character U+0000 in the explicitText string, and > implementations MAY reject certificates that include control > characters from the range U+0001 to U+001F) in the explicitText > string independent of the attribute encoding that is used. >=20 > If you believe that any control characters from the range > U+0000 to U+001f should be tolerated, please provide a convincing > rationale for each character individually. We want CAs to refuse to issue certificates with these characters. I do not think we should require relying parties to scan the text field = for the presence of these control characters as a step in certificate = validation. Russ From mrex@sap.com Thu Aug 11 09:49:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7854B21F8C83 for ; Thu, 11 Aug 2011 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.006 X-Spam-Level: X-Spam-Status: No, score=-10.006 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn8XFKJ3jMrE for ; Thu, 11 Aug 2011 09:49:47 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A794321F8C82 for ; Thu, 11 Aug 2011 09:49:46 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7BGoJvq011973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2011 18:50:19 +0200 (MEST) From: Martin Rex Message-Id: <201108111650.p7BGoIku003615@fs4113.wdf.sap.corp> To: housley@vigilsec.com (Russ Housley) Date: Thu, 11 Aug 2011 18:50:18 +0200 (MEST) In-Reply-To: <14FB44D8-FDB3-4FB7-AE87-8BCF6AFAA3B8@vigilsec.com> from "Russ Housley" at Aug 11, 11 12:16:33 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:49:47 -0000 Russ Housley wrote: > > >> Title : Clarifications to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > >> Author(s) : David Cooper > >> Filename : draft-ietf-pkix-rfc5280-clarifications-03.txt > >> > > With respect to section 2 > > 2. Update to RFC 5280, Section 4.2.1.4: Certificate Policies > > > > I don't like this: > > > > The explicitText string SHOULD NOT include any control > > characters (e.g., U+0000 to U+001F and U+007F to U+009F). > > > > and would strongly prefer if it said > > > > Implementations SHOULD reject certificates that include the > > control character U+0000 in the explicitText string, and > > implementations MAY reject certificates that include control > > characters from the range U+0001 to U+001F) in the explicitText > > string independent of the attribute encoding that is used. > > > > If you believe that any control characters from the range > > U+0000 to U+001f should be tolerated, please provide a convincing > > rationale for each character individually. > > We want CAs to refuse to issue certificates with these characters. > > I do not think we should require relying parties to scan the text > field for the presence of these control characters as a step in > certificate validation. I did _not_ write a "required" = MUST / SHALL. This was a SHOULD reject for U+0000 and a MAY reject for U+0001-U+001f. For some encodings (e.g. VisibleString) this restriction ought to be a side effect automatically enforced by a sensible ASN.1 decoder. But I would appreciate some pressure on CAs to discontinue doing such nonsense and face interop problems in the long run if they ignore it. U+0000 is well-known to cause all sorts of problems for textual information. U+0000 caused real security problems when used in cert subject DNames in TLS clients doing server endpoint identification according to rfc2818. -Martin From housley@vigilsec.com Thu Aug 11 09:53:54 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EE621F8BBD for ; Thu, 11 Aug 2011 09:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp0JwSYd6UJZ for ; Thu, 11 Aug 2011 09:53:53 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id BCECD21F8B0A for ; Thu, 11 Aug 2011 09:53:53 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B532CF240BF; Thu, 11 Aug 2011 12:54:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id XGq8FK+jdUoN; Thu, 11 Aug 2011 12:54:09 -0400 (EDT) Received: from [192.168.2.101] (pool-96-241-176-45.washdc.fios.verizon.net [96.241.176.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3E8E3F2403B; Thu, 11 Aug 2011 12:54:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <201108111650.p7BGoIku003615@fs4113.wdf.sap.corp> Date: Thu, 11 Aug 2011 12:54:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D574EC1-C92D-4E57-A607-D3E808854F1E@vigilsec.com> References: <201108111650.p7BGoIku003615@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:53:54 -0000 Martin: >>>> Title : Clarifications to the Internet X.509 Public = Key Infrastructure Certificate and Certificate Revocation List (CRL) = Profile >>>> Author(s) : David Cooper >>>> Filename : draft-ietf-pkix-rfc5280-clarifications-03.txt >>>>=20 >>> With respect to section 2=20 >>> 2. Update to RFC 5280, Section 4.2.1.4: Certificate Policies >>>=20 >>> I don't like this: >>>=20 >>> The explicitText string SHOULD NOT include any control >>> characters (e.g., U+0000 to U+001F and U+007F to U+009F). >>>=20 >>> and would strongly prefer if it said >>>=20 >>> Implementations SHOULD reject certificates that include the >>> control character U+0000 in the explicitText string, and >>> implementations MAY reject certificates that include control >>> characters from the range U+0001 to U+001F) in the explicitText >>> string independent of the attribute encoding that is used. >>>=20 >>> If you believe that any control characters from the range >>> U+0000 to U+001f should be tolerated, please provide a convincing >>> rationale for each character individually. >>=20 >> We want CAs to refuse to issue certificates with these characters. >>=20 >> I do not think we should require relying parties to scan the text >> field for the presence of these control characters as a step in >> certificate validation. >=20 > I did _not_ write a "required" =3D MUST / SHALL. > This was a SHOULD reject for U+0000 and a MAY reject for = U+0001-U+001f. >=20 > For some encodings (e.g. VisibleString) this restriction ought to be > a side effect automatically enforced by a sensible ASN.1 decoder. >=20 > But I would appreciate some pressure on CAs to discontinue doing > such nonsense and face interop problems in the long run if they > ignore it. U+0000 is well-known to cause all sorts of problems > for textual information. U+0000 caused real security problems > when used in cert subject DNames in TLS clients doing server=20 > endpoint identification according to rfc2818. My point is that you are shifting the actor from the AC to the relying = party. Russ From mrex@sap.com Thu Aug 11 10:01:39 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA4E21F8B63 for ; Thu, 11 Aug 2011 10:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.008 X-Spam-Level: X-Spam-Status: No, score=-10.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k0NNUsatH8x for ; Thu, 11 Aug 2011 10:01:39 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B148821F8B5F for ; Thu, 11 Aug 2011 10:01:38 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p7BH2Bjk023095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2011 19:02:11 +0200 (MEST) From: Martin Rex Message-Id: <201108111702.p7BH2Bjp004411@fs4113.wdf.sap.corp> To: housley@vigilsec.com (Russ Housley) Date: Thu, 11 Aug 2011 19:02:11 +0200 (MEST) In-Reply-To: <5D574EC1-C92D-4E57-A607-D3E808854F1E@vigilsec.com> from "Russ Housley" at Aug 11, 11 12:54:26 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:01:39 -0000 Russ Housley wrote: > > Martin: > > >>>> Title : Clarifications to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > >>>> Author(s) : David Cooper > >>>> Filename : draft-ietf-pkix-rfc5280-clarifications-03.txt > >>>> > >>> With respect to section 2 > >>> 2. Update to RFC 5280, Section 4.2.1.4: Certificate Policies > >>> > >>> I don't like this: > >>> > >>> The explicitText string SHOULD NOT include any control > >>> characters (e.g., U+0000 to U+001F and U+007F to U+009F). > >>> > >>> and would strongly prefer if it said > >>> > >>> Implementations SHOULD reject certificates that include the > >>> control character U+0000 in the explicitText string, and > >>> implementations MAY reject certificates that include control > >>> characters from the range U+0001 to U+001F) in the explicitText > >>> string independent of the attribute encoding that is used. > >>> > >>> If you believe that any control characters from the range > >>> U+0000 to U+001f should be tolerated, please provide a convincing > >>> rationale for each character individually. > >> > >> We want CAs to refuse to issue certificates with these characters. > >> > >> I do not think we should require relying parties to scan the text > >> field for the presence of these control characters as a step in > >> certificate validation. > > > > I did _not_ write a "required" = MUST / SHALL. > > This was a SHOULD reject for U+0000 and a MAY reject for U+0001-U+001f. > > > > For some encodings (e.g. VisibleString) this restriction ought to be > > a side effect automatically enforced by a sensible ASN.1 decoder. > > > > But I would appreciate some pressure on CAs to discontinue doing > > such nonsense and face interop problems in the long run if they > > ignore it. U+0000 is well-known to cause all sorts of problems > > for textual information. U+0000 caused real security problems > > when used in cert subject DNames in TLS clients doing server > > endpoint identification according to rfc2818. > > My point is that you are shifting the actor from the AC to the relying party. No, quite the contrary. The current proposal does _not_ allow the relying party to reject such a cert, which is really bad. If it was changed to "an implementation MAY reject", then the responsibility&blame for failures would be completely transferred to the CA instead. -Martin From hotz@jpl.nasa.gov Thu Aug 11 10:24:56 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0914421F8C68 for ; Thu, 11 Aug 2011 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEvw3QRz0ue2 for ; Thu, 11 Aug 2011 10:24:55 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9165A21F8C63 for ; Thu, 11 Aug 2011 10:24:55 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7BHPPoj006774 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 11 Aug 2011 10:25:26 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <201108102156.p7ALuKBt029557@fs4113.wdf.sap.corp> Date: Thu, 11 Aug 2011 10:25:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108102156.p7ALuKBt029557@fs4113.wdf.sap.corp> To: "mrex@sap.com" X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" Subject: Re: [pkix] Certification path X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:24:56 -0000 On Aug 10, 2011, at 2:56 PM, Martin Rex wrote: > And I'd really like to see the "certificate path validation" algorithm > to be clarified rather than this question being declared out-of-scoped > and relegated to the black arts of "certificate path construction". +1 I'm not getting the impression that the pragmatically desired behavior = is in question, but the quoted specifications don't seem to describe it. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From internet-drafts@ietf.org Thu Aug 11 16:19:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E032711E808D; Thu, 11 Aug 2011 16:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm+2w7EvaR1H; Thu, 11 Aug 2011 16:19:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477BD21F8AF3; Thu, 11 Aug 2011 16:19:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811231930.23713.74647.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 16:19:30 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5272-bis-05.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 23:19:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Certificate Management over CMS (CMC) Updates Author(s) : Jim Schaad Filename : draft-ietf-pkix-rfc5272-bis-05.txt Pages : 39 Date : 2011-08-11 This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273 and RFC 5274. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc5272-bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc5272-bis-05.txt From kent@bbn.com Thu Aug 11 17:30:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3278611E80AD for ; Thu, 11 Aug 2011 17:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.04 X-Spam-Level: X-Spam-Status: No, score=-106.04 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67j3NG-+M2dR for ; Thu, 11 Aug 2011 17:30:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B3A6A11E8098 for ; Thu, 11 Aug 2011 17:30:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55863 helo=[172.28.177.105]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qrfek-000Fdo-Ak; Thu, 11 Aug 2011 20:31:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E437E9D.8000504@telia.com> References: <4E437E9D.8000504@telia.com> Date: Thu, 11 Aug 2011 12:45:44 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 00:30:48 -0000 At 9:02 AM +0200 8/11/11, Anders Rundgren wrote: > "EST is a certificate enrollment protocol that operates > over HTTPS, and thus should be trivially accessible by > modern clients" > >This is essentially the rationale in the current I-D (02). > >"Modern clients" presumably (?) does not include the >most popular client of all, the Internet browser. > >It seems that the most appropriate description of EST is >"A SCEP upgrade and RFC effort". That's fine with me. >If the implicit ambition is something else, I would be >somewhat cautious. > >Anders Max has characterized EST as a simple cert enrollment protocol, a successor to SCEP, suitable for use with simple clients. I'm comfortable with that. The fact that EST is not tailored to browsers is not an issue. Steve From mrex@sap.com Thu Aug 11 17:43:04 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE3311E80B1 for ; Thu, 11 Aug 2011 17:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.01 X-Spam-Level: X-Spam-Status: No, score=-10.01 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30aOSYOsILIp for ; Thu, 11 Aug 2011 17:43:04 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 14AEF11E8089 for ; Thu, 11 Aug 2011 17:43:03 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p7C0hPpI019346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Aug 2011 02:43:25 +0200 (MEST) From: Martin Rex Message-Id: <201108120043.p7C0hO34001596@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Fri, 12 Aug 2011 02:43:24 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Aug 10, 11 03:55:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 00:43:05 -0000 Stephen Kent wrote: > > - extending CMC to accommodate scenarios in which a CA/AR > generates the key pair for the subject There seem to be various scenarios in productive use where the the keypair is created centrally and the entire credentials distributed. Company-internal, we originally used PKCS#12 and now use Active Directory. In electronic data exchange in Germany, there is a standard for taxes (Elster) and for social security data, and the credentials are also centrally created by the CA and distributed as PKCS#12 (one PKCS#12 with two keypairs, one for signing the other for encryption). Something similar is done in other countries as well (I usually only learn about such scenarios when the existing functionality is insufficient to implement the customer or legal requirement and I have to add new features at the lower-level abstract APIs for pkcs7/cms and WSSec.) Who is acutally doing this with CMS (or wants to do this with CMS)? -Martin From anders.rundgren@telia.com Thu Aug 11 22:09:21 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1BF21F86BA for ; Thu, 11 Aug 2011 22:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVbWyLcLp5iJ for ; Thu, 11 Aug 2011 22:09:21 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id AF16521F862F for ; Thu, 11 Aug 2011 22:09:20 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B01289BB4; Fri, 12 Aug 2011 07:08:32 +0200 Message-ID: <4E44B53F.1010102@telia.com> Date: Fri, 12 Aug 2011 07:08:15 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: max pritikin References: <4E437E9D.8000504@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 05:09:21 -0000 On 2011-08-11 18:45, Stephen Kent wrote: > At 9:02 AM +0200 8/11/11, Anders Rundgren wrote: >> "EST is a certificate enrollment protocol that operates >> over HTTPS, and thus should be trivially accessible by >> modern clients" >> >> This is essentially the rationale in the current I-D (02). >> >> "Modern clients" presumably (?) does not include the >> most popular client of all, the Internet browser. >> >> It seems that the most appropriate description of EST is >> "A SCEP upgrade and RFC effort". That's fine with me. >> If the implicit ambition is something else, I would be >> somewhat cautious. >> >> Anders > > Max has characterized EST as a simple cert enrollment protocol, > a successor to SCEP, suitable for use with simple clients. > I'm comfortable with that. The fact that EST is not tailored to > browsers is not an issue. Max, are you OK with mobile phones "iPads", and similar devices [soon] having embedded hardware keystores, being out of scope? HTML5's browser enrollment solution: http://www.w3.org/TR/html-markup/keygen.html Anders From wwwrun@rfc-editor.org Fri Aug 12 02:59:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0567221F8715 for ; Fri, 12 Aug 2011 02:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KckIfgQDrpZx for ; Fri, 12 Aug 2011 02:59:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A476D21F84DA for ; Fri, 12 Aug 2011 02:59:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 91CA698C225; Fri, 12 Aug 2011 03:00:22 -0700 (PDT) To: cadams@entrust.com, pcain@bbn.com, Denis.Pinkas@bull.net, robert.zuccherato@entrust.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20110812100022.91CA698C225@rfc-editor.org> Date: Fri, 12 Aug 2011 03:00:22 -0700 (PDT) X-Mailman-Approved-At: Fri, 12 Aug 2011 06:22:35 -0700 Cc: pkix@ietf.org, bdauvergne@entrouvert.com, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC3161 (2931) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 09:59:47 -0000 The following errata report has been submitted for RFC3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3161&eid=2931 -------------------------------------- Type: Technical Reported by: Benjamin Dauvergne Section: 2.4.2 Original Text ------------- PKIStatus ::= INTEGER { granted (0), -- when the PKIStatus contains the value zero a TimeStampToken, as requested, is present. grantedWithMods (1), -- when the PKIStatus contains the value one a TimeStampToken, with modifications, is present. rejection (2), waiting (3), revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5) -- notification that a revocation has occurred } Corrected Text -------------- PKIStatus ::= INTEGER { granted (0), -- when the PKIStatus contains the value zero a TimeStampToken, as -- requested, is present. grantedWithMods (1), -- when the PKIStatus contains the value one a TimeStampToken, -- with modifications, is present. rejection (2), waiting (3), revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5) -- notification that a revocation has occurred -- } Notes ----- In ASN.1 syntax 1988, all comment lines must be prefixed with double-hyphen, and comment lines followed by some content must be terminated with a double-hyphen. Instructions: ------------- This errata 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. -------------------------------------- RFC3161 (draft-ietf-pkix-time-stamp-15) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) Publication Date : August 2001 Author(s) : C. Adams, P. Cain, D. Pinkas, R. Zuccherato Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Aug 12 03:01:31 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E62421F8779 for ; Fri, 12 Aug 2011 03:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F46+9GPDeRU for ; Fri, 12 Aug 2011 03:01:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7121F84DA for ; Fri, 12 Aug 2011 03:01:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 58AF798C226; Fri, 12 Aug 2011 03:01:54 -0700 (PDT) To: cadams@entrust.com, pcain@bbn.com, Denis.Pinkas@bull.net, robert.zuccherato@entrust.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20110812100154.58AF798C226@rfc-editor.org> Date: Fri, 12 Aug 2011 03:01:54 -0700 (PDT) X-Mailman-Approved-At: Fri, 12 Aug 2011 06:22:35 -0700 Cc: pkix@ietf.org, bdauvergne@entrouvert.com, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC3161 (2932) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 10:01:31 -0000 The following errata report has been submitted for RFC3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3161&eid=2932 -------------------------------------- Type: Technical Reported by: Benjamin Dauvergne Section: 2.4.2 Original Text ------------- systemFailure (25) -- the request cannot be handled due to system failure } Corrected Text -------------- systemFailure (25) -- the request cannot be handled due to system failure -- } Notes ----- In ASN.1 syntax 1988, comment lines followed by content must be terminated by a double-hyphen. Instructions: ------------- This errata 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. -------------------------------------- RFC3161 (draft-ietf-pkix-time-stamp-15) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) Publication Date : August 2001 Author(s) : C. Adams, P. Cain, D. Pinkas, R. Zuccherato Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From kent@bbn.com Fri Aug 12 09:14:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE68621F8564 for ; Fri, 12 Aug 2011 09:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuVvJtEUk267 for ; Fri, 12 Aug 2011 09:14:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6442F21F852C for ; Fri, 12 Aug 2011 09:14:11 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55223 helo=[10.10.4.127]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QruNk-000P0J-8Q; Fri, 12 Aug 2011 12:14:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201108120043.p7C0hO34001596@fs4113.wdf.sap.corp> References: <201108120043.p7C0hO34001596@fs4113.wdf.sap.corp> Date: Fri, 12 Aug 2011 12:07:38 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 16:14:11 -0000 >... > >Who is acutally doing this with CMS (or wants to do this with CMS)? > > >-Martin I presume you are directing this question to the authors of the I-D. Steve From kent@bbn.com Fri Aug 12 09:14:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7470E21F873D for ; Fri, 12 Aug 2011 09:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIDgSHZwiTpB for ; Fri, 12 Aug 2011 09:14:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F35BC21F8736 for ; Fri, 12 Aug 2011 09:14:19 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55223 helo=[10.10.4.127]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QruNm-000P0J-Qo; Fri, 12 Aug 2011 12:14:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E44B53F.1010102@telia.com> References: <4E437E9D.8000504@telia.com> <4E44B53F.1010102@telia.com> Date: Fri, 12 Aug 2011 12:10:47 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 16:14:20 -0000 At 7:08 AM +0200 8/12/11, Anders Rundgren wrote: >... > >Max, are you OK with mobile phones "iPads", and similar devices >[soon] having embedded hardware keystores, being out of scope? I'd rather you not take what someone else (e.g., me) says, and apply your interpretation to it, in the fashion illustrated above. Steve From pritikin@cisco.com Fri Aug 12 10:03:49 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD2621F8661 for ; Fri, 12 Aug 2011 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A08pDhMLmUQn for ; Fri, 12 Aug 2011 10:03:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE4F21F8658 for ; Fri, 12 Aug 2011 10:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1857; q=dns/txt; s=iport; t=1313168666; x=1314378266; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DqAK0nheEz2yQOU1IcnR7u1IONIdMdhof9jzQHO1rG4=; b=jDHf1WlPrVRvQ30SUDU0yMOFzDMO9S6ogMRuLxAHicpr/Q9f/rrzZN+H ieuDDMfJGFH4R1YrEZOAQwEWRhtih0+JFg2o5rb4v4JJLqseKiVcQAzIQ WSilV0ONqgwUI9PGQGzcl7qGCamQa/2FvssrEV8whJe4wW/Fe1QMqDxLM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADlcRU6rRDoG/2dsb2JhbABBp3l3gUABAQEBAgEBAQEPASc0CwULCxguJzAGEyKHTQScPAGec4VoXwSHX4sxiXaHGg X-IronPort-AV: E=Sophos;i="4.67,363,1309737600"; d="scan'208";a="12654411" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-9.cisco.com with ESMTP; 12 Aug 2011 17:04:25 +0000 Received: from stealth-10-32-244-67.cisco.com (stealth-10-32-244-67.cisco.com [10.32.244.67]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7CH4Mka017805; Fri, 12 Aug 2011 17:04:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: Date: Fri, 12 Aug 2011 11:04:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> References: <4E437E9D.8000504@telia.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 17:03:49 -0000 On Aug 11, 2011, at 10:45 AM, Stephen Kent wrote: > At 9:02 AM +0200 8/11/11, Anders Rundgren wrote: >> "EST is a certificate enrollment protocol that operates >> over HTTPS, and thus should be trivially accessible by >> modern clients" >>=20 >> This is essentially the rationale in the current I-D (02). >>=20 >> "Modern clients" presumably (?) does not include the >> most popular client of all, the Internet browser. >>=20 >> It seems that the most appropriate description of EST is >> "A SCEP upgrade and RFC effort". That's fine with me. Importantly it is focussed on alignment/profile of CMC.=20 I am very aware of http://xkcd.com/927/ and would like to avoid such = proliferation.=20 >> If the implicit ambition is something else, I would be >> somewhat cautious. >>=20 >> Anders >=20 > Max has characterized EST as a simple cert enrollment protocol, > a successor to SCEP, suitable for use with simple clients. > I'm comfortable with that. The fact that EST is not tailored to > browsers is not an issue. also re: Anders Rudgren wrote: > Max, are you OK with mobile phones "iPads", and similar devices > [soon] having embedded hardware keystores, being out of scope? There is nothing within EST or CMC or SCEP or otherwise that would = _preclude_ a browser or a mobile device. The protocol components should = be easy to implement using the codebases available to such clients. I = have already implemented both SCEP and EST against a hardware keystore = so I don't perceive those as being 'out of scope' either. As a = simplification/profile of CMC it does not make sense to limit the focus = specifically to only those clients. - max >=20 > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Fri Aug 12 10:19:10 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791D621F8745 for ; Fri, 12 Aug 2011 10:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKZDoDFYZO66 for ; Fri, 12 Aug 2011 10:19:10 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id F2E2121F8663 for ; Fri, 12 Aug 2011 10:19:01 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B012C4DA9; Fri, 12 Aug 2011 19:19:32 +0200 Message-ID: <4E456093.6090609@telia.com> Date: Fri, 12 Aug 2011 19:19:15 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Max Pritikin References: <4E437E9D.8000504@telia.com> <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> In-Reply-To: <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 17:19:10 -0000 On 2011-08-12 19:04, Max Pritikin wrote: > also re: Anders Rudgren wrote: >> Max, are you OK with mobile phones "iPads", and similar devices >> [soon] having embedded hardware keystores, being out of scope? > > There is nothing within EST or CMC or SCEP or otherwise that > would _preclude_ a browser or a mobile device. That's what the KEYPROV guys said as well. However, they forgot a tiny detail: how to bind their protocol to a browser. Anders From wtc@google.com Fri Aug 12 11:11:19 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7AD21F86DC for ; Fri, 12 Aug 2011 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6O9z01EcdWi for ; Fri, 12 Aug 2011 11:11:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBED21F86B9 for ; Fri, 12 Aug 2011 11:11:17 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p7CIBrgB015921 for ; Fri, 12 Aug 2011 11:11:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313172713; bh=kj4eiyuUmPbM9A3TtuqKCHfB5Iw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Xmgdw/mX7MbM3SQT3D5g8hvZirwOp5zBDGCaslta2B7VaYrxwvwR+bZS3u9tolLd8 HJ7qCG7cn8fCE2sIOdrHw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=jP+J4eNUHGnT0ypvv+Xy/X0i3XAfcZNILsSsfBcKz/vDbB8C9zQLfhFi5gtGDEsVO fA3MRlpuBOkLHOhHGKkYw== Received: from iym1 (iym1.prod.google.com [10.241.52.1]) by hpaq14.eem.corp.google.com with ESMTP id p7CIA2uB018564 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 12 Aug 2011 11:11:51 -0700 Received: by iym1 with SMTP id 1so2068850iym.0 for ; Fri, 12 Aug 2011 11:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NN6Cv3baZKZjtWEaB+xXfISYSDzfJywWJ+1qcKhGUg4=; b=PnENOLSu0vqb0Uyx/klKNPg85ix0H3hMzfBWFCmN6+RNIaPRVo6e57sYS+/KNRjsZJ rYj9u03o9KPhQnNK5fpQ== Received: by 10.42.151.2 with SMTP id c2mr1283670icw.15.1313172711196; Fri, 12 Aug 2011 11:11:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.151.2 with SMTP id c2mr1283662icw.15.1313172711112; Fri, 12 Aug 2011 11:11:51 -0700 (PDT) Received: by 10.231.14.70 with HTTP; Fri, 12 Aug 2011 11:11:51 -0700 (PDT) In-Reply-To: <4E456093.6090609@telia.com> References: <4E437E9D.8000504@telia.com> <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> <4E456093.6090609@telia.com> Date: Fri, 12 Aug 2011 11:11:51 -0700 Message-ID: From: Wan-Teh Chang To: Max Pritikin , Anders Rundgren Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:11:19 -0000 On Fri, Aug 12, 2011 at 10:19 AM, Anders Rundgren wrote: > On 2011-08-12 19:04, Max Pritikin wrote: > >> There is nothing within EST or CMC or SCEP or otherwise that >> would _preclude_ a browser or a mobile device. > > That's what the KEYPROV guys said as well. =A0However, they forgot > a tiny detail: how to bind their protocol to a browser. I am interested in implementing a certificate enrollment protocol in Firefox and Google Chrome to replace . I am studying KeyGen2 and EST. I have a question about Anders' comment above. By "binding a certificate enrollment protocol to a browser", do you mean specifying an HTML element or JavaScript function for a server to kick off the key generation and certificate request generation in the browser? For importing a newly issued certificate into a browser, draft-pritikin-est= -02 specifies the MIME-type "application/x-est-x509" for the HTTP response carrying the new certificate, which is the moral equivalent of "application/x-x509-user-cert" used for . So it's not clear to me if any other "browser binding" is necessary for this operation. Perhaps a JavaScript function similar to Mozilla's crypto.importUserCertificates function? https://developer.mozilla.org/en/JavaScript_crypto/importUserCertificates The handling of an HTTP 202 response in Section 5.2.2 of draft-pritikin-est-02 does seem to be intended for an automated client (such as one running on an unattended network appliance) rather than a web browser. Wan-Teh Chang From anders.rundgren@telia.com Fri Aug 12 22:31:22 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CAC11E8083 for ; Fri, 12 Aug 2011 22:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvmy8BcXvp7r for ; Fri, 12 Aug 2011 22:31:21 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7501B11E807C for ; Fri, 12 Aug 2011 22:31:21 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E9700489E10; Sat, 13 Aug 2011 07:31:56 +0200 Message-ID: <4E460C3B.7040501@telia.com> Date: Sat, 13 Aug 2011 07:31:39 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Wan-Teh Chang References: <4E437E9D.8000504@telia.com> <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> <4E456093.6090609@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 05:31:22 -0000 On 2011-08-12 20:11, Wan-Teh Chang wrote: > On Fri, Aug 12, 2011 at 10:19 AM, Anders Rundgren > wrote: >> On 2011-08-12 19:04, Max Pritikin wrote: >> >>> There is nothing within EST or CMC or SCEP or otherwise that >>> would _preclude_ a browser or a mobile device. >> >> That's what the KEYPROV guys said as well. However, they forgot >> a tiny detail: how to bind their protocol to a browser. > > I am interested in implementing a certificate enrollment protocol in > Firefox and Google Chrome to replace . That's absolutely fantastic! If somebody manages creating and implementing an enrollment solution that is useful for everything from small enterprises to social media and on-line banking it would be no less than a REVOLUTION! > I am studying KeyGen2 and EST. That should be quite challenging since they address this space from entirely different "value propositions". PKIX's enrollment standards (all pf them) deal with certificate provisioning which is only a subset of token provisioning. The latter among many things includes PIN-code provisioning based on the *issuer's policy*. To make this realistic on a major scale KeyGen2 actually depends on a *specific token architecture and API* since current middleware like PKCS #11 does not address on-line token provisioning. Microsoft is trying to do similar things with their "MiniDriver". IMO, that's a very difficult approach. A short peek in http://www.opensc-project.org/pipermail/opensc-devel verifies my claim that *abstracting token APIs is a never-ending story*. It is much easier pushing a fixed API on the token vendors, at least if you're Google :-) One middleware driver/platform and a single JUnit test suite is the real boon of this (admittedly a bit unusual) idea. I doubt that http://www.nist.gov/nstic will ever get their baby of the ground unless token provisioning becomes as simple as password ditto. >I have a question about Anders' comment above. > > By "binding a certificate enrollment protocol to a browser", do you > mean specifying an HTML element or JavaScript function for a > server to kick off the key generation and certificate request > generation in the browser? Exactly. In KeyGen2 the kick off is the start of a 6-10 pass protocol running inside of the browser. > For importing a newly issued certificate into a browser, draft-pritikin-est-02 > specifies the MIME-type "application/x-est-x509" for the HTTP > response carrying the new certificate, which is the moral equivalent > of "application/x-x509-user-cert" used for . So it's not > clear to me if any other "browser binding" is necessary for this > operation. Perhaps a JavaScript function similar to Mozilla's > crypto.importUserCertificates function? > https://developer.mozilla.org/en/JavaScript_crypto/importUserCertificates For this function is (almost) redundant. In KeyGen2 the final phase holds certificates (and then some...) but it is also the end of an *end-to-end-secured transaction* that if successful returns a signed receipt to the issuer. > The handling of an HTTP 202 response in Section 5.2.2 of > draft-pritikin-est-02 does seem to be intended for an automated > client (such as one running on an unattended network > appliance) rather than a web browser. Indeed. A browser scheme would return a page saying something to the user in case of a server/issuer error. Anders From iesg-secretary@ietf.org Mon Aug 15 14:25:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A06A11E8115; Mon, 15 Aug 2011 14:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXy64a+jQLKa; Mon, 15 Aug 2011 14:25:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1221F8D3B; Mon, 15 Aug 2011 14:25:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110815212517.6957.34010.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 14:25:17 -0700 Cc: pkix@ietf.org Subject: [pkix] Last Call: (Certificate Management over CMS (CMC) Updates) to Proposed Standard X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:25:18 -0000 The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Certificate Management over CMS (CMC) Updates' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273 and RFC 5274. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5272-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5272-bis/ No IPR declarations have been submitted directly on this I-D. From pritikin@cisco.com Mon Aug 15 16:22:28 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9400D11E8091 for ; Mon, 15 Aug 2011 16:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfAZ4vvaORaL for ; Mon, 15 Aug 2011 16:22:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D3F7711E8086 for ; Mon, 15 Aug 2011 16:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2063; q=dns/txt; s=iport; t=1313450595; x=1314660195; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4ghYI4kkAxyUe8cv7sy+KY+mnu5k5CxEXGTYr8bh+t4=; b=QKf7+M04wXtQMjF3YqxcXfaQiyfbfR2nMEK8ro92/1dYhywz2aH6ndPA mGAIS/5pAf9qzqx8sijfH9CSnUZhbbEiieMpba32KWaZoqZw5EqaCAV7w 3yE065lpDvvXfpoXn0F83ZLlJFjuYMkxZ3mfZAtJOplaMeqNE92wP6uK7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEOpSU6rRDoI/2dsb2JhbABBqBZ3gUABAQEBAgESASc/BQsLGC5XBhMih04Em30Bnw2FaF8Eh1+LM5EU X-IronPort-AV: E=Sophos;i="4.67,377,1309737600"; d="scan'208";a="13379286" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 15 Aug 2011 23:23:14 +0000 Received: from sjc-vpn5-1504.cisco.com (sjc-vpn5-1504.cisco.com [10.21.93.224]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7FNNDaG018949; Mon, 15 Aug 2011 23:23:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: Date: Mon, 15 Aug 2011 17:23:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6D8BB182-920B-4BA6-B040-562EF0BCF461@cisco.com> References: <4E437E9D.8000504@telia.com> <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> <4E456093.6090609@telia.com> To: Wan-Teh Chang X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 23:22:28 -0000 On Aug 12, 2011, at 12:11 PM, Wan-Teh Chang wrote: > On Fri, Aug 12, 2011 at 10:19 AM, Anders Rundgren > wrote: >> On 2011-08-12 19:04, Max Pritikin wrote: >>=20 >>> There is nothing within EST or CMC or SCEP or otherwise that >>> would _preclude_ a browser or a mobile device. >>=20 >> That's what the KEYPROV guys said as well. However, they forgot >> a tiny detail: how to bind their protocol to a browser. >=20 > I am interested in implementing a certificate enrollment protocol in > Firefox and Google Chrome to replace . I am studying > KeyGen2 and EST. I have a question about Anders' comment > above. >=20 > By "binding a certificate enrollment protocol to a browser", do you > mean specifying an HTML element or JavaScript function for a > server to kick off the key generation and certificate request > generation in the browser? >=20 > For importing a newly issued certificate into a browser, = draft-pritikin-est-02 > specifies the MIME-type "application/x-est-x509" for the HTTP > response carrying the new certificate, which is the moral equivalent > of "application/x-x509-user-cert" used for . So it's not > clear to me if any other "browser binding" is necessary for this > operation. Perhaps a JavaScript function similar to Mozilla's > crypto.importUserCertificates function? > = https://developer.mozilla.org/en/JavaScript_crypto/importUserCertificates This matches my thinking and I'm very appreciative of the feedback from = a browser oriented perspective.=20 > The handling of an HTTP 202 response in Section 5.2.2 of > draft-pritikin-est-02 does seem to be intended for an automated > client (such as one running on an unattended network > appliance) rather than a web browser. You are correct that I was thinking of unattended network appliances = during that discussion. I am very open to suggestions concerning how to = handle this case (and what sort of "human readable content" should be = returned).=20 - max > Wan-Teh Chang From ietf@augustcellars.com Mon Aug 15 18:17:14 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C9721F8BDB for ; Mon, 15 Aug 2011 18:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvRaExA+1Jry for ; Mon, 15 Aug 2011 18:17:14 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C64CC21F8B85 for ; Mon, 15 Aug 2011 18:17:13 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 284CA2C9C5; Mon, 15 Aug 2011 18:18:00 -0700 (PDT) From: "Jim Schaad" To: , "'Stephen Kent'" References: from "Stephen Kent" at Aug 10, 11 03:55:40 pm <201108120043.p7C0hO34001596@fs4113.wdf.sap.corp> In-Reply-To: <201108120043.p7C0hO34001596@fs4113.wdf.sap.corp> Date: Mon, 15 Aug 2011 18:52:16 -0700 Message-ID: <005a01cc5bb7$255c23c0$70146b40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK1EqfCtI9gxV+5SmAC6hrDQv0H85NNSOJQ Content-Language: en-us Cc: pkix@ietf.org Subject: Re: [pkix] status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 01:17:14 -0000 Please clarify - do you mean CMS or CMC > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Martin Rex > Sent: Thursday, August 11, 2011 5:43 PM > To: Stephen Kent > Cc: pkix@ietf.org > Subject: Re: [pkix] status update > > Stephen Kent wrote: > > > > - extending CMC to accommodate scenarios in which a CA/AR > > generates the key pair for the subject > > There seem to be various scenarios in productive use where the the keypair > is created centrally and the entire credentials distributed. > > Company-internal, we originally used PKCS#12 and now use Active Directory. > > In electronic data exchange in Germany, there is a standard for taxes (Elster) > and for social security data, and the credentials are also centrally created by > the CA and distributed as PKCS#12 (one PKCS#12 with two keypairs, one for > signing the other for encryption). > > Something similar is done in other countries as well (I usually only learn about > such scenarios when the existing functionality is insufficient to implement > the customer or legal requirement and I have to add new features at the > lower-level abstract APIs for pkcs7/cms and WSSec.) > > > Who is acutally doing this with CMS (or wants to do this with CMS)? > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Mon Aug 15 21:26:13 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E011E8086 for ; Mon, 15 Aug 2011 21:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgULA7jc2voQ for ; Mon, 15 Aug 2011 21:26:12 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7611E8085 for ; Mon, 15 Aug 2011 21:26:11 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E9700554749; Tue, 16 Aug 2011 06:26:55 +0200 Message-ID: <4E49F18B.6060401@telia.com> Date: Tue, 16 Aug 2011 06:26:51 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Max Pritikin References: <4E437E9D.8000504@telia.com> <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> <4E456093.6090609@telia.com> <6D8BB182-920B-4BA6-B040-562EF0BCF461@cisco.com> In-Reply-To: <6D8BB182-920B-4BA6-B040-562EF0BCF461@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 04:26:13 -0000 IMHO the browser use-case is so large in terms of potential users, and has to date been much less successful than for example SCEP for network devices, that it deserves a dedicated solution. The browser use case has quite a bunch of unique characteristics like: - User authentication on the web level rather than in the protocol - It is rather the server that requests keys to be generated - The user is effectively a part of the protocol - Last but not the least: a variant set of key containers It is possible that by creating a scheme with a gazillion options you could address the entire enrollment universe. My belief is that CMP will appear completely trivial when you're done :-) It has in this context been mentioned that upgrading CAs end is very difficult: It is actually extremely simple compared to upgrading billions of client platforms using dozens of operating systems. http://ejbca.org is a example of a CA that has "plugins" for a huge number of standard as well as proprietary enrollment and management protocols. The perceived XML vs ASN.1 issue doesn't exist in *any* CA product worth mentioning. Anders On 2011-08-16 01:23, Max Pritikin wrote: > > On Aug 12, 2011, at 12:11 PM, Wan-Teh Chang wrote: > >> On Fri, Aug 12, 2011 at 10:19 AM, Anders Rundgren >> wrote: >>> On 2011-08-12 19:04, Max Pritikin wrote: >>> >>>> There is nothing within EST or CMC or SCEP or otherwise that >>>> would _preclude_ a browser or a mobile device. >>> >>> That's what the KEYPROV guys said as well. However, they forgot >>> a tiny detail: how to bind their protocol to a browser. >> >> I am interested in implementing a certificate enrollment protocol in >> Firefox and Google Chrome to replace . I am studying >> KeyGen2 and EST. I have a question about Anders' comment >> above. >> >> By "binding a certificate enrollment protocol to a browser", do you >> mean specifying an HTML element or JavaScript function for a >> server to kick off the key generation and certificate request >> generation in the browser? >> >> For importing a newly issued certificate into a browser, draft-pritikin-est-02 >> specifies the MIME-type "application/x-est-x509" for the HTTP >> response carrying the new certificate, which is the moral equivalent >> of "application/x-x509-user-cert" used for . So it's not >> clear to me if any other "browser binding" is necessary for this >> operation. Perhaps a JavaScript function similar to Mozilla's >> crypto.importUserCertificates function? >> https://developer.mozilla.org/en/JavaScript_crypto/importUserCertificates > > This matches my thinking and I'm very appreciative of the feedback from a browser oriented perspective. > >> The handling of an HTTP 202 response in Section 5.2.2 of >> draft-pritikin-est-02 does seem to be intended for an automated >> client (such as one running on an unattended network >> appliance) rather than a web browser. > > You are correct that I was thinking of unattended network appliances during that discussion. I am very open to suggestions concerning how to handle this case (and what sort of "human readable content" should be returned). > > - max > > >> Wan-Teh Chang > > From internet-drafts@ietf.org Tue Aug 16 00:46:00 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857EC21F8B61; Tue, 16 Aug 2011 00:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeU9DryTuwde; Tue, 16 Aug 2011 00:46:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1751621F8B2E; Tue, 16 Aug 2011 00:46:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110816074600.18957.83745.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2011 00:46:00 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 07:46:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : S/MIME Capabilities for Public Key Definitions Author(s) : Jim Schaad Filename : draft-ietf-pkix-pubkey-caps-03.txt Pages : 23 Date : 2011-08-16 This document defines a set of S/MIME Capability types for ASN.1 encoding for the current set of public keys define in the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is with the OCSP Agility draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-03.txt From kent@bbn.com Tue Aug 16 08:13:00 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C4021F8B07 for ; Tue, 16 Aug 2011 08:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GHP0i8SCS0F for ; Tue, 16 Aug 2011 08:13:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4665D21F8AEA for ; Tue, 16 Aug 2011 08:13:00 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49211) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtLKu-0000GF-GO for pkix@ietf.org; Tue, 16 Aug 2011 11:13:48 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 16 Aug 2011 11:10:38 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] draft-ietf-pkix-pubkey-caps X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 15:13:01 -0000 Folks, WGLC has ended for this doc, and I have seen no adverse comments, so we will forward it to the IESG, shortly. Steve From kent@bbn.com Tue Aug 16 08:46:38 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5268311E80A0 for ; Tue, 16 Aug 2011 08:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y+cQ6ERJAVS for ; Tue, 16 Aug 2011 08:46:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B7A6421F8B35 for ; Tue, 16 Aug 2011 08:46:37 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49226) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QtLrQ-00010j-Ue; Tue, 16 Aug 2011 11:47:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E49F18B.6060401@telia.com> References: <4E437E9D.8000504@telia.com> <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> <4E456093.6090609@telia.com> <6D8BB182-920B-4BA6-B040-562EF0BCF461@cisco.com> <4E49F18B.6060401@telia.com> Date: Tue, 16 Aug 2011 11:47:16 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 15:46:38 -0000 At 6:26 AM +0200 8/16/11, Anders Rundgren wrote: >IMHO the browser use-case is so large in terms of potential users, >and has to date been much less successful than for example SCEP >for network devices, that it deserves a dedicated solution. Max didn't sign up to do that. If Max wants to make some accommodations for browsers, and he can still retain the simplicity that motivates EST, then that's fine. Steve From mrex@sap.com Tue Aug 16 10:10:39 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01321F8B80 for ; Tue, 16 Aug 2011 10:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.012 X-Spam-Level: X-Spam-Status: No, score=-10.012 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sJ6YNe7CKxG for ; Tue, 16 Aug 2011 10:10:38 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 483FB21F8B7B for ; Tue, 16 Aug 2011 10:10:38 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p7GHBCdl027410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Aug 2011 19:11:12 +0200 (MEST) From: Martin Rex Message-Id: <201108161711.p7GHBAOI011748@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Tue, 16 Aug 2011 19:11:10 +0200 (MEST) In-Reply-To: <005a01cc5bb7$255c23c0$70146b40$@augustcellars.com> from "Jim Schaad" at Aug 15, 11 06:52:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 17:10:39 -0000 Jim Schaad wrote: > > Please clarify - do you mean CMS or CMC > > > Stephen Kent wrote: > > > > > > - extending CMC to accommodate scenarios in which a CA/AR > > > generates the key pair for the subject "to accomodate scenarios in which CA/AR generates the key pair for the subject" sounds like a usage scenario which is currently covered by PKCS#12. Scenarios I know have been either using PKCS#12 exclusively or been offering PKCS#12 as an option. And often, they're also used to bootstrap trust along the way. -Martin From anders.rundgren@telia.com Tue Aug 16 10:26:07 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72F621F8B8C for ; Tue, 16 Aug 2011 10:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhYyWIHc5rhO for ; Tue, 16 Aug 2011 10:26:07 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id F0DD921F8B86 for ; Tue, 16 Aug 2011 10:26:06 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E97005A8C42; Tue, 16 Aug 2011 19:26:48 +0200 Message-ID: <4E4AA854.6080806@telia.com> Date: Tue, 16 Aug 2011 19:26:44 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Stephen Kent References: <4E437E9D.8000504@telia.com> <328D52E9-2105-4E66-A7BC-B7DCFE495A08@cisco.com> <4E456093.6090609@telia.com> <6D8BB182-920B-4BA6-B040-562EF0BCF461@cisco.com> <4E49F18B.6060401@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] EST-02. Re: status update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 17:26:07 -0000 On 2011-08-16 17:47, Stephen Kent wrote: > At 6:26 AM +0200 8/16/11, Anders Rundgren wrote: >> IMHO the browser use-case is so large in terms of potential users, >> and has to date been much less successful than for example SCEP >> for network devices, that it deserves a dedicated solution. > > Max didn't sign up to do that. > > If Max wants to make some accommodations for browsers, and he > can still retain the simplicity that motivates EST, then that's > fine. Yes, if Max also can retain that simplicity when the browser's target key-container is a smart card, he has outsmarted the entire computer security industry. Anders From anders.rundgren@telia.com Thu Aug 18 23:41:00 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3C121F8546 for ; Thu, 18 Aug 2011 23:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xzn3x3DZQ77K for ; Thu, 18 Aug 2011 23:40:59 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEDF21F8532 for ; Thu, 18 Aug 2011 23:40:58 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E97006A0EA7; Fri, 19 Aug 2011 08:41:53 +0200 Message-ID: <4E4E05AA.2090105@telia.com> Date: Fri, 19 Aug 2011 08:41:46 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: "pkix@ietf.org" , max pritikin X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------090103080306070800090408" Subject: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 06:41:00 -0000 This is a multi-part message in MIME format. --------------090103080306070800090408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lets say you run a small Windows-only enterprise using the latest server and client versions. Now, assume that you want to use smart cards instead of passwords. Oops! You also need to purchase a $25 000 Forefront Identity Manager and then hire a really pricey smart card consultant who knows all about drivers and cards. Only government agencies would ever /considering /buying into that. How does EST relate to this scenario? Anders --------------090103080306070800090408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lets say you run a small Windows-only enterprise using the latest server and client versions.

Now, assume that you want to use smart cards instead of passwords.

Oops! You also need to purchase a $25 000 Forefront Identity Manager and then hire a really pricey smart card consultant who knows all about drivers and cards.  Only government agencies would ever considering buying into that.

How does EST relate to this scenario?

Anders
--------------090103080306070800090408-- From pritikin@cisco.com Fri Aug 19 10:27:15 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3707F21F84F2 for ; Fri, 19 Aug 2011 10:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh-IZ8wT-OGR for ; Fri, 19 Aug 2011 10:27:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7243121F8B38 for ; Fri, 19 Aug 2011 10:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2795; q=dns/txt; s=iport; t=1313774892; x=1314984492; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UJsdikThrSJy3E1qdnI6CKXzv1AsDSbOveoqMil/KJg=; b=NQct4LTiZpYbOltxYSratV0RQJdLx9eJ9iK7Vcq9V+4sTJ58WKatyf2y tpXKfwOdtO1wzM1RZoqpy7qur8b0ipmXubJq6H2oj2KfHsPJyMbyoZMaA NzUO+kLBd7ykC7YymCiGDexVBE6cY4a8sY24Fg3q291xc5DgvfN5SS1yD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEmcTk6rRDoG/2dsb2JhbAA5CagNd4FAAQEBAQIBEgEnPwULC0ZXBicHB4dPmh4BnnODKIJBXwSHYIszhQyMCA X-IronPort-AV: E=Sophos;i="4.68,251,1312156800"; d="scan'208";a="14756416" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-2.cisco.com with ESMTP; 19 Aug 2011 17:28:11 +0000 Received: from [10.21.71.56] ([10.21.71.56]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7JHSAJD032236; Fri, 19 Aug 2011 17:28:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4E4E05AA.2090105@telia.com> Date: Fri, 19 Aug 2011 11:28:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E4E05AA.2090105@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 17:27:15 -0000 Response inline, On Aug 19, 2011, at 12:41 AM, Anders Rundgren wrote: > Lets say you run a small Windows-only enterprise using the latest = server and client versions. >=20 > Now, assume that you want to use smart cards instead of passwords. >=20 > Oops! You also need to purchase a $25 000 Forefront Identity Manager = and then hire a really pricey smart card consultant who knows all = about drivers and cards. Only government agencies would ever = considering buying into that. >=20 > How does EST relate to this scenario? This doesn't strike me as a technical discussion -- Microsoft's = licensing/pricing policy is not based on technical protocol details. I = don't work for Microsoft and am not in a good position to hypothesize = about their business decisions nor do I think this is this the = appropriate forum for that discussion.=20 We could have an interesting discussion about the role of a consistent = message from the standards community in driving interoperability amongst = vendors. But that isn't technical in nature either. The best I can offer is the observation that Microsoft's current = offerings include a undocumented(?) profile of CMC combined with a = non-RFC5273 related transport. Additionally Microsoft's new work = includes a newer MS-WSTEP SOAP based enrollment protocol which is = interesting but is also proprietary and includes dependencies on SOAP, = WS-Security and WS-Trust that I think is overkill. Similarly VerSign has = a web services api which is consistent with Microsoft's ideas but is not = interoperable. =20 Broadly, I argue that EST provides clarify regarding the existing CMC = and CMC Transport options in a way that meets the requirements exposed = by those non-standards based implementations and drives = interoperability. I would like to work more closely with both Microsoft = and Versign on their recent efforts in this area and have appreciated = the conversations I've had with them about these technologies. Their = input has been valuable in forming my personal opinions which helped = shape the EST drafts. (Albeit with continued gaps regarding the SOAP/WS = stack). =20 I continue to hope that EST helps drive greater interoperability which I = believe will address some of your non-technical concerns. I believe that = our focus, in this forum, is to move the IETF PKIX standards forward. It = is interesting to compare and understand our efforts in regards to = proprietary solutions from various vendors -- and I strongly believe in = working together as a community -- but ultimately some product teams are = going to explore their own non-standards based solutions and we can't = let ourselves be too distracted by that.=20 - max >=20 > Anders >=20 From anders.rundgren@telia.com Fri Aug 19 12:02:12 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0D321F8B46 for ; Fri, 19 Aug 2011 12:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNGHElu3YUPq for ; Fri, 19 Aug 2011 12:02:12 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id C2E8221F8B1D for ; Fri, 19 Aug 2011 12:02:11 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B01535A21; Fri, 19 Aug 2011 21:03:05 +0200 Message-ID: <4E4EB362.5090903@telia.com> Date: Fri, 19 Aug 2011 21:02:58 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Max Pritikin References: <4E4E05AA.2090105@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 19:02:12 -0000 Max, You skipped the core of subject line. How is smart card enrollment supported by EST? Since EST-02 does not mention words like Browser, Middleware, and Tokens it is hard to believe that these items have gotten much consideration during the design. This is nothing to get hung about because it applies to all PKIX enrollment schemes. However, as a person involved in smart card deployments, I don't see the point hoping that somebody else will take care of the mess created by leaving half of the enrollment infrastructure undefined. Anders On 2011-08-19 19:28, Max Pritikin wrote: > Response inline, > > On Aug 19, 2011, at 12:41 AM, Anders Rundgren wrote: > >> Lets say you run a small Windows-only enterprise using the latest server and client versions. >> >> Now, assume that you want to use smart cards instead of passwords. >> >> Oops! You also need to purchase a $25 000 Forefront Identity Manager and then hire a really pricey smart card consultant who knows all about drivers and cards. Only government agencies would ever considering buying into that. >> >> How does EST relate to this scenario? > This doesn't strike me as a technical discussion -- Microsoft's licensing/pricing policy is not based on technical protocol details. I don't work for Microsoft and am not in a good position to hypothesize about their business decisions nor do I think this is this the appropriate forum for that discussion. > > We could have an interesting discussion about the role of a consistent message from the standards community in driving interoperability amongst vendors. But that isn't technical in nature either. > > The best I can offer is the observation that Microsoft's current offerings include a undocumented(?) profile of CMC combined with a non-RFC5273 related transport. Additionally Microsoft's new work includes a newer MS-WSTEP SOAP based enrollment protocol which is interesting but is also proprietary and includes dependencies on SOAP, WS-Security and WS-Trust that I think is overkill. Similarly VerSign has a web services api which is consistent with Microsoft's ideas but is not interoperable. > > Broadly, I argue that EST provides clarify regarding the existing CMC and CMC Transport options in a way that meets the requirements exposed by those non-standards based implementations and drives interoperability. I would like to work more closely with both Microsoft and Versign on their recent efforts in this area and have appreciated the conversations I've had with them about these technologies. Their input has been valuable in forming my personal opinions which helped shape the EST drafts. (Albeit with continued gaps regarding the SOAP/WS stack). > > I continue to hope that EST helps drive greater interoperability which I believe will address some of your non-technical concerns. I believe that our focus, in this forum, is to move the IETF PKIX standards forward. It is interesting to compare and understand our efforts in regards to proprietary solutions from various vendors -- and I strongly believe in working together as a community -- but ultimately some product teams are going to explore their own non-standards based solutions and we can't let ourselves be too distracted by that. > > - max > >> Anders >> > From pritikin@cisco.com Fri Aug 19 12:54:45 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649E211E80A3 for ; Fri, 19 Aug 2011 12:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERTBy2vKnY32 for ; Fri, 19 Aug 2011 12:54:43 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C0AFD11E8094 for ; Fri, 19 Aug 2011 12:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=4528; q=dns/txt; s=iport; t=1313783741; x=1314993341; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=x3DtZx+Jm2fdFJ45lj1Hw9fIpiWvDYKXDQ5kenqwmes=; b=hbG6UHipS6wRk8t4XpvekelzYl+ufvmhnYbEo+gDHjhG7BkYHD8nTRuS Kpg34fBh5POW1kdPeX7cv2HrbbN3d4Vs/gXvi9BOW7R6iV2oBss2fcK1u m449oWbGmyB4lgaPsNDwUEFSnx5nIgTGhhXhGY6tax2tUwBaYqI1xRbea Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGy/Tk6tJV2Z/2dsb2JhbAA4CagNd4FAAQEBAQIBEgEnLgMFCQULCxguVwYnBweHT5oSAZ53gyiCQV8Eh2CLM4UMjAg X-IronPort-AV: E=Sophos;i="4.68,252,1312156800"; d="scan'208";a="14802440" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 19 Aug 2011 19:55:24 +0000 Received: from [10.21.71.56] ([10.21.71.56]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7JJtNBA006490; Fri, 19 Aug 2011 19:55:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4E4EB362.5090903@telia.com> Date: Fri, 19 Aug 2011 13:55:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 19:54:45 -0000 On Aug 19, 2011, at 1:02 PM, Anders Rundgren wrote: > Max, > You skipped the core of subject line. =20 My apologies. I was unaware that you had hidden your question in the = subject line and that the body of your message was extraneous. :) > How is smart card enrollment supported by EST? Obviously EST depends on existing cryptographic primitives which are be = provided by common smartcard APIs. As such it is trivial to show that a = keypair contained on a smartcard can be used in an EST exchange. As an = expert in this area I suspect you are very familiar with these APIs and = their capabilities so my assumption is that you have a different = concern.=20 I'm wondering if your underlying concern is how the CA server can = determine that the key is actually on the smartcard. Is this correct? Is = this your concern? If email as a communication medium isn't working for this conversation = I'd be happy to host a webex conference call with any interested = attendees. Or I'd be happy to unicast my phone number to you for an = offline conversation.=20 - max > Since EST-02 does not mention words like Browser, Middleware, and = Tokens it is hard to believe that these items have gotten much = consideration during the design. This is nothing to get hung about > because it applies to all PKIX enrollment schemes. >=20 > However, as a person involved in smart card deployments, I don't see = the point hoping that somebody else will take care of the mess created = by leaving half of the enrollment infrastructure undefined. >=20 > Anders >=20 > On 2011-08-19 19:28, Max Pritikin wrote: >> Response inline, >>=20 >> On Aug 19, 2011, at 12:41 AM, Anders Rundgren wrote: >>=20 >>> Lets say you run a small Windows-only enterprise using the latest = server and client versions. >>>=20 >>> Now, assume that you want to use smart cards instead of passwords. >>>=20 >>> Oops! You also need to purchase a $25 000 Forefront Identity Manager = and then hire a really pricey smart card consultant who knows all = about drivers and cards. Only government agencies would ever = considering buying into that. >>>=20 >>> How does EST relate to this scenario? >> This doesn't strike me as a technical discussion -- Microsoft's = licensing/pricing policy is not based on technical protocol details. I = don't work for Microsoft and am not in a good position to hypothesize = about their business decisions nor do I think this is this the = appropriate forum for that discussion.=20 >>=20 >> We could have an interesting discussion about the role of a = consistent message from the standards community in driving = interoperability amongst vendors. But that isn't technical in nature = either. >>=20 >> The best I can offer is the observation that Microsoft's current = offerings include a undocumented(?) profile of CMC combined with a = non-RFC5273 related transport. Additionally Microsoft's new work = includes a newer MS-WSTEP SOAP based enrollment protocol which is = interesting but is also proprietary and includes dependencies on SOAP, = WS-Security and WS-Trust that I think is overkill. Similarly VerSign has = a web services api which is consistent with Microsoft's ideas but is not = interoperable. =20 >>=20 >> Broadly, I argue that EST provides clarify regarding the existing CMC = and CMC Transport options in a way that meets the requirements exposed = by those non-standards based implementations and drives = interoperability. I would like to work more closely with both Microsoft = and Versign on their recent efforts in this area and have appreciated = the conversations I've had with them about these technologies. Their = input has been valuable in forming my personal opinions which helped = shape the EST drafts. (Albeit with continued gaps regarding the SOAP/WS = stack). =20 >>=20 >> I continue to hope that EST helps drive greater interoperability = which I believe will address some of your non-technical concerns. I = believe that our focus, in this forum, is to move the IETF PKIX = standards forward. It is interesting to compare and understand our = efforts in regards to proprietary solutions from various vendors -- and = I strongly believe in working together as a community -- but ultimately = some product teams are going to explore their own non-standards based = solutions and we can't let ourselves be too distracted by that.=20 >>=20 >> - max >>=20 >>> Anders >>>=20 >>=20 >=20 From anders.rundgren@telia.com Fri Aug 19 13:33:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B7711E80C7 for ; Fri, 19 Aug 2011 13:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvtvDfpuortr for ; Fri, 19 Aug 2011 13:33:46 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB2111E80C6 for ; Fri, 19 Aug 2011 13:33:45 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F00CCED30; Fri, 19 Aug 2011 22:34:38 +0200 Message-ID: <4E4EC8D5.3040108@telia.com> Date: Fri, 19 Aug 2011 22:34:29 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Max Pritikin References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> In-Reply-To: <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 20:33:46 -0000 On 2011-08-19 21:55, Max Pritikin wrote: > I'm wondering if your underlying concern is how the CA server can determine > that the key is actually on the smartcard. Is this correct? Is this your concern? Well, my #1 concern is how you can create a smart card enrollment system that allows you to buy an empty card, insert it, go to a CA with a browser, authenticate (in some way) and then get certificates provisioned including things like issuer-defined PIN-codes etc. As it appears you indeed need a smart card expert and tons of proprietary software. Existing middleware like PKCS #11 does not support on-line provisioning so basically the whole thing is toast unless you go far outside of the protocol. This is probably unacceptable to you and PKIX, which to some extent explains why there is a virtual army of companies writing smart card middleware [primarily] for governments. My take on this, is creating a complete system where all interfaces are defined: CA => Browser => Protocol => Middleware => Container Yes, there are User interfaces as well in layer 2-4. Although this may look very "cardish", the design is actually targeting smart key-stores including enhanced "soft tokens". Will this be a "standard"? I leave that to the market to decide :-) Anders > On Aug 19, 2011, at 1:02 PM, Anders Rundgren wrote: > >> Max, >> You skipped the core of subject line. > My apologies. I was unaware that you had hidden your question in the subject line and that the body of your message was extraneous. :) > >> How is smart card enrollment supported by EST? > Obviously EST depends on existing cryptographic primitives which are be provided by common smartcard APIs. As such it is trivial to show that a keypair contained on a smartcard can be used in an EST exchange. As an expert in this area I suspect you are very familiar with these APIs and their capabilities so my assumption is that you have a different concern. > > I'm wondering if your underlying concern is how the CA server can determine that the key is actually on the smartcard. Is this correct? Is this your concern? > > If email as a communication medium isn't working for this conversation I'd be happy to host a webex conference call with any interested attendees. Or I'd be happy to unicast my phone number to you for an offline conversation. > > - max > >> Since EST-02 does not mention words like Browser, Middleware, and Tokens it is hard to believe that these items have gotten much consideration during the design. This is nothing to get hung about >> because it applies to all PKIX enrollment schemes. >> >> However, as a person involved in smart card deployments, I don't see the point hoping that somebody else will take care of the mess created by leaving half of the enrollment infrastructure undefined. >> >> Anders >> >> On 2011-08-19 19:28, Max Pritikin wrote: >>> Response inline, >>> >>> On Aug 19, 2011, at 12:41 AM, Anders Rundgren wrote: >>> >>>> Lets say you run a small Windows-only enterprise using the latest server and client versions. >>>> >>>> Now, assume that you want to use smart cards instead of passwords. >>>> >>>> Oops! You also need to purchase a $25 000 Forefront Identity Manager and then hire a really pricey smart card consultant who knows all about drivers and cards. Only government agencies would ever considering buying into that. >>>> >>>> How does EST relate to this scenario? >>> This doesn't strike me as a technical discussion -- Microsoft's licensing/pricing policy is not based on technical protocol details. I don't work for Microsoft and am not in a good position to hypothesize about their business decisions nor do I think this is this the appropriate forum for that discussion. >>> >>> We could have an interesting discussion about the role of a consistent message from the standards community in driving interoperability amongst vendors. But that isn't technical in nature either. >>> >>> The best I can offer is the observation that Microsoft's current offerings include a undocumented(?) profile of CMC combined with a non-RFC5273 related transport. Additionally Microsoft's new work includes a newer MS-WSTEP SOAP based enrollment protocol which is interesting but is also proprietary and includes dependencies on SOAP, WS-Security and WS-Trust that I think is overkill. Similarly VerSign has a web services api which is consistent with Microsoft's ideas but is not interoperable. >>> >>> Broadly, I argue that EST provides clarify regarding the existing CMC and CMC Transport options in a way that meets the requirements exposed by those non-standards based implementations and drives interoperability. I would like to work more closely with both Microsoft and Versign on their recent efforts in this area and have appreciated the conversations I've had with them about these technologies. Their input has been valuable in forming my personal opinions which helped shape the EST drafts. (Albeit with continued gaps regarding the SOAP/WS stack). >>> >>> I continue to hope that EST helps drive greater interoperability which I believe will address some of your non-technical concerns. I believe that our focus, in this forum, is to move the IETF PKIX standards forward. It is interesting to compare and understand our efforts in regards to proprietary solutions from various vendors -- and I strongly believe in working together as a community -- but ultimately some product teams are going to explore their own non-standards based solutions and we can't let ourselves be too distracted by that. >>> >>> - max >>> >>>> Anders >>>> > From mstjohns@comcast.net Fri Aug 19 14:21:11 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A509E11E80DC for ; Fri, 19 Aug 2011 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg5pVHCujAou for ; Fri, 19 Aug 2011 14:21:10 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8911E80D3 for ; Fri, 19 Aug 2011 14:21:09 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id NLwE1h0080xGWP855MN7AV; Fri, 19 Aug 2011 21:22:07 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta12.westchester.pa.mail.comcast.net with comcast id NMJE1h02q1EtFYL3YMJard; Fri, 19 Aug 2011 21:21:53 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Aug 2011 17:17:52 -0400 To: Anders Rundgren , Max Pritikin From: Michael StJohns In-Reply-To: <4E4EC8D5.3040108@telia.com> References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20110819212109.3DC8911E80D3@ietfa.amsl.com> Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 21:21:11 -0000 Hi Anders - Comments in line At 04:34 PM 8/19/2011, Anders Rundgren wrote: >On 2011-08-19 21:55, Max Pritikin wrote: > >> I'm wondering if your underlying concern is how the CA server can determine >> that the key is actually on the smartcard. Is this correct? Is this your concern? > >Well, my #1 concern is how you can create a smart card enrollment system that >allows you to buy an empty card, insert it, go to a CA with a browser, authenticate (in >some way) and then get certificates provisioned including things like issuer-defined >PIN-codes etc. Generally, an empty card won't get you much. You have to load the card with the appropriate applet or buy the card already provisioned with such applet (e.g. the CAC or PIVII applet comes with a few different cards, there's also coolkey and musclecard). Alternately, you can get a generic card understood by a token management system that knows how to load the applet and provision the card - for something in open source, see Dogtag - the open source version of the Red Hat PKI stuff. >As it appears you indeed need a smart card expert and tons of proprietary software. >Existing middleware like PKCS #11 does not support on-line provisioning so basically >the whole thing is toast unless you go far outside of the protocol. Strange - I've actually been able to use PKCS11 in conjunction with things like browsers to do on-line provisioning. It really just depends on the protocol or interface you need to use to talk to the card. Firefox for example let's you add PKCS11 drivers as security modules to the browser. You can then use various tools to create keys and certs on the card. For the open source play pen here I recommend Muscle and its assorted plugins including the PKCS11 musclecard driver. Continuing on, there's a whole body of open standards on provisioning the card with applets - check out www.globalplatform.org. To be honest, the hardest part is finding card vendors willing to sell in quantities less than 1K. And continuing on even further - there's always PKCS15. >This is probably >unacceptable to you and PKIX, which to some extent explains why there is a virtual >army of companies writing smart card middleware [primarily] for governments. > >My take on this, is creating a complete system where all interfaces are defined: > > CA => Browser => Protocol => Middleware => Container I'm really not convinced this is a PKIX issue. It's possible that something like the Java Card 3.0 Connected spec's might actually already fit most of the bill though. Later, Mike >Yes, there are User interfaces as well in layer 2-4. > >Although this may look very "cardish", the design is actually targeting smart >key-stores including enhanced "soft tokens". > >Will this be a "standard"? I leave that to the market to decide :-) > >Anders > >> On Aug 19, 2011, at 1:02 PM, Anders Rundgren wrote: >> >>> Max, >>> You skipped the core of subject line. >> My apologies. I was unaware that you had hidden your question in the subject line and that the body of your message was extraneous. :) >> >>> How is smart card enrollment supported by EST? >> Obviously EST depends on existing cryptographic primitives which are be provided by common smartcard APIs. As such it is trivial to show that a keypair contained on a smartcard can be used in an EST exchange. As an expert in this area I suspect you are very familiar with these APIs and their capabilities so my assumption is that you have a different concern. >> >> I'm wondering if your underlying concern is how the CA server can determine that the key is actually on the smartcard. Is this correct? Is this your concern? >> >> If email as a communication medium isn't working for this conversation I'd be happy to host a webex conference call with any interested attendees. Or I'd be happy to unicast my phone number to you for an offline conversation. >> >> - max >> >>> Since EST-02 does not mention words like Browser, Middleware, and Tokens it is hard to believe that these items have gotten much consideration during the design. This is nothing to get hung about >>> because it applies to all PKIX enrollment schemes. >>> >>> However, as a person involved in smart card deployments, I don't see the point hoping that somebody else will take care of the mess created by leaving half of the enrollment infrastructure undefined. >>> >>> Anders >>> >>> On 2011-08-19 19:28, Max Pritikin wrote: >>>> Response inline, >>>> >>>> On Aug 19, 2011, at 12:41 AM, Anders Rundgren wrote: >>>> >>>>> Lets say you run a small Windows-only enterprise using the latest server and client versions. >>>>> >>>>> Now, assume that you want to use smart cards instead of passwords. >>>>> >>>>> Oops! You also need to purchase a $25 000 Forefront Identity Manager and then hire a really pricey smart card consultant who knows all about drivers and cards. Only government agencies would ever considering buying into that. >>>>> >>>>> How does EST relate to this scenario? >>>> This doesn't strike me as a technical discussion -- Microsoft's licensing/pricing policy is not based on technical protocol details. I don't work for Microsoft and am not in a good position to hypothesize about their business decisions nor do I think this is this the appropriate forum for that discussion. >>>> >>>> We could have an interesting discussion about the role of a consistent message from the standards community in driving interoperability amongst vendors. But that isn't technical in nature either. >>>> >>>> The best I can offer is the observation that Microsoft's current offerings include a undocumented(?) profile of CMC combined with a non-RFC5273 related transport. Additionally Microsoft's new work includes a newer MS-WSTEP SOAP based enrollment protocol which is interesting but is also proprietary and includes dependencies on SOAP, WS-Security and WS-Trust that I think is overkill. Similarly VerSign has a web services api which is consistent with Microsoft's ideas but is not interoperable. >>>> >>>> Broadly, I argue that EST provides clarify regarding the existing CMC and CMC Transport options in a way that meets the requirements exposed by those non-standards based implementations and drives interoperability. I would like to work more closely with both Microsoft and Versign on their recent efforts in this area and have appreciated the conversations I've had with them about these technologies. Their input has been valuable in forming my personal opinions which helped shape the EST drafts. (Albeit with continued gaps regarding the SOAP/WS stack). >>>> >>>> I continue to hope that EST helps drive greater interoperability which I believe will address some of your non-technical concerns. I believe that our focus, in this forum, is to move the IETF PKIX standards forward. It is interesting to compare and understand our efforts in regards to proprietary solutions from various vendors -- and I strongly believe in working together as a community -- but ultimately some product teams are going to explore their own non-standards based solutions and we can't let ourselves be too distracted by that. >>>> >>>> - max >>>> >>>>> Anders >>>>> >> > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From pritikin@cisco.com Fri Aug 19 14:23:36 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B0611E80D3 for ; Fri, 19 Aug 2011 14:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjG7TnKLw4Or for ; Fri, 19 Aug 2011 14:23:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C0BB211E80B9 for ; Fri, 19 Aug 2011 14:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=7495; q=dns/txt; s=iport; t=1313789070; x=1314998670; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=42mARWkZpu6BUYaLUdWmx+xvWnnublqIkecSUPN5pUg=; b=iJvhktSkDym4lUYHYSivVC4g/QzyL46jVSteBO+hG4LTfVVYxW+Sh8bS 5oDcdBy4YTOnPGXga/xRsdfqRfpfaLUuQdVpLwzaCRE0bZ0wKPidli3Pi XUh5OxzHkfkomA8XUFkbKpwZi1wgS1EqIKvTW+oIE5rB/AfCvI1Z7b8pP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACLTTk6rRDoI/2dsb2JhbAA4CagOd4FAAQEBAQIBEgEnLgMFCQULCxguVwYnBweHT5l7AZ5ugyiCQV8Eh2CLM4UMjAg X-IronPort-AV: E=Sophos;i="4.68,252,1312156800"; d="scan'208";a="14821023" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 19 Aug 2011 21:24:29 +0000 Received: from [10.21.71.56] ([10.21.71.56]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7JLOSjl020468; Fri, 19 Aug 2011 21:24:28 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4E4EC8D5.3040108@telia.com> Date: Fri, 19 Aug 2011 15:24:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 21:23:40 -0000 On Aug 19, 2011, at 2:34 PM, Anders Rundgren wrote: > On 2011-08-19 21:55, Max Pritikin wrote: >=20 >> I'm wondering if your underlying concern is how the CA server can = determine >> that the key is actually on the smartcard. Is this correct? Is this = your concern? >=20 > Well, my #1 concern is how you can create a smart card enrollment = system that > allows you to buy an empty card, insert it, go to a CA with a browser, = authenticate (in > some way) and then get certificates provisioned including things like = issuer-defined > PIN-codes etc. We are of course assuming that the browser/client supports EST and the = smartcard itself. In which case I see no major impediment to what you = describe. At most I see an issue with the distribution of policy (e.g. = "issuer-defined PIN-codes") but I'm sure we can discuss appropriate = methods for that. Apparently I see the world like this: EST Server (e.g. CA) =3D> EST protocol =3D> EST Client (e.g. Browser) =3D>= Smartcard In my prototype I've focussed on the use of a general purpose web server = as the server interface and am very interested in Browser support for = the client. The flexibility of the browser UI as a client is of course = as compelling here as it is for so many other solutions. Still to some = extent we are only defining the EST protocol so it would be extremely = helpful if we could focus this conversation on protocol requirements.=20 What is it about this model you've described that requires something = different in the protocol? And what differences are you looking for? > As it appears you indeed need a smart card expert and tons of = proprietary software. > Existing middleware like PKCS #11 does not support on-line = provisioning so basically > the whole thing is toast unless you go far outside of the protocol. = This is probably > unacceptable to you and PKIX, which to some extent explains why there = is a virtual > army of companies writing smart card middleware [primarily] for = governments. >=20 > My take on this, is creating a complete system where all interfaces = are defined: >=20 > CA =3D> Browser =3D> Protocol =3D> Middleware =3D> = Container You appear to use a different ordering than I do and I'm not = understanding your proposed stack. Are you proposing that the protocol = is run on the local client and communicates between the web browser and = some middleware/driver for the smartcard? I'm not seeing how that = perspective helps us. - max > Yes, there are User interfaces as well in layer 2-4. >=20 > Although this may look very "cardish", the design is actually = targeting smart > key-stores including enhanced "soft tokens". >=20 > Will this be a "standard"? I leave that to the market to decide :-) >=20 > Anders >=20 >> On Aug 19, 2011, at 1:02 PM, Anders Rundgren wrote: >>=20 >>> Max, >>> You skipped the core of subject line. =20 >> My apologies. I was unaware that you had hidden your question in the = subject line and that the body of your message was extraneous. :) >>=20 >>> How is smart card enrollment supported by EST? >> Obviously EST depends on existing cryptographic primitives which are = be provided by common smartcard APIs. As such it is trivial to show that = a keypair contained on a smartcard can be used in an EST exchange. As an = expert in this area I suspect you are very familiar with these APIs and = their capabilities so my assumption is that you have a different = concern.=20 >>=20 >> I'm wondering if your underlying concern is how the CA server can = determine that the key is actually on the smartcard. Is this correct? Is = this your concern? >>=20 >> If email as a communication medium isn't working for this = conversation I'd be happy to host a webex conference call with any = interested attendees. Or I'd be happy to unicast my phone number to you = for an offline conversation.=20 >>=20 >> - max >>=20 >>> Since EST-02 does not mention words like Browser, Middleware, and = Tokens it is hard to believe that these items have gotten much = consideration during the design. This is nothing to get hung about >>> because it applies to all PKIX enrollment schemes. >>>=20 >>> However, as a person involved in smart card deployments, I don't see = the point hoping that somebody else will take care of the mess created = by leaving half of the enrollment infrastructure undefined. >>>=20 >>> Anders >>>=20 >>> On 2011-08-19 19:28, Max Pritikin wrote: >>>> Response inline, >>>>=20 >>>> On Aug 19, 2011, at 12:41 AM, Anders Rundgren wrote: >>>>=20 >>>>> Lets say you run a small Windows-only enterprise using the latest = server and client versions. >>>>>=20 >>>>> Now, assume that you want to use smart cards instead of passwords. >>>>>=20 >>>>> Oops! You also need to purchase a $25 000 Forefront Identity = Manager and then hire a really pricey smart card consultant who = knows all about drivers and cards. Only government agencies would ever = considering buying into that. >>>>>=20 >>>>> How does EST relate to this scenario? >>>> This doesn't strike me as a technical discussion -- Microsoft's = licensing/pricing policy is not based on technical protocol details. I = don't work for Microsoft and am not in a good position to hypothesize = about their business decisions nor do I think this is this the = appropriate forum for that discussion.=20 >>>>=20 >>>> We could have an interesting discussion about the role of a = consistent message from the standards community in driving = interoperability amongst vendors. But that isn't technical in nature = either. >>>>=20 >>>> The best I can offer is the observation that Microsoft's current = offerings include a undocumented(?) profile of CMC combined with a = non-RFC5273 related transport. Additionally Microsoft's new work = includes a newer MS-WSTEP SOAP based enrollment protocol which is = interesting but is also proprietary and includes dependencies on SOAP, = WS-Security and WS-Trust that I think is overkill. Similarly VerSign has = a web services api which is consistent with Microsoft's ideas but is not = interoperable. =20 >>>>=20 >>>> Broadly, I argue that EST provides clarify regarding the existing = CMC and CMC Transport options in a way that meets the requirements = exposed by those non-standards based implementations and drives = interoperability. I would like to work more closely with both Microsoft = and Versign on their recent efforts in this area and have appreciated = the conversations I've had with them about these technologies. Their = input has been valuable in forming my personal opinions which helped = shape the EST drafts. (Albeit with continued gaps regarding the SOAP/WS = stack). =20 >>>>=20 >>>> I continue to hope that EST helps drive greater interoperability = which I believe will address some of your non-technical concerns. I = believe that our focus, in this forum, is to move the IETF PKIX = standards forward. It is interesting to compare and understand our = efforts in regards to proprietary solutions from various vendors -- and = I strongly believe in working together as a community -- but ultimately = some product teams are going to explore their own non-standards based = solutions and we can't let ourselves be too distracted by that.=20 >>>>=20 >>>> - max >>>>=20 >>>>> Anders >>>>>=20 >>=20 >=20 From anders.rundgren@telia.com Fri Aug 19 22:18:20 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA5121F8797 for ; Fri, 19 Aug 2011 22:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlFT+NboWUKb for ; Fri, 19 Aug 2011 22:18:19 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 17E2521F8770 for ; Fri, 19 Aug 2011 22:18:18 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B0154328E; Sat, 20 Aug 2011 07:19:14 +0200 Message-ID: <4E4F43CA.3090405@telia.com> Date: Sat, 20 Aug 2011 07:19:06 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Max Pritikin References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> In-Reply-To: <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 05:18:20 -0000 On 2011-08-19 23:24, Max Pritikin wrote: > > Apparently I see the world like this: > > EST Server (e.g. CA) => EST protocol => EST Client (e.g. Browser) => Smartcard A problem with EST is that achieving *true end-to-end security* (which IMO is a prerequisite), seems to require that the crypto module/smart card/etc runs the entire protocol. AFAICT, none of the "contenders" have such requirements. Anders From anders.rundgren@telia.com Fri Aug 19 23:25:25 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348C521F8B2D for ; Fri, 19 Aug 2011 23:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp9MyKgxn7MB for ; Fri, 19 Aug 2011 23:25:24 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 07E4A21F8B27 for ; Fri, 19 Aug 2011 23:25:23 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B01544D88; Sat, 20 Aug 2011 08:26:18 +0200 Message-ID: <4E4F5382.7030903@telia.com> Date: Sat, 20 Aug 2011 08:26:10 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Michael StJohns References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <4E170C77019EDB75@smtp-in12.han.skanova.net> (added by postmaster@pne.skanova.net) In-Reply-To: <4E170C77019EDB75@smtp-in12.han.skanova.net> (added by postmaster@pne.skanova.net) X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 06:25:25 -0000 On 2011-08-19 23:17, Michael StJohns wrote: Michael, before jumping into the specifics you need to know what I'm into: "A universal on-line provisioning system running in browsers where the target keystore may reside in an external smart card, be embedded in (phone) hardware, or just be a part of the client platform OS" The issuers may be banks, governments, employers, etc. They want to maintain their security policies also over the Internet. Most important: the users (consumer/citizen/employee) are non-tech-savvy. > Hi Anders - Comments in line > > At 04:34 PM 8/19/2011, Anders Rundgren wrote: >> On 2011-08-19 21:55, Max Pritikin wrote: >> >>> I'm wondering if your underlying concern is how the CA server can determine >>> that the key is actually on the smartcard. Is this correct? Is this your concern? >> >> Well, my #1 concern is how you can create a smart card enrollment system that >> allows you to buy an empty card, insert it, go to a CA with a browser, authenticate (in >> some way) and then get certificates provisioned including things like issuer-defined >> PIN-codes etc. > > Generally, an empty card won't get you much. You have to load the card with the > appropriate applet or buy the card already provisioned with such applet > (e.g. the CAC or PIVII applet comes with a few different cards, there's also > coolkey and musclecard). > > Alternately, you can get a generic card understood by a token management system > that knows how to load the applet and provision the card - for something in > open source, see Dogtag - the open source version of the Red Hat PKI stuff. I know. How would this help EST and/or the platform vendors? >> As it appears you indeed need a smart card expert and tons of proprietary software. >> Existing middleware like PKCS #11 does not support on-line provisioning so basically >> the whole thing is toast unless you go far outside of the protocol. > > Strange - I've actually been able to use PKCS11 in conjunction with things like browsers > to do on-line provisioning. Me too. After having "formatted" and prepared PIN-codes etc. This has very little in common with a scheme for end-users who have no interest/knowledge in this tech. Anyway, PKCS #11 does not support end-to-end security for on-line provisioning so it is (from my perspective NB...) not even a candidate. > It really just depends on the protocol or interface you need > to use to talk to the card. Firefox for example let's you add PKCS11 drivers as security > modules to the browser. You can then use various tools to create keys and certs on the > card. For the open source play pen here I recommend Muscle and its assorted plugins > including the PKCS11 musclecard driver. See earlier comments. > Continuing on, there's a whole body of open standards on provisioning the > card with applets - check out www.globalplatform.org. GlobalPlatform have had EONs of time coming up with something like a universal driver, protocol, etc.; they have not. > To be honest, the hardest part is finding card vendors willing to sell in quantities > less than 1K. Most of them also requires you to sign NDAs as well which is why I had to turn to Open Hardware. I wasn't even allowed publishing my code!!! > And continuing on even further - there's always PKCS15. > > >> This is probably >> unacceptable to you and PKIX, which to some extent explains why there is a virtual >> army of companies writing smart card middleware [primarily] for governments. >> >> My take on this, is creating a complete system where all interfaces are defined: >> >> CA => Browser => Protocol => Middleware => Container > I'm really not convinced this is a PKIX issue. You are right, it has historically been delegated to the card industry. Having worked there myself I know the mantra: "Whatever we do, tokens must never be a commodity". But the truth is that PKI tokens are simple electronic devices that unlike disk drives exhibit a very variant set of interfaces, in spite of the fact that they all in the end do exactly the same thing! > It's possible that something like > the Java Card 3.0 Connected spec's might actually already fit most of the bill though. Java Card 3.0 was an attempt keeping prices up. The vision has failed and IMO the whole concept is wrong. I'm more into adding smart card capability to for example USB memory sticks which would only increase end-use price with $1. Mr. Obama's NSTIC program won't go 1 mm based on the current smart card tech since the private sector isn't interested in paying the $500 / seat that small government agencies typically have to pay to become smart card enabled. Another example of related (ridiculous) smart card tech: http://us.blackberry.com/ataglance/security/products/smartcardreader Currently banks in the EU and Asia create their own on-line provisioning software since the ones in current browsers doesn't meet their requirements. This was and still is my primary motivation. Anders From turners@ieca.com Mon Aug 22 05:51:46 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BA021F8B30 for ; Mon, 22 Aug 2011 05:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.958 X-Spam-Level: X-Spam-Status: No, score=-100.958 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiUlCUWvoAa3 for ; Mon, 22 Aug 2011 05:51:44 -0700 (PDT) Received: from nm14-vm0.bullet.mail.sp2.yahoo.com (nm14-vm0.bullet.mail.sp2.yahoo.com [98.139.91.246]) by ietfa.amsl.com (Postfix) with SMTP id 965AE21F8B29 for ; Mon, 22 Aug 2011 05:51:43 -0700 (PDT) Received: from [98.139.91.67] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 22 Aug 2011 12:52:48 -0000 Received: from [98.139.91.50] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 22 Aug 2011 12:52:48 -0000 Received: from [127.0.0.1] by omp1050.mail.sp2.yahoo.com with NNFMP; 22 Aug 2011 12:52:48 -0000 X-Yahoo-Newman-Id: 730185.63846.bm@omp1050.mail.sp2.yahoo.com Received: (qmail 37811 invoked from network); 22 Aug 2011 12:52:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314017568; bh=vyUn7TYgaUGQwXwm7+j0iCmAlVH9mR1l3yJXm+ywkJA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=TARvgMSD42pJ9SuaHRzxwJC8tY/LXjFGJoj2wTXqrkBnoyVYTbbs7G56Rrh1G158U0P8UFGHEsYfq3ggnVuMFozofdbKwblPT/BB4CEfxBq+yv3/OPlxb/Zy74z2fz7S63Qd+akc0o54t8iC2THmIhR9rfFG4Y7QL2a5zP+Qbtk= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9D4h6_4VM1l9HXhwcdVCuhA4YYjyArVui5WgGakO9OcDj5Y DAyPIoUfg9ZXLDE9VhlZA7juNm68shNDeALEGPn8el104upXNynMSjoFJNHD z9chPjLsZsyHVxAgxkwc8ua9BqLMbL8MF4tid9hd2YCrUDOjfGPOa6x36qfd uvdYCbC7NQh7NsQGLtp2tu6Jzs.xtT0Sg26rNvKslmMPX_pBDorODQxXjWFL jFNf80tigEGrSNXER7KWAhn_JzfMiw6J_qtdqZJWXliNcktEAu_DKKZUFrNP 9HnzdP1Y2wghXrBay0K4WqHhnQzgVOgOf2Hi5gZR0fIpfWp9gF7vmoxp5g6V MVOn20ll.AWCsgsmT0ld_Pf7jlgCOSZ8KKJYk1tb5ZxKFNNZeBqKLArZq2JD WcO8Ko.qwR3c8LLCPPzNwU_MC7O9r4mGJypft.3Uj X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.118.172 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 22 Aug 2011 05:52:48 -0700 PDT Message-ID: <4E52511F.6060408@ieca.com> Date: Mon, 22 Aug 2011 08:52:47 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] AD Review of draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:51:50 -0000 I think the -03 version is just about ready to go. That is I have no comments on the existing text though I expect getting it through the IESG will be interesting (Apps ADs love to discuss about anything to do with characters strings/sets). But, I think this draft needs to also address the issue of self-signed EE certificates. I know at least the DANE WG had a lengthy discussion about self-signed EE certificates, I see that Max's EST draft also includes them, and they're used in the wild. I want to see text included that addresses them. spt From paul.hoffman@vpnc.org Mon Aug 22 08:07:23 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C9421F85B9 for ; Mon, 22 Aug 2011 08:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoObmY7UeTiy for ; Mon, 22 Aug 2011 08:07:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 662CF21F85B5 for ; Mon, 22 Aug 2011 08:07:23 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7MF8QYw062046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Aug 2011 08:08:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4E52511F.6060408@ieca.com> Date: Mon, 22 Aug 2011 08:08:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8CC89B24-D7DE-4C7A-9DBF-CCAFC90A8D6E@vpnc.org> References: <4E52511F.6060408@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1244.3) Cc: pkix@ietf.org Subject: Re: [pkix] AD Review of draft-ietf-pkix-rfc5280-clarifications-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:07:24 -0000 On Aug 22, 2011, at 5:52 AM, Sean Turner wrote: > I think the -03 version is just about ready to go. That is I have no = comments on the existing text though I expect getting it through the = IESG will be interesting (Apps ADs love to discuss about anything to do = with characters strings/sets). But, I think this draft needs to also = address the issue of self-signed EE certificates. I know at least the = DANE WG had a lengthy discussion about self-signed EE certificates, I = see that Max's EST draft also includes them, and they're used in the = wild. I want to see text included that addresses them. +1. Given that this document already updates, not just clarifies, RFC = 5280, it would be a great place to state exactly how PKIX will handle = self-signed non-CA certificates in the future. David's terse writing = style will be an extra bonus here. Even if the above doesn't happen, the name of the document needs to be = changed from "Clarifications to..." to "Updates to..." since both of the = current sections are listed as updates, not clarifications. --Paul Hoffman From pritikin@cisco.com Mon Aug 22 13:57:55 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE5C21F8CA2 for ; Mon, 22 Aug 2011 13:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO69HDv1ru2i for ; Mon, 22 Aug 2011 13:57:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 357B421F8C7D for ; Mon, 22 Aug 2011 13:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=954; q=dns/txt; s=iport; t=1314046741; x=1315256341; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4D5CE8RXciRzIjt7f1evFI1466waT6+YO6TuG3rC1HI=; b=SSlg1OK7BOIvLod0AUWIur5xH6iZtBtMwF0z/i5shYT8v+Bi9vvErtWE H5x/84VK8cf1GciKn6gG8NSXoq5TK1N0bSZHTjfNAVeCfdu/YMv8ne25U 7hgTd+eZOxa4yj+lwoPklUi6VEvmYSXGqIPbOQHh4kP6jc14sIDDloAlA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFbCUk6rRDoI/2dsb2JhbABBqBV3gUABAQEBAgESASc/BQsLGC5XBjWHT5YuAZ8HhWlfBIdgizSRFg X-IronPort-AV: E=Sophos;i="4.68,265,1312156800"; d="scan'208";a="15444143" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 22 Aug 2011 20:59:00 +0000 Received: from sjc-vpn3-1406.cisco.com (sjc-vpn3-1406.cisco.com [10.21.69.126]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7MKx0Ps010471; Mon, 22 Aug 2011 20:59:00 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4E4F43CA.3090405@telia.com> Date: Mon, 22 Aug 2011 14:58:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> <4E4F43CA.3090405@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 20:57:56 -0000 Anders,=20 Previously I asked this question: I'm wondering if your underlying concern is how the CA server can = determine that the key is actually on the smartcard. Is this correct? Is = this your concern? =46rom your discussion I'm thinking this is the underlying protocol = issue you are concerned with, but you haven't confirmed it directly. Is = this the issue? - max=20 On Aug 19, 2011, at 11:19 PM, Anders Rundgren wrote: > On 2011-08-19 23:24, Max Pritikin wrote: > >>=20 >> Apparently I see the world like this: >>=20 >> EST Server (e.g. CA) =3D> EST protocol =3D> EST Client (e.g. Browser) = =3D> Smartcard >=20 > A problem with EST is that achieving *true end-to-end security* (which = IMO is > a prerequisite), seems to require that the crypto module/smart = card/etc runs > the entire protocol. >=20 > AFAICT, none of the "contenders" have such requirements. >=20 > >=20 > Anders >=20 From pritikin@cisco.com Mon Aug 22 14:01:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6E921F8634 for ; Mon, 22 Aug 2011 14:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oabKsFN3ZlTP for ; Mon, 22 Aug 2011 14:01:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 63D7921F85B8 for ; Mon, 22 Aug 2011 14:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=5856; q=dns/txt; s=iport; t=1314046961; x=1315256561; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PEo85XwHgELqVDCnnC6E6UqDyeG15mc6ZB0nmF+p8rw=; b=QeKvtTrkZdD1ZqHeaqKZ7wYninvukt+wMJyj+JOoyj/zwPlwGBjyxQ+V KXVhUu0qqhorG/j/FfZ5oieCdoLWGcIGIWqsNcFEonnj5RIQHONLa8MON aoHSn1/79uHyRbGI/yTFut5u5XATWdtoymOvKgmMyoG/WrmSA7DQiswwt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANLCUk6rRDoG/2dsb2JhbABBqBV3gUABAQEBAgESAScPIg4FCwsYLlcGNYdPBJYsAZ8IhWlfBIdgizSRFg X-IronPort-AV: E=Sophos;i="4.68,265,1312156800"; d="scan'208";a="15446972" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 22 Aug 2011 21:02:40 +0000 Received: from sjc-vpn3-1406.cisco.com (sjc-vpn3-1406.cisco.com [10.21.69.126]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7ML2ece022333; Mon, 22 Aug 2011 21:02:40 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4E4F5382.7030903@telia.com> Date: Mon, 22 Aug 2011 15:02:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <4E170C77019EDB75@smtp-in12.han.skanova.net> (added by postmaster@pne.skanova.net) <4E4F5382.7030903@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 21:01:37 -0000 Focusing on one thing you said inline, On Aug 20, 2011, at 12:26 AM, Anders Rundgren wrote: > On 2011-08-19 23:17, Michael StJohns wrote: >=20 > Michael, before jumping into the specifics you need to know what I'm = into: >=20 > "A universal on-line provisioning system running in browsers where > the target keystore may reside in an external smart card, be = embedded > in (phone) hardware, or just be a part of the client platform OS" >=20 > The issuers may be banks, governments, employers, etc. They want > to maintain their security policies also over the Internet. >=20 > Most important: the users (consumer/citizen/employee) are = non-tech-savvy. >=20 >> Hi Anders - Comments in line >>=20 >> At 04:34 PM 8/19/2011, Anders Rundgren wrote: >>> On 2011-08-19 21:55, Max Pritikin wrote: >>>=20 >>>> I'm wondering if your underlying concern is how the CA server can = determine >>>> that the key is actually on the smartcard. Is this correct? Is this = your concern? >>>=20 >>> Well, my #1 concern is how you can create a smart card enrollment = system that >>> allows you to buy an empty card, insert it, go to a CA with a = browser, authenticate (in >>> some way) and then get certificates provisioned including things = like issuer-defined >>> PIN-codes etc. >>=20 >> Generally, an empty card won't get you much. You have to load the = card with the >> appropriate applet or buy the card already provisioned with such = applet >> (e.g. the CAC or PIVII applet comes with a few different cards, = there's also >> coolkey and musclecard). >>=20 >> Alternately, you can get a generic card understood by a token = management system=20 >> that knows how to load the applet and provision the card - for = something in >> open source, see Dogtag - the open source version of the Red Hat PKI = stuff. >=20 > I know. How would this help EST and/or the platform vendors? >=20 >=20 >>> As it appears you indeed need a smart card expert and tons of = proprietary software. >>> Existing middleware like PKCS #11 does not support on-line = provisioning so basically >>> the whole thing is toast unless you go far outside of the protocol. =20= >>=20 >> Strange - I've actually been able to use PKCS11 in conjunction with = things like browsers=20 >> to do on-line provisioning. >=20 > Me too. After having "formatted" and prepared PIN-codes etc. This has = very little > in common with a scheme for end-users who have no interest/knowledge = in this tech. >=20 > Anyway, PKCS #11 does not support end-to-end security for on-line = provisioning so > it is (from my perspective NB...) not even a candidate. By 'end-to-end' security do you mean that the server in the protocol = exchange can determine that the key's being enrolled exist on the = smartcard rather than within the OS? - max > It really just depends on the protocol or interface you need >> to use to talk to the card. Firefox for example let's you add PKCS11 = drivers as security=20 >> modules to the browser. You can then use various tools to create = keys and certs on the >> card. For the open source play pen here I recommend Muscle and its = assorted plugins >> including the PKCS11 musclecard driver. >=20 > See earlier comments. >=20 >=20 >> Continuing on, there's a whole body of open standards on provisioning = the=20 >> card with applets - check out www.globalplatform.org. >=20 > GlobalPlatform have had EONs of time coming up with something like a = universal > driver, protocol, etc.; they have not. >=20 >=20 >> To be honest, the hardest part is finding card vendors willing to = sell in quantities >> less than 1K. >=20 > Most of them also requires you to sign NDAs as well which is why I had = to turn to > Open Hardware. I wasn't even allowed publishing my code!!! >=20 >=20 >> And continuing on even further - there's always PKCS15. >>=20 >>=20 >>> This is probably >>> unacceptable to you and PKIX, which to some extent explains why = there is a virtual >>> army of companies writing smart card middleware [primarily] for = governments. >>>=20 >>> My take on this, is creating a complete system where all interfaces = are defined: >>>=20 >>> CA =3D> Browser =3D> Protocol =3D> Middleware =3D> = Container >=20 >=20 >> I'm really not convinced this is a PKIX issue. >=20 > You are right, it has historically been delegated to the card = industry. >=20 > Having worked there myself I know the mantra: "Whatever we do, tokens > must never be a commodity". >=20 > But the truth is that PKI tokens are simple electronic devices that > unlike disk drives exhibit a very variant set of interfaces, in spite > of the fact that they all in the end do exactly the same thing! >=20 >=20 >> It's possible that something like=20 >> the Java Card 3.0 Connected spec's might actually already fit most of = the bill though. >=20 > Java Card 3.0 was an attempt keeping prices up. The vision has failed > and IMO the whole concept is wrong. >=20 > I'm more into adding smart card capability to for example USB memory > sticks which would only increase end-use price with $1. >=20 > Mr. Obama's NSTIC program won't go 1 mm based on the current smart = card tech > since the private sector isn't interested in paying the $500 / seat = that small > government agencies typically have to pay to become smart card = enabled. >=20 > Another example of related (ridiculous) smart card tech: > http://us.blackberry.com/ataglance/security/products/smartcardreader >=20 >=20 > Currently banks in the EU and Asia create their own on-line = provisioning > software since the ones in current browsers doesn't meet their = requirements. > This was and still is my primary motivation. >=20 >=20 > Anders From tmiller@mitre.org Tue Aug 23 05:34:02 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C331121F85B9 for ; Tue, 23 Aug 2011 05:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItIKYP+zrw7S for ; Tue, 23 Aug 2011 05:34:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB5921F85AB for ; Tue, 23 Aug 2011 05:34:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5B44C21B0894; Tue, 23 Aug 2011 08:35:09 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 55D7E21B0460; Tue, 23 Aug 2011 08:35:09 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 23 Aug 2011 08:35:09 -0400 From: "Miller, Timothy J." To: Max Pritikin Date: Tue, 23 Aug 2011 08:35:07 -0400 Thread-Topic: [pkix] EST-02 smart card question Thread-Index: AcxhkRgFoLaf2Td+RTm3IQjjHPBBxQ== Message-ID: <89112AFD-24F3-4CBC-997C-1E2C20FFC406@mitre.org> References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> <4E4F43CA.3090405@telia.com> <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> In-Reply-To: <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-3-788258426"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:34:02 -0000 --Apple-Mail-3-788258426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 22, 2011, at 3:58 PM, Max Pritikin wrote: > I'm wondering if your underlying concern is how the CA server can = determine that the key is actually on the smartcard. Is this correct? Is = this your concern? Based on previous discussions with Anders and my own cursory review of = Keygen2, that is indeed a core concern of his. It's a valid concern, = but IMHO there's no solution without a prearranged exchange of keys = (i.e., exactly what a TMS does). The protocol is important for fungibility of devices, but without an = out-of-band enrollment ceremony, no attestation arrangement really = carries any meaning. -- T --Apple-Mail-3-788258426 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA4MjMxMjM1MDdaMCMGCSqGSIb3DQEJBDEWBBRmpGjppSQt9N0W8/Sv YLEM2GgjTzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgFLH1TQg4pE2eGWF/+4uErkXlVHRh6SGf98o R29hGck8vt8/c+bMKHU0ENBvZw9vRUNC/Kh8FizTMPgMroEZgn8oKgJSSiUO0GN9z1ilvcJd4GZD MdGhA/C1nO22IUrrdsozNmAn2Zi4rsKGy8r6zFvhDBZ/nFqkI2A/eL3ZPPlhAAAAAAAA --Apple-Mail-3-788258426-- From pritikin@cisco.com Tue Aug 23 11:20:23 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C668821F8BF6 for ; Tue, 23 Aug 2011 11:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9LKQLc+KnB9 for ; Tue, 23 Aug 2011 11:20:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E72E521F8BEF for ; Tue, 23 Aug 2011 11:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=5433; q=dns/txt; s=iport; t=1314123691; x=1315333291; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YuyQMftkEFyh1wFk/jwDuaYNTTf4eyDd2T1qRTC/PW8=; b=KdADWblvjg9iyLJwRGImhzWGZEjNQh7x/1xhRCGZbImCMJrNrzT0v8rD nX2ToxRWDKawfceI+KhDwYe4Do+SUjMstPZ7Phc5mskAEkWJ5wOGUwlGn QcSIHTOU9H8AY9BIR1n6N/gjDbpv0+zQFsVpJ+SYVr+SsC4QyE4piHwkt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHXvU06rRDoJ/2dsb2JhbABCp2R3gUABAQEBAgESASctEgULCxguVwYBLQeHT51pAZ9chWlfBIdhiziRGQ X-IronPort-AV: E=Sophos;i="4.68,270,1312156800"; d="scan'208";a="15780472" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 23 Aug 2011 18:21:30 +0000 Received: from sjc-vpn4-925.cisco.com (sjc-vpn4-925.cisco.com [10.21.83.156]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7NILTDA028349; Tue, 23 Aug 2011 18:21:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <89112AFD-24F3-4CBC-997C-1E2C20FFC406@mitre.org> Date: Tue, 23 Aug 2011 12:21:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> <4E4F43CA.3090405@telia.com> <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> <89112AFD-24F3-4CBC-997C-1E2C20FFC406@mitre.org> To: "Miller, Timothy J." , Anders Rundgren X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:20:23 -0000 On Aug 23, 2011, at 6:35 AM, Miller, Timothy J. wrote: > On Aug 22, 2011, at 3:58 PM, Max Pritikin wrote: >=20 >> I'm wondering if your underlying concern is how the CA server can = determine that the key is actually on the smartcard. Is this correct? Is = this your concern? >=20 > Based on previous discussions with Anders and my own cursory review of = Keygen2, that is indeed a core concern of his. It's a valid concern, = but IMHO there's no solution without a prearranged exchange of keys = (i.e., exactly what a TMS does). >=20 > The protocol is important for fungibility of devices, but without an = out-of-band enrollment ceremony, no attestation arrangement really = carries any meaning. >=20 > -- T >=20 Ok then. I think we can agree this is an interesting concern. I don't = think any of our current approaches addresses this issue. Below I lay = out my thoughts and then provide stream-of-thought discussion of how I = might approach solving this.=20 [How we fail to solve this today:] I don't see that Keygen2 or an out-of-band enrollment ceremony solves = this problem. Lets use my simple diagram of the elements: Server (e.g. CA) =3D> protocol =3D> Client (e.g. OS/Software/Browser) =3D>= Smartcard In an out-of-band-enrollment ceremony the User interfaces with the = Browser or OS/Software/Browser and provides the out-of-band information = such as symmetric keys or key hashes or whatnot. Since the = OS/Software/Browser now knows all this data it can present any of it to = the Server in any form and thus the server=20 CAN NOT determine if the Smartcard is where the keys are stored. Unless = the device prevents unauthorized software this doesn't buy us any = assurance of where the keys are stored.=20 Similarly for KeyGen2. The client's response is signed by the "private = key which only the client has access to" (see slide 8 of KeyGen2 Short = Presentation) but there is nothing specifically enforcing that this = client key is stored within a specific container (that I see in the = docs). Again, unless the device prevents unauthorized software this = doesn't buy us any assurance of where the keys are stored. Ander's stated in his off list reply: "That is, the CA recognizes [device] containers based on the device certificate. The [device] implementation makes the CA know that the key is in the [device]. There is no need for pre-arranged keys; either you trust [the manufacturer] or you = don't." Which is also an accurate description of the EST model described for = requirement A3 (see section 2) wherein "this capability allows a client = who has a certificate issued by a 3rd party, such as a certificate = issued by a device manufacturer, to leverage that credential during = initial enrollment" to perform exactly what Ander's is talking about.=20 What is harder to solve is a situation where the device manufacturer = does not provide a wall garden and where the OS/Software/Browser = installed on a device might _not_ also be trusted. In other words: Where = the Device and the smartcard are considered independent. We'd need to = ensure that the Smartcard does something in the protocol exchange that = that OS/Software/Browser couldn't itself do. And because all user input = to the smartcard are through these software components this means = out-of-band exchanges are out so lets focus on manufacturing installed = credentials within the smartcard. [Thinking about how we might solve it:]=20 (ok, this is weak. I'm just getting the point across).=20 1. Assume the smartcard has a manufacturing installed credential. 2. Assume the smartcard has a general purpose interface for leveraging = any contained keys. Something like: Sign_this_digestInfo (keyindex, externallycomputeddigest); 3. Obviously the OS/Software/Browser can use this interface to implement = the RSA-SHA1 etc.=20 The OS/Software/Browser can leverage these keys such that the = Server can't tell if it is the smartcard or the general device. 4. What we need is a signature method that is NOT ACCESSIBLE from the = interface. For example if the above "Sign_this_digestinfo" interface REFUSED to = sign the SHA1 hash of the public key then we'd know that particular = signature could only be generated by the smartcard via some other = interface. For example if the interface included an extra function like: Generate_a_CSR_with_extensionX (keyindex) Where "extensionX" is a signature of the public key of exactly the form = not accessible by the generic interface. That would allow the CA to determine that for a given smartcard = containing a manufacturer installed credential if "extensionX" is = included in the CSR then the request refers to a keypair the smartcard = contains internally (and that the smartcard generated the CSR via the = alternate interface).=20 This would require the following: A) An independent RFC defining this extension within the CSR B) A Protocol Implementation Conformance Statement type document = for the device (e.g. out of scope) C) The exact same protocol methods we use today Such a solution seems possible but is not, to my mind, something we'd = address in the enrollment protocol. Rather it would be a distinct = document extending the CSR. I'm only thinking out loud and won't be offended if somebody points out = a gap in my logic, - max From anders.rundgren@telia.com Tue Aug 23 11:44:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4036021F8C3F for ; Tue, 23 Aug 2011 11:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvKV8RnDqnDd for ; Tue, 23 Aug 2011 11:44:07 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA2121F8C26 for ; Tue, 23 Aug 2011 11:44:07 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E52661200090B21; Tue, 23 Aug 2011 20:45:10 +0200 Message-ID: <4E53F527.50308@telia.com> Date: Tue, 23 Aug 2011 20:44:55 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Max Pritikin References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> <4E4F43CA.3090405@telia.com> <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> In-Reply-To: <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:44:08 -0000 On 2011-08-22 22:58, Max Pritikin wrote: > Previously I asked this question: > I'm wondering if your underlying concern is how the CA server > can determine that the key is actually on the smartcard. > Is this correct? Is this your concern? Indeed it is, but I prefer describing it in another way: Although people involved in USG security tend to claim that "this will never happen", I believe that pure economics, convenience and "coolness" will make virtualized PIV and CAC credentials in mobile devices enrolled in *self-service* processes using your original card as "bootstrap", the norm. However, this can only be realized if the self-enrolled credentials are stored in containers that exhibit (and can *securely attest* during enrollment), the same technical strength (like FIPS 140 certification) as the original. For more details regarding the process see [1]. Exactly the same considerations apply to virtualized EMV and SIM cards. During the design of KeyGen2/SKS [2], I found the E2ES-mechanism in GlobalPlatform quite powerful and decided "borrowing" the concept. In fact, it had several uses beyond what GP exploits, like a fully transaction-based provisioning process. Transactions are IMO fundamental for achieving the robustness required by a BILLION-headed mainly non-tech-savvy user-base. The only question that worried me was how this would affect systems where E2ES isn't possible or required. The PoC showed that this was a no-issue; "soft tokens" or firmware keystores can use exactly the same API protocol and with zero drawbacks since the additional crypto container code is close to trivial. Nope, there are no cards out there that supports this API and protocol. I consider that a minor "snag" :-) Browsers and operating systems are much more important than cards and can therefore "dictate" how tokens should be designed! I can't imagine that Google or Mozilla would be interested in qualifying a gazillion cards and drivers that differ for no valid reasons at all except for supporting vendor lock-in. One Protocol, One API, One Middleware Driver/Platform, and One set of Test Suites begin to look like a rather simple project actually :-) Regards, Anders [1] http://www.ietf.org/mail-archive/web/pkix/current/msg29490.html [2] http://webpki.org/auth-token-4-the-cloud.html From anders.rundgren@telia.com Tue Aug 23 12:28:39 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B2621F8C20 for ; Tue, 23 Aug 2011 12:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjjGE3Et3kM3 for ; Tue, 23 Aug 2011 12:28:38 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id F140421F8B8E for ; Tue, 23 Aug 2011 12:28:37 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E52661200095655; Tue, 23 Aug 2011 21:29:41 +0200 Message-ID: <4E53FF96.3000403@telia.com> Date: Tue, 23 Aug 2011 21:29:26 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Max Pritikin References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> <4E4F43CA.3090405@telia.com> <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> <89112AFD-24F3-4CBC-997C-1E2C20FFC406@mitre.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:28:39 -0000 Max, I'm sorry that I have mislead you by not deleting my 2008 KeyGen2 short presentation. Early 2009 I did a complete rethink and designed a system based on sessions which are very much like a dedicated TLS. An early reviewer asked : Why don't you use TLS? Because it is much smarter using a proxy for the "heavy lifting" and keeping the container simple. In addition, TLS client-certificate-authentication with the container as "end-point" is incompatible with user interaction. If you read the core document http://webpki.org/papers/keygen2/sks-api-arch.pdf you will see that the attestation key has no use except for creating provisioning sessions. Otherwise it would indeed be easy to trick this system. Note: ETSI did the ground-work. I just made it useful :-) by throwing out 20Y+ old ISO-7816 standards. Anders On 2011-08-23 20:21, Max Pritikin wrote: > On Aug 23, 2011, at 6:35 AM, Miller, Timothy J. wrote: > >> On Aug 22, 2011, at 3:58 PM, Max Pritikin wrote: >> >>> I'm wondering if your underlying concern is how the CA server can determine that the key is actually on the smartcard. Is this correct? Is this your concern? >> >> Based on previous discussions with Anders and my own cursory review of Keygen2, that is indeed a core concern of his. It's a valid concern, but IMHO there's no solution without a prearranged exchange of keys (i.e., exactly what a TMS does). >> >> The protocol is important for fungibility of devices, but without an out-of-band enrollment ceremony, no attestation arrangement really carries any meaning. >> >> -- T >> > > > Ok then. I think we can agree this is an interesting concern. I don't think any of our current approaches addresses this issue. Below I lay out my thoughts and then provide stream-of-thought discussion of how I might approach solving this. > > [How we fail to solve this today:] > > I don't see that Keygen2 or an out-of-band enrollment ceremony solves this problem. Lets use my simple diagram of the elements: > Server (e.g. CA) => protocol => Client (e.g. OS/Software/Browser) => Smartcard > > In an out-of-band-enrollment ceremony the User interfaces with the Browser or OS/Software/Browser and provides the out-of-band information such as symmetric keys or key hashes or whatnot. Since the OS/Software/Browser now knows all this data it can present any of it to the Server in any form and thus the server > CAN NOT determine if the Smartcard is where the keys are stored. Unless the device prevents unauthorized software this doesn't buy us any assurance of where the keys are stored. > > Similarly for KeyGen2. The client's response is signed by the "private key which only the client has access to" (see slide 8 of KeyGen2 Short Presentation) but there is nothing specifically enforcing that this client key is stored within a specific container (that I see in the docs). Again, unless the device prevents unauthorized software this doesn't buy us any assurance of where the keys are stored. > > Ander's stated in his off list reply: > "That is, the CA recognizes [device] containers based on the > device certificate. The [device] implementation makes > the CA know that the key is in the [device]. There is no need > for pre-arranged keys; either you trust [the manufacturer] or you don't." > > Which is also an accurate description of the EST model described for requirement A3 (see section 2) wherein "this capability allows a client who has a certificate issued by a 3rd party, such as a certificate issued by a device manufacturer, to leverage that credential during initial enrollment" to perform exactly what Ander's is talking about. > > What is harder to solve is a situation where the device manufacturer does not provide a wall garden and where the OS/Software/Browser installed on a device might _not_ also be trusted. In other words: Where the Device and the smartcard are considered independent. We'd need to ensure that the Smartcard does something in the protocol exchange that that OS/Software/Browser couldn't itself do. And because all user input to the smartcard are through these software components this means out-of-band exchanges are out so lets focus on manufacturing installed credentials within the smartcard. > > [Thinking about how we might solve it:] > > (ok, this is weak. I'm just getting the point across). > > 1. Assume the smartcard has a manufacturing installed credential. > 2. Assume the smartcard has a general purpose interface for leveraging any contained keys. Something like: > Sign_this_digestInfo (keyindex, externallycomputeddigest); > 3. Obviously the OS/Software/Browser can use this interface to implement the RSA-SHA1 etc. > The OS/Software/Browser can leverage these keys such that the Server can't tell if it is the smartcard or the general device. > 4. What we need is a signature method that is NOT ACCESSIBLE from the interface. > > For example if the above "Sign_this_digestinfo" interface REFUSED to sign the SHA1 hash of the public key then we'd know that particular signature could only be generated by the smartcard via some other interface. For example if the interface included an extra function like: > Generate_a_CSR_with_extensionX (keyindex) > Where "extensionX" is a signature of the public key of exactly the form not accessible by the generic interface. > > That would allow the CA to determine that for a given smartcard containing a manufacturer installed credential if "extensionX" is included in the CSR then the request refers to a keypair the smartcard contains internally (and that the smartcard generated the CSR via the alternate interface). > > This would require the following: > A) An independent RFC defining this extension within the CSR > B) A Protocol Implementation Conformance Statement type document for the device (e.g. out of scope) > C) The exact same protocol methods we use today > > Such a solution seems possible but is not, to my mind, something we'd address in the enrollment protocol. Rather it would be a distinct document extending the CSR. > I'm only thinking out loud and won't be offended if somebody points out a gap in my logic, > > - max > > > From kent@bbn.com Tue Aug 23 13:42:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A6F21F8CAF for ; Tue, 23 Aug 2011 13:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.608 X-Spam-Level: X-Spam-Status: No, score=-106.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy6g6njXaicA for ; Tue, 23 Aug 2011 13:42:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id ECC5821F8CAB for ; Tue, 23 Aug 2011 13:42:36 -0700 (PDT) Received: from dhcp89-089-129.bbn.com ([128.89.89.129]:49206) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qvxp2-000L8p-Ff; Tue, 23 Aug 2011 16:43:44 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E53F527.50308@telia.com> References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> <4E4F43CA.3090405@telia.com> <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> <4E53F527.50308@telia.com> Date: Tue, 23 Aug 2011 16:40:16 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:42:37 -0000 At 8:44 PM +0200 8/23/11, Anders Rundgren wrote: >On 2011-08-22 22:58, Max Pritikin wrote: > >> Previously I asked this question: >> I'm wondering if your underlying concern is how the CA server >> can determine that the key is actually on the smartcard. >> Is this correct? Is this your concern? > >Indeed it is, but I prefer describing it in another way: > >Although people involved in USG security tend to claim that >"this will never happen", I believe that pure economics, >convenience and "coolness" will make virtualized PIV and CAC >credentials in mobile devices enrolled in *self-service* >processes using your original card as "bootstrap", the norm. The CAC and PIVs have approval processes associated with accreditation of devices. So, unless the cognizant gov agencies decide that market forces are more important than security concerns, virtualization is unlikely to occur. In the commercial sector, where cost considerations always trump secruity, ... Steve From anders.rundgren@telia.com Tue Aug 23 14:45:29 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E46021F8CC3 for ; Tue, 23 Aug 2011 14:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, GB_AFFORDABLE=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiQ-ubt6GlKO for ; Tue, 23 Aug 2011 14:45:28 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCC021F8CBA for ; Tue, 23 Aug 2011 14:45:28 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E97008439A0; Tue, 23 Aug 2011 23:46:31 +0200 Message-ID: <4E541FA9.4040603@telia.com> Date: Tue, 23 Aug 2011 23:46:17 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Stephen Kent References: <4E4E05AA.2090105@telia.com> <4E4EB362.5090903@telia.com> <9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com> <4E4EC8D5.3040108@telia.com> <3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com> <4E4F43CA.3090405@telia.com> <535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com> <4E53F527.50308@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:45:29 -0000 On 2011-08-23 22:40, Stephen Kent wrote: > At 8:44 PM +0200 8/23/11, Anders Rundgren wrote: >> On 2011-08-22 22:58, Max Pritikin wrote: >> >>> Previously I asked this question: >>> I'm wondering if your underlying concern is how the CA server >>> can determine that the key is actually on the smartcard. >>> Is this correct? Is this your concern? >> >> Indeed it is, but I prefer describing it in another way: >> >> Although people involved in USG security tend to claim that >> "this will never happen", I believe that pure economics, >> convenience and "coolness" will make virtualized PIV and CAC >> credentials in mobile devices enrolled in *self-service* >> processes using your original card as "bootstrap", the norm. > > The CAC and PIVs have approval processes associated with accreditation > of devices. So, unless the cognizant gov agencies decide that market > forces are more important than security concerns, virtualization is > unlikely to occur. I'm pretty sure that Google, Apple and Microsoft together with silicon vendors (one day) will receive the necessary certification. Waiting for that moment to arrive before taking action is essentially what the industry has done to date. It was a baaaaaaaaaaaaaad idea :-) > In the commercial sector, where cost considerations always trump > secruity, ... That's true, they don't generally buy into the "at any cost" thing, they'd rather wait until something affordable and useful comes around. That's essentially what all this fuzz is about. http://us.blackberry.com/ataglance/security/products/smartcardreader R.I.P. Regards, Anders From pgut001@login01.cs.auckland.ac.nz Tue Aug 23 19:55:06 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF0921F8ABE for ; Tue, 23 Aug 2011 19:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWZwGXf9zl8X for ; Tue, 23 Aug 2011 19:55:05 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 506EF21F8A4F for ; Tue, 23 Aug 2011 19:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1314154575; x=1345690575; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20pritikin@cisco.com |Subject:=20Re:=20[pkix]=20EST-02=20smart=20card=20questi on|Cc:=20pkix@ietf.org|In-Reply-To:=20<4E53F527.50308@tel ia.com>|Message-Id:=20|Date:=20Wed,=2024=20Aug=202011=2014:56:11=20+ 1200; bh=UhHAdsSEKRkZU0Si5DxIGz7ccFfies+Wrpm4FpU4BT8=; b=KHa4AInGj5Q6W9CUEfpKhyQoBG38Sf/g5iO9gZ4Ogvqs7XGZ+dIChMVN IkwpPh9fl6scsdq07d0CAVtZcYSxUuExvDFYJbSPU9XokiQiLKIn+3p54 18aibL/iExL2caU1ATdcupNWYzGztft82g7Mt/qjTkJTBioUUps53yAZy 8=; X-IronPort-AV: E=Sophos;i="4.68,273,1312113600"; d="scan'208";a="79967797" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Aug 2011 14:56:11 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qw3dT-0004dZ-Gt; Wed, 24 Aug 2011 14:56:11 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qw3dT-0000Rf-4p; Wed, 24 Aug 2011 14:56:11 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, pritikin@cisco.com In-Reply-To: <4E53F527.50308@telia.com> Message-Id: Date: Wed, 24 Aug 2011 14:56:11 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 02:55:06 -0000 Max Pritikin writes: >Although people involved in USG security tend to claim that "this will never >happen", I believe that pure economics, convenience and "coolness" will make >virtualized PIV and CAC credentials in mobile devices enrolled in *self- >service* processes using your original card as "bootstrap", the norm. It's actually already happened, several years ago. See "Remote Desktop Protocol: Smart Card Virtual Channel Extension", Microsoft Corporation, 7 February 2008. So the key is still in the smart card, but the smart card may be on the other side of the planet. This pretty much epitomises the problem with smart cards, having the key locked into a device that does anything an untrusted remote system tells it to is little better than having the key on the untrusted system. Peter. From pgut001@login01.cs.auckland.ac.nz Tue Aug 23 19:59:48 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA3521F8B84 for ; Tue, 23 Aug 2011 19:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8yXWiN8CyKK for ; Tue, 23 Aug 2011 19:59:47 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 99E9C21F8B5C for ; Tue, 23 Aug 2011 19:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1314154857; x=1345690857; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20kent@bbn.com|Subject: =20Re:=20[pkix]=20EST-02=20smart=20card=20question|Cc:=20 pkix@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2024=20Aug=202011=2015:00:56 =20+1200; bh=qvypa7+HUrilNt9Nfgx8TFflm95dZwfuUtyHW1p3hyg=; b=DhJ+OPBe7svV8/ktinVfVCqXOX+Udu0WQdYMalTgNWhxrcQwxeaYhH9D HZtkIXrsb/VyytYTP4ec29MEJjsp88Z+wKVSQG7/8jzrsXlFgx8Pqu41w /WN8q+eMe4CxCazekYRfKS9/Qrot9uzBfJSng4TsiSuJ92wWhXlsWpAho U=; X-IronPort-AV: E=Sophos;i="4.68,273,1312113600"; d="scan'208";a="79969363" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Aug 2011 15:00:56 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qw3i4-0004oI-HM; Wed, 24 Aug 2011 15:00:56 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qw3i4-0001T6-B5; Wed, 24 Aug 2011 15:00:56 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, kent@bbn.com In-Reply-To: Message-Id: Date: Wed, 24 Aug 2011 15:00:56 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 02:59:48 -0000 Stephen Kent writes: >The CAC and PIVs have approval processes associated with accreditation of >devices. So, unless the cognizant gov agencies decide that market forces are >more important than security concerns, virtualization is unlikely to occur. See my previous post, it already has, several years ago (unless the RDP smart card virtualisation detects when it's talking to a CAC and refuses to proxy it, which seems unlikely). Peter. From anders.rundgren@telia.com Wed Aug 24 03:16:23 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6FF21F8620 for ; Wed, 24 Aug 2011 03:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsXC6E-8IMBU for ; Wed, 24 Aug 2011 03:16:22 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8365121F85CE for ; Wed, 24 Aug 2011 03:16:22 -0700 (PDT) Received: from [192.168.3.119] (193.12.106.2) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F00DF0ECD; Wed, 24 Aug 2011 12:17:26 +0200 Message-ID: <4E54CFB5.1030802@telia.com> Date: Wed, 24 Aug 2011 12:17:25 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 10:16:23 -0000 On 2011-08-24 05:00, Peter Gutmann wrote: > Stephen Kent writes: > >> The CAC and PIVs have approval processes associated with accreditation of >> devices. So, unless the cognizant gov agencies decide that market forces are >> more important than security concerns, virtualization is unlikely to occur. > > See my previous post, it already has, several years ago (unless the RDP smart > card virtualisation detects when it's talking to a CAC and refuses to proxy > it, which seems unlikely). You are of course perfectly right about that. However, the situation where you provide the key container and the issuer provides the key, is a step further away on this path and will take some time to get general acceptance. But first it must be *implemented* otherwise we have nothing to argue about :-) Anders From DPKemp@missi.ncsc.mil Wed Aug 24 05:52:08 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5321F8AB0 for ; Wed, 24 Aug 2011 05:52:07 -0700 (PDT) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPrwRr8ejOoK for ; Wed, 24 Aug 2011 05:52:04 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1314190327-20935-2" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5E77A21F8801 for ; Wed, 24 Aug 2011 05:51:51 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p7OCqwgf049655 for ; Wed, 24 Aug 2011 08:53:01 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 08:53:14 -0400 Date: Wed, 24 Aug 2011 08:52:58 -0400 Message-ID: In-Reply-To: References: <4E4E05AA.2090105@telia.com><4E4EB362.5090903@telia.com><9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com><4E4EC8D5.3040108@telia.com><3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com><4E4F43CA.3090405@telia.com><535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com><4E53F527.50308@telia.com> From: "Kemp, David P." To: Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:52:09 -0000 This is a multi-part message in MIME format... ------------=_1314190327-20935-2 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1314190327-20935-2 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5E77A21F8801 for ; Wed, 24 Aug 2011 05:51:51 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p7OCqwgf049655 for ; Wed, 24 Aug 2011 08:53:01 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 08:53:14 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC625C.C056BC95" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [pkix] EST-02 smart card question Date: Wed, 24 Aug 2011 08:52:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] EST-02 smart card question Thread-Index: Acxh1WJudQtUx/g6S+mbhHbMtJ97PQAgKL9Q References: <4E4E05AA.2090105@telia.com><4E4EB362.5090903@telia.com><9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco.com><4E4EC8D5.3040108@telia.com><3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisco.com><4E4F43CA.3090405@telia.com><535B5D0D-DB60-49C7-97E6-6F3EBD120857@cisco.com><4E53F527.50308@telia.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 24 Aug 2011 12:53:14.0015 (UTC) FILETIME=[C944E2F0:01CC625C] This is a multi-part message in MIME format. ------_=_NextPart_001_01CC625C.C056BC95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note: I apologize in advance if somebody's firewall turns this text message into a "banned attachment". >From: Stephen Kent >>At 8:44 PM +0200 8/23/11, Anders Rundgren wrote: >> >> Although people involved in USG security tend to claim that >> "this will never happen", I believe that pure economics, >> convenience and "coolness" will make virtualized PIV and CAC >> credentials in mobile devices enrolled in *self-service* >> processes using your original card as "bootstrap", the norm. > > The CAC and PIVs have approval processes associated with > accreditation of devices. So, unless the cognizant gov > agencies decide that market forces are more important > than security concerns, virtualization is unlikely to occur. Steve, The USG is not immune to market forces :-). Technologies such as TI's OMAP make it conceivable that mobile devices could one day provide "approvable" security. While critical applications will always require certified devices, we are attempting to define a "commercial solutions for classified" process to support accreditation of systems that employ multiple layers of approved commercial protection. Our mobility architecture includes a two-stage provisioning process - central provisioning provides a hands-on enrollment ceremony to load approved firmware, configurations and device keys, and field provisioning personalizes a fungible device into its user-specific and usable state. Given appropriate protocols and systems, it appears possible for the user to personalize a device to a CAC at an unattended kiosk (e.g., a controlled client/browser), though probably not through an uncontrolled client/browser. Dave ------_=_NextPart_001_01CC625C.C056BC95 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjwMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAJgAAAFJFOiBbcGtpeF0gRVNULTAy IHNtYXJ0IGNhcmQgcXVlc3Rpb24AmQwBBYADAA4AAADbBwgAGAAIADQAOgADAHsBASCAAwAOAAAA 2wcIABgACAA0ADsAAwB8AQEJgAEAIQAAAEQxNEE1N0I2NDk0QURBNDRCMDJEQjMxOTkzM0NCM0FE AEAHAQOQBgDgDgAARgAAAAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMALgAAAAAAAwA2AAAAAABA ADkAoCi9v1xizAEeAD0AAQAAAAUAAABSRTogAAAAAAIBRwABAAAAMwAAAGM9VVM7YT0gO3A9RXhj aGFuZ2VOU0E7bD1EQUJFQ0stMTEwODI0MTI1MjU5Wi05NjczAAAeAHAAAQAAACIAAABbcGtpeF0g RVNULTAyIHNtYXJ0IGNhcmQgcXVlc3Rpb24AAAACAXEAAQAAABsAAAABzGHVYm51C1TH+DpL6ZuE dsy0n3s9ACAov1AAHgAaDAEAAAAPAAAAS2VtcCwgRGF2aWQgUC4AAB4AHQ4BAAAAIgAAAFtwa2l4 XSBFU1QtMDIgc21hcnQgY2FyZCBxdWVzdGlvbgAAAAIBCRABAAAAXwUAAFsFAADvBwAATFpGdQVm CaADAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBj aOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUHMLCQFkMzYWUAumB7Bv gQ6wOiBJIGFwF6FgZ2l6ZSALgB1gZIp2AHBjHfFmIHMDcCJlBuBkeScEIGZpbRggdwdAAyB0CHAG MXQeaAQAICAOwgeBc2FniR3ydG8dYCAiYgBw3m4JgB1gAkAA0GgHgAIwnCIuCqIKhAqAPkYDYSUd MFMOsHBoCfAgSxMjESPFPkEFQDg6NIA0IFBNICswAdABFlA4LzIzLzExmiwQwG4EgQQgUnUngPsJ wQOgdwNgHRElViVWEMAGbCCQCGBnaCBwZdZvC1Ad8nYG8HYicR4ROFVTRx7gBZAIcXR5ryDRJ4Ag ICHgYwthbSCB+yKgKVciIJMD8CABImArMMsFwBPgcCpwbiInUB1Q+GJlbAiQKzAtQypgCHCbHfAF kW4DcA3gcywpV38xESswAwAJ8B6RAHAigCJvBaAG8CJgBBAiLnQAwGt9HfB2H7AgMAdAHdEigFDE SVYy40NBQzGoGCHfIxEHMQQgHhEEYGIDEB3w/wEANIAekAQgCfADYCAAK0SiKhQQbGYtFBByOAJ6 KilXcANgOCEUEAQgdaEAkG5nIHkIYSAFsPppHcBuB0As4AsRHWAEIMMiIDNQdHN0ch1wL5FnIJAd 8DEwcm0jVSlGIP5UPdE1wTLjNUEEIBPgMDF/L0EDYB5gAyA6mDzAHvBj/wcwDrAigAPwIJA+xgDQ NoJ7LDAioGkCIDvQHtA35S79BgBvJ1An8CqwBBE9wgWg2mcDAHoAcAVAZ0DgQsffIYAegAiQBCAF gWkBADBU3QDAcjRQBUACEHI4IgrA/x3wBGAw0QdwHYAAIEYxPsb/LVEDoCvnMREekCBRJ1A0h9dD xCCxRSFpNFBsLFEh4P86sCwBI1skkSswMZUjZD9C3yuiILExMAVAB3BtJ/AwQeMh4Eh8Oi0pRMA/ MAWQ7mgxMB2iB5FzGtAqUDzBhFRJH3FPTUFQNCT7LDBLxGkeYAJgSAY3jAWg3HVsIoACIDfBYSxQ QMJ9R+IiQKVWUTPAK+ZEwFf/IKAqsQUBNuA8cAMgL0EwAN88cEPSLmUHQB/geQQgGCD8cXUfsSzg BJA24B+gInG7N+UnUHcy0TDRIqFlSfD/NuA7YSHRAQELgDLRMyJRkP8EkEIRAyAe8ApAXARI4Szi /wQQXeMzwDqVLLJUMC9QF8H/Qz8e4FzwX2EgcjCBX3EXsL8sUFGgKfAFICqxC2B5J6K/RCFApCJx YMk6kQ6wY0PS/SNbTzuxN3MsMgrAE9AsMO9pQTDCC4As8HUBAEGxICD8d285cAGQIYFYswCQAiD7 O1JjFi1dkQIwPWBBE22bx1jibIJLAWRzLUPxOGT/IwJdkl9wAiBOAxewHkBnuH0foW0f4BggJ1Ax ER+gZ+8IcFv1MvI35CA0UFzwJ1D/MvJd8VgBbWwnoQIgNNNsgv5mJ/AdwFZSdYUhsywwOxLfBJA5 cCpwQhAfoGMy4zsw71ZDbQEOsFMxR1YgJOFAo/86kEIiaPM6sAbwdSRlVSdQ71WhL0IT8Spgb2KB VlJiEv89wnpCLLJ3ySHxdYUh0z+Dv2QhA6An8F9CJ4EigGtD4JBzayAofBBnLnYxHzIiPVA4lCzw MpF0L2L1A2B3OYEpPaIqJANgIjD/AmAsUFFCIJADYCoygzOFD1uGFiNbREBhI2R9i+AAHgA1EAEA AABBAAAAPEMxQTQ3RjE1NDBERjMyNDZBOEQzMEM4NTNDMDVEMERBMDNERTI2RDlAREFCRUNLLm1p c3NpLm5jc2MubWlsPgAAAAAeADkQAQAAAHMBAAA8NEU0RTA1QUEuMjA5MDEwNUB0ZWxpYS5jb20+ PEI2MEY2ODlCLUQwOUItNDY3Qy1CNkI5LUYzOUQxQzE0ODY1NEBjaXNjby5jb20+PDRFNEVCMzYy LjUwOTA5MDNAdGVsaWEuY29tPjw5RkJEMkIyMi1BMkEyLTRERUItQkFCOC0xN0UwMkQ2QUMwRTlA Y2lzY28uY29tPjw0RTRFQzhENS4zMDQwMTA4QHRlbGlhLmNvbT48MzU3NUNFRDItQjNGNy00MTIw LUI1RDItN0E5NzkwRUVCOTVDQGNpc2NvLmNvbT48NEU0RjQzQ0EuMzA5MDQwNUB0ZWxpYS5jb20+ PDUzNUI1RDBELURCNjAtNDlDNy05N0U2LTZGM0VCRDEyMDg1N0BjaXNjby5jb20+PDRFNTNGNTI3 LjUwMzA4QHRlbGlhLmNvbT4gPHAwNjI0MDgwNmNhNzliZTgyY2U5MEBbMTI4Ljg5Ljg5LjEyOV0+ AAAeAEIQAQAAACgAAAA8cDA2MjQwODA2Y2E3OWJlODJjZTkwQFsxMjguODkuODkuMTI5XT4AAwCA EP////8fAPMQAQAAAFgAAABSAEUAJQAzAEEAIABbAHAAawBpAHgAXQAgAEUAUwBUAC0AMAAyACAA cwBtAGEAcgB0ACAAYwBhAHIAZAAgAHEAdQBlAHMAdABpAG8AbgAuAEUATQBMAAAACwD2EAAAAABA AAcwOFpUwFxizAFAAAgwZqhiwFxizAECARAwAQAAAEYAAAAAAAAAkmPyllT+0xGj+ACAXzGcRQcA XkpAl6OU0hGjxQCAX77IvwAAAXNdPAAAyxYRPwjTpU+afGo9SESipwAAAnErMwAAAAADAN4/n04A AAMA8T8JBAAAHgD4PwEAAAAPAAAAS2VtcCwgRGF2aWQgUC4AAAIB+T8BAAAATQAAAAAAAADcp0DI wEIQGrS5CAArL+GCAQAAAAAAAAAvTz1FWENIQU5HRU5TQS9PVT1NSVNTSS9DTj1SRUNJUElFTlRT L0NOPURQS0VNUDEAAAAAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEA AAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAa QAAAAAAeADBAAQAAAAgAAABEUEtFTVAxAB4AMUABAAAACAAAAERQS0VNUDEAHgA4QAEAAAAIAAAA RFBLRU1QMQAeADlAAQAAAAIAAAAuAAAAAwB2QP////8DAAlZAQAAAAMAAW4AAAAAAwAhgQMgBgAA AAAAwAAAAAAAAEYAAAAAAYEAAAAAAAAFACKBAyAGAAAAAADAAAAAAAAARgAAAAACgQAAAAAAAAAA AAADACSBAyAGAAAAAADAAAAAAAAARgAAAAATgQAAAQAAAAsAJYEDIAYAAAAAAMAAAAAAAABGAAAA AByBAAAAAAAACwAngQMgBgAAAAAAwAAAAAAAAEYAAAAAJoEAAAAAAAADACmBAyAGAAAAAADAAAAA AAAARgAAAAAQgQAAAAAAAAMAKoEDIAYAAAAAAMAAAAAAAABGAAAAABGBAAAAAAAAAwAtgQMgBgAA AAAAwAAAAAAAAEYAAAAAKoEAAAAAAAADADCBAyAGAAAAAADAAAAAAAAARgAAAAApgQAAAAAAAAsA MYEDIAYAAAAAAMAAAAAAAABGAAAAACSBAAAAAAAACwAygQMgBgAAAAAAwAAAAAAAAEYAAAAALIEA AAAAAAAeADOBAyAGAAAAAADAAAAAAAAARgAAAAAngQAAAQAAAAEAAAAAAAAAAwA0gQMgBgAAAAAA wAAAAAAAAEYAAAAAEoEAAAEAAAAeADWBAyAGAAAAAADAAAAAAAAARgAAAAAhgQAAAQAAAAEAAAAA AAAACwA2gQMgBgAAAAAAwAAAAAAAAEYAAAAAA4EAAAAAAAADADmBAyAGAAAAAADAAAAAAAAARgAA AAAjgQAA////fwsAiIEIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwDtgQggBgAAAAAAwAAA AAAAAEYAAAAAAYUAAAAAAAALAPKBCCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA/IEIIAYA AAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwADggggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAL AOyCCCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsA8IIIIAYAAAAAAMAAAAAAAABGAAAAAIKF AAAAAAAAQADsgwggBgAAAAAAwAAAAAAAAEYAAAAAv4UAAHDI0l1cYswBCwApAAAAAAALACMAAAAA AAMABhCccPGIAwAHEF4FAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAATk9URTpJQVBPTE9H SVpFSU5BRFZBTkNFSUZTT01FQk9EWVNGSVJFV0FMTFRVUk5TVEhJU1RFWFRNRVNTQUdFSU5UT0Ei QkFOTkVEQVRUQUNITUVOVCJGUk9NOlNURVBIRU5LRQAAAAACAX8AAQAAAEEAAAA8QzFBNDdGMTU0 MERGMzI0NkE4RDMwQzg1M0MwNUQwREEwM0RFMjZEOUBEQUJFQ0subWlzc2kubmNzYy5taWw+AAAA AGqC ------_=_NextPart_001_01CC625C.C056BC95-- ------------=_1314190327-20935-2-- From SChokhani@cygnacom.com Wed Aug 24 06:06:32 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39F521F8782 for ; Wed, 24 Aug 2011 06:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRCi3zP2AwyB for ; Wed, 24 Aug 2011 06:06:32 -0700 (PDT) Received: from mail108.messagelabs.com (mail108.messagelabs.com [216.82.250.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3403D21F8772 for ; Wed, 24 Aug 2011 06:06:32 -0700 (PDT) X-Env-Sender: SChokhani@cygnacom.com X-Msg-Ref: server-12.tower-108.messagelabs.com!1314191260!17088885!1 X-Originating-IP: [216.191.252.22] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19935 invoked from network); 24 Aug 2011 13:07:41 -0000 Received: from sottexche2.entrust.com (HELO sottexchE2.entrust.com) (216.191.252.22) by server-12.tower-108.messagelabs.com with AES128-SHA encrypted SMTP; 24 Aug 2011 13:07:41 -0000 Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 24 Aug 2011 09:07:23 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 24 Aug 2011 09:07:39 -0400 From: Santosh Chokhani To: Peter Gutmann , "anders.rundgren@telia.com" , "kent@bbn.com" Date: Wed, 24 Aug 2011 09:07:37 -0400 Thread-Topic: [pkix] EST-02 smart card question Thread-Index: AcxiCg6dihvs6wciSsOh7y3aM/abkwAVGiGA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:06:32 -0000 I see the comment. But, is this really anything new? We all know that any hardware crypto module is at the mercy of the host inv= oking it. If the host has a Trojan or is misconfigured, the crypto module = as secret and private keys in it can be misused. Isn't that is why we have multitude to tools in the security toolbox, if on= e cares to use them? -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pet= er Gutmann Sent: Tuesday, August 23, 2011 11:01 PM To: anders.rundgren@telia.com; kent@bbn.com Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question Stephen Kent writes: >The CAC and PIVs have approval processes associated with accreditation of >devices. So, unless the cognizant gov agencies decide that market forces a= re >more important than security concerns, virtualization is unlikely to occur= . See my previous post, it already has, several years ago (unless the RDP sma= rt card virtualisation detects when it's talking to a CAC and refuses to proxy it, which seems unlikely). Peter. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From pgut001@login01.cs.auckland.ac.nz Wed Aug 24 06:29:09 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2382421F8B36 for ; Wed, 24 Aug 2011 06:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE33t7AOXudt for ; Wed, 24 Aug 2011 06:29:08 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id BCA2121F8AF0 for ; Wed, 24 Aug 2011 06:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1314192619; x=1345728619; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20kent@bbn.com,=20pgut0 01@cs.auckland.ac.nz,=0D=0A=20=20=20=20SChokhani@cygnacom .com|Subject:=20RE:=20[pkix]=20EST-02=20smart=20card=20qu estion|Cc:=20pkix@ietf.org|In-Reply-To:=20 |Message-Id:=20|Date:=20Thu,=2025=20Aug=202011=2001:30:14=20+1200; bh=/V1s2jF3ZIG9l/0OQLvSGe1/l9gl0pl+zIVoe2y1kQE=; b=E5f2pxQBWzXJR7efx5KshfpMWmH1ALrrk5xjeDqQffRP3YsY1bVoBukK H3pBcU0xjLaYGeuXLdgaebF4Gbgmt8rRVLXx0LyeFmyodcoDjqmObhIWf os/4/teuREula+luIoqWgvXVbThKU8HAl7nbKLUbhM9tj25Nxfpk/obFW 4=; X-IronPort-AV: E=Sophos;i="4.68,275,1312113600"; d="scan'208";a="80313623" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Aug 2011 01:30:14 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QwDX4-00083x-HI; Thu, 25 Aug 2011 01:30:14 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QwDX4-0003eR-6c; Thu, 25 Aug 2011 01:30:14 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, kent@bbn.com, pgut001@cs.auckland.ac.nz, SChokhani@cygnacom.com In-Reply-To: Message-Id: Date: Thu, 25 Aug 2011 01:30:14 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:29:09 -0000 Santosh Chokhani writes: >But, is this really anything new? It seems to come as a considerable surprise to people who expect that smart- card-auth guarantees some high level of assurance that the holder of the card directly authorised the transaction, rather than having the card stuck 24/7 in a reader in a server room connected via virtual USB ports to half a dozen workstations throughout the building, saving the users the hassle of dealing with smart cards and the IT admins the hassle of dealing with users failing to deal with smart cards. Think of it as passwords written on whiteboards, but with the illusion of security because smart cards are involved. Peter. From kent@bbn.com Wed Aug 24 11:14:33 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D5721F8A66 for ; Wed, 24 Aug 2011 11:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maqQFK1pCnQu for ; Wed, 24 Aug 2011 11:14:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE221F8A64 for ; Wed, 24 Aug 2011 11:14:32 -0700 (PDT) Received: from dhcp89-089-129.bbn.com ([128.89.89.129]:49167) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QwHzL-00093D-4g; Wed, 24 Aug 2011 14:15:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4E4E05AA.2090105@telia.com><4E4EB362.5090903@telia.com><9FBD2B22-A2A2-4DEB-BAB8-17E02D6AC0E9@cisco. com><4E4EC8D5.3040108@telia.com><3575CED2-B3F7-4120-B5D2-7A9790EEB95C@cisc o.com><4E4F43CA.3090405@telia.com><535B5D0D-DB60-49C7-97E6-6F3EBD120857@ci sco.com><4E53F527.50308@telia.com> Date: Wed, 24 Aug 2011 14:14:54 -0400 To: "Kemp, David P." From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 18:14:33 -0000 A >... >Steve, > >The USG is not immune to market forces :-). Technologies such as TI's >OMAP make it conceivable that mobile devices could one day provide >"approvable" security. While critical applications will always require >certified devices, we are attempting to define a "commercial solutions >for classified" process to support accreditation of systems that employ >multiple layers of approved commercial protection. Gee, can I get a rebate on my federal taxes (equal to the % spent on bad ideas like this, when applied to the classified context :-)? >Our mobility architecture includes a two-stage provisioning process - >central provisioning provides a hands-on enrollment ceremony to load >approved firmware, configurations and device keys, and field >provisioning personalizes a fungible device into its user-specific and >usable state. Given appropriate protocols and systems, it appears >possible for the user to personalize a device to a CAC at an unattended >kiosk (e.g., a controlled client/browser), though probably not through >an uncontrolled client/browser. > >Dave The provisioning process you describe could preclude a virtualized CAC, because the device that is initialized during the first step contains a known key (or key pair) and that could be used to distinguish a CAC from a non-CAC. Thus the issue is one of whether the issuer wants to allow virtualization, in the name of convenience and cost savings, or to preclude it, in the name of security. Steve From kent@bbn.com Wed Aug 24 11:14:35 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1928F21F8B02 for ; Wed, 24 Aug 2011 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKcxRRQkneZm for ; Wed, 24 Aug 2011 11:14:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2904521F8A64 for ; Wed, 24 Aug 2011 11:14:34 -0700 (PDT) Received: from dhcp89-089-129.bbn.com ([128.89.89.129]:49167) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QwHzJ-00093D-P2; Wed, 24 Aug 2011 14:15:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 24 Aug 2011 14:15:26 -0400 To: Peter Gutmann From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-897912755==_ma============" Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 18:14:35 -0000 --============_-897912755==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:56 PM +1200 8/24/11, Peter Gutmann wrote: >Max Pritikin writes: > >>Although people involved in USG security tend to claim that "this will never >>happen", I believe that pure economics, convenience and "coolness" will make >>virtualized PIV and CAC credentials in mobile devices enrolled in *self- >>service* processes using your original card as "bootstrap", the norm. > >It's actually already happened, several years ago. See "Remote Desktop >Protocol: Smart Card Virtual Channel Extension", Microsoft Corporation, 7 >February 2008. So the key is still in the smart card, but the smart card may >be on the other side of the planet. This pretty much epitomises the problem >with smart cards, having the key locked into a device that does anything an >untrusted remote system tells it to is little better than having the key on >the untrusted system. > >Peter. I was not aware of this "feature" of Windows. Makes me even happier to be a Mac user :-). I especially like these quotes from the current (June 2011) version of the MS-RDPSEC document: 5 Security This protocol has no security aspects and relies on the underlying transport for any security. 5.1 Security Considerations for Implementers None. 5.2 Index of Security Parameters None. Still, I interpreted Anders's comments re virtualization as referring to use of a device that holds credentials, issued by a variety of CAs in a non-cooperative fashion, with each CA believing that the device is controlled by the CA in question. The doc you cite shows that use of a smart card does not imply that the user is in physical possession of the card, in this case. Smart card systems that require use of an external device for signing, with human PIN/data entry are presumably not subject to the MS remote desktop hack. So, there are technical means of addressing this concern, if people really care. Steve --============_-897912755==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] EST-02 smart card question
At 2:56 PM +1200 8/24/11, Peter Gutmann wrote:
Max Pritikin <pritikin@cisco.com> writes:

>Although people involved in USG security tend to claim that "this will never
>happen", I believe that pure economics, convenience and "coolness" will make
>virtualized PIV and CAC credentials in mobile devices enrolled in *self-
>service* processes using your original card as "bootstrap", the norm.
It's actually already happened, several years ago.  See "Remote Desktop
Protocol: Smart Card Virtual Channel Extension", Microsoft Corporation, 7
February 2008.  So the key is still in the smart card, but the smart card may
be on the other side of the planet.  This pretty much epitomises the problem
with smart cards, having the key locked into a device that does anything an
untrusted remote system tells it to is little better than having the key on
the untrusted system.
Peter.

I was not aware of this "feature" of Windows.  Makes me even happier to be
a Mac user :-).

I especially like these quotes from the current (June 2011) version of the MS-RDPSEC document:

5 Security
This protocol has no security aspects and relies on the underlying transport for any security.

5.1 Security Considerations for Implementers
None.
5.2 Index of Security Parameters
None.


Still, I interpreted Anders's comments re virtualization as referring to use of a device that holds credentials, issued by a variety of CAs in a non-cooperative fashion, with each CA believing that the device is controlled by the CA in question. The doc you cite shows that use of a smart card does not imply that
the user is in physical possession of the card, in this case. Smart card
systems that require use of an external device for signing, with human PIN/data entry are presumably not subject to the MS remote desktop hack. So, there are technical means of addressing this concern, if people really care.

Steve
--============_-897912755==_ma============-- From mstjohns@comcast.net Wed Aug 24 12:06:22 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0855221F8BA4 for ; Wed, 24 Aug 2011 12:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UI8BGyEkdoH for ; Wed, 24 Aug 2011 12:06:21 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 60FD521F8B14 for ; Wed, 24 Aug 2011 12:06:21 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta09.westchester.pa.mail.comcast.net with comcast id QK4w1h0020vyq2s59K7Zqa; Wed, 24 Aug 2011 19:07:33 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta05.westchester.pa.mail.comcast.net with comcast id QK7X1h02d1EtFYL3RK7Y5F; Wed, 24 Aug 2011 19:07:33 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Aug 2011 15:07:08 -0400 To: pkix@ietf.org From: Michael StJohns Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_954113799==.ALT" Message-Id: <20110824190621.60FD521F8B14@ietfa.amsl.com> Subject: [pkix] CRL and OCSP signer certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:06:22 -0000 --=====================_954113799==.ALT Content-Type: text/plain; charset="us-ascii" Hi - After pawing through 5280 et al, I'm unclear of whether or not the cRLSign keyUsage bit can be asserted in a non-CA certificate (a certificate where the basicConstraints extension is missing, or where cA is FALSE in such extension). Do certificates that "contain public keys used exclusively for purposes other than validating digital signatures on certificates" need to be or should they be CA certificates? Secondly, am I correct in reading that a basicConstraints extension with cA is FALSE gets encoded as an empty sequence? This is extracted from 5280 and refers to the basicConstraints extension. It is the only item somewhat on point I could find - but doesn't actually say anything about cA=FALSE. This extension MAY appear as a critical or non- critical extension in CA certificates that contain public keys used exclusively for purposes other than validating digital signatures on certificates. Such CA certificates include ones that contain public keys used exclusively for validating digital signatures on CRLs and ones that contain key management public keys used with certificate enrollment protocols. Thanks! Mike --=====================_954113799==.ALT Content-Type: text/html; charset="us-ascii" Hi -

After pawing through 5280 et al, I'm unclear of whether or not the cRLSign keyUsage bit can be asserted in a non-CA certificate (a certificate where the basicConstraints extension is missing, or where cA is FALSE in such extension).   Do certificates that "contain public keys used exclusively for purposes other than validating digital signatures on certificates" need to be  or should they be CA certificates?

Secondly, am I correct in reading that a basicConstraints extension with cA is FALSE gets encoded as an empty sequence?

This is extracted from 5280 and refers to the basicConstraints extension. It is the only item somewhat on point I could find - but doesn't actually say anything about cA=FALSE.

This extension MAY appear as a critical or non-
   critical extension in CA certificates that contain public
keys used
   exclusively for purposes other than validating digital
signatures on
   certificates.  Such CA certificates include ones that
contain public
   keys used exclusively for validating digital signatures on
CRLs and
   ones that contain key management public keys used with
certificate
   enrollment protocols.
Thanks! Mike
--=====================_954113799==.ALT-- From pgut001@login01.cs.auckland.ac.nz Wed Aug 24 21:48:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3539121F8B82 for ; Wed, 24 Aug 2011 21:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi8wMJ3ag0oB for ; Wed, 24 Aug 2011 21:48:16 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4682E21F8B7D for ; Wed, 24 Aug 2011 21:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1314247769; x=1345783769; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20kent@bbn.com,=20pgut001@cs.auckland.ac.nz|Subject: =20Re:=20[pkix]=20EST-02=20smart=20card=20question|Cc:=20 anders.rundgren@telia.com,=20pkix@ietf.org,=20pritikin@ci sco.com|In-Reply-To:=20|Message-Id:=20|Date:=20Thu,=2025=20Aug=202011=2016:49:20=20+12 00; bh=lKGa/y3gI4SgLYKRO01clupztB3gvzHGtaFtNw5sQLM=; b=FwGlbMX3zeeHncaBpufq0P62jnvi80gRRoWgT7xeKO5SnQ9H52P0latX /gUC1Cu9r9VWRAYIMGMLRxuVB3wCGI1OU2DG8GlecPxz1BxeN/RntrgCy Obib4rFd7Et0QQIJa0NYSQRoUn+XM9GSBIrCeTvC/R3vpx7unMthhS0c+ M=; X-IronPort-AV: E=Sophos;i="4.68,279,1312113600"; d="scan'208";a="80501881" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Aug 2011 16:49:21 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QwRsW-0005rd-Hk; Thu, 25 Aug 2011 16:49:20 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QwRsW-0001ff-Ec; Thu, 25 Aug 2011 16:49:20 +1200 From: Peter Gutmann To: kent@bbn.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Thu, 25 Aug 2011 16:49:20 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 04:48:18 -0000 Stephen Kent writes: >I was not aware of this "feature" of Windows. Makes me even happier to be >a Mac user :-). Works just as well under Linux (and, presumably, OS X, although I've never really seen that used on corporate desktops outside art/graphics departments so that's by extrapolation from the Linux/Unix situation) using virtual USB port redirection. It's actually even less secure than the Windows version because Windows at least uses RDP security while Linux just does USB-over-TCP, and I'm not aware of anyone considering it worth tunnelling over SSH. >Smart card systems that require use of an external device for signing, with >human PIN/data entry are presumably not subject to the MS remote desktop hack. Where I've seen it used it's used for authentication rather than long-term signing (that is, the card performs a sig.op, but only on ephemeral data). So the IT folks plug in the card and enter the PIN to unlock, and then the auth gets proxied to wherever it's needed over the network. Since the card is never unplugged, it always remains unlocked via the PIN. As you say, it doesn't work for a PIN-per-signature application. Peter. From md@e-net.lt Thu Aug 25 01:06:31 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E73521F86C1 for ; Thu, 25 Aug 2011 01:06:31 -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=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqo1r6yxLCwm for ; Thu, 25 Aug 2011 01:06:31 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id CEB9E21F852E for ; Thu, 25 Aug 2011 01:06:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=mail.ssc.lt) by mail.ssc.lt with esmtp (Exim 4.50) id 1QwUyG-0007AW-GT; Thu, 25 Aug 2011 11:07:28 +0300 Received: from 84.15.15.12 (SquirrelMail authenticated user md@e-net.lt) by mail.ssc.lt with HTTP; Thu, 25 Aug 2011 11:07:28 +0300 (EEST) Message-ID: <62959.84.15.15.12.1314259648.squirrel@mail.ssc.lt> In-Reply-To: References: Date: Thu, 25 Aug 2011 11:07:28 +0300 (EEST) From: "Moudrick M. Dadashov" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: md@e-net.lt List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 08:06:31 -0000 On Thu, August 25, 2011 07:49, Peter Gutmann wrote: > Stephen Kent writes: > >>I was not aware of this "feature" of Windows. Makes me even happier to >> be >>a Mac user :-). > > Works just as well under Linux (and, presumably, OS X, although I've never > really seen that used on corporate desktops outside art/graphics > departments > so that's by extrapolation from the Linux/Unix situation) using virtual > USB > port redirection. It's actually even less secure than the Windows version > because Windows at least uses RDP security while Linux just does > USB-over-TCP, > and I'm not aware of anyone considering it worth tunnelling over SSH. > >>Smart card systems that require use of an external device for signing, >> with >>human PIN/data entry are presumably not subject to the MS remote desktop >> hack. > > Where I've seen it used it's used for authentication rather than long-term > signing (that is, the card performs a sig.op, but only on ephemeral data). > So > the IT folks plug in the card and enter the PIN to unlock, and then the > auth > gets proxied to wherever it's needed over the network. Since the card is > never unplugged, it always remains unlocked via the PIN. As you say, it > doesn't work for a PIN-per-signature application. > Do you see any problems when this scenario is implemented on a dedicated 1:1 or 1:n communication channel? Thanks, M.D. cell: +370-699-26662 > Peter. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From anders.rundgren@telia.com Thu Aug 25 13:04:13 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F1521F86AF for ; Thu, 25 Aug 2011 13:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag9i5qBDMOnr for ; Thu, 25 Aug 2011 13:04:12 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5FA21F8C43 for ; Thu, 25 Aug 2011 13:04:11 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E526612001814F5 for pkix@ietf.org; Thu, 25 Aug 2011 22:05:20 +0200 Message-ID: <4E56AAFD.3030405@telia.com> Date: Thu, 25 Aug 2011 22:05:17 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4E5421EA.8010904@telia.com> <3712DF46-D370-4024-9C0D-FF7CF80487A3@cisco.com> In-Reply-To: <3712DF46-D370-4024-9C0D-FF7CF80487A3@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------020903060708060509010802" Subject: [pkix] Token Provisioning versus Certificate Enrollment X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:04:13 -0000 This is a multi-part message in MIME format. --------------020903060708060509010802 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit With a hope to shed some light regarding enrollment protocols the following may be of some interest. KeyGen2 is /_not_/ a Certificate Enrollment protocol; /it is a Token (cryptographic module) Provisioning protocol/. Unlike Certificate Enrollment which essentially only requires a request-response pair where the response (certificate) can be securely derived to request, /Token Provisioning usually needs additional steps /_before_/and _after_ the core message exchange as well/. Also in contrast to Certificate Enrollment protocols, /Token Provisioning _always_ targets a specific token container/. If /_secure_/ Token Provisioning is to be performed by remote users over the Internet, /E2ES (end-to-end-security) _must be enforced_, and preferably throughout the _entire_ process/. Since E2ES cannot be /abstracted/, a prerequisite is that /the issuer and token _speak the same language_/. This obviously thickens the plot considerably unless you also standardize the token (/with respect to provisioning NB/), which was the sole motivation behind KeyGen2's alter ago, the SKS. KeyGen2/SKS in similarity to GlobalPlatform relies on a very light-weight security mechanism based on session keys and a two-level client where the provisioning middleware does the /"heavy lifting"/ and handle /user interactions/, while /the token _exclusively_ deals with low-level E2ES-centric operations/. Token Provisioning in browsers is currently entirely based on /third-party proprietary and mostly secret "plugins"/. Anders Rundgren http://webpki.org/auth-token-4-the-cloud.html --------------020903060708060509010802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit With a hope to shed some light regarding enrollment protocols the following may be of some interest.

KeyGen2 is not a Certificate Enrollment protocol; it is a Token (cryptographic module) Provisioning protocol.

Unlike Certificate Enrollment which essentially only requires a request-response pair where the response (certificate) can be securely derived to request, Token Provisioning usually needs additional steps before and after the core message exchange as well.

Also in contrast to Certificate Enrollment protocols, Token Provisioning always targets a specific token container.
If secure Token Provisioning is to be performed by remote users over the Internet, E2ES (end-to-end-security) must be enforced, and preferably throughout the entire process.

Since E2ES cannot be abstracted, a prerequisite is that the issuer and token speak the same language.
This obviously thickens the plot considerably unless you also standardize the token (with respect to provisioning NB), which was the sole motivation behind KeyGen2's alter ago, the SKS.

KeyGen2/SKS in similarity to GlobalPlatform relies on a very light-weight security mechanism based on session keys and a two-level client where the provisioning middleware does the "heavy lifting" and handle user interactions, while the token exclusively deals with low-level E2ES-centric operations.

Token Provisioning in browsers is currently entirely based on third-party proprietary and mostly secret "plugins".

Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html
--------------020903060708060509010802-- From kent@bbn.com Thu Aug 25 15:07:47 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A25221F8B94 for ; Thu, 25 Aug 2011 15:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.261 X-Spam-Level: X-Spam-Status: No, score=-106.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t2c4xZ4i6Al for ; Thu, 25 Aug 2011 15:07:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1C99921F8B8F for ; Thu, 25 Aug 2011 15:07:46 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59639 helo=[192.168.1.13]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qwi6e-0003oZ-FE; Thu, 25 Aug 2011 18:09:00 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 25 Aug 2011 15:21:22 -0400 To: Peter Gutmann From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 22:07:47 -0000 At 4:49 PM +1200 8/25/11, Peter Gutmann wrote: >... > >>Smart card systems that require use of an external device for signing, with >>human PIN/data entry are presumably not subject to the MS remote >>desktop hack. > >Where I've seen it used it's used for authentication rather than long-term >signing (that is, the card performs a sig.op, but only on ephemeral data). So >the IT folks plug in the card and enter the PIN to unlock, and then the auth >gets proxied to wherever it's needed over the network. Since the card is >never unplugged, it always remains unlocked via the PIN. As you say, it >doesn't work for a PIN-per-signature application. Agreed. Also, for the CAC case, there are other considerations that make this seem an unlikely scenario. CACs are often THE Giv issued photo ID for their holders, so one is not likely to go far away from a machine that is holding one's CAC. In some contexts, the CAC is intended to be used for physical access control too, which means that one might not be able to go very far, physically, w/o one's CAC. Steve From kent@bbn.com Thu Aug 25 15:07:49 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AABA21F8BB3 for ; Thu, 25 Aug 2011 15:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmphfLSeWI4C for ; Thu, 25 Aug 2011 15:07:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CDECB21F8B8F for ; Thu, 25 Aug 2011 15:07:48 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59639 helo=[192.168.1.13]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qwi6g-0003oZ-VI; Thu, 25 Aug 2011 18:09:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <62959.84.15.15.12.1314259648.squirrel@mail.ssc.lt> References: <62959.84.15.15.12.1314259648.squirrel@mail.ssc.lt> Date: Thu, 25 Aug 2011 15:22:50 -0400 To: md@e-net.lt From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 22:07:49 -0000 At 11:07 AM +0300 8/25/11, Moudrick M. Dadashov wrote: >... >Do you see any problems when this scenario is implemented on a dedicated >1:1 or 1:n communication channel? >Thanks, > >M.D. I don't know how to interpret your comment. can you provide additional context? Steve From pgut001@login01.cs.auckland.ac.nz Thu Aug 25 15:47:23 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7648421F8B51 for ; Thu, 25 Aug 2011 15:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmKqvQAlOQS7 for ; Thu, 25 Aug 2011 15:47:22 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC0D21F8BA7 for ; Thu, 25 Aug 2011 15:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1314312517; x=1345848517; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20kent@bbn.com,=20md@e-net.lt|Subject:=20Re:=20[pkix ]=20EST-02=20smart=20card=20question|Cc:=20pkix@ietf.org |In-Reply-To:=20 |Message-Id:=20|Date:=20Fri,=2026=20Aug=202011=2010:48:35=20+1200; bh=5Rj6JJr24sdP7C4K7xFrBaxLtFEp2dmLwEoyzvF7HQY=; b=hRV4Pl3xEhGtYWozZ9jZYE2Y6L+5IL0Fm9tMhX3SCCWpYSYqh+ImK8H7 uyQFUnux86X1vgpryjM8Ky6axywvYuCfYtJ9npTQxjxcN04QjeSt6VWpR 2J3qlf0nK/KWZfjIawCdgdUtLsPCwNh/FlyroAdJLmQwzfmaq5pzNpjEw s=; X-IronPort-AV: E=Sophos;i="4.68,282,1312113600"; d="scan'208";a="80605562" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Aug 2011 10:48:35 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qwiix-0002Km-GY; Fri, 26 Aug 2011 10:48:35 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qwiix-00081n-2u; Fri, 26 Aug 2011 10:48:35 +1200 From: Peter Gutmann To: kent@bbn.com, md@e-net.lt In-Reply-To: Message-Id: Date: Fri, 26 Aug 2011 10:48:35 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 22:47:23 -0000 Stephen Kent writes: >At 11:07 AM +0300 8/25/11, Moudrick M. Dadashov wrote: >>... >>Do you see any problems when this scenario is implemented on a dedicated >>1:1 or 1:n communication channel? > >I don't know how to interpret your comment. can you provide additional >context? That was going to be my reply as well: Which scenario, what problem are you trying to solve, and what's the threat model? Peter. From md@e-net.lt Thu Aug 25 18:04:30 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9740C21F8B17 for ; Thu, 25 Aug 2011 18:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nCGHs+YT10I for ; Thu, 25 Aug 2011 18:04:29 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2F021F8B16 for ; Thu, 25 Aug 2011 18:04:29 -0700 (PDT) Received: from lan-84-240-23-136.vln.skynet.lt ([84.240.23.136] helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1QwkrT-0000Ff-NR; Fri, 26 Aug 2011 04:05:31 +0300 Message-ID: <4E56F15B.90200@e-net.lt> Date: Fri, 26 Aug 2011 04:05:31 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Stationery: 0.7.5 Content-Type: multipart/alternative; boundary="------------000608050908000302080809" Cc: pkix@ietf.org Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 01:04:30 -0000 This is a multi-part message in MIME format. --------------000608050908000302080809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/26/2011 1:48 AM, Peter Gutmann wrote: > Stephen Kent writes: >> At 11:07 AM +0300 8/25/11, Moudrick M. Dadashov wrote: >>> ... >>> Do you see any problems when this scenario is implemented on a dedicated >>> 1:1 or 1:n communication channel? >> I don't know how to interpret your comment. can you provide additional >> context? > That was going to be my reply as well: Which scenario, what problem are you > trying to solve, and what's the threat model? > > Peter. > The scenario: I've a remote http server with his key pair stored on a secure device (eToken). The server can be accessed only through an authenticated vpn connection. I was asking do you see any problem if the eToken on the server remains unlocked for further sessions after once entering the PIN (cached password etc.)? Thenks, M.D. --------------000608050908000302080809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/26/2011 1:48 AM, Peter Gutmann wrote: 
Stephen Kent <kent@bbn.com> writes:

At 11:07 AM +0300 8/25/11, Moudrick M. Dadashov wrote:

...
Do you see any problems when this scenario is implemented on a dedicated
1:1 or 1:n communication channel?

I don't know how to interpret your comment.  can you provide additional 
context?

That was going to be my reply as well: Which scenario, what problem are you
trying to solve, and what's the threat model?

Peter.
The scenario: I've a remote http server with his key pair stored on a secure device (eToken). The server can be accessed only through an authenticated vpn connection. I was asking do you see any problem if the eToken on the server remains unlocked for further sessions after once entering the PIN (cached password etc.)?

Thenks,
M.D.   
--------------000608050908000302080809-- From tmiller@mitre.org Fri Aug 26 05:38:37 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D3321F87F0 for ; Fri, 26 Aug 2011 05:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUE3rmC49nYl for ; Fri, 26 Aug 2011 05:38:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C96B421F850B for ; Fri, 26 Aug 2011 05:38:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 478E221B0A96 for ; Fri, 26 Aug 2011 08:39:52 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 37C7F21B0631 for ; Fri, 26 Aug 2011 08:39:52 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 26 Aug 2011 08:39:52 -0400 From: "Miller, Timothy J." To: "pkix@ietf.org PKIX" Date: Fri, 26 Aug 2011 08:39:54 -0400 Thread-Topic: [pkix] Token Provisioning versus Certificate Enrollment Thread-Index: Acxj7T97R7s+p3oDRF2tGhvg+ikVfQ== Message-ID: <4E1DBD94-3E0D-4708-A9F9-643FD81C3643@mitre.org> References: <4E5421EA.8010904@telia.com> <3712DF46-D370-4024-9C0D-FF7CF80487A3@cisco.com> <4E56AAFD.3030405@telia.com> In-Reply-To: <4E56AAFD.3030405@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2-1047745141"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [pkix] Token Provisioning versus Certificate Enrollment X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 12:38:37 -0000 --Apple-Mail-2-1047745141 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii So I keep wondering where the right forum for this discussion is. = Clearly token management has an interface with PKI systems, but that's = as far as it goes. I don't think TMS standards are in scope here, but = then I don't know a body where it would be *in* scope. -- T On Aug 25, 2011, at 3:05 PM, Anders Rundgren wrote: > With a hope to shed some light regarding enrollment protocols the = following may be of some interest. >=20 > KeyGen2 is not a Certificate Enrollment protocol; it is a Token = (cryptographic module) Provisioning protocol. >=20 > Unlike Certificate Enrollment which essentially only requires a = request-response pair where the response (certificate) can be securely = derived to request, Token Provisioning usually needs additional steps = before and after the core message exchange as well. >=20 > Also in contrast to Certificate Enrollment protocols, Token = Provisioning always targets a specific token container. > If secure Token Provisioning is to be performed by remote users over = the Internet, E2ES (end-to-end-security) must be enforced, and = preferably throughout the entire process. >=20 > Since E2ES cannot be abstracted, a prerequisite is that the issuer and = token speak the same language. > This obviously thickens the plot considerably unless you also = standardize the token (with respect to provisioning NB), which was the = sole motivation behind KeyGen2's alter ago, the SKS. >=20 > KeyGen2/SKS in similarity to GlobalPlatform relies on a very = light-weight security mechanism based on session keys and a two-level = client where the provisioning middleware does the "heavy lifting" and = handle user interactions, while the token exclusively deals with = low-level E2ES-centric operations. >=20 > Token Provisioning in browsers is currently entirely based on = third-party proprietary and mostly secret "plugins". >=20 > Anders Rundgren > http://webpki.org/auth-token-4-the-cloud.html > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-2-1047745141 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA4MjYxMjM5NTRaMCMGCSqGSIb3DQEJBDEWBBQX72VlPkb+HLBp43h/ 9xi4vFXwLjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgHP+nhTmSgCnsWwfKUXXQtxEQBFJqLWLtwl6 IWnvUQvwcaN9Iez6cAu/TjVIDPNCVGK01QCRh3Gfwwh2Gk60pdvsnt52TzvEQsLQYqlVEAabzgnI hBLyF1nylJZw6CrDXKVRPk1KkpgHWDLng7q/wkPzFAFRLuMWyfMBX5m1rUBRAAAAAAAA --Apple-Mail-2-1047745141-- From tmiller@mitre.org Fri Aug 26 06:08:18 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C730021F8744 for ; Fri, 26 Aug 2011 06:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3zK4bNQoXM6 for ; Fri, 26 Aug 2011 06:08:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 28F0E21F871E for ; Fri, 26 Aug 2011 06:08:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4A2DF21B145C; Fri, 26 Aug 2011 09:09:34 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4184121B1455; Fri, 26 Aug 2011 09:09:34 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 26 Aug 2011 09:09:34 -0400 From: "Miller, Timothy J." To: Peter Gutmann Date: Fri, 26 Aug 2011 09:09:33 -0400 Thread-Topic: [pkix] EST-02 smart card question Thread-Index: Acxj8WX+I7xhokcgSfqRSKGRgjqb9Q== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-5-1049524114"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:08:18 -0000 --Apple-Mail-5-1049524114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 See also: D. Balfanz and E. Felton, =93Hand-Held Computers Can Be Better Smart = Cards,=94 in Proceedings of USENIX Security =9299, Washington, D.C., = 1999. B. Schneier and A. Shostack, =93Breaking Up Is Hard To Do: Modeling = Security Threats For Smart Cards,=94 Presented at the USENIX Workshop on = Smartcard Technology, Chicago, IL, 1999. Yes, I actually keep those references handy. :) -- T On Aug 23, 2011, at 9:56 PM, Peter Gutmann wrote: > Max Pritikin writes: >=20 >> Although people involved in USG security tend to claim that "this = will never >> happen", I believe that pure economics, convenience and "coolness" = will make >> virtualized PIV and CAC credentials in mobile devices enrolled in = *self- >> service* processes using your original card as "bootstrap", the norm. >=20 > It's actually already happened, several years ago. See "Remote = Desktop > Protocol: Smart Card Virtual Channel Extension", Microsoft = Corporation, 7 > February 2008. So the key is still in the smart card, but the smart = card may > be on the other side of the planet. This pretty much epitomises the = problem > with smart cards, having the key locked into a device that does = anything an > untrusted remote system tells it to is little better than having the = key on > the untrusted system. >=20 > Peter. >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-5-1049524114 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA4MjYxMzA5MzNaMCMGCSqGSIb3DQEJBDEWBBSK3e21cKbfIc+deHh7 YG+Wq52BZDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgLlMMm+GEKhRv4nWkbJzQac4o0PbCg77iM1K VKUTHjWSd+ESOQrQD3q6xNe6xPVQl5IkC99aonr15dnuCQ3WHUUif44koCbEdnFO23vM3oRd0noN C/ljvsGJWrGECc1i0szhXZxVq938zMHypbSsrwCpcR+nmujjJHsuJd+YbUTKAAAAAAAA --Apple-Mail-5-1049524114-- From tmiller@mitre.org Fri Aug 26 06:10:31 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F317C21F8B77 for ; Fri, 26 Aug 2011 06:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SayP-kf6CWA6 for ; Fri, 26 Aug 2011 06:10:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0E88721F8B73 for ; Fri, 26 Aug 2011 06:10:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 592B621B145A; Fri, 26 Aug 2011 09:11:29 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 468DD21B1460; Fri, 26 Aug 2011 09:11:29 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 26 Aug 2011 09:11:29 -0400 From: "Miller, Timothy J." To: Santosh Chokhani Date: Fri, 26 Aug 2011 09:11:27 -0400 Thread-Topic: [pkix] EST-02 smart card question Thread-Index: Acxj8aqF2T9iYm7GRNixv7bJXb1xVw== Message-ID: <248350F5-755E-4FFD-8444-05684506B260@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-6-1049638676"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] EST-02 smart card question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:10:31 -0000 --Apple-Mail-6-1049638676 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 24, 2011, at 8:07 AM, Santosh Chokhani wrote: > I see the comment. >=20 > But, is this really anything new? >=20 > We all know that any hardware crypto module is at the mercy of the = host invoking it. If the host has a Trojan or is misconfigured, the = crypto module as secret and private keys in it can be misused. Trusted activation pathways are possible, but tend to be more expensive = than just "dumb reader, smart card." -- T --Apple-Mail-6-1049638676 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA4MjYxMzExMjhaMCMGCSqGSIb3DQEJBDEWBBSdMyHdesnR0axPkeAY SX/7TKgMLTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgGhRd/NhZk5gygPM2atY8wfT2ipTeG0njU4m olwlHOLyhBOrwdHH0oKnEmGe/o4pG76FN8z8Cso5yHZ+CPwQEYId2zhOsvPYbZvSRZ3U7/ESb/ha krl08a+fHh/IrpS47HbK7ss5R8vH7cbzToWPi4CC6kez3A5lVXFHrrIicnD9AAAAAAAA --Apple-Mail-6-1049638676-- From anders.rundgren@telia.com Fri Aug 26 06:11:34 2011 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C0521F8A30 for ; Fri, 26 Aug 2011 06:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBud56HcPnJt for ; Fri, 26 Aug 2011 06:11:32 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 634A021F8A57 for ; Fri, 26 Aug 2011 06:11:31 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E526612001C4B95; Fri, 26 Aug 2011 15:12:44 +0200 Message-ID: <4E579BC9.4030109@telia.com> Date: Fri, 26 Aug 2011 15:12:41 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: "Miller, Timothy J." References: <4E5421EA.8010904@telia.com> <3712DF46-D370-4024-9C0D-FF7CF80487A3@cisco.com> <4E56AAFD.3030405@telia.com> <4E1DBD94-3E0D-4708-A9F9-643FD81C3643@mitre.org> In-Reply-To: <4E1DBD94-3E0D-4708-A9F9-643FD81C3643@mitre.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------060903020001040500070109" Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] Token Provisioning versus Certificate Enrollment X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:11:34 -0000 This is a multi-part message in MIME format. --------------060903020001040500070109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2011-08-26 14:39, Miller, Timothy J. wrote: > So I keep wondering where the right forum for this discussion is. Clearly token management has an interface with PKI systems, but that's as far as it goes. I don't think TMS standards are in scope here, but then I don't know a body where it would be *in* scope. You are absolutely correct! This is outside of what any SDO could possible deal with. Not even TrustedComputingGroup which I'm an invited expert member of dared addressing TPM key-provisioning from a browser. Anders > -- T > > > On Aug 25, 2011, at 3:05 PM, Anders Rundgren wrote: > >> With a hope to shed some light regarding enrollment protocols the following may be of some interest. >> >> KeyGen2 is not a Certificate Enrollment protocol; it is a Token (cryptographic module) Provisioning protocol. >> >> Unlike Certificate Enrollment which essentially only requires a request-response pair where the response (certificate) can be securely derived to request, Token Provisioning usually needs additional steps before and after the core message exchange as well. >> >> Also in contrast to Certificate Enrollment protocols, Token Provisioning always targets a specific token container. >> If secure Token Provisioning is to be performed by remote users over the Internet, E2ES (end-to-end-security) must be enforced, and preferably throughout the entire process. >> >> Since E2ES cannot be abstracted, a prerequisite is that the issuer and token speak the same language. >> This obviously thickens the plot considerably unless you also standardize the token (with respect to provisioning NB), which was the sole motivation behind KeyGen2's alter ago, the SKS. >> >> KeyGen2/SKS in similarity to GlobalPlatform relies on a very light-weight security mechanism based on session keys and a two-level client where the provisioning middleware does the "heavy lifting" and handle user interactions, while the token exclusively deals with low-level E2ES-centric operations. >> >> Token Provisioning in browsers is currently entirely based on third-party proprietary and mostly secret "plugins". >> >> Anders Rundgren >> http://webpki.org/auth-token-4-the-cloud.html >> _______________________________________________ >> 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 --------------060903020001040500070109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2011-08-26 14:39, Miller, Timothy J. wrote: 
So I keep wondering where the right forum for this discussion is.  Clearly token management has an interface with PKI systems, but that's as far as it goes.  I don't think TMS standards are in scope here, but then I don't know a body where it would be *in* scope.

You are absolutely correct!  This is outside of what any SDO could possible deal with.  Not even TrustedComputingGroup which I'm an invited expert member of dared addressing TPM key-provisioning from a browser.

Anders

-- T


On Aug 25, 2011, at 3:05 PM, Anders Rundgren wrote:


With a hope to shed some light regarding enrollment protocols the following may be of some interest.

KeyGen2 is not a Certificate Enrollment protocol; it is a Token (cryptographic module) Provisioning protocol.

Unlike Certificate Enrollment which essentially only requires a request-response pair where the response (certificate) can be securely derived to request, Token Provisioning usually needs additional steps before and after the core message exchange as well.

Also in contrast to Certificate Enrollment protocols, Token Provisioning always targets a specific token container.
If secure Token Provisioning is to be performed by remote users over the Internet, E2ES (end-to-end-security) must be enforced, and preferably throughout the entire process.

Since E2ES cannot be abstracted, a prerequisite is that the issuer and token speak the same language.
This obviously thickens the plot considerably unless you also standardize the token (with respect to provisioning NB), which was the sole motivation behind KeyGen2's alter ago, the SKS.

KeyGen2/SKS in similarity to GlobalPlatform relies on a very light-weight security mechanism based on session keys and a two-level client where the provisioning middleware does the "heavy lifting" and handle user interactions, while the token exclusively deals with low-level E2ES-centric operations.

Token Provisioning in browsers is currently entirely based on third-party proprietary and mostly secret "plugins".

Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html
_______________________________________________
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


    

    

  


--------------060903020001040500070109--

From tmiller@mitre.org  Fri Aug 26 06:16:31 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAE621F87D9 for ; Fri, 26 Aug 2011 06:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgjVoCZAFwtj for ; Fri, 26 Aug 2011 06:16:31 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE2521F85AA for ; Fri, 26 Aug 2011 06:16:31 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4D8EB21B145C; Fri, 26 Aug 2011 09:17:47 -0400 (EDT)
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 450A121B1455; Fri, 26 Aug 2011 09:17:47 -0400 (EDT)
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 26 Aug 2011 09:17:47 -0400
From: "Miller, Timothy J." 
To: Peter Gutmann 
Date: Fri, 26 Aug 2011 09:17:45 -0400
Thread-Topic: [pkix] EST-02 smart card question
Thread-Index: Acxj8ov+bn9ujCv5TR+TpRIQc3garg==
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-7-1050016400"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] EST-02 smart card question
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 13:16:31 -0000

--Apple-Mail-7-1050016400
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Aug 24, 2011, at 11:49 PM, Peter Gutmann wrote:

> Works just as well under Linux (and, presumably, OS X, although I've =
never=20
> really seen that used on corporate desktops outside art/graphics =
departments=20
> so that's by extrapolation from the Linux/Unix situation) using =
virtual USB=20
> port redirection.  It's actually even less secure than the Windows =
version=20
> because Windows at least uses RDP security while Linux just does =
USB-over-TCP,
> and I'm not aware of anyone considering it worth tunnelling over SSH.

Sun implemented USB redirection into the rdesktop distributed with the =
commercial version of VirtualBox, so a UNIX implementation of USB/RDP is =
technically available (but not open source).

IIRC, ssh-agent can be made to redirect smart card based credentials, =
but it's been forever since I toyed with it.

-- T



--Apple-Mail-7-1050016400
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw
ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy
PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7
RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ
t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8
rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I
ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd
dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw
0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F
UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v
Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xMTA4MjYxMzE3NDVaMCMGCSqGSIb3DQEJBDEWBBTdU3i+GDXxnO4hGU6z
hN2ou/TWjjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5
IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgBAtycbK2DJD8DEzuW9StnwGL3oj//9n8yCn
wGwKWFDNE79K9u8oyp/az3PWJqxTomb8U2CwVnrK+gKthkBMDkpOi4cpJTU9N78UH+vJZtV3ySxq
AtzGCAgtiTIb456dp90wdH+R8FF/QAaqODvBEKOTPQo82n832EPJb8FHgSobAAAAAAAA

--Apple-Mail-7-1050016400--

From tmiller@mitre.org  Fri Aug 26 06:17:21 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D4B21F89B8 for ; Fri, 26 Aug 2011 06:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62jLmEpkpbtA for ; Fri, 26 Aug 2011 06:17:21 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 391B121F85AA for ; Fri, 26 Aug 2011 06:17:21 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5CFB221B124C; Fri, 26 Aug 2011 09:18:37 -0400 (EDT)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5516521B0622; Fri, 26 Aug 2011 09:18:37 -0400 (EDT)
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 26 Aug 2011 09:18:37 -0400
From: "Miller, Timothy J." 
To: Stephen Kent 
Date: Fri, 26 Aug 2011 09:18:35 -0400
Thread-Topic: [pkix] EST-02 smart card question
Thread-Index: Acxj8qmvPfjfWArgSSaLvxDqDwidnA==
Message-ID: <98F7988F-6498-4B9A-BA80-5112BBCC3691@mitre.org>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-8-1050066812"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] EST-02 smart card question
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 13:17:21 -0000

--Apple-Mail-8-1050066812
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Aug 25, 2011, at 2:21 PM, Stephen Kent wrote:

> Also, for the CAC case, there are other considerations that make this =
seem
> an unlikely scenario. CACs are often THE Giv issued photo ID for their =
holders,
> so one is not likely to go far away from a machine that is holding =
one's CAC.
> In some contexts, the CAC is intended to be used for physical access =
control
> too, which means that one might not be able to go very far, =
physically, w/o
> one's CAC.

Except for the user at home.

-- T


--Apple-Mail-8-1050066812
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw
ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy
PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7
RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ
t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8
rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I
ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd
dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw
0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F
UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v
Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xMTA4MjYxMzE4MzZaMCMGCSqGSIb3DQEJBDEWBBTQY587WBbuXlVfCoY0
0PcS2JyiYDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5
IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgI9MTxi74kKizu1g2EQcjpiIwT2qTkaHEmMi
a8ezB1Hp6ScdoSOOrXoLVRk71/sL/bhZjPO7WG0N6vxfiLng2cNzCFyoSF8hQNWKJn2ToHIcPC7K
Rh9mceOK+fayPw94GOi++EsVb0Tp3ioRdrlvjl6PcQA5wPp/YUM4P6Bw2iGtAAAAAAAA

--Apple-Mail-8-1050066812--

From joneswm@us.ibm.com  Fri Aug 26 09:08:36 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCC821F8C6B for ; Fri, 26 Aug 2011 09:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level: 
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M91ol0-k9rnA for ; Fri, 26 Aug 2011 09:08:35 -0700 (PDT)
Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD1621F8C15 for ; Fri, 26 Aug 2011 09:08:35 -0700 (PDT)
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7QEnxnW018552 for ; Fri, 26 Aug 2011 10:49:59 -0400
Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7QG9nHK174110 for ; Fri, 26 Aug 2011 12:09:50 -0400
Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7QG9j3S009445 for ; Fri, 26 Aug 2011 10:09:45 -0600
Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7QG9jYt009440 for ; Fri, 26 Aug 2011 10:09:45 -0600
Auto-Submitted: auto-generated
From: Wendy Jones 
To: pkix@ietf.org
Message-ID: 
Date: Fri, 26 Aug 2011 10:09:43 -0600
X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V853_CD5_06022011|June 02, 2011) at 08/26/2011 10:09:45
MIME-Version: 1.0
Content-type: multipart/alternative;  Boundary="0__=08BBF26BDFCB4E978f9e8a93df938690918c08BBF26BDFCB4E97"
Content-Disposition: inline
Subject: [pkix] AUTO: Wendy Jones/Raleigh/IBM is out of the office. (returning 08/30/2011)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 16:08:36 -0000

--0__=08BBF26BDFCB4E978f9e8a93df938690918c08BBF26BDFCB4E97
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable



I am out of the office until 08/30/2011.

I will have no access to voice-mail and e-mail until I return.

As a result, if you require immediate assistance, please contact my bac=
kup
via the C&SI central id:
AMSCGRLS@us.ibm.com  or  AMS Centralized GR
Landing-Support/Poughkeepsie/IBM

Otherwise, I will respond to you after I return to the office.

Thanks and have a great day.
Wendy


Note: This is an automated response to your message  "pkix Digest, Vol =
25,
Issue 26" sent on 08/26/2011 7:08:19.

This is the only notification you will receive while this person is awa=
y.=

--0__=08BBF26BDFCB4E978f9e8a93df938690918c08BBF26BDFCB4E97
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable



I am out of the office until 08=
/30/2011.



I will have no access to vo=
ice-mail and e-mail until I return.



As a result, if you require=
 immediate assistance, please contact my backup via the C&SI centra=
l id:  

AMSCGRLS@us.ibm.com  o=
r  AMS Centralized GR Landing-Support/Poughkeepsie/IBM



Otherwise, I will respond t=
o you after I return to the office.



Thanks and have a great day=
.

Wendy





Note: Thi=
s is an automated response to your message  "pkix Digest, Vol 25, Issue 26"<=
/font> sent=
 on 08/26/2011 7:08:19. 



This is t=
he only notification you will receive while this person is away.=
=

--0__=08BBF26BDFCB4E978f9e8a93df938690918c08BBF26BDFCB4E97--


From SChokhani@cygnacom.com  Fri Aug 26 09:25:25 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D746521F8C8F for ; Fri, 26 Aug 2011 09:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.266
X-Spam-Level: 
X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqnRbcm4y4KU for ; Fri, 26 Aug 2011 09:25:25 -0700 (PDT)
Received: from mail166.messagelabs.com (mail166.messagelabs.com [216.82.253.163]) by ietfa.amsl.com (Postfix) with ESMTP id 26C3D21F8C89 for ; Fri, 26 Aug 2011 09:25:24 -0700 (PDT)
X-Env-Sender: SChokhani@cygnacom.com
X-Msg-Ref: server-8.tower-166.messagelabs.com!1314375998!7693554!1
X-Originating-IP: [216.191.252.21]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11217 invoked from network); 26 Aug 2011 16:26:40 -0000
Received: from sottexche1.entrust.com (HELO sottexchE1.entrust.com) (216.191.252.21) by server-8.tower-166.messagelabs.com with AES128-SHA encrypted SMTP; 26 Aug 2011 16:26:40 -0000
Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE1.entrust.com (216.191.252.21) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 26 Aug 2011 12:26:13 -0400
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 26 Aug 2011 12:26:38 -0400
From: Santosh Chokhani 
To: "Miller, Timothy J." 
Date: Fri, 26 Aug 2011 12:26:36 -0400
Thread-Topic: [pkix] EST-02 smart card question
Thread-Index: Acxj8aqF2T9iYm7GRNixv7bJXb1xVwAGyfjA
Message-ID: 
References:    <248350F5-755E-4FFD-8444-05684506B260@mitre.org>
In-Reply-To: <248350F5-755E-4FFD-8444-05684506B260@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] EST-02 smart card question
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 16:25:26 -0000

Security is still a function of the end machine and security of trusted pat=
h/channel.

-----Original Message-----
From: Miller, Timothy J. [mailto:tmiller@mitre.org]
Sent: Friday, August 26, 2011 9:11 AM
To: Santosh Chokhani
Cc: Peter Gutmann; anders.rundgren@telia.com; kent@bbn.com; pkix@ietf.org
Subject: Re: [pkix] EST-02 smart card question


On Aug 24, 2011, at 8:07 AM, Santosh Chokhani wrote:

> I see the comment.
>
> But, is this really anything new?
>
> We all know that any hardware crypto module is at the mercy of the host i=
nvoking it.  If the host has a Trojan or is misconfigured, the crypto modul=
e as secret and private keys in it can be misused.

Trusted activation pathways are possible, but tend to be more expensive tha=
n just "dumb reader, smart card."

-- T



From anders.rundgren@telia.com  Fri Aug 26 10:48:02 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D24121F8C37 for ; Fri, 26 Aug 2011 10:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3HyUjmS2evT for ; Fri, 26 Aug 2011 10:48:01 -0700 (PDT)
Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4762F21F8C17 for ; Fri, 26 Aug 2011 10:48:01 -0700 (PDT)
Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E970097C165; Fri, 26 Aug 2011 19:48:58 +0200
Message-ID: <4E57DC86.4060404@telia.com>
Date: Fri, 26 Aug 2011 19:48:54 +0200
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: Santosh Chokhani 
References:    <248350F5-755E-4FFD-8444-05684506B260@mitre.org> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] EST-02 smart card question
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2011 17:48:02 -0000

On 2011-08-26 18:26, Santosh Chokhani wrote:
> Security is still a function of the end machine and security of trusted path/channel.

Sort of related.  The stuff described in

http://www.ietf.org/mail-archive/web/pkix/current/msg29682.html

is also intended to support "ACLs" for keys so that an issuer can
discriminate access to keys residing in a common key-store.

This mechanism obviously depends on that the OS is "healthy".

The problem is really finding a universally useful way of expressing
this so that issuers do not have to know everything about the client
platform.  Signed apps seems like a prerequisite.

I doubt that PCs will ever be able to use this, but in mobile
phones it should be possible.  A slight crux is the frequent use of
non-native code like Java which makes the trusted path a bit fuzzy.

Bank people have explained that this feature is a "SHOULD" while
token PINs and associated policies are a "MUST".

Anders

> 
> -----Original Message-----
> From: Miller, Timothy J. [mailto:tmiller@mitre.org]
> Sent: Friday, August 26, 2011 9:11 AM
> To: Santosh Chokhani
> Cc: Peter Gutmann; anders.rundgren@telia.com; kent@bbn.com; pkix@ietf.org
> Subject: Re: [pkix] EST-02 smart card question
> 
> 
> On Aug 24, 2011, at 8:07 AM, Santosh Chokhani wrote:
> 
>> I see the comment.
>>
>> But, is this really anything new?
>>
>> We all know that any hardware crypto module is at the mercy of the host invoking it.  If the host has a Trojan or is misconfigured, the crypto module as secret and private keys in it can be misused.
> 
> Trusted activation pathways are possible, but tend to be more expensive than just "dumb reader, smart card."
> 
> -- T
> 
> 
> 


From anders.rundgren@telia.com  Fri Aug 26 23:48:28 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2734721F8AAA for ; Fri, 26 Aug 2011 23:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level: 
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPAWA4ePw5YH for ; Fri, 26 Aug 2011 23:48:27 -0700 (PDT)
Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4753D21F8A67 for ; Fri, 26 Aug 2011 23:48:26 -0700 (PDT)
Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E970098F1EF for pkix@ietf.org; Sat, 27 Aug 2011 08:49:43 +0200
Message-ID: <4E589383.7050309@telia.com>
Date: Sat, 27 Aug 2011 08:49:39 +0200
From: Anders Rundgren 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: "pkix@ietf.org" 
X-Enigmail-Version: 1.1.1
Content-Type: multipart/alternative; boundary="------------050506070706060004020304"
Subject: [pkix] EST-02 and PIN-codes
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Aug 2011 06:48:28 -0000

This is a multi-part message in MIME format.
--------------050506070706060004020304
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

It has been mentioned in various list and off-list communication that associating an issuer-defined PIN-code to a deployed key in a token could be achieved by for example adding an attribute to the
certificate response.

However, this requires that the token runs in "Administrator Mode" which it does in traditional CMSes (Card Management Systems).

I maintain that performing token provisioning using a [future] standard browser in a /secure/, /scalable /and /user-friendly/ way is /_infeasible_/ based on current token technology since the latter
was neither designed to support end-user provisioning nor dealing with independent issuers.

In the SKS token, the administrator role is virtualized per issuer and doesn't require the middleware impersonating a token administrator.  The user's ability to change PINs etc is /unilaterally/
determined by each issuer's unique policy.  AFAICT, this assumes a full-blown E2ES (End To End Security) model.

The user's administrative capability is essentially limited to key delete operations and granting an issuer the right creating a key.

Anders

--------------050506070706060004020304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  

    
  
  
    It has been mentioned in various list and off-list communication
    that associating an issuer-defined PIN-code to a deployed key in a
    token could be achieved by for example adding an attribute to the
    certificate response.

    

    However, this requires that the token runs in "Administrator Mode"
    which it does in traditional CMSes (Card Management Systems).

    

    I maintain that performing token provisioning using a [future]
    standard browser in a secure, scalable and user-friendly
    way is infeasible based on current token technology
    since the latter was neither designed to support end-user
    provisioning nor dealing with independent issuers.

    

    In the SKS token, the administrator role is virtualized per issuer
    and doesn't require the middleware impersonating a token
    administrator.  The user's ability to change PINs etc is unilaterally
    determined by each issuer's unique policy.  AFAICT, this assumes a
    full-blown E2ES (End To End Security) model.

    

    The user's administrative capability is essentially limited to key
    delete operations and granting an issuer the right creating a key.

    

    Anders

  


--------------050506070706060004020304--

From kent@bbn.com  Sat Aug 27 09:00:42 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C1221F886D for ; Sat, 27 Aug 2011 09:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.555
X-Spam-Level: 
X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsiwLG96BpGZ for ; Sat, 27 Aug 2011 09:00:41 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3A33421F880C for ; Sat, 27 Aug 2011 09:00:40 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:47610 helo=[10.242.10.130]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QxLKW-0000hk-Py; Sat, 27 Aug 2011 12:01:57 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4E56F15B.90200@e-net.lt>
References:  <4E56F15B.90200@e-net.lt>
Date: Sat, 27 Aug 2011 09:18:01 -0400
To: "Moudrick M. Dadashov" 
From: Stephen Kent 
Content-Type: multipart/alternative; boundary="============_-897661580==_ma============"
Cc: pkix@ietf.org
Subject: Re: [pkix] EST-02 smart card question
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Aug 2011 16:00:42 -0000

--============_-897661580==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 4:05 AM +0300 8/26/11, Moudrick M. Dadashov wrote:
>On 8/26/2011 1:48 AM, Peter Gutmann wrote:
>
>>Stephen Kent  writes:
>>
>>>At 11:07 AM +0300 8/25/11, Moudrick M. Dadashov wrote:
>>>
>>>>...
>>>>Do you see any problems when this scenario is implemented on a dedicated
>>>>1:1 or 1:n communication channel?
>>>>
>>>I don't know how to interpret your comment.  can you provide additional
>>>context?
>>>
>>That was going to be my reply as well: Which scenario, what problem are you
>>trying to solve, and what's the threat model?
>>
>>Peter.
>>
>The scenario: I've a remote http server with his key pair stored on 
>a secure device (eToken). The server can be accessed only through an 
>authenticated vpn connection. I was asking do you see any problem if 
>the eToken on the server remains unlocked for further sessions after 
>once entering the PIN (cached password etc.)?
>
>Thenks,
>M.D.

Thanks for the clarification.  In this scenario, if the token is being used to
protect the private key of the server, not a person accessing the server, then
there is no issue. if the key in the token represents a user, then there might
be concerns, oin a broader secruity context.

Steve
--============_-897661580==_ma============
Content-Type: text/html; charset="us-ascii"


Re: [pkix] EST-02 smart card
question

At 4:05 AM +0300 8/26/11, Moudrick M. Dadashov wrote:


On 8/26/2011 1:48 AM, Peter Gutmann
wrote:


Stephen Kent <kent@bbn.com>
writes:


At 11:07 AM +0300 8/25/11, Moudrick
M. Dadashov wrote:


...

Do you see any problems when this scenario is implemented on a
dedicated

1:1 or 1:n communication channel?






I don't know how to interpret your
comment.  can you provide additional

context?






That was going to be my reply as
well: Which scenario, what problem are you

trying to solve, and what's the threat model?



Peter.






The scenario: I've a remote http server
with his key pair stored on a secure device (eToken). The server can
be accessed only through an authenticated vpn connection. I was asking
do you see any problem if the eToken on the server remains unlocked
for further sessions after once entering the PIN (cached password
etc.)?



Thenks,


M.D.   





Thanks for the clarification.  In this scenario, if the
token is being used to


protect the private key of the server, not a person accessing the
server, then


there is no issue. if the key in the token represents a user,
then there might


be concerns, oin a broader secruity context.





Steve



--============_-897661580==_ma============--

From kent@bbn.com  Sat Aug 27 09:00:57 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2662C21F8564 for ; Sat, 27 Aug 2011 09:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.556
X-Spam-Level: 
X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwq2PIaGRcXB for ; Sat, 27 Aug 2011 09:00:55 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BB15F21F8551 for ; Sat, 27 Aug 2011 09:00:55 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:47610 helo=[10.242.10.130]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QxLKo-0000hk-Bz; Sat, 27 Aug 2011 12:02:14 -0400
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <98F7988F-6498-4B9A-BA80-5112BBCC3691@mitre.org>
References:   <98F7988F-6498-4B9A-BA80-5112BBCC3691@mitre.org>
Date: Sat, 27 Aug 2011 09:24:00 -0400
To: "Miller, Timothy J." 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] EST-02 smart card question
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Aug 2011 16:00:57 -0000

At 9:18 AM -0400 8/26/11, Miller, Timothy J. wrote:
>On Aug 25, 2011, at 2:21 PM, Stephen Kent wrote:
>
>>  Also, for the CAC case, there are other considerations that make this seem
>>  an unlikely scenario. CACs are often THE Giv issued photo ID for 
>>their holders,
>>  so one is not likely to go far away from a machine that is holding 
>>one's CAC.
>>  In some contexts, the CAC is intended to be used for physical access control
>>  too, which means that one might not be able to go very far, physically, w/o
>>  one's CAC.
>
>Except for the user at home.
>
>-- T

Just remember the Amex slogan: "Don't leave home without the card."

Steve

From md@e-net.lt  Sat Aug 27 15:08:31 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE5E21F8B72 for ; Sat, 27 Aug 2011 15:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htIIbn3V6wld for ; Sat, 27 Aug 2011 15:08:30 -0700 (PDT)
Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 35C2E21F8B70 for ; Sat, 27 Aug 2011 15:08:30 -0700 (PDT)
Received: from lan-84-240-23-136.vln.skynet.lt ([84.240.23.136] helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1QxR45-0002oB-Qx; Sun, 28 Aug 2011 01:09:21 +0300
Message-ID: <4E596B11.2060406@e-net.lt>
Date: Sun, 28 Aug 2011 01:09:21 +0300
From: "Moudrick M. Dadashov" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Stephen Kent 
References:  <4E56F15B.90200@e-net.lt> 
In-Reply-To: 
X-Stationery: 0.7.5
Content-Type: multipart/alternative; boundary="------------010606030608010107070106"
Cc: pkix@ietf.org
Subject: Re: [pkix] EST-02 smart card question
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Aug 2011 22:08:31 -0000

This is a multi-part message in MIME format.
--------------010606030608010107070106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 8/27/2011 4:18 PM, Stephen Kent wrote:
> At 4:05 AM +0300 8/26/11, Moudrick M. Dadashov wrote:
>> On 8/26/2011 1:48 AM, Peter Gutmann wrote:
>>> Stephen Kent  writes:
>>>> At 11:07 AM +0300 8/25/11, Moudrick M. Dadashov wrote:
>>>>> ...
>>>>> Do you see any problems when this scenario is implemented on a 
>>>>> dedicated
>>>>> 1:1 or 1:n communication channel?
>>>> I don't know how to interpret your comment.  can you provide additional
>>>> context?
>>> That was going to be my reply as well: Which scenario, what problem 
>>> are you
>>> trying to solve, and what's the threat model?
>>>
>>> Peter.
>> The scenario: I've a remote http server with his key pair stored on a 
>> secure device (eToken). The server can be accessed only through an 
>> authenticated vpn connection. I was asking do you see any problem if 
>> the eToken on the server remains unlocked for further sessions after 
>> once entering the PIN (cached password etc.)?
>>
>> Thenks,
>> M.D. 
>
> Thanks for the clarification.  In this scenario, if the token is being 
> used to
> protect the private key of the server, not a person accessing the 
> server, then
> there is no issue. if the key in the token represents a user, then 
> there might
> be concerns, oin a broader secruity context.
>
> Steve
Yes, the eToken holds server's private key in this case.

Thanks,
M.D.

--------------010606030608010107070106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    On 8/27/2011 4:18 PM, Stephen Kent wrote:
    

      
      Re: [pkix] EST-02 smart card
        question
      
At 4:05 AM +0300 8/26/11, Moudrick M. Dadashov wrote:

      
On 8/26/2011
        1:48 AM, Peter Gutmann
        wrote:

        
Stephen
            Kent <kent@bbn.com>
            writes:

          
At
              11:07 AM +0300 8/25/11, Moudrick
              M. Dadashov wrote:

            
...

                Do you see any problems when this scenario is
                implemented on a
                dedicated

                1:1 or 1:n communication channel?

            

          

          
I
              don't know how to interpret your
              comment.  can you provide additional

              context?

          

        

        
That was
            going to be my reply as
            well: Which scenario, what problem are you

            trying to solve, and what's the threat model?

            

            Peter.

          

      

      
The scenario:
        I've a remote http server
        with his key pair stored on a secure device (eToken). The server
        can
        be accessed only through an authenticated vpn connection. I was
        asking
        do you see any problem if the eToken on the server remains
        unlocked
        for further sessions after once entering the PIN (cached
        password
        etc.)?

        

        Thenks,

      
M.D.   

      


      

      
Thanks for the clarification.  In this scenario, if the
        token is being used to

      
protect the private key of the server, not a person accessing
        the
        server, then

      
there is no issue. if the key in the token represents a user,
        then there might

      
be concerns, oin a broader secruity context.

      


      

      
Steve

    

    Yes, the eToken holds server's private key in this case.

    

    Thanks,

    M.D.

  


--------------010606030608010107070106--

From jmdesp@free.fr  Sun Aug 28 19:21:38 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9F621F86BE for ; Sun, 28 Aug 2011 19:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level: 
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X+cZrni-alY for ; Sun, 28 Aug 2011 19:21:37 -0700 (PDT)
Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECBA21F86B6 for ; Sun, 28 Aug 2011 19:21:35 -0700 (PDT)
Received: from [IPv6:2a01:e35:2f1a:f7d0:f8d4:3012:db67:6fe8] (unknown [IPv6:2a01:e35:2f1a:f7d0:f8d4:3012:db67:6fe8]) by smtp1-g21.free.fr (Postfix) with ESMTP id 707C6940069 for ; Mon, 29 Aug 2011 04:22:52 +0200 (CEST)
Message-ID: <4E5AF801.3000209@free.fr>
Date: Mon, 29 Aug 2011 04:22:57 +0200
From: Jean-Marc Desperrier 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0a2) Gecko/20110821 Thunderbird/8.0a2
MIME-Version: 1.0
To: pkix@ietf.org
References: <20110824190621.60FD521F8B14@ietfa.amsl.com>
In-Reply-To: <20110824190621.60FD521F8B14@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] CRL and OCSP signer certs
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2011 02:21:38 -0000

On 24/08/2011 21:07, Michael StJohns wrote:
> After pawing through 5280 et al, I'm unclear of whether or not the 
> cRLSign keyUsage bit can be asserted in a non-CA certificate (a 
> certificate where the basicConstraints extension is missing, or where 
> cA is FALSE in such extension).
There's existing usage of that. I believe X509 makes it clearer it's 
possible.
> Do certificates that "contain public keys used exclusively for 
> purposes other than validating digital signatures on certificates" 
> need to be  or should they be CA certificates?
This depends on what setting the CA bit to true is *precisely* supposed 
to mean.
They are varying interpretations and it's never been settled which one 
*exactly* is the correct one.

Based on the fact a number of CRL issuer don't set the CA bit to true, 
the most restrictive of the interpretations, "CA is set to say this 
certificate issues other certificate, basically redondant with 
keyCertSign keyusage", should be the correct one for that existing usage 
to be correct.

With the more extensive interpretations, "CA to true means the entity 
that controls the cert is a CA", or "CA to true means the DN of this 
cert designates a CA entity", many of those CRL issuers ought to have 
set CA to true, and didn't.

I know one software that assumes CRL issuer don't have the CA bit set to 
true, but that software actually is hand tailored for the one CRL issuer 
certificate using CA it supports.



From peter.sylvester@edelweb.fr  Wed Aug 31 09:13:19 2011
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0328D21F8BB7 for ; Wed, 31 Aug 2011 09:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.195
X-Spam-Level: 
X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_24=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk-5MwuMZuFp for ; Wed, 31 Aug 2011 09:13:18 -0700 (PDT)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 32E9F21F8B05 for ; Wed, 31 Aug 2011 09:13:18 -0700 (PDT)
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id C798281F2 for ; Wed, 31 Aug 2011 18:14:46 +0200 (CEST)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 9BE9016FDB for ; Wed, 31 Aug 2011 18:14:31 +0200 (CEST)
Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTP id AC1657824 for ; Wed, 31 Aug 2011 18:14:46 +0200 (CEST)
Message-ID: <4E5E5DF7.6040508@edelweb.fr>
Date: Wed, 31 Aug 2011 18:14:47 +0200
From: Peter Sylvester 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12
MIME-Version: 1.0
To: pkix@ietf.org
References: <20110824190621.60FD521F8B14@ietfa.amsl.com> <4E5AF801.3000209@free.fr>
In-Reply-To: <4E5AF801.3000209@free.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] CRL and OCSP signer certs
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Aug 2011 16:13:19 -0000

On 08/29/2011 04:22 AM, Jean-Marc Desperrier wrote:
> On 24/08/2011 21:07, Michael StJohns wrote:
>> After pawing through 5280 et al, I'm unclear of whether or not the 
>> cRLSign keyUsage bit can be asserted in a non-CA certificate (a 
>> certificate where the basicConstraints extension is missing, or where 
>> cA is FALSE in such extension).
> There's existing usage of that. I believe X509 makes it clearer it's 
> possible.

yes.

>> Do certificates that "contain public keys used exclusively for 
>> purposes other than validating digital signatures on certificates" 
>> need to be  or should they be CA certificates?
> This depends on what setting the CA bit to true is *precisely* 
> supposed to mean.
> They are varying interpretations and it's never been settled which one 
> *exactly* is the correct one.
Unless I have overlooked something, I don' think that there is something 
that remains to be settled:
>
> Based on the fact a number of CRL issuer don't set the CA bit to true, 
> the most restrictive of the interpretations, "CA is set to say this 
> certificate issues other certificate, basically redondant with 
> keyCertSign keyusage", should be the correct one for that existing 
> usage to be correct.
But this is not the case. It is not written like that and the
the logical function is to combine certsign and CA=true with a logical 
AND, not OR.
if you want to validate a certificate that has signed another one. Both 
extensions must be present.

IMO this seems to be an invalid interpretation.

There may be historical software that only looks at CA=true.  BUT, since 
RFC 5280 requires keyusage
to be a critical extension in conformant certs, software that does not 
recognize keyusage would
not accept a certsign cert if they don't understand keyusage (hoping 
that the software understands "critical".)

Anyway, we are not talking about certSign.
 >
 > With the more extensive interpretations, "CA to true means the entity 
that controls the cert is a CA", or "CA to true means the DN of this 
cert designates a CA entity", many of those CRL issuers ought to have 
set CA to true, and didn't.

There is nothing in the text that relates crlSign with basicconstraints. 
Any cert that has no certSign can have any value of the CA boolean.
It is not verified by any of the rules concerning these keyusage fields.

If some verifier requires any particular setting of basicconstraints 
during validation a a CRLsigner cert, the
verifier seems wrong to me.

IMO "ought to have" has no standing.

>
> I know one software that assumes CRL issuer don't have the CA bit set 
> to true, but that software actually is hand tailored for the one CRL 
> issuer certificate using CA it supports.
See above.

regards
/P