Re: The PKC-only application security model ...
Nicolas Williams <[EMAIL PROTECTED]> writes: Advice on how to generate self-signed certs for this purpose would be good for an FYI, or even a BCP. I don't think we need extensions to any protocols that support PKI to support bare PK (though some protocols have both, e.g., IKE). It's been around for nearly a decade, see http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Thierry Moreau wrote: In draft-ietf-sip-dtls-srtp-framework, the detailed scheme uses self-signed certificates created by client end-entities themselves. The basic idea is identical. At the detailed level in my document, the client end-entity "auto-issues" a security certificate with a "breached" CA private key. In the TLS Certificate request message, a list of CA distinguished names is provided to the end entity. Referring to a "breached" CA public key is an invitation to submit a meaningless end-entity certificate, making the detailed scheme "more plain" with respect to TLS options (i.e. an empty list in a certificate request message could be a not so well supported mode in TLS software implementations). So, maybe the reference to the notion of self-signed EE certificates in draft-ietf-sip-dtls-srtp-framework could be replaced by "meaningless EE certificates" (or something else), which would include both self-signed or auto-issued. In such a case, the RFC publication for my document would become more pressing. A related discussion occurred on the IETK PKIX mailing list in June 2008 under the subject "RFC 5280 Question". re: http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model http://www.garlic.com/~lynn/2008k.html#51 The PKC-only application security model another approach that X9 financial standard organization took to attempt the enormous digital certificate bloat was standards effort for "compressed" digital signature ... possibly reducing 100-times bloat to possibly only 5 to 10 times bloat. There was some conjecture that such "lightweight" digital certificates might also find place in wireless applications. part of compression effort was to recognize that the server already had much of the information was exactly the same in every certificate and/or the server already possessed. I raised the issue (rather than harping on the theme that digital certificates being redundant and superfluous ... besides 100 times bloat) that (for all the situations they were looking at) the server already had all the information in a digital certificate. Therefor, it would be possible to define a new class of zero byte digital certificates that would be appended to every digitally signed transaction. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Tom Scavo wrote: On Wed, Jul 23, 2008 at 6:32 PM, Thierry Moreau <[EMAIL PROTECTED]> wrote: The document I published on my web site today is focused on fielding certificateless public operations with the TLS protocol which does not support client public keys without certificates - hence the meaningless security certificate. As such, your document is directly applicable to a proposed standard that is now winding its way through the OASIS process: http://wiki.oasis-open.org/security/SamlHoKWebSSOProfile The proponents of this variant of SAML Web Browser SSO have no interest in an online database of public keys, but your profile is relevant nonetheless, for its interoperability aspects. Thanks, I will look into this. You mentioned earlier that this may become an IETF RFC. Do I take this to mean that your company holds no patent, copyright, trademark or license rights that would prevent us from relying on your profile? Neither patent nor patent application for the matter contained in the referenced document. -- - Thierry Moreau - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Eric Rescorla wrote: At Wed, 23 Jul 2008 17:32:02 -0500, Thierry Moreau wrote: Anne & Lynn Wheeler wrote about various flavors of certificateless public key operation in various standards, notably in the financial industry. Thanks for reporting those. No doubt that certificateless public key operation is neither new nor absence from today's scene. The document I published on my web site today is focused on fielding certificateless public operations with the TLS protocol which does not support client public keys without certificates - hence the meaningless security certificate. Nothing fancy in this technique, just a small contribution with the hope to facilitate the use of client-side PKC. DTLS-SRTP (http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework-02, http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp) uses a similar technique: certificates solely as a key carrier authenticated by an out-of-band exchange. In draft-ietf-sip-dtls-srtp-framework, the detailed scheme uses self-signed certificates created by client end-entities themselves. The basic idea is identical. At the detailed level in my document, the client end-entity "auto-issues" a security certificate with a "breached" CA private key. In the TLS Certificate request message, a list of CA distinguished names is provided to the end entity. Referring to a "breached" CA public key is an invitation to submit a meaningless end-entity certificate, making the detailed scheme "more plain" with respect to TLS options (i.e. an empty list in a certificate request message could be a not so well supported mode in TLS software implementations). So, maybe the reference to the notion of self-signed EE certificates in draft-ietf-sip-dtls-srtp-framework could be replaced by "meaningless EE certificates" (or something else), which would include both self-signed or auto-issued. In such a case, the RFC publication for my document would become more pressing. A related discussion occurred on the IETK PKIX mailing list in June 2008 under the subject "RFC 5280 Question". Regards, -- - Thierry Moreau - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
On Wed, Jul 23, 2008 at 6:32 PM, Thierry Moreau <[EMAIL PROTECTED]> wrote: > > The document I published on my web site today is focused on fielding > certificateless public operations with the TLS protocol which does not > support client public keys without certificates - hence the meaningless > security certificate. As such, your document is directly applicable to a proposed standard that is now winding its way through the OASIS process: http://wiki.oasis-open.org/security/SamlHoKWebSSOProfile The proponents of this variant of SAML Web Browser SSO have no interest in an online database of public keys, but your profile is relevant nonetheless, for its interoperability aspects. You mentioned earlier that this may become an IETF RFC. Do I take this to mean that your company holds no patent, copyright, trademark or license rights that would prevent us from relying on your profile? Thanks, Tom Scavo NCSA - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
At Wed, 23 Jul 2008 17:32:02 -0500, Thierry Moreau wrote: > > > > Anne & Lynn Wheeler wrote about various flavors of certificateless > public key operation in various standards, notably in the financial > industry. > > Thanks for reporting those. > > No doubt that certificateless public key operation is neither new nor > absence from today's scene. > > The document I published on my web site today is focused on fielding > certificateless public operations with the TLS protocol which does not > support client public keys without certificates - hence the meaningless > security certificate. Nothing fancy in this technique, just a small > contribution with the hope to facilitate the use of client-side PKC. DTLS-SRTP (http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework-02, http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp) uses a similar technique: certificates solely as a key carrier authenticated by an out-of-band exchange. -Ekr - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Thierry Moreau wrote: Anne & Lynn Wheeler wrote about various flavors of certificateless public key operation in various standards, notably in the financial industry. Thanks for reporting those. No doubt that certificateless public key operation is neither new nor absence from today's scene. The document I published on my web site today is focused on fielding certificateless public operations with the TLS protocol which does not support client public keys without certificates - hence the meaningless security certificate. Nothing fancy in this technique, just a small contribution with the hope to facilitate the use of client-side PKC. this post references scenario for replacing the SSL server domain name certificates with a certificate-less public key infrastructure http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model the first reply http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model mentions certificate-less X9.59 (financial transaction), certificate-less KERBEROS (large number of infrastructure and application authentication operation) and certificate-less RADIUS (possibly dominant client authentication infrastructure in the world today used by lots of ISP, corporate intranets, webhosting operations, etc). RADIUS provides a generalized authentication, authorization, and accounting infrastructure ... where AAA specifics can be specified on an account or client basis (i.e. including being able to easily accomodating both password and public key concurrently). http://www.garlic.com/~lynn/subpubkey.html#radius There are even RADIUS "plug-ins" for webservers for doing webserver client authentication. A combination of replacing SSL server domain name certificates with certificate-less server operation and and using certifcate-less RADIUS (client) authentication ... covers mutual (client & server) operation. RADIUS references from our rfc index: http://www.garlic.com/~lynn/rfcietff.htm click on "Term (term->RFC#)" field and then click on "RADIUS" (in the "Acronym fastpath"): Remote authentication dial in user service (RADIUS) see also authentication , network access server , network services 5176 5090 5080 5030 4849 4818 4679 4675 4673 4672 4671 4670 4669 4668 4603 4590 4372 4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058 clicking on any of the RFC numbers, retrieves the RFC summary in the lower frame. Clicking on the ".txt=nnn" field (in a RFC summary) retrieves the actual RFC. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
On Wed, Jul 23, 2008 at 05:32:02PM -0500, Thierry Moreau wrote: > The document I published on my web site today is focused on fielding > certificateless public operations with the TLS protocol which does not > support client public keys without certificates - hence the meaningless > security certificate. Nothing fancy in this technique, just a small > contribution with the hope to facilitate the use of client-side PKC. Advice on how to generate self-signed certs for this purpose would be good for an FYI, or even a BCP. I don't think we need extensions to any protocols that support PKI to support bare PK (though some protocols have both, e.g., IKE). Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Anne & Lynn Wheeler wrote about various flavors of certificateless public key operation in various standards, notably in the financial industry. Thanks for reporting those. No doubt that certificateless public key operation is neither new nor absence from today's scene. The document I published on my web site today is focused on fielding certificateless public operations with the TLS protocol which does not support client public keys without certificates - hence the meaningless security certificate. Nothing fancy in this technique, just a small contribution with the hope to facilitate the use of client-side PKC. - Thierry Moreau - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Thierry Moreau wrote: A)The big picture refers to the "PKC-only application security scheme", in which client-server applications may be secured with client-side public key pairs, but *no trusted certification authority* is involved (server operators are expected to maintain a trusted database of their clients' public keys). original PK-init (public key) draft for Kerberos was (only) certificateless public key operation ... i.e. kerberos server operators maintaining trusted database of their clients' public keys (in lieu of passwords) ... PKI/certificate mode of operation was eventually added to the specification. lots of past posts about certificateless public key kerberos http://www.garlic.com/~lynn/subpubkey.html#kerberos similar implementation was done for RADIUS http://www.garlic.com/~lynn/subpubkey.html#radius general posts about certificateless (sometimes "naked") public key http://www.garlic.com/~lynn/subpubkey.html#certless X9.59 is financial transaction standard also using certificateless public key operation http://www.garlic.com/~lynn/x959.html#x959 part of the issue was that in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. One of the issues for x9.59 was that it had to be lightweight enough to operate in existing infrastructures. Some of the certificate-oriented payment transaction standards from the period resulted in factor of 100 times (two orders of magnitude) payload (i.e. certificate payload overhead could be 100 times larger than basic payment transaction) and processing (i.e. certificate processing overhead could be 100 times larger than basic payment transaction) bloat http://www.garlic.com/~lynn/subpubkey.html#bloat general discussions of the "account authority public key" model (as contrast to "certification authority public key" model) http://www.garlic.com/~lynn/x959.html#aads - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]