BTW: I played with the CA:true / CA:false extensions and it doesn't seem that OpenSSL in Dispatch really cares about them.
On Mon, Aug 31, 2015 at 9:32 AM, Jakub Scholz <[email protected]> wrote: > Hi Cliff, > > Yes, you perfectly described how we use the NSS database in qpidd today. > > I was wondering whether the CA:false and CA:true can play a role. I will > test it to see. > > The idea of using the intermediate CAs to avoid the revocation list is > interesting, I didn't though about it before, but it sounds like an elegant > solution. The problem is that using custom CA and sign the certificates for > few hundred customers is often quite painful. On the other hand, the self > signed certificates also cause trouble here and there, so maybe it is > really time to get rid of them. > > Thanks & Regards > Jakub > > On Sun, Aug 30, 2015 at 9:13 PM, Cliff Jansen <[email protected]> > wrote: > >> Hi Jacob, >> >> I believe you have been using the NSS trustargs to do special >> authentication configuration. Something like assign "T" to a dummy >> cert and store client certificates in your list of CAs with an >> appropriate trustarg so that they could validate as a leaf certificate >> only and not as an intermediate CA (signing arbitrary credentials). >> >> Proton's trustedCerts can get you part way there, but I'm not >> convinced of the rest is possible. NSS uses the trustargs attribute >> to augment or override attributes on the certificates themselves. To >> the best of my knowledge OpenSSL and Java crypto only use the >> attributes contained in the actual certificate (Windows certificates >> can have limited different meaning depending on which store they live >> in). >> >> In theory, you can require the self-signed certs that you use to have >> the proper X509v3 extensions that correspond to the NSS trustargs you >> rely on, otherwise you reject them as malformed before you insert them >> in your CA database. The extensions would presumably be: >> >> Basic constraint: CA:false (critical) >> Key usage: Digital signature/key encipherment (critical) >> Extended key usage: TLS Web Client Auth (only, no signing) >> >> That may work as you intend for OpenSSL and Dispatch. >> >> However, I do not recommend this as your preferred approach. The fly >> in the ointment is RFC5280 section 6.2 which essentially says: the >> rules in this RFC are deliberately murky when using self-signed certs >> as CA's... implementations can do what they want. >> >> >> As an alternative that works more within stricter rfc5280 rules, >> perhaps you could do something like: >> >> You become the root certificate authority >> Users send you a CSR >> You create a unique intermediate CA for each user from the root >> Use this CA to sign this one CSR using the constraints you like >> Import each intermediate CA into your CA database but not the root >> >> Here a stolen user private key cannot be used to create fake >> credentials. You can remove the intermediate CA at will to revoke the >> client certificate (without using the formal revocation list >> mechanism). Predictable rfc5280 validation will occur on all >> platforms. Disclaimer: I haven't actually tried this and I'm mostly >> guessing at your use case. But I do worry that using self-signed >> certificates as you currently do will require reworking all your >> certificates each time you add a future component (Java broker, >> Windows thingamajig). >> >> Cliff >> >> On Fri, Aug 28, 2015 at 6:54 AM, Jakub Scholz <[email protected]> wrote: >> > Thanks for the clarification regarding the certificate databases. As I >> see >> > it, the trustedCerts might be useful in case you don't use CAs but >> directly >> > the end user certificates. This is what I usually use with self-signed >> > certificates. In such case you don't wont to have them all listed during >> > the SSL handshake, because each certificate = user account. So one can >> use >> > the trustedCerts to override it. That is nice. >> > >> > However, that brings me to another question ... the C++ broker is using >> the >> > NSS library which distinguishes between trusted peer (only the trusted >> peer >> > it self can connect, certificates signed by the peer will be rejected) >> and >> > trusted CA (certificates signed by the trusted CA can connect). Do you >> have >> > by coincidence an idea how Proton / OpenSSL deals with this? There is no >> > trusted peer / CA flag in the certDb. >> > >> > Thanks & Regards >> > Jakub >> > >> > On Tue, Aug 25, 2015 at 8:19 PM, Cliff Jansen <[email protected]> >> wrote: >> > >> >> The certDb (proton: >> >> pn_ssl_domain_t::pn_ssl_domain_trusted_certificate_db) is the >> >> database/collection/store of CA certificates which are used to >> >> validate the authenticity of the peer's certificate (client or >> >> server). For self signed certificates, at least the public portion of >> >> the certificate itself must be in the database (since it is its own >> >> CA). >> >> >> >> The trustedCerts (proton >> >> pn_ssl_domain_t::pn_ssl_domain_set_peer_authentication) is a >> >> server-only attribute specifying the list of CA's that will be >> >> included in the "client certificate request" portion of the first SSL >> >> handshake packet from the server to the client. In theory, Proton >> >> could allow the application examine this list and provide its >> >> preferred client certificate for that server, but it currently >> >> requires a single certificate to be specified before socket creation, >> >> and it does not change during SSL negotiation. Proton could also >> >> allow the server to change the list based on the client's IP address >> >> or other client hello context, but again the value is fixed before >> >> listener socket creation. >> >> >> >> I am not sure if there is a good use case to specify the two with >> >> different values for messaging applications requiring client >> >> certificates, but the ability is there for the static case. They are >> >> separately (and dynamically between handshake stages) configurable in >> >> both OpenSSL and SChannel, so it is clear some SSL applications need >> >> the flexibility. >> >> >> >> On Mon, Aug 24, 2015 at 7:58 PM, Ted Ross <[email protected]> wrote: >> >> > >> >> > >> >> > On 08/19/2015 11:15 AM, Jakub Scholz wrote: >> >> >> >> >> >> I spent some time playing with Qpid Dispatch (0.4) in combination >> with >> >> >> Qpid >> >> >> C++ broker. I was impressed about what it does already. Big +1 to >> >> everyone >> >> >> involved. >> >> >> >> >> >> I still run into some issues / limitations / questions ... maybe >> someone >> >> >> can help with them ... >> >> >> >> >> >> 1) Is there some technical reason why the linkRoutePattern isn't >> allowed >> >> >> to >> >> >> contain any periods (well, apart the one at the end) and why it has >> to >> >> end >> >> >> with a period? In my use case, almost every address name contains >> >> several >> >> >> periods in it and in many cases the important part in the address is >> >> only >> >> >> after the last period. So it would be very useful to be able to use >> >> >> multiple periods in the linkRoutePattern prefix and to be not >> required >> >> to >> >> >> end the prefix with a period. >> >> > >> >> > >> >> > There is no technical reason for this limitation. It was done for >> >> > expediency to prove the link-routing concept. This should be >> expanded to >> >> > match any pattern. >> >> > >> >> >> >> >> >> 2) The Listener allows to configure the certDB and trustedCert >> >> parameters. >> >> >> I thought that one is for CAs and one is for self signed >> certificates. >> >> But >> >> >> it doesn't seem to be that easy. Can someone explain how are they >> >> supposed >> >> >> to work? >> >> > >> >> > >> >> > This functionality comes straight from Proton. It is my >> understanding >> >> that >> >> > certDB can be for CAs or self-signed certs. The trustedCert >> parameter >> >> can >> >> > be used to constrain the set of certificates in the DB that are >> >> considered >> >> > trusted for this listener. >> >> > >> >> > Perhaps someone else can provide some more clarity. >> >> > >> >> >> >> >> >> 3) In the configuration file, what is the relation between "router", >> >> >> "container", "listener" and "connector"? Is there some kind of >> hierarchy >> >> >> between them? It almost seems that "router" and "container" are >> entities >> >> >> which always apply to the whole Dispatch process and can be used >> only >> >> >> once. >> >> >> Is that correct? >> >> > >> >> > >> >> > That is correct. In fact, we plan to combine the configuration in >> >> > "container" and "router" into a single section (probably router) to >> >> reduce >> >> > the confusion. >> >> > >> >> >> >> >> >> 4) The DISPATCH-58 issue seems to be quite annoying - are there any >> >> plans >> >> >> to fix it? >> >> > >> >> > >> >> > Yes, I'm planning a refactor of the ingress links that will improve >> the >> >> > ability to use flow control across the network. This will likely >> improve >> >> > the DISPATCH-58 issue. >> >> > >> >> >> >> >> >> Thanks & Regards >> >> >> JAkub >> >> >> >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> >> > For additional commands, e-mail: [email protected] >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
