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

From: Denis Pinkas <[email-masked]>
Date: Mon, 04 Mar 2013 09:42:53 +0100

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.

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.

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.

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

}

4.The text states: This extension MAY be marked critical.

If the alternate name is present, why should there be a DN ?

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.

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.

7.The XML structure proposed to fit inside contextInfo is overly complex.

AuthenticationInstant is mandatory, whereas it is not needed.

AssertionRef is not needed.

ServiceID is not needed.

8.There are no matching rules defined. This means that the verification 
of the content of that field is not possible.

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

"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".
The example in Appendix C illustrates the complexity of the proposal.
Can the approach be made simpler ? If not, why ?

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

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 04 Mar 2013 11:09:56 +0100

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.

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 <[email-masked]>
Date:  Monday, March 4, 2013 9:42 AM
To:  Stefan Santesson <[email-masked]>, pkix <[email-masked]>
Subject:  Comments on draft-santesson-auth-context-extension-04

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

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

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

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

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

This information is always available from the SAML assertion and is
considered fundamental, thus required.

> AssertionRef 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
>  
>                       "san"   The SAML attribute value is placed in the
>  
> I also failed to understand the reason of such ³mapping².

Yes, and I think that is the reason behind most of your comments.

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

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Mon, 04 Mar 2013 12:26:40 +0200

On 3/4/2013 12:09 PM, Stefan Santesson wrote:
> 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.
> 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 <[email-masked] <mailto:[email-masked]>>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>, 
> pkix <[email-masked] <mailto:[email-masked]>>
>     The goal of this document is to associate a public key to be used
>     for verifying electronic signatures
>     1.The proposed draft is not aligned with the current practices of
>     RFC 5280 and X.509:
>     There is no rational in this draft to explain why this
>     straightforward approach has not been chosen.
>
>     OtherName fits well with the requirements, if you accept to use an
>     OID rather than
>     The value component would contain an XML structure conformant with
>     a XML schema.
>
>
> There is not explanation why we don't store an identifier as a SAN, 
> since we do not create or store an identifier.
>
>     (b) a specific profile, in an Appendix, so that other RFCs could
>     refer to the main body of the document.
>
>
> For exactly the same reason why SAML AuthContextClassRef in a SAML 
> assertion is mandatory but not the XML structure it defines.
> 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.
>
>
>     5.The XML schema should be given first (Appendix B) followed by
>     the explanations (sections 3.1 and 3.2).
> 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
> 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.
>
> 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):
>     8.There are no matching rules defined. This means that the
>     verification of the content of that field is not possible.
>
>
> attribute, this data in the extension is optional and, if present, is 
> a hint.
>     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.
>
> 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.
>
> A CA issues a certificate to a user based an a SAML assertion 
> authentication based on the attribute profile of that federation.
>
> You now need to determine whether that SAML assertion and the 
> certificate represents the same user.
> 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.
>
>     authenticates to a RA (Registration Authority) and then is given
>     back a non-repudiation certificate
>     I am unsure what the text in this section wants to say when using
>     the words "dynamic manner".
>
>
>
> 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.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 04 Mar 2013 12:58:00 +0100

Hi,

On the question in your mail, these mechanisms are complementary.

The semantics identifier of ETSI TS 119 412-2 may be used to give the value
of a serial number some structure.
If that is all your implementation needs, then you are al done.

In our case, it does not give us all we need, because we have:
1. Already gone through the pain of implementing identity semantics in the
form of a SAML attribute profile, and we need to leverage that also in
certs.
2. We need to map certs to SAML assertions to make sure they represent the
same user.

ETSI TS 119 412-2 does not give us that.

However, these concepts can easily be combined.

The SAML attribute value that is being placed in a serialNumber attribute
can be formatted according to the semantics identifier defined in ETSI TS
119 412-2. And the source of the identifier value may be expressed using the
auth context extension.

This way you can serve the relying party that is trained to interpret the
semantics identifier structure.
At the same time you can serve the relying party that need to know the SAML
origin of the attribute value.

The whole purpose of the extension is that the cert should work as a normal
cert even if the extension is not understood. It just provides additional
information to those trained to understand the extension.
This is the same with semantics identifier. If you don't understand that
identifier, the content of serialNumber is just understood as an arbitrary
string of characters. If you do understand it, it gives you more semantics.

/Stefan

From:  "Moudrick M. Dadashov" <[email-masked]>
Date:  Monday, March 4, 2013 11:26 AM
To:  Stefan Santesson <[email-masked]>
Cc:  Denis Pinkas <[email-masked]>, pkix <[email-masked]>
Subject:  Re: [pkix] Comments on draft-santesson-auth-context-extension-04

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

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 04 Mar 2013 14:57:10 +0100

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

>> This extension provides means to preserve information about the original SAML
>> attributes in the cert.
>>  
>> 
>>  
>>  
>> 
>>  
>>   
>>>  (b) a specific profile, in an Appendix, so that other RFCs could refer to
>>> the main body of the document.
>>>  
>>>  
>>>  
>>>  
>>>  
>>   
>> 
>>  
>>  
>> In some cases you don't want to include explicit data, if that data is static
>> and can be implicitly known through an identifier.
>>  
>> 
>>  
>>  
>> 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.
>>  
>> 
>>  
>>  
>> 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.
>>  
>> 
>>  
>>   
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>>  
>>> An example: ³AuthContextInfo Element² does not exist. However, it is better
>>> to state that the contextInfo component
>> is defined in the schema. XML Schema defines syntax and structure but not the
>> semantics. Semantics are defined the section 3.
>>  
>> 
>>  
>>   
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>> The XML Schema is actually very simple. Its just the nature of XML Schemas to
>> look more complex than they actually are.
>>  
>> matching rule is it would be if this was an identifier that as a whole should
>> be compared with something else.
>>  
>> 
>>  
>>  
>> attribute, this data in the extension is optional and, if present, is a hint.
>>  
>>> 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).
>>>  
>>>  
>>>  
>>   
>> 
>>  
>>  
>> A user logs in to your service using a SAML assertion, and sends you a signed
>> document associated with the issued certificate.
>>  
>> provides compatible levels of assertion for user authentication as defined in
>> your SAML federation.
>>  
>> 
>>  
>>  
>> 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.
>>  
>> 
>>  
>>  
>> exactly what identity information each certificate carries, as it maps to the
>> attribute profile of a SAML federation.
>>  
>> 
>>  
>>  
>> /Stefan
>>  
>> 
>>  
>>   
>>>  
>>>  
>>>  
>>> 
>>> 
>>>  
>>>  
>>> Denis
>>>  
>>>        
>>>  
>>>  
>>   
>>   
>>  
>> [email-masked]://www.ietf.org/mailman/listinfo/pkix
>>  
>  
>

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 05 Mar 2013 18:44:11 +0100

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:
> conventions, such as the one expressed in ETSI TS 119 412-2, can 
> co-exist with this extension.
>
> /Stefan
>
> From: "Moudrick M. Dadashov" <[email-masked] <mailto:[email-masked]>>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>
> Cc: Denis Pinkas <[email-masked] 
> <mailto:[email-masked]>>, pkix <[email-masked] 
> <mailto:[email-masked]>>
>>     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.
>>     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.
>>
>>     The use case addressed is where the CA/RA obtains the
>>     authenticated identify from a SAML assertion when issuing the
>>     certificate.
>>     To: Stefan Santesson <[email-masked]
>>     <mailto:[email-masked]>>, pkix <[email-masked]
>>     <mailto:[email-masked]>>
>>         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.
>>
>>
>>         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.
>>         OtherName fits well with the requirements, if you accept to
>>         use an OID rather than
>>         The value component would contain an XML structure conformant
>>         with a XML schema.
>>
>>
>>     There is not explanation why we don't store an identifier as a
>>     SAN, since we do not create or store an identifier.
>>
>>         (b) a specific profile, in an Appendix, so that other RFCs
>>         could refer to the main body of the document.
>>
>>
>>     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.
>>
>>     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.
>>
>>
>>     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).
>>     That is one way to do it. If I was the implementer, I really
>>     wouldn't care as long as the information is there.
>>         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
>>     This information is always available from the SAML assertion and
>>     is considered fundamental, thus required.
>>
>>     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):
>>     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.
>>         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.
>>
>>     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 user logs in to your service using a SAML assertion, and sends
>>     you a signed document associated with the issued certificate.
>>     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
>>         I am unsure what the text in this section wants to say when
>>         using the words "dynamic manner".
>>
>>
>>
>>     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.
>>     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
>>
>>
>>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 06 Mar 2013 01:26:59 +0100

Hi Denis,

Comments in line;

From:  Denis Pinkas <[email-masked]>
Date:  Tuesday, March 5, 2013 6:44 PM
To:  Stefan Santesson <[email-masked]>
Cc:  pkix <[email-masked]>, Sean Turner <[email-masked]>
Subject:  Re: [pkix] Comments on draft-santesson-auth-context-extension-04

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

>    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

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,

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.
>>>>> 1. The proposed draft is not aligned with the current practices of RFC
>>>>> 5280 and X.509:
>>>> There is not explanation why we don't store an identifier as a SAN, since
>>>> we do not create or store an identifier.
>>>>  
>>>> 
>>>>  
>>>>   
>>>>>  
>>>>>  
>>>>>  
>>>>> 
>>>>>  
>>>>>  
>>>>> An  example: ³AuthContextInfo Element² does not exist. However, it is
>>>>> 8. There are no matching rules defined. This means that the verification
>>>>> words ³dynamic manner².
>>>> 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
>>>> 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
>>>>>  
>>>>>        
>>>>>  
>>>>>  
>>>>   
>>>>   
>>>>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 06 Mar 2013 13:27:20 +0100

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

Cc:  pkix <[email-masked]>

> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 08 Mar 2013 09:44:20 +0100

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

> 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
>
>
>
>
> Cc: pkix <[email-masked] <mailto:[email-masked]>>
>     I read the new specification (dated March 4) and it does not solve
>     my concerns.
>     **
>           "You now need to determine whether that SAML assertion and
>     the certificate represents the same user."
>
>     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 ...
>
>     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,
>     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.
>
>     PS. I wonder whether we should continue to have in mind to have
>     this document issued as an RFC.
>>     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
>>
>>     Subject: Re: [pkix] Comments on
>>     draft-santesson-auth-context-extension-04
>>
>>>         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.
>>>         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.
>>>         "123456", then this extension can tell you where this string
>>>         came from.
>>>
>>>         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.
>>>
>>>
>>>             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.
>>>
>>>
>>>             the right place to hold such a set of attributes is in
>>>             the subject alternate name.
>>>             OtherName fits well with the requirements, if you accept
>>>             to use an OID rather than
>>>             The value component would contain an XML structure
>>>             conformant with a XML schema.
>>>
>>>
>>>         There is not explanation why we don't store an identifier as
>>>         a SAN, since we do not create or store an identifier.
>>>
>>>             (b) a specific profile, in an Appendix, so that other
>>>             RFCs could refer to the main body of the document.
>>>
>>>
>>>         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.
>>>
>>>
>>>         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).
>>>             6.The vocabulary used in sections 3.1 and 3.2 is
>>>             confusing and should be changed.
>>>
>>>         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.
>>>
>>>         This information is always available from the SAML assertion
>>>         and is considered fundamental, thus required.
>>>
>>>         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):
>>>             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.
>>>             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.
>>>
>>>         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.
>>>             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
>>>             I am unsure what the text in this section wants to say
>>>             when using the words "dynamic manner".
>>>
>>>
>>>
>>>         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.
>>>
>>>         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.
>>>
>>>         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
>>>
>>>
>>>
>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked] (Martin Rex)
Date: Sat, 9 Mar 2013 00:18:24 +0100 (CET)

Denis,

While I have no personal interest or use in this proposal myself,
I'm somewhat confused by your message.

> the responsibility of the CA.

Stefan said that he _has_ RPs who care.  Where is your problem with this?

> that this document should progress as an Internet Draft.

"progress as Internet Draft"?
(I have not the slightest idea what that is.)

>From the document header, Stefan seems to be looking for an Individual
Submission with the intended document status "Informational".

Were you thinking of a Standards track document?
Or were you thinking about a WG work item (Last thing I heard was that
PKIX is scheduled to shut down (as IETF WG) and not accepting any further
work items).  Only the latter two would need any kind of "approval".

Stefan's primary interest seems to be sharing information about what he
does (or intends to do) with the IETF community.  And Stefan seems to
solicit and accept feedback and suggestions from the PKIX community
to make this work more useful to others.

> an important issue which deserves an Internet Draft.

Stefan indicated that he needs this extension to convey information
that does not qualify as SAN/otherName, so this feedback seems to be
missing the point.

If you have a need for this, you might have to create your own proposal/I-D
to fit this purpose.

-Martin

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 11 Mar 2013 10:41:40 +0100

Martin,

The problem is that we currently only have a static description for a 
mapping but no indication on how
a RP shall use the content of the extension, in particular when it is 
critical.

I have also difficulties to understand why this mapping information 
needs to be in the certificate since it will be in the audit trail of 
the CA anyway.

What is important is how the RP shall use that information and my 
understanding is still the following:
making sure the the certificate belongs to a person that has used a SAML 
token.

So it is much straightforward to include in the certificate information 
about the SAML token itself rather than
information on a mapping with the content of the DN which anyway is of 
no value for a RP because it cannot be verified.

If a document is targeted to informational, it is because it may be 
useful outside the community which has an original interest in it.

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 11 Mar 2013 08:12:39 +0100

Denis,

If you don't understand how this information can be useful, that probably
is because you don't have a problem that needs this information.

If you don't have a problem that needs this information, why does any of
this bother you?

The matching rules are not necessary because matching of SAML attributes
is defined by SAML.

Anyway. Answering below;

>a RP shall use the content of the extension, in particular when it is

The information is there. You may use it any way you like. There are many
use-cases describing situations where this information is useful.
Criticality only means that you need to recognise the extension in order
to accept the cert, not that you have to use it in any particular way.

>needs to be in the certificate since it will be in the audit trail of

That is probably because you don't have a problem that requires this
information in the cert. The CA audit trail is not available to the RP at
time of cert validation.

>making sure the the certificate belongs to a person that has used a SAML

The RP can use several strategies depending on the amount and type of
information present in the extension.
It either gives you the information you need as RP (filling an information
gap) or it doesn't.
If it does it makes it possible for you to accept the cert.

>no value for a RP because it cannot be verified.

If that is what you need, then feel free to define such extension.
I need a certificate that carries a normal cert name. I just need extra
information to understand what that name is.

>useful outside the community which has an original interest in it.

Not necessarily. But if someone has a problem that is addressed here
(which you obviously have not), then I would not mind make it useful
outside of our project.

/Stefan