From nobody Wed Apr 8 12:19:21 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31AA1B351D for ; Wed, 8 Apr 2015 12:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 m2OKOQqk1xoP for ; Wed, 8 Apr 2015 12:19:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F9E1B3529 for ; Wed, 8 Apr 2015 12:19:18 -0700 (PDT) Received: from unnumerable-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t38JJHNY062507 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Apr 2015 14:19:18 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable-2.local Message-ID: <55257F30.9050608@nostrum.com> Date: Wed, 08 Apr 2015 14:19:12 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: stir@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Draft minutes for STIR at IETF92 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:19:19 -0000 Draft minutes are available at http://www.ietf.org/proceedings/92/minutes/minutes-92-stir Please send any additions/corrections to the list or the chairs before May 11. Thanks go to Eric Burger for the excellent notes! RjS From nobody Wed Apr 15 03:23:13 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE4B1A1A5A for ; Wed, 15 Apr 2015 03:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 gL6ekl4hdp9l for ; Wed, 15 Apr 2015 03:23:09 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8701B1A1A52 for ; Wed, 15 Apr 2015 03:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=yP61DteuZuiKeBTs1XkfT5aSMHpSS+tZ11m+ZGR1x98=; b=VlG0b2AQLENbsRJH/YKu3CTYXfMr0JN/pvKTS5Iy73r9ptCrUuShoU67SKAzHRTV34U3MQ4vniLhH7Sv8emVbR+LA0gJzMaCvgQECReybZsckzBtPhA/KiAyOiG4uWTHXt+s6HxLenUR9w+zv3tWP/l14sYJYvo7hmVtiqfmkNo=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:62941 helo=[192.168.15.128]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YiKTL-0003Vw-8E for stir@ietf.org; Wed, 15 Apr 2015 03:23:09 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_0D7109B5-7FC6-4493-9A21-F1DA85F323E2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: <55257F30.9050608@nostrum.com> Date: Wed, 15 Apr 2015 06:23:05 -0400 Message-Id: References: <55257F30.9050608@nostrum.com> To: stir@ietf.org X-Mailer: Apple Mail (2.2070.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] Is Perfection the Enemy of the Good (was Draft minutes for STIR at IETF92) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 10:23:11 -0000 --Apple-Mail=_0D7109B5-7FC6-4493-9A21-F1DA85F323E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The minutes state: > Authorization check options: > Do we need to check if a particular number is in the scope of validity = for a cert, or do we need to list the numbers asserted in the = certificate? After lots of discussion, just want to know if the = certificate covers the number. > Eric offers that it is not practically useful to worry about = revocation. Not knowing whether a particular signer is authorized to = sign for a number RIGHT NOW will make no difference in user behavior. > Jon thinks Eric is saying it does not matter what number is in the = certificate. Violent discussion ensues, as Jon is arguing the whole = point of STIR is to have the number in the certificate and Eric is = arguing it does not matter if the attestation has not been revoked. = Realization hits as room falls asleep. I thought it would be good to expand on what I was trying to convey at = the meeting. The whole point of STIR is to authenticate the number being = presented to the called party. As such, the whole point of the = certificate is to attest the number being presented is the number of the = caller. The debate was about what level of perfection do we need in the real = world to make STIR useful. What I was trying to lay out is the argument = that real-time verification of certificate validity is not necessary to = achieve the goals of STIR. To recap: we need a mechanism whereby a service provider vouches for the = identity of a caller. In the U.S. market, it looks like we are = converging on using the X.509 model of a single, national root CA. The = root CA delegates signing to various registered and regulated service = providers. Those service providers issue certificates to end user = devices, asserting the identity of the end user, specifically (in the = case of STIR), the end user=E2=80=99s =E2=80=9Cphone number=E2=80=9D or, = colloquially, their Caller ID string. Redundantly, we use the X.509 = certificate=E2=80=99s private key to sign the asserted Caller ID in the = SIP signaling. Here is an observation: with sufficiently short certificate lifetimes, = having an on-line validation check of the certificate does not = materially impact the integrity of STIR with respect to its promise of = authenticating the caller. Let us say the service provider issues = certificates with two week lifetimes. This is a reasonable assumption as = the presumption for the whole STIR mechanism is certificate management = is remotely managed by the service provider. The reason that is a = reasonable assumption is the IETF itself has shown it cannot reliably = manage to manually keep the IETF.ORG certificate up to date. If we = cannot do it manually, grandpa in Iowa is certainly not going to manage = his phone's certificate manually. Anyway, what are we protecting = against? We are protecting against the end user lying about their = identity. First off, they cannot put something in that is different than = what the service provider is attesting is their number. Why? Because the = certificate, generated by the service provider, cryptographically = asserts what the number is. Any mismatch between the number in the = certificate and the number asserted in the SIP signaling is an = authentication failure. But what about number porting, you might ask? Let us say an entity gets = service from provider T. With that service, the entity gets a phone = number N. Now let us say some time later, the entity ports their service = to provider V. On porting, provider V issues a new certificate for = number N. When the entity places a call now, they might try to be = nefarious and use T=E2=80=99s certificate. However, for the purposes of = STIR, the fact the entity uses the =E2=80=98wrong=E2=80=99 certificate = is irrelevant. The =E2=80=98wrong=E2=80=99 certificate still only allows = the entity to make an assertion on the number N, which does not change = in the porting process. By having a relatively short lifetime for the certificate we ensure that = someone does not grab a number, release it, and then masquerade later as = being the authoritative owner of the number. Two weeks is well short of = the usual number fallow period, so that alone eliminates this problem. = Someone might try to be nefarious and attempt some SWATing or = robocalling after they =E2=80=98disconnect=E2=80=99 service. In this = case, it will be obvious who is doing the calling, as one and only one = entity will have the certificate, given the certificate=E2=80=99s = limited lifetime. One objection privately raised after the exchange is what happens if an = entity in the signing chain becomes compromised. Let us take the easy = one first. That is the case where the Grace L. Ferguson Telephone And = Storm Door Company=E2=80=99s [1] loses their certificate and someone = nefarious starts issuing certificates in their name. This is also known = as the DigiNotar case [2]. There is an easy / modest solution to this = problem and a hard / hard solution. The easy / hard solution is to limit = the lifetime of the intermediate certificate. That is easy, because = client devices need do nothing. When they validate the certificate = issued by the compromised intermediate CA, they will notice the CA=E2=80=99= s certificate, issued by the root CA, has expired. It is modest for the = service provider because it means they need to be sure to use their = latest certificate when they generate their customer=E2=80=99s keys. = That is not at all onerous, but it is not free. The hard / hard solution = is an online check like OCSP. It is hard for the user and end user = devices, because it means on-line in-line checking of inbound signaling. = It is hard for the service providers because they have to keep the OCSP = lists up to date. Now for the hard one: what happens if a national root CA is compromised? = The best I can say is all bets are off. Short of the kind of update that = followed DigiNotar, I am not sure how, using an X.509-based system, one = can deal with securely updating devices. With the root gone, the device = literally cannot trust anyone. This is a clue that end devices will need = multiple roots installed, so that if one root is compromised, another = authentication chain can be used to update the end device=E2=80=99s root = store. In short, OSCP or other on-line checks of end device certificate = validity adds complexity and cost, which will inhibit deployment, = allowing the SWATers and robo callers to continue their evil ways. [1] http://en.wikipedia.org/wiki/Bob_Newhart#Personal_comedic_style [2] http://en.wikipedia.org/wiki/DigiNotar --Apple-Mail=_0D7109B5-7FC6-4493-9A21-F1DA85F323E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVLjwJAAoJEDY/T2tCIPW30H0P/jLrUcBjqaZhIqTweN6ykorZ UQX79vSgZMJLWqAReuvQiEIqwCjF8d47W+mKABDyg6q9B0OhEPUcIdAW0b2090iI Qo8yQdKQuTLXrEMwHpm5QMue06OhiAntDOrWMOugI16zzu7SFWfrNXmcd3XcP1cO F4Lb/TI91T8VYSHrp7yIaxTJvY0PP0UCKrB3+C+I6D48+tNiGRdFuqLD3SzpKGsM OC5+okFkjoktNDbFCDaBIdp4ZzHvauhGOmjU/vV5/GmouYbJBhZX2yaQK18rfbDJ /yN0KINi/5xsxKLGezpXzLMYiD92lYfzkzUKwqCSS3hgfqUpsMpiU35s7vrNSfeZ vXlXvXU5Ee+UGxe8J2zPn2Y3+GDSK0Asg8V0b2KMMRigtaA37/1fP3UJosIl+Urq Iec+49y9jNMnefJfLYzeWnpXHSdllhx02RO4jqjNxNJRZNQ3Z7sWD3H0/bjHFyyS eAJ6rnPj06QC9rRATBCcoaE5qFpjjV7ta0Bqmj3ZyvkbbP/pJ3aBWyXvy1Su0He1 XbOcXUYcEXV6G3Ot5YVNk82omFCBfD2grTreZDm0nPIPKO2Ltz22Q4YW4NgL62H2 sIF+Swcvd08XmJxkaJ837QNc619kjuEFNT0zJI0pYUqKJamvzSnPwD/nOEh0mNyH GPfVR2DFXI/OzEz+HpHa =IQ8Q -----END PGP SIGNATURE----- --Apple-Mail=_0D7109B5-7FC6-4493-9A21-F1DA85F323E2-- From nobody Wed Apr 15 06:46:16 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5DB1A914F for ; Wed, 15 Apr 2015 06:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 E0Aq4Tqg5S7Y for ; Wed, 15 Apr 2015 06:46:11 -0700 (PDT) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (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 B8AED1A90B5 for ; Wed, 15 Apr 2015 06:46:10 -0700 (PDT) Received: by qkhg7 with SMTP id g7so84081618qkh.2 for ; Wed, 15 Apr 2015 06:46:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7kNAd9h0W8DIvgh5Hs+f1zO8BOD97zeY+DKRFMoxGqs=; b=IuEdIkAy6ns6PA+pzGtY7W3FlnC/t0tfW9Cis+UdsGBnpKRgK2Rp5tLibUGZITuSWz l7az3XXy+sG46EWEV01TY/SY+2H35ePHVfIQSwIam/fZ5FYfEb/RI4w7dKU8NTvrKpPS 1CF/7CF/7svPCIFaJYvF+Zn9uKMyRXzitK15X997IMx+gD1T3nq6rjt6KuQi29GAKJwU wJsxXzj0/zA0NLpRy6X6WrIjnL5Dxjz9VlbwQd89E1R9PmwBG+UJepjxJabcqUs+nUxQ LPbNWEBSO5OxdlZV4a+Xa5oUIKnCSgAQpVuo1AkVtVi1+fCQ8InAp2cUkyOLjMkPObqq TVLw== X-Gm-Message-State: ALoCoQmknD5Rp7gggy+uGplpaZRa3xuTXXSRb8wi8T45GLNSZuB3NMlON3mQf1FfaCLPlkbP8/K1 X-Received: by 10.55.24.11 with SMTP id j11mr51379547qkh.73.1429105541554; Wed, 15 Apr 2015 06:45:41 -0700 (PDT) Received: from kmckeown-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id m25sm3168200qkh.26.2015.04.15.06.45.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Apr 2015 06:45:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Brian Rosen In-Reply-To: Date: Wed, 15 Apr 2015 09:45:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2A6869BB-1F24-4620-AEDD-7771321E6691@brianrosen.net> References: <55257F30.9050608@nostrum.com> To: Eric Burger X-Mailer: Apple Mail (2.2098) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] Is Perfection the Enemy of the Good (was Draft minutes for STIR at IETF92) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 13:46:14 -0000 I think you are making assumptions that many of us are not making. One of them is certificate per number. ISTM you are assuming each = number gets their own credential. Many of us are not assuming that. = Credentials holders should be able to manage mapping of number to = credentials from one per number to one per holder. If you have multiple = numbers per certificate, potentially millions of numbers (if a big = carrier decided they wanted one credential for all their numbers) then = you need something that tells you that the certificate is good for that = number. That same query, whatever it is, can also attest to the = validity of the cert. Whether you actually use something like OCSP, or = you just try to follow some URI to get a list of numbers associated with = the cert, you can get the validity of the cert, for that number, = determined reliably. The other assumption you are making is that certificated carrier is by = definition =E2=80=9Cgood=E2=80=9D and other entities don=E2=80=99t = manage certificates. Many of us don=E2=80=99t subscribe to that notion, = and don=E2=80=99t plan to have any special status for certificated = carriers. Any delegation gets recorded in a database. There need not = be one database, but it=E2=80=99s not database per certificated carrier. = As you heard in the meeting, regulators (and not just in the US) are = rethinking to whom numbers are delegated, and the notion that = certificated carriers have some special status with respect to number = delegation is becoming obsolete. I do think that implementations need to plan for the possibility of = compromise of the root key. We need to be able to change the root key, = any sub-root keys and re-issue all certificates in a short time period. = If you can revoke a key, then you need something (CRL or OSCP-like) to = check that. I believe that two weeks of compromised keys is = unacceptable, so I believe we want an on-line real-time validity check. = I think in the scheme of things, that=E2=80=99s not a big increase in = complexity of deployment. I think all of this is one call to a database where you send the = credential and the TN and get back a yes/no. You can imagine ways to = optimize the entire mechanism of start with a signature and a URL to a = credential and end with a yes/no for the entire checking process (fetch = credential, validate it, check signature). =20 Brian > On Apr 15, 2015, at 6:23 AM, Eric Burger = wrote: >=20 > The minutes state: >> Authorization check options: >> Do we need to check if a particular number is in the scope of = validity for a cert, or do we need to list the numbers asserted in the = certificate? After lots of discussion, just want to know if the = certificate covers the number. >> Eric offers that it is not practically useful to worry about = revocation. Not knowing whether a particular signer is authorized to = sign for a number RIGHT NOW will make no difference in user behavior. >> Jon thinks Eric is saying it does not matter what number is in the = certificate. Violent discussion ensues, as Jon is arguing the whole = point of STIR is to have the number in the certificate and Eric is = arguing it does not matter if the attestation has not been revoked. = Realization hits as room falls asleep. >=20 > I thought it would be good to expand on what I was trying to convey at = the meeting. The whole point of STIR is to authenticate the number being = presented to the called party. As such, the whole point of the = certificate is to attest the number being presented is the number of the = caller. >=20 > The debate was about what level of perfection do we need in the real = world to make STIR useful. What I was trying to lay out is the argument = that real-time verification of certificate validity is not necessary to = achieve the goals of STIR. >=20 > To recap: we need a mechanism whereby a service provider vouches for = the identity of a caller. In the U.S. market, it looks like we are = converging on using the X.509 model of a single, national root CA. The = root CA delegates signing to various registered and regulated service = providers. Those service providers issue certificates to end user = devices, asserting the identity of the end user, specifically (in the = case of STIR), the end user=E2=80=99s =E2=80=9Cphone number=E2=80=9D or, = colloquially, their Caller ID string. Redundantly, we use the X.509 = certificate=E2=80=99s private key to sign the asserted Caller ID in the = SIP signaling. >=20 > Here is an observation: with sufficiently short certificate lifetimes, = having an on-line validation check of the certificate does not = materially impact the integrity of STIR with respect to its promise of = authenticating the caller. Let us say the service provider issues = certificates with two week lifetimes. This is a reasonable assumption as = the presumption for the whole STIR mechanism is certificate management = is remotely managed by the service provider. The reason that is a = reasonable assumption is the IETF itself has shown it cannot reliably = manage to manually keep the IETF.ORG certificate up to date. If we = cannot do it manually, grandpa in Iowa is certainly not going to manage = his phone's certificate manually. Anyway, what are we protecting = against? We are protecting against the end user lying about their = identity. First off, they cannot put something in that is different than = what the service provider is attesting is their number. Why? Because the = certificate, generated by the service provider, cryptographically = asserts what the number is. Any mismatch between the number in the = certificate and the number asserted in the SIP signaling is an = authentication failure. >=20 > But what about number porting, you might ask? Let us say an entity = gets service from provider T. With that service, the entity gets a phone = number N. Now let us say some time later, the entity ports their service = to provider V. On porting, provider V issues a new certificate for = number N. When the entity places a call now, they might try to be = nefarious and use T=E2=80=99s certificate. However, for the purposes of = STIR, the fact the entity uses the =E2=80=98wrong=E2=80=99 certificate = is irrelevant. The =E2=80=98wrong=E2=80=99 certificate still only allows = the entity to make an assertion on the number N, which does not change = in the porting process. >=20 > By having a relatively short lifetime for the certificate we ensure = that someone does not grab a number, release it, and then masquerade = later as being the authoritative owner of the number. Two weeks is well = short of the usual number fallow period, so that alone eliminates this = problem. Someone might try to be nefarious and attempt some SWATing or = robocalling after they =E2=80=98disconnect=E2=80=99 service. In this = case, it will be obvious who is doing the calling, as one and only one = entity will have the certificate, given the certificate=E2=80=99s = limited lifetime. >=20 > One objection privately raised after the exchange is what happens if = an entity in the signing chain becomes compromised. Let us take the easy = one first. That is the case where the Grace L. Ferguson Telephone And = Storm Door Company=E2=80=99s [1] loses their certificate and someone = nefarious starts issuing certificates in their name. This is also known = as the DigiNotar case [2]. There is an easy / modest solution to this = problem and a hard / hard solution. The easy / hard solution is to limit = the lifetime of the intermediate certificate. That is easy, because = client devices need do nothing. When they validate the certificate = issued by the compromised intermediate CA, they will notice the CA=E2=80=99= s certificate, issued by the root CA, has expired. It is modest for the = service provider because it means they need to be sure to use their = latest certificate when they generate their customer=E2=80=99s keys. = That is not at all onerous, but it is not free. The hard / hard solution = is an online check like OCSP. It is hard for the user and end user = devices, because it means on-line in-line checking of inbound signaling. = It is hard for the service providers because they have to keep the OCSP = lists up to date. >=20 > Now for the hard one: what happens if a national root CA is = compromised? The best I can say is all bets are off. Short of the kind = of update that followed DigiNotar, I am not sure how, using an = X.509-based system, one can deal with securely updating devices. With = the root gone, the device literally cannot trust anyone. This is a clue = that end devices will need multiple roots installed, so that if one root = is compromised, another authentication chain can be used to update the = end device=E2=80=99s root store. >=20 > In short, OSCP or other on-line checks of end device certificate = validity adds complexity and cost, which will inhibit deployment, = allowing the SWATers and robo callers to continue their evil ways. >=20 >=20 > [1] http://en.wikipedia.org/wiki/Bob_Newhart#Personal_comedic_style > [2] http://en.wikipedia.org/wiki/DigiNotar > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir