Re: [IETF-PKIX] Critical extensions and Policy OIDs

[Phillip M Hallam-Baker <pbaker@xxxxxxxxxxxx>]

Bob writes:

>I haven't done a recent search, but to the best of my knowledge, only
>VeriSign has actually published a Certification Practice Statement, and I'm
>not sure whether they intend to publish a separate Policy document in
>addition, or not.

Belsign certainly has (they licensed the VeriSign CPS).

>I'm not aware of any CAs that are actually including a policy OID in their
>certificates to date -- if someone does know of some examples it might be
>quite helpful -- maybe even a defacto practice.

Signet in Australia does. I would assume most would plan to.

>Corporate lawyers being what they are, I would expect that a Policy issued
>by a CA would be long on defenses against any possible liability on their
>part, and rather short on any possible defenses on the part of the
>subscriber or subject, unless market demands eventually dictate such
>language, or unless a particular strong customer shows up with sufficient
>leverage to force particular language (same thing, I guess.)

Accepting liability is a perfectly reasonable business decision,
the purpose of lawyers is to allow liability to be predicted and
understood, not to eliminate it.

VeriSign is issuing insurance with its certificates which both
provides assurance to certain parties that the certificate can
be relied upon and controls liability. This does not appear
to meet your expectations.


>What still isn't clear is the extent to which a policy OID constitutes a
>representation or agreement between the subscriber and the CA, and/or the
>extent to which such a representation by the subscriber can be relied on by
>a relying party.

That would depend on the nature of the agreement,
various national laws and a body of precedent and
statute yet to be established.

>It seems somewhat unlikely that a CA would actually assume responsibility
of
>the subscriber's use of the issued certs -- at best they would take
>responsibility for the correct identification of the subscriber and the
>binding of the subscriber's public key to the name or other attributes, but
>they aren't about to get into the underwriting business -- at least under
>present business model's.

I would guess that if there were a 'per use' liability
connected with a cert that there would have to be a
'per use' charging model in most cases but I would
not make a stronger statement.

A bank issuing SET certificates is essentially a CA
that assumes responsibility for the subscribers use
of the cert - this is profitable since every transaction
carries insurance.

            Phill