Subject: [dane] Question regarding draft-ietf-dane-protocol-14

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 22 Jan 2012 16:55:21 +0200

Hi all, 

I have a question regarding the support of raw public keys with DANE. 

From browsing through draft-ietf-dane-protocol-14 I understand that you make use of the subjectPublicKeyInfo structure defined in RFC 5280. 

My question: Do you dump the  subjectPublicKeyInfo directly into a RR or do you put an entire PKIX certificate in a RR but only the subjectPublicKeyInfo field is "read" (and the rest is ignored)?

Ciao
Hannes

---

From: Scott Schmit <[email-masked]>
Date: Sun, 22 Jan 2012 11:24:31 -0500

On Sun, Jan 22, 2012 at 04:55:21PM +0200, Hannes Tschofenig wrote:
> From browsing through draft-ietf-dane-protocol-14 I understand that
> you make use of the subjectPublicKeyInfo structure defined in RFC
> 5280. 
> 
> My question: Do you dump the  subjectPublicKeyInfo directly into a RR
> or do you put an entire PKIX certificate in a RR but only the
> subjectPublicKeyInfo field is "read" (and the rest is ignored)?

I think we intended the former, and the pseudocode agrees with me--it
selects the SPKI from the cert and then does a match against the
certificate data (whether full or hash) in the record.

That said, the wording in 2.1.2 is ambiguous. Perhaps replacing:

#  A one-octet value, called "selector", specifying what will be
#  matched.

with

#  A one-octet value, called "selector", specifying what the association
#  data will be matched against from the TLS certificate presented by
#  the server.

would make this clearer?

That said, calling the "Certficate for Association" field a certificate
probably causes more of the confusion. Calling it "association data"
or "matching data" would be better. Sometimes it's a certificate,
sometimes it's a hash of a certificate, sometimes it's a SPKI, and
sometimes it's a hash of an SPKI.

-- 
Scott Schmit

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Jan 2012 09:16:56 -0800

> #  data will be matched against from the TLS certificate presented by

Yes. Will be in -15.

> sometimes it's a hash of an SPKI.

I'm hesitant to make that change now, but it is something worth discussing in WGLC.

--Paul Hoffman

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 22 Jan 2012 20:36:27 +0200

Hi Scott, 

thanks for the quick response. 

Good to hear that you use the subjectPublicKeyInfo block (without the rest of the elements in the Certificate structure). 

A follow-up question: Is there code available to create DER encoded subjectPublicKeyInfo blocks and to decode them?

Ciao
Hannes

PS: Regarding readability I have to say that 
a) I didn't follow the work closely,  
b) I am only interested in the raw public key based variant, and 
c) the document mostly talks about putting certificates into the DNS. 
For this reason it is a bit confusing. 

On Jan 22, 2012, at 6:24 PM, Scott Schmit wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: [email-masked]
Date: Sun, 22 Jan 2012 19:45:53 +0100 (CET)

Hi Hannes,

> A follow-up question: Is there code available to create DER encoded
> subjectPublicKeyInfo blocks and to decode them?

I use python for doing this:

Decoding can be done using the M2Crypto[0] library in python (a OpenSSL
wrapper):

from M2Crypto import X509
cert = X509.load_cert('/path/to/cert')
print cert.get_pubkey().as_der()
print cert.get_pubkey().as_text()

For encoding, the M2Crypto.RSA module can be used afaik.

-- Pieter Lexis

0 - http://www.heikkitoivonen.net/m2crypto/api/

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Jan 2012 09:06:33 +0200

Hi Pieter, 

Thanks for your quick response. I should have better explained my question. 

For certificate handling there are many tools available (many of them come with the ssl/tls stack but some are also shipped separately, such as the Windows makecert). Some of them come with a fairly nice user interface as well. 

Since you guys are not only using certs but fragments of them (as it is the case with the subjectPublicKeyInfo) I was wondering whether someone has worked on these tools already to allow convenient creating, and verification of subjectPublicKeyInfo structures so that they then be dumped into the RR. For deploying smaller systems, and for testing this would be quite useful. 

Ciao
Hannes

PS: In your code below you seem to be using a certificate as a starting point.Those who want to use raw public keys probably wouldn't create certificates.

---

From: Pieter Lexis <[email-masked]>
Date: Mon, 23 Jan 2012 10:42:11 +0100

Hi Hannes,

On 01/23/2012 08:06 AM, Hannes Tschofenig wrote:
> Since you guys are not only using certs but fragments of them (as it
> is the case with the subjectPublicKeyInfo) I was wondering whether
> someone has worked on these tools already to allow convenient
> creating, and verification of subjectPublicKeyInfo structures so that
> they then be dumped into the RR. For deploying smaller systems, and
> for testing this would be quite useful.

As a matter-of-fact I have. I'm currently busy implementing a TLSA
creator/verifier in python (hence the python code) that takes a
certificate (either from an on-disk certificate or a certificate
retrieved in the TLS session) and dumps the SubjectPublicKeyInfo or full
cert in (hashed) DER format into the RR.

I'm planning on releasing the tool somewhere this week, after I've
verified all permutations of fields produce the right results.

Cheers,

Pieter Lexis

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 08:17:46 -0800

> PS: In your code below you seem to be using a certificate as a starting point.Those who want to use raw public keys probably wouldn't create certificates.

The WG is currently only focused on certificates and the keys from certificates because those are the only things that can be used in standards-compliant TLS. As others have noted, if the TLS WG adopts a standards-track method for using raw public keys, it is likely that DANE would be updated to use them. Until then, however, the WG has (repeatedly) decided that because our work does not change TLS, raw public keys that would be used in TLS are out of scope.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Jan 2012 12:47:23 -0500 (EST)

> verified all permutations of fields produce the right results.

I created one a while ago, and it should get published better. It is
want powers/powered http://dane.xelerance.com/

It uses ldnsx, a python module added to recent ldns versions. Since it
is small and I currently do not have a good publication url, I attached
it.

Note it uses some non-obvious socket calls due to some unavailable modes
for ipv6 in some of the other python networking modules.

Paul
ps. someone also gave me some patches that i havent had time to look at
yet to support more then type 1 certifiactes.