On 27/12/08 04:47, Paul C. Bryan wrote:
On Dec 26, 5:38 pm, Nelson B Bolyard<nel...@bolyard.me> wrote:
Clearly several participants in this discussion were surprised that a CA would
delegate the duty of validating domain control to an RA, and some opined
that a CA ought to perform that duty itself.
I certainly fall in that category.
Curious. I thought it was the standard business model of many CAs to
outsource some or all of the functions to the reseller or customer.
Indeed, this is the "Verisign buyout model"; outsource something new,
get huge, get bought out by Verisign.
Has anyone done a survey about how this is done in all CAs?
I'm not convinced that's necessary, but it certainly does seem that a CA firm
ought to be prepared to deal with the possibility that an RA makes a
(potentially
big) mistake without sacrificing the CA firm's entire business. The challenge,
in
the event of an RA error, is to restore/maintain confidence in the integrity
of the CA's PKI overall, while mitigating the potential damage from dubious
enrollments.
I think I can boil down my concern in this statement:
When trust is being established in a certification authority, trust is
explicitly being placed in its operational practices. It is not being
trusted in its ability to place trust in turn in whomever it may
decide to outsource its operations. By allowing arbitrary parties to
perform critical RA activities (such as DV) the CA is attempting to
extend its operations beyond that which was originally judged.
Hold on, that is leaping to far...
All businesses place their all trust in "outsourced" entites. They are
called "employees" and "suppliers" and various other names. This is normal.
However, when a contract is signed or an agreement otherwise reached
(and the latter is more the case here), the responsibility for the
agreement remains in the primary party. Again, this is normal.
Nothing has changed here in the CA business. The CA has reached
agreement on its offered CPS, and the assumptions should hold:
the CPS describes what it does.
the CA takes the responsibility.
It doesn't matter in business principle whether it outsources a function
to a reseller, to its employees or to the government.
Is there a criteria anywhere that says or implies "The CA has not
outsourced critical function X to an external agent?" Can anyone recall
such a statment? This would be a controversial criteria because we know
that a popular incentive is to generate opportunities for business revenues.
So, I would like to suggest that Comodo consider modifying its practices
somewhat, to reduce the mismatch of scope between subordinate CAs and RAs.
I suggest that Comodo operate a separate subordinate CA for each RA to
whom Comodo has delegated validation duties. I suggest that a new
subordinate CA be created for each such RA, and that all new certs issued
for those RAs be issued from those new single-RA CAs. I am aware of at
least one other commercial CA that operates that way, operating a separate
subordinate CA for each RA to whom they have delegated validation duties.
I believe that is a sound way to minimize the "collateral damage" that
might need to be inflicted, even temporarily, to restore/maintain PKI
integrity in the event of a breach.
I believe your suggestion is valid. This seems to fit s. 13 of the
Mozilla CA Certificate policy: "... we recommend that CAs consider
using separate root CA certificates with separate public keys (or
separate intermediate CA certificates with separate public keys under
a single root) when issuing certificates according to different
Certificate Policies, so that we or others may selectively enable or
disable acceptance of certificates issued according to a particular
policy, or may otherwise treat such certificates differently ..."
I believe another valid option would be for the CA to incorporate key
RA duties, namely domain verification. The CA can still have resellers
that initiate registration and collect information. Verification would
remain within the operations of that which is judged in the CA's
conformance to policy.
As advice this would remain fine and standard. However trying to create
some sort of restriction on how these things are done is likely to close
of opportunities to do it better another way, in the future.
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
