Frank Hecker wrote:
> As I've said before, I don't think use of certs in general and SSL in
> particular should be artificially constrained to fit the perceived
> requirements of the Internet e-commerce market. To get back to Gerv's
> draft paper, I think his discussion is consistent with that approach:
> He's proposing leaving the existing browser CA/SSL model and UI in
place
> for legacy CAs and certs, and basically creating an extension to the
> model and UI specifically for SSL uses with financial implications.
> Certainly one can quibble with the various details of his proposal;
for
> example, it may be that it would be more appropriate to give special
> treatment to only one additional class of cert, rather than the two
> classes ("shopping" and "banking"). However this general approach is
IMO
> worth discussing.
we were asked to work with this small client/server startup in menlo
park that wanted to do payments on their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and they had this thing called ssl. in the year we worked with them,
they moved from menlo park to mountain view and changed their name from
mosaic to netscape (trivia question ... who had the original rights to
the name netscape?).
so part of this was for what became to be called e--commerce. the
customer would type in the url ... and it would go to an ssl shopping
shite. the browser would get back an ssl domain name certificate and
check the domain name in the certificate with the name typed in by the
customer. merchant webservers began complaining that running sll for
the shopping experience was cutting performance by 80-90 percent and
almost all such merchant sites now run w/o ssl. as a result there is no
checking of what the customer typed in to the browser for a URL against
what site the user is actually visiting.
eventually the customer gets to the end of shopping and hits the
check-out button ... which does supply a URL that specifies ssl. Now if
this was really a fraudulent site ... it is highly likely that the
crooks will have established some perfectly valid domain name and
gotten a valid SSL certificate for it ... and they are likely to also
make sure that whatever domain name that the check-out button supplies
... corresponds to the domain name in some certificate that have valid
control over.
now when somebody applies for a SSL domain name certificate ... the
certification authority usually goes to a great deal of trouble to
validate that the entity is associated with an identifiable valid
company (this basically is a complex, costly, and error-prone
identification process). They then contact the domain name
infrastructure and try and cross-check that the company listed as the
owner of the domain is the same company that is applying for the
certificate. Now if there has actually been a domain name hijacking ...
there is some possibility that the crooks have managed to change the
name of the company owning the domain to some valid dummy front company
that they have formed. in which case the whole certificate authority
process falls apart since it is fundamentally based on the integrity of
the domain name infrastructure registry of true owners.
so there is a proposal to have domain name owners register a public key
along with their domain name. then future communication from the domain
name owner is digitally signed and the domain name infrastructure can
verify the digital signature with the (certificateless) onfile public
key for that domain name.
this supposedly mitigates some of the forms of domain name hijacking.
the proposal is somewhat back back the SSL certification authority
industry since it improves the integrity of the domain name
infrastructure ... on which there ability to correctly certify the true
domain name owner is based.
it has another side effor for the ssl certification authority industry
... rather than doing the expensive, time-consumer and error prone
identification process they can require that ssl certificate
applications also be digitally signed. they then have a much simpler,
less-expensive, and reliable authentication process by retrieving the
(certificateless) onfile public key for the domain name owner (from the
domain name infrastructure).
http://www.garlic.com/~lynn/subpubkey.html#certless
it does represent something of catch22 for the ssl certification
authority industry. if the integrity of the domain name infrastructure
is improved it somewhat mitigates one of the original justifications
for having ssl certificates. another issue is if the ssl certification
authority can base the trust of their whole operation on the retrieval
of (certificateless) onfile public keys from the domain name
infrastructure ... one could imagine that others in the world might
also start trusting real-time retrieval of certificateless, onfile
public keys from the domain name infrastructure. There might even be a
slightly modified version of SSL that used real time retrieval of
certificateless, onfile public keys ... rather than a public key from a
stale, state (and potentially revoked?) certificate.
part os this comes somewhat from the original design point for PKI
certificates which was the offline mail environment of the early 80s. A
recipient would dialup their (electronic) post-office, exchange email,
and hangup. They then could be dealing with a first-time communication
from a total stranger. This is somewhat a later day analogy to the
letters of credit model from the sailing ship days ... where the
relying party had no (other) method of validating first-time
interaction with total stranger.
In the early 90s, there were x.509 identity certificates. The
certification authorities were somewhat faced with not really being
able to predict what information an unknown, future relying party might
require about an individual.
There was some tendency to want to grossly overload such identity
certificates with excessive amounts of personal information.
Somewhat in the mid-90s, various institutions came to the realization
that such identity certificates grossly overloaded with excessive
personal information presented significant liability and privacy
issues. There was some effort to retrench to something called a
relying-party-only certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo
which basically contained some sort of unique record index pointer
(account number, userid, or other distinquishing value) and a public
key. The subject would create a message (also containing the
distinquishing value) and digitally sign it with their private key.
They then would package the message, the digital signature and the
certificate and send it off to the relying party. The relying party
would extract the distinguishing index value from the message and
retrieve the indicated record containing all the necessary relationship
information about the originating entity (including their registed
public key). They then could validate the digital signature using the
onfile public key. In such situations it was trivial to proove that
such a stale, static certificate was redundant and superfluous. Part of
what made it so easy to proove they were redundant and superfluous was
the whole operation violated the original design point that
certificates were met to serve ... first-time communication between
complete strangers where the relying party had absolutely no other
method for establishing any information about the stranger they were
communicating with.
There was also some look at these stale, static redundant and
superfluous digital certificates for payment transactions by customers
with their respective fianncial institutions (again violating the basic
design point environment that certificates were met to serve). It turns
out that the nominal payment message size is about 60-80 bytes. The
nominal relying-party-only certificate from the mid-90s (even with only
an account number and a public key) was on the order of 4k-12k bytes.
Not only was the attachment of stale, static digital certificates to
every payment transaction redundant and superfluous, but doing so would
represent an enormous payload bloat of a factor of one hundred times.
_______________________________________________
Mozilla-security mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-security
