Subject: [stir] comment on draft-jennings-stir-rfc4474bis-00

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Oct 2013 10:56:11 -0400

Jon, Cullen and Eric:

In reading this doc I noted that it devotes a lot of text to describing 
support
for what seems to be AoR-style SIP IDs, rather than just the TEL SIP ID. 
I thought
that the WG had decided to put off discussion of the former, and focus 
only on the
latter ID type, initially. By trying to make this doc incorporate both 
types of IDs
it seems to dilute the focus, and make for a much more complex discussion.

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 30 Oct 2013 16:40:48 +0000

This is mostly legacy text from the original RFC4474, with some new
connecting text added as we try to break up the components of the
mechanism and make the pieces more modular. I'd say the state of this -00
points in the direction we want to go with that, but there's still more
surgery required, pending WG agreement on the direction.

I will further say though that I think it will be tough to describe a
system for providing identity for telephone numbers that is not at least
aware of non-TN URIs and capable of differentiating them - not always a
trivial thing, actually. Whether or not the logic gate that points us down
the TN/non-TN paths is strictly in STIR's scope, we will need it for this
to actually work. I moreover think that the behavior of verifiers in terms
of how they check fields, acquire credentials and so on will have
significant overlap in the two cases. I also suspect there's widespread
agreement about how to approach the non-TN case. So I'm hesitant to erect
barriers that will completely wall off the non-TN path from the
specifications here. But I won't deny that the -00 could do a better job
of organizing all this.

Jon Peterson
Neustar, Inc.

On 10/30/13 7:56 AM, "Stephen Kent" <[email-masked]> wrote:

>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Oct 2013 12:57:01 -0400

Jon,

My concern is that we seem to understand how one can manage 
authorization for
telephone numbers as IDs, in a fashion that does not go down the path of the
browser PKI, and all its problems. If the names for which we vouch are 
scoped by DNS,
and if we use DANE, I am comfortable with that too. But, if we have to 
make this
discussion very abstract, in order to accommodate caller ID models that 
do not derive
from authoritative ID sources, then I am very worried.

Frankly, as a security guy, I was getting lost in the discussion, but maybe
that's a presentation/exposition issue more than a technical issue.

Steve

---

From: Michael Hammer <[email-masked]>
Date: Wed, 30 Oct 2013 17:43:41 +0000

And who is the authority (to act as trust anchor) for those non-TN URIs?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Wednesday, October 30, 2013 12:41 PM
To: Stephen Kent; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

This is mostly legacy text from the original RFC4474, with some new
connecting text added as we try to break up the components of the mechanism
and make the pieces more modular. I'd say the state of this -00 points in
the direction we want to go with that, but there's still more surgery
required, pending WG agreement on the direction.

I will further say though that I think it will be tough to describe a system
for providing identity for telephone numbers that is not at least aware of
non-TN URIs and capable of differentiating them - not always a trivial
thing, actually. Whether or not the logic gate that points us down the
TN/non-TN paths is strictly in STIR's scope, we will need it for this to
actually work. I moreover think that the behavior of verifiers in terms of
how they check fields, acquire credentials and so on will have significant
overlap in the two cases. I also suspect there's widespread agreement about
how to approach the non-TN case. So I'm hesitant to erect barriers that will
completely wall off the non-TN path from the specifications here. But I
won't deny that the -00 could do a better job of organizing all this.

Jon Peterson
Neustar, Inc.

On 10/30/13 7:56 AM, "Stephen Kent" <[email-masked]> wrote:

>support for what seems to be AoR-style SIP IDs, rather than just the 
>TEL SIP ID.
>I thought
>only on the latter ID type, initially. By trying to make this doc 
>incorporate both types of IDs it seems to dilute the focus, and make 
>for a much more complex discussion.
>
>Steve

---

From: Brian Rosen <[email-masked]>
Date: Wed, 30 Oct 2013 14:17:38 -0400

That one is easy.  If you are placing a call from [email-masked], then example.com is the trust anchor. 

Since we’re using DNS to resolve example.com, then something DANE like would suffice to make sure that it really is example.com that is sending the call.

Brian

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 30 Oct 2013 18:24:03 +0000

Well, in RFC4474 it was browser PKI, effectively. Today we might want an
option for DANE. But that is indeed why modularity seems increasingly
important to me here.

I think we've got a couple different pieces of mechanism in our solution
space that we might want to click together in different ways. We know we
need signatures over some fields of a SIP request, and those fields don't
depend on whether the identifier is a TN or a SIP URI. This is a piece we
can nail down independently of where we get keying material from and who
constitutes a trust anchor. While it would be great if we could have a
single trust anchor that would serve all of SIP's identity needs, I think
the deployment environment is complex enough that we may be looking at
more than one. 

I don't think introducing points of modularity makes the discussion more
abstract, I think it makes it more tractable. This is one of the main
things I want to talk about in the YVR second session. We definitely don't
want to incur additional complexity as we make this modular, but we also
don't want to lock ourselves into vertical silo when we can't predict
exactly what the market will accept.

Jon Peterson
Neustar, Inc.

On 10/30/13 10:43 AM, "Michael Hammer" <[email-masked]>
wrote:

>mechanism
>system

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 14:26:45 -0400

I would put it more succinctly ... can we just fix one thing at a time.  We
should not preclude the use of alternative identifiers in the future but the
immediate problem is telephone numbers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Wednesday, October 30, 2013 12:57 PM
To: Peterson, Jon; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

Jon,

My concern is that we seem to understand how one can manage authorization
for telephone numbers as IDs, in a fashion that does not go down the path of
the browser PKI, and all its problems. If the names for which we vouch are
scoped by DNS, and if we use DANE, I am comfortable with that too. But, if
we have to make this discussion very abstract, in order to accommodate
caller ID models that do not derive from authoritative ID sources, then I am
very worried.

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 30 Oct 2013 18:47:44 +0000

No disagreement that telephone numbers are the immediate problem, but it
isn't trivially easy to decouple the work on non-TN identifiers, it isn't
clear how much new work on non-TN identifiers needs to be done beyond what
RFC4474 already did, and it certainly isn't just rfc4474bis in this WG
that proposes to address both: strikes-out does as well (see section 4.1
of that draft, say).

I think we'll find that any solution we build for this is going to be able
to address non-TN identifiers too, and I think it would be a tough sell to
argue that we should delete any such text, as necessarily any verifier is
going to have to look at a From header field value and ascertain whether
it contains a TN or not. Once you've gone that far down the path, if the
signature verification is the same, and the credential acquisition
potentially the same as well, it's just not going to save us any effort to
keep non-TN identifiers out of these drafts.

Jon Peterson
Neustar, Inc.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 12:55:32 -0400

+1 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Wednesday, October 30, 2013 10:56 AM
To: [email-masked]
Subject: [stir] comment on draft-jennings-stir-rfc4474bis-00

Jon, Cullen and Eric:

In reading this doc I noted that it devotes a lot of text to describing
support for what seems to be AoR-style SIP IDs, rather than just the TEL SIP
ID. 
I thought
that the WG had decided to put off discussion of the former, and focus only
on the latter ID type, initially. By trying to make this doc incorporate
both types of IDs it seems to dilute the focus, and make for a much more
complex discussion.

Steve

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 15:03:41 -0400

Well we will just have to agree to disagree here.  Personally I think
keeping text on non-TN identifiers AT THIS TIME is a distraction.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Wednesday, October 30, 2013 2:48 PM
To: Richard Shockey; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

No disagreement that telephone numbers are the immediate problem, but it
isn't trivially easy to decouple the work on non-TN identifiers, it isn't
clear how much new work on non-TN identifiers needs to be done beyond what
RFC4474 already did, and it certainly isn't just rfc4474bis in this WG that
proposes to address both: strikes-out does as well (see section 4.1 of that
draft, say).

I think we'll find that any solution we build for this is going to be able
to address non-TN identifiers too, and I think it would be a tough sell to
argue that we should delete any such text, as necessarily any verifier is
going to have to look at a From header field value and ascertain whether it
contains a TN or not. Once you've gone that far down the path, if the
signature verification is the same, and the credential acquisition
potentially the same as well, it's just not going to save us any effort to
keep non-TN identifiers out of these drafts.

Jon Peterson
Neustar, Inc.

On 10/30/13 11:26 AM, "Richard Shockey" <[email-masked]> wrote:

>should not preclude the use of alternative identifiers in the future 
>but the immediate problem is telephone numbers.
>
>authorization for telephone numbers as IDs, in a fashion that does not 
>go down the path of the browser PKI, and all its problems. If the names 
>for which we vouch are scoped by DNS, and if we use DANE, I am 
>comfortable with that too. But, if we have to make this discussion very 
>abstract, in order to accommodate caller ID models that do not derive 
>Frankly, as a security guy, I was getting lost in the discussion, but 
>maybe that's a presentation/exposition issue more than a technical 
>issue.
>
>Steve
>
>

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 13:26:29 -0400

-----Original Message-----

Jon,

Steve

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 31 Oct 2013 00:35:06 +0000

Major distraction and out of scope

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Standards and Industry Alliances
+1-609-903-3360
[email-masked]

> On Oct 30, 2013, at 8:31 PM, "Richard Shockey" <[email-masked]> wrote:
> 
>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 31 Oct 2013 13:11:20 +0000

Yeah, except when that domain name is chasebank-not-really.com (but not that
obvious).
There are so many variations on spelling, I generally don't *trust* any of
them.
What 3rd party that I can trust is verifying those DNS domains???

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 2:18 PM
To: Michael Hammer
Cc: Jon Peterson; [email-masked]; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

That one is easy.  If you are placing a call from [email-masked], then
example.com is the trust anchor. 

Since we're using DNS to resolve example.com, then something DANE like would
suffice to make sure that it really is example.com that is sending the call.

Brian

On Oct 30, 2013, at 1:43 PM, Michael Hammer <[email-masked]>
wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Peterson, Jon
> mechanism and make the pieces more modular. I'd say the state of this 
> -00 points in the direction we want to go with that, but there's still 
> more surgery required, pending WG agreement on the direction.
> 
> system for providing identity for telephone numbers that is not at 
> least aware of non-TN URIs and capable of differentiating them - not 
> always a trivial thing, actually. Whether or not the logic gate that 
> points us down the TN/non-TN paths is strictly in STIR's scope, we 
> will need it for this to actually work. I moreover think that the 
> behavior of verifiers in terms of how they check fields, acquire 
> credentials and so on will have significant overlap in the two cases. 
> I also suspect there's widespread agreement about how to approach the 
> non-TN case. So I'm hesitant to erect barriers that will completely 
> wall off the non-TN path from the specifications here. But I won't deny
that the -00 could do a better job of organizing all this.
>> In reading this doc I noted that it devotes a lot of text to 
>> describing support for what seems to be AoR-style SIP IDs, rather 
>> than just the TEL SIP ID.
>> I thought
>> that the WG had decided to put off discussion of the former, and 
>> focus only on the latter ID type, initially. By trying to make this 
>> doc incorporate both types of IDs it seems to dilute the focus, and 
>> make for a much more complex discussion.
>> 
>> Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Oct 2013 10:17:47 -0400

Brian,

I think DANE needs to be noted here explicitly. It is an example of what 
I noted, i.e.,
an authoritative source for DNS-based credentials. If we are silent on 
this point folks
may assume that the current, browser PKI (aka WebPKI) is suitable.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Oct 2013 10:55:18 -0400

Jon,

I must respectfully disagree on this point.

The WebPKI is not, from s secruity perspective, comparable to use of DANE
(for DNS-based names) or a telephone-number-based PKI based on 
national-level
authorities. If modularity is intended to blur the distinctions among 
all of these,
we are doing a disservice to readers, implementers, etc.

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 31 Oct 2013 15:52:00 +0000

You are of course entitled to your opinion, but I think you need to beyond
saying "there's new work that we'd have to do only in support non-TNs" and
identify what that work actually is.

Jon Peterson
Neustar, Inc.

On 10/30/13 12:03 PM, "Richard Shockey" <[email-masked]> wrote:

>that
>it

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 31 Oct 2013 16:06:22 +0000

I certainly don't suggest to blur that distinction between credentials
with different strengths. What I do suggest though is that there is room
here to make a clear break between:

1) the process by which we sign/verify with credentials
2) the process by which we acquire credentials and ascertain their
authority over an ID

That is true, and I would argue useful for us in a divide-and-conquer work
flow, whether or not there are multiple ways of doing (2). But I think the
fact that there are upcoming technologies that aren't yet prime time, like
DANE, indicates that there might need to be multiple ways to do (2). Even
if we assume a world that is all certificates, there may still be multiple
ways for a verifier to acquire them: a cert might be tacked on to a SIP
request itself, found in the verifier cache, downloaded using any of a
number of protocols. What I'm concerned about is assuming a vertical "one
true way" at this stage in our process.

Jon Peterson
Neustar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 31 Oct 2013 16:27:16 +0000

Jon,

Understand being flexible and covering all fronts.
But, if it gets watered down to a least common denominator 
that doesn't meet the requirements for TN, I think that would be a failure.

Mike

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Thursday, October 31, 2013 12:06 PM
To: Stephen Kent; Michael Hammer; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

I certainly don't suggest to blur that distinction between credentials with
different strengths. What I do suggest though is that there is room here to
make a clear break between:

1) the process by which we sign/verify with credentials
2) the process by which we acquire credentials and ascertain their authority
over an ID

That is true, and I would argue useful for us in a divide-and-conquer work
flow, whether or not there are multiple ways of doing (2). But I think the
fact that there are upcoming technologies that aren't yet prime time, like
DANE, indicates that there might need to be multiple ways to do (2). Even if
we assume a world that is all certificates, there may still be multiple ways
for a verifier to acquire them: a cert might be tacked on to a SIP request
itself, found in the verifier cache, downloaded using any of a number of
protocols. What I'm concerned about is assuming a vertical "one true way" at
this stage in our process.

Jon Peterson
Neustar, Inc.

On 10/31/13 7:55 AM, "Stephen Kent" <[email-masked]> wrote:

>The WebPKI is not, from s secruity perspective, comparable to use of 
>DANE (for DNS-based names) or a telephone-number-based PKI based on 
>national-level authorities. If modularity is intended to blur the 
>distinctions among all of these, we are doing a disservice to readers, 
>implementers, etc.
>
>Steve
>
>

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 15:17:46 -0400

Well we will just have to agree to disagree here.  Personally I think
keeping text on non-TN identifiers AT THIS TIME is a distraction.  RAI does
not have a good track record with overreaching requirements. 

 I would prefer such text along with deleted but it seems the chances of
having that opinion considered consensus is nil. 

-----Original Message-----

Jon Peterson
Neustar, Inc.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Oct 2013 13:51:27 -0400

Jon,

> 2) the process by which we acquire credentials and ascertain their
I agree that these are distinct.
> DANE, indicates that there might need to be multiple ways to do (2).
If this is a suggestion to rely on the WebPKI approach, I would disagree.
It would be too easy for folks to make use of that broken model and not
make the effort to move to a better approach, e.g., DANE. We ought not
be silent on this, methinks :-).
> Even
I agree that there ought to be explicit support for multiple ways for an
RP to acquire credentials. But, we also need to document or more ways
to do this, lest we have gap that may be filled in non-interoperable ways.

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 31 Oct 2013 18:22:51 +0000

I think we're mostly on the same page here, though the question of whether
something like web PKI is still relevant largely depends on how real we
think DANE is. No question that it would be better, and that the warts of
web PKI grow increasingly ugly. But I haven't heard a lot of enthusiasm
from browser vendors, say, about DANE (I haven't taken this temperature
super recently, though, so that may just be stale information). I also
think that despite its warts, the world is still better off with web PKI
today than it would be if it all went away with nothing to replace it.

I'm not sure I could predict with total certainty where the market is
going to go with all this. When I'm in that position, I tend to favor a
certain amount of flexibility rather than gambling it all on one number on
the roulette wheel.

Jon Peterson
Neustar, Inc.

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Thu, 31 Oct 2013 18:39:30 +0000

I heard a remark from the panel at an Acme Packet Interconnect conference a few years ago (by Richard Shockey?) that E.164 numbers are an international language that do not require multiple character sets or PUNYcode.

I agree study of non-TN authentication is valuable but a solution specific to TNs seems cardinal.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: October 31, 2013 11:27 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

Jon,

Mike

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Thursday, October 31, 2013 12:06 PM
To: Stephen Kent; Michael Hammer; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

Jon Peterson
Neustar, Inc.

>distinctions among all of these, we are doing a disservice to readers,

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Oct 2013 16:16:35 -0400

Jon,

> certain amount of flexibility rather than gambling it all on one number on
How about a compromise; we strong recommend DANE, and characterize
the WebPKI as a fallback, with caveats.

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 31 Oct 2013 20:42:22 +0000

I wouldn't have any objection to ending up with that recommendation for
handling non-TN identities - but I'm still just trying to take the first
baby steps in the direction of a solution here.

Jon Peterson
Neustar, Inc.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 31 Oct 2013 16:52:55 -0400

I’m not necessarily opposed, but let’s spend a bit of time thinking about this.

If we assume, as we have so far, that we have a database that holds credentials, and everyone gets the credentials from the database, then a lot of the WebPKI problems don’t occur.
We don’t really care who signed the cert if the right cert is in the database for the TN.  It could be self signed, and it would be okay.  Not ideal, but okay.

Our vulnerabilities are who can change the record in the database, and what kind of MITM mischief could occur in fetching an entry from the database.  Improperly issuing a cert or even a whole lot of them, isn’t a problem per se.

Even something as really bad as leaking the private key of the CA wouldn’t take us down.  We’d get worried about recent entries, but as long as we’re sure the entity writing to the database is who we think it is, it’s not a big problem, right?

What are the WebPKI problems do you think we care about?

Brian

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Oct 2013 17:35:14 -0400

Brian,
> We don’t really care who signed the cert if the right cert is in the database for the TN.  It could be self signed, and it would be okay.  Not ideal, but okay.
I did not realize that the model we were specifying had the properties 
you describe.
I though that a caller (or an intermediary acting on its behalf) might 
send a signed token
as part of call setup, and the callee (or an intermediary acting on its 
behalf) would
acquire a credential to verify that token. Whether that credential comes 
from "a database"
or is fetched using a URL passed as part of call setup, or whatever was 
not clear to me.
Also, if one makes use of PKI technology, the database need not, itself, 
be trusted,
so the fact that a credential comes form a database does not ensure that 
it's valid,
of authoritative for the asserted caller ID.
> Our vulnerabilities are who can change the record in the database, and what kind of MITM mischief could occur in fetching an entry from the database.  Improperly issuing a cert or even a whole lot…
It sounds as though you have a very specific DB model in mind, which I 
didn't see as an intrinsic part
of the spec Jon et al. were writing.
> Even something as really bad as leaking the private key of the CA wouldn’t take us down.  We’d get worried about recent entries, but as long as we’re sure the entity writing to the database is who…
ibid.
> What are the WebPKI problems do you think we care about?
The biggest problem with the WebPKI is that is enables ANY trust anchor 
to issue
a cert for ANY subject, and the cert will be accepted. This means that a 
secruity
breach at ANY TA is very bad.

Steve

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Oct 2013 18:19:37 -0400

Guilty as charged.  Digits travel well. 

And +1 to the rest of your sentiment here.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gorman, Pierce A [NTK]
Sent: Thursday, October 31, 2013 2:40 PM
To: Michael Hammer; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

I heard a remark from the panel at an Acme Packet Interconnect conference a
few years ago (by Richard Shockey?) that E.164 numbers are an international
language that do not require multiple character sets or PUNYcode.

I agree study of non-TN authentication is valuable but a solution specific
to TNs seems cardinal.

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: October 31, 2013 11:27 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

Jon,

Understand being flexible and covering all fronts.
But, if it gets watered down to a least common denominator that doesn't meet
the requirements for TN, I think that would be a failure.

Mike

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Thursday, October 31, 2013 12:06 PM
To: Stephen Kent; Michael Hammer; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

Jon Peterson
Neustar, Inc.

This e-mail may contain Sprint proprietary information intended for the sole
use of the recipient(s). Any use by others is prohibited. If you are not the
intended recipient, please contact the sender and delete all copies of the
message.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Oct 2013 18:28:14 -0400

I would strongly caution that issues surrounding the E.164 numbering plan
and the databases that enable them are in fact national specific issues
enabled in law. 

We only may be able to make Recommendations on implementation of STIR key
management structures we may not be able to impose them. 

This is a fluid situation at this point. To be blunt I'm not sure what is
the best recommendation or course of action we can make to the NRA's.  As
you point out the record on PKI is mixed.  That said number assignment
authorities and those that receive the resource are a more limited and
restricted subset and that may actually work to our advantage. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Thursday, October 31, 2013 4:17 PM
To: Peterson, Jon; [email-masked]
Subject: Re: [stir] comment on draft-jennings-stir-rfc4474bis-00

Jon,

> I think we're mostly on the same page here, though the question of 
> whether something like web PKI is still relevant largely depends on 
> how real we think DANE is. No question that it would be better, and 
> that the warts of web PKI grow increasingly ugly. But I haven't heard 
> a lot of enthusiasm from browser vendors, say, about DANE (I haven't 
> taken this temperature super recently, though, so that may just be 
> stale information). I also think that despite its warts, the world is 
> still better off with web PKI today than it would be if it all went away
with nothing to replace it.
> going to go with all this. When I'm in that position, I tend to favor 
> a certain amount of flexibility rather than gambling it all on one 
> number on the roulette wheel.
>
How about a compromise; we strong recommend DANE, and characterize the
WebPKI as a fallback, with caveats.

Steve