[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements
Ryan Sleevi
sleevi at google.com
Wed Jul 31 11:40:03 MST 2013
Wayne,
I appreciate your reply in explaining this further.
Please understand our intent is not to single GoDaddy out, but our
concern remains that this highlights a potentially dangerous
disagreement upon what "issuance" means. Our concern stems from the
fact that, in our view, issuance is the practice of signing a
certificate. The time of issuance is when that certificate was signed
by the Issuing CA - that is, specifically *not* the notBefore/notAfter
validity periods, but the actual act of signing. Thus, signing a new
version of the certificate - whether through the changing of a public
key, the serial number, subject information, or any other aspect of
the certificate - logically constitutes a certificate being issued,
and thus is in-scope of the appropriate program requirements, audit
policies, and baseline requirements in force at the time of issuance.
While we agree that this specific certificate is hardly one for
immediate alarm, given the precdent you point out, it is the
interpretation of issuance that is concerning and worthy of further
discussion. Jeremy has accurately raised captured some of the dangers
that the differing interpretation may bring.
As a further practical matter, such certificate re-issuance is, from a
relying party, indistinguishable from original issuance. For example,
the Certificate Policies OID embedded in this particular certificate
is the same one that is reflected in the Starfield CP/CPS document
stored at http://certificates.godaddy.com/repository/ - that is,
Version 3.0, dated January 28, 2013. As such, it's impossible to
discern from examination of this certificate, under which CP/CPS it
was issued, the level of assurance in the certificate, and whether or
not an audit has confirmed the veracity of the CP/CPS and practices.
I'm sure you can understand why this would naturally be concerning.
Our view of issuance being the act of signing a certificate is, in
many ways, trying to avoid the possibility of any CAs acting in bad
faith, whether intentionally or through coercion. An example would be
arguing that otherwise dangerous or malicious certificates were issued
in compliance with a prior CPS, particularly one that may have been
unaudited or problematic at the time of 'original' issuance.
Practically speaking, what are the dangers or operational hurdles from
ensuring that the BRs make it clear that 'issuance' follows its
logical/common sense interpretation, which is the act of signing a
TBSCertificate and producing a signature/certificate.
On Wed, Jul 31, 2013 at 9:47 AM, Wayne Thayer <wthayer at godaddy.com> wrote:
> 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
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
More information about the Public
mailing list