Subject: Re: [pkix] New draft for consideration as a work item.

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 1 Apr 2011 12:01:50 +0200

It is a good initiative and should be considered as a new work item for this group.

However, this draft is not going to be accepted with: 
4.  Security Considerations
     None.
The various SHOULD from section 3 should be explained in section 4.
Denis
----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2011-03-31, 17:06:35
Sujet : [pkix] New draft for consideration as a work item.

Hello all:

A new version of I-D, draft-patterson-pkix-attribute-signing-eku-00.txt has been successfully 
submitted by Patrick Patterson and posted to the IETF repository.

Filename: draft-patterson-pkix-attribute-signing-eku
Revision: 00
Title: attributeSigning extendedKeyUsage value
Creation_date: 2011-03-28
WG ID: Independent Submission
Number_of_pages: 8

Abstract:
This document specifies a value for the extendedKeyUsage X.509
extension that may be used to create a certificate that would be used
to sign attribute assertions. This allows the differentiation of
certificates used to identify a particular server (which would have a
serverAuth EKU), from the certificate used by that server to sign
attribute assertions, and would easily allow a policy to be developed
for issuance of such a certificate to an identity provider.

I would ask that the above be considered as a new work item for this group.

Thank you.

---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Tom Gindin <[email-masked]>
Date: Sat, 2 Apr 2011 11:08:54 -0400

Patrick:

        Is it called "attributeSigning" or "assertionSigning"?  The title 
says one, and section 3 says the other.  BTW, it looks reasonable to me.

                Tom Gindin

From:
Patrick Patterson <[email-masked]>
To:
pkix <[email-masked]>
Date:
03/31/2011 02:52 PM
Subject:
[pkix] New draft for consideration as a work item.
Sent by:
[email-masked]

Hello all:

A new version of I-D, draft-patterson-pkix-attribute-signing-eku-00.txt 
has been successfully submitted by Patrick Patterson and posted to the 
IETF repository.

Abstract:

I would ask that the above be considered as a new work item for this 
group.

Thank you.

---
Patrick Patterson
Chief PKI Architect

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 Apr 2011 11:39:11 -0400

At 11:06 AM -0400 3/31/11, Patrick Patterson wrote:
>Hello all:
>
>A new version of I-D, 
>draft-patterson-pkix-attribute-signing-eku-00.txt has been 
>successfully submitted by Patrick Patterson and posted to the IETF 
>repository.
>

I think you need to cite some examples of how this would be used and
why it's important, to motivate this feature.  Also, the doc contains 
the following text:

" ... Federation Enabler Certification Authority for issuing 
certificates to  Identity Providers or Attribute Providers in a 
WS-Fed or SAML federation."

This set of terms is not defined anywhere in the doc, nor is there a 
reference to other docs that would explain them. So a lot more 
context is needed for
me to understand what you're talking about.

The Secruity Considerations section should be "TBD" at this stage, if
you have nothing concrete to say.  "None" is NOT acceptable for this doc :-).

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 18 Apr 2011 23:08:06 +0200

Patrick,

As Stephen says, this document needs more motivation.

EKU is a useful tool in PKIs where multiple types of certificates are used.

I don't see that this is a typical case for a federation. It is common that
the trust in IdP public keys are either by direct trust (OOB
pre-configuration) or by means of signed metadata, signed by the federation
operator. In neither case is an EKU necessary for the operation.

It would therefore be useful to know more about the use case where you see
this come into play.

Further. It is common to define specific application specific EKUs in a WG
dealing with the need of this application rather than doing it in PKIX. Is
this possibly something more suitable for the abfab WG?

ASN.1 OIDs are not assigned by IANA, so the IANA section is not correct. I
guess Russ still maintains the PKIX arc.

Definition of an EKU also requires an ASN.1 section with an ASN.1 module for
import into compilers and other specs.

/Stefan

From:  Stephen Kent <[email-masked]>
Date:  Tue, 5 Apr 2011 11:39:11 -0400
To:  Patrick Patterson <[email-masked]>
Cc:  pkix <[email-masked]>
Subject:  Re: [pkix] New draft for consideration as a work item.

>> A new version of I-D, draft-patterson-pkix-attribute-signing-eku-00.txt has
>> been successfully submitted by Patrick Patterson and posted to the IETF
>> repository.
> why it's important, to motivate this feature.  Also, the doc contains the
> following text:
> 
> " ... Federation Enabler Certification Authority for issuing certificates to
> Identity Providers or Attribute Providers in a WS-Fed or SAML federation."
> 
> This set of terms is not defined anywhere in the doc, nor is there a reference
> to other docs that would explain them. So a lot more context is needed for
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix