AffirmTrust Root Inclusion Request
Kathleen Wilson
Websites trust bit for all of them. The request is also to enable EV for
all 4 roots. The root certificates under consideration are: AffirmTrust
Commercial, AffirmTrust Networking, AffirmTrust Premium, and AffirmTrust
Premium ECC.
AffirmTrust is a new Certification Authority based in the US.
AffirmTrust plans to offer certificates for web-based and mobile
applications including microbanking, debit cards and smartcards, mobile
phone applications, new media, cloud computing, social networking, etc.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=543639
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#AffirmTrust
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=501719
Noteworthy points:
* The certificates may be downloaded from here:
http://www.affirmtrust.com/resources/
** AffirmTrust Commercial
** AffirmTrust Networking
** AffirmTrust Premium
** AffirmTrust Premium ECC
* The CPS and Relying Party Agreement documents are in English.
CPS: http://www.affirmtrust.com/repo/AffirmTrust_CPS_v1.1_12-23-2010.pdf
Relying Party Agreement:
http://www.affirmtrust.com/repo/AffirmTrust_Relying_Party_Agreement_v1.1_12-23-2010.pdf
* Each root will sign internally-operated sub-CAs which will sign
end-entity certificates. AffirmTrust initially plans to only issue EV
SSL certificates, but may in the future issue DV SSL, OV SSL, email
(S/MIME), and code signing certificates under different sub-CAs of each
root.
* Currently each root only has one subordinate CA, for issuing EV SSL
certificates. There are provisions in Appendix A of the CPS for issuing
additional subordinate CAs and types of certificates in the future. The
CPS indicates that future subCAs may be created for issuing OV and DV
certificates.
* The request is to enable the websites trust bit.
** CPS Section II.D: When AffirmTrust issues an EV Certificate,
AffirmTrust represents and warrants to the EV Certificate Beneficiaries,
during the period when the EV Certificate is Valid, that AffirmTrust has
followed the requirements of the EV Guidelines and its EV Policies in
issuing the EV Certificate and in verifying the accuracy of the
information contained in the EV Certificate ("EV Certificate
Warranties"). The EV Certificate Warranties specifically include, but
are not limited to, the following:
(1) Legal Existence. AffirmTrust has confirmed with the incorporating or
registration agency in the Subject's jurisdiction of incorporation or
registration that, as of the date the EV Certificate was issued, the
Subject named in the EV Certificate legally exists as a valid
organization or entity in the jurisdiction of incorporation or registration;
(2) Identity. In accordance with the procedures stated in the EV
Guidelines, AffirmTrust has confirmed that, as of the date the EV
Certificate was issued, the legal name of the Subject named in the EV
Certificate matches the name on the official government records of the
incorporating or registration agency in the Subject's jurisdiction of
incorporation or registration, and if an assumed name is also included,
that the assumed name is properly registered by the Subject in the
jurisdiction of its place of business;
(3) Right to Use Domain Name. AffirmTrust has taken all steps reasonably
necessary to verify that, as of the date the EV Certificate was issued,
the Subject named in the EV Certificate has the exclusive right to use
the domain name(s) listed in the EV Certificate;
(4) Authorization for EV Certificate. AffirmTrust has taken all steps
reasonably necessary to verify that the Subject named in the EV
Certificate has authorized the issuance of the EV Certificate;
(5) Accuracy of Information. AffirmTrust has taken all steps reasonably
necessary to verify that all of the other information in the EV
Certificate is accurate, as of the date the EV Certificate was issued;
(6) Subscriber Agreement. The Subject named in the EV Certificate has
entered into a legally valid and enforceable Subscriber Agreement with
AffirmTrust that satisfies the requirements of the EV Guidelines or the
Applicant Representative has acknowledged and accepted the Terms of Use
(if applicable);
** CPS Appendix A, section 3.2: Whenever an organization name is
included in the Certificate (e.g., for OV Certificates), AffirmTrust
will take reasonable steps to establish that a Certificate request made
on behalf of that Organization is legitimate and properly authorized.
AffirmTrust will ensure the following: (a) the Organizational Name
appears in conjunction with a country and possibly a state or province
of other locality to sufficiently identify its place of registration or
a place where it is currently doing business; and (b) in the case of an
Organization that could reasonably be expected to be registered with a
local, state or national authority, in certain circumstances AffirmTrust
will obtain, view and verify copies of the registration documents. For
instance, AffirmTrust may (a) verify the validity of the registration
through the authority that issued it, or (b) verify the validity of the
registration through a reputable third party database or other resource,
or (c) verify the validity of the Organization through a trusted third
party data source, or (d) confirm that the Organization exists if such
Organization is not the type that is typically registered or is capable
of being verified under clause (b).
** CPS Appendix A, section 3.3: When a domain name is included in a
Certificate together with an organization name (e.g., for OV
Certificates), AffirmTrust will verify that the Subscriber had the right
to use the domain name submitted by the Subscriber at the time it
submitted its application. For instance, AffirmTrust may perform this
verification by confirming that the Subscriber is the same person or
entity that holds the domain name registration from the relevant domain
name registrar or that the Subscriber is otherwise authorized to use
such domain name.
** CPS Appendix A, section 3.3: When a domain name is included in a
Certificate without authentication of the entity owning the domain name
(e.g., for DV Certificates), AffirmTrust will verify that the Subscriber
has control over such domain name at the time it submitted its
enrollment form by accessing a third party database of domain names and
their owners. To do this, AffirmTrust will send an e-mail message to one
of the following e-mail addresses requesting confirmation of the
Certificate order and authorization to issue the Certificate in the
domain name: (a) an e-mail address listed as the administrative or
technical contact for the domain name in an official InterNIC domain
name registry that includes the domain name, (b) a limited list of the
most commonly used generic e-mail addresses for authorized persons at
domain names (e.g., “ad...@domain.com,“ or “hostm...@domain.com” for
the domain name domain.com), or (c) using a manual process conducted by
AffirmTrust, to another e-mail address containing the domain name that
is listed as the Common Name in the enrollment form. Upon receipt of a
confirming e-mail message authorizing issuance of the Certificate,
AffirmTrust will issue the Certificate as described below. Additionally,
a confirmatory phone call to the applicant may be performed for Domain
Control Certificate applications.
* EV Policy OIDs
** AffirmTrust Commercial: 1.3.6.1.4.1.34697.2.1
** AffirmTrust Networking: 1.3.6.1.4.1.34697.2.2
** AffirmTrust Premium: 1.3.6.1.4.1.34697.2.3
** AffirmTrust Premium ECC: 1.3.6.1.4.1.34697.2.4
* Test Websites:
** AffirmTrust Commercial - https://commercial.affirmtrust.com/
** AffirmTrust Networking - https://networking.affirmtrust.com:4431/
** AffirmTrust Premium - https://premium.affirmtrust.com:4432/
** AffirmTrust Premium ECC – https://premiumecc.affirmtrust.com:4433/
*CRL:
http://crl.affirmtrust.com/crl/AffirmTrustCommercial.crl
http://crl.affirmtrust.com/crl/aftcomev2.crl (NextUpdate: 7 days)
http://crl.affirmtrust.com/crl/AffirmTrustNetworking.crl
http://crl.affirmtrust.com/crl/aftnetworkev2.crl (NextUpdate: 7 days)
http://crl.affirmtrust.com/crl/AffirmTrustPremium.crl
http://crl.affirmtrust.com/crl/aftpremev2.crl (NextUpdate: 7 days)
http://crl.affirmtrust.com/crl/AffirmTrustPremiumECC.crl
http://crl.affirmtrust.com/crl/aftpremeccev2.crl (NextUpdate: 7 days)
** CPS Section II.I: End-entity certificate CRLs will be updated and
reissued at least every seven days, and the nextUpdate field value will
not be more than ten days, except as otherwise provided in AffirmTrust's
Business Continuity Plan. AffirmTrust shall post the CRLs online at
www.affirmtrust.com/resources at the interval stated in the previous
sentence (but also within 24 hours of a Certificate revocation) in a DER
format.
* OCSP:
** AffirmTrust Commercial: http://ocsp.affirmtrust.com/commev
** AffirmTrust Networking: http://ocsp.affirmtrust.com/ntwkev
** AffirmTrust Premium: http://ocsp.affirmtrust.com/premev
** AffirmTrust Premium ECC: http://ocsp.affirmtrust.com/premeccev
** CPS Section II.I: AffirmTrust shall provide revocation information
for end-entity EV Certificates via an OCSP service that is updated at
least every four days, and OCSP responses from this service will have a
maximum expiration time of ten days.
* Audit: WebTrust CA and WebTrust EV audits were performed by IS
Partners, LLC, which is part of Interactive Solutions, LLC
(http://www.ispartnersllc.com, http://www.interactivesolutionsllc.com/).
The audit reports were attached to the bug, and I exchanged email with a
representative of Interactive Solutions to confirm the authenticity of
the audit reports.
** WebTrust CA: https://bugzilla.mozilla.org/attachment.cgi?id=428774
(2010.01.31)
** WebTrust EV: https://bugzilla.mozilla.org/attachment.cgi?id=428776
(2010.01.31)
Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):
* None noted.
This begins the discussion of the request from AffirmTrust to add 4 root
certificates, enable the Websites trust bit for all of them, and enable
EV for all of them. At the conclusion of this discussion, 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
Kathleen Wilson
Would at least two people please review and comment on this request from
AffirmTrust to add 4 root certificates, turn on the websites trust bit
for them, and enable EV?
I will greatly appreciate your help with reviewing and discussing this
request.
Kathleen
Jeremy Rowley
Now that the new policy has been submitted for approval, should CPS
documents be reviewed under the new policy or the old one?
Jeremy
-----Original Message-----
From:
dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Kathleen Wilson
Sent: Friday, January 28, 2011 11:48 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: AffirmTrust Root Inclusion Request
On 1/7/11 9:24 AM, Kathleen Wilson wrote:
Would at least two people please review and comment on this request from
AffirmTrust to add 4 root certificates, turn on the websites trust bit
for them, and enable EV?
I will greatly appreciate your help with reviewing and discussing this
request.
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Kathleen Wilson
> Hey Kathleen,
>
> Now that the new policy has been submitted for approval, should CPS
> documents be reviewed under the new policy or the old one?
>
> Jeremy
>
The new one.
Thanks,
Kathleen
Eddy Nigg
Will try to do that soon.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Rafa M
additional subordinate CAs and types of certificates in the future./
That subordinate CAs, will be always internally operated?
If not, what kind of organizations could get a subordinate CA certificate?
Regards,
Rafa
El 28/01/2011 19:47, Kathleen Wilson escribió:
> On 1/7/11 9:24 AM, Kathleen Wilson wrote:
Kirk Hall
> /There are provisions in Appendix A of the CPS for issuing
> additional subordinate CAs and types of certificates in the future./
>
> That subordinate CAs, will be always internally operated?
>
> If not, what kind of organizations could get a subordinate CA certificate?
>
> Regards,
>
> Rafa
>
> El 28/01/2011 19:47, Kathleen Wilson escribió:
>
>
To answer your question, let me start by reviewing what is already in
our CPS on this issue.
Sections I.C, III.B, and V.A of our CPS provide as follows:
“C. Description and Use of Certificates
1. AffirmTrust Extended Validation Server Certificates
*** AffirmTrust conforms to the current version of the CA-Browser
Forum Guidelines for Issuance and Management of Extended Validation
Certificates ("EV Guidelines") published at http://www.cabforum.org,
and implements the EV Guidelines through this CPS and AffirmTrust’s
other EV Policies. In the event of any inconsistency between
AffirmTrust’s EV Policies and the EV Guidelines, the EV Guidelines
take precedence. [This is the mandatory commitment to the EV
Guidelines required of all CAs under EV Guideline Section 7.1.2(3)
***”
“III.B. Authentication Process
“At the present time, AffirmTrust issues only Extended Validation
Server Certificates and only to Private Organizations created in the
United States as defined in the EV Guidelines.
“AffirmTrust does not presently issue Domain Validated (DV)
Certificates (SSL/TLS), Organization Validated (OV) Certificates (SSL/
TLS), Email (S/MIME) Certificates, or Code Signing Certificates. In
the event AffirmTrust decides to issue one or more of these other
Certificate types, it will amend its CPS at that time to include
generally the authentication and issuing procedures listed in Appendix
A, as applicable for each Certificate type, as well as all applicable
CA-Browser Forum guidelines.”
“V.C ***AffirmTrust has not authorized any external sub-CAs to be
operated by third parties at the present time.
“In the event AffirmTrust decides to authorize any external sub-CAs to
be operated by third parties in the future, AffirmTrust intends to
amend this CPS to impose legal, technical, attestation and audit, and
other requirements on the sub-CAs substantially equivalent to those
followed by AffirmTrust for similar certificates.
“In the event an external sub-CA is authorized to issue EV
Certificates, AffirmTrust intends to state in its CPS AffirmTrust’s
practices following all relevant rules as stated in the EV Guidelines
concerning external sub-CAs operated by third parties (as such rules
may be amended from time to time in the Guidelines), including but not
limited to EV Guidelines 7.1.2(3), 8.2.2, 10.12, 11.1.1(1), 12.2.2,
and 15.2.2.
“End-entity certificates are not issued off AffirmTrust’s root
certificates, but are issued off the following intermediate Sub-CA
root certificates:
For AffirmTrust Commercial Root: ***
• End-entity certificates issued by any future external sub-CA will be
issued off a sub-CA root certificate identified by sub-CA identity and
authentication method with the following naming scheme: AffirmTrust
Commercial [additional identity information re sub-CA and
authentication method] CA. Key length will be 2048 bits.
For AffirmTrust Networking Root: ***
• End-entity certificates issued by any future external sub-CA will be
issued off a sub-CA root certificate identified by sub-CA identity and
authentication method with the following naming scheme: AffirmTrust
Networking [additional identity information re sub-CA and
authentication method] CA. Key length will be 2048 bits.
For AffirmTrust Premium Root: ***
• End-entity certificates issued by any future external sub-CA will be
issued off a sub-CA root certificate identified by sub-CA identity and
authentication method with the following naming scheme: AffirmTrust
Premium [additional identity information re sub-CA and authentication
method] CA. Key length will be 4096 bits.
For AffirmTrust Premium ECC Root: ***
• End-entity certificates issued by any future external sub-CA will be
issued off a sub-CA root certificate identified by sub-CA identity and
authentication method with the following naming scheme: AffirmTrust
Premium ECC [additional identity information re sub-CA and
authentication method] CA. Key length will be 384 bits.”
EV CERTIFICATES: As noted above, AffirmTrust’s main interest at the
present time is in EV Certificates, and all the rules for issuing EV
Certificates are laid out in great detail in the EV Guidelines,
http://www.cabforum.org/Guidelines_v1_3.pdf. These requirements are
mandatory on all CAs that issue EV Certs, including all subordinate
CAs, whether owned by a CA or independent.
In the quoted CPS provisions above, we make it clear that if we ever
authorize a third party subordinate CA to issue EV certs off one of
our roots, we will (1) create a separate sub-CA for the subordinate CA
to use which is marked with the subordinate CA’s name and type of
certificate (EV), and (2) we will require the subordinate CA to follow
all provisions of the EV Guidelines, including all EV WebTrust audit
requirements. This is also required by EV Guidelines Sec. 7.1.2(3),
which states:
In addition, the CA MUST include (directly or by reference) the
applicable requirements of these Guidelines in all contracts with
Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve
or relate to the issuance or maintenance of EV Certificates. The CA
MUST enforce compliance with such terms.
In addition, AffirmTrust is bound by EV Guidelines Section 15.2.2
concerning third party subordinate CAs:
15.2.2 Root CA Indemnification
In cases where the Subordinate CA and the Root CA are different legal
entities and the Root CA specifically enables the Subordinate CA to
issue EV Subscriber Certificates, the Root CA SHALL also be
responsible for the performance and warranties of the Subordinate CA,
for the Subordinate CA’s compliance with these Guidelines, and for all
liabilities and indemnification obligations of the Subordinate CA
under these Guidelines, as if the Root CA were the Subordinate CA
issuing the EV Certificates.
OV AND DV CERTIFICATES: As you know, there are no similar mandatory
rules for independent subordinate CAs issuing organizationally
validated (OV) and domain validated (DV) certificates. That’s why we
included the language in our CPS quoted above that states if we
“authorize any external sub-CAs to be operated by third parties in the
future, AffirmTrust intends to amend this CPS to impose legal,
technical, attestation and audit, and other requirements on the sub-
CAs substantially equivalent to those followed by AffirmTrust for
similar certificates.”
In other words, before we would issue any sub-CA to an independent
subordinate CA for use in issuing OV or DV certificates, we would
FIRST specify the applicable authentication and audit requirements for
AffirmTrust’s OWN issuance of OV or DV certificates in our CPS, and
then require that the subordinate CA follow at least those minimum
guidelines. Because we do not presently plan to issue OV or DV
certificates, we have not included the FINAL specifications in our CPS
– but we did include general requirements for OV and DV certificates
in Appendix A of our CPS (Authentication and Certificate Issuance
Procedures for Non-EV Certificates), which are very similar to (and
just as strong as) the processes specified by other commercial CAs in
their own CPSs for OV and DV certificates.
TYPES OF ORGANIZATIONS THAT COULD GET A SUBORDINATE CA CERTIFICATE: So
in answer to your original question above – we don’t have a list of
the types of organizations that could get a subordinate CA certificate
from AffirmTrust, but if this ever happens, it would likely be the
SAME type of organization that other commercial CAs issue subordinate
CA certificates to. This could include enterprise CAs, or established
companies that are willing to follow ALL the rules and requirements
that we have quoted above.
For subordinate CAs that want to issue EV certificates, they will have
to follow all the EV Guidelines applicable to all CAs and be audited,
and AffirmTrust will be responsible for their actions as specified in
EV Guideline 15.2.2 quoted above.
For subordinate CAs that want to issue OV or DV certificates, they
will have to follow all rules established by AffirmTrust for its OWN
similar OV or DV certificates, including all “legal, technical,
attestation and audit, and other requirements *** substantially
equivalent to those followed by AffirmTrust for similar certificates.”
Eddy Nigg
>
> Will try to do that soon.
>
Just curious if this CA is actually life and issuing certificates to the
public? If not, the benefit for Mozilla's users might be questionable.
Some additional information would be useful.
Besides that I have nothing particular to add at the moment.If there
should be considerable changes with the CA policies and practices, a
review might be in order. But that's true for almost any CA, just in
this case there are more unknowns than usual.
Rafa M
With regard to:
"Right to Use Domain Name. AffirmTrust has taken all steps reasonably
necessary to verify that, as of the date the EV Certificate was issued,
the Subject named in the EV Certificate has the exclusive right to use
the domain name(s) listed in the EV Certificate;":
Specifically, what mechanism is used to verify this?
Regards,
R
Kirk Hall
> On 01/29/2011 01:08 AM, From Eddy Nigg:
>
>
>
> > Will try to do that soon.
>
> Just curious if this CA is actually life and issuing certificates to the
> public? If not, the benefit for Mozilla's users might be questionable.
> Some additional information would be useful.
>
> Besides that I have nothing particular to add at the moment.If there
> should be considerable changes with the CA policies and practices, a
> review might be in order. But that's true for almost any CA, just in
> this case there are more unknowns than usual.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
AffirmTrust presently offers EV certificates to the general public,
but until our roots are distributed in Mozilla (and therefore also
distributed in Android, which follows Mozilla’s decisions on trusted
roots), our certs won’t have sufficient ubiquity to be commercially
attractive for general use. We are planning a major promotion of our
commercial products as of Summer 2011, after our roots have been
distributed in Mozilla and Android.
Our roots were accepted early last year in Microsoft, Apple, Chrome,
Opera, and all other major browsers and are widely distributed in
those markets. The roots were administratively accepted by Mozilla in
February 2010, and we’ve waited nearly a year in the Mozilla queue for
start of the Mozilla public discussion, so this is the last step
before complete ubiquity.
Most roots of the other CAs waiting in the Mozilla queue likewise are
not widely used at present, as Mozilla has succeeded so well as a
browser that distribution by Mozilla is now a “must” for CAs.
Kirk Hall
The language you have quoted from the AffirmTrust CPS Section II.D(3)
is mandatory language that comes directly from the CA-Browser Forum’s
EV Guidelines Section 6.2.1(2)(C), see http://www.cabforum.org/Guidelines_v1_3.pdf.
The quoted language relates to the warranty provided by AffirmTrust to
relying parties and others that AffirmTrust has determined an EV
certificate customer’s right to use the domain name in the EV
certificate using appropriate methods. This warranty language is
REQUIRED of all CAs that issue EV certificates, and is not unique to
AffirmTrust.
What verification methods are used to determine a customer’s right to
use a domain name? These methods are outlined in great detail in the
EV Guidelines Section 10.6.2, and are also REQUIRED for all CAs to use
in issuing EV certificates – they are not unique to AffirmTrust or to
any other CA. That’s the whole point of the EV Guidelines – they
provide for strong authentication, and are uniform across all CAs –
everyone must use the same strong methods.
From EV Guidelines Section 10.6.2, here are the specific verification
methods AffirmTrust (and all other CAs issuing EV certificates) will
use:
10.6.2 Acceptable Methods of Verification
(1) Applicant as Registered Holder: Acceptable methods by which the
CA MAY verify that the Applicant is the registered holder of the
Domain Name include the following:
(A) Performing a WHOIS inquiry on the Internet for the Domain Name
supplied by the Applicant, and obtaining a response indicating that
the Applicant or a Parent/Subsidiary Company is the entity to which
the Domain Name is registered; or
(B) Communicating with the contact listed on the WHOIS record to
confirm that the Applicant is the registered holder of the Domain Name
and having the contact update the WHOIS records to reflect the proper
Domain Name registration. Confirmation that the registered owner of
the Domain Name is a Parent/Subsidiary Company of the Applicant, or a
registered trading name of the Applicant is sufficient to establish
that the Applicant is the registered owner of the Domain Name;
(C) In cases where domain registration information is private, and the
domain registrar offers services to forward communication to the
registered domain holder, the CA MAY contact the Applicant through the
domain registrar by e-mail or paper mail.
(2) Applicant’s Exclusive Right to Use: In cases where the Applicant
is not the registered holder of the Domain Name, the CA MUST verify
the Applicant’s exclusive right to use the Domain Name(s).
(A) In cases where the registered domain holder can be contacted using
information obtained from WHOIS, or through the domain registrar, the
CA MUST obtain positive confirmation from the registered domain holder
by paper mail, e-mail, telephone, or facsimile that the Applicant has
been granted the exclusive right to use the requested Fully Qualified
Domain Name (FQDN).
If the Top-Level Domain is a generic top-level domain (gTLD) such
as .com, .net, or .org in accordance with RFC 1591, the CA MUST obtain
positive confirmation from the second-level domain registration
holder. For example, if the requested FQDN is www1.www.example.com,
the CA MUST obtain positive confirmation from the domain holder of
example.com.
If the Top-Level Domain is a 2 letter Country Code Top-Level Domain
(ccTLD), the CA MUST obtain positive confirmation from the domain
holder at the appropriate domain level, based on the rules of the
ccTLD. For example, if the requested FQDN is www.mysite.users.internet.co.uk,
the CA MUST obtain positive confirmation from the domain holder of
internet.co.uk.
In addition, the CA MUST verify the Applicant„s exclusive right to use
the Domain Name using one of the following methods:
(i) Relying on a Verified Legal Opinion or a Verified Accountant
Letter to the effect that the Applicant has the exclusive right to use
the specified Domain Name in identifying itself on the Internet; or
(ii) Relying on a representation from the Contract Signer, or the
Certificate Approver, if expressly so authorized in a mutually-agreed-
upon contract.
(B) In cases where the registered domain holder cannot be contacted,
the CA MUST:
(i) Rely on a Verified Legal Opinion or a Verified Accountant Letter
to the effect that the Applicant has the exclusive right to use the
specified Domain Name in identifying itself on the Internet; and
(ii) Rely on a representation from the Contract Signer, or the
Certificate Approver, if expressly so authorized in a mutually-agreed-
upon contract, coupled with a practical demonstration by the Applicant
establishing that it controls the Domain Name by making an agreed-upon
change in information found online on a Web page identified by a
uniform resource identifier containing the Applicant’s FQDN.
(3) Knowledge: Acceptable methods by which the CA MAY verify that the
Applicant is aware that it has exclusive control of the Domain Name
include the following:
(A) Relying on a Verified Legal Opinion or a Verified Accountant
Letter to the effect that the Applicant is aware that it has exclusive
control of the Domain Name; or
(B) Obtaining a confirmation from the Contract Signer or Certificate
Approver verifying that the Applicant is aware that it has exclusive
control of the Domain Name.
Kathleen Wilson
Thank you Rafa and Eddy for reviewing and commenting on this request
from AffirmTrust to add 4 root certificates, turn on the websites trust
bit for them, and enable EV.
No action items have resulted from this discussion so far.
Are there any further comments or questions for AffirmTrust before I
close this discussion and recommend approval?
Kathleen
Kathleen Wilson
Again, thank you to those of you who have reviewed and commented on this
root inclusion request.
No action items have resulted from this discussion.
This concludes the public discussion about AffirmTrust�s request to add
4 root certificates, turn on the websites trust bit for them, and enable EV.
I will post my recommendation for approval of this request in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=543639
All follow-up on this request should be posted directly in the bug.
Thanks again to all of you who have participated in this discussion.
Kathleen