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

[Stefan Santesson <[e-mail]>]

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]>
Date:  Tuesday, March 5, 2013 6:44 PM
To:  Stefan Santesson <[e-mail]>
Cc:  pkix <[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 there 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]>
>>  Date:  Monday, March 4, 2013 11:26 AM
>>  To:  Stefan Santesson <[e-mail]>
>>  Cc:  Denis Pinkas <[e-mail]>, pkix <[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]>
>>>>  Date:  Monday, March 4, 2013 9:42 AM
>>>>  To:  Stefan Santesson <[e-mail]>,  pkix <[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-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
>>>> [e-mail]://www.ietf.org/mailman/listinfo/pkix
>>>>  
>>>  
>>>  
>>>  
>>>  
>>   
>  
>  
> _______________________________________________ pkix mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/pkix