[Certsanddns] FW: Wed 26 Jan 2011 - Meeting on Possible use of DNSSEC and X.509v3 certificates in combination

[James M Galvin]

Thuy is not requesting attendance.

He is the communications manager at PIR, where Lance Wolak works.  He 
was the person sending the message out to the DNSSEC Coalition member 
list, which is where the recent "rush" of invitation requests is coming 
from.

Jim



-- On January 7, 2011 1:45:50 PM -0500 Tim Moses 
<tim.moses at entrust.com> wrote regarding RE: [Certsanddns] FW: Wed 26 
Jan 2011 - Meeting on Possible use of	DNSSEC and X.509v3 certificates 
in combination --

>
>
> Andy – Is Thuy requesting to attend?  That part isn’t clear to
> me.  All the best.  Tim.
>
>
>
>
> From: certsanddns-bounces at cabforum.org
> [mailto:certsanddns-bounces at cabforum.org] On Behalf Of Steingruebl,
> Andy
> Sent: Friday, January 07, 2011 12:08 PM
> To: Certs and DNS industry meeting Jan 2011 (certsanddns at cabforum.org)
> Subject: [Certsanddns] FW: Wed 26 Jan 2011 - Meeting on Possible use
> of DNSSEC and X.509v3 certificates in combination
>
>
>
> Did this one go to the whole list, or just a subset?  Looks like Thuy
> isn’t on our list?
>
>
>
> --
>
> Andy Steingruebl
>
> Manager, Internet Standards and Governance
>
> PayPal Information Risk Management
>
> (408) 967-4650
>
>
>
>
> From: Thuy LeDinh [mailto:tledinh at pir.org]
> Sent: Wednesday, January 05, 2011 7:31 PM
> To: James M. Galvin
> Subject: Wed 26 Jan 2011 - Meeting on Possible use of DNSSEC and
> X.509v3 certificates in combination
>
>
>
> Dear Colleagues,
>
>
>
> The CA/Browser Forum and the DNSSEC Coalition are holding a joint
> expert meeting to discuss the possible use of DNSSEC and X.509v3
> certificates in combination, as outlined in the note following this
> announcement.
>
>
>
>   The meeting will be held at:
>
>  PayPal Inc.,
>
>   9999 N. 90th Street,
>
>   Scottsdale,
>
>   AZ 85258.
>
>
>
>   Starting at 1:00 PM local time on the Wed 26 Jan 2011.
>
>
>
> Those interested in attending should forward a request to the
> organizing committee at: certsanddns at cabforum.org containing the
> following information:
>
>
>
> 1. Name,
>
> 2. Organization,
>
> 3. Brief background and expression of interest.
>
>
>
> Please submit by 10 Jan 2011.  Those selected to attend will be
> notified by 14 Jan 2011.
>
>
>
> Applicants should be aware that attendance is limited to 30 people.
> So, it may not be possible to accommodate all those who express an
> interest in attending.
>
>
>
> The Organizing Committee comprises:
>
> Jim Galvin, Afilias
>
> Phillip Hallam-Baker, Comodo
>
> Ryan Koski, Go Daddy
>
> Tim Moses, Entrust
>
> Yngve Pettersen, Opera
>
> Andy Steingruebl, PayPal
>
> Ben Wilson, DigiCert
>
>
>
>
>
> Background
>
> There has been important progress in the deployment of DNSSEC in the
> past 12 months.  And there is now a reasonable expectation that most
> DNS TLDs will be signed within the next 12 months.
>
>
>
> The question of how to deploy DNSSEC, and whether deployment is
> feasible, has opened up an opportunity to consider how DNSSEC will be
> used in practice.  It would be a remarkably poor use of time and
> resources, for instance, to deploy an infrastructure as complex as
> DNSSEC only to deflect spoofing attacks from the DNS infrastructure
> to the BGP infrastructure. And, while providing an alternative to the
> existing market for the Certification Authority infrastructure that
> has been established over the past 15 years may be one use of DNSSEC,
> it is not the only (or even the best) use that can be made of it.
>
>
>
> Now that DNS registrars are at the point of deployment, questions
> about the DNSSEC business model cannot be ignored any longer. The
> registrars are being asked to make a substantial investment to
> support DNSSEC. And, in order to justify that investment, most will
> expect to demonstrate benefits to their customers that are concrete
> and immediate.
>
>
>
> DNSSEC is a PKI. Certification Authorities are in the business of
> deploying, managing and marketing PKIs. DNSSEC offers capabilities
> that the X.509v3 model does not.  And, X.509v3 is designed to support
> use cases that DNSSEC is not. Certification Authorities are also the
> traditional partners that DNS registrars have relied upon to fulfill
> their customers’ existing PKI needs.
>
>
>
> There are many potential benefits of combining the X.509v3 and DNSSEC
> models. DNSSEC provides a key-validation mechanism that is directly
> tied to the Internet naming system: the DNS. X.509v3 provides support
> for Trusted Third Party services, including assurance that the
> key-holder is a legitimate business entity, has authorized the
> issuance, and can be held accountable.
>
>
>
> The practices and liability model of DNSSEC is (at best) incompletely
> documented, while X.509v3 provides a liability model that is designed
> to control risk exposure in multi-million dollar electronic contracts.
>
>
>
> Each infrastructure offers capabilities that the other does not. We
> can either attempt to grow one infrastructure to encompass the other,
> or we can use both in combination. Important areas of potential
> benefit include:
>
>
>
> Security Policy
>
> The security of SSL would be significantly improved if there were a
> means of ensuring that clients select the strongest level of security
> available for a site. While HSTS 'strict security' offers this
> service after first contact, DNSSEC has the potential to offer it on
> every contact.
>
>
>
> Certification Authority Authorization
>
> One of the biggest challenges facing a Certification Authority is
> avoiding certificate mis-issuance. Mis-issuance events can damage a
> CA brand for decades, and have led some to assert that the security
> of the SSL PKI is determined by the issuance practices of the
> weakest, most negligent, CA in the browser trust store. CAA is a
> proposal that uses DNS records to specify which CAs are authorized to
> issue for a given domain, thereby preventing this form of downgrade
> attack.
>
>
>
> Strong Wildcards / Ubiquitous Keying
>
> Wildcard certificates have proven benefits for certain purposes.  But
> the lack of a direct binding to the actual end-entity domain name
> remains somewhat unsatisfactory. Combining wildcard certificates with
> DNSSEC may allow this limitation to be overcome.
>
>
>
> Lifecycle Management
>
> As with any PKI, DNSSEC requires support infrastructure for key
> lifecycle management. PKI vendors already provide and maintain
> infrastructures to manage the lifecycle of the cryptographic keys.
> Most enterprises will be best served by one infrastructure that can
> manage keys for both X.509 and DNSSEC.
>
>
>
> Liability control
>
> Early attempts to establish X.509v3 PKI were frustrated by the lack
> of consideration for the liabilities that issuing parties incur by
> signing public-keys for unspecified purposes. DNSSEC lacks the
> sophisticated controls that have been developed to control and
> mitigate such liabilities.  But, ignoring a legal issue does not
> cause it to go away.  In particular, DNSSEC does not allow a
> key-signer to specify: the practices under which the key was
> validated, the intended field of use, or what relying party
> expectations are reasonable. Simple measures would allow the existing
> features used to mitigate litigation risks in X.509v3 to be applied
> in the context of DNSSEC.
>
>
>
> Realizing these potential benefits represents a multi-party action
> problem. While it is easy to propose technical standards to implement
> such measures, realizing the benefits is only possible if there is
> common interest in establishing a business infrastructure to support
> them. Infrastructure is useless without applications that use it,
> just as applications are useless without the infrastructure upon
> which it was built to rely.
>
>
>
>
>
> __________________________________________________
>
>
>
> .ORG, The Public Interest Registry
>
> Mobile:+1 703-929-6395  |  www.pir.org |
>
>
>
> Find us on Facebook  |  .ORG Blog | Flickr | YouTube | Twitter |
>
>
>
> Confidentiality Note:  Proprietary and confidential to .ORG, The
> Public Interest Registry.  If received in error, please inform sender
> and then delete.
>
>