From shawn.emery@oracle.com Tue Jun 1 00:43:39 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB783A68BD; Tue, 1 Jun 2010 00:43:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPsAyOw4SVKR; Tue, 1 Jun 2010 00:43:38 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 10B5A3A6824; Tue, 1 Jun 2010 00:43:38 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o517hKZ9017027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jun 2010 07:43:22 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o517Saon011978; Tue, 1 Jun 2010 07:43:19 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 312300221275378176; Tue, 01 Jun 2010 00:42:56 -0700 Received: from [129.150.48.63] (/129.150.48.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 00:42:55 -0700 Message-ID: <4C04B9FE.2090804@oracle.com> Date: Tue, 01 Jun 2010 01:42:54 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: kitten@ietf.org, sasl@ietf.org Subject: Kitten Recharter Content-Type: multipart/mixed; boundary="------------060805080206080204000308" X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090201.4C04BA1C.01BA:SCFMA4539811,ss=1,fgs=0 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 07:43:39 -0000 This is a multi-part message in MIME format. --------------060805080206080204000308 Content-Type: multipart/alternative; boundary="------------040107090009090306070208" --------------040107090009090306070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Per the recent thead on "MOGGIES Proposed Charter"; I have taken suggestions by kitten/SASL WG members and created recharter text for Kitten (whilst closing SASL). Please let me know if I missed anything. Shawn. Kitten co-chair. -- --------------040107090009090306070208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Per the recent thead on "MOGGIES Proposed Charter"; I have taken suggestions by kitten/SASL WG members and created recharter text for Kitten (whilst closing SASL).  Please let me know if I missed anything.

Shawn.
Kitten co-chair.
--

--------------040107090009090306070208-- --------------060805080206080204000308 Content-Type: text/plain; name="kitten-recharter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kitten-recharter.txt" Kitten (Common Authentication Technology Next Generation) Description of Working Group: The Generic Security Services (GSS) API and Simple Authentication and Security Layer (SASL) provide various applications with a security framework for secure network communication. The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL-related submissions. This working is chartered to specify the following extensions and improvements (draft-yu-kitten-api-wishlist-00) to the GSS-API: * Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials * Specify interface for asynchronous calls. * Define interfaces for better error message reporting. * Provide a more programmer friendly interface for application developers. This WG is also chartered to transition proposed SASL mechanisms as GSS-API mechanisms: * A SASL Mechanism for OpenID draft-lear-ietf-sasl-openid-00 * A SASL Mechanism for SAML draft-wierenga-ietf-sasl-saml-00 The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations that support the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2). * Shepard draft-melnikov-digest-to-historic through standards track. This WG should review proposals for new SASL and GSS-API mechanisms. The WG should also review non-mechanism proposals related to SASL and the GSS-API. Deliverables: * GSS-API: initializing credentials [editor: TBD] * GSS-API: iterating credentials [editor: TBD] * GSS-API: exporting/importing credentials [editor: TBD] * GSS-API: specification for asynchronous calls [editor: TBD] * GSS-API: interfaces/improvements for better error message reporting [editor: TBD] * GSS-API: programmer friendly interfaces [editor: TBD] * GSS-API: transition SASL mechanism for OpenID [editor: TBD] * GSS-API: transition SASL mechanism for SAML [editor: TBD] * GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana [editor: Nicolas Williams] * GSS-API: publish draft-ietf-kitten-gssapi-naming-exts [editor: Leif Johansson] * SASL: publish draft-melnikov-digest-to-historic [editor: Alexey Melnikov] Goals and Milestones: June 2010 Submit publish draft-ietf-kitten-gssapi-naming-exts to the IESG as Proposed Standard June 2010 WGLC, again, on draft-ietf-kitten-gssapi-extensions-iana July 2010 Submit draft-ietf-kitten-gssapi-extensions-iana to the IESG as Proposed Standard July 2010 First Meeting TBD Other Listed Work Items --------------060805080206080204000308-- From shawn.emery@oracle.com Tue Jun 8 16:19:52 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059403A6826 for ; Tue, 8 Jun 2010 16:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtw-WWWfhaqS for ; Tue, 8 Jun 2010 16:19:50 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BF36D3A684C for ; Tue, 8 Jun 2010 16:19:45 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o58NJikP004769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Jun 2010 23:19:46 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o58Cdthp027866 for ; Tue, 8 Jun 2010 23:19:43 GMT Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 331330641276039098; Tue, 08 Jun 2010 16:18:18 -0700 Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jun 2010 16:18:18 -0700 Message-ID: <4C0ECFB9.7080900@oracle.com> Date: Tue, 08 Jun 2010 17:18:17 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: kitten@ietf.org Subject: extensions-iana registry Content-Type: multipart/alternative; boundary="------------000401050709060507080307" X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090202.4C0ED012.0089:SCFMA4539811,ss=1,fgs=0 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 23:19:52 -0000 This is a multi-part message in MIME format. --------------000401050709060507080307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Based on IANA feed-back; the WG needs to reach consensus on how the GSS-API extensions are to be registered. Options proposed: 1. single GSS-API name-space registry 2. separate registry - symbolic and constant registries 3. registry per programming language 4. multiple registries ... Time-out is in two weeks (ending 6/22/10). My preference is option 1. Shawn kitten co-chair. -- --------------000401050709060507080307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Based on IANA feed-back; the WG needs to reach consensus on how the GSS-API extensions are to be registered.  Options proposed:

    1. single GSS-API name-space registry
    2. separate registry - symbolic and constant registries
    3. registry per programming language
    4. multiple registries
    ...

Time-out is in two weeks (ending 6/22/10).

</co-chair> My preference is option 1.

Shawn kitten co-chair.
--
--------------000401050709060507080307-- From stpeter@stpeter.im Tue Jun 8 18:21:01 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8287F3A682D for ; Tue, 8 Jun 2010 18:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj7NK6EBN6IJ for ; Tue, 8 Jun 2010 18:21:00 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 849B53A67A4 for ; Tue, 8 Jun 2010 18:21:00 -0700 (PDT) Received: from squire.local (dsl-240-39.dynamic-dsl.frii.net [216.17.240.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8969D40CFD for ; Tue, 8 Jun 2010 19:21:01 -0600 (MDT) Message-ID: <4C0EEC7C.9030707@stpeter.im> Date: Tue, 08 Jun 2010 19:21:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: kitten@ietf.org Subject: Re: extensions-iana registry References: <4C0ECFB9.7080900@oracle.com> In-Reply-To: <4C0ECFB9.7080900@oracle.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020409010702000902070606" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 01:21:01 -0000 This is a cryptographically signed message in MIME format. --------------ms020409010702000902070606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/8/10 5:18 PM, Shawn Emery wrote: > 1. single GSS-API name-space registry That's my vote. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020409010702000902070606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwOTAxMjEwMFowIwYJKoZIhvcNAQkEMRYEFFNGCtQ5Uwnh2V/faqVH IqjGxChpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAjMPsO3ag+kN24kOlEmYB76PEZOeFw32TEU6zzFz/ xrx0cb9XN69cCykG6bxfQiSM0rDZY2o7Wu2owEnxjivlX/XYnEDsyST+Bcnmkax8Ywgj7KK8 iNwu1Oyhax7WWsplev/ZufhTG4JSqRty0Bb6DJEtV2SiQablFciJSYKMIwcZRBvzI4PqC69C nyAJfSji4EWCCETfKvvPZLfd9Mao0CotAQHbyWrpPPwtx0v22X8YEAYGl3r58JmbnACcIQeA Wdi/N5bDD3n7qVkAyC9g9Wk7UySY/DTNmF+D+2UxyAobQ66UEFrgPHqoAZN5v4BQFtjLWBGw o2AAIhZ/pF3LQAAAAAAAAA== --------------ms020409010702000902070606-- From alexey.melnikov@isode.com Tue Jun 8 22:25:19 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47E63A6885 for ; Tue, 8 Jun 2010 22:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cODeVV8mHxiU for ; Tue, 8 Jun 2010 22:25:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DCF673A685A for ; Tue, 8 Jun 2010 22:25:18 -0700 (PDT) Received: from [172.16.2.133] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 9 Jun 2010 06:25:19 +0100 Message-ID: <4C0F25B0.9060801@isode.com> Date: Wed, 09 Jun 2010 06:25:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: kitten@ietf.org Subject: Re: extensions-iana registry References: <4C0ECFB9.7080900@oracle.com> In-Reply-To: <4C0ECFB9.7080900@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 05:25:19 -0000 Shawn Emery wrote: > > Based on IANA feed-back; the WG needs to reach consensus on how the > GSS-API extensions are to be registered. Options proposed: > > 1. single GSS-API name-space registry I prefer this choice. > 2. separate registry - symbolic and constant registries > 3. registry per programming language > 4. multiple registries > ... > > Time-out is in two weeks (ending 6/22/10). From alexey.melnikov@isode.com Fri Jun 11 10:40:42 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7702B3A67D6; Fri, 11 Jun 2010 10:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xLenSwKlsed; Fri, 11 Jun 2010 10:40:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 106F03A6A30; Fri, 11 Jun 2010 10:40:41 -0700 (PDT) Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 11 Jun 2010 18:40:41 +0100 Message-ID: <4C12750D.4030904@isode.com> Date: Fri, 11 Jun 2010 18:40:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Shawn Emery Subject: Re: [sasl] Kitten Recharter References: <4C04B9FE.2090804@oracle.com> In-Reply-To: <4C04B9FE.2090804@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 17:40:42 -0000 Shawn Emery wrote: > Per the recent thead on "MOGGIES Proposed Charter"; I have taken > suggestions by kitten/SASL WG members and created recharter text for > Kitten (whilst closing SASL). Please let me know if I missed anything. > > Shawn. > Kitten co-chair. Hi Sean, Thanks for the updated version. This looks much better. Some additional comments inline. >Kitten (Common Authentication Technology Next Generation) > > >Description of Working Group: > >The Generic Security Services (GSS) API and Simple Authentication and Security >Layer (SASL) provide various applications with a security framework for secure >network communication. The purpose of the Common Authentication Technology >Next Generation (Kitten) working group (WG) is to develop >extensions/improvements to the GSS-API, shepherd specific GSS-API security >mechanisms, and provide guidance for any new SASL-related submissions. > >This working is chartered to specify the following extensions and improvements >(draft-yu-kitten-api-wishlist-00) to the GSS-API: > >* Provide new interfaces for credential management, which include the following: > initializing credentials > iterating credentials > exporting/importing credentials > >* Specify interface for asynchronous calls. > >* Define interfaces for better error message reporting. > >* Provide a more programmer friendly interface for application developers. > > This point is a bit vague. Do we actually need this as an explicit goal? >This WG is also chartered to transition proposed SASL mechanisms as >GSS-API mechanisms: > >* A SASL Mechanism for OpenID > draft-lear-ietf-sasl-openid-00 >* A SASL Mechanism for SAML > draft-wierenga-ietf-sasl-saml-00 > >The transition from SASL to GSS-API mechanisms will allow a greater set of >applications to utilize said mechanisms with SASL implementations that support >the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2). > >* Shepard draft-melnikov-digest-to-historic through standards track. > typo: shephard >This WG should review proposals for new SASL and GSS-API mechanisms. The WG >should also review non-mechanism proposals related to SASL and the GSS-API. > I think this is a bit too open-ended for IESG. I would have asked about that if I were asked to review such charter ;-). To be frank, I would delete these 2 sentences, or say the exactly opposite: other proposals would require rechartering. However chairs always have some flexibility in allowing conversations on related topics, as long as this doesn't compromise progress on major deliverables. >Deliverables: > >* GSS-API: initializing credentials >[editor: TBD] > >* GSS-API: iterating credentials >[editor: TBD] > >* GSS-API: exporting/importing credentials >[editor: TBD] > >* GSS-API: specification for asynchronous calls >[editor: TBD] > >* GSS-API: interfaces/improvements for better error message reporting >[editor: TBD] > >* GSS-API: programmer friendly interfaces >[editor: TBD] > >* GSS-API: transition SASL mechanism for OpenID >[editor: TBD] > >* GSS-API: transition SASL mechanism for SAML >[editor: TBD] > >* GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana >[editor: Nicolas Williams] > >* GSS-API: publish draft-ietf-kitten-gssapi-naming-exts >[editor: Leif Johansson] > >* SASL: publish draft-melnikov-digest-to-historic >[editor: Alexey Melnikov] > >Goals and Milestones: > >June 2010 Submit publish draft-ietf-kitten-gssapi-naming-exts to the IESG as Proposed Standard >June 2010 WGLC, again, on draft-ietf-kitten-gssapi-extensions-iana >July 2010 Submit draft-ietf-kitten-gssapi-extensions-iana to the IESG as Proposed Standard >July 2010 First Meeting >TBD Other Listed Work Items > > From jhutz@cmu.edu Fri Jun 11 11:10:45 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388813A6A2F; Fri, 11 Jun 2010 11:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R0FvvO5q3uM; Fri, 11 Jun 2010 11:10:42 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id EA89C3A6A2D; Fri, 11 Jun 2010 11:10:41 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5BIAgGX006123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 14:10:42 -0400 (EDT) Date: Fri, 11 Jun 2010 14:10:42 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov , Shawn Emery Subject: Re: [sasl] Kitten Recharter Message-ID: <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> In-Reply-To: <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> References: <4C04B9FE.2090804@oracle.com> <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, sasl@ietf.org, jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 18:10:45 -0000 --On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov wrote: >> * Shepard draft-melnikov-digest-to-historic through standards track. >> > typo: shephard shepherd, with an 'e', please >> This WG should review proposals for new SASL and GSS-API mechanisms. >> The WG should also review non-mechanism proposals related to SASL and >> the GSS-API. >> > I think this is a bit too open-ended for IESG. I would have asked about > that if I were asked to review such charter ;-). > > To be frank, I would delete these 2 sentences, or say the exactly > opposite: other proposals would require rechartering. However chairs > always have some flexibility in allowing conversations on related topics, > as long as this doesn't compromise progress on major deliverables. Not at all. The intent here is not that the WG have an open-ended mandate to take on any and all mechanism work. However, we want to be clear that this is the place to take any such proposals, and that it is in scope for the WG to discuss and review them, and to consider whether it wants to work on them (in which case a charter revision would be needed). -- Jeff From alexey.melnikov@isode.com Fri Jun 11 11:13:16 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CF93A69A0; Fri, 11 Jun 2010 11:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av62LmpqIsid; Fri, 11 Jun 2010 11:13:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 467173A6A15; Fri, 11 Jun 2010 11:13:14 -0700 (PDT) Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 11 Jun 2010 19:13:16 +0100 Message-ID: <4C127CAE.6010203@isode.com> Date: Fri, 11 Jun 2010 19:13:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Jeffrey Hutzelman Subject: Re: [sasl] Kitten Recharter References: <4C04B9FE.2090804@oracle.com> <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> In-Reply-To: <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 18:13:16 -0000 Jeffrey Hutzelman wrote: > --On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov > wrote: > >>> * Shepard draft-melnikov-digest-to-historic through standards track. >> >> typo: shephard > > shepherd, with an 'e', please. Thanks :-) >>> This WG should review proposals for new SASL and GSS-API mechanisms. >>> The WG should also review non-mechanism proposals related to SASL and >>> the GSS-API. >>> >> I think this is a bit too open-ended for IESG. I would have asked about >> that if I were asked to review such charter ;-). >> >> To be frank, I would delete these 2 sentences, or say the exactly >> opposite: other proposals would require rechartering. However chairs >> always have some flexibility in allowing conversations on related >> topics, >> as long as this doesn't compromise progress on major deliverables. > > Not at all. The intent here is not that the WG have an open-ended > mandate to take on any and all mechanism work. However, we want to be > clear that this is the place to take any such proposals, and that it > is in scope for the WG to discuss and review them, and to consider > whether it wants to work on them (in which case a charter revision > would be needed). If that is the intent, then the text is not good enough. It doesn't explicitly says that rechartering would be needed, it seems to imply the opposite. It is also not clear to me what can be described as "non-mechanism proposals related to SASL and the GSS-API". If we are talking about SASL protocol profiles, then we should say that. From jhutz@cmu.edu Fri Jun 11 11:49:42 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5452328C122; Fri, 11 Jun 2010 11:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3It3rkgN4ovJ; Fri, 11 Jun 2010 11:49:41 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 4593C28C0F9; Fri, 11 Jun 2010 11:49:41 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5BIngcq005400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 14:49:42 -0400 (EDT) Date: Fri, 11 Jun 2010 14:49:42 -0400 From: Jeffrey Hutzelman To: Alexey Melnikov Subject: Re: [sasl] Kitten Recharter Message-ID: In-Reply-To: <4C127CAE.6010203@isode.com> References: <4C04B9FE.2090804@oracle.com> <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> <4C127CAE.6010203@isode.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, sasl@ietf.org, jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 18:49:42 -0000 --On Friday, June 11, 2010 07:13:02 PM +0100 Alexey Melnikov wrote: > Jeffrey Hutzelman wrote: > >> --On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov >> wrote: >> >>>> * Shepard draft-melnikov-digest-to-historic through standards track. >>> >>> typo: shephard >> >> shepherd, with an 'e', please. > > Thanks :-) > >>>> This WG should review proposals for new SASL and GSS-API mechanisms. >>>> The WG should also review non-mechanism proposals related to SASL and >>>> the GSS-API. >>>> >>> I think this is a bit too open-ended for IESG. I would have asked about >>> that if I were asked to review such charter ;-). >>> >>> To be frank, I would delete these 2 sentences, or say the exactly >>> opposite: other proposals would require rechartering. However chairs >>> always have some flexibility in allowing conversations on related >>> topics, >>> as long as this doesn't compromise progress on major deliverables. >> >> Not at all. The intent here is not that the WG have an open-ended >> mandate to take on any and all mechanism work. However, we want to be >> clear that this is the place to take any such proposals, and that it >> is in scope for the WG to discuss and review them, and to consider >> whether it wants to work on them (in which case a charter revision >> would be needed). > > If that is the intent, then the text is not good enough. It doesn't > explicitly says that rechartering would be needed, it seems to imply the > opposite. > It is also not clear to me what can be described as "non-mechanism > proposals related to SASL and the GSS-API". If we are talking about SASL > protocol profiles, then we should say that. I don't think it's talking about SASL protocol profiles. It's talking about proposals related to SASL and GSS-API, other than mechanisms. In other words, we're not restricted to considering proposals for new mechanisms; we can also consider proposals to do things like adding mechanism attribute query to GSS-API or adding the PRF or channel binding abstractions to SASL, or whatever else comes along. I do think it should be in scope for the WG to review and provide expert advice on any work which adds SASL or GSS-API support to a new or existing protocol. However, actually _doing_ such work should be explicitly out of scope, as that should happen in the appropriate WG for the application protocol in question. -- Jeff From hartmans@painless-security.com Wed Jun 16 13:31:53 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C50E28C190; Wed, 16 Jun 2010 13:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-1.361, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eohXenAb6O3H; Wed, 16 Jun 2010 13:31:06 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 87EC43A6986; Wed, 16 Jun 2010 13:30:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DA52E20394; Wed, 16 Jun 2010 16:30:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E0EC940D4; Wed, 16 Jun 2010 16:30:25 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org, emu@ietf.org, kitten@ietf.org, moonshot-community@jiscmail.ac.uk, saag@ietf.org Subject: Federated Authentication BOF at IETF 78 mail-copies-to: never mail-followups-to: moonshot-community@jiscmail.ac.uk Date: Wed, 16 Jun 2010 16:30:25 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 20:31:54 -0000 Hi. I'd like to announce that there will be a BOF on federated authentication beyond the web at IETF 78. we'd like to form a working group to standardize protocols for federated access to applications that are not browser based. Targets include think client applications and some machine-to-machine authentication use cases. At this point we have not focused on requirements imposed by RAI applications. You can see draft specs at http://www.project-moonshot.org/specifications There is a BOF agenda at http://www.project-moonshot.org/bof/agenda We encourage you to join our mailing list, see http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY . To the extent we're able we'd love to collect comments or things people will want to discuss at the BOF now. Hopefully we can get as much as possible out of the way on the list and have a very productive session! We hope to see you there. From shawn.emery@oracle.com Thu Jun 17 17:44:42 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1C93A659B; Thu, 17 Jun 2010 17:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTXJGWYVgiyr; Thu, 17 Jun 2010 17:44:41 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1E9393A67A2; Thu, 17 Jun 2010 17:44:41 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5I0iij4028219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Jun 2010 00:44:45 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HKKKk0014638; Fri, 18 Jun 2010 00:44:43 GMT Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 354165281276821849; Thu, 17 Jun 2010 17:44:09 -0700 Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 17:44:09 -0700 Message-ID: <4C1AC158.8090009@oracle.com> Date: Thu, 17 Jun 2010 18:44:08 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: [sasl] Kitten Recharter References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com> In-Reply-To: <4C12750D.4030904@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4C1AC17E.0001:SCFMA922111,ss=1,fgs=0 Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 00:44:42 -0000 On 06/11/10 11:40 AM, Alexey Melnikov wrote: > Shawn Emery wrote: > >> Per the recent thead on "MOGGIES Proposed Charter"; I have taken >> suggestions by kitten/SASL WG members and created recharter text for >> Kitten (whilst closing SASL). Please let me know if I missed anything. >> >> Shawn. >> Kitten co-chair. > > Hi Sean, > Thanks for the updated version. This looks much better. Thanks. > Some additional comments inline. > >> Kitten (Common Authentication Technology Next Generation) >> >> >> >> * Provide a more programmer friendly interface for application >> developers. >> >> > This point is a bit vague. Do we actually need this as an explicit goal? Do you want more details on how this will be accomplished? For example: * Provide a more programmer friendly GSS-API for application developers. This could include reducing the number of interface parameters, eliminating those whose values' are commonly used. >> This WG should review proposals for new SASL and GSS-API mechanisms. >> The WG >> should also review non-mechanism proposals related to SASL and the >> GSS-API. >> > I think this is a bit too open-ended for IESG. I would have asked > about that if I were asked to review such charter ;-). > > To be frank, I would delete these 2 sentences, or say the exactly > opposite: other proposals would require rechartering. However chairs > always have some flexibility in allowing conversations on related > topics, as long as this doesn't compromise progress on major deliverables. I've read the follow-up thread between you and Hutzelman, and concluded that the following clarification should be made: This WG should review proposals for new SASL and GSS-API mechanisms. The WG should also review non-mechanism proposals related to SASL and the GSS-API. However, work that adds SASL or GSS-API support in application protocols should be handled by the application's WG. Shawn. -- From jhutz@cmu.edu Thu Jun 17 18:22:38 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993093A6877; Thu, 17 Jun 2010 18:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.612 X-Spam-Level: X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BxxxcmGfYNs; Thu, 17 Jun 2010 18:22:35 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 47CE23A63CB; Thu, 17 Jun 2010 18:22:35 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5I1McV1024508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 21:22:39 -0400 (EDT) Date: Thu, 17 Jun 2010 21:22:38 -0400 From: Jeffrey Hutzelman To: Shawn Emery , Alexey Melnikov Subject: Re: [sasl] Kitten Recharter Message-ID: <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu> In-Reply-To: <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com> References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com> <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, sasl@ietf.org, jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 01:22:39 -0000 --On Thursday, June 17, 2010 06:44:08 PM -0600 Shawn Emery wrote: > On 06/11/10 11:40 AM, Alexey Melnikov wrote: >> Shawn Emery wrote: >> >>> Per the recent thead on "MOGGIES Proposed Charter"; I have taken >>> suggestions by kitten/SASL WG members and created recharter text for >>> Kitten (whilst closing SASL). Please let me know if I missed anything. >>> >>> Shawn. >>> Kitten co-chair. >> >> Hi Sean, >> Thanks for the updated version. This looks much better. > > Thanks. > >> Some additional comments inline. >> >>> Kitten (Common Authentication Technology Next Generation) >>> >>> >>> >>> * Provide a more programmer friendly interface for application >>> developers. >>> >>> >> This point is a bit vague. Do we actually need this as an explicit goal? > > Do you want more details on how this will be accomplished? For example: > > * Provide a more programmer friendly GSS-API for application developers. > This could include reducing the number of interface parameters, > eliminating those whose values' are commonly used. > > >>> This WG should review proposals for new SASL and GSS-API mechanisms. >>> The WG >>> should also review non-mechanism proposals related to SASL and the >>> GSS-API. >>> >> I think this is a bit too open-ended for IESG. I would have asked >> about that if I were asked to review such charter ;-). >> >> To be frank, I would delete these 2 sentences, or say the exactly >> opposite: other proposals would require rechartering. However chairs >> always have some flexibility in allowing conversations on related >> topics, as long as this doesn't compromise progress on major >> deliverables. > > I've read the follow-up thread between you and Hutzelman, and concluded > that the following clarification should be made: > > This WG should review proposals for new SASL and GSS-API mechanisms. The > WG should also review non-mechanism proposals related to SASL and the > GSS-API. However, work that adds SASL or GSS-API support in application > protocols should be handled by the application's WG. To the first sentence, add "but may take on work on such mechanisms only through a revision of this charter". Then I think you'll have captured the gist of the discussion. -- Jeff From alexey.melnikov@isode.com Fri Jun 18 01:47:48 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBAF3A6A11; Fri, 18 Jun 2010 01:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO6Q3+au9yyj; Fri, 18 Jun 2010 01:47:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4B8D13A6A13; Fri, 18 Jun 2010 01:47:46 -0700 (PDT) Received: from [188.28.32.193] (188.28.32.193.threembb.co.uk [188.28.32.193]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 18 Jun 2010 09:47:35 +0100 Message-ID: <4C1B32A2.4090109@isode.com> Date: Fri, 18 Jun 2010 09:47:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Jeffrey Hutzelman Subject: Re: [sasl] Kitten Recharter References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com> <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com> <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu> In-Reply-To: <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 08:47:48 -0000 Jeffrey Hutzelman wrote: > --On Thursday, June 17, 2010 06:44:08 PM -0600 Shawn Emery > wrote: > >> On 06/11/10 11:40 AM, Alexey Melnikov wrote: >> >>> Shawn Emery wrote: >> [...] >>>> >>>> >>>> * Provide a more programmer friendly interface for application >>>> developers. >>> >>> This point is a bit vague. Do we actually need this as an explicit >>> goal? >> >> Do you want more details on how this will be accomplished? For example: >> >> * Provide a more programmer friendly GSS-API for application developers. >> This could include reducing the number of interface parameters, >> eliminating those whose values' are commonly used. > *not* commonly used? Yes, something like that. >> >> >>>> This WG should review proposals for new SASL and GSS-API mechanisms. >>>> The WG >>>> should also review non-mechanism proposals related to SASL and the >>>> GSS-API. >>> >>> I think this is a bit too open-ended for IESG. I would have asked >>> about that if I were asked to review such charter ;-). >>> >>> To be frank, I would delete these 2 sentences, or say the exactly >>> opposite: other proposals would require rechartering. However chairs >>> always have some flexibility in allowing conversations on related >>> topics, as long as this doesn't compromise progress on major >>> deliverables. >> >> I've read the follow-up thread between you and Hutzelman, and concluded >> that the following clarification should be made: >> >> This WG should review proposals for new SASL and GSS-API mechanisms. >> The >> WG should also review non-mechanism proposals related to SASL and the >> GSS-API. However, work that adds SASL or GSS-API support in application >> protocols should be handled by the application's WG. > > To the first sentence, add "but may take on work on such mechanisms > only through a revision of this charter". Then I think you'll have > captured the gist of the discussion. +1. From lha@kth.se Fri Jun 18 12:04:20 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A003A68A0 for ; Fri, 18 Jun 2010 12:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.459 X-Spam-Level: X-Spam-Status: No, score=-4.459 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmRi3lSzK+Sf for ; Fri, 18 Jun 2010 12:04:20 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id CA92C3A67D4 for ; Fri, 18 Jun 2010 12:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 94DAD14C022; Fri, 18 Jun 2010 21:03:54 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6YFiAvXEAE1q; Fri, 18 Jun 2010 21:03:50 +0200 (CEST) X-KTH-Auth: lha [2620:0:1b00:1121:81ec:1fd5:e34c:5dd9] X-KTH-mail-from: lha@kth.se Received: from [IPv6:2620::1b00:1121:81ec:1fd5:e34c:5dd9] (unknown [IPv6:2620:0:1b00:1121:81ec:1fd5:e34c:5dd9]) by smtp-2.sys.kth.se (Postfix) with ESMTP id E178614DC41; Fri, 18 Jun 2010 21:03:49 +0200 (CEST) Subject: Re: extensions-iana registry Mime-Version: 1.0 (Apple Message framework v1150) Content-Type: multipart/signed; boundary=Apple-Mail-29-80423516; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <4C0ECFB9.7080900@oracle.com> Date: Fri, 18 Jun 2010 12:04:10 -0700 Message-Id: References: <4C0ECFB9.7080900@oracle.com> To: Shawn Emery X-Mailer: Apple Mail (2.1150) Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 19:04:21 -0000 --Apple-Mail-29-80423516 Content-Type: multipart/alternative; boundary=Apple-Mail-28-80423463 --Apple-Mail-28-80423463 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 8 jun 2010 kl. 16:18 skrev Shawn Emery: >=20 > Based on IANA feed-back; the WG needs to reach consensus on how the = GSS-API extensions are to be registered. Options proposed: >=20 > 1. single GSS-API name-space registry > 2. separate registry - symbolic and constant registries > 3. registry per programming language > 4. multiple registries How would each of these look like ? Esp the first one. Love --Apple-Mail-28-80423463 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
8 jun 2010 kl. 16:18 skrev Shawn Emery:


Based on IANA feed-back; the WG needs to reach consensus on how the GSS-API extensions are to be registered.  Options proposed:

    1. single GSS-API name-space registry
    2. separate registry - symbolic and constant registries
    3. registry per programming language
    4. multiple registries


How would each of these look like ? Esp the first one.

Love

--Apple-Mail-28-80423463-- --Apple-Mail-29-80423516 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYxODE5 MDQxMFowIwYJKoZIhvcNAQkEMRYEFAppvkULUUVpZSQejFcXOhURUAF5MIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBAKo/4gSeUTWuuyk0AwcuRD3H+iXqjg30RWF8HJYSM6h1NbV0RITQ kRMre6LpTMEQMH8Vm0RIzN8bJfdhrQ9GrFhlDNHEVgNR7JHIORAp3yfJkkWNhvu3t3o3FUgib21v IsniOxbngNZzyokynGRecqPi6KVNJVgkszwk9QklPDeRmo6oZSmSCKnt1Einv8S+hgiXuIu/1KIk vWIF8gK04uNDoFAQd5bOpfW+IT0HF1ptS7Rvu0rzMF+Ql/HASZovto5x6joWQ4xQwEC6kaD/cUFk RLwhwwPikC61wGZc0DZnVs8HqKMv5XCW1F1BjxVbMxpsb3impGusjVVYLGgqkkAAAAAAAAA= --Apple-Mail-29-80423516-- From shawn.emery@oracle.com Tue Jun 22 22:55:52 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA673A6A43 for ; Tue, 22 Jun 2010 22:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.194 X-Spam-Level: X-Spam-Status: No, score=-5.194 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHZxsxC4s785 for ; Tue, 22 Jun 2010 22:55:44 -0700 (PDT) Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) by core3.amsl.com (Postfix) with ESMTP id 61A453A6A4C for ; Tue, 22 Jun 2010 22:55:24 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by rcsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id o5N5rNM5022357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jun 2010 05:53:23 GMT Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o5N5qprp002574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jun 2010 05:52:52 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5MMSxPA014915; Wed, 23 Jun 2010 05:52:50 GMT Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 349125511277272354; Tue, 22 Jun 2010 22:52:34 -0700 Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jun 2010 22:52:34 -0700 Message-ID: <4C21A121.30603@oracle.com> Date: Tue, 22 Jun 2010 23:52:33 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: extensions-iana registry References: <4C0ECFB9.7080900@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040005070809010907000307" X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090201.4C21A134.01F6:SCFMA4539811,ss=1,fgs=0 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 05:55:53 -0000 This is a multi-part message in MIME format. --------------040005070809010907000307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 06/18/10 01:04 PM, Love Hörnquist Åstrand wrote: > > 8 jun 2010 kl. 16:18 skrev Shawn Emery: > >> >> Based on IANA feed-back; the WG needs to reach consensus on how the >> GSS-API extensions are to be registered. Options proposed: >> >> 1. single GSS-API name-space registry >> 2. separate registry - symbolic and constant registries >> 3. registry per programming language >> 4. multiple registries > > > How would each of these look like ? Esp the first one. 1. single GSS-API name-space registry A type that does not have separate symbolic and constant registries. In other words, not 2 or 3. 2. separate registry - symbolic and constant registries A constant registry contains entries specific to constant name-values. A symbolic registry contains entries for non-constants, e.g. function names, name types, etc. 3. registry per programming language Registries partitioned by programming language, for example: Registry a. contains entries for bindings in C. Registry b. contains entries for binging in Java. ... Entries in a. and b. do not have to be unique, but all entries in each of the language registries should be specified. 4. multiple registries Multiple registries is really 2 or 3. Perhaps we should put an example with different name-space types in the appendix for the single name-space registry? Would this help clarify? Shawn. -- --------------040005070809010907000307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/18/10 01:04 PM, Love Hörnquist Åstrand wrote:

8 jun 2010 kl. 16:18 skrev Shawn Emery:


Based on IANA feed-back; the WG needs to reach consensus on how the GSS-API extensions are to be registered.  Options proposed:

    1. single GSS-API name-space registry
    2. separate registry - symbolic and constant registries
    3. registry per programming language
    4. multiple registries


How would each of these look like ? Esp the first one.

1. single GSS-API name-space registry
A type that does not have separate symbolic and constant registries.  In other words, not 2 or 3.

2. separate registry - symbolic and constant registries
A constant registry contains entries specific to constant name-values.
A symbolic registry contains entries for non-constants, e.g. function names, name types, etc.

3. registry per programming language
Registries partitioned by programming language, for example:
Registry a. contains entries for bindings in C.
Registry b. contains entries for binging in Java.
...
Entries in a. and b. do not have to be unique, but all entries in each of the language registries should be specified.

4. multiple registries
Multiple registries is really 2 or 3.

Perhaps we should put an example with different name-space types in the appendix for the single name-space registry?  Would this help clarify?

Shawn.
--
--------------040005070809010907000307-- From shawn.emery@oracle.com Tue Jun 22 22:56:00 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6373A6A48 for ; Tue, 22 Jun 2010 22:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qzYHzoYSj3F for ; Tue, 22 Jun 2010 22:55:53 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id F02913A6A41 for ; Tue, 22 Jun 2010 22:55:46 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o5N5tW2q008415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jun 2010 05:55:34 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5N24Hkt013936 for ; Wed, 23 Jun 2010 05:55:31 GMT Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 365903251277272504; Tue, 22 Jun 2010 22:55:04 -0700 Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jun 2010 22:55:03 -0700 Message-ID: <4C21A1B7.60703@oracle.com> Date: Tue, 22 Jun 2010 23:55:03 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: "kitten@ietf.org" Subject: Fwd: Fwd: Nomcom 2010-2011: Second Call for Volunteers Content-Type: multipart/alternative; boundary="------------010801070305050907040601" X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090202.4C21A1D6.00D5:SCFMA922111,ss=1,fgs=0 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 05:56:01 -0000 This is a multi-part message in MIME format. --------------010801070305050907040601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Fwd: Nomcom 2010-2011: Second Call for Volunteers Date: Tue, 22 Jun 2010 18:41:58 -0400 From: Russ Housley To: IETF WG Chairs Some WG Chairs have helped spread the word by posting this call for participants to their mail list. If you have not already done so, please pass the word. Russ > From: NomCom Chair > Date: June 21, 2010 5:49:08 PM EDT > To: IETF Announcement list > Subject: Nomcom 2010-2011: Second Call for Volunteers > > Hi all, > > This is the Second call for Volunteers for the 2010-11 nomcom. We are > just about halfway through the volunteer period so if you are > considering > volunteering please do so very soon. > > I am pleased to report that we have 29 volunteers thus far whose > qualifications have been confirmed by the secretariat. I have notified > each of these volunteers by email. > > If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve > as a > voting member and have not received a confirmation email from me, > please > re-submit and bring to my attention right away! > > However, we need many more volunteers. You have until 17:00 PDT > (24:00 > UTC) on July 8, 2010 to volunteer for nomcom but it is much better > if you > volunteer as early as possible. The more volunteers, the better > chance we > have of choosing a random yet representative cross section of the IETF > pouplation. > > As a reminder, volunteers must have attended 3 of the past 5 IETF > meetings - per RFC 3777, which means 3 of the following meetings: > IETF-73, > IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are > willing to > forgo appointment to any of the positions for which the nominating > committee is responsible, please volunteer. > > The 10 nominating committee members are selected randomly from a > pool of > volunteers. The details of the operation of nomcom may be found in > RFC > 3777. The process on how to volunteer for nomcom is in the initial > announcement: https://datatracker.ietf.org/ann/nomcom/2330/ > > The lists of open positions and people whose terms end in March 2011 > and > thus the positions for which the nominating committee is responsible > are > summarized in the initial announcement: > https://datatracker.ietf.org/ann/nomcom/2330/ > > The 29 volunteers who have thus far been qualified by the secretariat > are: > > Fred Baker, Cisco Systems > > Stephan Wenger, Vidyo, Inc. > > Marc Blanchet, Viagenie > > Lixia Zhang, UCLA > > John Drake, Juniper Networks > > Ole Troan, Cisco > > Jiankang Yao, CNNIC > > Wassim Haddad, Ericsson > > Yi Zhao, Huawei USA > > Teemu Savolainen, Nokia > > Jouni Korhonen, Nokia Siemens Networks > > Mehmet Ersue, Nokia Siemens Networks > > Christian Schmidt, Nokia Siemens Networks > > Stephen Hanna, Juniper Networks > > Suresh Krishnan, Ericsson > > Eric Gray, Ericsson > > David Sinicrope, Ericsson > > Jan Melen, Ericsson > > Richard Barnes, BBN Technologies > > Hugo Salgado Hernandez, NIC Chile > > Ning Zong, Huawei Technologies > > Qin Wu, Huawei Technologies > > Karen Seo, BBN Technologies > > Haibin Song, Huawei Technologies > > Susan Hares, Huawei Technologies > > Tony Hansen. AT&T Labs > > Fuqing Huang, Huawei Technologies Co., Ltd. > > Huub van Helvoort, Huawei Technologies > > Miya Kohno, Juniper Networks > > The primary activity for this nomcom will begin just prior to > IETF-78 in > Maastricht and should be completed in early January 2011. The > nomcom will > be collecting requirements from the community, as well as talking to > candidates and to community members about candidates. There will be > weekly > conference calls to ensure progress. Thus, being a nomcom member does > require some time commitment. > > While, there is no requirement in RFC 3777 that a participant attend > IETF > meetings while serving on nomcom, please consider that during the IETF > meetings, people that do not attend would be expected to remotely > participate during the day in the time zones of the meeting > locations - > Maastricht at the end of July and Beijing in November. > > If you are not yet sure you would like to volunteer, please consider > that > nomcom members play a very important role in shaping the leadership > of the > IETF. Ensuring the leadership of the IETF is fair and balanced and > comprised of those who can lead the IETF in the right direction is an > important responsibility that rests on the IETF participants at large. > Volunteering for the nomcom is a good way of contributing in that > direction. > > Please volunteer by sending an email before: > 17:00 PDT (24:00 UTC) July 8, 2010 as follows: > > To: nomcom-chair@ietf.org > Subject: Nomcom 2010-11 Volunteer > > Please include the following information in the body: > > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > > // typically what goes in the Company field > // in the IETF Registration Form > > [] > // > > // For confirmation if selected > > Please expect an email response from me within 3 days stating > whether or > not you are qualified. If you don't receive a response, please re- > send > your email with the tag "Duplicate:" added to the subject line. > > Thank you and I hope to hear from you, > > Thomas Walsh > Chair, Nomcom 2010-11 > Email: nomcom-chair@ietf.org > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --------------010801070305050907040601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

-------- Original Message --------
Subject: Fwd: Nomcom 2010-2011: Second Call for Volunteers
Date: Tue, 22 Jun 2010 18:41:58 -0400
From: Russ Housley <housley@vigilsec.com>
To: IETF WG Chairs <wgchairs@ietf.org>


Some WG Chairs have helped spread the word by posting this call for
participants to their mail list.  If you have not already done so,
please pass the word.

Russ

> From: NomCom Chair <nomcom-chair@ietf.org>
> Date: June 21, 2010 5:49:08 PM EDT
> To: IETF Announcement list <ietf-announce@ietf.org>
> Subject: Nomcom 2010-2011: Second Call for Volunteers
>
> Hi all,
>
> This is the Second call for Volunteers for the 2010-11 nomcom.  We are
> just about halfway through the volunteer period so if you are  
> considering
> volunteering please do so very soon.
>
> I am pleased to report that we have 29 volunteers thus far whose
> qualifications have been confirmed by the secretariat. I have notified
> each of these volunteers by email.
>
> If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve  
> as a
> voting member and have not received a confirmation email from me,  
> please
> re-submit and bring to my attention right away!
>
> However, we need many more volunteers.  You have until 17:00 PDT  
> (24:00
> UTC) on July 8, 2010 to volunteer for nomcom but it is much better  
> if you
> volunteer as early as possible.  The more volunteers, the better  
> chance we
> have of choosing a random yet representative cross section of the IETF
> pouplation.
>
> As a reminder, volunteers must have attended 3 of the past 5 IETF
> meetings - per RFC 3777, which means 3 of the following meetings:  
> IETF-73,
> IETF-74, IETF-75, IETF-76 and IETF-77.  If you qualify, and are  
> willing to
> forgo appointment to any of the positions for which the nominating
> committee is responsible, please volunteer.
>
> The 10 nominating committee members are selected randomly from a  
> pool of
> volunteers.  The details of the operation of nomcom may be found in  
> RFC
> 3777.  The process on how to volunteer for nomcom is in the initial
> announcement:  https://datatracker.ietf.org/ann/nomcom/2330/
>
> The lists of open positions and people whose terms end in March 2011  
> and
> thus the positions for which the nominating committee is responsible  
> are
> summarized in the initial announcement:
> https://datatracker.ietf.org/ann/nomcom/2330/
>
> The 29 volunteers who have thus far been qualified by the secretariat
> are:
>
> Fred Baker, Cisco Systems
>
> Stephan Wenger, Vidyo, Inc.
>
> Marc Blanchet, Viagenie
>
> Lixia Zhang, UCLA
>
> John Drake, Juniper Networks
>
> Ole Troan, Cisco
>
> Jiankang Yao, CNNIC
>
> Wassim Haddad, Ericsson
>
> Yi Zhao, Huawei USA
>
> Teemu Savolainen, Nokia
>
> Jouni Korhonen, Nokia Siemens Networks
>
> Mehmet Ersue, Nokia Siemens Networks
>
> Christian Schmidt, Nokia Siemens Networks
>
> Stephen Hanna, Juniper Networks
>
> Suresh Krishnan, Ericsson
>
> Eric Gray, Ericsson
>
> David Sinicrope, Ericsson
>
> Jan Melen, Ericsson
>
> Richard Barnes, BBN Technologies
>
> Hugo Salgado Hernandez, NIC Chile
>
> Ning Zong, Huawei Technologies
>
> Qin Wu, Huawei Technologies
>
> Karen Seo, BBN Technologies
>
> Haibin Song, Huawei Technologies
>
> Susan Hares, Huawei Technologies
>
> Tony Hansen. AT&T Labs
>
> Fuqing Huang, Huawei Technologies Co., Ltd.
>
> Huub van Helvoort, Huawei Technologies
>
> Miya Kohno, Juniper Networks
>
> The primary activity for this nomcom will begin just prior to  
> IETF-78 in
> Maastricht and should be completed in early January 2011.  The  
> nomcom will
> be collecting requirements from the community, as well as talking to
> candidates and to community members about candidates. There will be  
> weekly
> conference calls to ensure progress. Thus, being a nomcom member does
> require some time commitment.
>
> While, there is no requirement in RFC 3777 that a participant attend  
> IETF
> meetings while serving on nomcom, please consider that during the IETF
> meetings, people that do not attend would be expected to remotely
> participate during the day in the time zones of the meeting  
> locations -
> Maastricht at the end of July and Beijing in November.
>
> If you are not yet sure you would like to volunteer, please consider  
> that
> nomcom members play a very important role in shaping the leadership  
> of the
> IETF.  Ensuring the leadership of the IETF is fair and balanced and
> comprised of those who can lead the IETF in the right direction is an
> important responsibility that rests on the IETF participants at large.
> Volunteering for the nomcom is a good way of contributing in that
> direction.
>
> Please volunteer by sending an email before:
> 17:00 PDT (24:00 UTC) July 8, 2010 as follows:
>
> To: nomcom-chair@ietf.org
> Subject: Nomcom 2010-11 Volunteer
>
> Please include the following information in the body:
>
> <Your Full Name>  // As you enter in the IETF Registration Form,
>                  // First/Given name followed by Last/Family Name
>
> <Current Primary Affiliation>
>                  // typically what goes in the Company field
>                  // in the IETF Registration Form
>
> [<all email addresses used to Register for the past 5 IETF meetings>]
> <Preferred email address>  //
>
> <Telephone number>         // For confirmation if selected
>
> Please expect an email response from me within 3 days stating  
> whether or
> not you are qualified.  If you don't receive a response, please re- 
> send
> your email with the tag "Duplicate:" added to the subject line.
>
> Thank you and I hope to hear from you,
>
> Thomas Walsh
> Chair, Nomcom 2010-11
> Email: nomcom-chair@ietf.org
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>



--------------010801070305050907040601-- From lha@kth.se Wed Jun 23 10:00:51 2010 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9BD3A6AB1 for ; Wed, 23 Jun 2010 10:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.274 X-Spam-Level: X-Spam-Status: No, score=-4.274 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ+sQOuQIbVh for ; Wed, 23 Jun 2010 10:00:51 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 6820A3A6AB0 for ; Wed, 23 Jun 2010 10:00:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 64BE7155AEA; Wed, 23 Jun 2010 19:00:27 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A8SUPfBLx1Mh; Wed, 23 Jun 2010 19:00:26 +0200 (CEST) X-KTH-Auth: lha [2620:0:1b00:1121:d56d:b16f:2c2a:deee] X-KTH-mail-from: lha@kth.se Received: from [IPv6:2620::1b00:1121:d56d:b16f:2c2a:deee] (unknown [IPv6:2620:0:1b00:1121:d56d:b16f:2c2a:deee]) by smtp-1.sys.kth.se (Postfix) with ESMTP id A014515700F; Wed, 23 Jun 2010 19:00:25 +0200 (CEST) Subject: Re: extensions-iana registry Mime-Version: 1.0 (Apple Message framework v1153) Content-Type: multipart/signed; boundary=Apple-Mail-118-505029016; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <4C21A121.30603@oracle.com> Date: Wed, 23 Jun 2010 10:00:55 -0700 Message-Id: <8247527F-431B-46B5-957F-406AFA822149@kth.se> References: <4C0ECFB9.7080900@oracle.com> <4C21A121.30603@oracle.com> To: Shawn Emery X-Mailer: Apple Mail (2.1153) Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 17:00:51 -0000 --Apple-Mail-118-505029016 Content-Type: multipart/alternative; boundary=Apple-Mail-117-505028971 --Apple-Mail-117-505028971 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 22 jun 2010 kl. 22:52 skrev Shawn Emery: > On 06/18/10 01:04 PM, Love H=F6rnquist =C5strand wrote: >>=20 >>=20 >> 8 jun 2010 kl. 16:18 skrev Shawn Emery: >>=20 >>>=20 >>> Based on IANA feed-back; the WG needs to reach consensus on how the = GSS-API extensions are to be registered. Options proposed: >>>=20 >>> 1. single GSS-API name-space registry >>> 2. separate registry - symbolic and constant registries >>> 3. registry per programming language >>> 4. multiple registries >>=20 >>=20 >> How would each of these look like ? Esp the first one. I think I was more looking for examples. For example, every time a new language is added, yet another row need to = be added, and I'm concered how easy that is to manged and express to = IANA what change we want to make. I think there should be one registry for each language added and how it = maps to the base specification language. Love >=20 > 1. single GSS-API name-space registry > A type that does not have separate symbolic and constant registries. = In other words, not 2 or 3. >=20 > 2. separate registry - symbolic and constant registries > A constant registry contains entries specific to constant name-values. > A symbolic registry contains entries for non-constants, e.g. function = names, name types, etc. >=20 > 3. registry per programming language > Registries partitioned by programming language, for example: > Registry a. contains entries for bindings in C. > Registry b. contains entries for binging in Java. > ... > Entries in a. and b. do not have to be unique, but all entries in each = of the language registries should be specified. >=20 > 4. multiple registries > Multiple registries is really 2 or 3. >=20 > Perhaps we should put an example with different name-space types in = the appendix for the single name-space registry? Would this help = clarify? >=20 > Shawn. > -- --Apple-Mail-117-505028971 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 06/18/10 01:04 PM, Love H=F6rnquist =C5strand wrote:

8 jun 2010 kl. 16:18 skrev Shawn Emery:


Based on IANA feed-back; the WG needs to reach consensus on how the GSS-API extensions are to be registered.  Options proposed:

    1. single GSS-API name-space registry
    2. separate registry - symbolic and constant registries
    3. registry per programming language
    4. multiple registries


How would each of these look like ? Esp the first = one.

I = think I was more looking for examples.

For = example, every time a new language is added, yet another row need to be = added, and I'm concered how easy that is to manged and express to IANA = what change we want to make.

I think there = should be one registry for each language added and how it maps to the = base specification = language.

Love


1. single = GSS-API name-space registry
A type that does not have separate symbolic and constant = registries.  In other words, not 2 or 3.

2. separate registry - symbolic and constant registries
A constant registry contains entries specific to constant = name-values.
A symbolic registry contains entries for non-constants, e.g. function names, name types, etc.

3. registry per programming language
Registries partitioned by programming language, for example:
Registry a. contains entries for bindings in C.
Registry b. contains entries for binging in Java.
...
Entries in a. and b. do not have to be unique, but all entries in each of the language registries should be specified.

4. multiple registries
Multiple registries is really 2 or 3.

Perhaps we should put an example with different name-space types in the appendix for the single name-space registry?  Would this help = clarify?

Shawn.
--

= --Apple-Mail-117-505028971-- --Apple-Mail-118-505029016 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYyMzE3 MDA1NlowIwYJKoZIhvcNAQkEMRYEFMhnHV4/W9lU1f8llW6u8vepf20dMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBAEwKxX5dPe9xNLOGLDjOpvfnYWI77Luu7guvLsKdd8173P5n5joH MhuSo0Xj1sR4qpbhhZQfG9fh8/Fh5n6ZFOj82e9iuO+ELHV2eFh0R/H3Hv029hagrLyXRiv5w6mT qeDPnG3mkGQanmjYpu5IpKgT+D6aaIxUcLiEzOdNAL6euAhEq8Q9myDqnhwLtFavUj+MPVDwrnA0 uhMBOF7ufy1bGkjv7fU5/mFUGbOj02iKY9BkF9+q8hpR/v2YW4fzhR1oaoTHtqDA0h55UHgtYKX2 ljlI+DYkcwTQdpB4cWJFaxkJi4I5wQjaTfNQL3bkpSvCTOSW9X1Zkbkb9GZfI9AAAAAAAAA= --Apple-Mail-118-505029016-- From root@core3.amsl.com Thu Jun 24 12:45:01 2010 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C71703A688C; Thu, 24 Jun 2010 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-gssapi-naming-exts-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100624194501.C71703A688C@core3.amsl.com> Date: Thu, 24 Jun 2010 12:45:01 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 19:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : N. Williams, L. Johansson Filename : draft-ietf-kitten-gssapi-naming-exts-08.txt Pages : 14 Date : 2010-06-24 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-naming-exts-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-24124316.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Jun 24 20:30:16 2010 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D996528C0D7; Thu, 24 Jun 2010 20:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-digest-to-historic-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100625033010.D996528C0D7@core3.amsl.com> Date: Thu, 24 Jun 2010 20:30:03 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 03:30:16 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Moving DIGEST-MD5 to Historic Author(s) : A. Melnikov Filename : draft-ietf-kitten-digest-to-historic-00.txt Pages : 7 Date : 2010-06-24 This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It recommends that DIGEST-MD5 to be marked as OBSOLETE in the IANA Registry of SASL mechanisms, and that RFC 2831 be moved to Historic status. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-sasl@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-digest-to-historic-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-digest-to-historic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-24202204.I-D@ietf.org> --NextPart--