Subject: [stir] Call for adoption of draft-peterson-stir-certificates

From: Robert Sparks <[email-masked]>
Date: Fri, 25 Jul 2014 13:42:38 -0400

There was very strong consensus in the Toronto STIR meeting to adopt 
draft-peterson-stir-certificates as a STIR WG document.
This message is to confirm that consensus on-list.
Please comment before 8-Aug-2014.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 26 Jul 2014 13:49:26 +0000

I support adopting draft-peterson-stir-certificates as a STIR WG document.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Friday, July 25, 2014 1:43 PM
To: [email-masked]
Subject: [stir] Call for adoption of draft-peterson-stir-certificates

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

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 26 Jul 2014 14:38:21 -0400

+1  

Yes we want to direct our work towards a full 509/CRL based solution and all
the messy issues that go with that as our friends in SIDR have understood.

---

From: <[email-masked]>
Date: Sun, 27 Jul 2014 16:08:21 +0000

I support this becoming a WG work item.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13<tel:+33%20(0)%201%2045%2029%2058%2013>

-------- Message d'origine --------
De : Robert Sparks <[email-masked]>
Date : 25/07/2014 19:43 (GMT+01:00)
A : [email-masked]
Objet : [stir] Call for adoption of draft-peterson-stir-certificates

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: David Schwartz <[email-masked]>
Date: Sun, 27 Jul 2014 16:25:35 +0000

+1

> On Jul 25, 2014, at 8:43 PM, "Robert Sparks" <[email-masked]> wrote:
> 
> There was very strong consensus in the Toronto STIR meeting to adopt draft-peterson-stir-certificates as a STIR WG document.

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 27 Jul 2014 17:20:44 -0400

OK .. The real question.  How are the gory details going to be worked out?  

In STIR or where? 

If you look at SIDR as a somewhat close approximation of the current problem
statement we have to decide how the 509 gets profiled the CRL and the rest
of the details. I would argue that we cannot decide the underlying
distribution mechanism for either the private or public keys. That is a
nation state specific problem.  We can recommend that the relevant National
Numbering Authority do FOO but I'm not sure how much else is possible.

Is that in RAI or ?   This is actually something the AD's and frankly Russ
could chime in on. Russ knowing as much about 509 as all of us combined. 

Well?

I would suggest that we do consult with our SIDR friends here.  Having
personally spoken to many of them on a private research project it seems
fruitful to document the issues they were confronted with and apply them
when applicate to our current work plan. 

BTW even though this list is often silent I would suggest the Toronto
Consensus is actually real progress.  This is actually a BFD considering the
WG has only been in existence for less than 1 year.  We know the problem we
know how SIP has to handle the problem we know what a solution sort of looks
like.  Don't worry be happy! 

From: stir [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, July 27, 2014 12:08 PM
To: [email-masked]
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13 <tel:+33%20(0)%201%2045%2029%2058%2013> 

-------- Message d'origine --------
De : Robert Sparks <[email-masked] <mailto:[email-masked]> > 
Date : 25/07/2014 19:43 (GMT+01:00) 
A : [email-masked] <mailto:[email-masked]>  
Objet : [stir] Call for adoption of draft-peterson-stir-certificates 

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

____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 28 Jul 2014 09:05:41 -0400

I think we do it in STIR.  Not only do we have Russ, but we have Sean, and we have EKR, and we have other folks well versed in certs.

I agree than distribution will vary some by country, but I think it would be worth our time to write up some guidelines at least.

One part I know we have to do is to do something OCSP-like that verifies the validity of a cert for a particular TN (that is, get a cert for a range, port a number out of the range, the cert is still valid for the rest of the range, but not the TN ported out).  Not sure a CRL is really helpful since we need that query.  It’s not a bad thing to have a CRL, but you need the other bit anyway.

And I agree, we are making very good progress.

Brian

On Jul 27, 2014, at 5:20 PM, Richard Shockey <[email-masked]> wrote:

> If you look at SIDR as a somewhat close approximation of the current problem statement we have to decide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution mechanism for either the private or public keys. That is a nation state specific problem.  We can recommend that the relevant National Numbering Authority do FOO but I’m not sure how much else is possible.
>  
> Is that in RAI or ?   This is actually something the AD’s and frankly Russ could chime in on. Russ knowing as much about 509 as all of us combined.
>  
> Well?
>  
> I would suggest that we do consult with our SIDR friends here.  Having personally spoken to many of them on a private research project it seems fruitful to document the issues they were confronted with and apply them when applicate to our current work plan.
>  
> BTW even though this list is often silent I would suggest the Toronto Consensus is actually real progress.  This is actually a BFD considering the WG has only been in existence for less than 1 year.  We know the problem we know how SIP has to handle the problem we know what a solution sort of looks like.  Don’t worry be happy!
>  
>  
> From: stir [mailto:[email-masked]] On Behalf Of [email-masked]
> +33 (0) 1 45 29 58 13

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Jul 2014 14:47:40 +0000

My suggestion would be conceptual simplicity. My hunch is that the fraction of numbers that are assigned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have "holes".) The only ranges likely to be left are large-scale businesses. Thus, if we can devise a mechanism that's a bit less efficient, but avoids dealing with prefixes, this might be a good trade-off.

As long as there's a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-less static table of national prefixes, the national aspect doesn't seem to be too hard - even if there's more than one way to retrieve a cert or public key. (I realize +1 poses somewhat unique challenges, but treating it as a list of mini-countries for each area code, where the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 9:06 AM
To: Richard Shockey
Cc: FOUQUART Philippe IMT/OLN; [email-masked]
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

One part I know we have to do is to do something OCSP-like that verifies the validity of a cert for a particular TN (that is, get a cert for a range, port a number out of the range, the cert is still valid for the rest of the range, but not the TN ported out).  Not sure a CRL is really helpful since we need that query.  It's not a bad thing to have a CRL, but you need the other bit anyway.

Brian

On Jul 27, 2014, at 5:20 PM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

In STIR or where?

If you look at SIDR as a somewhat close approximation of the current problem statement we have to decide how the 509 gets profiled the CRL and the rest of the details. I would argue that we cannot decide the underlying distribution mechanism for either the private or public keys. That is a nation state specific problem.  We can recommend that the relevant National Numbering Authority do FOO but I'm not sure how much else is possible.

Is that in RAI or ?   This is actually something the AD's and frankly Russ could chime in on. Russ knowing as much about 509 as all of us combined.

Well?

BTW even though this list is often silent I would suggest the Toronto Consensus is actually real progress.  This is actually a BFD considering the WG has only been in existence for less than 1 year.  We know the problem we know how SIP has to handle the problem we know what a solution sort of looks like.  Don't worry be happy!

From: stir [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Sunday, July 27, 2014 12:08 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

Philippe Fouquart
Orange Labs Networks

-------- Message d'origine --------
De : Robert Sparks <[email-masked]<mailto:[email-masked]>>
Date : 25/07/2014 19:43 (GMT+01:00)
A : [email-masked]<mailto:[email-masked]>
Objet : [stir] Call for adoption of draft-peterson-stir-certificates

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

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 28 Jul 2014 10:53:44 -0400

Either a cert has a bunch of TNs in it, or it is cert-per-TN.  
While cert-per-TN is conceptually simple, for a large carrier, it’s a significant burden, especially because they would need to keep all those private keys in many places in their networks.
If you have multiple TNs in a cert, then you can’t have the actual TNs the cert covers in the cert itself without getting huge, or you can have ranges.  If you have multiple TNs in a cert, you need the OCSP-like “is this cert good for this TN”.  If you have cert-per-TN, then you have OCSP as is - CRLs won’t work, because the cert gets revoked for a port, and thus the CRL would be huge.

Brian

On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <[email-masked]> wrote:

> My suggestion would be conceptual simplicity. My hunch is that the fraction of numbers that are assigned as continuous ranges to providers is decreasing, given porting activity. (Almost every 10k or 1k block will have “holes”.) The only ranges likely to be left are large-scale businesses. Thus, if we can devise a mechanism that’s a bit less efficient, but avoids dealing with prefixes, this might be a good trade-off.
>  
> As long as there’s a discovery mechanism (e.g., LoST, as mentioned before) or even a more-or-less static table of national prefixes, the national aspect doesn’t seem to be too hard – even if there’s more than one way to retrieve a cert or public key. (I realize +1 poses somewhat unique challenges, but treating it as a list of mini-countries for each area code, where the Canadian, Caribbean and US ones point to different databases/DNS entries seems manageable.)
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Jul 2014 14:59:47 +0000

I guess it also depends on whether a database (DNS, HTTP-based) returns a cert or a public key.

I don't see the difference - you could use the same private key to sign a bunch of certs, for different numbers. Why would you need a different private key? (After all, in a standard web cert, the CA signs millions with the same key.)

Depending on how widely available the database becomes outside the usual set of carriers, I suspect there will be carriers who will want to obscure which numbers they manage. They can do this by creating individual keys.

From: Brian Rosen [mailto:[email-masked]]
Sent: Monday, July 28, 2014 10:54 AM
To: Henning Schulzrinne
Cc: Richard Shockey; FOUQUART Philippe IMT/OLN; [email-masked]
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

Either a cert has a bunch of TNs in it, or it is cert-per-TN.
While cert-per-TN is conceptually simple, for a large carrier, it's a significant burden, especially because they would need to keep all those private keys in many places in their networks.
If you have multiple TNs in a cert, then you can't have the actual TNs the cert covers in the cert itself without getting huge, or you can have ranges.  If you have multiple TNs in a cert, you need the OCSP-like "is this cert good for this TN".  If you have cert-per-TN, then you have OCSP as is - CRLs won't work, because the cert gets revoked for a port, and thus the CRL would be huge.

Brian

On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 9:06 AM
To: Richard Shockey
Cc: FOUQUART Philippe IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

Brian

In STIR or where?

Well?

Philippe Fouquart
Orange Labs Networks

-------- Message d'origine --------
De : Robert Sparks <[email-masked]<mailto:[email-masked]>>
Date : 25/07/2014 19:43 (GMT+01:00)
A : [email-masked]<mailto:[email-masked]>
Objet : [stir] Call for adoption of draft-peterson-stir-certificates

Thank you.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 28 Jul 2014 11:08:02 -0400

I believe we agreed that credentials are represented in certs and not Hadriel’s DANE-like proposal.

I think there is quite a bit of difference between a CA signing a cert with the same key it signs all certs and having a zillion certs having the same private key, but I’ll let the experts chime in on that.

My model is that credential holders have control over how many certs they have.  When they get a delegation, they go to the database and either ask for a new cert with that delegation, or they supply an existing cert and ask that the delegation be added to it.

BTW, if it’s TN-per-cert, then a delegation of 10K numbers is 10K certs, 10K calls to the database, 10K times PKCS-whatever to create the cert, etc.

Brian

On Jul 28, 2014, at 10:59 AM, Henning Schulzrinne <[email-masked]> wrote:

> I don’t see the difference – you could use the same private key to sign a bunch of certs, for different numbers. Why would you need a different private key? (After all, in a standard web cert, the CA signs millions with the same key.)
>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 28 Jul 2014 11:52:15 -0400

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 10:54 AM
To: Henning Schulzrinne
Cc: FOUQUART Philippe IMT/OLN; [email-masked]; Richard Shockey
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

While cert-per-TN is conceptually simple, for a large carrier, it's a
significant burden, especially because they would need to keep all those
private keys in many places in their networks.

[RS> ] 

[RS> ]  Really?  How many places would you anticipate?  If you are a major
US MSO its only about 4 consolidated centers. ILEC CO's are going away
LATA's are gone in a few years in the US.   Are you assuming then that the
originating SBC is the entity that signs the INVITE?  Just curious. 

If you have multiple TNs in a cert, then you can't have the actual TNs the
cert covers in the cert itself without getting huge, or you can have ranges.
If you have multiple TNs in a cert, you need the OCSP-like "is this cert
good for this TN".  If you have cert-per-TN, then you have OCSP as is - CRLs
won't work, because the cert gets revoked for a port, and thus the CRL would
be huge.

[RS> ] Ok how many real competitive ports per day are you looking at?  Not
the network grooming stuff. Granted there is a policy issue on how fast this
would  have to be updated. 

In any event is should be clear that I agree with Henning that a cert per TN
system is preferable and our guidelines should reflect that. Why are you
even suggesting number block ranges?  You are the last person I would have
thought would be fond of the LERG. [That's the North American Local Exchange
Routing Guide for you non NA centric folks]

In addition I certainly agree that we cannot boil the ocean here with a
requirement for some global system. Nothing will ever get deployed. I still
have the 6116 arrows sticking out my back. 

Brian

On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne
<[email-masked] <mailto:[email-masked]> > wrote:

My suggestion would be conceptual simplicity. My hunch is that the fraction
of numbers that are assigned as continuous ranges to providers is
decreasing, given porting activity. (Almost every 10k or 1k block will have
"holes".) The only ranges likely to be left are large-scale businesses.
Thus, if we can devise a mechanism that's a bit less efficient, but avoids
dealing with prefixes, this might be a good trade-off.

As long as there's a discovery mechanism (e.g., LoST, as mentioned before)
or even a more-or-less static table of national prefixes, the national
aspect doesn't seem to be too hard - even if there's more than one way to
retrieve a cert or public key. (I realize +1 poses somewhat unique
challenges, but treating it as a list of mini-countries for each area code,
where the Canadian, Caribbean and US ones point to different databases/DNS
entries seems manageable.)

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 9:06 AM
To: Richard Shockey
Cc: FOUQUART Philippe IMT/OLN; [email-masked] <mailto:[email-masked]> 
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

I think we do it in STIR.  Not only do we have Russ, but we have Sean, and
we have EKR, and we have other folks well versed in certs.

I agree than distribution will vary some by country, but I think it would be
worth our time to write up some guidelines at least.

One part I know we have to do is to do something OCSP-like that verifies the
validity of a cert for a particular TN (that is, get a cert for a range,
port a number out of the range, the cert is still valid for the rest of the
range, but not the TN ported out).  Not sure a CRL is really helpful since
we need that query.  It's not a bad thing to have a CRL, but you need the
other bit anyway.

Brian

On Jul 27, 2014, at 5:20 PM, Richard Shockey < <mailto:[email-masked]>
[email-masked]> wrote:

In STIR or where?

Well?

 

From: stir [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of  <mailto:[email-masked]>
[email-masked]
Sent: Sunday, July 27, 2014 12:08 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

Philippe Fouquart
Orange Labs Networks
 <tel:+33%20(0)%201%2045%2029%2058%2013> +33 (0) 1 45 29 58 13

-------- Message d'origine --------
De : Robert Sparks < <mailto:[email-masked]> [email-masked]> 
Date : 25/07/2014 19:43 (GMT+01:00) 
A :  <mailto:[email-masked]> [email-masked] 
Objet : [stir] Call for adoption of draft-peterson-stir-certificates 

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

 

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 28 Jul 2014 12:48:31 -0400

> [RS> ]  Really?  How many places would you anticipate?  If you are a major US MSO its only about 4 consolidated centers. ILEC CO’s are going away LATA’s are gone in a few years in the US.   Are you assuming then that the originating SBC is the entity that signs the INVITE?  Just curious.
Signing could be done at or near the subscriber SBC.  There are a lot more than 4 of those.
Checking could be done at the same spot and/or could be done at interchange points (POIs).  I understand 7-9 is the average number for larger SPs and there is more than one SBC in each.  
I think it’s at least dozens, and probably more for many larger networks.  And they are geographically spread out.  

> [RS> ] Ok how many real competitive ports per day are you looking at?  Not the network grooming stuff. Granted there is a policy issue on how fast this would  have to be updated.
US NPAC does about 1.5M transactions a day.  Not all of those would invalidate a cert, but I lot would either create one or invalidate one.  I believe you have to keep the cert in the CRL at least until it expires.  How long we’re you thinking the expiration time was?  A typical year?   More?   You fetch an entire CRL.   It’s just not a practical answer.  And we have OCSP.  A much more practical answer, even with an extension if we support ranges.

>  
> In any event is should be clear that I agree with Henning that a cert per TN system is preferable and our guidelines should reflect that. Why are you even suggesting number block ranges?  You are the last person I would have thought would be fond of the LERG. [That’s the North American Local Exchange Routing Guide for you non NA centric folks]
Because most delegations to SPs are in a range.  It may be that eventually, SPs won’t keep number inventory, but they do for most SPs in effectively all countries.  

>  
>  
> In addition I certainly agree that we cannot boil the ocean here with a requirement for some global system. Nothing will ever get deployed… I still have the 6116 arrows sticking out my back.
No one is arguing, but the details have to be worked out.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Jul 2014 13:52:31 -0500

There are several conversations starting.
Please move them to a new thread and preserve the 'adoption' thread for 
comments specifically about adopting the document.

RjS

On 7/28/14, 11:48 AM, Brian Rosen wrote:
>> significant burden, especially because they would need to keep all 
>> those private keys in many places in their networks.
>> */[RS> ]/*
>> */[RS> ]  Really?  How many places would you anticipate? If you are a 
>> major US MSO its only about 4 consolidated centers. ILEC CO's are 
>> going away LATA's are gone in a few years in the US.   Are you 
>> assuming then that the originating SBC is the entity that signs the 
>> INVITE?  Just curious./*
> Checking could be done at the same spot and/or could be done at 
> interchange points (POIs).  I understand 7-9 is the average number for 
> larger SPs and there is more than one SBC in each.
> I think it's at least dozens, and probably more for many larger 
> networks.  And they are geographically spread out.
>
>> *//*
>> *//*
>> If you have multiple TNs in a cert, then you can't have the actual 
>> TNs the cert covers in the cert itself without getting huge, or you 
>> can have ranges.  If you have multiple TNs in a cert, you need the 
>> OCSP-like "is this cert good for this TN".  If you have cert-per-TN, 
>> then you have OCSP as is - CRLs won't work, because the cert gets 
>> revoked for a port, and thus the CRL would be huge.
>> */[RS> ] Ok how many real competitive ports per day are you looking 
>> at?  Not the network grooming stuff. Granted there is a policy issue 
>> on how fast this would  have to be updated./*
> US NPAC does about 1.5M transactions a day.  Not all of those would 
> invalidate a cert, but I lot would either create one or invalidate 
> one.  I believe you have to keep the cert in the CRL at least until it 
> expires.  How long we're you thinking the expiration time was?  A 
> typical year?   More?   You fetch an entire CRL.   It's just not a 
> practical answer.  And we have OCSP.  A much more practical answer, 
> even with an extension if we support ranges.
>
>
>> *//*
>> *//*
>> */In any event is should be clear that I agree with Henning that a 
>> cert per TN system is preferable and our guidelines should reflect 
>> that. Why are you even suggesting number block ranges?  You are the 
>> last person I would have thought would be fond of the LERG. [That's 
>> the North American Local Exchange Routing Guide for you non NA 
>> centric folks]/*
> Because most delegations to SPs are in a range.  It may be that 
> eventually, SPs won't keep number inventory, but they do for most SPs 
> in effectively all countries.
>
>> *//*
>> *//*
>> *//*
>> */In addition I certainly agree that we cannot boil the ocean here 
>> with a requirement for some global system. Nothing will ever get 
>> deployed... I still have the 6116 arrows sticking out my back./*
>> *//*
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>     My suggestion would be conceptual simplicity. My hunch is that
>>     the fraction of numbers that are assigned as continuous ranges to
>>     providers is decreasing, given porting activity. (Almost every
>>     10k or 1k block will have "holes".) The only ranges likely to be
>>     left are large-scale businesses. Thus, if we can devise a
>>     mechanism that's a bit less efficient, but avoids dealing with
>>     prefixes, this might be a good trade-off.
>>     As long as there's a discovery mechanism (e.g., LoST, as
>>     mentioned before) or even a more-or-less static table of national
>>     prefixes, the national aspect doesn't seem to be too hard -- even
>>     if there's more than one way to retrieve a cert or public key. (I
>>     realize +1 poses somewhat unique challenges, but treating it as a
>>     list of mini-countries for each area code, where the Canadian,
>>     Caribbean and US ones point to different databases/DNS entries
>>     seems manageable.)
>>     *From:*stir [mailto:[email-masked]]*On Behalf Of*Brian Rosen
>>     *Sent:*Monday, July 28, 2014 9:06 AM
>>     *To:*Richard Shockey
>>     *Cc:*FOUQUART Philippe IMT/OLN;[email-masked] <mailto:[email-masked]>
>>     *Subject:*Re: [stir] Call for adoption of
>>     draft-peterson-stir-certificates
>>     I think we do it in STIR.  Not only do we have Russ, but we have
>>     Sean, and we have EKR, and we have other folks well versed in certs.
>>     I agree than distribution will vary some by country, but I think
>>     it would be worth our time to write up some guidelines at least.
>>     One part I know we have to do is to do something OCSP-like that
>>     verifies the validity of a cert for a particular TN (that is, get
>>     a cert for a range, port a number out of the range, the cert is
>>     still valid for the rest of the range, but not the TN ported
>>     out).  Not sure a CRL is really helpful since we need that query.
>>      It's not a bad thing to have a CRL, but you need the other bit
>>     anyway.
>>     If you look at SIDR as a somewhat close approximation of the
>>     current problem statement we have to decide how the 509 gets
>>     profiled the CRL and the rest of the details. I would argue that
>>     we cannot decide the underlying distribution mechanism for either
>>     the private or public keys. That is a nation state specific
>>     problem.  We can recommend that the relevant National Numbering
>>     Authority do FOO but I'm not sure how much else is possible.
>>     Is that in RAI or ?   This is actually something the AD's and
>>     frankly Russ could chime in on. Russ knowing as much about 509 as
>>     all of us combined.
>>     Well?
>>     I would suggest that we do consult with our SIDR friends here. 
>>     Having personally spoken to many of them on a private research
>>     project it seems fruitful to document the issues they were
>>     confronted with and apply them when applicate to our current work
>>     plan.
>>     BTW even though this list is often silent I would suggest the
>>     Toronto Consensus is actually real progress.  This is actually a
>>     BFD considering the WG has only been in existence for less than 1
>>     year.  We know the problem we know how SIP has to handle the
>>     problem we know what a solution sort of looks like. Don't worry
>>     be happy!
>>     *From:*stir [mailto:[email-masked]]*On Behalf
>>     [email-masked] <mailto:[email-masked]>
>>     *Sent:*Sunday, July 27, 2014 12:08 PM
>>     *To:[email-masked] <mailto:[email-masked]>
>>     *Subject:*Re: [stir] Call for adoption of
>>     draft-peterson-stir-certificates
>>     +33 (0) 1 45 29 58 13 <tel:+33%20%280%29%201%2045%2029%2058%2013>
>>
>>
>>
>>
>>     A :[email-masked] <mailto:[email-masked]>

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Mon, 28 Jul 2014 21:41:08 +0200

All the previous comments are in line with the cert-agreement as Brian mentioned and we shall just have a look at the broader picture.

Issues:
1.) How to find the CA for validation?
2.) Signing single- or multiple phone numbers with a cert?
3.) Do we need certificate profiles /extensions as proposed?

Add. 1.) Finding certificates is a big issue in PKI
If we do not trust the Trust-reference in the SIP message, we can solve it by introducing a trusted Reference-Plane that points to a CA for every number or blocks of numbers if that is still needed. (FCC is going to change this in future anyhow).
This can be added to existing databases. NPAC, ENUM, or others like LIDBI,etc.
It will definitely be tolerant to global regulatory requirements as e.g. used in European signature laws.

To allow smooth migration, one can start with signing whole blocks by the operator on behalf of users. Then one can slowly migrate to user-assigned certs for every users phone.

Add. 2.) Signing single- or multiple phone numbers
With the introduction of a reference plane we can have both models served.
However, thinking about Henning and Richards arguments, we will need individual number assignment in the future anyhow. The solution shall therefore be agnostic.
This of course is in conflict with the proposal to create phone number specific certificate profiles / extensions.

Add. 3.) Do we need certificate profiles /extensions as proposed?
Short answer: No

For certs with the proposed profiles one shall be aware of the following:
- Current signing and validation SW can not handle it
- Client SW will be limited to telephony specific usage
- No other applications e.g. WEB, Messaging, login, etc.
can handle it and therefore we re-create the multiple credential management
issues we know from passwords and that like already.
- A CName in the certificate can hold phone number(s) as well.
Therefore one can use it on any client.
- Multiple phone numbers can be signed with the domain of the operator or the IP-PBX.

We therefore shall care for re-usable credentials and not create profiles which clients and relying parties can not handle.

We shall always keep a smooth migration part in mind.
e.g.: 1.) Signing everything on behalf of the user by operators and 2.) Slow migration to private user signatures.

Willi