From nobody Thu Mar 27 01:17:40 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF85A1A04A3 for ; Thu, 27 Mar 2014 01:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, HTTP_ESCAPED_HOST=1.125, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9n1QPGYlgff for ; Thu, 27 Mar 2014 01:17:34 -0700 (PDT) Received: from hermes7.ccf.auth.gr (hermes7.ccf.auth.gr [155.207.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id 11CE31A02DA for ; Thu, 27 Mar 2014 01:17:33 -0700 (PDT) Received: from [155.207.112.243] (noc-dhcp9.ccf.auth.gr [155.207.112.243]) (authenticated bits=0) by hermes7.ccf.auth.gr (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id s2R8HTRq017995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 27 Mar 2014 10:17:30 +0200 Message-ID: <5333DE94.8080907@it.auth.gr> Date: Thu, 27 Mar 2014 10:17:24 +0200 From: Vyronas Tsingaras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000608090900090008070301" X-Virus-Scanned: clamav-milter 0.97.8 at hermes7 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/qi3sh9PqJZC2R8LfGjloXIZKHKc Subject: [pkix] RFC 5280/6818 X.509v3 DNS Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 08:17:37 -0000 This is a cryptographically signed message in MIME format. --------------ms000608090900090008070301 Content-Type: multipart/alternative; boundary="------------020603080903000400060707" This is a multi-part message in MIME format. --------------020603080903000400060707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable What is the reasoning behind name constraints format for type "DNS name" = as specified in RFC 5280 ? In other words why is it different=20 from the URI scheme, where ".example.com " = would satisfy *.example.com , *.*example.com=20 BUT not example.com ? Currently = as it stands, a CA has no way to restrict itself from issuing=20 certificates for example.com while allowing itself=20 to issue for host.example.com . A NC for type=20 DNS "example.com " will allow the CA to=20 issue a certificate for example.comwhen the desired behavior would be to = only allow ".example.com "(in URI=20 scheme). This could be undesirable. It seems like while the scheme for=20 URIs and email where updated whereas the DNS scheme was left untouched.=20 Wouldn't it be better if the DNS scheme followed the other 2? The relevant section is 4.2.1.10 in RFC 5280 = --------------020603080903000400060707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is the reasoning behind name constraints format for type “DNS name” as specified in RFC 528= 0? In other words why is it different from the URI scheme, where “.example.comR= 21; would satisfy *.example.com, *.*example.com BUT not example.com? Currently as it stands, a CA has no way to restrict itself from issuing certificates for example.com while allowing itself to issue for host.example.com. A NC for type DNS “example.com= ” will allow the CA to issue a certificate for example.comwhen the desired behavior would be to only allow “.example.comR= 21;(in URI scheme).  This could be undesirable. It seems like while the scheme for URIs and email where updated whereas the DNS scheme was left untouched. Wouldn’t it be better if the DNS scheme follo= wed the other 2?

The relevant section is 4.2.1.10 in= RFC 5280
--------------020603080903000400060707-- --------------ms000608090900090008070301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIStTCC BeswggTToAMCAQICCBLbYSynVIMBMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJHUjFE MEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBD ZXJ0LiBBdXRob3JpdHkxOzA5BgNVBAMTMkFyaXN0b3RsZSBVbml2ZXJzaXR5IG9mIFRoZXNz YWxvbmlraSBDZW50cmFsIENBIFIzMB4XDTEzMTAwMjA3NTA1MFoXDTE3MTAwMTA3NTA1MFow bDELMAkGA1UEBhMCR1IxLTArBgNVBAoTJEFyaXN0b3RsZSBVbml2ZXJzaXR5IG9mIFRoZXNz YWxvbmlraTEuMCwGA1UEAxMlQVVUSCBVc2VycyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBS NjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKxytCDDa7pmDG69qdxp/nh1qOlX X31YeDjTjPR1zqvgJ50gGad/aa76zPWrQVpB83qFPN4cXIjNIeIc9XAVaPd1ps61xtzKMBax +7xuAqV+1M3BCglLaScnR6rkLAUOq22rlir7O6KJJ828Yerb5RaoWr0C5r2fW5O36pirbFY8 hwx8kO+s9rWvhKhorlzVToI8pn8YqHQZsxFtph4j2A5rZZzkFdtsm8PfE4V+10PPuWiAu+h1 Ov5bBAtUuD+ug/ZTa75oRz9iBZFiWNlMKTbCjt/o/cRD8LrHQS35NJiDBJqG1YOVffQ0Vi4V yjStjLFvuNje/PW1IP+ga8owYe0CAwEAAaOCAmowggJmMA8GA1UdEwEB/wQFMAMBAf8wDgYD VR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSv7nBUPXHCLCd5jBtP8hCUrJpy0zBHBgNVHR8EQDA+ MDygOqA4hjZodHRwOi8vY3JsdjEucGtpLmF1dGguZ3IvQXV0aENlbnRyYWxDQVIzL2NybHYx LmRlci5jcmwwHwYDVR0jBBgwFoAU9ZMXSh1ztn9/ILKlFJRXchkzNtIwcQYIKwYBBQUHAQEE ZTBjMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5wa2kuYXV0aC5ncjA8BggrBgEFBQcwAoYw aHR0cDovL3d3dy5wa2kuYXV0aC5nci9jZXJ0cy9BdXRoQ2VudHJhbENBUjMucGVtMIIBIAYD VR0gBIIBFzCCARMwggEPBgsrBgEEAbwdAgADBTCB/zA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5wa2kuYXV0aC5nci9kb2N1bWVudHMvQ1BTLnBocDCBxgYIKwYBBQUHAgIwgbkwKxYkQXJp c3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMAMCAQEagYlUaGlzIGNlcnRpZmlj YXRlIGlzIHN1YmplY3QgdG8gR3JlZWsgbGF3cyBhbmQgb3VyIENQUy4gVGhpcyBDZXJ0aWZp Y2F0ZSBtdXN0IG9ubHkgYmUgdXNlZCBmb3IgYWNhZGVtaWMsIHJlc2VhcmNoIG9yIGVkdWNh dGlvbmFsIHB1cnBvc2VzLjAjBgNVHR4EHDAaoBgwCoIILmF1dGguZ3IwCoEILmF1dGguZ3Iw DQYJKoZIhvcNAQEFBQADggEBACgcycsZ9H4rOJ8nAANheYJj3u5fU5eWdwxkoZfQ5ugmsh81 ABO87XBGJYGj5g/8yW7CrG6WOPedBO0zjNqBpRCoZTQ/6cTUpLoRdtScFwv/cpnoKxvPY0mq CLJOu3bGA53LoZipZHH38cYfSgB78qmc3YC9ELqGSun55UeYZtc+ZJca/A2QIuJUPuvidHF7 rGMtAxxiqGkgeBzwjMy6wq+hxO9Mf3gswR6QYc3jxx+9cD/+Rv/oxveFupMDbTA+nD671iKA gltYGFi8ckhDdTEH9mzIvojwiLGuPScaRqNKW4gAGdrz9LE5JwD9ij0WaBrbE0cHP4GKlzCk KDqLbm0wggYtMIIFFaADAgECAgUBAAAABTANBgkqhkiG9w0BAQUFADCBlTELMAkGA1UEBhMC R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlv bnMgQ2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVz ZWFyY2ggSW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMB4XDTEzMDkxMjA4MDQ1NFoXDTIxMDkx MDA4MDQ1NFowgZAxCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBh bmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE7MDkGA1UEAxMyQXJp c3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpIENlbnRyYWwgQ0EgUjMwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCb+M8pkmGOZjlS5eF/D+FBOZByYgMp/3cPzfPJ 4HJdLwVaE3O7FQ13zZb/PZ0NwoDP37V79IU44TX3gQ9Eryw2qJjZYot2phVYpu2KIao2RaUE MKf1/D+n36TtlE8cCFY6nFfZ0w22TkNKQDRuIiTP0yVoWwNq6gKjQqGfCUOqMVbtivQAudKC aiiC0dJE0BX/pye6+xmZlHzP/ej0gbCAhoThIpXkXZAzhjX5GubdSumvCglfk/baTX8rCgry qWr9E30GkK04t4mFqJiT7ir/bMxGCwpTOzxSAU2dkVxKTjrw13fCGz2TqmbptCiWWCi7UQT+ 3t/qow/JzSqo8YsjAgMBAAGjggKFMIICgTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQU9ZMXSh1ztn9/ILKlFJRXchkzNtIwRgYDVR0fBD8wPTA7oDmgN4Y1 aHR0cDovL2NybHYxLmhhcmljYS5nci9IYXJpY2FSb290Q0EyMDExL2NybHYxLmRlci5jcmww HwYDVR0jBBgwFoAUppFC/RNhSiOeCKQp5dgTBCPuQSUwbgYIKwYBBQUHAQEEYjBgMCEGCCsG AQUFBzABhhVodHRwOi8vb2NzcC5oYXJpY2EuZ3IwOwYIKwYBBQUHMAKGL2h0dHA6Ly93d3cu aGFyaWNhLmdyL2NlcnRzL0hhcmljYVJvb3RDQTIwMTEucGVtMIIBPwYDVR0gBIIBNjCCATIw ggEuBgwrBgEEAYHPEQEAAgcwggEcMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmhhcmljYS5n ci9kb2N1bWVudHMvQ1BTLnBocDCB5QYIKwYBBQUHAgIwgdgwShZDSGVsbGVuaWMgQWNhZGVt aWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgEBGoGJVGhpcyBjZXJ0aWZpY2F0ZSBpcyBzdWJqZWN0IHRvIEdyZWVrIGxhd3MgYW5kIG91 ciBDUFMuIFRoaXMgQ2VydGlmaWNhdGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGFjYWRlbWlj LCByZXNlYXJjaCBvciBlZHVjYXRpb25hbCBwdXJwb3Nlcy4wIwYDVR0eBBwwGqAYMAqCCC5h dXRoLmdyMAqBCC5hdXRoLmdyMA0GCSqGSIb3DQEBBQUAA4IBAQB7KcpoBLCArRNqwJiIaPAb LTmVvfn+uZ1QyXiyD5yS3R7eZjXRvTWnDyi9bNAti4B3P1haABXutuKdGuxGng8vJAnEamg3 f8jhE6lp3c1LrUgshcFlnmYgMAsEfBxBocNzzJS6c86oD8V9YJTu+2tMLwlJd11vq/56HaEO ICYt/6qTSGrv+VUviGzB9l1ueCX5JFL4YJ4E1O9MY2tXM4MpmkQenRnUV6OP//sLvoxhxmlB 7x+Xsnn072g0NwdxI2o86ioQiIu8rHntfqlQ3beAfhpTk7UPETLa2orWdNs3r2KKx8EEXGDO OWeXdoREdJxThfi0pCcS5kjt4iGFsePhMIIGkTCCBXmgAwIBAgIIGV2SCm6+XmIwDQYJKoZI hvcNAQEFBQAwbDELMAkGA1UEBhMCR1IxLTArBgNVBAoTJEFyaXN0b3RsZSBVbml2ZXJzaXR5 IG9mIFRoZXNzYWxvbmlraTEuMCwGA1UEAxMlQVVUSCBVc2VycyBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBSNjAeFw0xMzExMTQwMDAwMDBaFw0xNTExMTIxMDMwMjFaMIHVMQswCQYDVQQG EwJHUjEtMCsGA1UECgwkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMRIw EAYDVQQLDAlJVCBDZW50ZXIxQTA/BgNVBAsMOENsYXNzIEIgLSBQcml2YXRlIEtleSBjcmVh dGVkIGFuZCBzdG9yZWQgaW4gc29mdHdhcmUgQ1NQMRowGAYDVQQDDBFWeXJvbmFzIFRzaW5n YXJhczEkMCIGCSqGSIb3DQEJARYVdnRzaW5nYXJhc0BpdC5hdXRoLmdyMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw6B4UQRmXyWwpWVB797qLga/PEIwYE/QTYhMFwNU4bbp KT6A/GF2G828QRyFbuWLIfLLfSiCcou/Jkj70KFXRoBBSGQf9ySvoFG7tKt/TNrrIhcyJ6LY dPOpyldgwnjfHqndIfPnfaNq8MeB4gtZjz/HH7wHc3o4DLNYgOiZkFYgfOe8dw3igQFJarvQ NHyYgbxjAz60Onl51VxygMvlIwNSt6RHxsUaYhllXMN1tA1Jwrjtr2ujcvb3a14ovtn76otl 7g0RIdzUIclyfTPFgU89XpQP6BnlKTxue9Jf/H+Pke3GfVEnt9DmpFgIFfoEr7a82gP5ZQkO jGm9y/hCpQIDAQABo4ICyzCCAscwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCBeAwKQYDVR0l BCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3FAICMCkGCSsGAQQBgjcUAgQcHhoA UwBtAGEAcgB0AGMAYQByAGQAVQBzAGUAcjAdBgNVHQ4EFgQUORgFan/NYFhDRM8hMN5EQRzE J1QwHwYDVR0jBBgwFoAUr+5wVD1xwiwneYwbT/IQlKyactMwbwYIKwYBBQUHAQEEYzBhMCMG CCsGAQUFBzABhhdodHRwOi8vb2NzcC5wa2kuYXV0aC5ncjA6BggrBgEFBQcwAoYuaHR0cDov L3d3dy5wa2kuYXV0aC5nci9jZXJ0cy9BdXRoVXNlcnNDQVI2LnBlbTBFBgNVHR8EPjA8MDqg OKA2hjRodHRwOi8vY3JsdjEucGtpLmF1dGguZ3IvQXV0aFVzZXJzQ0FSNi9jcmx2MS5kZXIu Y3JsMIIBIAYDVR0gBIIBFzCCARMwggEPBgsrBgEEAbwdAgADBTCB/zA0BggrBgEFBQcCARYo aHR0cDovL3d3dy5wa2kuYXV0aC5nci9kb2N1bWVudHMvQ1BTLnBocDCBxgYIKwYBBQUHAgIw gbkwKxYkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMAMCAQEagYlUaGlz IGNlcnRpZmljYXRlIGlzIHN1YmplY3QgdG8gR3JlZWsgbGF3cyBhbmQgb3VyIENQUy4gVGhp cyBDZXJ0aWZpY2F0ZSBtdXN0IG9ubHkgYmUgdXNlZCBmb3IgYWNhZGVtaWMsIHJlc2VhcmNo IG9yIGVkdWNhdGlvbmFsIHB1cnBvc2VzLjA4BgNVHREEMTAvoC0GCisGAQQBgjcUAgOgHwwd dnRzaW5nYXJhc0BwY2xhYnMuaXRjLmF1dGguZ3IwDQYJKoZIhvcNAQEFBQADggEBAI7RqkI6 /pYikKVzPBewxaSDuXhsOArSwrq88w3MtGG4CNioGGT1umocpzVTtvoEeujcFzZ9ciIT6SMY XQsRhJs/JH7VtVg7YuR+vXzP3Pb7UwaFL1DvRinNmKnNrRGuXU1uBA0fiVbj7BdICCAEiCUn K+U3yuloLEVcRxH2oZm4yPRXdbnrXcWRvwnWnXhweKojgXcsbKh0tUS+yV9oI4l/UwArBmiI IhU8Wik3bfudh74wNTRjKSZvcJk2/CcExDG5KB5tj5NAVRJ4pECiMbC1KuXY/TX48qaaH0zS kML9Tvc1+FYB+S03Ij+UuegOX7kyTaNnJnjcdewh0zJi2J4xggOEMIIDgAIBATB4MGwxCzAJ BgNVBAYTAkdSMS0wKwYDVQQKEyRBcmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25p a2kxLjAsBgNVBAMTJUFVVEggVXNlcnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUjYCCBld kgpuvl5iMAkGBSsOAwIaBQCgggHhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MDMyNzA4MTcyNFowIwYJKoZIhvcNAQkEMRYEFEhu+8QAjJT1IHWGq5z0 1cfvhNXWMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgYcGCSsGAQQBgjcQBDF6MHgwbDELMAkGA1UEBhMCR1IxLTArBgNVBAoTJEFy aXN0b3RsZSBVbml2ZXJzaXR5IG9mIFRoZXNzYWxvbmlraTEuMCwGA1UEAxMlQVVUSCBVc2Vy cyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBSNgIIGV2SCm6+XmIwgYkGCyqGSIb3DQEJEAIL MXqgeDBsMQswCQYDVQQGEwJHUjEtMCsGA1UEChMkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2Yg VGhlc3NhbG9uaWtpMS4wLAYDVQQDEyVBVVRIIFVzZXJzIENlcnRpZmljYXRpb24gQXV0aG9y aXR5IFI2AggZXZIKbr5eYjANBgkqhkiG9w0BAQEFAASCAQBifuF7V2X4xMiyDI89lp2gTuDN K87rMPEYh9W3+4YgqGAw4R8yv7JWDBua8IN/lSdZHNgTpb5Scwxh9lJpq9vH1Aa1EflNM52m VS0po9KKWYXA2WJ6VqIzl+8cefetseOPbWV/cj6W7iXWlUCPua4ZeVHjJN7GAxLc7w8/krFp aTBNpft2V0najsPnE6xdXLAd/qx3bqe2UdjGVA4EzrtJxwAnl8cd4BpK0ixU9wU1fjmsi3z2 eAcdtDDn4tfdBkJfxsquf+yDSpZyG+48uV6WwUJzCWmn3rjsLDQkFM5ckwjL1pOe40bih7gg xyNiE58QdUXL+0qcaMugdXJy436fAAAAAAAA --------------ms000608090900090008070301-- From nobody Thu Mar 27 08:18:59 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A0A1A00BC for ; Wed, 26 Mar 2014 22:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms6mzm0851Uf for ; Wed, 26 Mar 2014 22:08:59 -0700 (PDT) Received: from hermes7.ccf.auth.gr (hermes7.ccf.auth.gr [155.207.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id 347951A00A9 for ; Wed, 26 Mar 2014 22:08:58 -0700 (PDT) Received: from [192.168.2.20] (ppp079167184158.access.hol.gr [79.167.184.158]) (authenticated bits=0) by hermes7.ccf.auth.gr (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id s2R58qeE000359 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 27 Mar 2014 07:08:55 +0200 User-Agent: mySecureMail/2.5.8104 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="----C0EOR3ZIV4U3PZV9A255MRL4HVA4WF" From: Vyron Tsingaras Date: Thu, 27 Mar 2014 07:08:46 +0200 To: pkix@ietf.org Message-ID: X-Virus-Scanned: clamav-milter 0.97.8 at hermes7 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/RXgW7_H1jTGo2PNTQ4LX1MO_YZk X-Mailman-Approved-At: Thu, 27 Mar 2014 08:18:54 -0700 Subject: [pkix] RFC 5280/6818 X.509v3 DNS Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 05:09:03 -0000 ------C0EOR3ZIV4U3PZV9A255MRL4HVA4WF Content-Type: multipart/alternative; boundary="----W8Y62D4L97GOWWN9TNH613R6M667US" ------W8Y62D4L97GOWWN9TNH613R6M667US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am not sure if this is the right place for this but here goes: What is th= e reasoning behind name constraints format for type =E2=80=9CDNS name=E2=80= =9D as specified in RFC 5280? In other words why is it different from the U= RI scheme, where =E2=80=9C=2Eexample=2Ecom=E2=80=9D would satisfy *=2Eexamp= le=2Ecom, *=2E*example=2Ecom BUT not example=2Ecom? Currently as it stands,= a CA has no way to restrict itself from issuing certificates for example= =2Ecom while allowing itself to issue for host=2Eexample=2Ecom=2E A NC for = type DNS =E2=80=9Cexample=2Ecom=E2=80=9D will allow the CA to issue a certi= ficate for example=2Ecomwhen the desired behavior would be to only allow = =E2=80=9C=2Eexample=2Ecom=E2=80=9D(in URI scheme)=2E This could be undesir= able=2E It seems like while the scheme for URIs and email where updated whe= reas the DNS scheme was left untouched=2E Wouldn=E2=80=99t it be better if = the DNS scheme followed the other 2? The relevant section is 4=2E2=2E1=2E1= 0 in RFC 5280 -- Sent with mySecureMail=2E http://www=2Emysecurephone=2Ee= u/ ------W8Y62D4L97GOWWN9TNH613R6M667US Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am not sure if this is the right place for this but here goes: What= is the reasoning behind name constraints format for type “DNS name&#= 8221; as specified in RFC 5280? In other words why= is it different from the URI scheme, where “=2Eexample=2Ecom” would satisfy *=2Eexample=2Ecom, *=2E*example=2Ecom BUT not example= =2Ecom? Currently as it stands, a CA has no way to restrict itself from= issuing certificates for example=2Ecom while allowing itself to issue for host=2Eexample=2Ecom=2E A NC for type DNS “example=2Ecom” will allow the CA to issue a= certificate for example=2Ecomwhen the desired behavior would be to only al= low “=2Eexample=2Ecom”(in URI scheme)=2E  This could be undesirable=2E It seems like= while the scheme for URIs and email where updated whereas the DNS scheme w= as left untouched=2E Wouldn’t it be better if the DNS scheme followed= the other 2?

The relevant section is
4=2E2=2E1=2E10 in RFC 5280
<= br/>
--
Sent with mySecureMail=2E
http://www=2Emysecurephone=2E= eu/ ------W8Y62D4L97GOWWN9TNH613R6M667US-- ------C0EOR3ZIV4U3PZV9A255MRL4HVA4WF Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s"; size=6642 MIIZ7gYJKoZIhvcNAQcCoIIZ3zCCGdsCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghbqMIIEMTCCAxmgAwIBAgIBADANBgkqhkiG9w0BAQUFADCBlTELMAkGA1UEBhMCR1IxRDBCBgNV BAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0 aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRp b25zIFJvb3RDQSAyMDExMB4XDTExMTIwNjEzNDk1MloXDTMxMTIwMTEzNDk1MlowgZUxCzAJBgNV BAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRp b25zIENlcnQuIEF1dGhvcml0eTFAMD4GA1UEAxM3SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2Vh cmNoIEluc3RpdHV0aW9ucyBSb290Q0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKlTAOMupvaO+mDYLZU++CwqVE7NuYRhlFhPjz2L5EPzdYmNUeTDN9KKiE15HrcS3UN4SoqS 5tdI1Q+kOilENbgH9mgdVc04UfCMJDGFr4PJfel3r+0ae50X+bOdOFAPplp5kYCvN66m0zH7tSYJ nTxa71HFK9+WXesyHgLacEnsbgzImjeN9/E2YEsmLIKe0HjzDQ9jpFEw4fkrJxIH2Oq9GGKYsFk3 fb7u8yBRQlqD75O6aRXxYp2fmTmCobd0LovUxQt7L/DICto9eQqakxylKHJzkUOap9FNhYS5qXSP FEDH3N6sQWRstBmbAmNtJGSPRLIl6s5ddAxjMlyNh+UCAwEAAaOBiTCBhjAPBgNVHRMBAf8EBTAD AQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUppFC/RNhSiOeCKQp5dgTBCPuQSUwRwYDVR0eBEAw PqA8MAWCAy5ncjAFggMuZXUwBoIELmVkdTAGggQub3JnMAWBAy5ncjAFgQMuZXUwBoEELmVkdTAG gQQub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAf73lB4XtuP7KMhjdCSk4cNx6NZrokgclPEg8hwAOX hiVtXdMiKahsog2p6z0GW5k6x8zDmjR/qw7IThzh+uTczQ2+vyT+bOdrwg3IBp5OjWEopmr95fZi 6hg8TqBTnbI6nOulnJEWtk2C4AwFSKls9cz4y51JtPACpf1wA+2KIaWuE4ZJwzNzvoc7dIsXRSZM FpGD/md9zU1jZ/rzAxKWeAaNsWftjj++n08C9bMJL/NMh98qy5V8AcysNnq/onN694/BtZqhFLKP M58N7yLcZnuEvUUXBj08yrl3NI/K6s8/MT7jiOOASSXIl7WdmplNsDz4SgCbZN2fOUvRJ9e4MIIF 6zCCBNOgAwIBAgIIEtthLKdUgwEwDQYJKoZIhvcNAQEFBQAwgZAxCzAJBgNVBAYTAkdSMUQwQgYD VQQKEztIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1 dGhvcml0eTE7MDkGA1UEAxMyQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpIENl bnRyYWwgQ0EgUjMwHhcNMTMxMDAyMDc1MDUwWhcNMTcxMDAxMDc1MDUwWjBsMQswCQYDVQQGEwJH UjEtMCsGA1UEChMkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMS4wLAYDVQQD EyVBVVRIIFVzZXJzIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFI2MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEArHK0IMNrumYMbr2p3Gn+eHWo6VdffVh4ONOM9HXOq+AnnSAZp39prvrM 9atBWkHzeoU83hxciM0h4hz1cBVo93WmzrXG3MowFrH7vG4CpX7UzcEKCUtpJydHquQsBQ6rbauW Kvs7ooknzbxh6tvlFqhavQLmvZ9bk7fqmKtsVjyHDHyQ76z2ta+EqGiuXNVOgjymfxiodBmzEW2m HiPYDmtlnOQV22ybw98ThX7XQ8+5aIC76HU6/lsEC1S4P66D9lNrvmhHP2IFkWJY2UwpNsKO3+j9 xEPwusdBLfk0mIMEmobVg5V99DRWLhXKNK2MsW+42N789bUg/6BryjBh7QIDAQABo4ICajCCAmYw DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFK/ucFQ9ccIsJ3mMG0/y EJSsmnLTMEcGA1UdHwRAMD4wPKA6oDiGNmh0dHA6Ly9jcmx2MS5wa2kuYXV0aC5nci9BdXRoQ2Vu dHJhbENBUjMvY3JsdjEuZGVyLmNybDAfBgNVHSMEGDAWgBT1kxdKHXO2f38gsqUUlFdyGTM20jBx BggrBgEFBQcBAQRlMGMwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLnBraS5hdXRoLmdyMDwGCCsG AQUFBzAChjBodHRwOi8vd3d3LnBraS5hdXRoLmdyL2NlcnRzL0F1dGhDZW50cmFsQ0FSMy5wZW0w ggEgBgNVHSAEggEXMIIBEzCCAQ8GCysGAQQBvB0CAAMFMIH/MDQGCCsGAQUFBwIBFihodHRwOi8v d3d3LnBraS5hdXRoLmdyL2RvY3VtZW50cy9DUFMucGhwMIHGBggrBgEFBQcCAjCBuTArFiRBcmlz dG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUg aXMgc3ViamVjdCB0byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11 c3Qgb25seSBiZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcHVy cG9zZXMuMCMGA1UdHgQcMBqgGDAKggguYXV0aC5ncjAKgQguYXV0aC5ncjANBgkqhkiG9w0BAQUF AAOCAQEAKBzJyxn0fis4nycAA2F5gmPe7l9Tl5Z3DGShl9Dm6CayHzUAE7ztcEYlgaPmD/zJbsKs bpY4950E7TOM2oGlEKhlND/pxNSkuhF21JwXC/9ymegrG89jSaoIsk67dsYDncuhmKlkcffxxh9K AHvyqZzdgL0QuoZK6fnlR5hm1z5klxr8DZAi4lQ+6+J0cXusYy0DHGKoaSB4HPCMzLrCr6HE70x/ eCzBHpBhzePHH71wP/5G/+jG94W6kwNtMD6cPrvWIoCCW1gYWLxySEN1MQf2bMi+iPCIsa49JxpG o0pbiAAZ2vP0sTknAP2KPRZoGtsTRwc/gYqXMKQoOotubTCCBi0wggUVoAMCAQICBQEAAAAFMA0G CSqGSIb3DQEBBQUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMg YW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxQDA+BgNVBAMTN0hlbGxl bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgUm9vdENBIDIwMTEwHhcNMTMw OTEyMDgwNDU0WhcNMjEwOTEwMDgwNDU0WjCBkDELMAkGA1UEBhMCR1IxRDBCBgNVBAoTO0hlbGxl bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0aG9yaXR5MTsw OQYDVQQDEzJBcmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kgQ2VudHJhbCBDQSBS MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJv4zymSYY5mOVLl4X8P4UE5kHJiAyn/ dw/N88ngcl0vBVoTc7sVDXfNlv89nQ3CgM/ftXv0hTjhNfeBD0SvLDaomNlii3amFVim7YohqjZF pQQwp/X8P6ffpO2UTxwIVjqcV9nTDbZOQ0pANG4iJM/TJWhbA2rqAqNCoZ8JQ6oxVu2K9AC50oJq KILR0kTQFf+nJ7r7GZmUfM/96PSBsICGhOEileRdkDOGNfka5t1K6a8KCV+T9tpNfysKCvKpav0T fQaQrTi3iYWomJPuKv9szEYLClM7PFIBTZ2RXEpOOvDXd8IbPZOqZum0KJZYKLtRBP7e3+qjD8nN KqjxiyMCAwEAAaOCAoUwggKBMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1Ud DgQWBBT1kxdKHXO2f38gsqUUlFdyGTM20jBGBgNVHR8EPzA9MDugOaA3hjVodHRwOi8vY3JsdjEu aGFyaWNhLmdyL0hhcmljYVJvb3RDQTIwMTEvY3JsdjEuZGVyLmNybDAfBgNVHSMEGDAWgBSmkUL9 E2FKI54IpCnl2BMEI+5BJTBuBggrBgEFBQcBAQRiMGAwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3Nw LmhhcmljYS5ncjA7BggrBgEFBQcwAoYvaHR0cDovL3d3dy5oYXJpY2EuZ3IvY2VydHMvSGFyaWNh Um9vdENBMjAxMS5wZW0wggE/BgNVHSAEggE2MIIBMjCCAS4GDCsGAQQBgc8RAQACBzCCARwwMgYI KwYBBQUHAgEWJmh0dHA6Ly93d3cuaGFyaWNhLmdyL2RvY3VtZW50cy9DUFMucGhwMIHlBggrBgEF BQcCAjCB2DBKFkNIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagYlUaGlzIGNlcnRpZmljYXRlIGlzIHN1YmplY3Qg dG8gR3JlZWsgbGF3cyBhbmQgb3VyIENQUy4gVGhpcyBDZXJ0aWZpY2F0ZSBtdXN0IG9ubHkgYmUg dXNlZCBmb3IgYWNhZGVtaWMsIHJlc2VhcmNoIG9yIGVkdWNhdGlvbmFsIHB1cnBvc2VzLjAjBgNV HR4EHDAaoBgwCoIILmF1dGguZ3IwCoEILmF1dGguZ3IwDQYJKoZIhvcNAQEFBQADggEBAHspymgE sICtE2rAmIho8BstOZW9+f65nVDJeLIPnJLdHt5mNdG9NacPKL1s0C2LgHc/WFoAFe624p0a7Eae Dy8kCcRqaDd/yOETqWndzUutSCyFwWWeZiAwCwR8HEGhw3PMlLpzzqgPxX1glO77a0wvCUl3XW+r /nodoQ4gJi3/qpNIau/5VS+IbMH2XW54JfkkUvhgngTU70xja1czgymaRB6dGdRXo4//+wu+jGHG aUHvH5eyefTvaDQ3B3EjajzqKhCIi7ysee1+qVDdt4B+GlOTtQ8RMtraitZ02zevYorHwQRcYM45 Z5d2hER0nFOF+LSkJxLmSO3iIYWx4+EwggaRMIIFeaADAgECAggZXZIKbr5eYjANBgkqhkiG9w0B AQUFADBsMQswCQYDVQQGEwJHUjEtMCsGA1UEChMkQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVGhl c3NhbG9uaWtpMS4wLAYDVQQDEyVBVVRIIFVzZXJzIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFI2 MB4XDTEzMTExNDAwMDAwMFoXDTE1MTExMjEwMzAyMVowgdUxCzAJBgNVBAYTAkdSMS0wKwYDVQQK DCRBcmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kxEjAQBgNVBAsMCUlUIENlbnRl cjFBMD8GA1UECww4Q2xhc3MgQiAtIFByaXZhdGUgS2V5IGNyZWF0ZWQgYW5kIHN0b3JlZCBpbiBz b2Z0d2FyZSBDU1AxGjAYBgNVBAMMEVZ5cm9uYXMgVHNpbmdhcmFzMSQwIgYJKoZIhvcNAQkBFhV2 dHNpbmdhcmFzQGl0LmF1dGguZ3IwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDoHhR BGZfJbClZUHv3uouBr88QjBgT9BNiEwXA1ThtukpPoD8YXYbzbxBHIVu5Ysh8st9KIJyi78mSPvQ oVdGgEFIZB/3JK+gUbu0q39M2usiFzInoth086nKV2DCeN8eqd0h8+d9o2rwx4HiC1mPP8cfvAdz ejgMs1iA6JmQViB857x3DeKBAUlqu9A0fJiBvGMDPrQ6eXnVXHKAy+UjA1K3pEfGxRpiGWVcw3W0 DUnCuO2va6Ny9vdrXii+2fvqi2XuDREh3NQhyXJ9M8WBTz1elA/oGeUpPG570l/8f4+R7cZ9USe3 0OakWAgV+gSvtrzaA/llCQ6Mab3L+EKlAgMBAAGjggLLMIICxzAMBgNVHRMBAf8EAjAAMAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwKQYJKwYB BAGCNxQCBBweGgBTAG0AYQByAHQAYwBhAHIAZABVAHMAZQByMB0GA1UdDgQWBBQ5GAVqf81gWENE zyEw3kRBHMQnVDAfBgNVHSMEGDAWgBSv7nBUPXHCLCd5jBtP8hCUrJpy0zBvBggrBgEFBQcBAQRj MGEwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLnBraS5hdXRoLmdyMDoGCCsGAQUFBzAChi5odHRw Oi8vd3d3LnBraS5hdXRoLmdyL2NlcnRzL0F1dGhVc2Vyc0NBUjYucGVtMEUGA1UdHwQ+MDwwOqA4 oDaGNGh0dHA6Ly9jcmx2MS5wa2kuYXV0aC5nci9BdXRoVXNlcnNDQVI2L2NybHYxLmRlci5jcmww ggEgBgNVHSAEggEXMIIBEzCCAQ8GCysGAQQBvB0CAAMFMIH/MDQGCCsGAQUFBwIBFihodHRwOi8v d3d3LnBraS5hdXRoLmdyL2RvY3VtZW50cy9DUFMucGhwMIHGBggrBgEFBQcCAjCBuTArFiRBcmlz dG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUg aXMgc3ViamVjdCB0byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11 c3Qgb25seSBiZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcHVy cG9zZXMuMDgGA1UdEQQxMC+gLQYKKwYBBAGCNxQCA6AfDB12dHNpbmdhcmFzQHBjbGFicy5pdGMu YXV0aC5ncjANBgkqhkiG9w0BAQUFAAOCAQEAjtGqQjr+liKQpXM8F7DFpIO5eGw4CtLCurzzDcy0 YbgI2KgYZPW6ahynNVO2+gR66NwXNn1yIhPpIxhdCxGEmz8kftW1WDti5H69fM/c9vtTBoUvUO9G Kc2Yqc2tEa5dTW4EDR+JVuPsF0gIIASIJScr5TfK6WgsRVxHEfahmbjI9Fd1uetdxZG/CdadeHB4 qiOBdyxsqHS1RL7JX2gjiX9TACsGaIgiFTxaKTdt+52HvjA1NGMpJm9wmTb8JwTEMbkoHm2Pk0BV EnikQKIxsLUq5dj9NfjyppofTNKQwv1O9zX4VgH5LTciP5S56A5fuTJNo2cmeNx17CHTMmLYnjGC AsgwggLEAgEBMHgwbDELMAkGA1UEBhMCR1IxLTArBgNVBAoTJEFyaXN0b3RsZSBVbml2ZXJzaXR5 IG9mIFRoZXNzYWxvbmlraTEuMCwGA1UEAxMlQVVUSCBVc2VycyBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBSNgIIGV2SCm6+XmIwDQYJYIZIAWUDBAIBBQCgggEhMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDMyNzA3MDg0N1owLwYJKoZIhvcNAQkEMSIEIEaPQGzo iTgjMsi6Say6Eg32rJ+1zvBHdCns3NRAVArfMIG1BgkqhkiG9w0BCQ8xgacwgaQwCwYJYIZIAWUD BAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEBMAsG CSqGSIb3DQEBCzALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQENMAsGCSqGSIb3DQEBDDALBglghkgB ZQMEAgEwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjANBgkqhkiG9w0BAQEFAASC AQBbUw+Dzz9iRYDfcvsRJpq9ZLLCAJyQVOjA8y6oKM5EqiYHWGR52AaVzZ5n3ogUlZRzgFGwbDTT 6yMyHZA9eKET6nh1l8W07ISI89P6IFNMlBAdJ561LXQleNn485HIqN6mESzy7OXqLZ5Gkq4XhJcC AQRLYdzvZ/EFNa2zMqucJw9WzDGu/GRfQHIELVdgo09evM7SLtAsHfj8bTL0rCBRPRiKAuGldbOp dnv8GBtCAGfETtexVjyFVFUS452E5MNVOS5rEmoCCV9xaBR+RuqigqLhXXVxPE2D4Fr4QgWdyLDy erNMoSWA7n1z2CHeUrJTZpH/iFrXQYQVB3tY4pSc ------C0EOR3ZIV4U3PZV9A255MRL4HVA4WF-- From nobody Thu Mar 27 11:34:58 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914E11A0720 for ; Thu, 27 Mar 2014 11:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.733 X-Spam-Level: X-Spam-Status: No, score=0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBr01E53QBVd for ; Thu, 27 Mar 2014 11:34:52 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.80.20]) by ietfa.amsl.com (Postfix) with ESMTP id CF10B1A070A for ; Thu, 27 Mar 2014 11:34:51 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id EAC44FB36470; Thu, 27 Mar 2014 13:34:49 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 9A77DFB362BD for ; Thu, 27 Mar 2014 13:34:49 -0500 (CDT) Received: from [96.231.225.192] (port=51939 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WTF8a-0006lV-KL; Thu, 27 Mar 2014 13:34:49 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: <52301F43.8000906@free.fr> Date: Thu, 27 Mar 2014 14:34:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130730074001.16244.7339.idtracker@ietfa.amsl.com> <520401E9.9070609@ieca.com> <022f01ceadda$4d4f1ff0$e7ed5fd0$@akayla.com> <52301F43.8000906@free.fr> To: Denis X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:51939 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 27 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/-j6DcBUT14COfhH5QrkpibmbkFM Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-turner-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 18:34:55 -0000 Denis, Inline=85 and a new version is available: = http://datatracker.ietf.org/doc/draft-turner-cmc-serverkeygeneration/ spt On Sep 11, 2013, at 03:44, Denis wrote: > I have several concerns with this proposal which is targeted to the = Standards track. [spt] Again thanks for your review. You're review resulted in basically = a new version of the draft. > 1. What means compliance to this standard which has a fairly important = number of options ?=20 > How can interoperability be achieved with so many options ? The = document does not address=20 > the responses to these questions. [spt] RAs are optional in RFC 5280 so those scenarios are optional. = With respect to whether AuthData or SignedData are the MTI we think both = are MTI and by saying nothing that is the case. For the server, the = main requirement is in section 4: Clients and servers MUST support id-cmc- shroudWithPublicKey. Client and servers SHOULD support id-cmc- shroudWithSharedSecret. > 2. The title is: "Server key generation". When reading the text it = appears that the right title=20 > should rather be : "CA/RA key generation=94. Disagree based on the definition in CMC a server is either the CA or RA, = but I can see changing it to: CMC (Certificate Management over Cryptographic Message Syntax) Extensions: Server Side Key Generation > 3. On page 4, a sentence states: " Section 7 describes additional CMC > error codes. Section 8 describes additional exchanges when the > server requires the client provide Proof-of-Possession (POP). > =20 > The problem is that the reason(s) to support POP is neither explained = here, neither explained=20 > in section 8, neither explained in the security considerations = section. As a compromise how about I add a pointer to RFC 4211 from the security = considerations for why a CA might want to do POP and add that it's a = CP-driven choice: POP is important; [RFC4211] provides some information about POP; for = server-generated keys it can only be provided after the server-generated = key has been returned by the client (see Section 8). Whether a server = requires POP is a CP dependent [RFC3647]. =20 > 4. There are four basic scenarios. The fifth one is unclear as = currently described on page 7. > =20 > The advantages / disadvantages of each method should be clearly = advertised. There is one term=20 > which should be used: PFS (Perfect Forward Secrecy). Using PFS in this = context means that even=20 > if a third party managed to intercept a symmetrical key or a private = key, then that party can=20 > only use the intercepted key in that exchange. Because the next secret = key is not based on the=20 > previously intercepted key, the third party must begin a new brute = force calculation to guess=20 > the new key value. > =20 > Scenario 1 does not provide PFS. All others provide PFS. > Scenarios 2 and 3 are similar in concept: > - Scenario 2 uses secret keys. > - Scenario 3 uses certificates usable for data authentication. I took a shot at explaining the scenarios differently by listing the = scenario and then explaining the characteristics. Let me know what you = think - see Section 2. I can buy PFS as a differentiating characteristic but I'm not sure that = I completely agree on which scenario gets it but there's text there that = we can argue about now. > 5. The management of a PKI for the clients might prevent the use of = scenarios 3 and 4: > - Smartcards, smartcard readers and PINs may need to be used. > - Otherwise, passphrases will need to be managed and protected. > - Clients must have certificates before being able asking = certificates=20 > for machines. > - Client certificates may need to be checked for revocation. > =20 > These disadvantages are not mentioned, but should be advertised. So the disadvantages are the typical PKI woes? I'm not sure we need to = include 'em all do we? Anyway I took a shot at better describing some = of the woes/hidden dragons. =20 > Scenario 4 normally requires two certificates belonging to the client:=20= > one for authentication and one for encryption. I think this is already addressed in the text: Here, clients can request a certificate with a certificate or certificates that the client already has. ^^^^^^^^^^^^ > 6. All the scenarios that are described mandate the client, prior to = the exchange, either=20 > to share a secret with the CA/RA or to already have at least one = public key certificate. > =20 > All the scenarios have the following points in common: > =20 > - a management of all the clients must be performed in advance, > - the processing of the requests can be fully automated. Yes this is true. > There is another scenario that has different advantages /disadvantages = and which requires=20 > a manual processing of the requests. > =20 > The main idea is that clients, prior to the exchange, do not need to = share any secret with=20 > the CA/RA or to already have a public key certificate known or = verifiable by the CA/RA. > =20 > Clients only need to know a public certificate (or a public key) for = the CA/RA.=20 > That certificate is usable for encryption. > =20 > The scenario is as follows: > =20 > The client encrypts the following: the CertRequest (see RFC 5272), the = OID of the CP=20 > under which the certificate should be issued, an identifier of the = type of certificate=20 > that is requested under that policy, a secret key to be used by the = CA/RA when responding,=20 > a derivation method to compute two secret keys when responding, an = identifier of the client,=20 > an identifier of the request for this client, a cryptographic checksum = over the various fields. > =20 > When the CA/RA receives the request, it can only verify that it is a = well formed request.=20 > Then the client and the CA/RA can use a side channel (out of bands = means) where no confidentiality=20 > is required to authenticate the request. This may be performed for = example using a phone call,=20 > a SMS, an email or a combination of the above means. > =20 > Once authentication of the request has been achieved, the server will = generate the key pair and=20 > the certificate and will derive two keys from the secret key and use = one for encryption and=20 > the other one for authentication. In this way the client obtains the = private key (encrypted=20 > under one key) while the response which contains the certificate is = authenticated using the=20 > other secret key. > =20 > Requests that are not authenticated by clients after X days are simply = deleted. > =20 > I would appreciate to have such a scenario added. My initial thought here was this won't fly because CMC requires that = authenticated or signed data encapsulate the PKI data (i.e., it's the = outer most siganture) so that would be an update to the base spec. Jim = however pointed out that we could do something that meets your needs = with CMC so we added the following: While it is generally assumed that the identifier and the shared secret are generated by the key generation server and then securely transported to the end-entity, there is no practical reason why this cannot be done in the opposite direction. In this case the end-entity will generate an identifier and shared secret. When the server receives the CMC key generation, it recognizes that it does not correspond to an existing identifier/secret pair and puts it on hold. The end-entity then communicates the identifier and secret to the server. The server then performs the necessary user management dealing with identity validation and certificate setup. If that passes and the secret appears random, then the certificate will be issued and the response returned. If it does not pass checking then the certificate will fail to issue. I'll try to add some words in to explain this in the appropriate = scenarios. > If scenarios 3 and 4 are maintained, I would propose to clearly = separate them from the others=20 > and mention that they require a PKI for the clients. > =20 > To summarise: > =20 > - a scenario 0 which is targeted for human beings and does not rely = on a pre-shared secret=20 > or certificates for clients and supports PFS. > =20 > - a scenario 1 which relies on a pre-shared secret, but does not = support PFS. > =20 > - a scenario 2 which relies on a pre-shared secret and supports PFS. > =20 > Scenarios which require certificates for clients. > =20 > - a scenario 3 which relies on one certificate and supports PFS. > =20 > - a scenario 3 which relies on two certificates and supports PFS. I didn=92t do exactly as you proposed but there were significant changes = made to the section. Let us know what you think. > 7. About scenario 5. I do not think that what is written on page 13 is = always applicable : > =20 > "When the RA generates the key on behalf of the client, the RA > effectively becomes a proxy for the client from the CA's = perspective. > The protocol exchange between the RA and CA is identical to other > situations in which a client requests a certificate.=20 > =20 > Usually the CA trusts the RA and will use a different protocol between = them. The diagrams=20 > later on shows both the RA and the CA. The introduction should tackle = this topic earlier=20 > and explain the relationships. So I've got some of the trust relationship information addressed later = but I can see adding it in s5 too. Let me know what you think about the = additions in s2.5 3rd para. > 8. I have a substantial comment on section 6.1. > =20 > ServerKeyGenRequest ::=3D SEQUENCE { > certificateRequest CertTemplate, > shroudMethod ShroudMethod, > algCapabilities SMimeCapabilties OPTIONAL, > archiveKey BOOLEAN DEFAULT TRUE > } > =20 > The ASN.1 structure of CertTemplate is not provided, but this = structure is described=20 > in RFC 5272 as: > =20 > CertTemplate ::=3D SEQUENCE { > version [0] Version OPTIONAL, > serialNumber [1] INTEGER OPTIONAL, > signingAlg [2] AlgorithmIdentifier OPTIONAL, > issuer [3] Name OPTIONAL, > validity [4] OptionalValidity OPTIONAL, > subject [5] Name OPTIONAL, > publicKey [6] SubjectPublicKeyInfo OPTIONAL, > issuerUID [7] UniqueIdentifier OPTIONAL, > subjectUID [8] UniqueIdentifier OPTIONAL, > extensions [9] Extensions OPTIONAL } > =20 > The text states: > =20 > o certificateRequest contains the data fields that the client > suggests for the certificate being requested for the server > generated key pair. The format is TaggedRequest from = [RFC5272], > which supports both PKCS#10 and CRMF requests. > =20 > The text should refer to CertTemplate, but refers toTaggedRequest. > This is incorrect. Oh wow a great catch - yeah this ought to be pointing to TaggedRequest. > This structure is however insufficient to cover real use cases in = practice. > =20 > It is important to be able to add in ServerKeyGenRequest: > =20 > a) the OID of the CP under which the certificate should be issued. = Note: the certificate=20 > may contain an extension with anyPolicy, but the CA/RA may still need = to know under=20 > which CP the certificate should be issued, The capability to include the CP oid is available in both the PKCS#10 = and CRMF. In PKCS#10, you'd include the certificate policies extension = in the extensions attributes and in the CRMF you'd put it in the = extensions attribute. =20 > b) an identifier of the type of certificate that is requested under = that policy=20 > (if there is more than one under that CP). I'm not sure what you mean by including a OID for the certificate type. > 9. Section 8 does not explain under which circumstances POP is needed. I don't think we need to it's up to the server/CP to determine when it = is needed. When the server wants to do POP it uses the mechanism = described in s8. > 10. Section 9 (security considerations) is insufficient and should = address PFS.=20 > If POP is really needed, section 9 should add a few words. I think we covered PFS sufficiently in the earlier sections. I added a pointer to RFC 4211 for POP. =20 >=20 > 11. Editorial > =20 > Page 5 uses "shroud methods" and in the next line we have "shrouding = methods".=20 > Please make it consistent. fixed > 12. Typo on page 34 Fourth paragraph, line 2: > =20 > Change: > =20 > A compromised signature key, when used by the intended party, will > =20 > into > =20 > a compromised signature key, when used by the intended party, will >=20 fixed > Denis Thanks again for the review! >> Sean, >> I've read through the draft. It looks like it's much improved = over >> the previous draft. What's more it seems to make all of the changes = you >> agreed to in your response to Denis (June 1, 2012!). I'll leave it = to Denis >> to indicate whether he's in agreement, since I don't recall seeing = him reply >> to your response as to whether the proposed changes were agreeable. >> Certainly there were items you did not agree between the two of you. >>=20 >> The draft has a fair number of nits or minor areas that I = question. >> None of them cover the fundamentals of the concept. Since I collated >> my input in a Word document, I'm providing that to you under separate >> cover rather than retyping them into an e-mail as I would do for a >> Gen-ART review. Please look them over and feel free to respond to = the >> list with your thoughts. Or a revised draft would do just fine too. = ;-) >>=20 >> With the cleanups and clarifications I propose, I'd say that the >> draft covers my checkboxes for a server-generated key solution. I'd >> like to hear what others have to say. >>=20 >> -Peter >>=20 >> -----Original Message----- >> From:=20 >> pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org >> ] On Behalf Of Sean >> Turner >> Sent: Thursday, August 08, 2013 1:39 PM >> To:=20 >> pkix@ietf.org >>=20 >> Subject: [pkix] Fwd: I-D Action: = draft-turner-cmc-serverkeygeneration-00.txt >>=20 >> >>=20 >> Here's a revised version of a draft that was formerly a wg draft. >>=20 >> Denis' comments from a while back actually resulted in a complete = re-write. >> Comments are welcome. >>=20 >> spt >>=20 >> >>=20 >> -------- Original Message -------- >> Subject: I-D Action: draft-turner-cmc-serverkeygeneration-00.txt >> Date: Tue, 30 Jul 2013 00:40:01 -0700 >> From:=20 >> internet-drafts@ietf.org >>=20 >> Reply-To:=20 >> internet-drafts@ietf.org >>=20 >> To:=20 >> i-d-announce@ietf.org >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : CMC (Certificate Management over Cryptographic=20= >> Message Syntax) Extensions: Server Key Generation >> Author(s) : Jim Schaad >> Sean Turner >> Paul Timmel >> Filename : draft-turner-cmc-serverkeygeneration-00.txt >> Pages : 42 >> Date : 2013-07-30 >>=20 >> Abstract: >> This document defines a set of extensions to the Certificate >> Management over Cryptographic Message Syntax (CMC) protocol that >> addresses the desire to support server-side generation of keys. = This >> service is provided by the definition of additional control >> statements within the CMC architecture. Additional CMC errors = are >> also defined. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >>=20 >> https://datatracker.ietf.org/doc/draft-turner-cmc-serverkeygeneration >>=20 >>=20 >> There's also a htmlized version available at: >>=20 >> http://tools.ietf.org/html/draft-turner-cmc-serverkeygeneration-00 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at=20 >> tools.ietf.org >> . >>=20 >> Internet-Drafts are also available by anonymous FTP at: >>=20 >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> I-D-Announce mailing list >>=20 >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >>=20 >> Internet-Draft directories:=20 >> http://www.ietf.org/shadow.html >>=20 >> or=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >>=20 >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >>=20 >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Sat Mar 29 19:23:10 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533211A0728 for ; Sat, 29 Mar 2014 19:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIzNKt3mPppG for ; Sat, 29 Mar 2014 19:23:04 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 940621A0716 for ; Sat, 29 Mar 2014 19:23:03 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 29 Mar 2014 22:23:00 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 29 Mar 2014 22:22:59 -0400 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 293A76E803C for ; Sat, 29 Mar 2014 22:22:53 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s2U2MxMT62783650 for ; Sun, 30 Mar 2014 02:22:59 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s2U2MwCS002971 for ; Sat, 29 Mar 2014 22:22:59 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s2U2MwD4002968; Sat, 29 Mar 2014 22:22:58 -0400 In-Reply-To: References: To: Vyron Tsingaras MIME-Version: 1.0 X-KeepSent: E3E2CA78:6EF9F075-85257CAB:00018D85; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Tom Gindin Message-ID: Date: Sat, 29 Mar 2014 22:22:57 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 9.0.1IF1|November 26, 2013) at 03/29/2014 22:22:58, Serialize complete at 03/29/2014 22:22:58 Content-Type: multipart/alternative; boundary="=_alternative 000D15FA85257CAB_=" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14033002-7182-0000-0000-00000A2C3E47 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/yrtiiFUyD4LGvZ9lvaaJ2m3h5H0 Cc: pkix@ietf.org Subject: Re: [pkix] RFC 5280/6818 X.509v3 DNS Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 02:23:08 -0000 This is a multipart message in MIME format. --=_alternative 000D15FA85257CAB_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I don't know if you'll consider this message fully responsive, but = this practice has been the case since RFC 2459 in January '99. X.509v3,=20 which predates that, gave no format for DNS name constraints or those in=20 any Internet format. I joined the group shortly after RFC 2459, but it=20 appears that at least two members agreed with you then:=20 http://www.ietf.org/mail-archive/web/pkix/current/msg21192.html and=20 http://www.ietf.org/mail-archive/web/pkix/current/msg21190.html For what it's worth I tend to agree with James' and Paul's point=20 that permitting issuers to make that distinction makes sense. That does=20 not mean that adding it 15 years after the original is as clearly correct=20 as it would have been then, and the PKIX group is no longer in a position=20 to do anything about it. Tom Gindin, CISSP P.S. The opinions above are mine, and not necessarily those of my=20 employer From: Vyron Tsingaras To: pkix@ietf.org,=20 Date: 03/27/2014 11:19 AM Subject: [pkix] RFC 5280/6818 X.509v3 DNS Name Constraints Sent by: "pkix" I am not sure if this is the right place for this but here goes: What is=20 the reasoning behind name constraints format for type ?DNS name? as=20 specified in RFC 5280? In other words why is it different from the URI=20 scheme, where ?.example.com? would satisfy *.example.com, *.*example.com=20 BUT not example.com? Currently as it stands, a CA has no way to restrict=20 itself from issuing certificates for example.com while allowing itself to=20 issue for host.example.com. A NC for type DNS ?example.com? will allow the = CA to issue a certificate for example.comwhen the desired behavior would=20 be to only allow ?.example.com?(in URI scheme). This could be=20 undesirable. It seems like while the scheme for URIs and email where=20 updated whereas the DNS scheme was left untouched. Wouldn?t it be better=20 if the DNS scheme followed the other 2? The relevant section is 4.2.1.10 in RFC 5280 -- Sent with mySecureMail. http://www.mysecurephone.eu/[attachment "smime.p7s" deleted by Tom=20 Gindin/Watson/IBM] =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 000D15FA85257CAB_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable         I don't know if you'll consider this message fully responsive, but this practice has been the case since RFC 2459 in January '99.  X.509v3, which predates that, gave no format for DNS name constraints or those in any Internet format.  I joined the group shortly after RFC 2459, but it appears that at least two members agreed with you then: htt= p://www.ietf.org/mail-archive/web/pkix/current/msg21192.html and http://www.ietf.org/mail-archive/web/pk= ix/current/msg21190.html
        For what it's worth I tend to agree with James' and Paul's point that permitting issuers to make that distinction makes sense.  That does not mean that adding it 15 years after the original is as clearly correct as it would have been then, and the PKIX group is no longer in a position to do anything about it.

Tom Gindin, CISSP

P.S.         The opinions above are mine, and not necessarily those of my employer




From:     =    Vyron Tsingaras <vtsinga= ras@it.auth.gr>
To:     &n= bsp;  pkix@ietf.org,
Date:     =    03/27/2014 11:19 AM
Subject:   &nbs= p;    [pkix] RFC 5280/6818 X.509v3 DNS Name Constraints
Sent by:   &nbs= p;    "pkix" <pkix-bounces@ietf.org>




I am not sure if this is the right place for this but here goes: What is the reasoning behind name constraints format for type “DNS name” as specified in RFC 5280? In other words why is it different from the URI scheme, where “= ;.example.com” would satisfy *.example.com, *.*exam= ple.com BUT not example.com? Currently as it stands, a CA has no way to restrict itself from issuing certificates for example.com while allowing itself to issue for host.example.com. A NC for type DNS “example.com= 221; will allow the CA to issue a certificate for example.comwhen the desired behavior would be to only allow “.example.com”(in URI scheme).  This could be undesirable. It seems like while the scheme for URIs and email where updated whereas the DNS scheme was left untouched. Wouldn’t it be better if the DNS scheme followed the other 2?

The relevant section is 4.2.1.10 in RFC 5280



--
Sent with mySecureMail.
http://www.mys= ecurephone.eu/[attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--=_alternative 000D15FA85257CAB_=--