CAs and external entities (resellers, outsourcing)
Kai Engert
understand the event involved an approved CA and an external entity they
work with.
From my perspective, it's a CA's job to ensure competent verification
of certificate requests. The auditing required for CAs is supposed to
prove it.
The verification task is the most important task. All people and
processes involved should be part of the assuring audit.
The current Mozilla CA Certificate Policy says:
"6. We require that all CAs whose certificates are distributed with our
software products: ... provide attestation of their conformance to the
stated verification requirements ..."
In my opinion, it means, a CA must do this job themselves.
The policy currently does not appear to handle the scenario where a CA
delegates the verification job to an external entity. So it's unclear
whether it's "forbidden" or "allowed if the external entity has received
equivalent attestation of their conformance".
In my personal opinion, a CA violates the Mozilla CA Certificate Policy
if they delegate the verification job to an external entity not owning
"attestation of their conformance to the stated verification requirements".
If we'd like to be strict, we could remove CAs from our approved list if
they have shown to be non-conforming in the above way.
In any case, the CA policy should get clarified about involving external
entities in the verification and issueing process. All existing CAs
should be required to make a statement about their current business
practices with regards to external entities. After a grace period all
CAs must either stop using external entities, or get "conformance
attestation" for all involved entities.
Kai
Eddy Nigg
>
> The current Mozilla CA Certificate Policy says:
> "6. We require that all CAs whose certificates are distributed with our
> software products: ... provide attestation of their conformance to the
> stated verification requirements ..."
>
Kai, just to counter Ian's reply:
The objective of the Mozilla CA policy is to provide sound, reliable and
in this context reasonable security for its users.
This is anchored clearly in the Mozilla Manifesto as a principal and
further described and defined in the Mozilla CA Policy what PKI and CAs
concerns. The Mozilla CA Policy is clear in its requirements, *intend*
and what it is meant to achieve. All the rest is just throwing sand into
ones eyes.
In this respect section 7 of said policy clearly states what the
requirements are. CAs may find different ways to achieve and conform to
those requirements, however it should not lead to a compromise of those
requirements. Personally I wouldn't outsource domain control validation
but incorporate it into the general process of certificate issuance. In
case it is delegated, the third party must provide attestation of their
conformance. I think this is what you were proposing...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Ben Bucksch
> From my perspective, it's a CA's job to ensure competent verification
> of certificate requests. The auditing required for CAs is supposed to
> prove it. The verification task is the most important task. All
> people and
> processes involved should be part of the assuring audit.
>
> The current Mozilla CA Certificate Policy says:
> "6. We require that all CAs whose certificates are distributed with our
> software products: ... provide attestation of their conformance to the
> stated verification requirements ..."
>
> In my opinion, it means, a CA must do this job themselves.
> In my personal opinion, a CA violates the Mozilla CA Certificate Policy
> if they delegate the verification job to an external entity not owning
> "attestation of their conformance to the stated verification
> requirements".
>
Agreed.
What *is* a CA? I thought it was a company that verifies that a certain
entity is what it claims to be, it verifies identity.
(Even that definition is much smaller than "secure", which normal users
assume, based on our own marketing of SSL = "secure").
The Certificate is merely the technical means to transmit the statement
of verification. For that to work reliably, the CA also has to assure
technical security of their systems.
Based on that definition, which I think most people - even here and on
sec-group - assumed to be true, the CA has to do all verifications itself.
I think the Mozilla policy also implies that, by requiring the audits.
I'd like to see the audit, because I cannot imagine that 7000 resellers
were audited, and if any audit approved them all, it audit was useless
and should be removed from our policy.
Some people seem to now - by allowing "Re define a CA as just a company
that holds the private bits to a root cert that we distribute. That,
IMHO, is a useless definition.
In any case, Comodo has obviously failed to assure its processes. Frank
Hecker asked what is needed to regain trust. It is the assurance of
their processes, that this cannot happen again. For me, that means that
Comodo does all verification
*themselves*, and of course also the key signing. It is not possible to
outsource that task, because it's where the trust relies.
It's fine with me that they have resellers. However, they are just
sellers, not do the verifications. As sales people/companies go, if you
allow the real world comparison, they can recruit customers and collect
money, but they do not do the core business, and they are not
particularly trusted either.
And, FWIW, I do not consider the fact that somebody paid via a certain
credit card to be a sufficient verification, for the sake of SSL certs,
that he really is that person. Nor when he can receive an email to
webmaster@.
(That might have been the "verification" process of Certstar: spam
webmaster@ email addresses (as reed said in the bug), and if they react
to that, obviously they must have read the webmaster@ email and
therefore control the domain, which means the verification is already
done. Yes, I'm cynical.)
Please also read my following post about PositiveSSL specifically.
Frank Hecker
> From my perspective, it's a CA's job to ensure competent verification
> of certificate requests. The auditing required for CAs is supposed to
> prove it.
> In my opinion, it means, a CA must do this job themselves.
My quick personal perspective on this (and I'll apologize in advance to
those of you for whom this is old news):
It is long-standing practice in the CA industry to outsource certain
verification-related tasks to third-party Registration Authorities. See
for example the definition of an RA in an old IETF PKIX document:
http://tools.ietf.org/html/draft-ietf-pkix-roadmap-09
"Registration Authority (RA) - An optional entity given responsibility
for performing some of the administrative tasks necessary in the
registration of subjects, such as: confirming the subject's identity;
**validating that the subject is entitled to have the values requested
in a PKC [public key certificate]**; and verifying that the subject has
possession of the private key associated with the public key requested
for a PKC." [emphasis added]
So IMO there is nothing inherently unusual or illegitimate in the fact
that Comodo or other CAs have resellers acting as RAs and doing
validation of domain control/ownership. However such RAs are acting as
agents of the CA, and the CA has ultimate responsibility for ensuring
that the RAs act to uphold the claims made in the CA's published CPS.
As for attestation, in a typical WebTrust for CAs audit the management
of the CA asserts that the CA is operating in accordance with the CPS,
including whatever claims are made in the CPS vis-a-vis subscriber
verification. For example, for Comodo these assertions are in the
following document:
http://www.comodo.com/repository/non_ev_management_assertions.pdf
including the assertion that (during the period of the audit) Comodo
"maintained effective controls to provide reasonable assurance that ...
subscriber information was properly authenticated", albeit with a
disclaimer that "There are inherent limitations in any controls,
including the possibility of human error and the circumvention or
overriding of controls. Accordingly, even effective controls can provide
only reasonable assurance ...."
(Incidentally, this is fairly standard language for a WebTrust for CAs
audit. All the WebTrust management assertions that I've read look like
this.)
The WebTrust for CAs auditors then examine and test these assertions in
various ways, and make their own attestation. For example in the case of
Comodo they stated in the relevant WebTrust for CAs report
https://cert.webtrust.org/ViewSeal?id=798
that "In our opinion for the period 1st April 2008 through to 31st July
2008, the Company’s Directors’ assertion, as set forth in the first
paragraph, is fairly stated in all material respects, based on the
AICPA/CICA WebTrust for Certification Authorities Criteria", although
there's also a disclaimer: "Because of inherent limitations in controls,
errors or fraud may occur and not be detected" (and also things may
change in future).
(Again, this is all pretty standard for a WebTrust for CAs audit report.)
So, in theory at least a WebTrust for CAs audit is supposed to confirm
management's assertions that verification of subscriber information is
being done properly, including any verifications done by third-party RAs
acting on behalf of the CA. In practice such confirmation is not
necessarily based on doing detailed investigation of each and every RA;
it might instead be based on examination of the overall controls put in
place to regulate RAs, combined with any internal audits that CA
managers might have done for RAs. In this respect I suspect that what
Comodo has been and is doing is similar to what other CAs with RAs do.
> The policy currently does not appear to handle the scenario where a CA
> delegates the verification job to an external entity. So it's unclear
> whether it's "forbidden" or "allowed if the external entity has
> received equivalent attestation of their conformance".
When we created the policy I was well aware of the existence of RAs and
of the possibility that CAs might outsource functions like domain
validtion to RAs. Whether or not this is clear from the policy (and I
guess it's not, since you and others are asking about this), my
intention was certainly that the activities of RAs were considered to be
encompassed within the overall activities of CAs, and that the policy's
requirement for CAs to validate domains left open the possibility that
this might be done by RAs acting as agents of CAs.
So, to repeat, I don't think the key issue here is whether CAs should or
should not be allowed to delegate domain validation to RAs. The question
(e.g., as in the case of Comodo and Certstar) is rather whether
particular RAs are doing this properly, and if it's not done properly,
whether the failures on the part of RAs represent isolated incidents or
whether they indicate a systemic failure of the CA to properly oversee
its RAs.
Frank
P.S. I'm out of town on vacation this week visiting family. I plan to
continue working on this issue and responding to messages in this
newsgroup, but you shouldn't expect an immediate response if you post
something or email me. I'm going to try to post a summary of where
things are either tonight or tomorrow morning.
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg
> When we created the policy I was well aware of the existence of RAs and
> of the possibility that CAs might outsource functions like domain
> validtion to RAs. Whether or not this is clear from the policy (and I
> guess it's not, since you and others are asking about this), my
> intention was certainly that the activities of RAs were considered to be
> encompassed within the overall activities of CAs, and that the policy's
> requirement for CAs to validate domains left open the possibility that
> this might be done by RAs acting as agents of CAs.
Incidentally we've not long ago agreed that we'll have to look at the
various RAs scenarios more closely in the future. There is a similarity
between externally controlled sub CAs, RAs and apparently also
"Resellers", where resellers actually act as RAs (according to Comodo's
CPS).
As in the case of various other issues listed in the "Problematic
Practices" pages [1], RAs will have to be defined more clearly as well.
Something which was supposed to be obvious apparently isn't.
As such, there are many common practices in this industry which are not
up to today's requirements and/or the race to the bottom require clear
regulation, something which previously maybe wasn't required. My
insistence on detecting, declaring and defining them previously always
had the goal to prevent possible damage and with it make PKI and digital
certificates irrelevant for the Internet. Therefore, common practice by
CAs never must be the criteria for sound and responsible requirements.
> So, to repeat, I don't think the key issue here is whether CAs should or
> should not be allowed to delegate domain validation to RAs. The question
> (e.g., as in the case of Comodo and Certstar) is rather whether
> particular RAs are doing this properly, and if it's not done properly,
> whether the failures on the part of RAs represent isolated incidents or
> whether they indicate a systemic failure of the CA to properly oversee
> its RAs.
It's the inconvenience to have to confirm an email ping or other
automated control verification by the subscriber which leads some CAs to
circumvent it with "agreement by checkbox" validation. This results in
an undue risk (being it just by human error and not intend or
negligence) and unfair competition as well. I'd never outsource domain
name validation to such identities like RAs and Resellers, not even for
intermediate CAs. RAs may perform identity or organization validation
sometimes more efficient than the CA due to local proximity, however
technical requirements such as domain or email have no justification to
be outsourced. Otherwise also physical and local controls and
requirements will have to be added to the RA infrastructure, which makes
it even more complicated.
[1] http://wiki.mozilla.org/CA:Problematic_Practices
Kyle Hamilton
Wasn't it a lack of regulation that managed to put the US and the rest
of the world into this economic semi-meltdown that we're in? Wasn't
it untrustworthy auditing (from Arthur Anderson) that led to the
implementation of Sarbanes-Oxley and such?
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Ian G
> This comment is likely going to be viewed as being in poor taste...
It is rather on point. It is also likely to be viewed as poor taste :)
> Wasn't it a lack of regulation that managed to put the US and the rest
> of the world into this economic semi-meltdown that we're in? Wasn't
> it untrustworthy auditing (from Arthur Anderson) that led to the
> implementation of Sarbanes-Oxley and such?
Enron was an early harbinger of over-dependence on simplistic
signalling, and a consequent careful manipulation of that signalling by
the players. Which lead to the failure of Arthur Anderson as a
conspirator in that manipulation ("are we properly following our
document destruction policy?").
Which then led to a call by the ignorant and the insiders, both, for
increased regulation. Hello Sarbanes-Oxley. You will never find
auditors willing to resist more complicated requirements for auditing,
and you will not find the public resisting more calls for more checks.
However, Sarbanes-Oxley (and about 6 others) added more complexity and
further obscured signals, when the problem was already too much
complexity and too little value in signals and too little effort by
relying parties. (I dissemble here, for brevity.)
According to my (very brief) checking, not one auditor signalled even
one failure in the current meltdown. Yet, all of the failures were
basic, finance-101 mistakes, easily described. Go figure...
So, whatever. The USA is about to enter an enhanced, increased burden
of regulation, in a time where we have just basically proved that the
last round of regulation obscured the basic problems, and did nothing
but increase the costs (basically, double, and the IPO market moved to
London).
It is *extremely helpful* to watch the world of regulated finance, when
considering the world of CAs. The structure is basically the same, the
only difference is that when we make a mistake, nobody notices; when
they make a mistake, a million pensions are wiped out.
iang
Ben Bucksch
> So, in theory at least a WebTrust for CAs audit is supposed to confirm
> management's assertions that verification of subscriber information is
> being done properly, including any verifications done by third-party
> RAs acting on behalf of the CA. In practice such confirmation is not
> necessarily based on doing detailed investigation of each and every
> RA; it might instead be based on examination of the overall controls
> put in place to regulate RAs
So, who actually controls that verifications are done at all? I mean,
paper is nice, I can claim and write all I want, and not actually do it,
but I thought the point of the audit was to *check* and control and
ensure that the processes are *actually* carried out as specified. What
else is an audit for? To get the CEO's signature that he claims to do
what he wrote, or what? We don't need an audit for that, a scan of his
signature would do.
Verifications are the core of a CA's business, and the audit is there to
control the CA's *actual* operations by an *independent* party, because
it's exactly not sufficient to just trust the CA to do things properly,
or to trust the CA that it trusts its RA, without ever actually checking it.
Eddy Nigg
> So, who actually controls that verifications are done at all? I mean,
> paper is nice, I can claim and write all I want, and not actually do it,
> but I thought the point of the audit was to *check* and control and
> ensure that the processes are *actually* carried out as specified. What
> else is an audit for? To get the CEO's signature that he claims to do
> what he wrote, or what? We don't need an audit for that, a scan of his
> signature would do.
>
> Verifications are the core of a CA's business, and the audit is there to
> control the CA's *actual* operations by an *independent* party, because
> it's exactly not sufficient to just trust the CA to do things properly,
> or to trust the CA that it trusts its RA, without ever actually checking
> it.
Apparently the auditors found a binding agreement sufficient enough for
resellers to perform those validations. This, in addition to random
checks and samples performed by the CA. The audit mostly confirms what
the CP/CPS claims.
This is most likely not what the Mozilla CA Policy envisioned and
requires. As a matter of fact, we could have known about it and
considered it insufficient during Comodo's review last spring.
Unfortunately even if it came up in some form, it drowned by the other
concerns which were on the table. We could re-read those discussions in
order to find out.
Eddy Nigg
>
> This is most likely not what the Mozilla CA Policy envisioned and
> requires. As a matter of fact, we could have known about it and
> considered it insufficient during Comodo's review last spring.
> Unfortunately even if it came up in some form, it drowned by the other
> concerns which were on the table. We could re-read those discussions in
> order to find out.
>
Isn't this interesting?
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/fdbb981d7dcd678f
Kai Engert
Yes
Eddy Nigg
I edited the Problematic Practices page and added
https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties
It might need some improvement. Frank, can you review? This will affect
obviously only future inclusion requests and is not a resolution to the
current issue and other CAs which might be affected.
Ian G
> I edited the Problematic Practices page and added
> https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties
My comment: it is written like a requirement, using MUST. This is
confusing, and it bypasses the process for change of policy.
iang
Eddy Nigg
> On 30/12/08 20:41, Eddy Nigg wrote:
>
>> I edited the Problematic Practices page and added
>> https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties
>>
>
>
> My comment: it is written like a requirement, using MUST. This is
> confusing, and it bypasses the process for change of policy.
>
MUST was intentional. It's not policy, but anything in the problematic
practices may be policy one day :-)
Frank Hecker
> I edited the Problematic Practices page and added
> https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties
>
> It might need some improvement. Frank, can you review? This will affect
> obviously only future inclusion requests and is not a resolution to the
> current issue and other CAs which might be affected.
I'm not totally happy with that language, but I'm supposed to be on
vacation with my family and don't have time to rewrite it right now.
I will say however that as a general matter I think it is good CA
practice to have standard procedures and associated IT systems for
verifying domain ownership/control and email account ownership/control,
and to have resellers either use the CA's own systems or use CA-approved
equivalents. (For example, reseller A might use the CA's own instances
of such systems, while reseller B might run the same software but on its
own systems.)
One reason I say this is "good CA practice" as opposed to a mandatory
requirement, is because of cases like enterprise PKIs where the
enterprises might act as RAs and do verification based on their own
internal systems (e.g., HR databases).
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg
>
> One reason I say this is "good CA practice" as opposed to a mandatory
> requirement, is because of cases like enterprise PKIs where the
> enterprises might act as RAs and do verification based on their own
> internal systems (e.g., HR databases).
>
I think this is what we want to avoid actually, don't we? Or perhaps we
could leave it as is, since the Mozilla CA Policy is actually clear in
relation to validations.
Incidentally I had previously a problem with Microsoft's policy to
disallowing certain enterprise scenarios, hereby it might make some
sense. But even then, the proposal would actually call for an
attestation, whereas the attestation itself hasn't been defined yet. I
think this is what also Kay proposed.
Now, we must not forget what an RA is, what a reseller is and what an
enterprise scenario is. RAs are interesting for the verification and
validation of identity documents in person for example. Or organizations
for that matter. Since RAs always have to interact with the CA at some
point, I believe incorporating domain/email validation is more than
easy. Even in enterprise settings is that possible.
Resellers should not perform any validation procedures at all. They
should sell certificates and not be involved with any of the technical
sides of he procedures. Reseller != RA.
As such, I believe that it would be good to improve the Mozilla CA
Policy and work towards better definitions and requirements. Even if the
validation aspect is clearly defined and *required*, we might exclude
certain practices outright. There are of course other points I'd like to
have improved.
Kyle Hamilton
<hec...@mozillafoundation.org> wrote:
> I will say however that as a general matter I think it is good CA practice
> to have standard procedures and associated IT systems for verifying domain
> ownership/control and email account ownership/control, and to have resellers
> either use the CA's own systems or use CA-approved equivalents. (For
> example, reseller A might use the CA's own instances of such systems, while
> reseller B might run the same software but on its own systems.)
>
> One reason I say this is "good CA practice" as opposed to a mandatory
> requirement, is because of cases like enterprise PKIs where the enterprises
> might act as RAs and do verification based on their own internal systems
> (e.g., HR databases).
Ummm... has an enterprise PKI ever been included in Mozilla?
Also, who's to say that domain ownership/control and email account
ownership/control aren't authoritatively evidenced by internal systems
(technically, all someone external can do is verify that someone has
access to the the machine pointed to by the DNS, or can access the
email, both of which rely on the capability of the actual owner to
adequately secure their systems -- but if a policy is in place that
only employees are authorized to have 'control' access to systems or
email accounts within the domain then that business evidence is more
authoritative.
(In any case, enterprises that act as RAs are unlikely to be acting as
RAs for domain-validation, they're much more likely to be operating as
RAs for "entities authorized to operate on the enterprise's behalf".
Which is a perfectly legitimate thing for them to do, as long as the
bounds of trust are carefully defined and preserved through the client
user interfaces. which they never are.)
-Kyle H
Rob Stradling
entity may choose (and be approved) to perform both of these roles.
I fully agree that the Reseller role "should not perform any validation
procedures at all".
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Frank Hecker
> Ummm... has an enterprise PKI ever been included in Mozilla?
Sorry, I wasn't being clear here. I'm not referring to enterprises that
have their own root CAs. I was referring to schemes where enterprises
work through CAs like VeriSign to issue certificates to their own
employees, servers, etc. IIRC in a number of these schemes the CA is
responsible for actually issuing the certificates but the validation is
done by the enterprise. (For example, the CA might provide a web-based
interface by which authorized representatives of the enterprise can
submit previously-validated CSRs to the CA, and get back certificates in
return.) In these cases the enterprises are essentially acting as RAs.
Eddy Nigg
> employees, servers, etc. IIRC in a number of these schemes the CA is
> responsible for actually issuing the certificates but the validation is
> done by the enterprise. (For example, the CA might provide a web-based
> interface by which authorized representatives of the enterprise can
> submit previously-validated CSRs to the CA, and get back certificates in
> return.) In these cases the enterprises are essentially acting as RAs.
>
And on the same token, the CA could perform the validation of the domain
through said web interface. I'd see exception for whole IP blocks and
batch submissions, whereas the IP block ownership and details of the
batch submission have been validated by the CA manually beforehand.
The enterprise scenario doesn't present a situation which would justify
exemption of domain validation requirement. As per proposal it still
would be possible though with appropriate attestation about the RAs
capabilities and controls in place.
Eddy Nigg
> Yes, Reseller and RA are 2 distinct roles. However, in some cases, a single
> entity may choose (and be approved) to perform both of these roles.
>
> I fully agree that the Reseller role "should not perform any validation
> procedures at all".
>
Robin, could you provide some clarifications and your opinion concerning
the post I made titled "Facts about Comodo Resellers and RAs" in
particular in relation to the CP and CP statements here:
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/416aa6f5b5610ccf
ro...@comodo.com
> Robin, could you provide some clarifications and your opinion concerning
> the post I made titled "Facts about Comodo Resellers and RAs" in
> particular in relation to the CP and CP statements here:
>
> http://groups.google.com/group/mozilla.dev.tech.crypto/msg/416aa6f5b5610ccf
Eddy,
That thread has a lot going on and I don't propose to try to
address it all. However, I will address your reading of our CPS in an
attempt to bring some degree of clarity.
If I correctly understood your referenced post, you asserted that:
1) Comodo outsources validation to its (non RA) resellers.
2) That the outsourcing of validation to anyone is in direct conflict
with section 4.2.7 of the PositiveSSL CPS.
#1 is incorrect.
You refer to section 1.10.2 of the main CPS as evidence for your
assertion, but that section specifically refers to our main RA class
of partners, which we denominate "Web Host Resellers".
#2 is also incorrect.
The PositiveSSL CPS is an addendum to the main CPS and should be
considered in conjunction with the main CPS and its other addenda.
You refer to section 4.2.7 of the PositiveSSL CPS in particular,
noting that is says ".. Comodo checks that the Subscriber has control
over the Domain name ..".
But consider it together with the rest of the main CPS. Section 4.2.7
(of the PositiveSSL CPS) is a new subsection to be added to section
4.2 "Application Validation" in the main CPS. Section 4.2 as a whole
(in the main CPS) talks throughout of "Comodo checks..", "Comodo
validates..", etc, but note also the preceeding sections of the main
CPS, 4.1, and 4.1.1 which set out exactly who is to do the
validation. Sections 4.1 and 4.1.1 make clear who is to do the
certificate application processing. Taking sections 4.1 and 4.1.1
into consideration makes it clear that the validation to be performed
in section 4.2 may, in fact, be done either by Comodo or by its
appointed RAs.
Sections 1.10, 2.2, 2.8, 3.9.3, 4.13.1, 5.15, 5.18, and 5.26 of the
main CPS also further serve to define the interaction of RAs in the
processing of certificate applications.
Regards
Robin Alden
Comodo
Eddy Nigg
> That thread has a lot going on and I don't propose to try to
> address it all. However, I will address your reading of our CPS in an
> attempt to bring some degree of clarity.
> If I correctly understood your referenced post, you asserted that:
> 1) Comodo outsources validation to its (non RA) resellers.
> 2) That the outsourcing of validation to anyone is in direct conflict
> with section 4.2.7 of the PositiveSSL CPS.
Hi Robin,
Thanks for your reply. In order to understand this a bit better, let me
challenge and ask you some more questions.
>
> #1 is incorrect.
> You refer to section 1.10.2 of the main CPS as evidence for your
> assertion, but that section specifically refers to our main RA class
> of partners, which we denominate "Web Host Resellers".
OK, therefore "Web Host Resellers" are actually RAs. In the section
1.10.2 it says clearly:
"The Web Host Reseller Partner is obliged to conduct validation in
accordance with the validation guidelines and agrees via an online
process (checking the “I have sufficiently validated this application”
checkbox when applying for a Certificate) that sufficient validation has
taken place prior to issuing a certificate."
So what you are saying is, that Web Host Resellers are actually RAs
according to the CPS and are conducting the validations. How are those
validations usually done - as per below? Which training do they receive
usually? How do you select those RAs? Which subscriber agreement must be
presented by the RA to the subscriber?
Section 4.2 deals with application validation and in particular 4.2.2
explicitly mentions again (as also in the PositiveSSL CPS):
"Reviewing domain name ownership records publicly available through
Internet approved global domain registrars and using generic e-mails
which ordinarily are only available to person(s) controlling the domain
name administration, for example, webmaster@ . . ., postmaster@ . . .,
admin@; or
Requesting documentation that verifies control of the domain."
However it's not Comodo which performs those validations you say, but
the RA (Web Host Reseller). Why isn't Comodo doing it through the same
web interfaces available to the resellers? How exactly are documentation
verified for control validation? How are you retaining evidence about
the performed validations? How did the auditor review those validations?
> Sections 1.10, 2.2, 2.8, 3.9.3, 4.13.1, 5.15, 5.18, and 5.26 of the
> main CPS also further serve to define the interaction of RAs in the
> processing of certificate applications.
What are the penalties in case an RA doesn't upheld the CPS and as per
section 5.18?
And a last question, where exactly are resellers handled in your CP/CPS?
Thanks so far...
Ben Bucksch
I think this scenario is different, assuming it's implemented properly:
The company would only be able to approve web server certs for their
domain, i.e. it's like a wildcard cert. More importantly, they'd verify
S/MIME email certs, but again only within their domain.
I would consider this to be secure.
wolfgang...@t-systems.com
wrote:
> Eddy Nigg wrote:
> > I edited the Problematic Practices page and added
>
> > It might need some improvement. Frank, can you review? This will affect
> > obviously only future inclusion requests and is not a resolution to the
> > current issue and other CAs which might be affected.
>
> I'm not totally happy with that language, but I'm supposed to be on
> vacation with my family and don't have time to rewrite it right now.
>
> I will say however that as a general matter I think it is good CA
> practice to have standard procedures and associated IT systems for
> verifying domain ownership/control and email account ownership/control,
> and to have resellers either use the CA's own systems or use CA-approved
> equivalents. (For example, reseller A might use the CA's own instances
> of such systems, while reseller B might run the same software but on its
> own systems.)
>
> One reason I say this is "good CA practice" as opposed to a mandatory
> requirement, is because of cases like enterprise PKIs where the
> enterprises might act as RAs and do verification based on their own
> internal systems (e.g., HR databases).
>
> Frank
>
> --
> Frank Hecker
> hec...@mozillafoundation.org
Frank,
The Comodo topic has once again sparked a fierce discussion about the
validity of certificates, how appropriate levels of security and trust
should look like and what to do to establish them.
Since we expect this discussion to have "some" impact on the
evaluation of requests for Root integration (the current schedule
appears not to be valid anymore) we wonder whether you can tell us
something about your plans to work on that topic and what does that
mean for all pending requests for integration?!
Kind regards
Wolfgang Pietrus
Eddy Nigg
>
> Frank,
>
> The Comodo topic has once again sparked a fierce discussion about the
> validity of certificates, how appropriate levels of security and trust
> should look like and what to do to establish them.
>
> Since we expect this discussion to have "some" impact on the
> evaluation of requests for Root integration (the current schedule
> appears not to be valid anymore) we wonder whether you can tell us
> something about your plans to work on that topic and what does that
> mean for all pending requests for integration?!
>
Wolfgang, does your CA rely on RAs? It was my understanding IIRC that it
is not the case. If the issues raised previously were addressed by you
and the bug updated accordingly, than I don't think there should be any
delay in continuing the schedule including the inclusion request of your CA.
Frank, is there any reason why no inclusions (and relevant comments
periods) aren't processed according to schedule? Is there any resolution
pending which prevents us from doing so?
wolfgang...@t-systems.com
> On 01/12/2009 11:27 AM, wolfgang.piet...@t-systems.com:
>
>
>
> > Frank,
>
> > The Comodo topic has once again sparked a fierce discussion about the
> > validity of certificates, how appropriate levels of security and trust
> > should look like and what to do to establish them.
>
> > Since we expect this discussion to have "some" impact on the
> > evaluation of requests for Root integration (the current schedule
> > appears not to be valid anymore) we wonder whether you can tell us
> > something about your plans to work on that topic and what does that
> > mean for all pending requests for integration?!
>
> Wolfgang, does your CA rely on RAs? It was my understanding IIRC that it
> is not the case. If the issues raised previously were addressed by you
> and the bug updated accordingly, than I don't think there should be any
> delay in continuing the schedule including the inclusion request of your CA.
Eddy, no we don't rely on external RAs (for services under the root we
made our request for).
Still we see that this discussion potentially will result in some work
to change policies. If this is so, will requests be processed anyway
during that time?
>
> Frank, is there any reason why no inclusions (and relevant comments
> periods) aren't processed according to schedule? Is there any resolution
> pending which prevents us from doing so?
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
Regards
Wolfgang Pietrus