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

[Denis Pinkas <[e-mail]>]

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
>