[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

automated processing of generalized certificates

I like many aspects of Carl's arguments in
        http://www.clark.net/pub/cme/html/cert.html

and I would like to expand on the idea of automated processing
of certificates.

I see a need for both free-form and automatable certificates, and
I think they should be distinguished:
        Meaning-Inline: <arbitrary text>
        Meaning-Registered: <IANA-registered policy id>

The value associated with a Meaning-Inline tag could be anything that
you wanted to communicate.  Restricting it to text would aid
implementation, but allowing for multiple languages seems
important (I like the Unicode idea if the implementation can
be done simply, e.g. by presenting hard-to-represent Unicode
characters as hex values.  PICS is tentatively using Unicode/UTF-7:
draft-pics-services-00.txt)

The Meaning-Registered tag would introduce an id much like a
MIME type.  The "major" type would indicate some of the
semantics, and the minor (perhaps multi-level?) type would get
more specific, and imply a full set of semantics registered
with IANA, for example.  This would have several benefits:
        Allow higher-level semantics to be explicit - e.g. chaining and CRLs
        Allow for multi-lingual descriptions of semantics

To allow multi-media objects to be certified, there could be
another tag explicitly or implicitly referenced by one of
the Meaning-* tags.

I think these two meaning fields should be mutually exclusive.
Otherwise people will try to fool others by making the
Meaning-Inline contradict the Meaning-Registered.


We need to identify the special kinds of high-level semantics
that need to be understood by clients.  One is CRLs.

Certificate Revocation Lists (CRLs) can introduce lots of complexity,
but I suspect will they will be important for some kinds of
certificates.  We should either have a tag (Revocation-Method: ?) or
an attribute of the Meaning-Registered tag which requires compliant
clients to either use one of a specified variety of CRL searches, or
reject or require manual intervention before using the certificate.
Perhaps we need levels of implementation compliance, and this could be
optional for the simple clients.  Or some day maybe we'll just allow
the revocation searching code to be downloaded as a signed Java
application....

        Examples: security clearance, marriage certification,
        driver's license, deed to property, 


Another high-level sort of semantics we need to capture is the
rules for "chaining" of certificates.  E.g. PGP allows chaining of
email identity certs.  I've done a study of the 'web of trust'
that is generated by that, available at
        http://bcn.boulder.co.us/~neal/pgpstat/

Rules like which types of certificates (Meaning-Registered major
type?) can chain to which other certificates, perhaps how long a chain
can be, the need for multiple independent paths, etc. might be
specified or left to user specification.


Finally, would the WWW extension mechanism be useful here?  Perhaps
have a presentation by the W3C folks on that at the IETF?

Neal.McBurnett@att.com  503-331-5795    Portland/Denver
Bell Labs Innovations for Lucent Technologies
        Formerly AT&T's systems and technology business
http://bcn.boulder.co.us/~neal/  (with PGP key)