X.509 and ssh - SSH

This is a discussion on X.509 and ssh - SSH ; Hi, What is the current status of X.509 support in SSH? I know there is support for X.509 under the form of a patch ( http://roumenpetrov.info/openssh ). But as far as I know it's not supported by clients such as ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 20 of 66

Thread: X.509 and ssh

  1. X.509 and ssh


    Hi,

    What is the current status of X.509 support in SSH? I know there is support
    for X.509 under the form of a patch (http://roumenpetrov.info/openssh). But
    as far as I know it's not supported by clients such as PuTTY.

    Thanks,

    Jan



  2. Re: X.509 and ssh

    >>>>> "JKV" == JKV writes:

    JKV> Hi,

    JKV> What is the current status of X.509 support in SSH? I know there
    JKV> is support for X.509 under the form of a patch
    JKV> (http://roumenpetrov.info/openssh). But as far as I know it's not
    JKV> supported by clients such as PuTTY.

    It is best supported in commercial products, such as Tectia (ssh.com) and
    VShell (vandyke.com).

    --
    Richard Silverman
    res@qoxp.net


  3. Re: X.509 and ssh

    "Richard E. Silverman" writes:
    >>>>>> "JKV" == JKV writes:

    > JKV> Hi,


    > JKV> What is the current status of X.509 support in SSH? I know there
    > JKV> is support for X.509 under the form of a patch
    > JKV> (http://roumenpetrov.info/openssh). But as far as I know it's not
    > JKV> supported by clients such as PuTTY.


    >It is best supported in commercial products, such as Tectia (ssh.com) and
    >VShell (vandyke.com).


    It should be mentioned that since the required formats were never properly
    specified in any standards, what's implemented is vendor-specific and
    nonstandard. The only way that something like Putty could support whatever it
    is that the ssh.com and VanDyke implementations do is by reverse-engineering
    the applications.

    Peter.


  4. Re: X.509 and ssh


    "Peter Gutmann" wrote in message
    news:450h8aF48i2uU1@individual.net...
    > "Richard E. Silverman" writes:
    > >>>>>> "JKV" == JKV writes:

    > > JKV> Hi,

    >
    > > JKV> What is the current status of X.509 support in SSH? I know there
    > > JKV> is support for X.509 under the form of a patch
    > > JKV> (http://roumenpetrov.info/openssh). But as far as I know it's

    not
    > > JKV> supported by clients such as PuTTY.

    >
    > >It is best supported in commercial products, such as Tectia (ssh.com) and
    > >VShell (vandyke.com).

    >
    > It should be mentioned that since the required formats were never properly
    > specified in any standards, what's implemented is vendor-specific and
    > nonstandard. The only way that something like Putty could support

    whatever it
    > is that the ssh.com and VanDyke implementations do is by

    reverse-engineering
    > the applications.
    >
    > Peter.
    >


    Is there any effort going on in standardizing the use of X.509 in ssh?

    Thanks,

    Jan




  5. Re: X.509 and ssh

    "JKV" writes:

    >Is there any effort going on in standardizing the use of X.509 in ssh?


    There's an expired RFC draft for this that no-one seems to be terribly
    interested in. As an extension of this, the SSH drafts contained placeholders
    for X.509 for over eight years that were finally removed before they were
    published as RFCs due to lack of interest - SSH was specifically designed to
    not require X.509 (which is one of the contributing reasons for its runaway
    success), so you can forgive the developers for not falling over themselves to
    implement it :-).

    As an even further extension, this question has come up every now and then on
    the SSH list. The response is "If you're really interested in it, write a
    draft RFC", whereupon the person asking the question suddenly decides that
    they're not really that interested in it after all. So I guess I could also
    say "If you're really interested in it, write a draft RFC".

    Peter.


  6. Re: X.509 and ssh

    Latest draft is draft-ietf-secsh-x509-02.txt.

    Also note that Peter Gutmann is against X.509 support in secure shells
    - mail archive on secsh working group clearly show this.


  7. Re: X.509 and ssh

    >>>>> "PG" == Peter Gutmann writes:

    PG> "Richard E. Silverman" writes:
    >>>>>>> "JKV" == JKV writes:

    JKV> Hi,

    JKV> What is the current status of X.509 support in SSH? I know there
    JKV> is support for X.509 under the form of a patch
    JKV> (http://roumenpetrov.info/openssh). But as far as I know it's not
    JKV> supported by clients such as PuTTY.

    >> It is best supported in commercial products, such as Tectia
    >> (ssh.com) and VShell (vandyke.com).


    PG> It should be mentioned that since the required formats were never
    PG> properly specified in any standards, what's implemented is
    PG> vendor-specific and nonstandard. The only way that something like
    PG> Putty could support whatever it is that the ssh.com and VanDyke
    PG> implementations do is by reverse-engineering the applications.

    That's not quite true. Although X.509 is not part of the final SSH-TRANS
    RFC, X.509 key types were defined in earlier drafts (as you note later in
    this thread). Both Tectia and VShell use those key types (x509v3-sign-rsa
    and x509v3-sign-dsa) as specified in that draft, so I don't believe there
    is any need to reverse engineer anything. If you think there is, please
    explain.

    It is true that, since these types are no longer part of the spec, they
    should technically be qualified in use now (e.g. x509v3-sign-rsa@ssh.com).

    --
    Richard Silverman
    res@qoxp.net


  8. Re: X.509 and ssh

    >>>>> "PG" == Peter Gutmann writes:

    PG> "JKV" writes:
    >> Is there any effort going on in standardizing the use of X.509 in
    >> ssh?


    PG> SSH was specifically designed to not require X.509 (which is one
    PG> of the contributing reasons for its runaway success), so you can
    PG> forgive the developers for not falling over themselves to
    PG> implement it :-).

    It is indeed a reason for its early success -- and it is now an impediment
    to its adoption in large organizations. The simple known-hosts file
    mechanism for server authentication is great for getting SSH up and
    running quickly for oneself, or among a small number of hosts. In a
    collection of hundreds or thousands of clients and servers, maintaining
    these lists becomes an impossible and non-scaling task. Maintaining and
    distributing them every time a server is added, removed, or rekeyed
    anywhere in the organization is a nightmare. In fact, it may be
    practically impossible when you consider that implementations represent
    these lists using different formats and mechanisms (e.g. PuTTY uses the
    Windows registry), and many clients are simply not available for updating
    much of the time (e.g. laptops).

    With a standard, distributed trust system such as X.509 PKI, this problem
    simply goes away. It is only necessary to distribute to clients, once, a
    single root certificate under which server hostkey certificates are
    issued. Servers may then be added, removed, or rekeyed at will, with no
    client updates needed. Similar improvements are realized if certificates
    are also used for user authentication, although that entails much more
    overhead and hence is less likely to be necessary or used.

    GSSAPI/Kerberos solves the server authentication problem as well, using a
    different technology, and solves the hostname aliasing problem too (modulo
    security of the DNS). However, it is often not feasible to implement
    Kerberos due to practical limitations of today's networks, such as NAT and
    firewalls. X.509 is much more self-contained.

    Finally, I will note that this definitely is not a theoretical problem. I
    am right now in the process of reviewing SSH usage at my company. It is
    quite likely that we will go with a commercial implementation rather than
    OpenSSH, despite the many advantages of OpenSSH, for precisely this
    reason.

    --
    Richard Silverman
    res@qoxp.net


  9. Re: X.509 and ssh


    "Richard E. Silverman" writes:
    > With a standard, distributed trust system such as X.509 PKI, this problem
    > simply goes away. It is only necessary to distribute to clients, once, a
    > single root certificate under which server hostkey certificates are
    > issued. Servers may then be added, removed, or rekeyed at will, with no
    > client updates needed. Similar improvements are realized if certificates
    > are also used for user authentication, although that entails much more
    > overhead and hence is less likely to be necessary or used.
    >
    > GSSAPI/Kerberos solves the server authentication problem as well, using a
    > different technology, and solves the hostname aliasing problem too (modulo
    > security of the DNS). However, it is often not feasible to implement
    > Kerberos due to practical limitations of today's networks, such as NAT and
    > firewalls. X.509 is much more self-contained.


    aka digital certificates are an analogy to the letters of
    credit/introduction from the sailing ship days where the relying
    parties (clients) otherwise didn't have access to the necessary
    information (either their own local repository or realtime/online
    access to some certifying authority).

    one of the issues from the early 90s with x.509 identity certificates
    and trusted third party PKI certification authorities ... was that the
    TTP/CAs were looking at making the identification useful for relying
    parties helping justify the prices that they would be charging the
    key-owners (for the certificates). not knowing ahead of time ... all
    possibly relying-parties (that might be making use of the
    certificates), there was a tendency to grossly overload the x.509
    identity certificates with personal information (in the hopes that
    majority of future relying parties might find something of use).

    one of the issues going into the mid-90s, was that a dawning
    realization that x.509 identity certificates, grossly overloaded with
    personal information represented significant privacy and liability
    issues.

    the original pk-init draft for kerberos ... simply involved
    registering a public key (in lieu of a password) ... and then
    performing digital signature verification using the onfile public key
    (in place of password matching). I periodically get email from the
    person that claims to have been responsible for pki-based certificates
    added to the pk-init draft, apologizing for not realizing (at the
    time) that it was redundant and superfluous.

    misc past kerberos related posts
    http://www.garlic.com/~lynn/subpubkey.html#kerberos

    when working on the original payment gateway ... there were proposals
    that consumers could register a public key with their certificatoin
    authority ... aka their financial institution and then digitally sign
    the transactions ... for verification by their financial institution
    using the onfile public key. one such is the x9.59 financial standard
    http://www.garlic.com/~lynn/x959.html#x959

    there were also PKI-oriented suggestions that adding digital
    signatures and attached digital certificates to financial transactins
    would modernize financial transactions. the counter observation was
    that the purpose of digital certificates were to allow offline
    verification (i.e. when the relying party didn't have online access to
    the certifying authority) which was the case prior to the
    infrastructure going online in the 70s (aka the certificate-oriented
    proposal was essentially to return to the offline days of 30 years
    earlier).

    again, given that the relying party has their own repository of
    information and/or online access to some certifying authority, then
    the digital certificates were redundant and superfluous. an adequant
    modernization would be to digitally sign the transactions and verify
    the digitally signature with the onfile public keys.

    there was a separate problem with appending digital ceritificates to
    such financial transactions. the typical financial transaction is on
    the order of 60-80 bytes ... and the typical PKI certificate appending
    protocols of the mid-90s added another 4k-12k bytes to the financial
    transaction ... and enormous payload bloat (increase of 100 times) for
    something that was redundant and superfluous.

    for a time, there was a standardization effort in the X9 financial
    standards group looking at creating PKI digital certificates that
    would be on the order of 300 bytes ... eliminating the enormous
    payload penalty for redundant and superfluous digital certificates.
    One approach was itemizing the various fields in a standard digital
    certificate that were common across all digital certificates issued by
    the same financial institution, and then eliminating the redundant
    fields. This would only result in retaining those fields that were
    unique to a specific certificate. However, it was possible to show
    that the financial institution (as both the relying party and the
    certificate issuing party) would be in possesion of all certificate
    fields and therefor it was possible to reduce such digital
    certificates to zero fields and zero bytes ... an enormous improvement
    in the payload bloat associated with appending redundant and
    superfluous digital certificates.

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

  10. Re: X.509 and ssh

    On 2006-02-11, Richard E. Silverman wrote:
    > The simple known-hosts file [snip discussion of x.509 and kerberos
    > as alternatives to static known hosts files]


    There's another option not mentioned, and it is a (proposed) standard:
    SSH fingerprints via DNS, RFC4255. It needs a secure DNS to be useful,
    and only helps with known hosts, though.

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  11. Re: X.509 and ssh

    >>>>> "DT" == Darren Tucker writes:

    DT> On 2006-02-11, Richard E. Silverman wrote:
    >> The simple known-hosts file [snip discussion of x.509 and kerberos
    >> as alternatives to static known hosts files]


    DT> There's another option not mentioned, and it is a (proposed)
    DT> standard: SSH fingerprints via DNS, RFC4255. It needs a secure
    DT> DNS to be useful, and only helps with known hosts, though.

    Good point; thanks. I'm not sure what you mean by "only helps with known
    hosts," though; could you clarify?

    I should also have pointed out that Kerberos server authentication (a
    GSSAPI key exchange) is not available in OpenSSH per se, but rather in
    some derived versions (such as the Debian ssh-krb5 package).

    --
    Richard Silverman
    res@qoxp.net


  12. Re: X.509 and ssh

    On 2006-02-12, Richard E. Silverman wrote:
    >>>>>> "DT" == Darren Tucker writes:

    > DT> There's another option not mentioned, and it is a (proposed)
    > DT> standard: SSH fingerprints via DNS, RFC4255. It needs a secure
    > DT> DNS to be useful, and only helps with known hosts, though.
    >
    > Good point; thanks. I'm not sure what you mean by "only helps with known
    > hosts," though; could you clarify?


    You can't use it to centralise, eg, authorized_keys.

    To achieve the same effect as, eg, kerberos single sign on you would
    still need to distribute authorized_keys files to the relevant servers.

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  13. Re: X.509 and ssh

    >>>>> "DT" == Darren Tucker writes:

    DT> On 2006-02-12, Richard E. Silverman wrote:
    >>>>>>> "DT" == Darren Tucker writes:

    DT> There's another option not mentioned, and it is a (proposed)
    DT> standard: SSH fingerprints via DNS, RFC4255. It needs a secure
    DT> DNS to be useful, and only helps with known hosts, though.
    >> Good point; thanks. I'm not sure what you mean by "only helps
    >> with known hosts," though; could you clarify?


    DT> You can't use it to centralise, eg, authorized_keys.

    DT> To achieve the same effect as, eg, kerberos single sign on you
    DT> would still need to distribute authorized_keys files to the
    DT> relevant servers.

    Oh, you mean it doesn't help with user authentication. Yes; I was only
    talking about server auth.

    --
    Richard Silverman
    res@qoxp.net


  14. Re: X.509 and ssh

    Richard E. Silverman wrote:
    >>>>>> "PG" == Peter Gutmann writes:

    >
    > PG> "JKV" writes:
    > >> Is there any effort going on in standardizing the use of X.509 in
    > >> ssh?

    >
    > PG> SSH was specifically designed to not require X.509 (which is one
    > PG> of the contributing reasons for its runaway success), so you can
    > PG> forgive the developers for not falling over themselves to
    > PG> implement it :-).
    >
    > It is indeed a reason for its early success -- and it is now an impediment
    > to its adoption in large organizations. The simple known-hosts file
    > mechanism for server authentication is great for getting SSH up and
    > running quickly for oneself, or among a small number of hosts. In a
    > collection of hundreds or thousands of clients and servers, maintaining
    > these lists becomes an impossible and non-scaling task. Maintaining and
    > distributing them every time a server is added, removed, or rekeyed
    > anywhere in the organization is a nightmare. In fact, it may be
    > practically impossible when you consider that implementations represent
    > these lists using different formats and mechanisms (e.g. PuTTY uses the
    > Windows registry), and many clients are simply not available for updating
    > much of the time (e.g. laptops).
    >
    > With a standard, distributed trust system such as X.509 PKI, this problem
    > simply goes away. It is only necessary to distribute to clients, once, a
    > single root certificate under which server hostkey certificates are
    > issued. Servers may then be added, removed, or rekeyed at will, with no
    > client updates needed. Similar improvements are realized if certificates
    > are also used for user authentication, although that entails much more
    > overhead and hence is less likely to be necessary or used.
    >
    > GSSAPI/Kerberos solves the server authentication problem as well, using a
    > different technology, and solves the hostname aliasing problem too (modulo
    > security of the DNS). However, it is often not feasible to implement
    > Kerberos due to practical limitations of today's networks, such as NAT and
    > firewalls. X.509 is much more self-contained.
    >
    > Finally, I will note that this definitely is not a theoretical problem. I
    > am right now in the process of reviewing SSH usage at my company. It is
    > quite likely that we will go with a commercial implementation rather than
    > OpenSSH, despite the many advantages of OpenSSH, for precisely this
    > reason.
    >


    Couldn't something be built into the protocol to distribute known_hosts?
    For example I connect to server X, it's fingerprint matches the one I
    have on file, therefore I trust it and it pushes down a list of all the
    hosts it trusts? If there are any new ones, I get them the next time I
    connect to the server.

    --
    To reply by email remove "_nospam"

  15. Re: X.509 and ssh

    Chuck writes:
    > Couldn't something be built into the protocol to distribute known_hosts?
    > For example I connect to server X, it's fingerprint matches the one I
    > have on file, therefore I trust it and it pushes down a list of all the
    > hosts it trusts? If there are any new ones, I get them the next time I
    > connect to the server.


    basically all the public key oriented authentication schemes is
    dependent on having a local trusted repository of public keys and what
    they are associated with. this is true even for PKI x.509
    infrastructures ... although in the PKI case, the repository may be
    significantly obfuscated and almost cloaded in mysticism.

    the PKI case may have all sorts of obstructions involved with dealing
    with any local tursted public key repository and/or adding new entries
    to the repository ... where an attempt is made in both software and
    policy that only certain privileged entities known as "certification
    authorities" have their trusted public keys in your repository.

    another variation is secure DNS. basically almost any kind of
    information can be registered with the domain name infrastructure and
    distributed ... including lots of infrastructure for local caching of
    that information. basically secure DNS would do what you describe ...
    if public keys were registered in domain name infrastructure.

    one of the issues that i've observed with the SSL domain name server
    certificates is that the PKI certification authority industry has
    somewhat sponsored secure DNS and registration of public keys.

    the issue is that frequently that somebody reguests a SSL domain name
    server certificate from a certification authority ... and must supply
    a bunch of identification information. the certification authority
    then must validate the supplied identification information corresponds
    to the identification information onfile with the domain name
    infrastructure (for that domain name owner). this is a time-consuming,
    expensive and error-prone process.

    note however, there have been various vulnerabilities with the domain
    name infrastructure like domain name hijacking ... which puts at risk
    the certification process done by the PKI certification authorities.
    So somewhat to improve the integrity of domain name infrastructure
    (and therefor the certification done by PKI certificatio authorities),
    the proposal is that domain name owners register their public key when
    they register a domain name.

    this also offers an opportunity for the PKI certification authorities,
    they now can require that SSL domain name certificate applications be
    digital signed by the applicant. Then the PKI certificaiton authority
    can replace their time-consuming, error-prone and expensive
    identification process with a much simpler, more reliable, and less
    expensive authentication process by doing a real-time retrieval of the
    domain name owner's public key and verifying the digital signature
    attached to the SSL domain name certificate application.

    This significantly enhancing the business process of the PKI
    certification authorities as well as the integrity of the domain name
    infrastructure (which the PKI certification authorities are dependent
    on for their certifications). The catch-22 or downside is that if the
    PKI certification authorities can do real-time retrieval of onfile
    public keys for verifying digital signatures ... then it is possible
    that the rest of the world could start doing it also ... which in turn
    could make any SSL domain name certificates redundent and superfluous.

    Furthermore, one could imagine that such secure DNS implementation (of
    real-time retrieval of onfile trusted public keys) could have the
    local caching implementation slightly enhanced to interoperate with
    any local repository of trusted public keys ... and integrated with
    something like the PGP-like user interface allowing users to provide
    optional trust ratings for any public keys in their local repository
    of trusted public keys.

    misc. past posts on SSL domain name server certificates
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    one suggestion for an enhancement to the SSL protocol is to allow any
    public key and associated crypto-protocol options to be piggybacked on
    the domain name infrastructure response to request for a server's
    ip-address. then the client has the server's public key in the same
    response that it acquires the server's ip-address. the client could
    then do the session key generation, encode it with the server's public
    key and transmit it in the initial encrypted session setup
    .... eliminating all the upfront SSL session protocol chatter. One
    could even imagine it being done for a single round-trip transaction
    protocol ... say using something like UDP.

    the client currently is able to cache ip-address response from the
    domain name infrastructure ... so one could imagine that any public
    key responses could be cached similar. with some enhancements, such
    public key responses could be even given longer cached lifetimes (say
    in the local trusted public key repository).

    basically ... using the existing domain name infrastructure real-time
    information distribution and caching mechanism ... and eliminating the
    need for PKI stale, static, redundant and superfluous (x.509 or other)
    certificate-based operations.

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

  16. Re: X.509 and ssh

    Anne & Lynn Wheeler wrote:

    [lots of stuff snipped]

    > local trusted public key repository).
    >
    > basically ... using the existing domain name infrastructure real-time
    > information distribution and caching mechanism ... and eliminating the
    > need for PKI stale, static, redundant and superfluous (x.509 or other)
    > certificate-based operations.
    >


    I like it. I really like it. Is this just at the proposal stage or is it
    actually being implemented somewhere?

    --
    To reply by email remove "_nospam"

  17. Re: X.509 and ssh

    Chuck writes:
    > I like it. I really like it. Is this just at the proposal stage or is it
    > actually being implemented somewhere?


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

    i think that the PKI/CA forces are quite ambivalent about it ... on
    the one hand they need the public key registration as part of overall
    improving the integrity of the domain name infrastructure (which they
    are dependent on when they go thru the business process of certifying
    the domain name owner, before issueing the digital certificate
    represented that they had done the appropriate certification).

    They can also use real-time retrieval of the onfile, registered public
    key to move from the error-prone, time-consuming, and expensive
    identification process to a much simpler, less expensive, and more
    reliable authentication process.

    however, opening up real-time retrieval of onfile, registered public
    keys is a pandoras box for them since it leads down the trail of
    obsoleting the stale, static, redundant and superfluous certificates.

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

  18. Re: X.509 and ssh

    Anne & Lynn Wheeler wrote:
    > Chuck writes:
    >> I like it. I really like it. Is this just at the proposal stage or is it
    >> actually being implemented somewhere?

    >
    > ref:
    > http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
    >
    > i think that the PKI/CA forces are quite ambivalent about it ... on
    > the one hand they need the public key registration as part of overall
    > improving the integrity of the domain name infrastructure (which they
    > are dependent on when they go thru the business process of certifying
    > the domain name owner, before issueing the digital certificate
    > represented that they had done the appropriate certification).
    >
    > They can also use real-time retrieval of the onfile, registered public
    > key to move from the error-prone, time-consuming, and expensive
    > identification process to a much simpler, less expensive, and more
    > reliable authentication process.
    >
    > however, opening up real-time retrieval of onfile, registered public
    > keys is a pandoras box for them since it leads down the trail of
    > obsoleting the stale, static, redundant and superfluous certificates.
    >


    If I were a CA I would NOT be pushing for this at all. What good would
    it be to me to speed up the certification process if it eliminates me in
    the end? Or perhaps they will simply get into the domain registration
    business.




    --
    To reply by email remove "_nospam"

  19. Re: X.509 and ssh

    Chuck writes:
    > If I were a CA I would NOT be pushing for this at all. What good would
    > it be to me to speed up the certification process if it eliminates me in
    > the end? Or perhaps they will simply get into the domain registration
    > business.


    ref:
    http://www.garlic.com/~lynn/2006b.html#57 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

    the part about making it cheaper, more reliable, and less
    time-consuming by verifying a digital signature on a certificate
    application (by doing a real-time retrieval of onfile, registered
    public key) ... is somewhat incidental to the real objective of
    improving the overall integrity of the domain name infrastructure.

    by having a public key registered as part of domain name registration
    .... then all future communication between the domain name owner and
    the domain name infrastructure can be digitally signed (and validated)
    .... which helps to reduce things like domain name hijacking.

    fundamentally, a digital certificate (or any other physical license,
    credential, etc) is a stale, static, locally cached representation of
    some certification process. in the case of ssl domain name
    certificates, the certification includes certifying that the entity
    requesting the ssl domain name certificate is the domain name owner.

    if there are integrity issues with the domain name infrastructure with
    regard to the true owner of a domain name (from exploits like domain
    name hijacking) then the trust root for the whole ssl domain name
    pki/certificate infrastructure (the information on file as to the
    identity of the true domain name owner) is at risk ... aka attacker
    creates a dummy front company, hijacks the domain name, and then
    applies for a ssl domain name digital certificate ... and succesfully
    is issued a ssl domain name digital certificate ... because the
    attacker is, in fact, the current, onfile, registered owner of the
    domain name. for more information use one of the search engines to
    find a lot more about (even recent) domain name hijacking exploits.

    the monkey wrench in this whole scheme is the domain name
    infrastructure being fundamentally a real-time trusted information
    distribution implementation. if there are registered public keys in
    the domain name infrastructure ... then it is possible for the domain
    name infrastructure to also provide trusted, real-time distribution of
    any and all information on file.

    i've frequently asserted that real-time distribution of trusted
    information is orders of magnitude perferred to using stale, static
    redundant and superfluous digital certificates.

    in effect, digital certificates are paradigm analogous to the letters
    of credit/introduction from the sailing ship days ... where they
    substituted for the relying party having either their own information
    (about the subject in question) and/or direct communication with some
    recognized authority. over the centuries,
    credential/license/certificates have acted as substitutes for direct
    knowledge and/or direct communication. however, as infrastructures
    migrate to online, all-the-time operations ... direct communication is
    available ... and the credentials/licenses/certificates substitutes
    are becoming more and more redundant and superfluous.

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

  20. Re: X.509 and ssh

    "Richard E. Silverman" wrote in message
    news:m2pslto3v8.fsf@darwin.oankali.net...
    >
    > With a standard, distributed trust system such as X.509 PKI, this problem
    > simply goes away. It is only necessary to distribute to clients, once, a
    > single root certificate under which server hostkey certificates are
    > issued. Servers may then be added, removed, or rekeyed at will, with no
    > client updates needed. Similar improvements are realized if certificates
    > are also used for user authentication, although that entails much more
    > overhead and hence is less likely to be necessary or used.
    >

    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.

    Jan



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