Re: id-ce-nameConstraints (2.5.29.30) in the real world
Hmmm...why are all of the DNSNames duplicated? The ones with a dot at the beginning don't need to be there, do they? On 02/11/13 15:13, Kaspar Brand wrote: On 02.11.2013 15:40, Erwann Abalea wrote: You missed the exclusion of IPv6 addresses. So this CA can certify for any IPv6 address range. I don't think it will be very dangerous within the next year, considering current IPv6 deployment. s/You/They/. I'm not affiliated with O=Baltimore in any way (nor with O=admin, JFTR). For a live site serving this cert in the handshake, you might want to visit https://www.sonderbewilligungen.admin.ch. Kaspar -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: id-ce-nameConstraints (2.5.29.30) in the real world
On 02/11/13 14:40, Erwann Abalea wrote: Le samedi 2 novembre 2013 08:39:53 UTC+1, Kaspar Brand a écrit : 11 hours ago, a new certificate was given birth to which I would like to share with this list for edification purposes. I think that the audience here should be able to fully appreciate what marvellous real-world example we are now provided with for testing the PKIX-based path validation implementations of the world for RFC 5280 compliance (Applications conforming to this profile MUST be able to process name constraints that are imposed on the directoryName name form and SHOULD be able to process name constraints that are imposed on the rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name forms). Nice. Even cut/pasting it to parse it is a bargain. Wouldn't it have been easier to have several CA certificates with smaller constraints? With such a large permitted subtree, can it really be considered constrained? Technically, it is, yes. You missed the exclusion of IPv6 addresses. So this CA can certify for any IPv6 address range. I don't think it will be very dangerous within the next year, considering current IPv6 deployment. Nonetheless, that IPv6 omission means that this CA certificate is unfortunately _not_ considered technically constrained according to the Mozilla CA Certificate Inclusion Policy. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: id-ce-nameConstraints (2.5.29.30) in the real world
Kaspar, since you're looking for examples of Name Constraints in the real world, this site's certificate chain has a slightly less crazy example... ;-) https://premier.intel.com On 02/11/13 07:39, Kaspar Brand wrote: 11 hours ago, a new certificate was given birth to which I would like to share with this list for edification purposes. I think that the audience here should be able to fully appreciate what marvellous real-world example we are now provided with for testing the PKIX-based path validation implementations of the world for RFC 5280 compliance (Applications conforming to this profile MUST be able to process name constraints that are imposed on the directoryName name form and SHOULD be able to process name constraints that are imposed on the rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name forms). Time is short, however: the certificate will expire on 1st November 2014, already. Happy testing, and let's not go astray into any policy discussions, please. Kaspar -BEGIN CERTIFICATE- MIIVKjCCFBKgAwIBAgIEByeWvjANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTEzMTEwMTIwMzk1M1oX DTE0MTEwMTIwMzgxMVowbTELMAkGA1UEBhMCQ0gxDjAMBgNVBAoTBWFkbWluMREw DwYDVQQLEwhTZXJ2aWNlczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3Jp dGllczEXMBUGA1UEAxMOQWRtaW5DQS1DRC1UMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDSNCUxmaksOFX4Y1H1MChI2V4mBAHjEBckQtB/n/JIx+gU DgyaMqphdCQHowY+5ArBH1dFFI9/rW+pvxg+x2NGaClvIcFxR3m3Q3xFfrBFlSc8 xb5sIKjZWoBThcVueVzaAcppqbTB1O1sFNcSS/SJ4gd/EJ8XFepKxKvrQiQX/b/F usCBX9APnIeToh7x94BVbCLlS1oWq27guIUSHZAzLGw7LPU5y8rOQzaDzve3KITu PMyBk/5bDe2JuTYX357pl6IHftMs6ZW2+CmavCzh+IisU1cRhJYFWtRNufzVTjvJ bM6B/l8Qc/TttFXlA4LMKb32o2KaxsvoIbudPvwJAgMBAAGjghHjMIIR3zASBgNV HRMBAf8ECDAGAQH/AgEBMF8GA1UdIARYMFYwSAYJKwYBBAGxPgEAMDswOQYIKwYB BQUHAgEWLWh0dHA6Ly9jeWJlcnRydXN0Lm9tbmlyb290LmNvbS9yZXBvc2l0b3J5 LmNmbTAKBghghXQBEQMVATCCELMGA1UdHgSCEKowghCmoIIQlDAWghRuYXRpb25h bC1yZWdpc3RyeS5jaDAQgg52ZXZhLW9ubGluZS5jaDAVghNoZWx2ZXRpY2FyY2hp dmVzLmNoMA+CDWljaHNjaHdlaXouY2gwC4IJZW52aXJhLmNoMAqCCGFkbWluLmNo MAqCCGFnYXRlLmNoMA2CC2FydDc0aXZnLmNoMBGCD21vYmlsZXNwb3J0Mi5jaDAT ghFhY3Jvc3N0aGVhbHBzLm9yZzAMggpuYWJvZGF0LmNoMA2CC2NhZGFzdHJlLmNo MBCCDm1vYmlsZXNwb3J0LmNoMA6CDHN3aXNzdG9wby5jaDAKgghmaW5tYS5jaDAM ggpldGF0LWdlLmNoMA2CC2ZhYmFzb2Z0LmNoMA6CDGFncm9zY29wZS5jaDAVghNn ZWxhbi1pbmZvcm1hdGlrLmNoMAyCCm15Z2VsYW4uY2gwD4INZXNwYWNlLWV2ZC5j aDAPgg1lc3BhY2Utd2JmLmNoMBSCEnJlZ2lzdHJlLW1vbmFjby5tYzARgg9leHRy YW5ldC1ldmQuY2gwCYIHaXZiZS5jaDAHggVhZy5jaDAHggVnci5jaDALgglzY2h3 eXouY2gwB4IFc3ouY2gwB4IFemguY2gwC4IJc3BoYWlyLmNoMAuCCWVvZmNvbS5j aDAMggplLW9mY29tLmNoMAyCCmVjZW5zdXMuY2gwEYIPaG91c2luZy1zdGF0LmNo MAyCCnB1YmxpY2EuY2gwB4IFdGkuY2gwB4IFY2guY2gwCIIGc2lrLmNoMBOCEXN3 aXNzLWFyY2hpdmVzLmNoMBCCDnNwaXRhbGRhdm9zLmNoMAyCCmpvYmFyZWEuY2gw EIIOdGF4bWVvbmxpbmUuY2gwCoIIbWV0YXMuY2gwD4INc3dpc3NtZWRpYy5jaDAM ggp6ZW50cmFzLmNoMAeCBWJlLmNoMBeCFS5uYXRpb25hbC1yZWdpc3RyeS5jaDAR gg8udmV2YS1vbmxpbmUuY2gwFoIULmhlbHZldGljYXJjaGl2ZXMuY2gwEIIOLmlj aHNjaHdlaXouY2gwDIIKLmVudmlyYS5jaDALggkuYWRtaW4uY2gwC4IJLmFnYXRl LmNoMA6CDC5hcnQ3NGl2Zy5jaDASghAubW9iaWxlc3BvcnQyLmNoMBSCEi5hY3Jv c3N0aGVhbHBzLm9yZzANggsubmFib2RhdC5jaDAOggwuY2FkYXN0cmUuY2gwEYIP Lm1vYmlsZXNwb3J0LmNoMA+CDS5zd2lzc3RvcG8uY2gwC4IJLmZpbm1hLmNoMA2C Cy5ldGF0LWdlLmNoMA6CDC5mYWJhc29mdC5jaDAPgg0uYWdyb3Njb3BlLmNoMBaC FC5nZWxhbi1pbmZvcm1hdGlrLmNoMA2CCy5teWdlbGFuLmNoMBCCDi5lc3BhY2Ut ZXZkLmNoMBCCDi5lc3BhY2Utd2JmLmNoMBWCEy5yZWdpc3RyZS1tb25hY28ubWMw EoIQLmV4dHJhbmV0LWV2ZC5jaDAKggguaXZiZS5jaDAIggYuYWcuY2gwCIIGLmdy LmNoMAyCCi5zY2h3eXouY2gwCIIGLnN6LmNoMAiCBi56aC5jaDAMggouc3BoYWly LmNoMAyCCi5lb2Zjb20uY2gwDYILLmUtb2Zjb20uY2gwDYILLmVjZW5zdXMuY2gw EoIQLmhvdXNpbmctc3RhdC5jaDANggsucHVibGljYS5jaDAIggYudGkuY2gwCIIG LmNoLmNoMAmCBy5zaWsuY2gwFIISLnN3aXNzLWFyY2hpdmVzLmNoMBGCDy5zcGl0 YWxkYXZvcy5jaDANggsuam9iYXJlYS5jaDARgg8udGF4bWVvbmxpbmUuY2gwC4IJ Lm1ldGFzLmNoMBCCDi5zd2lzc21lZGljLmNoMA2CCy56ZW50cmFzLmNoMAiCBi5i ZS5jaDAhpB8wHTELMAkGA1UEBhMCQ0gxDjAMBgNVBAoTBWFkbWluMEWkQzBBMQsw CQYDVQQGEwJDSDENMAsGA1UEBxMEQmVybjEjMCEGA1UECgwaQkFGVSBCdW5kZXNh bXQgZsO8ciBVbXdlbHQwSKRGMEQxCzAJBgNVBAYTAkNIMQ0wCwYDVQQHEwRCZXJu MSYwJAYDVQQKEx1CaWJsaW90aGVxdWUgbmF0aW9uYWxlIHN1aXNzZTBapFgwVjEL MAkGA1UEBhMCQ0gxDTALBgNVBAcTBEJlcm4xODA2BgNVBAoML0J1bmRlc2FtdCBm w7xyIEluZm9ybWF0aWsgdW5kIFRlbGVrb21tdW5pa2F0aW9uMESkQjBAMQswCQYD VQQGEwJDSDENMAsGA1UEBxMEQmVybjEiMCAGA1UECgwZQnVuZGVzYW10IGbDvHIg R2VzdW5kaGVpdDBIpEYwRDELMAkGA1UEBhMCQ0gxDTALBgNVBAcTBEJlcm4xJjAk BgNVBAoMHUJ1bmRlc2FtdCBmw7xyIExhbmR3aXJ0c2NoYWZ0MEykSjBIMQswCQYD VQQGEwJDSDENMAsGA1UEBxMEQmVybjEqMCgGA1UECgwhQnVuZGVzYW10IGbDvHIg U296aWFsdmVyc2ljaGVydW5nMEukSTBHMQswCQYDVQQGEwJDSDETMBEGA1UEBxMK TWFnZ2xpbmdlbjEjMCEGA1UECgwaQnVuZGVzYW10IGbDvHIgU3BvcnQgQkFTUE8w RaRDMEExCzAJBgNVBAYTAkNIMRAwDgYDVQQHEwdJdHRpZ2VuMSAwHgYDVQQKDBdC dW5kZXNhbXQgZsO8ciBTdHJhc3NlbjBDpEEwPzELMAkGA1UEBhMCQ0gxEDAOBgNV BAcTB0l0dGlnZW4xHjAcBgNVBAoMFUJ1bmRlc2FtdCBmw7xyIFVtd2VsdDBUpFIw
Re: id-ce-nameConstraints (2.5.29.30) in the real world
Erwann, true, we did omit the required IPv6 constraint. Given the expiration of the cross-certificate, we were not able to wait for the 5.4 version of our PKI software currently in QA, which enables IPv6 excluded subtrees, to be released. We expect to make longer term arrangements with BIT at a time when we can enforce the IPv6 block. As this is a cross certificate, we had to introduce the entire namespace in a single certificate rather than multiple CAs because the issued end entity certificates with life extending beyond the past weekend all originate from one existing CA. Only the cross certificate was expiring and it needed to cover the existing operational name space. We also wanted to document the entire researched name space at the same time that we took an exception to BR 1.1.6's 9.7/9.2.4, where to support the existing base of certificates properly we were forced to omit the required locality called for in 9.2.4 in one of the directory names. This was to be clear that we understand and intend to properly implement the requirements of 9.2.4, but had a legacy obstacle that caused one directory name to be required that omits locality and state/province. This was the o=admin,c=CH name. Given the BIT's registration of o=admin as associated to an OID in their arc, established by law, we opted to treat o=admin as a Doing Business As value supported by the QGIS of documented exclusive use of this name published on the Swiss OFCOM site. BIT now has the name constraints in place to move o=admin,c=CH directory named certificates into the more specific names we found in WHOIS data and Swiss QGIS. Rob, we opted to include the dotless and the dotted DNSNames to support https://ch.ch as well as https://www.ch.ch. I foresee doing this as regular practice, as it seems short URLs would be a burdensome reason to re-issue a subordinate CA. Granted, it's a lot of think, especially for battery-powered devices. -Steve -- View this message in context: http://mozilla.6506.n7.nabble.com/id-ce-nameConstraints-2-5-29-30-in-the-real-world-tp297147p297380.html Sent from the Mozilla - Cryptography mailing list archive at Nabble.com. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: id-ce-nameConstraints (2.5.29.30) in the real world
On 04.11.2013 11:44, Rob Stradling wrote: Kaspar, since you're looking for examples of Name Constraints in the real world, this site's certificate chain has a slightly less crazy example... ;-) https://premier.intel.com Or https://www.harica.gr. Or https://www.emporium.vt.edu. Or https://www.cpc.gov.ae. Or https://www.rentenservice.com. Etc. I wasn't specifically looking for examples. But the ICA certs at these sites are definitely of better quality than Verizon's latest feat (of course it's nonsense to also include the .-prefixed DNS names). Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: id-ce-nameConstraints (2.5.29.30) in the real world
Le samedi 2 novembre 2013 08:39:53 UTC+1, Kaspar Brand a écrit : 11 hours ago, a new certificate was given birth to which I would like to share with this list for edification purposes. I think that the audience here should be able to fully appreciate what marvellous real-world example we are now provided with for testing the PKIX-based path validation implementations of the world for RFC 5280 compliance (Applications conforming to this profile MUST be able to process name constraints that are imposed on the directoryName name form and SHOULD be able to process name constraints that are imposed on the rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name forms). Nice. Even cut/pasting it to parse it is a bargain. Wouldn't it have been easier to have several CA certificates with smaller constraints? With such a large permitted subtree, can it really be considered constrained? Technically, it is, yes. You missed the exclusion of IPv6 addresses. So this CA can certify for any IPv6 address range. I don't think it will be very dangerous within the next year, considering current IPv6 deployment. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: id-ce-nameConstraints (2.5.29.30) in the real world
On 02.11.2013 15:40, Erwann Abalea wrote: You missed the exclusion of IPv6 addresses. So this CA can certify for any IPv6 address range. I don't think it will be very dangerous within the next year, considering current IPv6 deployment. s/You/They/. I'm not affiliated with O=Baltimore in any way (nor with O=admin, JFTR). For a live site serving this cert in the handshake, you might want to visit https://www.sonderbewilligungen.admin.ch. Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
