[128824] in cryptography@c2.net mail archive
Re: The PKC-only application security model ...
daemon@ATHENA.MIT.EDU (Thierry Moreau)
Thu Jul 24 15:33:52 2008
Date: Thu, 24 Jul 2008 06:42:57 -0500
From: Thierry Moreau <thierry.moreau@connotech.com>
To: Eric Rescorla <ekr@networkresonance.com>
CC: Anne & Lynn Wheeler <lynn@garlic.com>,
Cryptography List <cryptography@metzdowd.com>
In-Reply-To: <20080724014547.C87EE4A1C1C@kilo.rtfm.com>
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 majordomo@metzdowd.com
