Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

["Jeffrey A. Williams" <[e-mail]>]

Michael and all,

  Nice outline.  What still bothers me is all this is still tied
to trust anchors.  How do we or anyone know or do about a trust
anchor that has been corrupted or otherwise breached?  It is likely
that the knowing of same will be delayed by some time factor and the
potential damage assessment may take even longer.  So there is a real
likelihood of potential harm here...

  Secondly, the same condition could/will apply to CA's Cert Database
with similar results. As some of us already know and has been detected,
reported and documented a few of the larger and well known CA's have had
their Cert databases breached leaving Cert holders from those CA's in
a very uncomfortable if not dangerous position on a number of levels.


-----Original Message-----
>From: Michael StJohns <[e-mail]>
>Sent: Oct 4, 2010 1:30 PM
>To: [e-mail], [e-mail], [e-mail], [e-mail]
>Cc: [e-mail], [e-mail], [e-mail], [e-mail]
>Subject: Re: [TLS] [pkix]   Cert Enumeration and Key Assurance With  DNSSEC
>
>Hi -
>
>DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both?
>
>
>DNSSEC provides a "secure" association FROM the name TO the IP address.  But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner.  Also, DNSSEC doesn't protect from IP hijacking (re-routing).
>
>PKIX provides a "secure" association TO/FROM "a" name to a public key.  The host owner holds the private key and can prove "ownership" of the related public key.  But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner.
>
>
>What if - the PKIX certificate for the host contained a "permit" for the name signed by the DNS owner?  A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC?
>
>
>The path goes something like:
>
>1) Use DNS and DNSSEC to find the host (or even just DNS)
>2) Use TLS to grab the certificate
>3) Verify the certificate using the PKIX path to a trust anchor
>4) Verify the host knows the private key related to the host certificate
>5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK)
>6) Verify the name offered in the certificate matches the DNS name looked up.
>
>You've verified that:
>a) The zone owner has assigned the name to the owner of the cert's private key
>b) The host owner has agreed the host has the DNS name.
>c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe).
>
>The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue.
>
>A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue.  
>
>Mike
>
>
>
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls
Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [e-mail]
Phone: [phone]