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

[Denis Pinkas <[e-mail]>]

Stefan,

  I wonder whether your had "fresh eyes", because you moved one step 
forwards and then you moved three steps backwards:
Section3.2 "Attribute matching" has now disappeared.

The major disagreements remain: I disagree with the scope and the new 
draft does not solve my concerns.

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.

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.

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.

Denis

> Denis,
>
> I took a look at this this morning with fresh eyes, and some of your 
> questions triggered me to do further improvements on the Schema, 
> explanations and examples.
>
> The latest draft is still available from here:
> http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt
>
> Hopefully the new examples will give you a better Idea on how this 
> extension can be used and why this is not suitable as an other name form.
>
> I'm really grateful for your review even if I don't do everything 
> exactly as you suggested.
>
> /Stefan
>
>
>
>
> From: Denis Pinkas <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, March 5, 2013 6:44 PM
> To: Stefan Santesson <[e-mail] <mailto:[e-mail]>>
> Cc: pkix <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04
>
>     Stefan,
>
>     I read the new specification (dated March 4) and it does not solve
>     my concerns.
>     **
>     The real goal is stated at the top of page 4:
>
>
>     *to verify that the signature was created by the same user that
>     logged on *
>
>     *to the service*.
>
>     In your response below, you also say:
>
>           "You now need to determine whether that SAML assertion and
>     the certificate represents the same user."
>
>     This is rather different from the goal stated on page 3:
>
>     The primary purpose of this document is to provide a mechanism that
>
>     allows an application to understand information that express the
>
>     identity of a *subject in a certificate that is stored either in a*
>
>     *subject field attribute, as a subject alternative name or in a*
>
>     *subject directory attribute.*
>
>
>     If we draw an analogy with the way to construct a DN, we do not
>     mention that the DN was created after
>     the presentation of a passport or an ID card, plus a way to
>     justify the place of birth, a a way to justify
>     the place of living, an that the country name was extracted from
>     the presentation of the passport, etc ...
>
>     So why should we do this in your context ?
>
>     We need to store information in the certificate directly derived
>     from the SAML token, so that the application
>     which performed a SAML authentication can make sure that the
>     certificate was delivered for the same person,
>     by *making a comparison using some set of rules.**
>     *
>     So *t**here is a need to have matching rules* for the content of
>     the SAML token with the content of
>     the new extension (whatever it is). If we don't have such rules,
>     then the goal at the top of page 4 cannot be met.
>
>     I do not see the added value to explain some translation process
>     since it would be used for audit purposes only and
>     the CA MUST anyway maintain information about the issuance of the
>     token. So in case of a problem, the
>     CA SHALL be able to answer and it is not needed to overload the
>     content of the certificate with more information.
>
>     I still believe that OtherName is the right place to contains the
>     parameters extracted from the SAML token,
>     that will be used for comparison.
>
>     Denis
>
>
>     PS. I wonder whether we should continue to have in mind to have
>     this document issued as an RFC.
>            It may well be a national Swedish standard.
>
>>     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" <[e-mail] <mailto:[e-mail]>>
>>     Date: Monday, March 4, 2013 11:26 AM
>>     To: Stefan Santesson <[e-mail] <mailto:[e-mail]>>
>>     Cc: Denis Pinkas <[e-mail]
>>     <mailto:[e-mail]>>, pkix <[e-mail]
>>     <mailto:[e-mail]>>
>>     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 <[e-mail]
>>>         <mailto:[e-mail]>>
>>>         Date: Monday, March 4, 2013 9:42 AM
>>>         To: Stefan Santesson <[e-mail]
>>>         <mailto:[e-mail]>>, pkix <[e-mail]
>>>         <mailto:[e-mail]>>
>>>         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-idOBJECT 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 {
>>>
>>>             contextTypeUTF8String,
>>>
>>>             contextInfoUTF8String 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
>>>         [e-mail]://www.ietf.org/mailman/listinfo/pkix
>>
>
>     _______________________________________________ pkix mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/pkix 
>