Subject: Re: [stir] Second WG Last Call for STIR Certificates Document

From: Russ Housley <[email-masked]>
Date: Mon, 3 Oct 2016 04:48:43 -0400

I have been thinking about this some more.  I have been uneasy about this use of policy qualifier, and I think that I have figured out the source of that concern.

The certificate is a signed structure.  It is signed by the CA, and the CA needs to be able to vouch for the information in it.  I’m not sure how the CA knows what level of assurance qualifier value is appropriate for a particular subject.

In the current documents, consider a PASSporT signer that is associated with two sets of caller numbers, where the signer can provide full assurance for the first set and partial assurance for the second set.  Then, this signer will need two certificates, one with id-loa-full and the other with id-loa-partial, then the signer must select the appropriate certificate based on the caller number.  Really, the CA is not adding any value here.

Perhaps it would be better to remove the level of assurance from the certificate altogether.

If we do that, the we would need to include the level of assurance in the signed PASSporT claims.  In this case, the signer would need to include either loa=full or loa=partial, depending on the caller number.

Either way, the signer is deciding what level of assurance to include.

What do others think?

Russ

On Sep 15, 2016, at 12:07 PM, Russ Housley <[email-masked]> wrote:

> I have found a place where additional clarity is needed in Section 5.1.  The current text is:
> 
> 5.1.  Levels Of Assurance
> 
>   This specification supports different level of assurance (LOA).  The
>   LOA indications, which are Object Identifiers (OIDs) included in the
>   certificate's certificate policies extension [RFC5280], allow CAs to
>   differentiate those enrolled from proof-of-possession versus
>   delegation.  A Certification Policy and a Certification Practice
>   Statement [RFC3647] are produced as part of the normal PKI
>   bootstrapping process (i.e., the CP is written first and then the CAs
>   say how they conform to the CP in the CPS).  OIDs are used to
>   reference the CP and if the CA wishes it can also include a reference
>   to the CPS with the certificate policies extension.  CAs that wish to
>   express different LOAs MUST include the certificate policies
>   extension in issued certificates.  See Section 11 for additional
>   information about the LOA registry.
> 
> This all makes sense to me, but it does not say whether the LOA is inferred from the CertPolicyId or explicitly carried in the PolicyQualifierInfo.  I think that the later is intended because of the reference to an LOA registry.  Please confirm that I got that right.
> 
> For background, RFC 5280 specifies the following ASN.1 for the PolicyQualifierInfo:
> 
>   PolicyQualifierInfo ::= SEQUENCE {
>        policyQualifierId  PolicyQualifierId,
>        qualifier          ANY DEFINED BY policyQualifierId }
> 
> So, I think we need to specify a single OID for the LOA policyQualifierId that is used in all certificates, and then have the qualifier carry an object identifier for the LOA.  Each certificate policy would list the LOA object identifiers that are supported.  If this is the intent, then the IANA considerations should ask for the assignment of the policyQualifierId object identifier.
> 
> That would result in something like this:
> 
>   id-qt-loa OBJECT IDENTIFIER ::= { id-qt TBD1 } 
> 
>   id-loa-full OBJECT IDENTIFIER ::= { TBD2 } 
>   id-loa-partial OBJECT IDENTIFIER ::= { TBD3 } 
>   id-loa-none OBJECT IDENTIFIER ::= { TBD4 }
> 
> Comments?
> 
> Russ
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 3 Oct 2016 14:36:19 +0000

I prefer loa in the claims.

Pierce

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: October 03, 2016 3:49 AM
To: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Second WG Last Call for STIR Certificates Document

The certificate is a signed structure.  It is signed by the CA, and the CA needs to be able to vouch for the information in it.  I'm not sure how the CA knows what level of assurance qualifier value is appropriate for a particular subject.

What do others think?

Russ

>   id-loa-none OBJECT IDENTIFIER ::= { TBD4 }

________________________________

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 3 Oct 2016 20:37:20 +0000

So, I definitely agree that it makes sense for an authentication service
to select a level of assurance on a per-call basis when it is signing for
requests coming from heterogenous points of origin, and that the AS
shouldn't have to hold multiple certificates with different LoAs to do
that. For that reason, I do see the value in specifying a JWT claim which
allows authentication services to characterize those different
originators. I don't think this is such a universally applicable feature
that we need that we need to spend another rev to get it into the baseline
PASSporT spec, but I can definitely see adding something like that as an
extension in the near future.

I'm not sure however that this JWT claim would entirely eliminate the need
for a level of assurance indication in the certificate or the
corresponding proposed registry. In some models, for example, a number
owner might delegate authority to a customer, and want to grant the
customer a credential they could use to sign requests with their own
authentication service. Moving LoA to PASSporT only works if we assume
that any certificate holder has the authority to assign LoAs - but in
delegation models, the LoA should be constrained by limited authority of
the cert. There are other use cases I can think of as well where having a
level of assurance in a cert could be meaningful.

But I don't think we need to specify how delegation in the cert would work
now: we just need to create the necessary registry in the certs document.
Given that we are late in the process here, I'd propose we just do that
and let the community do with it what they will. If people end up never
using this code point and registry in certs, we won't have gone to any
real trouble for it.

Jon Peterson
Neustar, Inc.

On 10/3/16, 4:48 AM, "stir on behalf of Russ Housley"
<[email-masked] on behalf of [email-masked]> wrote:

>I have been thinking about this some more.  I have been uneasy about this
>use of policy qualifier, and I think that I have figured out the source
>of that concern.
>
>The certificate is a signed structure.  It is signed by the CA, and the
>CA needs to be able to vouch for the information in it.  I¹m not sure how
>the CA knows what level of assurance qualifier value is appropriate for a
>particular subject.
>
>In the current documents, consider a PASSporT signer that is associated
>with two sets of caller numbers, where the signer can provide full
>assurance for the first set and partial assurance for the second set.
>Then, this signer will need two certificates, one with id-loa-full and
>the other with id-loa-partial, then the signer must select the
>appropriate certificate based on the caller number.  Really, the CA is
>not adding any value here.
>
>If we do that, the we would need to include the level of assurance in the
>signed PASSporT claims.  In this case, the signer would need to include
>either loa=full or loa=partial, depending on the caller number.
>
>> This all makes sense to me, but it does not say whether the LOA is
>>inferred from the CertPolicyId or explicitly carried in the
>>PolicyQualifierInfo.  I think that the later is intended because of the
>>reference to an LOA registry.  Please confirm that I got that right.
>> 
>> So, I think we need to specify a single OID for the LOA
>>policyQualifierId that is used in all certificates, and then have the
>>qualifier carry an object identifier for the LOA.  Each certificate
>>policy would list the LOA object identifiers that are supported.  If
>>this is the intent, then the IANA considerations should ask for the
>>assignment of the policyQualifierId object identifier.
>> 
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Wed, 5 Oct 2016 08:26:26 -0400

I agree, delegation does seem to be the right use case for this.

In SHAKEN framework, we, i think mistakenly, tried to use this policy indicator for attestation of how the call was originated. While i think we could have made it work, i think the main problem was that the attestation is a per call decision and choosing between different certificates to sign just didn’t feel right once we started mapping it out.

Rather we are going to make the attestation a claim as part of a passport extension.  A per call attestation indicator signed in the token. 

So i think the concern Russ is expressing I can see and we have experienced first hand, but i also agree with Jon that there is probably scenarios where a delegated customer might be signing all calls with a policy indicator that says, “we have delegated the authority to sign calls, so validate the calling identity in that context” so keeping it around is probably ok.

-Chris

> On Oct 3, 2016, at 4:37 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Russ Housley <[email-masked]>
Date: Wed, 5 Oct 2016 08:40:43 -0400

Chris:

When that delegation occurs, it is done by issuing a certificate.  That certificate may need to contain constraints on the passport claim.  That feels like a much better fit.

Russ

---

From: Chris Wendt <[email-masked]>
Date: Wed, 5 Oct 2016 08:42:30 -0400

Agree

> On Oct 5, 2016, at 8:40 AM, Russ Housley <[email-masked]> wrote:
> 
> Chris:
> 
> On Oct 5, 2016, at 8:26 AM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Oct 3, 2016, at 4:37 PM, Peterson, Jon <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>>> On Sep 15, 2016, at 12:07 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>>>>