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

Stefan Santesson <stefan@aaa-sec.com> Mon, 04 March 2013 11:58 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 CD10621F8881 for <pkix@ietfa.amsl.com>; Mon, 4 Mar 2013 03:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.946
X-Spam-Level:
X-Spam-Status: No, score=-99.946 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 CKPUK01Ty+MX for <pkix@ietfa.amsl.com>; Mon, 4 Mar 2013 03:58:04 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E1CCF21F8845 for <pkix@ietf.org>; Mon, 4 Mar 2013 03:58:03 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id BB74651E7DA for <pkix@ietf.org>; Mon, 4 Mar 2013 12:58:01 +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 s9by-qaC8pV6 for <pkix@ietf.org>; Mon, 4 Mar 2013 12:58:01 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2257B4FB162 for <pkix@ietf.org>; Mon, 4 Mar 2013 12:58:01 +0100 (CET)
Received: (qmail 18268 invoked from network); 4 Mar 2013 11:58:00 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender <stefan@aaa-sec.com>) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <md@e-net.lt>; 4 Mar 2013 11:58:00 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Mon, 04 Mar 2013 12:58:00 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Moudrick M. Dadashov" <md@e-net.lt>
Message-ID: <CD5A477C.5D0C4%stefan@aaa-sec.com>
Thread-Topic: [pkix] Comments on draft-santesson-auth-context-extension-04
In-Reply-To: <513476E0.5040300@e-net.lt>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3445246683_762612"
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, 04 Mar 2013 11:58:04 -0000

Hi,

On the question in your mail, these mechanisms are complementary.

The semantics identifier of ETSI TS 119 412-2 may be used to give the value
of a serial number some structure.
If that is all your implementation needs, then you are al done.

In our case, it does not give us all we need, because we have:
1. Already gone through the pain of implementing identity semantics in the
form of a SAML attribute profile, and we need to leverage that also in
certs.
2. We need to map certs to SAML assertions to make sure they represent the
same user.

ETSI TS 119 412-2 does not give us that.

However, these concepts can easily be combined.

The SAML attribute value that is being placed in a serialNumber attribute
can be formatted according to the semantics identifier defined in ETSI TS
119 412-2. And the source of the identifier value may be expressed using the
auth context extension.

This way you can serve the relying party that is trained to interpret the
semantics identifier structure.
At the same time you can serve the relying party that need to know the SAML
origin of the attribute value.

The whole purpose of the extension is that the cert should work as a normal
cert even if the extension is not understood. It just provides additional
information to those trained to understand the extension.
This is the same with semantics identifier. If you don't understand that
identifier, the content of serialNumber is just understood as an arbitrary
string of characters. If you do understand it, it gives you more semantics.

/Stefan



From:  "Moudrick M. Dadashov" <md@e-net.lt>
Date:  Monday, March 4, 2013 11:26 AM
To:  Stefan Santesson <stefan@aaa-sec.com>
Cc:  Denis Pinkas <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject:  Re: [pkix] Comments on draft-santesson-auth-context-extension-04

>     
>  
> On 3/4/2013 12:09 PM, Stefan Santesson wrote:
>  
>  
>>  
>> Denis,
>>  
>> 
>>  
>>  
>> First, thanks for your review. I really appreciate it.
>>  
>> 
>>  
>>  
>> It seems to me, especially with your leading concluding comment, that you
>> have missed out on what this specification attempts to do.
>>  
>> Perhaps you did not read the introduction enough, or perhaps I didn't write
>> it clear enough.
>>  
>> 
>>  
>>  
>> The purpose is not to associate the subject with a identifier composed of a
>> set of attributes.
>>  
>> That is, this is NOT a new name form.
>>  
>> 
>>  
>>  
>> This extension helps a relying party to understand the source of the identity
>> information that is placed in the traditional identity fields of a
>> certificate.
>>  
>> For example. If the serialNumber attributes holds the string "123456", then
>> this extension can tell you where this string came from.
>>  
>> 
>>  
>>  
>  How is this related to "semantics identifier" (ETSI TS 119 412-2) then?
>  
>  M.D.