From stefan@aaa-sec.com Fri Mar 1 08:56:13 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E7921F938B for ; Fri, 1 Mar 2013 08:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.915 X-Spam-Level: X-Spam-Status: No, score=-99.915 tagged_above=-999 required=5 tests=[AWL=-1.477, BAYES_40=-0.185, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4+oats8c62N for ; Fri, 1 Mar 2013 08:56:13 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD2221F9387 for ; Fri, 1 Mar 2013 08:56:13 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 19B6C4EB221 for ; Fri, 1 Mar 2013 17:56:12 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jE9_34eenDEK for ; Fri, 1 Mar 2013 17:56:11 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D247A4EB21F for ; Fri, 1 Mar 2013 17:56:11 +0100 (CET) Received: (qmail 41989 invoked from network); 1 Mar 2013 16:56:11 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.216]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Mar 2013 16:56:11 -0000 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Fri, 01 Mar 2013 17:56:08 +0100 From: Stefan Santesson To: pkix Message-ID: Thread-Topic: Agenda posted In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445005372_1838468" Subject: [pkix] Agenda posted X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:56:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445005372_1838468 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit An agenda for the PKIX meeting in Orlando has been posted. http://www.ietf.org/proceedings/86/agenda/agenda-86-pkix I have not yet got confirmation from the est editors but assume some of the authors will provide an update presentation. /Stefan --B_3445005372_1838468 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
An agenda for the PKIX meeti= ng in Orlando has been posted.


I have not yet got = confirmation from the est editors but assume some of the authors will provid= e an update presentation.

/Stefan

<= /html> --B_3445005372_1838468-- From denis.pinkas@bull.net Mon Mar 4 00:43:09 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F241721F88BE for ; Mon, 4 Mar 2013 00:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS9wNt7zwZbw for ; Mon, 4 Mar 2013 00:43:04 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3C44A21F88E1 for ; Mon, 4 Mar 2013 00:43:00 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id C88B31D297; Mon, 4 Mar 2013 09:42:58 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013030409425813-509 ; Mon, 4 Mar 2013 09:42:58 +0100 Message-ID: <51345E8D.3070601@bull.net> Date: Mon, 04 Mar 2013 09:42:53 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stefan Santesson , pkix X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 04/03/2013 09:42:58, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 04/03/2013 09:42:58, Serialize complete at 04/03/2013 09:42:58 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------070304040505030409010200" Subject: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 08:43:09 -0000 This is a multi-part message in MIME format. --------------070304040505030409010200 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 --------------070304040505030409010200 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1

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

 

 

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 {

          contextType     UTF8String,

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

--------------070304040505030409010200-- From stefan@aaa-sec.com Mon Mar 4 02:10:40 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5421F87FF for ; Mon, 4 Mar 2013 02:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.04 X-Spam-Level: X-Spam-Status: No, score=-99.04 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m68VrtCOlCd1 for ; Mon, 4 Mar 2013 02:10:34 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id C295221F8757 for ; Mon, 4 Mar 2013 02:10:32 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id DB96751DD5E for ; Mon, 4 Mar 2013 11:10:30 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rU8sGV7jQ7UX for ; Mon, 4 Mar 2013 11:10:21 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D830C51DE69 for ; Mon, 4 Mar 2013 11:09:56 +0100 (CET) Received: (qmail 8487 invoked from network); 4 Mar 2013 10:09:56 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Mar 2013 10:09:56 -0000 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 04 Mar 2013 11:09:56 +0100 From: Stefan Santesson To: Denis Pinkas , pkix Message-ID: Thread-Topic: Comments on draft-santesson-auth-context-extension-04 In-Reply-To: <51345E8D.3070601@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445240198_371853" Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 10:10:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445240198_371853 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 identif= y 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 Date: Monday, March 4, 2013 9:42 AM To: Stefan Santesson , pkix Subject: Comments on draft-santesson-auth-context-extension-04 > =20 > =20 >=20 > Stefan, > =20 > =20 >=20 > =20 > =20 > 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. > =20 > =20 > =20 No you got this wrong. This is not an Identifier. > =20 > =20 > MAJOR COMMENTS > =20 > =20 > =20 > 1. The proposed draft is not aligned with the current practices of RFC 52= 80 > and X.509:=20 > the right place to hold such a set of attributes is in the subject alter= nate > name.=20 > The subject DN may or may not be empty. > =20 > =20 > =20 > There is no rational in this draft to explain why this straightforward > approach has not been chosen. > =20 > =20 > =20 > SubjectAltName ::=3D GeneralNames > =20 > =20 > =20 > GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName > =20 > =20 > =20 > GeneralName ::=3D CHOICE { > =20 > otherName [0] OtherName, > =20 > rfc822Name [1] IA5String, > =20 > dNSName [2] IA5String, > =20 > x400Address [3] ORAddress, > =20 > directoryName [4] Name, > =20 > ediPartyName [5] EDIPartyName, > =20 > uniformResourceIdentifier [6] IA5String, > =20 > iPAddress [7] OCTET STRING, > =20 > registeredID [8] OBJECT IDENTIFIER } > =20 > =20 > =20 > OtherName ::=3D SEQUENCE { > =20 > type-id OBJECT IDENTIFIER, > =20 > value [0] EXPLICIT ANY DEFINED BY type-id } > =20 > =20 > =20 > OtherName fits well with the requirements, if you accept to use an OID ra= ther > than=20 > a uniformResourceIdentifier. > =20 > =20 > =20 > The value component would contain an XML structure conformant with a XML > schema. > =20 > =20 > =20 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 w= e do not create or store an identifier. > =20 > =20 > 2. The document should be restructured to define: > =20 > (a) the general way to answer to the requirements, and > (b) a specific profile, in an Appendix, so that other RFCs could refer t= o the > main body of the document. > =20 > =20 > =20 That could be one way to do it. > =20 > =20 > DETAILED COMMENTS > =20 > =20 > =20 > 3. The proposed structure is not appropriate. > =20 > =20 > =20 > a) Why is there a need to have a SEQUENCE ? This should be avoided. > =20 > b) Why is contextInfo OPTIONAL? This should be avoided. > =20 > =20 > =20 > AuthenticationContexts ::=3D SEQUENCE SIZE (1..MAX) OF > =20 > AuthenticationContext > =20 > =20 > =20 > AuthenticationContext ::=3D SEQUENCE { > =20 > contextType UTF8String, > =20 > contextInfo UTF8String OPTIONAL > =20 > } > =20 For exactly the same reason why SAML AuthContextClassRef in a SAML assertio= n 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. > =20 > =20 > =20 > =20 > 4. The text states: This extension MAY be marked critical. > =20 > =20 > =20 > If the alternate name is present, why should there be a DN ? > =20 > =20 This comment must be based on a misunderstanding of the scope of this document. > =20 > =20 > =20 > =20 > 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. > =20 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. > =20 > =20 > =20 > =20 > 6. The vocabulary used in sections 3.1 and 3.2 is confusing and should be > changed. > =20 > =20 > =20 > An example: =B3AuthContextInfo Element=B2 does not exist. However, it is bett= er to > state that the contextInfo component > contains an XML structure which must conform to an XML schema. > =20 > =20 > =20 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. > =20 > =20 > 7. The XML structure proposed to fit inside contextInfo is overly complex= . > =20 > =20 > =20 > AuthenticationInstant is mandatory, whereas it is not needed. This information is always available from the SAML assertion and is considered fundamental, thus required. > =20 > AssertionRef is not needed. > =20 > ServiceID is not needed. > =20 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 (whic= h unfortunately can't be included in the spec): http://aaa-sec.com/eid2/sigsupport/XMLschema/AuthContExtDoc/index.html > =20 > =20 > =20 > =20 > 8. There are no matching rules defined. This means that the verification = of > the content of that field is not possible. > =20 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.=20 But I could actually add some text to clarify this. > =20 > =20 > =20 > =20 > 9. In section 3.2, I failed to understand the explanations for CertRef as= well > as for rdn and san. > =20 > =20 > =20 > Why CertNameType cannot be =B3factorized=B2 ? (in the example from Page 15, t= here > 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. > =20 > =20 > =20 > "rdn" The SAML attribute value is placed in the > =20 > subject field of the certificate in a > =20 > present Relative Distinguished Name > =20 > attribute. > =20 > =20 > =20 > "san" The SAML attribute value is placed in the > =20 > Subject Alternative Name extension of the > =20 > certificate. > =20 > =20 > =20 > I also failed to understand the reason of such =B3mapping=B2. Yes, and I think that is the reason behind most of your comments. >=20 > The example in Appendix C illustrates the complexity of the proposal. > Can the approach be made simpler ? If not, why ? > =20 > =20 > =20 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 authenticatio= n 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. > =20 > =20 > 10. In section 4, I failed to understand the =B3dynamic=B2 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 wo= rds > =B3dynamic manner=B2. > =20 > =20 Your view is to restrictive. The dynamic aspect of this is that a certificate may be issued on the fly a= t 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 servic= e 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 kno= w exactly what identity information each certificate carries, as it maps to the attribute profile of a SAML federation. /Stefan >=20 > =20 > =20 > Denis > =20 > =20 --B_3445240198_371853 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis,

<= div>First, thanks for your review. I really appreciate it.

It seems to me, especially with your leading concluding comment, tha= t you have missed out on what this specification attempts to do.
P= erhaps you did not read the introduction enough, or perhaps I didn't write i= t clear enough.

The purpose is not to associate the= subject with a identifier composed of a set of attributes.
That i= s, this is NOT a new name form.

This extension help= s 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 thi= s extension can tell you where this string came from.

The use case addressed is where the CA/RA obtains the authenticated ident= ify from a SAML assertion when issuing the certificate.
This exten= sion provides means to preserve information about the original SAML attribut= es in the cert.


From: Denis Pinkas <den= is.pinkas@bull.net>
Date: M= onday, March 4, 2013 9:42 AM
To: S= tefan Santesson <stefan@aaa-sec.com>, pkix <pkix@ietf.org>
Subject: Comments on draft-santesson-aut= h-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 wro= ng. 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 ::=3D GeneralNames

 

   GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName

 

   GeneralName ::=3D CHOICE {

       = ; otherName    &nb= sp;            &= nbsp;     [0] = ;    OtherName,

       = ; rfc822Name    &n= bsp;            =      [1] &nbs= p;   IA5String,

       = ; dNSName     = ;            &nb= sp;       [2]     IA5String,

       = ; x400Address    &= nbsp;            = ;    [3]  &nb= sp;  ORAddress,

       = ; directoryName    = ;            &nb= sp;  [4]     = Name,

       = ; ediPartyName    =             &nbs= p;   [5]   &n= bsp; EDIPartyName,

       = ; uniformResourceIdentifier  = ;     [6] &nb= sp;   IA5String,

       = ; iPAddress    &nb= sp;            &= nbsp;     [7] = ;    OCTET STRING,

       = ; registeredID    =             &nbs= p;   [8]   &n= bsp; OBJECT IDENTIFIER }

 

   OtherName ::=3D SEQUENCE {

       = ; type-id    OBJ= ECT 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 c= reate 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 w= ay 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.

 

      Aut= henticationContexts ::=3D SEQUENCE SIZE (1..MAX) OF

       = ;            &nb= sp;             AuthenticationContext

 

      Aut= henticationContext ::=3D SEQUENCE {

       = ;   contextType  &= nbsp;  UTF8String,

       = ;   contextInfo  &= nbsp;  UTF8String OPTIONAL

      }


For exactly the sam= e reason why SAML AuthContextClassRef in a SAML assertion is mandatory but n= ot the XML structure it defines.
In some cases you don't want to i= nclude explicit data, if that data is static and can be implicitly known thr= ough 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 de= fine both a static XML document with fixed values as well as a structure whe= re different values can be entered.

Just including = the reference to the XML Schema may then provide sufficient information to t= he relying party. The actual XML document is only included if some variable = data need to be communicated within the associated XML document.
<= br>
Just including contextType but not contextInfo could be compar= ed with the case where we include a certificate policy OID, but not the enti= re policy text.

This is a really smart way to do th= is, 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 b= e based on a misunderstanding of the scope of this document.

<= /div>

<= span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB"> 

 

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 infor= mation is there.
I think it is quite common to place programatic c= ontracts in Appendixes, wile explaining data elements in the body of the doc= ument.

 

 

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 s= chema. XML Schema defines syntax and structure but not the semantics. Semant= ics 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 c= onsidered 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 a= re.
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 woul= d be if this was an identifier that as a whole should be compared with somet= hing else.

The SAML attribute value does not have t= o match the value of the cert attribute, this data in the extension is optio= nal and, if present, is a hint. 
But I could actually add som= e 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 on= e e-mail attribute that was placed in the SubjAltName extension of the cert.=

 

       = ;            &nb= sp;  "rdn"   The = SAML attribute value is placed in the

       = ;            &nb= sp;          subject field of the certificate in a

       = ;            &nb= sp;          present Relative Distinguished Name

       = ;            &nb= sp;          attribute.

 

       = ;            &nb= sp;  "san"   The = SAML attribute value is placed in the

       = ;            &nb= sp;          Subject Alternative Name extension of the<= /p>

       = ;            &nb= sp;          certificate.

 

I also failed to understand the reason of such “mapping”.

<= div>
Yes, and I think that is the reason behind most of your c= omments.

<= p class=3D"MsoPlainText"> The example in Appendix C illustrates the complexity of the proposal.
Can the approach be made simpler ? If not, why ?
<= /p>

 


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 s= hould be clear.

Consider the case where you know us= ers by attributes defined in a SAML federation, where for example serialNumb= er is NOT used.
A CA issues a certificate to a user based an a SAM= L assertion authentication based on the attribute profile of that federation= .

A user logs in to your service using a SAML asser= tion, and sends you a signed document associated with the issued certificate= .
You now need to determine whether that SAML assertion and the ce= rtificate represents the same user.
You also need to determine tha= t the SAML assertion and the certificate provides compatible levels of asser= tion for user authentication as defined in your SAML federation.
<= br>
This extension gives you exactly the amount of data that is ne= eded in order to do this in an unambiguous fully automated process.

 

10. In section 4, I failed to understand the “dynamic” aspect. My understan= ding 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 n= eeded, containing just the information that is needed for one particular sit= uation.
This extension is (where this is used in the Swedish natio= nal infrastructure) added to certificates that are issued for just one insta= nce of signing, and hence can be dynamically adapted to the needs of the int= ended relying party.

Next time the user signs, a ne= w key pair is generated with new certs that may contain another set of the u= ser's attributes.

The first instance may for exampl= e contain the users private identity based on a national identifier, the sec= ond may carry an organisational identity based on employee number.
What attributes that are needed in every instance is determined in a servic= e 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 t= o know exactly what identity information each certificate carries, as it map= s to the attribute profile of a SAML federation.

/S= tefan


Denis
=

--B_3445240198_371853-- From md@e-net.lt Mon Mar 4 02:26:59 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED4F21F8925 for ; Mon, 4 Mar 2013 02:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhdextGLF0jX for ; Mon, 4 Mar 2013 02:26:55 -0800 (PST) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1C39721F891D for ; Mon, 4 Mar 2013 02:26:54 -0800 (PST) Received: from [84.240.23.136] (helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1UCSba-0007Y2-NG; Mon, 04 Mar 2013 12:26:50 +0200 Message-ID: <513476E0.5040300@e-net.lt> Date: Mon, 04 Mar 2013 12:26:40 +0200 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040409070101020509060801" Cc: pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 10:26:59 -0000 This is a multi-part message in MIME format. --------------040409070101020509060801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > > Date: Monday, March 4, 2013 9:42 AM > To: Stefan Santesson >, > pkix > > Subject: Comments on draft-santesson-auth-context-extension-04 > > Stefan, > > > The goal of this document is to associate a public key to be used > for verifying electronic signatures > with an identifier composed of a set of attributes, typically SAML > attributes, contained in an authentication token. > > > No you got this wrong. This is not an Identifier. > > MAJOR COMMENTS > > 1.The proposed draft is not aligned with the current practices of > RFC 5280 and X.509: > the right place to hold such a set of attributes is in the subject > alternate name. > The subject DN may or may not be empty. > > There is no rational in this draft to explain why this > straightforward approach has not been chosen. > > SubjectAltName ::= GeneralNames > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > GeneralName ::= CHOICE { > > otherName[0]OtherName, > > rfc822Name[1]IA5String, > > dNSName[2]IA5String, > > x400Address[3]ORAddress, > > directoryName[4]Name, > > ediPartyName[5]EDIPartyName, > > uniformResourceIdentifier[6]IA5String, > > iPAddress[7]OCTET STRING, > > registeredID[8]OBJECT IDENTIFIER } > > OtherName ::= SEQUENCE { > > type-idOBJECT IDENTIFIER, > > value[0] EXPLICIT ANY DEFINED BY type-id } > > OtherName fits well with the requirements, if you accept to use an > OID rather than > a uniformResourceIdentifier. > > The value component would contain an XML structure conformant with > a XML schema. > > > This draft does not contain an identifier, thus this comment is > irrelevant. > There is not explanation why we don't store an identifier as a SAN, > since we do not create or store an identifier. > > 2.The document should be restructured to define: > > (a) the general way to answer to the requirements, and > (b) a specific profile, in an Appendix, so that other RFCs could > refer to the main body of the document. > > > That could be one way to do it. > > DETAILED COMMENTS > > 3.The proposed structure is not appropriate. > > a) Why is there a need to have a SEQUENCE ? This should be avoided. > > b) Why is contextInfo OPTIONAL? This should be avoided. > > AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF > > AuthenticationContext > > AuthenticationContext ::= SEQUENCE { > > contextTypeUTF8String, > > contextInfoUTF8String OPTIONAL > > } > > > For exactly the same reason why SAML AuthContextClassRef in a SAML > assertion is mandatory but not the XML structure it defines. > In some cases you don't want to include explicit data, if that data is > static and can be implicitly known through an identifier. > > The AuthContextClassRef in SAML is the best example as it is an exact > functional replica of this. > The URL identified by AuthContextClassRef is also a XML Schema ns for > associated XML document. > > The XML Schema can define both a static XML document with fixed values > as well as a structure where different values can be entered. > > Just including the reference to the XML Schema may then provide > sufficient information to the relying party. The actual XML document > is only included if some variable data need to be communicated within > the associated XML document. > > Just including contextType but not contextInfo could be compared with > the case where we include a certificate policy OID, but not the entire > policy text. > > This is a really smart way to do this, which is made possible through > the versatility of XML Schemas. > > > 4.The text states: This extension MAY be marked critical. > > If the alternate name is present, why should there be a DN ? > > > This comment must be based on a misunderstanding of the scope of this > document. > > 5.The XML schema should be given first (Appendix B) followed by > the explanations (sections 3.1 and 3.2). > In other words, sections 3.1 and 3.2 should be placed in Appendix B. > > > That is one way to do it. If I was the implementer, I really wouldn't > care as long as the information is there. > I think it is quite common to place programatic contracts in > Appendixes, wile explaining data elements in the body of the document. > > 6.The vocabulary used in sections 3.1 and 3.2 is confusing and > should be changed. > > An example: "AuthContextInfo Element" does not exist. However, it > is better to state that the contextInfo component > contains an XML structure which must conform to an XML schema. > > > Sorry, I don't get this comment. The AuthContextInfo element does > exist. It is defined in the schema. XML Schema defines syntax and > structure but not the semantics. Semantics are defined the section 3. > > 7.The XML structure proposed to fit inside contextInfo is overly > complex. > > AuthenticationInstant is mandatory, whereas it is not needed. > > > This information is always available from the SAML assertion and is > considered fundamental, thus required. > > AssertionRef is not needed. > > ServiceID is not needed. > > > And hence, both are optional. > > The XML Schema is actually very simple. Its just the nature of XML > Schemas to look more complex than they actually are. > Perhaps it is easier if you examine it through this following web doc > (which unfortunately can't be included in the spec): > http://aaa-sec.com/eid2/sigsupport/XMLschema/AuthContExtDoc/index.html > > > 8.There are no matching rules defined. This means that the > verification of the content of that field is not possible. > > > First of all, this is not an identifier, thus there is no reason for a > matching rule is it would be if this was an identifier that as a whole > should be compared with something else. > > The SAML attribute value does not have to match the value of the cert > attribute, this data in the extension is optional and, if present, is > a hint. > But I could actually add some text to clarify this. > > 9.In section 3.2, I failed to understand the explanations for > CertRef as well as for rdn and san. > > Why CertNameType cannot be "factorized" ? (in the example from > Page 15, there are all the same). > > > No, the example in the spec has one e-mail attribute that was placed > in the SubjAltName extension of the cert. > > "rdn"The SAML attribute value is placed in the > > subject field of the certificate in a > > present Relative Distinguished Name > > attribute. > > "san"The SAML attribute value is placed in the > > Subject Alternative Name extension of the > > certificate. > > I also failed to understand the reason of such "mapping". > > > Yes, and I think that is the reason behind most of your comments. > > > The example in Appendix C illustrates the complexity of the proposal. > Can the approach be made simpler ? If not, why ? > > > No it can't be made simpler. It contains exactly the information we > need in the implementation where it is used. > > I could write a whole whitepaper about all detailed reasons, but if > you really think about the use case, it should be clear. > > Consider the case where you know users by attributes defined in a SAML > federation, where for example serialNumber is NOT used. > A CA issues a certificate to a user based an a SAML assertion > authentication based on the attribute profile of that federation. > > A user logs in to your service using a SAML assertion, and sends you a > signed document associated with the issued certificate. > You now need to determine whether that SAML assertion and the > certificate represents the same user. > You also need to determine that the SAML assertion and the certificate > provides compatible levels of assertion for user authentication as > defined in your SAML federation. > > This extension gives you exactly the amount of data that is needed in > order to do this in an unambiguous fully automated process. > > 10.In section 4, I failed to understand the "dynamic" aspect. My > understanding is that a person statically > authenticates to a RA (Registration Authority) and then is given > back a non-repudiation certificate > with SAML attributes in it which may then be used as identity > attributes. > I am unsure what the text in this section wants to say when using > the words "dynamic manner". > > > > Your view is to restrictive. > > The dynamic aspect of this is that a certificate may be issued on the > fly at the instance when it is needed, containing just the information > that is needed for one particular situation. > This extension is (where this is used in the Swedish national > infrastructure) added to certificates that are issued for just one > instance of signing, and hence can be dynamically adapted to the needs > of the intended relying party. > > Next time the user signs, a new key pair is generated with new certs > that may contain another set of the user's attributes. > > The first instance may for example contain the users private identity > based on a national identifier, the second may carry an organisational > identity based on employee number. > What attributes that are needed in every instance is determined in a > service context that is outside the scope of this specification. > > In these certificates, both the national identifier and the employee > number may be placed as a serialNumber attribute in the subject field. > Despite that, this extension makes it possible for the relying party > to know exactly what identity information each certificate carries, as > it maps to the attribute profile of a SAML federation. > > /Stefan > > > Denis > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------040409070101020509060801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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 <denis.pinkas@bull.net>
Date: Monday, March 4, 2013 9:42 AM
To: Stefan Santesson <stefan@aaa-sec.com>, pkix <pkix@ietf.org>
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):


 

 

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
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------040409070101020509060801-- From stefan@aaa-sec.com Mon Mar 4 03:58:04 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD10621F8881 for ; Mon, 4 Mar 2013 03:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.946 X-Spam-Level: X-Spam-Status: No, score=-99.946 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKPUK01Ty+MX for ; Mon, 4 Mar 2013 03:58:04 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E1CCF21F8845 for ; Mon, 4 Mar 2013 03:58:03 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id BB74651E7DA for ; Mon, 4 Mar 2013 12:58:01 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s9by-qaC8pV6 for ; Mon, 4 Mar 2013 12:58:01 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2257B4FB162 for ; Mon, 4 Mar 2013 12:58:01 +0100 (CET) Received: (qmail 18268 invoked from network); 4 Mar 2013 11:58:00 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Mar 2013 11:58:00 -0000 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 04 Mar 2013 12:58:00 +0100 From: Stefan Santesson To: "Moudrick M. Dadashov" Message-ID: Thread-Topic: [pkix] Comments on draft-santesson-auth-context-extension-04 In-Reply-To: <513476E0.5040300@e-net.lt> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445246683_762612" Cc: pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:58:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445246683_762612 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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" Date: Monday, March 4, 2013 11:26 AM To: Stefan Santesson Cc: Denis Pinkas , pkix 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. --B_3445246683_762612 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi,

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

The semantics identifier of ETSI TS 119 412-2 may be us= ed 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:
    <= li>Already gone through the pain of implementing identity semantics in the f= orm of a SAML attribute profile, and we need to leverage that also in certs.=
  1. 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 com= bined.

The SAML attribute value that is being place= d in a serialNumber attribute can be formatted according to the semantics id= entifier 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 serv= e the relying party that need to know the SAML origin of the attribute value= .

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

/Stefan


<= /div>

From: "Moudrick M. D= adashov" <md@e-net.lt>
Date: Monday, March 4, 2013 11:26 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Denis Pinkas <denis.p= inkas@bull.net>, pkix <pkix@ietf.or= g>
Subject: Re: [pkix] Comm= ents 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.




--B_3445246683_762612-- From stefan@aaa-sec.com Mon Mar 4 05:57:30 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C998B21F8A5F for ; Mon, 4 Mar 2013 05:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.493 X-Spam-Level: X-Spam-Status: No, score=-99.493 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFcgr-3VnP1q for ; Mon, 4 Mar 2013 05:57:23 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E91CA21F8A6B for ; Mon, 4 Mar 2013 05:57:22 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 7285051EE61 for ; Mon, 4 Mar 2013 14:57:20 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eo68Yh7JUZ76 for ; Mon, 4 Mar 2013 14:57:13 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 30AA351F12B for ; Mon, 4 Mar 2013 14:57:13 +0100 (CET) Received: (qmail 43338 invoked from network); 4 Mar 2013 13:57:12 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Mar 2013 13:57:12 -0000 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 04 Mar 2013 14:57:10 +0100 From: Stefan Santesson To: "Moudrick M. Dadashov" Message-ID: Thread-Topic: [pkix] Comments on draft-santesson-auth-context-extension-04 In-Reply-To: <513476E0.5040300@e-net.lt> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445253835_1241822" Cc: pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:57:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445253835_1241822 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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" Date: Monday, March 4, 2013 11:26 AM To: Stefan Santesson Cc: Denis Pinkas , pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 > =20 > =20 > On 3/4/2013 12:09 PM, Stefan Santesson wrote: > =20 > =20 >> =20 >> Denis, >> =20 >>=20 >> =20 >> =20 >> First, thanks for your review. I really appreciate it. >> =20 >>=20 >> =20 >> =20 >> It seems to me, especially with your leading concluding comment, that yo= u >> have missed out on what this specification attempts to do. >> =20 >> Perhaps you did not read the introduction enough, or perhaps I didn't wr= ite >> it clear enough. >> =20 >>=20 >> =20 >> =20 >> The purpose is not to associate the subject with a identifier composed o= f a >> set of attributes. >> =20 >> That is, this is NOT a new name form. >> =20 >>=20 >> =20 >> =20 >> This extension helps a relying party to understand the source of the ide= ntity >> information that is placed in the traditional identity fields of a >> certificate. >> =20 >> For example. If the serialNumber attributes holds the string "123456", t= hen >> this extension can tell you where this string came from. >> =20 >>=20 >> =20 >> =20 > How is this related to "semantics identifier" (ETSI TS 119 412-2) then? > =20 > M.D.=20 > =20 >> =20 >> The use case addressed is where the CA/RA obtains the authenticated iden= tify >> from a SAML assertion when issuing the certificate. >> =20 >> This extension provides means to preserve information about the original= SAML >> attributes in the cert. >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From: Denis Pinkas >> Date: Monday, March 4, 2013 9:42 AM >> To: Stefan Santesson , pkix >> Subject: Comments on draft-santesson-auth-context-extension-04 >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> Stefan, >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> 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. >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> No you got this wrong. This is not an Identifier. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> MAJOR COMMENTS >>> =20 >>> =20 >>> =20 >>> 1. The proposed draft is not aligned with the current practices of RFC = 5280 >>> and X.509:=20 >>> 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. >>> =20 >>> =20 >>> =20 >>> There is no rational in this draft to explain why this straightforward >>> approach has not been chosen. >>> =20 >>> =20 >>> =20 >>> SubjectAltName ::=3D GeneralNames >>> =20 >>> =20 >>> =20 >>> GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName >>> =20 >>> =20 >>> =20 >>> GeneralName ::=3D CHOICE { >>> =20 >>> otherName [0] OtherName, >>> =20 >>> rfc822Name [1] IA5String, >>> =20 >>> dNSName [2] IA5String, >>> =20 >>> x400Address [3] ORAddress, >>> =20 >>> directoryName [4] Name, >>> =20 >>> ediPartyName [5] EDIPartyName, >>> =20 >>> uniformResourceIdentifier [6] IA5String, >>> =20 >>> iPAddress [7] OCTET STRING, >>> =20 >>> registeredID [8] OBJECT IDENTIFIER } >>> =20 >>> =20 >>> =20 >>> OtherName ::=3D SEQUENCE { >>> =20 >>> type-id OBJECT IDENTIFIER, >>> =20 >>> value [0] EXPLICIT ANY DEFINED BY type-id } >>> =20 >>> =20 >>> =20 >>> OtherName fits well with the requirements, if you accept to use an OID >>> rather than=20 >>> a uniformResourceIdentifier. >>> =20 >>> =20 >>> =20 >>> The value component would contain an XML structure conformant with a XM= L >>> schema. >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> This draft does not contain an identifier, thus this comment is irreleva= nt. >> =20 >> There is not explanation why we don't store an identifier as a SAN, sinc= e we >> do not create or store an identifier. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> 2. The document should be restructured to define: >>> =20 >>> (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. >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> That could be one way to do it. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> DETAILED COMMENTS >>> =20 >>> =20 >>> =20 >>> 3. The proposed structure is not appropriate. >>> =20 >>> =20 >>> =20 >>> a) Why is there a need to have a SEQUENCE ? This should be avoided. >>> =20 >>> b) Why is contextInfo OPTIONAL? This should be avoided. >>> =20 >>> =20 >>> =20 >>> AuthenticationContexts ::=3D SEQUENCE SIZE (1..MAX) OF >>> =20 >>> AuthenticationContext >>> =20 >>> =20 >>> =20 >>> AuthenticationContext ::=3D SEQUENCE { >>> =20 >>> contextType UTF8String, >>> =20 >>> contextInfo UTF8String OPTIONAL >>> =20 >>> } >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> For exactly the same reason why SAML AuthContextClassRef in a SAML asser= tion >> is mandatory but not the XML structure it defines. >> =20 >> In some cases you don't want to include explicit data, if that data is s= tatic >> and can be implicitly known through an identifier. >> =20 >>=20 >> =20 >> =20 >> The AuthContextClassRef in SAML is the best example as it is an exact >> functional replica of this. >> =20 >> The URL identified by AuthContextClassRef is also a XML Schema ns for >> associated XML document. >> =20 >>=20 >> =20 >> =20 >> The XML Schema can define both a static XML document with fixed values a= s >> well as a structure where different values can be entered. >> =20 >>=20 >> =20 >> =20 >> Just including the reference to the XML Schema may then provide sufficie= nt >> information to the relying party. The actual XML document is only includ= ed if >> some variable data need to be communicated within the associated XML >> document. >> =20 >>=20 >> =20 >> =20 >> Just including contextType but not contextInfo could be compared with th= e >> case where we include a certificate policy OID, but not the entire polic= y >> text. >> =20 >>=20 >> =20 >> =20 >> This is a really smart way to do this, which is made possible through th= e >> versatility of XML Schemas. >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> =20 >>> =20 >>> 4. The text states: This extension MAY be marked critical. >>> =20 >>> =20 >>> =20 >>> If the alternate name is present, why should there be a DN ? >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> This comment must be based on a misunderstanding of the scope of this >> document. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> =20 >>> =20 >>> 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. >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> That is one way to do it. If I was the implementer, I really wouldn't ca= re as >> long as the information is there. >> =20 >> I think it is quite common to place programatic contracts in Appendixes,= wile >> explaining data elements in the body of the document. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> =20 >>> =20 >>> 6. The vocabulary used in sections 3.1 and 3.2 is confusing and should = be >>> changed. >>> =20 >>> =20 >>> =20 >>> An example: =B3AuthContextInfo Element=B2 does not exist. However, it is be= tter >>> to state that the contextInfo component >>> contains an XML structure which must conform to an XML schema. >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> 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 no= t the >> semantics. Semantics are defined the section 3. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> 7. The XML structure proposed to fit inside contextInfo is overly compl= ex. >>> =20 >>> =20 >>> =20 >>> AuthenticationInstant is mandatory, whereas it is not needed. >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> This information is always available from the SAML assertion and is >> considered fundamental, thus required. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> AssertionRef is not needed. >>> =20 >>> ServiceID is not needed. >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> And hence, both are optional. >> =20 >>=20 >> =20 >> =20 >> The XML Schema is actually very simple. Its just the nature of XML Schem= as to >> look more complex than they actually are. >> =20 >> Perhaps it is easier if you examine it through this following web doc (w= hich >> unfortunately can't be included in the spec): >> =20 >> http://aaa-sec.com/eid2/sigsupport/XMLschema/AuthContExtDoc/index.html >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> =20 >>> =20 >>> 8. There are no matching rules defined. This means that the verificatio= n of >>> the content of that field is not possible. >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> 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 s= hould >> be compared with something else. >> =20 >>=20 >> =20 >> =20 >> 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. >> =20 >> But I could actually add some text to clarify this. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> =20 >>> =20 >>> 9. In section 3.2, I failed to understand the explanations for CertRef = as >>> well as for rdn and san. >>> =20 >>> =20 >>> =20 >>> Why CertNameType cannot be =B3factorized=B2 ? (in the example from Page 15, >>> there are all the same). >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> No, the example in the spec has one e-mail attribute that was placed in = the >> SubjAltName extension of the cert. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> =20 >>> "rdn" The SAML attribute value is placed in the >>> =20 >>> subject field of the certificate in a >>> =20 >>> present Relative Distinguished Name >>> =20 >>> attribute. >>> =20 >>> =20 >>> =20 >>> "san" The SAML attribute value is placed in the >>> =20 >>> Subject Alternative Name extension of the >>> =20 >>> certificate. >>> =20 >>> =20 >>> =20 >>> I also failed to understand the reason of such =B3mapping=B2. >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> Yes, and I think that is the reason behind most of your comments. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>>=20 >>> The example in Appendix C illustrates the complexity of the proposal. >>> Can the approach be made simpler ? If not, why ? >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >> No it can't be made simpler. It contains exactly the information we need= in >> the implementation where it is used. >> =20 >>=20 >> =20 >> =20 >> I could write a whole whitepaper about all detailed reasons, but if you >> really think about the use case, it should be clear. >> =20 >>=20 >> =20 >> =20 >> Consider the case where you know users by attributes defined in a SAML >> federation, where for example serialNumber is NOT used. >> =20 >> A CA issues a certificate to a user based an a SAML assertion authentica= tion >> based on the attribute profile of that federation. >> =20 >>=20 >> =20 >> =20 >> A user logs in to your service using a SAML assertion, and sends you a s= igned >> document associated with the issued certificate. >> =20 >> You now need to determine whether that SAML assertion and the certificat= e >> represents the same user. >> =20 >> You also need to determine that the SAML assertion and the certificate >> provides compatible levels of assertion for user authentication as defin= ed in >> your SAML federation. >> =20 >>=20 >> =20 >> =20 >> This extension gives you exactly the amount of data that is needed in or= der >> to do this in an unambiguous fully automated process. >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> 10. In section 4, I failed to understand the =B3dynamic=B2 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 attribut= es. >>> I am unsure what the text in this section wants to say when using the = words >>> =B3dynamic manner=B2. >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> Your view is to restrictive. >> =20 >>=20 >> =20 >> =20 >> The dynamic aspect of this is that a certificate may be issued on the fl= y at >> the instance when it is needed, containing just the information that is >> needed for one particular situation. >> =20 >> This extension is (where this is used in the Swedish national infrastruc= ture) >> 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 pa= rty. >> =20 >>=20 >> =20 >> =20 >> Next time the user signs, a new key pair is generated with new certs tha= t may >> contain another set of the user's attributes. >> =20 >>=20 >> =20 >> =20 >> The first instance may for example contain the users private identity ba= sed >> on a national identifier, the second may carry an organisational identit= y >> based on employee number. >> =20 >> What attributes that are needed in every instance is determined in a ser= vice >> context that is outside the scope of this specification. >> =20 >>=20 >> =20 >> =20 >> In these certificates, both the national identifier and the employee num= ber >> may be placed as a serialNumber attribute in the subject field. >> =20 >> Despite that, this extension makes it possible for the relying party to = know >> exactly what identity information each certificate carries, as it maps t= o the >> attribute profile of a SAML federation. >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>>=20 >>> =20 >>> =20 >>> Denis >>> =20 >>> =20 >>> =20 >>> =20 >> =20 >> =20 >> =20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix >> =20 > =20 > =20 --B_3445253835_1241822 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Based on comments received t= oday I have updated this draft, preliminary available at:
htt= p://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt

I have edited the Introduction section to clarify the s= cope of the document.

I have also added a new secti= on (now 3.2) that explains the absence of attribute matching rules.
The section should also make clear how specific attribute data format conv= entions, such as the one expressed in ETSI TS 119 412-2, can co-exist w= ith this extension.

/Stefan

From: "Moudrick M. Dadashov" <md@e-net.lt>
Dat= e: Monday, March 4, 2013 11:26 AM
= To: Stefan Santesson <stefan@= aaa-sec.com>
Cc: Denis Pink= as <denis.pinkas@bull.net>,= pkix <pkix@ietf.org>
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 <denis.pinkas@bull.net>
Date: Monday, March 4, 2013 9:42 AM
To: Stefan Santesson <st= efan@aaa-sec.com>, pkix <pk= ix@ietf.org>
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.<= /span>

 

   SubjectAltN= ame ::=3D GeneralNames

 

   GeneralName= s ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName

 

   GeneralName= ::=3D CHOICE {

     &= nbsp;  otherName   = ;            &nb= sp;       [0]     OtherName,

     &= nbsp;  rfc822Name  &nbs= p;            &n= bsp;      [1]=      IA5String,

     &= nbsp;  dNSName   &= nbsp;            = ;         [2]     IA5String,<= /p>

     &= nbsp;  x400Address  &nb= sp;            &= nbsp;     [3] = ;    ORAddress,

     &= nbsp;  directoryName  &= nbsp;            = ;    [4]  &nb= sp;  Name,

     &= nbsp;  ediPartyName  &n= bsp;            =      [5] &nbs= p;   EDIPartyName,

     &= nbsp;  uniformResourceIdentifier&= nbsp;      [6]     IA5String,

     &= nbsp;  iPAddress   = ;            &nb= sp;       [7]     OCTET STRING,

     &= nbsp;  registeredID  &n= bsp;            =      [8] &nbs= p;   OBJECT IDENTIFIER }

 

   OtherName := :=3D SEQUENCE {

     &= nbsp;  type-id    = OBJECT IDENTIFIER,

     &= nbsp;  value   &nb= sp;  [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.<= /span>

 

      = AuthenticationContexts ::=3D SEQUENCE SIZE (1..MAX) OF

     &= nbsp;            = ;            &nb= sp;  AuthenticationContext

 

      = AuthenticationContext ::=3D SEQUENCE {

     &= nbsp;    contextType&nb= sp;    UTF8String,

     &= nbsp;    contextInfo&nb= sp;    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 i= s 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 e= xist. 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):


 

 

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.

 

     &= nbsp;            = ;    "rdn"   = The SAML attribute value is placed in the

     &= nbsp;            = ;            subject field of the certificate in a

     &= nbsp;            = ;            present Relative Distinguished Name

     &= nbsp;            = ;            attribute.

 

     &= nbsp;            = ;    "san"   = The SAML attribute value is placed in the

     &= nbsp;            = ;            Subject Alternative Name extension of the

     &= nbsp;            = ;            certificate.

 

I also failed to understand the reason of such “mapping= 221;.


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̶= 1; 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
pkix@ietf.o=
rghttps://www.ietf.org/mailman/listinfo/pkix

--B_3445253835_1241822-- From denis.pinkas@bull.net Tue Mar 5 09:44:24 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3538921F8491 for ; Tue, 5 Mar 2013 09:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.342 X-Spam-Level: X-Spam-Status: No, score=-5.342 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjxIszt6AaVT for ; Tue, 5 Mar 2013 09:44:18 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 63CD81F0D12 for ; Tue, 5 Mar 2013 09:44:17 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 0E41E1D2FB; Tue, 5 Mar 2013 18:44:16 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013030518441498-4727 ; Tue, 5 Mar 2013 18:44:14 +0100 Message-ID: <51362EEB.6070802@bull.net> Date: Tue, 05 Mar 2013 18:44:11 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 05/03/2013 18:44:15, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 05/03/2013 18:44:16, Serialize complete at 05/03/2013 18:44:16 Content-Type: multipart/alternative; boundary="------------000803000105000106070705" Cc: pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 17:44:24 -0000 This is a multi-part message in MIME format. --------------000803000105000106070705 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, I read the new specification (dated March 4) and it does not solve my concerns. ** The real goal is stated at the top of page 4: *to verify that the signature was created by the same user that logged on * *to the service*. In your response below, you also say: "You now need to determine whether that SAML assertion and the certificate represents the same user." This is rather different from the goal stated on page 3: The primary purpose of this document is to provide a mechanism that allows an application to understand information that express the identity of a *subject in a certificate that is stored either in a* *subject field attribute, as a subject alternative name or in a* *subject directory attribute.* If we draw an analogy with the way to construct a DN, we do not mention that the DN was created after the presentation of a passport or an ID card, plus a way to justify the place of birth, a a way to justify the place of living, an that the country name was extracted from the presentation of the passport, etc ... So why should we do this in your context ? We need to store information in the certificate directly derived from the SAML token, so that the application which performed a SAML authentication can make sure that the certificate was delivered for the same person, by *making a comparison using some set of rules.** * So *t**here is a need to have matching rules* for the content of the SAML token with the content of the new extension (whatever it is). If we don't have such rules, then the goal at the top of page 4 cannot be met. I do not see the added value to explain some translation process since it would be used for audit purposes only and the CA MUST anyway maintain information about the issuance of the token. So in case of a problem, the CA SHALL be able to answer and it is not needed to overload the content of the certificate with more information. I still believe that OtherName is the right place to contains the parameters extracted from the SAML token, that will be used for comparison. Denis PS. I wonder whether we should continue to have in mind to have this document issued as an RFC. It may well be a national Swedish standard. > Based on comments received today I have updated this draft, > preliminary available at: > http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt > > I have edited the Introduction section to clarify the scope of the > document. > > I have also added a new section (now 3.2) that explains the absence of > attribute matching rules. > The section should also make clear how specific attribute data format > conventions, such as the one expressed in ETSI TS 119 412-2, can > co-exist with this extension. > > /Stefan > > From: "Moudrick M. Dadashov" > > Date: Monday, March 4, 2013 11:26 AM > To: Stefan Santesson > > Cc: Denis Pinkas >, pkix > > 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 > > >> Date: Monday, March 4, 2013 9:42 AM >> To: Stefan Santesson > >, pkix > > >> Subject: Comments on draft-santesson-auth-context-extension-04 >> >> Stefan, >> >> >> The goal of this document is to associate a public key to be >> used for verifying electronic signatures >> with an identifier composed of a set of attributes, typically >> SAML attributes, contained in an authentication token. >> >> >> No you got this wrong. This is not an Identifier. >> >> MAJOR COMMENTS >> >> 1.The proposed draft is not aligned with the current >> practices of RFC 5280 and X.509: >> the right place to hold such a set of attributes is in the >> subject alternate name. >> The subject DN may or may not be empty. >> >> There is no rational in this draft to explain why this >> straightforward approach has not been chosen. >> >> SubjectAltName ::= GeneralNames >> >> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName >> >> GeneralName ::= CHOICE { >> >> otherName[0]OtherName, >> >> rfc822Name[1]IA5String, >> >> dNSName[2]IA5String, >> >> x400Address[3]ORAddress, >> >> directoryName[4]Name, >> >> ediPartyName[5]EDIPartyName, >> >> uniformResourceIdentifier[6]IA5String, >> >> iPAddress[7]OCTET STRING, >> >> registeredID[8]OBJECT IDENTIFIER } >> >> OtherName ::= SEQUENCE { >> >> type-idOBJECT IDENTIFIER, >> >> value[0] EXPLICIT ANY DEFINED BY type-id } >> >> OtherName fits well with the requirements, if you accept to >> use an OID rather than >> a uniformResourceIdentifier. >> >> The value component would contain an XML structure conformant >> with a XML schema. >> >> >> This draft does not contain an identifier, thus this comment is >> irrelevant. >> There is not explanation why we don't store an identifier as a >> SAN, since we do not create or store an identifier. >> >> 2.The document should be restructured to define: >> >> (a) the general way to answer to the requirements, and >> (b) a specific profile, in an Appendix, so that other RFCs >> could refer to the main body of the document. >> >> >> That could be one way to do it. >> >> DETAILED COMMENTS >> >> 3.The proposed structure is not appropriate. >> >> a) Why is there a need to have a SEQUENCE ? This should be >> avoided. >> >> b) Why is contextInfo OPTIONAL? This should be avoided. >> >> AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF >> >> AuthenticationContext >> >> AuthenticationContext ::= SEQUENCE { >> >> contextTypeUTF8String, >> >> contextInfoUTF8String OPTIONAL >> >> } >> >> >> For exactly the same reason why SAML AuthContextClassRef in a >> SAML assertion is mandatory but not the XML structure it defines. >> In some cases you don't want to include explicit data, if that >> data is static and can be implicitly known through an identifier. >> >> The AuthContextClassRef in SAML is the best example as it is an >> exact functional replica of this. >> The URL identified by AuthContextClassRef is also a XML Schema ns >> for associated XML document. >> >> The XML Schema can define both a static XML document with fixed >> values as well as a structure where different values can be entered. >> >> Just including the reference to the XML Schema may then provide >> sufficient information to the relying party. The actual XML >> document is only included if some variable data need to be >> communicated within the associated XML document. >> >> Just including contextType but not contextInfo could be compared >> with the case where we include a certificate policy OID, but not >> the entire policy text. >> >> This is a really smart way to do this, which is made possible >> through the versatility of XML Schemas. >> >> >> 4.The text states: This extension MAY be marked critical. >> >> If the alternate name is present, why should there be a DN ? >> >> >> This comment must be based on a misunderstanding of the scope of >> this document. >> >> 5.The XML schema should be given first (Appendix B) followed >> by the explanations (sections 3.1 and 3.2). >> In other words, sections 3.1 and 3.2 should be placed in >> Appendix B. >> >> >> That is one way to do it. If I was the implementer, I really >> wouldn't care as long as the information is there. >> I think it is quite common to place programatic contracts in >> Appendixes, wile explaining data elements in the body of the >> document. >> >> 6.The vocabulary used in sections 3.1 and 3.2 is confusing >> and should be changed. >> >> An example: "AuthContextInfo Element" does not exist. >> However, it is better to state that the contextInfo component >> contains an XML structure which must conform to an XML schema. >> >> >> Sorry, I don't get this comment. The AuthContextInfo element does >> exist. It is defined in the schema. XML Schema defines syntax and >> structure but not the semantics. Semantics are defined the section 3. >> >> 7.The XML structure proposed to fit inside contextInfo is >> overly complex. >> >> AuthenticationInstant is mandatory, whereas it is not needed. >> >> >> This information is always available from the SAML assertion and >> is considered fundamental, thus required. >> >> AssertionRef is not needed. >> >> ServiceID is not needed. >> >> >> And hence, both are optional. >> >> The XML Schema is actually very simple. Its just the nature of >> XML Schemas to look more complex than they actually are. >> Perhaps it is easier if you examine it through this following web >> doc (which unfortunately can't be included in the spec): >> http://aaa-sec.com/eid2/sigsupport/XMLschema/AuthContExtDoc/index.html >> >> >> 8.There are no matching rules defined. This means that the >> verification of the content of that field is not possible. >> >> >> First of all, this is not an identifier, thus there is no reason >> for a matching rule is it would be if this was an identifier that >> as a whole should be compared with something else. >> >> The SAML attribute value does not have to match the value of the >> cert attribute, this data in the extension is optional and, if >> present, is a hint. >> But I could actually add some text to clarify this. >> >> 9.In section 3.2, I failed to understand the explanations for >> CertRef as well as for rdn and san. >> >> Why CertNameType cannot be "factorized" ? (in the example >> from Page 15, there are all the same). >> >> >> No, the example in the spec has one e-mail attribute that was >> placed in the SubjAltName extension of the cert. >> >> "rdn"The SAML attribute value is placed in the >> >> subject field of the certificate in a >> >> present Relative Distinguished Name >> >> attribute. >> >> "san"The SAML attribute value is placed in the >> >> Subject Alternative Name extension of the >> >> certificate. >> >> I also failed to understand the reason of such "mapping". >> >> >> Yes, and I think that is the reason behind most of your comments. >> >> >> The example in Appendix C illustrates the complexity of the >> proposal. >> Can the approach be made simpler ? If not, why ? >> >> >> No it can't be made simpler. It contains exactly the information >> we need in the implementation where it is used. >> >> I could write a whole whitepaper about all detailed reasons, but >> if you really think about the use case, it should be clear. >> >> Consider the case where you know users by attributes defined in a >> SAML federation, where for example serialNumber is NOT used. >> A CA issues a certificate to a user based an a SAML assertion >> authentication based on the attribute profile of that federation. >> >> A user logs in to your service using a SAML assertion, and sends >> you a signed document associated with the issued certificate. >> You now need to determine whether that SAML assertion and the >> certificate represents the same user. >> You also need to determine that the SAML assertion and the >> certificate provides compatible levels of assertion for user >> authentication as defined in your SAML federation. >> >> This extension gives you exactly the amount of data that is >> needed in order to do this in an unambiguous fully automated process. >> >> 10.In section 4, I failed to understand the "dynamic" aspect. >> My understanding is that a person statically >> authenticates to a RA (Registration Authority) and then is >> given back a non-repudiation certificate >> with SAML attributes in it which may then be used as identity >> attributes. >> I am unsure what the text in this section wants to say when >> using the words "dynamic manner". >> >> >> >> Your view is to restrictive. >> >> The dynamic aspect of this is that a certificate may be issued on >> the fly at the instance when it is needed, containing just the >> information that is needed for one particular situation. >> This extension is (where this is used in the Swedish national >> infrastructure) added to certificates that are issued for just >> one instance of signing, and hence can be dynamically adapted to >> the needs of the intended relying party. >> >> Next time the user signs, a new key pair is generated with new >> certs that may contain another set of the user's attributes. >> >> The first instance may for example contain the users private >> identity based on a national identifier, the second may carry an >> organisational identity based on employee number. >> What attributes that are needed in every instance is determined >> in a service context that is outside the scope of this specification. >> >> In these certificates, both the national identifier and the >> employee number may be placed as a serialNumber attribute in the >> subject field. >> Despite that, this extension makes it possible for the relying >> party to know exactly what identity information each certificate >> carries, as it maps to the attribute profile of a SAML federation. >> >> /Stefan >> >> >> Denis >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix > --------------000803000105000106070705 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
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:

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" <md@e-net.lt>
Date: Monday, March 4, 2013 11:26 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Denis Pinkas <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
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 <denis.pinkas@bull.net>
Date: Monday, March 4, 2013 9:42 AM
To: Stefan Santesson <stefan@aaa-sec.com>, pkix <pkix@ietf.org>
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):


 

 

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
pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix


--------------000803000105000106070705-- From stefan@aaa-sec.com Tue Mar 5 16:27:30 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2253611E80A5 for ; Tue, 5 Mar 2013 16:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.725 X-Spam-Level: X-Spam-Status: No, score=-98.725 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyJ3oToDJUK5 for ; Tue, 5 Mar 2013 16:27:20 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1276321F8523 for ; Tue, 5 Mar 2013 16:27:12 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 165544D9AA5 for ; Wed, 6 Mar 2013 01:27:10 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UcjATUqVIGcK for ; Wed, 6 Mar 2013 01:27:01 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id F013F4DB581 for ; Wed, 6 Mar 2013 01:27:00 +0100 (CET) Received: (qmail 95787 invoked from network); 6 Mar 2013 00:26:59 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 6 Mar 2013 00:26:59 -0000 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Wed, 06 Mar 2013 01:26:59 +0100 From: Stefan Santesson To: Denis Pinkas Message-ID: Thread-Topic: [pkix] Comments on draft-santesson-auth-context-extension-04 In-Reply-To: <51362EEB.6070802@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445378021_1641212" Cc: pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 00:27:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445378021_1641212 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Denis, Comments in line; From: Denis Pinkas Date: Tuesday, March 5, 2013 6:44 PM To: Stefan Santesson Cc: pkix , Sean Turner Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 > =20 > =20 > Stefan, > =20 > I read the new specification (dated March 4) and it does not solve my > concerns. > =20 > The real goal is stated at the top of page 4: >=20 >=20 > =20 > =20 > 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. > =20 > In your response below, you also say: > =20 > "You now need to determine whether that SAML assertion and the > certificate represents the same user." > =20 > This is rather different from the goal stated on page 3: > =20 > =20 >=20 > The primary purpose of this document is to provide a mechanism that > =20 > allows an application to understand information that express the > =20 > identity of a subject in a certificate that is stored either in a > =20 > subject field attribute, as a subject alternative name or in a > =20 > subject directory attribute. > =20 This is the primary function. This can be used to achieve the goal of the example use case above. There is no contradiction. >=20 > 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 ... > =20 > 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 no= t 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 no= t scale very well. > =20 > We need to store information in the certificate directly derived from th= e > 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. >=20 > So there is a need to have matching rules for the content of the SAML to= ken > with the content of > the new extension (whatever it is). If we don't have such rules, then th= e > 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 i= t 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 th= e scope of this document. > =20 > I do not see the added value to explain some translation process since i= t > 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 million= s 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. > =20 > I still believe that OtherName is the right place to contains the parame= ters > 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 > =20 > Denis=20 > =20 > =20 > PS. I wonder whether we should continue to have in mind to have this doc= ument > issued as an RFC. > It may well be a national Swedish standard. > =20 > =20 > =20 >> =20 >> Based on comments received today I have updated this draft, preliminary >> available at: >> =20 >> http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt >> =20 >>=20 >> =20 >> =20 >> I have edited the Introduction section to clarify the scope of the docum= ent. >> =20 >>=20 >> =20 >> =20 >> I have also added a new section (now 3.2) that explains the absence of >> attribute matching rules. >> =20 >> 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-exis= t >> with this extension. >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >> From: "Moudrick M. Dadashov" >> Date: Monday, March 4, 2013 11:26 AM >> To: Stefan Santesson >> Cc: Denis Pinkas , pkix >> Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension= -04 >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> On 3/4/2013 12:09 PM, Stefan Santesson wrote: >>> =20 >>> =20 >>>> =20 >>>> Denis, >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> First, thanks for your review. I really appreciate it. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> It seems to me, especially with your leading concluding comment, that = you >>>> have missed out on what this specification attempts to do. >>>> =20 >>>> Perhaps you did not read the introduction enough, or perhaps I didn't = write >>>> it clear enough. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The purpose is not to associate the subject with a identifier composed= of a >>>> set of attributes. >>>> =20 >>>> That is, this is NOT a new name form. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> 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. >>>> =20 >>>> For example. If the serialNumber attributes holds the string "123456",= then >>>> this extension can tell you where this string came from. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>> How is this related to "semantics identifier" (ETSI TS 119 412-2) then= ? >>> =20 >>> M.D.=20 >>> =20 >>>> =20 >>>> The use case addressed is where the CA/RA obtains the authenticated >>>> identify from a SAML assertion when issuing the certificate. >>>> =20 >>>> This extension provides means to preserve information about the origin= al >>>> SAML attributes in the cert. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> From: Denis Pinkas >>>> Date: Monday, March 4, 2013 9:42 AM >>>> To: Stefan Santesson , pkix >>>> Subject: Comments on draft-santesson-auth-context-extension-04 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> Stefan, >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> 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. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> No you got this wrong. This is not an Identifier. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> MAJOR COMMENTS >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 1. The proposed draft is not aligned with the current practices of RF= C >>>>> 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. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> There is no rational in this draft to explain why this straightforwar= d >>>>> approach has not been chosen. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> SubjectAltName ::=3D GeneralNames >>>>> =20 >>>>> =20 >>>>> =20 >>>>> GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName >>>>> =20 >>>>> =20 >>>>> =20 >>>>> GeneralName ::=3D CHOICE { >>>>> =20 >>>>> otherName [0] OtherName, >>>>> =20 >>>>> rfc822Name [1] IA5String, >>>>> =20 >>>>> dNSName [2] IA5String, >>>>> =20 >>>>> x400Address [3] ORAddress, >>>>> =20 >>>>> directoryName [4] Name, >>>>> =20 >>>>> ediPartyName [5] EDIPartyName, >>>>> =20 >>>>> uniformResourceIdentifier [6] IA5String, >>>>> =20 >>>>> iPAddress [7] OCTET STRING, >>>>> =20 >>>>> registeredID [8] OBJECT IDENTIFIER } >>>>> =20 >>>>> =20 >>>>> =20 >>>>> OtherName ::=3D SEQUENCE { >>>>> =20 >>>>> type-id OBJECT IDENTIFIER, >>>>> =20 >>>>> value [0] EXPLICIT ANY DEFINED BY type-id } >>>>> =20 >>>>> =20 >>>>> =20 >>>>> OtherName fits well with the requirements, if you accept to use an O= ID >>>>> rather than=20 >>>>> a uniformResourceIdentifier. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> The value component would contain an XML structure conformant with a = XML >>>>> schema. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This draft does not contain an identifier, thus this comment is irrele= vant. >>>> =20 >>>> There is not explanation why we don't store an identifier as a SAN, si= nce >>>> we do not create or store an identifier. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> 2. The document should be restructured to define: >>>>> =20 >>>>> (a) the general way to answer to the requirements, and >>>>> (b) a specific profile, in an Appendix, so that other RFCs could ref= er to >>>>> the main body of the document. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> That could be one way to do it. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> DETAILED COMMENTS >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 3. The proposed structure is not appropriate. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> a) Why is there a need to have a SEQUENCE ? This should be avoided. >>>>> =20 >>>>> b) Why is contextInfo OPTIONAL? This should be avoided. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> AuthenticationContexts ::=3D SEQUENCE SIZE (1..MAX) OF >>>>> =20 >>>>> AuthenticationContext >>>>> =20 >>>>> =20 >>>>> =20 >>>>> AuthenticationContext ::=3D SEQUENCE { >>>>> =20 >>>>> contextType UTF8String, >>>>> =20 >>>>> contextInfo UTF8String OPTIONAL >>>>> =20 >>>>> } >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> For exactly the same reason why SAML AuthContextClassRef in a SAML >>>> assertion is mandatory but not the XML structure it defines. >>>> =20 >>>> In some cases you don't want to include explicit data, if that data is >>>> static and can be implicitly known through an identifier. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The AuthContextClassRef in SAML is the best example as it is an exact >>>> functional replica of this. >>>> =20 >>>> The URL identified by AuthContextClassRef is also a XML Schema ns for >>>> associated XML document. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The XML Schema can define both a static XML document with fixed values= as >>>> well as a structure where different values can be entered. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Just including the reference to the XML Schema may then provide suffic= ient >>>> information to the relying party. The actual XML document is only incl= uded >>>> if some variable data need to be communicated within the associated XM= L >>>> document. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Just including contextType but not contextInfo could be compared with = the >>>> case where we include a certificate policy OID, but not the entire pol= icy >>>> text. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This is a really smart way to do this, which is made possible through = the >>>> versatility of XML Schemas. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 4. The text states: This extension MAY be marked critical. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> If the alternate name is present, why should there be a DN ? >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This comment must be based on a misunderstanding of the scope of this >>>> document. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 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. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> That is one way to do it. If I was the implementer, I really wouldn't = care >>>> as long as the information is there. >>>> =20 >>>> I think it is quite common to place programatic contracts in Appendixe= s, >>>> wile explaining data elements in the body of the document. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 6. The vocabulary used in sections 3.1 and 3.2 is confusing and shoul= d be >>>>> changed. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> An example: =B3AuthContextInfo Element=B2 does not exist. However, it is >>>>> better to state that the contextInfo component >>>>> contains an XML structure which must conform to an XML schema. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Sorry, I don't get this comment. The AuthContextInfo element does exis= t. It >>>> is defined in the schema. XML Schema defines syntax and structure but = not >>>> the semantics. Semantics are defined the section 3. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> 7. The XML structure proposed to fit inside contextInfo is overly com= plex. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> AuthenticationInstant is mandatory, whereas it is not needed. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This information is always available from the SAML assertion and is >>>> considered fundamental, thus required. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> AssertionRef is not needed. >>>>> =20 >>>>> ServiceID is not needed. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> And hence, both are optional. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The XML Schema is actually very simple. Its just the nature of XML Sch= emas >>>> to look more complex than they actually are. >>>> =20 >>>> Perhaps it is easier if you examine it through this following web doc >>>> (which unfortunately can't be included in the spec): >>>> =20 >>>> http://aaa-sec.com/eid2/sigsupport/XMLschema/AuthContExtDoc/index.html >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 8. There are no matching rules defined. This means that the verificat= ion >>>>> of the content of that field is not possible. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> 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. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> 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.=20 >>>> =20 >>>> But I could actually add some text to clarify this. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 9. In section 3.2, I failed to understand the explanations for CertRe= f as >>>>> well as for rdn and san. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> Why CertNameType cannot be =B3factorized=B2 ? (in the example from Page = 15, >>>>> there are all the same). >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> No, the example in the spec has one e-mail attribute that was placed i= n the >>>> SubjAltName extension of the cert. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> "rdn" The SAML attribute value is placed in t= he >>>>> =20 >>>>> subject field of the certificate in a >>>>> =20 >>>>> present Relative Distinguished Name >>>>> =20 >>>>> attribute. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> "san" The SAML attribute value is placed in t= he >>>>> =20 >>>>> Subject Alternative Name extension of t= he >>>>> =20 >>>>> certificate. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> I also failed to understand the reason of such =B3mapping=B2. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Yes, and I think that is the reason behind most of your comments. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> The example in Appendix C illustrates the complexity of the proposal= . >>>>> Can the approach be made simpler ? If not, why ? >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> No it can't be made simpler. It contains exactly the information we ne= ed in >>>> the implementation where it is used. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> I could write a whole whitepaper about all detailed reasons, but if yo= u >>>> really think about the use case, it should be clear. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Consider the case where you know users by attributes defined in a SAML >>>> federation, where for example serialNumber is NOT used. >>>> =20 >>>> A CA issues a certificate to a user based an a SAML assertion >>>> authentication based on the attribute profile of that federation. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> A user logs in to your service using a SAML assertion, and sends you a >>>> signed document associated with the issued certificate. >>>> =20 >>>> You now need to determine whether that SAML assertion and the certific= ate >>>> represents the same user. >>>> =20 >>>> You also need to determine that the SAML assertion and the certificate >>>> provides compatible levels of assertion for user authentication as def= ined >>>> in your SAML federation. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This extension gives you exactly the amount of data that is needed in = order >>>> to do this in an unambiguous fully automated process. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> 10. In section 4, I failed to understand the =B3dynamic=B2 aspect. My >>>>> understanding is that a person statically >>>>> authenticates to a RA (Registration Authority) and then is given bac= k a >>>>> non-repudiation certificate >>>>> with SAML attributes in it which may then be used as identity attrib= utes. >>>>> I am unsure what the text in this section wants to say when using th= e >>>>> words =B3dynamic manner=B2. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Your view is to restrictive. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> 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 tha= t is >>>> needed for one particular situation. >>>> =20 >>>> This extension is (where this is used in the Swedish national >>>> infrastructure) added to certificates that are issued for just one ins= tance >>>> of signing, and hence can be dynamically adapted to the needs of the >>>> intended relying party. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Next time the user signs, a new key pair is generated with new certs t= hat >>>> may contain another set of the user's attributes. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The first instance may for example contain the users private identity = based >>>> on a national identifier, the second may carry an organisational ident= ity >>>> based on employee number. >>>> =20 >>>> What attributes that are needed in every instance is determined in a >>>> service context that is outside the scope of this specification. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> In these certificates, both the national identifier and the employee n= umber >>>> may be placed as a serialNumber attribute in the subject field. >>>> =20 >>>> Despite that, this extension makes it possible for the relying party t= o >>>> know exactly what identity information each certificate carries, as it= maps >>>> to the attribute profile of a SAML federation. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> /Stefan >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> Denis >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix >>>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 > =20 > =20 --B_3445378021_1641212 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Denis,

Comments in line;

Fro= m: Denis Pinkas <denis.pin= kas@bull.net>
Date: Tuesday= , March 5, 2013 6:44 PM
To: Stefan= Santesson <stefan@aaa-sec.com>= ;
Cc: pkix <pkix@ietf.org>, Sean Turner <turners@ieca.com>
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.

N= o that is an example of what you might want to do with this.

<= /div>

In your response below, you also say:

      "You n= ow 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 c= ase 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. Els= e why bother?

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

<= div>Basically, if you have gone through the paint to teach every participati= ng service to understand user identity according to the SAML attribute profi= le, you may want to use that also to understand certificate entities.
<= div>
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 pu= t the finger on a problem that caused me to do another update to make this c= lear.

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, becaus= e the SAML attribute stored in this extension, when compared with anything o= utside 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 o= utside 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 ca= se 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 pro= cess must be well defined and automated.
The comparison between th= e SAML assertion the user presented at login, and the signature certificate = presented by the user in the same session will originate from multiple Idene= ity Providers and signature services, so just relying on local conventions d= oes not scale and is too static to provide a future proof solution.

Do I dare to say trust me? :) We have modelled and prototyp= ed 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.
<= /span>

No, for a number of reasons.

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

The biggest reason why this definitely can't be an other n= ame is because there is absolutely no guarantee that the content in this ext= ension 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 st= atic ruleset. In such case that schema identifier will be the same for all c= erts issued to various subjects.

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

/St= efan


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 Swedis= h standard.

=
Based on comments received today I have updated this draft, preliminary available at:

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" <md@e-net.lt>
Date: Monday, March 4, 2013 11:26 AM
To: Stefan Santesson <st= efan@aaa-sec.com>
Cc: Denis Pinkas <denis.pinkas@bull.n= et>, pkix <pk= ix@ietf.org>
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 <denis.pinkas@bull.net>
Date: Monday, March 4, 2013 9:42 AM
To: Stefan Santesson <stefan@aaa-sec.com>, pkix <pkix@ietf.org>
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.

 

   S= ubjectAltName ::=3D GeneralNames

 

   G= eneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName<= /o:p>

 

   G= eneralName ::=3D CHOICE {

   &nb= sp;    otherName &= nbsp;            = ;         [0] =     OtherName,

   &nb= sp;    rfc822Name =             &nbs= p;        [1] =     IA5String,

   &nb= sp;    dNSName &nb= sp;            &= nbsp;          [2] =     IA5String,

   &nb= sp;    x400Address = ;            &nb= sp;       [3] =     ORAddress,

   &nb= sp;    directoryName&nb= sp;            &= nbsp;     [4] =     Name,

   &nb= sp;    ediPartyName&nbs= p;            &n= bsp;      [5] =     EDIPartyName,

   &nb= sp;    uniformResourceIdentifier       [6]     IA5String,

   &nb= sp;    iPAddress &= nbsp;            = ;         [7] =     OCTET STRING,

   &nb= sp;    registeredID&nbs= p;            &n= bsp;      [8] =     OBJECT IDENTIFIER }

 

   O= therName ::=3D SEQUENCE {

   &nb= sp;    type-id &nb= sp;  OBJECT IDENTIFIER,

   &nb= sp;    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.
<= /p>

 

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.

 

   &nb= sp;  AuthenticationContexts ::=3D SEQUENCE SIZE (1..MAX) OF=

   &nb= sp;            &= nbsp;            = ;    AuthenticationContext<= /p>

 

   &nb= sp;  AuthenticationContext ::=3D SEQUENCE {

   &nb= sp;      contextType     UTF8String,

   &nb= sp;      contextInfo     UTF8String OPTIONAL

   &nb= sp;  }


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 examp= le 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.<= /span>

 

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.<= /p>


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


 

 

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.

 

   &nb= sp;            &= nbsp;     "rdn"&nbs= p;  The SAML attribute value is placed in the

   &nb= sp;            &= nbsp;            = ; subject field of the certificate in a

   &nb= sp;            &= nbsp;            = ; present Relative Distinguished Name=

   &nb= sp;            &= nbsp;            = ; attribute.

 

   &nb= sp;            &= nbsp;     "san"&nbs= p;  The SAML attribute value is placed in the

   &nb= sp;            &= nbsp;            = ; Subject Alternative Name extension of the

   &nb= sp;            &= nbsp;            = ; 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 “dynami= c 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
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix


--B_3445378021_1641212-- From stefan@aaa-sec.com Wed Mar 6 04:27:38 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78121F88EF for ; Wed, 6 Mar 2013 04:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.883 X-Spam-Level: X-Spam-Status: No, score=-98.883 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkr+ecG-MOmI for ; Wed, 6 Mar 2013 04:27:29 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFBC21F86D2 for ; Wed, 6 Mar 2013 04:27:28 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 20DED52EC13 for ; Wed, 6 Mar 2013 13:27:27 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5_m5FAzVk3lu for ; Wed, 6 Mar 2013 13:27:16 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A536952EDB2 for ; Wed, 6 Mar 2013 13:27:16 +0100 (CET) Received: (qmail 91016 invoked from network); 6 Mar 2013 12:27:16 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 6 Mar 2013 12:27:16 -0000 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Wed, 06 Mar 2013 13:27:20 +0100 From: Stefan Santesson To: Denis Pinkas Message-ID: Thread-Topic: [pkix] Comments on draft-santesson-auth-context-extension-04 In-Reply-To: <51362EEB.6070802@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445421244_2998215" Cc: pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:27:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445421244_2998215 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 extensio= n 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 a= s you suggested. /Stefan From: Denis Pinkas Date: Tuesday, March 5, 2013 6:44 PM To: Stefan Santesson Cc: pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 > =20 > =20 > Stefan, > =20 > I read the new specification (dated March 4) and it does not solve my > concerns. > =20 > The real goal is stated at the top of page 4: >=20 >=20 > =20 > =20 > to verify that the signature was created by the same user that logged on > to the service. > =20 > In your response below, you also say: > =20 > "You now need to determine whether that SAML assertion and the > certificate represents the same user." > =20 > This is rather different from the goal stated on page 3: > =20 > =20 > The primary purpose of this document is to provide a mechanism that > =20 > allows an application to understand information that express the > =20 > identity of a subject in a certificate that is stored either in a > =20 > subject field attribute, as a subject alternative name or in a > =20 > subject directory attribute. > =20 > 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 ... > =20 > So why should we do this in your context ? > =20 > We need to store information in the certificate directly derived from th= e > 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. > =20 > So there is a need to have matching rules for the content of the SAML to= ken > with the content of > the new extension (whatever it is). If we don't have such rules, then th= e > goal at the top of page 4 cannot be met. > =20 > I do not see the added value to explain some translation process since i= t > 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. > =20 > I still believe that OtherName is the right place to contains the parame= ters > extracted from the SAML token, > that will be used for comparison. > =20 > Denis=20 > =20 > =20 > PS. I wonder whether we should continue to have in mind to have this doc= ument > issued as an RFC. > It may well be a national Swedish standard. > =20 > =20 > =20 >> =20 >> Based on comments received today I have updated this draft, preliminary >> available at: >> =20 >> http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt >> =20 >>=20 >> =20 >> =20 >> I have edited the Introduction section to clarify the scope of the docum= ent. >> =20 >>=20 >> =20 >> =20 >> I have also added a new section (now 3.2) that explains the absence of >> attribute matching rules. >> =20 >> 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-exis= t >> with this extension. >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >> From: "Moudrick M. Dadashov" >> Date: Monday, March 4, 2013 11:26 AM >> To: Stefan Santesson >> Cc: Denis Pinkas , pkix >> Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension= -04 >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> On 3/4/2013 12:09 PM, Stefan Santesson wrote: >>> =20 >>> =20 >>>> =20 >>>> Denis, >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> First, thanks for your review. I really appreciate it. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> It seems to me, especially with your leading concluding comment, that = you >>>> have missed out on what this specification attempts to do. >>>> =20 >>>> Perhaps you did not read the introduction enough, or perhaps I didn't = write >>>> it clear enough. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The purpose is not to associate the subject with a identifier composed= of a >>>> set of attributes. >>>> =20 >>>> That is, this is NOT a new name form. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> 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. >>>> =20 >>>> For example. If the serialNumber attributes holds the string "123456",= then >>>> this extension can tell you where this string came from. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>> How is this related to "semantics identifier" (ETSI TS 119 412-2) then= ? >>> =20 >>> M.D.=20 >>> =20 >>>> =20 >>>> The use case addressed is where the CA/RA obtains the authenticated >>>> identify from a SAML assertion when issuing the certificate. >>>> =20 >>>> This extension provides means to preserve information about the origin= al >>>> SAML attributes in the cert. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> From: Denis Pinkas >>>> Date: Monday, March 4, 2013 9:42 AM >>>> To: Stefan Santesson , pkix >>>> Subject: Comments on draft-santesson-auth-context-extension-04 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> Stefan, >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> 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. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> No you got this wrong. This is not an Identifier. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> MAJOR COMMENTS >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 1. The proposed draft is not aligned with the current practices of RF= C >>>>> 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. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> There is no rational in this draft to explain why this straightforwar= d >>>>> approach has not been chosen. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> SubjectAltName ::=3D GeneralNames >>>>> =20 >>>>> =20 >>>>> =20 >>>>> GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName >>>>> =20 >>>>> =20 >>>>> =20 >>>>> GeneralName ::=3D CHOICE { >>>>> =20 >>>>> otherName [0] OtherName, >>>>> =20 >>>>> rfc822Name [1] IA5String, >>>>> =20 >>>>> dNSName [2] IA5String, >>>>> =20 >>>>> x400Address [3] ORAddress, >>>>> =20 >>>>> directoryName [4] Name, >>>>> =20 >>>>> ediPartyName [5] EDIPartyName, >>>>> =20 >>>>> uniformResourceIdentifier [6] IA5String, >>>>> =20 >>>>> iPAddress [7] OCTET STRING, >>>>> =20 >>>>> registeredID [8] OBJECT IDENTIFIER } >>>>> =20 >>>>> =20 >>>>> =20 >>>>> OtherName ::=3D SEQUENCE { >>>>> =20 >>>>> type-id OBJECT IDENTIFIER, >>>>> =20 >>>>> value [0] EXPLICIT ANY DEFINED BY type-id } >>>>> =20 >>>>> =20 >>>>> =20 >>>>> OtherName fits well with the requirements, if you accept to use an O= ID >>>>> rather than=20 >>>>> a uniformResourceIdentifier. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> The value component would contain an XML structure conformant with a = XML >>>>> schema. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This draft does not contain an identifier, thus this comment is irrele= vant. >>>> =20 >>>> There is not explanation why we don't store an identifier as a SAN, si= nce >>>> we do not create or store an identifier. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> 2. The document should be restructured to define: >>>>> =20 >>>>> (a) the general way to answer to the requirements, and >>>>> (b) a specific profile, in an Appendix, so that other RFCs could ref= er to >>>>> the main body of the document. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> That could be one way to do it. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> DETAILED COMMENTS >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 3. The proposed structure is not appropriate. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> a) Why is there a need to have a SEQUENCE ? This should be avoided. >>>>> =20 >>>>> b) Why is contextInfo OPTIONAL? This should be avoided. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> AuthenticationContexts ::=3D SEQUENCE SIZE (1..MAX) OF >>>>> =20 >>>>> AuthenticationContext >>>>> =20 >>>>> =20 >>>>> =20 >>>>> AuthenticationContext ::=3D SEQUENCE { >>>>> =20 >>>>> contextType UTF8String, >>>>> =20 >>>>> contextInfo UTF8String OPTIONAL >>>>> =20 >>>>> } >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> For exactly the same reason why SAML AuthContextClassRef in a SAML >>>> assertion is mandatory but not the XML structure it defines. >>>> =20 >>>> In some cases you don't want to include explicit data, if that data is >>>> static and can be implicitly known through an identifier. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The AuthContextClassRef in SAML is the best example as it is an exact >>>> functional replica of this. >>>> =20 >>>> The URL identified by AuthContextClassRef is also a XML Schema ns for >>>> associated XML document. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The XML Schema can define both a static XML document with fixed values= as >>>> well as a structure where different values can be entered. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Just including the reference to the XML Schema may then provide suffic= ient >>>> information to the relying party. The actual XML document is only incl= uded >>>> if some variable data need to be communicated within the associated XM= L >>>> document. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Just including contextType but not contextInfo could be compared with = the >>>> case where we include a certificate policy OID, but not the entire pol= icy >>>> text. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This is a really smart way to do this, which is made possible through = the >>>> versatility of XML Schemas. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 4. The text states: This extension MAY be marked critical. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> If the alternate name is present, why should there be a DN ? >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This comment must be based on a misunderstanding of the scope of this >>>> document. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 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. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> That is one way to do it. If I was the implementer, I really wouldn't = care >>>> as long as the information is there. >>>> =20 >>>> I think it is quite common to place programatic contracts in Appendixe= s, >>>> wile explaining data elements in the body of the document. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 6. The vocabulary used in sections 3.1 and 3.2 is confusing and shoul= d be >>>>> changed. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> An example: =B3AuthContextInfo Element=B2 does not exist. However, it is >>>>> better to state that the contextInfo component >>>>> contains an XML structure which must conform to an XML schema. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Sorry, I don't get this comment. The AuthContextInfo element does exis= t. It >>>> is defined in the schema. XML Schema defines syntax and structure but = not >>>> the semantics. Semantics are defined the section 3. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> 7. The XML structure proposed to fit inside contextInfo is overly com= plex. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> AuthenticationInstant is mandatory, whereas it is not needed. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This information is always available from the SAML assertion and is >>>> considered fundamental, thus required. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> AssertionRef is not needed. >>>>> =20 >>>>> ServiceID is not needed. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> And hence, both are optional. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The XML Schema is actually very simple. Its just the nature of XML Sch= emas >>>> to look more complex than they actually are. >>>> =20 >>>> Perhaps it is easier if you examine it through this following web doc >>>> (which unfortunately can't be included in the spec): >>>> =20 >>>> http://aaa-sec.com/eid2/sigsupport/XMLschema/AuthContExtDoc/index.html >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 8. There are no matching rules defined. This means that the verificat= ion >>>>> of the content of that field is not possible. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> 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. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> 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.=20 >>>> =20 >>>> But I could actually add some text to clarify this. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> 9. In section 3.2, I failed to understand the explanations for CertRe= f as >>>>> well as for rdn and san. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> Why CertNameType cannot be =B3factorized=B2 ? (in the example from Page = 15, >>>>> there are all the same). >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> No, the example in the spec has one e-mail attribute that was placed i= n the >>>> SubjAltName extension of the cert. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> "rdn" The SAML attribute value is placed in t= he >>>>> =20 >>>>> subject field of the certificate in a >>>>> =20 >>>>> present Relative Distinguished Name >>>>> =20 >>>>> attribute. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> "san" The SAML attribute value is placed in t= he >>>>> =20 >>>>> Subject Alternative Name extension of t= he >>>>> =20 >>>>> certificate. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> I also failed to understand the reason of such =B3mapping=B2. >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Yes, and I think that is the reason behind most of your comments. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> The example in Appendix C illustrates the complexity of the proposal= . >>>>> Can the approach be made simpler ? If not, why ? >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> No it can't be made simpler. It contains exactly the information we ne= ed in >>>> the implementation where it is used. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> I could write a whole whitepaper about all detailed reasons, but if yo= u >>>> really think about the use case, it should be clear. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Consider the case where you know users by attributes defined in a SAML >>>> federation, where for example serialNumber is NOT used. >>>> =20 >>>> A CA issues a certificate to a user based an a SAML assertion >>>> authentication based on the attribute profile of that federation. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> A user logs in to your service using a SAML assertion, and sends you a >>>> signed document associated with the issued certificate. >>>> =20 >>>> You now need to determine whether that SAML assertion and the certific= ate >>>> represents the same user. >>>> =20 >>>> You also need to determine that the SAML assertion and the certificate >>>> provides compatible levels of assertion for user authentication as def= ined >>>> in your SAML federation. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> This extension gives you exactly the amount of data that is needed in = order >>>> to do this in an unambiguous fully automated process. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> 10. In section 4, I failed to understand the =B3dynamic=B2 aspect. My >>>>> understanding is that a person statically >>>>> authenticates to a RA (Registration Authority) and then is given bac= k a >>>>> non-repudiation certificate >>>>> with SAML attributes in it which may then be used as identity attrib= utes. >>>>> I am unsure what the text in this section wants to say when using th= e >>>>> words =B3dynamic manner=B2. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Your view is to restrictive. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> 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 tha= t is >>>> needed for one particular situation. >>>> =20 >>>> This extension is (where this is used in the Swedish national >>>> infrastructure) added to certificates that are issued for just one ins= tance >>>> of signing, and hence can be dynamically adapted to the needs of the >>>> intended relying party. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Next time the user signs, a new key pair is generated with new certs t= hat >>>> may contain another set of the user's attributes. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> The first instance may for example contain the users private identity = based >>>> on a national identifier, the second may carry an organisational ident= ity >>>> based on employee number. >>>> =20 >>>> What attributes that are needed in every instance is determined in a >>>> service context that is outside the scope of this specification. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> In these certificates, both the national identifier and the employee n= umber >>>> may be placed as a serialNumber attribute in the subject field. >>>> =20 >>>> Despite that, this extension makes it possible for the relying party t= o >>>> know exactly what identity information each certificate carries, as it= maps >>>> to the attribute profile of a SAML federation. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> /Stefan >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> Denis >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix >>>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3445421244_2998215 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis,

<= div>I took a look at this this morning with fresh eyes, and some of your que= stions triggered me to do further improvements on the Schema, explanations a= nd examples.

The latest draft is still available fr= om here:
http://aaa-sec.com/_temp/draft-santesson-auth-context-ext= ension-04.txt

Hopefully the new examples will give = you a better Idea on how this extension can be used and why this is not suit= able 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 <denis.pinkas@bull.net>
Date: Tuesday, March 5, 2013 6:44 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: pkix <pkix@ietf.org&= gt;
Subject: Re: [pkix] Comments o= n 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 n= ow 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 Swedis= h standard.

=
Based on comments received today I have updated this draft, preliminary available at:

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" <md@e-net.lt>
Date: Monday, March 4, 2013 11:26 AM
To: Stefan Santesson <st= efan@aaa-sec.com>
Cc: Denis Pinkas <denis.pinkas@bull.n= et>, pkix <pk= ix@ietf.org>
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 <denis.pinkas@bull.net>
Date: Monday, March 4, 2013 9:42 AM
To: Stefan Santesson <stefan@aaa-sec.com>, pkix <pkix@ietf.org>
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.

 

   S= ubjectAltName ::=3D GeneralNames

 

   G= eneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName<= /o:p>

 

   G= eneralName ::=3D CHOICE {

   &nb= sp;    otherName &= nbsp;            = ;         [0] =     OtherName,

   &nb= sp;    rfc822Name =             &nbs= p;        [1] =     IA5String,

   &nb= sp;    dNSName &nb= sp;            &= nbsp;          [2] =     IA5String,

   &nb= sp;    x400Address = ;            &nb= sp;       [3] =     ORAddress,

   &nb= sp;    directoryName&nb= sp;            &= nbsp;     [4] =     Name,

   &nb= sp;    ediPartyName&nbs= p;            &n= bsp;      [5] =     EDIPartyName,

   &nb= sp;    uniformResourceIdentifier       [6]     IA5String,

   &nb= sp;    iPAddress &= nbsp;            = ;         [7] =     OCTET STRING,

   &nb= sp;    registeredID&nbs= p;            &n= bsp;      [8] =     OBJECT IDENTIFIER }

 

   O= therName ::=3D SEQUENCE {

   &nb= sp;    type-id &nb= sp;  OBJECT IDENTIFIER,

   &nb= sp;    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.
<= /p>

 

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.

 

   &nb= sp;  AuthenticationContexts ::=3D SEQUENCE SIZE (1..MAX) OF=

   &nb= sp;            &= nbsp;            = ;    AuthenticationContext<= /p>

 

   &nb= sp;  AuthenticationContext ::=3D SEQUENCE {

   &nb= sp;      contextType     UTF8String,

   &nb= sp;      contextInfo     UTF8String OPTIONAL

   &nb= sp;  }


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 examp= le 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.<= /span>

 

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.<= /p>


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


 

 

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.

 

   &nb= sp;            &= nbsp;     "rdn"&nbs= p;  The SAML attribute value is placed in the

   &nb= sp;            &= nbsp;            = ; subject field of the certificate in a

   &nb= sp;            &= nbsp;            = ; present Relative Distinguished Name=

   &nb= sp;            &= nbsp;            = ; attribute.

 

   &nb= sp;            &= nbsp;     "san"&nbs= p;  The SAML attribute value is placed in the

   &nb= sp;            &= nbsp;            = ; Subject Alternative Name extension of the

   &nb= sp;            &= nbsp;            = ; 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 “dynami= c 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
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix


_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3445421244_2998215-- From pritikin@cisco.com Thu Mar 7 17:58:02 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C3E21F8767 for ; Thu, 7 Mar 2013 17:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VJcV8cC6LgK for ; Thu, 7 Mar 2013 17:58:01 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3278721F8765 for ; Thu, 7 Mar 2013 17:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=603; q=dns/txt; s=iport; t=1362707881; x=1363917481; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xzh8jCpYIEhiD56wASvH3wG6/wSKqtikNQ7O6BjqcYI=; b=Mv7gBWhngwi5mE2djLBkkeNNWgu7/BPJt3F1WW4e1+jVLFMOml0wFoiQ TZHj+U7u5Ix1HsA+zaWF/DQD6bXlEHeyVZ8Ds8+h0C0QMp3LqdZ8DEYBc gvfauk72ZkCMp2TKnLx7iaOHfODgp+A80JF2wlpKMZHalZMl5Il46Saky 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAEFFOVGtJV2Z/2dsb2JhbABEh1+8cYFfFnSCLAEBAQMBAQEBNzQLBQsCAQgiFBAnCyUCBA4FCAGIBAYMu1WOWQIxB4JfYQOnPIMJgic X-IronPort-AV: E=Sophos;i="4.84,806,1355097600"; d="scan'208";a="182122304" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 08 Mar 2013 01:58:00 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r281w03u021285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Mar 2013 01:58:00 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.17]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 19:58:00 -0600 From: "Max Pritikin (pritikin)" To: Stefan Santesson Thread-Topic: [pkix] Agenda posted Thread-Index: AQHOFp2xC4hQ9GUpp0mWuoKXWTwlBJibeBkA Date: Fri, 8 Mar 2013 01:58:00 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B698CFFE38@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.1.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DD7F2E90D2B2448A25EE02BA94CE3D2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Agenda posted X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 01:58:02 -0000 On Mar 1, 2013, at 9:56 AM, Stefan Santesson wrote: > An agenda for the PKIX meeting in Orlando has been posted. >=20 > http://www.ietf.org/proceedings/86/agenda/agenda-86-pkix >=20 > I have not yet got confirmation from the est editors but assume some of t= he authors will provide an update presentation. My apologies - I thought we'd responded.=20 Yes, we will provide an update presentation, - max >=20 > /Stefan >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Fri Mar 8 00:44:35 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7484D21F8609 for ; Fri, 8 Mar 2013 00:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.889 X-Spam-Level: X-Spam-Status: No, score=-4.889 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgCy4doFrRJM for ; Fri, 8 Mar 2013 00:44:28 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 590F521F8545 for ; Fri, 8 Mar 2013 00:44:27 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 2FF571D131; Fri, 8 Mar 2013 09:44:26 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013030809442495-10897 ; Fri, 8 Mar 2013 09:44:24 +0100 Message-ID: <5139A4E4.2010107@bull.net> Date: Fri, 08 Mar 2013 09:44:20 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 08/03/2013 09:44:26, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 08/03/2013 09:44:26, Serialize complete at 08/03/2013 09:44:26 Content-Type: multipart/alternative; boundary="------------000006000108030300060303" Cc: pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 08:44:35 -0000 This is a multi-part message in MIME format. --------------000006000108030300060303 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, I wonder whether your had "fresh eyes", because you moved one step forwards and then you moved three steps backwards: Section3.2 "Attribute matching" has now disappeared. The major disagreements remain: I disagree with the scope and the new draft does not solve my concerns. Allowing to have SAML attributes in a PKC would be a very good thing. However, the relying party DOES NOT care how these SAML attributes have been translated into a subject DN. It is the responsibility of the CA. Thus, if the scope only remains to know how the correspondence was made between the SAML attributes and the subject DN, I don't believe that this document will be useful for the Internet community and thus I am still unconvinced that this document should progress as an Internet Draft. If the scope is changed to allow to include SAML attributes as another name form in a PKC, then this is an important issue which deserves an Internet Draft. Denis > Denis, > > I took a look at this this morning with fresh eyes, and some of your > questions triggered me to do further improvements on the Schema, > explanations and examples. > > The latest draft is still available from here: > http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt > > Hopefully the new examples will give you a better Idea on how this > extension can be used and why this is not suitable as an other name form. > > I'm really grateful for your review even if I don't do everything > exactly as you suggested. > > /Stefan > > > > > From: Denis Pinkas > > Date: Tuesday, March 5, 2013 6:44 PM > To: Stefan Santesson > > Cc: pkix > > Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 > > Stefan, > > I read the new specification (dated March 4) and it does not solve > my concerns. > ** > The real goal is stated at the top of page 4: > > > *to verify that the signature was created by the same user that > logged on * > > *to the service*. > > In your response below, you also say: > > "You now need to determine whether that SAML assertion and > the certificate represents the same user." > > This is rather different from the goal stated on page 3: > > The primary purpose of this document is to provide a mechanism that > > allows an application to understand information that express the > > identity of a *subject in a certificate that is stored either in a* > > *subject field attribute, as a subject alternative name or in a* > > *subject directory attribute.* > > > If we draw an analogy with the way to construct a DN, we do not > mention that the DN was created after > the presentation of a passport or an ID card, plus a way to > justify the place of birth, a a way to justify > the place of living, an that the country name was extracted from > the presentation of the passport, etc ... > > So why should we do this in your context ? > > We need to store information in the certificate directly derived > from the SAML token, so that the application > which performed a SAML authentication can make sure that the > certificate was delivered for the same person, > by *making a comparison using some set of rules.** > * > So *t**here is a need to have matching rules* for the content of > the SAML token with the content of > the new extension (whatever it is). If we don't have such rules, > then the goal at the top of page 4 cannot be met. > > I do not see the added value to explain some translation process > since it would be used for audit purposes only and > the CA MUST anyway maintain information about the issuance of the > token. So in case of a problem, the > CA SHALL be able to answer and it is not needed to overload the > content of the certificate with more information. > > I still believe that OtherName is the right place to contains the > parameters extracted from the SAML token, > that will be used for comparison. > > Denis > > > PS. I wonder whether we should continue to have in mind to have > this document issued as an RFC. > It may well be a national Swedish standard. > >> Based on comments received today I have updated this draft, >> preliminary available at: >> http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt >> >> I have edited the Introduction section to clarify the scope of >> the document. >> >> I have also added a new section (now 3.2) that explains the >> absence of attribute matching rules. >> The section should also make clear how specific attribute data >> format conventions, such as the one expressed in ETSI TS 119 >> 412-2, can co-exist with this extension. >> >> /Stefan >> >> From: "Moudrick M. Dadashov" > >> Date: Monday, March 4, 2013 11:26 AM >> To: Stefan Santesson > >> Cc: Denis Pinkas > >, pkix > > >> 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 >> > >>> Date: Monday, March 4, 2013 9:42 AM >>> To: Stefan Santesson >> >, pkix >> > >>> Subject: Comments on draft-santesson-auth-context-extension-04 >>> >>> Stefan, >>> >>> >>> The goal of this document is to associate a public key >>> to be used for verifying electronic signatures >>> with an identifier composed of a set of attributes, >>> typically SAML attributes, contained in an >>> authentication token. >>> >>> >>> No you got this wrong. This is not an Identifier. >>> >>> MAJOR COMMENTS >>> >>> 1.The proposed draft is not aligned with the current >>> practices of RFC 5280 and X.509: >>> the right place to hold such a set of attributes is in >>> the subject alternate name. >>> The subject DN may or may not be empty. >>> >>> There is no rational in this draft to explain why this >>> straightforward approach has not been chosen. >>> >>> SubjectAltName ::= GeneralNames >>> >>> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName >>> >>> GeneralName ::= CHOICE { >>> >>> otherName[0]OtherName, >>> >>> rfc822Name[1]IA5String, >>> >>> dNSName[2]IA5String, >>> >>> x400Address[3]ORAddress, >>> >>> directoryName[4]Name, >>> >>> ediPartyName[5]EDIPartyName, >>> >>> uniformResourceIdentifier[6]IA5String, >>> >>> iPAddress[7]OCTET STRING, >>> >>> registeredID[8]OBJECT IDENTIFIER } >>> >>> OtherName ::= SEQUENCE { >>> >>> type-idOBJECT IDENTIFIER, >>> >>> value[0] EXPLICIT ANY DEFINED BY type-id } >>> >>> OtherName fits well with the requirements, if you accept >>> to use an OID rather than >>> a uniformResourceIdentifier. >>> >>> The value component would contain an XML structure >>> conformant with a XML schema. >>> >>> >>> This draft does not contain an identifier, thus this comment >>> is irrelevant. >>> There is not explanation why we don't store an identifier as >>> a SAN, since we do not create or store an identifier. >>> >>> 2.The document should be restructured to define: >>> >>> (a) the general way to answer to the requirements, and >>> (b) a specific profile, in an Appendix, so that other >>> RFCs could refer to the main body of the document. >>> >>> >>> That could be one way to do it. >>> >>> DETAILED COMMENTS >>> >>> 3.The proposed structure is not appropriate. >>> >>> a) Why is there a need to have a SEQUENCE ? This should >>> be avoided. >>> >>> b) Why is contextInfo OPTIONAL? This should be avoided. >>> >>> AuthenticationContexts ::= SEQUENCE SIZE (1..MAX) OF >>> >>> AuthenticationContext >>> >>> AuthenticationContext ::= SEQUENCE { >>> >>> contextTypeUTF8String, >>> >>> contextInfoUTF8String OPTIONAL >>> >>> } >>> >>> >>> For exactly the same reason why SAML AuthContextClassRef in >>> a SAML assertion is mandatory but not the XML structure it >>> defines. >>> In some cases you don't want to include explicit data, if >>> that data is static and can be implicitly known through an >>> identifier. >>> >>> The AuthContextClassRef in SAML is the best example as it is >>> an exact functional replica of this. >>> The URL identified by AuthContextClassRef is also a XML >>> Schema ns for associated XML document. >>> >>> The XML Schema can define both a static XML document with >>> fixed values as well as a structure where different values >>> can be entered. >>> >>> Just including the reference to the XML Schema may then >>> provide sufficient information to the relying party. The >>> actual XML document is only included if some variable data >>> need to be communicated within the associated XML document. >>> >>> Just including contextType but not contextInfo could be >>> compared with the case where we include a certificate policy >>> OID, but not the entire policy text. >>> >>> This is a really smart way to do this, which is made >>> possible through the versatility of XML Schemas. >>> >>> >>> 4.The text states: This extension MAY be marked critical. >>> >>> If the alternate name is present, why should there be a DN ? >>> >>> >>> This comment must be based on a misunderstanding of the >>> scope of this document. >>> >>> 5.The XML schema should be given first (Appendix B) >>> followed by the explanations (sections 3.1 and 3.2). >>> In other words, sections 3.1 and 3.2 should be placed in >>> Appendix B. >>> >>> >>> That is one way to do it. If I was the implementer, I really >>> wouldn't care as long as the information is there. >>> I think it is quite common to place programatic contracts in >>> Appendixes, wile explaining data elements in the body of the >>> document. >>> >>> 6.The vocabulary used in sections 3.1 and 3.2 is >>> confusing and should be changed. >>> >>> An example: "AuthContextInfo Element" does not exist. >>> However, it is better to state that the contextInfo >>> component >>> contains an XML structure which must conform to an XML >>> schema. >>> >>> >>> Sorry, I don't get this comment. The AuthContextInfo element >>> does exist. It is defined in the schema. XML Schema defines >>> syntax and structure but not the semantics. Semantics are >>> defined the section 3. >>> >>> 7.The XML structure proposed to fit inside contextInfo >>> is overly complex. >>> >>> AuthenticationInstant is mandatory, whereas it is not >>> needed. >>> >>> >>> This information is always available from the SAML assertion >>> and is considered fundamental, thus required. >>> >>> AssertionRef is not needed. >>> >>> ServiceID is not needed. >>> >>> >>> And hence, both are optional. >>> >>> The XML Schema is actually very simple. Its just the nature >>> of XML Schemas to look more complex than they actually are. >>> Perhaps it is easier if you examine it through this >>> following web doc (which unfortunately can't be included in >>> the spec): >>> http://aaa-sec.com/eid2/sigsupport/XMLschema/AuthContExtDoc/index.html >>> >>> >>> 8.There are no matching rules defined. This means that >>> the verification of the content of that field is not >>> possible. >>> >>> >>> First of all, this is not an identifier, thus there is no >>> reason for a matching rule is it would be if this was an >>> identifier that as a whole should be compared with something >>> else. >>> >>> The SAML attribute value does not have to match the value of >>> the cert attribute, this data in the extension is optional >>> and, if present, is a hint. >>> But I could actually add some text to clarify this. >>> >>> 9.In section 3.2, I failed to understand the >>> explanations for CertRef as well as for rdn and san. >>> >>> Why CertNameType cannot be "factorized" ? (in the >>> example from Page 15, there are all the same). >>> >>> >>> No, the example in the spec has one e-mail attribute that >>> was placed in the SubjAltName extension of the cert. >>> >>> "rdn"The SAML attribute value is placed in the >>> >>> subject field of the certificate in a >>> >>> present Relative Distinguished Name >>> >>> attribute. >>> >>> "san"The SAML attribute value is placed in the >>> >>> Subject Alternative Name extension of the >>> >>> certificate. >>> >>> I also failed to understand the reason of such "mapping". >>> >>> >>> Yes, and I think that is the reason behind most of your >>> comments. >>> >>> >>> The example in Appendix C illustrates the complexity of >>> the proposal. >>> Can the approach be made simpler ? If not, why ? >>> >>> >>> No it can't be made simpler. It contains exactly the >>> information we need in the implementation where it is used. >>> >>> I could write a whole whitepaper about all detailed reasons, >>> but if you really think about the use case, it should be clear. >>> >>> Consider the case where you know users by attributes defined >>> in a SAML federation, where for example serialNumber is NOT >>> used. >>> A CA issues a certificate to a user based an a SAML >>> assertion authentication based on the attribute profile of >>> that federation. >>> >>> A user logs in to your service using a SAML assertion, and >>> sends you a signed document associated with the issued >>> certificate. >>> You now need to determine whether that SAML assertion and >>> the certificate represents the same user. >>> You also need to determine that the SAML assertion and the >>> certificate provides compatible levels of assertion for user >>> authentication as defined in your SAML federation. >>> >>> This extension gives you exactly the amount of data that is >>> needed in order to do this in an unambiguous fully automated >>> process. >>> >>> 10.In section 4, I failed to understand the "dynamic" >>> aspect. My understanding is that a person statically >>> authenticates to a RA (Registration Authority) and then >>> is given back a non-repudiation certificate >>> with SAML attributes in it which may then be used as >>> identity attributes. >>> I am unsure what the text in this section wants to say >>> when using the words "dynamic manner". >>> >>> >>> >>> Your view is to restrictive. >>> >>> The dynamic aspect of this is that a certificate may be >>> issued on the fly at the instance when it is needed, >>> containing just the information that is needed for one >>> particular situation. >>> This extension is (where this is used in the Swedish >>> national infrastructure) added to certificates that are >>> issued for just one instance of signing, and hence can be >>> dynamically adapted to the needs of the intended relying party. >>> >>> Next time the user signs, a new key pair is generated with >>> new certs that may contain another set of the user's attributes. >>> >>> The first instance may for example contain the users private >>> identity based on a national identifier, the second may >>> carry an organisational identity based on employee number. >>> What attributes that are needed in every instance is >>> determined in a service context that is outside the scope of >>> this specification. >>> >>> In these certificates, both the national identifier and the >>> employee number may be placed as a serialNumber attribute in >>> the subject field. >>> Despite that, this extension makes it possible for the >>> relying party to know exactly what identity information each >>> certificate carries, as it maps to the attribute profile of >>> a SAML federation. >>> >>> /Stefan >>> >>> >>> Denis >>> >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix >> > > _______________________________________________ pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --------------000006000108030300060303 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

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

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

Allowing to have SAML attributes in a PKC would be a very good thing. However, the relying party DOES NOT care
how these SAML attributes have been translated into a subject DN. It is the responsibility of the CA.

Thus, if the scope only remains to know how the correspondence was made between  the SAML attributes and
the subject DN, I don't believe that this document will be useful for the Internet community and thus I am still unconvinced
that this document should progress as an Internet Draft.

If the scope is changed to allow to include SAML attributes as another name form in a PKC, then this is
an important issue which deserves an Internet Draft.

Denis

Denis,

I took a look at this this morning with fresh eyes, and some of your questions triggered me to do further improvements on the Schema, explanations and examples.

The latest draft is still available from here:

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 <denis.pinkas@bull.net>
Date: Tuesday, March 5, 2013 6:44 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: pkix <pkix@ietf.org>
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:

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" <md@e-net.lt>
Date: Monday, March 4, 2013 11:26 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Denis Pinkas <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
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 <denis.pinkas@bull.net>
Date: Monday, March 4, 2013 9:42 AM
To: Stefan Santesson <stefan@aaa-sec.com>, pkix <pkix@ietf.org>
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):


 

 

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
pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix


_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix

--------------000006000108030300060303-- From ben@digicert.com Fri Mar 8 08:54:17 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FC721F856D for ; Fri, 8 Mar 2013 08:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.462 X-Spam-Level: X-Spam-Status: No, score=-4.462 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSGaDVFbOKZO for ; Fri, 8 Mar 2013 08:54:07 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9321F8563 for ; Fri, 8 Mar 2013 08:54:07 -0800 (PST) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 2DDC38FAC19 for ; Fri, 8 Mar 2013 09:54:07 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1362761647; bh=B/M7FbqgMGV/xFRTrV39SdVjoMimBvfqQY3WCrC6IiQ=; h=Reply-To:From:To:Subject:Date; b=BJ1p3vbXbxDjAW2X0wpZS7Kz75HKPEWkEtzyEhQrjFyYpKd7pe2AJ6e0lGeNT7mBm st0KWuOFaqqKswXQRPoFG30SeWY8QoDZOjADeC2ayyAvxd8CPsoCMlGRTWcaNxTAyn vGCK7Q9itUtRiqWTkGDdmQedNUr4fcf/CLw3Wokk= From: "Ben Wilson" To: "'pkix'" Date: Fri, 8 Mar 2013 09:54:05 -0700 Organization: DigiCert Message-ID: <00b401ce1c1d$8b117710$a1346530$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01CE1BE2.DEB2ED30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4cHWHT3dheD5AsSqSZNK0gSuFQfg== Content-Language: en-us Subject: [pkix] OID Processing betwee Intermediate CA and End Entity Certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 16:54:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B5_01CE1BE2.DEB2ED30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Do any of you know whether software should process a certificate chain properly if I construct a policy OID arc (for SSL/TLS Server Certificates) as follows? Intermediate CA Policy OID : 2.16.840.1.114412.1 End Entity Policy OID : 2.16.840.1.114412.1.1 Thanks, Ben ------=_NextPart_000_00B5_01CE1BE2.DEB2ED30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do any of = you know whether software should process a certificate chain properly if = I construct a policy OID arc (for SSL/TLS Server Certificates) as = follows?

End = Entity Policy OID :

Thanks,

Ben

 

------=_NextPart_000_00B5_01CE1BE2.DEB2ED30-- From SChokhani@cygnacom.com Fri Mar 8 09:23:45 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299D521F8630 for ; Fri, 8 Mar 2013 09:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqyisUQQtBTL for ; Fri, 8 Mar 2013 09:23:44 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 64D8021F8615 for ; Fri, 8 Mar 2013 09:23:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,809,1355115600"; d="scan'208,217";a="4092703" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 08 Mar 2013 12:23:42 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 8 Mar 2013 12:23:41 -0500 From: Santosh Chokhani To: "ben@digicert.com" , 'pkix' Date: Fri, 8 Mar 2013 12:23:40 -0500 Thread-Topic: [pkix] OID Processing betwee Intermediate CA and End Entity Certificates Thread-Index: Ac4cHWHT3dheD5AsSqSZNK0gSuFQfgABBZKQ Message-ID: References: <00b401ce1c1d$8b117710$a1346530$@digicert.com> In-Reply-To: <00b401ce1c1d$8b117710$a1346530$@digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AFF3DC95F4scygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] OID Processing betwee Intermediate CA and End Entity Certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:23:45 -0000 --_000_B83745DA469B7847811819C5005244AFF3DC95F4scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That depends on the status of the require explicit policy in the path valid= ation state machine and user acceptable policy set. At best, the chain is good for no certificate policies. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ben= Wilson Sent: Friday, March 08, 2013 11:54 AM To: 'pkix' Subject: [pkix] OID Processing betwee Intermediate CA and End Entity Certif= icates Do any of you know whether software should process a certificate chain prop= erly if I construct a policy OID arc (for SSL/TLS Server Certificates) as f= ollows? Intermediate CA Policy OID : 2.16.840.1.114412.1 End Entity Policy OID : 2.16.840.1.114412.1.1 Thanks, Ben --_000_B83745DA469B7847811819C5005244AFF3DC95F4scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That depends on the status of the require explicit policy in = the path validation state machine and user acceptable policy set.

 <= /o:p>

At best,= the chain is good for no certificate policies.

 

From: pkix-bounces@ietf.org [mailto:pkix-bou= nces@ietf.org] On Behalf Of Ben Wilson
Sent: Friday, March= 08, 2013 11:54 AM
To: 'pkix'
Subject: [pkix] OID Proce= ssing betwee Intermediate CA and End Entity Certificates
<= /p>

 

Do any of you know whether software should process a certificate chain p= roperly if I construct a policy OID arc (for SSL/TLS Server Certificates) a= s follows?

Intermediate CA Policy OID :  =

2.16.840.1.114412.1

2.16.840.1.114412.1.1

=

I= ntermediate CA Policy OID : 

2.16.840.1.114412.1

2.16.840.1.114412.1.1

Thanks,

Ben

 

= = --_000_B83745DA469B7847811819C5005244AFF3DC95F4scygexch7cygnac_-- From ben@digicert.com Fri Mar 8 09:36:40 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50A021F8738 for ; Fri, 8 Mar 2013 09:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyk0QfM17kV8 for ; Fri, 8 Mar 2013 09:36:37 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id DE21E21F8751 for ; Fri, 8 Mar 2013 09:36:36 -0800 (PST) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 9A3AA7FA18F for ; Fri, 8 Mar 2013 10:36:36 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1362764196; bh=5IXPwYD1aUaaIe5H0JfcRRMH0zqPau9WwZYBBRkfopo=; h=Reply-To:From:To:Subject:Date; b=L6/A/xWL0hWoPNzI0EHyYrLxjaoM9CwOdtfTk2hXSZIvrn8S6ApqYn0+P5RVGRvAQ +mpaWTy25G0vrgrbP5vRpHu7CHFrYwT02cUu19e87ZKYuqTfAatk+mtX3J5h8bIV3+ 9XzEuv67ERu1VJA2QA9Tgv0WYuJ3Jsgk6eZ3PEnk= From: "Ben Wilson" To: "'pkix'" Date: Fri, 8 Mar 2013 10:36:34 -0700 Organization: DigiCert Message-ID: <010601ce1c23$7aa50030$6fef0090$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0107_01CE1BE8.CE469D60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4cID4yYuSDeTBrQp+uuf3c/H1ROg== Content-Language: en-us Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:36:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0107_01CE1BE8.CE469D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've received a couple of clarifications off-list, but just to clarify - policy OIDs at the CA level are constraints on what policies an end entity certificate may include/assert. So if you are creating a subCA, and you are going to use it to issue certificates under multiple end entity policies, it's better to omit the CP OID altogether. Alternatives include specifying all policies (which you may not know beforehand) or the allpolicies OID. "In other words, contrary of what some people believe there are no policies for CAs, there are only policy OIDs for EE certificates." So, the OID arc structure will not work as I thought it might - like a filter reading left to right. Thanks, Ben ------=_NextPart_000_0107_01CE1BE8.CE469D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve received a couple of clarifications = off-list,  but just to clarify – policy OIDs at the CA level = are constraints on what policies an end entity certificate may = include/assert. 

So if you are creating a subCA, and you are = going to use it to issue certificates under multiple end entity = policies, it’s better to omit the CP OID altogether.  = Alternatives include specifying all policies (which you may not know = beforehand) or the allpolicies OID.

“In other words, = contrary of what some people believe there are no policies for CAs, = there are only policy OIDs for EE certificates.”  =

 So, the OID arc structure will not work as = I thought it might -  like a filter reading left to = right.

Thanks,

Ben

------=_NextPart_000_0107_01CE1BE8.CE469D60-- From SChokhani@cygnacom.com Fri Mar 8 09:46:07 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E9921F87BA for ; Fri, 8 Mar 2013 09:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dud+DKw6tINH for ; Fri, 8 Mar 2013 09:46:06 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id D0CF021F87B1 for ; Fri, 8 Mar 2013 09:46:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,809,1355115600"; d="scan'208,217";a="8132732" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 08 Mar 2013 12:46:03 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 8 Mar 2013 12:46:03 -0500 From: Santosh Chokhani To: "ben@digicert.com" , 'pkix' Date: Fri, 8 Mar 2013 12:46:02 -0500 Thread-Topic: [pkix] OID Processing between Intermediate CA and End Entity Certificates Thread-Index: Ac4cID4yYuSDeTBrQp+uuf3c/H1ROgABG9Dg Message-ID: References: <010601ce1c23$7aa50030$6fef0090$@digicert.com> In-Reply-To: <010601ce1c23$7aa50030$6fef0090$@digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AFF3DC95FAscygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:46:07 -0000 --_000_B83745DA469B7847811819C5005244AFF3DC95FAscygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Omitting policy OID may not work. The chain may be invalid and is at the b= est not good for any policies. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ben= Wilson Sent: Friday, March 08, 2013 12:37 PM To: 'pkix' Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity C= ertificates I've received a couple of clarifications off-list, but just to clarify - p= olicy OIDs at the CA level are constraints on what policies an end entity c= ertificate may include/assert. So if you are creating a subCA, and you are going to use it to issue certif= icates under multiple end entity policies, it's better to omit the CP OID a= ltogether. Alternatives include specifying all policies (which you may not= know beforehand) or the allpolicies OID. "In other words, contrary of what some people believe there are no policies= for CAs, there are only policy OIDs for EE certificates." So, the OID arc structure will not work as I thought it might - like a fi= lter reading left to right. Thanks, Ben --_000_B83745DA469B7847811819C5005244AFF3DC95FAscygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Omitting policy OID may not work.  The chain may be inva= lid and is at the best not good for any policies.

 

=

From: pkix-bounces@ietf.org [mailto:pkix-b= ounces@ietf.org] On Behalf Of Ben Wilson
Sent: Friday, Mar= ch 08, 2013 12:37 PM
To: 'pkix'
Subject: Re: [pkix] OID= Processing between Intermediate CA and End Entity Certificates<= /span>

 

I’ve received a couple of cla= rifications off-list,  but just to clarify – policy OIDs at the = CA level are constraints on what policies an end entity certificate may inc= lude/assert. 

So if you are creating a subCA, and you are going to use= it to issue certificates under multiple end entity policies, it’s be= tter to omit the CP OID altogether.  Alternatives include specifying a= ll policies (which you may not know beforehand) or the allpolicies OID.

“= ;In other words, contrary of what some people believe there are no policies= for CAs, there are only policy OIDs for EE certificates.” 

 = So, the OID arc structure will not work as I thought it might -  like = a filter reading left to right.

<= span style=3D'color:#1F497D'>Thanks,

Ben

= --_000_B83745DA469B7847811819C5005244AFF3DC95FAscygexch7cygnac_-- From ben@digicert.com Fri Mar 8 09:50:01 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A06121F8794 for ; Fri, 8 Mar 2013 09:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAF-268Vljjn for ; Fri, 8 Mar 2013 09:49:56 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 72ED521F868E for ; Fri, 8 Mar 2013 09:49:56 -0800 (PST) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 40E318FAC1A; Fri, 8 Mar 2013 10:49:56 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1362764996; bh=uR+tUS0Og5FJbw0/OYOBXPr4Ygfr1dC/gFQgOuwO0R8=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date; b=lSFxD90GbI3hsMfrQ6hHNkDo5SM4Fmt5l765sRWDWcfiOxuXbFgg2b9yUHNABrL38 z7rQgcmGGm6Pc4jhxEumHf7oIaDcQYF50a3ddFu5EqhwSzUKQW8ATRxktQXhYds3bn BCJCv7e5M0F9L1hDCgjL9QJ/zKkhpq0eCJbOWlfo= From: "Ben Wilson" To: "'Santosh Chokhani'" , "'pkix'" References: <010601ce1c23$7aa50030$6fef0090$@digicert.com> In-Reply-To: Date: Fri, 8 Mar 2013 10:49:54 -0700 Organization: DigiCert Message-ID: <011701ce1c25$5741f0b0$05c5d210$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01CE1BEA.AAE3B4F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQC2Ehg+PnyaJggAPdetcbY2awQIAwE+PWqJmsI0LaA= Content-Language: en-us Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:50:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0118_01CE1BEA.AAE3B4F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks, Santosh. So, is best practice to put in the 2.5.29.32.0 - "anyPolicy" OID? From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Friday, March 08, 2013 10:46 AM To: ben@digicert.com; 'pkix' Subject: RE: [pkix] OID Processing between Intermediate CA and End Entity Certificates Omitting policy OID may not work. The chain may be invalid and is at the best not good for any policies. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ben Wilson Sent: Friday, March 08, 2013 12:37 PM To: 'pkix' Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates I've received a couple of clarifications off-list, but just to clarify - policy OIDs at the CA level are constraints on what policies an end entity certificate may include/assert. So if you are creating a subCA, and you are going to use it to issue certificates under multiple end entity policies, it's better to omit the CP OID altogether. Alternatives include specifying all policies (which you may not know beforehand) or the allpolicies OID. "In other words, contrary of what some people believe there are no policies for CAs, there are only policy OIDs for EE certificates." So, the OID arc structure will not work as I thought it might - like a filter reading left to right. Thanks, Ben ------=_NextPart_000_0118_01CE1BEA.AAE3B4F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Santosh.  So, is best practice to = put in the 2.5.29.32.0 - "anyPolicy” OID? =

 

From:= = Santosh Chokhani [mailto:SChokhani@cygnacom.com]
Sent: = Friday, March 08, 2013 10:46 AM
To: ben@digicert.com; = 'pkix'
Subject: RE: [pkix] OID Processing between Intermediate = CA and End Entity Certificates

 

Omitting policy OID may not work.  The = chain may be invalid and is at the best not good for any = policies.

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Ben Wilson
Sent: Friday, March 08, 2013 = 12:37 PM
To: 'pkix'
Subject: Re: [pkix] OID = Processing between Intermediate CA and End Entity = Certificates

 

I’ve received a couple of clarifications = off-list,  but just to clarify – policy OIDs at the CA level = are constraints on what policies an end entity certificate may = include/assert. 

So if you are creating a subCA, and you are = going to use it to issue certificates under multiple end entity = policies, it’s better to omit the CP OID altogether.  = Alternatives include specifying all policies (which you may not know = beforehand) or the allpolicies OID.

“In other words, = contrary of what some people believe there are no policies for CAs, = there are only policy OIDs for EE certificates.”  =

 So, the OID arc structure will not work as = I thought it might -  like a filter reading left to = right.

Thanks,

Ben

------=_NextPart_000_0118_01CE1BEA.AAE3B4F0-- From SChokhani@cygnacom.com Fri Mar 8 09:52:26 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E0221F868E for ; Fri, 8 Mar 2013 09:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgx+f6pryn1R for ; Fri, 8 Mar 2013 09:52:19 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBEE21F8644 for ; Fri, 8 Mar 2013 09:52:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,809,1355115600"; d="scan'208,217";a="4097689" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 08 Mar 2013 12:52:18 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 8 Mar 2013 12:52:18 -0500 From: Santosh Chokhani To: "ben@digicert.com" , 'pkix' Date: Fri, 8 Mar 2013 12:52:17 -0500 Thread-Topic: [pkix] OID Processing between Intermediate CA and End Entity Certificates Thread-Index: AQC2Ehg+PnyaJggAPdetcbY2awQIAwE+PWqJmsI0LaCAAACwgA== Message-ID: References: <010601ce1c23$7aa50030$6fef0090$@digicert.com> <011701ce1c25$5741f0b0$05c5d210$@digicert.com> In-Reply-To: <011701ce1c25$5741f0b0$05c5d210$@digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AFF3DC95FEscygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:52:26 -0000 --_000_B83745DA469B7847811819C5005244AFF3DC95FEscygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, except some products such as Windows XP and other toolkits may treat = "anyPolicy" as a simple OID and not a wild card. I generally recommend customers to spell out the OIDs. From: Ben Wilson [mailto:ben@digicert.com] Sent: Friday, March 08, 2013 12:50 PM To: Santosh Chokhani; 'pkix' Subject: RE: [pkix] OID Processing between Intermediate CA and End Entity C= ertificates Thanks, Santosh. So, is best practice to put in the 2.5.29.32.0 - "anyPoli= cy" OID? From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Friday, March 08, 2013 10:46 AM To: ben@digicert.com; 'pkix' Subject: RE: [pkix] OID Processing between Intermediate CA and End Entity C= ertificates Omitting policy OID may not work. The chain may be invalid and is at the b= est not good for any policies. From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of Ben Wilson Sent: Friday, March 08, 2013 12:37 PM To: 'pkix' Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity C= ertificates I've received a couple of clarifications off-list, but just to clarify - p= olicy OIDs at the CA level are constraints on what policies an end entity c= ertificate may include/assert. So if you are creating a subCA, and you are going to use it to issue certif= icates under multiple end entity policies, it's better to omit the CP OID a= ltogether. Alternatives include specifying all policies (which you may not= know beforehand) or the allpolicies OID. "In other words, contrary of what some people believe there are no policies= for CAs, there are only policy OIDs for EE certificates." So, the OID arc structure will not work as I thought it might - like a fi= lter reading left to right. Thanks, Ben --_000_B83745DA469B7847811819C5005244AFF3DC95FEscygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, except some products such as Windows XP and other toolki= ts may  treat “anyPolicy” as a simple OID and not a wild c= ard.

 

I generally recommend customers to spell out the OIDs.

 =

From: Ben Wilson [mailto:ben@di= gicert.com]
Sent: Friday, March 08, 2013 12:50 PM
To: = Santosh Chokhani; 'pkix'
Subject: RE: [pkix] OID Processing betwe= en Intermediate CA and End Entity Certificates

<= /div>

 

Thanks, Santosh.  So, is best practice to put i= n the 2.5.29.32.0 - "anyPolicy” OID?

 

<= div>

From: Santosh Chokhani [mailto:SChokhani@cygnacom.com]
Sent: = Friday, March 08, 2013 10:46 AM
To: ben@digicert.com; 'pkix'
Subject: RE: [pkix] OID Proce= ssing between Intermediate CA and End Entity Certificates
=

 

Omitting policy OID may not work.  T= he chain may be invalid and is at the best not good for any policies.<= /o:p>

&nb= sp;

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ben= Wilson
Sent: Friday, March 08, 2013 12:37 PM
To: 'pkix= '
Subject: Re: [pkix] OID Processing between Intermediate CA and = End Entity Certificates

 

= I’ve received a couple of clarifications off-list,  but just to = clarify – policy OIDs at the CA level are constraints on what policie= s an end entity certificate may include/assert. 

So if you are creating = a subCA, and you are going to use it to issue certificates under multiple e= nd entity policies, it’s better to omit the CP OID altogether.  = Alternatives include specifying all policies (which you may not know before= hand) or the allpolicies OID.

“In other words, contrary of what some peo= ple believe there are no policies for CAs, there are only policy OIDs for E= E certificates.” 

 So, the OID arc structure will not work as= I thought it might -  like a filter reading left to right.=

Thanks,<= /o:p>

Ben

= --_000_B83745DA469B7847811819C5005244AFF3DC95FEscygexch7cygnac_-- From carl@redhoundsoftware.com Fri Mar 8 09:53:08 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336F121F87DF for ; Fri, 8 Mar 2013 09:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.589 X-Spam-Level: *** X-Spam-Status: No, score=3.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06MGaCvvWi9B for ; Fri, 8 Mar 2013 09:53:06 -0800 (PST) Received: from mail-gg0-x236.google.com (mail-gg0-x236.google.com [IPv6:2607:f8b0:4002:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 828F321F87D7 for ; Fri, 8 Mar 2013 09:53:06 -0800 (PST) Received: by mail-gg0-f182.google.com with SMTP id d1so307053ggn.27 for ; Fri, 08 Mar 2013 09:53:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=MvB3hDXUEkEwN+24y4KCLkbhAYd9FFZ/my2ocQtXsjU=; b=gBwBjfk20wPXrzZuClTQ034pvKwXq21M8YzjSv4MdlxiaODvxQFO1NMiU1WRWTLckS 1Y+YkbB78FKao0Vu5v7WBTZ1JW3d61yV/8epvcCw8LYEE4UTHITYz5dgDj7Kq8FehID6 qLQ55FEqTt0hmGveYXvr4pSEkULQXgLOvKvM+FniP2Sgg3JQRRLFT287czYzUdLag4Ej p8S/S1aWBtsmEW3px4/5TGGV4iIdx0Zs4qBhKEp+NNGakWYEgefDdTR4ENjrZk+dlbig VKS+UFAlBdyybBnid1JivcFAWbhhMDNd6jkTvHlj67mc0q40EY8yyixD0H2ksW3o0i1D 30GQ== X-Received: by 10.236.82.65 with SMTP id n41mr2423398yhe.66.1362765185939; Fri, 08 Mar 2013 09:53:05 -0800 (PST) Received: from [192.168.2.7] (pool-173-79-106-247.washdc.fios.verizon.net. [173.79.106.247]) by mx.google.com with ESMTPS id d43sm8991645yhk.23.2013.03.08.09.53.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 Mar 2013 09:53:05 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Fri, 08 Mar 2013 12:52:58 -0500 From: Carl Wallace To: , 'pkix' Message-ID: Thread-Topic: [pkix] OID Processing between Intermediate CA and End Entity Certificates In-Reply-To: <011701ce1c25$5741f0b0$05c5d210$@digicert.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445591983_3517841" X-Gm-Message-State: ALoCoQmbhJ51rJ9m3XyeJS2kbrAGGlnUZPlCMUc1LVSoDV3MFLVjINrtq9d/l7kDYNv9SlzNuhd5 Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:53:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445591983_3517841 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sounds like you may be looking for EKU-type semantics, at least before thos= e were altered to be like the certificate policy semantics that won't work fo= r you. =20 From: Ben Wilson Organization: DigiCert Reply-To: Date: Friday, March 8, 2013 12:49 PM To: Santosh Chokhani , 'pkix' Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates > Thanks, Santosh. So, is best practice to put in the 2.5.29.32.0 - "anyPo= licy=B2 > OID?=20 > =20 >=20 > From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] > Sent: Friday, March 08, 2013 10:46 AM > To: ben@digicert.com; 'pkix' > Subject: RE: [pkix] OID Processing between Intermediate CA and End Entity > Certificates > =20 > Omitting policy OID may not work. The chain may be invalid and is at the= best > not good for any policies. > =20 >=20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of B= en > Wilson > Sent: Friday, March 08, 2013 12:37 PM > To: 'pkix' > Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity > Certificates > =20 > I=B9ve received a couple of clarifications off-list, but just to clarify =AD > policy OIDs at the CA level are constraints on what policies an end entit= y > certificate may include/assert. > So if you are creating a subCA, and you are going to use it to issue > certificates under multiple end entity policies, it=B9s better to omit the = CP > OID altogether. Alternatives include specifying all policies (which you = may > not know beforehand) or the allpolicies OID. > =B3In other words, contrary of what some people believe there are no polici= es > for CAs, there are only policy OIDs for EE certificates.=B2 > So, the OID arc structure will not work as I thought it might - like a > filter reading left to right. > Thanks, > Ben > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3445591983_3517841 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Sounds like you may be looki= ng for EKU-type semantics, at least before those were altered to be like the=  certificate policy semantics that won't work for you.  

From: Ben Wilson <ben@digicert.com>
Organization: DigiCert
Reply-To: <ben@digicert.com<= /a>>
Date: Friday, March 8, 201= 3 12:49 PM
To: Santosh Chokhani &l= t;
schokhani@cygnacom.com>, 'p= kix' <pkix@ietf.org>
Subject: Re: [pkix] OID Processing between Inter= mediate CA and End Entity Certificates

Thanks, Santosh.  So, is best practice to put in the 2.5.29.32.0 - "= anyPolicy” OID?

 

From: S= antosh Chokhani [mailto:SChokhani@cy= gnacom.com]
Sent: Friday, March 08, 2013 10:46 AM
To: ben@digicert.com; 'pkix'
Subj= ect: RE: [pkix] OID Processing between Intermediate CA and End Entity Ce= rtificates

 =

Omitting policy O= ID may not work.  The chain may be invalid and is at the best not good = for any policies.

 

<= span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; ">From:= pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ben Wilson
Sent: Friday, March 08, 2013 12:37 PM
To: 'p= kix'
Subject: Re: [pkix] OID Processing between Intermediate CA an= d End Entity Certificates

 

I&= #8217;ve received a couple of clarifications off-list,  but just to cla= rify – policy OIDs at the CA level are constraints on what policies an= end entity certificate may include/assert. 

So if you are creating a subCA,= and you are going to use it to issue certificates under multiple end entity= policies, it’s better to omit the CP OID altogether.  Alternativ= es include specifying all policies (which you may not know beforehand) or th= e allpolicies OID.

“In other words, contrary of what some people believe the= re are no policies for CAs, there are only policy OIDs for EE certificates.&= #8221; 

 So, the OID arc structure will not work as I thought it might = -  like a filter reading left to right.

Thanks,

Ben

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3445591983_3517841-- From piyush@ditenity.com Fri Mar 8 10:36:16 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24521F8862 for ; Fri, 8 Mar 2013 10:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1uB-WbmY-Kr for ; Fri, 8 Mar 2013 10:36:14 -0800 (PST) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 442BC21F885E for ; Fri, 8 Mar 2013 10:36:14 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id j1so2336718oag.7 for ; Fri, 08 Mar 2013 10:36:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=dQL6+ZQFlPTwv09HIK1V86AND044se5YHQaWThMlx6o=; b=REOhOlQXhlpntms+kPqji9lYWAfaSV9M9tGnP2wSiiBc5COuzXtFkRGBAZVwZb2Gcx wi5428BUENrikG4RhTxfxavrLkp2VvTZGhOJ8siXVJ/ta6DUXSHdAwYJHfHYwjEu2ysk 1tFpV01k5RdL/PRH60BnBHtZTs/1VnDzMTaEKQE64yxkuKo1JaA0k7F2CWN5deytNBaz W+5dw4oirxpLtq/Se/iJ+bi4h5wG54Unx75dTO2H7/k6XmsRs3V99hj5g0HdaaWQXw2/ xcufnyJvlrIEwEqEuU2Lyf35n9tkVm4w/a4Bj/W30jO4W4j6qCVSi7HtFKB0z6PaYUhe V+Hw== X-Received: by 10.182.110.33 with SMTP id hx1mr2611369obb.32.1362767773655; Fri, 08 Mar 2013 10:36:13 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id d10sm6619780obk.1.2013.03.08.10.36.11 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 Mar 2013 10:36:12 -0800 (PST) From: "Piyush Jain" To: "'Santosh Chokhani'" , , "'pkix'" References: <010601ce1c23$7aa50030$6fef0090$@digicert.com> <011701ce1c25$5741f0b0$05c5d210$@digicert.com> In-Reply-To: Date: Fri, 8 Mar 2013 10:36:05 -0800 Message-ID: <06ea01ce1c2b$cc0e1710$642a4530$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06EB_01CE1BE8.BDEC5DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQC2Ehg+PnyaJggAPdetcbY2awQIAwE+PWqJAYToMOkCethzeJqiQvqQ Content-Language: en-us X-Gm-Message-State: ALoCoQkuqkBFwF1ikoYRXez3lVu1uzu2Twg6qfYadySzsK/skX2XseKYogIMjfZOSVfnz7aNQenV Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:36:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06EB_01CE1BE8.BDEC5DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That may be the reason why some CA certificates have explicit policy OIDs as well as "anyPolicy" OID in the CP extension. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Santosh Chokhani Sent: Friday, March 08, 2013 9:52 AM To: ben@digicert.com; 'pkix' Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates Yes, except some products such as Windows XP and other toolkits may treat "anyPolicy" as a simple OID and not a wild card. I generally recommend customers to spell out the OIDs. From: Ben Wilson [mailto:ben@digicert.com] Sent: Friday, March 08, 2013 12:50 PM To: Santosh Chokhani; 'pkix' Subject: RE: [pkix] OID Processing between Intermediate CA and End Entity Certificates Thanks, Santosh. So, is best practice to put in the 2.5.29.32.0 - "anyPolicy" OID? From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Friday, March 08, 2013 10:46 AM To: ben@digicert.com; 'pkix' Subject: RE: [pkix] OID Processing between Intermediate CA and End Entity Certificates Omitting policy OID may not work. The chain may be invalid and is at the best not good for any policies. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ben Wilson Sent: Friday, March 08, 2013 12:37 PM To: 'pkix' Subject: Re: [pkix] OID Processing between Intermediate CA and End Entity Certificates I've received a couple of clarifications off-list, but just to clarify - policy OIDs at the CA level are constraints on what policies an end entity certificate may include/assert. So if you are creating a subCA, and you are going to use it to issue certificates under multiple end entity policies, it's better to omit the CP OID altogether. Alternatives include specifying all policies (which you may not know beforehand) or the allpolicies OID. "In other words, contrary of what some people believe there are no policies for CAs, there are only policy OIDs for EE certificates." So, the OID arc structure will not work as I thought it might - like a filter reading left to right. Thanks, Ben ------=_NextPart_000_06EB_01CE1BE8.BDEC5DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That may be the reason why some CA certificates = have explicit policy OIDs as well as “anyPolicy” OID in the = CP extension.

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Santosh Chokhani
Sent: Friday, March 08, 2013 9:52 = AM
To: ben@digicert.com; 'pkix'
Subject: Re: [pkix] = OID Processing between Intermediate CA and End Entity = Certificates

 

Yes, except some products such as Windows XP and = other toolkits may  treat “anyPolicy” as a simple OID = and not a wild card.

 

I generally recommend = customers to spell out the OIDs.

 

From:= = Ben Wilson [mailto:ben@digicert.com] =
Sent: Friday, March 08, 2013 12:50 PM
To: Santosh = Chokhani; 'pkix'
Subject: RE: [pkix] OID Processing between = Intermediate CA and End Entity = Certificates

 

Thanks, Santosh.  So, is best practice to = put in the 2.5.29.32.0 - "anyPolicy” OID? =

 

From:= = Santosh Chokhani [mailto:SChokhani@cygnacom.com]=
Sent: Friday, March 08, 2013 10:46 AM
To: ben@digicert.com; = 'pkix'
Subject: RE: [pkix] OID Processing between Intermediate = CA and End Entity Certificates

 

Omitting policy OID may not work.  The = chain may be invalid and is at the best not good for any = policies.

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Ben Wilson
Sent: Friday, March 08, 2013 = 12:37 PM
To: 'pkix'
Subject: Re: [pkix] OID = Processing between Intermediate CA and End Entity = Certificates

 

I’ve received a couple of clarifications = off-list,  but just to clarify – policy OIDs at the CA level = are constraints on what policies an end entity certificate may = include/assert. 

So if you are creating a subCA, and you are = going to use it to issue certificates under multiple end entity = policies, it’s better to omit the CP OID altogether.  = Alternatives include specifying all policies (which you may not know = beforehand) or the allpolicies OID.

“In other words, = contrary of what some people believe there are no policies for CAs, = there are only policy OIDs for EE certificates.”  =

 So, the OID arc structure will not work as = I thought it might -  like a filter reading left to = right.

Thanks,

Ben

------=_NextPart_000_06EB_01CE1BE8.BDEC5DB0-- From mrex@sap.com Fri Mar 8 15:18:34 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2A21F8605 for ; Fri, 8 Mar 2013 15:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.005 X-Spam-Level: X-Spam-Status: No, score=-10.005 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RDSmuK42FML for ; Fri, 8 Mar 2013 15:18:33 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9B321F85FE for ; Fri, 8 Mar 2013 15:18:32 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r28NIOVt005820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Mar 2013 00:18:24 +0100 (MET) In-Reply-To: <5139A4E4.2010107@bull.net> To: Denis Pinkas Date: Sat, 9 Mar 2013 00:18:24 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130308231824.595391A617@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Stefan Santesson , pkix Subject: Re: [pkix] Comments on draft-santesson-auth-context-extension-04 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 23:18:34 -0000 Denis, While I have no personal interest or use in this proposal myself, I'm somewhat confused by your message. Denis Pinkas wrote: > > 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. Stefan said that he _has_ RPs who care. Where is your problem with this? > > 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. "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. > > 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. 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 wwwrun@rfc-editor.org Sun Mar 10 07:30:44 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848B321F8613 for ; Sun, 10 Mar 2013 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSmhOWeSPn64 for ; Sun, 10 Mar 2013 07:30:44 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2C13021F85DA for ; Sun, 10 Mar 2013 07:30:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2128EB1E003; Sun, 10 Mar 2013 07:30:37 -0700 (PDT) To: philliph@comodo.com, rob.stradling@comodo.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20130310143037.2128EB1E003@rfc-editor.org> Date: Sun, 10 Mar 2013 07:30:37 -0700 (PDT) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Editorial Errata Reported] RFC6844 (3528) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 14:30:44 -0000 The following errata report has been submitted for RFC6844, "DNS Certification Authority Authorization (CAA) Resource Record". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6844&eid=3528 -------------------------------------- Type: Editorial Reported by: Sean Turner Section: s7.3 Original Text ------------- Reserved> Corrected Text -------------- Reserved Notes ----- The additional ">" is unnecessary. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6844 (draft-ietf-pkix-caa-15) -------------------------------------- Title : DNS Certification Authority Authorization (CAA) Resource Record Publication Date : January 2013 Author(s) : P. Hallam-Baker, R. Stradling Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Sun Mar 10 07:37:57 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF921F8804 for ; Sun, 10 Mar 2013 07:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm5HScDZACb0 for ; Sun, 10 Mar 2013 07:37:56 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C770C21F863A for ; Sun, 10 Mar 2013 07:37:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B1884B1E003; Sun, 10 Mar 2013 07:37:49 -0700 (PDT) To: philliph@comodo.com, rob.stradling@comodo.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20130310143749.B1884B1E003@rfc-editor.org> Date: Sun, 10 Mar 2013 07:37:49 -0700 (PDT) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Editorial Errata Reported] RFC6844 (3532) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 14:37:57 -0000 The following errata report has been submitted for RFC6844, "DNS Certification Authority Authorization (CAA) Resource Record". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6844&eid=3532 -------------------------------------- Type: Editorial Reported by: Sean Turner Section: s7.3 Original Text ------------- 1-7 Reserved [RFC6844] Corrected Text -------------- 1-7 Unassigned [RFC6844] Notes ----- "Unassigned" is better than Reserved. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6844 (draft-ietf-pkix-caa-15) -------------------------------------- Title : DNS Certification Authority Authorization (CAA) Resource Record Publication Date : January 2013 Author(s) : P. Hallam-Baker, R. Stradling Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From denis.pinkas@bull.net Mon Mar 11 02:15:07 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A14D21F84F5 for ; Mon, 11 Mar 2013 02:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsJkL0Dm-2jn for ; Mon, 11 Mar 2013 02:15:06 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7509221F84EF for ; Mon, 11 Mar 2013 02:15:01 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 01ABB1D28E; Mon, 11 Mar 2013 10:14:59 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013031110144887-17856 ; Mon, 11 Mar 2013 10:14:48 +0100 Message-ID: <513DA081.7050404@bull.net> Date: Mon, 11 Mar 2013 10:14:41 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/03/2013 10:14:58, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/03/2013 10:14:59, Serialize complete at 11/03/2013 10:14:59 Content-Type: multipart/alternative; boundary="------------010606060500020302040001" Cc: pkix Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 09:15:07 -0000 This is a multi-part message in MIME format. --------------010606060500020302040001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable *Stefan,* ** *The review of your individual draft, took me the time I had during the=20 week for the IETF stuff; hence, why this reply has been delayed.* *The situation is rather simple, if we forget about the editorial comment= s, you have accepted one minor text change and that=92s all.* ** *So the major problems are not solved to my satisfaction.* ** *I have maintained below the portion of the text which needs to be=20 further discussed. ** **My comments are in blue.* ** *There is a new and very important issue that I discovered while reading=20 your comments. ** **See the discussion about singleExtensions and of responseExtensions.* *Comment 8*: You have changed the meaning of the revoked state in a way=20 that is not what I requested. The original text was: *The "revoked" state indicates that the certificate has been revoked* *(either permanantly or temporarily (on hold)).* The new text is: * The "revoked" state indicates that the certificate has been revoked* * either permanently or temporarily on hold (i.e. the revocation reaso= n* * is certificateHold).* By doing this, you do not allow any other case in the future to have a=20 temporary revocation: =93*temporarily on hold=94***is not the same=20 as*=93**temporarily revoked=94**.* I propose the following rewording: *The "revoked" state indicates that the certificate has been revoked * * either permanently or temporarily (e.g. placed on hold).* I substituted "temporarily on hold" with "temporarily. The rest=20 unchanged since the only existing reason code for temporary revocation=20 is certificateHold. *As you say, the only CURRENT existing reason code for temporary=20 revocation is certificateHold. ** **We must not PREVENT other reasons in the future to mean =93temporary=20 revocation=94, hence why the change is needed.* The way the text from draft 13 is now written seems to allow using=20 either *=93unknown=94*or *=93revoked=94*for non-issued certificates. If this is the intent, then the good news is that this does not come=20 anymore into conflict with the French rules which apply for the Administration since OCSP responders from CAs used by the French=20 Ministries having a direct access to the database of issued certificates will be able to use *=93unknown*=94, rather than *=93revoked=94*and the r= eason=20 code *=93onhold=94.* However, the current text is still mandating the use of *Extended=20 Revoked Definition*, but the rational for its need it is very poor. As I have said on the PKIX list, the fact that the revocation date is=20 January 1rst, 1970 is fully sufficient to know that we are in that very=20 special case, and you have not provided a rational to say the contrary. I have. And I have pointed you to the minutes of the last PKIC meeting. The consensus of the WG is to have the extension for just those reasons. As implementer, I don't like heuristics. A date of Jan 1st 1970 may=20 indicate this behaviour, but may just be a misconfiguration. It is not an explicit statement. So we could get rid of it, =85 but the text from section 4.4.8 states: * This extension MAY be present in other responses to signal that the* * responder implements the extended revoked definition in section 2.2.= * I have difficulties to understand what is really meant there (=93other=20 responses=94 ?), since the text states: * This extension indicates that the responder supports the extended* * definition of the "revoked" status to also include non-issued* * certificates according to section 2.2.* Since both =93unknown=94 and revoked=94 can be used, it would be desirabl= e to=20 be able to include the same extension in both cases, but in that case that extension should be renamed. This extension can be included in all responses to signal that a=20 responder implements the expanded definition of revoked. Doing so makes this fact auditable without having to ask for a=20 non-issued cert. I would propose to rename it: "*non-issued certificate*=94 which means=20 that the associated CA has no record of ever having issued a certificate with the certificate serial number in the request (I still consider it=20 as unnecessary in the case of =93revoked=94, but it would be very useful = in=20 the case of =93unknown=94). Of course, the text from section 4.4.8 would need to be revised. I propose the following: * * *4.4.8 Non-issued certificate extension* * This extension MUST be included in the OCSP response when the OCSP* * responder knows that the CA identified in the request has no record* * of ever having issued a certificate with the certificate serial* * number indicated in the request.* * Clients do not have to parse this extension in order to determine* * the status of certificates in responses.* * This extension is identified by the object identifier id-pkix-ocsp-* * non-issued-cert.* * id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::=3D {id-pkix-ocsp= 9}* * The value of the extension SHALL be NULL. This extension MUST NOT be= * * marked critical.* Then the text on page 8 would need to be rearranged. Your extension variant is a significant change to what has been agreed. Your extension would need to be a single response extension, and can't=20 be used to audit the behaviour of the OCSP responder unless you send a request for a non-issued cert. *Hummm !!! We have a very important point there. Thanks to your comment,=20 I now realize that the proposed extension applies to the whole response. However, this is not possible and I will=20 now explain why. An OCSP responder may receive a delegation from several CAs. With some of them, it can use a direct=20 access to the database of certificates, while for some others, it will use CRLs. So the meaning of =93revoked=94=20 will depend of the CA. * ** *This means that the indication cannot be global to the OCSP response.=20 If we use an extension, it can only apply ** **to an individual response and thus MUST in singleExtensions instead of=20 responseExtensions.* ** *Since it is singleExtension, it can used to =93audit the behaviour of th= e=20 OCSP responder=94 and I do not grasp your rational ** **when you say =93unless you send a request for a non-issued cert=94. The= re=20 is no need for sending anything.* We want to avoid sending such fake requests for audit purposes as it may=20 interfere with systems at the responder trying to detect existence of=20 rouge certificates. *There is no need to sending fake requests.* This is a type of change that I can't make unless you get support from a=20 majority of the WG for the change of direction you propose. *The important point is that the text states:* ** *=93The "revoked" state (=85) _MAY also be returned_ if the associated CA= =20 has no record of ever having issued a certificate with the certificate serial number in the request, using any current or=20 previous issuing key (referred to as a "non-issued" certificate in this document).=94* ** *The test does **_not_**state =93**_MUST_**also be returned=94. This mean= s=20 that it is also possible to reply =93unknown=94 if the associated CA ** **has no record of ever having issued a certificate with the certificate=20 serial number in the request. However, this is not ** **straightforward when reading the text and thus the text should be made=20 more explicit.* ** *Now, we get to the main point. The reason for adding an extension is=20 NOT to say that an extended meaning of revoked ** **is being used, but that the INDIVIDUAL response is given using a=20 direct access to the records of the certificates issued by the CA.* The current text is: * This state MAY also be returned if the* * associated CA has no record of ever having issued a certificate with= * * the certificate serial number in the request, using any current or* * previous issuing key (referred to as a "non-issued" certificate in* * this document).* * The "unknown" state indicates that the responder doesn't know about* * the certificate being requested.* * NOTE: The "revoked" state for known non-issued certificate serial* * numbers is allowed in order to reduce the risk of relying* * parties using CRLs as a fall back mechanism, which would be* * considerably higher if an "unknown" response was returned.* * When a responder responds revoked to a status request for a non-* * issued certificate, the responder MUST include the extended revoked* * definition response extension (section 4.4.8) in the response,* * indicating that the OCSP responder supports the extended definition* * of revoked state to also cover non-issued certificates. In addition,= * * the SingleResponse related to this non-issued certificate;* * - MUST provide the revocation reason certificateHold (6),* * - MUST specify the revocationTime January 1, 1970, and;* * - MUST NOT include a CRL References extension (section 4.4.2) or an= y* * CRL Entry Extensions (section 4.4.5).* Proposed text for a replacement: * The "unknown" state indicates that the responder doesn't know about* * the certificate being requested.* =20 * If the OCSP responder knows that CA identified in the request has* * no record of ever having issued a certificate with the certificate* * serial number in the request, using any current or previous issuing* * key (referred to as a "non-issued" certificate in this document),* * the OCSP responder SHALL respond either =93revoked =93 or =93unknown= =94.* This is unfortunately very common in your rewording efforts. When trying=20 to fix one thing, you create new even bigger problems. An infrastructure that provides reproduced responses will respond=20 "unauthorized". This text may be interpreted to interfere with such=20 operations. *I fear I don=92t understand your argument about =93unauthorized=94, but=20 before replying see below my next comment.* Further, and worse. This is not backwards compatible. Current OCSP=20 responders may respond "good" even if they have access to CA records. *You say: =93Current OCSP responders may respond "good" even if they have= =20 access to CA records=94. Originally RFC 2560 allowed returning =93good=94 for OCSP responder using CRLs. Since RFC 2560 provid= ed=20 no way to indicate that a direct access to the database was being used or not, it was not possible to do better. * ** *Now, if an OCSP responder has a direct access and indicates in the=20 response that it has such an access, do you really believe that it will return good ? I don=92t. * ** *If an OCSP responder wants to return =93good=94, it can still do it, but= in=20 that case it will not signal that it is using a direct access ** **and this is perfectly backwards compatible. So I do not =93buy=94 your=20 argumentation.* ** *Now, may be you understand better why I propose to rename the extension=20 =934.4.8 Non-issued certificate extension=94 and ** **also to change its semantics.* * Note: The "revoked" state for known non-issued certificate serial* * numbers is allowed in order to reduce the risk of relying parties* * using CRLs as a fall back mechanism, which would be possible when* * the "unknown" response is returned.* * When a responder responds revoked or unknown to a status request* * for a non-issued certificate, the responder MUST include the* * non-issued certificate extension (see section 4.4.8) in the* * response.* * When a responder responds revoked to a status request for a non-* * issued certificate, in addition, the responder:* * - MUST provide the revocation reason certificateHold (6),* * - MUST specify the revocationTime January 1, 1970, and;* * - MUST NOT include a CRL References extension (section 4.4.2) or an= y* * CRL Entry Extensions (section 4.4.5).* Finally, the last bullet on page 4 should be reworded: Current text: * o Section 4.4.8 specifies a new extension that indicates that the= * * responder supports the extended use of the "revoked" response* * for non-issued certificates defined in section 2.2.* Proposed replacement text: * o Section 4.4.8 specifies a new extension that indicates that* * the OCSP responder knows that CA identified in the request* * has no record of ever having issued a certificate with the* * certificate serial number present in the request, as defined* * in section 2.2.* No. Again, this changes the scope of the extension and its audit properti= es. Such change requires WG consensus. *See earlier comments.* *Comment 9:*Solved, if the comment above may be solved. *Comment 20*:This comment is preliminary classified by you as =93not=20 broken=94. However, since you asked: =93If you don=92t replace 4.2.2.3, then what really are you missing ?=94, I will provide you with an answer. This is the wrong way to state the question. Providing an ASN.1 syntax=20 as in 4.2.1 is not enough: the use of every parameter MUST be explained using English words. So if you explain the use of every parameter after=20 the description of the ASN.1 syntax in section 4.2.1. then section 4.2.2.= 3 is no more needed and thus can be deleted. The answer to your question =93what is really missing=94 is a description= of=20 the use of every parameter listed in the ASN.1 in section 4.2.1 There are sufficient descriptions in the subsections following the ASN.1=20 description. Your change proposals are not compatible with the minimalist= ic approach adopted by the WG. *The key point is whether we want a =93good=94 document or maintain the l= ow=20 quality of the original document.*** *Comment 26*: You asked for explanations. Let me provide you with an=20 example when CRLs are being used by the OCSP responder in the background. The OCSP responder needs to make sure that the CRL it uses is valid. If=20 it is simply using published CRLs (i.e. no trusted link with the CA), it=20 needs to make sure that the CA which has issued the CRL has no been revoked. No, this is a misstatement. You don't revoke CAs. You revoke CA=20 certificates. *Right.* There might be a CA certificate that has been revoked for a reason that=20 does not affect the OCSP responder. * ..but the contrary may also apply.* These are operational policies that are outside the scope of the protocol= . *The proposed text does not affect the protocol.* The proposed text in comment 26 is plain wrong, or at least misleading.=20 The OCSP responder does not have to validate the CRL up to any=20 particular root. It may for example have been configured to directly trust the public key=20 used to validate the CRL. *T**his depends how it makes sure that it is reading the right CRL. It=20 may or may not use a root CA.* In France, there is a root CA for the Administration. However, the use=20 of that root CA is optional. Thus a Ministry may have its own root, but may also have its key certified by the root CA of the=20 Administration. The OCSP responder may use the root CA of the Ministry, while a relying party may use the root CA of the Administration (or the=20 reverse) to validate the CRL for the target certificate. Thus the revocation status will be different if the certificate of the=20 CA of the Ministry is revoked by the root CA of the Administration. Which reinforces my point. How the OCSP responder is configured to trust=20 its information source is outside the scope of the protocol. The OCSP protocol never claims to provide the same conclusion about=20 revocation than another source the relying party may use. *We both agree; however would you point me where this is said in the=20 current draft? Since I could not find it, I believe it is useful to highlight the point in the security=20 considerations section. * * * *Finally, I believe that the major point indicated earlier comes from=20 the original "bad writing" of RFC 2560.* *There is no clear distinction between what applies to=20 ***BasicOCSPResponse* and ***what applies *to Single Response.* *On page 15 from draft-14, the text still states in section 4.2.2.2 =20 Authorized Responder: "It is necessary however to ensure that the entity signing this=20 information is authorized to do so". This is vague. What is "this information " ? This text is within section=20 "4.2.2 Notes on OCSP Responses". This does not help much. Is it BasicOCSPResponse ? If it is , this is wrong. It is SingleResponse, since a single response may be signed by the right=20 key and/or the right certificate, but not another single response. How can a reader guess that it is SingleResponse ? Once again the quality of the text is really bad, and that text and some=20 other portions (3.2 Signed Response Acceptance Requirements) would need to be changed. * ** *Denis* > Denis, > > My replies in line; > > From: Denis Pinkas > > Date: Monday, February 11, 2013 3:18 PM > To: Stefan Santesson > > Cc: Stephen Kent >, pkix=20 > > > Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC > > Stefan, > > I have finally reviewed your disposition of comments. I have used > draft 13. > > I will not address the comments in sequence, but I will consider > four categories: > > *Category 1)*Some comments which seem to be solved. Yes indeed, > they may be a few of them ! > > *Category 2)*Some comments which might possibly be solved at the > WG level. > > *Category 3)*Some comments that I will address at the IETF last > call level, rather than the WG last call level, since I disagree > that it is =93new ways to say the same thing=94 and it is likely to= be > a waste of time for both of us to argue again at the WG level > (these comments are commented as =93not broken=94). > > *Category 4)*Some typos and editorials found while reading draft 13= . > > *CATEGORY 1* > > *Comment 4*(was editorial). > > *Comment 5.* > > ** > > *Comment 6. * > > *Comment 19*. Solved, since *=93unknown=94*seems now to be also > allowed for non-issued certificates > (even if the OCSP responder is using a direct access to the > certificate database). See comment 8. > > *Comment 13*: Acceptable, since the text uses *=93MAY=94.* > > *Comment 18. * > > *Comment 22.* > > *Comment 23.* > > *Comment 28.* > > *CATEGORY 1* > > *Comment 8*: You have changed the meaning of the revoked state in > a way that is not what I requested. > > The original text was: > > *The "revoked" state indicates that the certificate has been revoke= d* > > *(either permanantly or temporarily (on hold)).* > > The new text is: > > ** > > * The "revoked" state indicates that the certificate has been re= voked* > > * either permanently or temporarily on hold (i.e. the revocation= reason* > > * is certificateHold).* > > By doing this, you do not allow any other case in the future to > have a temporary revocation: =93*temporarily on hold=94** > *is not the same as*=93**temporarily revoked=94**.* > > I propose the following rewording: > > *The "revoked" state indicates that the certificate has been revoke= d * > > * either permanently or temporarily (e.g. placed on hold).* > > > I substituted "temporarily on hold" with "temporarily. The rest=20 > unchanged since the only existing reason code for temporary revocation=20 > is certificateHold. > > > > The way the text from draft 13 is now written seems to allow using > either *=93unknown=94*or *=93revoked=94*for non-issued certificates= . > If this is the intent, then the good news is that this does not > come anymore into conflict with the French rules which apply for > the Administration since OCSP responders from CAs used by the > French Ministries having a direct access to the database > of issued certificates will be able to use *=93unknown*=94, rather > than *=93revoked=94*and the reason code *=93onhold=94.* > > However, the current text is still mandating the use of *Extended > Revoked Definition*, but the rational for its need it is very poor. > As I have said on the PKIX list, the fact that the revocation date > is January 1rst, 1970 is fully sufficient to know that we are in th= at > very special case, and you have not provided a rational to say the > contrary. > > > I have. And I have pointed you to the minutes of the last PKIC meeting. > The consensus of the WG is to have the extension for just those reasons= . > > As implementer, I don't like heuristics. A date of Jan 1st 1970 may=20 > indicate this behaviour, but may just be a misconfiguration. It is not=20 > an explicit statement. > > So we could get rid of it, =85 but the text from section 4.4.8 stat= es: > > * This extension MAY be present in other responses to signal tha= t the* > > * responder implements the extended revoked definition in sectio= n 2.2.* > > I have difficulties to understand what is really meant there > (=93other responses=94 ?), since the text states: > > * This extension indicates that the responder supports the exten= ded* > > * definition of the "revoked" status to also include non-issued* > > * certificates according to section 2.2.* > > Since both =93unknown=94 and revoked=94 can be used, it would be > desirable to be able to include the same extension in both cases, > but in that case that extension should be renamed. > > > This extension can be included in all responses to signal that a=20 > responder implements the expanded definition of revoked. > Doing so makes this fact auditable without having to ask for a=20 > non-issued cert. > > > I would propose to rename it: "*non-issued certificate*=94 which > means that the associated CA has no record of ever having issued > a certificate with the certificate serial number in the request (I > still consider it as unnecessary in the case of =93revoked=94, but = it > would be > very useful in the case of =93unknown=94). Of course, the text from > section 4.4.8 would need to be revised. > > I propose the following: > > *4.4.8 Non-issued certificate extension* > > * * > > * This extension MUST be included in the OCSP response when the = OCSP* > > * responder knows that the CA identified in the request has no r= ecord* > > * of ever having issued a certificate with the certificate seria= l* > > * number indicated in the request.* > > * * > > * Clients do not have to parse this extension in order to determ= ine* > > * the status of certificates in responses.* > > * * > > * This extension is identified by the object identifier id-pkix-= ocsp-* > > * non-issued-cert.* > > * * > > * id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::=3D {id-pki= x-ocsp 9}* > > * * > > * The value of the extension SHALL be NULL. This extension MUST = NOT be* > > * marked critical.* > > Then the text on page 8 would need to be rearranged. > > > Your extension variant is a significant change to what has been agreed= . > Your extension would need to be a single response extension, and can't=20 > be used to audit the behaviour of the OCSP responder unless you send a=20 > request for a non-issued cert. > We want to avoid sending such fake requests for audit purposes as it=20 > may interfere with systems at the responder trying to detect existence=20 > of rouge certificates. > > This is a type of change that I can't make unless you get support from=20 > a majority of the WG for the change of direction you propose. > > The current text is: > > * This state MAY also be returned if the* > > * associated CA has no record of ever having issued a certificat= e with* > > * the certificate serial number in the request, using any curren= t or* > > * previous issuing key (referred to as a "non-issued" certificat= e in* > > * this document).* > > * * > > * The "unknown" state indicates that the responder doesn't know = about* > > * the certificate being requested.* > > * * > > * NOTE: The "revoked" state for known non-issued certificate ser= ial* > > * numbers is allowed in order to reduce the risk of relyin= g* > > * parties using CRLs as a fall back mechanism, which would= be* > > * considerably higher if an "unknown" response was returne= d.* > > * * > > * When a responder responds revoked to a status request for a no= n-* > > * issued certificate, the responder MUST include the extended re= voked* > > * definition response extension (section 4.4.8) in the response,= * > > * indicating that the OCSP responder supports the extended defin= ition* > > * of revoked state to also cover non-issued certificates. In add= ition,* > > * the SingleResponse related to this non-issued certificate;* > > * * > > * - MUST provide the revocation reason certificateHold (6),* > > * * > > * - MUST specify the revocationTime January 1, 1970, and;* > > * * > > * - MUST NOT include a CRL References extension (section 4.4.2= ) or any* > > * CRL Entry Extensions (section 4.4.5).* > > Proposed text for a replacement: > > * The "unknown" state indicates that the responder doesn't know = about* > > * the certificate being requested.* > > * * > > * If the OCSP responder knows that CA identified in the request = has* > > * no record of ever having issued a certificate with the certifi= cate* > > * serial number in the request, using any current or previous is= suing* > > * key (referred to as a "non-issued" certificate in this documen= t),* > > * the OCSP responder SHALL respond either =93revoked =93 or =93u= nknown=94.* > > > This is unfortunately very common in your rewording efforts. When=20 > trying to fix one thing, you create new even bigger problems. > > An infrastructure that provides reproduced responses will respond=20 > "unauthorized". This text may be interpreted to interfere with such=20 > operations. > Further, and worse. This is not backwards compatible. Current OCSP=20 > responders may respond "good" even if they have access to CA records. > > * * > > * Note: The "revoked" state for known non-issued certificate ser= ial* > > * numbers is allowed in order to reduce the risk of relying part= ies* > > * using CRLs as a fall back mechanism, which would be possible w= hen* > > * the "unknown" response is returned.* > > * * > > * When a responder responds revoked or unknown to a status reque= st* > > * for a non-issued certificate, the responder MUST include the* > > * non-issued certificate extension (see section 4.4.8) in the* > > * response.* > > * * > > * When a responder responds revoked to a status request for a no= n-* > > * issued certificate, in addition, the responder:* > > * * > > * - MUST provide the revocation reason certificateHold (6),* > > * * > > * - MUST specify the revocationTime January 1, 1970, and;* > > * * > > * - MUST NOT include a CRL References extension (section 4.4.2)= or any* > > * CRL Entry Extensions (section 4.4.5).* > > Finally, the last bullet on page 4 should be reworded: > > Current text: > > * o Section 4.4.8 specifies a new extension that indicates th= at the* > > * responder supports the extended use of the "revoked" res= ponse* > > * for non-issued certificates defined in section 2.2.* > > ** > > Proposed replacement text: > > * o Section 4.4.8 specifies a new extension that indicates t= hat* > > * the OCSP responder knows that CA identified in the reque= st* > > * has no record of ever having issued a certificate with t= he* > > * certificate serial number present in the request, as def= ined* > > * in section 2.2.* > > > No. Again, this changes the scope of the extension and its audit=20 > properties. > Such change requires WG consensus. > > > *Comment 9:*Solved, if the comment above may be solved. > > *Comment 20*:This comment is preliminary classified by you as =93no= t > broken=94. However, since you asked: =93If you don=92t replace 4.2.= 2.3, > then what really are you missing ?=94, I will provide you with an > answer. > > This is the wrong way to state the question. Providing an ASN.1 > syntax as in 4.2.1 is not enough: the use of every parameter > MUST be explained using English words. So if you explain the use > of every parameter after the description of the ASN.1 syntax > in section 4.2.1. then section 4.2.2.3 is no more needed and thus > can be deleted. > > The answer to your question =93what is really missing=94 is a > description of the use of every parameter listed in the ASN.1 in > section 4.2.1 > > > There are sufficient descriptions in the subsections following the=20 > ASN.1 description. Your change proposals are not compatible with the=20 > minimalistic approach adopted by the WG. > > > *Comment 21.* > > While I can agree in general with the intent of the text, I do not > understand the first sentence of the Note which speaks of =93CA key > rollover=94 > and is copied below: > > * Note: CA key rollover is not prohibited when issuing a certifi= cate* > > * for an authorized responder for backwards compatibility = with* > > * RFC 2560 [RFC2560]. That is, it is not prohibited to iss= ue a* > > * certificate for an authorized responder using a differen= t* > > * issuing key than the key used to issued the certificate = being* > > * checked for revocation. However, such practice is strong= ly* > > * discouraged since clients are not required to recognize = a* > > * responder with such certificate as an authorized respond= er.* > > I would propose to delete it, since it does not add anything and > thus to have: > > * Note: For backwards compatibility with RFC 2560 [RFC2560], it = is* > > * not prohibited to issue a certificate for an authorized* > > * responder using a different issuing key than the key use= d to* > > * issued the certificate being checked for revocation.* > > * However, such practice is strongly discouraged since cli= ents* > > * are not required to recognize a responder with such* > > * certificate as an authorized responder.* > > > I agree, your text is better. Updated. > > *Comment 24*: The ASN.1 module in annex B.1 is still wrong, since > it does not define NoCheck. > > > No you are wrong. We have confirmed with several ASN.1 experts that=20 > definition of NoCheck is not necessary to define null content. > The current definition is perfectly valid ASN.1 > > *Comment 26*: You asked for explanations. Let me provide you with > an example when CRLs are being used by the OCSP responder > in the background. The OCSP responder needs to make sure that the > CRL it uses is valid. If it is simply using published CRLs > (i.e. no trusted link with the CA), it needs to make sure that the > CA which has issued the CRL has no been revoked. > > > No, this is a misstatement. You don't revoke CAs. You revoke CA=20 > certificates. There might be a CA certificate that has been revoked=20 > for a reason that does not affect the OCSP responder. > These are operational policies that are outside the scope of the protoc= ol. > > The proposed text in comment 26 is plain wrong, or at least=20 > misleading. The OCSP responder does not have to validate the CRL up to=20 > any particular root. It may for example have been configured to=20 > directly trust the public key used to validate the CRL. > > > In France, there is a root CA for the Administration. However, the > use of that root CA is optional. Thus a Ministry may have its own > root, > but may also have its key certified by the root CA of the > Administration. The OCSP responder may use the root CA of the > Ministry, > while a relying party may use the root CA of the Administration > (or the reverse) to validate the CRL for the target certificate. > Thus the revocation status will be different if the certificate of > the CA of the Ministry is revoked by the root CA of the > Administration. > > > Which reinforces my point. How the OCSP responder is configured to=20 > trust its information source is outside the scope of the protocol. > > The OCSP protocol never claims to provide the same conclusion about=20 > revocation than another source the relying party may use. > > I skip category 3 as this will be dealt with in IESG last call. > > > *CATEGORY 3* > > *Comments*2, 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27. > > *CATEGORY 4* > > Page 4. The indentation of the bullets in section 1 is not uniform. > Bullets 1, 4, 5 and 9 have problems. > > Page 4. The fact that there is now an Annex B.2 dealing with the > 2008 ASN.1 syntax is missing. This should be added. > > Page 10. Change =93*Se further section 4.2.2.2=94*into =93*See furt= her > section 4.2.2.2=94 > * > > > > Thanks. I have fixed them all. > > /Stefan > > > Denis > ** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >> Denis, >> >> Responding to your comments below. >> >> However, one general remark to make recurring comments easier to >> understand. >> >> The WG decided to adopt a minimalistic approach to updating RFC >> 2560. That means that >> >> 1. We don't change anything from RFC 2560 unless it is broken, >> or the industry clearly need clarifications in order to avoid >> interoperability issues. >> 2. We retain the document structure of RFC 2560 as much as >> possible to allow easy comparison of what the changes are in >> comparison with RFC 2560. >> >> >> One can always think up more clever ways to write things out in >> words. But that also comes with a risk. >> The current words has been around for a long time and we know >> from experience which words worked to produce working >> implementations, and which did not. >> Introducing new ways to say the same thing may introduce new >> problems and people might disagree on what the new perfect >> wording should be. And this could go on forever. >> >> So when my reply is "Not broken", then that is because the >> current wording does not have such problems that is merits a chang= e. >> >> >> >> From: Denis Pinkas > > >> Date: Sunday, January 20, 2013 5:12 PM >> To: Stefan Santesson > >, Stephen Kent > > >> Cc: pkix > >> Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC >> >> Please find 32 comments on draft-ietf-pkix-rfc2560bis >> >> 1.The document states: >> >> **> responded to separately> >> >> >> Responded to separately. >> >> 2.The current text from section 2 states: >> >> 2. Protocol Overview >> >> =20 >> >> In lieu of or as a supplement to checking against a period= ic CRL, it >> >> may be necessary to obtain*timely information* regarding = the >> >> revocation status of a certificate (cf. RFC5280], Section = 3.3). >> >> Examples include high-value funds transfer or large stock = trades. >> >> =20 >> >> The Online Certificate Status Protocol (OCSP) enables appl= ications to >> >> determine the (revocation) state of an identified certific= ate. OCSP >> >> may be used to satisfy some of the operational requirement= s of >> >> providing*more timely revocation information* than is pos= sible with >> >> CRLs and may also be used to obtain additional status info= rmation. >> >> =20 >> >> This text is misleading because readers may think that OCPS ne= cessarily provides =93timely information=94. >> >> =20 >> >> >> "may" does not mean "necessarily". >> >> Proposed text replacement: >> >> =20 >> >> *The Online Certificate Status Protocol (OCSP) is a >> client-server * >> >> *protocol which enables applications to obtain the revocation >> status * >> >> *of one or more certificates either "good", "revoked", or >> "unknown".* >> >> ** >> >> *The revocation status may be provided by the server either >> using a * >> >> *real time access to a database of issued certificates, or >> using a * >> >> *batch access to a database of issued certificates, or using a= * >> >> *real time access to a database of revocation statuses of >> issued * >> >> *certificates, or using a batch access to a database of >> revocation * >> >> *statuses of issued certificates, or using CRLs, or using a * >> >> *combination of base CRLs and delta CRLs.* >> >> ** >> >> *In the first case, it is possible to obtain timely >> revocation status * >> >> *information, whereas in the other cases, the freshness of the= * >> >> *revocation status is not better than the mechanisms it is >> based on.* >> >> =20 >> >> =20 >> >> >> Not broken >> >> 3.The current text from section 2 states: >> >> =20 >> >> An OCSP client issues a status request to an OCSP responde= r and >> >> Suspends acceptance of*the certificate in question* until= the >> >> responder provides a response. >> >> =20 >> >> This protocol specifies the data that needs to be exchange= d between >> >> an application checking the status of a certificate and th= e server >> >> providing that status. >> >> =20 >> >> Thus is insufficient for an overview. More details are needed = to know what the document provides, >> in particular that the request may contain several requests fo= r several certificates issued by different CAs. >> The possibility of using extensions should also be advertised. >> >> =20 >> >> Proposed text replacement: >> >> =20 >> >> When using OCSP, an OCSP client issues a certificate revocatio= n >> >> status request to an OCSP responder *for one or more >> certificates * >> >> *issued by the same CA or for one or more certificates issued >> by * >> >> *different CAs *and then suspends acceptance of the >> certificate(s) >> >> in question until the responder provides a response. >> >> This document specifies the data that needs to be exchanged >> between >> >> an application checking the status of a certificate and the >> server >> >> providing that status. >> >> *OCSP may also provide additional status information using * >> >> *extensions. * >> >> >> Not broken >> >> 4.Page 6. Editorial. Punctuation and a CR/LF are missing. >> >> The text states: >> >> * 3. the request contains the information needed by the res= ponder If* >> >> * any one of the prior conditions are not met, the OCSP = responder* >> >> * produces an error message; otherwise, it returns a def= initive* >> >> * response.* >> >> It should state: >> >> * 4. the request contains the information needed by the res= ponder.* >> >> * * >> >> * If any one of the prior conditions are not met, the OC= SP responder* >> >> * produces an error message; otherwise, it returns a def= initive* >> >> * response.* >> >> >> Fixed in draft 10. >> >> 5.On page 7, the text states: >> >> ** >> >> *All definitive response messages SHALL be digitally signed. >> The key* >> >> *used to sign the response MUST belong to one of the following= :* >> >> * * >> >> * - the CA who issued the certificate in question* >> >> * - a Trusted Responder whose public key is trusted by th= e requester* >> >> * - a CA Designated Responder (Authorized Responder) who = holds a* >> >> * specially marked certificate issued directly by the CA= , indicating* >> >> * that the responder may issue OCSP responses for that C= A.* >> >> ** >> >> The paragraph is ambiguous on several aspects. >> >> Delegation is addressed in at least three different places, >> but with different terms and conditions. >> If some one picks a sentence in one paragraph rather than >> another, it will lead to a different conclusion. >> RFCs are supposed to be clear. >> >> On page 10, the current text states in section*2.6 OCSP >> Signature Authority Delegation *states: >> >> =20 >> >> *The key that signs a certificate's status information need >> not be the* >> >> *same key that signed the certificate.**A certificate's issuer= * >> >> *explicitly delegates OCSP signing authority by issuing a >> certificate* >> >> *containing a unique value for extendedKeyUsage in the OCSP >> signer's* >> >> *certificate. This certificate MUST be issued directly to the* >> >> *responder by the cognizant CA.* >> >> =20 >> >> On page 16, there is a section >> *4.2.2.2***called*=93**Authorized Responders=94*dealing with t= he >> same topic. >> >> Section 4.2.2.2 states: >> >> *The key that signs a certificate's status information need >> not be the* >> >> *same key that signed the certificate**. It is necessary >> however to* >> >> *ensure that the entity signing this information is >> authorized to do* >> >> *so.Therefore, a certificate's issuer MAY either sign the OCSP= * >> >> *responses itself or it MAY explicitly designate this >> authority to* >> >> *another entity.OCSP signing delegation SHALL be designated >> by the* >> >> *inclusion of id-kp-OCSPSigning in an extendedKeyUsage >> certificate* >> >> *extension included in the OCSP response signer's >> certificate.This* >> >> *certificate MUST be issued directly by the CA that issued the= * >> >> *certificate in question.* >> >> ** >> >> *The CA SHOULD use the same issuing key to issue a delegation* >> >> *certificate as was used to sign the certificate being >> checked for* >> >> *revocation. Systems relying on OCSP responses MUST recognize = a* >> >> *delegation certificate as being issued by the CA that issued >> the* >> >> *certificate in question only if the delegation certificate >> and the* >> >> *certificate being checked for revocation was signed by the >> same key.*** >> >> The last sentence above in yellow is the key sentence that is >> missing in the two other sections. >> >> =20 >> >> Most implementations only support the case where the OCSP Resp= onder receives an OCSP certificate that is signed by the same key >> that was used to sign the target certificate. They do not supp= ort the case where the OCSP Responder receives an OCSP certificate >> that is signed by a key that is different from the one that wa= s used to sign the target certificate. >> >> It is inappropriate to have three sections dealing with the >> same topic with a slightly different meaning. >> >> It is proposed the following. >> >> On page 7, after: >> >> * - a CA Designated Responder (Authorized Responder) who = holds a* >> >> * specially marked certificate issued directly by the CA= , indicating* >> >> * that the responder may issue OCSP responses for that C= A.* >> >> it is proposed to add =93(*see section 4.2.2.2 for further >> details**)=94*, so that the reader knows that more details are >> provided later on. >> >> Then we do not need two sections to address delegation which >> start with the same sentence: >> >> >> =93*The key that signs a certificate's status information need >> not be the same key that signed the certificate=94.* >> >> ** >> >> It is thus proposed to delete section 2.6. >> >> Section 4.2.2.2 will thus remain the single section providing >> full details. >> >> =20 >> >> >> I have added references to section 4.2.2.2 in the quoted sections >> in 2.2 and 2.6. >> (will be included in draft 11) >> >> >> 6. Page 7, the text states: >> >> * A definitive response message is composed of:* >> >> * * >> >> * - version of the response syntax* >> >> * - name of the responder* >> >> * - responses for each of the certificates in a request* >> >> * - optional extensions* >> >> * - signature algorithm OID* >> >> * - signature computed across hash of the response* >> >> This description does not fit with the ASN.1 syntax which is >> detailed later on, and in particular: >> >> * ResponseData ::=3D SEQUENCE {* >> >> * version [0] EXPLICIT Version DEFAULT v1,= * >> >> * **responderID ResponderID,* >> >> * producedAt GeneralizedTime,* >> >> * responses SEQUENCE OF SingleResponse,* >> >> * responseExtensions [1] EXPLICIT Extensions OPTIONAL= }* >> >> Proposed text replacement: >> >> *A definitive response message is composed of:* >> >> ** >> >> *- a response status and if there is no error, the following:* >> >> *- the version of the response syntax,* >> >> *- an identifier of the OCSP server,* >> >> *- the time at which the response was produced,* >> >> *- single responses for each of the target certificates,* >> >> *- optional extensions,* >> >> *- the signature algorithm OID,* >> >> *- the signature computed across hash of the response, and* >> >> *- optional certificates.* >> >> >> This is an overview section. We ought not try to duplicate the >> level of detail provided in the detailed protocol section. >> A "definitive response" according to tho 2.1 is a response to an >> error-free request, so your first remark is redundant. >> >> I have added a note about time to the current list, and changed >> "name" to identifier in bullet 2. >> (will be included in draft 11) >> >> 7.The text states on page 7: >> >> *The response for each of the certificates in a request >> consists of* >> >> ** >> >> *-target certificate identifier* >> >> *-certificate status value* >> >> *-response validity interval* >> >> *-optional extensions* >> >> However, there are no explanations for the purpose of these >> parameters and how they should be processed. >> >> There are also no explanations on how to process a single >> response and how to verify that it is its presence within the >> signed structure >> is valid or not valid. This is a major deficiency of the >> current description of RC 2560 where there is no explanation >> on how to validate >> a single response. >> >> Text proposal to be added after: >> >> *The purpose of the identifier of the OCSP server is to allow >> OCSP * >> >> *clients to find whether the definitive response was signed >> by a CA * >> >> *or by an OCSP Responder.* >> >> ** >> >> *The identifier of the OCSP server SHOULD either be the name >> or the * >> >> *key from a CA, or the name or the key from a OCSP Responder.* >> >> ** >> >> *Unless there exist local rules (which are outside the scope >> of this * >> >> *document) for verifying that a single response is correctly >> signed, * >> >> *the following applies:* >> >> *When the identifier matches with the name of the CA which >> has issued * >> >> *the target certificate or corresponds to the key used to >> issue the * >> >> *target certificate, then a single response is correctly signe= d * >> >> *only if the digital signature of the OCSP response is valid >> using the * >> >> *key used to sign the target certificate.* >> >> ** >> >> *When the identifier does not match with the name of the CA >> which has * >> >> *issued the target certificate or does not correspond to the >> key used * >> >> *to issue the target certificate, then an single response is >> correctly * >> >> *signed only if :* >> >> ** >> >> *(a) there exists in the response an OCSP certificate issued b= y * >> >> *the CA which has issued the target certificate which is * >> >> *signed by the same key as the one used to issue the * >> >> *target certificate, and* >> >> ** >> >> *(b) the digital signature of the OCSP response is valid using= * >> >> *the subjectPublicKey contained in this OCSP certificate.* >> >> >> Not broken. >> All of this is already covered by the document. >> >> 8.The text states on page 7: >> >> The "revoked" state indicates that the certificate has been >> revoked >> >> *(either permanently or temporarily (on hold)). *This state >> MAY also be >> >> returned if the responder knows that the requested >> certificate has >> >> *never been issued during the history of the associated CA >> *using any >> >> current or previous issuing key. ** >> >> The text is ambiguous because there are two embedded >> parenthesis and it is unclear whether the inner parenthesis >> means =93i.e=94 or =93e.g=94. >> This single sentence may let think that on hold is the single >> case for temporarily revocation. Since neither X.509 nor RFC >> 5280 address >> the case of a temporary revocation in the context of an OCSP >> response (but only in the context of CRLs), we are able to >> add another case >> of temporary revocation which will only apply in the context >> of OCSP. >> >> The above sentence using the terms=93*never been issued during >> the history of the associated CA*=93does not capture the fact >> that it could be issued in the future, hence why using=93*not >> yet been used=94*would be more appropriate. >> >> Finally, it would have been more logical to use =93unknown=94.= So >> it is important to add a note to explain why we have chosen >> that case for =93legacy clients=94, >> otherwise the people who have not participate to the >> exchanges will not understand. >> >> Proposed text replacement: >> >> *The "revoked" state indicates that the certificate has be= en revoked,* >> >> * either permanently or temporarily.* >> >> =20 >> >> A certificate may be temporarily revoked either because it= is >> >> placed on hold (*i.e. the revocation reason is certificate= Hold*) or >> >> because the responder is able to know, using a positive li= st of >> >> issued certificates, that the serial number from the reque= sted >> >> certificate has*not yet been used* by the CA to issue a c= ertificate >> >> (*i.e. the revocation reason is notIssuedOrIrregularlyIssu= ed*). >> >> =20 >> >> *NOTE: The "revoked" state is used rather than the =93unknown=94= state, to* >> >> * make sure that relying parties that were conformant to= RFC 2560* >> >> * will not use CRLs as a fall back mechanism.* >> >> =20 >> >> >> I removed the double parenthesis and adopted your clarification >> with regard to "on hold". >> >> The text in draft 10 has changed from what you have commented on. >> I believe that text is better. >> >> You "Note" has problems. >> >> 1. We do not prevent responders to respond "unknown" if their >> assessment is that this is an appropriate response, >> considering what they know about the requested serial number. >> Thus the term "is used" is misleading. >> 2. This mechanisms does not "make sure" that the clients do >> anything. It's up to the discretion of the relying party to >> decide what source of revocation checking they rely on. This >> does however reduce the risk of clients falling back to CRL:s >> 3. This mechanism is not just relevant to old clients, but also >> to new one for the same reason. >> >> >> I have adopted a modified version of your Note: >> >> NOTE: The "revoked" state for known non-issued certificate seri= al >> numbers is allowed in order to reduce the risk of relying >> parties using CRLs as a fall back mechanism, which would = be >> considerably higher if an "unknown" response was returned= . >> >> >> >> 9.The text states on page 8: >> >> *When a responder responds revoked to a status request for a >> non-* >> >> *issued certificate, the responder MUST also;* >> >> ** >> >> *- include the extended revoked definition response extension* >> >> *(section 4.8), indicating that the OCSP responder supports th= e* >> >> *extended definition of revoked state to also cover non-issued= * >> >> *certificates,* >> >> ** >> >> *- provide the revocation reason certificateHold (6), and;* >> >> ** >> >> *- specify the revocation date January 1, 1970. * >> >> As already explained on the PKIX list, using the revocation >> reason**certificateHold is not appropriate >> because it changes the meaning of certificateHold. >> >> The extended revoked definition response extension is a means >> to signal that it not a true certificate hold but a =93not >> issued certificate=94. >> Legacy applications cannot take advantage of it. >> >> Some applications which handle non repudiation enter a >> waiting state when the revocation reason certificateHold is >> used thus >> it is not appropriate to overload the meaning. >> >> ** >> >> It is possible to use another enumeration for signalling that >> specific case: >> >> notIssuedOrIrregularlyIssued (7). >> >> ** >> >> Thus for new applications it would be much better to use >> notIssuedOrIrregularlyIssued (7) as already proposed on the >> PKIX list. >> >> The above sentence uses the text: =20 >> >> =20 >> >> =93a status request for a*non-issued certificate*=94 >> >> =20 >> >> whereas it would be more appropriate to state: =20 >> >> =20 >> >> =93a status request for a* serial number which has not been u= sed by the CA or used irregularly to issue a certificate=94.* >> >> * * >> >> Placing the ASN.1 description at such a place in the document = is inappropriate since the ASN.1 structures have not yet been described. >> Thus only the functional aspects should be mentioned, but not = the ASN.1 implications. >> >> * * >> >> BTW, the description should follow the same order as the ASN.1= . This is not the case. >> >> =20 >> >> This text should be deleted from this section and the appropri= ate text should be added when the parameters of the response are describe= d. >> >> =20 >> >> The text proposed in the previous comment should be sufficient= at this time of reading. >> >> =20 >> >> In addition, section*4.4.8Extended Revoked Definition *should >> be deleted.** >> >> =20 >> >> =20 >> >> >> The referred text has been updates in draft 09. >> >> This has been discussed on the list and you have yet to convince >> the list of your new reason code. >> I disagree as the risk of running into problems with the deployed >> base of application is hugely larger with introduction of a new >> reason code, rather than using certificateHold. >> No application should be broken, since no application have >> business asking for non-issued cert serial numbers in the first >> place. Secondly, no application can assume that a certificateHold >> reason will be cleared any time soon. >> >> >> 10.The text states on page 8: >> >> *2.4Semantics of thisUpdate, nextUpdate and producedAt* >> >> This section is misplaced. At this time of reading, the >> reader does not know that thisUpdate, nextUpdate and >> producedAt are values >> used by the ASN.1 structures. It is appropriate to describe >> what theses parameters mean when the ASN.1 syntax is described= . >> The current ASN.1 syntax is very badly described. One would >> expect that after every ASN.1 structure description every >> parameter is described. >> Unfortunately this is not the case. >> >> The text from this section is not aligned with the text that >> is present in section 4.2.2.1. >> >> In particular, in section 2.4: >> >> ** >> >> *If nextUpdate is not set, the responder is indicating that >> newer* >> >> *revocation information is available all the time.* >> >> While in section 4.2.2.1: >> >> *Responses where the nextUpdate value is not set are equivalen= t * >> >> *to a CRL with no time for nextUpdate (see Section 2.4).* >> >> It is not appropriate to have two different descriptions in >> two different places. >> >> Delete section 2.4. See comment number 19 for the description >> of these parameters. >> >> >> Not broken. >> The current text segments fits well into a protocol overview secti= on. >> >> 11.Section 2.5 is also misplaced. They use values from the >> ASN.1 syntax which has not yet been described. >> They should be moved or incorporated in the document once the >> ASN.1 description has been done. >> >> >> Not broken. >> >> 12.Remainder: Section 2.6 should be deleted (see comment >> number 5). >> >> >> Not broken. >> >> 13.Section 2.7 states: >> >> *2.7CA Key Compromise* >> >> ** >> >> *If an OCSP responder knows that a particular CA's private >> key has* >> >> *been compromised, it MAY return the revoked state for all* >> >> *certificates issued by that CA.* >> >> This section is misleading and should be removed. The reason >> is the following: >> >> The relying party must verify that the singleResponse is >> signed by a responder which is entitled to do so. >> >> a) If the CA key has been compromised and if the response is >> signed by that CA key then the singleResponse will be discarde= d >> when performing the certification path validation _whatever >> the content of the response may be_. >> >> b) If the CA key which has issued the OCSP certificate has >> been compromised and if the response is signed by the key >> present >> in the OCSP certificate then the singleResponse will be >> discarded when performing the certification path validation >> _whatever the content of the response may be_. >> >> Security must be provided using the validation of the >> certification path. Thus it does not matter what the OCSP >> responder states. >> >> >> >> Not broken. >> An OCSP responder does not have to be chained to the broken CA. >> The relying party may have other trust configuration at choice. >> >> >> >> 14.The text states on page 11: >> >> *3.2Signed Response Acceptance Requirements* >> >> ** >> >> *Prior to accepting a signed response as valid, OCSP clients >> SHALL* >> >> *confirm that:* >> >> ** >> >> *1. The certificate identified in a received response >> corresponds to* >> >> *that which was identified in the corresponding request;* >> >> ** >> >> *2. The signature on the response is valid;* >> >> ** >> >> *3. The identity of the signer matches the intended recipient >> of the* >> >> *request.* >> >> ** >> >> *4. The signer is currently authorized to sign the response.* >> >> ** >> >> *5. The time at which the status being indicated is known to b= e* >> >> *correct (thisUpdate) is sufficiently recent.* >> >> ** >> >> *6. When available, the time at or before which newer >> information will* >> >> *be available about the status of the certificate >> (nextUpdate) is* >> >> *greater than the current time.* >> >> This section is misplaced since it uses terms from the ASN.1 >> syntax and the protocol description has not yet been made, >> since it is the next section 4. Its text is not correct either= . >> >> This description does not take into account the fact that >> a*BasicOCSPResponse *may contain one or several >> *SingleResponses. * >> In particular, the sentence=93*The signer is currently >> authorized to sign the response*=94 is misleading because a si= gner >> may be authorized to include some***SingleResponses *but not >> necessarily all of them. >> >> The appropriate explanations should be done after the >> description of the response, when describing the processing >> of the response. >> >> Delete that section. >> >> >> Not broken. >> >> 15.On page 12, after the ASN.1 description, the only >> parameters which are described are: >> >> *hashAlgorithm,**issuerNameHash, issuerKeyHash and serialNumbe= r.* >> >> ** >> >> This is insufficient.In order to cover the full list of >> parameters, the following text is proposed: >> >> *requestorName is optional and MAY be used by the server for >> access * >> >> *control and audit purposes.* >> >> ** >> >> *requestList contains one or more single requests.* >> >> ** >> >> *requestExtensions is OPTIONAL.Any specific extension is >> OPTIONAL.* >> >> *The critical flag SHOULD NOT be set for any of them. Section >> 4.4 * >> >> *suggests several useful extensions.Additional extensions MAY >> be * >> >> *defined in additional RFCs.* >> >> ** >> >> *reqCert contains the identifier of a target certificate.* >> >> ** >> >> *issuerNameHash is the hash of the Issuer's distinguished >> name.The * >> >> *hash shall be calculated over the DER encoding of the >> issuer's name * >> >> *field in the certificate being checked. * >> >> ** >> >> *issuerKeyHash is the hash of the Issuer's public key.The hash= * >> >> *shall be calculated over the value (excluding tag and >> length) of the * >> >> *subject public key field in the issuer's certificate.The hash= * >> >> *algorithm used for both these hashes, is identified in * >> >> *hashAlgorithm. * >> >> ** >> >> *The primary reason to use the hash of the CA's public key in = * >> >> *addition to the hash of the CA's name, to identify the issuer= , * >> >> *is that it is possible that two CAs may choose to use the sam= e * >> >> *name (uniqueness in the Name is a recommendation that cannot >> be * >> >> *enforced). Two CAs will never, however, have the same public >> key * >> >> *unless the CAs either explicitly decided to share their >> private * >> >> *key, or the key of one of the CAs was compromised.* >> >> ** >> >> *serialNumber is the serial number of the certificate for whic= h * >> >> *status is being requested.* >> >> ** >> >> *singleRequestExtensions is OPTIONAL.Any specific extension is= * >> >> *OPTIONAL.The critical flag SHOULD NOT be set for any of them.= * >> >> ** >> >> *The requestor MAY choose to sign the OCSP request.In that >> case, the* >> >> *signature is computed over the tbsRequest structure.If the >> request* >> >> *is signed, the requestor SHALL specify its name in the >> requestorName* >> >> *field.Also, for signed requests, the requestor MAY include* >> >> *certificates that help the OCSP responder verify the >> requestor's* >> >> *signature in the certs field of Signature.* >> >> >> Not broken. >> The current text is short, but it is actually sufficient from the >> context of the ASN.1 definitions of the section. This is a >> detailed protocol section and the reader need to understand ASN.1 >> in any case to understand and implement the section. >> The information about criticality is already covered in the >> extension section. >> >> >> 16.Section 4.1.2 is called:=93*Notes on the Request Syntax=94* >> >> The first paragraph has been moved after the description >> of*issuerKeyHash *and thus is no more needed. >> >> The second paragraph has been moved after the description >> of*requestExtensions. * >> However, the sentence >> =93 *Unrecognized extensions MUST be ignored (unless they have >> the critical flag set and are not understood)*=94 >> has been deleted since it applies to the OCSP responder and >> not to the OCSP client. Thus it is no more needed. >> >> The third paragraph applies to signed requests. However, it >> should belong to a section dedicated on how clients should >> build OCPS requests, >> which is currently missing. See the next comment. >> >> This section should be deleted. >> >> >> Not broken. >> >> 17.There should be a new section called: =93*Requirements for >> OCSP clients=94. * >> >> It is important first to re-advertise that the request may be >> about several certificates. >> Thus it is important to describe the process for building a >> request, which is currently missing. >> >> *An OCSP request allows getting in the same response the >> revocation * >> >> *status of one or more certificates.In order to request the * >> >> *status of one or more certificates in a single request, OCSP = * >> >> *clients SHALL follow the following rules :* >> >> ** >> >> *For each candidate certificate, OCSP clients SHALL verify * >> >> *whether there exists a locally defined rule for the >> certificate in * >> >> *question which indicates the URI where the OCSP responder is = * >> >> *located.If this rule exists, it SHALL be followed. * >> >> ** >> >> *Otherwise, OCSP clients SHALL determine whether the candidate= * >> >> *certificate contains an AIA extension with an accessMethod >> which * >> >> *contains the id-ad-ocsp OID.If it is the case, the >> accessLocation * >> >> *contains a uniformResourceIdentifier (URI) which indicates th= e * >> >> *location of the OCSP server for that certificate. * >> >> ** >> >> *Certificates that contain the same URI MAY be grouped in a >> single * >> >> *request.* >> >> ** >> >> *Note:For each candidate certificate, when performing the path= * >> >> *validation algorithm, the OCSP client SHOULD verify that the = * >> >> *current time is within the validity period of the target * >> >> *certificate.Certificates which are outside their validity * >> >> *period SHOULD NOT be included in the request.* >> >> *The requestor MAY choose to sign the OCSP request. In that >> case, the* >> >> *signature is computed over the tbsRequest structure. If the >> request* >> >> *is signed, the requestor SHALL specify its name in the >> requestorName* >> >> *field. Also, for signed requests, the requestor MAY include* >> >> *certificates that help the OCSP responder verify the >> requestor's* >> >> *signature in the certs field of Signature.* >> >> >> Not broken. >> >> Your text may provide guidance that could be useful to some >> implementers, but is completely beyond this document and further, >> not generally applicable or true. >> As an example, an organisation may setup an in house locally >> configured OCSP responder that responds to all certificates "out >> there" that is relevant to that organisation. >> Such clients would just blindly send OCSP requests to their local >> responder, disregarding any information in the cert. >> It's totally beyond this spec to have an opinion about this. >> >> >> 18.The text states on page 14: >> >> *The responder MAY include certificates in the* >> >> *certs field of BasicOCSPResponse that help the OCSP client >> verify the* >> >> *responder's signature. If no certificates are included then >> certs* >> >> *SHOULD be absent.* >> >> While this sentence is true, it is not sufficient. In order >> to allow verifying every *SingleResponse*, >> it is important to include the relevant certificates which >> are pertinent to every *SingleResponse.* >> >> Proposed full text replacement: >> >> The responder MAY include certificates in the certs field of >> >> BasicOCSPResponse that help the OCSP client verify the >> responder's >> >> signature. >> >> *For every SingleResponse where the responder is not a CA, the= * >> >> *responder SHALL include the relevant OCSP certificate in the >> certs * >> >> *field of BasicOCSPResponse in order to allow the OCSP client = * >> >> *verifying the responder was entitled to include that >> SingleResponse * >> >> *in the signed BasicOCSPResponse.* >> >> ** >> >> **If no certificates are included then certs SHOULD be absent. >> >> >> Not broken. >> >> This requirement would break backwards compatibility with RFC 2560= . >> Further this would not be needed for a locally configured responde= r. >> >> 19.Page 15. The ASN.1 syntax should be changed in order to be >> able to use the enumeration case 7 that is not used for CRLs. >> This leads to the following change: >> >> Current text: >> >> ** >> >> *revocationReason[0]EXPLICIT CRLReason OPTIONAL }* >> >> Proposed text change: >> >> Current text: >> >> ** >> >> *revocationReason [0]EXPLICIT RevocationReason OPTIONAL }* >> >> *RevocationReason ::=3D ENUMERATED {* >> >> *unspecified(0),* >> >> *keyCompromise(1),* >> >> *cACompromise(2),* >> >> *affiliationChanged(3),* >> >> *superseded(4),* >> >> *cessationOfOperation(5),* >> >> *certificateHold(6),* >> >> *notIssuedOrIrregularlyIssued (7),* >> >> *removeFromCRL(8),* >> >> *privilegeWithdrawn(9),* >> >> *aACompromise(10) }* >> >> >> Not broken. >> >> You have to convince the list about your new reason code. >> >> 20.Page 15. After the ASN.1 syntax, there is no description >> of every parameter, neither on its use >> (except a few words in section*4.2.2.1 Time >> *about*thisUpdate, nextUpdate and producedAt).* >> >> ** >> >> Every parameter needs to be described and explained. >> >> ** >> >> *responderID indicates either the name or the key from a CA, >> or the * >> >> *name or the key from a OCSP Responder.* >> >> ** >> >> *producedAt indicates the time at which this response was >> signed.* >> >> ** >> >> *responses contains one or more single responses.* >> >> ** >> >> *responseExtensions is OPTIONAL.Any specific extension is >> OPTIONAL.* >> >> *The critical flag may or may not be set.* >> >> ** >> >> *certID is usually a copy of the same field which was placed >> in the * >> >> *request, but for OCSP responders which pre-produce signed >> responses * >> >> *certID may be the identifier of a target certificate that >> was not * >> >> *present in the request (see the end of section 4.2).* >> >> ** >> >> *certStatus indicates the status of the certificate: either >> good, * >> >> *revoked or unknown.* >> >> ** >> >> *thisUpdate indicates the time at which the status being >> indicated * >> >> *is known to be correct.* >> >> ** >> >> *nextUpdate indicates the time at or before which newer >> information * >> >> *will be available about the status of the certificate.If * >> >> *nextUpdate is not set, the server is indicating that newer * >> >> *revocation information is available all the time. * >> >> ** >> >> *If nextUpdate is set, it often corresponds to the {thisUpdate= , * >> >> *nextUpdate} interval in CRLs.Responses whose nextUpdate >> value is * >> >> *earlier than the local UTC time value SHOULD be considered * >> >> *unreliable.Responses whose thisUpdate time is later than the >> local * >> >> *UTC time SHOULD be considered unreliable.* >> >> ** >> >> *singleExtensions is OPTIONAL.Any specific extension is >> OPTIONAL.* >> >> *The critical flag SHOULD NOT be set for any of them.* >> >> ** >> >> *revocationTime indicates the time at which the certificate wa= s * >> >> *revoked.* >> >> ** >> >> *revocationReason is OPTIONAL. It includes all the cases that >> are * >> >> *present in CRLReason used for CRLs and an additional case 7 >> which is* >> >> *not used for CRLs.Case 7 is called >> notIssuedOrIrregularlyIssued. * >> >> ** >> >> *- "notIssued" corresponds to the case where the certificate * >> >> *serial number that was sent was erroneous and has not yet * >> >> *been used by the CA at the time of the query,* >> >> ** >> >> *- "irregularlyIssued" corresponds to the case where the * >> >> *certificate serial number that was sent really exists in a * >> >> *certificate that is correctly signed, but to its knowledge * >> >> *the CA has not issued a certificate with such a serial * >> >> *number. As an example, it may have been issued by the CA * >> >> *because the RA was compromised. * >> >> ** >> >> * When a responder responds revoked to a status request for= which it* >> >> * knows that the serial number has not been used by the CA = or has* >> >> * been irregularly used irregularly to issue a certificate,= then* >> >> * in RevokedInfo the responder MUST:* >> >> * * >> >> * - specify the revocationTime : January 1, 1970,* >> >> * - provide the revocationReason: notIssuedOrIrregul= arlyIssued (7).* >> >> * * >> >> * and in SingleResponse the responder MUST NOT include the = nextUpdate.* >> >> ** >> >> *The response MUST include a SingleResponse for each >> certificate in* >> >> *the request and SHOULD NOT include any additional >> SingleResponse* >> >> *elements.However, there is one exception: * >> >> ** >> >> *OCSP responders MAY pre-produce signed responses specifying >> the * >> >> *status of certificates at a specified time.The time at which = * >> >> *the status was known to be correct SHALL be reflected in the = * >> >> *thisUpdate field of the response. * >> >> ** >> >> *OCSP responders that pre-generate status responses MAY return= * >> >> *responses that include additional SingleResponse elements if* >> >> *necessary to improve response pre-generation performance or >> cache* >> >> *efficiency (as permitted in [RFC5019]).* >> >> Since the text above provides all the explanations at the >> level of the ASN.1 parameters, the general text >> from section*4.2.2.3 Basic Response *is no more need and >> should be deleted.** >> >> ** >> >> >> Preliminary I would say "not broken". >> If you don't replace 4.2.2.3, then what really are you missing? >> >> 21.0n page 16, there is a section >> *4.2.2.2***called*=93**Authorized Responders=94*** >> >> Section 4.2.2.2 states: >> >> *(=85)* >> >> *This certificate MUST be issued directly by the CA that >> issued the* >> >> *certificate in question.* >> >> ** >> >> *The CA SHOULD use the same issuing key to issue a delegation* >> >> *certificate as was used to sign the certificate being >> checked for* >> >> *revocation. Systems relying on OCSP responses MUST recognize = a* >> >> *delegation certificate as being issued by the CA that issued >> the* >> >> *certificate in question only if the delegation certificate >> and the* >> >> *certificate being checked for revocation was signed by the >> same key.* >> >> This section would need to reformatted to address CA >> requirements first and then OCSP responder requirements: >> >> *(=85)* >> >> *This certificate MUST be issued directly by the CA that >> issued the* >> >> *certificate in question.The CA SHOULD use the same issuing >> key to * >> >> *issue a delegation certificate as was used to sign the >> certificate * >> >> *being checked for revocation. * >> >> ** >> >> *Systems relying on OCSP responses MUST _be able to_ >> recognize a * >> >> *delegation certificate as being issued by the CA that issued >> the * >> >> *certificate in question if the delegation certificate and * >> >> *the certificate being checked _were_ signed by the same key.* >> >> >> I disagree. The CA is actually free to do anything, but cannot >> expect the client to recognise the responder as authorised unless >> the same private key is used. >> The current text places the requirement where they belong. >> >> 22.On page 17, the text states: >> >> *They MUST reject the* >> >> *response if the certificate required to validate the >> signature on the* >> >> *response fails to meet at least one of the following criteria= :* >> >> This is ambiguous. It is inappropriate to have a negative >> statement like=93*They MUST reject=94. * >> The sentence should be turned in the positive form=93*They >> SHALL accept=94* >> >> Since the ASN.1 syntax has now be described, it is possible >> to be more specific. >> >> The first occurrence of the word =93response=94 should be chan= ged >> into =93singleResponse=94, while the second occurrence >> of the word =93response=94 should be changed into =93ResponseD= ata=94 >> >> Proposed text replacement: >> >> *They SHALL accept a singleResponse if the certificate >> required to * >> >> *validate the signature placed on the ResponseData meets one >> of the * >> >> *following criteria:* >> >> >> >> No, this change is not backwards compatible. >> So state the requirements for rejection is not equivalent to >> stating requirements for acceptance. >> There may be other locally configured reasons to reject in >> addition to those listed in the standard. >> >> >> 23.On page 17, the text states: >> >> *3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsa= ge* >> >> *extension and is issued by the CA that issued the >> certificate in* >> >> *question as stated above."* >> >> In order to be crystal clear, it is proposed to change the >> wording in the following way: >> >> *3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsa= ge* >> >> *extension and was signed by the CA using the same key that >> used * >> >> *to issue the certificate in question.* >> >> >> No, issuing with another key is not prohibited, and may be >> accepted by some clients as an authorised responder. >> >> 24.On page 17, the text states: >> >> *This SHOULD be a non-critical extension. The value of the >> extension * >> >> *SHALL be NULL.* >> >> ** >> >> The ASN.1 syntax is missing. Add: >> >> ** >> >> *NoCheck ::=3D NULL* >> >> ** >> >> >> Moving this to a separate discussion. >> I'm not sure what the preferred way to describe this is. >> >> >> 25.Remainder: On page 18, the general text from >> section***4.2.2.3 Basic Response***is no more needed and >> should be deleted. See comment 20. >> >> ** >> >> >> Not broken. >> >> 26.On page 24, text should be added to the Security >> consideration section: >> >> *Different results when using OCSP and CRLs* >> >> ** >> >> *OCSP clients or verifiers must build and verify a >> certification path * >> >> *for each target certificate up to a trusted root.When an OCSP= * >> >> *Responder is using published CRLs, it must also build and >> verify a * >> >> *certification path for the CRLs it uses up to a trusted root.= * >> >> ** >> >> *However, it should be realized that the root used by an OCSP = * >> >> *Responder to verified these CRLs is not necessarily the same >> as the * >> >> *one that would be used by the OCSP client, if it were going >> to verify * >> >> *the CRLs itself.Hence the revocation status may not be >> identical * >> >> *in both cases.* >> >> ** >> >> ** >> >> >> I don't understand this one. >> >> 27.On page 24, text should be added to the Security >> consideration section: >> >> ** >> >> *Denial of service attack using a flood of queries* >> >> ** >> >> *A denial of service vulnerability is evident with respect to >> a flood * >> >> *of queries.The production of a cryptographic signature * >> >> *significantly affects response generation cycle time, thereby= * >> >> *exacerbating the situation. * >> >> ** >> >> *The flood of queries may either come from a flood attack or >> from the * >> >> *fact that there are too many certificates supported by the >> same OCSP * >> >> *responder.In the later case, the number of queries can be * >> >> *reduced by using a technique similar to the splitting of CRLs= : * >> >> ** >> >> *When a block of certificates have been issued with the same * >> >> *accessLocation in the AIA extension field of these >> certificates, * >> >> *then the accessLocation should be changed.In this way, a give= n * >> >> *OCSP server will only be responsible for a block of >> certificates.* >> >> ** >> >> >> If the security considerations section is talking about splitting >> OCSP responders in this way, then the document itself need to >> introduce the subject. >> I would suggest that it is beyond this update to do so. >> >> ** >> >> 28.On page 31, the text states. >> >> *An alternative to this module that conforms to the 2002 >> version of * >> >> *ASN.1 may be found in Section 4 of [RFC5912]. * >> >> ** >> >> RFC 5912 omits to define the nocheck extension. Thus it is >> inappropriate to refer to RFC 5912. >> >> The corrected module should be defined in this new draft. >> A corrected module is providedin *draft-pinkas-rfc2560bis-03.* >> >> >> Will move this (as stated above) to a separate discussion. >> >> 29.Different topics are not covered by the document. These >> topics are important. >> The following comments propose text to be placed in annexes. >> Three annexes are being proposed. >> >> Note: The texts are extracted from*draft-pinkas-rfc2560bis-03.= * >> >> >> Not broken. >> Each such amendment need to be thoroughly reviewed and motivated. >> >> >> 30.First annex being proposed. This annex is important, >> because key rollover is not addressed in the draft. >> >> *KEY ROLLOVER* >> >> ** >> >> *1. CA that directly supports an OCSP service* >> >> ** >> >> *When a CA that directly supports an OCSP service performs a >> key * >> >> *rollover:* >> >> ** >> >> *- for certificates issued under the old key, the CA SHALL >> continue * >> >> *to sign the revocation status of OCSP responses with that >> old key * >> >> *at least until all these certificates are expired, and* >> >> ** >> >> *- for certificates issued under the new key, the CA SHALL >> change the * >> >> *accessLocation in the AIA extension field of these >> certificates * >> >> *and sign the revocation status of OCSP responses with that >> new key * >> >> *at least until all these certificates are expired.* >> >> ** >> >> *Note: The change in accessLocation is necessary when the CA >> rekeys * >> >> *to meet the following constraints imposed by this standard: * >> >> ** >> >> *1) a BasicOCSPResponse can only be signed using a single * >> >> *private key; * >> >> ** >> >> *2) the response must be signed using the same CA key that * >> >> *was used to sign the certificate in question; and* >> >> ** >> >> *3) the OCSP response needs to cover all the certificates * >> >> *queried in the OCSP request.* >> >> *2. CA that uses OCSP responders* >> >> *When a CA that uses OCSP Responders performs a key rollover, >> then * >> >> *it MUST either designate a new OCSP Responder or keep the >> current * >> >> *OCSP Responder(s).* >> >> ** >> >> *If the CA designates a new OCSP Responder, then it SHALL >> change the * >> >> *accessLocation in the AIA extension field for the newly issue= d * >> >> *certificates and issue an OCSP certificate to the new OCSP >> Responder * >> >> *using its new key.* >> >> ** >> >> *If the CA keeps the same OCSP Responder(s), then it SHALL >> continue * >> >> *to use the same accessLocation(s) in the AIA extension field >> for the * >> >> *newly issued certificates and issue an OCSP certificate to th= e * >> >> *appropriate OCSP Responder(s) using its new key.* >> >> ** >> >> *Note: The CA may need to continue issuing certificates to >> the OCSP * >> >> *Responder(s) using the old CA key until all the certificates >> issued * >> >> *under the CA' old key for which the OCSP Responder(s) are * >> >> *authoritative have expired.* >> >> ** >> >> *3. OCSP Responder key rollover* >> >> ** >> >> *When an OCSP Responder performs a key rollover >> (asynchronously from * >> >> *a CA key rollover), then each CA which has designated an OCSP= * >> >> *Responder SHALL issue a new certificate for that OCSP >> Responder and * >> >> *for each of its issuing keys which meets the following >> property: * >> >> ** >> >> *- the issuing key has been used to sign at least one >> certificate * >> >> *which contains an AIA extension designating that OCSP >> Responder * >> >> *and that certificate is not yet expired.* >> >> ** >> >> *An OCSP Responder key rollover does not affect the values of >> the * >> >> *URIs that are placed in the accessLocation field from the >> target * >> >> *certificates.One or more OCSP Responder MAY respond to an OCS= P * >> >> *request addressed at a given URI picked from the >> accessLocation * >> >> *field from a target certificate.Each OCSP Responder MAY use a= * >> >> *different signing key, as long as it got an OCSP certificate = * >> >> *appropriate for that signing key and for the target >> certificate. * >> >> 31.Second annex being proposed. This annex is important >> because it describes the validation of an OCSP response in >> the past >> which is of a particular importance when validating >> electronic signatures. >> >> *Response processing by an OCSP client* >> >> ** >> >> *OCSP responses can be verified at the current time by an >> OCSP client * >> >> *when receiving a response, whereas old responses can be >> verified at * >> >> *a time in the past by a verifier.The algorithm below addresse= s * >> >> *both cases.* >> >> ** >> >> *Prior to processing a basic response, OCSP clients MUST >> determine * >> >> *the checking time, which may be either the current time or a >> time * >> >> *in the past.* >> >> ** >> >> *OCSP clients or verifiers SHALL check if the response contain= s * >> >> *responseExtensions. If such an extension is found and is >> recognized, * >> >> *it MUST be processed.If such a critical extension is found an= d * >> >> *is not recognized, the whole OCSP response MUST be >> considered as * >> >> *invalid.* >> >> ** >> >> *If the checking time is the current time, and if a nonce >> extension * >> >> *has been used in the request and is recognized (see section >> 4.5.1), * >> >> *OCSP clients MUST check whether the same nonce is present in >> the * >> >> *response.If the nonce is not present or is different, then th= e * >> >> *OCSP response MUST be discarded.* >> >> ** >> >> *Only the single response(s) which are/is of interest SHALL be= * >> >> *checked.* >> >> ** >> >> *STEP 1* >> >> ** >> >> *OCSP clients or verifiers SHALL verify that the certificate * >> >> *identified in a single response is of interest.Otherwise, >> proceed * >> >> *to step 3.* >> >> ** >> >> *If the certificate status included in a single certificate >> response * >> >> *is "unknown", then the revocation status of that certificate >> is * >> >> *"unknown", and proceed to step 3.* >> >> ** >> >> *If the certificate status from the single certificate >> response is * >> >> *either "good" or "revoked", OCSP clients or verifiers SHALL >> check * >> >> *that the checking time is within the validity period of the >> target * >> >> *certificate.If it is not the case, then the revocation >> status of * >> >> *that certificate is "unknown" and proceed to step 3.* >> >> ** >> >> *If the checking time is the current time, and if a nonce has >> been * >> >> *used in the request, then proceed to step 2.* >> >> ** >> >> *If the checking time is the current time, and if no nonce >> has been * >> >> *used in the request, OCSP clients MUST check that the >> producedAt* >> >> *field is within a time window that is "close enough" to the >> current * >> >> *time. * >> >> ** >> >> *Note: the notion of "close enough" is a local matter.It can >> be set * >> >> *to a few minutes to allow for small UTC time differences * >> >> *between the client and the server or to a few hours in case * >> >> *the server is producing pre-computed responses.* >> >> ** >> >> *If the checking time is a time in the past, verifiers MUST >> check * >> >> *that the producedAt field is in accordance with the >> verification * >> >> *rules (e.g. close and/or after the date of a time-stamp token= ).* >> >> ** >> >> *In addition, if the nextUpdate field is present, OCSP >> clients MUST * >> >> *check that the time which is indicated is greater than the >> checking * >> >> *time, otherwise the single response MUST be discarded.* >> >> ** >> >> *If checks are successful, then OCSP clients MUST process the = * >> >> *singleExtensions field, if it is present. * >> >> ** >> >> *If the criticality flag is set and the extension is not >> understood, * >> >> *then the status of the certificate shall be "unknown" and >> proceed to * >> >> *step 3.Otherwise, proceed to step 2. * >> >> ** >> >> *If the extension is understood, then the extension MUST be * >> >> *processed.According to its content proceed either to step 2 >> or to * >> >> *step 3. * >> >> ** >> >> *STEP 2* >> >> ** >> >> *OCSP clients or verifiers MUST build and verify a >> certification path * >> >> *for that certificate up to a trusted root, so that they have >> the * >> >> *knowledge of the CA public key value that was used to sign th= e * >> >> *target certificate.The revocation status of each certificate >> of * >> >> *that certification path (except the target certificate) >> SHALL be * >> >> *checked.* >> >> ** >> >> *If no path can be built or if one of the certificates of the >> path is * >> >> *revoked, then the revocation status of that certificate is >> "unknown", * >> >> *and proceed to step 3. * >> >> ** >> >> *If the certification path (except the target certificate) is >> valid, * >> >> *then two cases need to be considered:* >> >> ** >> >> *a) If the responderID matches with the name or the key from >> the CA * >> >> *which has issued the target certificate, then check whether >> the * >> >> *OCSP response is signed by the same key that was used to sign= * >> >> *the target certificate.* >> >> ** >> >> *If it is the case, then the revocation status of that * >> >> *certificate as indicated in the certStatus field is * >> >> *accepted and proceed to step 3.* >> >> ** >> >> *If it is not the case, then the revocation status of that * >> >> *certificate is "unknown" and proceed to step 3.* >> >> ** >> >> *b) If the responderID does not match with the name or the >> key from * >> >> *the CA which has issued the target certificate, then it >> indicates * >> >> *the name or the key from an OCSP Responder.Check whether ther= e * >> >> *exists a local rule which applies to this target certificate >> to * >> >> *verify that the signature of the BasicOCSPResponse is valid >> for * >> >> *that single response.If this rule exists, it SHALL be >> followed. * >> >> ** >> >> *Otherwise check whether there is an OCSP certificate (i.e. >> which * >> >> *has both the ocspSigning OID in the extended key usage >> extension * >> >> *and the digitalSignature bit in the key usage extension) >> signed * >> >> *by the same key that was used to sign the target certificate.= * >> >> *This certificate MUST be present in the certs field from the = * >> >> *BasicOCSPResponse. * >> >> ** >> >> *If such certificate is not found or is invalid, then the * >> >> *revocation status of that certificate is "unknown" and * >> >> *proceed to step 3.* >> >> ** >> >> *If such certificate exists and if the checking time is * >> >> *within the validity period of this certificate, then it MUST = * >> >> *be verified whether the OCSP response can be verified using * >> >> *the public key that is present in the OCSP Certificate. * >> >> ** >> >> *If it is not the case, then the revocation status of that * >> >> *certificate is "unknown" and proceed to step 3.* >> >> ** >> >> *If it is the case, then it MUST be verified that the OCSP * >> >> *Certificate has not been revoked.* >> >> ** >> >> *If one of these conditions is met, then the status for the >> target * >> >> *certificate as indicated in the certStatus field is accepted,= * >> >> *otherwise the revocation status is "unknown".* >> >> ** >> >> *STEP 3* >> >> ** >> >> *If there exists another single certificate status response >> for a * >> >> *target certificate that is of interest, then proceed to step >> 1. * >> >> *Otherwise the basic response is now processed.* >> >> 32.Third annex being proposed. This annex is important >> because it provides guidance on how to build an OCSP >> responder in the three cases. >> Many text portions are similar, but three full texts are >> provided in order to provide a better clarity for each of the >> three cases. >> >> *1. Request processing by OCSP servers* >> >> ** >> >> *The behavior of an OCSP server will be different whether the >> OCSP * >> >> *server is a CA acting as an OCSP responder, is an OCSP >> Responder * >> >> *which received a delegation from one or more CAs, or is a >> locally * >> >> *trusted Responder.* >> >> ** >> >> *1.1. Processing by a CA acting as an OCSP responder* >> >> ** >> >> *The OCSP responder SHALL maintain a list of entries. Each >> entry * >> >> *SHALL contain:* >> >> ** >> >> *- the URI associated to the OCSP responder, from which the >> OCSP * >> >> *requests are received, * >> >> ** >> >> *- the DN from a CA,* >> >> ** >> >> *- an issuing public key from a CA,* >> >> ** >> >> *- the method(s) used to know for which subset of certificates= * >> >> *issued by the CA it is responsible for, * >> >> ** >> >> *- the method(s) used to obtain the revocation status of that = * >> >> *subset of certificates issued under that CA issuing public >> key, * >> >> *and* >> >> ** >> >> *- the method used to gain access and sign with the private ke= y * >> >> *corresponding to the issuing public key.* >> >> ** >> >> *For a given URI value, the OCSP responder SHALL only use one >> CA * >> >> *key pair value. * >> >> ** >> >> *When it receives an OCSP request on that URI, the OCSP >> responder * >> >> *SHALL handle exceptions according to section 2.3. * >> >> ** >> >> *If the OCSP request contains the name of a requestor, the OCS= P * >> >> *responder SHALL verify whether there exists a locally >> defined rule * >> >> *which regulates access control.If this rule exists, it SHALL >> be * >> >> *followed.* >> >> ** >> >> *Then, for each target certificate, the OCSP responder SHALL >> verify * >> >> *whether both the hash of the issuer's DN and the hash of the >> issuer * >> >> *public key which are present in the request are eligible to a= * >> >> *locally defined rule which indicates that the OCSP responder >> is * >> >> *responsible to provide the revocation status of that target * >> >> *certificate.If this rule exists, it SHALL be followed.* >> >> ** >> >> *Otherwise, the OCSP responder SHALL determine whether it is * >> >> *responsible to provide the revocation status of that target * >> >> *certificate according to the following rule.* >> >> ** >> >> *For each target certificate, the OCSP responder SHALL verify >> whether * >> >> *both the hash of the issuer's DN and the hash of the issuer >> public * >> >> *key which are present in the request match respectively with >> the DN * >> >> *and the hash of the public key of contained in an entry from >> the * >> >> *list of entries maintained by this OCSP responder. * >> >> ** >> >> *When there is no match, then the OCSP responder SHALL >> indicate the * >> >> *"unknown" status and proceed with the next target >> certificate from * >> >> *the OCSP request.* >> >> ** >> >> *When there is a match, then the OCSP responder SHALL use the >> serial * >> >> *number of the target certificate that is present in the >> request and * >> >> *determine the revocation status of that certificate >> according to * >> >> *the method(s) defined in the entry. * >> >> ** >> >> *When the revocation status is provided by the server using a >> real * >> >> *time access to a database of revocation statuses of issued * >> >> *certificates, then the thisUpdate field SHALL be present in t= he* >> >> *SingleResponse response whereas the nextUpdate field SHALL be= * >> >> *missing. * >> >> ** >> >> *Otherwise, both the thisUpdate and the nextUpdate fields >> SHALL be * >> >> *present in the SingleResponse. * >> >> ** >> >> *The time at which this response will be signed MUST be >> indicated in * >> >> *the producedAt field from the SingleResponse.* >> >> ** >> >> *If a singleRequestExtensions is present in the request it >> MUST be * >> >> *processed.* >> >> ** >> >> *If there is another target certificate present in the >> request, it * >> >> *SHALL be processed in the same way.* >> >> ** >> >> *If a requestExtensions is present in the request it MUST be * >> >> *processed.* >> >> ** >> >> *The OCSP response MUST be signed using the CA issuing >> private key.* >> >> ** >> >> ** >> >> *1.2. Processing by an OCSP Responder* >> >> ** >> >> *For each CA from which the OCSP Responder has received a >> delegation, * >> >> *the OCSP Responder SHALL maintain a list of entries. * >> >> ** >> >> *Each entry SHALL contain:* >> >> ** >> >> *- the URI associated to this OCSP Responder, from which the >> OCSP * >> >> *requests are received, * >> >> ** >> >> *- the DN from a CA,* >> >> ** >> >> *- an issuing public key from a CA,* >> >> ** >> >> *- the method(s) used to know for which subset of certificates= * >> >> *issued by the CA it is responsible for, * >> >> ** >> >> *- the method(s) used to obtain the revocation status of that = * >> >> *subset of certificates issued under that CA issuing public ke= y,* >> >> ** >> >> *- an OCSP certificate, * >> >> ** >> >> *- the OCSP public key contained in that OCSP certificate, and= * >> >> ** >> >> *- the method used to gain access and sign with the OCSP >> private * >> >> *key corresponding to that OCSP certificate.* >> >> ** >> >> *For a given URI value, the OCSP Responder SHALL only use one >> OCSP * >> >> *key pair value.Therefore there cannot be two entries with the= * >> >> *same URI value and a different OCSP public key value.* >> >> ** >> >> *NOTE: a BasicOCSPResponse can only be signed using a single >> private * >> >> *key. * >> >> ** >> >> *The OCSP certificate SHALL be signed by the CA issuing >> private key * >> >> *which corresponds to the issuing CA public key that is in thi= s * >> >> *entry.* >> >> ** >> >> *When it receives an OCSP request, the OCSP responder SHALL >> handle * >> >> *exceptions according to section 2.3. * >> >> ** >> >> *If the OCSP request contains the name of a requestor, the OCS= P * >> >> *responder SHALL verify whether there exists a locally >> defined rule * >> >> *which regulates access control.If this rule exists, it SHALL >> be * >> >> *followed.* >> >> ** >> >> *For each target certificate, the OCSP Responder SHALL verify = * >> >> *whether both the hash of the issuer's DN and the hash of the >> issuer * >> >> *public key which are present in the OCSP request match with >> those * >> >> *from an entry.* >> >> ** >> >> *When there is no match, then the OCSP Responder SHALL >> indicate the * >> >> *"unknown" status and proceed with the next target >> certificate from * >> >> *the OCSP request.* >> >> ** >> >> *When there is a match, the OCSP Responder SHALL use the seria= l * >> >> *number of the target certificate this is present in the OCSP = * >> >> *request to determine the revocation status of that certificat= e * >> >> *according to the method(s) indicated in the entry. * >> >> ** >> >> *When the revocation status is provided by the server using a >> real * >> >> *time access to a database of revocation statuses of issued * >> >> *certificates, then the thisUpdate field SHALL be present in t= he* >> >> *SingleResponse response whereas the nextUpdate field SHALL be= * >> >> *missing. * >> >> ** >> >> *Otherwise, both the thisUpdate and the nextUpdate fields >> SHALL be * >> >> *present in the SingleResponse. * >> >> ** >> >> *The time at which this response will be signed MUST be >> indicated in * >> >> *the producedAt field from the SingleResponse.* >> >> ** >> >> *If a singleRequestExtensions is present in the request it >> MUST be * >> >> *processed.* >> >> ** >> >> *If there is another target certificate present in the >> request, it * >> >> *SHALL be processed in the same way.* >> >> ** >> >> *If a requestExtensions is present in the request it SHALL be = * >> >> *processed.* >> >> ** >> >> *The OCSP response MUST be signed using the OCSP private key.* >> >> ** >> >> *Unless there is a local rule which states differently, for >> every * >> >> *target certificate which matches both with the hash of a CA >> DN and an * >> >> *issuing public key from an entry, the OCSP certificate of >> that entry * >> >> *SHALL be placed in the certs field.* >> >> ** >> >> *It may happen, that none of the target certificates from the >> OCSP* >> >> *request matches both with the hash of a CA DN and an issuing >> public * >> >> *key from an entry.In that case and unless a local rule states= * >> >> *differently, the certs field from the BasicOCSPResponse >> SHOULD be * >> >> *kept empty (to limit the disclose of the names of the CAs >> from which * >> >> *the OCSP Responder received a delegation from).* >> >> ** >> >> *1.3. Processing by a locally trusted Responder* >> >> ** >> >> *For each CA for which the locally trusted Responder is * >> >> *authoritative, the OCSP Responder SHALL maintain a list of >> entries. * >> >> ** >> >> *Each entry SHALL contain:* >> >> ** >> >> *- the URI associated to this OCSP Responder, from which the >> OCSP * >> >> *requests are received, * >> >> ** >> >> *- the DN from a CA,* >> >> ** >> >> *- an issuing public key from a CA,* >> >> ** >> >> *- the method(s) used to know for which subset of certificates= * >> >> *issued by the CA it is responsible for, * >> >> ** >> >> *- the method(s) used to obtain the revocation status of that = * >> >> *subset of certificates issued under that CA issuing public ke= y,* >> >> ** >> >> *- the method used to gain access to the private key in order >> to * >> >> *sign the OCSP response. * >> >> ** >> >> *For a given URI value, the OCSP Responder SHALL only use one >> private * >> >> *key.Therefore there cannot be two entries with the same URI >> value * >> >> *and a different method to gain access to the appropriate >> private key.* >> >> ** >> >> *NOTE: a BasicOCSPResponse can only be signed using a single >> private * >> >> *key. * >> >> ** >> >> *When it receives an OCSP request, the OCSP responder SHALL >> handle * >> >> *exceptions according to section 2.3. * >> >> ** >> >> *If the OCSP request contains the name of a requestor, the OCS= P * >> >> *responder SHALL verify whether there exists a locally >> defined rule * >> >> *which regulates access control.If this rule exists, it SHALL >> be * >> >> *followed.* >> >> ** >> >> *For each target certificate, the OCSP Responder SHALL verify = * >> >> *whether both the hash of the issuer's DN and the hash of the >> issuer * >> >> *public key which are present in the OCSP request match with >> those * >> >> *from an entry.* >> >> ** >> >> *When there is no match, then the OCSP Responder SHALL >> indicate the * >> >> *"unknown" status and proceed with the next target >> certificate from * >> >> *the OCSP request.* >> >> ** >> >> *When there is a match, the OCSP Responder SHALL use the seria= l * >> >> *number of the target certificate this is present in the OCSP = * >> >> *request to determine the revocation status of that certificat= e * >> >> *according to the method(s) indicated in the entry. * >> >> ** >> >> *When the revocation status is provided by the server using a >> real * >> >> *time access to a database of revocation statuses of issued * >> >> *certificates, then the thisUpdate field SHALL be present in t= he* >> >> *SingleResponse response whereas the nextUpdate field SHALL be= * >> >> *missing. * >> >> ** >> >> *Otherwise, both the thisUpdate and the nextUpdate fields >> SHALL be * >> >> *present in the SingleResponse. * >> >> ** >> >> *The time at which this response will be signed MUST be >> indicated in * >> >> *the producedAt field from the SingleResponse.* >> >> ** >> >> *If a singleRequestExtensions is present in the request it >> MUST be * >> >> *processed.* >> >> ** >> >> *If there is another target certificate present in the >> request, it * >> >> *SHALL be processed in the same way.* >> >> ** >> >> *If a requestExtensions is present in the request it SHALL be = * >> >> *processed.* >> >> ** >> >> *The OCSP response MUST be signed using the OCSP private key.* >> >> ** >> >> *The certs field may contain no, one or several OCSP >> certificates * >> >> *according to local rules followed by the locally trusted >> Responder.* >> >> >> Not broken. >> >> /Stefan >> >> End of comments >> >> >> Denis >> >> _______________________________________________ pkix mailing >> list pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix=20 >> > --------------010606060500020302040001 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Stefan,

The review of your individual draft, took me the time I had during the week for the IETF stuff;
hence, why this reply has been delayed.

The situation is rather simple, if we forget about the editorial comments,
you have accepted one minor text change and that=92s all.

So the major problems are not solved to my satisfaction.

I have maintained below the portion of the text which needs to be further discussed.
My comments are in blue.

There is a new and very important issue tha= t I discovered while reading your comments.
See the discussion about singleExtensions and of responseExtensions.

Comment 8<= /span>: You have changed the meaning of the revoked state in a way that is not what I requested.

The origina= l text was:

=A0=A0 The "revoked" st= ate indicates that the certificate has been revoked<= span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB"><= /span>

=A0=A0 (either permanan= tly or temporarily (on hold)).<= /span>

The new tex= t is:

=A0=A0 The =
"revoked" state indicates that the certificate has been revoked
=A0=A0 eith=
er permanently or temporarily on hold (i.e. the revocation reason<=
/b>
=A0=A0 is c=
ertificateHold).

By doing th= is, you do not allow any other case in the future to have a temporary revocation: =93temporarily on hold=94 is not the same as =93temporarily revoked=94.<= /span>

I propose t= he following rewording:

=A0=A0 The "revoked" st= ate indicates that the certificate has been revoked = <= /span>

=A0=A0 either permanently or temporarily (e=
.g. placed on hold).

I substitut= ed "temporarily on hold" with "temporarily. The rest unchanged since the only existing reason code for temporary revocation is certificateHold.

As you say, the only CURRENT existing reaso= n code for temporary revocation is certificateHold. We must not PREVENT other reasons in the future to mean =93temporary revocation=94, hence why the change is needed.

The way the text from draft 13 is now written seems to allow using either =93unknown=94 or <= b style=3D"mso-bidi-font-weight: normal">=93revoked=94 for non-iss= ued certificates.
If this is the intent, then the good news is that this does not come anymore into conflict with the French rules which apply
for the Administration since OCSP responders from CAs used by the French Ministries having a direct access to the database of issued certificates
will be able to use
=93unknown=94, rather = than =93revoked=94 and the reason code <= span style=3D"font-size:10.0pt;mso-ansi-language:EN-GB" lang=3D"EN-GB">=93onhold=94.<= /span>

However, th= e current text is still mandating the use of Extended Revoked Definition, but the rational for its need it is very poor.
As I have said on the PKIX list, the fact that the revocation date is January 1rst, 1970 is fully sufficient to know that we are in that very special case,
and you have not provided a rational to say the contrary.

I have. And I have pointed you to the minutes of the last PKIC meeting.

The consensus of the WG is to have the extension for just those reasons.

As implementer, I don't like heuristics. A dat= e of Jan 1st 1970 may indicate this behaviour,
but may just be a misconfiguration. It is not an explicit statement.

So we could get rid of it, =85 but the text from section 4.4.8 states:

=A0=A0 This=
 extension MAY be present in other responses to signal that the
=A0=A0 resp=
onder implements the extended revoked definition in section 2.2.

I have difficulties to understand what is really meant there (=93other responses=94 ?), since the text states:<= /span>

=A0=A0 This=
 extension indicates that the responder supports the extended<=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB"><=
/pre>
        
=A0=A0 defi=
nition of the "revoked" status to also include non-issued
        
=A0=A0 cert=
ificates according to section 2.2.

Since both =93unknown=94 and revoked=94 can be used, it would be desirab= le to be able to include the same extension in both cases,
but in that case that extension should be renamed.=

This extension can be included in all response= s to signal that a responder implements the expanded definition of revoked.<= /span>

Doing so ma= kes this fact auditable without having to ask for a non-issued cert.

I would propose to rename it: "non-issued certificate=94 which me= ans that the associated CA has no record of ever having issued a certificate
with the certificate serial number in the request (I still consider it as unnecessary in the case of =93revoked=94, but = it would be very useful in the case of =93unknown=94).
Of course, the text from section 4.4.8 would need to be revised.

I propose t= he following:

=A0
4.4.8=A0 Non-issued certificate extension
=A0=A0 This=
 extension MUST be included in the OCSP response when the OCSP 
=A0=A0=A0re=
sponder knows that the CA identified in the request has no record =
=A0=A0=A0of=
 ever having issued a certificate with the certificate serial =
=
=A0=A0=A0nu=
mber indicated in the request.
=A0=A0 Clie=
nts do not have to parse this extension in order to determine =
=
=A0=A0=A0th=
e status of certificates in responses.
=A0=A0 This=
 extension is identified by the object identifier id-pkix-ocsp-
=A0=A0 non-=
issued-cert.
=A0=A0=A0=A0 id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}
=A0=A0 The =
value of the extension SHALL be NULL. This extension MUST NOT be
=A0=A0 mark=
ed critical.

Then the te= xt on page 8 would need to be rearranged.

Your extens= ion =A0variant is a significant change to what has been agreed.

Your extens= ion would need to be a single response extension, and can't be used to audit the behaviour of the OCSP responder
unless you send a request for a non-issued cert.

Hummm !!! We have a very important point there. Thanks to your comment, I now realize that the proposed extension
applies to the whole response. However, this is not possible and I will now explain why. An OCSP responder may receive
a delegation from several CAs. With some of them, it can use a direct access to the database of certificates,
while for some others, it will use CRLs. So the meaning of =93revoked=94 will depend of the CA.
=

This means that the indication cannot be global to the OCSP response. If we use an extension, it can only apply
to an individual response and thus MUST in singleExtensions instead of responseExtensions.

Since it is singleExtension, it can used to =93audit the behaviour of the OCSP responder=94 and I do no= t grasp your rational
when you say =93unless you send a request for a non-issued cert=94. There is no need for sending anything.<= /b>

We want to avoid sending such fake requests fo= r audit purposes as it may interfere with systems at the responder trying to detect existence of rouge certificates.<= /span>

There is no need to sending fake requests.<= /b>

This is a type of change that I can't make unless you get support from a majority of the WG for the change of direction you propose.=

The important point is that the text states:=

=93The "revoked" state (=85) MAY also be returned if the associated CA has no record of ever having issued a certificate
with the certificate serial number in the request, using any current or previous issuing key (referred to as a
"non-issued" certificate in this document).=94

The test does not state =93MUST also be returned=94. Thi= s means that it is also possible to reply =93unknown=94 if th= e associated CA
has no record of ever having issued a certificate with the certificate serial number in the request. However, this is not
straightforward when reading the text and thus the text should be made more explicit.

Now, we get to the main point. The reason for adding an extension is NOT to say that an extended meaning of revoked
is being used, but that the INDIVIDUAL response is given using a direct access to the records of the certificates issued by the CA.

The current text is:

=A0=A0 This=
 state MAY also be returned if the
=A0=A0 asso=
ciated CA has no record of ever having issued a certificate with
=A0=A0 the =
certificate serial number in the request, using any current or=
=
=A0=A0 prev=
ious issuing key (referred to as a "non-issued" certificate in=
=
=A0=A0 this=
 document).
=A0=A0 The =
"unknown" state indicates that the responder doesn't know about
=A0=A0 the =
certificate being requested.
=A0=A0 NOTE=
: The "revoked" state for known non-issued certificate serial<=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB"><=
/pre>
        
=A0=A0=A0=A0=A0=A0=
=A0=A0 numbers is allowed in order to reduce the risk of relying
=A0=A0=A0=A0=A0=A0=
=A0=A0 parties using CRLs as a fall back mechanism, which would be=
=A0=A0=A0=A0=A0=A0=
=A0=A0 considerably higher if an "unknown" response was returned.<=
/span>
=A0=A0 When=
 a responder responds revoked to a status request for a non-
        
=A0=A0 issu=
ed certificate, the responder MUST include the extended revoked
=A0=A0 defi=
nition response extension (section 4.4.8) in the response,
        
=A0=A0 indi=
cating that the OCSP responder supports the extended definition
=A0=A0 of r=
evoked state to also cover non-issued certificates. In addition,
=A0=A0 the =
SingleResponse related to this non-issued certificate;
=A0=A0=A0 -=
 MUST provide the revocation reason certificateHold (6),
=A0=A0=A0 -=
 MUST specify the revocationTime January 1, 1970, and;
=A0=A0=A0 -=
 MUST NOT include a CRL References extension (section 4.4.2) or any
=A0=A0=A0=A0=A0 CRL Entry Extensions (section 4.4.5). 

Proposed te= xt for a replacement:

=A0=A0 The =
"unknown" state indicates that the responder doesn't know about
=A0=A0 the =
certificate being requested.
=
=A0
=A0=A0 If t=
he OCSP responder knows that CA identified in the request has =
=
=A0=A0=A0no=
 record of ever having issued a certificate with the certificate <=
/b>
=A0=A0=A0se=
rial number in the request, using any current or previous issuing =
=A0=A0=A0ke=
y (referred to as a "non-issued" certificate in this document), 
=A0=A0=A0th=
e OCSP responder SHALL respond either =93revoked =93 or =93unknown=94.

This is unfortunately very common in your rewording efforts. When trying to fix one thing, you create new even bigger problems.

An infrastructure that provides reproduced responses will respond "unauthorized". This text may be interpreted to interfere with such operations.

I fear I don=92t understand your argument ab= out =93unauthorized=94, but before replying see below my next comment.

Further, an= d worse. This is not backwards compatible. Current OCSP responders may respond "good" even if they have access to CA records.=A0

You say: =93Current OCSP responders may resp= ond "good" even if they have access to CA records=94. Originall= y RFC 2560 allowed
returning =93good=94 for OCSP responder using CRLs. Since R= FC 2560 provided no way to indicate that a direct access to the database
was being used or not, it was not possible to do better.

Now, if an OCSP responder has a direct acces= s and indicates in the response that it has such an access, do you really believe
that it will return good ? I don=92t.

If an OCSP responder wants to return =93goo= d=94, it can still do it, but in that case it will not signal that it is using a direct access
and this is perfectly backwards compatible. So I do not =93buy=94 your argumentation.

Now, may be you understand better why I propose to rename the extension =934.4.8 Non-issued certificate extension=94 and
also to change its semantics.

=A0

=A0=A0 Note=
: The "revoked" state for known non-issued certificate serial =
=
=A0=A0=A0nu=
mbers is allowed in order to reduce the risk of relying parties 
=A0=A0=A0using CRLs as a fall back mechanism=
, which would be possible when 
=A0=A0=A0th=
e "unknown" response is returned.
=A0=A0 When=
 a responder responds revoked or unknown to a status request <=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB"><=
/pre>
        
=A0=A0=A0fo=
r a non-issued certificate, the responder MUST include the 
        
=A0=A0=A0no=
n-issued certificate extension (see section 4.4.8) in the 
        
=A0=A0=A0re=
sponse. 
=A0=A0=A0Wh=
en a responder responds revoked to a status request for a non-=
=
=A0=A0 issu=
ed certificate, in addition, the responder:
=A0=A0=A0 -=
 MUST provide the revocation reason certificateHold (6),
=A0=A0=A0 -=
 MUST specify the revocationTime January 1, 1970, and;
=A0=A0=A0 -=
 MUST NOT include a CRL References extension (section 4.4.2) or any
=A0=A0=A0=A0=A0 CRL Entry Extensions (section 4.4.5).

Finally, th= e last bullet on page 4 should be reworded:

Current tex= t:

=A0=A0=A0=A0=A0 o Section 4.4.8 specifies a new extension that indicates that the
=A0=A0=A0=A0=A0=A0=
=A0=A0 responder supports the extended use of the "revoked" respon=
se=
=A0=A0=A0=A0=A0=A0=
=A0=A0 for non-issued certificates defined in section 2.2.<=
/b>

Proposed replacement text:

=A0=A0=A0=A0=A0 o=A0 Section 4.4.8 specifies=
 a new extension that indicates that 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0the OCSP responder knows that CA identified in the reques=
t =
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0has no record of ever having issued a certificate with th=
e =
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0certificate serial number present in the request, as defi=
ned 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0in section 2.2.

No. Again, this changes the scope of the extension and its audit properties.

Such change requires WG consensus.

See earlier comments.=

Comment 9:= Solved, if = the comment above may be solved.

Comment 20= :=A0 This comment is preliminary classified by you as =93not broken=94. However, since you asked: =93If you don=92t replace 4.2.2.3,
then what really are you missing ?=94, I will provide you wit= h an answer.

This is the wrong way to state the question. Providing an ASN.1 syntax as in 4.2.1 is not enough: the use of every parameter MUST be explained
using English words. So if you explain the use of every parameter after the description of the ASN.1 syntax in section 4.2.1. then section 4.2.2.3
is no more needed and thus can be deleted.
<= /p>

The answer = to your question =93what is really missing=94 is a description o= f the use of every parameter listed in the ASN.1 in section 4.2.1

There are sufficient descriptions in the subsections following the ASN.1 description. Your change proposals are not compatible with the minimalistic
approach adopted by the WG.
<= /span>

The key point is whether we want a =93good=94 document or maintain the low quality of the original document.

Comment 26= : You asked = for explanations. Let me provide you with an example when CRLs are being used by the OCSP responder in the background.
The OCSP responder needs to make sure that the CRL it uses is valid. If it is simply using published CRLs (i.e. no trusted link with the CA), it needs
to make sure that the CA which has issued the CRL has no been revoked.

No, this is a misstatement. You don't revoke CAs. You revoke CA certificates.

Right.

There might be a CA certificate that has been revoked for a reason that does not affect the OCSP responder.

=A0..but the contrary may also apply.

These are operational policies that are outsid= e the scope of the protocol.

The proposed text does not affect the protocol.

The proposed text in comment 26 is plain wrong= , or at least misleading. The OCSP responder does not have to validate the CRL up to any particular root.
It may for example have been configured to directly trust the public key used to validate the CRL.
<= /span>

This depends how it makes sure that it is reading the right CRL. It may or may not use a root CA.

In France, there is a root CA for the Administration. However, the use of that root CA is optional. Thus a Ministry may have its own root,
but may also have its key certified by the root CA of the Administration. The OCSP responder may use the root CA of the Ministry,
while a relying party may use the root CA of the Administration (or the reverse) to validate the CRL for the target certificate.
Thus the revocation status will be different if the certificate of the CA of the Ministry is revoked by the root CA of the Administration.

Which reinforces my point. How the OCSP responder is configured to trust its information source is outside the scope of the protocol.=

The OCSP protocol never claims to provide the same conclusion about revocation than another source the relying party may use.<= /span>

We both agree; however would you point me where this is said in the current draft? Since I could not find it,
I believe it is useful to highlight the point in the security considerations section.


Finally, I believe that the major point indicated earlier comes from the original "bad writing" of=A0 RFC 2560.

There is no clear distinction between what applies to BasicOCSPResponse and = what applies to Single Response.

On page 15 from draft-14, the text still states in section=A0 4.2.2.2=A0 Authorized Responder:

=A0=A0 "It is necessary however to ensure that the entity signing this information is authorized to do so".

This is vague. What is "this information " ? This text is within section "4.2.2=A0 Notes on OCSP Responses".
This does not help much.

Is it BasicOCSPResponse ? If it is , this is wrong.

It is SingleResponse, since a single response may be signed by the right key and/or the right certificate,
but not another single response.

How can a reader guess that it is SingleResponse ?

Once again the quality of the text is really bad, and that text and some other portions=A0 (3.2=A0 Signed Response Acceptance Requirements)
would need to be changed.

Denis



Denis,

My replies in line;

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Monday, February 11, 2013 3:18 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Stephen Kent <<= a moz-do-not-send=3D"true" href=3D"mailto:kent@bbn.com">kent@bb= n.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

Stef= an,

=A0

I ha= ve finally reviewed your disposition of comments. I have used draft 13.

=A0

I wi= ll not address the comments in sequence, but I will consider four categories:

=A0

Ca= tegory 1) Some = comments which seem to be solved. Yes indeed, they may be a few of them !

=A0

Ca= tegory 2) Some = comments which might possibly be solved at the WG level.

=A0

Ca= tegory 3) Some = comments that I will address at the IETF last call level, rather than the WG last call level, since I disagree
that it is =93new ways to say the same thing=94 and i= t is likely to be a waste of time for both of us to argue again at the WG level
(these comments are commented as =93not broken=94).

=A0

Ca= tegory 4) Some typos and editorials found while reading draft 13.

=A0

=A0

CA= TEGORY 1

=A0

Co= mment 4 (was editorial).

=A0

Co= mment 5.

=A0

Co= mment 6.

=A0

Co= mment 19. Solved, since = =93unknown=94 se= ems now to be also allowed for non-issued certificates (even if the OCSP responder is using a direct access to the certificate database). See comment 8.

=A0

Co= mment 13: Acceptable, since the text uses =93= MAY=94.

=A0

Co= mment 18.

=A0

Co= mment 22.

=A0

Co= mment 23.

=A0

Co= mment 28.

=A0

CA= TEGORY 1

=A0

Co= mment 8: You have changed the meaning of the revoked state in a way that is not what I requested.

=A0

The original text was:

=A0

=A0=A0 The "revoked" state indicates that the certificate has been revoked

=A0=A0 (either permanantly or temporarily (on hold)).

=A0

The = new text is:

=A0

=A0=A0 The =
"revoked" state indicates that the certificate has been revoked
=A0=A0 eith=
er permanently or temporarily on hold (i.e. the revocation reason
=A0=A0 is c=
ertificateHold).

=A0

By doing this, you do not allow any other case in the future to have a temporary revocation: =93t= emporarily on hold=94 <= br> is not the same as =93t= emporarily revoked=94.=

=A0

I propose the following rewording:

=A0

=A0=A0 The "revoked" state indicates that the certificate has been revoked

=A0=A0 eith=
er permanently or temporarily (e.g. placed on hold).

I substituted "temporarily on hold" with "temporarily. The rest unchanged since the only existing reason code for temporary revocation is certificateHold.



The = way the text from draft 13 is now written seems to allow using either =93= unknown=94 or = = =93revoked=94 fo= r non-issued certificates.
If this is the intent, then the good news is that this does not come anymore into conflict with the French rules which apply for
the Administration since OCSP responders from CAs used by the French Ministries having a direct access to the database
of issued certificates will be able to use
=93= unknown=94, rather than =93= revoked=94 and the reason code =93= onhold=94.

=A0

Howe= ver, the current text is still mandating the use of = Extended Revoked Definition, bu= t the rational for its need it is very poor.
As I have said on the PKIX list, the fact that the revocation date is January 1rst, 1970 is fully sufficient to know that we are in that
very special case, and you have not provided a rational to say the contrary.


I have. And I have pointed you to the minutes of the last PKIC meeting.
The consensus of the WG is to have the extension for just those reasons.

As implementer, I don't like heuristics. A date of Jan 1st 1970 may indicate this behaviour, but may just be a misconfiguration. It is not an explicit statement.

=A0

So w= e could get rid of it, =85 but the text from section 4.4.8 states:

=A0

=A0=A0 This=
 extension MAY be present in other responses to signal that the
=A0=A0 resp=
onder implements the extended revoked definition in section 2.2.

=A0

I ha= ve difficulties to understand what is really meant there (=93other responses=94 ?), since the text state= s:

=A0

=A0=A0 This=
 extension indicates that the responder supports the extended<=
/span>
=A0=A0 defi=
nition of the "revoked" status to also include non-issued
=A0=A0 cert=
ificates according to section 2.2.

=A0

Sinc= e both =93unknown=94 and revoked=94 can be used, it wou= ld be desirable to be able to include the same extension in both cases,
but in that case that extension should be renamed.


This extension can be included in all responses to signal that a responder implements the expanded definition of revoked.
Doing so makes this fact auditable without having to ask for a non-issued cert.


I wo= uld propose to rename it: "= non-issued certificate=94 which means that the associated CA has no record of ever having issued
a certificate with the certificate serial number in the request (I still consider it as unnecessary in the case of =93revoked=94, but it would be
very useful in the case of =93unknown=94). Of course, the text from section 4.4.8 would need to be revised.

=A0

I propose the following:

=A0

4.4.8=A0 No=
n-issued certificate extension
=A0
=A0=A0 This extension MUST be included in t=
he OCSP response when the OCSP 
=A0=A0=A0re=
sponder knows that the CA identified in the request has no record 
=A0=A0=A0of=
 ever having issued a certificate with the certificate serial =
=A0=A0=A0nu=
mber indicated in the request.
=A0
=A0=A0 Clients do not have to parse this ex=
tension in order to determine 
=A0=A0=A0th=
e status of certificates in responses.
=A0
=A0=A0 This extension is identified by the =
object identifier id-pkix-ocsp-
=A0=A0 non-=
issued-cert.
=A0
=A0=A0=A0=A0 id-pkix-ocsp-non-issued-cert O=
BJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}
=A0
=A0=A0 The value of the extension SHALL be =
NULL. This extension MUST NOT be
=A0=A0 mark=
ed critical.

=A0

Then the text on page 8 would need to be rearranged.<= /o:p>

=A0


Your extension =A0variant is a significant change to what has been agreed.
Your extension would need to be a single response extension, and can't be used to audit the behaviour of the OCSP responder unless you send a request for a non-issued cert.
We want to avoid sending such fake requests for audit purposes as it may interfere with systems at the responder trying to detect existence of rouge certificates.

This is a type of change that I can't make unless you get support from a majority of the WG for the change of direction you propose.

The current text is:

=A0

=A0=A0 This=
 state MAY also be returned if the
=A0=A0 asso=
ciated CA has no record of ever having issued a certificate with
=A0=A0 the =
certificate serial number in the request, using any current or=
=A0=A0 prev=
ious issuing key (referred to as a "non-issued" certificate in=
=A0=A0 this=
 document).
=A0
=A0=A0 The "unknown" state indicates that t=
he responder doesn't know about
=A0=A0 the =
certificate being requested.
=A0
=A0=A0 NOTE: The "revoked" state for known =
non-issued certificate serial
=A0=A0=A0=A0=A0=A0=
=A0=A0 numbers is allowed in order to reduce the risk of relying
=A0=A0=A0=A0=A0=A0=
=A0=A0 parties using CRLs as a fall back mechanism, which would be=
=A0=A0=A0=A0=A0=A0=
=A0=A0 considerably higher if an "unknown" response was returned.<=
o:p>
=A0
=A0=A0 When a responder responds revoked to=
 a status request for a non-
=A0=A0 issu=
ed certificate, the responder MUST include the extended revoked
=A0=A0 defi=
nition response extension (section 4.4.8) in the response,
=A0=A0 indi=
cating that the OCSP responder supports the extended definition
=A0=A0 of r=
evoked state to also cover non-issued certificates. In addition,
=A0=A0 the =
SingleResponse related to this non-issued certificate;<=
/b>
=A0
=A0=A0=A0 - MUST provide the revocation rea=
son certificateHold (6),
=A0
=A0=A0=A0 - MUST specify the revocationTime=
 January 1, 1970, and;
=A0
=A0=A0 =A0=
- MUST NOT include a CRL References extension (section 4.4.2) or a=
ny
=A0=A0=A0=A0=A0 CRL Entry Extensions (section 4.4.5). 

=A0

Prop= osed text for a replacement:

=A0

=A0=A0 The =
"unknown" state indicates that the responder doesn't know about
=A0=A0 the =
certificate being requested.
=A0
=A0=A0 If the OCSP responder knows that CA =
identified in the request has 
=A0=A0=A0no=
 record of ever having issued a certificate with the certificate 
=A0=A0=A0se=
rial number in the request, using any current or previous issuing 
=A0=A0=A0ke=
y (referred to as a "non-issued" certificate in this document), 
=A0=A0=A0th=
e OCSP responder SHALL respond either =93revoked =93 or =93unknown=94.

This is unfortunately very common in your rewording efforts. When trying to fix one thing, you create new even bigger problems.

An infrastructure that provides reproduced responses will respond "unauthorized". This text may be interpreted to interfere with such operations.
Further, and worse. This is not backwards compatible. Current OCSP responders may respond "good" even if they have access to CA records.=A0

=A0
=A0=A0 Note: The "revoked" state for known =
non-issued certificate serial 
=A0=A0=A0nu=
mbers is allowed in order to reduce the risk of relying parties 
=A0=A0=A0us=
ing CRLs as a fall back mechanism, which would be possible when 
=A0=A0=A0th=
e "unknown" response is returned.
=A0
=A0=A0 When a responder responds revoked or=
 unknown to a status request 
=A0=A0=A0fo=
r a non-issued certificate, the responder MUST include the 
=A0=A0=A0no=
n-issued certificate extension (see section 4.4.8) in the 
=A0=A0=A0re=
sponse. 
=A0
=A0=A0 When a responder responds revoked to=
 a status request for a non-
=A0=A0 issu=
ed certificate, in addition, the responder:
=A0
=A0=A0=A0 - MUST provide the revocation rea=
son certificateHold (6),
=A0
=A0=A0=A0 - MUST specify the revocationTime=
 January 1, 1970, and;
=A0
=A0=A0=A0 - MUST NOT include a CRL Referenc=
es extension (section 4.4.2) or any
=A0=A0=A0=A0=A0 CRL Entry Extensions (section 4.4.5).

=A0

Fina= lly, the last bullet on page 4 should be reworded:

=A0

Curr= ent text:

=A0

=A0=A0=A0=A0=A0 o Section 4.4.8 specifies a new extension that indicates that the
=A0=A0=A0=A0=A0=A0=
=A0=A0 responder supports the extended use of the "revoked" respon=
se
=A0=A0=A0=A0=A0=A0=
=A0=A0 for non-issued certificates defined in section 2.2.

=A0

Prop= osed replacement text:

=A0

=A0=A0=A0=A0=A0 o =A0Section 4.4.8 specifies=
 a new extension that indicates that 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0the OCSP responder knows that CA identified in the reques=
t 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0has no record of ever having issued a certificate with th=
e 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0certificate serial number present in the request, as defi=
ned 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0in section 2.2.

=A0


No. Again, this changes the scope of the extension and its audit properties.
Such change requires WG consensus.


Co= mment 9: Solved, if the comment above may be solved.

=A0

Co= mment 20:=A0 = This comment is preliminary classified by you as =93not broken=94. However, since you asked: =93If you don=92= t replace 4.2.2.3,
then what really are you missing ?=94, I will provide you with an answer.

=A0

This= is the wrong way to state the question. Providing an ASN.1 syntax as in 4.2.1 is not enough: the use of every parameter
MUST be explained using English words. So if you explain the use of every parameter after the description of the ASN.1 syntax
in section 4.2.1. then section 4.2.2.3 is no more needed and thus can be deleted.

=A0

The answer to your question =93what is really missing=94 = is a description of the use of every parameter listed in the ASN.1 in section 4.2.1

=A0


There are sufficient descriptions in the subsections following the ASN.1 description. Your change proposals are not compatible with the minimalistic approach adopted by the WG.


Co= mment 21.

=A0

Whil= e I can agree in general with the intent of the text, I do not understand the first sentence of the Note which speaks of =93CA key rollover=94
and is copied below:

=A0

=A0=A0 Note=
: CA key rollover is not prohibited when issuing a certificate=
=A0=A0=A0=A0=A0=A0=
=A0=A0 for an authorized responder for backwards compatibility wit=
h
=A0=A0=A0=A0=A0=A0=
=A0=A0 RFC 2560 [RFC2560]. That is, it is not prohibited to issue =
a
=A0=A0=A0=A0=A0=A0=
=A0=A0 certificate for an authorized responder using a different
=A0=A0=A0=A0=A0=A0=
=A0=A0 issuing key than the key used to issued the certificate bei=
ng
=A0=A0=A0=A0=A0=A0=
=A0=A0 checked for revocation. However, such practice is strongly<=
o:p>
=A0=A0=A0=A0=A0=A0=
=A0=A0 discouraged since clients are not required to recognize a
=A0=A0=A0=A0=A0=A0=
=A0=A0 responder with such certificate as an authorized responder.=

=A0

I wo= uld propose to delete it, since it does not add anything and thus to have:

=A0

=A0=A0 Note=
: For backwards compatibility with RFC 2560 [RFC2560], it is <=
/span>
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0not prohibited to issue a certificate for an authorized <=
o:p>
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0responder using a different issuing key than the key used=
 to 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0issued the certificate being checked for revocation. 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0However, such practice is strongly discouraged since clie=
nts 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0are not required to recognize a responder with such =
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0certificate as an authorized responder.=

I agree, your text is better. Updated.

=A0

Co= mment 24: The ASN.1 module in annex B.1 is still wrong, since it does not define NoCheck. <= /o:p>

=A0


No you are wrong. We have confirmed with several ASN.1 experts that definition of NoCheck is not necessary to define null content.
The current definition is perfectly valid ASN.1

Co= mment 26: You asked for explanations. Let me provide you with an example when CRLs are being used by the OCSP responder
in the background. The OCSP responder needs to make sure that the CRL it uses is valid. If it is simply using published CRLs
(i.e. no trusted link with the CA), it needs to make sure that the CA which has issued the CRL has no been revoked.

=A0


No, this is a misstatement. You don't revoke CAs. You revoke CA certificates. There might be a CA certificate that has been revoked for a reason that does not affect the OCSP responder.
These are operational policies that are outside the scope of the protocol.

The proposed text in comment 26 is plain wrong, or at least misleading. The OCSP responder does not have to validate the CRL up to any particular root. It may for example have been configured to directly trust the public key used to validate the CRL.


In <= st1:place w:st=3D"on">France<= /st1:country-region>, there is a root CA for the Administration. However, the use of that root CA is optional. Thus a Ministry may have its own root,
but may also have its key certified by the root CA of the Administration. The OCSP responder may use the root CA of the Ministry,
while a relying party may use the root CA of the Administration (or the reverse) to validate the CRL for the target certificate.
Thus the revocation status will be different if the certificate of the CA of the Ministry is revoked by the root CA of the Administration.
<= /p>

=A0


Which reinforces my point. How the OCSP responder is configured to trust its information source is outside the scope of the protocol.

The OCSP protocol never claims to provide the same conclusion about revocation than another source the relying party may use.

I skip category 3 as this will be dealt with in IESG last call.


CA= TEGORY 3

=A0

Co= mments 2, = 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27.

=A0

=A0

CA= TEGORY 4

=A0

Page= 4. The indentation of the bullets in section 1 is not uniform.
Bullets 1, 4, 5 and 9 have problems.

=A0

Page= 4. The fact that there is now an Annex B.2 dealing with the 2008 ASN.1 syntax is missing. This should be added.

=A0

Page 10. Change =93S= e further section 4.2.2.2=94 in= to =93S= ee further section 4.2.2.2=94



Thanks. I have fixed them all.

/Stefan


Denis
<= o:p>

=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Denis,<= /div>

Respond= ing to your comments below.

However= , one general remark to make recurring comments easier to understand.

The WG decided to adopt a minimalistic approach to updating RFC 2560. That means that=A0
  1. We don't change anything from RFC 2560 unless it is broken, or the industry clearly need clarifications in order to avoid interoperability issues.
  2. We retain the document structure of RFC 2560 as much as possible to allow easy comparison of what the changes are in comparison with RFC 2560.

One can always think up more clever ways to write things out in words. But that also comes with a risk.
The current words has been around for a long time and we know from experience which words worked to produce working implementations, and which did not.
Introdu= cing new ways to say the same thing may introduce new problems and people might disagree on what the new perfect wording should be. And this could go on forever.

So when my reply is "Not broken", then that is because the current wording does not have such problems that is merits a change.



Fr= om: Denis Pinkas <denis.pinkas@= bull.net>
Date: Sunday, January 20, 2013 5:12 PM
To: Stefan Santesson <stefan@aaa-sec.c= om>, Stephen Kent <kent@bbn.com> Cc: pkix <pkix@ietf.org>=
Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

Please find 32 comments on draft-ietf-pkix-rfc2560bis

=A0

1.= The document states:

=A0= <Cut away issue 1 regarding authorship etc, as it has been responded to separately>


Respond= ed to separately.

=A0=

=A0=

2.= The current text from section 2 states:

=A0=

2.=A0 Protocol Overv=
iew
=A0
=A0=A0 In lieu of or=
 as a supplement to checking against a periodic CRL, it=
=A0=A0 may be necess=
ary to obtain timely information=
 regarding the
=A0=A0 revocation st=
atus of a certificate (cf. RFC5280], Section 3.3).
                          
=A0=A0 Examples incl=
ude high-value funds transfer or large stock trades.
                          
=A0
=A0=A0 The Online Ce=
rtificate Status Protocol (OCSP) enables applications to
=A0=A0 determine the=
 (revocation) state of an identified certificate. OCSP<=
/pre>
                          
=A0=A0 may be used t=
o satisfy some of the operational requirements of
=A0=A0 providing more timely revocation information<=
/b> than is possible with
=A0=A0 CRLs and may =
also be used to obtain additional status information. <=
/pre>
                          
=A0
This text is misleading because re=
aders may think that OCPS necessarily provides =93timely information=94.<=
o:p>
=A0

"may" does not mean "necessarily".

Proposed text replacement:
=A0

=A0=A0 The Online Certificate Status Protocol (OCSP) is a client-server

=A0=A0 protocol which enables applications to obtain the revocation status <= /p>

=A0=A0 of one or more certificates either "good", "revoked", or "unknown".

=A0<= /p>

=A0=A0 The revocation status may be provided by the server either using a <= /b>

=A0=A0 real time access to a database of issued certificates, or using a

=A0=A0 batch access to a database of issued certificates, or using a

=A0=A0 real time access to a database of revocation statuses of issued =

=A0=A0 certificates, or using a batch access to a database of revocation

=A0=A0 statuses of issued certificates, or using CRLs, or using a

=A0=A0 combination of base CRLs and delta CRLs.

=A0<= /p>

=A0=A0 In the first case, it is possible to obtain timely revocation status

=A0=A0 information, whereas in the other cases, the freshness of the

=A0=A0 revocation status is not better than the mechanisms it is based on.

=A0
=A0

Not broken

3.= The current text from section 2 states:

=A0
=A0=A0 An OCSP clien=
t issues a status request to an OCSP responder and 
                          
=A0=A0=A0Suspends ac=
ceptance of the certificate in q=
uestion until the 
=A0=A0=A0responder p=
rovides a response.
=A0
=A0=A0 This protocol=
 specifies the data that needs to be exchanged between<=
/pre>
                          
=A0=A0 an applicatio=
n checking the status of a certificate and the server
                          
=A0=A0 providing tha=
t status.
=A0
Thus is insufficient for an overvi=
ew. More details are needed to know what the document provides,=20
in particular that the request may contain several requests for several c=
ertificates issued by different CAs.=20
The possibility of using extensions should also be advertised.=
=A0
Proposed text replacement:
=A0

=A0=A0 = When using OCSP, an OCSP client issues a certificate revocation

=A0=A0 = status request to an OCSP responder for one or more certificates <= /span>

=A0=A0 issued by the same CA or for one or more certificates issued by =

=A0=A0 different CAs and then suspends acceptance of the certificate(s)

=A0=A0 = in question until the responder provides a response.

=A0

=A0=A0 = This document specifies the data that needs to be exchanged between

=A0=A0 = an application checking the status of a certificate and the server

=A0=A0 = providing that status.=A0

=A0

=A0=A0 OCSP may also provide additional status information using <= /p>

=A0=A0 extensions.

=A0=

=A0=


Not broken

4.= Page 6. Editorial. Punctuation and a CR/LF are missing.

=A0=

The text states:<= /span>

=A0

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 3. t=
he request contains the information needed by the responder If=
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 any one of the prior conditions are not met, the OCSP responder=
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 produces an error message; otherwise, it returns a definitive
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 response.

=A0

It should state:<= /span>

=A0

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 4. t=
he request contains the information needed by the responder.
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0
=A0=A0=A0=A0=A0 If any one of the prior con=
ditions are not met, the OCSP responder
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 produces an error message; otherwise, it returns a definitive
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 response.

=A0=

=A0=


Fixed i= n draft 10.

5.= On page 7, the text states:=

=A0=

=A0=A0 All definitive response messages SHALL be digitally signed. The key

=A0=A0 used to sign the response MUST belong to one of the following:

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0
=A0=A0 -=A0=
 the CA who issued the certificate in question
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 a Trusted Responder whose public=
 key is trusted by the requester
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 a CA Designated Responder (Autho=
rized Responder) who holds a
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 specially marked certificate issued directly by the CA, indicating
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 that the responder may issue OCSP responses for that CA.<=
/span>

=A0=

The paragraph is ambiguous o= n several aspects.

=A0

Delegation is addressed in a= t least three different places, but with different terms and conditions.
If some one picks a sentence in one paragraph rather than another, it will lead to a different conclusion.
RFCs are supposed to be clear.

=A0=

On page 10, the current text states in section 2.6 OCSP Signature Authority Delegation <= /span>states:

=A0

=A0=A0 The key that signs a certificate's status information need not be the=

=A0=A0 same key that signed the certificate. A certificate's issuer

=A0=A0 explicitly delegates OCSP signing authority by issuing a certificate

=A0=A0 containing a unique value for extendedKeyUsage in the OCSP signer's

=A0=A0 certificate. This certificate MUST be issued directly to the

=A0=A0 responder by the cognizant CA.

=A0

On page 16, there is a section 4.2.2.2 called =93= Authorized Responders=94 dealing with the same topic= .

=A0

Section 4.2.2.2 states:=

=A0=

=A0=A0 The key that signs a certificate's status information need not be the=

=A0=A0 same key that signed the certificate. It is necessary however to

=A0=A0 ensure that the entity signing this information is authorized to do=

=A0=A0 so.=A0 T= herefore, a certificate's issuer MAY either sign the OCSP

=A0=A0 responses itself or it MAY explicitly designate this authority to

=A0=A0 another entity.=A0 OCSP signing delegation SHALL be designated by the

=A0=A0 inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate

=A0=A0 extension included in the OCSP response signer's certificate.=A0 T= his

=A0=A0 certificate MUST be issued directly by the CA that issued the

=A0=A0 certificate in question.

=A0<= /p>

=A0=A0 The CA SHOULD use the same issuing key to issue a delegation<= /p>

=A0=A0 certificate as was used to sign the certificate being checked for

=A0=A0 revocation. Systems relying on OCSP responses MUST recognize a

=A0=A0 delegation certificate as being issued by the CA that issued the

=A0=A0 certificate in question only if the delegation certificate and the=

=A0=A0 certificate being checked for revocation was signed by the same key.

=A0=

The last sentence above in yellow is the key sentence that is missing in the two other sections.

=A0
Most implementations only support =
the case where the OCSP Responder receives an OCSP certificate that is si=
gned by the same key=20
that was used to sign the target certificate. They do not support the cas=
e where the OCSP Responder receives an OCSP certificate=20
that is signed by a key that is different from the one that was used to s=
ign the target certificate.

=A0

It is inappropriate to have three sections dealing with the same topic with a slightly different meaning.

=A0

It is proposed the following= .

=A0

On page 7, after:=

=A0=

<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0 -=A0 a CA Designated Responder (Autho=
rized Responder) who holds a
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">=A0=A0=A0=A0=A0 specially marked certificate issued directly by the CA, indicating
<=
span style=3D"mso-ansi-language:
EN-GB" lang=3D"EN-GB">