X.509 and ssh - SSH

This is a discussion on X.509 and ssh - SSH ; On 2006-03-13, Richard E. Silverman wrote: >>>>>> "ALW" == Anne & Lynn Wheeler writes: > ALW> -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ > > I was actually wondering why you constantly post rambling, multi-page I was wondering whether Anne ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 66

Thread: X.509 and ssh

  1. Re: X.509 and ssh

    On 2006-03-13, Richard E. Silverman wrote:
    >>>>>> "ALW" == Anne & Lynn Wheeler writes:

    > ALW> -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
    >
    > I was actually wondering why you constantly post rambling, multi-page


    I was wondering whether Anne & Lynn were siamese twins - but according
    to someone who knows they're not.

    And passing off difficult communication as "just my style" is not much
    more defensible than writing a network protocol for the client side only.

    --
    Elvis Notargiacomo master AT barefaced DOT cheek
    http://www.notatla.org.uk/goen/
    Powergen write "Why not stay with us" - let me count the ways!

  2. Re: X.509 and ssh

    all mail refused wrote:
    > On 2006-03-13, Richard E. Silverman wrote:
    >>>>>>> "ALW" == Anne & Lynn Wheeler writes:
    >>> -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

    >>
    >> I was actually wondering why you constantly post rambling, multi-page

    >
    > I was wondering whether Anne & Lynn were siamese twins - but according
    > to someone who knows they're not.
    >
    > And passing off difficult communication as "just my style" is not much
    > more defensible than writing a network protocol for the client side
    > only.


    Along with the repeated references to some PhD paper for which there doesn't
    seem to be an actual link in the messages that repeatedly reference it.
    That's confusing at best.



  3. Re: X.509 and ssh

    "Nico Kadel-Garcia" writes:
    > Along with the repeated references to some PhD paper for which there
    > doesn't seem to be an actual link in the messages that repeatedly
    > reference it. That's confusing at best.


    actually there seems to be some additional semantic confusion. there
    was a question about "why" ... and i mentioned that there was a 9
    month research project that studied how i communicated (person sat in
    the back of my office for 9 months, took notes on all my voice
    communication, also had copies of all my incoming and outgoing email
    as well as logs of all instant messages). this research project also
    resulted in a stanford phd thesis ... joint with language and comp. ai
    department ... as well as material for several subsequent books and
    papers. in that literature, it goes into quite a bit of detail about
    "why" ... quite a bit more than i could possibly explain.

    there was no subsequent request for the actual references ... so it
    appeared like the original question(s) were possible specious and
    there was no serious interest in investigating why.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  4. Re: X.509 and ssh

    Anne & Lynn Wheeler writes:
    > there was no subsequent request for the actual references ... so it
    > appeared like the original question(s) were possible specious and
    > there was no serious interest in investigating why.


    the actual thesis isn't online ... possibly wait for the google book
    scanning project and/or have access to the stanford library.

    a couple more recent references to some of the work by the prime
    researcher (found with search engine)
    http://www.ncrel.literacy.smartlibra...m?segment=2369
    http://llt.msu.edu/vol4num2/murray/

    which includes the following items:

    Denise E. Murray is Director of the National Centre for English
    Language Teaching and Research, Macquarie University, Sydney,
    Australia. She was founding Chair of the Department of Linguistics and
    Language Development at San Jose State University. She has been
    involved in ESL instruction and teacher education for more than 25
    years. Her research interests include crosscultural literacy and the
    interaction between language, society and technology. Her publications
    include Knowledge machines: Language and information in a
    technological society, and Diversity as resource: Redefining cultural
    literacy.

    Murray, D. E. (1988). The context of oral and written language: A
    framework for mode and medium switching. Language in Society, 17,
    351-373.

    Murray, D. E. (1991). Conversation for action: The computer terminal
    as medium of communication. Amsterdam: John Benjamins.

    Murray, D. E. (1995). Knowledge machines: Language and information in
    a technological society. London: Longman.

    Murray, D. E. (1999). Access to information technology: Considerations
    for language educators. Prospect, 14, 4-12.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  5. Re: X.509 and ssh


    ..... oh, and i did stumble across an old intermim status report on the
    research project ... partial extract ...


    COMPOSITION AS CONVERSATION:
    The Computer Terminal as Medium of Communication
    Fifth Research Report
    April 16th, 1985
    Denise E. Murray
    San Jose CA

    DATA ANALYSIS

    In this reporting period, I have concentrated on developing a
    theoretical framework, driven by the data. This has included:

    An Operational Definition of 'Conversation'. This is a paper to
    be presented at the Stanford University School of Education Forum
    for Research on Language Issues.

    ......

    Defining 'problem-solving' discourse. This genre indicates structures
    which achieve object transmission, information transmission,
    direction, description, and information development.

    ....

    Channel of communication is not arbitrary; channel may be chosen from
    available options. This choice is motivated by field, tenor and mode
    of discourse.

    Characteristics of discourse depend on choices made along three
    clines:

    involvement/detachment
    planning/spontaneity
    collaboration/isolation

    .....

    I have tallied the amount of computer correspondence and conversation
    the subject has been engaged in over the past 6 months.

    I have asked for statistical help. xxxxx has suggested SPSS available
    on the IBM PC.

    Presentations

    I have written the first draft of the paper, COMPUTER CONVERSATION:
    Adapting the Composing Process to Conversation, to be presented at the
    International Conference on Computers and the Humanities, Brigham
    Young University, June 26-28, 1985

    I have written the first draft of the paper, When is a Conversation
    not a Conversation? Operationalizing a Definition of the Object of
    Discourse Study, to be presented at the Stanford University School of
    Education Forum for Research on Language Issues, May 11, 1985.

    .... snip ...

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  6. Re: X.509 and ssh


    "Anne & Lynn Wheeler" wrote in message
    news:m3k6ay45ym.fsf@lhwlinux.garlic.com...
    > "Nico Kadel-Garcia" writes:
    >> Along with the repeated references to some PhD paper for which there
    >> doesn't seem to be an actual link in the messages that repeatedly
    >> reference it. That's confusing at best.

    >
    > actually there seems to be some additional semantic confusion. there
    > was a question about "why" ... and i mentioned that there was a 9
    > month research project that studied how i communicated (person sat in
    > the back of my office for 9 months, took notes on all my voice
    > communication, also had copies of all my incoming and outgoing email
    > as well as logs of all instant messages). this research project also
    > resulted in a stanford phd thesis ... joint with language and comp. ai
    > department ... as well as material for several subsequent books and
    > papers. in that literature, it goes into quite a bit of detail about
    > "why" ... quite a bit more than i could possibly explain.
    >
    > there was no subsequent request for the actual references ... so it
    > appeared like the original question(s) were possible specious and
    > there was no serious interest in investigating why.


    Neither this nor your subsequent references actually names the paper nor
    provides any ability to view the paper's material. I'm sure it's very
    ego-gratifying to have a paper that mentions you, but since the content of
    the paper is unavailable and you've in fact failed to even describe what the
    paper said about your posting style, it's pretty much an entirely useless
    reference. Isn't it?

    In other words, there's no confusion: you've failed to actually explain or
    justify your failure to use capitals, periods, or other punctuation
    correctly and continue meandering about irrelevant material.

    *plonk*.



  7. Re: X.509 and ssh


    "Nico Kadel-Garcia" writes:
    > Neither this nor your subsequent references actually names the paper
    > nor provides any ability to view the paper's material. I'm sure it's
    > very ego-gratifying to have a paper that mentions you, but since the
    > content of the paper is unavailable and you've in fact failed to
    > even describe what the paper said about your posting style, it's
    > pretty much an entirely useless reference. Isn't it?
    >
    > In other words, there's no confusion: you've failed to actually
    > explain or justify your failure to use capitals, periods, or other
    > punctuation correctly and continue meandering about irrelevant
    > material.


    I guess that the earlier statements weren't very clear that the phd
    thesis and subsequent papers and books were based on analysis of
    collected nine months of my communication. the communication examples
    in the thesis and subsequent books and papers were anonymized so my
    name never appeared (in addition a lot of technical content of what
    was actually being discussed in the communication was frequently
    obscured).

    also from referenced status report mentioned here
    http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh

    the data collection effort and analysis was done under an IBM contract
    managed out of the Los Angelos Scientific Center and resulted in a IBM
    research report as well as Stanford phd thesis. The dissertation
    topic was "Composition as Conversation: The Computer Terminal as
    Medium of Communication" (aka title of phd thesis). It was joint
    between language department and computer ai department (I believe
    terry winograd was thesis advisor on the computer side)

    the earlier statments also reference that the collected material and
    analysis was used for subsequent papers and books.

    for some drift, various collected posts about cmc, some mentioning the
    dissertation
    http://www.garlic.com/~lynn/subnetwork.html#cmc

    the only publication on the subject that i'm aware of from the period
    (in the early 80s) that actually mentioned my name was a Datamation
    article that had some references to my getting blamed for a lot of
    online stuff that happened during the 70s and early 80s.

    some of the activity referenced in the Datamation article is also
    mentioned in various past postings about the internal network
    .... which was larger than than the arpanet/internet from the beginning
    until approximately summer of 1985 ... when the number of nodes in
    the internet passed the number of nodes in the internal network.
    http://www.garlic.com/~lynn/subnetwork.html#internalnet

    note the internal network size doesn't include the academic bitnet (in
    the US) and earn (in europe) which used the same technology as the
    internal network (bitnet/earn was also larger than internet
    in the early 80s)
    http://www.garlic.com/~lynn/subnetwork.html#bitnet

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  8. Re: X.509 and ssh

    Anne & Lynn Wheeler wrote:
    > "Nico Kadel-Garcia" writes:
    >> Neither this nor your subsequent references actually names the paper
    >> nor provides any ability to view the paper's material. I'm sure it's
    >> very ego-gratifying to have a paper that mentions you, but since the
    >> content of the paper is unavailable and you've in fact failed to
    >> even describe what the paper said about your posting style, it's
    >> pretty much an entirely useless reference. Isn't it?
    >>
    >> In other words, there's no confusion: you've failed to actually
    >> explain or justify your failure to use capitals, periods, or other
    >> punctuation correctly and continue meandering about irrelevant
    >> material.

    >
    > I guess that the earlier statements weren't very clear that the phd
    > thesis and subsequent papers and books were based on analysis of
    > collected nine months of my communication. the communication examples
    > in the thesis and subsequent books and papers were anonymized so my
    > name never appeared (in addition a lot of technical content of what
    > was actually being discussed in the communication was frequently
    > obscured).
    >
    > also from referenced status report mentioned here
    > http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh
    >
    > the data collection effort and analysis was done under an IBM contract
    > managed out of the Los Angelos Scientific Center and resulted in a IBM
    > research report as well as Stanford phd thesis. The dissertation
    > topic was "Composition as Conversation: The Computer Terminal as
    > Medium of Communication" (aka title of phd thesis). It was joint
    > between language department and computer ai department (I believe
    > terry winograd was thesis advisor on the computer side)
    >
    > the earlier statments also reference that the collected material and
    > analysis was used for subsequent papers and books.
    >
    > for some drift, various collected posts about cmc, some mentioning the
    > dissertation
    > http://www.garlic.com/~lynn/subnetwork.html#cmc
    >
    > the only publication on the subject that i'm aware of from the period
    > (in the early 80s) that actually mentioned my name was a Datamation
    > article that had some references to my getting blamed for a lot of
    > online stuff that happened during the 70s and early 80s.
    >
    > some of the activity referenced in the Datamation article is also
    > mentioned in various past postings about the internal network
    > ... which was larger than than the arpanet/internet from the beginning
    > until approximately summer of 1985 ... when the number of nodes in
    > the internet passed the number of nodes in the internal network.
    > http://www.garlic.com/~lynn/subnetwork.html#internalnet
    >
    > note the internal network size doesn't include the academic bitnet (in
    > the US) and earn (in europe) which used the same technology as the
    > internal network (bitnet/earn was also larger than internet
    > in the early 80s)
    > http://www.garlic.com/~lynn/subnetwork.html#bitnet
    >


    You really should consider shorter responses. One or two sentences will
    usually do.

  9. Re: X.509 and ssh

    Chuck writes:
    > You really should consider shorter responses. One or two sentences will
    > usually do.


    past refs in thread:
    http://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#14 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#27 X.509 and ssh

    well then, two search engines URLs
    http://www.google.com/search?as_q=&n...s=&safe=images
    http://search.yahoo.com/search?_adv_...m=i&fl=0&n=100

    the long responses were also something cited in the detailed analysis
    (in fact this is relatviely brief compared to the recent discussion
    in comp.arch on TLBs).

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  10. Re: X.509 and ssh

    Chuck wrote:

    > You really should consider shorter responses. One or two sentences
    > will usually do.


    Hey, I've got her/them killfiled. Notice that the references she/they made
    are also, in fact, pretty useless for finding the material she references.
    They're just Usenet archives of the previously irrelevant posts on the
    subject which don't actually contain any text of the papers she or they are
    so excited about being described in, nor does she/they say what the paper
    actually said about her/them.



  11. Re: X.509 and ssh



    On 16 Mar 2006 19:01:41 -0500, "Nico Kadel-Garcia"

    > Hey, I've got her/them killfiled. Notice that the references she/they made
    > are also, in fact, pretty useless for finding the material she references.
    > They're just Usenet archives of the previously irrelevant posts on the
    > subject which don't actually contain any text of the papers she or they are
    > so excited about being described in, nor does she/they say what the paper
    > actually said about her/them.



    Amen. I attempted to peel the garlic onion once or twice and found little
    more than non sequitur circular references. As you say, it's not even
    clear if the gibberish originates from a he, she, or them.

    "If you can't dazzle them with brilliance, baffle them with...."
    - W.C. Fields



  12. Re: X.509 and ssh

    Nomen Nescio wrote:
    > On 16 Mar 2006 19:01:41 -0500, "Nico Kadel-Garcia"
    >
    >> Hey, I've got her/them killfiled. Notice that the references she/they made
    >> are also, in fact, pretty useless for finding the material she references.
    >> They're just Usenet archives of the previously irrelevant posts on the
    >> subject which don't actually contain any text of the papers she or they are
    >> so excited about being described in, nor does she/they say what the paper
    >> actually said about her/them.

    >
    >
    > Amen. I attempted to peel the garlic onion once or twice and found little
    > more than non sequitur circular references. As you say, it's not even
    > clear if the gibberish originates from a he, she, or them.
    >
    > "If you can't dazzle them with brilliance, baffle them with...."
    > - W.C. Fields
    >
    >


    Bloviating.

    --
    To reply by email remove "_nospam"

  13. Re: X.509 and ssh

    Peter Gutmann wrote:
    > "JKV" writes:
    >
    >> I would like to use it the other way around. All users presenting a X.509
    >> certificate issued by a trusted party can access the server. Then I only
    >> need to install the root certificate of the trusted party on the server and
    >> the user management doesn't need to be done on that server but can be done
    >> independently.

    >
    > Then all you need to do is arrange the small matter of managing a PKI
    > alongside SSH.
    >
    > Somehow I think this isn't going in the right direction :-).
    >
    > Peter.
    >


    I couldn't help but come across this cynical naysayer (habitual at that,
    reading through prior posts).

    "all you need to do is arrange the small matter of managing a PKI
    > alongside SSH"


    As if to say its complicated? Surely, it is, if you don't understand or
    study it -- like anything else.

    As a matter of fact, creating your own CA can be as simple as a few
    openssl commands, or combining them into a couple scripts (one to create
    the CA, another to sign certs), and answering the identification
    questions (even that can be automated). One can issue certificates, or
    sign reqs in mere seconds.

    With a large set of machines, this SURE beats random public keys by
    themselves (which are far, far, FAR more difficult to keep track of)
    when in you are inside of a large organization or computers or otherwise
    have a large number of client machines to administer (image a world
    where https site used only byte/hex string keys). The only time the
    contemporary PKI public key byte/hex string is overall
    easier to use (verify communications) -- is when one only has a few
    machines that need to communicate with each other -- unless some (always
    risky and poor-scalability) trusted-keys replication is used.

    Moreover, x509 certs (and constructed CAs) instantly lend themselves to
    a whole host of other secure AND trust applications, https, ldaps,
    smtps, ftps, imaps (to name a few), mail signing / encryption, software
    signing. When you extend their reach out to all these other forms of
    communication, and used by computer laymen, old-fashioned random public
    key strings is simply not at all feasibile.

    Anyone who claims that that x509 is disadvantaged compared to plain PKI,
    is simply demonstrating that they have no practical or level experience
    with BOTH technologies. That really shows like sore thumb to those of us
    who do have both exeriences.

    The inability to present a balanced view of two arguments is highly
    detrimental only to ones own credibility, especially when combined with
    one-sided cynicism and hyperbole where they are trying to persuade
    undecided minds into adopting their beliefs.

    People aren't truly persuaded by another other single persons opinion -
    they are are much more persuaded by practical experience.

  14. Re: X.509 and ssh

    My deepest, deepest apologies, I misquoted the wrong text and person.
    This was not meant to be directed toward Peter or anyone specifically on
    this thread.

    > Peter Gutmann wrote:
    >> "JKV" writes:
    >>
    >>> I would like to use it the other way around. All users presenting a
    >>> X.509
    >>> certificate issued by a trusted party can access the server. Then I only
    >>> need to install the root certificate of the trusted party on the
    >>> server and
    >>> the user management doesn't need to be done on that server but can
    >>> be done
    >>> independently.

    >>
    >> Then all you need to do is arrange the small matter of managing a PKI
    >> alongside SSH.
    >>
    >> Somehow I think this isn't going in the right direction :-).
    >>
    >> Peter.
    >>

    >
    > I couldn't help but come across this cynical naysayer (habitual at that,
    > reading through prior posts).
    >
    > "all you need to do is arrange the small matter of managing a PKI
    >> alongside SSH"

    >
    > As if to say its complicated? Surely, it is, if you don't understand or
    > study it -- like anything else.
    >
    > As a matter of fact, creating your own CA can be as simple as a few
    > openssl commands, or combining them into a couple scripts (one to create
    > the CA, another to sign certs), and answering the identification
    > questions (even that can be automated). One can issue certificates, or
    > sign reqs in mere seconds.
    >
    > With a large set of machines, this SURE beats random public keys by
    > themselves (which are far, far, FAR more difficult to keep track of)
    > when in you are inside of a large organization or computers or otherwise
    > have a large number of client machines to administer (image a world
    > where https site used only byte/hex string keys). The only time the
    > contemporary PKI public key byte/hex string is overall
    > easier to use (verify communications) -- is when one only has a few
    > machines that need to communicate with each other -- unless some (always
    > risky and poor-scalability) trusted-keys replication is used.
    >
    > Moreover, x509 certs (and constructed CAs) instantly lend themselves to
    > a whole host of other secure AND trust applications, https, ldaps,
    > smtps, ftps, imaps (to name a few), mail signing / encryption, software
    > signing. When you extend their reach out to all these other forms of
    > communication, and used by computer laymen, old-fashioned random public
    > key strings is simply not at all feasibile.
    >
    > Anyone who claims that that x509 is disadvantaged compared to plain PKI,
    > is simply demonstrating that they have no practical or level experience
    > with BOTH technologies. That really shows like sore thumb to those of us
    > who do have both exeriences.
    >
    > The inability to present a balanced view of two arguments is highly
    > detrimental only to ones own credibility, especially when combined with
    > one-sided cynicism and hyperbole where they are trying to persuade
    > undecided minds into adopting their beliefs.
    >
    > People aren't truly persuaded by another other single persons opinion -
    > they are are much more persuaded by practical experience.


  15. Re: X.509 and ssh

    Ken Johanson sez:
    ....
    > As a matter of fact, creating your own CA can be as simple as a few
    > openssl commands, or combining them into a couple scripts (one to create
    > the CA, another to sign certs), and answering the identification
    > questions (even that can be automated). One can issue certificates, or
    > sign reqs in mere seconds.
    >
    > With a large set of machines, this SURE beats random public keys by
    > themselves (which are far, far, FAR more difficult to keep track of)
    > when in you are inside of a large organization or computers or otherwise
    > have a large number of client machines to administer (image a world
    > where https site used only byte/hex string keys).


    That tends to work well when you're your own sysadmin. When you're
    connecting to swervers fubared by other people, it's a different
    story.

    (I'd rather use a self-signed cert than copy authorized_keys all
    over the place every time, myself, but it's my network and I know
    what I'm doing.)

    Dima
    --
    Q276304 - Error Message: Your Password Must Be at Least 18770 Characters
    and Cannot Repeat Any of Your Previous 30689 Passwords -- RISKS 21.37

  16. Re: X.509 and ssh


    Ken Johanson writes:
    > Moreover, x509 certs (and constructed CAs) instantly lend themselves
    > to a whole host of other secure AND trust applications, https,
    > ldaps, smtps, ftps, imaps (to name a few), mail signing /
    > encryption, software signing. When you extend their reach out to all
    > these other forms of communication, and used by computer laymen,
    > old-fashioned random public key strings is simply not at all
    > feasibile.
    >
    > Anyone who claims that that x509 is disadvantaged compared to plain
    > PKI, is simply demonstrating that they have no practical or level
    > experience with BOTH technologies. That really shows like sore thumb
    > to those of us who do have both exeriences.


    one of the issues from x.509 identity certificates from the early 90s
    was the eventual realization that certificates potentially grossly
    overloaded with personal information represented significant privacy
    and liability issues.

    as a result, in the mid-90s you saw the introduction of
    relying-party-only certificates ...
    http://www.garlic.com/~lynn/subpubkey.html#rpo

    where the only unique information in the certificate was some sort of
    account number (that could be used to index a respository where the
    actual entity information resided, including the original issued
    public key information, along with that public key) and a public key.

    an entity created some sort of message or transaction, digitally
    signed the transaction and appended the RPO-certificate. It was
    trivial to show for these scenarios that the appended certificate was
    redundant and superfluous.

    I got a lot of flack in the mid-90s for demonstrating that appending
    such certificate was redundant and superfluous. The conventional
    wisdom at the time was that appendidng certificates was required for
    everything and if you voiced any sort of opposing view, you were a
    heretic doing the work of the devil. One of the lines was about
    appending certificates to retail payment transactions would bring the
    business process into the modern era. My counter-argument was that the
    purpose of appending certificates to payment transactions was to
    provide sufficient information for offline authorization ... and, as
    such was actually a return to the 50s era, predating online
    transactions.

    This is the business process analysis of appended certificates
    following the offline credential model or the letters of
    introduction/credit from the sailing ship days (dating back at least
    several centuries). The credential/certificate paradigm is useful in
    offline scenarios where the relying party.

    1) doesn't have their own information about the other party

    2) doesn't have any online access to trusted authorities for
    information about the other party

    3) must rely on prepackaged, stale, static credential/certificate
    about the other party rather than having online access to realtime
    information

    when we were called in to work with small client/server startup
    that wanted to do payments on their server and had this technology
    called SSL ...
    http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    http://www.garlic.com/~lynn/aadsm5.htm#asrn3

    we had to work out the business process details of using SSL
    technology for payments ... as well as doing walkthru audits of these
    emerging operations calling themselves certification authorities.

    for the original payment gateway, for using SSL between the server and
    the payment gateway (for payment transactions), one of the first
    things we had to do was specify something called mutual authentication
    (which hadn't yet been created for SSL). However, as we flushed out
    the business process of servers interacting with the payment gateway,
    we were keeping tables of authorized merchants and the gateway and
    gateway specificate information loaded at each merchant. By the time
    we were done with the process, it was evident that any certificate use
    was also totally redundent and superfluous (purely a side-effect of
    using the crypto function that were part of the SSL library).

    The payment gateway had registered information (including public keys)
    of all authorized merchants and all authorized merchants had
    configuration information regarding the payment gateway (including its
    public key). There was absolutely no incremental business process
    advantage of appending digital certificates to any of the
    transmissions.

    The other part of stale, static, redundant and superfluous
    certificates, at least related to payment transactions was that a
    typical retail payment transaction is on the order of 60-80 bytes.
    The RPO-certificate overhead from the mid-90s was on the order of
    4k-12k bytes (i.e. appending stale, static, redundant and superfluous
    digital certificates to payment transaction was causing a two orders
    of magnitude payload bloat). Somewhat as a result, there was an
    effort started in the financial standards organization for
    "compressed" digital certificates ... with a goal of reducing the
    4k-12k byte overhead down into the 300 byte range. Part of their
    effort was looking at eliminating all non-unique information from a
    RPO-certificate issued by a financial institution (CPS, misc. other
    stuff). I raised the issue that a perfectly valid compression
    technique was to eliminate all information already in possesion of the
    relying party. Since I could show that the relying party already had
    all possible information in the digital certificate, it was possible
    to reduce the digital certificates. Rather than claiming it was
    redundant and superfluous to attack stale, static digital certificates
    to a transaction, it was possible to show that it was possible to
    attach zero-byte digital certificates to every transaction (for a
    significant reduction in the enormous payload bloat caused by digital
    certificates).

    Another model for certificates ... with respect to thhe emulation of
    credential/certificates in the offline world (where the relying party
    had no other mechanism for establishing information in first time
    communcation with total stranger), was the offline email model from
    the early 80s. The relying party would dialup their local (electronic)
    post office, exchange email, and hangup. They potentially then had to
    deal with frist time email from a total stranger and no way of
    establishing any information about the sender.

    During the early establishment of electronic commerce, I had frequent
    opportunity in exchanges to refer to the merchant digital certificates
    as comfort certificates.

    Stale, static digital certificates are a tangible representation of a
    certification business process. In the offline world, certificates and
    credentials were used as a representation of such certification
    business processes for the relying parties who had no direct access or
    knowledge regarding the original certification process. These stale,
    static certificates and credentials provided a sense of comfort to the
    relying parties that some certification process had actually occured.

    One of the things that appears to have happened with regard to
    physical certificates and credentials ... is that they seemed to have
    taken on some mystical properties totally independent of the
    certification process that they were created to represent. The
    existance of a certificate or credential no convey mystical comfort
    .... even though they purely are required for representation of the
    certification process ... for relying parties that have no other means
    of acquiring information about the certification process.

    Another example of such credentials/certificates taking on mystical
    comfort properties are the diploma mills ... where the pieces of
    parchment produced by diploma mills seem to take on attributes totally
    independent of any educational attainment that the parchment is
    suppose to represent.

    An issue, is that in transition to online paradigm, it is possible for
    relying parties to have direct online real-time access to the
    certified information ... making having to rely on the stale, static
    representations of credentials and certificates, redundant and
    superfluous.

    However, there is an enormous paradigm change from an offline-based
    paradigm ... when the majority of people may still draw great comfort
    from artificial constructs that emulate the offline
    credential/certificate paradigm ... to an online-based paradigm
    dealing with realtime information and realtime business processes.

    One of the big PKI marketing issues has been "trust". However, the
    actual trust has to be in the certification process ... where any
    certificate is purely a stale, static representation of that
    certification process for use by relying parties that have no other
    means of directly accessing the information.

    As the world has migrated to more and more online ... that is somewhat
    pushing the X.509 and PKI operations into market segments that have no
    online mechanisms and/or can't justify the costs associated with
    online operation. However, as online becomes more and more ubiquitous
    and online costs continue to decline, that market segment for x.509
    and PKI operations is rapidly shrinking (needing stale static
    certificates as representation of some certification process for
    relying parties that otherwise don't have direct access to the
    information). Also part of the problem of moving into the no-value
    market segment, is that it becomes difficult to justify any revenue
    flow as part of doing no-value operations.

    a slightly related commented on some of the PKI operations attempting
    to misuse constructs with very specific meaning
    https://www.financialcryptography.co...es/000694.html

    slightly related set of posts on having worked on word smithing both
    the cal. state and federal electronic signature legislation
    http://www.garlic.com/~lynn/subpubkey.html#signature

    a collection of earlier posts in this thread:
    http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#12 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#13 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
    http://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#14 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#27 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#29 X.509 and ssh

    misc. past posts mentioning the enormous benefits of zero byte
    certificates
    http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
    http://www.garlic.com/~lynn/aadsm3.htm#cstech6 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/aadsm8.htm#softpki8 Software for PKI
    http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
    http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
    http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
    http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
    http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
    http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
    http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
    http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
    http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  17. Re: X.509 and ssh

    Anne & Lynn Wheeler wrote:
    > Ken Johanson writes:
    >> Moreover, x509 certs (and constructed CAs) instantly lend themselves
    >> to a whole host of other secure AND trust applications, https,
    >> ldaps, smtps, ftps, imaps (to name a few), mail signing /
    >> encryption, software signing. When you extend their reach out to all
    >> these other forms of communication, and used by computer laymen,
    >> old-fashioned random public key strings is simply not at all
    >> feasibile.
    >>
    >> Anyone who claims that that x509 is disadvantaged compared to plain
    >> PKI, is simply demonstrating that they have no practical or level
    >> experience with BOTH technologies. That really shows like sore thumb
    >> to those of us who do have both exeriences.

    >
    > one of the issues from x.509 identity certificates from the early 90s
    > was the eventual realization that certificates potentially grossly
    > overloaded with personal information represented significant privacy
    > and liability issues.


    "potentially" seem really vague to me the way you use it. The fact is,
    very few fields are actually required by CAs -- and the ones that are
    required are the ones needed to establish the identity being claimed
    (given name, location, email) (to distinguish one John Doe from
    another), and also the endorser cert / chain.

    Put simply, these 'superfluous' (as you claim) fields are nothing, if
    not essential. As essential, as the information you see on another
    person's drivers license or passport -- including the endorser's own
    (should-be) hard-to-duplicate insignia (which btw is far easier to
    duplicate than x509 endorsements)). As essential, as the ID present when
    you conduct an in-person transaction, or get aboard an airplane.

    Do you disagree with this simple premise, that certain minimum
    fields/data are *completely* essential to establish ID and trust? Or can
    I just write you a check for $100 and claim that a1b2c3d4 is my real
    public key / authentication code??

    >
    > as a result, in the mid-90s you saw the introduction of
    > relying-party-only certificates ...
    > http://www.garlic.com/~lynn/subpubkey.html#rpo
    >

    And they fit a very real world need. Delegated/subordinate signing
    authority are fully necessary for scalability reasons. Imagine having to
    go to your country's capital to get a passport.

    > where the only unique information in the certificate was some sort of
    > account number (that could be used to index a respository where the
    > actual entity information resided, including the original issued
    > public key information, along with that public key) and a public key.
    >
    > an entity created some sort of message or transaction, digitally
    > signed the transaction and appended the RPO-certificate. It was
    > trivial to show for these scenarios that the appended certificate was
    > redundant and superfluous.


    But redundant to what? Are you claiming that for each secure message
    that needs to be verified, some traceability (either by session or
    certificate presentation) is NOT needed??

    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?

    >
    > I got a lot of flack in the mid-90s for demonstrating that appending
    > such certificate was redundant and superfluous. The conventional
    > wisdom at the time was that appendidng certificates was required for
    > everything and if you voiced any sort of opposing view, you were a
    > heretic doing the work of the devil.


    I might believe you, given a concrete example.

    One of the lines was about
    > appending certificates to retail payment transactions would bring the
    > business process into the modern era. My counter-argument was that the
    > purpose of appending certificates to payment transactions was to
    > provide sufficient information for offline authorization ... and, as
    > such was actually a return to the 50s era, predating online
    > transactions.


    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.

    >
    > This is the business process analysis of appended certificates
    > following the offline credential model or the letters of
    > introduction/credit from the sailing ship days (dating back at least
    > several centuries). The credential/certificate paradigm is useful in
    > offline scenarios where the relying party.
    >
    > 1) doesn't have their own information about the other party
    >
    > 2) doesn't have any online access to trusted authorities for
    > information about the other party
    >
    > 3) must rely on prepackaged, stale, static credential/certificate
    > about the other party rather than having online access to realtime
    > information
    >
    > when we were called in to work with small client/server startup
    > that wanted to do payments on their server and had this technology
    > called SSL ...
    > http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    > http://www.garlic.com/~lynn/aadsm5.htm#asrn3
    >
    > we had to work out the business process details of using SSL
    > technology for payments ... as well as doing walkthru audits of these
    > emerging operations calling themselves certification authorities.
    >
    > for the original payment gateway, for using SSL between the server and
    > the payment gateway (for payment transactions), one of the first
    > things we had to do was specify something called mutual authentication
    > (which hadn't yet been created for SSL).


    And it is now. In fact its been available for many years ago, and
    happens to be used heavily in finance and government and military
    comms.. But you continually recite these antiquated use scenarios
    instead of something current (I imagine because you wouldn't have a
    sustainable argument against it anymore, or just because you have not
    been recently hired to 'audits' or 'consulting')

    However, as we flushed out
    > the business process of servers interacting with the payment gateway,
    > we were keeping tables of authorized merchants and the gateway and
    > gateway specificate information loaded at each merchant. By the time
    > we were done with the process, it was evident that any certificate use
    > was also totally redundent and superfluous (purely a side-effect of
    > using the crypto function that were part of the SSL library).
    >
    > The payment gateway had registered information (including public keys)
    > of all authorized merchants and all authorized merchants had
    > configuration information regarding the payment gateway (including its
    > public key).


    A daunting - in fact impossible task in the modern world where financial
    and other institutions have hundreds or thousands of third parties to
    deal with. In fact this is a shining example of the value of the x509
    signing model. In the same way that we need appointed govt officials to
    verify and issue (certify) personal *and* businesses identification.

    I think you just disproved your own point by mentioning the existence of
    a registry at each company. Anyone who has truly implemented that model
    on a large scale has become painfully aware of the scalability and
    security problems (decide when to add and revoke compromised keys and
    how validate new ones when the issuer's old one is compromised)

    There was absolutely no incremental business process
    > advantage of appending digital certificates to any of the
    > transmissions.
    >
    > The other part of stale, static, redundant and superfluous
    > certificates, at least related to payment transactions was that a
    > typical retail payment transaction is on the order of 60-80 bytes.
    > The RPO-certificate overhead from the mid-90s was on the order of
    > 4k-12k bytes (i.e. appending stale, static, redundant and superfluous
    > digital certificates to payment transaction was causing a two orders
    > of magnitude payload bloat).


    Your keyword "was" is interesting. Tell me if you think that holds true
    *today*, with SSL/TLS. You *can* answer this just with a simple yes or no.

    Somewhat as a result, there was an
    > effort started in the financial standards organization for
    > "compressed" digital certificates ... with a goal of reducing the
    > 4k-12k byte overhead down into the 300 byte range. Part of their
    > effort was looking at eliminating all non-unique information from a
    > RPO-certificate issued by a financial institution (CPS, misc. other
    > stuff). I raised the issue that a perfectly valid compression
    > technique was to eliminate all information already in possesion of the
    > relying party. Since I could show that the relying party already had
    > all possible information in the digital certificate, it was possible
    > to reduce the digital certificates. Rather than claiming it was
    > redundant and superfluous to attack stale, static digital certificates
    > to a transaction, it was possible to show that it was possible to
    > attach zero-byte digital certificates to every transaction (for a
    > significant reduction in the enormous payload bloat caused by digital
    > certificates).
    >


    So many uses of the word "was"...

    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?

  18. Re: X.509 and ssh

    Ken Johanson writes:
    > "potentially" seem really vague to me the way you use it. The fact is,
    > very few fields are actually required by CAs -- and the ones that are
    > required are the ones needed to establish the identity being claimed
    > (given name, location, email) (to distinguish one John Doe from
    > another), and also the endorser cert / chain.


    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).

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  19. 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).
    >


  20. 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?


    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

    this was the physical world scenario from the 50s ... by the 60s you
    were starting to see (at least) business countermeasure to this scenario
    in the offline market, where business checks had a maximum value limit
    printed on the check (i.e. the check wasn't good if the individual wrote
    it for the limit).

    the embezzler countermeasure was to create a 100 checks for $100 each
    .... in order to get the $10,000 (or 200 checks of $5000 each for $1m).

    the issue was trying to limited the authority of any one individual. an
    individual might have a $1000 total budget ... but trying to control it
    .... they would provide the individual with checks, no one such check
    could exceed $100. The actual problem was to try and keep the individual
    within their budget. The problem with the offline model was that
    individual, single (even authenticated) transactions didn't aggregate.

    This is where you got the online credit card model in the 70s. The
    consumer would do a transaction with the merchant ... and the merchant
    would forward the transaction to the responsible (certifying authority)
    institution for authentication and authorization. The merchant then got
    back a declined or approved response ... indicating the transaction had
    both been authenticated AND authorized (which was significantly more
    valuable to the merchant than just authenticated by itself).

    Because of the various vulnerabilities and exploits in the offline
    credential/certificate model ... you saw businesses moving to online
    business cards sometimes in the 80s ... but definitely by the 90s.
    Instead of an individual being given a stack of checks, they were given
    a corporate payment card. The corporate payment card had online business
    rules associated with it for authorizing financial transactions (in
    addition to authentication). The trivial business rule was whether the
    transaction ran over the aggregated budget (i.e. the individual could do
    any combination of transactions they wanted ... as long as they didn't
    exceed some aggregated limit ... something that is impossible to do with
    the offline, individual operation at a time, credential/certificate
    paradigm).

    One they got the aggregate budget/limit under control ... then they
    could also add other kinds of real-time transaction rules ... use only
    at specific categories of merchants, use only at specific set of
    merchants, use only for specific SKU codes, etc) ... the online paradigm
    not only provides the realtime aggregation function (not possible with
    the old-fashion, offline certificate/credential paradigm) as well as a
    variety of much more sophisticated rules (which can be dynamically
    change by time or other characteristic).

    What you have is the issuing financial institution as the registration
    authority and certifying authority. The financial institution performs
    the public key registration (typically defined as RA functions in the
    traditional Certification Authority paradigm) and then certifies the
    information. However, instead of actually issuing a certificate ... the
    institution specifies that it is only in support of online, realtime
    transactions (since there are numerous kinds of threats, exploits, and
    vulnerabilities that have been eliminated that you typically run into
    when you are dealing with an offline paradigm ... like inability to
    handle aggregated transactions like the 100 $100 check scenario that
    I've repeatedly used a number of times). The individual digitally signs
    their individual transactions that is sent to the merchant ... as in the
    x9.59 financial standard
    http://www.garlic.com/~lynn/x959.html#x959
    http://www.garlic.com/~lynn/subpubkey.html#x959

    it is not necessary to attach a digital certificate since it is required
    that the merchant send it off to the financial institution
    (certification authority) for both authentication (with the onfile
    public key) as well as authorization (does it meet all the business
    rules, including realtime business rule consideration). Since the
    financial institution has the onfile, registered public key for
    verifying the digital signature, it is redundant and superfluous to
    require the attachment of any digital certificate (or at least any
    attach digital certicate with non-zero payload actually carrying any
    real information)

    one of the requirements given the x9a10 working group for the x9.59
    financial standard was to preserve the integrity of the financial
    infrastructure for all retail payments.

    A recent post about various kinds of financial transaction threats if
    forced to fall-back to an offline, credential/certificate operation
    http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new
    tenner (USD10)

    a few misc. past posts showing crooks getting around any per check
    business limit by going to multiple checks (as in your 100 $100 check
    example) ... and the business world countering with real-time, online
    aggregated transaction operation (making the offline
    credential/certificate operation redundant and superfluous).
    http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
    http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
    http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
    http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
    http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
    http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces
    obstacles in PKI security adoption
    http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
    http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
    http://www.garlic.com/~lynn/99.html#240 Attacks on a PKI

    http://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a
    max amount in a X.509v3 certificat e?
    http://www.garlic.com/~lynn/aadsm10.htm#limit2 Q: Where should do I put
    a max amount in a X.509v3 certificate?
    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/aadsm12.htm#20 draft-ietf-pkix-warranty-ext-01
    http://www.garlic.com/~lynn/aadsm12.htm#31 The Bank-model Was: Employee
    Certificates - Security Issues
    http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates -
    Security Issues
    http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
    http://www.garlic.com/~lynn/2001c.html#8 Server authentication
    http://www.garlic.com/~lynn/2001g.html#21 Root certificates

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast