Re: [pkix] Comments on draft-santesson-auth-context-extension-04
Stefan Santesson <stefan@aaa-sec.com> Mon, 04 March 2013 13:57 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 C998B21F8A5F for <pkix@ietfa.amsl.com>; Mon, 4 Mar 2013 05:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.493
X-Spam-Level:
X-Spam-Status: No, score=-99.493 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SPEC_REPLICA_OBFU=1.812, 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 pFcgr-3VnP1q for <pkix@ietfa.amsl.com>; Mon, 4 Mar 2013 05:57:23 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E91CA21F8A6B for <pkix@ietf.org>; Mon, 4 Mar 2013 05:57:22 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 7285051EE61 for <pkix@ietf.org>; Mon, 4 Mar 2013 14:57:20 +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 eo68Yh7JUZ76 for <pkix@ietf.org>; Mon, 4 Mar 2013 14:57:13 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 30AA351F12B for <pkix@ietf.org>; Mon, 4 Mar 2013 14:57:13 +0100 (CET)
Received: (qmail 43338 invoked from network); 4 Mar 2013 13:57:12 -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 13:57:12 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Mon, 04 Mar 2013 14:57:10 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Moudrick M. Dadashov" <md@e-net.lt>
Message-ID: <CD5A661C.5D102%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_3445253835_1241822"
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 13:57:30 -0000
Based on comments received today I have updated this draft, preliminary available at: http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt I have edited the Introduction section to clarify the scope of the document. I have also added a new section (now 3.2) that explains the absence of attribute matching rules. The section should also make clear how specific attribute data format conventions, such as the one expressed in ETSI TS 119 412-2, can co-exist with this extension. /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. > >> >> The use case addressed is where the CA/RA obtains the authenticated identify >> from a SAML assertion when issuing the certificate. >> >> This extension provides means to preserve information about the original SAML >> attributes in the cert. >> >> >> >> >> >> >> >> From: Denis Pinkas <denis.pinkas@bull.net> >> Date: Monday, March 4, 2013 9:42 AM >> To: Stefan Santesson <stefan@aaa-sec.com>, pkix <pkix@ietf.org> >> Subject: Comments on draft-santesson-auth-context-extension-04 >> >> >> >> >> >>> >>> >>> >>> >>> Stefan, >>> >>> >>> >>> >>> >>> The goal of this document is to associate a public key to be used for >>> verifying electronic signatures >>> with an identifier composed of a set of attributes, typically SAML >>> attributes, contained in an authentication token. >>> >>> >>> >>> >>> >> >> >> >> >> No you got this wrong. This is not an Identifier. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> MAJOR COMMENTS >>> >>> >>> >>> 1. The proposed draft is not aligned with the current practices of RFC 5280 >>> and X.509: >>> the right place to hold such a set of attributes is in the subject >>> alternate name. >>> The subject DN may or may not be empty. >>> >>> >>> >>> There is no rational in this draft to explain why this straightforward >>> approach has not been chosen. >>> >>> >>> >>> SubjectAltName ::= GeneralNames >>> >>> >>> >>> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName >>> >>> >>> >>> GeneralName ::= CHOICE { >>> >>> otherName [0] OtherName, >>> >>> rfc822Name [1] IA5String, >>> >>> dNSName [2] IA5String, >>> >>> x400Address [3] ORAddress, >>> >>> directoryName [4] Name, >>> >>> ediPartyName [5] EDIPartyName, >>> >>> uniformResourceIdentifier [6] IA5String, >>> >>> iPAddress [7] OCTET STRING, >>> >>> registeredID [8] OBJECT IDENTIFIER } >>> >>> >>> >>> OtherName ::= SEQUENCE { >>> >>> type-id OBJECT IDENTIFIER, >>> >>> value [0] EXPLICIT ANY DEFINED BY type-id } >>> >>> >>> >>> OtherName fits well with the requirements, if you accept to use an OID >>> rather than >>> a uniformResourceIdentifier. >>> >>> >>> >>> The value component would contain an XML structure conformant with a XML >>> schema. >>> >>> >>> >>> >>> >> >> >> >> >> This draft does not contain an identifier, thus this comment is irrelevant. >> >> There is not explanation why we don't store an identifier as a SAN, since we >> do not create or store an identifier. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> 2. The document should be restructured to define: >>> >>> (a) the general way to answer to the requirements, and >>> (b) a specific profile, in an Appendix, so that other RFCs could refer to >>> the main body of the document. >>> >>> >>> >>> >>> >> >> >> >> >> That could be one way to do it. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> DETAILED COMMENTS >>> >>> >>> >>> 3. The proposed structure is not appropriate. >>> >>> >>> >>> a) Why is there a need to have a SEQUENCE ? This should be avoided. >>> >>> b) Why is contextInfo OPTIONAL? This should be avoided. >>> >>> >>> >>> AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF >>> >>> AuthenticationContext >>> >>> >>> >>> AuthenticationContext ::= SEQUENCE { >>> >>> contextType UTF8String, >>> >>> contextInfo UTF8String OPTIONAL >>> >>> } >>> >>> >>> >> >> >> >> >> For exactly the same reason why SAML AuthContextClassRef in a SAML assertion >> is mandatory but not the XML structure it defines. >> >> In some cases you don't want to include explicit data, if that data is static >> and can be implicitly known through an identifier. >> >> >> >> >> The AuthContextClassRef in SAML is the best example as it is an exact >> functional replica of this. >> >> The URL identified by AuthContextClassRef is also a XML Schema ns for >> associated XML document. >> >> >> >> >> The XML Schema can define both a static XML document with fixed values as >> well as a structure where different values can be entered. >> >> >> >> >> Just including the reference to the XML Schema may then provide sufficient >> information to the relying party. The actual XML document is only included if >> some variable data need to be communicated within the associated XML >> document. >> >> >> >> >> Just including contextType but not contextInfo could be compared with the >> case where we include a certificate policy OID, but not the entire policy >> text. >> >> >> >> >> This is a really smart way to do this, which is made possible through the >> versatility of XML Schemas. >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> 4. The text states: This extension MAY be marked critical. >>> >>> >>> >>> If the alternate name is present, why should there be a DN ? >>> >>> >>> >>> >> >> >> >> >> This comment must be based on a misunderstanding of the scope of this >> document. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> 5. The XML schema should be given first (Appendix B) followed by the >>> explanations (sections 3.1 and 3.2). >>> In other words, sections 3.1 and 3.2 should be placed in Appendix B. >>> >>> >>> >> >> >> >> >> That is one way to do it. If I was the implementer, I really wouldn't care as >> long as the information is there. >> >> I think it is quite common to place programatic contracts in Appendixes, wile >> explaining data elements in the body of the document. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> 6. The vocabulary used in sections 3.1 and 3.2 is confusing and should be >>> changed. >>> >>> >>> >>> An example: ³AuthContextInfo Element² does not exist. However, it is better >>> to state that the contextInfo component >>> contains an XML structure which must conform to an XML schema. >>> >>> >>> >>> >>> >> >> >> >> >> Sorry, I don't get this comment. The AuthContextInfo element does exist. It >> is defined in the schema. XML Schema defines syntax and structure but not the >> semantics. Semantics are defined the section 3. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> 7. The XML structure proposed to fit inside contextInfo is overly complex. >>> >>> >>> >>> AuthenticationInstant is mandatory, whereas it is not needed. >>> >>> >>> >> >> >> >> >> This information is always available from the SAML assertion and is >> considered fundamental, thus required. >> >> >> >> >>> >>> >>> >>> >>> >>> AssertionRef is not needed. >>> >>> ServiceID is not needed. >>> >>> >>> >> >> >> >> >> And hence, both are optional. >> >> >> >> >> The XML Schema is actually very simple. Its just the nature of XML Schemas to >> look more complex than they actually are. >> >> Perhaps it is easier if you examine it through this following web doc (which >> unfortunately can't be included in the spec): >> >> http://aaa-sec.com/eid2/sigsupport/XMLschema/AuthContExtDoc/index.html >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> 8. There are no matching rules defined. This means that the verification of >>> the content of that field is not possible. >>> >>> >>> >> >> >> >> >> First of all, this is not an identifier, thus there is no reason for a >> matching rule is it would be if this was an identifier that as a whole should >> be compared with something else. >> >> >> >> >> The SAML attribute value does not have to match the value of the cert >> attribute, this data in the extension is optional and, if present, is a hint. >> >> But I could actually add some text to clarify this. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> 9. In section 3.2, I failed to understand the explanations for CertRef as >>> well as for rdn and san. >>> >>> >>> >>> Why CertNameType cannot be ³factorized² ? (in the example from Page 15, >>> there are all the same). >>> >>> >>> >> >> >> >> >> No, the example in the spec has one e-mail attribute that was placed in the >> SubjAltName extension of the cert. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> "rdn" The SAML attribute value is placed in the >>> >>> subject field of the certificate in a >>> >>> present Relative Distinguished Name >>> >>> attribute. >>> >>> >>> >>> "san" The SAML attribute value is placed in the >>> >>> Subject Alternative Name extension of the >>> >>> certificate. >>> >>> >>> >>> I also failed to understand the reason of such ³mapping². >>> >>> >>> >> >> >> >> >> Yes, and I think that is the reason behind most of your comments. >> >> >> >> >>> >>> >>> >>> >>> >>> The example in Appendix C illustrates the complexity of the proposal. >>> Can the approach be made simpler ? If not, why ? >>> >>> >>> >>> >>> >> >> >> >> >> No it can't be made simpler. It contains exactly the information we need in >> the implementation where it is used. >> >> >> >> >> I could write a whole whitepaper about all detailed reasons, but if you >> really think about the use case, it should be clear. >> >> >> >> >> Consider the case where you know users by attributes defined in a SAML >> federation, where for example serialNumber is NOT used. >> >> A CA issues a certificate to a user based an a SAML assertion authentication >> based on the attribute profile of that federation. >> >> >> >> >> A user logs in to your service using a SAML assertion, and sends you a signed >> document associated with the issued certificate. >> >> You now need to determine whether that SAML assertion and the certificate >> represents the same user. >> >> You also need to determine that the SAML assertion and the certificate >> provides compatible levels of assertion for user authentication as defined in >> your SAML federation. >> >> >> >> >> This extension gives you exactly the amount of data that is needed in order >> to do this in an unambiguous fully automated process. >> >> >> >> >>> >>> >>> >>> >>> >>> >>> 10. In section 4, I failed to understand the ³dynamic² aspect. My >>> understanding is that a person statically >>> authenticates to a RA (Registration Authority) and then is given back a >>> non-repudiation certificate >>> with SAML attributes in it which may then be used as identity attributes. >>> I am unsure what the text in this section wants to say when using the words >>> ³dynamic manner². >>> >>> >>> >>> >> >> >> >> >> >> >> >> Your view is to restrictive. >> >> >> >> >> The dynamic aspect of this is that a certificate may be issued on the fly at >> the instance when it is needed, containing just the information that is >> needed for one particular situation. >> >> This extension is (where this is used in the Swedish national infrastructure) >> added to certificates that are issued for just one instance of signing, and >> hence can be dynamically adapted to the needs of the intended relying party. >> >> >> >> >> Next time the user signs, a new key pair is generated with new certs that may >> contain another set of the user's attributes. >> >> >> >> >> The first instance may for example contain the users private identity based >> on a national identifier, the second may carry an organisational identity >> based on employee number. >> >> What attributes that are needed in every instance is determined in a service >> context that is outside the scope of this specification. >> >> >> >> >> In these certificates, both the national identifier and the employee number >> may be placed as a serialNumber attribute in the subject field. >> >> Despite that, this extension makes it possible for the relying party to know >> exactly what identity information each certificate carries, as it maps to the >> attribute profile of a SAML federation. >> >> >> >> >> /Stefan >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> Denis >>> >>> >>> >>> >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix >> > >
- [pkix] Comments on draft-santesson-auth-context-e… Denis Pinkas
- Re: [pkix] Comments on draft-santesson-auth-conte… Stefan Santesson
- Re: [pkix] Comments on draft-santesson-auth-conte… Moudrick M. Dadashov
- Re: [pkix] Comments on draft-santesson-auth-conte… Stefan Santesson
- Re: [pkix] Comments on draft-santesson-auth-conte… Stefan Santesson
- Re: [pkix] Comments on draft-santesson-auth-conte… Denis Pinkas
- Re: [pkix] Comments on draft-santesson-auth-conte… Stefan Santesson
- Re: [pkix] Comments on draft-santesson-auth-conte… Stefan Santesson
- Re: [pkix] Comments on draft-santesson-auth-conte… Denis Pinkas
- Re: [pkix] Comments on draft-santesson-auth-conte… Martin Rex
- Re: [pkix] Comments on draft-santesson-auth-conte… Denis Pinkas
- Re: [pkix] Comments on draft-santesson-auth-conte… Stefan Santesson