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

[Stefan Santesson <[e-mail]>]

Hi Denis,

Comments in line;

From:  Denis Pinkas <[e-mail]>
Date:  Tuesday, March 5, 2013 6:44 PM
To:  Stefan Santesson <[e-mail]>
Cc:  pkix <[e-mail]>, Sean Turner <[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.

No that is an example of what you might want to do with this.

>  
>  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.
>  

This is the primary function. This can be used to achieve the goal of the
example use case above. There is no contradiction.


> 
>  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 ?

Only if it solves a problem you have. Else why bother?

You seem to be missing a big point, and perhaps that is because you have not
dealt with the problems of combining a SAML federation with a PKI
infrastructure?
This extension addresses real practical problems arising from the fact that
cert profiles and SAML federations have different attribute profiles. That
is, they use different attributes and name forms to express the same thing.

Basically, if you have gone through the paint to teach every participating
service to understand user identity according to the SAML attribute profile,
you may want to use that also to understand certificate entities.

In some cases that is absolutely necessary but currently not possible
without using quite ugly heuristics and very local conventions that does not
scale very well.

>  
>  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.


No, but you put the finger on a problem that caused me to do another update
to make this clear.

I removed the three parameters specifying the saml Attribute and replaced it
with a real saml:attribute element.

This removes any need to discuss attribute matching, because the SAML
attribute stored in this extension, when compared with anything outside of
the cert, is compared with a SAML attribute from a SAML assertion. Matching
SAML attributes is handled by the SAML standard and is therefore outside the
scope of this document.


>  
>  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.

The need does not arise just in case of a problem. This comparison is done
every time a user signs a document in a government service. This is millions
of transactions and hence this process must be well defined and automated.
The comparison between the SAML assertion the user presented at login, and
the signature certificate presented by the user in the same session will
originate from multiple Ideneity Providers and signature services, so just
relying on local conventions does not scale and is too static to provide a
future proof solution.

Do I dare to say trust me? :) We have modelled and prototyped this for
almost a year, and without adding this information to the certs, our
infrastructure would not work.

>  
>  I still believe that OtherName is the right place to contains the parameters
> extracted from the SAML token,
>  that will be used for comparison.

No, for a number of reasons.

We want this cert to be processed just as any normal certificate.
The primary purpose is to declare the information source of present subject
attributes and name forms, not to define a new OTHER name.

The biggest reason why this definitely can't be an other name is because
there is absolutely no guarantee that the content in this extension will
contain any unique name of anything related to the subject.
In it's simplest use it will just identify an XML Schema defining a static
ruleset. In such case that schema identifier will be the same for all certs
issued to various subjects.

An updated version of the draft is available using the same link.

/Stefan

>  
>  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
>>>>  
>>>  
>>>  
>>>  
>>>  
>>   
>  
>