Subject: surrogate/agent addenda (long)

From: [email-masked]
Date: Fri, 14 Feb 2003 15:02:02 -0700

I claim that I can model an operational environment in terms of entities
and permissions (for simplification attributes are also modeled as a kind
of permission).

Registry is defined to be the method that an operatinal environment uses to
map entities to permissions. A registry may be a single operational thing
or it may be made up multiple things both explicit and implicit.

Digital signatures and public keys are used to authenticate entities to the
operational environment. The operatinnal environment uses public keys in
the registry to represent entities (since they are unique to the
authentication of the entity). The mapping between public keys and
permissions is a function of the registry entry.

CA/PKI further extends the kinds of permissions to "delagation". A CA
entity/public key is given the permission of delegation.

A CA uses its own registry to provide a mapping between entities, public
keys, and permissions. A CA then signs a static, stale copy of some of the
fields in its registry and calls it a certificate.

An operational environment can authenticate delegated permissions from a
signed certificate by using the public key of a CA entity from its own
registry. Just for some convention I'll call delegation entities:
surrogates/agents. Full blown PKI defines the possibility of a multi-level
delegation as a trust hierarchy.

So my repeated assertion is that if the operational environment accesses a
surrogate/agent registry entry (local, remote, online, etc) then correspond
surrogate/agenty certificate can be shown to beredundant and superfluous.

So, I've managed to explain this redundant and superfluous characteristic
in a number of different ways:

1) a registry entry can contain anything that a certificate can contain,
therefor all fields that can occur in a certificate can also be placed in a
surrogate/agent registry entry. Also, for every field that can exist in a
certificate can be placed in a registry entry. When all fields from a
certificate are placed in a registry entry, the certificate can be
compressed to zero bytes.  These certificates aren't actually redundant and
superfluous, they are just zero bytes.

2) the creation of a registry entry for a surrogate/agent is equivalent to
a registration authority business process. anything that is done during a
CA's RA process can be done during the creation of a registry entry for the
surrogate/agent. If necessary, this can be viewed as caching the
certificate in the surrogate/agent registry entry. Then while the
certificate isn't strictly redundant and superfluous,
any transmission of the certificate is redundant and superfluous since the
operational environment already has access to the cached entry. This is
especially useful when the inclusion of a certificate in a transmission
represents a painful bloating of the total transmission size.

3) when there is a directly accessable registry entry (local, remote,
online, etc) for a surrogate/agent, then the certificate may just represent
information indirection .... somewhat like DNS system mapping of hostname
to ip-address. the registry entry contains some value that can be matched
to a field in the certificate. This provides a indirection mapping between
the permissions in the registry entry and the entity's public key in the
certificate (authenticated & deligated by the CA signatures and the CA
entry in a directly accessable registry entry). However, since nay value
that can occur in a certificate can also be placed in the registry entry,
the public key from certificate entry can be directly placed in the
surrogate/agent registry entry, eliminating the indirection provided by the
certificate and making the use of the certificate redundant and superfluous
.

4) an operational environment may require direct access to a
surrogate/agent registry entry (local, remote, online, etc) because of
permissions expressed in terms of aggregation information (information that
is maintained in the registry entry that represents information aggregation
and is a difficult paradigm for a static, stale certificate) or permissions
expressed in terms of real-time or near real-time information (again
difficult paradigm for a static, stale certificate).

5) If a static, stale certificate provides an identifier that is used to
index a surrogate/agent registry entry (local, remote, online, etc) then it
is also possible to include the same identifier as part of the message
digitally signed by the surrogate/agent.  As before, such a surrogate/agent
registry entry can include anything that a certificate can include,
including the public key of the surrogate/agent. By directly placing the
public key in the surrogate/agent registry entry, and directly accessing
the surrogate/agent registry entry using an identifier from the signed
message, then the signed message
can be authenticated using the public key from the directly accessed
surrogate/agent registry entry. The directly accessed surrogate/agent
registry entry can contain any other field that might exist in the
certificate, including all possible permission values. Since the digital
signed message can be authenticated without having to resort to the
certificate and since the directly accessed surrogate/agent registry entry
can contain any field that a certificate can contain, the static, stale
certificate transmitted as part of the message is redundant and superfluous
.

The simplest scenario for a static, stale certificate is in an operational
environment that only accesses a CA delegation registry entries and
permissions are solely established on the basis of the contents of the CA
registry entry and the contents of the certificate. This is the employee
certificate that is used for door entry. The door entry operational
environment only contains the public key of one or more CAs. The door is
opened purely based on being able to validate the CA's signature on the
certificate and then validate the employee's signature using the public key
in the certificate. For opening the door, there is no recourse to any
employee specific entry. This is the typical "offline" door operation
typical of low value situations. Higher value door operations tend to be
"online" in the sense that they directly access employee specific registry
information. Such online permission entry can be based on timely
information (like has the employee been fired within the past couple hours)
or aggregation (what other things has the employee done in the recent
past). It is in the accessing of the employee registry entry (local,
remote, online, etc) for timely and/or aggregated information that makes
the use of the static, stale certificate redundant and superfluous.

Similarly a portable device can either be "offline" in the sense that its
operation is totally determined from just a CA public key registry and a
static, stale certificate (and doesn't have direct access to the
surrogate/agent registry entry). Lets say there are large number of
"public" portable device and anybody can utilize any device so long as they
have a valid certificate for device useage. However, a certificate can
become redundant and superluous if the device has a surrogate/agent
specific registry entry that it references (since it is possible to
register any information that might be found in a certificate, in a
surrogate/agent registry entry). A portable device that might contain a
surrogate/agent specific registry entry might be a owner-specific paradigm
(i.e. the surrogate/agent registry entry in the device corresponds to the
owner). A onwer-specific paradigm could be implemented with certificates if
the certificate contained the device specific identifier. The device would
only work when a certificate was presented that contained the
device-specific identifier in one of the certificate fields.

Lets say we are looking at a hardware token implementation as keys for
automobiles. For an owner specific paradigm there can be a certificate/PKI
based implementation or a certificate-less based implementation. In the
PKI-based implementation the automobile's internal permission registry
table contains one or more CA public keys. The car starts for any hardware
token that has a digital signed certificate that specifies the specific
automobile serial number and authenticated by any of the CA public keys
(and of course the hardware token signs a valid message that is
authenticated from the public key in the certificate). The certificate-less
implementation replaces the CA public keys in the automobile's internal
permission registry table with public keys of the owner's hardware tokens.
Then only the directly listed hardware tokens are able to start the
automobile. In the certificate-less scheme, there would be a administration
mode used in conjunction with a valid hardware token to add/delete public
keys in the automobile's registry.

In the PKI-based implementation for "owned" automobile operation, it
becomes somewhat more problamatical to invalidate hardware tokens (aka
certificates) for the automobile. One method would be to create registry
entries for invalidated certificates (aka public key/hardware token).
However, I would assert as soon as surrogate/agent specific entries are
required for invalidated public keys .... then the infrastructure has been
established making certificate-less operation KISS (aka static, stale
certificates being redundant and superfluous). Just create a positive
list/registry of public keys .... possibly totally eliminating the
delegation permission associated with CA public keys.  The automobile
registry than has permissions like administrative mode, start automobile,
open trunk, open doors, etc for each public key (aka hardware token).

It is problamatical whether CA public keys would be retained in the
automobile registry solely associated with manufacture and service
operation. Standard automobile operation would be straight certificate-less
with the owner's hardware tokens being directly registered in the
automobile's registry table. However, there might be non-ownership related
permissions like various service operations. There could be a manufacture
CA delegation permissions associated with service operation and independent
of automobile serial/identification. The manufacture's public key would be
in the automobile's table with delegation permissions. The manufacture
would sign public key certificates for service operations, enabling service
specific permissions for all cars from the manufacture.

However, CRLs really become a nightmare in this situation. I would contend
that a much KISS solution is that the service operation goes online with
the manufacture (in much the same way that POS terminal do online
transaction) and that the automobile authenticates the service operation by
accessing the manufacture's online database. The manufacture's public key
is still in the automobile registry .... not for purposes of validatting
certificates but for purposes of validating online communcation with the
manufacture for authentication of real-time service organization
delegation. As a result, the operation is online with direct access to
registry entries for service organizations and therefor service
organization certificates are redundant and superfluous.

past references regarding compression of certificates to zero bytes:
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information
... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A
& X9F
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation
checking capability
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment
Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication
implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates

past references to methodology of registry operation caching certificate
kind of information (making certificate transmission redundant and
superfluous)
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A
& X9F
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and
PKI (addenda)
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm4.htm#8 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC)
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security
Issues
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's
Untangling Authentication
http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security
proposal
http://www.garlic.com/~lynn/2003.html#52 SSL & Man In the Middle Attack

past discussions of static, stale certificate issues vis-a-vis
aggregated/timely information:
http://www.garlic.com/~lynn/aadsmail.htm#vbank Statistical Attack Against
Virtual Banks (fwd)
http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs
http://www.garlic.com/~lynn/aadsmore.htm#client2 Client-side revocation
checking capability
http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation
checking capability
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation
checking capability
http://www.garlic.com/~lynn/aadsm2.htm#arch4 A different architecture? (was
Re: certificate path
http://www.garlic.com/~lynn/aadsm2.htm#availability A different
architecture? (was Re: certificate path
http://www.garlic.com/~lynn/aadsm2.htm#mauthauth Human Nature
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm4.htm#01 <b>redundant and superfluous</b>
(addenda)
http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
http://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki24 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsmail.htm#variations variations on your
account-authority model (small clarification)
http://www.garlic.com/~lynn/aepay2.htm#aadspriv Account Authority Digital
Signatures ... in support of x9.59
http://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS
http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort
Certificates
http://www.garlic.com/~lynn/aepay4.htm#x9flb12 LB#12 Protection Profiles
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay6.htm#dspki3 use of digital signatures and
PKI (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ...
RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ...
RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ...
RIP PKI ... part III
http://www.garlic.com/~lynn/aadsm12.htm#20 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/aadsm12.htm#26 I-D
ACTION:draft-ietf-pkix-usergroup-01.txt
http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security
Issues
http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security
Issues
http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security
Issues
http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's
Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit
Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#0 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#2 OCSP value proposition
http://www.garlic.com/~lynn/aadsm13.htm#3 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#6 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP
http://www.garlic.com/~lynn/aepay10.htm#31 some certification &
authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#34 some certification &
authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
http://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/98.html#0 Account Authority Digital Signature
model
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#42 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication
implementation
http://www.garlic.com/~lynn/2001.html#67 future trends in asymmetric
cryptography
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser
Confuse Me
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle
attacks?
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#40 Help! Good protocol for national
ID card?
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry
vs. Government
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry
vs. Government
http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs',
how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs',
how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs',
how curruptable are they to

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm