Re: [pkix] Comments on draft-santesson-auth-context-extension-04

Stefan Santesson <stefan@aaa-sec.com> Mon, 11 March 2013 12:12 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB2321F86FA for <pkix@ietfa.amsl.com>; Mon, 11 Mar 2013 05:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.205
X-Spam-Level:
X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7lKdfN1GaGr for <pkix@ietfa.amsl.com>; Mon, 11 Mar 2013 05:12:47 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E8E6721F86CB for <pkix@ietf.org>; Mon, 11 Mar 2013 05:12:46 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9FB8B57413A for <pkix@ietf.org>; Mon, 11 Mar 2013 13:12:45 +0100 (CET)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Wo2eqpZLLzTQ for <pkix@ietf.org>; Mon, 11 Mar 2013 13:12:44 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 126EB574164 for <pkix@ietf.org>; Mon, 11 Mar 2013 13:12:44 +0100 (CET)
Received: (qmail 81421 invoked from network); 11 Mar 2013 12:12:43 -0000
Received: from unknown (HELO [130.129.130.12]) (stefan@fiddler.nu@[130.129.130.12]) (envelope-sender <stefan@aaa-sec.com>) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <denis.pinkas@bull.net>; 11 Mar 2013 12:12:43 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Mon, 11 Mar 2013 08:12:39 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Denis Pinkas <denis.pinkas@bull.net>, mrex@sap.com
Message-ID: <CD633F2A.5DAD7%stefan@aaa-sec.com>
Thread-Topic: [pkix] Comments on draft-santesson-auth-context-extension-04
In-Reply-To: <513DA6D4.2010208@bull.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2013 12:12:48 -0000

Denis,

If you don't understand how this information can be useful, that probably
is because you don't have a problem that needs this information.

If you don't have a problem that needs this information, why does any of
this bother you?

The matching rules are not necessary because matching of SAML attributes
is defined by SAML.


Anyway. Answering below;

On 3/11/13 10:41 AM, "Denis Pinkas" <denis.pinkas@bull.net> wrote:

>Martin,
>
>The problem is that we currently only have a static description for a
>mapping but no indication on how
>a RP shall use the content of the extension, in particular when it is
>critical.

The information is there. You may use it any way you like. There are many
use-cases describing situations where this information is useful.
Criticality only means that you need to recognise the extension in order
to accept the cert, not that you have to use it in any particular way.

>
>I have also difficulties to understand why this mapping information
>needs to be in the certificate since it will be in the audit trail of
>the CA anyway.


That is probably because you don't have a problem that requires this
information in the cert. The CA audit trail is not available to the RP at
time of cert validation.

>
>What is important is how the RP shall use that information and my
>understanding is still the following:
>making sure the the certificate belongs to a person that has used a SAML
>token.

The RP can use several strategies depending on the amount and type of
information present in the extension.
It either gives you the information you need as RP (filling an information
gap) or it doesn't.
If it does it makes it possible for you to accept the cert.


>
>So it is much straightforward to include in the certificate information
>about the SAML token itself rather than
>information on a mapping with the content of the DN which anyway is of
>no value for a RP because it cannot be verified.

If that is what you need, then feel free to define such extension.
I need a certificate that carries a normal cert name. I just need extra
information to understand what that name is.

>
>If a document is targeted to informational, it is because it may be
>useful outside the community which has an original interest in it.


Not necessarily. But if someone has a problem that is addressed here
(which you obviously have not), then I would not mind make it useful
outside of our project.

/Stefan

>
>Denis
>
>> Denis,
>>
>> While I have no personal interest or use in this proposal myself,
>> I'm somewhat confused by your message.
>>
>> Denis Pinkas wrote:
>>> Allowing to have SAML attributes in a PKC would be a very good thing.
>>> However, the relying party DOES NOT care
>>> how these SAML attributes have been translated into a subject DN. It is
>>> the responsibility of the CA.
>> Stefan said that he _has_ RPs who care.  Where is your problem with
>>this?
>>
>>
>>> Thus, if the scope only remains to know how the correspondence was made
>>> between  the SAML attributes and
>>> the subject DN, I don't believe that this document will be useful for
>>> the Internet community and thus I am still unconvinced
>>> that this document should progress as an Internet Draft.
>> "progress as Internet Draft"?
>> (I have not the slightest idea what that is.)
>>
>>  From the document header, Stefan seems to be looking for an Individual
>> Submission with the intended document status "Informational".
>>
>> Were you thinking of a Standards track document?
>> Or were you thinking about a WG work item (Last thing I heard was that
>> PKIX is scheduled to shut down (as IETF WG) and not accepting any
>>further
>> work items).  Only the latter two would need any kind of "approval".
>>
>>
>> Stefan's primary interest seems to be sharing information about what he
>> does (or intends to do) with the IETF community.  And Stefan seems to
>> solicit and accept feedback and suggestions from the PKIX community
>> to make this work more useful to others.
>>
>>
>>> If the scope is changed to allow to include SAML attributes as another
>>> name form in a PKC, then this is
>>> an important issue which deserves an Internet Draft.
>> Stefan indicated that he needs this extension to convey information
>> that does not qualify as SAN/otherName, so this feedback seems to be
>> missing the point.
>>
>> If you have a need for this, you might have to create your own
>>proposal/I-D
>> to fit this purpose.
>>
>>
>> -Martin
>
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix