Simple SSL/TLS - Some Questions

[Eric Rescorla]

Jill Ramonsky <Jill.Ramonsky at aculab.com> writes:

> Eric raised some points which I should address. First, he asked me
> "You have read the RFC, right?". Well I guess I should be honest here
> and say no, I hadn't done that yet. Maybe that's where I went wrong,
> and would have asked fewer dumb questions if I had. But rest assured
> everyone, I will digest it thoroughly before trying to implement it!

You'll definitely have to. I think that "SSL and TLS" is pretty
thorough as a protocol book goes, but it's not designed to
let you implement the protocol without reading the RFC.


> He also asked "I'm trying to figure out why you care about this. The
> defined algorithms are good enough for almost all purposes.", and
> "Don't you want to be able to communicate with standard TLS
> implementations? If so, the kind of stuff you seem to want to do will
> in often break that.". To answer the first question, I have to state
> my absolute and sincere belief that if Alice, Bob, Carol, Dave, etc..,
> wish to communicate with each other privately, then it their business
> AND NO-ONE ELSE'S what choice of algorithm(s) they use, etc.. This
> leads inevitably to the conclusion that if a standards body forbids
> this, then the standards body will have to be circumvented. This of
> course leads to the second question, ("Don't you want to be able to
> communicate with standard TLS implementations?"). The answer is
> obvious. /Of course/ one should be able to communicate with standard
> TLS implementations, otherwise the toolkit would be worthless. And of
> course, communicating with other implementations /does /mean strictly
> obeying all the standards. These two positions are not, however,
> mutally exclusive, because what I am putting together is a /toolkit/,
> not an /application/. Application programmers will be able to use the
> toolkit to build standards-compliant applications if they want that,
> or anarchistic applications if they want that. (Of course, anarchistic
> applications will not interoperate with the rest of the world, but
> that's the price you pay for choosing that option, and it's what I
> mean by the phrase "private use by mutually consenting parties").

Uh, this is all sounding very non-simple. Since algorithm negotiation
is one of the things that people generally cite as making TLS too
complicated (not that I agree) I can't see why you'd want to make
it more complicated in this way. Moreover, I would think that
part of making something "for the masses" would be making appropriate
design decisions so that people can't shoot themselves in the
foot. If people are competent to make those decisions then they
should have no trouble figuring out how to use OpenSSL.

        
> GnuTLS (obviously only suitable if it ends up with a Gnu license)

GnuTLS already exists.


> Pretty Good TLS (I stole the idea from PGP obviously, but if this is
> to be "SSL for the masses" then it's not entirely inappropriate)
> 
> ...
> Anyway, all suggestions welcome.
> 
> (3) MULTIPLY SIGNED CERTIFICATES
> 
> A technical question now. (I did look at RFC2246 before asking this,
> but didn't find the answer there). In GPG / PGP, one can have multiply
> signed certificates. It's not called a "certificate" in GPG, it's
> called a signed key, but the priniciple is the same. Alice can get her
> key signed by both Carol and Dave, which has the intended meaning that
> both Carol and Dave vouch for the authenticity of Alice's key. Thus,
> if Bob wishes to send to Alice, he can do so provided he trusts
> /either/ Carol /or/ Dave.
> 
> 
> Can you do this with X.509 certificates? I know it would be hideously
> unusual (not to mention expensive) to get a single certificate signed
> by both Verisign and Thwarte, but can it be done? Is it possible? Is
> it allowed?
This is a PKIX issue. Check out RFC 3280. Anyway, the answer
is "no". A certificate has one signature. The X.509 way to have this
is to have multiple certificates issued for a given DN/key pair.

-Ekr

-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com