Re: Trivial PKI Question

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

Chris,
Thanx for your answers.  Here are some replies.

>> Question:  How should the identity as expressed in the document
>> relate to the identity as expressed by the signer's certificate?

>There may be no relationship at all. Their identity as a private
>individual may be irrelevant, subjugated by their role as the person
>in Big Buyer Corp who authorizes such payments digitally. Also,
>the creator of the order may not be the person who is authorized
>to digitally sign it.

This "works" in the paper-world as people are "flexible".  Automated
receivers OTOH are very unlikely to be able handle arbitrary schemes.
Using a business system as a mid-tier eliminates the need to move the
arbitrary-ness of the paper-world into the e-world.

Taken from another field:  I'm pretty sure that no e-government program
will ever consider accepting anything but a one-to-one match between
a citizen's ID (as they see it) and what a citizen certificate contains.  But
they also have to build special purpose RP software (due to the dys-
functional X.500 naming system) in order to do that.  In addition to
requiring CAs to follow their _hard-coded_ naming conventions.

<snip>

> The two are likely to contain different certificatePolicies.

<CertificatePolicyRant>
It is interesting to note that CPSs are frequently mentioned in this context
in spite of the fact that none of the major crypto-packages (Windows
and Java) offers any way to specify CPSs as a part of a CA trust acceptance
process.  The reason for this is simple: Computers don't understand
legal matters and CPSs are deployment-wise anything but standardized.
Peter Gutman's term "Kitchen sink extensions" is a fair description of
the value of CPSs for practical purposes.  Do "SysAdmins" ever
bother about the CPS of their VeriSign web-server certificates?
My Thawt web-server cert does not even have a CPS extension and
I haven't missed it that much.  CPSs were designed by lawyers for
lawyers.  But lawyers do not run e-business systems, write application
software packages, or know how to handle a Java keystore.
</CertificatePolicyRant>

<snip>

>> To create a foundation for more frictionless PKI-secured e-business,
>> I think that there *long-term* should be a one-to-one mapping between
>> [basic] business message identities and certificate identities.

>A kind of time-stamped intersection entity that comes between person
>and process ? A signed transaction ? Isn't this what Notaries were
>supposed to be for ?

Before PKI (I mean as things are today...), business systems authenticated
outgoing messages using various techniques (leased lines, VPNs, shared
secrets).  Why should this time-proven principle be changed due to the
introduction of PKI?

Although some believe this is "unethical", even the EU are now actively
discussing how automated processes featuring legal-entity-only certificates
and keys can legally sign invoices etc.  Several countries including Sweden,
now fully support this idea.   I.e. there is no point in making a one-to-one
translation of the paper-world into the e-world, as then you only inherit
the disadvantages of the paper-world, as well as being unable to exploit
the possibilities offered by the e-world.  However, it took the
EU ten years (!), to realize that "digital signatures" have many other
qualities, outside of replacing the hardly readable ink-blobs that you
occasionally have to put on various papers.  The majority of "manual
signatures" are BTW not made with more "intent" and "consideration",
than when hitting the OK-button of a typical business application!

<snip>

As as final note, I would like to express a whish that the S/MIME and
PKIX WGs start looking a bit above the ASN.1-level, to also address
deployment issues and shrink-wrap SW support.  There must be more than
one reason why practically no app outside of e-mail offer built-in PKI support.

Regards
Anders R