DigiCert Code Signing Enablement Request
Kathleen Wilson
DigiCert root certificates that are currently included in NSS.
DigiCert is a US-based commercial CA that provides digital certification
and identity assurance services internationally to a variety of sectors
including business, education, and government.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=515425
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#DigiCert
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=415671
Noteworthy points:
* All three of these root certificates were approved for inclusion
according to the Mozilla CA Policy in bug #364568.
** The three roots are “DigiCert Assured ID Root CA”, “DigiCert Global
Root CA”, and “DigiCert High Assurance EV Root CA”.
** Each root has internally-operated intermediate CAs for each level of
assurance.
* All documents are in English.
** Document Repository: http://www.digicert.com/ssl-cps-repository.htm
** CPS: http://www.digicert.com/DigiCert_CPS.pdf
** CPS for EV: http://www.digicert.com/DigiCert_EV-CPS.pdf
* This request is to enable the Code Signing trust bit for each of these
roots.
** The Websites and Email trust bits are currently enabled for these roots.
** CPS section 1.4.1: Code-signing Certificates have key usage of
digital signature and extended key usage for code signing.
** CPS Section 3.2.2 details the elements used by DigiCert to
authenticate the organization / subscriber identity.
** CPS Section 3.2.3: For Personal Email Certificates, DigiCert only
verifies the applicant's email address control. An email is sent to the
applicant at the email address to be included in the certificate. The
applicant must respond affirmatively and acknowledge the certificate
request at a specified DigiCert URL. The acknowledgement response
establishes that the applicant has control over the email address. The
name, email address and IP address of the individual providing the
response are recorded.
CPS Section 3.2.5: Procedures similar to those above are also used to
validate authority to receive an Enterprise Email Certificate. Authority
and ability to use an email address are confirmed through email and an
acknowledgement made at a secure URL. An email is sent to persons with
administrative control over the domain, e.g. webm...@domain.com,
admini...@domain.com, ad...@domain.com, etc., or as determined by
the WHOIS record. The email requests that the person with administrative
control over the domain visit a specified DigiCert URL where they enter
their name and acknowledge that the person requesting the certificate
has the right and authority to apply for the certificate. This confirms
that the applicant has the right or permission to acquire a certificate
under that domain. Similarly, another email is sent to the applicant at
the email address to be included in the certificate and the applicant
for the Enterprise Email Certificate must respond affirmatively and
acknowledge the certificate request at a specified DigiCert URL, as
described for Personal Email Certificates above in Section 3.2.3.
CPS Section 3.2.5: Authority to use domain name or IP address is
confirmed by a WHOIS check or a practical demonstration of domain
control to ensure that the Organization owns or controls the Domain Name
or IP address.
• The authority of the applicant's agent is confirmed with an authorized
contact listed with the Domain Name Registrar ("Registrar") or through a
person with administrative or technical control over the domain. The
registered domain administrator or technical contact is asked to confirm
the agent’s authorization to receive a Certificate for the URL
requested. Contact information is obtained from WHOIS and reviewed by
DigiCert validation personnel during the application process. After
application submittal, authorization from the domain contact person
and/or others such as persons with administrative control over the
domain (e.g. webm...@domain.com, admini...@domain.com,
ad...@domain.com, etc.) is received through one of the following methods:
• These persons are contacted via a “Domain Control Validation” email
and directed to a secure URL where at least one of them must enter their
name and acknowledge that the person requesting the certificate has the
right and authority to apply for the certificate to allow the
application for a certificate to proceed. The name, email address and IP
address of the organizational representative acknowledging authority are
also recorded;
• An Authorization Letter (e.g. Appendix A) is received from the
Subscriber as explained in Sections 3.2.2, 4.1.1 and other portions of
this CP/CPS;
• A record of one of the foregoing is on file in the account for the
Subscriber at DigiCert from a previous request for that domain (i.e. a
Subscriber may pre-authorize its agent to perform all future renewals of
the certificate); or
• Other comparable methods of establishing authority are performed by
DigiCert validation personnel.
** CPS Section 4.2.1: DigiCert validation personnel review the
application information provided by the Applicant to ensure That the
applicant has the right to use the domain name used in the application
*** Validated by reviewing domain name ownership records available
publicly from the Domain Name Registrar
*** Validation may be supplemented in one of the following ways:
*** By communicating with the Administrative Contact listed in the WHOIS
record
*** By communicating with generic emails which ordinarily are only
available to persons with administrative control over the domain, for
example, webm...@domain.com, admini...@domain.com,
ad...@domain.com, etc.
*** By requiring a practical demonstration of domain control (e.g.,
requiring the Applicant to make a specified change to a live page on the
given domain).
** CPS section 4.2.1: DigiCert validation personnel review the
application information provided by the Applicant to ensure that the
applicant is an accountable legal entity
*** Documentation of organizational existence is obtained from available
records, including those maintained by official government repositories
and commercial providers of such information.
*** If necessary, information may be validated by requesting official
company documentation, such as Business License, filed or certified
Articles of Incorporation/Organization, Sales License or other relevant
documents. For non-corporate applications, documentation listed in
Section 3.2.3.
** CPS section 4.9.1: DigiCert will revoke a digital certificate if: …
For Code-Signing Certificates, DigiCert receives notice or otherwise
becomes aware or suspects that information in the certificate is
inaccurate or that someone has used the Code-Signing Certificate to
sign, publish or distribute spyware, Trojans, root kits, browser
hijackers, malware, or other content it deems harmful, malicious,
hostile, deceptive or downloaded onto a user’s system without their consent.
* EV Policy OID: 2.16.840.1.114412.2.1
** See “CPS for EV” for details.
* Test Websites
** https://catest.digicert-assured-id-ca-1.digicert.com/
** https://catest.digicert-global-ca-1.digicert.com/
** https://catest.digicert-high-assurance-ev-ca-1.digicert.com/
* CRL: End-entity CRL Next Update is 7 days
* OCSP: http://ocsp.digicert.com/
* Audit: KPMG performed the audits against the WebTrust CA and WebTrust
EV criteria, and the audit statements are posted on the webtrust.org
website: https://cert.webtrust.org/ViewSeal?id=845,
https://cert.webtrust.org/ViewSeal?id=962.
This begins a one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved. If there are
outstanding issues or action items, then an additional discussion may be
needed as follow-up.
Kathleen
Jean-Marc Desperrier
> An email is sent to persons with administrative control over the domain,
> e.g. webm...@domain.com, admini...@domain.com, ad...@domain.com, etc.
IIRC we have an established list of acceptable emails for this, the CPS
should only use emails from that list, and *not* include "etc."
From the CPS :
> 1.1 Overview
Reference to code signing certificates is missing.
> 4.9.1 Circumstances for revocation
> DigiCert will revoke a digital certificate if:
> For Code-Signing Certificates, [...] content [...] downloaded onto a
> user�s system without their consent.
A very good point.
It's frequently hard to establish in a perfectly unequivocal way if a
software is really malware, but the fact that it tries to install itself
without user approval is a material fact that's usually much easier to
establish without any ambiguity.
If it isn't, I think this should be in every code signing CPS.
> 9.6.3 [...]
> the Subscriber represents, warrants and covenants to DigiCert, [...]
>it will not use the Certificate to digitally sign hostile code,
> spyware or other malicious software; to disable antispyware or other protective measures;
> to provide false or misleading descriptions of the signed code�s functions or features, or to
> use the Code-Signing Certificate in violation of applicable laws or the Subscriber
> Agreement.
But I think the above text about no-consent install should appear again
at this place?
> Appendix B
> Certificate Profiles
> 3. DigiCert End Entity Certificates
I don't see the code signing certificate profile there?
> * Audit: KPMG performed the audits against the WebTrust CA and WebTrust EV criteria,
Do the WebTrust CA criteria have specific requirements for code signing?
> For Email
> Certificates, the subject DN consists of an email address, common name (not verified � for Subscriber
> convenience only),
I know that's not what's under review here, but in my personal opinion,
unverified common name in mail certs are an unacceptable, demonstrated
security risk.
> d. DigiCert High Assurance CA-3 Email Certificate
Is this CA only for Enterprise Email Certificate ? We're missing the
profile of the personal mail certs with unverified CN then.
They're not called High Assurance Email Certificate, right?
> 3.2.2 Authentication of organization identity
> 3.2.3 Authentication of individual identity
I see no description of which kind of authentication is required for
each type of certificates, and in my opinion this is not good at all.
> At DigiCert�s discretion, DigiCert may require one or more of the following documents
As far as I'm concerned, it's just as if this text wasn't there in the
CPS. The CA doesn't *have* to do those checks, so I'll consider it never
does them.
> 3.2.3 Authentication of individual identity
Not a single document is *required* (they're all "at discretion") for
individual identity authentication.
What kind of certs are delivered to individuals ? I hope only the
personal email certificates.
> 3.2.2 Authentication of organization identity
So they are just two statement where Digicerts requires documents that
will enable it to verify the request :
> Proof of right to use name
- what is that specifically ?
> Proof of existence and professional status of the Individual
- what is that specifically ?
What we verify here is an individual but we're supposed to be
authenticating an organization ? How ? The DUNS number is optional.
We're not verifying there's a link between that individual and the
organization. Don't say it's obvious, it's not written, and only what's
written counts.
In this CPS, I see a lot of things that Digicert *may* do, but a
striking dearth of elements that Digicert *commits* itself to verify and
no specifics on how it will pursue those verifications.
At the end of this, I was a bit curious to check how the initial
evaluation of Digicert CPS went.
I've seen in bug https://bugzilla.mozilla.org/show_bug.cgi?id=364568
that Gervase verified that the CPS says domain control validation is
done, and that's enough to get the SSL flag.
Good, but for code signing there's no way to go forward without a
document that *proves* a real authentication is done :-)
Ben Wilson
Thanks for your comments. We will review them and respond accordingly
sometime next week. Thanks again.
Sincerely yours,
Ben Wilson
DigiCert, Inc.
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Jean-Marc Desperrier
Sent: Friday, July 02, 2010 11:49 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert Code Signing Enablement Request
Kathleen Wilson wrote:
> An email is sent to persons with administrative control over the domain,
> e.g. webm...@domain.com, admini...@domain.com, ad...@domain.com,
etc.
IIRC we have an established list of acceptable emails for this, the CPS
should only use emails from that list, and *not* include "etc."
From the CPS :
> 1.1 Overview
Reference to code signing certificates is missing.
> 4.9.1 Circumstances for revocation
> DigiCert will revoke a digital certificate if:
> For Code-Signing Certificates, [...] content [...] downloaded onto a
> user's system without their consent.
A very good point.
It's frequently hard to establish in a perfectly unequivocal way if a
software is really malware, but the fact that it tries to install itself
without user approval is a material fact that's usually much easier to
establish without any ambiguity.
If it isn't, I think this should be in every code signing CPS.
> 9.6.3 [...]
> the Subscriber represents, warrants and covenants to DigiCert, [...]
>it will not use the Certificate to digitally sign hostile code,
> spyware or other malicious software; to disable antispyware or other
protective measures;
> to provide false or misleading descriptions of the signed code's functions
or features, or to
> use the Code-Signing Certificate in violation of applicable laws or the
Subscriber
> Agreement.
But I think the above text about no-consent install should appear again
at this place?
> Appendix B
> Certificate Profiles
> 3. DigiCert End Entity Certificates
I don't see the code signing certificate profile there?
> * Audit: KPMG performed the audits against the WebTrust CA and WebTrust EV
criteria,
Do the WebTrust CA criteria have specific requirements for code signing?
> For Email
> Certificates, the subject DN consists of an email address, common name
(not verified - for Subscriber
> convenience only),
I know that's not what's under review here, but in my personal opinion,
unverified common name in mail certs are an unacceptable, demonstrated
security risk.
> d. DigiCert High Assurance CA-3 Email Certificate
Is this CA only for Enterprise Email Certificate ? We're missing the
profile of the personal mail certs with unverified CN then.
They're not called High Assurance Email Certificate, right?
> 3.2.2 Authentication of organization identity
> 3.2.3 Authentication of individual identity
I see no description of which kind of authentication is required for
each type of certificates, and in my opinion this is not good at all.
> At DigiCert's discretion, DigiCert may require one or more of the
following documents
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Eddy Nigg
> DigiCert has applied to enable the Code Signing trust bit for three
> DigiCert root certificates that are currently included in NSS.
>
> validate authority to receive an Enterprise Email Certificate.
> Authority and ability to use an email address are confirmed through
> email and an acknowledgement made at a secure URL. An email is sent to
> persons with administrative control over the domain, e.g.
> webm...@domain.com, admini...@domain.com, ad...@domain.com,
> etc., or as determined by the WHOIS record.
Even though the scope of this request is apparently limited to enabling
the code signing trust bit, the disclosure of these details obviously
automatically call for compliance of the new requirements of Mozilla
regarding domain control validation. Therefore now would be a good time
for Digicert to modify their CP/CPS and implementations in order to
comply to the new regulations.
> *** By communicating with generic emails which ordinarily are only
> available to persons with administrative control over the domain, for
> example, webm...@domain.com, admini...@domain.com,
> ad...@domain.com, etc.
The three examples from above are in that list, I'm not sure what "etc."
stands for. I believe that the acceptable email addresses considered
administrative for this purpose should be spelled out.
> *** By requiring a practical demonstration of domain control (e.g.,
> requiring the Applicant to make a specified change to a live page on
> the given domain).
I'm not sure how effective this method is, specially considering that
many web applications are subject to various flaws which would allow for
such practical demonstration (on the web pages). Other methods might be
safer, for example modifications of DNS records.
> This begins a one-week discussion period. After that week, I will
> provide a summary of issues noted and action items. If there are no
> outstanding issues, then this request can be approved. If there are
> outstanding issues or action items, then an additional discussion may
> be needed as follow-up.
>
Considering that the request is to enable code signing certificates, I
think something got missing here. I quickly searched through the CPS and
here some question. It appears as if server, client, email and code
signing extensions are all bundled into the same certificate for
DigiCert Assured ID CA-1 ?
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Code Signing (1.3.6.1.5.5.7.3.3)
Secure Email (1.3.6.1.5.5.7.3.4)
Time Stamping (1.3.6.1.5.5.7.3.8)
Including Time Stamping???? Server authentication together with code
signing?
Additionally what I'm missing somehow is the required validations a
subscriber must undergo in order to obtain an object code signing
certificate. I might have missed it or it's a bit unclear.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Eddy Nigg
> available records, including those maintained by official government
> repositories and commercial providers of such information.
> *** If necessary, information may be validated by requesting official
> company documentation, such as Business License, filed or certified
> Articles of Incorporation/Organization, Sales License or other
> relevant documents. For non-corporate applications, documentation
> listed in Section 3.2.3.
Sorry Ben, some more questions for you ;-)
I oversaw this part and checked with the CPS, but apparently there might
be something else missing. Obtaining records about an organization and
confirming its existence is one thing. But how exactly does DigiCert
make sure that the subscriber enrolling is actually authorized and truly
represents the organization? Or in other words, if I'll submit a CSR and
accept the subscriber agreement, can I get a certificate for Coca Cola,
Inc. ?
Based on that, can I get a certificate for coca-cola.com based on 4.2.1
(1): Validated by reviewing domain name ownership records available
publicly from the Domain Name Registrar ??? How is the authorized
subscriber validated in first place? I couldn't find any reference in
this respect.
Jean-Marc Desperrier
>> *** By requiring a practical demonstration of domain control
>> (e.g., requiring the Applicant to make a specified change to a live >> page
>
> I'm not sure how effective this method is, specially considering
> that many web applications are subject to various flaws which would
> allow for such practical demonstration (on the web pages)
What would you think if they required to create a page with a specific
name ?
Now, I'm thinking that whatever way we turn this, if you find a failure
in a web site, you can ask for a certificate in it's name.
> Other methods might be safer, for example modifications of DNS records.
One of the purpose of SSL is to protect against the risk of DNS
compromission.
But there if you compromise the DNS, you can just ask for your own cert
and you've broken DNS + SSL.
I does happen a bit less frequently than compromised HTTP servers.
> Obtaining records about an organization and confirming its existence is
> one thing.
Which is not written in the CPS. There's nowhere where Digicert *must*
obtain those in 3.2.2.
> how exactly does DigiCert make sure that the subscriber enrolling is
> actually authorized and truly represents the organization?
Which, using other words, is what I noticed already.
Now let's get to the point : We had a discussion earlier where I said I
doubted code signing CA were able to provide a high level of security,
and you answered that was not true with the current requirements of
Mozilla policy. I didn't have time at that point to go further, but
where is this level of requirements described exactly ?
And I think Digicerts needs to read it also, because they have to
incorporate them in their CP/CPS.
Eddy Nigg
> What would you think if they required to create a page with a specific
> name ?
Would work with most common flaws I've seen with the most popular
software that is installed on web sites.
> One of the purpose of SSL is to protect against the risk of DNS
> compromission.
> But there if you compromise the DNS, you can just ask for your own
> cert and you've broken DNS + SSL.
You can anyway, for any domain control validation method, including the
preferred mail ping.
>
> I does happen a bit less frequently than compromised HTTP servers.
Can you define "frequently" in this context? :-)
>
>> Obtaining records about an organization and confirming its existence is
>> one thing.
>
> Which is not written in the CPS. There's nowhere where Digicert *must*
> obtain those in 3.2.2.
Mhh..."may" should be probably replaced with "must" or "does", but I'm
not the author.
> Now let's get to the point : We had a discussion earlier where I said
> I doubted code signing CA were able to provide a high level of
> security, and you answered that was not true with the current
> requirements of Mozilla policy. I didn't have time at that point to go
> further, but where is this level of requirements described exactly ?
Mozilla CA policy section 7:
for certificates to be used for digitally signing code objects, the
CA takes reasonable measures to verify that the entity submitting
the certificate signing request is the same entity referenced in the
certificate /or/ has been authorized by the entity referenced in the
certificate to act on that entity's behalf;
It's surely the bare minimum, but that's all of the policy really.
Ben Wilson
during the review process, and we hope that we will have addressed them in
revisions to our CPS that we will circulate shortly. We are replacing the
auxiliary verb "may" with active verbs in several places in our CPS, and, in
addition to other changes we are making, we are clarifying our practices in
response to your comments as follows:
A. In Section 3.2.2 in response to Mozilla's policy of acceptable email
addresses, we are removing "etc." and amending it to state that we
communicate with one or more of the following email addresses:
webm...@domain.com, admini...@domain.com, ad...@domain.com,
hostmaster@domain, postmaster@domain, and any address listed in the
technical, registrant, or administrative contact field of the domain's WHOIS
record.
[Note: While this issue is not tied to enablement of the code-signing bit,
we would like to point out that DigiCert does not issue Domain-only
Validated (DV) SSL certificates (i.e. approval of issuance based merely on
an affirmative response to an automatically generated email). We use the
term "OV" below in our discussion of Sections 3.2.2, 3.2.3 and 3.2.5 to
refer to the fact that as illustrated in these revised sections, DigiCert
performs additional steps to vet the organizational existence and identity
of the applicant for SSL certificates, which many other CAs do not
perform--except for Extended Validation certificates.]
B. Section 1.1 (Overview) will now specifically mention code signing
certificates as follows: "This CPS describes nine Object Identifiers (OIDs)
that represent various uses and levels of trust for certificates: two for
SSL certificates, five for client certificates, one for code signing
certificates, and one for time-stamping." We are also adding the profile
for code signing certificates to a new "Certificate Profiles" document.
C. For Section 9.6.3 (Subscriber Agreement), we are incorporating
Jean-Marc's recommendation that we incorporate language from our Section
4.9.1 (Circumstances for revocation) to the effect that DigiCert will revoke
a Code-Signing Certificate if we discover that content is being downloaded
onto a user's system without their consent.
D. Jean-Marc also asked whether the WebTrust CA audit has specific
requirements for code signing--while it doesn't, the CAB Forum provides
guidance in its EV Guidelines. These supplement requirements set by
browsers. Nevertheless, our CA Web Trust for CAs audit does verify that we
conform to the practices in our CPS, including implementation of our code
signing certificate practices and procedures.
E. In response to the comments about validation of the Common Name in an
Email Certificate, we are modifying the Certificate Profiles to map to
requirements among federated communities, such as, for instance, the NIST
800-63 Assurance Levels. See page 13 of
http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.p
df. At Level 1 (FBCA Rudimentary) "names are not verified, names are
always assumed to be pseudonyms." Many CAs include unverified common names.
DigiCert takes precautions against the risk of including unverified
information by clearly labeling any information as unverified. Unverified
common names are only included in level 1 client certificates with profiles
that indicate the non-verified and/or pseudonymous nature of the common name
(and which are designed to meet Level 1/rudimentary criteria of the relevant
federated community). The profiles for these different levels of client
certificates will be included in our Certificate Profiles document.
F. Sections 3.2.2 and 3.2.3 have been revised extensively in response to
the comment, "I see no description of which kind of authentication is
required for each type of certificates, and in my opinion this is not good
at all." We are currently working on the exact language for each cell in
each table for 3.2.2 and 3.2.3.
Here is the language for the table in Section 3.2.2:
"3.2.2. Authentication of Organization Identity
----------------------------------------------------------------------------
--
OV Certificates DigiCert verifies the organizational existence and identity
of Applicants using reliable third party and government databases. If such
databases are insufficient to confirm the identity of the subject, DigiCert
validates the Applicant by requesting official company documentation, such
as a business license, filed or certified articles of
incorporation/organization, sales license or other relevant documents.
DigiCert also validates the Applicant's right to use the domain name that
will be listed in the certificate. Domain name ownership is validated by:
1. Relying on publicly available records from the Domain Name
Registrar;
2. Communicating with one of the following email addresses:
webm...@domain.com, admini...@domain.com, ad...@domain.com,
hostmaster@domain, postmaster@domain, and any address listed in the
technical, registrant, or administrative contact field of the domain's WHOIS
record; and/or
3. Requiring a practical demonstration of domain control (e.g.,
requiring the Applicant to make a specified change to a live page on the
given domain).
If a third-party made the certificate application on behalf of the company
listed in the WHOIS record, the third party must submit a document that
shows the Applicant's right to use the domain name (such as the Domain
Authorization Letter in Appendix A) that is signed by the Registrant (e.g. a
domain owner's authorized representative) or the Administrative Contact on
the WHOIS record. DigiCert may also require a photocopy of the Domain
Authorization Letter signer's photo ID (see Section 3.2.3).
----------------------------------------------------------------------------
--
EV Certificates EV Certificates are validated in accordance with Section 10
of the EV guidelines. Specifically, DigiCert verifies the Applicant's:
1. legal existence in accordance with Section 10.2,
2. assumed name (if any) in accordance with Section 10.3,
3. address in accordance with Section 10.4,
4. operational existence in accordance with Section 10.5,
5. domain name in accordance with Section 10.6,
6. contractor signer and certificate approved in accordance with
Section 10.7,
7. execution of the Subscriber Agreement and certificate request in
accordance with Section 10.8, and
8. approval of the certificate request in accordance with Section 10.9.
DigiCert may rely on a legal opinion or accountant letter that meets the
requirements of Section 10.10 of the EV Guidelines.
----------------------------------------------------------------------------
--
Code Signing Certificates DigiCert verifies the organizational
existence and identity of Applicants using reliable third party and
government databases. If such databases are insufficient to confirm the
identity of the subject, DigiCert validates the Applicant by requesting
official company documentation, such as a business license, filed or
certified articles of incorporation/organization, sales license or other
relevant documents.
G. For Section 3.2.3 (Authentication of Individual Identity), we are
refining the steps and processes required to authenticate an individual's
identity in order to meet the various assurance levels recognized among the
various federated communities, so we are not prepared to present them here.
(And we believe this is "out of scope.") The proposed language currently
under consideration for code signing certificates issued to individuals
reads:
"DigiCert requires at least one trustworthy government-issued photograph ID
to verify the identity of an individual Applicant. Acceptable IDs include
a:
1. Passport;
2. Driver's license;
3. Military ID;
4. Alien registration card or naturalization certificate; or
5. National health card.
DigiCert may accept other official documentation in its own discretion."
We welcome comments on this draft language.
H. On the issue of "authority" or "authorization" (the Coca Cola example),
the new Section 3.2.5 explains how DigiCert verifies the "organizational
authority" of the certificate requester:
"Verifying that the individual requesting the certificate has the authority
to act on behalf of the organization named in the certificate by:
1. Referring to information about the individual's role within the
organization that is independently obtained by DigiCert either from the
organization itself or from a reliable third party or government source, or
2. Confirming the individual's role within the organization by calling an
independently verified telephone number for the organization or by following
a comparable procedure that is more appropriate for that particular
organization."
I. Regarding concerns about the extended key usages in the profiles of our
Intermediate CA certificates--we do not see an issue. (The EKUs mentioned
are not all in the same end entity certificate profile, if that was the
issue.)
J. Finally, on the recent discussion of weaknesses/alternatives to
practical demonstration of domain control, we really don't feel this is
relevant to code signing (because a domain name is not listed in a code
signing certificate). However, we understand that this should be an
acceptable verification procedure for SSL certificates because it is allowed
under section 10.6.2 of the EV Guidelines, and OV certificates are at a
lower assurance level than EV (and our OV processes mitigate hijacking
threats better than the currently allowed DV processes). So, what is
acceptable for the higher assurance EV certificates should at least be
acceptable for OV certificate issuance processes.
Let us know if we haven't responded to any of the issues raised. Thanks.
Sincerely yours,
Ben
Benjamin T. Wilson, JD CISSP
General Counsel and SVP Industry Relations
DigiCert, Inc.
Because your success is built on trust. (tm)
Online: www.DigiCert.com
Email: b...@digicert.com
Toll Free: 1-800-896-7973 (US & Canada)
Direct: 1-801-701-9678
Fax: 1-866-842-0223 (Toll Free if calling from the US or Canada)
Nelson Bolyard
[...]
>> 4.9.1 Circumstances for revocation
>> DigiCert will revoke a digital certificate if:
>> For Code-Signing Certificates, [...] content [...] downloaded onto a
>
> A very good point.
>
> It's frequently hard to establish in a perfectly unequivocal way if a
> software is really malware, but the fact that it tries to install itself
> without user approval is a material fact that's usually much easier to
> establish without any ambiguity.
>
> If it isn't, I think this should be in every code signing CPS.
I disagree.
The point of signing anything is to establish who is the authorship of the
signed thing. When a CA issued a code signing cert, it is saying "if you
have a signature on a piece of code that is verifiable with this key, then
it was signed by the party named in this certificate". The implication is:
"if you have a problem with a piece of signed code whose signature is
verifiable with this cert, then this cert's subject name tells you who to
hold responsible."
Now, if the CA goes beyond that and tries to tie other meanings into that
cert, meanings that cannot be logically inferred from the cryptographic
properties of that cert, then the CA is setting consumer expectations
falsely. Worse, the CA may be setting itself up for a very bad time.
Consider this scenario:
CA 'D' issues a code signing cert to reputable company 'M' with the
conditions given above. Evil party 'E' controls a web site that begins to
download (and/or install) a piece of company M's signed software onto the
computers whose browsers visit her servers. Consumers begin to complain
loudly and in large numbers about company M's signed software appearing on
their computer without their permission.
First the consumers say that 'D' is an evil company, downloading unwanted
software onto their computers. Then they get a little more educated,
learning that 'D' doesn't sign M's software, but rather M signs its own
software. So, then they demand that D revoke M's certificate, on the
grounds that D's policy says it will do so.
Now, if D revokes M's certificate, M sues D and wins. OTOH, if D does NOT
revoke M's certificate, consumers all bad mouth D until it fails as a company.
IMO, D and M and even the consumers are best off if it is CLEAR to everyone
that a signature on a piece of software, which signature is verifiable by
a certificate from D, serves ONE purpose only, to identify the producer of
that software, and NOT to vouch for the quality of that piece of software
nor of the ethical behavior of any holder of any such certificate.
Eddy Nigg
On 07/08/2010 12:31 PM, From Ben Wilson:
> A. In Section 3.2.2 in response to Mozilla's policy of acceptable email
> addresses, we are removing "etc." and amending it to state that we
> communicate with one or more of the following email addresses:
> webm...@domain.com, admini...@domain.com, ad...@domain.com,
> hostmaster@domain, postmaster@domain, and any address listed in the
> technical, registrant, or administrative contact field of the domain's WHOIS
> record.
Excellent!
> Code Signing Certificates DigiCert verifies the organizational
> existence and identity of Applicants using reliable third party and
> government databases. If such databases are insufficient to confirm the
> identity of the subject, DigiCert validates the Applicant by requesting
> official company documentation, such as a business license, filed or
> certified articles of incorporation/organization, sales license or other
> relevant documents.
>
> G. For Section 3.2.3 (Authentication of Individual Identity), we are
> refining the steps and processes required to authenticate an individual's
> identity in order to meet the various assurance levels recognized among the
> various federated communities, so we are not prepared to present them here.
> (And we believe this is "out of scope.") The proposed language currently
> under consideration for code signing certificates issued to individuals
> reads:
> "DigiCert requires at least one trustworthy government-issued photograph ID
> to verify the identity of an individual Applicant. Acceptable IDs include
> a:
> 1. Passport;
> 2. Driver's license;
> 3. Military ID;
> 4. Alien registration card or naturalization certificate; or
> 5. National health card.
> DigiCert may accept other official documentation in its own discretion."
I believe there is something crucial missing which hasn't been
disclosed. HOW EXACTLY do you verify that I'm not Muhtar Kent? I
provided you with Muhtar Kent's Passport, can I get a certificate in his
name now?
Additionally, if you can't disclose how you are able to verify someones
identity, how can the relying parties know and rely on it? In this case
it's Mozilla which makes a decision on behalf of their users. I believe
it's very much on scope.
> H. On the issue of "authority" or "authorization" (the Coca Cola example),
> the new Section 3.2.5 explains how DigiCert verifies the "organizational
> authority" of the certificate requester:
> "Verifying that the individual requesting the certificate has the authority
> to act on behalf of the organization named in the certificate by:
> 1. Referring to information about the individual's role within the
> organization that is independently obtained by DigiCert either from the
> organization itself or from a reliable third party or government source, or
> 2. Confirming the individual's role within the organization by calling an
> independently verified telephone number for the organization or by following
> a comparable procedure that is more appropriate for that particular
> organization."
I'm certain you'll be able to confirm at Muhtar Kent is duly authorized
for just about anything that Coca Cola concerns. How do you know that
I'm Muhtar Kent ?
Also, what would be an comparable procedure as mentioned above? How
would you deal with an organization that is registered at the agents
address? Or at the accountant for that matter?
And finally, you mentioned further above:
If such databases are insufficient to confirm the
identity of the subject, DigiCert validates the Applicant by requesting
official company documentation, such as a business license, filed or
certified articles of incorporation/organization, sales license or other
relevant documents
But how do you validate it? Meaning, if I present you with all those
documents, I'll get a certificate for "American Mountain View, Inc." ?
Basically you disclose upon which documents you rely, you don't really
disclose how you validate it.
> I. Regarding concerns about the extended key usages in the profiles of our
> Intermediate CA certificates--we do not see an issue. (The EKUs mentioned
> are not all in the same end entity certificate profile, if that was the
> issue.)
Perhaps you want to spell it out or add a description which says exactly
the above?
Ben Wilson
This raises an interesting question about whether a CPS should publicize
"exact" details, which reduce the reconnaissance needed for an attacker to
identify vulnerabilities, or whether private disclosure to trusted
independent reviewers (who also sign NDAs and agree to protect trade
secrets) will improve the identity vetting processes and make them more
secure? If one takes the detailed CPS approach, then security sensitive
portions of the CPS (e.g. any detailed identity vetting processes) could be
marked for redaction before distribution or publication. What do people on
this list think about the various approaches to the amount of detail to be
provided in CPSs and the redaction option? I've noticed that most CPSs are
not that detailed, but I have had situations where the CP/CPS reviewer has
required details that were later redacted by the CA before publication. I'll
take a look at those sections and see what we can do to be more clear and
whether redaction is an option.
Thanks for the input,
Ben
Benjamin T. Wilson, JD CISSP
General Counsel and SVP Industry Relations DigiCert, Inc.
Because your success is built on trust. (tm)
Online: www.DigiCert.com
Email: b...@digicert.com
Toll Free: 1-800-896-7973 (US & Canada)
Direct: 1-801-701-9678
Fax: 1-866-842-0223 (Toll Free if calling from the US or Canada)
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Eddy Nigg
Sent: Saturday, July 10, 2010 1:48 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert Code Signing Enablement Request
Hi Ben,
On 07/08/2010 12:31 PM, From Ben Wilson:
> A. In Section 3.2.2 in response to Mozilla's policy of acceptable email
> addresses, we are removing "etc." and amending it to state that we
> communicate with one or more of the following email addresses:
> webm...@domain.com, admini...@domain.com, ad...@domain.com,
> hostmaster@domain, postmaster@domain, and any address listed in the
> technical, registrant, or administrative contact field of the domain's
WHOIS
> record.
Excellent!
I believe there is something crucial missing which hasn't been
disclosed. HOW EXACTLY do you verify that I'm not Muhtar Kent? I
provided you with Muhtar Kent's Passport, can I get a certificate in his
name now?
Additionally, if you can't disclose how you are able to verify someones
identity, how can the relying parties know and rely on it? In this case
it's Mozilla which makes a decision on behalf of their users. I believe
it's very much on scope.
> H. On the issue of "authority" or "authorization" (the Coca Cola
example),
> the new Section 3.2.5 explains how DigiCert verifies the "organizational
> authority" of the certificate requester:
> "Verifying that the individual requesting the certificate has the
authority
> to act on behalf of the organization named in the certificate by:
> 1. Referring to information about the individual's role within the
> organization that is independently obtained by DigiCert either from the
> organization itself or from a reliable third party or government source,
or
> 2. Confirming the individual's role within the organization by calling an
> independently verified telephone number for the organization or by
following
> a comparable procedure that is more appropriate for that particular
> organization."
I'm certain you'll be able to confirm at Muhtar Kent is duly authorized
for just about anything that Coca Cola concerns. How do you know that
I'm Muhtar Kent ?
Also, what would be an comparable procedure as mentioned above? How
would you deal with an organization that is registered at the agents
address? Or at the accountant for that matter?
And finally, you mentioned further above:
If such databases are insufficient to confirm the
identity of the subject, DigiCert validates the Applicant by requesting
official company documentation, such as a business license, filed or
certified articles of incorporation/organization, sales license or other
relevant documents
But how do you validate it? Meaning, if I present you with all those
documents, I'll get a certificate for "American Mountain View, Inc." ?
Basically you disclose upon which documents you rely, you don't really
disclose how you validate it.
> I. Regarding concerns about the extended key usages in the profiles of
our
> Intermediate CA certificates--we do not see an issue. (The EKUs mentioned
> are not all in the same end entity certificate profile, if that was the
> issue.)
Perhaps you want to spell it out or add a description which says exactly
the above?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
_______________________________________________
Eddy Nigg
On 07/11/2010 03:16 AM, From Ben Wilson:
> This raises an interesting question about whether a CPS should publicize
> "exact" details, which reduce the reconnaissance needed for an attacker to
> identify vulnerabilities, or whether private disclosure to trusted
> independent reviewers (who also sign NDAs and agree to protect trade
> secrets) will improve the identity vetting processes and make them more
> secure?
Obscurity as security is not such a good defense, it would be better
that the processes would be reasonable tight and not vulnerable.
Specially in Mozilla land and open source in general, obscurity as
defense doesn't basically not exist. Perhaps quite the opposite might be
the case, if your procedures are robust enough, any fraudulent attempt
will be sought elsewhere. Because the barrier and price would be too
high with yours. And if that's not the case, then this is a good
opportunity to make it such, for your advantage.
As such, I believe that the disclosure must be reasonable clear so that
the relying party knows what your policies and practices are. And what
if you are missing indeed an import step in your processes (from what I
know this is probably not the case, it's simply not disclosed properly,
which is the problem). Also, you might consider disclosing the minimum
set of practices in order to satisfy the requirements and leave the rest
to the imagination.
Further, your CA might not be actually affected and your practices are
entirely solid, but another CAs (practices) might be not. Now in the end
of the day, only disclosure (and audit of said disclosure) will provide
confirmation of those practices, whatever CA this is.
> If one takes the detailed CPS approach, then security sensitive
> portions of the CPS (e.g. any detailed identity vetting processes) could be
> marked for redaction before distribution or publication.
There are certain aspects of a CPS which don't have to be published, but
it must be unmistakeably clear that you are doing the right thing. For
example you might disclose that a copy of your CA root keys are store
with a bank, obviously nobody expects to know the address of the bank
and vault number etc.
So far my opinion - hopefully reasonable and logic.
Eddy Nigg
>
> So far my opinion - hopefully reasonable and logic.
>
One other note about the logic. Actually proper disclosure also protects
the CA quite a bit. Just consider tomorrow something bad happens, you
can always point to the CPS and its disclosed (and audited) practices,
which formed the basis for any approval with the software vendor.
But lets consider further that indeed something bad happened and lets
assume the guy mentioned in the certificate doesn't actually exist (or
worse, he was impersonated). Now the hurt relying party and user of
Mozilla will obviously look for somebody to blame. And Mozilla might be
one party to take such blame. Now lets consider further that Mozilla
can't actually tell how the CA reasonable verified, that the entity
submitting the certificate signing request is the same entity referenced
in the certificate. That's because the CA hasn't disclosed it and was
approved by Mozilla nevertheless. Oouups, now Mozilla will have to share
the blame.
Therefore, proper disclosure in order to satisfy the minimum
requirements which Mozilla sets forth in its policy is in my opinion a
requirement.
Kurt Seifried
make decisions to trust/not trust a CA (no way to deploy policies for
firefox/remove certs easily/etc.). So reading the CPS and going "hmmm.
that sounds weak. I should not trust them" won't really happen. The
bad guys will poke the system to find problems like I did with the
ssladmin@/ssladministrator@/etc. verification process ("hey,
waitaminute, I can get certficates for webmail providers trivially!").
To say nothing of the other methods I suspect will work.
Ultimately once Mozilla chooses to trust a CA the users are on the
ride with no easy way to get off.
-Kurt
Robin Alden
I disagree.
You have arbitrarily decided that everything must be disclosed, except some things e.g bank locations.
How does this relate to Mozilla CA policy?
Audits do not only cover what is disclosed.
Regards
Robin Alden
Comodo CA Limited
Office: +44 1274 730505
--
Regards
_______________________________________________
Eddy Nigg
> Eddy,
> I disagree.
Of course.
> You have arbitrarily decided that everything must be disclosed, except
> some things e.g bank locations.
It was an example.
>
> How does this relate to Mozilla CA policy?
Well, else how do we know if it's not disclosed? So far the CP/CPS of
the CAs has formed the basis for every root inclusion and this is what
Kathleen checks and what we discuss here. I'm not aware of any other
method for confirming compliance to the Mozilla CA policy.
>
> Audits do not only cover what is disclosed.
Right, but the audits also confirm what's disclosed. That's the point.
Eddy Nigg
On 07/11/2010 06:43 AM, From Kurt Seifried:
> I don't think it much matters. As an end user/admin I can't easily
> make decisions to trust/not trust a CA (no way to deploy policies for
> firefox/remove certs easily/etc.).
Correct, that's why Mozilla invests a considerable effort to make a
decision on their behalf.
> Ultimately once Mozilla chooses to trust a CA the users are on the
> ride with no easy way to get off.
Right, and Mozilla's decision has to be based on something.
Eddy Nigg
On 07/11/2010 03:16 AM, From Ben Wilson:
> This raises an interesting question about whether a CPS should publicize
> "exact" details, which reduce the reconnaissance needed for an attacker to
> identify vulnerabilities. If one takes the detailed CPS approach, then security sensitive
> portions of the CPS (e.g. any detailed identity vetting processes) could be
> marked for redaction before distribution or publication.
I thought about this some more - it's a good exercise for the brain
muscles on a hot and humid Sunday like today. ;-)
If the above statement of yours would be correct, then I'm afraid that
the EV guidelines and all relevant policies and practices statements
based on those guidelines would present a risk to everybody who relies
on EV certificates. That's because the EV guidelines define and describe
very detailed which validations a CA has to perform and exactly how they
have to be performed. For example just read section 3.2.2.2 EV Guideline
Requirements for Authentication of Organizational Identity of your EV
CPS at http://www.digicert.com/DigiCert_EV-CPS.pdf
If you really believe that this is the case and the current detailed
disclosure of the EV guidelines present a risk and allows an attacker to
identify vulnerabilities, then I suggest to take this issue to the
CA/Browser forum and present a motion to have any detailed requirements
of the vetting processes removed. I'll support your motion based on this
understanding.
But if this is not the case, then policy and practice statements must
disclose the vetting processes and validation steps exactly like they
are disclosed in your EV CPS as well.
Ben Wilson
One other thought I had while noodling over this--we have not yet discussed
financial, legal and reputational risk to the CA. The assumption is that
Mozilla users have no recourse and that they will only go after Mozilla
because it trusted a CA. This is not the case. The CA itself has these
risks as well. The CA has its financial livelihood at risk--who wants to do
business with a CA who keeps making careless mistakes? Legal risks
exist--including the fact that a relying party (or a class of them) could
sue the CA for negligent misrepresentation and other causes of action. And
third, reputational risk--even if the first two risks don't materialize, no
CA wants to earn a reputation for untrustworthiness. I think there needs to
be an appropriate amount of discretion exercised when determining what to
disclose and what not to disclose publicly. By the way, who do you think
will win the World Cup, the Netherlands or Spain? It should be a good
match.
Cheers,
Ben
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Eddy Nigg
Sent: Sunday, July 11, 2010 7:28 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert Code Signing Enablement Request
Hi Ben,
On 07/11/2010 03:16 AM, From Ben Wilson:
> This raises an interesting question about whether a CPS should publicize
> "exact" details, which reduce the reconnaissance needed for an attacker to
> identify vulnerabilities. If one takes the detailed CPS approach, then
security sensitive
> portions of the CPS (e.g. any detailed identity vetting processes) could
be
> marked for redaction before distribution or publication.
I thought about this some more - it's a good exercise for the brain
muscles on a hot and humid Sunday like today. ;-)
If the above statement of yours would be correct, then I'm afraid that
the EV guidelines and all relevant policies and practices statements
based on those guidelines would present a risk to everybody who relies
on EV certificates. That's because the EV guidelines define and describe
very detailed which validations a CA has to perform and exactly how they
have to be performed. For example just read section 3.2.2.2 EV Guideline
Requirements for Authentication of Organizational Identity of your EV
CPS at http://www.digicert.com/DigiCert_EV-CPS.pdf
If you really believe that this is the case and the current detailed
disclosure of the EV guidelines present a risk and allows an attacker to
identify vulnerabilities, then I suggest to take this issue to the
CA/Browser forum and present a motion to have any detailed requirements
of the vetting processes removed. I'll support your motion based on this
understanding.
But if this is not the case, then policy and practice statements must
disclose the vetting processes and validation steps exactly like they
are disclosed in your EV CPS as well.
--
Kurt Seifried
> One other thought I had while noodling over this--we have not yet discussed
> financial, legal and reputational risk to the CA. The assumption is that
> Mozilla users have no recourse and that they will only go after Mozilla
> because it trusted a CA. This is not the case. The CA itself has these
> risks as well. The CA has its financial livelihood at risk--who wants to do
> business with a CA who keeps making careless mistakes? Legal risks
> exist--including the fact that a relying party (or a class of them) could
> sue the CA for negligent misrepresentation and other causes of action. And
> third, reputational risk--even if the first two risks don't materialize, no
> CA wants to earn a reputation for untrustworthiness.
This is a lovely and largely theoretical argument that boils down to:
"The CAs will self-police themselves in the end users best interest
because the end users are ultimately the consumer of what the CA is
selling"
Except this doesn't work, provably:
1) The end users may be the ultimate consumer of what the CAs are
selling (trust/verification/etc.) but economically they have no power
and in many cases have no manner in which to complain (in some cases
there isn't even an email/phone number they can use to reach the CA,
let alone getting them to actually pay attention).
2) The buyers of the certificates (the sites/etc.) care much less
about security/reputation/etc. of the CA than things like speed of
issuing certificates (now in minutes!) and the cost (cheapest X cert,
etc.). Once a CA is in all the major browsers they are basically on
par/equal to all the other CAs (with the minor different being code
signing and what types of certs they can offer).
which has led to:
3) CAs with known issues/weaknesses. Witness the ssladministrato@/etc.
debacle, it was covered years ago, reported in Bugzilla. Nothing
happens. I buy a certificate for a webmail site from Verisign. Nothing
really happens. I go public. Verisign starts to fix the issue by
removing a few of the addresses (but not all). Not until it hits the
Slashdot front page does Verisign actually remove the rest of the
addresses.
http://www.linux-magazine.com/w3/issue/114/054-055_kurt.pdf
http://news.slashdot.org/story/10/04/18/1218212/Become-an-SSLAdmin-In-a-Few-Easy-Steps?art_pos=1
Can anyone point out to me the damage/etc. done to Verisign? Any
penalties or censure? As far as I know there was none. Even just
basically fixing the problem required public shaming and holding their
feet to the fire (in the sense of "if you don't fix this a lot of
people are about to start abusing it").
I'm willing to bet a large sum of money that a random survey of web
users would result in less than 1% knowing about CA
weaknesses/issues/basic understanding of how this all works.
The reason self regulation/policing due to market forces will never
work is there are no market forces for this. Even this list which is
generally well informed/on top of the problems failed for several
years to push the ssladministrator@ issue, I had to go buy certs, and
even then that wasn't enough.
In other words I believe that the only entities that can protect users
are the browser vendors, and they seem unwilling to do so (witness the
rapid inclusion of most CA root certificates, the unwillingness to
play hard ball with CAs, etc.
It's broken.
--
Kurt Seifried
ku...@seifried.org
tel: 1-703-879-3176
Eddy Nigg
On 07/11/2010 07:10 PM, From Ben Wilson:
> One other thought I had while noodling over this--we have not yet discussed
> financial, legal and reputational risk to the CA. The assumption is that
> Mozilla users have no recourse and that they will only go after Mozilla
> because it trusted a CA.
I have never said that anywhere and it's quite wrong. However the
software vendors must due their own due diligence and share a certain
responsibility - in this case Mozilla. As SSL security is just a part of
what the software vendors do, CAs have many more things to take care of
for THEIR primary business.
> And
> third, reputational risk--even if the first two risks don't materialize, no
> CA wants to earn a reputation for untrustworthiness.
Well, sometimes it seems to me that some CAs couldn't care less about
their reputation. Literally :-(
> I think there needs to
> be an appropriate amount of discretion exercised when determining what to
> disclose and what not to disclose publicly.
I agree and I believe there should be enough disclosed in order to make
an informed decision. In the end of the day I'm certain that you and
your team are going to agree with me. Specially since you would like to
see the same happen elsewhere too.
> By the way, who do you think
> will win the World Cup, the Netherlands or Spain? It should be a good
> match.
Well, it's already after the game, it was a fine match. Didn't had a
special preference though, thought that Holland could make it, but
apparently not. That's it for the next three years and eleven month :-)
Moudrick M. Dadashov
> Hi Ben,
>
> On 07/11/2010 07:10 PM, From Ben Wilson:
>> discussed
>> financial, legal and reputational risk to the CA. The assumption is
>> that
>> Mozilla users have no recourse and that they will only go after Mozilla
>> because it trusted a CA.
>
> software vendors must due their own due diligence and share a certain
> responsibility - in this case Mozilla. As SSL security is just a part
> of what the software vendors do, CAs have many more things to take
> care of for THEIR primary business.
>
I was expecting that "a certain responsibility" is a part of MOZILLA
FIREFOX END-USER SOFTWARE LICENSE AGREEMENT
(http://www.mozilla.com/en-US/legal/eula/firefox-en.html) but I can't
find it there.
Any ideas where Mozilla presents Firefox responsibility sharing issues?
Thanks a lot,
M.D.
cell: +370-699-26662
Kathleen Wilson
> DigiCert has applied to enable the Code Signing trust bit for three
> DigiCert root certificates that are currently included in NSS.
>
> DigiCert is a US-based commercial CA that provides digital certification
> and identity assurance services internationally to a variety of sectors
> including business, education, and government.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=515425
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#DigiCert
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=415671
>
> Noteworthy points:
>
> * All three of these root certificates were approved for inclusion
> according to the Mozilla CA Policy in bug #364568.
> ** The three roots are “DigiCert Assured ID Root CA”, “DigiCert Global
> Root CA”, and “DigiCert High Assurance EV Root CA”.
> ** Each root has internally-operated intermediate CAs for each level of
> assurance.
Note that the recent audits for these DigiCert roots have been posted:
https://cert.webtrust.org/ViewSeal?id=1054
https://cert.webtrust.org/ViewSeal?id=1055
The representatives of DigiCert plan to respond in this discussion in a
few days to post an updated CPS in order to clarify the descriptions of
their processes as per feedback provided in this discussion.
Kathleen
Kathleen Wilson
>
> The representatives of DigiCert plan to respond in this discussion in a
> few days to post an updated CPS in order to clarify the descriptions of
> their processes as per feedback provided in this discussion.
>
Well, it's been more than a few days... So I'm going to go ahead and
start the next discussion in the queue. This discussion may continue
when DigiCert posts their updated CPS.
Kathleen
Ben Wilson
of the revised CP and CPS for changes to sections that were not related to
the code-signing comments. We will submit the revised CP and CPS as soon as
possible.
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Kathleen Wilson
Sent: Monday, July 26, 2010 12:00 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert Code Signing Enablement Request
On 7/14/10 3:50 PM, Kathleen Wilson wrote:
>
> The representatives of DigiCert plan to respond in this discussion in a
> few days to post an updated CPS in order to clarify the descriptions of
> their processes as per feedback provided in this discussion.
>
Well, it's been more than a few days... So I'm going to go ahead and
start the next discussion in the queue. This discussion may continue
when DigiCert posts their updated CPS.
Kathleen