Re: [websec] #53: Clarify status of pin validation when used with private trust anchors

[websec issue tracker]

#53: Clarify status of pin validation when used with private trust anchors

Changes (by pal...@google.com):

 * status:  assigned => closed
 * resolution:   => fixed


-- 
---+
 Reporter:  pal...@google.com  |   Owner:  pal...@google.com
 Type:  defect |  Status:  closed
 Priority:  major  |   Milestone:
Component:  key-pinning| Version:
 Severity:  -  |  Resolution:  fixed
 Keywords: |
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #53: Clarify status of pin validation when used with private trust anchors

[Yoav Nir]

I agree. I think that this non-strict behavior is something that UAs will 
implement anyway, because otherwise the UA doesn't work in any place that has a 
"next generation firewall" (which is pretty much any firewall these days)

And if they did stick to only strict behavior, pretty much none of the 
potential servers would use HPKP. 

I agree that this text represents a middle ground that allows both UAs and 
servers to deploy the protocol.

so, +1.

Yoav
(with no hats, except maybe a next-generation firewall vendor hat)

On May 28, 2013, at 2:35 PM, Tobias Gondrom  wrote:

> Hi Chris,
> 
> I think so. (but am not 100% sure.)
> Any other comments on this issue before we close it?
> 
> Thanks, Tobias
> 
> 
> On 25/05/13 02:41, websec issue tracker wrote:
>> #53: Clarify status of pin validation when used with private trust anchors
>> 
>> 
>> Comment (by pal...@google.com):
>> 
>> The current draft has this text:
>> 
>>  578 If the connection has no errors, then the UA will determine
>> whether to
>>  579 apply a new, additional correctness check: Pin Validation. A UA
>> SHOULD
>>  580 perform Pin Validation whenever connecting to a Known Pinned Host,
>> but MAY
>>  581 allow Pin Validation to be disabled for Hosts according to local
>> policy. For
>>  582 example, a UA may disable Pin Validation for Pinned Hosts whose
>> validated
>>  583 certificate chain terminates at a user-defined trust anchor, rather
>> than a
>>  584 trust anchor built-in to the UA. However, if the Pinned Host Metadata
>>  585 indicates that the Pinned Host is operating in "strict mode" (see
>>  586 ), then the UA MUST perform Pin
>> Validation.
>> 
>> I believe this is the result of previous consensus. Is that correct, and
>> can I therefore close this issue?
>> 
> 
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #53: Clarify status of pin validation when used with private trust anchors

[Tobias Gondrom]

Hi Chris,

I think so. (but am not 100% sure.)
Any other comments on this issue before we close it?

Thanks, Tobias


On 25/05/13 02:41, websec issue tracker wrote:
> #53: Clarify status of pin validation when used with private trust anchors
>
>
> Comment (by pal...@google.com):
>
>  The current draft has this text:
>
>   578 If the connection has no errors, then the UA will determine
>  whether to
>   579 apply a new, additional correctness check: Pin Validation. A UA
>  SHOULD
>   580 perform Pin Validation whenever connecting to a Known Pinned Host,
>  but MAY
>   581 allow Pin Validation to be disabled for Hosts according to local
>  policy. For
>   582 example, a UA may disable Pin Validation for Pinned Hosts whose
>  validated
>   583 certificate chain terminates at a user-defined trust anchor, rather
>  than a
>   584 trust anchor built-in to the UA. However, if the Pinned Host Metadata
>   585 indicates that the Pinned Host is operating in "strict mode" (see
>   586 ), then the UA MUST perform Pin
>  Validation.
>
>  I believe this is the result of previous consensus. Is that correct, and
>  can I therefore close this issue?
>

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #53: Clarify status of pin validation when used with private trust anchors

[websec issue tracker]

#53: Clarify status of pin validation when used with private trust anchors


Comment (by pal...@google.com):

 The current draft has this text:

  578 If the connection has no errors, then the UA will determine
 whether to
  579 apply a new, additional correctness check: Pin Validation. A UA
 SHOULD
  580 perform Pin Validation whenever connecting to a Known Pinned Host,
 but MAY
  581 allow Pin Validation to be disabled for Hosts according to local
 policy. For
  582 example, a UA may disable Pin Validation for Pinned Hosts whose
 validated
  583 certificate chain terminates at a user-defined trust anchor, rather
 than a
  584 trust anchor built-in to the UA. However, if the Pinned Host Metadata
  585 indicates that the Pinned Host is operating in "strict mode" (see
  586 ), then the UA MUST perform Pin
 Validation.

 I believe this is the result of previous consensus. Is that correct, and
 can I therefore close this issue?

-- 
---+
 Reporter:  pal...@google.com  |   Owner:  pal...@google.com
 Type:  defect |  Status:  assigned
 Priority:  major  |   Milestone:
Component:  key-pinning| Version:
 Severity:  -  |  Resolution:
 Keywords: |
---+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #53: Clarify status of pin validation when used with private trust anchors

[websec issue tracker]

#53: Clarify status of pin validation when used with private trust anchors

Changes (by palmer@…):

 * status:  new => assigned


-- 
-+---
 Reporter:  palmer@… |   Owner:  palmer@…
 Type:  defect   |  Status:  assigned
 Priority:  major|   Milestone:
Component:  key-pinning  | Version:
 Severity:  -|  Resolution:
 Keywords:   |
-+---

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #53: Clarify status of pin validation when used with private trust anchors

[websec issue tracker]

#53: Clarify status of pin validation when used with private trust anchors

 Clarify in the I-D whether and how, when a the server's certificate chain
 chains up to a private trust anchor (as opposed to a publicly-trusted one
 such as in Mozilla's or Microsoft's root CA programs), the UA should
 perform pin validation. Options:

 * If anchor is private, do not perform pin validation

 * Always perform pin validation, presumably always failing when trust
 anchor is private

 * If anchor is private, validate against a database of private pins;
 ** If there is no DB of private pins, do not perform pin validation
 ** If there is no DB of private pins, perform pin validation anyway
 (presumably always failing)

 * Other options?

 Currently, Google Chrome opts to not perform pin validation when the trust
 anchor is private.

-- 
-+--
 Reporter:  palmer@… |  Owner:  palmer@…
 Type:  defect   | Status:  new
 Priority:  major|  Milestone:
Component:  key-pinning  |Version:
 Severity:  -|   Keywords:
-+--

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec