Subject: Re: [stir] Ranges or individual numbers

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Jul 2014 19:03:51 +0000

I'm not sure that the OCSP will differ all that much in practice, given the large number of ranges (i.e., a single SBC will see the same range only somewhat more likely than the same number within the caching interval).

Given the relatively low growth of voice services, my guess is that almost all new (to-a-provider) customers are either ports or from existing inventory. Ports will convert a block into three blocks: the range below the port, the ported "singleton" number (which may become, by chance, part of an existing block on the winning side at some point, but initially won't, by definition) and the range above. Managing all of these splits and merges doesn't sound all that much easier than individual numbers and seems harder to implement. Since we don't want porting to fail validation (I'm less worried that the losing provider can still sign for a while), we probably need a push notification.

I'm not against ranges, but I'm trying to make sure we consider all the complexities involved before early "optimization" of one facet.

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 12:49 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

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.

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.

And I agree, we are making very good progress.

Brian

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

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]<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

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]<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

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.

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

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Jul 2014 15:29:08 -0400

May I also note that that 1.5M number seems a little fantastic?  At that
rate, the entire US population would be porting their number roughly every
7 months.  I'm not saying you're wrong, just that we should be careful
about translating numbers like that into estimates of required certificate
changes.

On Tue, Jul 29, 2014 at 3:03 PM, Henning Schulzrinne <
[email-masked]> wrote:

>  I’m not sure that the OCSP will differ all that much in practice, given
> the large number of ranges (i.e., a single SBC will see the same range only
> somewhat more likely than the same number within the caching interval).
>
>
>
> Given the relatively low growth of voice services, my guess is that almost
> all new (to-a-provider) customers are either ports or from existing
> inventory. Ports will convert a block into three blocks: the range below
> the port, the ported “singleton” number (which may become, by chance, part
> of an existing block on the winning side at some point, but initially
> won’t, by definition) and the range above. Managing all of these splits and
> merges doesn’t sound all that much easier than individual numbers and seems
> harder to implement. Since we don’t want porting to fail validation (I’m
> less worried that the losing provider can still sign for a while), we
> probably need a push notification.
>
>
>
> I’m not against ranges, but I’m trying to make sure we consider all the
> complexities involved before early “optimization” of one facet.
>
>
>
> *From:* stir [mailto:[email-masked]] *On Behalf Of *Brian Rosen
> *Sent:* Monday, July 28, 2014 12:49 PM
> *To:* Richard Shockey
> *Cc:* [email-masked]
> *Subject:* Re: [stir] Call for adoption of
> draft-peterson-stir-certificates
>
>
>
> 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.*
>
> 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:* stir [mailto:[email-masked] <[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
>
>
>
> 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.
>
>
>
> 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] <[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
>
>
>
> +33 (0) 1 45 29 58 13 <+33%20(0)%201%2045%2029%2058%2013>
>
>
>
>
> De : Robert Sparks <[email-masked]>
> A : [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Jul 2014 15:51:21 -0400

It is the actual number of transactions, but as noted, not all transactions would affect certs.  There are some bulk operations that do things that may not affect certificates, although a lot of them would.  For example, it’s not uncommon for a carrier to change the “SPID” for a set of numbers it has maintain separate from other numbers (for example, from an acquisition).  Depending on how the carrier maintains its certs, the cert may or may not change (for example, the identity in the cert could be the parent, or it could relate to the acquisition).  

Brian
On Jul 29, 2014, at 3:29 PM, Richard Barnes <[email-masked]> wrote:

> May I also note that that 1.5M number seems a little fantastic?  At that rate, the entire US population would be porting their number roughly every 7 months.  I'm not saying you're wrong, just that we should be careful about translating numbers like that into estimates of required certificate changes.
> 
> 
> On Tue, Jul 29, 2014 at 3:03 PM, Henning Schulzrinne <[email-masked]> wrote:
> I’m not sure that the OCSP will differ all that much in practice, given the large number of ranges (i.e., a single SBC will see the same range only somewhat more likely than the same number within the caching interval).
> 
>  
> 
> Given the relatively low growth of voice services, my guess is that almost all new (to-a-provider) customers are either ports or from existing inventory. Ports will convert a block into three blocks: the range below the port, the ported “singleton” number (which may become, by chance, part of an existing block on the winning side at some point, but initially won’t, by definition) and the range above. Managing all of these splits and merges doesn’t sound all that much easier than individual numbers and seems harder to implement. Since we don’t want porting to fail validation (I’m less worried that the losing provider can still sign for a while), we probably need a push notification.
> 
>  
> 
> I’m not against ranges, but I’m trying to make sure we consider all the complexities involved before early “optimization” of one facet.
> 
>  
> 
> 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.
> 
> 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.)
> 
>  
> 
> Cc: FOUQUART Philippe IMT/OLN; [email-masked]
> 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?
> 
>  
> 
> 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]
> To: [email-masked]
> +33 (0) 1 45 29 58 13

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 29 Jul 2014 15:53:02 -0400

For purposes of argument though any "recommendation to NRA"s" will have to
address the issue from either perspective.

A.     Those jurisdictions that have some form of Centralized Real-time
Numbering Databases (LNP centric) which would be North America The
Netherlands aka COIN, Ireland the Baltics etc vs

B.     Those that don't and still do block routing.  The most obvious
example is the UK and France China Japan etal.  Germany is not all that
wonderful either.

From: stir [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Tuesday, July 29, 2014 3:04 PM
To: 'Brian Rosen'; Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] Ranges or individual numbers

I'm not sure that the OCSP will differ all that much in practice, given the
large number of ranges (i.e., a single SBC will see the same range only
somewhat more likely than the same number within the caching interval).

Given the relatively low growth of voice services, my guess is that almost
all new (to-a-provider) customers are either ports or from existing
inventory. Ports will convert a block into three blocks: the range below the
port, the ported "singleton" number (which may become, by chance, part of an
existing block on the winning side at some point, but initially won't, by
definition) and the range above. Managing all of these splits and merges
doesn't sound all that much easier than individual numbers and seems harder
to implement. Since we don't want porting to fail validation (I'm less
worried that the losing provider can still sign for a while), we probably
need a push notification.

I'm not against ranges, but I'm trying to make sure we consider all the
complexities involved before early "optimization" of one facet.

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 12:49 PM
To: Richard Shockey
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

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.

 

Brian

On Jul 28, 2014, at 10:47 AM, Henning Schulzrinne <
<mailto:[email-masked]> [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]> mailto:[email-masked]] On
Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 9:06 AM
To: Richard Shockey
Cc: FOUQUART Philippe IMT/OLN;  <mailto:[email-masked]> [email-masked]
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

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?

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]> 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

____________________________________________________________________________
_____________________________________________
 
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.

_______________________________________________
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: "Richard Shockey" <[email-masked]>
Date: Tue, 29 Jul 2014 16:13:59 -0400

May I also note that that 1.5M number seems a little fantastic?  

[RS> ] Believe me it’s not.    You have to understand what the NPAC actually does in the US network. NRA real-time databases do different things in different jurisdictions.

In the US it’s used for functions totally unrelated to Local Number Portability.  The term of art is “Network Grooming”.  A number shift from a 3G platform to VoLTE for instance instituted as what is known as an intra-carrier port.  A different Destination Point Code to the CSCF but the consumer still has the number.  The cert in that case would NOT change. 

You are thinking about actual competitive inter-carrier ports that go that Carrier A to Carrier B.  Where the carrier of record or would change. That is technically carrier “churn” and that has been consistent at about 1-2% of the market per year in North America.  That is actually supported by the fact that 7% of the entire US population moves every year.  But not all of those generate ports and in addition since most calling is actually local you have to separate inter from intra LATA calling to estimate how many INVITES need to be signed by a given SBC.   Doing this calculation in Europe is very very different.  

At that rate, the entire US population would be porting their number roughly every 7 months.  I'm not saying you're wrong, just that we should be careful about translating numbers like that into estimates of required certificate changes.

On Tue, Jul 29, 2014 at 3:03 PM, Henning Schulzrinne <[email-masked] <mailto:[email-masked]> > wrote:

From: stir [mailto: <mailto:[email-masked]> [email-masked]] On Behalf Of Brian Rosen
Sent: Monday, July 28, 2014 12:49 PM
To: Richard Shockey
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [stir] Call for adoption of draft-peterson-stir-certificates

 

 

 

Brian

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

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

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

-------- 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

_______________________________________________
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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Jul 2014 16:15:53 -0400

If we allowed ranges, I would NOT invalidate a cert when a number ported out (or back in) to a range.  I would have an OCSP-like query that was queried with cert and TN and responded with valid-for-that-TN or not.  Since CRLs don’t work, you need something like OCSP.  Since you are querying for validity, extending to say “valid for this TN” is a small change.

Numbers in use are growing, but somewhat slower than before.  Some of the growth is in devices that are not phones, but they would need certs.  Inventory changes all the time, especially since we hand out numbers in blocks of 1000, rather than the 10K we used to do it in.  That’s US experience, not necessarily the same in countries like India.

I don’t think push notification would work particularly well, but it’s possible as long as the notification expired reasonably promptly.  I think OCSP is the right model.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Jul 2014 20:32:25 +0000

Unless you query for every STIR validation, I don't see how OCSP can work with porting. If you don't query for each validation, there's a non-trivial chance that the number being validated has been ported and thus validation will fail (since it will be signed by the new carrier). I guess you could do a "try first and then invoke OSCP to see if there's been a port", but that all seems more complicated.

I'm not sure why push wouldn't work - high-volume validators would get the cert-affecting ports (which should be the 2% a year, i.e., 160M or so a year or roughly 500k a day). They'd likely retrieve the cert anyway at some point, so there's little wasted bandwidth. I'm assuming that major carriers will cache certs internally, whether by SBC or for their whole network, to reduce latency and avoid any dependency on external systems or networks. There's no real protocol work needed - the "pusher" (NPAC or similar)  would just open an HTTPS connection to a designated location and stream the certs across that connection.

The efficiency trade-off depends a bit on the certificate validity duration. I'm guessing that it will be similar to the typical web cert one, i.e., a year or so.

I'm aiming for simple implementation, particularly between organizational entities, robustness and low latency. One can always add optimization later.

From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, July 29, 2014 4:16 PM
To: Henning Schulzrinne
Cc: Richard Shockey; [email-masked]
Subject: Re: [stir] Ranges or individual numbers

If we allowed ranges, I would NOT invalidate a cert when a number ported out (or back in) to a range.  I would have an OCSP-like query that was queried with cert and TN and responded with valid-for-that-TN or not.  Since CRLs don't work, you need something like OCSP.  Since you are querying for validity, extending to say "valid for this TN" is a small change.

Numbers in use are growing, but somewhat slower than before.  Some of the growth is in devices that are not phones, but they would need certs.  Inventory changes all the time, especially since we hand out numbers in blocks of 1000, rather than the 10K we used to do it in.  That's US experience, not necessarily the same in countries like India.

I don't think push notification would work particularly well, but it's possible as long as the notification expired reasonably promptly.  I think OCSP is the right model.

---

From: Patrick Tarpey <[email-masked]>
Date: Tue, 29 Jul 2014 20:44:31 +0000

Hi all,

Is this a regulatory matter that impinges upon design/deployment or a usability question that impact performance/usability?

Pat

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, July 29, 2014 09:32 PM
To: 'Brian Rosen' <[email-masked]>
Cc: [email-masked] <[email-masked]>; Richard Shockey <[email-masked]>
Subject: Re: [stir] Ranges or individual numbers

Unless you query for every STIR validation, I don’t see how OCSP can work with porting. If you don’t query for each validation, there’s a non-trivial chance that the number being validated has been ported and thus validation will fail (since it will be signed by the new carrier). I guess you could do a “try first and then invoke OSCP to see if there’s been a port�, but that all seems more complicated.

I’m not sure why push wouldn’t work – high-volume validators would get the cert-affecting ports (which should be the 2% a year, i.e., 160M or so a year or roughly 500k a day). They’d likely retrieve the cert anyway at some point, so there’s little wasted bandwidth. I’m assuming that major carriers will cache certs internally, whether by SBC or for their whole network, to reduce latency and avoid any dependency on external systems or networks. There’s no real protocol work needed – the “pusher� (NPAC or similar)  would just open an HTTPS connection to a designated location and stream the certs across that connection.

The efficiency trade-off depends a bit on the certificate validity duration. I’m guessing that it will be similar to the typical web cert one, i.e., a year or so.

I’m aiming for simple implementation, particularly between organizational entities, robustness and low latency. One can always add optimization later.

If we allowed ranges, I would NOT invalidate a cert when a number ported out (or back in) to a range.  I would have an OCSP-like query that was queried with cert and TN and responded with valid-for-that-TN or not.  Since CRLs don’t work, you need something like OCSP.  Since you are querying for validity, extending to say “valid for this TN� is a small change.

________________________________

******************************************************************************************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use of the addressee only.

If you have received this email in error please notify the originator of the message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments at your own risk.

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Jul 2014 16:45:26 -0400

You typically query OCSP every time you validate.   Since we’re not trying to catch edge cases, you can avoid OCSP query if you’ve done it recently. 

I do expect that in some cases we’ll have to maintain a synced copy of the database inside a carrier.  We do that for NPAC, and it could work for this use.  If that’s what you mean by “push” okay.
There is a protocol associated with that, but it’s pretty easy, not as easy as you are suggesting, but not a lot harder.   Basically, you keep a transaction ID that has a known sequence.  You supply a transaction ID on the query, and you get back all the updates since then, and a new transaction ID to use on the next query.  There is an initialization process for a new or replaced copy that basically downloads a snapshot and the transaction ID of the snapshot.  Pretty trivial, not even sure its worth standardizing.  It’s how the U.S. White Space DB admins do the same thing.

Doing both allows anyone to not have to maintain the synced copy, but allows them to if they wanted to.  Note that you still do a query per validation, with a small cache for recently queried results, it’s just where the database you are querying is located that changes.

Brian

On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <[email-masked]> wrote:

> Unless you query for every STIR validation, I don’t see how OCSP can work with porting. If you don’t query for each validation, there’s a non-trivial chance that the number being validated has been ported and thus validation will fail (since it will be signed by the new carrier). I guess you could do a “try first and then invoke OSCP to see if there’s been a port”, but that all seems more complicated.
>  
> I’m not sure why push wouldn’t work – high-volume validators would get the cert-affecting ports (which should be the 2% a year, i.e., 160M or so a year or roughly 500k a day). They’d likely retrieve the cert anyway at some point, so there’s little wasted bandwidth. I’m assuming that major carriers will cache certs internally, whether by SBC or for their whole network, to reduce latency and avoid any dependency on external systems or networks. There’s no real protocol work needed – the “pusher” (NPAC or similar)  would just open an HTTPS connection to a designated location and stream the certs across that connection.
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Jul 2014 16:46:12 -0400

I think this is usability mostly.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Jul 2014 20:49:06 +0000

I don’t see this as a regulatory matter – from what I can tell, either the “one number” or “blocks” could work in any conceivable environment, as long as blocks are not restricted to (say) 1k blocks or prefixes.

This is more of an optimization issue, i.e., who needs to do what for each validation and how do system elements need to scale. For example, existing OCSP systems (at least according to Wikipedia…) return validity periods of multiple days and do not get queried for each TLS interaction.

From: Patrick Tarpey [mailto:[email-masked]]
Sent: Tuesday, July 29, 2014 4:45 PM
To: Henning Schulzrinne; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: Re: [stir] Ranges or individual numbers

Hi all,

Pat

From: Henning Schulzrinne [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, July 29, 2014 09:32 PM
To: 'Brian Rosen' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Richard Shockey <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Ranges or individual numbers

From: Brian Rosen [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, July 29, 2014 4:16 PM
To: Henning Schulzrinne
Cc: Richard Shockey; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Ranges or individual numbers

******************************************************************************************************************
For more information visit www.ofcom.org.uk<http://www.ofcom.org.uk>

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 29 Jul 2014 22:49:57 +0200

Guess, this is not a problem if the cert is bound to the phone number - the Identity - and not to the operator who is handling it at a given time.

This would require:
- that the CA with its OCSP servers is a neutral 3rd party.
- that operators in possession of private keys for signing use a common certificate and keys for all numbers. e.g. domain based.
- that individuals can use their phone number certificate for any relying party including their current carrier.

Number allocation databases for this case may publish references to the CA / CRL- / OCSP- servers. This references can point to individual number certs or to authorised operator certs if multiple numbers need to be signed.
For porting The reference-plane database authority can change the reference to a new Operator Trust authority in case the operator signs or do nothing if the uses certificate is continued to be used.

On load and network traffic:
- Not an issue for administration.
- On real time traffic: Not an issue since we do not need qualified signature handling and thus relying parties can cache queries for at least one day.

Willi

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 29 Jul 2014 22:55:11 +0200

No, this is only required for qualified signatures.

and all (most) current implementations support caching.

OCSP servers can be replicated and have little transport overhead.

On a tyny server we can serve thousand OCSP queries a second easily on a 100Mb link.

So this should not be fightening.

Willi

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Jul 2014 16:58:27 -0400

On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen <[email-masked]> wrote:

> You typically query OCSP every time you validate.   Since we’re not trying
> to catch edge cases, you can avoid OCSP query if you’ve done it recently.
>

This is more of a "webby" point of view.  The RPKI has gone a different
route, distributing CRLs through their repository system.

At a high level, those are basically your options.  Either you do OCSP when
you validate, or you fetch CRLs periodically.  If you do CRLs, then you
have to do fewer queries, but the speed with which you can revoke a
certificate is bounded by how often relying parties poll for CRLs (~daily
in the RPKI).  If you do OCSP, you can revoke certificates very quickly,
but you're more exposed to the vicissitudes of the network.  For example,
browsers can't fail a connection on OCSP failure because network failures
are common.

Note also that this discussion is only half of the portability discussion
-- only the revocation half.  You can grant new authorization to use
numbers as quickly as you can mint and hand out the certificates.
Revocation only affects your ability to remove authorization.

--Richard

> I do expect that in some cases we’ll have to maintain a synced copy of the
> database inside a carrier.  We do that for NPAC, and it could work for this
> use.  If that’s what you mean by “push” okay.
> There is a protocol associated with that, but it’s pretty easy, not as
> easy as you are suggesting, but not a lot harder.   Basically, you keep a
> transaction ID that has a known sequence.  You supply a transaction ID on
> the query, and you get back all the updates since then, and a new
> transaction ID to use on the next query.  There is an initialization
> process for a new or replaced copy that basically downloads a snapshot and
> the transaction ID of the snapshot.  Pretty trivial, not even sure its
> worth standardizing.  It’s how the U.S. White Space DB admins do the same
> thing.
>
> Doing both allows anyone to not have to maintain the synced copy, but
> allows them to if they wanted to.  Note that you still do a query per
> validation, with a small cache for recently queried results, it’s just
> where the database you are querying is located that changes.
>
> Brian
>
>
> Unless you query for every STIR validation, I don’t see how OCSP can work
> with porting. If you don’t query for each validation, there’s a non-trivial
> chance that the number being validated has been ported and thus validation
> will fail (since it will be signed by the new carrier). I guess you could
> do a “try first and then invoke OSCP to see if there’s been a port”, but
> that all seems more complicated.
>
> I’m not sure why push wouldn’t work – high-volume validators would get the
> cert-affecting ports (which should be the 2% a year, i.e., 160M or so a
> year or roughly 500k a day). They’d likely retrieve the cert anyway at some
> point, so there’s little wasted bandwidth. I’m assuming that major carriers
> will cache certs internally, whether by SBC or for their whole network, to
> reduce latency and avoid any dependency on external systems or networks.
> There’s no real protocol work needed – the “pusher” (NPAC or similar)
>  would just open an HTTPS connection to a designated location and stream
> the certs across that connection.
>
> The efficiency trade-off depends a bit on the certificate validity
> duration. I’m guessing that it will be similar to the typical web cert one,
> i.e., a year or so.
>
> I’m aiming for simple implementation, particularly between organizational
> entities, robustness and low latency. One can always add optimization later.
>
> *From:* Brian Rosen [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, July 29, 2014 4:16 PM
> *To:* Henning Schulzrinne
> *Cc:* Richard Shockey; [email-masked]
> *Subject:* Re: [stir] Ranges or individual numbers
>
> If we allowed ranges, I would NOT invalidate a cert when a number ported
> out (or back in) to a range.  I would have an OCSP-like query that was
> queried with cert and TN and responded with valid-for-that-TN or not.
>  Since CRLs don’t work, you need something like OCSP.  Since you are
> querying for validity, extending to say “valid for this TN” is a small
> change.
>
> Numbers in use are growing, but somewhat slower than before.  Some of the
> growth is in devices that are not phones, but they would need certs.
>  Inventory changes all the time, especially since we hand out numbers in
> blocks of 1000, rather than the 10K we used to do it in.  That’s US
> experience, not necessarily the same in countries like India.
>
> I don’t think push notification would work particularly well, but it’s
> possible as long as the notification expired reasonably promptly.  I think
> OCSP is the right model.
>
>
>

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 29 Jul 2014 23:03:23 +0200

This is a very important statement considering the current efforts to re-engineer number administration which could be a good starting point to introduce trust references for trusted Caller-IDs.

Just think about trust references instead of current number port information and any domain/operator accepting this trust relations can validate and authorise. ;-)
… OK, this is very far away. …

Willi

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Jul 2014 17:04:17 -0400

The number of revocations is way too large to consider a CRL.

Agree that we’re creating certs more often than we are “revoking" them. Quotes because I don’t want to actually revoke a cert on a range that has a number ported out of it.  It’s all the same operation, just one more value in the query.

Brian

On Jul 29, 2014, at 4:58 PM, Richard Barnes <[email-masked]> wrote:

> This is more of a "webby" point of view.  The RPKI has gone a different route, distributing CRLs through their repository system.
> 
> At a high level, those are basically your options.  Either you do OCSP when you validate, or you fetch CRLs periodically.  If you do CRLs, then you have to do fewer queries, but the speed with which you can revoke a certificate is bounded by how often relying parties poll for CRLs (~daily in the RPKI).  If you do OCSP, you can revoke certificates very quickly, but you're more exposed to the vicissitudes of the network.  For example, browsers can't fail a connection on OCSP failure because network failures are common.
> 
> Note also that this discussion is only half of the portability discussion -- only the revocation half.  You can grant new authorization to use numbers as quickly as you can mint and hand out the certificates.  Revocation only affects your ability to remove authorization.
> 
> --Richard
>

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 29 Jul 2014 23:08:49 +0200

This is a very important and overlooked point Richard.
Removal of authorisation has nothing to do with Revocation of certificates!

In fact, my Phone number identity can still be used for Emails, Web and PBX login but might not be accepted by my previous operator as an originating identity.

Thanks for this pointer!

Willi

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Jul 2014 17:18:50 -0400

As Richard noted, the RPKI uses CRLs instead of OCSP. We made that 
design choice because,
in that environment, every RP needs to be able to validate every cert. 
In the STIR context
it may be the case that not every RP needs to validate every cert, but 
if many RPs neefd
to validate most/many certs, CRLs are still a good idea. When I hear 
mention of downloading
500K certs a day, it strikes me that downloading CRLs is well within 
reason, at least as a primary
revocation mechanism.

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 29 Jul 2014 21:20:49 +0000

I wouldn't rule out a CRL under certain operational conditions. But it does hugely depend on how we structure the relationship between the certificates and the number(s) for which they are valid.

I've been assuming we will support ranges in certs, but that for that subset of certs the binding would be relatively loose. What do I mean by that? That for certs that are authoritative for a large set of numbers, there would be some layer of indirection between the cert and the number range, so that we didn't need to invalidate the cert every time a single number ported out of the range. There are validation strategies for this that can work, with either a pull model (where I query to validate whenever I am verifying a STIR-signed called, say) or a push model (where I subscribe to some kind of service that notifies me of changes to the ranges of certs so I have the information before I validate). I can imagine adapting CRLs to something that looks like the latter quality - especially for verifiers that sit in the network handling large numbers of calls.

There are a number of ways to design to this property. We need to make sure we choose something practical. From a STIR workflow perspective, I'd say we should focus on efforts for now on getting rfc4474bis solid as that is our chartered order of operations, but definitively we need to get on the right path to identifying the high level architecture and qualities we want for certs.

Jon Peterson
Neustar, Inc.

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 29, 2014 at 2:04 PM
To: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Richard Shockey <[email-masked]<mailto:[email-masked]>>, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Ranges or individual numbers

Brian

On Jul 29, 2014, at 4:58 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
You typically query OCSP every time you validate.   Since we’re not trying to catch edge cases, you can avoid OCSP query if you’ve done it recently.

--Richard

Brian

On Jul 29, 2014, at 4:32 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Jul 2014 17:40:29 -0400

I’m agreeing on how you represent the TNs in a cert when the cert has a lot of TNs associated with it.  That piece of information is part of validity, so if we have either CRLs or OCSP, we need that extra information at the time of validation.  

Also agree on priorities, but I’m fairly happy with where 4474bis is.  We made a major decision last week (and seemingly confirmed this week) that gets us a lot closer to understanding how credentials are represented.  I’m optimistic we can converge pretty rapidly on this subject.  

I sense we have a level of consensus on validation - you check a CRL-like thing or an OCSP-like thing when you validate, but you have some kind of cache for frequently occurring validations.  If someone doesn’t agree, please explain.

Without getting in to CRL vs OCSP, we agree that there is some way that the changes in cert validity get propagated for this check.

So, I would be interested in seeing if we can just concentrate on allowing ranges or limit to one-cert-per-TN.
Is there a real problem with ranges?  I agree there is simplicity of cert-per-TN, but I do think service providers would prefer to manage fewer than that many keys, and the complications are not very significant.

I think we all understand that either way, there can be more than one cert for any given TN because some delegations work that way - you authorize someone to use the TN, but don’t relinquish your right to sign for calls from that TN.

Brian

On Jul 29, 2014, at 5:20 PM, Peterson, Jon <[email-masked]> wrote:

> From: Brian Rosen <[email-masked]>
> To: Richard Barnes <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Richard Shockey <[email-masked]>, Henning Schulzrinne <[email-masked]>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Jul 2014 21:57:36 +0000

It might help to walk through the complete operation when a call arrives to make sure we're on the same flow chart. My mental picture would be:

1.       Call arrives with a 4474bis URL pointing to the cert. SBC checks if URL is in local cache; if not, SBC retrieves cert. Depending on the range/individual decision, this cert gets populated into a database/lookup table that has a per-number entry. (Any indexing database won't work on ranges, just precise matches, whether SQL  or noSQL.)

2.       Next, the SBC issues an OCSP query or checks the local CRL copy. The check would be against the NPAC, not the entity that hosted the cert in step #1. It is left to decide whether the OCSP query result is cached for some time period (days). The OCSP query is for a specific number. If the query is done for every call, the OCSP servers have to essentially be in the loop for every phone call, possibly several times (if validation is done in multiple locations).

Is that the model that others are thinking about?

It would be helpful to know whether the number of private keys depends on the range issues, i.e., would every cert have a different signing private key. I don't think so, but don't know for sure.

In the long run, the accumulated effect of porting will create smaller and smaller contiguous blocks (unless companies merge their way back to MaBell and PaCable).

From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, July 29, 2014 5:40 PM
To: Jon Peterson
Cc: Richard Barnes; [email-masked]; Richard Shockey; Henning Schulzrinne
Subject: Re: [stir] Ranges or individual numbers

I'm agreeing on how you represent the TNs in a cert when the cert has a lot of TNs associated with it.  That piece of information is part of validity, so if we have either CRLs or OCSP, we need that extra information at the time of validation.

Also agree on priorities, but I'm fairly happy with where 4474bis is.  We made a major decision last week (and seemingly confirmed this week) that gets us a lot closer to understanding how credentials are represented.  I'm optimistic we can converge pretty rapidly on this subject.

I sense we have a level of consensus on validation - you check a CRL-like thing or an OCSP-like thing when you validate, but you have some kind of cache for frequently occurring validations.  If someone doesn't agree, please explain.

I think we all understand that either way, there can be more than one cert for any given TN because some delegations work that way - you authorize someone to use the TN, but don't relinquish your right to sign for calls from that TN.

Brian

On Jul 29, 2014, at 5:20 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

Jon Peterson
Neustar, Inc.

Agree that we're creating certs more often than we are "revoking" them. Quotes because I don't want to actually revoke a cert on a range that has a number ported out of it.  It's all the same operation, just one more value in the query.

Brian

On Tue, Jul 29, 2014 at 4:45 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
You typically query OCSP every time you validate.   Since we're not trying to catch edge cases, you can avoid OCSP query if you've done it recently.

I do expect that in some cases we'll have to maintain a synced copy of the database inside a carrier.  We do that for NPAC, and it could work for this use.  If that's what you mean by "push" okay.
There is a protocol associated with that, but it's pretty easy, not as easy as you are suggesting, but not a lot harder.   Basically, you keep a transaction ID that has a known sequence.  You supply a transaction ID on the query, and you get back all the updates since then, and a new transaction ID to use on the next query.  There is an initialization process for a new or replaced copy that basically downloads a snapshot and the transaction ID of the snapshot.  Pretty trivial, not even sure its worth standardizing.  It's how the U.S. White Space DB admins do the same thing.

Doing both allows anyone to not have to maintain the synced copy, but allows them to if they wanted to.  Note that you still do a query per validation, with a small cache for recently queried results, it's just where the database you are querying is located that changes.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Jul 2014 18:10:34 -0400

On Jul 29, 2014, at 5:57 PM, Henning Schulzrinne <[email-masked]> wrote:

> It might help to walk through the complete operation when a call arrives to make sure we’re on the same flow chart. My mental picture would be:
>  
> 1.       Call arrives with a 4474bis URL pointing to the cert. SBC checks if URL is in local cache; if not, SBC retrieves cert. Depending on the range/individual decision, this cert gets populated into a database/lookup table that has a per-number entry. (Any indexing database won’t work on ranges, just precise matches, whether SQL  or noSQL.)
Yes

> 2.       Next, the SBC issues an OCSP query or checks the local CRL copy. The check would be against the NPAC, not the entity that hosted the cert in step #1. It is left to decide whether the OCSP…
No.  The NPAC may have the certificated carrier port information, but does not know about delegations that may have changed beyond that point.  You have to query the database that issues the certs, although you may have a pushed copy of that database to query.  You can cache the query for some time (hours, maybe a day).  The cert DB has to track the porting DB, but it has information on delegations the porting DB doesn’t.  

As an easy example, consider the “American Express delegates Call Center Enterprises, Inc to make calls using it’s front door number”.  Then it wants to revoke that delegation, and create a new one for “Cheepie Call Center Corp”.  The port DB doesn’t change.  The Call Center Enterprise and Cheepie Call Center Corp’s certs change, Amex and the carrier that provided the TN to Amex don’t change.

> It would be helpful to know whether the number of private keys depends on the range issues, i.e., would every cert have a different signing private key. I don’t think so, but don’t know for sure.
This was raised before.  While I don’t think that we will prohibit a holder of multiple certs from reusing private keys, I don’t think that is a good idea.
I’m not even sure it works well.  Someone with more math will have to tell me how much it “costs” to create a tens of millions of public keys from the same private key (not all at once).

> In the long run, the accumulated effect of porting will create smaller and smaller contiguous blocks (unless companies merge their way back to MaBell and PaCable).
The idea I have is that it doesn’t matter a whit how many blocks there are.  You can attach any number of TNs to any credential and the mapping can change without revoking (in the classic sense) the cert, or changing the private or public key.  Since we have a per-country DB, which everyone trusts, it can maintain the mapping of TN to certs without any real complications, and can provide both query and a sync service with that data, along with the public keys themselves.

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Wed, 30 Jul 2014 08:03:59 +0200

> No.  The NPAC may have the certificated carrier port information, but does not know about delegations that may have changed beyond that point.  You have to query the database that issues the certs,…

For simplicity reasons, the carrier port information might disappear from NPAC databases in future. This will allow to store certificate and domain references only.
PKI even allows to do multiple signing of digests for delegation and forwarding cases.

So if the signed call arrives (1.), we can validate the signature and certificate regardless of the operator running this number.

And as mentioned in (2.) caching is a good practice for signatures one has accepted for authorisation. This also has the advantage that cached certificates & of course their signatures can be easily excluded from authorisation without revoking the certificate itself.
It is not necessary and even bad practice to revoke the certificate since the identity owner can still re-use it with the same phone-number for different operators & service providers.

> As an easy example, consider the “American Express delegates Call Center Enterprises, Inc to make calls using it’s front door number”.  Then it wants to revoke that delegation, and create a new one…
This PBX sample has quite a few different and valid solutions for a PKI reliant system.
 a) Just sign with cert of new “Cheepie Call Center Corp”  
     needs mapping numbers to certs
 b) Sign with both, “AMEX and Cheepie” 
     quite some overhead signing digests twice)
 c) Install a "AMEX” cert and private-keys at “Cheepie” 
     might be a good solution since AMEX can revoke authorisation and it is good for branding.
...

> I’m not even sure it works well.  Someone with more math will have to tell me how much it “costs” to create a tens of millions of public keys from the same private key (not all at once).

It is very bad practice to re-use private keys for multiple PKI certificates.
… it will render all certs with the same key if the key is compromised.

Generating millions of keys just takes a short time. On weak computers may be two Hours. So this shall not be a reason. 
More important is that private keys shall only be known to the signing identity-owner or to the party / operator who signs document/phone number  on behalf of the identity owner.

> The idea I have is that it doesn’t matter a whit how many blocks there are.  You can attach any number of TNs to any credential and the mapping can change without revoking (in the classic sense) th…

Good point:
This mapping can be a reference-plane managed in each country and and added to NPACK, ENUM databases or that like.

This then will not nail any certificate to operators. instead it will map certificates to the phone-number as the real identity.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2014 11:05:34 -0400

Wilhelm,
>
> ...
> For simplicity reasons, the carrier port information might disappear 
> from NPAC databases in future. This will allow to store certificate 
> and domain references only.
what do you mean by the phrase above? X.509 certs contain exactly one 
signature.

Steve

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Wed, 30 Jul 2014 17:27:34 +0200

Sorry for being unclear and not placing a sample.

The phrase in general is a bit weak. ;-)

a.) Port information might disappear from NPAC databases. 
There I have the vision that NPAC databases get a single number granularity and become a Reference-Plane
with references CA’s with certificates allowed to sign for a given telephone number. this is the address where one can fetch certs, CRLs or do OCSP queries.

This will simplify enrolment and disconnect operator authorisation from phone number identities.

b.) multiple signatures.
I ment on the document / digest and not in the certificate.

A document / digest can be signed with multiple signatures belonging to different certs.

As such, the problem of call-forwarding raised in previous messages could be resolved and all signatures can be validated by relying parties.
e.g.
1. signature by originating user, 
2. signature by forwarder.
3. … other forwarders or modifiers

We use it for 
- documents signed by staff, boss(es) and the notary public for example.
- machines to authenticate and sign completion of operation in a sequence

Hope this helps

Willi

On 30 Jul 2014, at 17:05, Stephen Kent <[email-masked]> wrote:

> what do you mean by the phrase above? X.509 certs contain exactly one signature.
> 
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2014 11:40:44 -0400

Willi,

Thanks for the clarification.

If a doc is signed by multiple entities the semantics of the doc
may become more complex, e.g., with regard to authorization and
revocation. So, it will be necessary to be very careful and provide
a thorough description of the validation process in such circumstances.

Steve

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Wed, 30 Jul 2014 18:18:26 +0200

Basically this is not a problem because the digest remains the sam a and the signatures are just appended one after the other.

Each signature just signs the hash of the original digest and appends the signature at the end.

Most validation libraries can handle this.

Willi

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2014 12:36:27 -0400

Willi,

I was not worried about the ability of software to validate the sigs.
I was worried about the semantics of the multiple sigs. In some contexts
the order of signing is meaningful, in others not. In some contexts all
sigs must be valid (crypto correct, cert not revoked, cert not expired, 
etc.),
while in other contexts an RP might care about some sigs and ignore 
others, etc.

Steve