X.509 and ssh - SSH

This is a discussion on X.509 and ssh - SSH ; Ken Johanson wrote: > You are implying that a cert must be attached for message. That is not > true. SSL establishes sessions, where in the cert / keys are exchanged > only at the beginning of the session. There ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 66 of 66

Thread: X.509 and ssh

  1. Re: X.509 and ssh

    Ken Johanson wrote:
    > You are implying that a cert must be attached for message. That is not
    > true. SSL establishes sessions, where in the cert / keys are exchanged
    > only at the beginning of the session. There is no "KB's worth of
    > superfluous bytes" as you claim below, and certainly none of those are
    > wasted in the case where identity must be assured.


    there tends to be a broad range of different applications. supposedly
    one of the big drivers for certificate business in the mid-90s was in
    conjunction with financial transactions. the example was a financial
    transaction that is typically requiring 60-80 bytes ... and a large
    contingent of the PKI industry behind appending certificates to such
    transactions (as part of financial institutions paying $100 for digital
    certificates for everybody in the country that might do a financial
    transactions).

    it was possible to trivially show

    1) that if the financial institution already had all the information,
    then it was redundant and superfluous to attach a digital certificate to
    such financial transactions

    2) that the typical financial transaction was 60-80 bytes and the
    payload overhead of having redundant and superfluous certificates was on
    the order of 4k-12k bytes (representing a payload bloat of a two orders
    of magnitude increase).

    So in SSL, the overhead is theoritically front load for a session.
    However, when we originally helping to patch together the actual
    business process use of SSL
    http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    http://www.garlic.com/~lynn/aadsm5.htm#asrn3

    a lot of the SSL HTTP transactions were individual transactions (not KB
    transactions).

    the original business justification for SSL digital certificates were
    related to e-commerce ... and mentioned in the above references. The
    process was that the merchant got their domain name in a certificate. As
    part of the TCP/HTTP/SSL session setup, the person had typed in the
    URL/domain name into the browser, the browser had contacted DNS to map
    that domain name to IP-address, the browser contacted the webserver, the
    webserver responded with certificate, the browser validated the
    certificate and then check the typed in domain name against the domain
    name in the certificate.

    however, the majority of the merchants operating webservers discovered
    that the SSL overhead increased overhead by a factor of five times
    compared to running straight HTTP. As a result ... you saw almost all
    merchants dropping back to using SSL for purely the payment/checkout
    phase of electronic commerce. The problem is that the URL/domainname
    that is typed in by the user is no longer checked against an SSL
    certificate. What now happens is that the user clicks on a button
    supplied by the webserver that generates the URL and domain name ...
    which is then used to check against the domain name in the certificate
    also supplied by the same webserver. The issue now is that the majority
    of the ecommerce use in the world now violates fundamental kindergarten
    security principles ... since the webserver provides both the URL and
    the certificate that are checked against each other. It would take a
    really dumb crook to not have a completely valid certificate that
    corresponds to the domain that they provide in the button.

    So the other issue was that HTTP (which SSL was a subset) had other
    these truelly trivial transaction payloads ... and was using TCP
    protocol for doing it. Now TCP has a minimum of seven packet exchange
    for session setup (ignoring any added HTTP and/or additional SSL
    overhead). One of the characteristics in these early days was that most
    TCP implementations assumed few, long running sessions .... as opposed
    to a very large number of extremely short transaction like operations.
    One of the places that this appeared was in the linear list operation
    supporting FINWAIT. There was a crises period as HTTP (& SSL) caught on
    where numerous major webservers found that they were spending 99percent
    of total cpu managing the FINWAIT list.

    lots and lots of posts about SSL and certificates from the period
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    there is another issue somewhat involving the weak binding between
    domain name and domain name owner. the issue is that many of the
    certification authorities aren't the authoritative agency for the
    (SSL domain name server certificate) information they are certifying.
    much of the original justification for SSL related to mitm attacks was
    various integrity issues in the domain name infrastructure.

    the process tends to be that a domain name owner registers some amount
    of identification information for their domain name ownership with the
    domain name infrastructure. the certification authorities then require
    that SSL domain name certificate applicants also provide some amount
    of identification information. then the certification authorities
    attempt to do the expensive, time-consuming, and error-prone process
    of matching the supplied identification information for the SSL domain
    name certificate with the identificaiton information on file with the
    domain name infrastructure for the domain name.

    as part of various integrity issues related to that process, there has
    been a proposal, somewhat backed by the ssl domain name certification
    authority industry that domain name owners also register a public key
    with the domain name infrastructure (in addition to identificaiton
    information). then future communcation can be digitally signed and
    verified with the onfile public key. also the ssl domain name
    certification authority industry can require that ssl domain name
    certificate applications be digitally signed. then the certification
    authority can replace the expensive, time-consuming, and error-prone
    identification matching process with a much less-expensive and
    efficient authentication process by doing a real-time retrieval of the
    on-file publickey from the domain name infrastructure for verifying
    the digital signature (in lieu of doing a real-time retrieval of the
    on-file identificaiton information for the expensive, time-consuming
    and error-prone identification matching).

    the two catch22 issues here are

    1) improving the overall integrity issues of the domain name
    infrastructure lessons the original justification for ssl domain name
    certificates

    2) if the certification authority industry can rely on real-time
    retrieval of publickeys from the domain name infrastructure as the
    base, TRUST ROOT for all of their operations ... it is possible that
    other people in the world might also be able to do real-time retrieval
    of publickeys as a substitute to relying on SSL domain name
    certificates

    so there one could imagine a real transaction oriented SSL ... where the
    browser takes the URL domain name and requests the domain name to
    ip-address mapping. In the same transaction the domain name
    infrastructure also piggybacks in the same transaction, any registered
    public key for that webserver.

    Now you can imagine that in the initial communication, the browser
    includes the actual request, encrypted with a randomly generated secret
    key, which is, in-turn encrypted with the onfile public key obtained
    from the domain name infrastructure. This is all packaged in single
    transmission set of to the webserver. If it becomes an issue, the
    various SSL options can also be registered with the domain name
    infrastructure (as part of registering the public key). This can be a
    true SSL transaction and eliminates all the existing SSL protocol
    chatter back and forth (and no digital certificate required)

    so, if you start considering transaction efficiency ... there is the
    issue of 7packet minimum for TCP sessions. VMTP specified a 5-packet
    minimum exchange for reliable communication.

    From my RFC index.
    http://www.garlic.com/~lynn/rfcietff.htm

    http://www.garlic.com/~lynn/rfcidx3.htm#1045

    1045 E
    VMTP: Versatile Message Transaction Protocol: Protocol
    specification, Cheriton D., 1988/02/01 (123pp) (.txt=264928)
    (VMTP)

    as usual in my RFC index summary entries, clicking on the ".txt=nnn"
    field retrieves the actual RFC.

    However, when we were doing XTP protocol specification ... we actually
    came up with a minimum 3-packet exchange for reliable transaction
    http://www.garlic.com/~lynn/subnetwork.html#xtphsp

    lots of other posts mentioning the catch-22 issue for the SSL domain
    name certification authority industry moving to higher integrity domain
    name infrastructure operation
    http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation
    checking capability
    http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key
    Infrastructure: An Artifact...
    http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An
    Artifact...
    http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
    http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop

    http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source
    crypto?
    http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source
    crypto? (bad form)
    http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
    http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
    http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM
    (was WYTM?)
    http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
    http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against
    Phishing, Spoofing and Spamming
    http://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
    http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the
    session fixation bug?
    http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at
    MasterCard processor
    http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
    http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet
    security hall of shame
    http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE
    Secure Email Technologies
    http://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud -
    Case #3 - Phishing
    http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud -
    Case #3 - Phishing
    http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement
    shuffle" and other dances
    http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement
    shuffle" and other dances
    http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
    http://www.garlic.com/~lynn/2001l.html#22 Web of Trust
    http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into
    Browser Confuse Me
    http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
    http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in
    abscense of client certificates
    http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
    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#2 SRP authentication for web app
    http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all
    equally secure?
    http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs',
    how curruptable are they to
    http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
    http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
    http://www.garlic.com/~lynn/2003d.html#29 SSL questions
    http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption
    in a system to system interface
    http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses
    malicious network traffic
    http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model
    (At least I hope it's new)
    http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA
    application
    http://www.garlic.com/~lynn/2004b.html#41 SSL certificates
    http://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
    http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated
    Public Key Exchange without Digital Certificates
    http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated
    Public Key Exchange without Digital Certificates
    http://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
    http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
    http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and
    interoperability-issues sendmail/Exchange/postfix
    http://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and
    interoperability-issues sendmail/Exchange/postfix
    http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
    http://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
    http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
    http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of
    certificates & public keys securely
    http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no
    SSL being used
    http://www.garlic.com/~lynn/2005i.html#3 General PKI Question
    http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the
    Internet
    http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
    http://www.garlic.com/~lynn/2005m.html#0 simple question about
    certificate chains
    http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from
    External CA
    http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a
    secured P2P network
    http://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
    http://www.garlic.com/~lynn/2005u.html#9 PGP Lame question
    http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
    http://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"

  2. Re: X.509 and ssh

    Ken Johanson wrote:
    > Anne and/or Lynn have recited so many perceived "drawbacks" to x509 in
    > general, even in light of their usage in just about every modern
    > security / identity communication system of late. But what
    > *constructive* suggestions to improve the supposed deficiencies, have
    > they offered? What specific technology are they claiming is a
    > good/better replacement (some patent-pending technology of theirs
    > perhaps?)? And why do they so repeatedly recite "used to be"
    > limitations, but not also mention (or show awareness of) the current
    > state of the art fully address those?


    so there is some complete agreement with the SSL domain name
    Certification Authority industry proposal to have domain name owners
    register onfile public keys when they register domain names.

    rather than just restricting the use of realtime, online, onfile public
    key use to just validating digital signatures on communication with the
    domain name infrastructure and for ssl domain name digital certificate
    applications ... enable access to the online, onfile public keys
    available to everyone in the world. Then everybody has online, realtime
    access to the real public keys w/o having to resort to redundant,
    superfluous, stale, static digital certificates ... and can also
    optimize the SSL protocol chatter.
    http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh

    another trivial case is the x9.59 financial standards protocol which was
    designed to preserve the integrity of the financial infrastructure
    for all retail payments. the paying entity has a pre-existing
    relationship with their financial institution. the paying entity's
    financial institution keeps some amount of information about their
    account holders. one of the pieces of information about their account
    holders, is the account holders' public keys. If the paying entity's
    financial institution already has the registered public keys for all
    their account holders (as well as other registered information), it is
    trivial to demonstrate that it is redundant and superfluous to append
    stale, static digital certificates to transactions sent to the paying
    entity's financial institution for authentication and authorization.
    http://www.garlic.com/~lynn/x959.html#x959
    http://www.garlic.com/~lynn/subpubkey.html#x959

    so the next step is to trivial show that when the relying party has
    direct access to the real information .... say in the case where the
    authoritative agency for domain name ownership has onfile public keys
    for the domain name owner and is willing to provide real time access to
    such information, the stale, static digital certificates (representing
    that registration and certification) is redundant and superfluous.

    Another is any case, where a registration and certification authority is
    providing for online real-time business processes in support of digital
    signed transactions. If the relying party trusts a certification
    authority to issue a stale, static digital certification that can be
    used for authentication ... relying parties may find it even more
    valuable if the certification authority would provide real-time
    authentication and authorized transaction (even taking financial
    liability) for digital signed transactions. Since they can be the same
    registration and certification authority in both the offline, stale,
    static digital certificate scernario (a credential/certificate
    representing some real certification business process for purely
    authentication) and in the real-time, online support of digitally signed
    transactions (which can include authorization and liability in addition
    to the sense of any authentication).

    It turns out that one of the shortcomings for accepting liability in the
    financial transaction case with respect to the offline digital
    certificate model ... is the one hundred checks of $100 each (i.e. the
    digital certificate can emulate the business check scenario and say the
    certificate is not good for any checks over $100) or two hundred checks
    of $5000 each. The digital certificate just provides a method for
    authenticating ... and potentially could include a maximum per
    transaction limit (following the stale, static business check
    methodology). However, the infrastructure was still vulnerable to
    aggregation attacks ... and the countermeasure was online transactions
    that supported not only per transaction rules but could also support
    aggregation rules ... something not easily done or controlled with an
    offline, stale, static paradigm.

    The online, integrated authentication and authorization model could
    provide both per transaction business controls as well as aggregated
    business controls. Once you have an online, integrated authentication
    and authorization paradigm ... it makes the offline, stale, static
    processes redundant and superfluous.

  3. Re: X.509 and ssh

    Ken Johanson wrote:
    > 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.


    re:
    http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh


    so the stale, static, offline credential, certificate, license, diploma,
    letters of credit, letters of introduction methodology have served a
    useful business requirement in the physical world for centuries, namely
    providing a mechanism to represent some information to relying parties
    who have had no other mechanisms for accessing the actual information.

    digital certificates are just electronic analogs of their physical world
    counterparts, meeting the same business requirements ... namely
    providing a mechanism to represent some information to relying parties
    who have had no other mechanisms for accessing the actual information.

    so in the mid-90s there were efforts looking at chip-based, digital
    certificate-based driver's licenses ... as a higher valued
    implementation for better trust and operation.

    however, it ran into some of the similar retrenchments that faced x.509
    identity certificates ... even the physical drivers license contain
    unnecessary privacy information ... like date-of-birth, creating
    identity theft vulnerabilities.

    the other value proposition justification was that high value business
    processes .... like interaction with police officers supposedly could be
    better trusted using the higher value and higher integrity chip-based
    driver licenses incorporating digital certificate technology.

    however, police officers at that time were already in transition to much
    higher value online transactions. rather than simply relying on the
    information in a driver's license ... the driver's license simply
    provided an index into the online repository ... and the police officer
    used it to do realtime, online accesses the online respository,
    retrieving realtime information for authenticating and other wise
    validating the entity they were supposedly dealing with. Any information
    (other then simple repository lookup value) in the drivers license,
    became redundant and superfluous.

    All the higher value driver license related operations, were moving to
    online, realtime operation ... leaving any information content
    requirements for driver licenses to no-value operations that couldn't
    justify an online operation.

    If you are faced with a situation where the driver license has very
    defined use (say a trivial barcode to index a repository that contains
    your complete history and numerous biometric mechanisms for validating
    who you area) ... then any additional feature of a drivers license for
    use in no-value operations ... needs to be financially justified by the
    no-value operations (since they are redundant and superfluous for all
    the higher value business processes that can justify doing realtime
    online operations).

    The online characteristic can also be used to help address some of the
    existing identity theft vulnerabilities related to driver's license. For
    instance, an individual can authorize ... in a manner similar to how
    they might digitally sign an x9.59 transaction
    http://www.garlic.com/~lynn/x959.html#x959
    http://www.garlic.com/~lynn/subtopic...bkey.html#x959

    .... a transaction that answers yes/no to whether they are at least 21
    years old. the actual birth-date never has to be divulged ... the
    certification authority just responds yes/no in a manner similar to how
    certification authorities response approved/declined to existing
    realtime, online financial transactions.

    This is sort of the set "FAST" transaction proposals by FSTC
    http://www.fstc.org/

    that could even ride the same 8583 rails as existing financial
    transactions ... but in a manner similar to answer yes/no to financial
    transactions (w/o disclosing things like current account balance or
    transaction history) ... could answer yes/no to other kinds of
    certifications.

    some other past posts mentioning the digital certificate model for
    drivers licenses from the mid-90s ... and why it sort of evaporated.
    http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
    http://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded
    X9.59 NWI
    http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort
    Certificates
    http://www.garlic.com/~lynn/aepay6.htm#itheft "Gurard against Identity
    Theft" (arrived in the post today)
    http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process,
    payment, authentication and identification

    http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate
    Revocation Protocol
    http://www.garlic.com/~lynn/aadsm7.htm#idcard AGAINST ID CARDS
    http://www.garlic.com/~lynn/aadsmail.htm#liability AADS & X9.59
    performance and algorithm key sizes
    http://www.garlic.com/~lynn/aadsm11.htm#37 ALARMED ... Only Mostly Dead
    .... RIP PKI
    http://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead
    .... RIP PKI ... part II
    http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
    http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
    http://www.garlic.com/~lynn/aadsm13.htm#5 OCSP and LDAP
    http://www.garlic.com/~lynn/aadsm14.htm#13 A Trial Balloon to Ban Email?
    http://www.garlic.com/~lynn/aadsm15.htm#1 invoicing with PKI
    http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and
    authorization ... addenda
    http://www.garlic.com/~lynn/aadsm19.htm#48 Why Blockbuster looks at your ID
    http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet
    security hall of shame
    http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on
    high-assurance certificates
    http://www.garlic.com/~lynn/2001.html#62 California DMV
    http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
    http://www.garlic.com/~lynn/2001k.html#6 Is VeriSign lying???
    http://www.garlic.com/~lynn/2001l.html#29 voice encryption box (STU-III
    for the masses)
    http://www.garlic.com/~lynn/2001n.html#56 Certificate Authentication
    Issues in IE and Verisign
    http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
    http://www.garlic.com/~lynn/2002n.html#40 Help! Good protocol for
    national ID card?
    http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all
    equally secure?
    http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs',
    how curruptable are they to
    http://www.garlic.com/~lynn/2003m.html#21 Drivers License required for
    surfing?
    http://www.garlic.com/~lynn/2004i.html#4 New Method for Authenticated
    Public Key Exchange without Digital Certificates
    http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
    http://www.garlic.com/~lynn/2005i.html#33 Improving Authentication on
    the Internet
    http://www.garlic.com/~lynn/2005l.html#32 More Phishing scams, still no
    SSL being used
    http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using
    self-signed certs
    http://www.garlic.com/~lynn/2005u.html#37 Mainframe Applications and
    Records Keeping?
    http://www.garlic.com/~lynn/2006.html#37 The new High Assurance SSL
    Certificates

  4. Re: X.509 and ssh

    Ken Johanson wrote:
    > Let me write you 100 $100 checks... will you cash them all and hands me
    > the goods based on my self-generated, unvouched public key? Really?


    as stated in other post
    http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh

    this was a real business fraud problem ... which businesses responded
    with a stale, static credential/certificate (dating some number of
    decades) in the form of a check embossed with a stale, static, per
    transaction business rule embossed each such credentials (check) with
    per transaction limit. some of the digital certificates for financial
    purposes even proposed having similar stale, static, per transaction
    business rule embosed in the electronic digital certificate (aka not
    good for transactions with value greater than xxxx).

    the problem that started being addressed sometime in the 80s with
    payment cards that were used for realtime, online operation (where the
    backend business rules could include a broad range of per transaction
    specifications ... but there could also be aggregation business rules
    .... that representing real time rules spanning a collection of
    transactions) ... was fraud being done by doing using 100 $100 checks or
    possibly 200 $5000 checks (whatever the per transaction limit was).

    the relying parties liked it much better because not only were they
    getting realtime authentication responses back from the authoriative
    agency (or certification authorities, if you wish), but they were also
    getting back realtime authorization responses (which you couldn't do
    using the offline stale, static credential/certificate paradigm)

    for the various digital certificate-based financial transaction
    proposals ... they went thru all the legacy business rule proposals that
    had been used in stale, static credentials/certificates in the past.
    however, it was trivial to show that such stale, static legacy
    approaches couldn't address the aggregation countermeasures implemented
    in online, realtime operations. furthermore, any authoritative agency
    supporting such infrastructures could easily have all the information
    necessary for both doing realtime authentication and realtime
    authorization .... making any stale, static digital certificate
    operation redundant and superfluous.

    so the stale, static, offline credential, certificate, license,
    diploma, letters of credit, letters of introduction methodology have
    served a useful business requirement in the physical world for
    centuries, namely providing a mechanism to represent some information
    to relying parties who have had no other mechanisms for accessing the
    actual information.

    digital certificates are just electronic analogs of their physical
    world counterparts, meeting the same business requirements ... namely
    providing a mechanism to represent some information to relying parties
    who have had no other mechanisms for accessing the actual information.

    for business operations that have moved into an online paradigm with
    realtime, online access to all necessary information ... the stale,
    static digital certificate methodology represents an archaic, obsolete,
    redundant and superfluous paradigm.

  5. Re: X.509 and ssh

    ref:
    http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh
    http://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh

    so another another scenario comparing online based transaction operation
    and offline credential/certificate operation are door badge systems.

    the legacy, oldtime door badge systems have been offline. as the higher
    value online door badge systems came into being, the offline door badge
    systems have moved into the lower cost market niche.

    in the 3-factor authentication model
    http://www.garlic.com/~lynn/subpubkey.html#3factor

    * something you have
    * something you know
    * something you are

    an electronic door badge represents "something you have" authentication.
    in the legacy offline door badge system, the badge would present some
    unique information that validates a specific badge and differentiates it
    from other badges (aka unique "something you have" authentication) and
    then some other code that provides the basis for authorization decision
    (by a specific door processor). before the introduction of online door
    badge systems, the authorization information provided by the badge for
    the offline paradigm was becoming more and more complex ... listing
    specific classes of doors that were authorized and/or specific doors
    that it was authorized. this overloaded the function of the badge with
    both "something you have" authentication as well as providing
    authorization information for the offline door badge processor.

    with the introduction of online door badge, the construct served by the
    badge could return to purely a unique "something you have"
    authentication. The badge provides unique information to differentiate
    itself from other badges; the online system looks up that specific badge
    entry and finds the corresponding entity (associated with the badge),
    including the entity's permissions and determines whether or not to
    authorize the door to open. The online system typically can support a
    lot more complex set of realtime permission rules ... compared to
    features provided by offline door badge systems ... not only stale,
    static per transaction rules, but say a capability to raise an alarm if
    the same "something you have" badge is used to enter multiple succesive
    times w/o having been used for exits between the entries. This is
    comparable to the richer set of features in online payment card
    operation ... where set of authorization rules of an online paradigm can
    include authorization spanning aggregation of transactions (like has an
    aggregate set of transactions exceeded the entity's credit limit) as
    opposed to single transaction operation.

    now various door badge systems ... whether online or offline have tended
    to implement static information to represent a unique physical object
    ("something you have" authentication). systems relying on static data
    representation are a lot more vulnerable to evesdropping and/or skimming
    and vulnerable to replay attacks (possibly with counterfeit/cloned badges).

    a countermeasure to such skimming/evesdropping (in support of replay
    attacks) is a badge with a chip that implements public/private key
    technology. the chip has a unique private key which is used to digitally
    sign randomly generated data. the relying party then validates the
    digital signature (with the corresponding public key) as part of
    establishing a unique token in support of a "something you have"
    authentication paradigm.

    the public/private key door badge, can be implemented in an offline door
    badge system, where the door badge is providing both authentication and
    authorization information. The chip in the door badge not only returns a
    digital signature to the door reader but also a digital certificate. the
    digital certificate contains the public key necessary to validate the
    digital signature (performing the authentication part of the operation)
    and the other information in the digital certificate provides the basis
    for the door deciding whether or not to open (authorization). this
    technology change is a countermeasure to various kinds of replay attacks
    against offline door badge systems.

    an online public/private key door badge system implementation doesn't
    require a digital certificate since the online entry contains the public
    key necessary to validate a digital signature (for a specific badge as
    part of establishing a specific unique badge in support of "something
    you have" authentication). the online entry also contains the permission
    specifications in support of the realtime, online authorization rules.
    in the higher value, online door badge system operation, any digital
    certificate (providing information for both authentication and
    authorization functions) is redundant and superfluous ... since that
    information is part of the operation of the online door badge system
    The online systems tend more sophisticated authorization rule
    implementation, which tend to also be more valuable and more complex
    than possible in an offline door badge system using stale, static
    authorization rules.

    The digital signature paradigm can be viewed as providing dynamic data
    authentication countermeasure to skimming/evesdropping (and replay
    attacks typically associated with static data authentication
    infrastructures). However, the offline paradigm, using a digital
    certificate tends to retain stale, static authorization rule
    implementation. The transition to online operation can take advantage of
    both the dynamic data authentication (provided by the digital signature
    paradigm) and also dynamic authorization rules (provided by having
    aggregated and realtime information available in the online system).

    so the stale, static, offline credential, certificate, license, diploma,
    letters of credit, letters of introduction methodology have served a
    useful business requirement in the physical world for centuries, namely
    providing a mechanism to represent some information to relying parties
    who have had no other mechanisms for accessing the actual information.

    digital certificates are just electronic analogs of their physical world
    counterparts, meeting the same business requirements ... namely
    providing a mechanism to represent some information to relying parties
    who have had no other mechanisms for accessing the actual information.

    a few past postings discussing the offline/online door badge system
    comparison:
    http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed)
    http://www.garlic.com/~lynn/2003b.html#50 Authentication w/o user ids
    and passwords
    http://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob
    Bemer, Computer Pioneer,Father of ASCII,Invento
    http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
    http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh

  6. Re: X.509 and ssh

    Anne & Lynn Wheeler wrote:
    >
    >
    > so the stale, static, offline credential, certificate, license, diploma,
    > letters of credit, letters of introduction methodology have served a


    These descriptions certainly implies that x509 certs are "stale, static,
    offline credential", again your presentation would lead readers to
    believe that (and interpret "stale" as derogatory and diminished value)
    this is all the are. In fact, and as you know (but do not present in
    balance, on the same sentence, (eg "The static/offline and not live
    portion of the certificates"), certs *can* be checked for their validity
    during session initiation or periodically, using CRL and OCSP protocols.

    This too is a contrast to the (arguable much more stale/static) simple
    PKI systems that store trusted keys locally, but have no way to check
    some authority to know if those keys were compromised. Again your broke
    your own line of argument, where you claim that local "registries" of
    trusted key are adequate and state that certificate data (which contains
    essential revocation/OCSP URLs) are merely superfluous.

    >
    > however, it ran into some of the similar retrenchments that faced x.509
    > identity certificates ... even the physical drivers license contain
    > unnecessary privacy information ... like date-of-birth, creating
    > identity theft vulnerabilities.


    Is this the only example you can provide, because it's clearly wrong...
    Your DOB is *essential* because an entire array of public service
    require knowledge/verification of your DOB before you are eligible for
    services (over-18 and over-21 activities in the US, and senior citizen
    eligibility for services, to name just a few) -- and also because your
    DOB helps distinguish one Lynn Wheeler from another.

    x509 and personal IDs have not been used because of cost and because of
    administrative concerns by govt, and because of portion of the
    population believes then should be anonymous and un-trackable of they so
    choose.

    However this tide is changing - even with proposals to leave those
    people in an optional state, other will choose to use digital ID system
    because they make *guarantees* against ID theft that paper, passports,
    certificates and drivers licenses cannot (including but not limited to
    mere photo-copy duplication). Give the choice, I certainly would pick
    the digital certificate with 2 factor authentication, compared to
    paper/plastic photo ID and payment cards. The paranoid will not, so be
    it (they lament having to be registered/traceable with govt but expect
    to drive motor vehicles too).

    >
    > the other value proposition justification was that high value business
    > processes .... like interaction with police officers supposedly could be
    > better trusted using the higher value and higher integrity chip-based
    > driver licenses incorporating digital certificate technology.
    >

    This is correct.

    > however, police officers at that time were already in transition to much
    > higher value online transactions. rather than simply relying on the
    > information in a driver's license ... the driver's license simply
    > provided an index into the online repository ...


    You fail to see the point, the non-digital ID can be forged. This is
    *diminished* value. I can masquerade as Lynn Wheeler using my fake ID,
    and run red lights at your expense. This happens NOW.

    and the police officer
    > used it to do realtime, online accesses the online respository,
    > retrieving realtime information for authenticating and other wise
    > validating the entity they were supposedly dealing with. Any information
    > (other then simple repository lookup value) in the drivers license,
    > became redundant and superfluous.


    What you're really trying to propone (apparently) is that and single
    user-id (drivers license #) is sufficient, without what you call
    superfluous cert data (address, name, etc). Where this breaks down is if
    the officer is offline, or the "registry" fails in any way. Central
    registries also have complexity and scalability issues, especially when
    they must convey all the detail (and not just revocation info) (vs
    having all the static details contained inside the cert).

    Again, using the trusty x509/SSL example, image if every SSL website
    *required* contacting some registry(s) to get details of the company,
    instead of conveying the relevant business details during SSL handshake
    (eg inside the cert). The system would be both slower and more prone to
    failure. And *yet* x509 does allow this to work if the com[pany and
    client choose to have stricter requirements -- using meta URLs
    referenced in the cert, and CRL/OCSP.

    The REAL world example is when you buy something from someone, or when
    you crash your car into someone else, and have to exchange
    identification data. That person will not necessarily have access to the
    registry service. Having all the essential ID data contained *inside*
    the cert is purely necessary.

    Would you buy something from someone of their ID papers contained *only*
    their (supposed) ID #?? You would *not*.

    >
    > The online characteristic can also be used to help address some of the
    > existing identity theft vulnerabilities related to driver's license. For
    > instance, an individual can authorize ... in a manner similar to how
    > they might digitally sign an x9.59 transaction


    The identity theft vulnerabilities of paper and or digital ID system are
    merely and artifact of modern day, primitive methods that credit cards
    companies use to "authenticate" persons. Specifically, needing your DOB.
    These artifacts will disappear with time (as vendors stop using them),
    and, they need to access them with will NOT go away (using the very poor
    DOB example you provided), because:

    a) DOB is simply necessary for modern society
    b) they will be registered in a non-permissive system anyway (they
    already are)
    c) the artifact DOB-type authenticators will stop being used (by law),
    and those datums will become innocuous, as they should be. So DOB can be
    used to validate your right to enter drink alcohol or gamble, etc, as it
    should be and is now.

    The permissive model you describe will ONLY be used/useful for things
    that *require* permission, like financial transactions. But these datums
    (bank account information) do not exist inside of x509 anyway -- only
    essential and largely static *identification* data does (and limited at
    that, i.e DOB is not required in a most certificates, unless you work
    for certain high security agencies).

    Put simply your proposing of a registry based system solve-all (where a
    user IDs themselves by presenting ID# only) (where signed x509 cert data
    is not needed) is flawed and fails by the same tokens you claim the x509
    certs fail:

    a) redundant over-the-wire transmission of static data when a local copy
    can/should exist.
    b) required equipment and connectivity to registry (and also *redundant*
    registry trust/validation scheme (which x509/SSL already have solved))
    c) requires all of the same semantics that x509 already provide for
    integrity and authentication.

    The permissive model you propose is *only* applicable to *permissive*
    data (financial, etc). You're obviously implying that real word ID
    information DOB specifically should permissive -- is false, or that
    current x509 fields (which current does NOT include DOB) contains what
    "should be" private data is false -- if you cause a car accident with
    me, then I have complete and irrevocable rights to *positively* ID you
    (name, address, DOB together uniquely ID a person in today
    permanent-identifier*-less world) so that I can recoup damages (though
    some privacy advocates would dispute this "right", they are the exception)

    *What you have referred to as a user-id number (which links a person to
    the registry) already exists as an RFE, an extended attribute in x509,
    where the cert can record and carry your life-long unique identifier.
    This too, is nothing less that essential. Again, if *nothing* else
    existed in the cert except this permanentID (and all other data
    including name had to be sent over the wire), then it *still* needs to
    be signed by a trusted party for which I carry a trust store -- so that
    I can validate your ID now (before you leave the scene of the wreck),
    while I do not have access to the registry, and then get your details
    later.

    So the x509 and signature system still serves and indisputable purpose,
    and clearly having additional fields also in the cert, such as your
    *static* name, is fully reasonable (to most people).

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4