[stir] Questions about stir-certificates

[Martin Thomson <[e-mail]>]

In looking at the drafts in ACME, a few questions came up about the
structure of the certificate. The current draft describes a single
non-critical extension that includes a mix of service provider codes
and telephone numbers (both single and ranges).

For the ACME drafts, it seems like we have two basic models in mind here:

1. A service provider gains a certificate that is allocated to their
code.  As I understand it, SHAKEN assumes that this will not be
further constrained by telephone numbers, but the basic model allows
for this to also list a set of numbers for which the service provider
can speak.  The certification authority is presumably also similarly
constrained, but that might be addressed with provisioning.  This is
the acme-service-provider draft.

2. An individual gains a certificate for a single telephone number.
This is the acme-telephone draft.

If I guess the rationale correctly, the reason that telephone numbers
don't use an otherName in subjectAltName is that SAN doesn't allow for
progressive restriction down the certification path.  A certification
authority can't issue a name^Wnumber-constrained subordinate using
subjectAltName.  The new field allows for two different meanings: that
the certificate holder can speak for the telephone numbers that are
included, and that a certification authority can issue a certificate
for those telephone numbers.

The first question is whether this delegation makes any sense for
service provider codes.  A service provider that signs a subordinate
(such as an enterprise that operates a PBX) is hardly going to allow
that subordinate to use their service provider code.  In light of
that, it seems like subjectAltName is entirely appropriate place to
put a service provider code.

Right now, the rules for subordinates are somewhat arbitrary: they
apply to numbers, but not service provider codes, yet the two are
bundled in the same extension.

I really don't think that it's a great design choice to bundle service
provider codes with telephone numbers as TNAuthList does currently.
It seems arbitrary.  I'll concede that this might seem partly an
aesthetic objection, but the two are entirely different things with
different rules.  Given that the authority to sign for a telephone
number is most often a consequence of being a particular service
provider (and having a valid code) rather than a direct and
independent authority.

Even if they are retained as a single structure, mixing the two is
unnecessary.  It would be easier to process if this were structured
with the two separate so that consumers can ignore the branch they
don't care about, e.g.:

    TNAuthList ::= SEQUENCE {
     spc ServiceProviderCode (1..MAX) OPTIONAL,
     tnSet TNEntry (1..MAX) OPTIONAL
    }

    TNEntry ::= CHOICE {
      range [0] TelephoneNumberRange,
      one   [1] TelephoneNumber
      }

It's also unclear to me whether a certificate that includes AIA for
telephone numbers also effectively constrains subordinates to comply
with that set.  The document doesn't say.  On the assumption that it
does, what happens when the resource identified in the AIA changes?
There's a possibility that changes in the referenced resource could
invalidate subordinates.  Doesn't this put AIA on the critical path?

(Nit: please cite RFC 7230 or RFC 2818 for HTTPS when talking about AIA.)

The draft is unclear on how uniqueness is managed for service provider
codes, or even if uniqueness is a requirement.  Is this a property of
the certification path in that a trust anchor will be connected to a
particular country prefix (or set thereof), or is there something more
concrete?

Other questions:

How does one add `count` to a number containing "*" or "#"?
Does the addition of `count` treat the `start` as an integer?
What does a `count` of 0 mean?

How do I express that all numbers in the +1 prefix are covered?
Assuming ignorance of the NANP, do I need to list "10"+10, "100"+100",
"1000"+1000 and every length up to the full 15 digit E.164 number
separately?  (The NANP is perhaps a bad example, try finding solid
information on the numbering plan for +257).  Did the working group
consider a number prefix in addition to the range, to allow for saying
"+1..." as a single rule?  I know many places that this would be
sufficient, even though I know that prefixes are - in general - not
sufficient.

Why does JWTClaimName use IA5String rather than UTF8String?  If you
need constraints on valid characters, prose is a better choice.  RFC
7519 permits any Unicode string by not constraining the format of the
name.