Subject: [pkix] claimSigning EKU draft for PKIX WG Consideration

From: Matt King <[email-masked]>
Date: Fri, 22 Apr 2011 13:51:24 -0400

Dear PKIX Working Group

I have posted an draft document describing a claimSigning EKU.  It is
titled “draft-king-pkix-claimsigning-extn-00.txt” (abstract below) and
it can be found at the following link for your review:

http://datatracker.ietf.org/doc/draft-king-pkix-claimsigning-extn/?include_text=1

I ask that the attached draft be considered as a new work item for
this group.  Thank you in advance for your time.

Abstract

   This memo specifies an Extended Key Usage (EKU) X.509 certificate
   extension which indicates that the certificate holder is authorized
   to sign security tokens to assert claims, or attributes, about a
   principal.

   When an owner of a certificate that asserts the claimSigning EKU
   signs a claim, the owner is asserting that a statement about the
   principal is true. For example, a IdP secure token service (STS)
   would use an X.509 certificate containing the claimSigning EKU to
   sign SAML assertions containing an identifier and attributes about a
   user.

-- 
Matt King
Protiviti
Government Services
[email-masked]
[email-masked]
410-271-5624 (Mobile)

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 23 Apr 2011 01:31:26 +0200

Matt,

Thanks for binging this proposal to PKIX.

First thing that strikes me is that we seem to have two competing
proposals on the table. This one and
draft-patterson-pkix-attribute-signing-eku.
Is this a coincidence or are the authors aware of each other and has
intentionally put forth different proposals?

This draft seems to have more description of the use case and also involve
the use for signing metadata records which is interesting.

The OID declaration in section 3 seems to have corrupted line wrapping.
Looks like you used NroffEdit and forgot to include the .nf directive :)

Try replacing with the following:
.in 8
.nf
id-kp  OBJECT IDENTIFIER  ::=
   { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) 3 }

id-kp-claimSigning  OBJECT IDENTIFIER  ::=  { id-kp TBD }
.fi
.in 3

The document is missing an ASN.1 section, but I guess you can add that
later.

Section 4 is problematic from a standardization scope perspective. A
standard cannot mandate matters that is outside of it's scope (or
jurisdiction).
If this standard would define a claims signing protocol, then it would be
within the scope of such standard to say what EKU values that such
protocol mandates.

However, this draft does not defines such a protocol. It only defines an
EKU value.
It is not reasonable for this standard to dictate behavior of
implementations that does not implement this standard.
Thus, you can't dictate that implementations MUT NOT accept a cert for any
purpose if it does not contain the EKU you define.
Likewise you can't force implementations to accept a cert if it DOES
contain your EKU.
All you can say is what statement this EKU provides. Unless you want to go
further, you need to place such requirements in the protocol using the EKU.

Finally, the use of this EKU for signing metadata provides an interesting
use case as it could be done with a cert provided from a general purpose
PKI. However isn't that a bit of a stretched semantics to denote that as
claims signing?
Given that there are no claims in the metadata.

/Stefan

On 11-04-22 7:51 PM, "Matt King" <[email-masked]> wrote:

>titled ³draft-king-pkix-claimsigning-extn-00.txt² (abstract below) and
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Matt King <[email-masked]>
Date: Mon, 25 Apr 2011 22:20:03 -0400

Hi Stefan

Thanks for your comments.  To address some of your concerns:

1. We were not aware of the competing proposal and will analyze it to
understand and proved more information about the differences
2. We will fix the wrapping issue and missing ASN.1 section
3. We will evaluate the feasibility and pracicality of defining a
claimSigning protocol
4. I'll need to consult with my team about your metadata signing
comment, but I do believe that someone who signs metadata is making a
claim that the contents of the metadata are true.  While you could
execute this operation with a general purpose PKI, it would have more
meaning if the metadata is signed with keys associated with a cert
asserting a claimSigning EKU.

I'll be out of town this week due to a death in my family, but I will
look forward to continued discussion of our proposal and provide
additional responses to your comments upon my return.  Thank you again
for considering our proposal.

Matt
-- 
Matt King
Protiviti Inc.
Government Services

-- 
Matt King
[email-masked]
410-271-5624 (Mobile)

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Apr 2011 09:38:26 +0200

Matt,

In-line.

>3. We will evaluate the feasibility and pracicality of defining a

That is not what I was suggesting. But if you feel that is desired then
that should probably be a matter for another work group. My point is that
different type of standards can put different requirements on EKU
processing. A standard just defining EKU can for example not put
requirements on clients not implementing the standard. So you need in any
case clear up the requirements language of that section.

>asserting a claimSigning EKU.

Well, following your reasoning, all signing is claim signing. You can
always say that you claim something in the act of signing. The term
"Claims" however has been used lately in the industry in a much more
defined manner. I'd say it has been used as a substitution for the term
"Attribute" with a minor semantical twist that I never have understood,
but in any case very close to attributes. SAML works with attributes and
Information Cards with claims, even though they produce SAML assertions
with attributes (identical to the claims) in the end. In the end of the
day, the meta data catalog do not contain neither claims, nor attributes
of subjects. It contain metadata about identity providers, service
providers and attribute providers etc.

I think you need to clarify your use of the term claims in your document
to do what you suggest.

/Stefan