[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Wayne Thayer wthayer at godaddy.com
Wed Jul 31 16:47:19 UTC 2013


The certificates that Ryan has questioned are just another example of legacy (pre-BR) policies that are being allowed to naturally expire over time.  In this case, the situation is as follows:

- Go Daddy (unfortunately) followed the industry in issuing very long lived certificates (in some cases up to 10 years) prior to the adoption of the BRs.
- Go Daddy also follows a common practice of allowing subscribers to "rekey" a certificate whenever they like as long as the certificate is valid.  This happens more than you might expect, for a variety of reasons.
- We define "rekey" as providing the subscriber with a replacement certificate that has not been revetted, expires at the exact same time, and contains a new public key.
- With random serial numbers, it's quite difficult for the average subscriber to tell the difference between an original and a rekeyed certificate because, by our definition, no subject information has changed.  To aid in that, we change the 'valid from' date for the rekeyed certificate to the current date.  That's why the certificate referenced below looks just like a new one.  Of course, we could change this if it's perceived to be an issue with a "rekeyed" certificate.

This issue naturally goes away as these legacy certificates expire, and it is not a violation of our policies, nor do I believe is it a violation of the BRs.  More importantly, It does not perpetuate any bad practices as some have suggested.

Thanks,

Wayne

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+wthayer=godaddy.com at lists.mozilla.org] On Behalf Of Jeremy Rowley
Sent: Wednesday, July 31, 2013 4:10 AM
To: 'Gervase Markham'; mozilla-dev-security-policy at lists.mozilla.org
Subject: RE: Concerns regarding Mozilla Root Program/Baseline Requirements

I've seen "rekey" used with at least the following meanings by various
people:

1) A certificate that contains the same identity information as a previous certificate but with a brand new private/public key pair and possibly a different expiration date (I believe this is the correct definition)
2) A certificate with a new key pair that contains the expiration date of an existing certificate but uses modified identity information from an existing certificate
3) A certificate with the same key pair that contains the expiration date of an existing certificate but uses modified identity information from an existing certificate
4) A certificate that is really a duplicate of an existing certificate but with a new expiration date.

Because of all the possible meanings, only GoDaddy can clarify what it means by "rekey".  However, I don't think that definition is really relevant to since rekeying should not take a certificate outside the scope of the baseline requirements.  

The BRs state that "Certificates issued after the Effective Date MUST have a
Validity Period no greater than 60 months".   Although issuance is not
clearly defined, a rational reading of the BRs implies that any rekey, renewal, or similar action that causes the CA to create a certificate is considered an issuance and thus subject to the BRs.  To determine otherwise would circumvent the entire protective purpose of the BRs as a CA could issue a cert initially complaint with the BRs and then modify the cert as it sees fit, including modifying the cert to include an unverified domain name.


Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com at lists.mozilla
.org] On Behalf Of Gervase Markham
Sent: Wednesday, July 31, 2013 3:57 AM
To: mozilla-dev-security-policy at lists.mozilla.org
Subject: Re: Concerns regarding Mozilla Root Program/Baseline Requirements

Hi Ryan,

Thanks for bringing this to our attention.

On 30/07/13 22:15, Ryan Sleevi wrote:
> The specific certificates are issued by GoDaddy/Starfield Technologies.
> The specific issue at hand is the certificate validity dates. Contrary 
> to the BRs, and to the stated CPS (Section 7.1.4 "End Entity SSL 
> Certificates", and Section 6.3.2, "Usage periods for the Public and 
> Private Keys"), the certificates issued have validity lifetimes 
> exceeding
> 60 months. An example of such a certificate has been attached, which 
> demonstrates a 74-month validity period.

Unfortunately, attachments do not work in our discussion forums :-| For discussion purposes, I've attached a dump below. The cert can also be obtained from https://www.satveda.com/ .

> When contacted regarding this issue, GoDaddy has indicated that such 
> certificates were originally purchased while a previous CPS was in 
> place, and that through both policy and contractual obligations, they 
> allow customers to rekey certificates at any time during the original 
> purchase validity.

Forgive the simple question, but what exactly does it mean technically to "rekey" a certificate? I've seen this word used in a few contexts, and am wondering if it has a precise definition. Is the resulting rekeyed cert indistinguishable from a "new" cert containing the same information? IOW, does "rekey" mean "issue a new cert with the info we already have on file", or is it more complex than that?

To ask the question a different way: is there anything which technically prevents the CA changing the validity period during a "rekeying"?

When they say "the original purchase validity", are they saying that originally this cert was purchased before the BRs came into force, for a period of much more than 74 months, and now some time later, there were
74 months left and a rekeying was requested?

> Our concern is that such an interpretation enables dangerous or 
> discouraged practices. Further, our view is that any and all 
> certificates signed after a given date of compliance with the Baseline 
> Requirements, a Root Program, or an Audit Requirement should be 
> compliant with the appropriate policies in effect at the time of signing.

That seems a fairly sane position to me.

Gerv

gerv at mink:/usr/src/b2g$ openssl x509 -text -in ~/Download/satveda.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            4b:08:8c:0e:d6:c8:ae
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=07969287
        Validity
            Not Before: Mar  9 07:19:24 2013 GMT
            Not After : May 24 09:39:06 2019 GMT
        Subject: OU=Domain Control Validated, CN=www.satveda.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:bb:e0:ea:82:8e:50:bf:ba:94:89:e3:f4:dc:b4:
                    a1:06:91:c1:46:bc:33:37:74:e0:c6:71:e7:f0:09:
                    ec:d8:8e:ac:48:82:3f:b6:b4:49:80:98:04:04:61:
                    f7:ea:d2:ad:23:ed:2b:28:54:f2:14:e2:f4:84:88:
                    9c:4f:d1:b1:1b:52:98:a6:3e:85:e3:eb:22:df:09:
                    86:ff:14:9c:41:46:dd:13:ed:d9:f0:5d:a5:fe:7f:
                    6f:31:6b:a0:50:a5:f2:9a:ba:ea:8c:77:4d:1c:64:
                    82:7a:ea:f4:54:5b:f3:92:81:5e:5c:b1:04:da:c1:
                    d6:72:7d:e1:e5:ec:ad:53:ae:3d:14:21:44:2e:67:
                    f3:a2:c9:7d:9e:0b:98:4d:89:fc:c8:1e:a6:00:45:
                    8b:b6:a7:b9:dc:5e:5a:ff:0c:52:c6:92:7e:60:08:
                    d4:8d:34:6c:00:98:bc:43:e9:7b:e1:92:0b:f5:81:
                    f0:48:09:18:5a:35:8a:e2:74:f2:9d:da:48:b0:7d:
                    02:f8:a4:2b:5e:a0:22:cf:a0:15:9f:fb:ca:4d:8c:
                    f3:26:cb:62:74:a3:04:6e:e2:38:aa:0a:19:42:e8:
                    e3:57:a5:d3:97:64:38:31:89:3e:af:93:af:d6:e3:
                    60:c1:c3:6a:9c:58:da:16:60:c7:78:01:cf:dc:7c:
                    e1:11
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.godaddy.com/gds1-87.crl

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114413.1.7.23.1
                  CPS: http://certificates.godaddy.com/repository/

            Authority Information Access:
                OCSP - URI:http://ocsp.godaddy.com/
                CA Issuers -
URI:http://certificates.godaddy.com/repository/gd_intermediate.crt

            X509v3 Authority Key Identifier:

keyid:FD:AC:61:32:93:6C:45:D6:E2:EE:85:5F:9A:BA:E7:76:99:68:CC:E7

            X509v3 Subject Alternative Name:
                DNS:www.satveda.com, DNS:satveda.com
            X509v3 Subject Key Identifier:
                A7:39:2E:DC:0F:22:D5:D6:C6:B1:3B:35:65:3D:0D:B1:75:5B:F7:69
    Signature Algorithm: sha1WithRSAEncryption
         15:a9:fd:28:f6:cd:d1:f0:2d:d7:1c:df:b5:48:5c:c5:2c:44:
         59:ad:ba:3d:bc:08:30:6f:50:a4:9f:0b:05:28:d7:5e:62:87:
         f9:5d:24:c0:b1:ce:a1:d2:eb:aa:77:9b:01:21:1b:56:dd:e5:
         32:18:38:44:24:60:76:14:4d:4a:6a:d2:37:8b:64:45:5a:ba:
         4f:bf:b0:33:dd:f6:59:dc:fd:47:a9:3b:4f:29:65:3d:a4:0e:
         c7:89:22:48:e7:6b:e4:38:b7:d4:e2:27:1f:22:9c:99:b0:bd:
         b4:59:6d:8d:53:30:fa:28:ef:6c:66:b8:af:6c:9b:93:52:72:
         37:b3:2f:c1:bd:73:22:b4:2e:fa:08:fd:0c:95:89:21:eb:01:
         34:82:18:15:12:3c:a1:2c:d9:fc:f3:f9:48:1f:09:44:18:b8:
         7a:5b:57:ea:10:62:59:90:8c:dc:6f:52:f2:2a:a2:da:fc:2d:
         b4:8a:fb:11:cd:60:da:f9:dd:31:08:31:04:11:81:4e:4b:8a:
         81:40:70:5e:00:99:87:cb:d6:e0:d8:85:fe:4a:2e:97:99:a0:
         3d:6e:6f:26:a9:4d:e6:97:cb:c5:09:ef:49:24:c7:96:27:7e:
         bf:e4:cb:02:f8:00:63:43:7f:ca:05:75:d2:89:7a:f0:25:52:
         ac:47:fb:e6
-----BEGIN CERTIFICATE-----
MIIFRTCCBC2gAwIBAgIHSwiMDtbIrjANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm
aWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkxMDAuBgNVBAMTJ0dvIERhZGR5
IFNlY3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTERMA8GA1UEBRMIMDc5Njky
ODcwHhcNMTMwMzA5MDcxOTI0WhcNMTkwNTI0MDkzOTA2WjA9MSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxGDAWBgNVBAMTD3d3dy5zYXR2ZWRhLmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALvg6oKOUL+6lInj9Ny0
oQaRwUa8Mzd04MZx5/AJ7NiOrEiCP7a0SYCYBARh9+rSrSPtKyhU8hTi9ISInE/R
sRtSmKY+hePrIt8Jhv8UnEFG3RPt2fBdpf5/bzFroFCl8pq66ox3TRxkgnrq9FRb
85KBXlyxBNrB1nJ94eXsrVOuPRQhRC5n86LJfZ4LmE2J/MgepgBFi7anudxeWv8M
UsaSfmAI1I00bACYvEPpe+GSC/WB8EgJGFo1iuJ08p3aSLB9AvikK16gIs+gFZ/7
yk2M8ybLYnSjBG7iOKoKGULo41el05dkODGJPq+Tr9bjYMHDapxY2hZgx3gBz9x8
4RECAwEAAaOCAbowggG2MA8GA1UdEwEB/wQFMAMBAQAwHQYDVR0lBBYwFAYIKwYB
BQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB/wQEAwIFoDAzBgNVHR8ELDAqMCigJqAk
hiJodHRwOi8vY3JsLmdvZGFkZHkuY29tL2dkczEtODcuY3JsMFMGA1UdIARMMEow
SAYLYIZIAYb9bQEHFwEwOTA3BggrBgEFBQcCARYraHR0cDovL2NlcnRpZmljYXRl
cy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5LzCBgAYIKwYBBQUHAQEEdDByMCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5nb2RhZGR5LmNvbS8wSgYIKwYBBQUHMAKGPmh0
dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9nZF9pbnRl
cm1lZGlhdGUuY3J0MB8GA1UdIwQYMBaAFP2sYTKTbEXW4u6FX5q653aZaMznMCcG
A1UdEQQgMB6CD3d3dy5zYXR2ZWRhLmNvbYILc2F0dmVkYS5jb20wHQYDVR0OBBYE
FKc5LtwPItXWxrE7NWU9DbF1W/dpMA0GCSqGSIb3DQEBBQUAA4IBAQAVqf0o9s3R
8C3XHN+1SFzFLERZrbo9vAgwb1CknwsFKNdeYof5XSTAsc6h0uuqd5sBIRtW3eUy
GDhEJGB2FE1KatI3i2RFWrpPv7Az3fZZ3P1HqTtPKWU9pA7HiSJI52vkOLfU4icf
IpyZsL20WW2NUzD6KO9sZrivbJuTUnI3sy/BvXMitC76CP0MlYkh6wE0ghgVEjyh
LNn88/lIHwlEGLh6W1fqEGJZkIzcb1LyKqLa/C20ivsRzWDa+d0xCDEEEYFOS4qB
QHBeAJmHy9bg2IX+Si6XmaA9bm8mqU3ml8vFCe9JJMeWJ36/5MsC+ABjQ3/KBXXS
iXrwJVKsR/vm
-----END CERTIFICATE-----

_______________________________________________
dev-security-policy mailing list
dev-security-policy at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-security-policy at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



More information about the Public mailing list