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]
AppleID Security
Disclaimer: Yes, I am referenced, but I've been blarting about this for nearly two years now, and nobody's paid the slighest notice before; the matter of making website security both a) easy and b) better can now only become *more* urgent. http://www.theregister.co.uk/2008/07/24/apple_id_fraud/ - alec ps: hello again everyone; long time no see. - 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]
