Subject: [POSH] Fwd: I-D Action: draft-miller-posh-01.txt

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 6 Sep 2013 22:19:19 +0000

FYI, the latest draft incorporates just about all of the feedback we received as a result of the BoF, minus ASCII art; we'll see about that for the next version!

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

Begin forwarded message:

> From: <[email-masked]>
> Subject: I-D Action: draft-miller-posh-01.txt
> Date: September 6, 2013 4:14:29 PM MDT
> To: <[email-masked]>
> Reply-To: <[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : PKIX over Secure HTTP (POSH)
> 	Author(s)       : Matthew Miller
>                          Peter Saint-Andre
> 	Filename        : draft-miller-posh-01.txt
> 	Pages           : 15
> 	Date            : 2013-09-06
> 
> Abstract:
>   Experience has shown that it is extremely difficult to deploy proper
>   PKIX certificates for TLS in multi-tenanted environments, since
>   certification authorities will not issue certificates for hosted
>   domains to hosting services, hosted domains do not want hosting
>   services to hold their private keys, and hosting services wish to
>   avoid liability for holding those keys.  As a result, domains hosted
>   in multi-tenanted environments often deploy non-HTTP applications
>   such as email and instant messaging using certificates that identify
>   the hosting service, not the hosted domain.  Such deployments force
>   end users and peer services to accept a certificate with an improper
>   identifier, resulting in obvious security implications.  This
>   document defines two methods that make it easier to deploy
>   certificates for proper server identity checking in non-HTTP
>   application protocols.  The first method enables the TLS client
>   associated with a user agent or peer application server to obtain the
>   end-entity certificate of a hosted domain over secure HTTP as an
>   alternative to standard PKIX techniques.  The second method enables a
>   hosted domain to securely delegate a non-HTTP application to a
>   hosting service using redirects provided by HTTPS itself or by a
>   pointer in a file served over HTTPS at the hosted domain.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-miller-posh
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-miller-posh-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-miller-posh-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tobias Markmann <[email-masked]>
Date: Mon, 09 Sep 2013 21:54:15 -0000

Hi,

Matt Miller (mamille2) wrote:

FYI, the latest draft incorporates just about all of the feedback we
received as a result of the BoF, minus ASCII art; we'll see about that
for the next version!

- m&m

here some feedback based on an initial read of the changes.

Section 4.1

   Additionally, each JWK object MUST possess at least one of the
   following:

   o  The "x5t" field set to the certificate thumbprint, as per <a href="http://tools.ietf.org/html/draft-miller-posh-01#section-3.6">section: ]
      <a href="http://tools.ietf.org/html/draft-miller-posh-01#section-3.6">3.6: ] of [<a href="http://tools.ietf.org/html/draft-miller-posh-01#ref-JOSE-JWK">JOSE-JWK: ]].

   o  The "x5c" field set to the certificate chain, as per section 3.7
      of [<a href="http://tools.ietf.org/html/draft-miller-posh-01#ref-JOSE-JWK">JOSE-JWK: ]].

<div class="message-gap">
	<p style="margin: 0px; padding: 0px; ">

<div class="message-signature" id="signature_1378760946803-1670277853" name="signature_1378760946803-1670277853">
	I suggest making x5t, the thumbprint/fingerprint, a MUST to reduce the mimimum possible code paths to implement this draft, considering not all TLS API provide access to the public key's modulus and exponent. In addition, verification using the thumbprint is independent of the type of key (RSA, ECC, …) that the certficate uses, which further eases implementation and straightens the codepath. I'd still allow (MAY) inclusion of x5c, for debugging purposes though.
<div class="message-signature" name="signature_1378760946803-1670277853">
	 
<div class="message-signature" name="signature_1378760946803-1670277853">
	Cheers,
<div class="message-signature" name="signature_1378760946803-1670277853">
	Tobi

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 10 Sep 2013 21:42:11 +0000

Thanks for the feedback!  Requiring just the "x5t" makes sense, and we can incorporate that change in the next revision.

- m&m

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 Sep 2013 16:23:30 -0600

WFM!

On 9/10/13 3:42 PM, Matt Miller (mamille2) wrote:
> Thanks for the feedback!  Requiring just the "x5t" makes sense, and
> we can incorporate that change in the next revision.
> 
> 
> - m&m
> 
> Matt Miller < [email-masked] > Cisco Systems, Inc.
> 
>> FYI, the latest draft incorporates just about all of the feedback
>> we received as a result of the BoF, minus ASCII art; we'll see
>> about that for the next version!
>> 
>> 
>> - m&m
>> 
>> Matt Miller < [email-masked] > Cisco Systems, Inc.
>> 
>> 
>> o  The "x5t" field set to the certificate thumbprint, as per <a
>> href="http://tools.ietf.org/html/draft-miller-posh-01#section-3.6">section:
>> ] <a
>> href="http://tools.ietf.org/html/draft-miller-posh-01#section-3.6">3.6:
>> ] of [<a
>> href="http://tools.ietf.org/html/draft-miller-posh-01#ref-JOSE-JWK">JOSE-JWK:
>> ]].
>> 
>> 
>> o  The "x5c" field set to the certificate chain, as per section
>> 3.7 of [<a
>> href="http://tools.ietf.org/html/draft-miller-posh-01#ref-JOSE-JWK">JOSE-JWK:
>> ]].
>> 
>> <div class="message-gap"> <p style="margin: 0px; padding: 0px;
>> "> 
>> 
>> <div class="message-signature"
>> id="signature_1378760946803-1670277853"
>> name="signature_1378760946803-1670277853"> I suggest making x5t,
>> the thumbprint/fingerprint, a MUST to reduce the mimimum possible
>> code paths to implement this draft, considering not all TLS API
>> provide access to the public key's modulus and exponent. In
>> addition, verification using the thumbprint is independent of the
>> type of key (RSA, ECC, ?) that the certficate uses, which further
>> eases implementation and straightens the codepath. I'd still
>> allow (MAY) inclusion of x5c, for debugging purposes though. <div
>> class="message-signature"
>> name="signature_1378760946803-1670277853">  <div
>> class="message-signature"
>> name="signature_1378760946803-1670277853"> Cheers, <div
>> class="message-signature"
>> name="signature_1378760946803-1670277853"> Tobi
> 
> 
> 
> _______________________________________________ posh mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/posh
> 

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Sep 2013 14:44:52 +0100

> FYI, the latest draft incorporates just about all of the feedback we received as a result of the BoF, minus ASCII art; we'll see about that for the next version!
I think this version is an improvement. I do however miss a clear 
statement on whether HTTP redirects need to be followed during 
resolution. Maybe I missed that.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 11 Sep 2013 14:33:25 +0000

On Sep 11, 2013, at 7:44 AM, Alexey Melnikov <[email-masked]>
 wrote:

> I think this version is an improvement. I do however miss a clear statement on whether HTTP redirects need to be followed during resolution. Maybe I missed that.
> 

We probably removed too much while moving to the application-level referencing/redirect.  I'll talk to my co-author about it, but I suspect following some amount of HTTPS-level redirect is still going to be necessary to accommodate existing deployments (e.g., https://example.com/.well-known/... --> https://www.example.com/.well-known/... ).

- m&m

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Sep 2013 09:19:58 -0600

On 9/11/13 8:33 AM, Matt Miller (mamille2) wrote:
> 
> On Sep 11, 2013, at 7:44 AM, Alexey Melnikov 
> <[email-masked]> wrote:
> 
>>> FYI, the latest draft incorporates just about all of the
>>> feedback we received as a result of the BoF, minus ASCII art;
>>> we'll see about that for the next version!
>>> 
>> I think this version is an improvement. I do however miss a
>> clear statement on whether HTTP redirects need to be followed
>> during resolution. Maybe I missed that.
>> 
> 
> 
> We probably removed too much while moving to the application-level 
> referencing/redirect.  I'll talk to my co-author about it, but I 
> suspect following some amount of HTTPS-level redirect is still
> going to be necessary to accommodate existing deployments (e.g., 
> https://example.com/.well-known/... --> 
> https://www.example.com/.well-known/... ).

Yes, I think we were overzealous in our edits. :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/