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

From: Matt King <[email-masked]>
Date: Wed, 25 May 2011 15:36:44 -0400

Dear PKIX Working Group

I have posted an updated draft document describing the claimSigning EKU.  It is
titled “draft-king-pkix-claimsigning-extn-01.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

This revised draft replaces both the initial draft
"draft-king-pkix-claimsigning-extn-00.txt"
and "draft-patterson-pkix-attribute-signing-eku".  The authors of both
drafts have
collaborated and addressed all comments received to date and are
moving forward with this single submission.

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

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

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. This additional EKU value would further allow the
   differentiation of certificates used to identify a particular server
   from those used by the server to sign identity or attribute claims.

On Fri, Apr 22, 2011 at 1:51 PM, Matt King <[email-masked]> wrote:
> 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)
>

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

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 May 2011 01:21:44 +0200

Matt,

This draft carries a lot of the same problem as the last draft.

The requirements are all over the place and it is neither clear to me by
reading this draft what the context of these requirements are, what usages
that actually constitutes claim signing and how you would fulfill them.

For example. You SHOULD not escrow certificates? (I assume you mean the
private key). What is the context of such requirement and why would you
include such requirement.

Section 4 states that conformant implementations MUST implement the listed
steps which starts with that users SHOULD make use of the extension. So is
it a MUST or a SHOULD?

It is easy to see only the application you are dealing with, where your
context of using this may seem clear to you. But if others are to use the
same specification in their local context, are you sure that all
requirements you put up are reasonable to them? For example with respect
to key usage settings etc?

I personally don't like the word "claim signing". I don't see any standard
referenced that defines this term or give the context for it's use. I
think it is very important to add that context to the specification. I
would be more comfortable to relate it to the SAML protocol suite and the
need for signing of assertions (or what other purpose you are targeting
this for). 

Except that I don't want to dismiss this proposal. If correctly written
and scoped it might be useful.
Perhaps you van provide some use cases that makes it easier for us to
understand your proposal.

/Stefan

On 11-05-25 9:36 PM, "Matt King" <[email-masked]> wrote:

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

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 30 May 2011 10:04:02 +0200

> This draft carries a lot of the same problem as the last draft.
I haven' read te last version but:

We have already several texts which statements/assertions
about subjects and other things, e.g. OCSP, SCVP, DVCS
and to some degree also TSP. all define a specific
extended key usages.

the first three are services may be considered in the scope of
such a claimSigning thing. or is it intended that the signer
does not make an assertion? but just a claim?

the scope of this extension is very broad. it looks more
like "this is not a person" (but a server/service).

to a certain degree, some text looks like a best practice definition
for all kinds of certificates used by servers that provide attestations
assertions which not that different from CA signing devices?

the escrow remarks are not very motivated, I almost think
that they are questionable for the same practical reason
that one might want to escrow (backup) a CA key.

refereing to 'local practices' when the proposed value is not
present looks like ignoring other specifications.

the only exemple given is about an idp.

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 31 May 2011 14:17:20 +0200

I took a look at:  draft-king-pkix-claimsigning-extn-01

Section 5 states:
5.  Implications for a Certification Authority 
    The procedures and practices employed by a conformant CA MUST    ensure that the holder of the private key associated with the    public key in the Certificate is authorized to sign claims within    a particular community of interest before populating the    certificate with the id-kp-claimSigning EKU value
The key point is the fact that the CA will be aware of the "particular community of interest"
but not the relying parties. How then can relying parties know that the key owner is authorized 
to sign claims within this particular community of interest ?
   
By looking at the DN of the certificate ? 

The structure of the EKU is not really suited, since it is unable to carry additional information 
like the "particular community of interest".

Denis

---

From: Stephen Kent <[email-masked]>
Date: Tue, 31 May 2011 15:30:12 -0400

I concur with Stefan's assessment of this doc.

Steve