Subject: [pkix] PKIX failure in the real world, compounded by a not-standard

From: [email-masked]
Date: Mon, 11 Oct 2010 21:58:42 -0700 (Pacific Daylight Time)

Ah, San Jose Public Library, you actually have something of a clue about technology and are constantly expanding your already-sizeable knowledge resource-dissemination repertoire.  You have the honor and distinction of having the resources of San Jose State University merged into your system -- or should I say they have the honor and distinction of having your assets commingled with theirs -- in the same lending management system.  You are a shining exemplar for how technology can facilitate asset tracking and management, as well as the enforcement of SJSU's (quite reasonable) lending policies that reserve certain resources for SJSU faculty, staff, and students to check out, with in-library consultation for the public when they're not.

PKI has failed this organization, and the users it serves.  This is not the fault of SJPL, SJSU, or any of the users involved.

O'Reilly and Associates (known as the "animal book" publisher, the most commonly-recommended place to find authoritative information on the technologies involved with the Internet) has a service, called Safari Books Online, where they allow organizations to select subsets of their catalog for online access.  For ease of integrating with their client organizations (such as, in this case, the San Jose Public Library) asset management system, they append the client domain name to their own internal domain name, and parse out the information as necessary from the host field.

This immediately causes problems with host name mismatches between the conglomerated domain name.  (This points out a flaw in the way that the information is encoded into the certificate by the chosen Certifying Authority, Verisign Trust Network -- it includes only CN=catalog.sjlibrary.org, and contains no subjectAlternativeName.  However, that's not how PKI fails this organization and its users...)

One of the host names involved is 0-ssl.safaribooksonline.com.catalog.sjlibrary.org.  This is a user-browser-visible DNS name.  It's protected with a certificate on port 443, for https.  However, there's two problems here.  First, the certificate is only for catalog.sjlibrary.org (and has no subjectAlternativeName extensions).  Second, and much more stealthy and silent, there is a severe mismatch between the semantics of DNS administration and the certificate name validation rules...

catalog.sjlibrary.org.  IN  SOA (...)
@  IN A server.farm.ip.here
*   IN A server.farm.ip.here

Can anyone see why this works for SJPL and SJSU, and where the mismatch in semantics is?

The DNS guy (who's likely going to be more senior, and most likely not even involved with the web server team) is going to say "I pointed every name .catalog.sjlibrary.org to you, it's your problem what to do with them."

The web team, which is probably aware of the problem, can't solve it because the commercial CAs won't certify the application name.

And the only reason why this implementation can't be helped is because of 3.1 of the RFC for "HTTP over TLS/SSL", RFC 2818.  It specifies:

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

And PKIX, RFC5280, explicitly disclaims responsibility for any kind of wildcard matching.

So, even a wild-card certificate for *.catalog.sjlibrary.org will not solve the problem.  Only a *.*.*.catalog.sjlibrary.org (or *.safaribooksonline.com.catalog.sjlibrary.org) wildcard certificate would.

And there are no issuers of three-level deep wildcards in public service today. 

-Kyle H

https://0-ssl.safaribooksonline.com.catalog.sjlibrary.org/

Certification path for "catalog.sjlibrary.org"
Certificate:
    Version:
        Version 3
    Serial Number:
        37:87:F8:87:7B:47:68:2B:B3:20:D0:4A:12:09:D7:F0
    Certificate Signature Algorithm:
        PKCS #1 SHA-1 With RSA Encryption
    Issuer:
        OU = www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
        OU = VeriSign International Server CA - Class 3
        OU = "VeriSign, Inc."
        O = VeriSign Trust Network
    Validity:
        Not Before:
            1/21/2010 16:00:00 PM
            (1/22/2010 0:00:00 AM GMT)
        Not After:
            1/21/2013 15:59:59 PM
            (1/21/2013 23:59:59 PM GMT)
    Subject:
        CN = catalog.sjlibrary.org
        OU = Terms of use at www.verisign.com/rpa (c)05
        OU = San Jose State University Library and San Jose Public Library
        O = City of San Jose
        L = San Jose
        ST = California
        C = us
    Subject Public Key Info:
        Subject Public Key Algorithm:
            PKCS #1 RSA Encryption
        Subject's Public Key:
            Modulus (1024 bits):
            ce 9e 91 36 a7 4c 0f ad c1 23 6b 37 93 39 89 a9
            ec 9d a6 79 1c db 4e f3 34 da 6d 58 30 a1 0b 6f
            46 1e 77 6f 93 51 6b 2c 09 e4 ac 1d 57 bb 64 7d
            99 b6 96 c7 25 8c f1 b5 68 d8 71 6d 9d 03 60 0e
            b4 8f 74 5d a4 cd 7a c1 32 9e 28 70 8f 2b eb f7
            c4 d5 42 77 22 ae 3c 57 01 c9 94 d8 98 55 fe 0e
            05 a0 72 6d 00 55 51 37 ac 89 ce 2e ca df 36 bb
            88 d7 02 aa f8 f5 6a 5d bf 21 a0 57 5d 20 cf 7b
            Exponent (24 bits):
            65537
    Extensions:
        Certificate Basic Constraints:
            Not Critical
            Is not a Certificate Authority
        Certificate Key Usage:
            Not Critical
            Signing
            Key Encipherment
        Certificate Policies:
            Not Critical
            2.16.840.1.113733.1.7.23.3:
              Certification Practice Statement pointer:
                https://www.verisign.com/rpa
        CRL Distribution Points:
            Not Critical
            URI: http://SVRIntl-crl.verisign.com/SVRIntl.crl
        Extended Key Usage:
            Not Critical
            TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
            TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
            Netscape Server Gated Crypto (2.16.840.1.113730.4.1)
        Authority Information Access:
            Not Critical
            OCSP: URI: http://ocsp.verisign.com
            CA Issuers: URI: http://SVRIntl-aia.verisign.com/SVRIntl-aia.cer
        Logotype:
            Not Critical
            Size: 98 Bytes / 784 Bits
            30 60 a1 5e a0 5c 30 5a 30 58 30 56 16 09 69 6d
            61 67 65 2f 67 69 66 30 21 30 1f 30 07 06 05 2b
            0e 03 02 1a 04 14 4b 6b b9 28 96 06 0c bb d0 52
            38 9b 29 ac 4b 07 8b 21 05 18 30 26 16 24 68 74
            74 70 3a 2f 2f 6c 6f 67 6f 2e 76 65 72 69 73 69
            67 6e 2e 63 6f 6d 2f 76 73 6c 6f 67 6f 31 2e 67
            69 66
Certificate Signature Algorithm:
    PKCS #1 SHA-1 With RSA Encryption
Certificate Signature Value:
    Size: 128 Bytes / 1024 Bits
    a8 1b 88 76 ed 9e 67 a9 48 81 55 0d 13 1b 8c db
    09 0c 62 f6 7d 6e 78 66 82 99 1c 5f 2d 02 9d 77
    c1 f7 4a fa 55 58 ca 51 33 c1 a9 52 cd 89 46 f8
    45 2c 18 41 7a f4 2f eb 37 fb 90 05 ed 7b 51 66
    40 71 fd 27 c2 c9 88 2a 81 82 cb 2d e6 d9 7d ff
    b8 1c dd ce 55 89 98 8e 07 67 c4 4a 18 23 f1 9b
    9f 9b f8 87 0a 63 62 94 ac f5 72 f6 ca be 37 97
    dc 35 34 07 a2 15 47 42 59 9f 60 bc ba 9a 46 97
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Certificate:
    Version:
        Version 3
    Serial Number:
        25:4B:8A:85:38:42:CC:E3:58:F8:C5:DD:AE:22:6E:A4
    Certificate Signature Algorithm:
        PKCS #1 SHA-1 With RSA Encryption
    Issuer:
        OU = Class 3 Public Primary Certification Authority
        O = "VeriSign, Inc."
        C = US
    Validity:
        Not Before:
            4/16/1997 17:00:00 PM
            (4/17/1997 0:00:00 AM GMT)
        Not After:
            10/24/2011 16:59:59 PM
            (10/24/2011 23:59:59 PM GMT)
    Subject:
        OU = www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
        OU = VeriSign International Server CA - Class 3
        OU = "VeriSign, Inc."
        O = VeriSign Trust Network
    Subject Public Key Info:
        Subject Public Key Algorithm:
            PKCS #1 RSA Encryption
        Subject's Public Key:
            Modulus (1024 bits):
            d8 82 80 e8 d6 19 02 7d 1f 85 18 39 25 a2 65 2b
            e1 bf d4 05 d3 bc e6 36 3b aa f0 4c 6c 5b b6 e7
            aa 3c 73 45 55 b2 f1 bd ea 97 42 ed 9a 34 0a 15
            d4 a9 5c f5 40 25 dd d9 07 c1 32 b2 75 6c c4 ca
            bb a3 fe 56 27 71 43 aa 63 f5 30 3e 93 28 e5 fa
            f1 09 3b f3 b7 4d 4e 39 f7 5c 49 5a b8 c1 1d d3
            b2 8a fe 70 30 95 42 cb fe 2b 51 8b 5a 3c 3a f9
            22 4f 90 b2 02 a7 53 9c 4f 34 e7 ab 04 b2 7b 6f
            Exponent (24 bits):
            65537
    Extensions:
        Certificate Basic Constraints:
            Not Critical
            Is a Certificate Authority
            Maximum number of intermediate CAs: 0
        Certificate Policies:
            Not Critical
            Verisign User Notices:
              Certification Practice Statement pointer:
                https://www.verisign.com/CPS
        Extended Key Usage:
            Not Critical
            TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
            TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
            Netscape Server Gated Crypto (2.16.840.1.113730.4.1)
            2.16.840.1.113733.1.8.1
        Certificate Key Usage:
            Not Critical
            Certificate Signer
            CRL Signer
        Netscape Certificate Type:
            Not Critical
            SSL Certificate Authority
            Email Certificate Authority
        CRL Distribution Points:
            Not Critical
            URI: http://crl.verisign.com/pca3.crl
Certificate Signature Algorithm:
    PKCS #1 SHA-1 With RSA Encryption
Certificate Signature Value:
    Size: 128 Bytes / 1024 Bits
    08 01 ec e4 68 94 03 42 f1 73 f1 23 a2 3a de e9
    f1 da c6 54 c4 23 3e 86 ea cf 6a 3a 33 ab ea 9c
    04 14 07 36 06 0b f9 88 6f d5 13 ee 29 2b c3 e4
    72 8d 44 ed d1 ac 20 09 2d e1 f6 e1 19 05 38 b0
    3d 0f 9f 7f f8 9e 02 dc 86 02 86 61 4e 26 5f 5e
    9f 92 1e 0c 24 a4 f5 d0 70 13 cf 26 c3 43 3d 49
    1d 9e 82 2e 52 5f bc 3e c6 66 29 01 8e 4e 92 2c
    bc 46 75 03 82 ac 73 e9 d9 7e 0b 67 ef 54 52 1a
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Certificate:
    Version:
        Version 1
    Serial Number:
        70:BA:E4:1D:10:D9:29:34:B6:38:CA:7B:03:CC:BA:BF
    Certificate Signature Algorithm:
        PKCS #1 MD2 With RSA Encryption
    Issuer:
        OU = Class 3 Public Primary Certification Authority
        O = "VeriSign, Inc."
        C = US
    Validity:
        Not Before:
            1/28/1996 16:00:00 PM
            (1/29/1996 0:00:00 AM GMT)
        Not After:
            8/1/2028 16:59:59 PM
            (8/1/2028 23:59:59 PM GMT)
    Subject:
        OU = Class 3 Public Primary Certification Authority
        O = "VeriSign, Inc."
        C = US
    Subject Public Key Info:
        Subject Public Key Algorithm:
            PKCS #1 RSA Encryption
        Subject's Public Key:
            Modulus (1024 bits):
            c9 5c 59 9e f2 1b 8a 01 14 b4 10 df 04 40 db e3
            57 af 6a 45 40 8f 84 0c 0b d1 33 d9 d9 11 cf ee
            02 58 1f 25 f7 2a a8 44 05 aa ec 03 1f 78 7f 9e
            93 b9 9a 00 aa 23 7d d6 ac 85 a2 63 45 c7 72 27
            cc f4 4c c6 75 71 d2 39 ef 4f 42 f0 75 df 0a 90
            c6 8e 20 6f 98 0f f8 ac 23 5f 70 29 36 a4 c9 86
            e7 b1 9a 20 cb 53 a5 85 e7 3d be 7d 9a fe 24 45
            33 dc 76 15 ed 0f a2 71 64 4c 65 2e 81 68 45 a7
            Exponent (24 bits):
            65537
Certificate Signature Algorithm:
    PKCS #1 MD2 With RSA Encryption
Certificate Signature Value:
    Size: 128 Bytes / 1024 Bits
    bb 4c 12 2b cf 2c 26 00 4f 14 13 dd a6 fb fc 0a
    11 84 8c f3 28 1c 67 92 2f 7c b6 c5 fa df f0 e8
    95 bc 1d 8f 6c 2c a8 51 cc 73 d8 a4 c0 53 f0 4e
    d6 26 c0 76 01 57 81 92 5e 21 f1 d1 b1 ff e7 d0
    21 58 cd 69 17 e3 44 1c 9c 19 44 39 89 5c dc 9c
    00 0f 56 8d 02 99 ed a2 90 45 4c e4 bb 10 a4 3d
    f0 32 03 0e f1 ce f8 e8 c9 51 8c e6 62 9f e6 9f
    c0 7d b7 72 9c c9 36 3a 6b 9f 4e a8 ff 64 0d 64
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Oct 2010 10:25:26 +0200

I'll grant you that this particular weird use case will start working (no more browser working) if the rules are changed to allow *.a.com to match bar.foo.a.com.

But do you think what SJPL and O'Reilly are doing is reasonable?

Let's start with "0-ssl.safaribooksonline.com.catalog.sjlibrary.org". You call this a user-browser-visible DNS name. I am pretty sure no user ever types this in. In any case it quickly redirects to https://catalog.sjlibrary.org:443/validate?url=https%3A%2F%2F0-ssl.safaribooksonline.com.catalog.sjlibrary.org%3A443%2F. Why couldn't the link just have that to begin with? In that case, there would be no problem with warning screens.

Similarly, O'Reilly could have used something like "safaribooksonline.catalog.sjlibrary.org", in which case a "*.catalog.sjlibrary.org" certificate would work just fine.

Finally, SJPL could spend the extra money (now down to $45 when buying several certificates from the same vendor) to actually have a certificate for 0-ssl.safaribooksonline.com.catalog.sjlibrary.org.  Now it's true that if 0-ssl.safaribooksonline.com.catalog.sjlibrary.org and catalog.sjlibrary.org are the same server, it won't work unless you have a web server that supports SNI and the user happens to have a browser that supports SNI, but the future is bright.

So there's three ways to solve this without modifying PKIX. I don't think the San Jose Public Library can be the poster boy for why the HTTPS matching rules should be changed.

Yoav

On Oct 12, 2010, at 6:58 AM, <[email-masked]> wrote:

> MIIE3TCCBEagAwIBAgIQN4f4h3tHaCuzINBKEgnX8DANBgkqhkiG9w0BAQUFADCB
> ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy
> aVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy
> dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg
> SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0x
> MDAxMjIwMDAwMDBaFw0xMzAxMjEyMzU5NTlaMIHtMQswCQYDVQQGEwJ1czETMBEG
> A1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxQIU2FuIEpvc2UxGTAXBgNVBAoUEENp
> dHkgb2YgU2FuIEpvc2UxRjBEBgNVBAsUPVNhbiBKb3NlIFN0YXRlIFVuaXZlcnNp
> dHkgTGlicmFyeSBhbmQgU2FuIEpvc2UgUHVibGljIExpYnJhcnkxMzAxBgNVBAsU
> KlRlcm1zIG9mIHVzZSBhdCB3d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG
> A1UEAxQVY2F0YWxvZy5zamxpYnJhcnkub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GN
> ADCBiQKBgQDOnpE2p0wPrcEjazeTOYmp7J2meRzbTvM02m1YMKELb0Yed2+TUWss
> CeSsHVe7ZH2ZtpbHJYzxtWjYcW2dA2AOtI90XaTNesEynihwjyvr98TVQncirjxX
> AcmU2JhV/g4FoHJtAFVRN6yJzi7K3za7iNcCqvj1al2/IaBXXSDPewIDAQABo4IB
> rTCCAakwCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwRAYDVR0gBD0wOzA5BgtghkgB
> hvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
> cnBhMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9TVlJJbnRsLWNybC52ZXJpc2ln
> bi5jb20vU1ZSSW50bC5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUFBwMC
> BglghkgBhvhCBAEwcQYIKwYBBQUHAQEEZTBjMCQGCCsGAQUFBzABhhhodHRwOi8v
> b2NzcC52ZXJpc2lnbi5jb20wOwYIKwYBBQUHMAKGL2h0dHA6Ly9TVlJJbnRsLWFp
> YS52ZXJpc2lnbi5jb20vU1ZSSW50bC1haWEuY2VyMG4GCCsGAQUFBwEMBGIwYKFe
> oFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4myms
> SweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAN
> BgkqhkiG9w0BAQUFAAOBgQCoG4h27Z5nqUiBVQ0TG4zbCQxi9n1ueGaCmRxfLQKd
> d8H3SvpVWMpRM8GpUs2JRvhFLBhBevQv6zf7kAXte1FmQHH9J8LJiCqBgsst5tl9
> /7gc3c5ViZiOB2fEShgj8Zufm/iHCmNilKz1cvbKvjeX3DU0B6IVR0JZn2C8uppG
> lw==
> MIIDgzCCAuygAwIBAgIQJUuKhThCzONY+MXdriJupDANBgkqhkiG9w0BAQUFADBf
> MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
> LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
> HhcNOTcwNDE3MDAwMDAwWhcNMTExMDI0MjM1OTU5WjCBujEfMB0GA1UEChMWVmVy
> aVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVyaVNpZ24sIEluYy4xMzAx
> BgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2VydmVyIENBIC0gQ2xhc3Mg
> MzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMgSW5jb3JwLmJ5IFJlZi4g
> TElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjCBnzANBgkqhkiG9w0BAQEFAAOB
> jQAwgYkCgYEA2IKA6NYZAn0fhRg5JaJlK+G/1AXTvOY2O6rwTGxbtueqPHNFVbLx
> veqXQu2aNAoV1Klc9UAl3dkHwTKydWzEyruj/lYncUOqY/UwPpMo5frxCTvzt01O
> OfdcSVq4wR3Tsor+cDCVQsv+K1GLWjw6+SJPkLICp1OcTzTnqwSye28CAwEAAaOB
> 4zCB4DAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHAQEw
> KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzA0BgNV
> HSUELTArBggrBgEFBQcDAQYIKwYBBQUHAwIGCWCGSAGG+EIEAQYKYIZIAYb4RQEI
> ATALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMDEGA1UdHwQqMCgwJqAk
> oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMA0GCSqGSIb3DQEB
> BQUAA4GBAAgB7ORolANC8XPxI6I63unx2sZUxCM+hurPajozq+qcBBQHNgYL+Yhv
> 1RPuKSvD5HKNRO3RrCAJLeH24RkFOLA9D59/+J4C3IYChmFOJl9en5IeDCSk9dBw
> E88mw0M9SR2egi5SX7w+xmYpAY5Okiy8RnUDgqxz6dl+C2fvVFIa
> MIICPDCCAaUCEHC65B0Q2Sk0tjjKewPMur8wDQYJKoZIhvcNAQECBQAwXzELMAkG
> A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz
> cyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2
> MDEyOTAwMDAwMFoXDTI4MDgwMTIzNTk1OVowXzELMAkGA1UEBhMCVVMxFzAVBgNV
> BAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAzIFB1YmxpYyBQcmlt
> YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
> ADCBiQKBgQDJXFme8huKARS0EN8EQNvjV69qRUCPhAwL0TPZ2RHP7gJYHyX3KqhE
> BarsAx94f56TuZoAqiN91qyFomNFx3InzPRMxnVx0jnvT0Lwdd8KkMaOIG+YD/is
> I19wKTakyYbnsZogy1Olhec9vn2a/iRFM9x2Fe0PonFkTGUugWhFpwIDAQABMA0G
> CSqGSIb3DQEBAgUAA4GBALtMEivPLCYATxQT3ab7/AoRhIzzKBxnki98tsX63/Do
> lbwdj2wsqFHMc9ikwFPwTtYmwHYBV4GSXiHx0bH/59AhWM1pF+NEHJwZRDmJXNyc
> AA9WjQKZ7aKQRUzkuxCkPfAyAw7xzvjoyVGM5mKf5p/AfbdynMk2OmufTqj/ZA1k
> Scanned by Check Point Total Security Gateway.
> <smime.p7s><ATT00001..txt>

---

From: max pritikin <[email-masked]>
Date: Tue, 12 Oct 2010 09:33:29 -0500

And what do you all mean by "modifying PKIX"? The problem (if we  
accept it is a problem) is in:
(from below)
>> And the only reason why this implementation can't be helped is  
>> because of 3.1 of the RFC for "HTTP over TLS/SSL", RFC 2818.  It  
>> specifies:

By my reading this is two levels removed from the pkix discussions. As  
you say "And PKIX, RFC5280, explicitly disclaims responsibility for  
any kind of wildcard matching".

It sounds like you are arguing the HTTPS RFC mechanisms for Server  
Identity (section 3.1) could be improved. I can think of other cases  
where that could be improved.

- max

On Oct 12, 2010, at 3:25 AM, Yoav Nir wrote:

> I'll grant you that this particular weird use case will start  
> working (no more browser working) if the rules are changed to allow  
> *.a.com to match bar.foo.a.com.
>
> Let's start with "0- 
> ssl.safaribooksonline.com.catalog.sjlibrary.org". You call this a  
> user-browser-visible DNS name. I am pretty sure no user ever types  
> this in. In any case it quickly redirects to https://catalog.sjlibrary.org:443/validate?url=https%3A%2F%2F0-ssl.safaribooksonline.com.catalog.sjlibrary.org%3A443%2F 
> . Why couldn't the link just have that to begin with? In that case,  
> there would be no problem with warning screens.
>
> Similarly, O'Reilly could have used something like  
> "safaribooksonline.catalog.sjlibrary.org", in which case a  
> "*.catalog.sjlibrary.org" certificate would work just fine.
>
> Finally, SJPL could spend the extra money (now down to $45 when  
> buying several certificates from the same vendor) to actually have a  
> certificate for 0-ssl.safaribooksonline.com.catalog.sjlibrary.org.   
> Now it's true that if 0- 
> ssl.safaribooksonline.com.catalog.sjlibrary.org and  
> catalog.sjlibrary.org are the same server, it won't work unless you  
> have a web server that supports SNI and the user happens to have a  
> browser that supports SNI, but the future is bright.
>
> So there's three ways to solve this without modifying PKIX. I don't  
> think the San Jose Public Library can be the poster boy for why the  
> HTTPS matching rules should be changed.
>
> Yoav
>
>
>> Ah, San Jose Public Library, you actually have something of a clue  
>> about technology and are constantly expanding your already-sizeable  
>> knowledge resource-dissemination repertoire.  You have the honor  
>> and distinction of having the resources of San Jose State  
>> University merged into your system -- or should I say they have the  
>> honor and distinction of having your assets commingled with theirs  
>> -- in the same lending management system.  You are a shining  
>> exemplar for how technology can facilitate asset tracking and  
>> management, as well as the enforcement of SJSU's (quite reasonable)  
>> lending policies that reserve certain resources for SJSU faculty,  
>> staff, and students to check out, with in-library consultation for  
>> the public when they're not.
>>
>> PKI has failed this organization, and the users it serves.  This is  
>> not the fault of SJPL, SJSU, or any of the users involved.
>>
>> O'Reilly and Associates (known as the "animal book" publisher, the  
>> most commonly-recommended place to find authoritative information  
>> on the technologies involved with the Internet) has a service,  
>> called Safari Books Online, where they allow organizations to  
>> select subsets of their catalog for online access.  For ease of  
>> integrating with their client organizations (such as, in this case,  
>> the San Jose Public Library) asset management system, they append  
>> the client domain name to their own internal domain name, and parse  
>> out the information as necessary from the host field.
>>
>> This immediately causes problems with host name mismatches between  
>> the conglomerated domain name.  (This points out a flaw in the way  
>> that the information is encoded into the certificate by the chosen  
>> Certifying Authority, Verisign Trust Network -- it includes only  
>> CN=catalog.sjlibrary.org, and contains no subjectAlternativeName.   
>> However, that's not how PKI fails this organization and its users...)
>>
>> One of the host names involved is 0- 
>> ssl.safaribooksonline.com.catalog.sjlibrary.org.  This is a user- 
>> browser-visible DNS name.  It's protected with a certificate on  
>> port 443, for https.  However, there's two problems here.  First,  
>> the certificate is only for catalog.sjlibrary.org (and has no  
>> subjectAlternativeName extensions).  Second, and much more stealthy  
>> and silent, there is a severe mismatch between the semantics of DNS  
>> administration and the certificate name validation rules...
>>
>> The DNS guy (who's likely going to be more senior, and most likely  
>> not even involved with the web server team) is going to say "I  
>> pointed every name .catalog.sjlibrary.org to you, it's your problem  
>> what to do with them."
>>
>> The web team, which is probably aware of the problem, can't solve  
>> it because the commercial CAs won't certify the application name.
>>
>> And the only reason why this implementation can't be helped is  
>> because of 3.1 of the RFC for "HTTP over TLS/SSL", RFC 2818.  It  
>> specifies:
>>
>> So, even a wild-card certificate for *.catalog.sjlibrary.org will  
>> not solve the problem.  Only a *.*.*.catalog.sjlibrary.org (or  
>> *.safaribooksonline.com.catalog.sjlibrary.org) wildcard certificate  
>> would.
>>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Oct 2010 16:58:13 +0200

> any kind of wildcard matching".

That section is about matching certificates to the FQDN, so it's at most one level removed from PKIX.

> where that could be improved.

Kyle is.  I'm arguing against it.

Yoav

---

From: max pritikin <[email-masked]>
Date: Tue, 12 Oct 2010 10:43:33 -0500

Yes, this problem exists in a layer that specifies how certificates  
are matched to the FQDN. Calling this only one layer removed from PKIX  
is fine with me.

More problematic is that I meant 'Kyle' but said 'you'. My apologies  
for the bad quoting style.

I agree that in this case I don't see a significant problem. I look  
forward to Kyle's further thoughts.

- max

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 12 Oct 2010 14:32:02 -0400

Hi Kyle,

I am sorry to disagree with you. This is not a problem where PKIX fails, but
poor PKI management does. You said yourself that a simple use of a different
identifier (*.safaribooksonline.com.catalog.sjlibrary.org) would solve the
problem. I would say, that's an easy fix, isn't it ? Also using subjectAltNames
would provide an RFC compliant solution. Why aren't they fixing it by using
an appropriate certificate ? If they ran their own CA, re-issuing a cert
would take no time and no costs.. :D

I agree with you about the matching rules that tend to be too restrictive
and have implications in highly distributed environments... but that's an
application-specific problem, not really PKIX (i.e., TLS).

Best,
Max

On 10/12/2010 12:58 AM, [email-masked] wrote:
> Ah, San Jose Public Library, you actually have something of a clue about
[...]
> PKI has failed this organization, and the users it serves. This is not
> the fault of SJPL, SJSU, or any of the users involved.
[...]

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov