Subject: [keyassure] fyi: draft-turner-dnssec-centric-pki-00.txt

From: =JeffH <[email-masked]>
Date: Thu, 28 Oct 2010 13:35:46 -0700

Subject: I-D ACTION:draft-turner-dnssec-centric-pki-00.txt
From: [email-masked]
Date: Mon, 18 Oct 2010 16:45:02 -0700 (PDT)
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: DNSSEC-centric PKI
	Author(s)	: R. Housley, T. Polk, S. Turner
	Filename	: draft-turner-dnssec-centric-pki-00.txt
	Pages		: 6
	Date		: 2010-10-18
	
This draft is input to the KIDNS discussion.  The procedures defined
    herein provide a general Public Key Infrastructure (PKI) mechanism
    that leverages DNSSEC.  This is compatible with RFC 5280.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-turner-dnssec-centric-pki-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Oct 2010 17:25:21 -0400 (EDT)

> 	Filename	: draft-turner-dnssec-centric-pki-00.txt

    Certification Authorities (CAs) take great care to ensure that the
    private key holder is associated with the domain name contained in
    the certificate. DNSSEC [RFC4033][RFC4034][RFC4035] offers an
    opportunity to eliminate complicated off-line processes.

I would not add value judgements like  with "take great care". Research
papers from  Kaminsky, Appelbaum and others have claimed otherwise. Nor
is it "offline" as it most often is just an email/MX verification.

Perhaps something like:

    Certification Authorities (CAs) ensure that the private key holder is
    associated with the domain name contained in the certificate, usually
    requiring some form of human interaction by the private key holder.
    DNSSEC [RFC4033][RFC4034][RFC4035] offers an alternative method where
    the association of private key holder and domain name is automated via
    the DNSSEC signing operations of the DNS zone.

Regarding Section 2 / 3

I prefer this solution of returning a CA/EE over the addition of a new CAA
record, if one wants to add to the existing PKIX infrastructure with DNSSEC.

    For TLS [RFC5246], when the TLS looks up the IP address in the DNS it
    can also request the CERT RR.  If the certificate that is provided in
    the TLS handshake matches the one retrieved from DNSSEC, then the
    client can accept it as a trusted certificate for that site, provided
    local policy allows this.  If the CA certificate is returned in the
    TLS handshake, the TLS client can verify that the TLS server
    certificate was issued under that CA.

It is not entirely clear what to do with conflicting results. If the
CERT (or CA) has expired, or contains an invalid SIG, should the CERT
be rejected?  If the DNSSEC sig was bad, the record would never be
received for processing, and a servfail would be returned. Should a
client continue with only PKIX after a ServFail or not? These should
probably be local policy decisions, but the draft does not state these.

I'm also not entirely sure how to do this for a large site with many domains.
Does the CN= and/or subjectAltname matter? Does it need to match the DNS
queried hostname? Or is it ignored? (If it is ignored, one could argue that
the TLSFP approach might make more sense - we would have smaller DNS packets
to deal with as a fingerprint is much smaller then a full cert with many
subjectAltnames)

Paul