Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 27 Aug 2010 16:10:12 -0500 (GMT-05:00)

John and all,

  I for one fully agree with John here.

-----Original Message-----
>From: John Gilmore <[email-masked]>
>Sent: Aug 27, 2010 3:26 PM
>To: Stephen Schultze <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki
>
>> 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.
>
>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
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

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 [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 27 Aug 2010 16:16:21 -0500 (GMT-05:00)

Phillip and all,

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 27, 2010 2:37 PM
>To: "Jeffrey A. Williams" <[email-masked]>
>Cc: Simon Josefsson <[email-masked]>, Ondřej Surý <[email-masked]>, [email-masked]
>The approach that leads to fewest arguments is usually to write a
>charter that is agnostic on the issue of format in the text but only
>commits to produce a deliverable for the specific formats that are
>necessary to make it work.

  Yes of course.
>
>If anyone wants to propose a spec for additional formats, they can,
>but only if they can show that there are sufficient people to do the
>work and sufficient people in the target community to vet the work.

Problem here is in the vetting.  Out of the box thinking and than
product result may not have the necessary folks in the target
community to do a proper vetting, at least not early on.
>
>
>So for example in KEYPROV we started with an assumption that we were
>going to write a protocol in XML only. But the charter was agnostic on
>that issue and we later had a proposal to shadow the XML spec with an
>ASN.1 spec which is a perfectly justifiable approach. The fact that
>the draft in question is written by the IETF chair and one of the
>Security ADs is (mostly) besides the point.

  Good example point.
>
>
>2010/8/27 Jeffrey A. Williams <[email-masked]>:
>> Simon and all,
>>
>>  For a start on SPKI, one might want to review
>> the information at http://datatracker.ietf.org/doc/search/
>> Currently there is no IETF WG for SPKI.
>>
>>
>>>From: Simon Josefsson <[email-masked]>
>>>Sent: Aug 27, 2010 1:11 PM
>>>To: Ondřej Surý <[email-masked]>
>>>Cc: [email-masked]
>>>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:
>>>
>>>> [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,
>-- 
>Website: http://hallambaker.com/

Regards,
Jeffrey A. Williams

---

From: =JeffH <[email-masked]>
Date: Fri, 27 Aug 2010 15:32:05 -0700

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

+1 (at least ;)

=JeffH