Subject: [keyassure] Charter round 3 & KeyAssure Wiki

From: Ondřej Surý <[email-masked]>
Date: Fri, 27 Aug 2010 17:15:35 +0200

[I took Warren's original text, added bit from Richard and Nicholas.]

[I have also created a Wiki page for our charter work at:
  http://tools.ietf.org/area/sec/trac/wiki/Keyassure
]

Objective:

Specify mechanisms and techniques that allow Internet applications to 
establish cryptographically secured communications by using information 
distributed through the DNS for discovering and authenticating 
cryptographic material which is associated with a service located at a 
domain name

Problem Statement:

Entities on the Internet are usually identified by domain names and 
forming a cryptographically secured connection to the entity requires 
the entity to authenticate its name.  For instance, in HTTPS, a server 
responding to a query for <https://www.example.com> is expected to 
authenticate as "www.example.com".  Security protocols such as TLS and 
IPsec accomplish this authentication by allowing an endpoint to prove 
ownership of a private key whose corresponding public key is somehow 
bound to the name being authenticated.  As a pre-requisite for 
authentication, then, these protocols require a mechanism for bindings 
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a domain operator to sign DNS 
information directly, using keys that are bound to the domain by the 
parent domain; relying parties can continue this chain up to any trust 
anchor that they accept.  In this way, bindings of keys to domains are 
asserted not by external entities, but by the entities that operate the 
DNS.  In addition, this technique inherently limits the scope of any 
given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to 
present bindings between names within their control and public keys, in 
such a way that these bindings can be integrity-protected (and thus 
shown to be authentically from the domain operator) using DNSSEC and 
used as a basis for authentication in protocols that use domain names as 
identifiers.  The group may also specify updates or clarifications to 
protocols to describe how protocol entities discover and validate these 
bindings in the execution of specific applications.

Have a nice weekend,
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 27 Aug 2010 20:11:15 +0200

Thanks Ondřej, it looks like a good starting point.  I believe we need
to qualify it with references to existing work and technologies though.

For example, I propose that we qualify the "cryptographic material" to
be authenticated to be PKIX certificates and OpenPGP keys.  Are there
other formats that are an active use?  There is SPKI, but we need some
SPKI experts to participate in the discussion to make sure we end up
with something useful.  SSH keys have been discussed.  I volunteer to
review OpenPGP related parts, I'm less concerned about getting good
enough review on the PKIX part.

/Simon

Ondřej Surý <[email-masked]> writes:

> establish cryptographically secured communications by using
> information distributed through the DNS for discovering and
> authenticating cryptographic material which is associated with a
> service located at a domain name
>
> Problem Statement:
>
> asserted not by external entities, but by the entities that operate
> the DNS.  In addition, this technique inherently limits the scope of
> any given entity to the names in zones he controls.
>
> present bindings between names within their control and public keys,
> in such a way that these bindings can be integrity-protected (and thus
> used as a basis for authentication in protocols that use domain names
> as identifiers.  The group may also specify updates or clarifications
> to protocols to describe how protocol entities discover and validate
> these bindings in the execution of specific applications.
>
>
> Have a nice weekend,

---

From: Stephen Schultze <[email-masked]>
Date: Fri, 27 Aug 2010 15:49:52 -0400

I think there's still legitimate debate over whether certs or keys are  
ideal, and at this stage I'd rather leave it open-ended.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Aug 2010 16:08:39 -0400

On Aug 27, 2010, at 3:49 PM, Stephen Schultze wrote:

> I think there's still legitimate debate over whether certs or keys  
> are ideal, and at this stage I'd rather leave it open-ended.
>

+11 3/4

W

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

-- 
American Non-Sequitur Society;
we don't make sense, but we do like pizza!

---

From: John Gilmore <[email-masked]>
Date: Fri, 27 Aug 2010 13:26:19 -0700

> ideal, and at this stage I'd rather leave it open-ended.

It is absolutely clear that this charter should not require the use
of X.509 certificates for any purpose.

Those who like ambiguity and error are free to use them, and we may
even produce some RFCs that standardize that ambiguity and error.
Those who wish to avoid those outcomes should be able to follow
alternative paths.

	John

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 27 Aug 2010 18:13:29 -0400

+3.25