[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements
Rob Stradling
rob.stradling at comodo.com
Thu Aug 1 19:47:14 UTC 2013
On 31/07/13 19:40, Ryan Sleevi wrote:
<snip>
> 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.
I have to agree with Ryan. If re-keyed certificates are not regarded as
"issued", then surely they have to be regarded as "not issued". And in
that case, we wouldn't be permitted to respond "good" to OCSP requests
for these certs (as per BRs 13.2.6)!
> 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
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
More information about the Public
mailing list