Re: X.509 and ssh



If you can't answer to (but only delete and ignore) the obvious questions that were posed to you, then there is no conversation to he had.

And you are *still* referring to what was, instead of now, and distorting things merely to support your side (statements like "grossly overloaded" and "was redundant and superfluous" (again without an example) which are as much balderdash as saying that your drivers licensee being overloaded just because it makes you accountable and traceable to everyday people you may encounter).

If you don't like it, then don't use certs. For now, they're optional -- (unlike your drivers license)... even though they are far and away and growing as the most used system for secure internet protocols, whether issued by the CAs that you despise, or by your own personal CA.


ref:
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh

the issue in the early 90s with x.509 identity certificate standard
... appeared to be that personal information in a certificate seemed
to be a valuable business niche for certificates ... and some of the
emerging things called certification authorities ... which were out
to sell these x.509 identity certificates started down the road that
the more personal information included, the greater the value of the
certificate (and the implication that they could charge more).

that trend somewhat created the realization in a number of
institutions, that certificates, grossly overeloaded with personal
information, gave rise to significant privacy and liability issues
... and contributed to the appearance of the relying-party-only
certificates in the mid-90s.
http://www.garlic.com/~lynn/subpubkey.html#rpo

the original x.509 identity certificate paradigm seem to assume a
total anarchy where the x.509 identity certificate would be used for
initial introduction (like the letters of credit/introduction example)
between totally random strangers. as such, the respective entities as
individual relying parties, had no prior information about the other
party. In such a wide-open environment, it seemed necessary to pack as
much information as possible into the certificate.

however, the retrenchment to the relying-party-only model, placed all
the actual entity information in a repository someplace with just an
account number for indexing an entity's repository entry. however, it
was then trivial to demonstrate that attaching relying-party-only
digital certificates to signed operations (sent off to the relying
party) was redundant and superfluous .. since the relying party would
have access to all the requiered information and didn't require a
digital certificate to represent that information.

the other approach was to trivially demonstrate that there was no
information in such certificates that wasn't also contained in the
corresponding repository certified entry. in which case, if it could
be shown that the relying party had access to the repository certified
entry, then it was trivially possible to eliminate all fields in the
certificate resulting in a zero-byte digital certificate ... which
could be freely attached to everything.

in any case, the trivial case of a relying-party-only certificate is
where the institution that is acting as the relying party is also the
institution responsible for certifying the information and issuing a
digital certificate (representing that certifying process).

in an online environment ... replying-party-only model was extended,
so that if the information could be accessed by other parties (that
weren't directly responsible for the certification and issuing a
digital certificate, representing such certification) using purely
online realtime transactions, then the use of stale, static
certificate as a representation of some certified information (in some
repository) becomes redundant and superfluous (when the entities have
direct and/or online, realtime access to the original information).

the shrinking market for the offline credential/certificate market
(and any electronic analogs) is market segment where it isn't possible
to have online access to the real information and/or the value of the
operation can't justify (the rapidly declining) online access costs
(aka certificate moving further and further into the no-value market
segment).

part of this is the comfort that people have in the (physical) offline
credential/certificate model ... being accostomed to working in an
online environment ... and therefor not having direct, realtime access
to the actual information. The physical offline credential/certificate
provides them with a sense of comfort regarding some certification
process as actually having taken place (and which they have no means
of directly validating). They then have achieve similar comfort to
find an electronic certificate analog to these offline
credential/certificate constructs. However, it is normally trivial to
show that realtime, online direct access to the certified information
is at least as valuable ... and frequently significantly more valuable
than relying on a stale, static digital certificate (modulo the
scenario for which credentials/certificates were originally invented,
the place where the relying can't access the real information).

.



Relevant Pages

  • Re: How do you get the chain of certificates & public keys securely
    ... signatures maintain verification public keys in a trusted public key ... there are a number of mechanisms that relying parties may be ... public key for verifying a digital signature on the digital certificate ...
    (comp.security.ssh)
  • Re: Help! Im trying to understand PKI - especially CAs role
    ... > The CA verifies the credentials and signs the public key with the ... > credentials depend on the requested certificate class. ... the sender) locally or remotely. ... the relying party creates a relying-party-only certificate ...
    (comp.security.misc)
  • Re: X.509 and ssh
    ... the issue in the early 90s with x.509 identity certificate standard ... individual relying parties, had no prior information about the other ... certificate resulting in a zero-byte digital certificate ... ... in an online environment ... ...
    (comp.security.ssh)
  • trusted repositories and trusted transactions
    ... some forces trying to increase the perceived value of the certificate ... however, it almost every transaction oriented scenario, it was trivial ... transaction can take into account many factors, ... the offline world where relying parties did have their own information ...
    (sci.crypt)
  • Re: TLS-certificates and interoperability-issues sendmail / Exchange / postfix ..
    ... > to assert that certificate validation doesn't happen, ... this trusted public key store contains public keys of that the ... signed by the CA. this digital certificate is returned to the "key ...
    (comp.security.unix)