From limpbizkit@gmail.com Sat May 14 19:46:44 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D762312B01E for ; Sat, 14 May 2016 19:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV4VqicBJBov for ; Sat, 14 May 2016 19:46:43 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD09212B011 for ; Sat, 14 May 2016 19:46:42 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id 190so175176784iow.1 for ; Sat, 14 May 2016 19:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=Q6QOLvP4b5YfmTmoz7r4jBCsoPd9vxy7E4IiTMmGfrY=; b=mv9FcCD5UdpDoJDrAcuOuvW8aYANkEHaJ+81GZ6gYValfnH+ovBVQvfuxy9OPALaSX N6HqsgwMXPLrC33xbkeBBTm6yIYpP7HK83i1xp0BxV26LquAMzQfyuTiFOGmRtaakOt+ 961lN2ltY10cRb+jh5ErTOYQaNJEttyIxmw2souZb8n7gJOsS2kdGfZOh3N8s/iYCrEV 1dA2S8lotKwnRf71xJcWv8QcfRGjB4GvNl42LB/z7jbdDukqrJhsC930kCXZofG/qVoG JGweu2w5GgXyFZhD3RCGfevaeVBdIRu+O4cVHf1LfHJzHlY8HDpqwNPKqwHOa3evjcAY uylA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Q6QOLvP4b5YfmTmoz7r4jBCsoPd9vxy7E4IiTMmGfrY=; b=gXkb6ZtWsJ+jWE9RFo63P4q3XmLf8PaFnrjwbBk+qsFD5L3UvNr6fapkzmS/JGtQFQ 3hfm6lN1qVamJlhjidNYIUPstO/RZGSUIZEflDhTtTCPGAYa4YFfHBrfwOQBwXCpwJiG Jk4xYY3/U1wrS1Kmo3Bk7M1cqH0HHVG9/pmBAi7vt42ZOjcWMObOEX39+cOurYAhTcqZ A/7ZzfGfmtb82aD7ZCg4QirFPe7IfqgVaxpO7galir03bjwgPi0Wo4c3orflARtlp3cY kI1xf0fjSllH+/5eRwWWL2foMarUTVcvuW3zmyq/QtDJahmX3R9QlKGj8wY7dMqtFGiA XPDg== X-Gm-Message-State: AOPr4FVMJP+/JbVqOaGvynUlKoCvgtORGsprmyAZNJB962VLAR8FmDGqvKVhy8HGAGsNaRQSeszxuO+kKzPb4g== X-Received: by 10.107.37.16 with SMTP id l16mr14708073iol.138.1463280402107; Sat, 14 May 2016 19:46:42 -0700 (PDT) MIME-Version: 1.0 Sender: limpbizkit@gmail.com Received: by 10.79.35.106 with HTTP; Sat, 14 May 2016 19:46:22 -0700 (PDT) From: Jesse Wilson Date: Sat, 14 May 2016 22:46:22 -0400 X-Google-Sender-Auth: PlASUMymjKeiLx8dYfwLT_iLM0k Message-ID: To: websec@ietf.org Content-Type: multipart/alternative; boundary=001a114088b09311fc0532d88438 Archived-At: Subject: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 02:51:55 -0000 --001a114088b09311fc0532d88438 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I work on OkHttp, an Android HTTP client that implements HPKP-like certificate pinning. We recently saw a problem where different versions of Android returned different bytes for the ASN.1 encoding of the same certificate. This is bad: the pins don=E2=80=99t match! The certificate of interest uses a named curve (secp521r1) with ECC. I used der2ascii to view the SPKI ASN.1 bytes. Older versions of Android (which use BouncyCastle) embed the curve: SEQUENCE { SEQUENCE { # ecPublicKey OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } SEQUENCE { INTEGER { 1 } SEQUENCE { # prime-field OBJECT_IDENTIFIER { 1.2.840.10045.1.1 } INTEGER { `01ffffffffffffff...` } } SEQUENCE { OCTET_STRING { `01ffffffffffffff...` } OCTET_STRING { `0051953eb9618e1c...` } } OCTET_STRING { `0400c6858e06b704...` } INTEGER { `01ffffffffffffff...` } INTEGER { 1 } } } BIT_STRING { `0004019519de800d...` } } But new versions of Android (which use Conscrypt/OpenSSL) reference the curve by name: SEQUENCE { SEQUENCE { # ecPublicKey OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } # secp521r1 OBJECT_IDENTIFIER { 1.3.132.0.35 } } BIT_STRING { `0004019519de800d...` } } The original certificate embeds the curve. I believe my problem is that the Java APIs I=E2=80=99m using don=E2=80=99t = return raw bytes from the certificate. Instead Java decodes the certificate into a model and re-encodes that when the bytes are requested. The original and roundtripped SPKI bytes are not identical. Does anyone else do ASN.1 encoding in order to compute a certificate=E2=80= =99s pin? Or is it a uniquely Java problem?! The spec should warn that a single SPKI may have multiple conflicting encodings. I suggest that only encoding in the certificate should be pinned. TLS server administrators should also be careful to not inadvertently re-encode their SPKIs when doing maintenance. Thanks! =E2=80=8B --001a114088b09311fc0532d88438 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I work on OkHttp, an Android HTTP clien= t that implements HPKP-like certificate pinning. We recently saw a problem = where different versions of Android returned different bytes for the ASN.1 = encoding of the same certificate. This is bad: the pins don=E2=80=99t match= !

The certificate of interest use= s a named curve (secp521r1) with ECC. I used der2ascii to view the SPKI ASN.1 bytes.

Older versions of Android (whic= h use BouncyCastle) embed the curve:

SEQUENCE {
  SEQUENCE {
    # ecPublicKey
    OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
    SEQUENCE {
      INTEGER { 1 }
      SEQUENCE {
        # prime-field
        OBJECT_IDENTIFIER { 1.2.840.10045.1.1 }
        INTEGER { `01ffffffffffffff...` }
      }
      SEQUENCE {
        OCTET_STRING { `01ffffffffffffff...` }
        OCTET_STRING { `0051953eb9618e1c...` }
      }
      OCTET_STRING { `0400c6858e06b704...` }
      INTEGER { `01ffffffffffffff...` }
      INTEGER { 1 }
    }
  }
  BIT_STRING { `0004019519de800d...` }
}

But new versions o= f Android (which use Conscrypt/OpenSSL) reference the curve by name:

SEQUENCE {
  SEQUENCE {
    # ecPublicKey
    OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
    # secp521r1
    OBJECT_IDENTIFIER { 1.3.132.0.35 }
  }
  BIT_STRING { `0004019519de800d...` }
}

The original certi= ficate embeds the curve.

I believe my problem is that th= e Java APIs I=E2=80=99m using don=E2=80=99t return raw bytes from the certi= ficate. Instead Java decodes the certificate into a model and re-encodes th= at when the bytes are requested. The original and roundtripped SPKI bytes a= re not identical.

Does anyone else do ASN.1 encod= ing in order to compute a certificate=E2=80=99s pin? Or is it a uniquely Ja= va problem?!

The spec should warn that a sin= gle SPKI may have multiple conflicting encodings. I suggest that only encod= ing in the certificate should be pinned. TLS server administrators should a= lso be careful to not inadvertently re-encode their SPKIs when doing mainte= nance.

Thanks!

=E2=80=8B
--001a114088b09311fc0532d88438-- From nobody Sun May 15 00:23:50 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B672212B04C for ; Sun, 15 May 2016 00:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaPcXw4eTuzh for ; Sun, 15 May 2016 00:23:45 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542761200A0 for ; Sun, 15 May 2016 00:23:45 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id e201so66552731wme.0 for ; Sun, 15 May 2016 00:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KIW0MzhY0SnVM109cM3cIXUmrbCM7pG0dPSRRJMs5zE=; b=H+j5rwFBLSVfh8+ezk5Yq60i6qfoKQKoILUdQCTNC5JVlvKmjhJT6dTtIPuIBbxsae x69xfRf0THgxEA9lv5sj/QDSvI/xCo6/JHJCn+jSbmRt1RH0f2b0RhZgPymraK7GSCG6 QWBJODjHcJN6Mp4LRhDqQZpWiEQ9vQmkotBpQTn23uyFqHax0uIxdaS/HG08VLVRvAU1 XdSP+kfFU7cTO4GYu/Fiib9hsnCNum9mzmjBS6tjI2+JLhz7i2ROHOVinOqpwTVUevCU o3lNdkGfe3QqW/DAjes6WLy2MwuU8VJ/4mQf+tWdrKPDyWRV/s0J/FT+jbTvFXdWmKH8 G/pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KIW0MzhY0SnVM109cM3cIXUmrbCM7pG0dPSRRJMs5zE=; b=BGQR7LXcjid0PGpbAPsnI9MxmCu/OjkmpocUeQBZ4ROWxo17cpPCqkCmhy3/xXqYGV zlqeNSA7g5GixBAMhGUsxEEi74cVKCHe/QsyC6tiKourzpxg8X/2YvCmfwf1Z0y62Za2 jp11XG9sR5mTe+VMOcHQT2Cg/gKws+gFa1HeAQTyvxXkslDXRxgSRlJOLUpLn5nTq134 auIXCJpc5by/xAQvPWswMe0ZjWMRyIFCn7UY2fX1K3WH4VTKorUrEKCsfWOvXceh9iY8 x9a1tqvoPxNNhdAoj+pZltkddMlBn90WAGaQGvf2CtmI5hLETKNtL//nRRrssWXkQeXs 4Cew== X-Gm-Message-State: AOPr4FULIp1Qpv+Pl7PX4KvFTAM1N7MOyD3Y9NGffGB3jtT/C/sHXyXSWScOBKI1wHOz1Q== X-Received: by 10.194.139.104 with SMTP id qx8mr23038422wjb.14.1463297023854; Sun, 15 May 2016 00:23:43 -0700 (PDT) Received: from [172.24.249.66] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id az2sm27292992wjc.6.2016.05.15.00.23.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 00:23:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_042E2560-518D-4F74-A563-F5AB340824C0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Sun, 15 May 2016 10:22:39 +0300 Message-Id: <2133CA94-B702-4A6C-BB79-01B773762168@gmail.com> References: To: Jesse Wilson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: websec@ietf.org Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 07:23:48 -0000 --Apple-Mail=_042E2560-518D-4F74-A563-F5AB340824C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s interesting. With HPKP you can pin keys from existing = certificates, or keys that are not (yet) in certificates. One of the early deployment scenarios (which got de-emphasized later on) = was that you include two pins: your current production key and a spare = key that you will certify if something bad happens to the production key = (like the private key leaking out). So because there is more than one way to encode the public key in SPKI = you would need to predict how your CA is going to encode the SPKI of the = spare key. There=E2=80=99s a couple of obvious heuristics: assume that = the SPKI will be encoded the same way the SPKI is encoded in the = certificate request, or assume that the SPKI in the next certificate = will be encoded the same way as in the current certificate. Both of = these heuristics could work most of the time, but if you miss, your pin = is invalid and your site is bricked if you move to the backup public = key. It gets worse. Some sites re-certify the same key over and over. But = again, nothing is preventing the CA from encoding the SPKI differently = on the next certificate Maybe they=E2=80=99ve upgraded their software. So there could be more caveats here for using HPKP in addition to = needing to use the SPKI bytes from your actual DER-encoded certificate. As a procedural note, there is no longer a WebSec working group, and = RFCs, once published, are set in stone. Someone (you?) could publish a = document with a title like =E2=80=9CAdditional Operational = Considerations in Deploying HPKP=E2=80=9D. That could prove interesting. Yoav > On 15 May 2016, at 5:46 AM, Jesse Wilson wrote: >=20 > I work on OkHttp, an Android HTTP client that implements HPKP-like = certificate pinning. We recently saw a problem where different versions = of Android returned different bytes for the ASN.1 encoding of the same = certificate. This is bad: the pins don=E2=80=99t match! >=20 > The certificate of interest uses a named curve (secp521r1) with ECC. I = used der2ascii to view the SPKI = ASN.1 bytes. >=20 > Older versions of Android (which use BouncyCastle) embed the curve: >=20 > SEQUENCE { > SEQUENCE { > # ecPublicKey > OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } > SEQUENCE { > INTEGER { 1 } > SEQUENCE { > # prime-field > OBJECT_IDENTIFIER { 1.2.840.10045.1.1 } > INTEGER { `01ffffffffffffff...` } > } > SEQUENCE { > OCTET_STRING { `01ffffffffffffff...` } > OCTET_STRING { `0051953eb9618e1c...` } > } > OCTET_STRING { `0400c6858e06b704...` } > INTEGER { `01ffffffffffffff...` } > INTEGER { 1 } > } > } > BIT_STRING { `0004019519de800d...` } > } > But new versions of Android (which use Conscrypt/OpenSSL) reference = the curve by name: >=20 > SEQUENCE { > SEQUENCE { > # ecPublicKey > OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } > # secp521r1 > OBJECT_IDENTIFIER { 1.3.132.0.35 } > } > BIT_STRING { `0004019519de800d...` } > } > The original certificate embeds the curve. >=20 > I believe my problem is that the Java APIs I=E2=80=99m using don=E2=80=99= t return raw bytes from the certificate. Instead Java decodes the = certificate into a model and re-encodes that when the bytes are = requested. The original and roundtripped SPKI bytes are not identical. >=20 > Does anyone else do ASN.1 encoding in order to compute a = certificate=E2=80=99s pin? Or is it a uniquely Java problem?! >=20 > The spec should warn that a single SPKI may have multiple conflicting = encodings. I suggest that only encoding in the certificate should be = pinned. TLS server administrators should also be careful to not = inadvertently re-encode their SPKIs when doing maintenance. >=20 > Thanks! >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --Apple-Mail=_042E2560-518D-4F74-A563-F5AB340824C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s interesting. With HPKP you can pin keys from = existing certificates, or keys that are not (yet) in certificates.

One of the early = deployment scenarios (which got de-emphasized later on) was that you = include two pins: your current production key and a spare key that you = will certify if something bad happens to the production key (like the = private key leaking out).

So because there is more than one way to encode the public = key in SPKI you would need to predict how your CA is going to encode the = SPKI of the spare key. There=E2=80=99s a couple of obvious heuristics: = assume that the SPKI will be encoded the same way the SPKI is encoded in = the certificate request, or assume that the SPKI in the next certificate = will be encoded the same way as in the current certificate. Both of = these heuristics could work most of the time, but if you miss, your pin = is invalid and your site is bricked if you move to the backup public = key.

It gets = worse. Some sites re-certify the same key over and over. But again, = nothing is preventing the CA from encoding the SPKI differently on the = next certificate Maybe they=E2=80=99ve upgraded their = software.

So = there could be more caveats here for using HPKP in addition to needing = to use the SPKI bytes from your actual DER-encoded = certificate.

As = a procedural note, there is no longer a WebSec working group, and RFCs, = once published, are set in stone. Someone (you?) could publish a = document with a title like =E2=80=9CAdditional Operational = Considerations in Deploying HPKP=E2=80=9D. That could prove = interesting.

Yoav


On 15 May 2016, at 5:46 AM, Jesse Wilson <jesse@swank.ca> = wrote:

I work on OkHttp, an = Android HTTP client that implements HPKP-like certificate pinning. We = recently saw a problem where different versions of Android returned = different bytes for the ASN.1 encoding of the same certificate. This is = bad: the pins don=E2=80=99t match!

The certificate of interest uses a named = curve (secp521r1) with ECC. I used der2ascii to = view the SPKI ASN.1 bytes.

Older versions of Android (which use = BouncyCastle) embed the curve:

SEQUENCE {
  SEQUENCE {
    # ecPublicKey
    OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
    SEQUENCE {
      INTEGER { 1 }
      SEQUENCE {
        # prime-field
        OBJECT_IDENTIFIER { 1.2.840.10045.1.1 }
        INTEGER { `01ffffffffffffff...` }
      }
      SEQUENCE {
        OCTET_STRING { `01ffffffffffffff...` }
        OCTET_STRING { `0051953eb9618e1c...` }
      }
      OCTET_STRING { `0400c6858e06b704...` }
      INTEGER { `01ffffffffffffff...` }
      INTEGER { 1 }
    }
  }
  BIT_STRING { `0004019519de800d...` }
}

But = new versions of Android (which use Conscrypt/OpenSSL) reference the = curve by name:

SEQUENCE {
  SEQUENCE {
    # ecPublicKey
    OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
    # secp521r1
    OBJECT_IDENTIFIER { 1.3.132.0.35 }
  }
  BIT_STRING { `0004019519de800d...` }
}

The = original certificate embeds the curve.

I believe my problem is that the Java APIs = I=E2=80=99m using don=E2=80=99t return raw bytes from the certificate. = Instead Java decodes the certificate into a model and re-encodes that = when the bytes are requested. The original and roundtripped SPKI bytes = are not identical.

Does anyone else do ASN.1 encoding in order to compute a = certificate=E2=80=99s pin? Or is it a uniquely Java problem?!

The spec should warn = that a single SPKI may have multiple conflicting encodings. I suggest = that only encoding in the certificate should be pinned. TLS server = administrators should also be careful to not inadvertently re-encode = their SPKIs when doing maintenance.

Thanks!

=E2=80=8B
_______________________________________________
websec = mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

= --Apple-Mail=_042E2560-518D-4F74-A563-F5AB340824C0-- From nobody Sun May 15 10:10:23 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65412D1E6 for ; Sun, 15 May 2016 10:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYglaHEf_YU5 for ; Sun, 15 May 2016 10:10:21 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0F712D1E4 for ; Sun, 15 May 2016 10:10:21 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x201so238645818oif.3 for ; Sun, 15 May 2016 10:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XRHssBVmQCeuUr/YlLGqqKnHdB6gnTMsRqKLckntROA=; b=bKM5WwdFbq16kJNxdcHGfO606ESZp7q5ut7PY6Hv+n0KgotxYZwPG59fH9haxIql/7 2A0kA9M0UV9Euu7TARCrlG0LI3PxiRRS6vqswq3vrc468tfXknLp0T+VL6P94n11vxSL 8sumQmyjNQYtmjZHrV7PlLvIODWOoOxC3b7SzngSqn0pewi0tqIh1nvUiDZXh7a9uMcA SEWG4a5WGIAL++KPPqb9+hZvoZmtXP3Mw/lxkINyDuvNh2IUwLuUuGJUMTdd+rbza7uH JdmKq3tc/DULQUfNVEKIrjP5MUJ7/iI9rUOCpOZVYiQJMJ7AuCLYPOEDyIT6vquQeJXO PTYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XRHssBVmQCeuUr/YlLGqqKnHdB6gnTMsRqKLckntROA=; b=NqVNPyT2s1UYZmoH628UouDc5onu30JOAS+RBNtK2HXhBspnGsnsP/zocK8iOpOX2l aSXGjJxIlZGxlsdrth+tQ9Nh1YyYaHxnIFnwlqLCis5m+lSe94XPUTm659ghAljVfGJP Ny+N+7HHhiuGy+r65mE25EziZrzCnuou/pLYegNqoqkK1VQIYJRggw49+fr7KVwkVG4o Lc8Rj4Ccs4WaUi9d/AiUDr6bmOpPWsk26uL9QJgyJ0eKe01uoNBtw+pjKU3KFNSk5Ipa yMlHKpYIoTnoQcfLIwUZ4J5Ds9Fp4mYSGJjKYFJiKGcBDmablsitcQJ9MqPH7NnDksOm sVyg== X-Gm-Message-State: AOPr4FXMwAd1NxuIA0xrJgVOz09ORLzbeRWf4E6BRTQYvfmlyxgcIWljCWko0lFTRxnXcg== X-Received: by 10.202.218.84 with SMTP id r81mr14999299oig.49.1463332220477; Sun, 15 May 2016 10:10:20 -0700 (PDT) Received: from [172.18.133.40] (cowboy.intuit.com. [65.204.229.11]) by smtp.gmail.com with ESMTPSA id bb9sm4336430oec.6.2016.05.15.10.10.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 May 2016 10:10:19 -0700 (PDT) To: Yoav Nir , Jesse Wilson References: <2133CA94-B702-4A6C-BB79-01B773762168@gmail.com> From: Yaron Sheffer Message-ID: <5738AD77.6060509@gmail.com> Date: Sun, 15 May 2016 20:10:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <2133CA94-B702-4A6C-BB79-01B773762168@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: websec@ietf.org Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 17:10:22 -0000 On 15/05/16 10:22, Yoav Nir wrote: > That’s interesting. With HPKP you can pin keys from existing > certificates, or keys that are not (yet) in certificates. > > One of the early deployment scenarios (which got de-emphasized later > on) was that you include two pins: your current production key and a > spare key that you will certify if something bad happens to the > production key (like the private key leaking out). > > Hi Yoav, I had assumed this *is* the main deployment scenario. If it was de-emphasized, what do you consider as the "classic" HPKP usage scenario? Thanks, Yaron From nobody Sun May 15 10:22:23 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F712D1EC for ; Sun, 15 May 2016 10:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Ch1Q1HXFNc for ; Sun, 15 May 2016 10:22:19 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D92A12D1EA for ; Sun, 15 May 2016 10:22:19 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id x35so22091211ioi.0 for ; Sun, 15 May 2016 10:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-transfer-encoding; bh=v14HEvHt43f6f7GWZrWJgQJntxM5P/tIcaLkOi4I46o=; b=ABSmojQYXbgos4OMX8kYT2C2aNTnSqbzP23nssTgT7Knd4p1BjHT18G9woW5MnEqQZ EAGeN4GrXgXVrg1RXdKzRa4igzUvB3BxacBUaiMig5Yug0YLAtlW8n6iFuLRudLvO1Ei E7CnEn4nPjXHTjLfOeqlnncaV7zmRFi1ehv8+Q31U5NtjxZQ895GLImSgCd3a1O4hhyP 5LOPTGRu+pqLUOXVeFNRzA3QOtcCNC+aQCYVMA0W9aBUB3L08ZODcZEPePnTU8inXWMx 6qrJOUsqDBfvIty9kc6Q73n+r+QP7AzMoSa4HZYmzpZ/CWxklBYjm/u/2fKR9UgiN7nd MCVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-transfer-encoding; bh=v14HEvHt43f6f7GWZrWJgQJntxM5P/tIcaLkOi4I46o=; b=CN+Rdsbtol/R+FOYey7aW/0vhCDHg7Oe1jdq8sMYDeXHvOKaMQKgQhgC18mGLbD4Qz Utg4QlcKsC74ZQDcY8boiJR0A87b4Ktigw7xuhy/dUQYVNtnGW88eky8ghjueCeVO3m2 Yb7tsOH2Di5t1oPAsL1ZsVT4Vv9b47AzYV5dqYTybz+o+IjZ+q5kr/lBM2WmCD7gG6Cg x96XWMxexz+mGCJbgv03uKsHQDUlAvv03LaV0aa8U7ZpqgpM1zKsV7ke7FaPyeeII2KR sHqWX15oaARuMlcmavItVm4UEpzt0Ic5AUHVra+yM+rTkCVY9IVs1ShtFEFD07Vic5qs f73w== X-Gm-Message-State: AOPr4FW98FNHheRO1xRZAhXa5h7Hgc7wWHnLrRtsLsDzhnhUrdoBrKl5WdibaaMcxCUxwLwDMgmS2nqku2OU2Q== MIME-Version: 1.0 X-Received: by 10.36.252.199 with SMTP id b190mr1594580ith.2.1463332938910; Sun, 15 May 2016 10:22:18 -0700 (PDT) Received: by 10.64.126.67 with HTTP; Sun, 15 May 2016 10:22:18 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 May 2016 13:22:18 -0400 Message-ID: From: Jeffrey Walton To: Jesse Wilson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 17:22:22 -0000 On Sat, May 14, 2016 at 10:46 PM, Jesse Wilson wrote: > I work on OkHttp, an Android HTTP client that implements HPKP-like > certificate pinning. We recently saw a problem where different versions o= f > Android returned different bytes for the ASN.1 encoding of the same > certificate. This is bad: the pins don=E2=80=99t match! > > The certificate of interest uses a named curve (secp521r1) with ECC. I us= ed > der2ascii to view the SPKI ASN.1 bytes. > > Older versions of Android (which use BouncyCastle) embed the curve: > > SEQUENCE { > SEQUENCE { > # ecPublicKey > OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } > SEQUENCE { > INTEGER { 1 } > SEQUENCE { > # prime-field > OBJECT_IDENTIFIER { 1.2.840.10045.1.1 } > INTEGER { `01ffffffffffffff...` } > } > SEQUENCE { > OCTET_STRING { `01ffffffffffffff...` } > OCTET_STRING { `0051953eb9618e1c...` } > } > OCTET_STRING { `0400c6858e06b704...` } > INTEGER { `01ffffffffffffff...` } > INTEGER { 1 } > } > } > BIT_STRING { `0004019519de800d...` } > } > > But new versions of Android (which use Conscrypt/OpenSSL) reference the > curve by name: > > SEQUENCE { > SEQUENCE { > # ecPublicKey > OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } > # secp521r1 > OBJECT_IDENTIFIER { 1.3.132.0.35 } > } > BIT_STRING { `0004019519de800d...` } > } > > The original certificate embeds the curve. > > I believe my problem is that the Java APIs I=E2=80=99m using don=E2=80=99= t return raw bytes > from the certificate. Instead Java decodes the certificate into a model a= nd > re-encodes that when the bytes are requested. The original and roundtripp= ed > SPKI bytes are not identical. > > Does anyone else do ASN.1 encoding in order to compute a certificate=E2= =80=99s pin? > Or is it a uniquely Java problem?! > > The spec should warn that a single SPKI may have multiple conflicting > encodings. I suggest that only encoding in the certificate should be pinn= ed. > TLS server administrators should also be careful to not inadvertently > re-encode their SPKIs when doing maintenance. This is kind of expected. The problem is because the first certificate (older version of Android) uses domain parameters; while the second certificate (Conscrypt/OpenSSL) uses a named curve rather than domain parameters. I've experienced similar problems with OpenSSL servers and clients. In fact, if a named curve is *not used*, then you will encounter an error "no shared ciphers" under some circumstances. Also see http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography#Named_Curves. A certificate simply binds a public key to an identity through a trusted party's signature. Once you verify the signature on the certificate, you should canonicalize the certificate data and then pin the normalizedd data. Jeff From nobody Sun May 15 10:31:23 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4220612B022 for ; Sun, 15 May 2016 10:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sKMd31eT_yb for ; Sun, 15 May 2016 10:31:20 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E70812B018 for ; Sun, 15 May 2016 10:31:20 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id qe5so37930104igc.1 for ; Sun, 15 May 2016 10:31:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7xzIfDeVAYlnM5gAONWXuVSpd2kldlPZEQbZLXyRYyE=; b=LbEhRV8NqXTvn5Dcwhvrx6w9MRb+3FA99cOg88xBR2XGtq6aKLVbotRE6UP6c8aT3/ 6BEcvCxC4hZpTM6BUqenpls6Nbo1WuyB+S/T56v4zxGVyJUbgxG7JJC9UodpzYlqVMNR Sj+5A9E0dIA+7tIdEku2/t70cDprsTkUOZBvQY1QTjguEx8JxKoAL3mz89PAiFAVAmkD qNTZHSImOGlP3ZLNusf3kMuPfKnFrlFJcc/irqzse7HCLAAQ4FvLt923MeUN0dRaEmqE Rkcq+FimPuDm4gNJGFuNdGcJF0V54XoDrQOGc1sB/g1jkkDrQtH/eJkKhr/sXPzWcV93 1Rhg== X-Gm-Message-State: AOPr4FUqbrqSULDpsvtBaWVbd5BwZOfPv+2u/YTavAhXaCDU6h7JxcrKjPOHaef8TxSPXEmx9GtYRvyC+tF9Vg== X-Received: by 10.50.13.106 with SMTP id g10mr8550588igc.65.1463333479417; Sun, 15 May 2016 10:31:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jesse Wilson Date: Sun, 15 May 2016 17:31:09 +0000 Message-ID: To: noloader@gmail.com Content-Type: multipart/alternative; boundary=089e013c69ce3a8feb0532e4e03d Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 17:31:21 -0000 --089e013c69ce3a8feb0532e4e03d Content-Type: text/plain; charset=UTF-8 I definitely like the idea of a canonical form. That makes everything easy! But which format is the canonical one? --089e013c69ce3a8feb0532e4e03d Content-Type: text/html; charset=UTF-8
I definitely like the idea of a canonical form. That makes everything easy! But which format is the canonical one?
--089e013c69ce3a8feb0532e4e03d-- From nobody Sun May 15 10:42:05 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C376812B035 for ; Sun, 15 May 2016 10:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMMAJdaNMK34 for ; Sun, 15 May 2016 10:42:02 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A227812B018 for ; Sun, 15 May 2016 10:42:02 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id d62so10867306iof.1 for ; Sun, 15 May 2016 10:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=EcqZjU6zOuAneos0v1MC0im+BraepEeX7J91WYSjr3A=; b=aKAC8Os/JmiiKX/qRL4AmE4qjBdZsluu5E8JyJy2XUXmluyaSUMRtDT7af1zF8SBVj MW7rajqBDtRcEjs65tWneKZkvXlI+73MtuheBeHRn7AtxrsGEVKCUjyZkC3zq7TyvADt ju1levOUbk78AZkx1rE5LWqJ4bBlR7DLVDJDXXLBN1XQgI4v0u51wUG7d5NOKcRiDJ1X rhz0HFEjRpP/bLh/tnkf4K1cseUzlpEyvHtn/rqm01SKalIbVHY0GzTcOOBxfRHsSKbo AMBvqllmhYZZKp09MUh/go2zui0Y1lLvQXW6biw6/aYR4v0Q58k11u5R6XDj03PoVXrV yuww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=EcqZjU6zOuAneos0v1MC0im+BraepEeX7J91WYSjr3A=; b=ZzjtzkjJFQeYZjlBS2WM0sKw3+P/Gu+ppopVljybnd/PVr6XE6n0EwRjypecQN2PPc CtrWSjhN57hJVBqehOy3R/iaNXbbeyxJ2GQrFwmG03UYQjV0olbR4GAKkcXf9BA2G/Ys E23+poFdUsrlrhNjoL458ncac5dzsp5j4JTJ+wShohC/CkYf/OjFPkmz5UZsxP2pAh7L yE1iFVXV5ubofCBMMkisfDrD2OzRhVnSi8r9BUfZGhXv39BnOeCBbVRT9Fq5kyzBCvt0 wYxC+pvvg+FGeIs1bfFP3Y/PtADpgC8wLmmiIEKuFoad49JUkNkkCfX+f1pOKXkwwe6y Pyew== X-Gm-Message-State: AOPr4FU1u0OspbUI2K6OZ6bgKOiQlBYnPA7MjMr9bqil/1srnfugdd9qoaV5HX9X5AHovPmOa5+jcn3BuQOMXQ== MIME-Version: 1.0 X-Received: by 10.107.134.24 with SMTP id i24mr17145683iod.130.1463334121962; Sun, 15 May 2016 10:42:01 -0700 (PDT) Received: by 10.64.126.67 with HTTP; Sun, 15 May 2016 10:42:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 May 2016 13:42:01 -0400 Message-ID: From: Jeffrey Walton To: Jesse Wilson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 17:42:04 -0000 On Sun, May 15, 2016 at 1:31 PM, Jesse Wilson wrote: > I definitely like the idea of a canonical form. That makes everything easy! > But which format is the canonical one? It depends. One way to do it is to expand to domain parameters. All named curves can be expanded to its constituent domain parameters. Another way to do it is by comparing public points after you determine the named curve or domain parameters are equivalent. What you can't do is take domain parameters, and map _all_ of them back to named curves. Custom curves likely won't have an OID associated with them. Additionally, not all named curves are recognized by all libraries. For example, the old 1998 X9.62 curves are mostly no longer supported; and the WTLS curves are usually not supported because of weaker parameters even though they have well known names. For completeness, the public point is the coordinate Q=(x,y), and its created by raising the base point G to the private exponent x (i.e., Q=G^x). But for the Q=G^x machinery to work, the domain parameters need to be the same for both parties, Jeff From nobody Sun May 15 11:26:04 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E065D12D18A for ; Sun, 15 May 2016 11:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idDFNHioNMip for ; Sun, 15 May 2016 11:26:02 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA9F12D0AF for ; Sun, 15 May 2016 11:26:01 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a17so104635604wme.0 for ; Sun, 15 May 2016 11:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uOxFXdNhYvhJFIr75C1/WlCx0MSPJFJAwUpdtiuKRiU=; b=0t3Q4Dd/Gcv8teoyS0ljH8xcFs7jBVDf22w+vkPbZ7fOwvNjueTFycjyEh80iF/FFl waCBLQRP0pJiLIld7K+KeOQxR54nvciSL9bKTFBzfezpBV7pmayI4Lb+JNBokikU6kU3 3ISxgCkjai5m+JmItb9y1gTt/04tvO+ywSjVrgPvHGVP8SfJBdxeR9iHlnZonE/WIk/Q 9u/ZIma/F0GWiMik7eHREiaCcDay9f0la+L2bd6pwLBk/7mhPagSPH4+MZ94PZi7kc/5 Vr86+z3p7JNjNyrHktcW7O+ShO3DDM1GgmYC93vVHprxeodexlJhXCoZtNy7c+OnROyz y4dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uOxFXdNhYvhJFIr75C1/WlCx0MSPJFJAwUpdtiuKRiU=; b=ZejdVf7Y9Ansaneuk0mIXE4etdo120XYAvKW3hl2ZUbxZ2GyEhEiMQ++PzGJgk5sYL dZG5vGezV1UvFRz1M1fgjxUFv9DcGwwWUR4ZK2vC+ZT8Vfz1ls8GJFQe6Mqb8b/9VTNC bca0Z3m2G4jsjftc6F5P31CRlNJcl6Ji1BTODhco7tq7qia/N6xjznASX9Y+B1JQJ804 z0T4PV1OZz5B9djJq8LKvLZqWFDZgo+1TIQrBv8d3qodaBdTP2e3i8xbb/1rGQxuSoU7 WdbstEkmvQ+rnRzzhquD3TbqY1kRSh4LfmNnSiNIsZx6abksy5lrNu3TNvdeF799y5a0 A1qQ== X-Gm-Message-State: AOPr4FVMcRmMIp8TL+iQUVukycKurwGIiitaWQ0Jik5chrg7DA1YJ7p+A1Ay9zd22w+YpA== X-Received: by 10.28.227.138 with SMTP id a132mr13324577wmh.35.1463336760289; Sun, 15 May 2016 11:26:00 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id i194sm14315023wmf.6.2016.05.15.11.25.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 11:25:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <5738AD77.6060509@gmail.com> Date: Sun, 15 May 2016 21:24:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2133CA94-B702-4A6C-BB79-01B773762168@gmail.com> <5738AD77.6060509@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: websec@ietf.org Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 18:26:03 -0000 > On 15 May 2016, at 8:10 PM, Yaron Sheffer = wrote: >=20 >=20 >=20 > On 15/05/16 10:22, Yoav Nir wrote: >> That=E2=80=99s interesting. With HPKP you can pin keys from existing = certificates, or keys that are not (yet) in certificates. >>=20 >> One of the early deployment scenarios (which got de-emphasized later = on) was that you include two pins: your current production key and a = spare key that you will certify if something bad happens to the = production key (like the private key leaking out). >>=20 >>=20 > Hi Yoav, >=20 > I had assumed this *is* the main deployment scenario. If it was = de-emphasized, what do you consider as the "classic" HPKP usage = scenario? Current certificate plus some CA certificate that you are likely to use = to certify your next certificate. Yoav From nobody Sun May 15 11:26:18 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8589612D527 for ; Sun, 15 May 2016 11:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-O48w5KO1YY for ; Sun, 15 May 2016 11:26:16 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8786312D525 for ; Sun, 15 May 2016 11:26:16 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n129so77510902wmn.1 for ; Sun, 15 May 2016 11:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uOxFXdNhYvhJFIr75C1/WlCx0MSPJFJAwUpdtiuKRiU=; b=0t3Q4Dd/Gcv8teoyS0ljH8xcFs7jBVDf22w+vkPbZ7fOwvNjueTFycjyEh80iF/FFl waCBLQRP0pJiLIld7K+KeOQxR54nvciSL9bKTFBzfezpBV7pmayI4Lb+JNBokikU6kU3 3ISxgCkjai5m+JmItb9y1gTt/04tvO+ywSjVrgPvHGVP8SfJBdxeR9iHlnZonE/WIk/Q 9u/ZIma/F0GWiMik7eHREiaCcDay9f0la+L2bd6pwLBk/7mhPagSPH4+MZ94PZi7kc/5 Vr86+z3p7JNjNyrHktcW7O+ShO3DDM1GgmYC93vVHprxeodexlJhXCoZtNy7c+OnROyz y4dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uOxFXdNhYvhJFIr75C1/WlCx0MSPJFJAwUpdtiuKRiU=; b=K0GZTr/BwZxQ1UcrYx3Di35346t4WSeJG/K0yS9UZmSN6TlwnAuNiG50Z5SkWHcgsT tFxQ++fw4Dd5AXQ8+kEGA9PoTXsc7O0ixfhA5b3BGYhFAjWHvyzLMDEqucAoVrUEjVp9 BUhoZcHYVAZye3qHpDgDceg7PnF6vigHPsQ5p7qOaktS+5F6Q4yit4bTBGRo0F3J47KX /ppFbrwXtbtZ5/Ty05hcZC3lpBXxMhoWWuuaPtR+Q5yKif6wzH52lDzqc1+trURONVwY PhoO5H7hBwbRiwE9k49UdrCnL3/nHNgrkiiG2La37xcgUbXlkj7zDmHBCifLkOfs/Hex LrFA== X-Gm-Message-State: AOPr4FUlQ/A8AnjeNJDerT/g6Tid1816uhWe3PE21RRCognYVaA/XQlox3YG1zpwbRn0Rg== X-Received: by 10.28.215.1 with SMTP id o1mr14214786wmg.26.1463336775066; Sun, 15 May 2016 11:26:15 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id he10sm29730740wjc.21.2016.05.15.11.26.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 11:26:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <5738AD77.6060509@gmail.com> Date: Sun, 15 May 2016 21:24:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2133CA94-B702-4A6C-BB79-01B773762168@gmail.com> <5738AD77.6060509@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: websec@ietf.org Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 18:26:17 -0000 > On 15 May 2016, at 8:10 PM, Yaron Sheffer = wrote: >=20 >=20 >=20 > On 15/05/16 10:22, Yoav Nir wrote: >> That=E2=80=99s interesting. With HPKP you can pin keys from existing = certificates, or keys that are not (yet) in certificates. >>=20 >> One of the early deployment scenarios (which got de-emphasized later = on) was that you include two pins: your current production key and a = spare key that you will certify if something bad happens to the = production key (like the private key leaking out). >>=20 >>=20 > Hi Yoav, >=20 > I had assumed this *is* the main deployment scenario. If it was = de-emphasized, what do you consider as the "classic" HPKP usage = scenario? Current certificate plus some CA certificate that you are likely to use = to certify your next certificate. Yoav From nobody Sun May 15 12:54:56 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D3512D528 for ; Sun, 15 May 2016 12:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ctnv7JHa-Eu9 for ; Sun, 15 May 2016 12:54:54 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF75C12D526 for ; Sun, 15 May 2016 12:54:53 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a17so106595283wme.0 for ; Sun, 15 May 2016 12:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VnLYsKY/f4l9dFxK9P+EEUFeJ/9RtDnTyBsQd/Ob3w0=; b=VdzwbhDl9RlsAea4q1HawdR2Y7PUwtkbjWN51i2X/jAUZxgbFWy6VbW86mIK5hDisk SGONrz37YK1+kUHVuK1rFCr5YLrPHp/K5hmwx4YTLgAQ+hS4YXo/JGxVLlu625O4YXQe 2Wjy713EBN4pz4IaSBM8WYTJiFSbwk8UzZQyf81DbORHFjQRRmQJiz3nCnsT2GNG+NSU G9IEX9Wi17lceCYiEyHLn8S9+YhrUjUNhGXsDKBDxRxDMdzyx9l+YqX7gkd7bZ5bswGC Kh0PQG+R0C25NRxFs0/Npqqmpd80/uUQJrWAGMt4tCKdYNYNUREKrlgT22odyT/Nq3H7 gfPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VnLYsKY/f4l9dFxK9P+EEUFeJ/9RtDnTyBsQd/Ob3w0=; b=BRceOLoaMiOFB+6//MkfG60sC68M0bbUcLeP0qKUImLCiQy3tsiYvovg1wBX5xhGoB JTnSYSfMXzIp0qTmnKp406D8R3gRY5P3twwcBBWObZ5s8E+O1DSgNECm9nhENlhzwnkH 0aIYzWpFW+oBcKM8jlP5NbKIb2ezCFZW6XizP3gBEibc0E3XDI9ltMTsjHcuJq7rUxB5 Q15mAalUJLXuQUbMg/UbS0VBscRMq5CHuTXbYZGrh3lT6cbOS6q76yv1uk/TYZsu3TAt 77lsusf5wOznrqONhuNfy079Xw1NvaITBFEQymeFuBni78pZ3yO5SZcjGd3J79BYoccb 0a6w== X-Gm-Message-State: AOPr4FXRabW8mo5v9hjle/V1S2e4wB4n2peI6yVA3nTHVGJKLCMjsaxCNVT+NhiOYJX3ew== X-Received: by 10.194.173.42 with SMTP id bh10mr28973715wjc.150.1463342092268; Sun, 15 May 2016 12:54:52 -0700 (PDT) Received: from [10.0.0.11] (bzq-79-182-201-82.red.bezeqint.net. [79.182.201.82]) by smtp.gmail.com with ESMTPSA id w3sm30040682wjt.0.2016.05.15.12.54.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 May 2016 12:54:51 -0700 (PDT) To: Yoav Nir References: <2133CA94-B702-4A6C-BB79-01B773762168@gmail.com> <5738AD77.6060509@gmail.com> From: Yaron Sheffer Message-ID: <5738D403.5010000@gmail.com> Date: Sun, 15 May 2016 22:54:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: websec@ietf.org Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 19:54:55 -0000 >> On 15/05/16 10:22, Yoav Nir wrote: >>> That’s interesting. With HPKP you can pin keys from existing certificates, or keys that are not (yet) in certificates. >>> >>> One of the early deployment scenarios (which got de-emphasized later on) was that you include two pins: your current production key and a spare key that you will certify if something bad happens to the production key (like the private key leaking out). >>> >>> >> Hi Yoav, >> >> I had assumed this *is* the main deployment scenario. If it was de-emphasized, what do you consider as the "classic" HPKP usage scenario? > > Current certificate plus some CA certificate that you are likely to use to certify your next certificate. > > Yoav > But this too means that you're guessing how the CA will behave in the future. If your current cert is expiring in a month and you generate the new one, you can be surprised by the CA using a new intermediate cert. And of course, some people would never pin to a CA cert. To me, the whole idea of certificate pinning is to reduce the need to trust the PKI industry, and that includes my own friendly CA. Thanks, Yaron From nobody Sun May 15 13:32:19 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC66B12D1E7 for ; Sun, 15 May 2016 13:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFsWQtIMF_bP for ; Sun, 15 May 2016 13:32:16 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F9A12D11F for ; Sun, 15 May 2016 13:32:16 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n129so79563784wmn.1 for ; Sun, 15 May 2016 13:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rF+WOOCrLwseu7+/+jO5fRCPA7n8gMFKBwahDv1foZE=; b=xY06pLvjo3PgrLE+1dqtGpja4yHhM0njUNe+gvfWOHoJv+QTFIfHq6feruCb45+skv dtz8aCNPLF9vOu6nKKBHcPmC7xQu211oCRHQyJh4nhaZuLut/zByiDQyFVLqFZ50OzK4 +zFEkpNjhEW3b7B5lSVZaKOOaL0JzuCTWh/X8Co90FEfxgDei/GMoMXg3hRBx2ghw3/5 dXeO5XWPIjBI7SWjphAuUhhetvBSRF41YugoOz6X807mvqp4HyKomZad8mRvNh0bhxVo XA1DXYgM5Uqvap7X41LtjaOoLvio7LrU/Iu0Kqlh6iJVzVa7jdkx6f/7uOP5gg8zwgKJ Kovg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rF+WOOCrLwseu7+/+jO5fRCPA7n8gMFKBwahDv1foZE=; b=P+JAYcwQ0+Qu1U/zlor3GF67tSzvB9Uqlcq0koWE7NVcrSE8M3lM3BsIuYY8MXLFX3 QgHj5ifUdPPDSKU6Q6Jp1tR03Rvf9mHTXny5qI/PmbrG16zMDskI+Gz091LQ/qZaAv5z UvZebcKee7e7wVDqG9Qd8dOPNNVq7mn0B/SGGdS7/ZW2Gnpjz6zhOkObzP+frf1FoLPE 4sDY3BnhkirgMJg0NhjX87VUCKA5sgUVg6bKWy6buZOw0zEEMh83WxA4Gdzg+2br/oz0 WugAg42i/8MLTCOQAzx28qdTWuSg0TPxm8vEvvbdfIUaVtVdqJxEt1uI+Zf+SR3rJQea GkAA== X-Gm-Message-State: AOPr4FVcTSQcr/JzyKGJD4tQIaznDsG3WcIrP0JPFyqUkJYNovcAWyKyR2VNdNVrN+PBHg== X-Received: by 10.28.125.138 with SMTP id y132mr14117352wmc.90.1463344334720; Sun, 15 May 2016 13:32:14 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id jp2sm30172603wjc.16.2016.05.15.13.32.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 13:32:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <5738D403.5010000@gmail.com> Date: Sun, 15 May 2016 23:32:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2133CA94-B702-4A6C-BB79-01B773762168@gmail.com> <5738AD77.6060509@gmail.com> <5738D403.5010000@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: websec@ietf.org Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 20:32:18 -0000 > On 15 May 2016, at 10:54 PM, Yaron Sheffer = wrote: >=20 >>> On 15/05/16 10:22, Yoav Nir wrote: >>>> That=E2=80=99s interesting. With HPKP you can pin keys from = existing certificates, or keys that are not (yet) in certificates. >>>>=20 >>>> One of the early deployment scenarios (which got de-emphasized = later on) was that you include two pins: your current production key and = a spare key that you will certify if something bad happens to the = production key (like the private key leaking out). >>>>=20 >>>>=20 >>> Hi Yoav, >>>=20 >>> I had assumed this *is* the main deployment scenario. If it was = de-emphasized, what do you consider as the "classic" HPKP usage = scenario? >>=20 >> Current certificate plus some CA certificate that you are likely to = use to certify your next certificate. >>=20 >> Yoav >>=20 >=20 > But this too means that you're guessing how the CA will behave in the = future. If your current cert is expiring in a month and you generate the = new one, you can be surprised by the CA using a new intermediate cert. >=20 > And of course, some people would never pin to a CA cert. To me, the = whole idea of certificate pinning is to reduce the need to trust the PKI = industry, and that includes my own friendly CA. I agree. Appendix B of RFC 7469 recommends to have the backup pin signed = by a different CA and ready to use. That solves the issue of not knowing = how a CA might encode the SPKI. It used to be a costly solution, but = these days a certificate is pretty much free, so you really can have a = backup certificate ready to use. Yoav From nobody Sun May 15 13:54:04 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B212D517 for ; Sun, 15 May 2016 13:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wndbF-Qh4SEE for ; Sun, 15 May 2016 13:54:02 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063D712B046 for ; Sun, 15 May 2016 13:54:02 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id 190so189506810iow.1 for ; Sun, 15 May 2016 13:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4UaOk5l9yAOdZoG5bcE2NHHpODG1x6Ls7Ldh09ZRFVY=; b=bXOaAu00/kDhV96jBZqBMSQ+X1gelaqj1uGlLs3tfG4zwMUg02kt7wextpo6cNjCgM yl4rcA98QvQCvX0yJTvK4FyCFvND1LdXCno/k2E+jxdlikDuhTAEWY1jgFm0hFFU7kQX H+hOUaT2WcWql6tG0vtsiGRI4CBN3ridj3X9V2S805TGcSRvsLpzFSoMOiU3Q4TtCbMx QhQoB6jPz/tis/fZDTNFhOajTotq/dGGji9mUHGcArg0+GHFt8UlC47d5HHSf9ZnWKyv ZG8lEvWM4LtU9oXpFoUs1V+o6m99g6Itxz4YQujsYHh7BiBZY0FoA23RcW1pIo+zPh6L dH6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4UaOk5l9yAOdZoG5bcE2NHHpODG1x6Ls7Ldh09ZRFVY=; b=TZzto/1lESt4hEDzbL1htKIpoa7cirh5Imjv2fQTs1e0qU5XU9wGZDntbYXktuK28j VfwJ+fLqihMLrywjGz49DmgIXlvY6/VZXt0oQS+XNgH3HapJ09ZQV3rkFajUT9FXu+Sj Mof3t0waBdxDsg7B7s7wpJ5iobemAiOMtzjRlbcxz9/rFLIqOXcKZIF2O1adQ4D9bCP/ pBBS+if9owFlSo9SeM/PuoL0paydKKddsrpg0eoWfPXG+BK82IE90TRBVf7Ni1Jzcea0 qF1xbC5+nIHrh3MK/U43v8eqjSL13Y/2KDd9tUwgKJUxRFZ6cuPLcmLxcMy5eN04UZY0 vbsw== X-Gm-Message-State: AOPr4FWzyXrZddSEpSLOtzLyhh2td4kWYK2fmZUGnzvb3Fs4/K2XnF1rA0/xdQEvfdxVlUfQ29ISTKcySbTdkw== MIME-Version: 1.0 X-Received: by 10.107.10.208 with SMTP id 77mr18289091iok.51.1463345639857; Sun, 15 May 2016 13:53:59 -0700 (PDT) Received: by 10.36.253.67 with HTTP; Sun, 15 May 2016 13:53:59 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 May 2016 10:53:59 -1000 Message-ID: From: Brian Smith To: Jesse Wilson Content-Type: multipart/alternative; boundary=001a113f8d160c443e0532e7b517 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 20:54:04 -0000 --001a113f8d160c443e0532e7b517 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jesse Wilson wrote: > Older versions of Android (which use BouncyCastle) embed the curve: > > SEQUENCE { > SEQUENCE { > # ecPublicKey > OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } > SEQUENCE { > INTEGER { 1 } > SEQUENCE { > # prime-field > OBJECT_IDENTIFIER { 1.2.840.10045.1.1 } > INTEGER { `01ffffffffffffff...` } > } > SEQUENCE { > OCTET_STRING { `01ffffffffffffff...` } > OCTET_STRING { `0051953eb9618e1c...` } > } > OCTET_STRING { `0400c6858e06b704...` } > INTEGER { `01ffffffffffffff...` } > INTEGER { 1 } > } > } > BIT_STRING { `0004019519de800d...` } > } > > This is invalid. See https://tools.ietf.org/html/rfc5480#section-2.1.1: "= implicitCurve and specifiedCurve MUST NOT be used in PKIX." > But new versions of Android (which use Conscrypt/OpenSSL) reference the > curve by name: > > SEQUENCE { > SEQUENCE { > # ecPublicKey > OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } > # secp521r1 > OBJECT_IDENTIFIER { 1.3.132.0.35 } > } > BIT_STRING { `0004019519de800d...` } > } > > The original certificate embeds the curve. > This is the only correct encoding. > The original and roundtripped SPKI bytes are not identical. > Does anyone else do ASN.1 encoding in order to compute a certificate=E2=80= =99s pin? > 1. I recommend that you don't decode and then re-encode. Instead, I recommend that you only verify that the curve is specified using the valid encoding, and then compute the result using the single valid encoding directly, without using any encoder. > Or is it a uniquely Java problem?! > IIRC, older versions of OpenSSL have this problem too. > The spec should warn that a single SPKI may have multiple conflicting > encodings. > No. There's only one valid way to encode each SPKI. This makes sense if you think about the primary goal of the DER encoding of ASN.1: It's supposed to allow round-trip decode-encode where the output is the same as the input. > I suggest that only encoding in the certificate should be pinned. TLS > server administrators should also be careful to not inadvertently re-enco= de > their SPKIs when doing maintenance. > Instead, certificates with invalid encodings should be rejected by verifiers and nobody should produce certificates with invalid encodings. Cheers, Brian --=20 https://briansmith.org/ --001a113f8d160c443e0532e7b517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jess= e Wilson <jesse@swank.ca> wrote:

Older versions of Andr= oid (which use BouncyCastle) embed the curve:

SEQUENCE {
  SEQUENCE {
    # ecPublicKey
    OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
    SEQUENCE {
      INTEGER { 1 }
      SEQUENCE {
        # prime-field
        OBJECT_IDENTIFIER { 1.2.840.10045.1.1 }
        INTEGER { `01ffffffffffffff...` }
      }
      SEQUENCE {
        OCTET_STRING { `01ffffffffffffff...` }
        OCTET_STRING { `0051953eb9618e1c...` }
      }
      OCTET_STRING { `0400c6858e06b704...` }
      INTEGER { `01ffffffffffffff...` }
      INTEGER { 1 }
    }
  }
  BIT_STRING { `0004019519de800d...` }
}

Or= is it a uniquely Java problem?!

The spec should warn that a sin= gle SPKI may have multiple conflicting encodings.

No. There's only one valid way to encode each SPKI. This makes sense = if you think about the primary goal of the DER encoding of ASN.1: It's = supposed to allow round-trip decode-encode where the output is the same as = the input.

--
--001a113f8d160c443e0532e7b517-- From nobody Sun May 15 14:19:38 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1009212D520 for ; Sun, 15 May 2016 14:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7bYc_yTq2ab for ; Sun, 15 May 2016 14:19:35 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF70912D537 for ; Sun, 15 May 2016 14:19:35 -0700 (PDT) Received: by mail-io0-f178.google.com with SMTP id d62so189841926iof.2 for ; Sun, 15 May 2016 14:19:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/WEKoD2DjPeOqTmna4Z96bJncGq068E6Z8D2TDnfI7s=; b=k6egBeza9AUAKCHO8WafMrMJm0MBiWhIIgcRvfPmnjsCV7FAztjukbfWSO26z7DVR8 4VXjSgPA9u1h14K5/fopsc61dVtpvq8zMWcIGRoCWLrW8Jo23deGK95zp09mBzfMyTZw pexsGp/mPAvJM2n5SwWgdJ8b7WwTL8OcwrsE0L9tvOMbL0Geu5w5xKyuby9E+6wGbNTP sYSK5g+ypWCeEVfJdL1xLB6R76aooVV7hgzHUOiXXhp3ek2HjM1ROCksMXsFip4m9Nqm 3CQJVTgEadOcKSsXqAf4vs1fi8tlACYqApAbt9eGq+xKnt22cj6U7YRXWnO55tWklD0F 4fjw== X-Gm-Message-State: AOPr4FXkvpCDiqNu6VCbMF6oCPXgI6DYknBwM5XmfWjUl5qYia7bfomJWEE9JsqSNpyFA1tlNHhFSXNffD4Stg== X-Received: by 10.107.37.16 with SMTP id l16mr16410135iol.138.1463347174945; Sun, 15 May 2016 14:19:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jesse Wilson Date: Sun, 15 May 2016 21:19:24 +0000 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a114088b08bbe3a0532e8105d Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 21:19:38 -0000 --001a114088b08bbe3a0532e8105d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Brian! I=E2=80=99m happy to hear that this is an implementation bug = (that I can petition to get fixed), rather than spec bug (that we all have to workaround). --001a114088b08bbe3a0532e8105d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Brian! I=E2=80=99m happy to hear that this is an im= plementation bug (that I can petition to get fixed), rather than spec bug (= that we all have to workaround).

--001a114088b08bbe3a0532e8105d-- From nobody Sun May 15 15:23:51 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEF412D0DF for ; Sun, 15 May 2016 15:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuioUSe1Aywz for ; Sun, 15 May 2016 15:23:46 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C850412B054 for ; Sun, 15 May 2016 15:23:46 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id m9so31726042ige.1 for ; Sun, 15 May 2016 15:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-transfer-encoding; bh=GhtV2nlrxr8pTyy5ZksDzm1VEMoyeQPvc8ngmgqZLOo=; b=ztgEJh9glbvBcRteyU5aega1+f33LwOEOI/pHhJDlDHRV+859ZOwWsjrjUwuVhM+D7 8lB+v3xEXk7cFO3+GU23PTf6q88xBu9JLT9y+6paHpVIlLKydkAJSAkCXofEEnyTPnUJ 21xRrIsIQza9qejxkfhTTUDtycaXaOXSQZ1U6RRcvth8qFVn84x8mDsOTLh2PZcQ7YMk 5LCxCgUZCKqjRiLOgzo3IXCUKbiSVcjhCZNVg/dJTWLEsQCU3TBUhJv08e25X1DPxv7e D5pOzgwJIMTSwo+JdNdFH0Xgr7mWJ7xi1rC3hanvNxeiob6dvY4ckMWGaIZE/AvMZosi ytHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-transfer-encoding; bh=GhtV2nlrxr8pTyy5ZksDzm1VEMoyeQPvc8ngmgqZLOo=; b=k1sp2XgMnrbHR+sq9o7Ev7rBVHoAMxw28pDaCTwwKAXLNupTg5Why3bTYPOnCs1hLR WyQ90ba0Zx3uEONmfAaYZYI1wxtyQqPjI00wVwVK89ELPlm+BJmXEJRo9OThKuyTIKHb KwH7FstLp2hKda6SLuKytBmCVSnyS/YiC0xXEYYoGQk19wC2i9ZzsQqBB+wUjnrsXKJN 21u9jKs11+xBAYvLLNb0Vb+KPIumqMcYuQBIqMO/VZMZDLseZ5shynVQXNsZkphVQCUM E771RN3nvz/NDrtety9tZBWufEKM9S/eY2jezo/JAc8KFdTCGZFBx1wg62+7WsDrl0Dn gVYg== X-Gm-Message-State: AOPr4FVliKQWnGjTvoisHIS1assJuZzOCfdNSjmjQcBNCzZDvqYkOF0AgFUQ+iQvz6onGAo6+3QKkHs7D9BwyQ== MIME-Version: 1.0 X-Received: by 10.50.20.10 with SMTP id j10mr6673754ige.30.1463351026195; Sun, 15 May 2016 15:23:46 -0700 (PDT) Received: by 10.64.126.67 with HTTP; Sun, 15 May 2016 15:23:46 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 May 2016 18:23:46 -0400 Message-ID: From: Jeffrey Walton To: Jesse Wilson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 22:23:48 -0000 On Sun, May 15, 2016 at 5:19 PM, Jesse Wilson wrote: > Thanks Brian! I=E2=80=99m happy to hear that this is an implementation bu= g (that I > can petition to get fixed), rather than spec bug (that we all have to > workaround). It depends on the issuing policies. The IETF has no way to specify that a certificate was created or issued under PKIX, so its a moot point. (It creates a vaccum like the EV mess, except for standard certificates rather than EV certificates). Jeff From nobody Sun May 15 15:34:08 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F76312D106 for ; Sun, 15 May 2016 15:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj8JotR4qk-u for ; Sun, 15 May 2016 15:34:05 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2596812B039 for ; Sun, 15 May 2016 15:34:04 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id f89so190489369ioi.0 for ; Sun, 15 May 2016 15:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+D2mKasIKUlRNSKucjt24WytKyxOVXW+fJDxdFZWiLs=; b=Z8UdskuEyaHp21hbiwUYBG81F/AM9gAStfM/g0ch7D3X3sna19vS0ap3TyRqDuIsu5 eaoiBArKqOp9lXMXOJ8kE1A9bamKvzLk0ur97A8OJY+je3Sr4lhh6hj+ux0e1JtjuD5a 4hjKrfiOt/EJiDZI/sojOhSNCwySOyn1GXjZfeVzlxwsrQqCiI6vE3j6+boy3W7si5C6 tK7VrszRsDSk9B+Fpras3r7RIY4+BUqNg4zc8dFg1TkCJ21BAI2SixcDRvbxKMIUPGJi 5HuXjlWbygRTc30Hw1HcrgB0UWVyv6ee0Bbx3zYSPNvc/tWlJQcQPjBncMdOXLaxhlJT 3xFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+D2mKasIKUlRNSKucjt24WytKyxOVXW+fJDxdFZWiLs=; b=mQSQXKxhEQG/IdyF6K7q9sEc6ORX4Vah4DHcosBZ4vaPqyZckr3VmO7rGBwxC6ZVqs V52eCH9cp8wPHsf2kHYTZlHlnKO7bTDDz3U3jKJLBXHzS8MCxARPoI0rAiLNi/5H0eyX 7HeWI6w52llYZG+fjMVCDpSy3PmTeYs3SacDCx+bX3EiWB0XQ3Tr+jaLtIdFqMcGT/D4 HCG0cQ+wptudq09m60iNnirZn0v5uRhw/nnWTqT90rQ9TJ8PVbNh+QzzFP26yWmu2lHm 05ddtSI+Efbl/OsvNUE7R7v6S72HlOm8kX5g3KCYm3XPGoiJ1HnSaMZyt6B2+5JjyFum XqPQ== X-Gm-Message-State: AOPr4FVfgdg8UzDNDMVEiI6+uk4rz5OC5vyZl3GXNqSA4tDiCb/HwDzT/5D5MZM5d+FHV2vOm4lyJe8pQ8zwWA== MIME-Version: 1.0 X-Received: by 10.36.216.196 with SMTP id b187mr7677681itg.36.1463351644123; Sun, 15 May 2016 15:34:04 -0700 (PDT) Received: by 10.36.253.67 with HTTP; Sun, 15 May 2016 15:34:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 May 2016 12:34:04 -1000 Message-ID: From: Brian Smith To: noloader@gmail.com Content-Type: multipart/alternative; boundary=94eb2c05e99aee0d7a0532e91a02 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 22:34:07 -0000 --94eb2c05e99aee0d7a0532e91a02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jeffrey Walton wrote: > On Sun, May 15, 2016 at 5:19 PM, Jesse Wilson wrote: > > Thanks Brian! I=E2=80=99m happy to hear that this is an implementation = bug (that > I > > can petition to get fixed), rather than spec bug (that we all have to > > workaround). > > It depends on the issuing policies. > > The IETF has no way to specify that a certificate was created or > issued under PKIX, so its a moot point. (It creates a vaccum like the > EV mess, except for standard certificates rather than EV > certificates). > HPKP is specified in terms of RFC 5280, so we can assume only PKIX certificates are used for HPKP. In particular, HPKP (RFC7469) defers to RFC5280 for the specification of SPKI. RFC 5280 then defers to other specs for defining SPKI: "Conforming implementations that use the algorithms identified in [RFC3279 ], [RFC4055 ], and [RFC4491 ] MUST identify and encode the public key materials and digital signatures as described in those specifications." RFC 5480 updates RFC 3279. So, yes, a CA can issue a certificate that's not RFC 5480 but nobody should expect HPKP to work with such certificates. Cheers, Brian --=20 https://briansmith.org/ --94eb2c05e99aee0d7a0532e91a02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff= rey Walton <noloader@gmail.com> wrote:
=
On Sun, May 15, 2016 at 5:19 PM, Jesse Wi= lson <jesse@swank.ca> wrote: > Thanks Brian! I=E2=80=99m happy to hear that this is an implementation= bug (that I
> can petition to get fixed), rather than spec bug (that we all have to<= br> > workaround).

It depends on the issuing policies.

The IETF has no way to specify that a certificate was created or
issued under PKIX, so its a moot point. (It creates a vaccum like the
EV mess, except for standard certificates rather than EV
certificates).

HPKP is specified in ter= ms of RFC 5280, so we can assume only PKIX certificates are used for HPKP. = In particular, HPKP (RFC7469) defers to RFC5280 for the specification of SP= KI. RFC 5280 then defers to other specs for defining SPKI: "Conforming=C2=A0 implementations that use the a= lgorithms identified in [RFC3279],=C2=A0[RFC4055], and [<= /span>RFC4491] MUST identify and encode the public key=C2=A0materials and digit= al signatures as described in those=C2=A0specifications." RFC 5480 updates RFC 3279.<= /span>

So, yes, a CA can issue a certificate= that's not RFC 5480 but nobody should expect HPKP to work with such ce= rtificates.

Cheers,
Brian
--
--94eb2c05e99aee0d7a0532e91a02-- From nobody Sun May 15 16:04:15 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4364512D517 for ; Sun, 15 May 2016 16:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4078Qrib2sKR for ; Sun, 15 May 2016 16:04:12 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB3212D15D for ; Sun, 15 May 2016 16:04:12 -0700 (PDT) Received: by mail-ig0-x22d.google.com with SMTP id qe5so40517751igc.1 for ; Sun, 15 May 2016 16:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=EmQoob6YZHaxRbuTMYw+W/zfEIOdh5CxUYb8LVeVBJI=; b=foxAjPyokErFcXPQQb3gSKTz/RXzyu4LmlgfqTzG9CNflXV5ORP4LZ/rv0DFzvsOCx /ncQDzUvlQYPeIoEdxufbuhEur+cRCpaULs9Z9IpO+SMSVG+g1HwBiSOHHUrZMDXd7Fe oybVqE+hwqAs6QlxTnwAxQdHwSzdtxMwDxnWjNu6KHGMBlAn9e0NBdfWt+66m9mkkR7F /jy9VnpSqhhUZVk0DjOFn8Ic6+TpdSQ5AiSK5EaWT9RzJMAu+Q1zaIuW/ZBrqHXaJUss oHp7Esc1Y+nL+Ya2mHMCslW8Jihx9TZrmnG1kE/EcpoRmZq93TRG0EjZJwh0luISin3O BAvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=EmQoob6YZHaxRbuTMYw+W/zfEIOdh5CxUYb8LVeVBJI=; b=kOh/kpg+l12QLG6qeGSLVqfGwtjIRWV03R4nW61FQosfCQDJ6k3zb1CC1TBWZ9z2vH oCHkxKwUIvO92KC8LbHsSpYLFWNLz7M2z+laOQ8QXN+Q5DH5LVvBWs8x9InqhcHbQ50T YyR7m3wIMQiJa9p0PsshtyHxLqx5PQ8yn18xxDJKcMBl90f2vfdDlFgSwPNg4umfuCvY tkm8HF1Svzxv3DjzwyZKO8+wXEVjUbNFp23MjUNQ6xMtO50xm8UgebW7LKm5m9/qBKHf uQXD7h98pgEKpuB2AnpZxzPSMVQw2Ge3SF9iyGLakdVqaFo+fcNW5Rf9NYwhhbWiGnMP kG7Q== X-Gm-Message-State: AOPr4FXfk18BYNMLENKxY18Ay7TG1BbYmypUnKP82fy+fC0ZWtIH2Nwt47ejlZ74Yyvvo3Al+uKPfd01LVyB7Q== MIME-Version: 1.0 X-Received: by 10.50.69.66 with SMTP id c2mr8179911igu.30.1463353451864; Sun, 15 May 2016 16:04:11 -0700 (PDT) Received: by 10.64.126.67 with HTTP; Sun, 15 May 2016 16:04:11 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 May 2016 19:04:11 -0400 Message-ID: From: Jeffrey Walton To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF WebSec WG Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 23:04:14 -0000 >> > can petition to get fixed), rather than spec bug (that we all have to >> > workaround). >> >> It depends on the issuing policies. >> >> The IETF has no way to specify that a certificate was created or >> issued under PKIX, so its a moot point. (It creates a vaccum like the >> EV mess, except for standard certificates rather than EV >> certificates). > > > HPKP is specified in terms of RFC 5280, so we can assume only PKIX > certificates are used for HPKP.... In that case, the IETF provides a document on path building and validation (RFC 4158), but not certificate validation (modulo RFC 6125). As far as I can tell, its still the wild, wild west with no guidance on end-entity certificate validation. Jeff From nobody Sun May 15 16:23:22 2016 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3FD12D54F for ; Sun, 15 May 2016 16:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=domblogger.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpw9VzB2mAVz for ; Sun, 15 May 2016 16:23:20 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [IPv6:2600:3c00::f03c:91ff:fe56:d6a2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE46012D54D for ; Sun, 15 May 2016 16:23:19 -0700 (PDT) Received: from [192.168.0.103] (71-9-134-226.dhcp.mdfd.or.charter.com [71.9.134.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id 75E3547D for ; Sun, 15 May 2016 23:23:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1463354598; bh=jKOM1YdqSeB6mAWeA3PIMwGsUHRl5hwwVEmrVIfuKuw=; h=Subject:To:References:From:Date:In-Reply-To; b=mv4a3bobBt66r4Jvd+X4s0RaLKD7ADSUJsbuyZk6irQdVjWsJCGDEd/lPgkF1DMNh ybBadFxYEVmXpY3QGM/Z8UxmBcJ5J/AcO/Z5Iee0e5R6kPWgbl6y8E0/tb0L8L07fF oJLz9anIkXMQ9k4dqBzTe6hipIlc4R+QV7HAmSDs= To: websec@ietf.org References: From: Alice Wonder Message-ID: <573904E5.1000500@domblogger.net> Date: Sun, 15 May 2016 16:23:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [websec] HPKP & different encodings of the same public key X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 23:23:21 -0000 On 05/15/2016 04:04 PM, Jeffrey Walton wrote: >>>> can petition to get fixed), rather than spec bug (that we all have to >>>> workaround). >>> >>> It depends on the issuing policies. >>> >>> The IETF has no way to specify that a certificate was created or >>> issued under PKIX, so its a moot point. (It creates a vaccum like the >>> EV mess, except for standard certificates rather than EV >>> certificates). >> >> >> HPKP is specified in terms of RFC 5280, so we can assume only PKIX >> certificates are used for HPKP.... > > In that case, the IETF provides a document on path building and > validation (RFC 4158), but not certificate validation (modulo RFC > 6125). As far as I can tell, its still the wild, wild west with no > guidance on end-entity certificate validation. > > Jeff DANE is better anyway. HPKP is trust on first use, and even worse, trust on first use without user interaction. DANE is validate on every use HPKP only works with https DANE works with anything tcp or udp HPKP can be used for a DOS attack. Simple DNS cache poison and send the header with a bogus set of keypins and long TTL DANE validates via DNSSEC avoiding that issue. I do not understand browser resistance to DANE validation.