<http://tools.ietf.org/html/rfc6698#section-4.1> """
If an application receives one or more usable certificate associations, it attempts to match each certificate association with the TLS server's end entity certificate until a successful match is found. During the TLS handshake, if none of the certificate associations matches the certificate given by the TLS server, the TLS client MUST abort the handshake. """ Contrapositively, if the TLS client finds one or more associations that match the certificate, then it MAY proceed with the handshake. On Thu, Jun 13, 2013 at 9:20 AM, Bry8 Star <[email protected]> wrote: > Please explain/comment more on these: > > Conventions, used in this email msg: > * The Beginning "%" symbol (and a space after it), is not used in > any real zone file. ( I have used this symbol used here for this > email post only, just to indicate a begin of a configuration line, > as, multiple time email reply can/may change position or remove > Line-Feed(LF/EOL) indicator ). > * Command-line will start with "$" symbol (and a space after it). Do > not use shown '$' when using in real command. > * When a command-line ("$ ") will show "\" symbol at-end, then bring > below one line after it, and remove the \ symbol. Here "\" symbol > is indicating "Next-Line is part of This Line". > > I'm using such TLS / SSL Chain: > > SSL / TLS Certificate Pyramid & Levels : > > 01 = Level-01 = is TA/Root-CA cert. (My_Root_CA.crt). Self-signed > new my own CA/TA cert. > 02 = Level-02 = is an Intermediate CA cert. (My_i-CA.crt). under L-1. > 03 = Level-03 = is an Intermediate Authority cert for dom1.tld. > (dom1_tld_IA.crt). It can only be used to create certs, only under > dom1.tld. > 04 = Level-04 = is Server/EE-Certs : { s1.dom1.tld.crt, > s2.dom1.tld.crt, im.dom1.tld.crt, im2.dom1.tld.crt, > www.dom1.tld.crt, m.dom1.tld.crt } > > TA = Trust Anchor . CA = Certificate Authority. > IA = Intermediate Authority. > cert = certificate. cert keypair. Both public key portion and > private key portion. > crt = cert's public (key) portion. can be shared. > key / prv.pem = private key portion of cert. do not share. > > As a domain-owner, and an operator, etc ... i will be using my own > new self-signed TA (Trust Anchor) cert/bundle (aka, self-signed CA), > so i will need to do these, i understand this part: > > % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _25._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _25._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > > But when only TLSA TA "2 S M" is used, it is indicating, clients and > servers need to use multiple channels (port 80, port 443, port 53) > for related various purpose. :( > > C_A_D = Certificate Association Data. Either a Raw/Binary Data, > DER-encoded full cert, when s=0 & m=0. Or, it can be a hash-code > (Base64-encoded) of raw-data, when s=1, and m=1 or m=2. In Hex. > > Here, to create "C_A_D_of_TA" code-portion : > i will 1st create a DER file (C_A_D_of_TA.der), based on Level-3 > dom1_tld_IA.crt file, and then in 2nd step i will append DER code > based on Level-2 My_i-CA.crt file, and then in 3rd step i will > append DER code based on Level-1 My_Root_CA.crt file. (Similar to > what we do for creating TLS chain cert for httpd server software) : > > $ openssl x509 -in dom1_tld_IA.crt \ > -outform der -out C_A_D_of_TA.der > $ openssl x509 -in My_i-CA.crt \ > -outform der -out My_i-CA.der > $ cat My_i-CA.der >> C_A_D_of_TA.der > $ openssl x509 -in My_Root_CA.crt \ > -outform der -out My_Root_CA.der > $ cat My_Root_CA.der >> C_A_D_of_TA.der > > I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER > TLS certs. Both TA/Root-CA and EE/Server-Cert. > > Let us assume, i have such dns entries : Here 's1' is server > hostname. So is 's2'. Visitors & users will access 's1' srvr via > 'www' srvc, and access 's2' srvr via 'm' service (service > sub-domain-name) normally. When/if 's1' srvr is down, then user > will goto 's2' srvr for 'www' srvc, and when 's2' srvr is down then > user will goto 's1' srvr for 'm' srvc: > > % dom1.tld. 3600 IN SOA s1.dom1.tld. hostmaster.dom1.tld. 2013052910 > 18000 3600 864000 3600 > % dom1.tld. 3000 IN NS s1.dom1.tld. > % dom1.tld. 3000 IN NS s2.dom1.tld. > % dom1.tld. 300 IN A IP.ADRS_S-1_IPv4 > % dom1.tld. 300 IN A IP.ADRS_S-2_IPv4 > % dom1.tld. 300 IN AAAA IP::ADRS_S-1_IPv6 > % dom1.tld. 300 IN AAAA IP::ADRS_S-2_IPv6 > % s1.dom1.tld. 900 IN A IP.ADRS_S-1_IPv4 > % s2.dom1.tld. 900 IN A IP.ADRS_S-2_IPv4 > % s1.dom1.tld. 900 IN AAAA IP::ADRS_S-1_IPv6 > % s2.dom1.tld. 900 IN AAAA IP::ADRS_S-2_IPv6 > % www.dom1.tld. 300 IN CNAME dom1.tld. > % m.dom1.tld. 300 IN CNAME dom1.tld. > % _http._tcp.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld. > % _https._tcp.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld. > % _http._tcp.www.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld. > % _https._tcp.www.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld. > % _http._tcp.m.dom1.tld. 3600 IN SRV 0 0 80 m.dom1.tld. > % _https._tcp.m.dom1.tld. 3600 IN SRV 0 0 443 m.dom1.tld. > % dom1.tld. 3600 IN MX 10 s1.dom1.tld. > % dom1.tld. 3600 IN MX 20 s2.dom1.tld. > % _smtp._tcp.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld. > % _smtp._tcp.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld. > % _smtp._tcp.s1.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld. > % _smtp._tcp.s1.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld. > % _smtp._tcp.s2.dom1.tld. 3600 IN SRV 10 0 25 s2.dom1.tld. > % _smtp._tcp.s2.dom1.tld. 3600 IN SRV 20 0 25 s1.dom1.tld. > % _submission._tcp.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld. > % _submission._tcp.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld. > % _submission._tcp.s1.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld. > % _submission._tcp.s1.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld. > % _submission._tcp.s2.dom1.tld. 3600 IN SRV 10 0 587 s2.dom1.tld. > % _submission._tcp.s2.dom1.tld. 3600 IN SRV 20 0 587 s1.dom1.tld. > % _imaps._tcp.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld. > % _imaps._tcp.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld. > % _imaps._tcp.s1.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld. > % _imaps._tcp.s1.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld. > % _imaps._tcp.s2.dom1.tld. 3600 IN SRV 0 0 993 s2.dom1.tld. > % _imaps._tcp.s2.dom1.tld. 3600 IN SRV 5 0 993 s1.dom1.tld. > % _pop3s._tcp.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld. > % _pop3s._tcp.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld. > % _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld. > % _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld. > % _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 0 0 995 s2.dom1.tld. > % _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 5 0 995 s1.dom1.tld. > > I want, FUTURE FULL DANE & DNSSEC supported > web-browsers/HTTPS-clients (and httpd (HTTP, HTTPS) servers) to > pull/retrieve BOTH TA & EE type of certs from DNS, like : 1st > pull/retrieve FULL authentic EE/server-cert from TLSA dns ("1 S M" & > "3 S M" cases), and (in 2nd step), also pull/retrieve new > self-signed TA ("TLSA 2 S M"), or public CA ("TLSA 0 S M") from DNS > record (if it exist there and if required for TLS chain validation), > and after verifying TLSA EE cert and TLSA cert chain and > authenticity, then use EE/Server-Cert for creating authentic & > encrypted secured HTTPS connection. > > I basically want both HTTPS-client and HTTPS-server, to retrieve, > domain-owner declared/published, both TA and EE full certificate > from DNS, and then after cert chain validation succeeds, use the EE > cert to create encrypted connection. Without depending on any .crt > files specified or loaded in/from server or client software. > Server-side software will only need cert's private_key file portion > for creating encrypted traffic. > > So based on above expectation, i also want to add these: > > % _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_Srvr-Cert > % _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_Srvr-Cert > > Or, am i suppose to add these ? > > % _443._tcp.www.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_www_Srvr-Cert > % _443._tcp.m.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_m_Srvr-Cert > > I will create C_A_D_of_www_Srvr-Cert.der like this: > $ openssl x509 -in www_dom1_tld.crt \ > -outform der \ > -out C_A_D_of_www_Srvr-Cert.der > > And for other certs: > $ openssl x509 -in m_dom1_tld.crt \ > -outform der \ > -out C_A_D_of_m_Srvr-Cert.der > $ openssl x509 -in s1_dom1_tld.crt \ > -outform der \ > -out C_A_D_of_s1_Srvr-Cert.der > $ openssl x509 -in s2_dom1_tld.crt \ > -outform der \ > -out C_A_D_of_s2_Srvr-Cert.der > > So for my case, i will be adding both "TLSA 1 0 0" and "TLSA 2 0 0", > full certificates. To me, adding both TLSA "2 0 0" and "1 0 0" with > full certs, makes more sense, specially when domain-owner will be > using their own new self-signed/TA cert based solution. Then client > and server both can retrieve the TA and EE type cert using only one > channel, DNS-channel, port 53. I want to call it or treat it, as, a > Complete TLSA declaration, as it eliminates any chance of confusion, > and reduces TLS obtain & validation related steps, as it can easily > obtain all necessary full TLS certs from DNS records, authenticated > by DNSSEC. > > I'm trying to say via DNS ... here (TLSA 1 0 0) is my server's > self-signed full EE/server-cert, and here (TLSA 2 0 0) is my own & > new self-signed full Root-CA/TA cert bundle, ... ( so, you(client) > must use these (TA & EE certs) to validate the cert chain. and then > on success, use the EE cert for creating HTTPS secured connection). > > I want to support various & mixed channel based solutions, so i will > also do these : I will add both TLSA TA "2 0 0" and TLSA EE "1 0 0" > as mentioned in above. So that, clients & servers both side can > still obtain both TA & EE type of TLSA records via DNS channel (port > 53). And i will also serve/share full TLS cert chain/bundle-file > from HTTPS-server (apache/httpd) service software. So that, clients > & servers both side can still obtain (1) server/EE-cert and rest of > the TLS cert chain's linked certs (if server/EE-cert requires), via > HTTPS channel (port 443) and/or using OCSP channel (port 80) for TLS > cert's PKIX validity). > > I want, client & server software able to obtain & use entire EE cert > (from TLSA "1 S M" or TLSA "3 S M"), and i want them able to obtain > & use entire TA cert chain (from TLSA "2 S M" or TLSA "0 S M"). > > So for my case i will and want-to, use TLSA like this: > > % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > % _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_dom1_tld > % _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_dom1_tld > % _25._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _25._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _993._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _995._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _587._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld > % _25._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _25._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > % _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _993._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > % _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _995._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > % _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > % _587._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld > > Does DANE currently allow TWO combined TLSA record usage ? i want to > use both TLSA TA ("TLSA 2 0 0") and TLSA EE ("TLSA 1 0 0") > dns-record, for verifying EE cert created under a self-signed new TA > cert, and force both client & server side to validate both type of > certs, and after validation succeeds, the EE cert will be used for > HTTPS encryption, by both client & server. > If such/above is not supported, then please add support for it. > > Since i will not use partial cert portion or hash, in TLSA EE "1 S > M" or "3 S M" cases, so you may avoid referencing on that, and > please focus on full EE cert based practice/guidance/example. But > if (non-Full) partial cert is appropriate or adequate for TLSA TA "2 > S M" or "0 S M" cases without invoking/using extra channel usage, > then pls do mention on that. > > Please point out my errors, and help us/me/domain-owners with > better/improved configuration, thanks in advance. > > -- Bright Star. > Jun 13, 2013. > > > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
