Re: registration authorities

["Gonzalez Cadenas,Carlos Netfocus" <[e-mail]>]

Hi all,

Although clarifications have been provided in 3739 regarding the profile is not restricted to QCs, it will be very difficult to explain to the end entities that a cert containing so-called "QC" extensions is not issued as a QC.

In my opinion, as the QC extensions can include specifical properties of the certs regarding the issuance as a QC, but can contain another ones that have no relationship with the QCs (i.e. RA, retention period, usable with an SSCD, ...), maybe the name for the extension can lead to misinterpretations and confusions.

Thank you very much for your attention,

Kind regards and happy new year,

Carlos

>>> Stephen Kent <[e-mail]> 30/12/04 20:36 >>>

At 6:45 PM +0100 12/30/04, Peter Sylvester wrote:
>  > >Doesn't 3739 say:
>>  >
>>  >    The profile is however not limited to Qualified
>>  >    Certificates and further profiling may facilitate specific local
>>  >    needs.
>>
>>  yes, but what i said was that syntactically, inclusion of the
>>  extension defined for QC's will generally be interpreted as
>>  indicating a QC. In the U.S. we have a saying:
>>     "If it looks like a duck and quacks like a duck, then it's
>>probably a duck."
>>
>No, it is a video game. :-)

yes, it probably is!

>
>
>       *  Some editorial clarifications have been made to introductory
>          sections to clarify that this profile is generally applicable
>          to a broad type of certificates, even if its prime purpose is
>          to facilitate issuance of Qualified Certificates.
>
>
>>  I think this saying will apply here, whether the cert was issued
>>  under QC guidelines or not.
>
>I tend to interprete the phrases as a warning to indicate exactly the
>contrary.

I agree that the text says one can use the extension more broadly,
and I agree that, therefore, IF one feels a need to name an RA in a
cert, this is the standard way we have defined to do that, but I
would still bet that folks who see an extension named qc-Statement
will infer that its a qualified cert ...

Steve




Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena
de incurrir en responsabilidades legales. El emisor no garantiza la integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.


Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualssevol altres manipulacions que facin tercers.


Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of the
individual or entity to whom it is addressed. If you are not the intended recipient
and have received this information in error or have accessed it for any reason,
please notify us of this fact by email reply and then destroy or delete the message,
refraining from any reproduction, use, alteration, filing or communication to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUNtOfK085822; Thu, 30 Dec 2004 15:55:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUNtOO8085821; Thu, 30 Dec 2004 15:55:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from avir1.bancsabadell.com (tm01.bancsabadell.com [194.224.15.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUNtN9w085718 for <[e-mail]>; Thu, 30 Dec 2004 15:55:23 -0800 (PST) (envelope-from [e-mail])
Received: from RWEB-MTA by mail.bancsabadell.com with Novell_GroupWise; Fri, 31 Dec 2004 00:50:55 +0100
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0.5 Beta
Date: Fri, 31 Dec 2004 00:50:45 +0100
From: "Gonzalez Cadenas,Carlos Netfocus" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <Sylvester@[edelweb.fr]>, <chadwick@[salford.ac.uk]>
Subject: Re: registration authorities
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBUNtO9w085815
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

Although clarifications have been provided in 3739 regarding the profile is not restricted to QCs, it will be very difficult to explain to the end entities that a cert containing so-called "QC" extensions is not issued as a QC.

In my opinion, as the QC extensions can include specifical properties of the certs regarding the issuance as a QC, but can contain another ones that have no relationship with the QCs (i.e. RA, retention period, usable with an SSCD, ...), maybe the name for the extension can lead to misinterpretations and confusions.

Thank you very much for your attention,

Kind regards and happy new year,

Carlos

>>> Stephen Kent <[e-mail]> 30/12/04 20:36 >>>

At 6:45 PM +0100 12/30/04, Peter Sylvester wrote:
>  > >Doesn't 3739 say:
>>  >
>>  >    The profile is however not limited to Qualified
>>  >    Certificates and further profiling may facilitate specific local
>>  >    needs.
>>
>>  yes, but what i said was that syntactically, inclusion of the
>>  extension defined for QC's will generally be interpreted as
>>  indicating a QC. In the U.S. we have a saying:
>>     "If it looks like a duck and quacks like a duck, then it's
>>probably a duck."
>>
>No, it is a video game. :-)

yes, it probably is!

>
>
>       *  Some editorial clarifications have been made to introductory
>          sections to clarify that this profile is generally applicable
>          to a broad type of certificates, even if its prime purpose is
>          to facilitate issuance of Qualified Certificates.
>
>
>>  I think this saying will apply here, whether the cert was issued
>>  under QC guidelines or not.
>
>I tend to interprete the phrases as a warning to indicate exactly the
>contrary.

I agree that the text says one can use the extension more broadly,
and I agree that, therefore, IF one feels a need to name an RA in a
cert, this is the standard way we have defined to do that, but I
would still bet that folks who see an extension named qc-Statement
will infer that its a qualified cert ...

Steve




Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena
de incurrir en responsabilidades legales. El emisor no garantiza la integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.


Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualssevol altres manipulacions que facin tercers.


Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of the
individual or entity to whom it is addressed. If you are not the intended recipient
and have received this information in error or have accessed it for any reason,
please notify us of this fact by email reply and then destroy or delete the message,
refraining from any reproduction, use, alteration, filing or communication to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUNoRxg084291; Thu, 30 Dec 2004 15:50:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUNoRqw084290; Thu, 30 Dec 2004 15:50:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hotmail.com (bay21-f29.bay21.hotmail.com [65.54.233.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUNoQLd084252 for <[e-mail]>; Thu, 30 Dec 2004 15:50:26 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 30 Dec 2004 15:49:00 -0800
Message-ID: <[e-mail]>
Received: from 84.128.72.150 by by21fd.bay21.hotmail.msn.com with HTTP; Thu, 30 Dec 2004 23:48:57 GMT
X-Originating-IP: [84.128.72.150]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "Hannes Tschofenig" <[e-mail]>
To: [e-mail]
Subject: cms implementation
Date: Fri, 31 Dec 2004 00:48:57 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-OriginalArrivalTime: 30 Dec 2004 23:49:00.0581 (UTC) FILETIME=[22AD6550:01C4EECA]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hi all,

can someone point me to an open source cms implementation?

ciao
hannes




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUIOJ2T081514; Thu, 30 Dec 2004 10:24:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUIOJvK081513; Thu, 30 Dec 2004 10:24:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUIOIh0081455 for <[e-mail]>; Thu, 30 Dec 2004 10:24:19 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBUIO9jf001088; Thu, 30 Dec 2004 13:24:10 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200745bdf9f5b1b999@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 30 Dec 2004 13:23:38 -0500
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: registration authorities
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:45 PM +0100 12/30/04, Peter Sylvester wrote:
>  > >Doesn't 3739 say:
>>  >
>>  >    The profile is however not limited to Qualified
>>  >    Certificates and further profiling may facilitate specific local
>>  >    needs.
>>
>>  yes, but what i said was that syntactically, inclusion of the
>>  extension defined for QC's will generally be interpreted as
>>  indicating a QC. In the U.S. we have a saying:
>>     "If it looks like a duck and quacks like a duck, then it's 
>>probably a duck."
>>
>No, it is a video game. :-)

yes, it probably is!

>
>
>       *  Some editorial clarifications have been made to introductory
>          sections to clarify that this profile is generally applicable
>          to a broad type of certificates, even if its prime purpose is
>          to facilitate issuance of Qualified Certificates.
>
>
>>  I think this saying will apply here, whether the cert was issued
>>  under QC guidelines or not.
>
>I tend to interprete the phrases as a warning to indicate exactly the
>contrary.

I agree that the text says one can use the extension more broadly, 
and I agree that, therefore, IF one feels a need to name an RA in a 
cert, this is the standard way we have defined to do that, but I 
would still bet that folks who see an extension named qc-Statement 
will infer that its a qualified cert ...

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUHjnsp039810; Thu, 30 Dec 2004 09:45:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUHjna2039808; Thu, 30 Dec 2004 09:45:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUHjkSF039679 for <[e-mail]>; Thu, 30 Dec 2004 09:45:49 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBUHjmn16961; Thu, 30 Dec 2004 18:45:48 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 30 Dec 2004 18:45:48 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBUHjmD07935; Thu, 30 Dec 2004 18:45:48 +0100 (MET)
Date: Thu, 30 Dec 2004 18:45:48 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: registration authorities
Cc: [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >Doesn't 3739 say:
> >
> >    The profile is however not limited to Qualified
> >    Certificates and further profiling may facilitate specific local
> >    needs.
> 
> yes, but what i said was that syntactically, inclusion of the 
> extension defined for QC's will generally be interpreted as 
> indicating a QC. In the U.S. we have a saying:
>    "If it looks like a duck and quacks like a duck, then it's probably a duck."
> 
No, it is a video game. :-) 


      *  Some editorial clarifications have been made to introductory
         sections to clarify that this profile is generally applicable
         to a broad type of certificates, even if its prime purpose is
         to facilitate issuance of Qualified Certificates.


> I think this saying will apply here, whether the cert was issued 
> under QC guidelines or not.

I tend to interprete the phrases as a warning to indicate exactly the
contrary. 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUHDdS4095424; Thu, 30 Dec 2004 09:13:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUHDdYT095423; Thu, 30 Dec 2004 09:13:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUHDcpF094995 for <[e-mail]>; Thu, 30 Dec 2004 09:13:39 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBUHDMjh028380; Thu, 30 Dec 2004 12:13:24 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200743bdf9e7154d06@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 30 Dec 2004 12:13:03 -0500
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: registration authorities
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:00 PM +0100 12/30/04, Peter Sylvester wrote:
>Doesn't 3739 say:
>
>    The profile is however not limited to Qualified
>    Certificates and further profiling may facilitate specific local
>    needs.

yes, but what i said was that syntactically, inclusion of the 
extension defined for QC's will generally be interpreted as 
indicating a QC. In the U.S. we have a saying:
   "If it looks like a duck and quacks like a duck, then it's probably a duck."

I think this saying will apply here, whether the cert was issued 
under QC guidelines or not.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUH0mBo076796; Thu, 30 Dec 2004 09:00:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUH0mXb076795; Thu, 30 Dec 2004 09:00:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUH0k9A076722 for <[e-mail]>; Thu, 30 Dec 2004 09:00:47 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBUH0mn16355; Thu, 30 Dec 2004 18:00:48 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 30 Dec 2004 18:00:48 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBUH0lk07813; Thu, 30 Dec 2004 18:00:47 +0100 (MET)
Date: Thu, 30 Dec 2004 18:00:47 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: registration authorities
Cc: [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Doesn't 3739 say:

   The profile is however not limited to Qualified
   Certificates and further profiling may facilitate specific local
   needs.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUEsFqP058388; Thu, 30 Dec 2004 06:54:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUEsFVp058387; Thu, 30 Dec 2004 06:54:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUEsF2Z058359 for <[e-mail]>; Thu, 30 Dec 2004 06:54:15 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBUEs6jf022286; Thu, 30 Dec 2004 09:54:07 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p0620073ebdf9c41c1a7f@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <001401c4e35c$62e5f2f0$[e-mail]> <p06200702bde727b12e9e@[192.168.254.135]> <[e-mail]>
Date: Thu, 30 Dec 2004 09:53:57 -0500
To: David Chadwick <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: registration authorities
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:24 PM +0000 12/30/04, David Chadwick wrote:
>Steve
>
>a CA is a Certification Authority, and not necessarily a 
>Registration Authority. Conceptually and operationally they are 
>different and therefore there should always be an allowance for this.
>
>regards
>
>David
>

David,

I certainly agree with the distinction, but other than in the context 
of qualified certs, X.509 does not make explicit provision for 
inclusion of RA info, probably since it is not used in the cert 
validation process.

Peter Sylvester noted shortly after my message, a CA is certainly 
free to out an RA name in a cert, bnut I assumed he meant that one 
could include the qc extension and put the RA name in it. In that 
case the cert looks like a QC cert, syntactically, hence my comment.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUEPOai048598; Thu, 30 Dec 2004 06:25:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBUEPOmX048597; Thu, 30 Dec 2004 06:25:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-1.visp.demon.net (IDENT:[e-mail] [193.195.70.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBUEP626048428 for <[e-mail]>; Thu, 30 Dec 2004 06:25:11 -0800 (PST) (envelope-from [e-mail])
Received: from [82.32.148.41] (82-32-148-41.cable.ubr01.chap.blueyonder.co.uk [82.32.148.41]) by lon1-mail-1.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BYP69890 (AUTH [e-mail]); Thu, 30 Dec 2004 14:24:23 GMT
Message-ID: <[e-mail]>
Date: Thu, 30 Dec 2004 14:24:20 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: registration authorities
References: <001401c4e35c$62e5f2f0$[e-mail]> <p06200702bde727b12e9e@[192.168.254.135]>
In-Reply-To: <p06200702bde727b12e9e@[192.168.254.135]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve

a CA is a Certification Authority, and not necessarily a Registration 
Authority. Conceptually and operationally they are different and 
therefore there should always be an allowance for this.

regards

David

Stephen Kent wrote:
> At 11:45 AM +0100 12/16/04, Carlos González-Cadenas wrote:
> 
>> Hi all,
> 
>>  
> 
>> In RFC 3739 (Qualified Certificates Profile), we do have a place to 
>> state the name of the registration authorities that registered the 
>> names and attributes present in the certificate.
> 
>>  
> 
>> Is there any standard way to do it in non-qualified certificates?
> 
>>  
> 
>> Thanks in advance
> 
>>
>> Carlos
> 
>>  
> 
> *
> *
> *No, just the CA name.*
> *
> *
> *Steve*

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJQXvV044007; Thu, 23 Dec 2004 11:26:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBNJQXgf044006; Thu, 23 Dec 2004 11:26:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNJQUvb043593 for <[e-mail]>; Thu, 23 Dec 2004 11:26:32 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBNJQJjh012837; Thu, 23 Dec 2004 14:26:22 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p0620070dbdf0c817e138@[128.89.89.75]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 23 Dec 2004 14:09:39 -0500
To: Tom Gindin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC 3280 and multiple Organization (O) fields in DN
Cc: [e-mail], Jostein Tveit <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:46 AM -0500 12/23/04, Tom Gindin wrote:
>         IMHO, this rule originated with X.400.  The name form containing
>C, O, OU, and CN is largely derived from the "Mnemonic O/R address" of
>CCITT (now ITU) X.400, although in that standard there was also a
>mandatory administrative domain name.  In that standard, C, O, and CN had
>to be single-valued, while OU could have up to four values (see the
>MTSUpperBounds ASN.1 module).
>         I don't see anything in the directory standards proper (especially
>X.520 and X.521, where it would be expected) which is as clear as X.400 in
>forbidding multiple values of C and O while permitting them for OU.
>
>                 Tom Gindin
>

I think the semantics of the attributes support the notion of one 
instance for C and O, but multiple instances of OU.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNGlI5I038953; Thu, 23 Dec 2004 08:47:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBNGlIZd038952; Thu, 23 Dec 2004 08:47:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNGlDmT038911 for <[e-mail]>; Thu, 23 Dec 2004 08:47:13 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iBNGlBSn020709 for <[e-mail]>; Thu, 23 Dec 2004 11:47:11 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iBNGlB10288002 for <[e-mail]>; Thu, 23 Dec 2004 11:47:11 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBNGlANH020654 for <[e-mail]>; Thu, 23 Dec 2004 11:47:11 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iBNGlAae020640; Thu, 23 Dec 2004 11:47:10 -0500
In-Reply-To: <p06200702bdef1fc91916@[10.1.11.4]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail], Jostein Tveit <[e-mail]>
MIME-Version: 1.0
Subject: Re: RFC 3280 and multiple Organization (O) fields in DN
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 23 Dec 2004 11:46:41 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF6|December 9, 2004) at 12/23/2004 11:47:09, Serialize complete at 12/23/2004 11:47:09
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        IMHO, this rule originated with X.400.  The name form containing 
C, O, OU, and CN is largely derived from the "Mnemonic O/R address" of 
CCITT (now ITU) X.400, although in that standard there was also a 
mandatory administrative domain name.  In that standard, C, O, and CN had 
to be single-valued, while OU could have up to four values (see the 
MTSUpperBounds ASN.1 module).
        I don't see anything in the directory standards proper (especially 
X.520 and X.521, where it would be expected) which is as clear as X.400 in 
forbidding multiple values of C and O while permitting them for OU.

                Tom Gindin





Stephen Kent <[e-mail]>
Sent by: [e-mail]
12/22/2004 08:00 AM
 
        To:     Jostein Tveit <[e-mail]>
        cc:     [e-mail]
        Subject:        Re: RFC 3280 and multiple Organization (O) fields 
in DN



At 12:47 PM +0100 12/22/04, Jostein Tveit wrote:
>Hello pkix list!
>
>I have a question regarding RFC 3280 and support for multiple
>Organization (O) fields in the DN field in a certificate.
>
>A can not see that the standard says anything explicit about
>this.
>Can someone please guide me to where I can find some information
>about this issue, or point out the section I missed in the RFC.
>
>Basically, is multiple Organization (O) fields allowed?
>And where is it stated/not stated?
>
>Thanks in advance for all answers.
>
>Regards,
>--
>Jostein Tveit <[e-mail]>

This is an X.500/X.520 question, more than an X.509/PKIX question.

However, my answer in that one would not expect to see multiple 
organization attributes in a DN, although multiple organizational 
unit attributes are fine.  It's a matter of the semantics of DNs and 
the interpretation of attributes.  Similarly, one would not expect to 
see multiple country attributes in a DN, in the usual interpretation 
of the DIT.

Steve





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNAeE5I054015; Thu, 23 Dec 2004 02:40:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBNAeEbs054010; Thu, 23 Dec 2004 02:40:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBNAe91H053580 for <[e-mail]>; Thu, 23 Dec 2004 02:40:09 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 7478834C6F; Thu, 23 Dec 2004 23:40:02 +1300 (NZDT)
Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07023-19; Thu, 23 Dec 2004 23:40:02 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 67EB434C6C; Thu, 23 Dec 2004 23:40:00 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 41C6C37742; Thu, 23 Dec 2004 23:40:00 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1ChQO8-00019K-00; Thu, 23 Dec 2004 23:40:08 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: RFC 3280 and multiple Organization (O) fields in DN
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 23 Dec 2004 23:40:08 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:

>Early versions of the CCITT (wkich is now called ITU-T) included an
>informative state machine about name construction.

"Informative"?  I've always used that state machine as an example of the fact
that even the standards authors had no idea how a DN should be arranged.  So I
guess it is informative, but it's conveying an entirely different message than
was originally intended.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBMEFrjj006180; Wed, 22 Dec 2004 06:15:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBMEFrrN006179; Wed, 22 Dec 2004 06:15:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id iBMEFq6q006138 for <[e-mail]>; Wed, 22 Dec 2004 06:15:52 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 31257 invoked by uid 0); 22 Dec 2004 14:15:51 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.165) by woodstock.binhost.com with SMTP; 22 Dec 2004 14:15:51 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Wed, 22 Dec 2004 09:13:04 -0500
To: Jostein Tveit <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: RFC 3280 and multiple Organization (O) fields in DN
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is part of the X.500 distinguished name.  It does not prohibit any of 
the attributes from appearing more than once.  Early versions of the CCITT 
(wkich is now called ITU-T) included an informative state machine about 
name construction.  So many people took the state machine as normative that 
it was dropped from the later versions of the document to avoid confusion.

Russ

At 06:47 AM 12/22/2004, Jostein Tveit wrote:

>Hello pkix list!
>
>I have a question regarding RFC 3280 and support for multiple
>Organization (O) fields in the DN field in a certificate.
>
>A can not see that the standard says anything explicit about
>this.
>Can someone please guide me to where I can find some information
>about this issue, or point out the section I missed in the RFC.
>
>Basically, is multiple Organization (O) fields allowed?
>And where is it stated/not stated?
>
>Thanks in advance for all answers.
>
>Regards,
>--
>Jostein Tveit <[e-mail]>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBMD6cea036857; Wed, 22 Dec 2004 05:06:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBMD6cLD036856; Wed, 22 Dec 2004 05:06:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBMD6bg7036838 for <[e-mail]>; Wed, 22 Dec 2004 05:06:37 -0800 (PST) (envelope-from [e-mail])
Received: from [10.1.11.4] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBMD6Rjf001595; Wed, 22 Dec 2004 08:06:31 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200702bdef1fc91916@[10.1.11.4]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 22 Dec 2004 08:00:05 -0500
To: Jostein Tveit <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC 3280 and multiple Organization (O) fields in DN
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:47 PM +0100 12/22/04, Jostein Tveit wrote:
>Hello pkix list!
>
>I have a question regarding RFC 3280 and support for multiple
>Organization (O) fields in the DN field in a certificate.
>
>A can not see that the standard says anything explicit about
>this.
>Can someone please guide me to where I can find some information
>about this issue, or point out the section I missed in the RFC.
>
>Basically, is multiple Organization (O) fields allowed?
>And where is it stated/not stated?
>
>Thanks in advance for all answers.
>
>Regards,
>--
>Jostein Tveit <[e-mail]>

This is an X.500/X.520 question, more than an X.509/PKIX question.

However, my answer in that one would not expect to see multiple 
organization attributes in a DN, although multiple organizational 
unit attributes are fine.  It's a matter of the semantics of DNs and 
the interpretation of attributes.  Similarly, one would not expect to 
see multiple country attributes in a DN, in the usual interpretation 
of the DIT.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBMBlxcR079297; Wed, 22 Dec 2004 03:47:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBMBlxpX079296; Wed, 22 Dec 2004 03:47:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bacchus.pvv.ntnu.no (bacchus.pvv.ntnu.no [129.241.210.178]) by above.proper.com (8.12.11/8.12.9) with SMTP id iBMBlwd3079276 for <[e-mail]>; Wed, 22 Dec 2004 03:47:58 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 49195 invoked by uid 32454); 22 Dec 2004 11:47:59 -0000
To: [e-mail]
Subject: RFC 3280 and multiple Organization (O) fields in DN
From: Jostein Tveit <[e-mail]>
Organization: Norwegian University of Science and Technology
Date: Wed, 22 Dec 2004 12:47:58 +0100
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello pkix list!

I have a question regarding RFC 3280 and support for multiple
Organization (O) fields in the DN field in a certificate.

A can not see that the standard says anything explicit about
this.
Can someone please guide me to where I can find some information
about this issue, or point out the section I missed in the RFC.

Basically, is multiple Organization (O) fields allowed?
And where is it stated/not stated?

Thanks in advance for all answers.

Regards,
-- 
Jostein Tveit <[e-mail]>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBIJbMhT083791; Sat, 18 Dec 2004 11:37:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBIJbMCE083790; Sat, 18 Dec 2004 11:37:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBIJbKhl083779 for <[e-mail]>; Sat, 18 Dec 2004 11:37:21 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Sat, 18 Dec 2004 20:36:51 +0100
Date: Sat, 18 Dec 2004 20:36:50 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: SSL/TLS client-auth - Not the way forward?
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <005901c4e4ed$ffc41880$80c5a8c0@rsaedoscymkikx> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.65
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.65 on Emacs 21.3 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Sat, 18 Dec 2004 15:37:22 +0100, Michael Ströder <[e-mail]> said:

michael> 
michael> Anders Rundgren wrote:
[...]
michael> > Comments?
michael> 
michael> What exactly is your question?

I'm going to boldly assume his question means "Do you have any
comments on this practice, and what are they?".  What motives Anders
has, except taking the risk of getting his head bitten off (:-)),
that's an entirely different question.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBIJ632T064573; Sat, 18 Dec 2004 11:06:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBIJ63Mr064571; Sat, 18 Dec 2004 11:06:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av2-1-sn3.vrr.skanova.net (av2-1-sn3.vrr.skanova.net [81.228.9.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBIJ62Fk064227 for <[e-mail]>; Sat, 18 Dec 2004 11:06:03 -0800 (PST) (envelope-from [e-mail])
Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 8635437ED1; Sat, 18 Dec 2004 20:05:50 +0100 (CET)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 78F6637E89; Sat, 18 Dec 2004 20:05:50 +0100 (CET)
Received: from rsaedoscymkikx (t9o913p51.telia.com [213.64.27.51]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id C7B0338017; Sat, 18 Dec 2004 20:05:48 +0100 (CET)
Message-ID: <002201c4e534$9803ea30$80c5a8c0@rsaedoscymkikx>
From: "Anders Rundgren" <[e-mail]>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Cc: <[e-mail]>
References: <005901c4e4ed$ffc41880$80c5a8c0@rsaedoscymkikx> <[e-mail]>
Subject: Re: SSL/TLS client-auth - Not the way forward?
Date: Sat, 18 Dec 2004 20:05:45 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>What exactly is your question?

Michael,
One question was actually in the subject line.

Another question could be if this should in some way be addressed
by future standardization efforts.

I forgot a major reason for why SSL/TLS client-auth is likely to be
of limited use and that is the absence of a "WebSign" standard.
If certificate selection when authenticating and signing are different,
users get confused.  That's why all these Java-things normalize
this part by not using the native support.

That is, w.r.t. PKI practically every aspect of browser usage is
currently non-standard, including:

- certreq/keygen
- websign
- client-auth

This is a bit surprising as client-side PKI in conjunction with browsers
is at least a magnitude bigger than in conjunction with secure e-mail,
and the gap is widening.

rgds
Anders R

----- Original Message ----- 
From: "Michael Ströder" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, December 18, 2004 15:37
Subject: Re: SSL/TLS client-auth - Not the way forward?


Anders Rundgren wrote:
>
> ==================
> It is not using 2way SSL, if it were, there was really no need for it.
>
> fact is, 2way SSL only works in very simple scenarios, accessing only
> one host with no need to handle "logoff". In more often (larger scale)
> solutions, 2way SSL in reality works bad (because browsers will
> renegotiate SSL connections with host changes - also when changing
> subdomains within a domain). 2way SSL breaks SSO when switching
> between different subdomains within the same domain.
>
> because of the problems with 2way SSL, openlogon is designed to use
> 1way ssl, doing the "client side auth" as part of the applet.
>
> Also, 2way SSL is end-to-end between the browser and the server that
> terminates the SSL session. But in most larger setups, this tends to
> be SSL accelerators which sends on (only) the client public
> certificate to the application server. End-to-end is then only over
> the internet, where OpenLogon really is end-to-end since the SSL
> accelerators only takes care of the resource consuming keyexchange.
> Auth is handled by the logon service in the application server.
> ====================
>
> Comments?

What exactly is your question?

Ciao, Michael.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBIEc2cT005490; Sat, 18 Dec 2004 06:38:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBIEc29R005489; Sat, 18 Dec 2004 06:38:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com ([83.121.7.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBIEc1PA005443 for <[e-mail]>; Sat, 18 Dec 2004 06:38:01 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 57E404AC2; Sat, 18 Dec 2004 15:37:24 +0100 (CET)
Received: from nb2.stroeder.com ([127.0.0.1]) by localhost (nb2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02806-01; Sat, 18 Dec 2004 15:37:22 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 74E6F4A94; Sat, 18 Dec 2004 15:37:22 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 18 Dec 2004 15:37:22 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: Re: SSL/TLS client-auth - Not the way forward?
References: <005901c4e4ed$ffc41880$80c5a8c0@rsaedoscymkikx>
In-Reply-To: <005901c4e4ed$ffc41880$80c5a8c0@rsaedoscymkikx>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at stroeder.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> 
> ==================
> It is not using 2way SSL, if it were, there was really no need for it.
> 
> fact is, 2way SSL only works in very simple scenarios, accessing only
> one host with no need to handle "logoff". In more often (larger scale)
> solutions, 2way SSL in reality works bad (because browsers will
> renegotiate SSL connections with host changes - also when changing
> subdomains within a domain). 2way SSL breaks SSO when switching
> between different subdomains within the same domain.
> 
> because of the problems with 2way SSL, openlogon is designed to use
> 1way ssl, doing the "client side auth" as part of the applet.
> 
> Also, 2way SSL is end-to-end between the browser and the server that
> terminates the SSL session. But in most larger setups, this tends to
> be SSL accelerators which sends on (only) the client public
> certificate to the application server. End-to-end is then only over
> the internet, where OpenLogon really is end-to-end since the SSL
> accelerators only takes care of the resource consuming keyexchange.
> Auth is handled by the logon service in the application server.
> ====================
> 
> Comments?

What exactly is your question?

Ciao, Michael.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBIAesZQ088961; Sat, 18 Dec 2004 02:40:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBIAesZj088960; Sat, 18 Dec 2004 02:40:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-1-sn1.fre.skanova.net (av7-1-sn1.fre.skanova.net [81.228.11.113]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBIAerkS088804 for <[e-mail]>; Sat, 18 Dec 2004 02:40:53 -0800 (PST) (envelope-from [e-mail])
Received: by av7-1-sn1.fre.skanova.net (Postfix, from userid 502) id 40AFE37ECF; Sat, 18 Dec 2004 11:40:34 +0100 (CET)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av7-1-sn1.fre.skanova.net (Postfix) with ESMTP id 30BEE37E43 for <[e-mail]>; Sat, 18 Dec 2004 11:40:34 +0100 (CET)
Received: from rsaedoscymkikx (t10o913p28.telia.com [213.64.27.148]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id DA09D37E45 for <[e-mail]>; Sat, 18 Dec 2004 11:40:32 +0100 (CET)
Message-ID: <005901c4e4ed$ffc41880$80c5a8c0@rsaedoscymkikx>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: SSL/TLS client-auth - Not the way forward?
Date: Sat, 18 Dec 2004 11:40:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear List;

Quite a few large-scale PKI implementations rely on Java applets
for digital signatures.  Due to the limited integration between pure Java
and browser crypto/keystores, specific applets are used also for authentication,
rather than using the browser´s SSL/TLS client-authentication capability.  By
using a challenge-response mechanism on top of an SSL/TLS channel, secure
client authentication is achieved using a non-browser-based key.

Usually the server's public key is also a part of the response to thwart
possible man-in-the-middle attacks during the initial SSL/TLS setup.
That is, the auth server must check that the response contains its own key.

>From another mailing list I took the following lines that indicate that
there may be other reasons than Java/browser limitations to not
use SSL/TLS client-authentication.

==================
It is not using 2way SSL, if it were, there was really no need for it.

fact is, 2way SSL only works in very simple scenarios, accessing only
one host with no need to handle "logoff". In more often (larger scale)
solutions, 2way SSL in reality works bad (because browsers will
renegotiate SSL connections with host changes - also when changing
subdomains within a domain). 2way SSL breaks SSO when switching
between different subdomains within the same domain.

because of the problems with 2way SSL, openlogon is designed to use
1way ssl, doing the "client side auth" as part of the applet.

Also, 2way SSL is end-to-end between the browser and the server that
terminates the SSL session. But in most larger setups, this tends to
be SSL accelerators which sends on (only) the client public
certificate to the application server. End-to-end is then only over
the internet, where OpenLogon really is end-to-end since the SSL
accelerators only takes care of the resource consuming keyexchange.
Auth is handled by the logon service in the application server.
====================

Comments?

Anders Rundgren
PKI Architect etc.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGKmd5M098164; Thu, 16 Dec 2004 12:48:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGKmdJP098163; Thu, 16 Dec 2004 12:48:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGKmcSg098140 for <[e-mail]>; Thu, 16 Dec 2004 12:48:38 -0800 (PST) (envelope-from [e-mail])
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Dec 2004 12:48:25 -0800
Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Dec 2004 12:48:39 -0800
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Dec 2004 12:48:37 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 16 Dec 2004 12:48:26 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Thu, 16 Dec 2004 12:48:35 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTbfdnnQM8sCGUwQ1+o/ms74r26bABGmo+wAZn7R1AAKa9pIA==
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Dec 2004 20:48:26.0261 (UTC) FILETIME=[9722DC50:01C4E3B0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBGKmcSg098157
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here is 23-45
Trevor

* -----Original Message-----
* From: Trevor Freeman
* Sent: Wednesday, December 15, 2004 4:02 PM
* To: 'Denis Pinkas'
* Cc: '[e-mail]'
* Subject: RE: SCVP 16 comments deadline
* 
* Here is 17-22
* Trevor
* 
* * -----Original Message-----
* * From: Trevor Freeman
* * Sent: Tuesday, December 07, 2004 12:47 PM
* * To: 'Denis Pinkas'
* * Cc: [e-mail]
* * Subject: RE: SCVP 16 comments deadline
* *
* * Hi Denis,
* * Below are responses to 1-16. Others will follow later.
* * Trevor
* *
* * * -----Original Message-----
* * * From: Denis Pinkas [mailto:[e-mail]]
* * * Sent: Monday, December 06, 2004 2:25 AM
* * * To: Trevor Freeman
* * * Cc: [e-mail]
* * * Subject: Re: SCVP 16 comments deadline
* * *
* * * Trevor,
* * *
* * * > The deadline communicated at the DC meeting for making comments
on
* * SCVP
* * * > 16 was Nov 30th which has now passed. I have had only three
people
* * send
* * * > me comments to date. SCVP 17 will be closing very shortly so
this is
* * the
* * * > last reminder.
* * *
* * * Thank for the remainder. I missed the initial announcement.
* * * My comments are below.
* * *
* * *
* * * 1. Typo. There are two IPR statements related to RFC 3668 on the
first
* * * page. Delete one.
* * *
* * * " By submitting this Internet-Draft, I certify that any applicable
* * *    patent or other IPR claims of which I am aware have been
disclosed,
* * *    or will be disclosed, and any of which I become aware will be
* * *    disclosed, in accordance with RFC 3668".
* * [TF] Fixed
* * *
* * *
* * * 2. Page 11. Typos. First paragraph on top of the page.
* * * Replace "signers" by "signer's".
* * [TF] Fixed
* * *
* * *
* * * 3. Page 11. Typo. First paragraph on top of the page. Last
sentence.
* * * Replace "certificate" by "certificates".
* * [TF] Fixed
* * *
* * *
* * * 4. Page 13. Typo. Section 3.1.2 "checks"
* * * The two following lines are in fact one line:
* * *
* * * Change:
* * *
* * *      - Build a validated certification path to a trust anchor; and
* * *
* * *      - Do revocation status checks on the certification path.
* * *
* * * into:
* * *
* * *      - Build a validated certification path to a trust anchor and
* * *        do revocation status checks on the certification path.
* * *
* * [TF] Since this paragraph is listing the possible checks and
building a
* * path is a separate check to revocation checking, I think the current
* text
* * is more accurate.
* * *
* * * 5. Page 15. Typo. Section 3.1.4 validationPolicy
* * *
* * * This is the error left intentionally by the editor to know who
read
* the
* * * document. The following sentence is duplicated: " The
* validationPolicy
* * * item, defines the validation policy". Please delete one sentence.
* * [TF] Just checking <g> Fixed
* * *
* * *
* * * 6. Page 24. Typo. Section 3.1.5.9 keyUsages
* * *
* * * Change "keyUasge" into "keyUsage".
* * [TF] Fixed
* * *
* * *
* * * 7. Page 27. Typo. Section 3.1.8 valididationTime
* * * Last line of the first paragraph. Change "servers" into "server's"
* * [TF] Fixed
* * *
* * *
* * * 8. Page 32. Typo. Section 3.5 dhPublicKey
* * * Change: Diffie-Hellamn into Diffie-Hellman.
* * [TF] Fixed
* * *
* * *
* * * 9. Page 32. Typo. Section 3.5 dhPublicKey
* * * Fifth line. Change "an does" into "and does"
* * [TF] Fixed
* * *
* * *
* * * 10. Page 32. Typo. Section 3.5 dhPublicKey
* * * Delete: (see section Error! Reference source not found.)
* * *
* * *
* * * 11. Page 33. Typo. Section 4. Validation Response
* * *
* * * After the eight items. The following sentence has a grammar
problem:
* * *   "Successful responses are be made when the server has fully
* complied
* * *    with the request".
* * [TF] Deleted the "be"
* * *
* * *
* * * 12. Page 52. Typo. Section 6 Validation Policy Response
* * *
* * * The second sentence is incorrect. It is:
* * * The valPolResponse MAY not unique to any valPolRequest, ..."
* * *
* * * Change into:
* * * "The valPolResponse MAY not be unique to any valPolRequest, ..."
* * [TF] Fixed
* * *
* * *
* * * 13. The abstract does not reflect accurately the content of the
* * * document.
* * * "certificate handling" is too vague.
* * *
* * * Proposed abstract:
* * *
* * *    SCVP allows a client to delegate certificate path construction
and
* * *    certificate path validation to a server. The path construction
or
* * *    validation (i.e. making sure that none of the certificates of
the
* * *    path is revoked) is made according to a validation policy which
* * *    contains one or more trust anchors. It allows to simplify
client
* * *    implementations and to use a set of predefined validation
policies.
* * [TF] Suggested text substituted
* * *
* * *
* * * 14. Section 1.3
* * *
* * * The text on validation policy is new. There is no concept of
* "mutually
* * * agreed" validation policy between the client on the server. The
* server
* * * supports a set of validation policies which may or may not fit the
* need
* * * of the client.
* * *
* * * Change the second sentence of section 1.3 which is:
* * *
* * * " In SCVP, a validation policy can be either mutually
* * *    agreed between client and server, and subsequently referenced
in
* * *    request, or explicitly expressed in the request by passing all
of
* * *    the necessary parameters."
* * *
* * * into:
* * *
* * * " In SCVP, the validation policy to be used by the server can be
* either
* * * fully referenced in the request by the client (and thus no
additional
* * * parameter is necessary), referenced in the request by the client
with
* * * additional parameters or supported by default by the server if the
* * * client does not reference it."
* * [TF] Suggested text substituted
* * *
* * *
* * * 15. Section 1.3. The second paragraph needs to be reworded.
Currently,
* * * it is the following:
* * *
* * * " Policy definitions can be quite long and complex, and some
policies
* * *    may allow for the setting of a few parameters such as a set of
* * *    trust anchors.  The request can therefore be simplified if
these
* * *    previously agreed policy dependent parameters are referenced in
the
* * *    request by a mutually agreed OBJECT IDENTIFIER (OID) or URL
value.
* * *    The referenced value indicates either a partial or full set of
* * *    parameters. The client can therefore omit these agreed
parameters
* * *    from the request, only passing any parameters which are not
* * *    specified by the previously agreed policy.  Therefore in the
* * *    simplest form, with validation polices which define every
parameter
* * *    necessary, a SCVP request need only contain the certificate to
be
* * *    validated, the validation policy and any run-time parameters
for
* * *    the request".
* * *
* * * Proposed rewording:
* * *
* * * " Policy definitions can be quite long and complex, and some
policies
* * *    may allow for the setting of a few parameters.  The request can
* * *    therefore be very simple if OBJECT IDENTIFIERS (OIDs) are used
to
* * *    specify both the algorithm to be used and all the associated
* * *    parameters of the validation policy. The request can be more
* complex
* * *    if the validation policy fixes many of the parameters but
allows
* the
* * *    client to specify some of them. When the validation policy
defines
* * *    every parameter necessary, a SCVP request needs only to contain
the
* * *    certificate to be validated, the referenced validation policy
and
* any
* * *    run-time parameters for the request. In its simplest form, a
SCVP
* * *    request contains the certificate to be validated and any
run-time
* * *    parameters for the request. In that case the server uses a
default
* * *    validation policy".
* * [TF] Suggested text substituted
* * *
* * *
* * * 16. Section 1.3. Paragraph 3.
* * *
* * * The text is missing the fact that at least one validation policy
must
* * * be supported by the server. This is the default policy which is
used
* * * when the client omits to specify it.
* * *
* * * The current text is the following:
* * *
* * *   "SCVP server also publishes its default validation policy
settings.
* * *    The default policy can be requested for validation and the
client
* * *    can override any default value in the request if required.  The
* * *    default values are also used when processing requests which
* * *    reference a validation policy other than the default one that
does
* * *    not contain the full set of parameters necessary for validation
and
* * *    the client has also omitted the missing values in the request.
* * *
* * *    Therefore a client can also simplify the request by omitting a
* * *    parameter from a request if the default value published by the
* * *    server is acceptable".
* * *
* * * Replace it with:
* * *
* * * " A SCVP server must support a default validation policy which
will
* * *    be used if the client does not specify any in its request. A
server
* * *    publishes the references of the validation policies it
supports.
* * *    When these policies have parameters that may be overridden, the
* * *    default value for these parameters are communicated by the
server
* as
* * *    well. The client can simplify the request by omitting a
parameter
* * *    from a request if the default value published by the server for
a
* * *    given validation policy reference is acceptable. However if
there
* is
* * *    a desire to demonstrate to someone else that a specific
validation
* * *    policy with all its parameters has been used, it will need to
ask
* the
* * *    server for the inclusion of the full validation policy with all
the
* * *    parameters in the response".
* * [TF] Suggested text substituted
* * *
* * *
* * * 17. On top of page 7, the relationship between the validation
policy
* * * and the basic certification path algorithm is not explained. Then
in
* * * section 1.4 The concept of validation algorithm is introduced but
its
* * * relationship with the validation policy is not explained. This is
* * * confusing.
* * *
* * * Later on when observing the ASN.1 syntax it may be discovered that
two
* * * OIDs are being used:
* * *
* * *   - one for the validation policy (ValidationPolRef) and
* * *   - one for the validation algorithm (ValidationAlg).
* * *
* * * This is overcomplicated and unnecessary.
* [TF] Is there a specific issue with the current draft such as a
scenario
* which is not addressed?
* * *
* * * An important simplification is obtained if, as the previous text
* * * states, there is an OID to defined the validation policy and there
may
* * * be or may not be additional parameters.
* * *
* * * We could then have:
* * *
* * * valPolByOID::= SEQUENCE {
* * *        valPolId              OBJECT IDENTIFIER,
* * *        parameters            ANY DEFINED BY ValPolId OPTIONAL }
* * *
* * * Specifying a path processing compliant with section 6.1 of RFC
3280
* * * would be possible (notice however that the text from RFC 3280 is
too
* * * vague to support the case where a CRL is not signed by the CA).
* * *
* * * It would be desirable to be able to communicate easily and in a
* * * standard way the parameters that may be set in section 6.1 from
RFC
* * * 3280. In addition, key usage should be added to that list.
* * *
* * * The document should then define a bundle of all these previous
useful
* * * parameters and allow for the addition of other parameters.
* * *
* * * It is thus proposed to define an OID for a validation policy
compliant
* * * with section 6.1 of RFC 3280 (some differences with section 6 from
* * * 3280bis, i.e. adding precision, may be expected)
* * *
* * * It is thus proposed to modify the text starting from :
* * *
* * * " The inputs to the basic certification path processing algorithm
* * *    used by SCVP are defined by [PKIX-1] in section 6.1.1 and
* comprise"
* * *    up to the end of section 1.3 with the following:
* * *
* * * "For clients able to specify the parameters of a validation
policy,
* it
* * * may be useful to define a standard data structure (using a bundle)
* able
* * * to support the parameters of the basic certification path
processing
* * * algorithm defined by in section 6.1.1 from [PKIX-1] :
* * *
* * *   - a set of Trust Anchors (by value or by reference),
* * *   - the initial Certificate Policy set,
* * *   - initial Certificate Policy mapping setting,
* * *   - initial any-Policy setting,
* * *   - initial explicit Certificate Policy setting.
* * *
* * * as well as :
* * *
* * *    - the usage of the key contained in the certificate (e.g., key
* * *      encipherment, key agreement, signature)
* * *
* * * This will be done using a bundle which encapsulates all these
* * * parameters.
* * *
* * * Other application-specific purposes parameters may be added".
* * *
* * *
* * * 18. Section 1.4 is about a "Validation Algorithm". Given what was
* said
* * * before, the header of this section should be changed. If we make a
* * * subsection 1.3.1 called "1.3.1. General" for encapsulating the
* * previous
* * * text, then we can introduce a new section 1.3.2 called:
* * *
* * * "1.3.2. Validation policy according to section 6.1 of RFC 3280"
* [TF] See comment to 17
* * *
* * * Some of the text present in the current section 1.4 has been used
to
* * * build the new text that is proposed below:
* * *
* * * "1.3.2. Validation policy according to section 6.1 of RFC 3280
* * *
* * *    SCVP defines a specific validation policy which implements the
* * *    certification path validation algorithm as defined in section
6.1
* of
* * *    [PKIX-1]. This specific validation policy, called "rfc-3280
basic
* * *    validation policy" uses the parameters defined in the bundle
* * *    mentioned above.
* * *
* * *    Note that this algorithm does not support in its full
generality
* the
* * *    algorithm described in section 6.2 of [PKIX-1] since, when more
* than
* * *    one trust anchor is being defined, all the conditions that are
* * *    specified apply to all trust anchors, whereas section 6.2
allows to
* * *    have different conditions for every trust anchor.
* * *
* * *    The rfc-3280 basic validation policy may be the default
validation
* * *    policy supported by the server, but does not need to".
* * *
* * *
* * * 19. Section 2 "Protocol Overview"
* * *
* * * In order to allow for interoperability and testing a common
protocol
* * * needs to be supported. It should be defined.
* [TF] There is plenty of precedence for this to be in a separate
document.
* CMS itself just defines the syntax.
* * *
* * *
* * * 20. Section 3 "Validation Request"
* * *
* * * The unsigned request form is not explained and there is a
confusion
* for
* * * the signed request which indeed authenticates the client and is
thus
* * * not anonymous. The current text is :
* * *
* * *    "A signed
* * *    request is used to authenticate the client to the server or to
* * *    provide an anonymous client integrity over the request-response
* * *    pair."
* * *
* * * It should be rephrased as:
* * *
* * *    "An unsigned request provides an anonymous client integrity
over
* * *     the request since the hash of the request or the full request
is
* * *     incorporated in the response. A signed request is used to
* * *     authenticate the client to the server".
* [TF] Since by definition the anonymous client has to sign the request
as
* well this does not make sense. A server can also return a cached
response
* in which case there is no hash of the request in the response. How
about
* 
* An anonymous client signs the request to provide integrity over
* the request. A identifiable signs the request to authenticate itself
to
* the server.
* 
* 
* 
* 
* * *
* * *
* * * 21. Page 13. Section 3.1.2 "checks"
* * *
* * * The following sentence adds nothing and should be removed:
* * *
* * *    "A server may still choose to
* * *    perform revocation status checks when performing path
construction,
* * *    although this information cannot be returned to the client."
* [TF] I think it reinforces that with some checks, don't require
revocation
* status checking but a server may still elect to do so.
* * *
* * *
* * * 22. Page 15. Section 3.1.3 "wantBack"
* * *
* * * The text states:
* * *
* * *      - Proof of revocation status for each certificate in the AC
* * *         issuer certification path;
* * *
* * * It would be important to refer the section of the RFC which
explains
* * * how to
* * * check the "revocation status for each certificate in the AC issuer
* * * certification path".
* [TF] OK, I will add a reference to 3281 section 5.
* * *
* * *
* * * 23. Page 15. Section 3.1.3 "wantBack"
* * *
* * * The text states:
* * *
* * *    The client can also request a non-cached response to the
request by
* * *    including wantback id-swb-non-cached-resp in the request.
* * *
* * * The default behavior should be the reverse: fresh information is
* * * provided, unless the client accept cached information. The item
should
* * * be changed into:
* * * id-swb-cached-resp
[TF] This has been moved to response flags and the default is
non-cached.
* * *
* * *
* * * 24. Page 15. Section 3.1.3 "wantBack"
* * *
* * * The text states:
* * *
* * * id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
* * *
* * * It should be mentioned that this item is only possible for DPD.
[TF] Why is this only possible with DPD?
* * *
* * *
* * * 25. Page 16. Section 3.1.4 validationPolicy
* * *
* * * The following sentence is talking of an agreement whereas such
* * * agreement does not exist. Delete the sentence:
* * *
* * *   "The client and server can optionally agree on a set of
parameters
* * *    which may fully or partially define a validation policy".
[TF] OK
* * *
* * *
* * * 26. Page 16. Section 3.1.4 validationPolicy
* * * The text states:
* * *
* * *    "If a partial set of parameters has been agreed upon,
* * *    then the client supplies a reference to the policy plus
whatever
* * *    parameters are necessary to complete the request in this item.
* * *
* * * This should be replaced with:
* * *
* * *    "If the validation policy does not define all parameters
necessary
* * *    for processing an SCVP request, then the client need to supply
* these
* * *    parameters".
[TF] Thats is not true. The client can omit whatever parameters match
the server default value.
* * *
* * * 27. Page 16. Section 3.1.4 validationPolicy
* * *
* * *    The syntax of the validationPolicy item is defined as:
* * *
* * *    ValidationPolicy ::= SEQUENCE {
* * *      validationPolRef          ValidationPolRef,
* * *      validationAlg         [0] ValidationAlg OPTIONAL,
* * *      userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
* * *                                  IDENTIFIER OPTIONAL,
* * *      inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* * *      requireExplicitPolicy [3] BOOLEAN OPTIONAL,
* * *      inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
* * *      isCA                  [5] BOOLEAN OPTIONAL,
* * *      trustAnchors          [6] TrustAnchors OPTIONAL,
* * *      keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
* * *                                   OPTIONAL,
* * *      extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}
* * *
* * *
* * * This structure is quite odd, because it only allows to pass
additional
* * * parameters as parameters of the validationAlg. Suppressing the
* * * validationAlg item add adding validationParamExtensions would be a
* * * simpler and cleaner way.
[TF] The only way to include other parameters is because the algorithm
needs them. You cannot introduce new parameters without at the same time
defining there use. Therefore mandating additional parameters be passed
which the corresponding identifier for their is the right thing to do.
* * *
* * * Each validation policies uses its own parameters.
* * * We should have something like :
* * *
* * * ValPolByOID  ::= SEQUENCE {
* * *        valPolgId             OBJECT IDENTIFIER,
* * *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* * *
* * * More details follow.
* * *
* * *
* * * 28. It is highly debatable if URIs should be supported or not to
* * * reference a validation policy. URIs are not stable over time and
thus
* * * unless there are dereferenced and a hash value is computed over
them,
* * * it is insecure to use them. There is a discussion in the security
* * * consideration section, but no warning and no pointer here. If we
keep
* * * them, we should warn the user.
[TF] The argument over the stability of URIs is discussed in the
security section - which is the appropriate place. The reality is in
many organizations are stable enough and much more manageable. The issue
over dereferencing and hashing is bogus. Both OID and URI are both
opaque stings for this purpose and rely on you trusting the management
doing the right thing. 
* * *
* * * If the WG should decides that they should be supported (and if the
* IESG
* * * agrees) on page 17, the ASN.1 description should then be:
* * *
* * * ValidationPolicy ::= CHOICE {
* * *      valPolByOID         [0] ValPolByOID,
* * *      valPolByURI         [1] ValPolByURI }
* * *
* * * ValPolByOID  ::= SEQUENCE {
* * *        valPolgId             OBJECT IDENTIFIER,
* * *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* * *
* * * ValPolByURI ::= SEQUENCE {
* * *      uri            IA5String,
* * *      hashAlgo       OBJECT IDENTIFIER,
* * *      hashValue      OCTET STRING}
* * *
* * *
* * * 29. It is proposed to define the following bundle:
* * *
* * * ValidationParamBundle ::= SEQUENCE {
* * *      certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF
OBJECT
* * *                                    IDENTIFIER OPTIONAL,
* * *      inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
* * *      requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
* * *      inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
* * *      isCA                      [4] BOOLEAN OPTIONAL,
* * *      trustAnchors              [5] TrustAnchors OPTIONAL,
* * *      keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF
KeyUsage
* * *                                    OPTIONAL,
* * *      extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
* * *      extensions                [8] EXPLICIT Extensions OPTIONAL }
* * *
* * * Note that userPolicySet" is unclear and has been changed into
* * * "certificatePolicySet".
[TF] The use of userPolicySet aligns with 3280. I don't think the name
to the existing structure is ambiguous or misleading.
* * *
* * * The text would need to be aligned with the new structure and, of
* course
* * * the parameters of the rfc-3280 basic validation policy will simply
* * * include the bundle above as its parameters.
* * *
* * * It should also be mentioned somewhere in the document that the
support
* * * of the rfc-3280 basic validation policy is not mandatory for
* * * conformance but, if supported then the bundle needs to be
supported.
* * *
* * *
* * * 30. Page 17. Section 3.1.5 validationAlg should be deleted.
[TF] Already done
* * *
* * *
* * * 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should
be
* * * deleted and replaced by a section later on the "rfc-3280 basic
* * * validation policy", which should have its OID defined under the
scvp
* * * tree for OIDs.
[TF] the basic validation algorithm references the 3280 section 6. 
* * *
* * *
* * * 32. Page 17. Section 3.1.5.1. Some text of this section might be
re-
* * * sued to build a new section on the rfc-3280 basic validation
policy.
* * * Note that the last sentence at the bottom of page 17, should be
* * * removed. This sentence is: "The default validation policy MUST use
* the
* * * basic validation algorithm". Any default validation policy can be
* used.
* * *
[TF] See answer to 31
* * *
* * * 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
* * * should be as well deleted.
[TF] The duplicate has been deleted
* * *
* * *
* * * 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
* * *
* * * This goal of this section seems to introduce an additional test to
the
* * * basic "rfc-3280 basic validation policy". It would come naturally
as
* * an
* * * extension of ValidationParamBundle, rather than as a parameter of
the
* * * validationAlgo which has been proposed to be removed. The text
should
* * * be modified accordingly.
[TF] See answer 27 
* * *
* * *
* * * 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
* * *
* * *      NameValidationAlgParms ::= SEQUENCE {
* * *        keyPurposeId      KeyPurposeId,
* * *        validationNames   GeneralNames }
* * *
* * * This construct is artificial since KeyPurposeId is about the
Extended
* * * Key Usage and has nothing to do with name validation.
[TF] Its simple reuses and existing practice.
* * *
* * * It could indeed be interesting to test the Extended Key Usage
* extension
* * * of a certificate, but this should be supported as an extension of
* * * ValidationParamBundle. The text should be modified accordingly.
* * *
* * *
* * * 36. Page 22. Section 3.1.5.3 userPolicySet
* * *
* * * userPolicySet should be changed everywhere into
certificatePolicySet.
[TF] userPolicySet aligs with 3280 sectuin 6.
* * *
* * *
* * * 37. Page 22. Section 3.1.5.3 userPolicySet
* * *
* * * The text has many sentences like:
* * *
* * *    SCVP clients SHOULD support userPolicySet item in requests, and
* * *    SCVP servers MUST support userPolicySet item in requests.
* * *
* * * These requirements only apply for the rfc-3280 basic validation
* policy,
* * * and this should be clearly mentioned.
[TF] Since all validation polices contain userPolicySet, it can be in
any policy.
* * *
* * *
* * * 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
* * *
* * * The text states:
* * *
* * *    By default the server allows policy mapping as
* * *    part of certification path validation.
* * *
* * * For simplicity, this should be the reverse. Replace with:
* * *
* * *   "By default the server does not perform policy mapping as
* * *    part of certification path validation. If the client wants the
* * *    server to support policy mapping, allowPolicyMapping must be
set
* * *    to TRUE in the request".
[TF] This conflicts with 3280 section 6.
* * *
* * *
* * * 39. Page 24. Section 3.1.5.8 trustAnchors
* * *
* * * The text states:
* * *
* * *   "A certificate reference can be used to identify the
* * *    trust anchor by certificate hash and optionally a distinguished
* * *    name with serial number".
* * *
* * * This is not consistent with the ASN.1 definition of PKCReference
which
* * * is:
* * *
* * *    PKCReference ::= CHOICE {
* * *      cert                   [0] Certificate,
* * *      pkcRef                 [1] ESSCertID }
* * *
* * * Please correct.
* * *
* * *
* * * 40. Page 25. Section 3.1.6 responseRefHash
* * *
* * * The text states:
* * *
* * *    "By default, the server includes a hash
* * *    of the request in the response.  If the client wants the server
to
* * *    include the full request in the response, responseRefHash is
set to
* * *    FALSE."
* * *
* * * The server shall always include a hash of the request in the
response.
[TF] A server cannot include a hash of the request in a cached response.
* * * This is an easy way to allow to test the integrity of the request.
* * * Since the full description of the validation policy may be much
longer
* * * a flag should be used to say that the full validation policy is
not
* * * returned unless requested. 
[TF] There is one, it is responseValidationPolByRef. The reponce flags
now has a FullRequestInResponse in place of the requestRefHash

It is thus proposed to have instead the
* * * following:
* * *
* * * "3.1.6.1 fullRequestInResponse
* * *
* * *    The fullRequestInResponse controls if the client wants the
server
* * *    to include the full request in the response. By default,
* * *    fullRequestInResponse is set to FALSE. If the client wants back
* * *    the full request then it must set this parameter to TRUE. The
main
* * *    reason a client would request the server to include the full
* request
* * *    in the response is to archive the request-response exchange in
a
* * *    single object.  That is, the client wants to archive a single
* object
* * *    which includes both request and response".
* * *
* * *
* * * 41. Page 26. Section 3.1.6.2 responseValidationPolByRef
* * *
* * * This item should be renamed: fullValPolInResponse
* * *
* * * The text should be changed into:
* * *
* * * "The fullValPolInResponse controls whether the response includes
the
* * * identifier of the validation policy with all the parameters that
have
* * * been used by the server, i.e. all the variable parameters
independent
* * * from the fact that there were specified by the client or defaulted
if
* * * not specified. By default, fullValPolInResponse is set to FALSE.
If
* the
* * * client wants the full validation policy to be included, then
* * * fullValPolInResponse is set to TRUE. The main reason a client
would
* * * request the server to include validation policy to be included by
* value
* * * is to archive the request-response exchange in a single object.
That
* * * is, the client wants to archive the CVResponse and have it include
* * * every aspect of the validation policy."
[TF] I have not chages the name, but the section now reads

The responseValidationPolByRef controls whether the response includes
just a reference to the policy or the reference to the policy plus all
the parameters by value of the policy used to process the request.  
the response MUST contain references to the validation policy.  If the
client wants the validation policy parameters to be also included by
value, then the responseValidationPolByRef is set to FALSE.  The main
reason a client would request the server to include validation policy to
be included by value is to archive the request-response exchange in a
single object.  That is, the client wants to archive the CVResponse and
have it include every aspect of the validation policy.

* * *
* * * The ResponseFlags should be changed as follows:
* * *
* * *    ResponseFlags ::= SEQUENCE {
* * *      fullRequestInResponse      BOOLEAN DEFAULT FALSE,
* * *      fullValPolInResponse       BOOLEAN DEFAULT FALSE,
* * *      signResponse               BOOLEAN DEFAULT TRUE }
* * *
* * *
* * * 42. Page 28. Section 3.1.9 intermediateCerts. Minor.
* * *
* * * Change:
* * *
* * *    The optional intermediateCerts item helps the SCVP server
create
* * *    valid certification paths.
* * *
* * * into:
* * *
* * *    The optional intermediateCerts item may help the SCVP server to
* * * create
* * *    valid certification paths.
[TF] Fixed
* * *
* * * 43. Page 29. Section 3.1.11. producedAt
* * *
* * * Last sentence. Change:
* * *
* * *    SCVP server SHOULD support the producedAt values in the
request.
* * *
* * * into:
* * *
* * *    SCVP server MAY support the producedAt values in the request.
* * *
* * * Reason: cached responses should not need to be implemented in
order to
* * * be compliant with the specification.
[TF] Fixed
* * *
* * *
* * * 44. Page 32. Section 3.5 dhPublicKey
* * *
* * * The text states:
* * *
* * *   "For the server to compute the shared
* * *    secret, it must lean the public values the client generates,
* * *    therefore the client MUST include this in the request if it
uses
* * *    this mechanism to integrity protect the request-response pair."
* * *
* * * Replace:
* * *
* * * "to integrity protect the request-response pair"
* * *
* * * with :
* * *
* * * "to authenticate and integrity protect the first response and
* * * authenticate and integrity protect subsequent request-response
* pairs".
[TF] draft now read " integrity protect the request and the subsequent
response." The use of DH does not necessarily authenticate the request.
* * *
* * * 45. Page 32. Section 3.6 SCVP Request Authentication
* * *
* * * The text states:
* * *
* * *   "It is a matter of local policy what validation policy is used
by
* * *    the server when validating requests".
* * *
* * * This sentence could be misinterpreted because the word
"validating"
* is
* * * being used. Change into:
* * *
* * *    It is a matter of local policy what validation policy is used
by
* * *    the server when authentication requests".
* * *
[TF] Fixed
* * *
* * * 46. Page 35. Section 4. Validation Response
* * *
* * *    The CVResponse is defined as follows:
* * *
* * *      CVResponse ::= SEQUENCE {
* * *        cvResponseVersion         cvResponseVersion        INTEGER,
* * *        policyID                  INTEGER,
* * *        producedAt                GeneralizedTime,
* * *        ....
* * *
* * * On the next page the test states:
* * *
* * *   "The policy ID used by the SCVP server when it processed the
* request.
* * *    See section 6.4 for details."
* * *
* * * In section 6.4 the text states:
* * *
* * * "6.4 defaultPolicyID
* * *
* * *    An integer that uniquely represents the version of the default
* * *    validation policy as represented by the trustAnchors, ..."
* * *
* * * This is not understandable, over-engineering and very complicated.
* * * Please delete this item.
* * *
* * *
* * * 47. Page 35. Section 4. Validation Response
* * *
* * *    The CVResponse contains:
* * *
* * *        requestRef            [1] RequestReference OPTIONAL,
* * *
* * * Remove "OPTIONAL" since it is very beneficial to mandate this item
* * * since it allows to make sure that the request has not be modified
if
* * * the response is integrity protected. The computation is fast and
easy
* * * and the hash value does not overload the response.
* * *
* * *
* * * 48. Page 38. Section 4.5 respValidationPolicy
* * *
* * * The definition of this item is overcomplicated and not tailored to
* * * support any kind of validation policy.
* * *
* * * If the client does not specify the validation policy or if the
client
* * * specifies a validation policy which has default parameters, then
the
* * * full description of the validation policy shall be given back.
* * *
* * * If the client specifies a validation policy which has no default
* * * parameters, then the reference and parameters, if any, of the
* * * validation policy are in the request.
* * *
* * * The full description of the validation policy shall be given back
in
* * * any case, if the fullValPolInResponse Boolean in ResponseFlags is
set.
* * *
* * * respValidationPolicy :: = ValidationPolicy
* * *
* * *
* * *
* * * 49. Page 41. Section 4.6 requestRef
* * *
* * * As stated earlier, requestRef should be mandatory and always be a
hash
* * * of the request.
* * *
* * * In addition a fullRequest OPTIONAL parameter should be added as an
* * * optional item for CVResponse.
* * *
* * * The full description of the validation policy shall be given back
in
* * * any case, if the fullRequestInResponse Boolean in ResponseFlags is
* set.
* * *
* * * Change the text and the syntax accordingly.
* * *
* * *
* * * 50. Page 41. Section 4.6 requestRef
* * *
* * * The text states:
* * *
* * *    "The requestRef item allows the client to associate a response
* with
* * *    a request"
* * *
* * * This is wrong. This does not protect against a replay.
* * *
* * * Change with:
* * *
* * * "When the response is authenticated, the requestRef item allows
the
* * * client to make sure that the request was not modified in transit".
* * *
* * *
* * * 51. Page 41. Section 4.6 requestRef
* * *
* * * The text states:
* * *
* * * " The requestNonce provides an alternative mechanism for
* * *    matching requests and responses if the client has selected to
* * *    include a full response."
* * *
* * * This is wrong. This is not an alternative for matching requests
and
* * * responses.
* * *
* * * Replace with:
* * *
* * *   "The requestNonce allows to protect against replay, even if time
* * * synchronization is not good between the client and the server".
* * *
* * *
* * * 52. Page 42. Section 4.6.1 requestHash
* * *
* * * The text states:
* * *
* * * " The requestNonce provides an alternative mechanism for matching
* * * requests and responses".
* * *
* * * This is wrong. See above. Delete.
* * *
* * *
* * * 53. Page 45. Section 4.10.4 replyChecks
* * *
* * * ReplyCheck is defined as:
* * *
* * *      ReplyCheck ::= SEQUENCE {
* * *        check                      OBJECT IDENTIFIER,
* * *        status                     INTEGER }
* * *
* * * It should be defined as:
* * *
* * *      ReplyCheck ::= SEQUENCE {
* * *        check                      OBJECT IDENTIFIER,
* * *        status                     INTEGER DEFAULT 0}
* * *
* * *
* * * 54. Page 46. Section 4.10.4 replyChecks
* * *
* * * The text states
* * *
* * *    "The status value for public key certification path building to
a
* * *    trusted root along with complete status checking, { id-stc 3 },
can
* * *    be one of the following:
* * *
* * *        0: Good
* * *        1: Revoked
* * *        2: Revocation Offline
* * *        3: Revocation Unavailable
* * *
* * * It is unclear to understand the benefits that a client can have
from
* * * the difference between "Revocation Offline" and "Revocation
* * * Unavailable". In addition, these wordings do not match the
* explanations
* * * of what there are.
* * *
* * * A much more important response is missing: suspended. Suspended is
a
* * * variation of revoked, but the client then knows it may attempt
another
* * * try later on.
* * *
* * * It is thus suggested to change it into:
* * *
* * *        0: Good
* * *        1: Revoked
* * *        2: Suspended
* * *        3: Revocation info unavailable"
* * *
* * *
* * * 55. Page 46. Section 4.10.4 replyChecks
* * *
* * *
* * * The same comment applies for the status value for AC issuer
* * * certification path.
* * *
* * *
* * * 56. Page 48. Section 4.10.6 validationAlg
* * * For reasons given before, delete validationAlg.
* * *
* * *
* * * 57. Page 48. Section 4.10.8 nextUpdate
* * *
* * * If CRLs are used, should this field contain the value of the next
* * * update field for the smallest value of all the CRLs ? What is the
real
* * * benefit of supporting this element besides added complexity ? It
is
* * * suggested to delete that item.
* * *
* * *
* * * 58. Page 49. Section 4.11 responseNonce
* * *
* * * The text states:
* * *
* * * "The responseNonce item contains an identifier to binds the
request
* * * to the response."
* * *
* * * This is incorrect. The nonce is to detect replay.
* * *
* * * Change into:
* * *
* * * "The responseNonce item contains a unique number which allows to
* detect
* * * replay".
* * *
* * *
* * * 59. Page 51. Section 5 Server Policy Request
* * *
* * * The text states:
* * *
* * *   "A SCVP client uses the valPolRequest item to request the list
of
* * *    validation policies supported by the SCVP server."
* * *
* * * This is not a correct description of what this request is doing.
When
* * * looking at the ASN.1 it is doing much more. So the question is
whether
* * * two requests should be provided or one. In the later case, it is
* * * important to advertise correctly what the request is doing.
* * *
* * *
* * * 60. Page 52. Section 6 Validation Policy Response
* * *
* * * The ASN.1 of the VPResponse is over-complicated.
* * *
* * * The first three items are overengineering:
* * *
* * *        vpResponseVersion          INTEGER,
* * *        maxCVResponseVersion       INTEGER,
* * *        maxVPResponseVersion       INTEGER,
* * *
* * * Further more they are mandatory. Please delete.
* * *
* * *
* * * 61. Page 52. Section 6 Validation Policy Response
* * *
* * * The ASN.1 of the VPResponse is over-complicated.
* * *
* * *         defaultPolicyID            INTEGER,
* * *
* * * This item does not make sense. When an OID references a validation
* * * policy, there is no concept of versioning. Another version will
simply
* * * get another OID (hopefully in the same branch). Please delete.
* * *
* * *
* * * 62. Page 52. Section 6 Validation Policy Response
* * *
* * * The ASN.1 of the VPResponse is over-complicated.
* * *
* * *        validationPolices          SEQUENCE OF ValidationPolRef,
* * *        validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
* * *
* * * validationAlgs is unnecessary. Please delete.
* * *
* * * validationPolicies (not validationPolices) is the main component.
See
* * * below for a full proposal for restructuring VPResponse.
* * *
* * *
* * * 63. Page 52. Section 6 Validation Policy Response
* * *
* * *        authPolicies               SEQUENCE OF AuthPolicy,
* * *        responseTypes              ResponseTypes,
* * *        dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
* * *
* * * are elements which have nothing to do with the list of validation
* * * policies, and they are mandatory ! Either group them in one
OPTIONAL
* * * item or define another command to get them.
* * *
* * *
* * * 64. Page 52. Section 6 Validation Policy Response
* * *
* * *       defaultPolicyValues        ValidationPolValues,
* * *
* * * This is simply the set of parameters which are related to the
rfc-3280
* * * basic validation policy. This set could be used by other
validation
* * * policies. Please delete.
* * *
* * *
* * * 65. Page 52. Section 6 Validation Policy Response
* * *
* * * What follows is a sketch for a proposal for VPResponse.
* * *
* * *     VPResponse ::= SEQUENCE {
* * *        requestNonce               OCTET STRING      OPTIONAL
* * *        thisUpdate                 GeneralizedTime,
* * *        nextUpdate                 GeneralizedTime   OPTIONAL,
* * *        validationPolicies         SEQUENCE OF ValidationPolicy,
* * *        serverParams               ServerParams      OPTIONAL }
* * *
* * *
* * *     ServerParams ::= SEQUENCE {
* * *        responseTypes              ResponseTypes,
* * *        authPolicies           [0] SEQUENCE OF AuthPolicy
* OPTIONAL,
* * *        dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo
* OPTIONAL,
* * *        clockSkew              [2] INTEGER OPTIONAL }
* * *
* * * Note: it is re-called that ValidationPolicy should be redefined
as:
* * *
* * * ValidationPolicy ::= CHOICE {
* * *      valPolByOID         [0] ValPolByOID,
* * *      valPolByURI         [1] ValPolByURI }
* * *
* * * ValPolByOID  ::= SEQUENCE {
* * *        valPolgId             OBJECT IDENTIFIER,
* * *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* * *
* * * ValPolByURI ::= SEQUENCE {
* * *      uri            IA5String,
* * *      hashAlgo       OBJECT IDENTIFIER,
* * *      hashValue      OCTET STRING}
* * *
* * *
* * *
* * * 66. Page 56. Section 7 SCVP Server Relay
* * *
* * * This section is incomplete and lacking explanations. Please
explain
* how
* * * relaying is achieved.
* * *
* * *
* * * 67. Page 65. Section 9 Security Considerations
* * *
* * * In the second paragraph, there is a discussion about the use of
URIs
* to
* * * reference validation policies.
* * *
* * * Firstly, if URIs are going to stay, a pointer to the security
* * * consideration section should be present in the main body of the
* * * document.
* * *
* * * Secondly, the text should mention the need for the ability to
* * * dereference the URI and the need to compute a hash, while the main
* body
* * * of the document should explain the computation of a hash on the
* content
* * * of the URI.
* * *
* * *
* * * 68. Page 65. Section 9 Security Considerations
* * *
* * * The text states:
* * *
* * *   "It can also do this by using the Diffie-hellman keys to sign
the
* * * request".
* * *
* * * Replace "sign" by "authenticate".
* * *
* * * END OF COMMENTS
* * *
* * *




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGDEmej083912; Thu, 16 Dec 2004 05:14:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGDEmqP083911; Thu, 16 Dec 2004 05:14:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGDEkDf083321 for <[e-mail]>; Thu, 16 Dec 2004 05:14:47 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBGDEYn06255; Thu, 16 Dec 2004 14:14:34 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 16 Dec 2004 14:14:34 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBGDEYQ21947; Thu, 16 Dec 2004 14:14:34 +0100 (MET)
Date: Thu, 16 Dec 2004 14:14:34 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: registration authorities
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> No, just the CA name.
> 
> Steve

Who stop you to do the same thing? 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGCMm9O008376; Thu, 16 Dec 2004 04:22:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGCMmsC008374; Thu, 16 Dec 2004 04:22:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGCMl40008130 for <[e-mail]>; Thu, 16 Dec 2004 04:22:47 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.254.135] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBGCMfjf028865; Thu, 16 Dec 2004 07:22:42 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200704bde72b05f655@[192.168.254.135]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 16 Dec 2004 07:20:23 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Proposed Changes to RFC 3280
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:50 PM +0100 12/10/04, Massimiliano Pala wrote:
>Hello all,
>
>going through rfc3280 and reading the sections 5, 5.1, 5.1.2.5 about
>CRLs and nextUpdate field one idea came into my mind.
>The rfc enforces the use of the nextUpdate field which envisages the
>idea that new revocation information will be available within the
>retained time value.
>
>This could lead to some problems because all clients will query the
>CRL repository upon CRL expiration.
>Moreover, in practical environment, there is the common thought that
>the nextUpdate filed carries the time when new revocation data will
>be available, which (correct me if I am wrong) is not.
>
>So my idea is very simple, indeed. I would suggest to leave the field
>OPTIONAL (as in ASN.1).
>
>If the field is not present, then compliant applications should check
>for new CRL when validating a certificate. This is pretty the same way
>OCSP handles the nextUpdate field within responses, isn't it?
>
>Indeed the default behaviour for today CAs is to issue new CRLs as
>soon as a certificate is revoked - why being forced to issue a new
>CRL if no new data is indeed available ?
>
>Let me know your comments, if there are no major objection I will
>post a possible patch for the document to the list.
>
>--
>
>C'you,
>
>	Massimiliano Pala

The presence of the nextUpdate field allows clients to perform 
background retrieval of CRLs, in anticipation of later use of these 
CRLs in verifying certs. That strategy, if properly implemented, 
reduces the delay seen by the client for cert validation, in a 
CRL-based system.

I agree that it might be the case that a CRL repository might see 
increased traffic if every client tried to retrieve a given CRL at 
the time specified by this field, but whether this proves to be an 
operational problem is another matter.  From what Paul suggested in 
in message, I gather this has not proven to be the case so far. 
Also, I am sensitive to Paul's observation that we not adversely 
affect existing clients who may behave as I noted above.  Finally, 
there is no suggestion in the standard that a CA needs to publish a 
CRL immediately upon determining that a cert needs to be revoked, so 
I do not agree with your suggestion that this is normal behavior for 
CAs today. I know of several very large CAs that definitely do not 
behave in this fashion; they have set intervals for CRL issuance and 
they do not issue CRLs in between those times.

Stefan,

The nextUpdate is NOT an expiration time for a CRL.  CRLs do not 
expire; they are superceded by more recent CRLs that provided info 
that is more current, relevant to a future point in time. This field 
specifies a time and date by which a CA promises that it will make 
available a new CRL, even if there have been no new revocation 
events. As David noted, the field is essential because of the 
untrusted means by which we distribute CRLs. The field is optional in 
X.509 because it was not present in v1 CRLs.  PKIX mandates its use 
because lack of the field creates a serious vulnerability.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGCKZPT004902; Thu, 16 Dec 2004 04:20:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGCKZmC004901; Thu, 16 Dec 2004 04:20:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGCKYPf004761 for <[e-mail]>; Thu, 16 Dec 2004 04:20:35 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.254.135] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBGCKQjj028768; Thu, 16 Dec 2004 07:20:30 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200704bde72b05f655@[192.168.254.135]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 16 Dec 2004 07:20:23 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Proposed Changes to RFC 3280
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:50 PM +0100 12/10/04, Massimiliano Pala wrote:
>Hello all,
>
>going through rfc3280 and reading the sections 5, 5.1, 5.1.2.5 about
>CRLs and nextUpdate field one idea came into my mind.
>The rfc enforces the use of the nextUpdate field which envisages the
>idea that new revocation information will be available within the
>retained time value.
>
>This could lead to some problems because all clients will query the
>CRL repository upon CRL expiration.
>Moreover, in practical environment, there is the common thought that
>the nextUpdate filed carries the time when new revocation data will
>be available, which (correct me if I am wrong) is not.
>
>So my idea is very simple, indeed. I would suggest to leave the field
>OPTIONAL (as in ASN.1).
>
>If the field is not present, then compliant applications should check
>for new CRL when validating a certificate. This is pretty the same way
>OCSP handles the nextUpdate field within responses, isn't it?
>
>Indeed the default behaviour for today CAs is to issue new CRLs as
>soon as a certificate is revoked - why being forced to issue a new
>CRL if no new data is indeed available ?
>
>Let me know your comments, if there are no major objection I will
>post a possible patch for the document to the list.
>
>--
>
>C'you,
>
>	Massimiliano Pala

The presence of the nextUpdate field allows clients to perform 
background retrieval of CRLs, in anticipation of later use of these 
CRLs in verifying certs. That strategy, if properly implemented, 
reduces the delay seen by the client for cert validation, in a 
CRL-based system.

I agree that it might be the case that a CRL repository might see 
increased traffic if every client tried to retrieve a given CRL at 
the time specified by this field, but whether this proves to be an 
operational problem is another matter.  From what Paul suggested in 
in message, I gather this has not proven to be the case so far. 
Also, I am sensitive to Paul's observation that we not adversely 
affect existing clients who may behave as I noted above.  Finally, 
there is no suggestion in the standard that a CA needs to publish a 
CRL immediately upon determining that a cert needs to be revoked, so 
I do not agree with your suggestion that this is normal behavior for 
CAs today. I know of several very large CAs that definitely do not 
behave in this fashion; they have set intervals for CRL issuance and 
they do not issue CRLs in between those times.

Stefan,

The nextUpdate is NOT an expiration time for a CRL.  CRLs do not 
expire; they are superceded by more recent CRLs that provided info 
that is more current, relevant to a future point in time. This field 
specifies a time and date by which a CA promises that it will make 
available a new CRL, even if there have been no new revocation 
events. As David noted, the field is essential because of the 
untrusted means by which we distribute CRLs. The field is optional in 
X.509 because it was not present in v1 CRLs.  PKIX mandates its use 
because lack of the field creates a serious vulnerability.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGCKYaf004870; Thu, 16 Dec 2004 04:20:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGCKYDk004869; Thu, 16 Dec 2004 04:20:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGCKXWc004660 for <[e-mail]>; Thu, 16 Dec 2004 04:20:34 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.254.135] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iBGCKQjf028768; Thu, 16 Dec 2004 07:20:27 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200702bde727b12e9e@[192.168.254.135]>
In-Reply-To: <001401c4e35c$62e5f2f0$[e-mail]>
References: <001401c4e35c$62e5f2f0$[e-mail]>
Date: Thu, 16 Dec 2004 06:53:52 -0500
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: registration authorities
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1108922870==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1108922870==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

At 11:45 AM +0100 12/16/04, Carlos Gonz=E1lez-Cadenas wrote:
>Hi all,
>
>In RFC 3739 (Qualified Certificates Profile), we=20
>do have a place to state the name of the=20
>registration authorities that registered the=20
>names and attributes present in the certificate.
>
>Is there any standard way to do it in non-qualified certificates?
>
>Thanks in advance
>
>Carlos
>

No, just the CA name.

Steve
--============_-1108922870==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: registration authorities</title></head><body>
<div>At 11:45 AM +0100 12/16/04, Carlos Gonz=E1lez-Cadenas
wrote:</div>
<blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">Hi
all,</font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial"
size=3D"-1">&nbsp;</font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">In RFC 3739
(Qualified Certificates Profile), we do have a place to state the name
of the registration authorities that registered the names and
attributes present in the certificate.</font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial"
size=3D"-1">&nbsp;</font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">Is there any
standard way to do it in non-qualified
certificates?</font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial"
size=3D"-1">&nbsp;</font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial" size=3D"-1">Thanks in
advance</font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial"
size=3D"-1"><br></font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial"
size=3D"-1">Carlos</font></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Arial"
size=3D"-1">&nbsp;</font></blockquote>
<div><font size=3D"-1"><b><br></b></font></div>
<div><font size=3D"-1"><b>No, just the CA name.</b></font></div>
<div><font size=3D"-1"><b><br></b></font></div>
<div><font size=3D"-1"><b>Steve</b></font></div>
</body>
</html>
--============_-1108922870==_ma============--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGApL0e066807; Thu, 16 Dec 2004 02:51:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGApLjA066803; Thu, 16 Dec 2004 02:51:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from avir1.bancsabadell.com (tm01.bancsabadell.com [194.224.15.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGApJOS066088 for <[e-mail]>; Thu, 16 Dec 2004 02:51:20 -0800 (PST) (envelope-from [e-mail])
Received: from EFYBEM279076 ([172.18.17.57]) by mail.bancsabadell.com; Thu, 16 Dec 2004 11:45:45 +0100
Reply-To: <[e-mail]>
From: =?iso-8859-1?Q?Carlos_Gonz=E1lez-Cadenas?= <[e-mail]>
To: <[e-mail]>
Subject: registration authorities
Date: Thu, 16 Dec 2004 11:45:40 +0100
Organization: NetFocus
Message-ID: <001401c4e35c$62e5f2f0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C4E364.C4AA5AF0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C4E364.C4AA5AF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




Hi all,

=0D

In RFC 3739 (Qualified Certificates Profile), we do have a place to state
the name of the registration authorities that registered the names and
attributes present in the certificate.

=0D

Is there any standard way to do it in non-qualified certificates?

=0D

Thanks in advance


Carlos

=0D

Carlos Gonz=E1lez-Cadenas

Jefe de Departamento de Arquitectura Software=0D

Software Architecture Department Manager

Responsable de Seguridad de la Informaci=F3n=0D

Information Security Responsible

netfocus
by Siemens-BancSabadell

=0D

=0D

C/Sena, 12 nucli C planta 2
Edifici Landscape
08190 Sant Cugat del Vall=E8s

phone:  [phone]
fax:      [phone]
mailto:  [e-mail]
web:     www.netfocus.es <http://www.netfocus.es/>=0D

=0D



=0D
Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o=
 borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo=
 pena
de incurrir en responsabilidades legales. El emisor no garantiza la=
 integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.

=0D
Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o=
 se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per=
 aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui=
 d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no=
 garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es=
 responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualssevol altres manipulacions que facin tercers.

=0D
Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of=
 the
individual or entity to whom it is addressed. If you are not the intended=
 recipient
and have received this information in error or have accessed it for any=
 reason,
please notify us of this fact by email reply and then destroy or delete the=
 message,
refraining from any reproduction, use, alteration, filing or communication=
 to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the=
 accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.
------=_NextPart_000_0015_01C4E364.C4AA5AF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=
=3Diso-8859-1">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EstiloCorreo17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DES link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>Hi
all,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>In
RFC 3739 (Qualified Certificates Profile), we do have a place to state the=
 name
of the registration authorities that registered the names and attributes
present in the certificate.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>Is
there any standard way to do it in non-qualified=
 certificates?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>Thanks
in advance</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'><br>
Carlos</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DVerdana><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Verdana;font-weight:bold'>Carlos
Gonz=E1lez-Cadenas</span></font></b></st1:PersonName></p>

<p class=3DMsoNormal><st1:PersonName ProductID=3D"Carles Abarca" u1:st=
=3D"on"><font
size=3D1 face=3DVerdana><span lang=3DEN-GB style=
=3D'font-size:9.0pt;font-family:Verdana'></st1:PersonName>Jefe
de Departamento de Arquitectura Software&nbsp;</span></font></p>

<p class=3DMsoNormal><em><i><font size=3D1 face=3DVerdana><span lang=
=3DEN-GB
style=3D'font-size:9.0pt;font-family:Verdana'>Software Architecture=
 Department
Manager</span></font></i></em></p>

<p class=3DMsoNormal><font size=3D1 face=3DVerdana><span lang=3DEN-GB style=
=3D'font-size:
9.0pt;font-family:Verdana'>Responsable de Seguridad de la Informaci=
=F3n&nbsp;</span></font></p>

<p class=3DMsoNormal><em><i><font size=3D1 face=3DVerdana><span lang=
=3DEN-GB
style=3D'font-size:9.0pt;font-family:Verdana'>Information Security=
 Responsible</span></font></i></em><i><font
size=3D1 face=3DVerdana><span lang=3DEN-GB style=
=3D'font-size:9.0pt;font-family:Verdana;
font-style:italic'><br>
</span></font></i><font size=3D1 face=3DVerdana><span lang=3DEN-GB style=
=3D'font-size:
9.0pt;font-family:Verdana'><br>
</span></font><b><font size=3D5 color=3D"#b6ce52"><span lang=3DEN-US
style=
=3D'font-size:20.0pt;color:#B6CE52;font-weight:bold'>netfocus</span></font>=
</b><b><font
size=3D4 color=3D"#0099cc" face=3DVerdana><span lang=3DEN-US style=
=3D'font-size:14.0pt;
font-family:Verdana;color:#0099CC;font-weight:bold'><br>
</span></font></b><font size=3D1 color=3D"#969696"><span lang=3DEN-US
style=
=3D'font-size:7.0pt;color:#969696'>by&nbsp;Siemens-BancSabadell</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3D"#969696" face=3DArial><span=
 lang=3DEN-US
style=3D'font-size:8.0pt;color:#969696'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'line-height:50%'><font size=3D1 face=
=3DVerdana><span
lang=3DEN-US style=
=3D'font-size:9.0pt;line-height:50%;font-family:Verdana'>&nbsp;</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D1 color=3D"#080808" face=3DVerdana><span=
 lang=3DEN-US
style=3D'font-size:7.5pt;font-family:Verdana;color:#080808'>C/Sena, 12=
 nucli C
planta 2<br>
Edifici Landscape<br>
08190 Sant Cugat del Vall=E8s<br>
<br>
</span></font><u><font size=3D1 color=3D"#080808" face=3DVerdana><span lang=
=3DEN-US
style=
=3D'font-size:8.0pt;font-family:Verdana;color:#080808'>phone:</span></font>=
</u><font
size=3D1 color=3D"#080808" face=3DVerdana><span lang=3DEN-US style=
=3D'font-size:8.0pt;
font-family:Verdana;color:#080808'>&nbsp; [phone]<br>
<u>fax:</u>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [phone]<br>
<u>mailto:</u>&nbsp; </span></font><font size=3D1 color=3D"#333399" face=
=3DVerdana><span
lang=3DEN-US style=3D'font-size:8.0pt;font-family:Verdana;color:#333399'><a
href=
=3D"mailto:[e-mail]">[e-mail]</a></span=
></font><font
size=3D1 color=3D"#080808" face=3DVerdana><span lang=3DEN-US style=
=3D'font-size:8.0pt;
font-family:Verdana;color:#080808'><br>
<u>web:</u>&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font size=3D1 color=
=3D"#333399"
face=3DVerdana><span lang=3DEN-US style=
=3D'font-size:8.0pt;font-family:Verdana;
color:#333399'><a href=
=3D"http://www.netfocus.es/">www.netfocus.es</a></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

<table><tr><td bgcolor=3D#ffffff><font color=3D#000000> <br>Advertencia=
 legal:<br>Este mensaje y, en su caso, los ficheros anexos son=
 confidenciales,<br>especialmente en lo que respecta a los datos=
 personales, y se dirigen<br>exclusivamente al destinatario referenciado.=
 Si usted no lo es y lo ha<br>recibido por error o tiene conocimiento del=
 mismo por cualquier motivo, le<br>rogamos que nos lo comunique por este=
 medio y proceda a destruirlo o borrarlo,<br>y que en todo caso se abstenga=
 de utilizar, reproducir, alterar, archivar o<br>comunicar a terceros el=
 presente mensaje y ficheros anexos, todo ello bajo pena<br>de incurrir en=
 responsabilidades legales. El emisor no garantiza la=
 integridad,<br>rapidez o seguridad del presente correo, ni se=
 responsabiliza de posibles<br>perjuicios derivados de la captura,=
 incorporaciones de virus o cualesquiera<br>otras manipulaciones efectuadas=
 por terceros.<br></font></td></tr></table>
<table><tr><td bgcolor=3D#ffffff><font color=3D#000000> <br>Advertiment=
 legal:<br>Aquest missatge i, si escau, els fitxers annexos tenen caire=
 confidencial,<br>especialment pel que fa a les dades personals, i=
 s'adrecen exclusivament al<br>destinatari referenciat. Si no es tracta=
 d'aquest i l'ha rebut per error o se li<br>ha fet arribar per qualsevol=
 motiu, li preguem que ens ho comuniqui per aquesta<br>mateixa via i el=
 destrueixi o l'esborri, i que en tot cas s'abstingui=
 d'utilitzar,<br>reproduir, alterar, arxivar o comunicar a tercers aquest=
 missatge i fitxers<br>annexos, tot sota pena d'entrar en responsabilitats=
 legals. L'emissor no garanteix<br>la integritat, la rapidesa o la=
 seguretat d'aquest correu, ni es responsabilitza<br>de possibles=
 perjudicis derivats de la captura, incorporacions de virus o<br>qualssevol=
 altres manipulacions que facin tercers.<br></font></td></tr></table>
<table><tr><td bgcolor=3D#ffffff><font color=3D#000000>=
 <br>Disclaimer:<br>This message and any attached files transmitted with=
 it, is confidential,<br>especially as regards personal data. It is=
 intended solely for the use of the<br>individual or entity to whom it is=
 addressed. If you are not the intended recipient<br>and have received this=
 information in error or have accessed it for any reason,<br>please notify=
 us of this fact by email reply and then destroy or delete the=
 message,<br>refraining from any reproduction, use, alteration, filing or=
 communication to third<br>parties of this message and attached files on=
 penalty of incurring legal<br>responsibilities. The sender does not=
 guarantee the integrity, the accuracy, the<br>swift delivery or the=
 security of this email transmission, and assumes no<br>responsibility for=
 any possible damage incurred through data capture, virus<br>incorporation=
 or any manipulation carried out by third=
 parties.<br></font></td></tr></table>
------=_NextPart_000_0015_01C4E364.C4AA5AF0--



Received: from 68-189-102-69.ca.charter.com (68-189-102-69.ca.charter.com [68.189.102.69]) by above.proper.com (8.12.11/8.12.9) with SMTP id iBG6DCXp025989; Wed, 15 Dec 2004 22:13:20 -0800 (PST) (envelope-from [e-mail])
Received: from qrs.br5w.net (HELO 6oxpxz) [169.223.181.159] by 68-189-102-69.ca.charter.com with ESMTP id 96D3104CD6B; Thu, 16 Dec 2004 05:12:23 -0100
Message-ID: <z$9$x2yhfvw-hl-$o$z--$[e-mail]>
From: "Administrator" <[e-mail]>
To: [e-mail]
Subject: ADV:      Staff Announcement
Date: Thu, 16 Dec 04 05:12:23 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 5.00.2615.200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="3BAEE_9F__9_38__7.45FA_"

This is a multi-part message in MIME format.

--3BAEE_9F__9_38__7.45FA_
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations: Members and Staff

You Must Respond By 5 P.M. Friday, December 17, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Nonprofit Members and Staff 
who respond to this message before 5 P.M., Friday, December 17, 2004.

All desktop computers are brand-new packed in their original boxes,
and come with a full manufacturer's warranty plus
a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2005
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktops with the latest technology at an amazing price
to all who call:

    1-800-795-8466 by 5 P.M. Friday, December 17, 2004

The fast and powerful AT-2800 series Desktop features: 

      * Intel 2.0Ghz Processor for amazing speed and performance
      * 128MB DDR RAM,  -- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB
      * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW
      * Next Generation 2005 Technology
      * Premium video and sound -- For enhanced colors and graphics
      * Full Connectivity with Fax modem/Lan/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $499 ........................................ Your Cost $257

How to qualify:

  1. You must be a Member, Staff or Associate of a Nonprofit.
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-795-8466 by 5 P.M. Friday, December 17, 2004.
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.
  6. Ask for Department C.
   
   
Call Avtech Direct
1-800-795-8466 before 5 P.M. Friday, December 17, 2004


Visit our website at http://www.avtechcomputers.com


If you wish to unsubscribe from this list, please go to
http://www.avtechcomputers.com/announcements.asp



Avtech Direct
22647 Ventura Blvd. Suite 374
Woodland Hills, CA 91364
--3BAEE_9F__9_38__7.45FA_--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBG02Bc1045634; Wed, 15 Dec 2004 16:02:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBG02BAm045633; Wed, 15 Dec 2004 16:02:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBG02BHx045594 for <[e-mail]>; Wed, 15 Dec 2004 16:02:11 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 15 Dec 2004 16:02:09 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 15 Dec 2004 16:01:57 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Wed, 15 Dec 2004 16:02:02 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTbfdnnQM8sCGUwQ1+o/ms74r26bABGmo+wAZn7R1A=
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Dec 2004 00:01:57.0532 (UTC) FILETIME=[759475C0:01C4E302]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBG02BHx045628
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here is 17-22
Trevor

* -----Original Message-----
* From: Trevor Freeman
* Sent: Tuesday, December 07, 2004 12:47 PM
* To: 'Denis Pinkas'
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* Hi Denis,
* Below are responses to 1-16. Others will follow later.
* Trevor
* 
* * -----Original Message-----
* * From: Denis Pinkas [mailto:[e-mail]]
* * Sent: Monday, December 06, 2004 2:25 AM
* * To: Trevor Freeman
* * Cc: [e-mail]
* * Subject: Re: SCVP 16 comments deadline
* *
* * Trevor,
* *
* * > The deadline communicated at the DC meeting for making comments on
* SCVP
* * > 16 was Nov 30th which has now passed. I have had only three people
* send
* * > me comments to date. SCVP 17 will be closing very shortly so this
is
* the
* * > last reminder.
* *
* * Thank for the remainder. I missed the initial announcement.
* * My comments are below.
* *
* *
* * 1. Typo. There are two IPR statements related to RFC 3668 on the
first
* * page. Delete one.
* *
* * " By submitting this Internet-Draft, I certify that any applicable
* *    patent or other IPR claims of which I am aware have been
disclosed,
* *    or will be disclosed, and any of which I become aware will be
* *    disclosed, in accordance with RFC 3668".
* [TF] Fixed
* *
* *
* * 2. Page 11. Typos. First paragraph on top of the page.
* * Replace "signers" by "signer's".
* [TF] Fixed
* *
* *
* * 3. Page 11. Typo. First paragraph on top of the page. Last sentence.
* * Replace "certificate" by "certificates".
* [TF] Fixed
* *
* *
* * 4. Page 13. Typo. Section 3.1.2 "checks"
* * The two following lines are in fact one line:
* *
* * Change:
* *
* *      - Build a validated certification path to a trust anchor; and
* *
* *      - Do revocation status checks on the certification path.
* *
* * into:
* *
* *      - Build a validated certification path to a trust anchor and
* *        do revocation status checks on the certification path.
* *
* [TF] Since this paragraph is listing the possible checks and building
a
* path is a separate check to revocation checking, I think the current
text
* is more accurate.
* *
* * 5. Page 15. Typo. Section 3.1.4 validationPolicy
* *
* * This is the error left intentionally by the editor to know who read
the
* * document. The following sentence is duplicated: " The
validationPolicy
* * item, defines the validation policy". Please delete one sentence.
* [TF] Just checking <g> Fixed
* *
* *
* * 6. Page 24. Typo. Section 3.1.5.9 keyUsages
* *
* * Change "keyUasge" into "keyUsage".
* [TF] Fixed
* *
* *
* * 7. Page 27. Typo. Section 3.1.8 valididationTime
* * Last line of the first paragraph. Change "servers" into "server's"
* [TF] Fixed
* *
* *
* * 8. Page 32. Typo. Section 3.5 dhPublicKey
* * Change: Diffie-Hellamn into Diffie-Hellman.
* [TF] Fixed
* *
* *
* * 9. Page 32. Typo. Section 3.5 dhPublicKey
* * Fifth line. Change "an does" into "and does"
* [TF] Fixed
* *
* *
* * 10. Page 32. Typo. Section 3.5 dhPublicKey
* * Delete: (see section Error! Reference source not found.)
* *
* *
* * 11. Page 33. Typo. Section 4. Validation Response
* *
* * After the eight items. The following sentence has a grammar problem:
* *   "Successful responses are be made when the server has fully
complied
* *    with the request".
* [TF] Deleted the "be"
* *
* *
* * 12. Page 52. Typo. Section 6 Validation Policy Response
* *
* * The second sentence is incorrect. It is:
* * The valPolResponse MAY not unique to any valPolRequest, ..."
* *
* * Change into:
* * "The valPolResponse MAY not be unique to any valPolRequest, ..."
* [TF] Fixed
* *
* *
* * 13. The abstract does not reflect accurately the content of the
* * document.
* * "certificate handling" is too vague.
* *
* * Proposed abstract:
* *
* *    SCVP allows a client to delegate certificate path construction
and
* *    certificate path validation to a server. The path construction or
* *    validation (i.e. making sure that none of the certificates of the
* *    path is revoked) is made according to a validation policy which
* *    contains one or more trust anchors. It allows to simplify client
* *    implementations and to use a set of predefined validation
policies.
* [TF] Suggested text substituted
* *
* *
* * 14. Section 1.3
* *
* * The text on validation policy is new. There is no concept of
"mutually
* * agreed" validation policy between the client on the server. The
server
* * supports a set of validation policies which may or may not fit the
need
* * of the client.
* *
* * Change the second sentence of section 1.3 which is:
* *
* * " In SCVP, a validation policy can be either mutually
* *    agreed between client and server, and subsequently referenced in
* *    request, or explicitly expressed in the request by passing all of
* *    the necessary parameters."
* *
* * into:
* *
* * " In SCVP, the validation policy to be used by the server can be
either
* * fully referenced in the request by the client (and thus no
additional
* * parameter is necessary), referenced in the request by the client
with
* * additional parameters or supported by default by the server if the
* * client does not reference it."
* [TF] Suggested text substituted
* *
* *
* * 15. Section 1.3. The second paragraph needs to be reworded.
Currently,
* * it is the following:
* *
* * " Policy definitions can be quite long and complex, and some
policies
* *    may allow for the setting of a few parameters such as a set of
* *    trust anchors.  The request can therefore be simplified if these
* *    previously agreed policy dependent parameters are referenced in
the
* *    request by a mutually agreed OBJECT IDENTIFIER (OID) or URL
value.
* *    The referenced value indicates either a partial or full set of
* *    parameters. The client can therefore omit these agreed parameters
* *    from the request, only passing any parameters which are not
* *    specified by the previously agreed policy.  Therefore in the
* *    simplest form, with validation polices which define every
parameter
* *    necessary, a SCVP request need only contain the certificate to be
* *    validated, the validation policy and any run-time parameters for
* *    the request".
* *
* * Proposed rewording:
* *
* * " Policy definitions can be quite long and complex, and some
policies
* *    may allow for the setting of a few parameters.  The request can
* *    therefore be very simple if OBJECT IDENTIFIERS (OIDs) are used to
* *    specify both the algorithm to be used and all the associated
* *    parameters of the validation policy. The request can be more
complex
* *    if the validation policy fixes many of the parameters but allows
the
* *    client to specify some of them. When the validation policy
defines
* *    every parameter necessary, a SCVP request needs only to contain
the
* *    certificate to be validated, the referenced validation policy and
any
* *    run-time parameters for the request. In its simplest form, a SCVP
* *    request contains the certificate to be validated and any run-time
* *    parameters for the request. In that case the server uses a
default
* *    validation policy".
* [TF] Suggested text substituted
* *
* *
* * 16. Section 1.3. Paragraph 3.
* *
* * The text is missing the fact that at least one validation policy
must
* * be supported by the server. This is the default policy which is used
* * when the client omits to specify it.
* *
* * The current text is the following:
* *
* *   "SCVP server also publishes its default validation policy
settings.
* *    The default policy can be requested for validation and the client
* *    can override any default value in the request if required.  The
* *    default values are also used when processing requests which
* *    reference a validation policy other than the default one that
does
* *    not contain the full set of parameters necessary for validation
and
* *    the client has also omitted the missing values in the request.
* *
* *    Therefore a client can also simplify the request by omitting a
* *    parameter from a request if the default value published by the
* *    server is acceptable".
* *
* * Replace it with:
* *
* * " A SCVP server must support a default validation policy which will
* *    be used if the client does not specify any in its request. A
server
* *    publishes the references of the validation policies it supports.
* *    When these policies have parameters that may be overridden, the
* *    default value for these parameters are communicated by the server
as
* *    well. The client can simplify the request by omitting a parameter
* *    from a request if the default value published by the server for a
* *    given validation policy reference is acceptable. However if there
is
* *    a desire to demonstrate to someone else that a specific
validation
* *    policy with all its parameters has been used, it will need to ask
the
* *    server for the inclusion of the full validation policy with all
the
* *    parameters in the response".
* [TF] Suggested text substituted
* *
* *
* * 17. On top of page 7, the relationship between the validation policy
* * and the basic certification path algorithm is not explained. Then in
* * section 1.4 The concept of validation algorithm is introduced but
its
* * relationship with the validation policy is not explained. This is
* * confusing.
* *
* * Later on when observing the ASN.1 syntax it may be discovered that
two
* * OIDs are being used:
* *
* *   - one for the validation policy (ValidationPolRef) and
* *   - one for the validation algorithm (ValidationAlg).
* *
* * This is overcomplicated and unnecessary.
[TF] Is there a specific issue with the current draft such as a scenario
which is not addressed?
* *
* * An important simplification is obtained if, as the previous text
* * states, there is an OID to defined the validation policy and there
may
* * be or may not be additional parameters.
* *
* * We could then have:
* *
* * valPolByOID::= SEQUENCE {
* *        valPolId              OBJECT IDENTIFIER,
* *        parameters            ANY DEFINED BY ValPolId OPTIONAL }
* *
* * Specifying a path processing compliant with section 6.1 of RFC 3280
* * would be possible (notice however that the text from RFC 3280 is too
* * vague to support the case where a CRL is not signed by the CA).
* *
* * It would be desirable to be able to communicate easily and in a
* * standard way the parameters that may be set in section 6.1 from RFC
* * 3280. In addition, key usage should be added to that list.
* *
* * The document should then define a bundle of all these previous
useful
* * parameters and allow for the addition of other parameters.
* *
* * It is thus proposed to define an OID for a validation policy
compliant
* * with section 6.1 of RFC 3280 (some differences with section 6 from
* * 3280bis, i.e. adding precision, may be expected)
* *
* * It is thus proposed to modify the text starting from :
* *
* * " The inputs to the basic certification path processing algorithm
* *    used by SCVP are defined by [PKIX-1] in section 6.1.1 and
comprise"
* *    up to the end of section 1.3 with the following:
* *
* * "For clients able to specify the parameters of a validation policy,
it
* * may be useful to define a standard data structure (using a bundle)
able
* * to support the parameters of the basic certification path processing
* * algorithm defined by in section 6.1.1 from [PKIX-1] :
* *
* *   - a set of Trust Anchors (by value or by reference),
* *   - the initial Certificate Policy set,
* *   - initial Certificate Policy mapping setting,
* *   - initial any-Policy setting,
* *   - initial explicit Certificate Policy setting.
* *
* * as well as :
* *
* *    - the usage of the key contained in the certificate (e.g., key
* *      encipherment, key agreement, signature)
* *
* * This will be done using a bundle which encapsulates all these
* * parameters.
* *
* * Other application-specific purposes parameters may be added".
* *
* *
* * 18. Section 1.4 is about a "Validation Algorithm". Given what was
said
* * before, the header of this section should be changed. If we make a
* * subsection 1.3.1 called "1.3.1. General" for encapsulating the
* previous
* * text, then we can introduce a new section 1.3.2 called:
* *
* * "1.3.2. Validation policy according to section 6.1 of RFC 3280"
[TF] See comment to 17
* *
* * Some of the text present in the current section 1.4 has been used to
* * build the new text that is proposed below:
* *
* * "1.3.2. Validation policy according to section 6.1 of RFC 3280
* *
* *    SCVP defines a specific validation policy which implements the
* *    certification path validation algorithm as defined in section 6.1
of
* *    [PKIX-1]. This specific validation policy, called "rfc-3280 basic
* *    validation policy" uses the parameters defined in the bundle
* *    mentioned above.
* *
* *    Note that this algorithm does not support in its full generality
the
* *    algorithm described in section 6.2 of [PKIX-1] since, when more
than
* *    one trust anchor is being defined, all the conditions that are
* *    specified apply to all trust anchors, whereas section 6.2 allows
to
* *    have different conditions for every trust anchor.
* *
* *    The rfc-3280 basic validation policy may be the default
validation
* *    policy supported by the server, but does not need to".
* *
* *
* * 19. Section 2 "Protocol Overview"
* *
* * In order to allow for interoperability and testing a common protocol
* * needs to be supported. It should be defined.
[TF] There is plenty of precedence for this to be in a separate
document. CMS itself just defines the syntax.
* *
* *
* * 20. Section 3 "Validation Request"
* *
* * The unsigned request form is not explained and there is a confusion
for
* * the signed request which indeed authenticates the client and is thus
* * not anonymous. The current text is :
* *
* *    "A signed
* *    request is used to authenticate the client to the server or to
* *    provide an anonymous client integrity over the request-response
* *    pair."
* *
* * It should be rephrased as:
* *
* *    "An unsigned request provides an anonymous client integrity over
* *     the request since the hash of the request or the full request is
* *     incorporated in the response. A signed request is used to
* *     authenticate the client to the server".
[TF] Since by definition the anonymous client has to sign the request as
well this does not make sense. A server can also return a cached
response in which case there is no hash of the request in the response.
How about

An anonymous client signs the request to provide integrity over
the request. A identifiable signs the request to authenticate itself to
the server.




* *
* *
* * 21. Page 13. Section 3.1.2 "checks"
* *
* * The following sentence adds nothing and should be removed:
* *
* *    "A server may still choose to
* *    perform revocation status checks when performing path
construction,
* *    although this information cannot be returned to the client."
[TF] I think it reinforces that with some checks, don't require
revocation status checking but a server may still elect to do so.
* *
* *
* * 22. Page 15. Section 3.1.3 "wantBack"
* *
* * The text states:
* *
* *      - Proof of revocation status for each certificate in the AC
* *         issuer certification path;
* *
* * It would be important to refer the section of the RFC which explains
* * how to
* * check the "revocation status for each certificate in the AC issuer
* * certification path".
[TF] OK, I will add a reference to 3281 section 5.
* *
* *
* * 23. Page 15. Section 3.1.3 "wantBack"
* *
* * The text states:
* *
* *    The client can also request a non-cached response to the request
by
* *    including wantback id-swb-non-cached-resp in the request.
* *
* * The default behavior should be the reverse: fresh information is
* * provided, unless the client accept cached information. The item
should
* * be changed into:
* * id-swb-cached-resp
* *
* *
* * 24. Page 15. Section 3.1.3 "wantBack"
* *
* * The text states:
* *
* * id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
* *
* * It should be mentioned that this item is only possible for DPD.
* *
* *
* * 25. Page 16. Section 3.1.4 validationPolicy
* *
* * The following sentence is talking of an agreement whereas such
* * agreement does not exist. Delete the sentence:
* *
* *   "The client and server can optionally agree on a set of parameters
* *    which may fully or partially define a validation policy".
* *
* *
* * 26. Page 16. Section 3.1.4 validationPolicy
* * The text states:
* *
* *    "If a partial set of parameters has been agreed upon,
* *    then the client supplies a reference to the policy plus whatever
* *    parameters are necessary to complete the request in this item.
* *
* * This should be replaced with:
* *
* *    "If the validation policy does not define all parameters
necessary
* *    for processing an SCVP request, then the client need to supply
these
* *    parameters".
* *
* * 27. Page 16. Section 3.1.4 validationPolicy
* *
* *    The syntax of the validationPolicy item is defined as:
* *
* *    ValidationPolicy ::= SEQUENCE {
* *      validationPolRef          ValidationPolRef,
* *      validationAlg         [0] ValidationAlg OPTIONAL,
* *      userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
* *                                  IDENTIFIER OPTIONAL,
* *      inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* *      requireExplicitPolicy [3] BOOLEAN OPTIONAL,
* *      inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
* *      isCA                  [5] BOOLEAN OPTIONAL,
* *      trustAnchors          [6] TrustAnchors OPTIONAL,
* *      keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
* *                                   OPTIONAL,
* *      extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}
* *
* *
* * This structure is quite odd, because it only allows to pass
additional
* * parameters as parameters of the validationAlg. Suppressing the
* * validationAlg item add adding validationParamExtensions would be a
* * simpler and cleaner way.
* *
* * Each validation policies uses its own parameters.
* * We should have something like :
* *
* * ValPolByOID  ::= SEQUENCE {
* *        valPolgId             OBJECT IDENTIFIER,
* *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* *
* * More details follow.
* *
* *
* * 28. It is highly debatable if URIs should be supported or not to
* * reference a validation policy. URIs are not stable over time and
thus
* * unless there are dereferenced and a hash value is computed over
them,
* * it is insecure to use them. There is a discussion in the security
* * consideration section, but no warning and no pointer here. If we
keep
* * them, we should warn the user.
* *
* * If the WG should decides that they should be supported (and if the
IESG
* * agrees) on page 17, the ASN.1 description should then be:
* *
* * ValidationPolicy ::= CHOICE {
* *      valPolByOID         [0] ValPolByOID,
* *      valPolByURI         [1] ValPolByURI }
* *
* * ValPolByOID  ::= SEQUENCE {
* *        valPolgId             OBJECT IDENTIFIER,
* *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* *
* * ValPolByURI ::= SEQUENCE {
* *      uri            IA5String,
* *      hashAlgo       OBJECT IDENTIFIER,
* *      hashValue      OCTET STRING}
* *
* *
* * 29. It is proposed to define the following bundle:
* *
* * ValidationParamBundle ::= SEQUENCE {
* *      certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF OBJECT
* *                                    IDENTIFIER OPTIONAL,
* *      inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
* *      requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
* *      inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
* *      isCA                      [4] BOOLEAN OPTIONAL,
* *      trustAnchors              [5] TrustAnchors OPTIONAL,
* *      keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF
KeyUsage
* *                                    OPTIONAL,
* *      extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
* *      extensions                [8] EXPLICIT Extensions OPTIONAL }
* *
* * Note that userPolicySet" is unclear and has been changed into
* * "certificatePolicySet".
* *
* * The text would need to be aligned with the new structure and, of
course
* * the parameters of the rfc-3280 basic validation policy will simply
* * include the bundle above as its parameters.
* *
* * It should also be mentioned somewhere in the document that the
support
* * of the rfc-3280 basic validation policy is not mandatory for
* * conformance but, if supported then the bundle needs to be supported.
* *
* *
* * 30. Page 17. Section 3.1.5 validationAlg should be deleted.
* *
* *
* * 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
* * deleted and replaced by a section later on the "rfc-3280 basic
* * validation policy", which should have its OID defined under the scvp
* * tree for OIDs.
* *
* *
* * 32. Page 17. Section 3.1.5.1. Some text of this section might be re-
* * sued to build a new section on the rfc-3280 basic validation policy.
* * Note that the last sentence at the bottom of page 17, should be
* * removed. This sentence is: "The default validation policy MUST use
the
* * basic validation algorithm". Any default validation policy can be
used.
* *
* *
* * 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
* * should be as well deleted.
* *
* *
* * 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
* *
* * This goal of this section seems to introduce an additional test to
the
* * basic "rfc-3280 basic validation policy". It would come naturally as
* an
* * extension of ValidationParamBundle, rather than as a parameter of
the
* * validationAlgo which has been proposed to be removed. The text
should
* * be modified accordingly.
* *
* *
* * 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
* *
* *      NameValidationAlgParms ::= SEQUENCE {
* *        keyPurposeId      KeyPurposeId,
* *        validationNames   GeneralNames }
* *
* * This construct is artificial since KeyPurposeId is about the
Extended
* * Key Usage and has nothing to do with name validation.
* *
* * It could indeed be interesting to test the Extended Key Usage
extension
* * of a certificate, but this should be supported as an extension of
* * ValidationParamBundle. The text should be modified accordingly.
* *
* *
* * 36. Page 22. Section 3.1.5.3 userPolicySet
* *
* * userPolicySet should be changed everywhere into
certificatePolicySet.
* *
* *
* * 37. Page 22. Section 3.1.5.3 userPolicySet
* *
* * The text has many sentences like:
* *
* *    SCVP clients SHOULD support userPolicySet item in requests, and
* *    SCVP servers MUST support userPolicySet item in requests.
* *
* * These requirements only apply for the rfc-3280 basic validation
policy,
* * and this should be clearly mentioned.
* *
* *
* * 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
* *
* * The text states:
* *
* *    By default the server allows policy mapping as
* *    part of certification path validation.
* *
* * For simplicity, this should be the reverse. Replace with:
* *
* *   "By default the server does not perform policy mapping as
* *    part of certification path validation. If the client wants the
* *    server to support policy mapping, allowPolicyMapping must be set
* *    to TRUE in the request".
* *
* *
* * 39. Page 24. Section 3.1.5.8 trustAnchors
* *
* * The text states:
* *
* *   "A certificate reference can be used to identify the
* *    trust anchor by certificate hash and optionally a distinguished
* *    name with serial number".
* *
* * This is not consistent with the ASN.1 definition of PKCReference
which
* * is:
* *
* *    PKCReference ::= CHOICE {
* *      cert                   [0] Certificate,
* *      pkcRef                 [1] ESSCertID }
* *
* * Please correct.
* *
* *
* * 40. Page 25. Section 3.1.6 responseRefHash
* *
* * The text states:
* *
* *    "By default, the server includes a hash
* *    of the request in the response.  If the client wants the server
to
* *    include the full request in the response, responseRefHash is set
to
* *    FALSE."
* *
* * The server shall always include a hash of the request in the
response.
* * This is an easy way to allow to test the integrity of the request.
* * Since the full description of the validation policy may be much
longer
* * a flag should be used to say that the full validation policy is not
* * returned unless requested. It is thus proposed to have instead the
* * following:
* *
* * "3.1.6.1 fullRequestInResponse
* *
* *    The fullRequestInResponse controls if the client wants the server
* *    to include the full request in the response. By default,
* *    fullRequestInResponse is set to FALSE. If the client wants back
* *    the full request then it must set this parameter to TRUE. The
main
* *    reason a client would request the server to include the full
request
* *    in the response is to archive the request-response exchange in a
* *    single object.  That is, the client wants to archive a single
object
* *    which includes both request and response".
* *
* *
* * 41. Page 26. Section 3.1.6.2 responseValidationPolByRef
* *
* * This item should be renamed: fullValPolInResponse
* *
* * The text should be changed into:
* *
* * "The fullValPolInResponse controls whether the response includes the
* * identifier of the validation policy with all the parameters that
have
* * been used by the server, i.e. all the variable parameters
independent
* * from the fact that there were specified by the client or defaulted
if
* * not specified. By default, fullValPolInResponse is set to FALSE. If
the
* * client wants the full validation policy to be included, then
* * fullValPolInResponse is set to TRUE. The main reason a client would
* * request the server to include validation policy to be included by
value
* * is to archive the request-response exchange in a single object. That
* * is, the client wants to archive the CVResponse and have it include
* * every aspect of the validation policy."
* *
* * The ResponseFlags should be changed as follows:
* *
* *    ResponseFlags ::= SEQUENCE {
* *      fullRequestInResponse      BOOLEAN DEFAULT FALSE,
* *      fullValPolInResponse       BOOLEAN DEFAULT FALSE,
* *      signResponse               BOOLEAN DEFAULT TRUE }
* *
* *
* * 42. Page 28. Section 3.1.9 intermediateCerts. Minor.
* *
* * Change:
* *
* *    The optional intermediateCerts item helps the SCVP server create
* *    valid certification paths.
* *
* * into:
* *
* *    The optional intermediateCerts item may help the SCVP server to
* * create
* *    valid certification paths.
* *
* * 43. Page 29. Section 3.1.11. producedAt
* *
* * Last sentence. Change:
* *
* *    SCVP server SHOULD support the producedAt values in the request.
* *
* * into:
* *
* *    SCVP server MAY support the producedAt values in the request.
* *
* * Reason: cached responses should not need to be implemented in order
to
* * be compliant with the specification.
* *
* *
* * 44. Page 32. Section 3.5 dhPublicKey
* *
* * The text states:
* *
* *   "For the server to compute the shared
* *    secret, it must lean the public values the client generates,
* *    therefore the client MUST include this in the request if it uses
* *    this mechanism to integrity protect the request-response pair."
* *
* * Replace:
* *
* * "to integrity protect the request-response pair"
* *
* * with :
* *
* * "to authenticate and integrity protect the first response and
* * authenticate and integrity protect subsequent request-response
pairs".
* *
* * 45. Page 32. Section 3.6 SCVP Request Authentication
* *
* * The text states:
* *
* *   "It is a matter of local policy what validation policy is used by
* *    the server when validating requests".
* *
* * This sentence could be misinterpreted because the word "validating"
is
* * being used. Change into:
* *
* *    It is a matter of local policy what validation policy is used by
* *    the server when authentication requests".
* *
* *
* * 46. Page 35. Section 4. Validation Response
* *
* *    The CVResponse is defined as follows:
* *
* *      CVResponse ::= SEQUENCE {
* *        cvResponseVersion         cvResponseVersion        INTEGER,
* *        policyID                  INTEGER,
* *        producedAt                GeneralizedTime,
* *        ....
* *
* * On the next page the test states:
* *
* *   "The policy ID used by the SCVP server when it processed the
request.
* *    See section 6.4 for details."
* *
* * In section 6.4 the text states:
* *
* * "6.4 defaultPolicyID
* *
* *    An integer that uniquely represents the version of the default
* *    validation policy as represented by the trustAnchors, ..."
* *
* * This is not understandable, over-engineering and very complicated.
* * Please delete this item.
* *
* *
* * 47. Page 35. Section 4. Validation Response
* *
* *    The CVResponse contains:
* *
* *        requestRef            [1] RequestReference OPTIONAL,
* *
* * Remove "OPTIONAL" since it is very beneficial to mandate this item
* * since it allows to make sure that the request has not be modified if
* * the response is integrity protected. The computation is fast and
easy
* * and the hash value does not overload the response.
* *
* *
* * 48. Page 38. Section 4.5 respValidationPolicy
* *
* * The definition of this item is overcomplicated and not tailored to
* * support any kind of validation policy.
* *
* * If the client does not specify the validation policy or if the
client
* * specifies a validation policy which has default parameters, then the
* * full description of the validation policy shall be given back.
* *
* * If the client specifies a validation policy which has no default
* * parameters, then the reference and parameters, if any, of the
* * validation policy are in the request.
* *
* * The full description of the validation policy shall be given back in
* * any case, if the fullValPolInResponse Boolean in ResponseFlags is
set.
* *
* * respValidationPolicy :: = ValidationPolicy
* *
* *
* *
* * 49. Page 41. Section 4.6 requestRef
* *
* * As stated earlier, requestRef should be mandatory and always be a
hash
* * of the request.
* *
* * In addition a fullRequest OPTIONAL parameter should be added as an
* * optional item for CVResponse.
* *
* * The full description of the validation policy shall be given back in
* * any case, if the fullRequestInResponse Boolean in ResponseFlags is
set.
* *
* * Change the text and the syntax accordingly.
* *
* *
* * 50. Page 41. Section 4.6 requestRef
* *
* * The text states:
* *
* *    "The requestRef item allows the client to associate a response
with
* *    a request"
* *
* * This is wrong. This does not protect against a replay.
* *
* * Change with:
* *
* * "When the response is authenticated, the requestRef item allows the
* * client to make sure that the request was not modified in transit".
* *
* *
* * 51. Page 41. Section 4.6 requestRef
* *
* * The text states:
* *
* * " The requestNonce provides an alternative mechanism for
* *    matching requests and responses if the client has selected to
* *    include a full response."
* *
* * This is wrong. This is not an alternative for matching requests and
* * responses.
* *
* * Replace with:
* *
* *   "The requestNonce allows to protect against replay, even if time
* * synchronization is not good between the client and the server".
* *
* *
* * 52. Page 42. Section 4.6.1 requestHash
* *
* * The text states:
* *
* * " The requestNonce provides an alternative mechanism for matching
* * requests and responses".
* *
* * This is wrong. See above. Delete.
* *
* *
* * 53. Page 45. Section 4.10.4 replyChecks
* *
* * ReplyCheck is defined as:
* *
* *      ReplyCheck ::= SEQUENCE {
* *        check                      OBJECT IDENTIFIER,
* *        status                     INTEGER }
* *
* * It should be defined as:
* *
* *      ReplyCheck ::= SEQUENCE {
* *        check                      OBJECT IDENTIFIER,
* *        status                     INTEGER DEFAULT 0}
* *
* *
* * 54. Page 46. Section 4.10.4 replyChecks
* *
* * The text states
* *
* *    "The status value for public key certification path building to a
* *    trusted root along with complete status checking, { id-stc 3 },
can
* *    be one of the following:
* *
* *        0: Good
* *        1: Revoked
* *        2: Revocation Offline
* *        3: Revocation Unavailable
* *
* * It is unclear to understand the benefits that a client can have from
* * the difference between "Revocation Offline" and "Revocation
* * Unavailable". In addition, these wordings do not match the
explanations
* * of what there are.
* *
* * A much more important response is missing: suspended. Suspended is a
* * variation of revoked, but the client then knows it may attempt
another
* * try later on.
* *
* * It is thus suggested to change it into:
* *
* *        0: Good
* *        1: Revoked
* *        2: Suspended
* *        3: Revocation info unavailable"
* *
* *
* * 55. Page 46. Section 4.10.4 replyChecks
* *
* *
* * The same comment applies for the status value for AC issuer
* * certification path.
* *
* *
* * 56. Page 48. Section 4.10.6 validationAlg
* * For reasons given before, delete validationAlg.
* *
* *
* * 57. Page 48. Section 4.10.8 nextUpdate
* *
* * If CRLs are used, should this field contain the value of the next
* * update field for the smallest value of all the CRLs ? What is the
real
* * benefit of supporting this element besides added complexity ? It is
* * suggested to delete that item.
* *
* *
* * 58. Page 49. Section 4.11 responseNonce
* *
* * The text states:
* *
* * "The responseNonce item contains an identifier to binds the request
* * to the response."
* *
* * This is incorrect. The nonce is to detect replay.
* *
* * Change into:
* *
* * "The responseNonce item contains a unique number which allows to
detect
* * replay".
* *
* *
* * 59. Page 51. Section 5 Server Policy Request
* *
* * The text states:
* *
* *   "A SCVP client uses the valPolRequest item to request the list of
* *    validation policies supported by the SCVP server."
* *
* * This is not a correct description of what this request is doing.
When
* * looking at the ASN.1 it is doing much more. So the question is
whether
* * two requests should be provided or one. In the later case, it is
* * important to advertise correctly what the request is doing.
* *
* *
* * 60. Page 52. Section 6 Validation Policy Response
* *
* * The ASN.1 of the VPResponse is over-complicated.
* *
* * The first three items are overengineering:
* *
* *        vpResponseVersion          INTEGER,
* *        maxCVResponseVersion       INTEGER,
* *        maxVPResponseVersion       INTEGER,
* *
* * Further more they are mandatory. Please delete.
* *
* *
* * 61. Page 52. Section 6 Validation Policy Response
* *
* * The ASN.1 of the VPResponse is over-complicated.
* *
* *         defaultPolicyID            INTEGER,
* *
* * This item does not make sense. When an OID references a validation
* * policy, there is no concept of versioning. Another version will
simply
* * get another OID (hopefully in the same branch). Please delete.
* *
* *
* * 62. Page 52. Section 6 Validation Policy Response
* *
* * The ASN.1 of the VPResponse is over-complicated.
* *
* *        validationPolices          SEQUENCE OF ValidationPolRef,
* *        validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
* *
* * validationAlgs is unnecessary. Please delete.
* *
* * validationPolicies (not validationPolices) is the main component.
See
* * below for a full proposal for restructuring VPResponse.
* *
* *
* * 63. Page 52. Section 6 Validation Policy Response
* *
* *        authPolicies               SEQUENCE OF AuthPolicy,
* *        responseTypes              ResponseTypes,
* *        dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
* *
* * are elements which have nothing to do with the list of validation
* * policies, and they are mandatory ! Either group them in one OPTIONAL
* * item or define another command to get them.
* *
* *
* * 64. Page 52. Section 6 Validation Policy Response
* *
* *       defaultPolicyValues        ValidationPolValues,
* *
* * This is simply the set of parameters which are related to the
rfc-3280
* * basic validation policy. This set could be used by other validation
* * policies. Please delete.
* *
* *
* * 65. Page 52. Section 6 Validation Policy Response
* *
* * What follows is a sketch for a proposal for VPResponse.
* *
* *     VPResponse ::= SEQUENCE {
* *        requestNonce               OCTET STRING      OPTIONAL
* *        thisUpdate                 GeneralizedTime,
* *        nextUpdate                 GeneralizedTime   OPTIONAL,
* *        validationPolicies         SEQUENCE OF ValidationPolicy,
* *        serverParams               ServerParams      OPTIONAL }
* *
* *
* *     ServerParams ::= SEQUENCE {
* *        responseTypes              ResponseTypes,
* *        authPolicies           [0] SEQUENCE OF AuthPolicy
OPTIONAL,
* *        dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo
OPTIONAL,
* *        clockSkew              [2] INTEGER OPTIONAL }
* *
* * Note: it is re-called that ValidationPolicy should be redefined as:
* *
* * ValidationPolicy ::= CHOICE {
* *      valPolByOID         [0] ValPolByOID,
* *      valPolByURI         [1] ValPolByURI }
* *
* * ValPolByOID  ::= SEQUENCE {
* *        valPolgId             OBJECT IDENTIFIER,
* *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* *
* * ValPolByURI ::= SEQUENCE {
* *      uri            IA5String,
* *      hashAlgo       OBJECT IDENTIFIER,
* *      hashValue      OCTET STRING}
* *
* *
* *
* * 66. Page 56. Section 7 SCVP Server Relay
* *
* * This section is incomplete and lacking explanations. Please explain
how
* * relaying is achieved.
* *
* *
* * 67. Page 65. Section 9 Security Considerations
* *
* * In the second paragraph, there is a discussion about the use of URIs
to
* * reference validation policies.
* *
* * Firstly, if URIs are going to stay, a pointer to the security
* * consideration section should be present in the main body of the
* * document.
* *
* * Secondly, the text should mention the need for the ability to
* * dereference the URI and the need to compute a hash, while the main
body
* * of the document should explain the computation of a hash on the
content
* * of the URI.
* *
* *
* * 68. Page 65. Section 9 Security Considerations
* *
* * The text states:
* *
* *   "It can also do this by using the Diffie-hellman keys to sign the
* * request".
* *
* * Replace "sign" by "authenticate".
* *
* * END OF COMMENTS
* *
* *




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBFNb7lc022439; Wed, 15 Dec 2004 15:37:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBFNb7FS022438; Wed, 15 Dec 2004 15:37:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBFNb6lS022394 for <[e-mail]>; Wed, 15 Dec 2004 15:37:07 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Dec 2004 15:36:59 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 15 Dec 2004 15:36:52 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E2FE.FD0BD737"
Subject: RE: SCVP 16 comments deadline
Date: Wed, 15 Dec 2004 15:36:57 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTh+3SG7vEDA6qXT1Cw/fu3U94ExgA/2U8Q
From: "Trevor Freeman" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 15 Dec 2004 23:36:52.0451 (UTC) FILETIME=[F47B5330:01C4E2FE]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E2FE.FD0BD737
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi David,

First off I think that the current draft has an omission with respect
the fact that there is no explicit do revocation check. Therefore if you
want path construction with revocation, that is two checks to request.
If the client then subsequently passes in the revocation check on is
own, does that mandate a path build on the client certificate - no. A
server may elect to do that voluntarily, but I don't want to require the
server to do any more than is absolutely necessary. If a client had
previously requested the certificate validity form the server, it may
just be interested in refreshing the revocation status. It can simply do
that by passing in the set of certificates from the previous validation
and request revocation checking. You have the name CAs name and CDP or
AIA - so you have everything you need. I would expect the server to
check the status of signer of the revocation information but otherwise
where is the problem. I would agree that a client should not request
this without having first checked the status of the certificate, but
then there are 1000 ways the client can screw this up and the server is
powerless.

Trevor

=20

________________________________

From: David A. Cooper [mailto:[e-mail]]=20
Sent: Tuesday, December 14, 2004 8:37 AM
To: Trevor Freeman
Cc: Denis Pinkas; [e-mail]
Subject: Re: SCVP 16 comments deadline

=20

Trevor,

There seems to be a misunderstanding here.  The check in question is:

Do revocation status checks on the certification path

In your response to Denis below, you say:

If the client has asked for revocation information, I don't see a full
path build for the client certificate is required. You may build a path
for the CA certificate which signed the CRL, but that is different.

There is a disconnect between these two statements.  The check requires
the server to perform status checks on the path.  In your response, you
refer to the CRL.  If the check only required to server to perform a
status check on the end certificate (i.e., the certificate presented in
the request), then your comment would make sense.  However, the check
requires the server to perform status checks on the path.  Since SCVP
does not allow the client to present a path to the server, the server
MUST build a certification path in order to perform the
id-stc-build-status-checked-pkc-path check, otherwise the server would
not have a certification path for which to perform status checks.

You suggest that the id-stc-build-status-checked-pkc-path check might be
used by itself in a case in which a DPD client has already been able to
build a path.  But this does not work, since the server may not provide
status checks on the same certification path as the one constructed by
the client (or the one that the client had previously obtained from the
SCVP server).  The client could increase the chances that the server
would use the path that it was interested in by providing the
certificates in the path through the intermediateCerts field, but this
would not guarantee that the server would provide status checks for this
path.

As I said in my previous message, if the client wants to server to
provide status checks for the certificates in a particular certification
path, then the client should use OCSP.  OCSP allows the client to ask
for status information for a specific set of certificates, SCVP does
not.  With SCVP, the client can only specify the trust anchor and the
end certificate; the server MUST build the remainder of the
certification path.  So, even if the client only includes the
id-stc-build-status-checked-pkc-path check, there is an implicit
requirement for the server to build a certification path.  I believe
that it makes no sense for the server to perform the
id-stc-build-status-checked-pkc-path check on an unvalidated
certification path.  That is, I believe that the only sensible use of
this feature is for the server to build a validated certification path
and then perform status checks on that path; there is no benefit to
performing status checks on an unvalidated certification path.  Given
this, it makes sense to explicitly indicate that the
id-stc-build-status-checked-pkc-path check requires the server to build
a validated certification path and do revocation status checks on that
certification path.

Dave


Trevor Freeman wrote:



=20
* -----Original Message-----
* From: Denis Pinkas [mailto:[e-mail]]
* Sent: Monday, December 13, 2004 12:35 AM
* To: Trevor Freeman
* Cc: David A. Cooper; [e-mail]
* Subject: Re: SCVP 16 comments deadline
*=20
* Trevor,
*=20
* > David,
* > No wanting to rathole on this sine time is short, the section of the
* > document in question which Denis referred to is dealing with the set
of
* > request that the client can make to the server. We agree that the
client
* > can ask for path construction without revocation checking.
*=20
* Up to here we agree.
[TF] Good
*=20
* > I think it
* > legitimate a DPD client could ask for revocation checking because it
has
* > already be able to build a path. Conceivably a DPV client could do
the
* > same because it pervious asked for the path to be constructed and
just
* > wants the revocation data refreshed.
*=20
* Here we do not agree. If a client has already been able to build a
path,
* then he provides that path as "useful certificates" and the DPV server
will
* necessarily build the path (using or not using these "useful
certificates")
* and verify it.
*=20
* So if revocation checking is asked for by the client, this necessarily
* mandates path construction.
[TF] what there server does to process the request is orthogonal to the
section in question.  If the client has asked for revocation
information, I don't see a full path build for the client certificate is
required. You may build a path for the CA certificate which signed the
CRL, but that is different.
*=20
* Denis
*=20
*=20
* > However to get to the bottom line, is there a specific problem with
the
* > text in section 3.1.2
* > Trevor
* >
* > * -----Original Message-----
* > * From: David A. Cooper [mailto:[e-mail]]
* > * Sent: Thursday, December 09, 2004 2:22 PM
* > * To: Trevor Freeman
* > * Cc: [e-mail]
* > * Subject: Re: SCVP 16 comments deadline
* > *
* > * Trevor,
* > *
* > * I must say that I agree with Seth and Denis.  I was under the
impression
* > * that "Do revocation status checking on the certification path"
really
* > * meant "build and validated certification path to a trust anchor
and do
* > * revocation status checking on the certification path".  While I
can see
* > * that there may be circumstances in which one would request a
validated
* > * certification path without requiring revocation status checking, I
can't
* > * see requesting revocation status checking without requesting that
the
* > * path be validated.
* > *
* > * It is certainly the case that one can not "do revocation status
checking
* > * on the certification path" without also building a certification
path.
* > * Since the client can not provide a certification path, revocation
status
* > * checking must be performed on a path that is built by the server.
I
* > * suppose you could argue that this simply means that a well formed
query
* > * can not include the id-stc-build-status-checked-pkc-path without
also
* > * including either the id-stc-build-pkc-path or
* > * id-stc-build-valid-pkc-path check.  But, I see see the need for
this.
* > *
* > * A DPD client would include the id-stc-build-pkc-path along with
the
* > * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info
wantBacks.
* > * If the DPD client included the id-swb-pkc-revocation-info
wantBack, it
* > * wouldn't need to also include the
id-stc-build-status-checked-pkc-path
* > * check.  If the DPD client did not include the
id-swb-pkc-revocation-info
* > * wantBack, then would not include the
id-stc-build-status-checked-pkc-path check.
* > *
* > * So, I would argue that the id-swb-pkc-revocation-info wantBack
would
* > * only be used in the case that the client was requesting a
validated
* > * certification path.  The way that I had interpreted the currently
* > * defined checks items, an SCVP query would only include one check
since
* > * each successive check included the requirements of the previous
one:
* > * id-stc-build-valid-pkc-path included the requirement to build a
path
* > * (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
* > * included the requirement to build a validated path
* > * (id-stc-build-valid-pkc-path).
* > *
* > * Under what circumstances can you envision a client wanting the
server to
* > * do revocation status checking on a certification path (that is
* > * constructed by the server) without also including a requirement
that the
* > * certification path be validated?   If there are no reasonable
* > * circumstances in which a client would make such a query, why is it
* > * necessary for clients to be able to construct such a query?
* > *
* > * Dave
* > *
* > * Trevor Freeman wrote:
* > *
* > * >Hi Seth,
* > * >A server can always go beyond what the client asked for. I don't
see
* > * >that as strictly necessary in all cases such as if the client
just asks
* > * >for revocation. Untimely is a matter of local server policy. What
the
* > * >server cannot do is return status or errors relating to the other
* > * >activities which  were beyond the request scope.
* > * >Trevor
* > * >
* > * While it might make sense for a client to only ask for revocation
* > * checking if the client could specify the certification path, it
does not
* > * seem to make sense given that the server chooses the certification
path
* > * for which revocation status checking will be performed.  If the
client
* > * wants to specify a set of certificates for which it only wants to
know
* > * the revocation status, that is what OCSP is for.
* > *
* > * >
* > * >* -----Original Message-----
* > * >* From: Seth Hitchings [mailto:[e-mail]]
* > * >* Sent: Wednesday, December 08, 2004 11:34 AM
* > * >* To: Trevor Freeman
* > * >* Cc: [e-mail]
* > * >* Subject: RE: SCVP 16 comments deadline
* > * >*
* > * >* Trevor,
* > * >*
* > * >* For clarification, I assume that doing revocation status checks
on a path
* > * >* implies building a validated path?
* > * >*
* > * >* If I am correct, in what case would a client ever send more
than one check?
* > * >*
* > * >* Seth
* > * >*
* > * >* -----Original Message-----
* > * >* From: [e-mail]
* > * >[mailto:[e-mail]]
* > * >* On Behalf Of
* > * >* Trevor Freeman
* > * >* Sent: Wednesday, December 08, 2004 1:42 PM
* > * >* To: Denis Pinkas
* > * >* Cc: [e-mail]
* > * >* Subject: RE: SCVP 16 comments deadline
* > * >*
* > * >*
* > * >* Denis,
* > * >* I know of several systems who's policy is never to revoke the
identity certificate because
* > * >* they have other mechanisms to address the issue.
* > * >* They are using authorization bound to the identity and they
either rely on short lived
* > * >* authorization assertions or revoke the authorization privilege
assonated with the
* > * >* identity. Therefore in those cases not checking the revocation
status of the certificate
* > * >* makes perfect sense.
* > * >* Trevor
* > * >*
* > * >* * -----Original Message-----
* > * >* * From: [e-mail]
* > * >* [mailto:[e-mail]]
* > * >* * On Behalf Of Denis Pinkas
* > * >* * Sent: Wednesday, December 08, 2004 8:01 AM
* > * >* * To: Trevor Freeman
* > * >* * Cc: [e-mail]
* > * >* * Subject: Re: SCVP 16 comments deadline
* > * >* *
* > * >* *
* > * >* * Trevor,
* > * >* *
* > * >* * > Hi Denis,
* > * >* * > Below are responses to 1-16. Others will follow later.
* > * >* *
* > * >* * I am pleased that you accepted comments 13, 14, 15 and 16.
* > * >* * Among this list, I have a further remark on comment 4.
* > * >* *
* > * >* * > * 4. Page 13. Typo. Section 3.1.2 "checks"
* > * >* * > * The two following lines are in fact one line:
* > * >* * > *
* > * >* * > * Change:
* > * >* * > *
* > * >* * > *      - Build a validated certification path to a trust
anchor; and
* > * >* * > *
* > * >* * > *      - Do revocation status checks on the certification
path.
* > * >* * > *
* > * >* * > * into:
* > * >* * > *
* > * >* * > *      - Build a validated certification path to a trust
anchor and
* > * >* * > *        do revocation status checks on the certification
path.
* > * >* * > *
* > * >* * > [TF] Since this paragraph is listing the possible checks
and building a
* > * >* * > path is a separate check to revocation checking, I think
the current
* > * >* * > text is more accurate.
* > * >* *
* > * >* * I agree that "building a path is a separate check to
revocation checking",
* > * >* * but revocation checking without building a validated path
does not make sense.
* > * >* *
* > * >* * The full text currently is:
* > * >* *
* > * >* *      - Build a certification path to a trust anchor;
* > * >* *
* > * >* *      - Build a validated certification path to a trust
anchor; and
* > * >* *
* > * >* *      - Do revocation status checks on the certification path.
* > * >* *
* > * >* * The full text should be:
* > * >* *
* > * >* *      - Build a certification path to a trust anchor;
* > * >* *
* > * >* *      - Build a validated certification path to a trust
anchor; and
* > * >* *        do revocation status checks on the certification path.
* > * >* *
* > * >* * Denis

=20


------_=_NextPart_001_01C4E2FE.FD0BD737
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 201.0pt 0pt 0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi David,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>First off I think that the current =
draft
has an omission with respect the fact that there is no explicit do =
revocation
check. Therefore if you want path construction with revocation, that is =
two checks
to request. If the client then subsequently passes in the revocation =
check on
is own, does that mandate a path build on the client certificate &#8211; =
no. A
server may elect to do that voluntarily, but I don&#8217;t want to =
require the
server to do any more than is absolutely necessary. If a client had =
previously
requested the certificate validity form the server, it may just be =
interested
in refreshing the revocation status. It can simply do that by passing in =
the
set of certificates from the previous validation and request revocation
checking. You have the name CAs name and CDP or AIA &#8211; so you have
everything you need. I would expect the server to check the status of =
signer of
the revocation information but otherwise where is the problem. I would =
agree
that a client should not request this without having first checked the =
status
of the certificate, but then there are 1000 ways the client can screw =
this up
and the server is powerless.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Trevor</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> David A. Cooper [mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, December =
14, 2004
8:37 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Trevor Freeman<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Denis Pinkas; =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: SCVP 16 =
comments
deadline</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Trevor,<br>
<br>
There seems to be a misunderstanding here.&nbsp; The check in question =
is:</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Do revocation status checks on the =
certification path</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>In your response to Denis below, you =
say:</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>If the client has asked for revocation =
information, I
don't see a full path build for the client certificate is required. You =
may
build a path for the CA certificate which signed the CRL, but that is
different.</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>There is a disconnect between these two =
statements.&nbsp;
The check requires the server to perform status checks on <u>the =
path</u>.&nbsp;
In your response, you refer to <u>the CRL</u>.&nbsp; If the check only =
required
to server to perform a status check on the end certificate (i.e., the
certificate presented in the request), then your comment would make
sense.&nbsp; However, the check requires the server to perform status =
checks on
the <u>path</u>.&nbsp; Since SCVP does not allow the client to present a =
path
to the server, the server <u>MUST</u> build a certification path in =
order to
perform the id-stc-build-status-checked-pkc-path check, otherwise the =
server
would not have a certification path for which to perform status =
checks.<br>
<br>
You suggest that the id-stc-build-status-checked-pkc-path check might be =
used
by itself in a case in which a DPD client has already been able to build =
a
path.&nbsp; But this does not work, since the server may not provide =
status
checks on the same certification path as the one constructed by the =
client (or
the one that the client had previously obtained from the SCVP =
server).&nbsp;
The client could increase the chances that the server would use the path =
that
it was interested in by providing the certificates in the path through =
the
intermediateCerts field, but this would not guarantee that the server =
would
provide status checks for this path.<br>
<br>
As I said in my previous message, if the client wants to server to =
provide
status checks for the certificates in a particular certification path, =
then the
client should use OCSP.&nbsp; OCSP allows the client to ask for status
information for a specific set of certificates, SCVP does not.&nbsp; =
With SCVP,
the client can only specify the trust anchor and the end certificate; =
the
server MUST build the remainder of the certification path.&nbsp; So, =
even if
the client only includes the id-stc-build-status-checked-pkc-path check, =
there
is an implicit requirement for the server to build a certification =
path.&nbsp;
I believe that it makes no sense for the server to perform the
id-stc-build-status-checked-pkc-path check on an unvalidated =
certification
path.&nbsp; That is, I believe that the only sensible use of this =
feature is
for the server to build a validated certification path and then perform =
status
checks on that path; there is no benefit to performing status checks on =
an
unvalidated certification path.&nbsp; Given this, it makes sense to =
explicitly
indicate that the id-stc-build-status-checked-pkc-path check requires =
the
server to build a validated certification path and do revocation status =
checks
on that certification path.<br>
<br>
Dave<br>
<br>
<br>
Trevor Freeman wrote:<br>
<br>
</span></font></p>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font size=3D2
color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt'>* =
-----Original Message-----</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* From: Denis Pinkas [<a
href=3D"mailto:[e-mail]">mailto:[e-mail]</a>]</=
span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* Sent: Monday, December 13, 2004 12:35 =
AM</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* To: Trevor =
Freeman</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* Cc: David A. Cooper; <a
href=3D"mailto:[e-mail]">[e-mail]</a></span></font></pr=
e><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* Subject: Re: SCVP 16 comments =
deadline</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* Trevor,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; David,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; No wanting to rathole on this sine =
time is short, the section of the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; document in question which Denis =
referred to is dealing with the set of</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; request that the client can make to =
the server. We agree that the client</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; can ask for path construction without =
revocation checking.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* Up to here we =
agree.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>[TF] Good</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; I think =
it</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; legitimate a DPD client could ask for =
revocation checking because it has</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; already be able to build a path. =
Conceivably a DPV client could do the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; same because it pervious asked for the =
path to be constructed and just</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; wants the revocation data =
refreshed.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* Here we do not agree. If a client has =
already been able to build a path,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* then he provides that path as &quot;useful =
certificates&quot; and the DPV server will</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* necessarily build the path (using or not =
using these &quot;useful =
certificates&quot;)</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* and verify =
it.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* So if revocation checking is asked for by =
the client, this necessarily</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* mandates path =
construction.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>[TF] what there server does to process the =
request is orthogonal to the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>section in question.&nbsp; If the client has =
asked for revocation</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>information, I don't see a full path build =
for the client certificate is</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>required. You may build a path for the CA =
certificate which signed the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>CRL, but that is =
different.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* Denis</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* </span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; However to get to the bottom line, is =
there a specific problem with the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; text in section =
3.1.2</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; Trevor</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * -----Original =
Message-----</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * From: David A. Cooper [<a
href=3D"mailto:[e-mail]">mailto:[e-mail]</a>]</=
span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * Sent: Thursday, December 09, 2004 =
2:22 PM</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * To: Trevor =
Freeman</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * Cc: <a
href=3D"mailto:[e-mail]">[e-mail]</a></span></font></pr=
e><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * Subject: Re: SCVP 16 comments =
deadline</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * =
Trevor,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * I must say that I agree with Seth =
and Denis.&nbsp; I was under the =
impression</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * that &quot;Do revocation status =
checking on the certification path&quot; =
really</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * meant &quot;build and validated =
certification path to a trust anchor and =
do</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * revocation status checking on the =
certification path&quot;.&nbsp; While I can =
see</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * that there may be circumstances in =
which one would request a validated</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * certification path without requiring =
revocation status checking, I can't</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * see requesting revocation status =
checking without requesting that the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * path be =
validated.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * It is certainly the case that one =
can not &quot;do revocation status =
checking</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * on the certification path&quot; =
without also building a certification =
path.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * Since the client can not provide a =
certification path, revocation status</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * checking must be performed on a path =
that is built by the server. I</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * suppose you could argue that this =
simply means that a well formed query</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * can not include the =
id-stc-build-status-checked-pkc-path without =
also</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * including either the =
id-stc-build-pkc-path or</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * id-stc-build-valid-pkc-path =
check.&nbsp; But, I see see the need for =
this.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * A DPD client would include the =
id-stc-build-pkc-path along with the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * id-swb-pkc-best-cert-path and/or =
id-swb-pkc-revocation-info wantBacks.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * If the DPD client included the =
id-swb-pkc-revocation-info wantBack, it</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * wouldn't need to also include the =
id-stc-build-status-checked-pkc-path</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * check.&nbsp; If the DPD client did =
not include the id-swb-pkc-revocation-info</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * wantBack, then would not include the =
id-stc-build-status-checked-pkc-path =
check.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * So, I would argue that the =
id-swb-pkc-revocation-info wantBack would</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * only be used in the case that the =
client was requesting a validated</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * certification path.&nbsp; The way =
that I had interpreted the currently</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * defined checks items, an SCVP query =
would only include one check since</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * each successive check included the =
requirements of the previous one:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * id-stc-build-valid-pkc-path included =
the requirement to build a path</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * (id-stc-build-pkc-path) and =
id-stc-build-status-checked-pkc-path</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * included the requirement to build a =
validated path</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * =
(id-stc-build-valid-pkc-path).</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * Under what circumstances can you =
envision a client wanting the server to</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * do revocation status checking on a =
certification path (that is</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * constructed by the server) without =
also including a requirement that the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * certification path be =
validated?&nbsp;&nbsp; If there are no =
reasonable</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * circumstances in which a client =
would make such a query, why is it</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * necessary for clients to be able to =
construct such a query?</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * Dave</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * Trevor Freeman =
wrote:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;Hi =
Seth,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;A server can always go beyond =
what the client asked for. I don't see</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;that as strictly necessary in =
all cases such as if the client just asks</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;for revocation. Untimely is a =
matter of local server policy. What the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;server cannot do is return =
status or errors relating to the other</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;activities which&nbsp; were =
beyond the request scope.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * =
&gt;Trevor</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * While it might make sense for a =
client to only ask for revocation</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * checking if the client could specify =
the certification path, it does not</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * seem to make sense given that the =
server chooses the certification path</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * for which revocation status checking =
will be performed.&nbsp; If the client</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * wants to specify a set of =
certificates for which it only wants to =
know</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * the revocation status, that is what =
OCSP is for.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; *</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* -----Original =
Message-----</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* From: Seth Hitchings [<a
href=3D"mailto:[e-mail]">mailto:[e-mail]=
m</a>]</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* Sent: Wednesday, December 08, =
2004 11:34 AM</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* To: Trevor =
Freeman</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* Cc: <a
href=3D"mailto:[e-mail]">[e-mail]</a></span></font></pr=
e><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* Subject: RE: SCVP 16 comments =
deadline</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
Trevor,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* For clarification, I assume =
that doing revocation status checks on a =
path</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* implies building a validated =
path?</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* If I am correct, in what case =
would a client ever send more than one =
check?</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
Seth</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* -----Original =
Message-----</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* From: <a
href=3D"mailto:[e-mail]">[e-mail]=
</a></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;[<a
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* On Behalf =
Of</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* Trevor =
Freeman</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* Sent: Wednesday, December 08, =
2004 1:42 PM</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* To: Denis =
Pinkas</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* Cc: <a
href=3D"mailto:[e-mail]">[e-mail]</a></span></font></pr=
e><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* Subject: RE: SCVP 16 comments =
deadline</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
Denis,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* I know of several systems =
who's policy is never to revoke the identity certificate =
because</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* they have other mechanisms to =
address the issue.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* They are using authorization =
bound to the identity and they either rely on short =
lived</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* authorization assertions or =
revoke the authorization privilege assonated with =
the</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* identity. Therefore in those =
cases not checking the revocation status of the =
certificate</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* makes perfect =
sense.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
Trevor</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * -----Original =
Message-----</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * From: <a
href=3D"mailto:[e-mail]">[e-mail]=
</a></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* [<a
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * On Behalf Of Denis =
Pinkas</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * Sent: Wednesday, December =
08, 2004 8:01 AM</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * To: Trevor =
Freeman</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * Cc: <a
href=3D"mailto:[e-mail]">[e-mail]</a></span></font></pr=
e><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * Subject: Re: SCVP 16 =
comments deadline</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * =
Trevor,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; Hi =
Denis,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; Below are responses to =
1-16. Others will follow later.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * I am pleased that you =
accepted comments 13, 14, 15 and 16.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * Among this list, I have a =
further remark on comment 4.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; * 4. Page 13. Typo. =
Section 3.1.2 &quot;checks&quot;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; * The two following =
lines are in fact one line:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; * =
Change:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Build a validated certification path =
to a trust anchor; and</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Do revocation status checks on the =
certification path.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; * =
into:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Build a validated certification path =
to a trust anchor and</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do revocation status checks =
on the certification path.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; [TF] Since this =
paragraph is listing the possible checks and building =
a</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; path is a separate =
check to revocation checking, I think the =
current</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * &gt; text is more =
accurate.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * I agree that &quot;building =
a path is a separate check to revocation =
checking&quot;,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * but revocation checking =
without building a validated path does not make =
sense.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * The full text currently =
is:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Build a certification path to a trust =
anchor;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Build a validated certification path =
to a trust anchor; and</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Do revocation status checks on the =
certification path.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * The full text should =
be:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Build a certification path to a trust =
anchor;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Build a validated certification path =
to a trust anchor; and</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do revocation status checks =
on the certification path.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* =
*</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>* &gt; * &gt;* * Denis</span></font></pre>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C4E2FE.FD0BD737--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBFM7rOf058354; Wed, 15 Dec 2004 14:07:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBFM7r1u058352; Wed, 15 Dec 2004 14:07:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from auth1.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBFM7oTD057964 for <[e-mail]>; Wed, 15 Dec 2004 14:07:51 -0800 (PST) (envelope-from [e-mail])
Received: from auth1.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id 550282CC3F8 for <[e-mail]>; Thu, 16 Dec 2004 06:08:13 +0800 (CST)
Received: from pop34.cht.com.tw (pop34.cht.com.tw [10.160.1.14]) by auth1.cht.com.tw (Postfix) with SMTP id D0E1A2CD0D2 for <[e-mail]>; Thu, 16 Dec 2004 01:13:52 +0800 (CST)
Received: By OpenMail Mailer;Thu, 16 Dec 2004 01:13:15 +0800 (CST)
From: "Wen-Cheng Wang" <[e-mail]>
Reply-To: [e-mail]
Subject: SCVP 16 comments
Message-ID: <[e-mail]>
To: [e-mail]
Date: Thu, 16 Dec 2004 01:13:15 +0800 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBFM7qTD058346
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are my comments on SCVP ID 16.

1. Page 11:

The responseRefHash, responseValidationPolByRef, and
signResponse items are now grouped into the the
responseFlags item. 

Therefore, the sentence:

" A query 
  MUST contain a sequence of one or more queriedCerts items as well 
  as one checks, one wantBack and one validationPolicy item; and a 
  query MAY also contain responseRefHash, responseValidationPolByRef, 
  signResponse, serverContextInfo, validationTime, intermediateCerts, 
  revInfos, producedAt, and queryExtensions items."

should be changed to:

" A query 
  MUST contain a sequence of one or more queriedCerts items as well 
  as one checks, one wantBack and one validationPolicy item; and a 
  query MAY also contain responseFlags, serverContextInfo,
  validationTime, intermediateCerts, revInfos, producedAt, and
  queryExtensions items."

2. Page 12:

For the same reason, the sentence:

" The requestRefHash, responseValidationPolByRef 
  and signResponse items allow the client to request optional 
  features for the response."

should be changed to:

" The responseFlags item allows the client to request optional 
  features for the response."

3. Page 13:

When a client want to build/validate/do revocation check on the
certification path for the AC issuer, it is not clear that whether
the reference to the AC itself or the AC issuer's PKC need to be
send to the server?

Also, there are no OIDs defined for

  - Build a certification path to a trust anchor;
  - Build a certification path to a trust anchor for the AC 
    issuer

And I think the following statement is not correct.

  "Also, building a validated certification path does 
   not imply revocation status checks."

If the server does not perform revocation status checks,
how does it know the certification path is valid or not?

4. Page 17:
The following paragraph should not appear in section 3.1.4.1:

" SCVP servers SHOULD support serverContextInfo.  SCVP clients MAY 
  support serverContextInfo"

5. Page 18:

The following paragraph should be moved to section 3.1.4.1:

" Neither the clients nor server MUST dereference the URI during SCVP 
  request processing.  The URI is simply used as a reference for the 
  validation policy.  Clients and server MAY dereference the URI as 
  part of configuration."

6. Page 19, 20, 21, 22:
OID names are not consistent. The following substutions are
recommended:

id-bvae-notYetValid -> id-bvae-not-yet-valid

id-bvae-wrong-Anchor -> id-bvae-wrong-anchor

id-bvae-invalid-Key-Usage -> id-bvae-invalid-key-usage

id-bvae-invalid-Purpose -> id-bvae-invalid-purpose

id-bvae-invalid-Policy -> id-bvae-invalid-cert-policy

id-bvae-invalid-Name -> id-bvae-invalid-name

id-bvae-invalid-Entity -> id-bvae-invalid-entity

id-bvae-invalid-Depth -> id-bvae-invalid-path-length

id-bvae-invalidPurpose -> id-bvae-invalid-purpose

id-bvae-invalidCertPolicy -> id-bvae-invalid-cert-policy

id-bvae-invalidName -> id-bvae-invalid-name

id-bvae-invalidEntity -> id-bvae-invalid-entity

id-bvae-invalidPathDepth -> id-bvae-invalid-path-length

id-nvae-unknown-pupose -> id-nvae-unknown-purpose

id-nvae-nameMismatch -> id-nvae-name-mismatch

id-nvae-noCertName -> id-nvae-no-name

id-nvae-unknownPupose -> id-nvae-unknown-purpose

id-nvae-badName -> id-nvae-bad-name

id-nvae-badNameType -> id-nvae-bad-name-type

id-nvae-mixedNames -> id-nvae-mixed-names

7. Page 22:

The following paragraph should not appear in section 3.1.5.2.4:

" The userPolicySet item specifies a list of policy identifiers that 
  the SCVP server MUST use when forming and validating a certificate 
  If certPolicies is not specified, then any-policy MUST be used."

8. Page 64:

In the last paragraph of page 64:

"serverContextInformation" should be "serverContextInfo".


Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBFF6Ysg034392; Wed, 15 Dec 2004 07:06:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBFF6YqE034391; Wed, 15 Dec 2004 07:06:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBFF6XwS034346 for <[e-mail]>; Wed, 15 Dec 2004 07:06:33 -0800 (PST) (envelope-from [e-mail])
Received: from [172.0.0.1] ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Dec 2004 09:06:25 -0600
Received: from no.name.available by [172.0.0.1] via smtpd (for [200.57.34.107] [200.57.34.107]) with ESMTP; Wed, 15 Dec 2004 10:02:29 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: Question about CMP(RFC2510)
Date: Wed, 15 Dec 2004 09:05:48 -0600
Message-ID: <000b01c4e2b7$8f582e70$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <000a01c4e24f$c2dfd800$7c0410ac@5446D1>
Importance: Normal
X-OriginalArrivalTime: 15 Dec 2004 15:06:25.0531 (UTC) FILETIME=[A56A34B0:01C4E2B7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBFF6YwS034385
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

OK let's see, I just checked draft-ietf-pkix-rfc2510bis-09.txt where
pvno is defined as follows  (section 5.1.1, page 27) :

pvno    INTEGER  { cmp1999(1), cmp2000(2) }

Now this draft expired on August 12, 2004. My guess is that we'll hear
from the authors of  draft-ietf-pkix-rfc2510bis-09.txt anytime soon,
perhaps this issue will be cleared then. Draft bis07 for RFC2511 has
expired too, I still have to read what Jim Schaad wrote. 

Regards,

Miguel A Rodriguez
SeguriData
Mexico

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Lee Hyangjin
>Sent: Tuesday, December 14, 2004 8:43 PM
>To: [e-mail]
>Subject: Question about CMP(RFC2510)
>
>
>
>Hi, 
>
>I have a question on 'pvno' described in RFC2510, chapter 
>3.1.1 PKI Message Header.
>
>In this specfication, 'pvno' field is fixed at one(ietf-version2).
>
>So, I tried to find out the previous version(ietf-version1), I 
>couldn't  find out  in IETF web page.
>
>Why is the version2 ? Is there the previous spec?
>
>
>Regards,
>Lee
>
>******************************************
>Hyangjin Lee
> 
>Researcher
>E-Transaction Security Technology Team
>Korea Information Security Agency
>Tel.[phone]
>Fax.[phone]
>E-mail: [e-mail]
>******************************************
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBF5cLnp000939; Tue, 14 Dec 2004 21:38:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBF5cL9I000938; Tue, 14 Dec 2004 21:38:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBF5cIhP000899 for <[e-mail]>; Tue, 14 Dec 2004 21:38:18 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 39DE134935; Wed, 15 Dec 2004 18:38:20 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31678-29; Wed, 15 Dec 2004 18:38:20 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 997DA34407; Wed, 15 Dec 2004 18:38:19 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 9621C37748; Wed, 15 Dec 2004 18:38:19 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CeRrl-0000hJ-00; Wed, 15 Dec 2004 18:38:25 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Question about CMP(RFC2510)
Message-Id: <[e-mail]>
Date: Wed, 15 Dec 2004 18:38:25 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Hmm, that's a bit of a complex question.

Sorry, I forgot to add:

  Whirr, click, do not ask that question again, whoosh.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBF5bRW1099867; Tue, 14 Dec 2004 21:37:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBF5bRXZ099866; Tue, 14 Dec 2004 21:37:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBF5bO4x099813 for <[e-mail]>; Tue, 14 Dec 2004 21:37:24 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 7DD1A34210; Wed, 15 Dec 2004 18:37:28 +1300 (NZDT)
Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23098-14; Wed, 15 Dec 2004 18:37:28 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 89FB1343A3; Wed, 15 Dec 2004 18:37:27 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6167937748; Wed, 15 Dec 2004 18:37:27 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CeRqu-0000h0-00; Wed, 15 Dec 2004 18:37:32 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Question about CMP(RFC2510)
In-Reply-To: <000a01c4e24f$c2dfd800$7c0410ac@5446D1>
Message-Id: <[e-mail]>
Date: Wed, 15 Dec 2004 18:37:32 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Lee Hyangjin" <[e-mail]> writes:

>So, I tried to find out the previous version(ietf-version1), I couldn't  find
>out  in IETF web page.
>
>Why is the version2 ? Is there the previous spec?

Hmm, that's a bit of a complex question.  What was supposed to be CMP didn't
work but there was no way of fixing it, so the version number was changed to
ensure that the form that worked slightly better than the original would look
like something else to any implementation of the original form.  So there's
sort of a version 1 except that there isn't.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBF2gYrC001224; Tue, 14 Dec 2004 18:42:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBF2gYim001223; Tue, 14 Dec 2004 18:42:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sniper.kisa.or.kr ([211.252.150.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id iBF2gTfj001198 for <[e-mail]>; Tue, 14 Dec 2004 18:42:33 -0800 (PST) (envelope-from [e-mail])
Received: (snipe 8278 invoked by alias); 15 Dec 2004 11:39:23 +0900(KST)
Received: from [e-mail] with  Spamsniper 2.83 (Processed in 0.050904 secs);
Received: from unknown (HELO 5446D1) (172.16.4.124) by 0 with SMTP; 15 Dec 2004 11:39:23 +0900(KST)
X-RCPTTO: [e-mail],
Message-ID: <000a01c4e24f$c2dfd800$7c0410ac@5446D1>
From: "Lee Hyangjin" <[e-mail]>
To: <[e-mail]>
Subject: Question about CMP(RFC2510)
Date: Wed, 15 Dec 2004 11:42:46 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id iBF2gXfj001218
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, 

I have a question on 'pvno' described in RFC2510, chapter 3.1.1 PKI Message Header.

In this specfication, 'pvno' field is fixed at one(ietf-version2).

So, I tried to find out the previous version(ietf-version1), I couldn't  find out  in IETF web page.

Why is the version2 ? Is there the previous spec?


Regards,
Lee

******************************************
Hyangjin Lee
 
Researcher
E-Transaction Security Technology Team
Korea Information Security Agency
Tel.[phone]
Fax.[phone]
E-mail: [e-mail]
******************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBELImea095808; Tue, 14 Dec 2004 13:18:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBELImAr095807; Tue, 14 Dec 2004 13:18:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBELIl8n095794 for <[e-mail]>; Tue, 14 Dec 2004 13:18:48 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iBELAg6I008224; Tue, 14 Dec 2004 16:10:42 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iBEL3nLS018852; Tue, 14 Dec 2004 16:03:50 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2004 16:03:49 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Seth Hitchings <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Seth,<br>
<br>
I think that CertChecks should remain a SEQUENCE.&nbsp; While I don't
believe that a query should include more than one of the currently
defined check OIDs, new checks may be defined in the future which could
be used in combination.<br>
<br>
Dave<br>
<br>
Seth Hitchings wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title></title>
  <meta content="MSHTML 6.00.2900.2523" name="GENERATOR">
  <div dir="ltr" align="left"><font face="Arial"><font color="#0000ff"><font
 size="2">I<span class="634173817-14122004">f the changes that David
recommends are accepted (which I believe they should be), then is there
any reason for CertChecks to be a sequence of check OIDs? Validation
implies path construction, and status checking implies validation. When
would a client send more than one check?</span></font></font></font></div>
  <div>&nbsp;</div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="634173817-14122004">Seth</span></font></font></font></div>
  <div dir="ltr" align="left"><br>
  </div>
  <div class="OutlookMessageHeader" lang="en-us" dir="ltr" align="left">
  <hr tabindex="-1"><font face="Tahoma" size="2"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] <b>On
Behalf Of </b>David A. Cooper<br>
  <b>Sent:</b> Tuesday, December 14, 2004 11:37 AM<br>
  <b>To:</b> Trevor Freeman<br>
  <b>Cc:</b> Denis Pinkas; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a><br>
  <b>Subject:</b> Re: SCVP 16 comments deadline<br>
  </font><br>
  </div>
Trevor,<br>
  <br>
There seems to be a misunderstanding here.&nbsp; The check in question is:<br>
  <blockquote>Do revocation status checks on the certification path<br>
  </blockquote>
In your response to Denis below, you say:<br>
  <blockquote>If the client has asked for revocation information, I
don't see a full path build for the client certificate is required. You
may build a path for the CA certificate which signed the CRL, but that
is different.<br>
  </blockquote>
There is a disconnect between these two statements.&nbsp; The check requires
the server to perform status checks on <u>the path</u>.&nbsp; In your
response, you refer to <u>the CRL</u>.&nbsp; If the check only required to
server to perform a status check on the end certificate (i.e., the
certificate presented in the request), then your comment would make
sense.&nbsp; However, the check requires the server to perform status checks
on the <u>path</u>.&nbsp; Since SCVP does not allow the client to present a
path to the server, the server <u>MUST</u> build a certification path
in order to perform the id-stc-build-status-checked-pkc-path check,
otherwise the server would not have a certification path for which to
perform status checks.<br>
  <br>
You suggest that the id-stc-build-status-checked-pkc-path check might
be used by itself in a case in which a DPD client has already been able
to build a path.&nbsp; But this does not work, since the server may not
provide status checks on the same certification path as the one
constructed by the client (or the one that the client had previously
obtained from the SCVP server).&nbsp; The client could increase the chances
that the server would use the path that it was interested in by
providing the certificates in the path through the intermediateCerts
field, but this would not guarantee that the server would provide
status checks for this path.<br>
  <br>
As I said in my previous message, if the client wants to server to
provide status checks for the certificates in a particular
certification path, then the client should use OCSP.&nbsp; OCSP allows the
client to ask for status information for a specific set of
certificates, SCVP does not.&nbsp; With SCVP, the client can only specify
the trust anchor and the end certificate; the server MUST build the
remainder of the certification path.&nbsp; So, even if the client only
includes the id-stc-build-status-checked-pkc-path check, there is an
implicit requirement for the server to build a certification path.&nbsp; I
believe that it makes no sense for the server to perform the
id-stc-build-status-checked-pkc-path check on an unvalidated
certification path.&nbsp; That is, I believe that the only sensible use of
this feature is for the server to build a validated certification path
and then perform status checks on that path; there is no benefit to
performing status checks on an unvalidated certification path.&nbsp; Given
this, it makes sense to explicitly indicate that the
id-stc-build-status-checked-pkc-path check requires the server to build
a validated certification path and do revocation status checks on that
certification path.<br>
  <br>
Dave<br>
  <br>
  <br>
Trevor Freeman wrote:<br>
  <blockquote
 cite="[e-mail]"
 type="cite">
    <pre wrap="">* -----Original Message-----
* From: Denis Pinkas [<a class="moz-txt-link-freetext"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
* Sent: Monday, December 13, 2004 12:35 AM
* To: Trevor Freeman
* Cc: David A. Cooper; <a class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a>
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* &gt; David,
* &gt; No wanting to rathole on this sine time is short, the section of the
* &gt; document in question which Denis referred to is dealing with the set of
* &gt; request that the client can make to the server. We agree that the client
* &gt; can ask for path construction without revocation checking.
* 
* Up to here we agree.
[TF] Good
* 
* &gt; I think it
* &gt; legitimate a DPD client could ask for revocation checking because it has
* &gt; already be able to build a path. Conceivably a DPV client could do the
* &gt; same because it pervious asked for the path to be constructed and just
* &gt; wants the revocation data refreshed.
* 
* Here we do not agree. If a client has already been able to build a path,
* then he provides that path as "useful certificates" and the DPV server will
* necessarily build the path (using or not using these "useful certificates")
* and verify it.
* 
* So if revocation checking is asked for by the client, this necessarily
* mandates path construction.
[TF] what there server does to process the request is orthogonal to the
section in question.  If the client has asked for revocation
information, I don't see a full path build for the client certificate is
required. You may build a path for the CA certificate which signed the
CRL, but that is different.
* 
* Denis
* 
* 
* &gt; However to get to the bottom line, is there a specific problem with the
* &gt; text in section 3.1.2
* &gt; Trevor
* &gt;
* &gt; * -----Original Message-----
* &gt; * From: David A. Cooper [<a class="moz-txt-link-freetext"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
* &gt; * Sent: Thursday, December 09, 2004 2:22 PM
* &gt; * To: Trevor Freeman
* &gt; * Cc: <a class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a>
* &gt; * Subject: Re: SCVP 16 comments deadline
* &gt; *
* &gt; * Trevor,
* &gt; *
* &gt; * I must say that I agree with Seth and Denis.  I was under the impression
* &gt; * that "Do revocation status checking on the certification path" really
* &gt; * meant "build and validated certification path to a trust anchor and do
* &gt; * revocation status checking on the certification path".  While I can see
* &gt; * that there may be circumstances in which one would request a validated
* &gt; * certification path without requiring revocation status checking, I can't
* &gt; * see requesting revocation status checking without requesting that the
* &gt; * path be validated.
* &gt; *
* &gt; * It is certainly the case that one can not "do revocation status checking
* &gt; * on the certification path" without also building a certification path.
* &gt; * Since the client can not provide a certification path, revocation status
* &gt; * checking must be performed on a path that is built by the server. I
* &gt; * suppose you could argue that this simply means that a well formed query
* &gt; * can not include the id-stc-build-status-checked-pkc-path without also
* &gt; * including either the id-stc-build-pkc-path or
* &gt; * id-stc-build-valid-pkc-path check.  But, I see see the need for this.
* &gt; *
* &gt; * A DPD client would include the id-stc-build-pkc-path along with the
* &gt; * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info wantBacks.
* &gt; * If the DPD client included the id-swb-pkc-revocation-info wantBack, it
* &gt; * wouldn't need to also include the id-stc-build-status-checked-pkc-path
* &gt; * check.  If the DPD client did not include the id-swb-pkc-revocation-info
* &gt; * wantBack, then would not include the id-stc-build-status-checked-pkc-path check.
* &gt; *
* &gt; * So, I would argue that the id-swb-pkc-revocation-info wantBack would
* &gt; * only be used in the case that the client was requesting a validated
* &gt; * certification path.  The way that I had interpreted the currently
* &gt; * defined checks items, an SCVP query would only include one check since
* &gt; * each successive check included the requirements of the previous one:
* &gt; * id-stc-build-valid-pkc-path included the requirement to build a path
* &gt; * (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
* &gt; * included the requirement to build a validated path
* &gt; * (id-stc-build-valid-pkc-path).
* &gt; *
* &gt; * Under what circumstances can you envision a client wanting the server to
* &gt; * do revocation status checking on a certification path (that is
* &gt; * constructed by the server) without also including a requirement that the
* &gt; * certification path be validated?   If there are no reasonable
* &gt; * circumstances in which a client would make such a query, why is it
* &gt; * necessary for clients to be able to construct such a query?
* &gt; *
* &gt; * Dave
* &gt; *
* &gt; * Trevor Freeman wrote:
* &gt; *
* &gt; * &gt;Hi Seth,
* &gt; * &gt;A server can always go beyond what the client asked for. I don't see
* &gt; * &gt;that as strictly necessary in all cases such as if the client just asks
* &gt; * &gt;for revocation. Untimely is a matter of local server policy. What the
* &gt; * &gt;server cannot do is return status or errors relating to the other
* &gt; * &gt;activities which  were beyond the request scope.
* &gt; * &gt;Trevor
* &gt; * &gt;
* &gt; * While it might make sense for a client to only ask for revocation
* &gt; * checking if the client could specify the certification path, it does not
* &gt; * seem to make sense given that the server chooses the certification path
* &gt; * for which revocation status checking will be performed.  If the client
* &gt; * wants to specify a set of certificates for which it only wants to know
* &gt; * the revocation status, that is what OCSP is for.
* &gt; *
* &gt; * &gt;
* &gt; * &gt;* -----Original Message-----
* &gt; * &gt;* From: Seth Hitchings [<a class="moz-txt-link-freetext"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
* &gt; * &gt;* Sent: Wednesday, December 08, 2004 11:34 AM
* &gt; * &gt;* To: Trevor Freeman
* &gt; * &gt;* Cc: <a class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;* Subject: RE: SCVP 16 comments deadline
* &gt; * &gt;*
* &gt; * &gt;* Trevor,
* &gt; * &gt;*
* &gt; * &gt;* For clarification, I assume that doing revocation status checks on a path
* &gt; * &gt;* implies building a validated path?
* &gt; * &gt;*
* &gt; * &gt;* If I am correct, in what case would a client ever send more than one check?
* &gt; * &gt;*
* &gt; * &gt;* Seth
* &gt; * &gt;*
* &gt; * &gt;* -----Original Message-----
* &gt; * &gt;* From: <a class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;[<a class="moz-txt-link-freetext"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
* &gt; * &gt;* On Behalf Of
* &gt; * &gt;* Trevor Freeman
* &gt; * &gt;* Sent: Wednesday, December 08, 2004 1:42 PM
* &gt; * &gt;* To: Denis Pinkas
* &gt; * &gt;* Cc: <a class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;* Subject: RE: SCVP 16 comments deadline
* &gt; * &gt;*
* &gt; * &gt;*
* &gt; * &gt;* Denis,
* &gt; * &gt;* I know of several systems who's policy is never to revoke the identity certificate because
* &gt; * &gt;* they have other mechanisms to address the issue.
* &gt; * &gt;* They are using authorization bound to the identity and they either rely on short lived
* &gt; * &gt;* authorization assertions or revoke the authorization privilege assonated with the
* &gt; * &gt;* identity. Therefore in those cases not checking the revocation status of the certificate
* &gt; * &gt;* makes perfect sense.
* &gt; * &gt;* Trevor
* &gt; * &gt;*
* &gt; * &gt;* * -----Original Message-----
* &gt; * &gt;* * From: <a class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;* [<a class="moz-txt-link-freetext"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
* &gt; * &gt;* * On Behalf Of Denis Pinkas
* &gt; * &gt;* * Sent: Wednesday, December 08, 2004 8:01 AM
* &gt; * &gt;* * To: Trevor Freeman
* &gt; * &gt;* * Cc: <a class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;* * Subject: Re: SCVP 16 comments deadline
* &gt; * &gt;* *
* &gt; * &gt;* *
* &gt; * &gt;* * Trevor,
* &gt; * &gt;* *
* &gt; * &gt;* * &gt; Hi Denis,
* &gt; * &gt;* * &gt; Below are responses to 1-16. Others will follow later.
* &gt; * &gt;* *
* &gt; * &gt;* * I am pleased that you accepted comments 13, 14, 15 and 16.
* &gt; * &gt;* * Among this list, I have a further remark on comment 4.
* &gt; * &gt;* *
* &gt; * &gt;* * &gt; * 4. Page 13. Typo. Section 3.1.2 "checks"
* &gt; * &gt;* * &gt; * The two following lines are in fact one line:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; * Change:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Build a validated certification path to a trust anchor; and
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Do revocation status checks on the certification path.
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; * into:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Build a validated certification path to a trust anchor and
* &gt; * &gt;* * &gt; *        do revocation status checks on the certification path.
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; [TF] Since this paragraph is listing the possible checks and building a
* &gt; * &gt;* * &gt; path is a separate check to revocation checking, I think the current
* &gt; * &gt;* * &gt; text is more accurate.
* &gt; * &gt;* *
* &gt; * &gt;* * I agree that "building a path is a separate check to revocation checking",
* &gt; * &gt;* * but revocation checking without building a validated path does not make sense.
* &gt; * &gt;* *
* &gt; * &gt;* * The full text currently is:
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a certification path to a trust anchor;
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a validated certification path to a trust anchor; and
* &gt; * &gt;* *
* &gt; * &gt;* *      - Do revocation status checks on the certification path.
* &gt; * &gt;* *
* &gt; * &gt;* * The full text should be:
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a certification path to a trust anchor;
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a validated certification path to a trust anchor; and
* &gt; * &gt;* *        do revocation status checks on the certification path.
* &gt; * &gt;* *
* &gt; * &gt;* * Denis</pre>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEIJarg079270; Tue, 14 Dec 2004 10:19:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBEIJaed079269; Tue, 14 Dec 2004 10:19:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from polito.it (terra.polito.it [130.192.3.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEIJYDE079221 for <[e-mail]>; Tue, 14 Dec 2004 10:19:35 -0800 (PST) (envelope-from [e-mail])
X-AttachExt: p7s
X-ExtScanner: Niversoft's FindAttachments (free)
Received: from [217.133.8.148] (HELO [10.5.122.1]) by polito.it (CommuniGate Pro SMTP 4.2.6) with ESMTP-TLS id 9909243; Tue, 14 Dec 2004 19:19:25 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2004 19:19:49 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Politecnico di Torino
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: Proposed Changes to RFC 3280
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010800040900040204050304"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms010800040900040204050304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David A. Cooper wrote:
> Massimiliano,
> 
> The main reason that the nextUpdate field is needed is that CRLs are 
> distributed through untrusted mechanisms.
[...]
> Since a CRL issuer can publish a new CRL at any time, I can never be 
> certain that I have obtained the most recent CRL.  However, if the CRL 
> includes a nextUpdate time and the current time is after the specified 
> nextUpdate time, then I can be certain that I DO NOT have the most 
> recent CRL.  So, if a CRL issuer always included a nextUpdate time that 
> was 24 hours after the thisUpdate time, an attacker could never trick me 
> into using a CRL that is more than 24 hours out of date.
 >
> If a CRL did not include a nextUpdate time and the issuer only published 
> a new CRL when the revokedCertificates list changed, an attacker could 
> trick me into using an old CRL, no matter how much time had passed since 
> the CRL issuer had published a newer CRL.

You are right, the problem exists. But I think this is a repository-related
problem, not CRL-related. The problem raises from the lack of trust when
distributing CRLs.
To avoid the possibility for an attacker to provide old CRLs, some sort
of trusted channel should be used (e.g. an SSL/TLS channel - if I can
verify the CRL, then I should be able to establish such a channel) for
CRL retrieving.

Anyway, if I am worried about the attack you are envisaging above and
I do not want to use trusted distribution channels, then I still can use
the nextUpdate field - by making it optional it does not mean it is not
possible to use it, right?

> As to your other concern, technically the nextUpdate field is not an 
[...]
> that a newer CRL must be available, the relying party can continue to 
> use the older CRL.

This is something that I never understood, and I think everyone is trying
to avoid in its own PKIs (but this is a personal vision about CRLs).

> If you are worried about the the possibility that the repository will be 
> overloaded with requests from clients when the nextUpdate time in a CRL 
> is reached, there are tricks that you can use to avoid this problem.  In 
> "A Model of Certificate Revocation (see 
> http://csrc.nist.gov/pki/PKImodels/welcome.html), I describe a technique 
> that I call over-issued CRLs that helps to address this problem.

I will take a look at this, thanks for the pointer. Anyway, the fact you
have written the paper indicates that the possibility of an overload of the
repository does exist, right?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [e-mail]
                                                 Tel.:   [phone]
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: [phone]

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

--------------ms010800040900040204050304
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU7zCC
BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG
A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw
MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx
MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX
pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV
6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D
vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt
Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g
mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k
ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG
CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy
NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js
L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ
506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT
yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b
vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW
1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm
053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF
HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+
Azi6vNmzQwCbegU26NFazErhLS5qDXQwggU+MIIEJqADAgECAgIBaDANBgkqhkiG9w0BAQUF
ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ
dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxNDEwMDAwMFoXDTA2MTIz
MTA5MDAwMFowZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlu
bzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9sfcfWMG/mS8O69abPfnUWci
6TfUncSlfs8SzpwAsoW1/OJpGVtxq1yKQrP8WqiixEcZWSvnlOcyRj/C0tz3JLQKSAyrHKGS
Dkn5Md4HCue+L1JHQ3Ba14eQOj7rAugFgE+6LenTAvguOQl74/t9C93Ldm1NY+t1Fs36oPhP
JQ5inrZ6D8P9ol4s/ecyPhhQaU1tioqQy1d01gXTrmI2eH6Ui0AkyexVcxFpXR7qnvPV7huE
+ZTDU77t9jx24smmJuSxlA8HQS8I+qCytDhOYsKm676n1a4wpE9VunoVAm/+7tajm31ZYaxT
njX891kfFGoFi/J3tIRc67vh8Joy+wIDAQABo4ICCjCCAgYwdQYJYIZIAYb4QgENBGgWZklz
c3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9j
cHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBcBggrBgEF
BQcBAQRQME4wKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYI
KwYBBQUHMAKGFmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMIGTBgNVHSAEgYswgYgw
QwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh
L3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3
LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFKo8E8lJC1zNuNMg4MWV
lzMzXSQTMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQWBBT0DG1tnl9M
YlY5geDe+Y8vN6CExTANBgkqhkiG9w0BAQUFAAOCAQEAXx26gpm/oiG7ti2+e1Lwmnqn6jk0
ihxIxccazoTAjWzq60x+MhIJsIgRfGtv5U2XzEWc15UZru6srk8TqctT6EbqRMTCtx6mxPd6
RpKp3jepigGOkwnJsnjjUPC/tHmfJHNcll3Rk6a4OIvazlwOoCuQ8D0N9sAGtx35+T+tAyph
NU9yHtC3dpvQotLmJFo2Pr6sTy2ijCqQnHxJ2sZUEAlNEunKFP8y3uPfwvE0FEC7lONkUx+U
79yAlwPvBvASUopIQPy7BQ9IMupkj/1DmUvml/05f+DYv2x7UbiUlp1ksQXzs+WLxB2NADfn
CaPNvqphRz5KhJGOTJpc8CZ+UDCCBY8wggR3oAMCAQICAgFnMA0GCSqGSIb3DQEBBQUAMGUx
CzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMT
LVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDAy
MDMxNTAwMDBaFw0wNTEyMzExMjAwMDBaMH0xCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xMTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNh
IGUgSW5mb3JtYXRpY2ExGzAZBgNVBAMTEk1hc3NpbWlsaWFubyAgUGFsYTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAq9EaJRA7cRia5n0014UeruZBPwDwNyEpWxIvWqVG6taEt1P1
wApd7oKi7yhUL8yUpX2eEQdLj/yjCQOr1NqmkL5MwiZhVtwcli3/3G0OayKu/i6yRIW24SM5
sbNLO4hhZYSiHAMlZ/U5Y6r6zFvxRbIK9/mB/wrJ6HIzOzC+xncCAwEAAaOCArMwggKvMIGV
BglghkgBhvhCAQ0EgYcWgYRJc3N1ZWQgdW5kZXIgcG9saWNpZXM6CiBodHRwOi8vd3d3LmV1
cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8KIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Ev
aXQvY3BzLzEuMS8KIGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wEQYJYIZIAYb4QgEB
BAQDAgCwMGMGCCsGAQUFBwEBBFcwVTAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3Br
aS5vcmc6ODAyNjApBggrBgEFBQcwAoYdaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC8w
MgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NhLnBvbGl0by5pdC9jcmwwMi9jcmwuZGVyMAwG
A1UdEwEB/wQCMAAwPgYDVR0RBDcwNYEbbWFzc2ltaWxpYW5vLnBhbGFAcG9saXRvLml0oBYG
CisGAQQBlWICAQGgCBYGMTIxNTc1MIHNBgNVHSAEgcUwgcIwQwYKKwYBBAGpBwEBATA1MDMG
CCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYK
KwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0
L2Nwcy8xLjEvMDgGCisGAQQBlWIBAgEwKjAoBggrBgEFBQcCARYcaHR0cDovL2NhLnBvbGl0
by5pdC9jcHMvMi4xLzALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFKBsBAutUrWisrKMhGDw86gH
WDoSMB8GA1UdIwQYMBaAFPQMbW2eX0xiVjmB4N75jy83oITFMA0GCSqGSIb3DQEBBQUAA4IB
AQDrwXGLgvcDvhk2w6AFLp3DIhWl4zX9G6W4v9gis9vBHkIHQUg2iBmbVEeCn9XrSIXtuleH
uyYI+uu+KUdoCqt9XEFlL6eYnvrZNc7wWkH+msZwc11C+8UibhzaUezlEqTm9l+08xucAJER
4q489+2ZY7Kf8tFB1n4edgtg8rxrlNX++ZqqrJCnYWQvv0e4Hmav+CKnuMT+Y1qVv3BW6HDD
OBljhSEx6+cmooIPoWy8/5W/aGl5WEr1aCUZ/o8DODPxUIwEcUHV+m4EuQz7j0XLLcyC62Lc
FCx7+itzdJ61epbCmOgTNSWJFryVPClhlM3YFzFxL9Ae7mFmTdUbkdyKMIIFjzCCBHegAwIB
AgICAWcwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNu
aWNvIGRpIFRvcmlubzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTA0MDIwMzE1MDAwMFoXDTA1MTIzMTEyMDAwMFowfTELMAkG
A1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlubzExMC8GA1UECxMoRGlw
YXJ0aW1lbnRvIGRpIEF1dG9tYXRpY2EgZSBJbmZvcm1hdGljYTEbMBkGA1UEAxMSTWFzc2lt
aWxpYW5vICBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCr0RolEDtxGJrmfTTX
hR6u5kE/APA3ISlbEi9apUbq1oS3U/XACl3ugqLvKFQvzJSlfZ4RB0uP/KMJA6vU2qaQvkzC
JmFW3ByWLf/cbQ5rIq7+LrJEhbbhIzmxs0s7iGFlhKIcAyVn9TljqvrMW/FFsgr3+YH/Csno
cjM7ML7GdwIDAQABo4ICszCCAq8wgZUGCWCGSAGG+EIBDQSBhxaBhElzc3VlZCB1bmRlciBw
b2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLwogaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2NhLnBvbGl0by5p
dC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBVMCgGCCsGAQUF
BzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAChh1odHRwOi8v
d3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY2EucG9s
aXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADA+BgNVHREENzA1gRttYXNzaW1p
bGlhbm8ucGFsYUBwb2xpdG8uaXSgFgYKKwYBBAGVYgIBAaAIFgYxMjE1NzUwgc0GA1UdIASB
xTCBwjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5v
cmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wOAYKKwYBBAGVYgECATAqMCgGCCsG
AQUFBwIBFhxodHRwOi8vY2EucG9saXRvLml0L2Nwcy8yLjEvMAsGA1UdDwQEAwIE8DAdBgNV
HQ4EFgQUoGwEC61StaKysoyEYPDzqAdYOhIwHwYDVR0jBBgwFoAU9AxtbZ5fTGJWOYHg3vmP
LzeghMUwDQYJKoZIhvcNAQEFBQADggEBAOvBcYuC9wO+GTbDoAUuncMiFaXjNf0bpbi/2CKz
28EeQgdBSDaIGZtUR4Kf1etIhe26V4e7Jgj6674pR2gKq31cQWUvp5ie+tk1zvBaQf6axnBz
XUL7xSJuHNpR7OUSpOb2X7TzG5wAkRHirjz37Zljsp/y0UHWfh52C2DyvGuU1f75mqqskKdh
ZC+/R7geZq/4Iqe4xP5jWpW/cFbocMM4GWOFITHr5yaigg+hbLz/lb9oaXlYSvVoJRn+jwM4
M/FQjARxQdX6bgS5DPuPRcstzILrYtwULHv6K3N0nrV6lsKY6BM1JYkWvJU8KWGUzdgXMXEv
0B7uYWZN1RuR3IoxggLAMIICvAIBATBrMGUxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eQICAWcwCQYFKw4DAhoFAKCCAaswGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjE0MTgxOTQ5WjAjBgkqhkiG9w0BCQQx
FgQU/kW/jE+0p7njGyjggs6lfu7PJVAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
egYJKwYBBAGCNxAEMW0wazBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28g
ZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkCAgFnMHwGCyqGSIb3DQEJEAILMW2gazBlMQswCQYDVQQGEwJJVDEeMBwG
A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU
b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgFnMA0GCSqGSIb3DQEBAQUABIGAIYEQ
CpUgzJHy/AmRqwH9bgJ6hXHutD3F6fdt9GSw9KosBgp2KaNOSKPcnLo9bAWV/8R1Nw007Slk
toU7avWGZamq08THUFnygQrZ12OTiGD/qTEfk6u6jCngUEygQmIhQH94HaSozopock3sqmhV
MjRW9CUFwmk3jguFz5cpdsIAAAAAAAA=
--------------ms010800040900040204050304--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEHcBlC064861; Tue, 14 Dec 2004 09:38:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBEHcBvH064860; Tue, 14 Dec 2004 09:38:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEHc9km064841 for <[e-mail]>; Tue, 14 Dec 2004 09:38:10 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E203.FF60FACE"
Subject: RE: SCVP 16 comments deadline
Date: Tue, 14 Dec 2004 12:40:26 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTiAEsYMaNoCaFBSwafF5DRGJnpSgAA2ccw
From: "Seth Hitchings" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E203.FF60FACE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

If the changes that David recommends are accepted (which I believe they
should be), then is there any reason for CertChecks to be a sequence of
check OIDs? Validation implies path construction, and status checking
implies validation. When would a client send more than one check?
=20
Seth

  _____ =20

From: [e-mail] [mailto:[e-mail]]
On Behalf Of David A. Cooper
Sent: Tuesday, December 14, 2004 11:37 AM
To: Trevor Freeman
Cc: Denis Pinkas; [e-mail]
Subject: Re: SCVP 16 comments deadline


Trevor,

There seems to be a misunderstanding here.  The check in question is:


Do revocation status checks on the certification path


In your response to Denis below, you say:


If the client has asked for revocation information, I don't see a full
path build for the client certificate is required. You may build a path
for the CA certificate which signed the CRL, but that is different.


There is a disconnect between these two statements.  The check requires
the server to perform status checks on the path.  In your response, you
refer to the CRL.  If the check only required to server to perform a
status check on the end certificate (i.e., the certificate presented in
the request), then your comment would make sense.  However, the check
requires the server to perform status checks on the path.  Since SCVP
does not allow the client to present a path to the server, the server
MUST build a certification path in order to perform the
id-stc-build-status-checked-pkc-path check, otherwise the server would
not have a certification path for which to perform status checks.

You suggest that the id-stc-build-status-checked-pkc-path check might be
used by itself in a case in which a DPD client has already been able to
build a path.  But this does not work, since the server may not provide
status checks on the same certification path as the one constructed by
the client (or the one that the client had previously obtained from the
SCVP server).  The client could increase the chances that the server
would use the path that it was interested in by providing the
certificates in the path through the intermediateCerts field, but this
would not guarantee that the server would provide status checks for this
path.

As I said in my previous message, if the client wants to server to
provide status checks for the certificates in a particular certification
path, then the client should use OCSP.  OCSP allows the client to ask
for status information for a specific set of certificates, SCVP does
not.  With SCVP, the client can only specify the trust anchor and the
end certificate; the server MUST build the remainder of the
certification path.  So, even if the client only includes the
id-stc-build-status-checked-pkc-path check, there is an implicit
requirement for the server to build a certification path.  I believe
that it makes no sense for the server to perform the
id-stc-build-status-checked-pkc-path check on an unvalidated
certification path.  That is, I believe that the only sensible use of
this feature is for the server to build a validated certification path
and then perform status checks on that path; there is no benefit to
performing status checks on an unvalidated certification path.  Given
this, it makes sense to explicitly indicate that the
id-stc-build-status-checked-pkc-path check requires the server to build
a validated certification path and do revocation status checks on that
certification path.

Dave


Trevor Freeman wrote:


* -----Original Message-----

* From: Denis Pinkas [mailto:[e-mail]]

* Sent: Monday, December 13, 2004 12:35 AM

* To: Trevor Freeman

* Cc: David A. Cooper; [e-mail]

* Subject: Re: SCVP 16 comments deadline

*=20

* Trevor,

*=20

* > David,

* > No wanting to rathole on this sine time is short, the section of the

* > document in question which Denis referred to is dealing with the set
of

* > request that the client can make to the server. We agree that the
client

* > can ask for path construction without revocation checking.

*=20

* Up to here we agree.

[TF] Good

*=20

* > I think it

* > legitimate a DPD client could ask for revocation checking because it
has

* > already be able to build a path. Conceivably a DPV client could do
the

* > same because it pervious asked for the path to be constructed and
just

* > wants the revocation data refreshed.

*=20

* Here we do not agree. If a client has already been able to build a
path,

* then he provides that path as "useful certificates" and the DPV server
will

* necessarily build the path (using or not using these "useful
certificates")

* and verify it.

*=20

* So if revocation checking is asked for by the client, this necessarily

* mandates path construction.

[TF] what there server does to process the request is orthogonal to the

section in question.  If the client has asked for revocation

information, I don't see a full path build for the client certificate is

required. You may build a path for the CA certificate which signed the

CRL, but that is different.

*=20

* Denis

*=20

*=20

* > However to get to the bottom line, is there a specific problem with
the

* > text in section 3.1.2

* > Trevor

* >

* > * -----Original Message-----

* > * From: David A. Cooper [mailto:[e-mail]]

* > * Sent: Thursday, December 09, 2004 2:22 PM

* > * To: Trevor Freeman

* > * Cc: [e-mail]

* > * Subject: Re: SCVP 16 comments deadline

* > *

* > * Trevor,

* > *

* > * I must say that I agree with Seth and Denis.  I was under the
impression

* > * that "Do revocation status checking on the certification path"
really

* > * meant "build and validated certification path to a trust anchor
and do

* > * revocation status checking on the certification path".  While I
can see

* > * that there may be circumstances in which one would request a
validated

* > * certification path without requiring revocation status checking, I
can't

* > * see requesting revocation status checking without requesting that
the

* > * path be validated.

* > *

* > * It is certainly the case that one can not "do revocation status
checking

* > * on the certification path" without also building a certification
path.

* > * Since the client can not provide a certification path, revocation
status

* > * checking must be performed on a path that is built by the server.
I

* > * suppose you could argue that this simply means that a well formed
query

* > * can not include the id-stc-build-status-checked-pkc-path without
also

* > * including either the id-stc-build-pkc-path or

* > * id-stc-build-valid-pkc-path check.  But, I see see the need for
this.

* > *

* > * A DPD client would include the id-stc-build-pkc-path along with
the

* > * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info
wantBacks.

* > * If the DPD client included the id-swb-pkc-revocation-info
wantBack, it

* > * wouldn't need to also include the
id-stc-build-status-checked-pkc-path

* > * check.  If the DPD client did not include the
id-swb-pkc-revocation-info

* > * wantBack, then would not include the
id-stc-build-status-checked-pkc-path check.

* > *

* > * So, I would argue that the id-swb-pkc-revocation-info wantBack
would

* > * only be used in the case that the client was requesting a
validated

* > * certification path.  The way that I had interpreted the currently

* > * defined checks items, an SCVP query would only include one check
since

* > * each successive check included the requirements of the previous
one:

* > * id-stc-build-valid-pkc-path included the requirement to build a
path

* > * (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path

* > * included the requirement to build a validated path

* > * (id-stc-build-valid-pkc-path).

* > *

* > * Under what circumstances can you envision a client wanting the
server to

* > * do revocation status checking on a certification path (that is

* > * constructed by the server) without also including a requirement
that the

* > * certification path be validated?   If there are no reasonable

* > * circumstances in which a client would make such a query, why is it

* > * necessary for clients to be able to construct such a query?

* > *

* > * Dave

* > *

* > * Trevor Freeman wrote:

* > *

* > * >Hi Seth,

* > * >A server can always go beyond what the client asked for. I don't
see

* > * >that as strictly necessary in all cases such as if the client
just asks

* > * >for revocation. Untimely is a matter of local server policy. What
the

* > * >server cannot do is return status or errors relating to the other

* > * >activities which  were beyond the request scope.

* > * >Trevor

* > * >

* > * While it might make sense for a client to only ask for revocation

* > * checking if the client could specify the certification path, it
does not

* > * seem to make sense given that the server chooses the certification
path

* > * for which revocation status checking will be performed.  If the
client

* > * wants to specify a set of certificates for which it only wants to
know

* > * the revocation status, that is what OCSP is for.

* > *

* > * >

* > * >* -----Original Message-----

* > * >* From: Seth Hitchings [mailto:[e-mail]]

* > * >* Sent: Wednesday, December 08, 2004 11:34 AM

* > * >* To: Trevor Freeman

* > * >* Cc: [e-mail]

* > * >* Subject: RE: SCVP 16 comments deadline

* > * >*

* > * >* Trevor,

* > * >*

* > * >* For clarification, I assume that doing revocation status checks
on a path

* > * >* implies building a validated path?

* > * >*

* > * >* If I am correct, in what case would a client ever send more
than one check?

* > * >*

* > * >* Seth

* > * >*

* > * >* -----Original Message-----

* > * >* From: [e-mail]

* > * >[mailto:[e-mail]]

* > * >* On Behalf Of

* > * >* Trevor Freeman

* > * >* Sent: Wednesday, December 08, 2004 1:42 PM

* > * >* To: Denis Pinkas

* > * >* Cc: [e-mail]

* > * >* Subject: RE: SCVP 16 comments deadline

* > * >*

* > * >*

* > * >* Denis,

* > * >* I know of several systems who's policy is never to revoke the
identity certificate because

* > * >* they have other mechanisms to address the issue.

* > * >* They are using authorization bound to the identity and they
either rely on short lived

* > * >* authorization assertions or revoke the authorization privilege
assonated with the

* > * >* identity. Therefore in those cases not checking the revocation
status of the certificate

* > * >* makes perfect sense.

* > * >* Trevor

* > * >*

* > * >* * -----Original Message-----

* > * >* * From: [e-mail]

* > * >* [mailto:[e-mail]]

* > * >* * On Behalf Of Denis Pinkas

* > * >* * Sent: Wednesday, December 08, 2004 8:01 AM

* > * >* * To: Trevor Freeman

* > * >* * Cc: [e-mail]

* > * >* * Subject: Re: SCVP 16 comments deadline

* > * >* *

* > * >* *

* > * >* * Trevor,

* > * >* *

* > * >* * > Hi Denis,

* > * >* * > Below are responses to 1-16. Others will follow later.

* > * >* *

* > * >* * I am pleased that you accepted comments 13, 14, 15 and 16.

* > * >* * Among this list, I have a further remark on comment 4.

* > * >* *

* > * >* * > * 4. Page 13. Typo. Section 3.1.2 "checks"

* > * >* * > * The two following lines are in fact one line:

* > * >* * > *

* > * >* * > * Change:

* > * >* * > *

* > * >* * > *      - Build a validated certification path to a trust
anchor; and

* > * >* * > *

* > * >* * > *      - Do revocation status checks on the certification
path.

* > * >* * > *

* > * >* * > * into:

* > * >* * > *

* > * >* * > *      - Build a validated certification path to a trust
anchor and

* > * >* * > *        do revocation status checks on the certification
path.

* > * >* * > *

* > * >* * > [TF] Since this paragraph is listing the possible checks
and building a

* > * >* * > path is a separate check to revocation checking, I think
the current

* > * >* * > text is more accurate.

* > * >* *

* > * >* * I agree that "building a path is a separate check to
revocation checking",

* > * >* * but revocation checking without building a validated path
does not make sense.

* > * >* *

* > * >* * The full text currently is:

* > * >* *

* > * >* *      - Build a certification path to a trust anchor;

* > * >* *

* > * >* *      - Build a validated certification path to a trust
anchor; and

* > * >* *

* > * >* *      - Do revocation status checks on the certification path.

* > * >* *

* > * >* * The full text should be:

* > * >* *

* > * >* *      - Build a certification path to a trust anchor;

* > * >* *

* > * >* *      - Build a validated certification path to a trust
anchor; and

* > * >* *        do revocation status checks on the certification path.

* > * >* *

* > * >* * Denis



------_=_NextPart_001_01C4E203.FF60FACE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D634173817-14122004></SPAN><FONT=20
face=3DArial><FONT color=3D#0000ff><FONT size=3D2>I<SPAN =
class=3D634173817-14122004>f=20
the changes that David recommends are accepted (which I believe they =
should be),=20
then is there any reason for CertChecks to be a sequence of check OIDs?=20
Validation implies path construction, and status checking implies =
validation.=20
When would a client send more than one =
check?</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D634173817-14122004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D634173817-14122004>Seth</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>David A.=20
Cooper<BR><B>Sent:</B> Tuesday, December 14, 2004 11:37 AM<BR><B>To:</B> =
Trevor=20
Freeman<BR><B>Cc:</B> Denis Pinkas; [e-mail]<BR><B>Subject:</B> =
Re:=20
SCVP 16 comments deadline<BR></FONT><BR></DIV>
<DIV></DIV>Trevor,<BR><BR>There seems to be a misunderstanding =
here.&nbsp; The=20
check in question is:<BR>
<BLOCKQUOTE>Do revocation status checks on the certification=20
path<BR></BLOCKQUOTE>In your response to Denis below, you say:<BR>
<BLOCKQUOTE>If the client has asked for revocation information, I don't =
see a=20
  full path build for the client certificate is required. You may build =
a path=20
  for the CA certificate which signed the CRL, but that is=20
different.<BR></BLOCKQUOTE>There is a disconnect between these two=20
statements.&nbsp; The check requires the server to perform status checks =
on=20
<U>the path</U>.&nbsp; In your response, you refer to <U>the =
CRL</U>.&nbsp; If=20
the check only required to server to perform a status check on the end=20
certificate (i.e., the certificate presented in the request), then your =
comment=20
would make sense.&nbsp; However, the check requires the server to =
perform status=20
checks on the <U>path</U>.&nbsp; Since SCVP does not allow the client to =
present=20
a path to the server, the server <U>MUST</U> build a certification path =
in order=20
to perform the id-stc-build-status-checked-pkc-path check, otherwise the =
server=20
would not have a certification path for which to perform status=20
checks.<BR><BR>You suggest that the id-stc-build-status-checked-pkc-path =
check=20
might be used by itself in a case in which a DPD client has already been =
able to=20
build a path.&nbsp; But this does not work, since the server may not =
provide=20
status checks on the same certification path as the one constructed by =
the=20
client (or the one that the client had previously obtained from the SCVP =

server).&nbsp; The client could increase the chances that the server =
would use=20
the path that it was interested in by providing the certificates in the =
path=20
through the intermediateCerts field, but this would not guarantee that =
the=20
server would provide status checks for this path.<BR><BR>As I said in my =

previous message, if the client wants to server to provide status checks =
for the=20
certificates in a particular certification path, then the client should =
use=20
OCSP.&nbsp; OCSP allows the client to ask for status information for a =
specific=20
set of certificates, SCVP does not.&nbsp; With SCVP, the client can only =
specify=20
the trust anchor and the end certificate; the server MUST build the =
remainder of=20
the certification path.&nbsp; So, even if the client only includes the=20
id-stc-build-status-checked-pkc-path check, there is an implicit =
requirement for=20
the server to build a certification path.&nbsp; I believe that it makes =
no sense=20
for the server to perform the id-stc-build-status-checked-pkc-path check =
on an=20
unvalidated certification path.&nbsp; That is, I believe that the only =
sensible=20
use of this feature is for the server to build a validated certification =
path=20
and then perform status checks on that path; there is no benefit to =
performing=20
status checks on an unvalidated certification path.&nbsp; Given this, it =
makes=20
sense to explicitly indicate that the =
id-stc-build-status-checked-pkc-path check=20
requires the server to build a validated certification path and do =
revocation=20
status checks on that certification path.<BR><BR>Dave<BR><BR><BR>Trevor =
Freeman=20
wrote:<BR>
<BLOCKQUOTE=20
cite=[e-mail].c=
orp.microsoft.com=20
type=3D"cite"><PRE wrap=3D"">* -----Original Message-----
* From: Denis Pinkas [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]
* Sent: Monday, December 13, 2004 12:35 AM
* To: Trevor Freeman
* Cc: David A. Cooper; <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]</A>
* Subject: Re: SCVP 16 comments deadline
*=20
* Trevor,
*=20
* &gt; David,
* &gt; No wanting to rathole on this sine time is short, the section of =
the
* &gt; document in question which Denis referred to is dealing with the =
set of
* &gt; request that the client can make to the server. We agree that the =
client
* &gt; can ask for path construction without revocation checking.
*=20
* Up to here we agree.
[TF] Good
*=20
* &gt; I think it
* &gt; legitimate a DPD client could ask for revocation checking because =
it has
* &gt; already be able to build a path. Conceivably a DPV client could =
do the
* &gt; same because it pervious asked for the path to be constructed and =
just
* &gt; wants the revocation data refreshed.
*=20
* Here we do not agree. If a client has already been able to build a =
path,
* then he provides that path as "useful certificates" and the DPV server =
will
* necessarily build the path (using or not using these "useful =
certificates")
* and verify it.
*=20
* So if revocation checking is asked for by the client, this necessarily
* mandates path construction.
[TF] what there server does to process the request is orthogonal to the
section in question.  If the client has asked for revocation
information, I don't see a full path build for the client certificate is
required. You may build a path for the CA certificate which signed the
CRL, but that is different.
*=20
* Denis
*=20
*=20
* &gt; However to get to the bottom line, is there a specific problem =
with the
* &gt; text in section 3.1.2
* &gt; Trevor
* &gt;
* &gt; * -----Original Message-----
* &gt; * From: David A. Cooper [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]
* &gt; * Sent: Thursday, December 09, 2004 2:22 PM
* &gt; * To: Trevor Freeman
* &gt; * Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]</A>
* &gt; * Subject: Re: SCVP 16 comments deadline
* &gt; *
* &gt; * Trevor,
* &gt; *
* &gt; * I must say that I agree with Seth and Denis.  I was under the =
impression
* &gt; * that "Do revocation status checking on the certification path" =
really
* &gt; * meant "build and validated certification path to a trust anchor =
and do
* &gt; * revocation status checking on the certification path".  While I =
can see
* &gt; * that there may be circumstances in which one would request a =
validated
* &gt; * certification path without requiring revocation status =
checking, I can't
* &gt; * see requesting revocation status checking without requesting =
that the
* &gt; * path be validated.
* &gt; *
* &gt; * It is certainly the case that one can not "do revocation status =
checking
* &gt; * on the certification path" without also building a =
certification path.
* &gt; * Since the client can not provide a certification path, =
revocation status
* &gt; * checking must be performed on a path that is built by the =
server. I
* &gt; * suppose you could argue that this simply means that a well =
formed query
* &gt; * can not include the id-stc-build-status-checked-pkc-path =
without also
* &gt; * including either the id-stc-build-pkc-path or
* &gt; * id-stc-build-valid-pkc-path check.  But, I see see the need for =
this.
* &gt; *
* &gt; * A DPD client would include the id-stc-build-pkc-path along with =
the
* &gt; * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info =
wantBacks.
* &gt; * If the DPD client included the id-swb-pkc-revocation-info =
wantBack, it
* &gt; * wouldn't need to also include the =
id-stc-build-status-checked-pkc-path
* &gt; * check.  If the DPD client did not include the =
id-swb-pkc-revocation-info
* &gt; * wantBack, then would not include the =
id-stc-build-status-checked-pkc-path check.
* &gt; *
* &gt; * So, I would argue that the id-swb-pkc-revocation-info wantBack =
would
* &gt; * only be used in the case that the client was requesting a =
validated
* &gt; * certification path.  The way that I had interpreted the =
currently
* &gt; * defined checks items, an SCVP query would only include one =
check since
* &gt; * each successive check included the requirements of the previous =
one:
* &gt; * id-stc-build-valid-pkc-path included the requirement to build a =
path
* &gt; * (id-stc-build-pkc-path) and =
id-stc-build-status-checked-pkc-path
* &gt; * included the requirement to build a validated path
* &gt; * (id-stc-build-valid-pkc-path).
* &gt; *
* &gt; * Under what circumstances can you envision a client wanting the =
server to
* &gt; * do revocation status checking on a certification path (that is
* &gt; * constructed by the server) without also including a requirement =
that the
* &gt; * certification path be validated?   If there are no reasonable
* &gt; * circumstances in which a client would make such a query, why is =
it
* &gt; * necessary for clients to be able to construct such a query?
* &gt; *
* &gt; * Dave
* &gt; *
* &gt; * Trevor Freeman wrote:
* &gt; *
* &gt; * &gt;Hi Seth,
* &gt; * &gt;A server can always go beyond what the client asked for. I =
don't see
* &gt; * &gt;that as strictly necessary in all cases such as if the =
client just asks
* &gt; * &gt;for revocation. Untimely is a matter of local server =
policy. What the
* &gt; * &gt;server cannot do is return status or errors relating to the =
other
* &gt; * &gt;activities which  were beyond the request scope.
* &gt; * &gt;Trevor
* &gt; * &gt;
* &gt; * While it might make sense for a client to only ask for =
revocation
* &gt; * checking if the client could specify the certification path, it =
does not
* &gt; * seem to make sense given that the server chooses the =
certification path
* &gt; * for which revocation status checking will be performed.  If the =
client
* &gt; * wants to specify a set of certificates for which it only wants =
to know
* &gt; * the revocation status, that is what OCSP is for.
* &gt; *
* &gt; * &gt;
* &gt; * &gt;* -----Original Message-----
* &gt; * &gt;* From: Seth Hitchings [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
m</A>]
* &gt; * &gt;* Sent: Wednesday, December 08, 2004 11:34 AM
* &gt; * &gt;* To: Trevor Freeman
* &gt; * &gt;* Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]</A>
* &gt; * &gt;* Subject: RE: SCVP 16 comments deadline
* &gt; * &gt;*
* &gt; * &gt;* Trevor,
* &gt; * &gt;*
* &gt; * &gt;* For clarification, I assume that doing revocation status =
checks on a path
* &gt; * &gt;* implies building a validated path?
* &gt; * &gt;*
* &gt; * &gt;* If I am correct, in what case would a client ever send =
more than one check?
* &gt; * &gt;*
* &gt; * &gt;* Seth
* &gt; * &gt;*
* &gt; * &gt;* -----Original Message-----
* &gt; * &gt;* From: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]=
</A>
* &gt; * &gt;[<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]
* &gt; * &gt;* On Behalf Of
* &gt; * &gt;* Trevor Freeman
* &gt; * &gt;* Sent: Wednesday, December 08, 2004 1:42 PM
* &gt; * &gt;* To: Denis Pinkas
* &gt; * &gt;* Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]</A>
* &gt; * &gt;* Subject: RE: SCVP 16 comments deadline
* &gt; * &gt;*
* &gt; * &gt;*
* &gt; * &gt;* Denis,
* &gt; * &gt;* I know of several systems who's policy is never to revoke =
the identity certificate because
* &gt; * &gt;* they have other mechanisms to address the issue.
* &gt; * &gt;* They are using authorization bound to the identity and =
they either rely on short lived
* &gt; * &gt;* authorization assertions or revoke the authorization =
privilege assonated with the
* &gt; * &gt;* identity. Therefore in those cases not checking the =
revocation status of the certificate
* &gt; * &gt;* makes perfect sense.
* &gt; * &gt;* Trevor
* &gt; * &gt;*
* &gt; * &gt;* * -----Original Message-----
* &gt; * &gt;* * From: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]=
</A>
* &gt; * &gt;* [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]
* &gt; * &gt;* * On Behalf Of Denis Pinkas
* &gt; * &gt;* * Sent: Wednesday, December 08, 2004 8:01 AM
* &gt; * &gt;* * To: Trevor Freeman
* &gt; * &gt;* * Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]</A>
* &gt; * &gt;* * Subject: Re: SCVP 16 comments deadline
* &gt; * &gt;* *
* &gt; * &gt;* *
* &gt; * &gt;* * Trevor,
* &gt; * &gt;* *
* &gt; * &gt;* * &gt; Hi Denis,
* &gt; * &gt;* * &gt; Below are responses to 1-16. Others will follow =
later.
* &gt; * &gt;* *
* &gt; * &gt;* * I am pleased that you accepted comments 13, 14, 15 and =
16.
* &gt; * &gt;* * Among this list, I have a further remark on comment 4.
* &gt; * &gt;* *
* &gt; * &gt;* * &gt; * 4. Page 13. Typo. Section 3.1.2 "checks"
* &gt; * &gt;* * &gt; * The two following lines are in fact one line:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; * Change:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Build a validated certification path to a =
trust anchor; and
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Do revocation status checks on the =
certification path.
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; * into:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Build a validated certification path to a =
trust anchor and
* &gt; * &gt;* * &gt; *        do revocation status checks on the =
certification path.
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; [TF] Since this paragraph is listing the possible =
checks and building a
* &gt; * &gt;* * &gt; path is a separate check to revocation checking, I =
think the current
* &gt; * &gt;* * &gt; text is more accurate.
* &gt; * &gt;* *
* &gt; * &gt;* * I agree that "building a path is a separate check to =
revocation checking",
* &gt; * &gt;* * but revocation checking without building a validated =
path does not make sense.
* &gt; * &gt;* *
* &gt; * &gt;* * The full text currently is:
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a certification path to a trust anchor;
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a validated certification path to a trust =
anchor; and
* &gt; * &gt;* *
* &gt; * &gt;* *      - Do revocation status checks on the certification =
path.
* &gt; * &gt;* *
* &gt; * &gt;* * The full text should be:
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a certification path to a trust anchor;
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a validated certification path to a trust =
anchor; and
* &gt; * &gt;* *        do revocation status checks on the certification =
path.
* &gt; * &gt;* *
* &gt; * &gt;* * Denis</PRE></BLOCKQUOTE><BR></BODY></HTML>

------_=_NextPart_001_01C4E203.FF60FACE--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEHMMgv060556; Tue, 14 Dec 2004 09:22:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBEHMMrT060554; Tue, 14 Dec 2004 09:22:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEHMLHo060544 for <[e-mail]>; Tue, 14 Dec 2004 09:22:21 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iBEHEamc002966; Tue, 14 Dec 2004 12:14:36 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iBEH8a2r007193; Tue, 14 Dec 2004 12:08:38 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2004 12:08:44 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: [e-mail]
Subject: Re: Proposed Changes to RFC 3280
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano,

The main reason that the nextUpdate field is needed is that CRLs are 
distributed through untrusted mechanisms.

If I get a CRL from a directory, Web server, or whatever, I can verify 
the signature on the CRL to ensure that the CRL was really issued by the 
proper authority, but there are still two possibilities:

(1) I have obtained the most recently issued CRL; or

(2) The CRL that I have obtained is not the most recent one (an 
attacker, by some means, has caused me to get an older CRL).


Since a CRL issuer can publish a new CRL at any time, I can never be 
certain that I have obtained the most recent CRL.  However, if the CRL 
includes a nextUpdate time and the current time is after the specified 
nextUpdate time, then I can be certain that I DO NOT have the most 
recent CRL.  So, if a CRL issuer always included a nextUpdate time that 
was 24 hours after the thisUpdate time, an attacker could never trick me 
into using a CRL that is more than 24 hours out of date.

If a CRL did not include a nextUpdate time and the issuer only published 
a new CRL when the revokedCertificates list changed, an attacker could 
trick me into using an old CRL, no matter how much time had passed since 
the CRL issuer had published a newer CRL.

As to your other concern, technically the nextUpdate field is not an 
expiration time.  The nextUpdate field indicates that a new CRL will be 
published no later than the specified time.  A CRL issuer may publish a 
new CRL before the nextUpdate time.  However, the CRL issuer promises 
that if the nextUpdate time has passed, then a newer CRL will have been 
published.  Even if the relying party knows, from the nextUpdate time, 
that a newer CRL must be available, the relying party can continue to 
use the older CRL.

If you are worried about the the possibility that the repository will be 
overloaded with requests from clients when the nextUpdate time in a CRL 
is reached, there are tricks that you can use to avoid this problem.  In 
"A Model of Certificate Revocation (see 
http://csrc.nist.gov/pki/PKImodels/welcome.html), I describe a technique 
that I call over-issued CRLs that helps to address this problem.

Dave


Stefan Santesson wrote:

>Massimiliano,
>
>There seem to be some confusion with your proposal.
>
>The NextUpdate field certainly don't force clients to get a new CRL when
>they expire. It is perfectly compliant already to wait to get a new CRL
>when you have a certificate to validate.
>
>Effective revocation need the NextUpdate field to know if a cashed CRL
>is still valid and CAs must make sure that there is a valid CRL
>available.
>
>However there is another problem for those systems that wants to
>pre-fetch CRLs. Because the NextUpdate field is actually used as the
>expiry date there is no real possibility within the standard to express
>when a new CRL is available if there is an overlap between CRL expiry
>and CRL update.
>
>This is why Microsoft has added support for a private optional extension
>(CRL Next publish with OID 1.3.6.1.4.1.311.21.4) which indicates when a
>new CRL is scheduled to be published (prior to expiry of old CRL).
>
>Stefan Santesson
>Microsoft Security Center of Excellence (SCOE)
> 
>
>  
>
>>-----Original Message-----
>>From: [e-mail]
>>    
>>
>>On Behalf Of Massimiliano Pala
>>Sent: den 10 december 2004 19:32
>>To: [e-mail]
>>Subject: Proposed Changes to RFC 3280
>>
>>Hello all,
>>
>>going through rfc3280 and reading the sections 5, 5.1, 5.1.2.5 about
>>CRLs and nextUpdate field one idea came into my mind.
>>The rfc enforces the use of the nextUpdate field which envisages the
>>idea that new revocation information will be available within the
>>retained time value.
>>
>>This could lead to some problems because all clients will query the
>>CRL repository upon CRL expiration.
>>Moreover, in practical environment, there is the common thought that
>>the nextUpdate filed carries the time when new revocation data will
>>be available, which (correct me if I am wrong) is not.
>>
>>So my idea is very simple, indeed. I would suggest to leave the field
>>OPTIONAL (as in ASN.1).
>>
>>If the field is not present, then compliant applications should check
>>for new CRL when validating a certificate. This is pretty the same way
>>OCSP handles the nextUpdate field within responses, isn't it?
>>
>>Indeed the default behaviour for today CAs is to issue new CRLs as
>>soon as a certificate is revoked - why being forced to issue a new
>>CRL if no new data is indeed available ?
>>
>>Let me know your comments, if there are no major objection I will
>>post a possible patch for the document to the list.
>>
>>--
>>
>>C'you,
>>
>>	Massimiliano Pala
>>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEGeaNe047075; Tue, 14 Dec 2004 08:40:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBEGeaQH047074; Tue, 14 Dec 2004 08:40:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from polito.it (terra.polito.it [130.192.3.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEGeYRr047034 for <[e-mail]>; Tue, 14 Dec 2004 08:40:35 -0800 (PST) (envelope-from [e-mail])
X-AttachExt: p7s
X-ExtScanner: Niversoft's FindAttachments (free)
Received: from [217.133.8.148] (HELO [10.5.122.1]) by polito.it (CommuniGate Pro SMTP 4.2.6) with ESMTP-TLS id 9888062 for [e-mail]; Tue, 14 Dec 2004 17:40:23 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2004 17:40:42 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Politecnico di Torino
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Proposed Changes to RFC 3280
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040305030108090200020302"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms040305030108090200020302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Santesson wrote:
> Massimiliano,
> 
> There seem to be some confusion with your proposal.
> 
> The NextUpdate field certainly don't force clients to get a new CRL when
> they expire. It is perfectly compliant already to wait to get a new CRL
> when you have a certificate to validate.
> 
> Effective revocation need the NextUpdate field to know if a cashed CRL
> is still valid and CAs must make sure that there is a valid CRL
> available.

Are you sure about this ? The nextUpdate field states that a new
CRL will be made available within that date, but it does not state
that a new CRL will not be made available BEFORE that date.
This means, you should check the repository to be sure the cached
CRL is the most updated one.

Unfortunately there is no way to be sure about the time a new CRL
is issued. But this is another issue, i guess.

> However there is another problem for those systems that wants to
> pre-fetch CRLs. Because the NextUpdate field is actually used as the
> expiry date there is no real possibility within the standard to express
> when a new CRL is available if there is an overlap between CRL expiry
> and CRL update.

This is true, but please notice that in many PKIs new CRLs are issued as
soon as a certificate is revoked. I guess a new field should be added to
address this problem and it should carry the minimum time required for
a new CRL to be publish. This could solve the problem - online CAs could
use a very small timeframe (e.g. 5mins) - while offline CAs could use
a wider timeframe (e.g. 1 day or 1 week).

But this is a bigger change and will break compatibility with existing
applications.

> This is why Microsoft has added support for a private optional extension
> (CRL Next publish with OID 1.3.6.1.4.1.311.21.4) which indicates when a
> new CRL is scheduled to be published (prior to expiry of old CRL).

As I just written, this is another problem not covered by the proposal.

Anyway I don't think the use of a *private* extension is the solution.
I would prefer the usage of a non-private extension or (but would
require more work) the definition of a new CRL format (v3?) with the
additional field in the TBSCertList to address this issue.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [e-mail]
                                                  Tel.:   [phone]
http://security.polito.it                       Fax:    +39   178  270 2077
                                                  Mobile: [phone]

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

--------------ms040305030108090200020302
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU7zCC
BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG
A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw
MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx
MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX
pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV
6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D
vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt
Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g
mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k
ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG
CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy
NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js
L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ
506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT
yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b
vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW
1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm
053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF
HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+
Azi6vNmzQwCbegU26NFazErhLS5qDXQwggU+MIIEJqADAgECAgIBaDANBgkqhkiG9w0BAQUF
ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ
dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxNDEwMDAwMFoXDTA2MTIz
MTA5MDAwMFowZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlu
bzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9sfcfWMG/mS8O69abPfnUWci
6TfUncSlfs8SzpwAsoW1/OJpGVtxq1yKQrP8WqiixEcZWSvnlOcyRj/C0tz3JLQKSAyrHKGS
Dkn5Md4HCue+L1JHQ3Ba14eQOj7rAugFgE+6LenTAvguOQl74/t9C93Ldm1NY+t1Fs36oPhP
JQ5inrZ6D8P9ol4s/ecyPhhQaU1tioqQy1d01gXTrmI2eH6Ui0AkyexVcxFpXR7qnvPV7huE
+ZTDU77t9jx24smmJuSxlA8HQS8I+qCytDhOYsKm676n1a4wpE9VunoVAm/+7tajm31ZYaxT
njX891kfFGoFi/J3tIRc67vh8Joy+wIDAQABo4ICCjCCAgYwdQYJYIZIAYb4QgENBGgWZklz
c3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9j
cHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBcBggrBgEF
BQcBAQRQME4wKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYI
KwYBBQUHMAKGFmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMIGTBgNVHSAEgYswgYgw
QwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh
L3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3
LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFKo8E8lJC1zNuNMg4MWV
lzMzXSQTMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQWBBT0DG1tnl9M
YlY5geDe+Y8vN6CExTANBgkqhkiG9w0BAQUFAAOCAQEAXx26gpm/oiG7ti2+e1Lwmnqn6jk0
ihxIxccazoTAjWzq60x+MhIJsIgRfGtv5U2XzEWc15UZru6srk8TqctT6EbqRMTCtx6mxPd6
RpKp3jepigGOkwnJsnjjUPC/tHmfJHNcll3Rk6a4OIvazlwOoCuQ8D0N9sAGtx35+T+tAyph
NU9yHtC3dpvQotLmJFo2Pr6sTy2ijCqQnHxJ2sZUEAlNEunKFP8y3uPfwvE0FEC7lONkUx+U
79yAlwPvBvASUopIQPy7BQ9IMupkj/1DmUvml/05f+DYv2x7UbiUlp1ksQXzs+WLxB2NADfn
CaPNvqphRz5KhJGOTJpc8CZ+UDCCBY8wggR3oAMCAQICAgFnMA0GCSqGSIb3DQEBBQUAMGUx
CzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMT
LVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDAy
MDMxNTAwMDBaFw0wNTEyMzExMjAwMDBaMH0xCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xMTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNh
IGUgSW5mb3JtYXRpY2ExGzAZBgNVBAMTEk1hc3NpbWlsaWFubyAgUGFsYTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAq9EaJRA7cRia5n0014UeruZBPwDwNyEpWxIvWqVG6taEt1P1
wApd7oKi7yhUL8yUpX2eEQdLj/yjCQOr1NqmkL5MwiZhVtwcli3/3G0OayKu/i6yRIW24SM5
sbNLO4hhZYSiHAMlZ/U5Y6r6zFvxRbIK9/mB/wrJ6HIzOzC+xncCAwEAAaOCArMwggKvMIGV
BglghkgBhvhCAQ0EgYcWgYRJc3N1ZWQgdW5kZXIgcG9saWNpZXM6CiBodHRwOi8vd3d3LmV1
cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8KIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Ev
aXQvY3BzLzEuMS8KIGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wEQYJYIZIAYb4QgEB
BAQDAgCwMGMGCCsGAQUFBwEBBFcwVTAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3Br
aS5vcmc6ODAyNjApBggrBgEFBQcwAoYdaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC8w
MgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NhLnBvbGl0by5pdC9jcmwwMi9jcmwuZGVyMAwG
A1UdEwEB/wQCMAAwPgYDVR0RBDcwNYEbbWFzc2ltaWxpYW5vLnBhbGFAcG9saXRvLml0oBYG
CisGAQQBlWICAQGgCBYGMTIxNTc1MIHNBgNVHSAEgcUwgcIwQwYKKwYBBAGpBwEBATA1MDMG
CCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYK
KwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0
L2Nwcy8xLjEvMDgGCisGAQQBlWIBAgEwKjAoBggrBgEFBQcCARYcaHR0cDovL2NhLnBvbGl0
by5pdC9jcHMvMi4xLzALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFKBsBAutUrWisrKMhGDw86gH
WDoSMB8GA1UdIwQYMBaAFPQMbW2eX0xiVjmB4N75jy83oITFMA0GCSqGSIb3DQEBBQUAA4IB
AQDrwXGLgvcDvhk2w6AFLp3DIhWl4zX9G6W4v9gis9vBHkIHQUg2iBmbVEeCn9XrSIXtuleH
uyYI+uu+KUdoCqt9XEFlL6eYnvrZNc7wWkH+msZwc11C+8UibhzaUezlEqTm9l+08xucAJER
4q489+2ZY7Kf8tFB1n4edgtg8rxrlNX++ZqqrJCnYWQvv0e4Hmav+CKnuMT+Y1qVv3BW6HDD
OBljhSEx6+cmooIPoWy8/5W/aGl5WEr1aCUZ/o8DODPxUIwEcUHV+m4EuQz7j0XLLcyC62Lc
FCx7+itzdJ61epbCmOgTNSWJFryVPClhlM3YFzFxL9Ae7mFmTdUbkdyKMIIFjzCCBHegAwIB
AgICAWcwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNu
aWNvIGRpIFRvcmlubzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTA0MDIwMzE1MDAwMFoXDTA1MTIzMTEyMDAwMFowfTELMAkG
A1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlubzExMC8GA1UECxMoRGlw
YXJ0aW1lbnRvIGRpIEF1dG9tYXRpY2EgZSBJbmZvcm1hdGljYTEbMBkGA1UEAxMSTWFzc2lt
aWxpYW5vICBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCr0RolEDtxGJrmfTTX
hR6u5kE/APA3ISlbEi9apUbq1oS3U/XACl3ugqLvKFQvzJSlfZ4RB0uP/KMJA6vU2qaQvkzC
JmFW3ByWLf/cbQ5rIq7+LrJEhbbhIzmxs0s7iGFlhKIcAyVn9TljqvrMW/FFsgr3+YH/Csno
cjM7ML7GdwIDAQABo4ICszCCAq8wgZUGCWCGSAGG+EIBDQSBhxaBhElzc3VlZCB1bmRlciBw
b2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLwogaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2NhLnBvbGl0by5p
dC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBVMCgGCCsGAQUF
BzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAChh1odHRwOi8v
d3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY2EucG9s
aXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADA+BgNVHREENzA1gRttYXNzaW1p
bGlhbm8ucGFsYUBwb2xpdG8uaXSgFgYKKwYBBAGVYgIBAaAIFgYxMjE1NzUwgc0GA1UdIASB
xTCBwjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5v
cmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wOAYKKwYBBAGVYgECATAqMCgGCCsG
AQUFBwIBFhxodHRwOi8vY2EucG9saXRvLml0L2Nwcy8yLjEvMAsGA1UdDwQEAwIE8DAdBgNV
HQ4EFgQUoGwEC61StaKysoyEYPDzqAdYOhIwHwYDVR0jBBgwFoAU9AxtbZ5fTGJWOYHg3vmP
LzeghMUwDQYJKoZIhvcNAQEFBQADggEBAOvBcYuC9wO+GTbDoAUuncMiFaXjNf0bpbi/2CKz
28EeQgdBSDaIGZtUR4Kf1etIhe26V4e7Jgj6674pR2gKq31cQWUvp5ie+tk1zvBaQf6axnBz
XUL7xSJuHNpR7OUSpOb2X7TzG5wAkRHirjz37Zljsp/y0UHWfh52C2DyvGuU1f75mqqskKdh
ZC+/R7geZq/4Iqe4xP5jWpW/cFbocMM4GWOFITHr5yaigg+hbLz/lb9oaXlYSvVoJRn+jwM4
M/FQjARxQdX6bgS5DPuPRcstzILrYtwULHv6K3N0nrV6lsKY6BM1JYkWvJU8KWGUzdgXMXEv
0B7uYWZN1RuR3IoxggLAMIICvAIBATBrMGUxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eQICAWcwCQYFKw4DAhoFAKCCAaswGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjE0MTY0MDQyWjAjBgkqhkiG9w0BCQQx
FgQUjv47IzBKR4Fzs2csixhh/mhC+HwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
egYJKwYBBAGCNxAEMW0wazBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28g
ZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkCAgFnMHwGCyqGSIb3DQEJEAILMW2gazBlMQswCQYDVQQGEwJJVDEeMBwG
A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU
b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgFnMA0GCSqGSIb3DQEBAQUABIGAToh6
y0zo3+VwI89Y0rfL9g/85PpXRd1H30+Q2asgDQrVKRPHbLu4c1YorIt4cDdWyxXX2Z18irvW
kGo3hDYN3aydXRyWKa6TXwBlnBmQ712pqhUBzJVPDtnw3Mc+fwAl1IZ8HrkoW79CyfBFNvyQ
L3NigGzkz4hir+dxVEbcVWwAAAAAAAA=
--------------ms040305030108090200020302--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEGdGjX045555; Tue, 14 Dec 2004 08:39:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBEGdGPX045554; Tue, 14 Dec 2004 08:39:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEGdFwF045544 for <[e-mail]>; Tue, 14 Dec 2004 08:39:15 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iBEGbnmc014457; Tue, 14 Dec 2004 11:37:50 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iBEGaP2r027460; Tue, 14 Dec 2004 11:36:26 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2004 11:36:34 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Trevor,<br>
<br>
There seems to be a misunderstanding here.&nbsp; The check in question is:<br>
<blockquote>Do revocation status checks on the certification path<br>
</blockquote>
In your response to Denis below, you say:<br>
<blockquote> If the client has asked for revocation information, I
don't see a full path build for the client certificate is required. You
may build a path for the CA certificate which signed the CRL, but that
is different.<br>
</blockquote>
There is a disconnect between these two statements.&nbsp; The check requires
the server to perform status checks on <u>the path</u>.&nbsp; In your
response, you refer to <u>the CRL</u>.&nbsp; If the check only required to
server to perform a status check on the end certificate (i.e., the
certificate presented in the request), then your comment would make
sense.&nbsp; However, the check requires the server to perform status checks
on the <u>path</u>.&nbsp; Since SCVP does not allow the client to present a
path to the server, the server <u>MUST</u> build a certification path
in order to perform the id-stc-build-status-checked-pkc-path check,
otherwise the server would not have a certification path for which to
perform status checks.<br>
<br>
You suggest that the id-stc-build-status-checked-pkc-path check might
be used by itself in a case in which a DPD client has already been able
to build a path.&nbsp; But this does not work, since the server may not
provide status checks on the same certification path as the one
constructed by the client (or the one that the client had previously
obtained from the SCVP server).&nbsp; The client could increase the chances
that the server would use the path that it was interested in by
providing the certificates in the path through the intermediateCerts
field, but this would not guarantee that the server would provide
status checks for this path.<br>
<br>
As I said in my previous message, if the client wants to server to
provide status checks for the certificates in a particular
certification path, then the client should use OCSP.&nbsp; OCSP allows the
client to ask for status information for a specific set of
certificates, SCVP does not.&nbsp; With SCVP, the client can only specify
the trust anchor and the end certificate; the server MUST build the
remainder of the certification path.&nbsp; So, even if the client only
includes the id-stc-build-status-checked-pkc-path check, there is an
implicit requirement for the server to build a certification path.&nbsp; I
believe that it makes no sense for the server to perform the
id-stc-build-status-checked-pkc-path check on an unvalidated
certification path.&nbsp; That is, I believe that the only sensible use of
this feature is for the server to build a validated certification path
and then perform status checks on that path; there is no benefit to
performing status checks on an unvalidated certification path.&nbsp; Given
this, it makes sense to explicitly indicate that the
id-stc-build-status-checked-pkc-path check requires the server to build
a validated certification path and do revocation status checks on that
certification path.<br>
<br>
Dave<br>
<br>
<br>
Trevor Freeman wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">
* -----Original Message-----
* From: Denis Pinkas [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
* Sent: Monday, December 13, 2004 12:35 AM
* To: Trevor Freeman
* Cc: David A. Cooper; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* &gt; David,
* &gt; No wanting to rathole on this sine time is short, the section of the
* &gt; document in question which Denis referred to is dealing with the set of
* &gt; request that the client can make to the server. We agree that the client
* &gt; can ask for path construction without revocation checking.
* 
* Up to here we agree.
[TF] Good
* 
* &gt; I think it
* &gt; legitimate a DPD client could ask for revocation checking because it has
* &gt; already be able to build a path. Conceivably a DPV client could do the
* &gt; same because it pervious asked for the path to be constructed and just
* &gt; wants the revocation data refreshed.
* 
* Here we do not agree. If a client has already been able to build a path,
* then he provides that path as "useful certificates" and the DPV server will
* necessarily build the path (using or not using these "useful certificates")
* and verify it.
* 
* So if revocation checking is asked for by the client, this necessarily
* mandates path construction.
[TF] what there server does to process the request is orthogonal to the
section in question.  If the client has asked for revocation
information, I don't see a full path build for the client certificate is
required. You may build a path for the CA certificate which signed the
CRL, but that is different.
* 
* Denis
* 
* 
* &gt; However to get to the bottom line, is there a specific problem with the
* &gt; text in section 3.1.2
* &gt; Trevor
* &gt;
* &gt; * -----Original Message-----
* &gt; * From: David A. Cooper [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
* &gt; * Sent: Thursday, December 09, 2004 2:22 PM
* &gt; * To: Trevor Freeman
* &gt; * Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
* &gt; * Subject: Re: SCVP 16 comments deadline
* &gt; *
* &gt; * Trevor,
* &gt; *
* &gt; * I must say that I agree with Seth and Denis.  I was under the impression
* &gt; * that "Do revocation status checking on the certification path" really
* &gt; * meant "build and validated certification path to a trust anchor and do
* &gt; * revocation status checking on the certification path".  While I can see
* &gt; * that there may be circumstances in which one would request a validated
* &gt; * certification path without requiring revocation status checking, I can't
* &gt; * see requesting revocation status checking without requesting that the
* &gt; * path be validated.
* &gt; *
* &gt; * It is certainly the case that one can not "do revocation status checking
* &gt; * on the certification path" without also building a certification path.
* &gt; * Since the client can not provide a certification path, revocation status
* &gt; * checking must be performed on a path that is built by the server. I
* &gt; * suppose you could argue that this simply means that a well formed query
* &gt; * can not include the id-stc-build-status-checked-pkc-path without also
* &gt; * including either the id-stc-build-pkc-path or
* &gt; * id-stc-build-valid-pkc-path check.  But, I see see the need for this.
* &gt; *
* &gt; * A DPD client would include the id-stc-build-pkc-path along with the
* &gt; * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info wantBacks.
* &gt; * If the DPD client included the id-swb-pkc-revocation-info wantBack, it
* &gt; * wouldn't need to also include the id-stc-build-status-checked-pkc-path
* &gt; * check.  If the DPD client did not include the id-swb-pkc-revocation-info
* &gt; * wantBack, then would not include the id-stc-build-status-checked-pkc-path check.
* &gt; *
* &gt; * So, I would argue that the id-swb-pkc-revocation-info wantBack would
* &gt; * only be used in the case that the client was requesting a validated
* &gt; * certification path.  The way that I had interpreted the currently
* &gt; * defined checks items, an SCVP query would only include one check since
* &gt; * each successive check included the requirements of the previous one:
* &gt; * id-stc-build-valid-pkc-path included the requirement to build a path
* &gt; * (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
* &gt; * included the requirement to build a validated path
* &gt; * (id-stc-build-valid-pkc-path).
* &gt; *
* &gt; * Under what circumstances can you envision a client wanting the server to
* &gt; * do revocation status checking on a certification path (that is
* &gt; * constructed by the server) without also including a requirement that the
* &gt; * certification path be validated?   If there are no reasonable
* &gt; * circumstances in which a client would make such a query, why is it
* &gt; * necessary for clients to be able to construct such a query?
* &gt; *
* &gt; * Dave
* &gt; *
* &gt; * Trevor Freeman wrote:
* &gt; *
* &gt; * &gt;Hi Seth,
* &gt; * &gt;A server can always go beyond what the client asked for. I don't see
* &gt; * &gt;that as strictly necessary in all cases such as if the client just asks
* &gt; * &gt;for revocation. Untimely is a matter of local server policy. What the
* &gt; * &gt;server cannot do is return status or errors relating to the other
* &gt; * &gt;activities which  were beyond the request scope.
* &gt; * &gt;Trevor
* &gt; * &gt;
* &gt; * While it might make sense for a client to only ask for revocation
* &gt; * checking if the client could specify the certification path, it does not
* &gt; * seem to make sense given that the server chooses the certification path
* &gt; * for which revocation status checking will be performed.  If the client
* &gt; * wants to specify a set of certificates for which it only wants to know
* &gt; * the revocation status, that is what OCSP is for.
* &gt; *
* &gt; * &gt;
* &gt; * &gt;* -----Original Message-----
* &gt; * &gt;* From: Seth Hitchings [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
* &gt; * &gt;* Sent: Wednesday, December 08, 2004 11:34 AM
* &gt; * &gt;* To: Trevor Freeman
* &gt; * &gt;* Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;* Subject: RE: SCVP 16 comments deadline
* &gt; * &gt;*
* &gt; * &gt;* Trevor,
* &gt; * &gt;*
* &gt; * &gt;* For clarification, I assume that doing revocation status checks on a path
* &gt; * &gt;* implies building a validated path?
* &gt; * &gt;*
* &gt; * &gt;* If I am correct, in what case would a client ever send more than one check?
* &gt; * &gt;*
* &gt; * &gt;* Seth
* &gt; * &gt;*
* &gt; * &gt;* -----Original Message-----
* &gt; * &gt;* From: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;[<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
* &gt; * &gt;* On Behalf Of
* &gt; * &gt;* Trevor Freeman
* &gt; * &gt;* Sent: Wednesday, December 08, 2004 1:42 PM
* &gt; * &gt;* To: Denis Pinkas
* &gt; * &gt;* Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;* Subject: RE: SCVP 16 comments deadline
* &gt; * &gt;*
* &gt; * &gt;*
* &gt; * &gt;* Denis,
* &gt; * &gt;* I know of several systems who's policy is never to revoke the identity certificate because
* &gt; * &gt;* they have other mechanisms to address the issue.
* &gt; * &gt;* They are using authorization bound to the identity and they either rely on short lived
* &gt; * &gt;* authorization assertions or revoke the authorization privilege assonated with the
* &gt; * &gt;* identity. Therefore in those cases not checking the revocation status of the certificate
* &gt; * &gt;* makes perfect sense.
* &gt; * &gt;* Trevor
* &gt; * &gt;*
* &gt; * &gt;* * -----Original Message-----
* &gt; * &gt;* * From: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;* [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
* &gt; * &gt;* * On Behalf Of Denis Pinkas
* &gt; * &gt;* * Sent: Wednesday, December 08, 2004 8:01 AM
* &gt; * &gt;* * To: Trevor Freeman
* &gt; * &gt;* * Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
* &gt; * &gt;* * Subject: Re: SCVP 16 comments deadline
* &gt; * &gt;* *
* &gt; * &gt;* *
* &gt; * &gt;* * Trevor,
* &gt; * &gt;* *
* &gt; * &gt;* * &gt; Hi Denis,
* &gt; * &gt;* * &gt; Below are responses to 1-16. Others will follow later.
* &gt; * &gt;* *
* &gt; * &gt;* * I am pleased that you accepted comments 13, 14, 15 and 16.
* &gt; * &gt;* * Among this list, I have a further remark on comment 4.
* &gt; * &gt;* *
* &gt; * &gt;* * &gt; * 4. Page 13. Typo. Section 3.1.2 "checks"
* &gt; * &gt;* * &gt; * The two following lines are in fact one line:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; * Change:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Build a validated certification path to a trust anchor; and
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Do revocation status checks on the certification path.
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; * into:
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; *      - Build a validated certification path to a trust anchor and
* &gt; * &gt;* * &gt; *        do revocation status checks on the certification path.
* &gt; * &gt;* * &gt; *
* &gt; * &gt;* * &gt; [TF] Since this paragraph is listing the possible checks and building a
* &gt; * &gt;* * &gt; path is a separate check to revocation checking, I think the current
* &gt; * &gt;* * &gt; text is more accurate.
* &gt; * &gt;* *
* &gt; * &gt;* * I agree that "building a path is a separate check to revocation checking",
* &gt; * &gt;* * but revocation checking without building a validated path does not make sense.
* &gt; * &gt;* *
* &gt; * &gt;* * The full text currently is:
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a certification path to a trust anchor;
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a validated certification path to a trust anchor; and
* &gt; * &gt;* *
* &gt; * &gt;* *      - Do revocation status checks on the certification path.
* &gt; * &gt;* *
* &gt; * &gt;* * The full text should be:
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a certification path to a trust anchor;
* &gt; * &gt;* *
* &gt; * &gt;* *      - Build a validated certification path to a trust anchor; and
* &gt; * &gt;* *        do revocation status checks on the certification path.
* &gt; * &gt;* *
* &gt; * &gt;* * Denis</pre>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEBIIVw009432; Tue, 14 Dec 2004 03:18:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBEBIIBM009431; Tue, 14 Dec 2004 03:18:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from polito.it (terra.polito.it [130.192.3.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBEBIFh8009393 for <[e-mail]>; Tue, 14 Dec 2004 03:18:17 -0800 (PST) (envelope-from [e-mail])
X-AttachExt: p7s
X-ExtScanner: Niversoft's FindAttachments (free)
Received: from [217.133.8.148] (HELO [10.5.122.1]) by polito.it (CommuniGate Pro SMTP 4.2.6) with ESMTP-TLS id 9808897; Tue, 14 Dec 2004 12:17:58 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2004 12:18:21 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Politecnico di Torino
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / VPNC <[e-mail]>
CC: [e-mail]
Subject: Re: Proposed Changes to RFC 3280
References: <[e-mail]> <p06200700bde0da096304@[10.20.30.249]>
In-Reply-To: <p06200700bde0da096304@[10.20.30.249]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080809030309070105060304"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms080809030309070105060304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul Hoffman / VPNC wrote:
[...]
> "Could", yes, but so far, we have not heard that this is a problem in 
> current deployments.

This is true, anyway also you said it "Could" lead to problems, therefore
we should change this, I guess.

[...]
> Maybe I'm misunderstanding the proposal, but it seems like this would 
> cause *massive* problems for currently-deployed systems that expect and 
> rely on the nextUpdate field.

I don't see these *massive* problems for applications here, indeed as
the ASN.1 states it is an OPTIONAL parameter, an application should
already check the existence of the field before relying on its value...
... I guess these are the basis for good code writing.

Moreover the nextUpdate field (as it is described) carries information
on the date by which the next CRL will be issued, anyway new revocation
data could be made available any time sooner... this means that if I want to
be sure about updated revocation data, I should look at the repository for
new CRLs, nevertheless what the nextUpdate filed value is.

I guess this is not a big change in current software. Indeed there are
examples of software which lets the user to decide when to check for new
CRLs (e.g. once per day).

>> Indeed the default behaviour for today CAs is to issue new CRLs as
>> soon as a certificate is revoked
> 
> 
> That may be true for some systems, but it certainly isn't true for others.
> 
>>  - why being forced to issue a new
>> CRL if no new data is indeed available ?
> 
> 
> Because it is cheap for the CA to do.

This is true. My proposal wants to let CAs establish whether or not to put
the nextUpdate field into CRLs. This will obviously not touch currently
deployed policies (and applications) if the chosen behaviour is to put the
nextUpdate field into CRLs.

By stating the nextUpdate field as optional, I don't want to force CAs not
to use the field.

Please let me know if you have any new comments or objections to the
proposal.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [e-mail]
                                                 Tel.:   [phone]
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: [phone]

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

--------------ms080809030309070105060304
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU7zCC
BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG
A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw
MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx
MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX
pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV
6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D
vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt
Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g
mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k
ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG
CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy
NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js
L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ
506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT
yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b
vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW
1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm
053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF
HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+
Azi6vNmzQwCbegU26NFazErhLS5qDXQwggU+MIIEJqADAgECAgIBaDANBgkqhkiG9w0BAQUF
ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ
dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxNDEwMDAwMFoXDTA2MTIz
MTA5MDAwMFowZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlu
bzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9sfcfWMG/mS8O69abPfnUWci
6TfUncSlfs8SzpwAsoW1/OJpGVtxq1yKQrP8WqiixEcZWSvnlOcyRj/C0tz3JLQKSAyrHKGS
Dkn5Md4HCue+L1JHQ3Ba14eQOj7rAugFgE+6LenTAvguOQl74/t9C93Ldm1NY+t1Fs36oPhP
JQ5inrZ6D8P9ol4s/ecyPhhQaU1tioqQy1d01gXTrmI2eH6Ui0AkyexVcxFpXR7qnvPV7huE
+ZTDU77t9jx24smmJuSxlA8HQS8I+qCytDhOYsKm676n1a4wpE9VunoVAm/+7tajm31ZYaxT
njX891kfFGoFi/J3tIRc67vh8Joy+wIDAQABo4ICCjCCAgYwdQYJYIZIAYb4QgENBGgWZklz
c3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9j
cHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBcBggrBgEF
BQcBAQRQME4wKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYI
KwYBBQUHMAKGFmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMIGTBgNVHSAEgYswgYgw
QwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh
L3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3
LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFKo8E8lJC1zNuNMg4MWV
lzMzXSQTMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQWBBT0DG1tnl9M
YlY5geDe+Y8vN6CExTANBgkqhkiG9w0BAQUFAAOCAQEAXx26gpm/oiG7ti2+e1Lwmnqn6jk0
ihxIxccazoTAjWzq60x+MhIJsIgRfGtv5U2XzEWc15UZru6srk8TqctT6EbqRMTCtx6mxPd6
RpKp3jepigGOkwnJsnjjUPC/tHmfJHNcll3Rk6a4OIvazlwOoCuQ8D0N9sAGtx35+T+tAyph
NU9yHtC3dpvQotLmJFo2Pr6sTy2ijCqQnHxJ2sZUEAlNEunKFP8y3uPfwvE0FEC7lONkUx+U
79yAlwPvBvASUopIQPy7BQ9IMupkj/1DmUvml/05f+DYv2x7UbiUlp1ksQXzs+WLxB2NADfn
CaPNvqphRz5KhJGOTJpc8CZ+UDCCBY8wggR3oAMCAQICAgFnMA0GCSqGSIb3DQEBBQUAMGUx
CzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMT
LVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDAy
MDMxNTAwMDBaFw0wNTEyMzExMjAwMDBaMH0xCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xMTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNh
IGUgSW5mb3JtYXRpY2ExGzAZBgNVBAMTEk1hc3NpbWlsaWFubyAgUGFsYTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAq9EaJRA7cRia5n0014UeruZBPwDwNyEpWxIvWqVG6taEt1P1
wApd7oKi7yhUL8yUpX2eEQdLj/yjCQOr1NqmkL5MwiZhVtwcli3/3G0OayKu/i6yRIW24SM5
sbNLO4hhZYSiHAMlZ/U5Y6r6zFvxRbIK9/mB/wrJ6HIzOzC+xncCAwEAAaOCArMwggKvMIGV
BglghkgBhvhCAQ0EgYcWgYRJc3N1ZWQgdW5kZXIgcG9saWNpZXM6CiBodHRwOi8vd3d3LmV1
cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8KIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Ev
aXQvY3BzLzEuMS8KIGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wEQYJYIZIAYb4QgEB
BAQDAgCwMGMGCCsGAQUFBwEBBFcwVTAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3Br
aS5vcmc6ODAyNjApBggrBgEFBQcwAoYdaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC8w
MgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NhLnBvbGl0by5pdC9jcmwwMi9jcmwuZGVyMAwG
A1UdEwEB/wQCMAAwPgYDVR0RBDcwNYEbbWFzc2ltaWxpYW5vLnBhbGFAcG9saXRvLml0oBYG
CisGAQQBlWICAQGgCBYGMTIxNTc1MIHNBgNVHSAEgcUwgcIwQwYKKwYBBAGpBwEBATA1MDMG
CCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYK
KwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0
L2Nwcy8xLjEvMDgGCisGAQQBlWIBAgEwKjAoBggrBgEFBQcCARYcaHR0cDovL2NhLnBvbGl0
by5pdC9jcHMvMi4xLzALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFKBsBAutUrWisrKMhGDw86gH
WDoSMB8GA1UdIwQYMBaAFPQMbW2eX0xiVjmB4N75jy83oITFMA0GCSqGSIb3DQEBBQUAA4IB
AQDrwXGLgvcDvhk2w6AFLp3DIhWl4zX9G6W4v9gis9vBHkIHQUg2iBmbVEeCn9XrSIXtuleH
uyYI+uu+KUdoCqt9XEFlL6eYnvrZNc7wWkH+msZwc11C+8UibhzaUezlEqTm9l+08xucAJER
4q489+2ZY7Kf8tFB1n4edgtg8rxrlNX++ZqqrJCnYWQvv0e4Hmav+CKnuMT+Y1qVv3BW6HDD
OBljhSEx6+cmooIPoWy8/5W/aGl5WEr1aCUZ/o8DODPxUIwEcUHV+m4EuQz7j0XLLcyC62Lc
FCx7+itzdJ61epbCmOgTNSWJFryVPClhlM3YFzFxL9Ae7mFmTdUbkdyKMIIFjzCCBHegAwIB
AgICAWcwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNu
aWNvIGRpIFRvcmlubzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTA0MDIwMzE1MDAwMFoXDTA1MTIzMTEyMDAwMFowfTELMAkG
A1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlubzExMC8GA1UECxMoRGlw
YXJ0aW1lbnRvIGRpIEF1dG9tYXRpY2EgZSBJbmZvcm1hdGljYTEbMBkGA1UEAxMSTWFzc2lt
aWxpYW5vICBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCr0RolEDtxGJrmfTTX
hR6u5kE/APA3ISlbEi9apUbq1oS3U/XACl3ugqLvKFQvzJSlfZ4RB0uP/KMJA6vU2qaQvkzC
JmFW3ByWLf/cbQ5rIq7+LrJEhbbhIzmxs0s7iGFlhKIcAyVn9TljqvrMW/FFsgr3+YH/Csno
cjM7ML7GdwIDAQABo4ICszCCAq8wgZUGCWCGSAGG+EIBDQSBhxaBhElzc3VlZCB1bmRlciBw
b2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLwogaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2NhLnBvbGl0by5p
dC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBVMCgGCCsGAQUF
BzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAChh1odHRwOi8v
d3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY2EucG9s
aXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADA+BgNVHREENzA1gRttYXNzaW1p
bGlhbm8ucGFsYUBwb2xpdG8uaXSgFgYKKwYBBAGVYgIBAaAIFgYxMjE1NzUwgc0GA1UdIASB
xTCBwjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5v
cmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wOAYKKwYBBAGVYgECATAqMCgGCCsG
AQUFBwIBFhxodHRwOi8vY2EucG9saXRvLml0L2Nwcy8yLjEvMAsGA1UdDwQEAwIE8DAdBgNV
HQ4EFgQUoGwEC61StaKysoyEYPDzqAdYOhIwHwYDVR0jBBgwFoAU9AxtbZ5fTGJWOYHg3vmP
LzeghMUwDQYJKoZIhvcNAQEFBQADggEBAOvBcYuC9wO+GTbDoAUuncMiFaXjNf0bpbi/2CKz
28EeQgdBSDaIGZtUR4Kf1etIhe26V4e7Jgj6674pR2gKq31cQWUvp5ie+tk1zvBaQf6axnBz
XUL7xSJuHNpR7OUSpOb2X7TzG5wAkRHirjz37Zljsp/y0UHWfh52C2DyvGuU1f75mqqskKdh
ZC+/R7geZq/4Iqe4xP5jWpW/cFbocMM4GWOFITHr5yaigg+hbLz/lb9oaXlYSvVoJRn+jwM4
M/FQjARxQdX6bgS5DPuPRcstzILrYtwULHv6K3N0nrV6lsKY6BM1JYkWvJU8KWGUzdgXMXEv
0B7uYWZN1RuR3IoxggLAMIICvAIBATBrMGUxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eQICAWcwCQYFKw4DAhoFAKCCAaswGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjE0MTExODIxWjAjBgkqhkiG9w0BCQQx
FgQUWSHsJ1IN1tVu4F4k59JWx/kwd54wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
egYJKwYBBAGCNxAEMW0wazBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28g
ZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkCAgFnMHwGCyqGSIb3DQEJEAILMW2gazBlMQswCQYDVQQGEwJJVDEeMBwG
A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU
b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgFnMA0GCSqGSIb3DQEBAQUABIGAYP8B
rnVelQJ1DaYWHqqC8Uf/Cye2DawCQfZUyyVyBoMdXu28nS+wvK2SJBoGrual4stAyAiN82iU
ywnTC62un1JDvNOrZoHsTELSufvDKee2aukjk+RHwIQLTGLQKLrJn4APNP0qPvB1rljG4GRc
GOS/PSK8MYUCbww6FgPpHXwAAAAAAAA=
--------------ms080809030309070105060304--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDLLrho011394; Mon, 13 Dec 2004 13:21:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDLLrpc011393; Mon, 13 Dec 2004 13:21:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDLLmfn011370 for <[e-mail]>; Mon, 13 Dec 2004 13:21:48 -0800 (PST) (envelope-from [e-mail])
Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id DFBC97030B for <[e-mail]>; Mon, 13 Dec 2004 13:21:51 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "IETF-PKIX" <[e-mail]>
Subject: Draft-ietf-pkix-rfc2511bis-07
Date: Mon, 13 Dec 2004 13:30:56 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcThWwept5M0OIEuR8enDSXlEmbtFA==
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As advertized this draft is now under new editorship.  As the new editor
there are a number of issues that I fill still need to be resolved before
this draft can go to last call.  If there is no help forth coming then I
will be making arbitrary decions on these issue.

Additionally, if anyone has kept any of the final reports from the interop
trials for CMP, I would like to see the sections that relate to CRMF.

You can easily find the open issues and questions by searching for [[[ in
the document.

1.  Section 4.1 - I have a partial answer for this question dealing with non
DN style names that are authenticated, but are not actually either subject
names (DNs) or subject alt names (General Names).  The only real question at
this point is should this rational be documented.

2.  Section 4.2 - I am worried about the possiblity of somebody copying an
encrypted private key being sent to the CA/RA and then copying it into their
own certificate request.  They could then later request a key recovery from
the CA/RA and get back somebody elses private key.  This is the reason that
I am worried about how a POP proof is done here.  One potential answer is to
include the authenticated identity along with the private key in the
encrypted block.

3.  Section 4.2 - We MUST solve the question of what the contents of the
encrypted blob look like.  One potential answer is to obsolete thisMessage
and reaplace it with an EnvelopedData then all that needs to be covered is
the format of the encrypted key plus any POP info required.

4.  Section 4.3 - Does the DH section need to be expanded so that any key
agreement key pair can be used?  This can be done by adding a MAC alg and
value pair to the end of the POPOPrivKey choice (and potentially obsoleting
the dhMAC element).

5.  Section 4.4 - Two questions regarding guidence for the number of
iterations and the amount of salt to be used.  We need a cryptographer to
give us some guidelines for these details, or atleast need to set some
minimums.

6.  Section 6.1 & 6.2 - The content of these controls is not well defined
and a couple of questions regarding this are asked.  This may have been
addressed in the interop by adding some undocumented restrictions.

7.  Section 6.4 - There are a couple of archive questions here.  At this
point my inclination is to kill the entire section unless somebody wants to
make it acutally work.

8.  Section 6.8 - Ditto here.

9.  Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%"   The parsing is
difficult (but not impossible) due to the overload of the % token.

Jim






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDKYBYO097665; Mon, 13 Dec 2004 12:34:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDKYBZu097664; Mon, 13 Dec 2004 12:34:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDKY9Za097658 for <[e-mail]>; Mon, 13 Dec 2004 12:34:10 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16403; Mon, 13 Dec 2004 15:34:11 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc2511bis-07.txt
Date: Mon, 13 Dec 2004 15:34:11 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate 
			  Request Message Format (CRMF)
	Author(s)	: J. Schaad 
	Filename	: draft-ietf-pkix-rfc2511bis-07.txt
	Pages		: 33
	Date		: 2004-12-13
	
This document describes the Certificate Request Message Format (CRMF) 
   syntax and semantics.  This syntax is used to convey a request for a 
   certificate to a Certification Authority (CA), possibly via a 
   Registration Authority (RA), for the purposes of X.509 certificate 
   production.  The request will typically include a public key and 
   associated registration information.  This document does not define a 
   certificate request protocol

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-rfc2511bis-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc2511bis-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc2511bis-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc2511bis-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDJ6cK4061339; Mon, 13 Dec 2004 11:06:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDJ6cBZ061337; Mon, 13 Dec 2004 11:06:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDJ6bAP061327 for <[e-mail]>; Mon, 13 Dec 2004 11:06:37 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Dec 2004 11:06:30 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 13 Dec 2004 11:06:34 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Mon, 13 Dec 2004 11:06:39 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTg7qEAoqar6iReSGaUY49LQ/+Y5gAV2DCg
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "David A. Cooper" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Dec 2004 19:06:34.0323 (UTC) FILETIME=[DCE5E230:01C4E146]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBDJ6bAP061332
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Denis Pinkas [mailto:[e-mail]]
* Sent: Monday, December 13, 2004 12:35 AM
* To: Trevor Freeman
* Cc: David A. Cooper; [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* > David,
* > No wanting to rathole on this sine time is short, the section of the
* > document in question which Denis referred to is dealing with the set
of
* > request that the client can make to the server. We agree that the
client
* > can ask for path construction without revocation checking.
* 
* Up to here we agree.
[TF] Good
* 
* > I think it
* > legitimate a DPD client could ask for revocation checking because it
has
* > already be able to build a path. Conceivably a DPV client could do
the
* > same because it pervious asked for the path to be constructed and
just
* > wants the revocation data refreshed.
* 
* Here we do not agree. If a client has already been able to build a
path,
* then he provides that path as "useful certificates" and the DPV server
* will
* necessarily build the path (using or not using these "useful
* certificates")
* and verify it.
* 
* So if revocation checking is asked for by the client, this necessarily
* mandates path construction.
[TF] what there server does to process the request is orthogonal to the
section in question.  If the client has asked for revocation
information, I don't see a full path build for the client certificate is
required. You may build a path for the CA certificate which signed the
CRL, but that is different.
* 
* Denis
* 
* 
* > However to get to the bottom line, is there a specific problem with
the
* > text in section 3.1.2
* > Trevor
* >
* > * -----Original Message-----
* > * From: David A. Cooper [mailto:[e-mail]]
* > * Sent: Thursday, December 09, 2004 2:22 PM
* > * To: Trevor Freeman
* > * Cc: [e-mail]
* > * Subject: Re: SCVP 16 comments deadline
* > *
* > * Trevor,
* > *
* > * I must say that I agree with Seth and Denis.  I was under the
* > impression
* > * that "Do revocation status checking on the certification path"
really
* > * meant "build and validated certification path to a trust anchor
and do
* > * revocation status checking on the certification path".  While I
can
* > see
* > * that there may be circumstances in which one would request a
validated
* > * certification path without requiring revocation status checking, I
* > can't
* > * see requesting revocation status checking without requesting that
the
* > * path be validated.
* > *
* > * It is certainly the case that one can not "do revocation status
* > checking
* > * on the certification path" without also building a certification
path.
* > * Since the client can not provide a certification path, revocation
* > status
* > * checking must be performed on a path that is built by the server.
I
* > * suppose you could argue that this simply means that a well formed
* > query
* > * can not include the id-stc-build-status-checked-pkc-path without
also
* > * including either the id-stc-build-pkc-path or
* > * id-stc-build-valid-pkc-path check.  But, I see see the need for
this.
* > *
* > * A DPD client would include the id-stc-build-pkc-path along with
the
* > * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info
wantBacks.
* > * If the DPD client included the id-swb-pkc-revocation-info
wantBack, it
* > * wouldn't need to also include the
id-stc-build-status-checked-pkc-path
* > * check.  If the DPD client did not include the
* > id-swb-pkc-revocation-info
* > * wantBack, then would not include the
* > * id-stc-build-status-checked-pkc-path check.
* > *
* > * So, I would argue that the id-swb-pkc-revocation-info wantBack
would
* > * only be used in the case that the client was requesting a
validated
* > * certification path.  The way that I had interpreted the currently
* > * defined checks items, an SCVP query would only include one check
since
* > * each successive check included the requirements of the previous
one:
* > * id-stc-build-valid-pkc-path included the requirement to build a
path
* > * (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
* > * included the requirement to build a validated path
* > * (id-stc-build-valid-pkc-path).
* > *
* > * Under what circumstances can you envision a client wanting the
server
* > to
* > * do revocation status checking on a certification path (that is
* > * constructed by the server) without also including a requirement
that
* > the
* > * certification path be validated?   If there are no reasonable
* > * circumstances in which a client would make such a query, why is it
* > * necessary for clients to be able to construct such a query?
* > *
* > * Dave
* > *
* > * Trevor Freeman wrote:
* > *
* > * >Hi Seth,
* > * >A server can always go beyond what the client asked for. I don't
see
* > * >that as strictly necessary in all cases such as if the client
just
* > asks
* > * >for revocation. Untimely is a matter of local server policy. What
the
* > * >server cannot do is return status or errors relating to the other
* > * >activities which  were beyond the request scope.
* > * >Trevor
* > * >
* > * While it might make sense for a client to only ask for revocation
* > * checking if the client could specify the certification path, it
does
* > not
* > * seem to make sense given that the server chooses the certification
* > path
* > * for which revocation status checking will be performed.  If the
client
* > * wants to specify a set of certificates for which it only wants to
know
* > * the revocation status, that is what OCSP is for.
* > *
* > * >
* > * >* -----Original Message-----
* > * >* From: Seth Hitchings [mailto:[e-mail]]
* > * >* Sent: Wednesday, December 08, 2004 11:34 AM
* > * >* To: Trevor Freeman
* > * >* Cc: [e-mail]
* > * >* Subject: RE: SCVP 16 comments deadline
* > * >*
* > * >* Trevor,
* > * >*
* > * >* For clarification, I assume that doing revocation status checks
on
* > a
* > * path
* > * >* implies building
* > * >* a validated path?
* > * >*
* > * >* If I am correct, in what case would a client ever send more
than
* > one
* > * >* check?
* > * >*
* > * >* Seth
* > * >*
* > * >* -----Original Message-----
* > * >* From: [e-mail]
* > * >[mailto:[e-mail]]
* > * >* On Behalf Of
* > * >* Trevor Freeman
* > * >* Sent: Wednesday, December 08, 2004 1:42 PM
* > * >* To: Denis Pinkas
* > * >* Cc: [e-mail]
* > * >* Subject: RE: SCVP 16 comments deadline
* > * >*
* > * >*
* > * >* Denis,
* > * >* I know of several systems who's policy is never to revoke the
* > identity
* > * >* certificate because
* > * >* they have other mechanisms to address the issue.
* > * >* They are using authorization bound to the identity and they
either
* > rely
* > * on
* > * >* short lived
* > * >* authorization assertions or revoke the authorization privilege
* > * assonated
* > * >* with the
* > * >* identity. Therefore in those cases not checking the revocation
* > status
* > * of
* > * >* the certificate
* > * >* makes perfect sense.
* > * >* Trevor
* > * >*
* > * >* * -----Original Message-----
* > * >* * From: [e-mail]
* > * >* [mailto:[e-mail]]
* > * >* * On Behalf Of Denis Pinkas
* > * >* * Sent: Wednesday, December 08, 2004 8:01 AM
* > * >* * To: Trevor Freeman
* > * >* * Cc: [e-mail]
* > * >* * Subject: Re: SCVP 16 comments deadline
* > * >* *
* > * >* *
* > * >* * Trevor,
* > * >* *
* > * >* * > Hi Denis,
* > * >* * > Below are responses to 1-16. Others will follow later.
* > * >* *
* > * >* * I am pleased that you accepted comments 13, 14, 15 and 16.
* > * >* * Among this list, I have a further remark on comment 4.
* > * >* *
* > * >* * > * 4. Page 13. Typo. Section 3.1.2 "checks"
* > * >* * > * The two following lines are in fact one line:
* > * >* * > *
* > * >* * > * Change:
* > * >* * > *
* > * >* * > *      - Build a validated certification path to a trust
* > anchor;
* > * and
* > * >* * > *
* > * >* * > *      - Do revocation status checks on the certification
path.
* > * >* * > *
* > * >* * > * into:
* > * >* * > *
* > * >* * > *      - Build a validated certification path to a trust
anchor
* > and
* > * >* * > *        do revocation status checks on the certification
path.
* > * >* * > *
* > * >* * > [TF] Since this paragraph is listing the possible checks
and
* > * building
* > * >* a
* > * >* * > path is a separate check to revocation checking, I think
the
* > * current
* > * >* * > text is more accurate.
* > * >* *
* > * >* * I agree that "building a path is a separate check to
revocation
* > * >* checking",
* > * >* * but revocation checking without building a validated path
does
* > not
* > * make
* > * >* * sense.
* > * >* *
* > * >* * The full text currently is:
* > * >* *
* > * >* *      - Build a certification path to a trust anchor;
* > * >* *
* > * >* *      - Build a validated certification path to a trust
anchor;
* > and
* > * >* *
* > * >* *      - Do revocation status checks on the certification path.
* > * >* *
* > * >* * The full text should be:
* > * >* *
* > * >* *      - Build a certification path to a trust anchor;
* > * >* *
* > * >* *      - Build a validated certification path to a trust
anchor;
* > and
* > * >* *        do revocation status checks on the certification path.
* > * >* *
* > * >* * Denis
* > * >*
* > * >
* > * >
* > * >
* > *
* >
* >
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDIrt0T055418; Mon, 13 Dec 2004 10:53:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDIrtv5055417; Mon, 13 Dec 2004 10:53:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDIrre9055401 for <[e-mail]>; Mon, 13 Dec 2004 10:53:54 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 13 Dec 2004 18:53:43 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Proposed Changes to RFC 3280
Date: Mon, 13 Dec 2004 18:53:34 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Proposed Changes to RFC 3280
Thread-Index: AcTfRJNdRq/FOOSYQq24WCYOLPxqzAB/uOqA
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Dec 2004 18:53:43.0405 (UTC) FILETIME=[116521D0:01C4E145]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBDIrse9055411
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano,

There seem to be some confusion with your proposal.

The NextUpdate field certainly don't force clients to get a new CRL when
they expire. It is perfectly compliant already to wait to get a new CRL
when you have a certificate to validate.

Effective revocation need the NextUpdate field to know if a cashed CRL
is still valid and CAs must make sure that there is a valid CRL
available.

However there is another problem for those systems that wants to
pre-fetch CRLs. Because the NextUpdate field is actually used as the
expiry date there is no real possibility within the standard to express
when a new CRL is available if there is an overlap between CRL expiry
and CRL update.

This is why Microsoft has added support for a private optional extension
(CRL Next publish with OID 1.3.6.1.4.1.311.21.4) which indicates when a
new CRL is scheduled to be published (prior to expiry of old CRL).

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Massimiliano Pala
> Sent: den 10 december 2004 19:32
> To: [e-mail]
> Subject: Proposed Changes to RFC 3280
> 
> Hello all,
> 
> going through rfc3280 and reading the sections 5, 5.1, 5.1.2.5 about
> CRLs and nextUpdate field one idea came into my mind.
> The rfc enforces the use of the nextUpdate field which envisages the
> idea that new revocation information will be available within the
> retained time value.
> 
> This could lead to some problems because all clients will query the
> CRL repository upon CRL expiration.
> Moreover, in practical environment, there is the common thought that
> the nextUpdate filed carries the time when new revocation data will
> be available, which (correct me if I am wrong) is not.
> 
> So my idea is very simple, indeed. I would suggest to leave the field
> OPTIONAL (as in ASN.1).
> 
> If the field is not present, then compliant applications should check
> for new CRL when validating a certificate. This is pretty the same way
> OCSP handles the nextUpdate field within responses, isn't it?
> 
> Indeed the default behaviour for today CAs is to issue new CRLs as
> soon as a certificate is revoked - why being forced to issue a new
> CRL if no new data is indeed available ?
> 
> Let me know your comments, if there are no major objection I will
> post a possible patch for the document to the list.
> 
> --
> 
> C'you,
> 
> 	Massimiliano Pala
> 
>
--o---------------------------------------------------------------------
--
> -
> Massimiliano Pala [OpenCA Project Manager]
> [e-mail]
>                                                   Tel.:   +39 (0)59
270
> 094
> http://www.openca.org                           Fax:    +39   178  270
> 2077
> http://openca.sourceforge.net                   Mobile: +39 (0)347
7222
> 365
> 
> University of Modena and Reggio Emilia
> Certification Authority Informations:
> 
> Authority Access Point
> http://pki.unimo.it
> Authority's Certificate:
> http://pki.unimo.it/ca/issuers.html
> Certificate Revocation List:
> http://pki.unimo.it/crl/cacrl.crl
>
--o---------------------------------------------------------------------
--
> -



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDHQ4r0041125; Mon, 13 Dec 2004 09:26:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDHQ4xc041124; Mon, 13 Dec 2004 09:26:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from artemis.silanis.com (mail.silanis.com [209.167.254.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDHQ3Pa041115 for <[e-mail]>; Mon, 13 Dec 2004 09:26:04 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by artemis.silanis.com with Microsoft SMTPSVC; Mon, 13 Dec 2004 11:56:38 -0500
Received: from mx03.ca.mci.com ([142.77.2.11]) by artemis.silanis.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Dec 2004 11:28:34 -0500
Received: from above.proper.com (above.proper.com [208.184.76.39]) by mx03.ca.mci.com (Postfix) with ESMTP id A995212837 for <[e-mail]>; Sun, 12 Dec 2004 13:53:51 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBCH3JEc069895; Sun, 12 Dec 2004 09:03:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBCH3ITj069894; Sun, 12 Dec 2004 09:03:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBCH39Rb069832 for <[e-mail]>; Sun, 12 Dec 2004 09:03:18 -0800 (PST) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iBCH2MG11157; Sun, 12 Dec 2004 18:02:22 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iBCH27Sj043216; Sun, 12 Dec 2004 18:02:22 +0100 (CET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: Tim Polk <[e-mail]>
Cc: [e-mail]
Subject: Re: Mea Culpa and NEW SCVP 16 comments deadline 
In-reply-to: Your message of Thu, 09 Dec 2004 11:43:30 EST. <[e-mail]> 
Date: Sun, 12 Dec 2004 18:02:07 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 13 Dec 2004 16:28:35.0060 (UTC) FILETIME=[CAD12340:01C4E130]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some comments:
 - the requestorRef definition doesn't match its description in 3.2.
   IMHO we should keep the description, i.e., the requestorRef should be
   an octet string which is a local reference to the client. More, I'd like
   the rationale of 4.7 be reflected in 3.2...
 - please change wantBack (item name) and WantBack (type) into wantBacks
   and WantBacks (like [cC]ecks and [rR]eplyWantBacks: homogeneous use
   of the plural!)
 - I'd like to use other cert references than ESSCertIDs, IKE has and URL
   for instance. Please add an OID+Value choice in PKCReference/ACReference?
 - checks OIDs (id-stc-build-*) are different between 3.1.2 and the annex.
   IMHO the text which defines 7 cases is right.
 - 3.1.5.1 needs to be merged into 3.1.4.1. My understanding is there are
   a default validation policy and a basic validation algorithm.
 - spelling of basic valAlg errors (id-bvae-*) should be uniformized
 - same for name valAlg errors between definitions and descriptions
 - id-nvae-unknown-pupose -> id-nvae-unknown-purpose
 - there is nothing about the case where the extended key usage extension
   is absent. IMHO this is like key usage, i.e., the certificate MUST be
   considered goof for all extended usages...
 - responseFlags items *need* tags!
 - 4 uses id-ct-scvp-psResponse in place of id-ct-scvp-certValResponse (typo)
 - what are the differences between responseStatus 50 and 61, or 51 and 62?
 - in ValidationPolValues isCA and trustAnchors should be optional as they
   have no default values.
 - validationPolicyAttr is spuriously described again in 4.5.6
 - in 4.10 change valdationPolicy into validationErrors (typo) which is
   OPTIONAL (i.e., in the MAYs)
 - replyWantBacks for id-swb 10, 11 and 13 are missing
 - delete 4.10.6 validationAlg (moved to ValidationPolValues)
 - just a question "en passant": what OID to used in validationErrors for
   a failed "isCA" check? id-bvae-invalidEntity? id-bvae-invalidPurpose?
 - please change valPolRequest into VPRequest for the name of the type
 - same for valPolResponse and VPResponse
 - same in 6.4 for PolResponse
 - same in 6.6 for polResponse
 - delete 6.7 trustAnchors
 - IMHO dhPublicKeyInfo should be optional in VPResponse because DH is
   not the only protection way.
 - 6.14 VaidationPolValues (typo)
 - in ASN.1 annex:
    * nameValidationAlg -> NameValidationAlgParms
    * ValidationPolValues differs
    * some missing id-stc-build-*
    * id-svp-defaultValAlg -> id-svp-defaultValPolicy
    * missing id-svp-dnValAlg, incorrect id-nvae definition
 - in HTTP B.1 appendix:
   application/cv-policy-request -> application/cv-request
   (IMHO the Sample should be removed as the length header is missing too)

Regards

[e-mail]

PS: I have an implementation of draft 16 in OpenSSL 0.9.7d with a responder
and some test clients including racoon (IKE) and EAP-TLS. Of course as
only the beta version of OpenSSL really supports policies it is a very
partial implementation, BTW not worse than what already exists for
my applications (:-).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDHM7Bt040749; Mon, 13 Dec 2004 09:22:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDHM7Ta040748; Mon, 13 Dec 2004 09:22:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from artemis.silanis.com (mail.silanis.com [209.167.254.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDHM6ie040737 for <[e-mail]>; Mon, 13 Dec 2004 09:22:06 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by artemis.silanis.com with Microsoft SMTPSVC; Mon, 13 Dec 2004 11:56:27 -0500
Received: from mx03.ca.mci.com ([142.77.2.11]) by artemis.silanis.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Dec 2004 11:47:45 -0500
Received: from above.proper.com (above.proper.com [208.184.76.39]) by mx03.ca.mci.com (Postfix) with ESMTP id 60FC512E31 for <[e-mail]>; Sat, 11 Dec 2004 14:24:11 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBBHIval041089; Sat, 11 Dec 2004 09:18:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBBHIvxT041086; Sat, 11 Dec 2004 09:18:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBBHIle5040895; Sat, 11 Dec 2004 09:18:52 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06200700bde0da096304@[10.20.30.249]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 11 Dec 2004 09:13:52 -0800
To: [e-mail], [e-mail]
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: Proposed Changes to RFC 3280
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 13 Dec 2004 16:47:45.0699 (UTC) FILETIME=[78A6B730:01C4E133]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:32 AM +0100 12/11/04, Massimiliano Pala wrote:
>This could lead to some problems because all clients will query the
>CRL repository upon CRL expiration.

"Could", yes, but so far, we have not heard that this is a problem in 
current deployments.

>So my idea is very simple, indeed. I would suggest to leave the field
>OPTIONAL (as in ASN.1).

Maybe I'm misunderstanding the proposal, but it seems like this would 
cause *massive* problems for currently-deployed systems that expect 
and rely on the nextUpdate field.

>Indeed the default behaviour for today CAs is to issue new CRLs as
>soon as a certificate is revoked

That may be true for some systems, but it certainly isn't true for others.

>  - why being forced to issue a new
>CRL if no new data is indeed available ?

Because it is cheap for the CA to do.

>Let me know your comments, if there are no major objection I will
>post a possible patch for the document to the list.

Please consider my worry above about currently-deployed software. If 
I'm wrong, no problem, but if I'm right, then I can't imagine that 
the benefits of this kind of change would outweigh the difficulties 
for current systems.

--Paul Hoffman, Director
--VPN Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFqx7w058974; Mon, 13 Dec 2004 07:52:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDFqxq8058973; Mon, 13 Dec 2004 07:52:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFqvtk058894 for <[e-mail]>; Mon, 13 Dec 2004 07:52:58 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBDFqxn07127; Mon, 13 Dec 2004 16:52:59 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 13 Dec 2004 16:52:59 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBDFqxA08860; Mon, 13 Dec 2004 16:52:59 +0100 (MET)
Date: Mon, 13 Dec 2004 16:52:59 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [TF] 
> Reputedly copying the same section from 3379 has the same effect. I
> believe the current draft of SCVP complies with the text. The name must
> be in the certificate. I don't see value in repeating the value twice in
> the request.

And I don't "believe" this.in fact,I don't have to believe anything here,
since I know why I had asked for the text in 3379.

If one gets married, I don't necessarily want to change the identity 
indicated in a drivers licence just because of this. I want to be able 
to pretend to have a certain identity, i.e. a statement to be made for
it, and then, in whatever way, provide the means to authenticate this
identity, and not the other way around, to derive a potentially unwanted
identity.

If a certificate would be sufficient, then I don't see what can be
the meaning of the sentence  

"Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy."

a sentence which is grammatically incorrect, but anyway: There are
clearly TWO identifiers, one is the authenticated identity, and one
is another. 

If all declarations are done via a certificate that is also used
for authentication, what would be "mechanism for matching" of TWO
things can occur?  

But well, maybe the authors of 3379 may comment.  

Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFqskJ058778; Mon, 13 Dec 2004 07:52:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDFqsmZ058777; Mon, 13 Dec 2004 07:52:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFqqQi058702 for <[e-mail]>; Mon, 13 Dec 2004 07:52:53 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBDFqsn07119; Mon, 13 Dec 2004 16:52:54 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 13 Dec 2004 16:52:54 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBDFqsc08857; Mon, 13 Dec 2004 16:52:54 +0100 (MET)
Date: Mon, 13 Dec 2004 16:52:54 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For the statement

     If the extended key usage extension is present, it MUST contain 
     either the client authentication OID, the SCVP client OID, or 
     some other OID by agreement with the SCVP server.

where are the two OID defined? 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFEcvU027090; Mon, 13 Dec 2004 07:14:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDFEcGd027079; Mon, 13 Dec 2004 07:14:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFEYtA027024 for <[e-mail]>; Mon, 13 Dec 2004 07:14:37 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBDFEan06382; Mon, 13 Dec 2004 16:14:36 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 13 Dec 2004 16:14:36 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBDFEZb08698; Mon, 13 Dec 2004 16:14:35 +0100 (MET)
Date: Mon, 13 Dec 2004 16:14:35 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Peter,
> You are assuming that there is only one possible matching algorithm for
> a name type - which seems a fragile assertion. The be more  robust then
> you supply a name and a matching rule identifier - which is what the
> name validation algorithm does.
I am not assuming a single possible matching algorithm. 
I'd am saying that there should be at least
one matching algorithm that can compare any name (probably at least
binary comparison). 

> I have seen examples of cases where a name has been inserted into an asn
> structure which does not cause an ASN decode error but the name is still
> bad because the name semantics are wrong - so I don't subscribe to the
> notion that all bad names cause asn decode errors.

Do you mean 'additional syntactical constraints' or really 'semantics'?

Syntactical errors include dection like 'an rfc822 has an @ sign etc'.
Semantical sounds to me like you want validate whether the email exists, whether
domain exists, etc.?

Syntactical errors can provokde asn1 decoding errors, it depends also
to a certain degree on what version of ASN1 you use in order to
directly specify constraints... ooups, I think is currently
forbidden to talk at all about ASN1 version in PKIX. So I break the
rule. make a ASN1 syntax which is valid under a CURRENT version, please.  

Anyway, having a special error code doesn't hurt too much.


> 
> * -----Original Message-----
> * From: Peter Sylvester [mailto:[e-mail]]
> * Sent: Thursday, December 09, 2004 4:58 AM
> * To: [e-mail]; Trevor Freeman
> * Cc: [e-mail]
> * Subject: RE: SCVP 16 comments deadline
> * 
> * 3.1.5.2.3 Name Validation Algorithm
> * 
> * I find the possibilities for the Name Validation Algorithm
> * rather unsafisfying.
> * 
> * It should be possible IMO to have a matching simply by
> * presenting whatever form of Generalname and this should
> * be compared with the corresponding value in the cert.
> * 
> * In fact, the id-svp-dnValAlg sounds rather restrictive to
> * me, it seems to imply that only the subject field is
> * compared (or does this also compare with the Dirname in
> * a subjectAltname).
> * 
> * This restriction about a DN doesn't seem necssary to me,
> * Any generalName can be compared with any in the subjectAltname.
> * 
> * E.g. an IP address.
> * 
> * 'id-nvae-unknown-pupose'   ==> 'id-nvae-unknown-purpose'
> * 
> *   id-nvae-name-mismatch vs   The id-nvae-nameMismatch value
> [TF] Fixed
> * 
> * please align the spellings of all the errors types.
> * 
> *   The id-nvae-badName value means the client supplied either and
> *   empty or malformed name in the request.
> * 
> * what is a bad or malformed name? How can this happen without raising
> * a general asn1 decoding error
> * 
> * since it comes right next?
> * 
> * ---
> * cleanup the following text, please
> * 
> *   The userPolicySet item specifies a list of policy identifiers that
> *   the SCVP server MUST use when forming and validating a certificate
> *   If certPolicies is not specified, then any-policy MUST be used.
> * 
> * 3.1.5.3 userPolicySet
> * 
> *   The userPolicySet item specifies a list of certificate policy
> *   identifiers that the SCVP server MUST use when constructing and
> *   validating a certification path.  If userPolicySet is not specified,
> *   then any-policy MUST be used.
> * 
> * 
> [TF] I will change the userPolicy set to the following
> The userPolicySet item specifies a list of certificate policy
> identifiers that the SCVP server MUST use when constructing and
> validating a certification path.
> 
> The requirement for use of the userPolicySet falling back to any-policy
> is being dropped because the referenced policy or the default policy
> will cover this.
> * 
>  
> Trevor
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDF5P5E019404; Mon, 13 Dec 2004 07:05:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDF5PgI019403; Mon, 13 Dec 2004 07:05:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDF5NIO019386 for <[e-mail]>; Mon, 13 Dec 2004 07:05:24 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBDF5Pn06285; Mon, 13 Dec 2004 16:05:25 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 13 Dec 2004 16:05:25 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBDF5OV08673; Mon, 13 Dec 2004 16:05:24 +0100 (MET)
Date: Mon, 13 Dec 2004 16:05:24 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * 
> * None of these is a "declaration" of an identity. It is a means to
> * authenticate
> * the request at least in my opinion.
> [TF] When I sign email, I don't include an additional attribute, I just
> include my certificate. How is that not a declaration of identity.

You have a From: field in your e-mail, which is how a signer claims
his identity in general.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBD8b3b6043040; Mon, 13 Dec 2004 00:37:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBD8b3hl043039; Mon, 13 Dec 2004 00:37:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBD8b0mB042975 for <[e-mail]>; Mon, 13 Dec 2004 00:37:01 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA46156; Mon, 13 Dec 2004 09:49:24 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004121309364566:54 ; Mon, 13 Dec 2004 09:36:45 +0100 
Message-ID: <[e-mail]>
Date: Mon, 13 Dec 2004 09:36:44 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/13/2004 09:36:47 AM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/13/2004 09:36:50 AM, Serialize complete at 12/13/2004 09:36:50 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

(text deleted)

> [TF] You are advocating making the default policy selection implicit by
> omitting the policy form the request, we have chosen to make it explicit
> be defining a OID to represent the default policy. Functionally they are
> the same.

RFC 3379 states:

    A validation policy is a set of rules against which the validation of
    the certificate is performed.

RFC 3379 states:

    If the DPV request does not specify a validation policy, the server
    response MUST indicate the validation policy that was used.

SCVP MUST be compliant with RFC 3379.

> If the client specifies a policy it is one supported by the server
> which may or may not have parameters.
> [TF] Agreed

> Some parameters may be built-in in the policy and cannot be changed
> while some others may be allowed to be changed by the client.
> [TF] Agreed

> * 
> *  > The default
> * > values are also used when processing requests which reference a
> * > validation policy other than the default one that does not contain
> the
> * > full set of parameters necessary for validation and the client has
> also
> * > omitted the missing values in the request.
> * 
> * This sentence is rather long and complicated. I read it three times
> and
> * could not understand the exception for the default policy. If the
> default
> * policy is addressed above, we can simplify the sentence and only
> mention:

> [TF] All models contain the concept of default and non-default policy.
> If you specify a non-default policy, any parameter defined in the policy
> cannot be overridden by the client. Any parameter not defined by policy
> may be supplied by the client or the client can defer to the server
> default. If you specify the default policy, every parameter can be
> overridden.

You do not provide arguments against my proposal. However I noticed that 
your explanations are incorrect. If the default policy is being used (no OID 
specified in the request) then no paramter for that policy can be 
communicated by the client.

If a validation poilcy is specified by the client, then :

(1) some parameters for that policy are built-in in the policy and cannot be 
modified by the client (there are no policy parameters for doing this in the 
request), or

(2) some parameters for that policy may be specified by the client (there 
are policy parameters for doing this in the request). If they are not 
filed-in by the client, then either default values are used by the server or 
an error is returned.

> * "The default values are also used when processing requests which
> * reference a  validation policy that does not contain the full set of 
 > * parameters necessary for validation and the client has also omitted
 > * the missing values in the request."

> * > Therefore a client can also
> * > simplify the request by omitting a parameter from a request if the
> * > default value published by the server is acceptable.

> * This last sentence is correct.

(text deleted)

> * There should be non such concept of a "non-default policy".
> * Suppress "non-default" in the sentence.
> [TF] since we have the concept of default policy - we by definition get
> the non-default policy.

See above the argumentation against this.

Denis

> * > Therefore if you use the non-default policy, the policy value take
> * > precedence over the request value and cannot be overridden by the
> * > request. For the default policy the client can override any value.
> * 
> * No. See above.
> * 
> * Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBD8ZKMr042451; Mon, 13 Dec 2004 00:35:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBD8ZKKW042450; Mon, 13 Dec 2004 00:35:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBD8ZIGS042409 for <[e-mail]>; Mon, 13 Dec 2004 00:35:19 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA17566; Mon, 13 Dec 2004 09:47:40 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004121309350114:52 ; Mon, 13 Dec 2004 09:35:01 +0100 
Message-ID: <[e-mail]>
Date: Mon, 13 Dec 2004 09:35:00 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: "David A. Cooper" <[e-mail]>, [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/13/2004 09:35:01 AM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/13/2004 09:35:06 AM, Serialize complete at 12/13/2004 09:35:06 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

> David,
> No wanting to rathole on this sine time is short, the section of the
> document in question which Denis referred to is dealing with the set of
> request that the client can make to the server. We agree that the client
> can ask for path construction without revocation checking. 

Up to here we agree.

> I think it
> legitimate a DPD client could ask for revocation checking because it has
> already be able to build a path. Conceivably a DPV client could do the
> same because it pervious asked for the path to be constructed and just
> wants the revocation data refreshed. 

Here we do not agree. If a client has already been able to build a path, 
then he provides that path as "useful certificates" and the DPV server will 
necessarily build the path (using or not using these "useful certificates") 
and verify it.

So if revocation checking is asked for by the client, this necessarily 
mandates path construction.

Denis


> However to get to the bottom line, is there a specific problem with the
> text in section 3.1.2
> Trevor
> 
> * -----Original Message-----
> * From: David A. Cooper [mailto:[e-mail]]
> * Sent: Thursday, December 09, 2004 2:22 PM
> * To: Trevor Freeman
> * Cc: [e-mail]
> * Subject: Re: SCVP 16 comments deadline
> * 
> * Trevor,
> * 
> * I must say that I agree with Seth and Denis.  I was under the
> impression
> * that "Do revocation status checking on the certification path" really
> * meant "build and validated certification path to a trust anchor and do
> * revocation status checking on the certification path".  While I can
> see
> * that there may be circumstances in which one would request a validated
> * certification path without requiring revocation status checking, I
> can't
> * see requesting revocation status checking without requesting that the
> * path be validated.
> * 
> * It is certainly the case that one can not "do revocation status
> checking
> * on the certification path" without also building a certification path.
> * Since the client can not provide a certification path, revocation
> status
> * checking must be performed on a path that is built by the server.  I
> * suppose you could argue that this simply means that a well formed
> query
> * can not include the id-stc-build-status-checked-pkc-path without also
> * including either the id-stc-build-pkc-path or
> * id-stc-build-valid-pkc-path check.  But, I see see the need for this.
> * 
> * A DPD client would include the id-stc-build-pkc-path along with the
> * id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info wantBacks.
> * If the DPD client included the id-swb-pkc-revocation-info wantBack, it
> * wouldn't need to also include the id-stc-build-status-checked-pkc-path
> * check.  If the DPD client did not include the
> id-swb-pkc-revocation-info
> * wantBack, then would not include the
> * id-stc-build-status-checked-pkc-path check.
> * 
> * So, I would argue that the id-swb-pkc-revocation-info wantBack would
> * only be used in the case that the client was requesting a validated
> * certification path.  The way that I had interpreted the currently
> * defined checks items, an SCVP query would only include one check since
> * each successive check included the requirements of the previous one:
> * id-stc-build-valid-pkc-path included the requirement to build a path
> * (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
> * included the requirement to build a validated path
> * (id-stc-build-valid-pkc-path).
> * 
> * Under what circumstances can you envision a client wanting the server
> to
> * do revocation status checking on a certification path (that is
> * constructed by the server) without also including a requirement that
> the
> * certification path be validated?   If there are no reasonable
> * circumstances in which a client would make such a query, why is it
> * necessary for clients to be able to construct such a query?
> * 
> * Dave
> * 
> * Trevor Freeman wrote:
> * 
> * >Hi Seth,
> * >A server can always go beyond what the client asked for. I don't see
> * >that as strictly necessary in all cases such as if the client just
> asks
> * >for revocation. Untimely is a matter of local server policy. What the
> * >server cannot do is return status or errors relating to the other
> * >activities which  were beyond the request scope.
> * >Trevor
> * >
> * While it might make sense for a client to only ask for revocation
> * checking if the client could specify the certification path, it does
> not
> * seem to make sense given that the server chooses the certification
> path
> * for which revocation status checking will be performed.  If the client
> * wants to specify a set of certificates for which it only wants to know
> * the revocation status, that is what OCSP is for.
> * 
> * >
> * >* -----Original Message-----
> * >* From: Seth Hitchings [mailto:[e-mail]]
> * >* Sent: Wednesday, December 08, 2004 11:34 AM
> * >* To: Trevor Freeman
> * >* Cc: [e-mail]
> * >* Subject: RE: SCVP 16 comments deadline
> * >*
> * >* Trevor,
> * >*
> * >* For clarification, I assume that doing revocation status checks on
> a
> * path
> * >* implies building
> * >* a validated path?
> * >*
> * >* If I am correct, in what case would a client ever send more than
> one
> * >* check?
> * >*
> * >* Seth
> * >*
> * >* -----Original Message-----
> * >* From: [e-mail]
> * >[mailto:[e-mail]]
> * >* On Behalf Of
> * >* Trevor Freeman
> * >* Sent: Wednesday, December 08, 2004 1:42 PM
> * >* To: Denis Pinkas
> * >* Cc: [e-mail]
> * >* Subject: RE: SCVP 16 comments deadline
> * >*
> * >*
> * >* Denis,
> * >* I know of several systems who's policy is never to revoke the
> identity
> * >* certificate because
> * >* they have other mechanisms to address the issue.
> * >* They are using authorization bound to the identity and they either
> rely
> * on
> * >* short lived
> * >* authorization assertions or revoke the authorization privilege
> * assonated
> * >* with the
> * >* identity. Therefore in those cases not checking the revocation
> status
> * of
> * >* the certificate
> * >* makes perfect sense.
> * >* Trevor
> * >*
> * >* * -----Original Message-----
> * >* * From: [e-mail]
> * >* [mailto:[e-mail]]
> * >* * On Behalf Of Denis Pinkas
> * >* * Sent: Wednesday, December 08, 2004 8:01 AM
> * >* * To: Trevor Freeman
> * >* * Cc: [e-mail]
> * >* * Subject: Re: SCVP 16 comments deadline
> * >* *
> * >* *
> * >* * Trevor,
> * >* *
> * >* * > Hi Denis,
> * >* * > Below are responses to 1-16. Others will follow later.
> * >* *
> * >* * I am pleased that you accepted comments 13, 14, 15 and 16.
> * >* * Among this list, I have a further remark on comment 4.
> * >* *
> * >* * > * 4. Page 13. Typo. Section 3.1.2 "checks"
> * >* * > * The two following lines are in fact one line:
> * >* * > *
> * >* * > * Change:
> * >* * > *
> * >* * > *      - Build a validated certification path to a trust
> anchor;
> * and
> * >* * > *
> * >* * > *      - Do revocation status checks on the certification path.
> * >* * > *
> * >* * > * into:
> * >* * > *
> * >* * > *      - Build a validated certification path to a trust anchor
> and
> * >* * > *        do revocation status checks on the certification path.
> * >* * > *
> * >* * > [TF] Since this paragraph is listing the possible checks and
> * building
> * >* a
> * >* * > path is a separate check to revocation checking, I think the
> * current
> * >* * > text is more accurate.
> * >* *
> * >* * I agree that "building a path is a separate check to revocation
> * >* checking",
> * >* * but revocation checking without building a validated path does
> not
> * make
> * >* * sense.
> * >* *
> * >* * The full text currently is:
> * >* *
> * >* *      - Build a certification path to a trust anchor;
> * >* *
> * >* *      - Build a validated certification path to a trust anchor;
> and
> * >* *
> * >* *      - Do revocation status checks on the certification path.
> * >* *
> * >* * The full text should be:
> * >* *
> * >* *      - Build a certification path to a trust anchor;
> * >* *
> * >* *      - Build a validated certification path to a trust anchor;
> and
> * >* *        do revocation status checks on the certification path.
> * >* *
> * >* * Denis
> * >*
> * >
> * >
> * >
> * 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBCH3JEc069895; Sun, 12 Dec 2004 09:03:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBCH3ITj069894; Sun, 12 Dec 2004 09:03:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBCH39Rb069832 for <[e-mail]>; Sun, 12 Dec 2004 09:03:18 -0800 (PST) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iBCH2MG11157; Sun, 12 Dec 2004 18:02:22 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iBCH27Sj043216; Sun, 12 Dec 2004 18:02:22 +0100 (CET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: Tim Polk <[e-mail]>
cc: [e-mail]
Subject: Re: Mea Culpa and NEW SCVP 16 comments deadline 
In-reply-to: Your message of Thu, 09 Dec 2004 11:43:30 EST. <[e-mail]> 
Date: Sun, 12 Dec 2004 18:02:07 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some comments:
 - the requestorRef definition doesn't match its description in 3.2.
   IMHO we should keep the description, i.e., the requestorRef should be
   an octet string which is a local reference to the client. More, I'd like
   the rationale of 4.7 be reflected in 3.2...
 - please change wantBack (item name) and WantBack (type) into wantBacks
   and WantBacks (like [cC]ecks and [rR]eplyWantBacks: homogeneous use
   of the plural!)
 - I'd like to use other cert references than ESSCertIDs, IKE has and URL
   for instance. Please add an OID+Value choice in PKCReference/ACReference?
 - checks OIDs (id-stc-build-*) are different between 3.1.2 and the annex.
   IMHO the text which defines 7 cases is right.
 - 3.1.5.1 needs to be merged into 3.1.4.1. My understanding is there are
   a default validation policy and a basic validation algorithm.
 - spelling of basic valAlg errors (id-bvae-*) should be uniformized
 - same for name valAlg errors between definitions and descriptions
 - id-nvae-unknown-pupose -> id-nvae-unknown-purpose
 - there is nothing about the case where the extended key usage extension
   is absent. IMHO this is like key usage, i.e., the certificate MUST be
   considered goof for all extended usages...
 - responseFlags items *need* tags!
 - 4 uses id-ct-scvp-psResponse in place of id-ct-scvp-certValResponse (typo)
 - what are the differences between responseStatus 50 and 61, or 51 and 62?
 - in ValidationPolValues isCA and trustAnchors should be optional as they
   have no default values.
 - validationPolicyAttr is spuriously described again in 4.5.6
 - in 4.10 change valdationPolicy into validationErrors (typo) which is
   OPTIONAL (i.e., in the MAYs)
 - replyWantBacks for id-swb 10, 11 and 13 are missing
 - delete 4.10.6 validationAlg (moved to ValidationPolValues)
 - just a question "en passant": what OID to used in validationErrors for
   a failed "isCA" check? id-bvae-invalidEntity? id-bvae-invalidPurpose?
 - please change valPolRequest into VPRequest for the name of the type
 - same for valPolResponse and VPResponse
 - same in 6.4 for PolResponse
 - same in 6.6 for polResponse
 - delete 6.7 trustAnchors
 - IMHO dhPublicKeyInfo should be optional in VPResponse because DH is
   not the only protection way.
 - 6.14 VaidationPolValues (typo)
 - in ASN.1 annex:
    * nameValidationAlg -> NameValidationAlgParms
    * ValidationPolValues differs
    * some missing id-stc-build-*
    * id-svp-defaultValAlg -> id-svp-defaultValPolicy
    * missing id-svp-dnValAlg, incorrect id-nvae definition
 - in HTTP B.1 appendix:
   application/cv-policy-request -> application/cv-request
   (IMHO the Sample should be removed as the length header is missing too)

Regards

[e-mail]

PS: I have an implementation of draft 16 in OpenSSL 0.9.7d with a responder
and some test clients including racoon (IKE) and EAP-TLS. Of course as
only the beta version of OpenSSL really supports policies it is a very
partial implementation, BTW not worse than what already exists for
my applications (:-).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBBHIval041089; Sat, 11 Dec 2004 09:18:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBBHIvxT041086; Sat, 11 Dec 2004 09:18:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBBHIle5040895; Sat, 11 Dec 2004 09:18:52 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06200700bde0da096304@[10.20.30.249]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 11 Dec 2004 09:13:52 -0800
To: [e-mail], [e-mail]
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: Proposed Changes to RFC 3280
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:32 AM +0100 12/11/04, Massimiliano Pala wrote:
>This could lead to some problems because all clients will query the
>CRL repository upon CRL expiration.

"Could", yes, but so far, we have not heard that this is a problem in 
current deployments.

>So my idea is very simple, indeed. I would suggest to leave the field
>OPTIONAL (as in ASN.1).

Maybe I'm misunderstanding the proposal, but it seems like this would 
cause *massive* problems for currently-deployed systems that expect 
and rely on the nextUpdate field.

>Indeed the default behaviour for today CAs is to issue new CRLs as
>soon as a certificate is revoked

That may be true for some systems, but it certainly isn't true for others.

>  - why being forced to issue a new
>CRL if no new data is indeed available ?

Because it is cheap for the CA to do.

>Let me know your comments, if there are no major objection I will
>post a possible patch for the document to the list.

Please consider my worry above about currently-deployed software. If 
I'm wrong, no problem, but if I'm right, then I can't imagine that 
the benefits of this kind of change would outweigh the difficulties 
for current systems.

--Paul Hoffman, Director
--VPN Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBB3WY8p036081; Fri, 10 Dec 2004 19:32:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBB3WYNj036069; Fri, 10 Dec 2004 19:32:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.hackmasters.net (ppp-217-133-8-148.cust-adsl.tiscali.it [217.133.8.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBB3WL9X035713 for <[e-mail]>; Fri, 10 Dec 2004 19:32:26 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 7BE41FA082 for <[e-mail]>; Sat, 11 Dec 2004 04:57:38 +0100 (CET)
Received: by mail.hackmasters.net (Postfix, from userid 520) id CC626FA083; Sat, 11 Dec 2004 04:57:33 +0100 (CET)
Received: from [10.5.122.160] (junk.hackmasters.net [10.5.122.160]) by mail.hackmasters.net (Postfix) with ESMTP id CE922FA082 for <[e-mail]>; Sat, 11 Dec 2004 04:57:30 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 10 Dec 2004 16:50:20 +0100
From: Massimiliano Pala <[e-mail]>
Reply-To: [e-mail]
Organization: Hackmasters.net
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Proposed Changes to RFC 3280
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040003070100080006090908"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  zorba.hackmasters.net
X-Spam-Status: No, hits=-4.2 required=4.0 tests=BAYES_00,DATE_IN_PAST_12_24  autolearn=no version=2.60
X-Spam-Level: 
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms040003070100080006090908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello all,

going through rfc3280 and reading the sections 5, 5.1, 5.1.2.5 about
CRLs and nextUpdate field one idea came into my mind.
The rfc enforces the use of the nextUpdate field which envisages the
idea that new revocation information will be available within the
retained time value.

This could lead to some problems because all clients will query the
CRL repository upon CRL expiration.
Moreover, in practical environment, there is the common thought that
the nextUpdate filed carries the time when new revocation data will
be available, which (correct me if I am wrong) is not.

So my idea is very simple, indeed. I would suggest to leave the field
OPTIONAL (as in ASN.1).

If the field is not present, then compliant applications should check
for new CRL when validating a certificate. This is pretty the same way
OCSP handles the nextUpdate field within responses, isn't it?

Indeed the default behaviour for today CAs is to issue new CRLs as
soon as a certificate is revoked - why being forced to issue a new
CRL if no new data is indeed available ?

Let me know your comments, if there are no major objection I will
post a possible patch for the document to the list.

-- 

C'you,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]               [e-mail]
                                                 Tel.:   [phone]
http://www.openca.org                           Fax:    +39   178  270 2077
http://openca.sourceforge.net                   Mobile: [phone]

University of Modena and Reggio Emilia
Certification Authority Informations:

Authority Access Point                                  http://pki.unimo.it
Authority's Certificate:                http://pki.unimo.it/ca/issuers.html
Certificate Revocation List:              http://pki.unimo.it/crl/cacrl.crl
--o------------------------------------------------------------------------

--------------ms040003070100080006090908
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWoTCC
BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG
A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw
MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx
MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX
pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV
6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D
vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt
Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g
mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k
ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG
CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy
NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js
L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ
506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT
yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b
vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW
1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm
053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF
HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+
Azi6vNmzQwCbegU26NFazErhLS5qDXQwggUCMIID6qADAgECAgID5jANBgkqhkiG9w0BAQUF
ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ
dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMTIyMjE0MDAwMFoXDTA1MTIz
MTEyMDAwMFowgZwxJzAlBgkqhkiG9w0BCQEWGHN1cHBvcnRfZmlybWFAdW5pbW9yZS5pdDE0
MDIGA1UEAxMrQXV0b3JpdGEnIGRpIENlcnRpZmljYXppb25lIFVuaU1vUmUtRXVyb1BLSTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3Dc6grS/wQDT4vW50zSBT
d6GGqTeeke32VgyBTNwH74kYs+l9Lv8A4QNuLKCC/K+qXG8WUJCyrpgxbB+73JD/yxOAYggc
ou5FOKIfuUMlhsrxKrc8Z8LgeIxSEUxpNmvpX2BpE03+SfIr0IA2SnMPCGKmkc2lGqp2SCLd
2IrMOS/OFqJIhXOkzSU18FEWWEtc3JaZpc9NSDB5JO3XZf/gZ/BrtgF3cZBBDOK2tXCFQDja
Bhps47AhfbJUUsvQfK76spi8t2o+ygvrhmcDr77e/w8zeq4mPP9UfX/bLKVSp8Uxlb79fNiO
QMxfeXfM21hVGlCjFEyquqgTwNlCBr6rAgMBAAGjggGWMIIBkjBcBggrBgEFBQcBAQRQME4w
KAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYIKwYBBQUHMAKG
Fmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMA8GA1UdEwEB/wQFMAMBAf8wgZMGA1Ud
IASBizCBiDBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3Br
aS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0
dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wDgYDVR0PAQH/BAQDAgH2MB0G
A1UdDgQWBBSNtmANJRb3qJMqiHetv5V+4c1urjAfBgNVHSMEGDAWgBSqPBPJSQtczbjTIODF
lZczM10kEzANBgkqhkiG9w0BAQUFAAOCAQEAtmdzId6h0fTMqSZ1X7b1nVSielwpEgi1AJww
WnMTClOZHBDDIFwbc/pzgJ4de75cxq/g516XEmD/1vfRr2Hes9j/pr3uNnRDTp8wWH9wpT5P
YwZZooqfcCcD9HT5SSb+7kn+hl6QJUmVS7l8NigSsN3ouYapIest2nV8HYToAdeECHpJ1/aD
0Ovrla6vB0YgmJNPh3ER+klSrdgjuIeY4GbBEfLJuvWpRJZgIj1RGPFwo98M4/8WG0sMnFh6
CxG2j4GvR/C/Wm/CG48qGT2a9gmv3oI7Qv1KP71l76lHxxajmWLWqOJNvLigWcveIkOZwIbp
4v8GZOK0c+v0EH+ivjCCBoYwggVuoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZwxJzAlBgkq
hkiG9w0BCQEWGHN1cHBvcnRfZmlybWFAdW5pbW9yZS5pdDE0MDIGA1UEAxMrQXV0b3JpdGEn
IGRpIENlcnRpZmljYXppb25lIFVuaU1vUmUtRXVyb1BLSTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwHhcNMDMxMjMwMTUx
MjI5WhcNMDQxMjI5MTUxMjI5WjBvMQswCQYDVQQGEwJJVDEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTEUMBIGA1UECxMLVHJ1c3RjZW50ZXIxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDG
oL1pqELlnFAB8iDBcUGi1nmy4u+Jf6HGvv1ZI33ti1p9Q5pSsnCd5PCkcMTXO/hSV6Hcu6EL
PEwYY0fyaySf3A5HcCzLz3A1n70E2OrlfqUz+d2A7H+gpSrtV5BlGiz49BCFjiBeh7k4xwKE
0Pasxv4vLg+Wnb+lSEuuwTQx0wIDAQABo4IDgTCCA30wCQYDVR0TBAIwADARBglghkgBhvhC
AQEEBAMCBLAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYK
KwYBBAGCNxQCAjBdBglghkgBhvhCAQ0EUBZOQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQWRt
aW5pc3RyYXRvciBvZiBVbml2ZXJzaXRhJyBkaSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMB0G
A1UdDgQWBBT3vBE+YoleG9jSpVAqZJFPeHuu3TB6BgNVHSMEczBxgBSNtmANJRb3qJMqiHet
v5V+4c1urqFVpFMwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNVBAMT
J0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYICA+YwIgYDVR0RBBsw
GYEXbWFkd29sZkBoYWNrbWFzdGVycy5uZXQwCQYDVR0SBAIwADBBBggrBgEFBQcBAQQ1MDMw
MQYIKwYBBQUHMAKGJWh0dHA6Ly9wa2kudW5pbW9yZS5pdC9jYS9pc3N1ZXJzLmh0bWwwOwYD
VR0fBDQwMjAwoC6gLIYqaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwu
ZGVyMDkGCWCGSAGG+EIBBAQsFipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2NybDAy
L2NybC5kZXIwMgYJYIZIAYb4QgEDBCUWI2h0dHA6Ly9wa2kudW5pbW9yZS5pdC9jcmwvY2Fj
cmwuY3JsMDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vbWFpbC51bmltb3JlLml0L2Zpcm1hL2Nw
cy8xLjEvMIHWBgNVHSAEgc4wgcswQwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRw
Oi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEG
CCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMEEGCisG
AQQB6BMBAQEwMzAxBggrBgEFBQcCARYlaHR0cDovL21haWwudW5pbW9yZS5pdC9maXJtYS9j
cHMvMS4xLzANBgkqhkiG9w0BAQUFAAOCAQEAKmqxUUS+4oleNai3rBfoKjPFL89jvQxAJsPm
XdL5+WFwS5Om867DE14aAit8twetMmfDe3evx0ZC07+p5/KdhjNsfkYviKt/DwlTXt19ayOY
hnbsY6pj3PJk3dxInfpXMZjTb6uWYQPTfcXj9M5RDOBsB2hUEoqWKp9zriVpl1UbebvnuYHP
h4wBDeACymr2Etq9NcfA6EC6c6lU6hwh07UuZEmqAdZP6rr/qsloeijsFQaIzkRfw/cylmlz
eaPcYRdR2qDjgsFZGTh9JJ8SPTAYq44e3dpN7ttXnw4UN2OV+Ctf/XxCjMpsWBDOOxXCeFXm
vF8lF79I0pq8BXhmiDCCBoYwggVuoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZwxJzAlBgkq
hkiG9w0BCQEWGHN1cHBvcnRfZmlybWFAdW5pbW9yZS5pdDE0MDIGA1UEAxMrQXV0b3JpdGEn
IGRpIENlcnRpZmljYXppb25lIFVuaU1vUmUtRXVyb1BLSTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwHhcNMDMxMjMwMTUx
MjI5WhcNMDQxMjI5MTUxMjI5WjBvMQswCQYDVQQGEwJJVDEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTEUMBIGA1UECxMLVHJ1c3RjZW50ZXIxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDG
oL1pqELlnFAB8iDBcUGi1nmy4u+Jf6HGvv1ZI33ti1p9Q5pSsnCd5PCkcMTXO/hSV6Hcu6EL
PEwYY0fyaySf3A5HcCzLz3A1n70E2OrlfqUz+d2A7H+gpSrtV5BlGiz49BCFjiBeh7k4xwKE
0Pasxv4vLg+Wnb+lSEuuwTQx0wIDAQABo4IDgTCCA30wCQYDVR0TBAIwADARBglghkgBhvhC
AQEEBAMCBLAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYK
KwYBBAGCNxQCAjBdBglghkgBhvhCAQ0EUBZOQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQWRt
aW5pc3RyYXRvciBvZiBVbml2ZXJzaXRhJyBkaSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMB0G
A1UdDgQWBBT3vBE+YoleG9jSpVAqZJFPeHuu3TB6BgNVHSMEczBxgBSNtmANJRb3qJMqiHet
v5V+4c1urqFVpFMwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNVBAMT
J0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYICA+YwIgYDVR0RBBsw
GYEXbWFkd29sZkBoYWNrbWFzdGVycy5uZXQwCQYDVR0SBAIwADBBBggrBgEFBQcBAQQ1MDMw
MQYIKwYBBQUHMAKGJWh0dHA6Ly9wa2kudW5pbW9yZS5pdC9jYS9pc3N1ZXJzLmh0bWwwOwYD
VR0fBDQwMjAwoC6gLIYqaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwu
ZGVyMDkGCWCGSAGG+EIBBAQsFipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2NybDAy
L2NybC5kZXIwMgYJYIZIAYb4QgEDBCUWI2h0dHA6Ly9wa2kudW5pbW9yZS5pdC9jcmwvY2Fj
cmwuY3JsMDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vbWFpbC51bmltb3JlLml0L2Zpcm1hL2Nw
cy8xLjEvMIHWBgNVHSAEgc4wgcswQwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRw
Oi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEG
CCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMEEGCisG
AQQB6BMBAQEwMzAxBggrBgEFBQcCARYlaHR0cDovL21haWwudW5pbW9yZS5pdC9maXJtYS9j
cHMvMS4xLzANBgkqhkiG9w0BAQUFAAOCAQEAKmqxUUS+4oleNai3rBfoKjPFL89jvQxAJsPm
XdL5+WFwS5Om867DE14aAit8twetMmfDe3evx0ZC07+p5/KdhjNsfkYviKt/DwlTXt19ayOY
hnbsY6pj3PJk3dxInfpXMZjTb6uWYQPTfcXj9M5RDOBsB2hUEoqWKp9zriVpl1UbebvnuYHP
h4wBDeACymr2Etq9NcfA6EC6c6lU6hwh07UuZEmqAdZP6rr/qsloeijsFQaIzkRfw/cylmlz
eaPcYRdR2qDjgsFZGTh9JJ8SPTAYq44e3dpN7ttXnw4UN2OV+Ctf/XxCjMpsWBDOOxXCeFXm
vF8lF79I0pq8BXhmiDGCA2wwggNoAgEBMIGiMIGcMScwJQYJKoZIhvcNAQkBFhhzdXBwb3J0
X2Zpcm1hQHVuaW1vcmUuaXQxNDAyBgNVBAMTK0F1dG9yaXRhJyBkaSBDZXJ0aWZpY2F6aW9u
ZSBVbmlNb1JlLUV1cm9QS0kxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJl
Z2dpbyBFbWlsaWExCzAJBgNVBAYTAklUAgEBMAkGBSsOAwIaBQCgggIfMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MTIxMDE1NTAyMFowIwYJKoZIhvcN
AQkEMRYEFHcNwoQzf7z57V1XvCBzVsJVU8ClMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgZwxJzAlBgkqhkiG9w0BCQEWGHN1cHBvcnRfZmly
bWFAdW5pbW9yZS5pdDE0MDIGA1UEAxMrQXV0b3JpdGEnIGRpIENlcnRpZmljYXppb25lIFVu
aU1vUmUtRXVyb1BLSTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lv
IEVtaWxpYTELMAkGA1UEBhMCSVQCAQEwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGcMScwJQYJ
KoZIhvcNAQkBFhhzdXBwb3J0X2Zpcm1hQHVuaW1vcmUuaXQxNDAyBgNVBAMTK0F1dG9yaXRh
JyBkaSBDZXJ0aWZpY2F6aW9uZSBVbmlNb1JlLUV1cm9QS0kxLjAsBgNVBAoTJVVuaXZlcnNp
dGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYTAklUAgEBMA0GCSqGSIb3
DQEBAQUABIGAZcAVnoeVlbFLJC2vhf3ZeHW9WgsILO4n52wfIhrMzcVElK6cUIAnappG93uL
WfjsigZ7nW/EKowgdk0Gf8Qm4qaIExJgJl3Utjk4QBxy1O7w5uBWS3PndWs5PLeX7MiKgAc9
yuIvotnTjUnxr3eTCYXONfJJj1XgiNXRhTsnf2QAAAAAAAA=
--------------ms040003070100080006090908--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBB3WY68036082; Fri, 10 Dec 2004 19:32:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBB3WYM7036068; Fri, 10 Dec 2004 19:32:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.hackmasters.net (ppp-217-133-8-148.cust-adsl.tiscali.it [217.133.8.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBB3WJ3e035338 for <[e-mail]>; Fri, 10 Dec 2004 19:32:26 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id AD188FA081 for <[e-mail]>; Sat, 11 Dec 2004 04:57:28 +0100 (CET)
Received: by mail.hackmasters.net (Postfix, from userid 520) id 0170CFA082; Sat, 11 Dec 2004 04:57:26 +0100 (CET)
Received: from [10.5.122.160] (junk.hackmasters.net [10.5.122.160]) by mail.hackmasters.net (Postfix) with ESMTP id 06357FA081 for <[e-mail]>; Sat, 11 Dec 2004 04:57:25 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 11 Dec 2004 04:32:23 +0100
From: Massimiliano Pala <[e-mail]>
Reply-To: [e-mail]
Organization: Hackmasters.net
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Proposed Changes to RFC 3280
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040606040401000100030202"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on  zorba.hackmasters.net
X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00 autolearn=ham  version=2.60
X-Spam-Level: 
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms040606040401000100030202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello all,

going through rfc3280 and reading the sections 5, 5.1, 5.1.2.5 about
CRLs and nextUpdate field one idea came into my mind.
The rfc enforces the use of the nextUpdate field which envisages the
idea that new revocation information will be available within the
retained time value.

This could lead to some problems because all clients will query the
CRL repository upon CRL expiration.
Moreover, in practical environment, there is the common thought that
the nextUpdate filed carries the time when new revocation data will
be available, which (correct me if I am wrong) is not.

So my idea is very simple, indeed. I would suggest to leave the field
OPTIONAL (as in ASN.1).

If the field is not present, then compliant applications should check
for new CRL when validating a certificate. This is pretty the same way
OCSP handles the nextUpdate field within responses, isn't it?

Indeed the default behaviour for today CAs is to issue new CRLs as
soon as a certificate is revoked - why being forced to issue a new
CRL if no new data is indeed available ?

Let me know your comments, if there are no major objection I will
post a possible patch for the document to the list.

-- 

C'you,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]               [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                           Fax:    +39   178  270 2077
http://openca.sourceforge.net                   Mobile: [phone]

University of Modena and Reggio Emilia
Certification Authority Informations:

Authority Access Point                                  http://pki.unimo.it
Authority's Certificate:                http://pki.unimo.it/ca/issuers.html
Certificate Revocation List:              http://pki.unimo.it/crl/cacrl.crl
--o------------------------------------------------------------------------

--------------ms040606040401000100030202
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWoTCC
BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG
A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw
MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx
MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX
pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV
6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D
vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt
Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g
mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k
ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG
CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy
NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js
L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ
506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT
yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b
vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW
1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm
053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF
HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+
Azi6vNmzQwCbegU26NFazErhLS5qDXQwggUCMIID6qADAgECAgID5jANBgkqhkiG9w0BAQUF
ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ
dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMTIyMjE0MDAwMFoXDTA1MTIz
MTEyMDAwMFowgZwxJzAlBgkqhkiG9w0BCQEWGHN1cHBvcnRfZmlybWFAdW5pbW9yZS5pdDE0
MDIGA1UEAxMrQXV0b3JpdGEnIGRpIENlcnRpZmljYXppb25lIFVuaU1vUmUtRXVyb1BLSTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3Dc6grS/wQDT4vW50zSBT
d6GGqTeeke32VgyBTNwH74kYs+l9Lv8A4QNuLKCC/K+qXG8WUJCyrpgxbB+73JD/yxOAYggc
ou5FOKIfuUMlhsrxKrc8Z8LgeIxSEUxpNmvpX2BpE03+SfIr0IA2SnMPCGKmkc2lGqp2SCLd
2IrMOS/OFqJIhXOkzSU18FEWWEtc3JaZpc9NSDB5JO3XZf/gZ/BrtgF3cZBBDOK2tXCFQDja
Bhps47AhfbJUUsvQfK76spi8t2o+ygvrhmcDr77e/w8zeq4mPP9UfX/bLKVSp8Uxlb79fNiO
QMxfeXfM21hVGlCjFEyquqgTwNlCBr6rAgMBAAGjggGWMIIBkjBcBggrBgEFBQcBAQRQME4w
KAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYIKwYBBQUHMAKG
Fmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMA8GA1UdEwEB/wQFMAMBAf8wgZMGA1Ud
IASBizCBiDBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3Br
aS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0
dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wDgYDVR0PAQH/BAQDAgH2MB0G
A1UdDgQWBBSNtmANJRb3qJMqiHetv5V+4c1urjAfBgNVHSMEGDAWgBSqPBPJSQtczbjTIODF
lZczM10kEzANBgkqhkiG9w0BAQUFAAOCAQEAtmdzId6h0fTMqSZ1X7b1nVSielwpEgi1AJww
WnMTClOZHBDDIFwbc/pzgJ4de75cxq/g516XEmD/1vfRr2Hes9j/pr3uNnRDTp8wWH9wpT5P
YwZZooqfcCcD9HT5SSb+7kn+hl6QJUmVS7l8NigSsN3ouYapIest2nV8HYToAdeECHpJ1/aD
0Ovrla6vB0YgmJNPh3ER+klSrdgjuIeY4GbBEfLJuvWpRJZgIj1RGPFwo98M4/8WG0sMnFh6
CxG2j4GvR/C/Wm/CG48qGT2a9gmv3oI7Qv1KP71l76lHxxajmWLWqOJNvLigWcveIkOZwIbp
4v8GZOK0c+v0EH+ivjCCBoYwggVuoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZwxJzAlBgkq
hkiG9w0BCQEWGHN1cHBvcnRfZmlybWFAdW5pbW9yZS5pdDE0MDIGA1UEAxMrQXV0b3JpdGEn
IGRpIENlcnRpZmljYXppb25lIFVuaU1vUmUtRXVyb1BLSTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwHhcNMDMxMjMwMTUx
MjI5WhcNMDQxMjI5MTUxMjI5WjBvMQswCQYDVQQGEwJJVDEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTEUMBIGA1UECxMLVHJ1c3RjZW50ZXIxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDG
oL1pqELlnFAB8iDBcUGi1nmy4u+Jf6HGvv1ZI33ti1p9Q5pSsnCd5PCkcMTXO/hSV6Hcu6EL
PEwYY0fyaySf3A5HcCzLz3A1n70E2OrlfqUz+d2A7H+gpSrtV5BlGiz49BCFjiBeh7k4xwKE
0Pasxv4vLg+Wnb+lSEuuwTQx0wIDAQABo4IDgTCCA30wCQYDVR0TBAIwADARBglghkgBhvhC
AQEEBAMCBLAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYK
KwYBBAGCNxQCAjBdBglghkgBhvhCAQ0EUBZOQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQWRt
aW5pc3RyYXRvciBvZiBVbml2ZXJzaXRhJyBkaSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMB0G
A1UdDgQWBBT3vBE+YoleG9jSpVAqZJFPeHuu3TB6BgNVHSMEczBxgBSNtmANJRb3qJMqiHet
v5V+4c1urqFVpFMwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNVBAMT
J0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYICA+YwIgYDVR0RBBsw
GYEXbWFkd29sZkBoYWNrbWFzdGVycy5uZXQwCQYDVR0SBAIwADBBBggrBgEFBQcBAQQ1MDMw
MQYIKwYBBQUHMAKGJWh0dHA6Ly9wa2kudW5pbW9yZS5pdC9jYS9pc3N1ZXJzLmh0bWwwOwYD
VR0fBDQwMjAwoC6gLIYqaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwu
ZGVyMDkGCWCGSAGG+EIBBAQsFipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2NybDAy
L2NybC5kZXIwMgYJYIZIAYb4QgEDBCUWI2h0dHA6Ly9wa2kudW5pbW9yZS5pdC9jcmwvY2Fj
cmwuY3JsMDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vbWFpbC51bmltb3JlLml0L2Zpcm1hL2Nw
cy8xLjEvMIHWBgNVHSAEgc4wgcswQwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRw
Oi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEG
CCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMEEGCisG
AQQB6BMBAQEwMzAxBggrBgEFBQcCARYlaHR0cDovL21haWwudW5pbW9yZS5pdC9maXJtYS9j
cHMvMS4xLzANBgkqhkiG9w0BAQUFAAOCAQEAKmqxUUS+4oleNai3rBfoKjPFL89jvQxAJsPm
XdL5+WFwS5Om867DE14aAit8twetMmfDe3evx0ZC07+p5/KdhjNsfkYviKt/DwlTXt19ayOY
hnbsY6pj3PJk3dxInfpXMZjTb6uWYQPTfcXj9M5RDOBsB2hUEoqWKp9zriVpl1UbebvnuYHP
h4wBDeACymr2Etq9NcfA6EC6c6lU6hwh07UuZEmqAdZP6rr/qsloeijsFQaIzkRfw/cylmlz
eaPcYRdR2qDjgsFZGTh9JJ8SPTAYq44e3dpN7ttXnw4UN2OV+Ctf/XxCjMpsWBDOOxXCeFXm
vF8lF79I0pq8BXhmiDCCBoYwggVuoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZwxJzAlBgkq
hkiG9w0BCQEWGHN1cHBvcnRfZmlybWFAdW5pbW9yZS5pdDE0MDIGA1UEAxMrQXV0b3JpdGEn
IGRpIENlcnRpZmljYXppb25lIFVuaU1vUmUtRXVyb1BLSTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwHhcNMDMxMjMwMTUx
MjI5WhcNMDQxMjI5MTUxMjI5WjBvMQswCQYDVQQGEwJJVDEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTEUMBIGA1UECxMLVHJ1c3RjZW50ZXIxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDG
oL1pqELlnFAB8iDBcUGi1nmy4u+Jf6HGvv1ZI33ti1p9Q5pSsnCd5PCkcMTXO/hSV6Hcu6EL
PEwYY0fyaySf3A5HcCzLz3A1n70E2OrlfqUz+d2A7H+gpSrtV5BlGiz49BCFjiBeh7k4xwKE
0Pasxv4vLg+Wnb+lSEuuwTQx0wIDAQABo4IDgTCCA30wCQYDVR0TBAIwADARBglghkgBhvhC
AQEEBAMCBLAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYK
KwYBBAGCNxQCAjBdBglghkgBhvhCAQ0EUBZOQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQWRt
aW5pc3RyYXRvciBvZiBVbml2ZXJzaXRhJyBkaSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMB0G
A1UdDgQWBBT3vBE+YoleG9jSpVAqZJFPeHuu3TB6BgNVHSMEczBxgBSNtmANJRb3qJMqiHet
v5V+4c1urqFVpFMwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNVBAMT
J0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYICA+YwIgYDVR0RBBsw
GYEXbWFkd29sZkBoYWNrbWFzdGVycy5uZXQwCQYDVR0SBAIwADBBBggrBgEFBQcBAQQ1MDMw
MQYIKwYBBQUHMAKGJWh0dHA6Ly9wa2kudW5pbW9yZS5pdC9jYS9pc3N1ZXJzLmh0bWwwOwYD
VR0fBDQwMjAwoC6gLIYqaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwu
ZGVyMDkGCWCGSAGG+EIBBAQsFipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2NybDAy
L2NybC5kZXIwMgYJYIZIAYb4QgEDBCUWI2h0dHA6Ly9wa2kudW5pbW9yZS5pdC9jcmwvY2Fj
cmwuY3JsMDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vbWFpbC51bmltb3JlLml0L2Zpcm1hL2Nw
cy8xLjEvMIHWBgNVHSAEgc4wgcswQwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRw
Oi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEG
CCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMEEGCisG
AQQB6BMBAQEwMzAxBggrBgEFBQcCARYlaHR0cDovL21haWwudW5pbW9yZS5pdC9maXJtYS9j
cHMvMS4xLzANBgkqhkiG9w0BAQUFAAOCAQEAKmqxUUS+4oleNai3rBfoKjPFL89jvQxAJsPm
XdL5+WFwS5Om867DE14aAit8twetMmfDe3evx0ZC07+p5/KdhjNsfkYviKt/DwlTXt19ayOY
hnbsY6pj3PJk3dxInfpXMZjTb6uWYQPTfcXj9M5RDOBsB2hUEoqWKp9zriVpl1UbebvnuYHP
h4wBDeACymr2Etq9NcfA6EC6c6lU6hwh07UuZEmqAdZP6rr/qsloeijsFQaIzkRfw/cylmlz
eaPcYRdR2qDjgsFZGTh9JJ8SPTAYq44e3dpN7ttXnw4UN2OV+Ctf/XxCjMpsWBDOOxXCeFXm
vF8lF79I0pq8BXhmiDGCA2wwggNoAgEBMIGiMIGcMScwJQYJKoZIhvcNAQkBFhhzdXBwb3J0
X2Zpcm1hQHVuaW1vcmUuaXQxNDAyBgNVBAMTK0F1dG9yaXRhJyBkaSBDZXJ0aWZpY2F6aW9u
ZSBVbmlNb1JlLUV1cm9QS0kxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJl
Z2dpbyBFbWlsaWExCzAJBgNVBAYTAklUAgEBMAkGBSsOAwIaBQCgggIfMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MTIxMTAzMzIyM1owIwYJKoZIhvcN
AQkEMRYEFDyEz8budq9jMDnxeRoxbUwCc7sQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGzBgkrBgEEAYI3EAQxgaUwgaIwgZwxJzAlBgkqhkiG9w0BCQEWGHN1cHBvcnRfZmly
bWFAdW5pbW9yZS5pdDE0MDIGA1UEAxMrQXV0b3JpdGEnIGRpIENlcnRpZmljYXppb25lIFVu
aU1vUmUtRXVyb1BLSTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lv
IEVtaWxpYTELMAkGA1UEBhMCSVQCAQEwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGcMScwJQYJ
KoZIhvcNAQkBFhhzdXBwb3J0X2Zpcm1hQHVuaW1vcmUuaXQxNDAyBgNVBAMTK0F1dG9yaXRh
JyBkaSBDZXJ0aWZpY2F6aW9uZSBVbmlNb1JlLUV1cm9QS0kxLjAsBgNVBAoTJVVuaXZlcnNp
dGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYTAklUAgEBMA0GCSqGSIb3
DQEBAQUABIGAtGQlkXdAI6eeFyClnchqk4j3WeCTDlzl9TwkTzitdMJqo5yDmTrEwnWvR5ni
AC5TfqV0szSlEwaknjKz3add8mxw70RLP6IB7zKn2x99TQjiDLydOfuH28V0kFqjCGIXp2IO
ChHc1rxXb2m3DSAxGl/vfBJjyDZgoqAELLM1PrkAAAAAAAA=
--------------ms040606040401000100030202--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBANJJw5078119; Fri, 10 Dec 2004 15:19:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBANJJTC078118; Fri, 10 Dec 2004 15:19:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBANJIXf078038 for <[e-mail]>; Fri, 10 Dec 2004 15:19:18 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 15:19:15 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Fri, 10 Dec 2004 15:19:13 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Fri, 10 Dec 2004 15:19:17 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTe25wkruX8j+UURKiEfyoOq0IE0QAMS1yg
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Dec 2004 23:19:13.0976 (UTC) FILETIME=[A9841B80:01C4DF0E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBANJIXf078108
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,


* -----Original Message-----
* From: Denis Pinkas [mailto:[e-mail]]
* Sent: Friday, December 10, 2004 9:14 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* > Hi Peter,
* >
* > Ho they are combined is defined in section 1.3
* >
* > " The referenced (policy) value indicates either a partial or full
set
* > of parameters. The client can therefore omit these agreed parameters
* > from the request, only passing any parameters which are not
specified by
* > the previously agreed policy.  Therefore in the simplest form, with
* > validation polices which define every parameter necessary, a SCVP
* > request need only contain the certificate to be validated, the
* > validation policy and any run-time parameters for the request.
* >
* > SCVP server also publishes its default validation policy settings.
The
* > default policy can be requested for validation
* 
* Up to here this is fine.
* 
* > and the client can  override any default value in the request if
* required.
* 
* I do not agree here. The default policy is used when the client does
not
* specify anything and thus there are no parameters for the default
* validation
* policy.
[TF] You are advocating making the default policy selection implicit by
omitting the policy form the request, we have chosen to make it explicit
be defining a OID to represent the default policy. Functionally they are
the same.
* 
* If the client specifies a policy it is one supported by the server
which
* may
* or may not have parameters.
[TF] Agreed
* 
* Some parameters may be built-in in the policy and cannot be changed
while
* some others may be allowed to be changed by the client.
[TF] Agreed
* 
*  > The default
* > values are also used when processing requests which reference a
* > validation policy other than the default one that does not contain
the
* > full set of parameters necessary for validation and the client has
also
* > omitted the missing values in the request.
* 
* This sentence is rather long and complicated. I read it three times
and
* could not understand the exception for the default policy. If the
default
* policy is addressed above, we can simplify the sentence and only
mention:
[TF] All models contain the concept of default and non-default policy.
If you specify a non-default policy, any parameter defined in the policy
cannot be overridden by the client. Any parameter not defined by policy
may be supplied by the client or the client can defer to the server
default. If you specify the default policy, every parameter can be
overridden.
* 
* "The default values are also used when processing requests which
reference
* a
* validation policy that does not contain the full set of parameters
* necessary
* for validation and the client has also omitted the missing values in
the
* request."
* 
* > Therefore a client can also
* > simplify the request by omitting a parameter from a request if the
* > default value published by the server is acceptable.
* 
* This last sentence is correct.
* 
* > Further 3.1.5.1 also requires
* > " If there are any conflicts between the non-default policy
referenced
* > in the request and any supplied parameter values in the request,
then
* > the server MUST return an error response."
* 
* There should be non such concept of a "non-default policy".
* Suppress "non-default" in the sentence.
[TF] since we have the concept of default policy - we by definition get
the non-default policy.
* 
* > Therefore if you use the non-default policy, the policy value take
* > precedence over the request value and cannot be overridden by the
* > request. For the default policy the client can override any value.
* 
* No. See above.
* 
* Denis
* 
* > If the policy and client both omit a parameter, then the server
default
* > value is used.
* >
* > Trevor
* >
* > * -----Original Message-----
* > * From: Peter Sylvester [mailto:[e-mail]]
* > * Sent: Thursday, December 09, 2004 3:49 AM
* > * To: [e-mail]; Trevor Freeman
* > * Cc: [e-mail]
* > * Subject: RE: SCVP 16 comments deadline
* > *
* > * Either I was unclear in my question or you have totally
misunderstood
* > it,
* > * or I don't understand what your are responding.
* > *
* > * > Hi Peter,
* > * > All parameter assonated with policy mapping are names the same.
If
* > you
* > * > want guidance on their use in combination with the policy
reference
* > see
* > * > section 1.3.
* > * It is obviously not difficult to guess which names corresponds,
that
* > * is not the problem.
* > *
* > *
* > * > SCVP only supports one policy per request therefore if you want
to
* > * > process different polices for different certificates - send
* > different
* > * > requests.
* > * Where do I talk about different policies and different
certificates,
* > * are you confusing this with another message?
* > *
* > * I am just asking how parameters from the client and the server are
* > * combined in a request for one signed cert with one policy. And, to
* > * be sure, I can also assume that a client sets all the input flags
* > * or none, if you want.
* > *
* > * The current syntax allows all kind of combinations of settings and
* > * by the client and the server, it is not specified:
* > *
* > * - how they are combined
* > * - whether there this only a subset of useful meanings.
* > *
* > * > Trevor
* > * >
* > * > * -----Original Message-----
* > * > * From: Peter Sylvester [mailto:[e-mail]]
* > * > * Sent: Tuesday, December 07, 2004 4:15 AM
* > * > * To: Trevor Freeman
* > * > * Cc: [e-mail]
* > * > * Subject: Re: SCVP 16 comments deadline
* > * > *
* > * > * There are several boolean values like
* > * > *
* > * > *   ValidationPolicy ::= SEQUENCE {
* > * > *     ...
* > * > *     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* > * > *
* > * > * and a policy definition.
* > * > *
* > * > *   ValidationPolValues ::=SEQUENCE  {
* > * > *     ...
* > * > *     inhibitPolMap            BOOLEAN,
* > * > *
* > * > *
* > * > * - It would be nice to use the same field names.
* > * > *
* > * > * - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap
together
* > * > *   with some apppropriate tagging, it doesn't make much sense
to
* > * > *   me to code useless values.
* > * > *
* > * > * Would it be possible to add some statement about the intended
* > * > * meaning of the 6 possible combination:
* > * > *
* > * > *
* > * > * inhibitPolMap = FALSE
* > * > *
* > * > * inhibitPolicyMapping absent  1
* > * > *                      FALSE   2
* > * > *                      TRUE    3
* > * > *
* > * > * inhibitPolMap = TRUE
* > * > *
* > * > * inhibitPolicyMapping absent  4
* > * > *                      FALSE   5
* > * > *                      TRUE    6
* > * > *
* > * > *
* > * > * Does it mean that when the client value takes preceedence over
the
* > * > * server value?
* > * > *
* > * > * 1 = FALSE
* > * > * 2 = FALSE
* > * > * 3 = TRUE
* > * > * 4 = TRUE
* > * > * 5 = FALSE
* > * > * 6 = TRUE
* > * > *
* > * > *
* > * > * It had been said some time ago (as far as I remember) that
these
* > * > * inputs are not global ones but in principle for each of the
* > * > * certs to be asked for. what was the conclusion why they stay
* > global
* > * > * for all certs?
* > * >
* > * >
* > * >
* >
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAL9eql016663; Fri, 10 Dec 2004 13:09:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAL9eWH016662; Fri, 10 Dec 2004 13:09:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAL9Y8e016438 for <[e-mail]>; Fri, 10 Dec 2004 13:09:39 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Fri, 10 Dec 2004 13:09:31 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 13:09:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Fri, 10 Dec 2004 13:09:43 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTeuHHJ5fiz+maGQy62iJvpDVWsmwAQ7aEg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Dec 2004 21:09:30.0607 (UTC) FILETIME=[8A443FF0:01C4DEFC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBAL9d8e016639
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Friday, December 10, 2004 5:02 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* > *
* > *
* > * Does this means that the validate Algorithm is cert specific and
not
* > * request specific?
* > [TF] The request specifies a policy, which in tern references an
* > algorithm. The policy applies globally to the request. There is no
* > relationship between the certificate and the algorithm.
* > Trevor
* >
* 
* I agree that it seems sufficient for one request to have the same
* *algorithm(s)* performed for all the certs, but the only examples
defined
* contain a *parameter* which is specific to each cert, i.e. an
* identity/name
* that has to be matched with the content of a cert, thus currently the
* usage of this 'extension' features limits the requests to one cert
only.
* 
* For requests concerning SSL servers, IPsec auths, *one signature*, one
* cert will be present in the request, a case for multiple requests
*may*
* be certs for encryption. It may be sufficient to allow multiple names
* for e-mail protection certs in the existing parameter, and a rule
saying
* that names must be present.
[TF] If you just want to check all the certs to be email protection, you
can do that via the basic policy. If you want ot check specific certs
with specific names, yes you have to submit multiple requests.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAL2DUU006710; Fri, 10 Dec 2004 13:02:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAL2DlX006709; Fri, 10 Dec 2004 13:02:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAL27Qg006567 for <[e-mail]>; Fri, 10 Dec 2004 13:02:12 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Fri, 10 Dec 2004 13:02:05 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 13:02:04 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Fri, 10 Dec 2004 13:02:16 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTeuGot41fiFrBkREaYpqgenzxBJwAQmUGg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Dec 2004 21:02:04.0121 (UTC) FILETIME=[8023E490:01C4DEFB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBAL2CQg006704
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Friday, December 10, 2004 5:02 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* > [TF] How the server identifies the client is a mater of local server
* > policy.
* See my other message and a text proposal.
* 
* > *
* > * The 3379 text says:
* > *
* > *    When the DPV request is authenticated, the client SHOULD be
able to
* > *    include a client identifier in the request for the DPV server
to
* > copy
* > *    into the response.  Mechanisms for matching this identifier
with
* > the
* > *    authenticated identity depends on local DPV server conditions
* > and/or
* > *    the validation policy.
* > *
* > * The client has no way to declare its identity in the protocol,
* > * and there no provision of what this could be from what it would
* > * be derived from (IP address, DNS name of the host, ...), ...
* > [TF] The client can declare its identity in the request in a number
of
* > ways.
* >  	1. by including its signing certificate in the request
* > 	2. by including its DH certificate used to compute the hmac
* > 	3. By HMACing the request using a shared secret or password
* 
* None of these is a "declaration" of an identity. It is a means to
* authenticate
* the request at least in my opinion.
[TF] When I sign email, I don't include an additional attribute, I just
include my certificate. How is that not a declaration of identity.
* 
* Note the remark about 'may respond with an error' in
* the requirements. This is intended to mean that a server may reject
* a request when the declared entity is not one that can be
authenticated.
* (I don't think that it was meant that an error can be 'not
authorized')
* 
* >
* > What identity the server knows or uses for the client based on this
data
* > is a matter of local server policy
* >
* > *
* > * Why is this restricted to signed requests, and not to
'authenticated'?
* > [TF] Its not. Section 3 defies signed requests as being either
* > signedData or authenticatedData.
* 
* Ok.
* 
* > *
* > * As already said in another may, this text could make sense if
there
* > * would be a corresponding requestorName in the request.
* 
* you seem to agree?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAJ56kE083473; Fri, 10 Dec 2004 11:05:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAJ56Jx083472; Fri, 10 Dec 2004 11:05:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAJ56Z7083456 for <[e-mail]>; Fri, 10 Dec 2004 11:05:06 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Fri, 10 Dec 2004 11:05:02 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 11:05:04 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Fri, 10 Dec 2004 11:05:03 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTeuEdsUocAu8fQSWCXeYksnv8vZgAMdMqw
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Dec 2004 19:05:04.0519 (UTC) FILETIME=[2821A170:01C4DEEB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBAJ56Z7083467
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Friday, December 10, 2004 5:01 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* > [TF] I am saying how the server identifies the client for the
supplied
* > information is a matter of local policy to the server.
* 
* Repeating this three time doesn't make the statement true. It is
* totally contrary to what is described in the requirements document.
* 
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.  The DPV server MAY choose to blindly copy
the
*    identifier, omit the identifier, or return an error response.
[TF] 
Reputedly copying the same section from 3379 has the same effect. I
believe the current draft of SCVP complies with the text. The name must
be in the certificate. I don't see value in repeating the value twice in
the request.

* 
* If you don't agree about the meaning of 'client identifier' in the
* following excerpt, then we will not be able to get anywhere further.
* 
* If the intention of the excerpt above would be that the client does
not
* explicitely do provide an identifier, then the text would be like:
* 
*    When the DPV requets is authenticated, then server MAY return to
the
*    client an identifier derived from the authentication.
* 
* if you want to derive *one* identifier from the authentication, what
will
* you set for a certificate with one or more instances of
subjectAltname.
* The best you can do is to return all identities.
* 
* The client has to have a means to explicitely present his identity.
* 
* This is an identifier where the client declares its identity,
furthermore
* this identifier being an octet string without any structure is not
* something that is common in PKI environments, in particular you
already
* return a GeneralNames structure in the requesterName.
* 
* I simply repeat my request to add requesterName and a responderName
* structure
* in both the request and the response.
* 
* here a text proposal:
* 
* x.x.x Entity identification.
* 
* Since an SCVP response MAY be used by a client to demonstrate to
another
* relying party that certificate validation has been duly performed, the
* protocol allows to add identities of requesting clients and responding
* server to the response.
* 
* An identity is encoded as GeneralName. (cf. syntax)
* 
* Servers may have more than one identity, for example, a URI
* to access to the service, or a DN related or not to CAs.
* In particular, an SCVP server may have the same identity as a CA
* for which the server can provide answers in a similar way as an
* OCSP server.
* 
* The protocol is as follows:
* 
* x.x.x.1 requesterName
* 
* This field in the request indicates one or more identities
participating
* in the creation of the request. A client MAY add this field to a
request.
* If the request is authenticated, one of the presented identities
SHOULD
* match with at least one identity that can be derived from
authentication.
* A server MAY accept a request even if the presented identities do not
* correspond to one derived from authentication. If the request cannot
be
* authenticated, a server SHOULD reject the request if it contains this
* field.
* 
* On relaying, a relay MAY choose not to copy the presented identity to
* the relayed request, e.g., to anonymize the requester.
* 
* This field SHOULD be returned as is in the response. A server MAY
choose
* to add additional identities. This may be done when a relay is
involved,
* when an authenticated identity is different.
* 
* (merge some stuff from the existing requesterName if necessary).
* 
* x.x.x.1 responderName
* 
* This field in the request indicated identities of one or more servers
that
* are intending to participate in the construction of the response. This
* may be used for example to indicate to a relaying proxy the identity
of
* another scvp server.
* 
* This field in the response indicate the identities of the servers that
* have participated in creating the response. There is no particular
* relationship with the field with the same name in the input.
* 
* ------
* 
* Now we can treat the usefulness of the requester/responder for,loop
* control independantly.
* 
* > *
* > * Since two years or so I am asking that you just make two elements
* > *
* > * requestor GeneralNames
* > * responder GeneralNames
* > *
* > * in both the request and the response. (and to get rid of the octet
* > string
* > * stuff)
* > *
* > * I may have not understod your intention of "responder", if this is
a
* > pure
* > * local reference of the RESPONSE vs the repspoinder, then I think a
* > * sequence number would be more appropriate.
* > *
* 
* what is the current definition of responder good for? You menton
something
* below, see later.
* 
* 
* > * > *
* > * > * The new text replacing "requestor" in chapter 7 by
"requestorRef".
* > * > *
* > * > * > however,
* > * > * >  all of the octets MUST have values other than zero.
* > * > * Why? I would find it quite useful to add a
* > * > * hash of something local, if at all, the hash of its IP address
for
* > * > example
* > * > * (for which I can use the Nonce as well).
* > * > [TF] If you want me to remove the clause about values being
other
* > than
* > * > zero - I am happy to do so. Since this is of local significance
* > only, if
* > * > an implementation puts garbage in here it does not effect
* > * > interoperability.
* > * How do relate 'local significance only' and the usage of such
fields
* > * for 'loop control'. The significance not just local.
* > * If relays just put "relay" as a local reference you will have
* > problems.
* > *
* > * LOOONG time ago, I told you that an encoding of identifiers in an
* > octet
* > * string
* > * sounds strange, given that we have lots of ways and that you don't
* > provide
* > * any guideline on how identifiers can be encoded.
* > *
* > * Although you violantly rejected all proprosals to change this, you
* > * silently starting doing this in this version:
* > *
* > * - replacing an octet string by a sequence  (good, but omitted the
only
* > * reason
* > *   for not allowing zeros).
* > * - adding a requesterName item with is a generalnames
* > *
* > *
* 
* I probably expected some [TF] here, but well, you seem to agree.
* 
* > * > *
* > * > *   The requestRef item allows the client to associate a
response
* > with
* > * > *   a request.  The requestNonce provides an alternative
mechanism
* > ..
* > * > *
* > * > *   and you have also the requestorRef.
* > * > *
* > * > * The concept of trying to make loop control with values which
are
* > * > * explicitely
* > * > * defined as not globally unique sounds strange to me.
* > * > [TF] I have a big problem which the concept of global
uniqueness. I
* > * > class it the same bucket as non-repudiation.
* > *
* > * You are operating in a PKI where ID's of
* > * entities are unique within the PKI. If you don't trust the
* > * naming rule in your PKI, i.e. in some associated SCVP network
* > * which is much smaller, i.e. in the magnitude of the size of
* > * the CA name space.
* > [TF] Names give by an instance of a PKI are by definition not
global.
* 
* Can you point me to the definition?
* You may have a problem of ensuring uniqueness of name inside the PKI
* this but that's a similar proble as for the domain name system,
* it is organisational and not technical.
* Names inside a PKI are non-ambiguously associated to the
* entities as far as I remember.
* 
* I really don't see what you are arguing about?
* 
* > *
* > * Well, domain names work as far as I know. And telephone numbers
also.
* > * I don't say that non-repudiation doesn't work. I don't say that
* > * I agree or disagree with your comparision since I do not see why
this
* > * is relevant here.
* > *
* > * You are not even answering the question: You make loop control,
and
* > * you explicitely says that the identifiers that are used do only
have
* > * local significance. You could have said: An example for
identifiers
* > * that could be used for loop control are uuids generated on each
server
* > * startup using the server address and a time value.
* > [TF] Are you asking a question or suggesting text for the draft? If
you
* > want an example of how one might generate a identifier of local
* > significance I can do that.
* 
* An identifier of 'local' significance is simple: 'I'
* 
* It seems that we don't agree about the meaning of 'local
significance'.
* 
* You need that each potentially participating entity has at least one
* identifier which are distincet among the servers, but may or not
* have any global 'significance'.
* 
* If you want to keep the requester item for this, why not. it may be
* useful not to overload an 'identification', a nonce, a loop control
* tickmark
* in the same field.
* 
* > * > *  "The requestorRef item is also needed
* > * > *   to prevent looping in some configurations"
* > * > *
* > * > *  "No provisions are
* > * > *   made to ensure uniqueness of the requestorRef octet string"
* > * > *
* > * > * The usefulness of "requestorRef" as an identifier for the
request
* > * > * is pretty weak, since you can have a nonce if it is for each
* > * > * request. use GeneralName(s) in a requestorName sequence as for
the
* > * > * response.
* > * > *
* > * > * page 34:
* > * > *
* > * > *   The requestorRef and the responder items MUST be included if
the
* > * > request
* > * > * included a
* > * > *   requestor item.
* > * > *
* > * > * what does this mean? what is the relationship between a
* > requesterRef
* > * > and
* > * > * responder?
* > * > [TF] If requestorRef is populated, it means it's a relayed
request
* > in
* > * > which case the responder is of significance.
* > *
* > * No. any client can set a requestorRef, independant of whether the
* > request
* > * will be relayed. What is the significance of responder? In your
spec
* > * it is only of local signifance for the responding server? waht can
* > this
* > * be good for?
* 
* > [TF] It good for detecting loops. The server adds an identifier
which it
* > recognizes to the response. It is the only one rrequired to
recognize
* > the value so it can put whatever it wants in the field. There is no
need
* > to standardize the behavior of the SCVP server in this regard.
* 
* To be sure: The question was: "What is the significance of responder?"
* How does this value occur in the loop control algo? So far, the server
* just adds this, and noone is doing somthing with it, at least not in
* the current spec?
* 
* > *
* > * > *
* > * > * If I'd be interested in anything identifying the response,
then it
* > is
* > * > * a sequence of identifiers of the servers that have partipated,
and
* > * > some
* > * > * local ids or "serial number' like thing if I want to go to
that
* > server
* > * > and
* > * > * asks 'did you really tell this to my friend'.
* > * > *
* > * > *
* > * > * Chapter 7: Denis is right that the spec does not describe how
* > relaying
* > * > is
* > * > * performed, i.e. how a response is created from a response
received
* > * > from
* > * > * another
* > * > * server by a 'proxy'.
* > * > [TF] What specifically are you looking for?
* > *
* > * A working specification that includes:
* > *
* > * - how a request received is transformed into a new request by a
relay,
* > *   which fields are copied, or not, or may.
* > * - how the response is transformed into a response to the original
* > request
* > *   there are SEVERAL options, in particulat the one that addresses
* > *   the requirement of allowing a response as part of another one.
* > [TF] OK. I will add that.
* good.
* 
* Would it be possible to send a draft to the list before it get graved
into
* electronic marble.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAIu5wa082476; Fri, 10 Dec 2004 10:56:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAIu5OA082475; Fri, 10 Dec 2004 10:56:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAIu212082464 for <[e-mail]>; Fri, 10 Dec 2004 10:56:04 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Fri, 10 Dec 2004 10:55:57 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Fri, 10 Dec 2004 10:56:07 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Fri, 10 Dec 2004 10:55:58 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTePXmMh8qFTqvORfOOY0m+wOH2SQAqgv4g
From: "Trevor Freeman" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Dec 2004 18:56:07.0576 (UTC) FILETIME=[E816A180:01C4DEE9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBAIu412082470
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,
No wanting to rathole on this sine time is short, the section of the
document in question which Denis referred to is dealing with the set of
request that the client can make to the server. We agree that the client
can ask for path construction without revocation checking. I think it
legitimate a DPD client could ask for revocation checking because it has
already be able to build a path. Conceivably a DPV client could do the
same because it pervious asked for the path to be constructed and just
wants the revocation data refreshed. 

However to get to the bottom line, is there a specific problem with the
text in section 3.1.2
Trevor

* -----Original Message-----
* From: David A. Cooper [mailto:[e-mail]]
* Sent: Thursday, December 09, 2004 2:22 PM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* I must say that I agree with Seth and Denis.  I was under the
impression
* that "Do revocation status checking on the certification path" really
* meant "build and validated certification path to a trust anchor and do
* revocation status checking on the certification path".  While I can
see
* that there may be circumstances in which one would request a validated
* certification path without requiring revocation status checking, I
can't
* see requesting revocation status checking without requesting that the
* path be validated.
* 
* It is certainly the case that one can not "do revocation status
checking
* on the certification path" without also building a certification path.
* Since the client can not provide a certification path, revocation
status
* checking must be performed on a path that is built by the server.  I
* suppose you could argue that this simply means that a well formed
query
* can not include the id-stc-build-status-checked-pkc-path without also
* including either the id-stc-build-pkc-path or
* id-stc-build-valid-pkc-path check.  But, I see see the need for this.
* 
* A DPD client would include the id-stc-build-pkc-path along with the
* id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info wantBacks.
* If the DPD client included the id-swb-pkc-revocation-info wantBack, it
* wouldn't need to also include the id-stc-build-status-checked-pkc-path
* check.  If the DPD client did not include the
id-swb-pkc-revocation-info
* wantBack, then would not include the
* id-stc-build-status-checked-pkc-path check.
* 
* So, I would argue that the id-swb-pkc-revocation-info wantBack would
* only be used in the case that the client was requesting a validated
* certification path.  The way that I had interpreted the currently
* defined checks items, an SCVP query would only include one check since
* each successive check included the requirements of the previous one:
* id-stc-build-valid-pkc-path included the requirement to build a path
* (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
* included the requirement to build a validated path
* (id-stc-build-valid-pkc-path).
* 
* Under what circumstances can you envision a client wanting the server
to
* do revocation status checking on a certification path (that is
* constructed by the server) without also including a requirement that
the
* certification path be validated?   If there are no reasonable
* circumstances in which a client would make such a query, why is it
* necessary for clients to be able to construct such a query?
* 
* Dave
* 
* Trevor Freeman wrote:
* 
* >Hi Seth,
* >A server can always go beyond what the client asked for. I don't see
* >that as strictly necessary in all cases such as if the client just
asks
* >for revocation. Untimely is a matter of local server policy. What the
* >server cannot do is return status or errors relating to the other
* >activities which  were beyond the request scope.
* >Trevor
* >
* While it might make sense for a client to only ask for revocation
* checking if the client could specify the certification path, it does
not
* seem to make sense given that the server chooses the certification
path
* for which revocation status checking will be performed.  If the client
* wants to specify a set of certificates for which it only wants to know
* the revocation status, that is what OCSP is for.
* 
* >
* >* -----Original Message-----
* >* From: Seth Hitchings [mailto:[e-mail]]
* >* Sent: Wednesday, December 08, 2004 11:34 AM
* >* To: Trevor Freeman
* >* Cc: [e-mail]
* >* Subject: RE: SCVP 16 comments deadline
* >*
* >* Trevor,
* >*
* >* For clarification, I assume that doing revocation status checks on
a
* path
* >* implies building
* >* a validated path?
* >*
* >* If I am correct, in what case would a client ever send more than
one
* >* check?
* >*
* >* Seth
* >*
* >* -----Original Message-----
* >* From: [e-mail]
* >[mailto:[e-mail]]
* >* On Behalf Of
* >* Trevor Freeman
* >* Sent: Wednesday, December 08, 2004 1:42 PM
* >* To: Denis Pinkas
* >* Cc: [e-mail]
* >* Subject: RE: SCVP 16 comments deadline
* >*
* >*
* >* Denis,
* >* I know of several systems who's policy is never to revoke the
identity
* >* certificate because
* >* they have other mechanisms to address the issue.
* >* They are using authorization bound to the identity and they either
rely
* on
* >* short lived
* >* authorization assertions or revoke the authorization privilege
* assonated
* >* with the
* >* identity. Therefore in those cases not checking the revocation
status
* of
* >* the certificate
* >* makes perfect sense.
* >* Trevor
* >*
* >* * -----Original Message-----
* >* * From: [e-mail]
* >* [mailto:[e-mail]]
* >* * On Behalf Of Denis Pinkas
* >* * Sent: Wednesday, December 08, 2004 8:01 AM
* >* * To: Trevor Freeman
* >* * Cc: [e-mail]
* >* * Subject: Re: SCVP 16 comments deadline
* >* *
* >* *
* >* * Trevor,
* >* *
* >* * > Hi Denis,
* >* * > Below are responses to 1-16. Others will follow later.
* >* *
* >* * I am pleased that you accepted comments 13, 14, 15 and 16.
* >* * Among this list, I have a further remark on comment 4.
* >* *
* >* * > * 4. Page 13. Typo. Section 3.1.2 "checks"
* >* * > * The two following lines are in fact one line:
* >* * > *
* >* * > * Change:
* >* * > *
* >* * > *      - Build a validated certification path to a trust
anchor;
* and
* >* * > *
* >* * > *      - Do revocation status checks on the certification path.
* >* * > *
* >* * > * into:
* >* * > *
* >* * > *      - Build a validated certification path to a trust anchor
and
* >* * > *        do revocation status checks on the certification path.
* >* * > *
* >* * > [TF] Since this paragraph is listing the possible checks and
* building
* >* a
* >* * > path is a separate check to revocation checking, I think the
* current
* >* * > text is more accurate.
* >* *
* >* * I agree that "building a path is a separate check to revocation
* >* checking",
* >* * but revocation checking without building a validated path does
not
* make
* >* * sense.
* >* *
* >* * The full text currently is:
* >* *
* >* *      - Build a certification path to a trust anchor;
* >* *
* >* *      - Build a validated certification path to a trust anchor;
and
* >* *
* >* *      - Do revocation status checks on the certification path.
* >* *
* >* * The full text should be:
* >* *
* >* *      - Build a certification path to a trust anchor;
* >* *
* >* *      - Build a validated certification path to a trust anchor;
and
* >* *        do revocation status checks on the certification path.
* >* *
* >* * Denis
* >*
* >
* >
* >
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAIVNNv078217; Fri, 10 Dec 2004 10:31:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAIVNpr078216; Fri, 10 Dec 2004 10:31:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAIVGi8078007 for <[e-mail]>; Fri, 10 Dec 2004 10:31:23 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 10:31:16 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 10:31:14 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Fri, 10 Dec 2004 10:31:15 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTd7r9uvi55h3vOQ+CM+FfyWNF+4wA9NHIg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Dec 2004 18:31:14.0566 (UTC) FILETIME=[6E2F6260:01C4DEE6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBAIVNi8078205
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
You are assuming that there is only one possible matching algorithm for
a name type - which seems a fragile assertion. The be more  robust then
you supply a name and a matching rule identifier - which is what the
name validation algorithm does.
I have seen examples of cases where a name has been inserted into an asn
structure which does not cause an ASN decode error but the name is still
bad because the name semantics are wrong - so I don't subscribe to the
notion that all bad names cause asn decode errors.

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Thursday, December 09, 2004 4:58 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* 3.1.5.2.3 Name Validation Algorithm
* 
* I find the possibilities for the Name Validation Algorithm
* rather unsafisfying.
* 
* It should be possible IMO to have a matching simply by
* presenting whatever form of Generalname and this should
* be compared with the corresponding value in the cert.
* 
* In fact, the id-svp-dnValAlg sounds rather restrictive to
* me, it seems to imply that only the subject field is
* compared (or does this also compare with the Dirname in
* a subjectAltname).
* 
* This restriction about a DN doesn't seem necssary to me,
* Any generalName can be compared with any in the subjectAltname.
* 
* E.g. an IP address.
* 
* 'id-nvae-unknown-pupose'   ==> 'id-nvae-unknown-purpose'
* 
*   id-nvae-name-mismatch vs   The id-nvae-nameMismatch value
[TF] Fixed
* 
* please align the spellings of all the errors types.
* 
*   The id-nvae-badName value means the client supplied either and
*   empty or malformed name in the request.
* 
* what is a bad or malformed name? How can this happen without raising
* a general asn1 decoding error
* 
* since it comes right next?
* 
* ---
* cleanup the following text, please
* 
*   The userPolicySet item specifies a list of policy identifiers that
*   the SCVP server MUST use when forming and validating a certificate
*   If certPolicies is not specified, then any-policy MUST be used.
* 
* 3.1.5.3 userPolicySet
* 
*   The userPolicySet item specifies a list of certificate policy
*   identifiers that the SCVP server MUST use when constructing and
*   validating a certification path.  If userPolicySet is not specified,
*   then any-policy MUST be used.
* 
* 
[TF] I will change the userPolicy set to the following
The userPolicySet item specifies a list of certificate policy
identifiers that the SCVP server MUST use when constructing and
validating a certification path.

The requirement for use of the userPolicySet falling back to any-policy
is being dropped because the referenced policy or the default policy
will cover this.
* 
 
Trevor



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAHDsd0002149; Fri, 10 Dec 2004 09:13:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAHDsWh002148; Fri, 10 Dec 2004 09:13:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAHDqB2001986 for <[e-mail]>; Fri, 10 Dec 2004 09:13:53 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA38958; Fri, 10 Dec 2004 18:26:17 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004121018134185:440 ; Fri, 10 Dec 2004 18:13:41 +0100 
Message-ID: <[e-mail]>
Date: Fri, 10 Dec 2004 18:13:40 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/12/2004 18:13:42, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/12/2004 18:13:44, Serialize complete at 10/12/2004 18:13:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

> Hi Peter,
> 
> Ho they are combined is defined in section 1.3
> 
> " The referenced (policy) value indicates either a partial or full set
> of parameters. The client can therefore omit these agreed parameters
> from the request, only passing any parameters which are not specified by
> the previously agreed policy.  Therefore in the simplest form, with
> validation polices which define every parameter necessary, a SCVP
> request need only contain the certificate to be validated, the
> validation policy and any run-time parameters for the request.
> 
> SCVP server also publishes its default validation policy settings.  The
> default policy can be requested for validation 

Up to here this is fine.

> and the client can  override any default value in the request if required.

I do not agree here. The default policy is used when the client does not 
specify anything and thus there are no parameters for the default validation 
policy.

If the client specifies a policy it is one supported by the server which may 
or may not have parameters.

Some parameters may be built-in in the policy and cannot be changed while 
some others may be allowed to be changed by the client.

 > The default
> values are also used when processing requests which reference a
> validation policy other than the default one that does not contain the
> full set of parameters necessary for validation and the client has also
> omitted the missing values in the request. 

This sentence is rather long and complicated. I read it three times and 
could not understand the exception for the default policy. If the default 
policy is addressed above, we can simplify the sentence and only mention:

"The default values are also used when processing requests which reference a
validation policy that does not contain the full set of parameters necessary 
for validation and the client has also omitted the missing values in the 
request."

> Therefore a client can also
> simplify the request by omitting a parameter from a request if the
> default value published by the server is acceptable.

This last sentence is correct.

> Further 3.1.5.1 also requires
> " If there are any conflicts between the non-default policy referenced
> in the request and any supplied parameter values in the request, then
> the server MUST return an error response."

There should be non such concept of a "non-default policy".
Suppress "non-default" in the sentence.

> Therefore if you use the non-default policy, the policy value take
> precedence over the request value and cannot be overridden by the
> request. For the default policy the client can override any value.

No. See above.

Denis

> If the policy and client both omit a parameter, then the server default
> value is used.
> 
> Trevor
> 
> * -----Original Message-----
> * From: Peter Sylvester [mailto:[e-mail]]
> * Sent: Thursday, December 09, 2004 3:49 AM
> * To: [e-mail]; Trevor Freeman
> * Cc: [e-mail]
> * Subject: RE: SCVP 16 comments deadline
> * 
> * Either I was unclear in my question or you have totally misunderstood
> it,
> * or I don't understand what your are responding.
> * 
> * > Hi Peter,
> * > All parameter assonated with policy mapping are names the same. If
> you
> * > want guidance on their use in combination with the policy reference
> see
> * > section 1.3.
> * It is obviously not difficult to guess which names corresponds, that
> * is not the problem.
> * 
> * 
> * > SCVP only supports one policy per request therefore if you want to
> * > process different polices for different certificates - send
> different
> * > requests.
> * Where do I talk about different policies and different certificates,
> * are you confusing this with another message?
> * 
> * I am just asking how parameters from the client and the server are
> * combined in a request for one signed cert with one policy. And, to
> * be sure, I can also assume that a client sets all the input flags
> * or none, if you want.
> * 
> * The current syntax allows all kind of combinations of settings and
> * by the client and the server, it is not specified:
> * 
> * - how they are combined
> * - whether there this only a subset of useful meanings.
> * 
> * > Trevor
> * >
> * > * -----Original Message-----
> * > * From: Peter Sylvester [mailto:[e-mail]]
> * > * Sent: Tuesday, December 07, 2004 4:15 AM
> * > * To: Trevor Freeman
> * > * Cc: [e-mail]
> * > * Subject: Re: SCVP 16 comments deadline
> * > *
> * > * There are several boolean values like
> * > *
> * > *   ValidationPolicy ::= SEQUENCE {
> * > *     ...
> * > *     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
> * > *
> * > * and a policy definition.
> * > *
> * > *   ValidationPolValues ::=SEQUENCE  {
> * > *     ...
> * > *     inhibitPolMap            BOOLEAN,
> * > *
> * > *
> * > * - It would be nice to use the same field names.
> * > *
> * > * - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
> * > *   with some apppropriate tagging, it doesn't make much sense to
> * > *   me to code useless values.
> * > *
> * > * Would it be possible to add some statement about the intended
> * > * meaning of the 6 possible combination:
> * > *
> * > *
> * > * inhibitPolMap = FALSE
> * > *
> * > * inhibitPolicyMapping absent  1
> * > *                      FALSE   2
> * > *                      TRUE    3
> * > *
> * > * inhibitPolMap = TRUE
> * > *
> * > * inhibitPolicyMapping absent  4
> * > *                      FALSE   5
> * > *                      TRUE    6
> * > *
> * > *
> * > * Does it mean that when the client value takes preceedence over the
> * > * server value?
> * > *
> * > * 1 = FALSE
> * > * 2 = FALSE
> * > * 3 = TRUE
> * > * 4 = TRUE
> * > * 5 = FALSE
> * > * 6 = TRUE
> * > *
> * > *
> * > * It had been said some time ago (as far as I remember) that these
> * > * inputs are not global ones but in principle for each of the
> * > * certs to be asked for. what was the conclusion why they stay
> global
> * > * for all certs?
> * >
> * >
> * >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD1xhp042051; Fri, 10 Dec 2004 05:01:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAD1xrc042048; Fri, 10 Dec 2004 05:01:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD1wPm042006 for <[e-mail]>; Fri, 10 Dec 2004 05:01:58 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBAD1xn21406; Fri, 10 Dec 2004 14:01:59 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 10 Dec 2004 14:01:59 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBAD1wd29241; Fri, 10 Dec 2004 14:01:58 +0100 (MET)
Date: Fri, 10 Dec 2004 14:01:58 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * 
> * 
> * Does this means that the validate Algorithm is cert specific and not
> * request specific?
> [TF] The request specifies a policy, which in tern references an
> algorithm. The policy applies globally to the request. There is no
> relationship between the certificate and the algorithm.
> Trevor
>

I agree that it seems sufficient for one request to have the same
*algorithm(s)* performed for all the certs, but the only examples defined
contain a *parameter* which is specific to each cert, i.e. an identity/name
that has to be matched with the content of a cert, thus currently the
usage of this 'extension' features limits the requests to one cert only.

For requests concerning SSL servers, IPsec auths, *one signature*, one
cert will be present in the request, a case for multiple requests *may* 
be certs for encryption. It may be sufficient to allow multiple names
for e-mail protection certs in the existing parameter, and a rule saying
that names must be present.  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD1kGf041796; Fri, 10 Dec 2004 05:01:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAD1kh6041795; Fri, 10 Dec 2004 05:01:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD1jkV041774 for <[e-mail]>; Fri, 10 Dec 2004 05:01:45 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBAD1kn21399; Fri, 10 Dec 2004 14:01:46 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 10 Dec 2004 14:01:46 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBAD1jY29234; Fri, 10 Dec 2004 14:01:45 +0100 (MET)
Date: Fri, 10 Dec 2004 14:01:45 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [TF] How the server identifies the client is a mater of local server
> policy.
See my other message and a text proposal. 

> * 
> * The 3379 text says:
> * 
> *    When the DPV request is authenticated, the client SHOULD be able to
> *    include a client identifier in the request for the DPV server to
> copy
> *    into the response.  Mechanisms for matching this identifier with
> the
> *    authenticated identity depends on local DPV server conditions
> and/or
> *    the validation policy.
> * 
> * The client has no way to declare its identity in the protocol,
> * and there no provision of what this could be from what it would
> * be derived from (IP address, DNS name of the host, ...), ...
> [TF] The client can declare its identity in the request in a number of
> ways.
>  	1. by including its signing certificate in the request
> 	2. by including its DH certificate used to compute the hmac
> 	3. By HMACing the request using a shared secret or password

None of these is a "declaration" of an identity. It is a means to authenticate
the request at least in my opinion. 

Note the remark about 'may respond with an error' in
the requirements. This is intended to mean that a server may reject
a request when the declared entity is not one that can be authenticated.
(I don't think that it was meant that an error can be 'not authorized')

> 
> What identity the server knows or uses for the client based on this data
> is a matter of local server policy
>  
> * 
> * Why is this restricted to signed requests, and not to 'authenticated'?
> [TF] Its not. Section 3 defies signed requests as being either
> signedData or authenticatedData.

Ok. 

> * 
> * As already said in another may, this text could make sense if there
> * would be a corresponding requestorName in the request.

you seem to agree?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD0mYb040350; Fri, 10 Dec 2004 05:00:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAD0msV040347; Fri, 10 Dec 2004 05:00:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD0kPC040323 for <[e-mail]>; Fri, 10 Dec 2004 05:00:47 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBAD0ln21382; Fri, 10 Dec 2004 14:00:47 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 10 Dec 2004 14:00:47 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBAD0lt29227; Fri, 10 Dec 2004 14:00:47 +0100 (MET)
Date: Fri, 10 Dec 2004 14:00:47 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [TF] I am saying how the server identifies the client for the supplied
> information is a matter of local policy to the server.

Repeating this three time doesn't make the statement true. It is
totally contrary to what is described in the requirements document.

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

If you don't agree about the meaning of 'client identifier' in the
following excerpt, then we will not be able to get anywhere further.

If the intention of the excerpt above would be that the client does not
explicitely do provide an identifier, then the text would be like:

   When the DPV requets is authenticated, then server MAY return to the
   client an identifier derived from the authentication.

if you want to derive *one* identifier from the authentication, what will
you set for a certificate with one or more instances of subjectAltname.
The best you can do is to return all identities. 

The client has to have a means to explicitely present his identity.

This is an identifier where the client declares its identity, furthermore 
this identifier being an octet string without any structure is not
something that is common in PKI environments, in particular you already
return a GeneralNames structure in the requesterName. 

I simply repeat my request to add requesterName and a responderName structure
in both the request and the response. 

here a text proposal:

x.x.x Entity identification.

Since an SCVP response MAY be used by a client to demonstrate to another
relying party that certificate validation has been duly performed, the
protocol allows to add identities of requesting clients and responding
server to the response.

An identity is encoded as GeneralName. (cf. syntax)

Servers may have more than one identity, for example, a URI 
to access to the service, or a DN related or not to CAs.
In particular, an SCVP server may have the same identity as a CA
for which the server can provide answers in a similar way as an
OCSP server. 

The protocol is as follows:

x.x.x.1 requesterName

This field in the request indicates one or more identities participating
in the creation of the request. A client MAY add this field to a request.
If the request is authenticated, one of the presented identities SHOULD 
match with at least one identity that can be derived from authentication. 
A server MAY accept a request even if the presented identities do not 
correspond to one derived from authentication. If the request cannot be
authenticated, a server SHOULD reject the request if it contains this field.

On relaying, a relay MAY choose not to copy the presented identity to
the relayed request, e.g., to anonymize the requester.

This field SHOULD be returned as is in the response. A server MAY choose
to add additional identities. This may be done when a relay is involved, 
when an authenticated identity is different.  

(merge some stuff from the existing requesterName if necessary).

x.x.x.1 responderName

This field in the request indicated identities of one or more servers that
are intending to participate in the construction of the response. This
may be used for example to indicate to a relaying proxy the identity of
another scvp server. 

This field in the response indicate the identities of the servers that
have participated in creating the response. There is no particular
relationship with the field with the same name in the input. 

------

Now we can treat the usefulness of the requester/responder for,loop
control independantly. 
 
> * 
> * Since two years or so I am asking that you just make two elements
> * 
> * requestor GeneralNames
> * responder GeneralNames
> * 
> * in both the request and the response. (and to get rid of the octet
> string
> * stuff)
> * 
> * I may have not understod your intention of "responder", if this is a
> pure
> * local reference of the RESPONSE vs the repspoinder, then I think a
> * sequence number would be more appropriate.
> * 

what is the current definition of responder good for? You menton something
below, see later. 


> * > *
> * > * The new text replacing "requestor" in chapter 7 by "requestorRef".
> * > *
> * > * > however,
> * > * >  all of the octets MUST have values other than zero.
> * > * Why? I would find it quite useful to add a
> * > * hash of something local, if at all, the hash of its IP address for
> * > example
> * > * (for which I can use the Nonce as well).
> * > [TF] If you want me to remove the clause about values being other
> than
> * > zero - I am happy to do so. Since this is of local significance
> only, if
> * > an implementation puts garbage in here it does not effect
> * > interoperability.
> * How do relate 'local significance only' and the usage of such fields
> * for 'loop control'. The significance not just local.
> * If relays just put "relay" as a local reference you will have
> problems.
> * 
> * LOOONG time ago, I told you that an encoding of identifiers in an
> octet
> * string
> * sounds strange, given that we have lots of ways and that you don't
> provide
> * any guideline on how identifiers can be encoded.
> * 
> * Although you violantly rejected all proprosals to change this, you
> * silently starting doing this in this version:
> * 
> * - replacing an octet string by a sequence  (good, but omitted the only
> * reason
> *   for not allowing zeros).
> * - adding a requesterName item with is a generalnames
> * 
> * 

I probably expected some [TF] here, but well, you seem to agree.  

> * > *
> * > *   The requestRef item allows the client to associate a response
> with
> * > *   a request.  The requestNonce provides an alternative mechanism
> ..
> * > *
> * > *   and you have also the requestorRef.
> * > *
> * > * The concept of trying to make loop control with values which are
> * > * explicitely
> * > * defined as not globally unique sounds strange to me.
> * > [TF] I have a big problem which the concept of global uniqueness. I
> * > class it the same bucket as non-repudiation.
> * 
> * You are operating in a PKI where ID's of
> * entities are unique within the PKI. If you don't trust the
> * naming rule in your PKI, i.e. in some associated SCVP network
> * which is much smaller, i.e. in the magnitude of the size of
> * the CA name space.
> [TF] Names give by an instance of a PKI are by definition not global.

Can you point me to the definition?
You may have a problem of ensuring uniqueness of name inside the PKI
this but that's a similar proble as for the domain name system, 
it is organisational and not technical.
Names inside a PKI are non-ambiguously associated to the
entities as far as I remember.

I really don't see what you are arguing about?

> * 
> * Well, domain names work as far as I know. And telephone numbers also.
> * I don't say that non-repudiation doesn't work. I don't say that
> * I agree or disagree with your comparision since I do not see why this
> * is relevant here.
> * 
> * You are not even answering the question: You make loop control, and
> * you explicitely says that the identifiers that are used do only have
> * local significance. You could have said: An example for identifiers
> * that could be used for loop control are uuids generated on each server
> * startup using the server address and a time value.
> [TF] Are you asking a question or suggesting text for the draft? If you
> want an example of how one might generate a identifier of local
> significance I can do that.

An identifier of 'local' significance is simple: 'I'

It seems that we don't agree about the meaning of 'local significance'.

You need that each potentially participating entity has at least one
identifier which are distincet among the servers, but may or not
have any global 'significance'. 

If you want to keep the requester item for this, why not. it may be
useful not to overload an 'identification', a nonce, a loop control tickmark
in the same field. 

> * > *  "The requestorRef item is also needed
> * > *   to prevent looping in some configurations"
> * > *
> * > *  "No provisions are
> * > *   made to ensure uniqueness of the requestorRef octet string"
> * > *
> * > * The usefulness of "requestorRef" as an identifier for the request
> * > * is pretty weak, since you can have a nonce if it is for each
> * > * request. use GeneralName(s) in a requestorName sequence as for the
> * > * response.
> * > *
> * > * page 34:
> * > *
> * > *   The requestorRef and the responder items MUST be included if the
> * > request
> * > * included a
> * > *   requestor item.
> * > *
> * > * what does this mean? what is the relationship between a
> requesterRef
> * > and
> * > * responder?
> * > [TF] If requestorRef is populated, it means it's a relayed request
> in
> * > which case the responder is of significance.
> * 
> * No. any client can set a requestorRef, independant of whether the
> request
> * will be relayed. What is the significance of responder? In your spec
> * it is only of local signifance for the responding server? waht can
> this
> * be good for?

> [TF] It good for detecting loops. The server adds an identifier which it
> recognizes to the response. It is the only one rrequired to recognize
> the value so it can put whatever it wants in the field. There is no need
> to standardize the behavior of the SCVP server in this regard.

To be sure: The question was: "What is the significance of responder?" 
How does this value occur in the loop control algo? So far, the server
just adds this, and noone is doing somthing with it, at least not in
the current spec?

> * 
> * > *
> * > * If I'd be interested in anything identifying the response, then it
> is
> * > * a sequence of identifiers of the servers that have partipated, and
> * > some
> * > * local ids or "serial number' like thing if I want to go to that
> server
> * > and
> * > * asks 'did you really tell this to my friend'.
> * > *
> * > *
> * > * Chapter 7: Denis is right that the spec does not describe how
> relaying
> * > is
> * > * performed, i.e. how a response is created from a response received
> * > from
> * > * another
> * > * server by a 'proxy'.
> * > [TF] What specifically are you looking for?
> * 
> * A working specification that includes:
> * 
> * - how a request received is transformed into a new request by a relay,
> *   which fields are copied, or not, or may.
> * - how the response is transformed into a response to the original
> request
> *   there are SEVERAL options, in particulat the one that addresses
> *   the requirement of allowing a response as part of another one.
> [TF] OK. I will add that.
good.

Would it be possible to send a draft to the list before it get graved into 
electronic marble. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD07kw039477; Fri, 10 Dec 2004 05:00:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAD075q039476; Fri, 10 Dec 2004 05:00:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD048c039126 for <[e-mail]>; Fri, 10 Dec 2004 05:00:06 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBACxin21375; Fri, 10 Dec 2004 13:59:44 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 10 Dec 2004 13:59:44 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBACxhA29220; Fri, 10 Dec 2004 13:59:43 +0100 (MET)
Date: Fri, 10 Dec 2004 13:59:43 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * - It would be nice to use the same field names.
> [TF] Fixed

ok.
> * 
> * - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
> *   with some apppropriate tagging, it doesn't make much sense to
> *   me to code useless values.
> * 
> * Would it be possible to add some statement about the intended
> * meaning of the 6 possible combination:
> * 
> * 
> * inhibitPolMap = FALSE
> * 
> * inhibitPolicyMapping absent  1
> *                      FALSE   2
> *                      TRUE    3
> * 
> * inhibitPolMap = TRUE
> * 
> * inhibitPolicyMapping absent  4
> *                      FALSE   5
> *                      TRUE    6
> * 
> [TF] There is only one Boolean value for inhibitPolicyMapping. It can be
> defined in the policy, supplied in the request or defined in the servers
> default policy. Section 1.3 defines the precedence for each. Further
> 3.1.5.1 also requests the server to reject a request which summits a
> request which attempts to override the precedence.

Ok. 


> * 
> * Does it mean that when the client value takes preceedence over the
> * server value?
> * 
> * 1 = FALSE
> * 2 = FALSE
> * 3 = TRUE
> * 4 = TRUE
> * 5 = FALSE
> * 6 = TRUE
> * 
> * 
> * It had been said some time ago (as far as I remember) that these
> * inputs are not global ones but in principle for each of the
> * certs to be asked for. what was the conclusion why they stay global
> * for all certs?
> [TF] There is one validation policy per request therefore the same
> policy applies to all certs in the request.

Ok.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9NLPFN092974; Thu, 9 Dec 2004 15:21:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9NLPo4092973; Thu, 9 Dec 2004 15:21:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-1.visp.demon.net (IDENT:[e-mail] [193.195.70.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9NLOgA092724 for <[e-mail]>; Thu, 9 Dec 2004 15:21:24 -0800 (PST) (envelope-from [e-mail])
Received: from [80.7.98.186] (cpc3-hudd3-5-0-cust186.hudd.cable.ntl.com [80.7.98.186]) by lon1-mail-1.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BWU85675 (AUTH [e-mail]); Thu, 9 Dec 2004 23:21:09 GMT
Message-ID: <[e-mail]>
Date: Thu, 09 Dec 2004 23:21:08 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-ldap-* review notes
References: <6.1.2.0.0.20041206140940.03114f30@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041206140940.03114f30@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt

thanks for these. They are very useful. I'll get back to you later on 
any individual comments that I have a question about (but it might be a 
week or three.

David


Kurt D. Zeilenga wrote:
> Due to the size of my raw review notes, I've placed them
> on the web for independent download:
>   http://www.openldap.org/ietf/pkix/comments-ietf-pkix-ldap-pkc-schema-01.txt
>   http://www.openldap.org/ietf/pkix/comments-ietf-pkix-ldap-ac-schema-02.txt
>   http://www.openldap.org/ietf/pkix/comments-ietf-pkix-ldap-crl-schema-03.txt
> 
> Regards, Kurt
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9MLjSG025929; Thu, 9 Dec 2004 14:21:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9MLjnQ025922; Thu, 9 Dec 2004 14:21:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9MLh32025836 for <[e-mail]>; Thu, 9 Dec 2004 14:21:43 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iB9MLT2x030174; Thu, 9 Dec 2004 17:21:29 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iB9MLNWR024538; Thu, 9 Dec 2004 17:21:23 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 09 Dec 2004 17:22:01 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

I must say that I agree with Seth and Denis.  I was under the impression 
that "Do revocation status checking on the certification path" really 
meant "build and validated certification path to a trust anchor and do 
revocation status checking on the certification path".  While I can see 
that there may be circumstances in which one would request a validated 
certification path without requiring revocation status checking, I can't 
see requesting revocation status checking without requesting that the 
path be validated.

It is certainly the case that one can not "do revocation status checking 
on the certification path" without also building a certification path.  
Since the client can not provide a certification path, revocation status 
checking must be performed on a path that is built by the server.  I 
suppose you could argue that this simply means that a well formed query 
can not include the id-stc-build-status-checked-pkc-path without also 
including either the id-stc-build-pkc-path or 
id-stc-build-valid-pkc-path check.  But, I see see the need for this.

A DPD client would include the id-stc-build-pkc-path along with the 
id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info wantBacks.  
If the DPD client included the id-swb-pkc-revocation-info wantBack, it 
wouldn't need to also include the id-stc-build-status-checked-pkc-path 
check.  If the DPD client did not include the id-swb-pkc-revocation-info 
wantBack, then would not include the 
id-stc-build-status-checked-pkc-path check. 

So, I would argue that the id-swb-pkc-revocation-info wantBack would 
only be used in the case that the client was requesting a validated 
certification path.  The way that I had interpreted the currently 
defined checks items, an SCVP query would only include one check since 
each successive check included the requirements of the previous one:  
id-stc-build-valid-pkc-path included the requirement to build a path 
(id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path 
included the requirement to build a validated path 
(id-stc-build-valid-pkc-path).

Under what circumstances can you envision a client wanting the server to 
do revocation status checking on a certification path (that is 
constructed by the server) without also including a requirement that the 
certification path be validated?   If there are no reasonable 
circumstances in which a client would make such a query, why is it 
necessary for clients to be able to construct such a query?

Dave

Trevor Freeman wrote:

>Hi Seth,
>A server can always go beyond what the client asked for. I don't see
>that as strictly necessary in all cases such as if the client just asks
>for revocation. Untimely is a matter of local server policy. What the
>server cannot do is return status or errors relating to the other
>activities which  were beyond the request scope.
>Trevor
>
While it might make sense for a client to only ask for revocation 
checking if the client could specify the certification path, it does not 
seem to make sense given that the server chooses the certification path 
for which revocation status checking will be performed.  If the client 
wants to specify a set of certificates for which it only wants to know 
the revocation status, that is what OCSP is for.

>
>* -----Original Message-----
>* From: Seth Hitchings [mailto:[e-mail]]
>* Sent: Wednesday, December 08, 2004 11:34 AM
>* To: Trevor Freeman
>* Cc: [e-mail]
>* Subject: RE: SCVP 16 comments deadline
>* 
>* Trevor,
>* 
>* For clarification, I assume that doing revocation status checks on a path
>* implies building
>* a validated path?
>* 
>* If I am correct, in what case would a client ever send more than one
>* check?
>* 
>* Seth
>* 
>* -----Original Message-----
>* From: [e-mail]
>[mailto:[e-mail]]
>* On Behalf Of
>* Trevor Freeman
>* Sent: Wednesday, December 08, 2004 1:42 PM
>* To: Denis Pinkas
>* Cc: [e-mail]
>* Subject: RE: SCVP 16 comments deadline
>* 
>* 
>* Denis,
>* I know of several systems who's policy is never to revoke the identity
>* certificate because
>* they have other mechanisms to address the issue.
>* They are using authorization bound to the identity and they either rely on
>* short lived
>* authorization assertions or revoke the authorization privilege assonated
>* with the
>* identity. Therefore in those cases not checking the revocation status of
>* the certificate
>* makes perfect sense.
>* Trevor
>* 
>* * -----Original Message-----
>* * From: [e-mail]
>* [mailto:[e-mail]]
>* * On Behalf Of Denis Pinkas
>* * Sent: Wednesday, December 08, 2004 8:01 AM
>* * To: Trevor Freeman
>* * Cc: [e-mail]
>* * Subject: Re: SCVP 16 comments deadline
>* *
>* *
>* * Trevor,
>* *
>* * > Hi Denis,
>* * > Below are responses to 1-16. Others will follow later.
>* *
>* * I am pleased that you accepted comments 13, 14, 15 and 16.
>* * Among this list, I have a further remark on comment 4.
>* *
>* * > * 4. Page 13. Typo. Section 3.1.2 "checks"
>* * > * The two following lines are in fact one line:
>* * > *
>* * > * Change:
>* * > *
>* * > *      - Build a validated certification path to a trust anchor; and
>* * > *
>* * > *      - Do revocation status checks on the certification path.
>* * > *
>* * > * into:
>* * > *
>* * > *      - Build a validated certification path to a trust anchor and
>* * > *        do revocation status checks on the certification path.
>* * > *
>* * > [TF] Since this paragraph is listing the possible checks and building
>* a
>* * > path is a separate check to revocation checking, I think the current
>* * > text is more accurate.
>* *
>* * I agree that "building a path is a separate check to revocation
>* checking",
>* * but revocation checking without building a validated path does not make
>* * sense.
>* *
>* * The full text currently is:
>* *
>* *      - Build a certification path to a trust anchor;
>* *
>* *      - Build a validated certification path to a trust anchor; and
>* *
>* *      - Do revocation status checks on the certification path.
>* *
>* * The full text should be:
>* *
>* *      - Build a certification path to a trust anchor;
>* *
>* *      - Build a validated certification path to a trust anchor; and
>* *        do revocation status checks on the certification path.
>* *
>* * Denis
>* 
>
>  
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9J8umA027072; Thu, 9 Dec 2004 11:08:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9J8uxo027071; Thu, 9 Dec 2004 11:08:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9J8txn027042 for <[e-mail]>; Thu, 9 Dec 2004 11:08:55 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Thu, 9 Dec 2004 11:07:55 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Thu, 9 Dec 2004 11:08:09 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Thu, 9 Dec 2004 11:07:51 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTd5QkaDl509CeCSAC9CL9turT15AAO9qKw
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Dec 2004 19:08:09.0118 (UTC) FILETIME=[6BBF73E0:01C4DE22]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB9J8txn027065
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,

Ho they are combined is defined in section 1.3

" The referenced (policy) value indicates either a partial or full set
of parameters. The client can therefore omit these agreed parameters
from the request, only passing any parameters which are not specified by
the previously agreed policy.  Therefore in the simplest form, with
validation polices which define every parameter necessary, a SCVP
request need only contain the certificate to be validated, the
validation policy and any run-time parameters for the request.

SCVP server also publishes its default validation policy settings.  The
default policy can be requested for validation and the client can
override any default value in the request if required.  The default
values are also used when processing requests which reference a
validation policy other than the default one that does not contain the
full set of parameters necessary for validation and the client has also
omitted the missing values in the request.  Therefore a client can also
simplify the request by omitting a parameter from a request if the
default value published by the server is acceptable.

Further 3.1.5.1 also requires
" If there are any conflicts between the non-default policy referenced
in the request and any supplied parameter values in the request, then
the server MUST return an error response."

Therefore if you use the non-default policy, the policy value take
precedence over the request value and cannot be overridden by the
request. For the default policy the client can override any value.

If the policy and client both omit a parameter, then the server default
value is used.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Thursday, December 09, 2004 3:49 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* Either I was unclear in my question or you have totally misunderstood
it,
* or I don't understand what your are responding.
* 
* > Hi Peter,
* > All parameter assonated with policy mapping are names the same. If
you
* > want guidance on their use in combination with the policy reference
see
* > section 1.3.
* It is obviously not difficult to guess which names corresponds, that
* is not the problem.
* 
* 
* > SCVP only supports one policy per request therefore if you want to
* > process different polices for different certificates - send
different
* > requests.
* Where do I talk about different policies and different certificates,
* are you confusing this with another message?
* 
* I am just asking how parameters from the client and the server are
* combined in a request for one signed cert with one policy. And, to
* be sure, I can also assume that a client sets all the input flags
* or none, if you want.
* 
* The current syntax allows all kind of combinations of settings and
* by the client and the server, it is not specified:
* 
* - how they are combined
* - whether there this only a subset of useful meanings.
* 
* > Trevor
* >
* > * -----Original Message-----
* > * From: Peter Sylvester [mailto:[e-mail]]
* > * Sent: Tuesday, December 07, 2004 4:15 AM
* > * To: Trevor Freeman
* > * Cc: [e-mail]
* > * Subject: Re: SCVP 16 comments deadline
* > *
* > * There are several boolean values like
* > *
* > *   ValidationPolicy ::= SEQUENCE {
* > *     ...
* > *     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* > *
* > * and a policy definition.
* > *
* > *   ValidationPolValues ::=SEQUENCE  {
* > *     ...
* > *     inhibitPolMap            BOOLEAN,
* > *
* > *
* > * - It would be nice to use the same field names.
* > *
* > * - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
* > *   with some apppropriate tagging, it doesn't make much sense to
* > *   me to code useless values.
* > *
* > * Would it be possible to add some statement about the intended
* > * meaning of the 6 possible combination:
* > *
* > *
* > * inhibitPolMap = FALSE
* > *
* > * inhibitPolicyMapping absent  1
* > *                      FALSE   2
* > *                      TRUE    3
* > *
* > * inhibitPolMap = TRUE
* > *
* > * inhibitPolicyMapping absent  4
* > *                      FALSE   5
* > *                      TRUE    6
* > *
* > *
* > * Does it mean that when the client value takes preceedence over the
* > * server value?
* > *
* > * 1 = FALSE
* > * 2 = FALSE
* > * 3 = TRUE
* > * 4 = TRUE
* > * 5 = FALSE
* > * 6 = TRUE
* > *
* > *
* > * It had been said some time ago (as far as I remember) that these
* > * inputs are not global ones but in principle for each of the
* > * certs to be asked for. what was the conclusion why they stay
global
* > * for all certs?
* >
* >
* >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9IubbW014212; Thu, 9 Dec 2004 10:56:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9IubEp014209; Thu, 9 Dec 2004 10:56:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9IuabU014132 for <[e-mail]>; Thu, 9 Dec 2004 10:56:36 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Thu, 9 Dec 2004 10:56:49 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 10:56:32 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Thu, 9 Dec 2004 10:56:32 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTd5NSJrvuA0NdgSmGxkp06p/QG/wAOfSdA
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Dec 2004 18:56:32.0306 (UTC) FILETIME=[CC6A6120:01C4DE20]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB9IuabU014187
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Thursday, December 09, 2004 3:47 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* > *
* > * But:
* > *
* > * The syntax is GeneralNames. how many ids is the server intended
* > * to extract from a certificate? The subject + all alternate ids?
* > *
* > * Why not having this id declared by the client, and the
authentication
* > * methods matches against it. ==> Add a corresponding field in the
* > request.
* > * Which is required:
* > *
* > *    When the DPV request is authenticated, the client SHOULD be
able to
* > *    include a client identifier in the request for the DPV server
to
* > copy
* > *    into the response.  Mechanisms for matching this identifier
with
* > the
* > *    authenticated identity depends on local DPV server conditions
* > and/or
* > *    the validation policy.  The DPV server MAY choose to blindly
copy
* > the
* > *    identifier, omit the identifier, or return an error response.
* > *
* > * It is an identifer identifying the client and not the request.
* > [TF] If the client sends a signed request with certificate it has
* > included a client identifier in the request. Its matter of local
server
* > policy which name it chooses to return.
* 
* Are you saying that this client identifier is the "issuerSerial"?
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* What field *IS* the "client identifier"? The certificate is not
* a client identifier? In a certificate, you may have several
identifiers
* concerning the entity.
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* 
* The client has no way to set an "identifier for itself" in the
request, so
* that
* 
*    "the DPV server MAY choose to blindly copy the identifier".
* 
* The server that you propose ALWAYS MUST create some generalnames
* structure for which no guideline is given on how it could be
* derived from the requestorRef which is an item that has no relation
* at all to the returned requesterName.
[TF] I am saying how the server identifies the client for the supplied
information is a matter of local policy to the server.
* 
* Since two years or so I am asking that you just make two elements
* 
* requestor GeneralNames
* responder GeneralNames
* 
* in both the request and the response. (and to get rid of the octet
string
* stuff)
* 
* I may have not understod your intention of "responder", if this is a
pure
* local reference of the RESPONSE vs the repspoinder, then I think a
* sequence number would be more appropriate.
* 
* > *
* > * The new text replacing "requestor" in chapter 7 by "requestorRef".
* > *
* > * > however,
* > * >  all of the octets MUST have values other than zero.
* > * Why? I would find it quite useful to add a
* > * hash of something local, if at all, the hash of its IP address for
* > example
* > * (for which I can use the Nonce as well).
* > [TF] If you want me to remove the clause about values being other
than
* > zero - I am happy to do so. Since this is of local significance
only, if
* > an implementation puts garbage in here it does not effect
* > interoperability.
* How do relate 'local significance only' and the usage of such fields
* for 'loop control'. The significance not just local.
* If relays just put "relay" as a local reference you will have
problems.
* 
* LOOONG time ago, I told you that an encoding of identifiers in an
octet
* string
* sounds strange, given that we have lots of ways and that you don't
provide
* any guideline on how identifiers can be encoded.
* 
* Although you violantly rejected all proprosals to change this, you
* silently starting doing this in this version:
* 
* - replacing an octet string by a sequence  (good, but omitted the only
* reason
*   for not allowing zeros).
* - adding a requesterName item with is a generalnames
* 
* 
* > *
* > *   The requestRef item allows the client to associate a response
with
* > *   a request.  The requestNonce provides an alternative mechanism
..
* > *
* > *   and you have also the requestorRef.
* > *
* > * The concept of trying to make loop control with values which are
* > * explicitely
* > * defined as not globally unique sounds strange to me.
* > [TF] I have a big problem which the concept of global uniqueness. I
* > class it the same bucket as non-repudiation.
* 
* You are operating in a PKI where ID's of
* entities are unique within the PKI. If you don't trust the
* naming rule in your PKI, i.e. in some associated SCVP network
* which is much smaller, i.e. in the magnitude of the size of
* the CA name space.
[TF] Names give by an instance of a PKI are by definition not global.
* 
* Well, domain names work as far as I know. And telephone numbers also.
* I don't say that non-repudiation doesn't work. I don't say that
* I agree or disagree with your comparision since I do not see why this
* is relevant here.
* 
* You are not even answering the question: You make loop control, and
* you explicitely says that the identifiers that are used do only have
* local significance. You could have said: An example for identifiers
* that could be used for loop control are uuids generated on each server
* startup using the server address and a time value.
[TF] Are you asking a question or suggesting text for the draft? If you
want an example of how one might generate a identifier of local
significance I can do that.
* 
* 
* > *
* > *  "The requestorRef item is also needed
* > *   to prevent looping in some configurations"
* > *
* > *  "No provisions are
* > *   made to ensure uniqueness of the requestorRef octet string"
* > *
* > * The usefulness of "requestorRef" as an identifier for the request
* > * is pretty weak, since you can have a nonce if it is for each
* > * request. use GeneralName(s) in a requestorName sequence as for the
* > * response.
* > *
* > * page 34:
* > *
* > *   The requestorRef and the responder items MUST be included if the
* > request
* > * included a
* > *   requestor item.
* > *
* > * what does this mean? what is the relationship between a
requesterRef
* > and
* > * responder?
* > [TF] If requestorRef is populated, it means it's a relayed request
in
* > which case the responder is of significance.
* 
* No. any client can set a requestorRef, independant of whether the
request
* will be relayed. What is the significance of responder? In your spec
* it is only of local signifance for the responding server? waht can
this
* be good for?
[TF] It good for detecting loops. The server adds an identifier which it
recognizes to the response. It is the only one rrequired to recognize
the value so it can put whatever it wants in the field. There is no need
to standardize the behavior of the SCVP server in this regard.
* 
* > *
* > * If I'd be interested in anything identifying the response, then it
is
* > * a sequence of identifiers of the servers that have partipated, and
* > some
* > * local ids or "serial number' like thing if I want to go to that
server
* > and
* > * asks 'did you really tell this to my friend'.
* > *
* > *
* > * Chapter 7: Denis is right that the spec does not describe how
relaying
* > is
* > * performed, i.e. how a response is created from a response received
* > from
* > * another
* > * server by a 'proxy'.
* > [TF] What specifically are you looking for?
* 
* A working specification that includes:
* 
* - how a request received is transformed into a new request by a relay,
*   which fields are copied, or not, or may.
* - how the response is transformed into a response to the original
request
*   there are SEVERAL options, in particulat the one that addresses
*   the requirement of allowing a response as part of another one.
[TF] OK. I will add that.

Trevor
* 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9IS2UT077835; Thu, 9 Dec 2004 10:28:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9IS2UZ077833; Thu, 9 Dec 2004 10:28:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9IRtSW077676 for <[e-mail]>; Thu, 9 Dec 2004 10:28:01 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Thu, 9 Dec 2004 10:28:09 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Thu, 9 Dec 2004 10:28:10 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Thu, 9 Dec 2004 10:27:54 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTcXueJtGfvRfiwRcG4yQcnIxrqeABvAcFA
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Dec 2004 18:28:10.0462 (UTC) FILETIME=[D60997E0:01C4DE1C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB9IS1SW077822
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

H Peter,


* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Peter Sylvester
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* 
* There are several boolean values like
* 
*   ValidationPolicy ::= SEQUENCE {
*     ...
*     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* 
* and a policy definition.
* 
*   ValidationPolValues ::=SEQUENCE  {
*     ...
*     inhibitPolMap            BOOLEAN,
* 
* 
* - It would be nice to use the same field names.
[TF] Fixed
* 
* - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
*   with some apppropriate tagging, it doesn't make much sense to
*   me to code useless values.
* 
* Would it be possible to add some statement about the intended
* meaning of the 6 possible combination:
* 
* 
* inhibitPolMap = FALSE
* 
* inhibitPolicyMapping absent  1
*                      FALSE   2
*                      TRUE    3
* 
* inhibitPolMap = TRUE
* 
* inhibitPolicyMapping absent  4
*                      FALSE   5
*                      TRUE    6
* 
[TF] There is only one Boolean value for inhibitPolicyMapping. It can be
defined in the policy, supplied in the request or defined in the servers
default policy. Section 1.3 defines the precedence for each. Further
3.1.5.1 also requests the server to reject a request which summits a
request which attempts to override the precedence.
* 
* Does it mean that when the client value takes preceedence over the
* server value?
* 
* 1 = FALSE
* 2 = FALSE
* 3 = TRUE
* 4 = TRUE
* 5 = FALSE
* 6 = TRUE
* 
* 
* It had been said some time ago (as far as I remember) that these
* inputs are not global ones but in principle for each of the
* certs to be asked for. what was the conclusion why they stay global
* for all certs?
[TF] There is one validation policy per request therefore the same
policy applies to all certs in the request.

Trevor




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9IDU9H065130; Thu, 9 Dec 2004 10:13:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9IDUrm065129; Thu, 9 Dec 2004 10:13:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9IDRdd064966 for <[e-mail]>; Thu, 9 Dec 2004 10:13:27 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 10:13:25 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Thu, 9 Dec 2004 10:13:37 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Thu, 9 Dec 2004 10:13:24 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTcXub4hbVcv9fISyaI1MfW3qJOjgBu29XQ
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Dec 2004 18:13:37.0992 (UTC) FILETIME=[CE013C80:01C4DE1A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB9IDSdd065062
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter


* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Peter Sylvester
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* 
* We have
* 
*   Query ::= SEQUENCE {
*    queriedCerts               SEQUENCE SIZE (1..MAX) OF CertReference,
* 
*    ...
*    validationPolicy           ValidationPolicy,
* 
* with
*   ValidationPolicy ::= SEQUENCE {
*     ...
*     validationAlg         [0] ValidationAlg OPTIONAL,
* 
* 
* 3.1.5 validationAlg
* 
*   The validationAlg item, defines the validation algorithm to be used
*   by the SCVP server during certificate validation.  The value of
*   this item can be determined by agreement between the client and the
*   server, and is represented as an object identifier.  The server
*   might want to assign additional object identifiers that indicate
*   that some settings are used in addition to others given in the
*   request.  In this way, the validation algorithm object identifier
*   can be a shorthand for some SCVP options, but not others.
* 
*   The validationAlg item uses the ValidationAlg type, which has the
*   following syntax:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
* 
* and also
* 
* 
* 3.1.5.2 validationAlg
* 
*   The optional validationAlg item defines the validation algorithm to
*   be used by the SCVP server during certificate validation.  The
*   value of this item can be determined by agreement between the
*   client and the server, and the validation algorithm is represented
*   by an object identifier.
* 
*    The syntax of the validationAlg is:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
*   The following section specifies the basic validation algorithm and
*   the name validation algorithm.  SCVP clients and servers MUST
*   support both validation algorithms defined in this section.  Other
*   validation algorithms can be specified in other documents for use
*   with specific applications.  SCVP clients and servers MAY support
*   any such validation algorithms.
* 
* ---------------
* 
* 3.1.5.2.3 Name Validation Algorithm
* 
*   The name validation algorithm allows the client to supply an
*   application identifier and a name to the server.  The application
*   identifier defines the name matching rules to use in comparing the
*   name supplied in the request with the names in the certificate.
* 
* There may be more than one certificate in the request.
* 
* 
*     NameValidationAlgParms ::= SEQUENCE {
*       keyPurposeId      KeyPurposeId,
*       validationNames   GeneralNames }
* 
* What is the relation between the KeyPurposeId and the
extendeddkeyusage
* 3.1.5.10 extendedKeyUsages
* 
*   If the keyPurposeID supplied in the request is id-kp-mailProtection
*   [PKIX-1], then GeneralNames supplied in the request MUST be a
*   rfc822Name, and the matching rules are defined in [SMIME-CERT].
* 
* 'an rfc822Name".
* 
* what is the meaning of this if I have more than one email certificate,
* i.e. I want to validate all encryption certs before using them.
* 
* 
* Does this means that the validate Algorithm is cert specific and not
* request specific?
[TF] The request specifies a policy, which in tern references an
algorithm. The policy applies globally to the request. There is no
relationship between the certificate and the algorithm.
Trevor

Trevor




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9IACU8062269; Thu, 9 Dec 2004 10:10:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9IACNZ062268; Thu, 9 Dec 2004 10:10:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9IABjY062178 for <[e-mail]>; Thu, 9 Dec 2004 10:10:11 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Thu, 9 Dec 2004 10:10:19 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Thu, 9 Dec 2004 10:10:18 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Thu, 9 Dec 2004 10:10:05 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTcVlvPN6ZBSD5dRAKuopEHk0ffngBwaNGQ
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Dec 2004 18:10:18.0996 (UTC) FILETIME=[5764DB40:01C4DE1A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB9IABjY062250
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* To have an independant issue:
* 
* 
* 4.8 requestorName
* 
*   The optional requestorName item is used by the server with signed
*   requests to return the identity of the client in the response.
*   Mechanisms for matching this identifier with the authenticated
*   identity are a matter of local server policy.
* 
*   In the case of non-cached responses to signed requests, the SCVP
*   server MUST return a requestor name.  A server SHOULD copy the
*   selected identifier from a certificate or other credential used to
*   authenticate the request.  A SCVP server MAY use a client
*   identifier from an out-of-band mechanism or omit the identifier
*   from the response.
* 
*   In the case of cached responses to signed requests, the
*   RequestorName MAY be present in the response.
* 
*   SCVP server that supports signed requests MUST support this item.
* 
* This chapter is new and pretty uncomprehensible:
* 
* "matching" is IMO an action where you have two inputs, I don't see
* where the identifier comes from, or when it is extracted from
* some authenticated information, why there is a "matching" at all.
* "The identity" of the client is not defined anywhere in the document.
[TF] How the server identifies the client is a mater of local server
policy.
* 
* The 3379 text says:
* 
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.
* 
* The client has no way to declare its identity in the protocol,
* and there no provision of what this could be from what it would
* be derived from (IP address, DNS name of the host, ...), ...
[TF] The client can declare its identity in the request in a number of
ways.
 	1. by including its signing certificate in the request
	2. by including its DH certificate used to compute the hmac
	3. By HMACing the request using a shared secret or password

What identity the server knows or uses for the client based on this data
is a matter of local server policy
 
* 
* Why is this restricted to signed requests, and not to 'authenticated'?
[TF] Its not. Section 3 defies signed requests as being either
signedData or authenticatedData.
* 
* As already said in another may, this text could make sense if there
* would be a corresponding requestorName in the request.
* 
* 
* 


Trevor



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9Gj0lB096288; Thu, 9 Dec 2004 08:45:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9Gj0o9096287; Thu, 9 Dec 2004 08:45:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9Giw7p096240 for <[e-mail]>; Thu, 9 Dec 2004 08:44:58 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iB9Ghr2x018349; Thu, 9 Dec 2004 11:43:53 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iB9GhVWS018853; Thu, 9 Dec 2004 11:43:31 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Dec 2004 11:43:30 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Mea Culpa and NEW SCVP 16 comments deadline
Cc: Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

As Trevor noted, I had established a deadline for comments on SCVP 16 
during the last meeting.  I think I promised to restate this on list, but 
apparently failed to do so.  Since it was not in the minutes, it was not 
communicated to the list and it doesn't count.  So, I am setting a new 
deadline:

Wednesday, December 15.

Yes, that is a very aggressive deadline, but everyone on the PKIX list 
should be aware by now that we need to finish SCVP.  If you were interested 
in commenting, I assume that you have read the drafts already, and should 
be able to easily prepare your comments.  (And if you didn't expect a 
deadline before, this thread should have clued you in!)  It should not take 
a week to complete your review and submit comments.

So, my apologies: to the list for the oversight; and to the editors for 
extending the comment period.

Tim Polk

At 12:38 PM 12/6/2004 +0100, Peter Sylvester wrote:

>Denis and Trevor, >
> > Trevor,
> >
> > > The deadline communicated at the DC meeting for making comments on SCVP
> > > 16 was Nov 30th which has now passed. I have had only three people send
> > > me comments to date. SCVP 17 will be closing very shortly so this is the
> > > last reminder.
> >
> > Thank for the remainder. I missed the initial announcement.
>What announcement?
>what I can read here is:
>
>The minutes say (17 nov)
>
> > SCVP (version 16) - Trevor Freeman (Microsoft)
>         Lots of changes have been made from v15; many were editorial
> > but also many substantive changes and some new features. Another rev
> > of the document will be needed. We need to ensure that the ASN.1 is
> > correct, once we agree on the functionality, and so we will compile
> > it to verify. Presentation reviewed changes and new features
> > (relative to v15). See slides for additional details.
>
>The minutes had not been challenged by Trevor.
>
>I cannot see any announcement on the list about that date. There
>are "no presentation files and no minutes' available in the IETF
>server.
>
>According to my understanding of how IETF working groups
>function, an announement during a meeting is non-existant
>if not reflected in the mailing list message.
>
>(It may be that someone filters the content of the imc server for me).
>
>Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9ErUGC029479; Thu, 9 Dec 2004 06:53:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9ErUM3029478; Thu, 9 Dec 2004 06:53:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9ErNFP029404 for <[e-mail]>; Thu, 9 Dec 2004 06:53:27 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA32700; Thu, 9 Dec 2004 16:05:45 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004120915531208:1347 ; Thu, 9 Dec 2004 15:53:12 +0100 
Message-ID: <[e-mail]>
Date: Thu, 09 Dec 2004 15:53:08 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/12/2004 15:53:12, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/12/2004 15:53:14, Serialize complete at 09/12/2004 15:53:14
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

> * b) Section 3.1.5.1 is titled "Default Validation Algorithm" but
> * discusses the default validation policy.
> 
> [TF] This should have read algorithm not policy and is now fixed.

I do not agree with that fix.
You will see it when reading my comments 17 and 18.

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9DCegI011442; Thu, 9 Dec 2004 05:12:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9DCeMm011441; Thu, 9 Dec 2004 05:12:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9DCcq7011382 for <[e-mail]>; Thu, 9 Dec 2004 05:12:39 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB9DCdn03890; Thu, 9 Dec 2004 14:12:39 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 9 Dec 2004 14:12:39 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB9DCcV25391; Thu, 9 Dec 2004 14:12:38 +0100 (MET)
Date: Thu, 9 Dec 2004 14:12:38 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

second reply: 



by changing policy to algorithm in 3.1.5.1 my question may be answered;

  When using the default validation policy, the client can override 
  any of the default parameter values by supplying a specific value 
  in the request.  The SCVP server MUST make use of the provided 
  parameter values or return an error response. 
   

* 
* b) Section 3.1.5.1 is titled "Default Validation Algorithm" but
* discusses the default validation policy.

[TF] This should have read algorithm not policy and is now fixed.

What is the link to :

  Neither the clients nor server MUST dereference the URI during SCVP 
  request processing.  The URI is simply used as a reference for the 
  validation policy.  Clients and server MAY dereference the URI as 
  part of configuration. 
   
  The syntax of the validationPolRef is: 
   
    ValidationPolRef ::= CHOICE { 
      valPolRefByOID     [0] OBJECT IDENTIFIER, 
      valPolRefByURI     [1] IA5String } 
   
  If there are any conflicts between the non-default policy 
  referenced in the request and any supplied parameter values in the 
  request, then the server MUST return an error response. 

In what places policy has to be changed to algorithm in 3.1.5.1? 


> 
> Hi Peter,
> All parameter assonated with policy mapping are names the same. If you
> want guidance on their use in combination with the policy reference see
> section 1.3.
> SCVP only supports one policy per request therefore if you want to
> process different polices for different certificates - send different
> requests.
> Trevor
> 
> * -----Original Message-----
> * From: Peter Sylvester [mailto:[e-mail]]
> * Sent: Tuesday, December 07, 2004 4:15 AM
> * To: Trevor Freeman
> * Cc: [e-mail]
> * Subject: Re: SCVP 16 comments deadline
> * 
> * There are several boolean values like
> * 
> *   ValidationPolicy ::= SEQUENCE {
> *     ...
> *     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
> * 
> * and a policy definition.
> * 
> *   ValidationPolValues ::=SEQUENCE  {
> *     ...
> *     inhibitPolMap            BOOLEAN,
> * 
> * 
> * - It would be nice to use the same field names.
> * 
> * - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
> *   with some apppropriate tagging, it doesn't make much sense to
> *   me to code useless values.
> * 
> * Would it be possible to add some statement about the intended
> * meaning of the 6 possible combination:
> * 
> * 
> * inhibitPolMap = FALSE
> * 
> * inhibitPolicyMapping absent  1
> *                      FALSE   2
> *                      TRUE    3
> * 
> * inhibitPolMap = TRUE
> * 
> * inhibitPolicyMapping absent  4
> *                      FALSE   5
> *                      TRUE    6
> * 
> * 
> * Does it mean that when the client value takes preceedence over the
> * server value?
> * 
> * 1 = FALSE
> * 2 = FALSE
> * 3 = TRUE
> * 4 = TRUE
> * 5 = FALSE
> * 6 = TRUE
> * 
> * 
> * It had been said some time ago (as far as I remember) that these
> * inputs are not global ones but in principle for each of the
> * certs to be asked for. what was the conclusion why they stay global
> * for all certs?
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9CwBxu088939; Thu, 9 Dec 2004 04:58:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9CwBrJ088937; Thu, 9 Dec 2004 04:58:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9Cw98K088855 for <[e-mail]>; Thu, 9 Dec 2004 04:58:10 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB9CwAn03686; Thu, 9 Dec 2004 13:58:10 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 9 Dec 2004 13:58:10 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB9CwAT25334; Thu, 9 Dec 2004 13:58:10 +0100 (MET)
Date: Thu, 9 Dec 2004 13:58:10 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3.1.5.2.3 Name Validation Algorithm 
   
I find the possibilities for the Name Validation Algorithm
rather unsafisfying. 

It should be possible IMO to have a matching simply by
presenting whatever form of Generalname and this should
be compared with the corresponding value in the cert.

In fact, the id-svp-dnValAlg sounds rather restrictive to
me, it seems to imply that only the subject field is
compared (or does this also compare with the Dirname in
a subjectAltname).

This restriction about a DN doesn't seem necssary to me,
Any generalName can be compared with any in the subjectAltname.

E.g. an IP address. 

'id-nvae-unknown-pupose'   ==> 'id-nvae-unknown-purpose'

  id-nvae-name-mismatch vs   The id-nvae-nameMismatch value

please align the spellings of all the errors types.

  The id-nvae-badName value means the client supplied either and 
  empty or malformed name in the request. 

what is a bad or malformed name? How can this happen without raising
a general asn1 decoding error

since it comes right next? 

--- 
cleanup the following text, please 

  The userPolicySet item specifies a list of policy identifiers that 
  the SCVP server MUST use when forming and validating a certificate 
  If certPolicies is not specified, then any-policy MUST be used. 
   
3.1.5.3 userPolicySet 
   
  The userPolicySet item specifies a list of certificate policy 
  identifiers that the SCVP server MUST use when constructing and 
  validating a certification path.  If userPolicySet is not specified, 
  then any-policy MUST be used. 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9BmoPq085233; Thu, 9 Dec 2004 03:48:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9BmoBu085232; Thu, 9 Dec 2004 03:48:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9Bmmb5085218 for <[e-mail]>; Thu, 9 Dec 2004 03:48:49 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB9Bmnn02807; Thu, 9 Dec 2004 12:48:49 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 9 Dec 2004 12:48:49 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB9Bmm525121; Thu, 9 Dec 2004 12:48:49 +0100 (MET)
Date: Thu, 9 Dec 2004 12:48:49 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * -----Original Message-----
> * From: Peter Sylvester [mailto:[e-mail]]
> * Sent: Tuesday, December 07, 2004 4:15 AM
> * To: Trevor Freeman
> * Cc: [e-mail]
> * Subject: Re: SCVP 16 comments deadline
> * 
> * We have
> * 
> *   Query ::= SEQUENCE {
> *    queriedCerts               SEQUENCE SIZE (1..MAX) OF CertReference,
> * 
> *    ...
> *    validationPolicy           ValidationPolicy,
> * 
> * with
> *   ValidationPolicy ::= SEQUENCE {
> *     ...
> *     validationAlg         [0] ValidationAlg OPTIONAL,
> * 
> * 
> * 3.1.5 validationAlg
> [TF] The duplicate Validation alg section has been removed.

good. But which one? 

> * ---------------
> * 
> * 3.1.5.2.3 Name Validation Algorithm
> * 
> *   The name validation algorithm allows the client to supply an
> *   application identifier and a name to the server.  The application
> *   identifier defines the name matching rules to use in comparing the
> *   name supplied in the request with the names in the certificate.
> * 
> * There may be more than one certificate in the request.
> [TF] The policy is global to the request.
> * 
> * 
> *     NameValidationAlgParms ::= SEQUENCE {
> *       keyPurposeId      KeyPurposeId,
> *       validationNames   GeneralNames }
> * 
> * What is the relation between the KeyPurposeId and the
> extendeddkeyusage
> * 3.1.5.10 extendedKeyUsages
> [TF] The OID with name validation defines the matching rules. In theory
> there could be multiple matching rules for an 822 name.
no comment. 

> * 
> *   If the keyPurposeID supplied in the request is id-kp-mailProtection
> *   [PKIX-1], then GeneralNames supplied in the request MUST be a
> *   rfc822Name, and the matching rules are defined in [SMIME-CERT].
> * 
> * 'an rfc822Name".
> * 
> * what is the meaning of this if I have more than one email certificate,
> * i.e. I want to validate all encryption certs before using them.
> [TF] If they are different names they have to be different requests.
> * Does this means that the validate Algorithm is cert specific and not
> * request specific?
> [TF] The validation policy for the request is global to the request.
> 

It is quite normal that the parameters assocaited to the single algorithm
may not be different for each cert, in particular for email.

It seems possible to allow a list of emails and require that for each
email, there must be at least one certificate in the certificate list.

Or you move the parameters to some information associated to the certificate,
or one says that the sequence of names must correspond to the sequence
of certs, ... 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9BmepK085155; Thu, 9 Dec 2004 03:48:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9Bmers085154; Thu, 9 Dec 2004 03:48:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9BmcWu085135 for <[e-mail]>; Thu, 9 Dec 2004 03:48:39 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB9Bmdn02800; Thu, 9 Dec 2004 12:48:39 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 9 Dec 2004 12:48:39 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB9Bmc625114; Thu, 9 Dec 2004 12:48:38 +0100 (MET)
Date: Thu, 9 Dec 2004 12:48:38 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Either I was unclear in my question or you have totally misunderstood it,
or I don't understand what your are responding.

> Hi Peter,
> All parameter assonated with policy mapping are names the same. If you
> want guidance on their use in combination with the policy reference see
> section 1.3.
It is obviously not difficult to guess which names corresponds, that
is not the problem. 


> SCVP only supports one policy per request therefore if you want to
> process different polices for different certificates - send different
> requests.
Where do I talk about different policies and different certificates,
are you confusing this with another message? 

I am just asking how parameters from the client and the server are
combined in a request for one signed cert with one policy. And, to
be sure, I can also assume that a client sets all the input flags
or none, if you want. 

The current syntax allows all kind of combinations of settings and
by the client and the server, it is not specified:

- how they are combined
- whether there this only a subset of useful meanings. 

> Trevor
> 
> * -----Original Message-----
> * From: Peter Sylvester [mailto:[e-mail]]
> * Sent: Tuesday, December 07, 2004 4:15 AM
> * To: Trevor Freeman
> * Cc: [e-mail]
> * Subject: Re: SCVP 16 comments deadline
> * 
> * There are several boolean values like
> * 
> *   ValidationPolicy ::= SEQUENCE {
> *     ...
> *     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
> * 
> * and a policy definition.
> * 
> *   ValidationPolValues ::=SEQUENCE  {
> *     ...
> *     inhibitPolMap            BOOLEAN,
> * 
> * 
> * - It would be nice to use the same field names.
> * 
> * - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
> *   with some apppropriate tagging, it doesn't make much sense to
> *   me to code useless values.
> * 
> * Would it be possible to add some statement about the intended
> * meaning of the 6 possible combination:
> * 
> * 
> * inhibitPolMap = FALSE
> * 
> * inhibitPolicyMapping absent  1
> *                      FALSE   2
> *                      TRUE    3
> * 
> * inhibitPolMap = TRUE
> * 
> * inhibitPolicyMapping absent  4
> *                      FALSE   5
> *                      TRUE    6
> * 
> * 
> * Does it mean that when the client value takes preceedence over the
> * server value?
> * 
> * 1 = FALSE
> * 2 = FALSE
> * 3 = TRUE
> * 4 = TRUE
> * 5 = FALSE
> * 6 = TRUE
> * 
> * 
> * It had been said some time ago (as far as I remember) that these
> * inputs are not global ones but in principle for each of the
> * certs to be asked for. what was the conclusion why they stay global
> * for all certs?
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9BlCqm084547; Thu, 9 Dec 2004 03:47:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9BlCSU084546; Thu, 9 Dec 2004 03:47:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr ([212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9Bl85Q084318 for <[e-mail]>; Thu, 9 Dec 2004 03:47:11 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB9Bkcn02779; Thu, 9 Dec 2004 12:46:38 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 9 Dec 2004 12:46:38 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB9Bkcl25107; Thu, 9 Dec 2004 12:46:38 +0100 (MET)
Date: Thu, 9 Dec 2004 12:46:38 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * 
> * But:
> * 
> * The syntax is GeneralNames. how many ids is the server intended
> * to extract from a certificate? The subject + all alternate ids?
> * 
> * Why not having this id declared by the client, and the authentication
> * methods matches against it. ==> Add a corresponding field in the
> request.
> * Which is required:
> * 
> *    When the DPV request is authenticated, the client SHOULD be able to
> *    include a client identifier in the request for the DPV server to
> copy
> *    into the response.  Mechanisms for matching this identifier with
> the
> *    authenticated identity depends on local DPV server conditions
> and/or
> *    the validation policy.  The DPV server MAY choose to blindly copy
> the
> *    identifier, omit the identifier, or return an error response.
> * 
> * It is an identifer identifying the client and not the request.
> [TF] If the client sends a signed request with certificate it has
> included a client identifier in the request. Its matter of local server
> policy which name it chooses to return.

Are you saying that this client identifier is the "issuerSerial"?
What field *IS* the "client identifier"? The certificate is not
a client identifier? In a certificate, you may have several identifiers
concerning the entity. 

The client has no way to set an "identifier for itself" in the request, so that 

   "the DPV server MAY choose to blindly copy the identifier".

The server that you propose ALWAYS MUST create some generalnames
structure for which no guideline is given on how it could be
derived from the requestorRef which is an item that has no relation
at all to the returned requesterName. 

Since two years or so I am asking that you just make two elements

requestor GeneralNames
responder GeneralNames

in both the request and the response. (and to get rid of the octet string stuff)

I may have not understod your intention of "responder", if this is a pure
local reference of the RESPONSE vs the repspoinder, then I think a 
sequence number would be more appropriate. 

> * 
> * The new text replacing "requestor" in chapter 7 by "requestorRef".
> * 
> * > however,
> * >  all of the octets MUST have values other than zero.
> * Why? I would find it quite useful to add a
> * hash of something local, if at all, the hash of its IP address for
> example
> * (for which I can use the Nonce as well).
> [TF] If you want me to remove the clause about values being other than
> zero - I am happy to do so. Since this is of local significance only, if
> an implementation puts garbage in here it does not effect
> interoperability.
How do relate 'local significance only' and the usage of such fields
for 'loop control'. The significance not just local. 
If relays just put "relay" as a local reference you will have problems. 

LOOONG time ago, I told you that an encoding of identifiers in an octet string
sounds strange, given that we have lots of ways and that you don't provide
any guideline on how identifiers can be encoded.

Although you violantly rejected all proprosals to change this, you
silently starting doing this in this version:

- replacing an octet string by a sequence  (good, but omitted the only reason
  for not allowing zeros).
- adding a requesterName item with is a generalnames
  

> * 
> *   The requestRef item allows the client to associate a response with
> *   a request.  The requestNonce provides an alternative mechanism ..
> * 
> *   and you have also the requestorRef.
> * 
> * The concept of trying to make loop control with values which are
> * explicitely
> * defined as not globally unique sounds strange to me.
> [TF] I have a big problem which the concept of global uniqueness. I
> class it the same bucket as non-repudiation. 

You are operating in a PKI where ID's of
entities are unique within the PKI. If you don't trust the
naming rule in your PKI, i.e. in some associated SCVP network
which is much smaller, i.e. in the magnitude of the size of
the CA name space.

Well, domain names work as far as I know. And telephone numbers also.
I don't say that non-repudiation doesn't work. I don't say that
I agree or disagree with your comparision since I do not see why this
is relevant here. 

You are not even answering the question: You make loop control, and
you explicitely says that the identifiers that are used do only have
local significance. You could have said: An example for identifiers
that could be used for loop control are uuids generated on each server
startup using the server address and a time value. 


> * 
> *  "The requestorRef item is also needed
> *   to prevent looping in some configurations"
> * 
> *  "No provisions are
> *   made to ensure uniqueness of the requestorRef octet string"
> * 
> * The usefulness of "requestorRef" as an identifier for the request
> * is pretty weak, since you can have a nonce if it is for each
> * request. use GeneralName(s) in a requestorName sequence as for the
> * response.
> * 
> * page 34:
> * 
> *   The requestorRef and the responder items MUST be included if the
> request
> * included a
> *   requestor item.
> * 
> * what does this mean? what is the relationship between a requesterRef
> and
> * responder?
> [TF] If requestorRef is populated, it means it's a relayed request in
> which case the responder is of significance.

No. any client can set a requestorRef, independant of whether the request
will be relayed. What is the significance of responder? In your spec
it is only of local signifance for the responding server? waht can this
be good for? 

> * 
> * If I'd be interested in anything identifying the response, then it is
> * a sequence of identifiers of the servers that have partipated, and
> some
> * local ids or "serial number' like thing if I want to go to that server
> and
> * asks 'did you really tell this to my friend'.
> * 
> * 
> * Chapter 7: Denis is right that the spec does not describe how relaying
> is
> * performed, i.e. how a response is created from a response received
> from
> * another
> * server by a 'proxy'.
> [TF] What specifically are you looking for?

A working specification that includes:

- how a request received is transformed into a new request by a relay,
  which fields are copied, or not, or may.
- how the response is transformed into a response to the original request
  there are SEVERAL options, in particulat the one that addresses
  the requirement of allowing a response as part of another one.
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8JgHIS019802; Wed, 8 Dec 2004 11:42:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8JgHXN019801; Wed, 8 Dec 2004 11:42:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8Jg60B019721 for <[e-mail]>; Wed, 8 Dec 2004 11:42:16 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 8 Dec 2004 11:42:07 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 11:42:06 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Wed, 8 Dec 2004 11:42:06 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTdSOa1ahQnk6E8SKqa+x38ok0UfQADAXfwAAHZG+AAAEp6kA==
From: "Trevor Freeman" <[e-mail]>
To: "Seth Hitchings" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 08 Dec 2004 19:42:06.0740 (UTC) FILETIME=[FFDA2540:01C4DD5D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB8JgG0B019796
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Seth,
A server can always go beyond what the client asked for. I don't see
that as strictly necessary in all cases such as if the client just asks
for revocation. Untimely is a matter of local server policy. What the
server cannot do is return status or errors relating to the other
activities which  were beyond the request scope.
Trevor

* -----Original Message-----
* From: Seth Hitchings [mailto:[e-mail]]
* Sent: Wednesday, December 08, 2004 11:34 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* Trevor,
* 
* For clarification, I assume that doing revocation status checks on a
path
* implies building
* a validated path?
* 
* If I am correct, in what case would a client ever send more than one
* check?
* 
* Seth
* 
* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of
* Trevor Freeman
* Sent: Wednesday, December 08, 2004 1:42 PM
* To: Denis Pinkas
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* 
* Denis,
* I know of several systems who's policy is never to revoke the identity
* certificate because
* they have other mechanisms to address the issue.
* They are using authorization bound to the identity and they either
rely on
* short lived
* authorization assertions or revoke the authorization privilege
assonated
* with the
* identity. Therefore in those cases not checking the revocation status
of
* the certificate
* makes perfect sense.
* Trevor
* 
* * -----Original Message-----
* * From: [e-mail]
* [mailto:[e-mail]]
* * On Behalf Of Denis Pinkas
* * Sent: Wednesday, December 08, 2004 8:01 AM
* * To: Trevor Freeman
* * Cc: [e-mail]
* * Subject: Re: SCVP 16 comments deadline
* *
* *
* * Trevor,
* *
* * > Hi Denis,
* * > Below are responses to 1-16. Others will follow later.
* *
* * I am pleased that you accepted comments 13, 14, 15 and 16.
* * Among this list, I have a further remark on comment 4.
* *
* * > * 4. Page 13. Typo. Section 3.1.2 "checks"
* * > * The two following lines are in fact one line:
* * > *
* * > * Change:
* * > *
* * > *      - Build a validated certification path to a trust anchor;
and
* * > *
* * > *      - Do revocation status checks on the certification path.
* * > *
* * > * into:
* * > *
* * > *      - Build a validated certification path to a trust anchor
and
* * > *        do revocation status checks on the certification path.
* * > *
* * > [TF] Since this paragraph is listing the possible checks and
building
* a
* * > path is a separate check to revocation checking, I think the
current
* * > text is more accurate.
* *
* * I agree that "building a path is a separate check to revocation
* checking",
* * but revocation checking without building a validated path does not
make
* * sense.
* *
* * The full text currently is:
* *
* *      - Build a certification path to a trust anchor;
* *
* *      - Build a validated certification path to a trust anchor; and
* *
* *      - Do revocation status checks on the certification path.
* *
* * The full text should be:
* *
* *      - Build a certification path to a trust anchor;
* *
* *      - Build a validated certification path to a trust anchor; and
* *        do revocation status checks on the certification path.
* *
* * Denis
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8JVkEW010749; Wed, 8 Dec 2004 11:31:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8JVkFh010748; Wed, 8 Dec 2004 11:31:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8JVjgw010714 for <[e-mail]>; Wed, 8 Dec 2004 11:31:45 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: SCVP 16 comments deadline
Date: Wed, 8 Dec 2004 14:33:57 -0500
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01D2_01C4DD32.F3057160"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTdSOa1ahQnk6E8SKqa+x38ok0UfQADAXfwAAHZG+A=
From: "Seth Hitchings" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_01D2_01C4DD32.F3057160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Trevor,

For clarification, I assume that doing revocation status checks on a path implies building
a validated path?

If I am correct, in what case would a client ever send more than one check?

Seth

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Trevor Freeman
Sent: Wednesday, December 08, 2004 1:42 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: RE: SCVP 16 comments deadline


Denis,
I know of several systems who's policy is never to revoke the identity certificate because
they have other mechanisms to address the issue.
They are using authorization bound to the identity and they either rely on  short lived
authorization assertions or revoke the authorization privilege assonated with the
identity. Therefore in those cases not checking the revocation status of the certificate
makes perfect sense.
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Denis Pinkas
* Sent: Wednesday, December 08, 2004 8:01 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
*
*
* Trevor,
*
* > Hi Denis,
* > Below are responses to 1-16. Others will follow later.
*
* I am pleased that you accepted comments 13, 14, 15 and 16.
* Among this list, I have a further remark on comment 4.
*
* > * 4. Page 13. Typo. Section 3.1.2 "checks"
* > * The two following lines are in fact one line:
* > *
* > * Change:
* > *
* > *      - Build a validated certification path to a trust anchor; and
* > *
* > *      - Do revocation status checks on the certification path.
* > *
* > * into:
* > *
* > *      - Build a validated certification path to a trust anchor and
* > *        do revocation status checks on the certification path.
* > *
* > [TF] Since this paragraph is listing the possible checks and building a
* > path is a separate check to revocation checking, I think the current
* > text is more accurate.
*
* I agree that "building a path is a separate check to revocation checking",
* but revocation checking without building a validated path does not make
* sense.
*
* The full text currently is:
* 
*      - Build a certification path to a trust anchor;
* 
*      - Build a validated certification path to a trust anchor; and
* 
*      - Do revocation status checks on the certification path.
*
* The full text should be:
* 
*      - Build a certification path to a trust anchor;
* 
*      - Build a validated certification path to a trust anchor; and
*        do revocation status checks on the certification path.
*
* Denis



------=_NextPart_000_01D2_01C4DD32.F3057160
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICASEwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzE0MTQyNDExWhcNMDUw
NzI4MTQyNDExWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD
VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApU+vUXkZtNS8zIbCun9DLBIPm3s0KGJ7
Zi8g1nng+sa1AQYZWl0+E66CVVtqz87H2rJeRuWPSTlP3aLBh24tHWHh5Yifx6PGJ2aDzYa6BMrz
+dscn7MASmDOk3gVJyl0enKKzhpfwu32YzgoftV0oMXk5iFYDbejwrTDJgGWEhUCAwEAAaOB2jCB
1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j
b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu
Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr
BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB
BQUAA4GBAHaph4KaKdbtUyu1sgOlvLWWR6N4MDr3Kecna8npqNUs6bs2Ym77r8UtdvNbVpC9QnLl
6YgxvEN/kLiOYCgakyA1kIFefeZEL1WiRFkFoW7Y2OAHowT20LaRoOJnDuOiqDPUJb6fI88JHBad
gIg4rjN62pQIhj63BoZ4OpFGDVzaMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE
ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv
cml0eQIBITAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNDEyMDgxOTMzNTZaMCMGCSqGSIb3DQEJBDEWBBSbnVS9xcefFEfE3Wx6xyFRN8zq
OjBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0
ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgEhMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg
VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl
U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBITANBgkqhkiG9w0BAQEFAASBgCppqpXodcoP
/PZqi5QVqfFuEeLbAHsc2yN24L87P+DODRyI61g9YFwgo9j+LIoLzdFBQ4r09jPl0wcL768SUBwf
igbQETpmIXvjmJtRSoCU2Ba2j3AFE9gMbyGosi7Rj8Z9AyJDSPWzr+BIUnYvIzGmEubyFL3P2jzZ
JFze/WrhAAAAAAAA

------=_NextPart_000_01D2_01C4DD32.F3057160--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8IgEAI079807; Wed, 8 Dec 2004 10:42:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8IgDC3079800; Wed, 8 Dec 2004 10:42:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8Ig6Dx079720 for <[e-mail]>; Wed, 8 Dec 2004 10:42:12 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 10:42:03 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 10:42:03 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Wed, 8 Dec 2004 10:42:02 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTdSOa1ahQnk6E8SKqa+x38ok0UfQADAXfw
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 08 Dec 2004 18:42:03.0545 (UTC) FILETIME=[9C2E3890:01C4DD55]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB8IgDDx079781
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
I know of several systems who's policy is never to revoke the identity
certificate because they have other mechanisms to address the issue.
They are using authorization bound to the identity and they either rely
on  short lived authorization assertions or revoke the authorization
privilege assonated with the identity. Therefore in those cases not
checking the revocation status of the certificate makes perfect sense.
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Denis Pinkas
* Sent: Wednesday, December 08, 2004 8:01 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* 
* Trevor,
* 
* > Hi Denis,
* > Below are responses to 1-16. Others will follow later.
* 
* I am pleased that you accepted comments 13, 14, 15 and 16.
* Among this list, I have a further remark on comment 4.
* 
* > * 4. Page 13. Typo. Section 3.1.2 "checks"
* > * The two following lines are in fact one line:
* > *
* > * Change:
* > *
* > *      - Build a validated certification path to a trust anchor; and
* > *
* > *      - Do revocation status checks on the certification path.
* > *
* > * into:
* > *
* > *      - Build a validated certification path to a trust anchor and
* > *        do revocation status checks on the certification path.
* > *
* > [TF] Since this paragraph is listing the possible checks and
building a
* > path is a separate check to revocation checking, I think the current
* > text is more accurate.
* 
* I agree that "building a path is a separate check to revocation
checking",
* but revocation checking without building a validated path does not
make
* sense.
* 
* The full text currently is:
* 
*      - Build a certification path to a trust anchor;
* 
*      - Build a validated certification path to a trust anchor; and
* 
*      - Do revocation status checks on the certification path.
* 
* The full text should be:
* 
*      - Build a certification path to a trust anchor;
* 
*      - Build a validated certification path to a trust anchor; and
*        do revocation status checks on the certification path.
* 
* Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8ITtp9072324; Wed, 8 Dec 2004 10:29:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8ITtaY072321; Wed, 8 Dec 2004 10:29:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8ITrQw072254 for <[e-mail]>; Wed, 8 Dec 2004 10:29:54 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id i8so392037rne for <[e-mail]>; Wed, 08 Dec 2004 10:29:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=iP/pHx1Kvy3vyJ9SOuNcSk1MaLskfaWon5rUb5dO2+ygmF3+s3+M9ZcrvU/cspzjr983OnwXz2dfaARfi0L4bGptcydPq21Npo7lEXeG1XDAKoDszfT/2CvpiChG82LywTf4UbAcWyu2Eo2jhaHI2zB78bT/Kbq7jJvc30MYxwg=
Received: by 10.38.97.75 with SMTP id u75mr1054258rnb; Wed, 08 Dec 2004 10:29:51 -0800 (PST)
Received: by 10.38.78.47 with HTTP; Wed, 8 Dec 2004 10:29:51 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 8 Dec 2004 13:29:51 -0500
From: Dan Proietti <[e-mail]>
Reply-To: [e-mail]
To: Trevor Freeman <[e-mail]>
Subject: Re: SCVP 16 comments deadline
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor, I have one additional comment.

Section 4.9 responder: This item is not adequately described in this
section, nor is it mentioned anywhere else in the specification.  I
presume the value of this field is the value that the SCVP server
stuffs into the requestorRef to identify itself when relaying
requests.  But if the value is "only of local signifigance to the SCVP
server" then why is it returned to the client in the response?  What
could the client possibly do with information?


Dan


On Thu, 2 Dec 2004 12:22:31 -0800, Trevor Freeman
<[e-mail]> wrote:
>  
>  
> 
> The deadline communicated at the DC meeting for making comments on SCVP 16
> was Nov 30th which has now passed. I have had only three people send me
> comments to date. SCVP 17 will be closing very shortly so this is the last
> reminder.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8G2f7h053542; Wed, 8 Dec 2004 08:02:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8G2fYf053541; Wed, 8 Dec 2004 08:02:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8G2a13053345 for <[e-mail]>; Wed, 8 Dec 2004 08:02:38 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA45434; Wed, 8 Dec 2004 17:14:52 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004120817022107:854 ; Wed, 8 Dec 2004 17:02:21 +0100 
Message-ID: <[e-mail]>
Date: Wed, 08 Dec 2004 17:00:33 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/12/2004 17:02:21, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/12/2004 17:02:24, Serialize complete at 08/12/2004 17:02:24
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

> Hi Denis,
> Below are responses to 1-16. Others will follow later.

I am pleased that you accepted comments 13, 14, 15 and 16.
Among this list, I have a further remark on comment 4.

> * 4. Page 13. Typo. Section 3.1.2 "checks"
> * The two following lines are in fact one line:
> * 
> * Change:
> * 
> *      - Build a validated certification path to a trust anchor; and
> * 
> *      - Do revocation status checks on the certification path.
> * 
> * into:
> * 
> *      - Build a validated certification path to a trust anchor and
> *        do revocation status checks on the certification path.
> * 
> [TF] Since this paragraph is listing the possible checks and building a
> path is a separate check to revocation checking, I think the current
> text is more accurate.

I agree that "building a path is a separate check to revocation checking", 
but revocation checking without building a validated path does not make sense.

The full text currently is:

     - Build a certification path to a trust anchor;

     - Build a validated certification path to a trust anchor; and

     - Do revocation status checks on the certification path.

The full text should be:

     - Build a certification path to a trust anchor;

     - Build a validated certification path to a trust anchor; and
       do revocation status checks on the certification path.

Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB81UYin007694; Tue, 7 Dec 2004 17:30:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB81UYYu007692; Tue, 7 Dec 2004 17:30:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB81UX4A007650 for <[e-mail]>; Tue, 7 Dec 2004 17:30:33 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Tue, 7 Dec 2004 17:30:28 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 17:30:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Tue, 7 Dec 2004 17:30:46 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTcVlsj4LeyAoTkRDSyvPnKt4M0OQAbcOZw
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 08 Dec 2004 01:30:30.0939 (UTC) FILETIME=[815006B0:01C4DCC5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB81UX4A007665
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
See below for details.
Trevor
* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* We have
* 
*   Query ::= SEQUENCE {
*    queriedCerts               SEQUENCE SIZE (1..MAX) OF CertReference,
* 
*    ...
*    validationPolicy           ValidationPolicy,
* 
* with
*   ValidationPolicy ::= SEQUENCE {
*     ...
*     validationAlg         [0] ValidationAlg OPTIONAL,
* 
* 
* 3.1.5 validationAlg
[TF] The duplicate Validation alg section has been removed.
* 
*   The validationAlg item, defines the validation algorithm to be used
*   by the SCVP server during certificate validation.  The value of
*   this item can be determined by agreement between the client and the
*   server, and is represented as an object identifier.  The server
*   might want to assign additional object identifiers that indicate
*   that some settings are used in addition to others given in the
*   request.  In this way, the validation algorithm object identifier
*   can be a shorthand for some SCVP options, but not others.
* 
*   The validationAlg item uses the ValidationAlg type, which has the
*   following syntax:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
* 
* and also
* 
* 
* 3.1.5.2 validationAlg
* 
*   The optional validationAlg item defines the validation algorithm to
*   be used by the SCVP server during certificate validation.  The
*   value of this item can be determined by agreement between the
*   client and the server, and the validation algorithm is represented
*   by an object identifier.
* 
*    The syntax of the validationAlg is:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
*   The following section specifies the basic validation algorithm and
*   the name validation algorithm.  SCVP clients and servers MUST
*   support both validation algorithms defined in this section.  Other
*   validation algorithms can be specified in other documents for use
*   with specific applications.  SCVP clients and servers MAY support
*   any such validation algorithms.
* 
* ---------------
* 
* 3.1.5.2.3 Name Validation Algorithm
* 
*   The name validation algorithm allows the client to supply an
*   application identifier and a name to the server.  The application
*   identifier defines the name matching rules to use in comparing the
*   name supplied in the request with the names in the certificate.
* 
* There may be more than one certificate in the request.
[TF] The policy is global to the request.
* 
* 
*     NameValidationAlgParms ::= SEQUENCE {
*       keyPurposeId      KeyPurposeId,
*       validationNames   GeneralNames }
* 
* What is the relation between the KeyPurposeId and the
extendeddkeyusage
* 3.1.5.10 extendedKeyUsages
[TF] The OID with name validation defines the matching rules. In theory
there could be multiple matching rules for an 822 name.
* 
*   If the keyPurposeID supplied in the request is id-kp-mailProtection
*   [PKIX-1], then GeneralNames supplied in the request MUST be a
*   rfc822Name, and the matching rules are defined in [SMIME-CERT].
* 
* 'an rfc822Name".
* 
* what is the meaning of this if I have more than one email certificate,
* i.e. I want to validate all encryption certs before using them.
[TF] If they are different names they have to be different requests.
* 
* 
* Does this means that the validate Algorithm is cert specific and not
* request specific?
[TF] The validation policy for the request is global to the request.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB81JswQ096352; Tue, 7 Dec 2004 17:19:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB81JsDY096350; Tue, 7 Dec 2004 17:19:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB81Jk2B096022 for <[e-mail]>; Tue, 7 Dec 2004 17:19:53 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 17:19:49 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 17:19:45 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Tue, 7 Dec 2004 17:20:01 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTcVln7WwdGIN8wQ4mlM6QPVuMpWwAbUDiQ
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 08 Dec 2004 01:19:45.0847 (UTC) FILETIME=[00CECC70:01C4DCC4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB81Jr2B096338
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
All parameter assonated with policy mapping are names the same. If you
want guidance on their use in combination with the policy reference see
section 1.3.
SCVP only supports one policy per request therefore if you want to
process different polices for different certificates - send different
requests.
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Tuesday, December 07, 2004 4:15 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* There are several boolean values like
* 
*   ValidationPolicy ::= SEQUENCE {
*     ...
*     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* 
* and a policy definition.
* 
*   ValidationPolValues ::=SEQUENCE  {
*     ...
*     inhibitPolMap            BOOLEAN,
* 
* 
* - It would be nice to use the same field names.
* 
* - I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
*   with some apppropriate tagging, it doesn't make much sense to
*   me to code useless values.
* 
* Would it be possible to add some statement about the intended
* meaning of the 6 possible combination:
* 
* 
* inhibitPolMap = FALSE
* 
* inhibitPolicyMapping absent  1
*                      FALSE   2
*                      TRUE    3
* 
* inhibitPolMap = TRUE
* 
* inhibitPolicyMapping absent  4
*                      FALSE   5
*                      TRUE    6
* 
* 
* Does it mean that when the client value takes preceedence over the
* server value?
* 
* 1 = FALSE
* 2 = FALSE
* 3 = TRUE
* 4 = TRUE
* 5 = FALSE
* 6 = TRUE
* 
* 
* It had been said some time ago (as far as I remember) that these
* inputs are not global ones but in principle for each of the
* certs to be asked for. what was the conclusion why they stay global
* for all certs?




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB81AXnM084433; Tue, 7 Dec 2004 17:10:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB81AXNt084430; Tue, 7 Dec 2004 17:10:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB81ASCK084176 for <[e-mail]>; Tue, 7 Dec 2004 17:10:30 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Tue, 7 Dec 2004 17:10:31 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 17:10:26 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Tue, 7 Dec 2004 17:10:41 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTbwgE2YqxpW6TjSSqVYmGl85dg5gA/a37A
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 08 Dec 2004 01:10:26.0065 (UTC) FILETIME=[B326D810:01C4DCC2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB81AUCK084391
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
See below for answers
Trevor
* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Monday, December 06, 2004 10:09 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* 
* I am quite pleased that about the addition
* of requestorName in the responsea and that
* the convention of  consecutive null terminated
* strings in a requestorRef have been replaced,
* 
* But:
* 
* The syntax is GeneralNames. how many ids is the server intended
* to extract from a certificate? The subject + all alternate ids?
* 
* Why not having this id declared by the client, and the authentication
* methods matches against it. ==> Add a corresponding field in the
request.
* Which is required:
* 
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.  The DPV server MAY choose to blindly copy
the
*    identifier, omit the identifier, or return an error response.
* 
* It is an identifer identifying the client and not the request.
[TF] If the client sends a signed request with certificate it has
included a client identifier in the request. Its matter of local server
policy which name it chooses to return.
* 
* The new text replacing "requestor" in chapter 7 by "requestorRef".
* 
* > however,
* >  all of the octets MUST have values other than zero.
* Why? I would find it quite useful to add a
* hash of something local, if at all, the hash of its IP address for
example
* (for which I can use the Nonce as well).
[TF] If you want me to remove the clause about values being other than
zero - I am happy to do so. Since this is of local significance only, if
an implementation puts garbage in here it does not effect
interoperability.
* 
*   The requestRef item allows the client to associate a response with
*   a request.  The requestNonce provides an alternative mechanism ..
* 
*   and you have also the requestorRef.
* 
* The concept of trying to make loop control with values which are
* explicitely
* defined as not globally unique sounds strange to me.
[TF] I have a big problem which the concept of global uniqueness. I
class it the same bucket as non-repudiation. 
* 
*  "The requestorRef item is also needed
*   to prevent looping in some configurations"
* 
*  "No provisions are
*   made to ensure uniqueness of the requestorRef octet string"
* 
* The usefulness of "requestorRef" as an identifier for the request
* is pretty weak, since you can have a nonce if it is for each
* request. use GeneralName(s) in a requestorName sequence as for the
* response.
* 
* page 34:
* 
*   The requestorRef and the responder items MUST be included if the
request
* included a
*   requestor item.
* 
* what does this mean? what is the relationship between a requesterRef
and
* responder?
[TF] If requestorRef is populated, it means it's a relayed request in
which case the responder is of significance.
* 
* If I'd be interested in anything identifying the response, then it is
* a sequence of identifiers of the servers that have partipated, and
some
* local ids or "serial number' like thing if I want to go to that server
and
* asks 'did you really tell this to my friend'.
* 
* 
* Chapter 7: Denis is right that the spec does not describe how relaying
is
* performed, i.e. how a response is created from a response received
from
* another
* server by a 'proxy'.
[TF] What specifically are you looking for?
* 
* 
* 
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7MLDMc094968; Tue, 7 Dec 2004 14:21:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7MLDOq094964; Tue, 7 Dec 2004 14:21:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7MLCxk094923 for <[e-mail]>; Tue, 7 Dec 2004 14:21:12 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id z35so90525rne for <[e-mail]>; Tue, 07 Dec 2004 14:21:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=T4F7mSmrAO+cqcg2SLORm0EneOItUbSXi1y7BHv3dBKl8e1eTFI7apUxlOtsjvT+B/8D6HBlTSGwHNPAqiVlhwMDvxhLeEsTVMCLCpzTqazwlQvEWQMhaNi7FAAPxsu/600/JjtKiqMKBJzUoM58uE/qsAvDBOnciZDZ95kc3NE=
Received: by 10.38.104.57 with SMTP id b57mr522000rnc; Tue, 07 Dec 2004 14:21:08 -0800 (PST)
Received: by 10.38.78.47 with HTTP; Tue, 7 Dec 2004 14:21:06 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 7 Dec 2004 17:21:06 -0500
From: Dan Proietti <[e-mail]>
Reply-To: [e-mail]
To: Trevor Freeman <[e-mail]>
Subject: Re: SCVP 16 comments deadline
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for the reply, Trevor.  I've included additional clarification,
comments, and questions inline below.


Dan


On Tue, 7 Dec 2004 12:06:18 -0800, Trevor Freeman
<[e-mail]> wrote:
> Hi Dan,
> Thanks for the feedback. Answers below.
> Thanks
> Trevor
> 
> * -----Original Message-----
> * From: [e-mail]
> [mailto:[e-mail]]
> * On Behalf Of Dan Proietti
> * Sent: Monday, December 06, 2004 11:08 AM
> * To: [e-mail]
> * Subject: RE: SCVP 16 comments deadline
> *
> *
> * Hi, Trevor.  I have a few comments re: default validation policy.
> 
> 
> *
> * a) Section 1.3 states, "The default policy can be requested for
> * validation and the client can override any default value in the
> * request if required.  The default values are also used when processing
> * requests which reference a validation policy other than the default
> * one that does not contain the full set of parameters necessary for
> * validation and the client has also omitted the missing values in the
> * request." Section 6.14 is also quite clear about this.  However, in
> * section 3.1.4, the field descriptions for the ValidationPolicy type
> * imply that a fixed default is used when an OPTIONAL item is not
> * included.  For instance the description for userPolicySet (section
> * 3.1.5.3) states, "If userPolicySet is not specified, then any-policy
> * MUST be used."  If section 1.3 still holds, the correct description
> * should be something like, "If userPolicySet is not specified, then the
> * value from the default validation policy will be used."  Same goes for
> * the other ValidationPolicy field descriptions: inhibitPolicyMapping,
> * requireExplicitPolicy, inhibitAnyPolicy, isCA, keyUsages,
> * extendedKeyUsages.  If this is indeed the intent.
> 
> [TF] The conflict with default policy and user policy set has been
> recognized and the requirement around any-policy in 3.1.5.3 has been
> removed. Are there any other specifics in the section you reference
> where you feel there is a conflict? I have reread those sections and
> don't see any other clauses which appear to contradict the default
> policy.
> 

The clauses that are in error are:

3.1.5.4 inhibitPolicyMapping: "By default the server allows policy
mapping as part of certification path validation."

3.1.5.5 requireExplicitPolicy: "By default the server accepts no
policies in the certificate policies extension of valid certificates."

3.1.5.6 inhibitAnyPolicy: "By default the server processes the any-policy OID."

3.1.5.7 isCA: "If the BOOLEAN value is omitted from the request and
the client submits a CA certificate as the subject of the validation
request, then a server MUST NOT treat this as an error."

For each section I think that the quoted text should just be deleted. 
Default values for all these properties are defined by the validation
policy.

> *
> * b) Section 3.1.5.1 is titled "Default Validation Algorithm" but
> * discusses the default validation policy.
> 
> [TF] This should have read algorithm not policy and is now fixed.
> 

Huh?  What will this section be titled in 17?  "Default Validation
Algorithm" or "Default Validation Policy"?  My vote is for "Default
Validation Policy".

> 
> 
>   This is very confusing.  I
> * presume this should be titled "Default Validation Policy" and be
> * re-located to a sub-section of the validationPolRef description
> * (3.1.4.1)?
> *
> * c) Section 3.1.5.2.1 (Basic Validation Algorithm) defines the "meaning
> * of the default validation algorithm".  This is extremely confusing as
> * this is the first time this term is mentioned.  I presume "algorithm"
> * should be changed to "policy" and the remainder of this sub-section
> * should be merged into the "Default Validation Policy" section?
> 
> [TF] The basic validation algorithm is an algorithm not a policy in that
> it defines how the parameters are compared not their values.

The issue that I intended to raise with b) and c) is with the term
"default validation algorithm".  What is the "default validation
algorithm"?  As I understand it, it is the validation algorithm that
must be used when requesting the "default validation policy".  And
this algorithm must be the "basic validation algorithm".  Is it indeed
necessary to include the specialized term "default validation
algorithm" when it is equivalent to the already established term
"basic validation algorithm"?

> 
> *
> * d) Related to c) above, the second bullet states, "The acceptable
> * policy set will come from the userPolicySet item.  If no certificate
> * policies are specified in the userPolicySet item, then the SCVP server
> * will use any-policy."  What if the server has defined the default
> 
> [TF] The clause in 3.1.5.3 around use of any-policy has been removed.

Fair enough.  If the fully resolved validation policy still does not
contain an explicit value for userPolicySet, the "basic validation
algorithm" dictates that {any-policy} will be used.  This is the
behavior defined in 3280 Section 6.

> 
> * validation policy with a userPolicySet of {1.2.3.4} and the client
> * requests the default validation policy and does not specify a
> * userPolicySet override?  Does the server use {1.2.3.4} or
> * {any-policy}?  Or is it invalid for a server to define a default
> * validation policy with a userPolicySet other than {any-policy}?
> *
> * Personally, I think the specification needs to be more concise re:
> * constructing the actual validation policy based on a) the referenced
> * policy, b) the explicit overrides, and c) the default policy
> fallbacks.
> * An
> * example with a hypothetical agreed upon validation policy would do it.
> 
> [TF] OK I will add an example of how this works to 17.

Much appreciated. 

> 
> *
> * Thanks for your time,
> 
> 
> * Dan Proietti
> *
> *
> *
> *
> * On Thu, 2 Dec 2004 12:22:31 -0800, Trevor Freeman
> * <[e-mail]> wrote:
> * >
> * >
> * >
> * > The deadline communicated at the DC meeting for making comments on
> SCVP
> * 16
> * > was Nov 30th which has now passed. I have had only three people send
> me
> * > comments to date. SCVP 17 will be closing very shortly so this is
> the
> * last
> * > reminder.
> 
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7KklW0078721; Tue, 7 Dec 2004 12:46:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7Kkl4D078720; Tue, 7 Dec 2004 12:46:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7KkjI5078520 for <[e-mail]>; Tue, 7 Dec 2004 12:46:45 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 12:46:42 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 12:46:55 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Tue, 7 Dec 2004 12:46:37 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTbfdnnQM8sCGUwQ1+o/ms74r26bABGmo+w
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 07 Dec 2004 20:46:55.0339 (UTC) FILETIME=[E33983B0:01C4DC9D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB7KkjI5078654
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis,
Below are responses to 1-16. Others will follow later.
Trevor

* -----Original Message-----
* From: Denis Pinkas [mailto:[e-mail]]
* Sent: Monday, December 06, 2004 2:25 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* > The deadline communicated at the DC meeting for making comments on
SCVP
* > 16 was Nov 30th which has now passed. I have had only three people
send
* > me comments to date. SCVP 17 will be closing very shortly so this is
the
* > last reminder.
* 
* Thank for the remainder. I missed the initial announcement.
* My comments are below.
* 
* 
* 1. Typo. There are two IPR statements related to RFC 3668 on the first
* page. Delete one.
* 
* " By submitting this Internet-Draft, I certify that any applicable
*    patent or other IPR claims of which I am aware have been disclosed,
*    or will be disclosed, and any of which I become aware will be
*    disclosed, in accordance with RFC 3668".
[TF] Fixed
* 
* 
* 2. Page 11. Typos. First paragraph on top of the page.
* Replace "signers" by "signer's".
[TF] Fixed
* 
* 
* 3. Page 11. Typo. First paragraph on top of the page. Last sentence.
* Replace "certificate" by "certificates".
[TF] Fixed
* 
* 
* 4. Page 13. Typo. Section 3.1.2 "checks"
* The two following lines are in fact one line:
* 
* Change:
* 
*      - Build a validated certification path to a trust anchor; and
* 
*      - Do revocation status checks on the certification path.
* 
* into:
* 
*      - Build a validated certification path to a trust anchor and
*        do revocation status checks on the certification path.
* 
[TF] Since this paragraph is listing the possible checks and building a
path is a separate check to revocation checking, I think the current
text is more accurate.
* 
* 5. Page 15. Typo. Section 3.1.4 validationPolicy
* 
* This is the error left intentionally by the editor to know who read
the
* document. The following sentence is duplicated: " The validationPolicy
* item, defines the validation policy". Please delete one sentence.
[TF] Just checking <g> Fixed
* 
* 
* 6. Page 24. Typo. Section 3.1.5.9 keyUsages
* 
* Change "keyUasge" into "keyUsage".
[TF] Fixed
* 
* 
* 7. Page 27. Typo. Section 3.1.8 valididationTime
* Last line of the first paragraph. Change "servers" into "server's"
[TF] Fixed
* 
* 
* 8. Page 32. Typo. Section 3.5 dhPublicKey
* Change: Diffie-Hellamn into Diffie-Hellman.
[TF] Fixed
* 
* 
* 9. Page 32. Typo. Section 3.5 dhPublicKey
* Fifth line. Change "an does" into "and does"
[TF] Fixed
* 
* 
* 10. Page 32. Typo. Section 3.5 dhPublicKey
* Delete: (see section Error! Reference source not found.)
* 
* 
* 11. Page 33. Typo. Section 4. Validation Response
* 
* After the eight items. The following sentence has a grammar problem:
*   "Successful responses are be made when the server has fully complied
*    with the request".
[TF] Deleted the "be"
* 
* 
* 12. Page 52. Typo. Section 6 Validation Policy Response
* 
* The second sentence is incorrect. It is:
* The valPolResponse MAY not unique to any valPolRequest, ..."
* 
* Change into:
* "The valPolResponse MAY not be unique to any valPolRequest, ..."
[TF] Fixed
* 
* 
* 13. The abstract does not reflect accurately the content of the
* document.
* "certificate handling" is too vague.
* 
* Proposed abstract:
* 
*    SCVP allows a client to delegate certificate path construction and
*    certificate path validation to a server. The path construction or
*    validation (i.e. making sure that none of the certificates of the
*    path is revoked) is made according to a validation policy which
*    contains one or more trust anchors. It allows to simplify client
*    implementations and to use a set of predefined validation policies.
[TF] Suggested text substituted
* 
* 
* 14. Section 1.3
* 
* The text on validation policy is new. There is no concept of "mutually
* agreed" validation policy between the client on the server. The server
* supports a set of validation policies which may or may not fit the
need
* of the client.
* 
* Change the second sentence of section 1.3 which is:
* 
* " In SCVP, a validation policy can be either mutually
*    agreed between client and server, and subsequently referenced in
*    request, or explicitly expressed in the request by passing all of
*    the necessary parameters."
* 
* into:
* 
* " In SCVP, the validation policy to be used by the server can be
either
* fully referenced in the request by the client (and thus no additional
* parameter is necessary), referenced in the request by the client with
* additional parameters or supported by default by the server if the
* client does not reference it."
[TF] Suggested text substituted
* 
* 
* 15. Section 1.3. The second paragraph needs to be reworded. Currently,
* it is the following:
* 
* " Policy definitions can be quite long and complex, and some policies
*    may allow for the setting of a few parameters such as a set of
*    trust anchors.  The request can therefore be simplified if these
*    previously agreed policy dependent parameters are referenced in the
*    request by a mutually agreed OBJECT IDENTIFIER (OID) or URL value.
*    The referenced value indicates either a partial or full set of
*    parameters. The client can therefore omit these agreed parameters
*    from the request, only passing any parameters which are not
*    specified by the previously agreed policy.  Therefore in the
*    simplest form, with validation polices which define every parameter
*    necessary, a SCVP request need only contain the certificate to be
*    validated, the validation policy and any run-time parameters for
*    the request".
* 
* Proposed rewording:
* 
* " Policy definitions can be quite long and complex, and some policies
*    may allow for the setting of a few parameters.  The request can
*    therefore be very simple if OBJECT IDENTIFIERS (OIDs) are used to
*    specify both the algorithm to be used and all the associated
*    parameters of the validation policy. The request can be more
complex
*    if the validation policy fixes many of the parameters but allows
the
*    client to specify some of them. When the validation policy defines
*    every parameter necessary, a SCVP request needs only to contain the
*    certificate to be validated, the referenced validation policy and
any
*    run-time parameters for the request. In its simplest form, a SCVP
*    request contains the certificate to be validated and any run-time
*    parameters for the request. In that case the server uses a default
*    validation policy".
[TF] Suggested text substituted
* 
* 
* 16. Section 1.3. Paragraph 3.
* 
* The text is missing the fact that at least one validation policy must
* be supported by the server. This is the default policy which is used
* when the client omits to specify it.
* 
* The current text is the following:
* 
*   "SCVP server also publishes its default validation policy settings.
*    The default policy can be requested for validation and the client
*    can override any default value in the request if required.  The
*    default values are also used when processing requests which
*    reference a validation policy other than the default one that does
*    not contain the full set of parameters necessary for validation and
*    the client has also omitted the missing values in the request.
* 
*    Therefore a client can also simplify the request by omitting a
*    parameter from a request if the default value published by the
*    server is acceptable".
* 
* Replace it with:
* 
* " A SCVP server must support a default validation policy which will
*    be used if the client does not specify any in its request. A server
*    publishes the references of the validation policies it supports.
*    When these policies have parameters that may be overridden, the
*    default value for these parameters are communicated by the server
as
*    well. The client can simplify the request by omitting a parameter
*    from a request if the default value published by the server for a
*    given validation policy reference is acceptable. However if there
is
*    a desire to demonstrate to someone else that a specific validation
*    policy with all its parameters has been used, it will need to ask
the
*    server for the inclusion of the full validation policy with all the
*    parameters in the response".
[TF] Suggested text substituted
* 
* 
* 17. On top of page 7, the relationship between the validation policy
* and the basic certification path algorithm is not explained. Then in
* section 1.4 The concept of validation algorithm is introduced but its
* relationship with the validation policy is not explained. This is
* confusing.
* 
* Later on when observing the ASN.1 syntax it may be discovered that two
* OIDs are being used:
* 
*   - one for the validation policy (ValidationPolRef) and
*   - one for the validation algorithm (ValidationAlg).
* 
* This is overcomplicated and unnecessary.
* 
* An important simplification is obtained if, as the previous text
* states, there is an OID to defined the validation policy and there may
* be or may not be additional parameters.
* 
* We could then have:
* 
* valPolByOID::= SEQUENCE {
*        valPolId              OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY ValPolId OPTIONAL }
* 
* Specifying a path processing compliant with section 6.1 of RFC 3280
* would be possible (notice however that the text from RFC 3280 is too
* vague to support the case where a CRL is not signed by the CA).
* 
* It would be desirable to be able to communicate easily and in a
* standard way the parameters that may be set in section 6.1 from RFC
* 3280. In addition, key usage should be added to that list.
* 
* The document should then define a bundle of all these previous useful
* parameters and allow for the addition of other parameters.
* 
* It is thus proposed to define an OID for a validation policy compliant
* with section 6.1 of RFC 3280 (some differences with section 6 from
* 3280bis, i.e. adding precision, may be expected)
* 
* It is thus proposed to modify the text starting from :
* 
* " The inputs to the basic certification path processing algorithm
*    used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise"
*    up to the end of section 1.3 with the following:
* 
* "For clients able to specify the parameters of a validation policy, it
* may be useful to define a standard data structure (using a bundle)
able
* to support the parameters of the basic certification path processing
* algorithm defined by in section 6.1.1 from [PKIX-1] :
* 
*   - a set of Trust Anchors (by value or by reference),
*   - the initial Certificate Policy set,
*   - initial Certificate Policy mapping setting,
*   - initial any-Policy setting,
*   - initial explicit Certificate Policy setting.
* 
* as well as :
* 
*    - the usage of the key contained in the certificate (e.g., key
*      encipherment, key agreement, signature)
* 
* This will be done using a bundle which encapsulates all these
* parameters.
* 
* Other application-specific purposes parameters may be added".
* 
* 
* 18. Section 1.4 is about a "Validation Algorithm". Given what was said
* before, the header of this section should be changed. If we make a
* subsection 1.3.1 called "1.3.1. General" for encapsulating the
previous
* text, then we can introduce a new section 1.3.2 called:
* 
* "1.3.2. Validation policy according to section 6.1 of RFC 3280"
* 
* Some of the text present in the current section 1.4 has been used to
* build the new text that is proposed below:
* 
* "1.3.2. Validation policy according to section 6.1 of RFC 3280
* 
*    SCVP defines a specific validation policy which implements the
*    certification path validation algorithm as defined in section 6.1
of
*    [PKIX-1]. This specific validation policy, called "rfc-3280 basic
*    validation policy" uses the parameters defined in the bundle
*    mentioned above.
* 
*    Note that this algorithm does not support in its full generality
the
*    algorithm described in section 6.2 of [PKIX-1] since, when more
than
*    one trust anchor is being defined, all the conditions that are
*    specified apply to all trust anchors, whereas section 6.2 allows to
*    have different conditions for every trust anchor.
* 
*    The rfc-3280 basic validation policy may be the default validation
*    policy supported by the server, but does not need to".
* 
* 
* 19. Section 2 "Protocol Overview"
* 
* In order to allow for interoperability and testing a common protocol
* needs to be supported. It should be defined.
* 
* 
* 20. Section 3 "Validation Request"
* 
* The unsigned request form is not explained and there is a confusion
for
* the signed request which indeed authenticates the client and is thus
* not anonymous. The current text is :
* 
*    "A signed
*    request is used to authenticate the client to the server or to
*    provide an anonymous client integrity over the request-response
*    pair."
* 
* It should be rephrased as:
* 
*    "An unsigned request provides an anonymous client integrity over
*     the request since the hash of the request or the full request is
*     incorporated in the response. A signed request is used to
*     authenticate the client to the server".
* 
* 
* 21. Page 13. Section 3.1.2 "checks"
* 
* The following sentence adds nothing and should be removed:
* 
*    "A server may still choose to
*    perform revocation status checks when performing path construction,
*    although this information cannot be returned to the client."
* 
* 
* 22. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
*      - Proof of revocation status for each certificate in the AC
*         issuer certification path;
* 
* It would be important to refer the section of the RFC which explains
* how to
* check the "revocation status for each certificate in the AC issuer
* certification path".
* 
* 
* 23. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
*    The client can also request a non-cached response to the request by
*    including wantback id-swb-non-cached-resp in the request.
* 
* The default behavior should be the reverse: fresh information is
* provided, unless the client accept cached information. The item should
* be changed into:
* id-swb-cached-resp
* 
* 
* 24. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
* id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
* 
* It should be mentioned that this item is only possible for DPD.
* 
* 
* 25. Page 16. Section 3.1.4 validationPolicy
* 
* The following sentence is talking of an agreement whereas such
* agreement does not exist. Delete the sentence:
* 
*   "The client and server can optionally agree on a set of parameters
*    which may fully or partially define a validation policy".
* 
* 
* 26. Page 16. Section 3.1.4 validationPolicy
* The text states:
* 
*    "If a partial set of parameters has been agreed upon,
*    then the client supplies a reference to the policy plus whatever
*    parameters are necessary to complete the request in this item.
* 
* This should be replaced with:
* 
*    "If the validation policy does not define all parameters necessary
*    for processing an SCVP request, then the client need to supply
these
*    parameters".
* 
* 27. Page 16. Section 3.1.4 validationPolicy
* 
*    The syntax of the validationPolicy item is defined as:
* 
*    ValidationPolicy ::= SEQUENCE {
*      validationPolRef          ValidationPolRef,
*      validationAlg         [0] ValidationAlg OPTIONAL,
*      userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
*                                  IDENTIFIER OPTIONAL,
*      inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
*      requireExplicitPolicy [3] BOOLEAN OPTIONAL,
*      inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
*      isCA                  [5] BOOLEAN OPTIONAL,
*      trustAnchors          [6] TrustAnchors OPTIONAL,
*      keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
*                                   OPTIONAL,
*      extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}
* 
* 
* This structure is quite odd, because it only allows to pass additional
* parameters as parameters of the validationAlg. Suppressing the
* validationAlg item add adding validationParamExtensions would be a
* simpler and cleaner way.
* 
* Each validation policies uses its own parameters.
* We should have something like :
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* More details follow.
* 
* 
* 28. It is highly debatable if URIs should be supported or not to
* reference a validation policy. URIs are not stable over time and thus
* unless there are dereferenced and a hash value is computed over them,
* it is insecure to use them. There is a discussion in the security
* consideration section, but no warning and no pointer here. If we keep
* them, we should warn the user.
* 
* If the WG should decides that they should be supported (and if the
IESG
* agrees) on page 17, the ASN.1 description should then be:
* 
* ValidationPolicy ::= CHOICE {
*      valPolByOID         [0] ValPolByOID,
*      valPolByURI         [1] ValPolByURI }
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* ValPolByURI ::= SEQUENCE {
*      uri            IA5String,
*      hashAlgo       OBJECT IDENTIFIER,
*      hashValue      OCTET STRING}
* 
* 
* 29. It is proposed to define the following bundle:
* 
* ValidationParamBundle ::= SEQUENCE {
*      certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF OBJECT
*                                    IDENTIFIER OPTIONAL,
*      inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
*      requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
*      inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
*      isCA                      [4] BOOLEAN OPTIONAL,
*      trustAnchors              [5] TrustAnchors OPTIONAL,
*      keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF KeyUsage
*                                    OPTIONAL,
*      extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
*      extensions                [8] EXPLICIT Extensions OPTIONAL }
* 
* Note that userPolicySet" is unclear and has been changed into
* "certificatePolicySet".
* 
* The text would need to be aligned with the new structure and, of
course
* the parameters of the rfc-3280 basic validation policy will simply
* include the bundle above as its parameters.
* 
* It should also be mentioned somewhere in the document that the support
* of the rfc-3280 basic validation policy is not mandatory for
* conformance but, if supported then the bundle needs to be supported.
* 
* 
* 30. Page 17. Section 3.1.5 validationAlg should be deleted.
* 
* 
* 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
* deleted and replaced by a section later on the "rfc-3280 basic
* validation policy", which should have its OID defined under the scvp
* tree for OIDs.
* 
* 
* 32. Page 17. Section 3.1.5.1. Some text of this section might be re-
* sued to build a new section on the rfc-3280 basic validation policy.
* Note that the last sentence at the bottom of page 17, should be
* removed. This sentence is: "The default validation policy MUST use the
* basic validation algorithm". Any default validation policy can be
used.
* 
* 
* 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
* should be as well deleted.
* 
* 
* 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
* 
* This goal of this section seems to introduce an additional test to the
* basic "rfc-3280 basic validation policy". It would come naturally as
an
* extension of ValidationParamBundle, rather than as a parameter of the
* validationAlgo which has been proposed to be removed. The text should
* be modified accordingly.
* 
* 
* 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
* 
*      NameValidationAlgParms ::= SEQUENCE {
*        keyPurposeId      KeyPurposeId,
*        validationNames   GeneralNames }
* 
* This construct is artificial since KeyPurposeId is about the Extended
* Key Usage and has nothing to do with name validation.
* 
* It could indeed be interesting to test the Extended Key Usage
extension
* of a certificate, but this should be supported as an extension of
* ValidationParamBundle. The text should be modified accordingly.
* 
* 
* 36. Page 22. Section 3.1.5.3 userPolicySet
* 
* userPolicySet should be changed everywhere into certificatePolicySet.
* 
* 
* 37. Page 22. Section 3.1.5.3 userPolicySet
* 
* The text has many sentences like:
* 
*    SCVP clients SHOULD support userPolicySet item in requests, and
*    SCVP servers MUST support userPolicySet item in requests.
* 
* These requirements only apply for the rfc-3280 basic validation
policy,
* and this should be clearly mentioned.
* 
* 
* 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
* 
* The text states:
* 
*    By default the server allows policy mapping as
*    part of certification path validation.
* 
* For simplicity, this should be the reverse. Replace with:
* 
*   "By default the server does not perform policy mapping as
*    part of certification path validation. If the client wants the
*    server to support policy mapping, allowPolicyMapping must be set
*    to TRUE in the request".
* 
* 
* 39. Page 24. Section 3.1.5.8 trustAnchors
* 
* The text states:
* 
*   "A certificate reference can be used to identify the
*    trust anchor by certificate hash and optionally a distinguished
*    name with serial number".
* 
* This is not consistent with the ASN.1 definition of PKCReference which
* is:
* 
*    PKCReference ::= CHOICE {
*      cert                   [0] Certificate,
*      pkcRef                 [1] ESSCertID }
* 
* Please correct.
* 
* 
* 40. Page 25. Section 3.1.6 responseRefHash
* 
* The text states:
* 
*    "By default, the server includes a hash
*    of the request in the response.  If the client wants the server to
*    include the full request in the response, responseRefHash is set to
*    FALSE."
* 
* The server shall always include a hash of the request in the response.
* This is an easy way to allow to test the integrity of the request.
* Since the full description of the validation policy may be much longer
* a flag should be used to say that the full validation policy is not
* returned unless requested. It is thus proposed to have instead the
* following:
* 
* "3.1.6.1 fullRequestInResponse
* 
*    The fullRequestInResponse controls if the client wants the server
*    to include the full request in the response. By default,
*    fullRequestInResponse is set to FALSE. If the client wants back
*    the full request then it must set this parameter to TRUE. The main
*    reason a client would request the server to include the full
request
*    in the response is to archive the request-response exchange in a
*    single object.  That is, the client wants to archive a single
object
*    which includes both request and response".
* 
* 
* 41. Page 26. Section 3.1.6.2 responseValidationPolByRef
* 
* This item should be renamed: fullValPolInResponse
* 
* The text should be changed into:
* 
* "The fullValPolInResponse controls whether the response includes the
* identifier of the validation policy with all the parameters that have
* been used by the server, i.e. all the variable parameters independent
* from the fact that there were specified by the client or defaulted if
* not specified. By default, fullValPolInResponse is set to FALSE. If
the
* client wants the full validation policy to be included, then
* fullValPolInResponse is set to TRUE. The main reason a client would
* request the server to include validation policy to be included by
value
* is to archive the request-response exchange in a single object. That
* is, the client wants to archive the CVResponse and have it include
* every aspect of the validation policy."
* 
* The ResponseFlags should be changed as follows:
* 
*    ResponseFlags ::= SEQUENCE {
*      fullRequestInResponse      BOOLEAN DEFAULT FALSE,
*      fullValPolInResponse       BOOLEAN DEFAULT FALSE,
*      signResponse               BOOLEAN DEFAULT TRUE }
* 
* 
* 42. Page 28. Section 3.1.9 intermediateCerts. Minor.
* 
* Change:
* 
*    The optional intermediateCerts item helps the SCVP server create
*    valid certification paths.
* 
* into:
* 
*    The optional intermediateCerts item may help the SCVP server to
* create
*    valid certification paths.
* 
* 43. Page 29. Section 3.1.11. producedAt
* 
* Last sentence. Change:
* 
*    SCVP server SHOULD support the producedAt values in the request.
* 
* into:
* 
*    SCVP server MAY support the producedAt values in the request.
* 
* Reason: cached responses should not need to be implemented in order to
* be compliant with the specification.
* 
* 
* 44. Page 32. Section 3.5 dhPublicKey
* 
* The text states:
* 
*   "For the server to compute the shared
*    secret, it must lean the public values the client generates,
*    therefore the client MUST include this in the request if it uses
*    this mechanism to integrity protect the request-response pair."
* 
* Replace:
* 
* "to integrity protect the request-response pair"
* 
* with :
* 
* "to authenticate and integrity protect the first response and
* authenticate and integrity protect subsequent request-response pairs".
* 
* 45. Page 32. Section 3.6 SCVP Request Authentication
* 
* The text states:
* 
*   "It is a matter of local policy what validation policy is used by
*    the server when validating requests".
* 
* This sentence could be misinterpreted because the word "validating" is
* being used. Change into:
* 
*    It is a matter of local policy what validation policy is used by
*    the server when authentication requests".
* 
* 
* 46. Page 35. Section 4. Validation Response
* 
*    The CVResponse is defined as follows:
* 
*      CVResponse ::= SEQUENCE {
*        cvResponseVersion         cvResponseVersion        INTEGER,
*        policyID                  INTEGER,
*        producedAt                GeneralizedTime,
*        ....
* 
* On the next page the test states:
* 
*   "The policy ID used by the SCVP server when it processed the
request.
*    See section 6.4 for details."
* 
* In section 6.4 the text states:
* 
* "6.4 defaultPolicyID
* 
*    An integer that uniquely represents the version of the default
*    validation policy as represented by the trustAnchors, ..."
* 
* This is not understandable, over-engineering and very complicated.
* Please delete this item.
* 
* 
* 47. Page 35. Section 4. Validation Response
* 
*    The CVResponse contains:
* 
*        requestRef            [1] RequestReference OPTIONAL,
* 
* Remove "OPTIONAL" since it is very beneficial to mandate this item
* since it allows to make sure that the request has not be modified if
* the response is integrity protected. The computation is fast and easy
* and the hash value does not overload the response.
* 
* 
* 48. Page 38. Section 4.5 respValidationPolicy
* 
* The definition of this item is overcomplicated and not tailored to
* support any kind of validation policy.
* 
* If the client does not specify the validation policy or if the client
* specifies a validation policy which has default parameters, then the
* full description of the validation policy shall be given back.
* 
* If the client specifies a validation policy which has no default
* parameters, then the reference and parameters, if any, of the
* validation policy are in the request.
* 
* The full description of the validation policy shall be given back in
* any case, if the fullValPolInResponse Boolean in ResponseFlags is set.
* 
* respValidationPolicy :: = ValidationPolicy
* 
* 
* 
* 49. Page 41. Section 4.6 requestRef
* 
* As stated earlier, requestRef should be mandatory and always be a hash
* of the request.
* 
* In addition a fullRequest OPTIONAL parameter should be added as an
* optional item for CVResponse.
* 
* The full description of the validation policy shall be given back in
* any case, if the fullRequestInResponse Boolean in ResponseFlags is
set.
* 
* Change the text and the syntax accordingly.
* 
* 
* 50. Page 41. Section 4.6 requestRef
* 
* The text states:
* 
*    "The requestRef item allows the client to associate a response with
*    a request"
* 
* This is wrong. This does not protect against a replay.
* 
* Change with:
* 
* "When the response is authenticated, the requestRef item allows the
* client to make sure that the request was not modified in transit".
* 
* 
* 51. Page 41. Section 4.6 requestRef
* 
* The text states:
* 
* " The requestNonce provides an alternative mechanism for
*    matching requests and responses if the client has selected to
*    include a full response."
* 
* This is wrong. This is not an alternative for matching requests and
* responses.
* 
* Replace with:
* 
*   "The requestNonce allows to protect against replay, even if time
* synchronization is not good between the client and the server".
* 
* 
* 52. Page 42. Section 4.6.1 requestHash
* 
* The text states:
* 
* " The requestNonce provides an alternative mechanism for matching
* requests and responses".
* 
* This is wrong. See above. Delete.
* 
* 
* 53. Page 45. Section 4.10.4 replyChecks
* 
* ReplyCheck is defined as:
* 
*      ReplyCheck ::= SEQUENCE {
*        check                      OBJECT IDENTIFIER,
*        status                     INTEGER }
* 
* It should be defined as:
* 
*      ReplyCheck ::= SEQUENCE {
*        check                      OBJECT IDENTIFIER,
*        status                     INTEGER DEFAULT 0}
* 
* 
* 54. Page 46. Section 4.10.4 replyChecks
* 
* The text states
* 
*    "The status value for public key certification path building to a
*    trusted root along with complete status checking, { id-stc 3 }, can
*    be one of the following:
* 
*        0: Good
*        1: Revoked
*        2: Revocation Offline
*        3: Revocation Unavailable
* 
* It is unclear to understand the benefits that a client can have from
* the difference between "Revocation Offline" and "Revocation
* Unavailable". In addition, these wordings do not match the
explanations
* of what there are.
* 
* A much more important response is missing: suspended. Suspended is a
* variation of revoked, but the client then knows it may attempt another
* try later on.
* 
* It is thus suggested to change it into:
* 
*        0: Good
*        1: Revoked
*        2: Suspended
*        3: Revocation info unavailable"
* 
* 
* 55. Page 46. Section 4.10.4 replyChecks
* 
* 
* The same comment applies for the status value for AC issuer
* certification path.
* 
* 
* 56. Page 48. Section 4.10.6 validationAlg
* For reasons given before, delete validationAlg.
* 
* 
* 57. Page 48. Section 4.10.8 nextUpdate
* 
* If CRLs are used, should this field contain the value of the next
* update field for the smallest value of all the CRLs ? What is the real
* benefit of supporting this element besides added complexity ? It is
* suggested to delete that item.
* 
* 
* 58. Page 49. Section 4.11 responseNonce
* 
* The text states:
* 
* "The responseNonce item contains an identifier to binds the request
* to the response."
* 
* This is incorrect. The nonce is to detect replay.
* 
* Change into:
* 
* "The responseNonce item contains a unique number which allows to
detect
* replay".
* 
* 
* 59. Page 51. Section 5 Server Policy Request
* 
* The text states:
* 
*   "A SCVP client uses the valPolRequest item to request the list of
*    validation policies supported by the SCVP server."
* 
* This is not a correct description of what this request is doing. When
* looking at the ASN.1 it is doing much more. So the question is whether
* two requests should be provided or one. In the later case, it is
* important to advertise correctly what the request is doing.
* 
* 
* 60. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
* The first three items are overengineering:
* 
*        vpResponseVersion          INTEGER,
*        maxCVResponseVersion       INTEGER,
*        maxVPResponseVersion       INTEGER,
* 
* Further more they are mandatory. Please delete.
* 
* 
* 61. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
*         defaultPolicyID            INTEGER,
* 
* This item does not make sense. When an OID references a validation
* policy, there is no concept of versioning. Another version will simply
* get another OID (hopefully in the same branch). Please delete.
* 
* 
* 62. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
*        validationPolices          SEQUENCE OF ValidationPolRef,
*        validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
* 
* validationAlgs is unnecessary. Please delete.
* 
* validationPolicies (not validationPolices) is the main component. See
* below for a full proposal for restructuring VPResponse.
* 
* 
* 63. Page 52. Section 6 Validation Policy Response
* 
*        authPolicies               SEQUENCE OF AuthPolicy,
*        responseTypes              ResponseTypes,
*        dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
* 
* are elements which have nothing to do with the list of validation
* policies, and they are mandatory ! Either group them in one OPTIONAL
* item or define another command to get them.
* 
* 
* 64. Page 52. Section 6 Validation Policy Response
* 
*       defaultPolicyValues        ValidationPolValues,
* 
* This is simply the set of parameters which are related to the rfc-3280
* basic validation policy. This set could be used by other validation
* policies. Please delete.
* 
* 
* 65. Page 52. Section 6 Validation Policy Response
* 
* What follows is a sketch for a proposal for VPResponse.
* 
*     VPResponse ::= SEQUENCE {
*        requestNonce               OCTET STRING      OPTIONAL
*        thisUpdate                 GeneralizedTime,
*        nextUpdate                 GeneralizedTime   OPTIONAL,
*        validationPolicies         SEQUENCE OF ValidationPolicy,
*        serverParams               ServerParams      OPTIONAL }
* 
* 
*     ServerParams ::= SEQUENCE {
*        responseTypes              ResponseTypes,
*        authPolicies           [0] SEQUENCE OF AuthPolicy
OPTIONAL,
*        dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo
OPTIONAL,
*        clockSkew              [2] INTEGER OPTIONAL }
* 
* Note: it is re-called that ValidationPolicy should be redefined as:
* 
* ValidationPolicy ::= CHOICE {
*      valPolByOID         [0] ValPolByOID,
*      valPolByURI         [1] ValPolByURI }
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* ValPolByURI ::= SEQUENCE {
*      uri            IA5String,
*      hashAlgo       OBJECT IDENTIFIER,
*      hashValue      OCTET STRING}
* 
* 
* 
* 66. Page 56. Section 7 SCVP Server Relay
* 
* This section is incomplete and lacking explanations. Please explain
how
* relaying is achieved.
* 
* 
* 67. Page 65. Section 9 Security Considerations
* 
* In the second paragraph, there is a discussion about the use of URIs
to
* reference validation policies.
* 
* Firstly, if URIs are going to stay, a pointer to the security
* consideration section should be present in the main body of the
* document.
* 
* Secondly, the text should mention the need for the ability to
* dereference the URI and the need to compute a hash, while the main
body
* of the document should explain the computation of a hash on the
content
* of the URI.
* 
* 
* 68. Page 65. Section 9 Security Considerations
* 
* The text states:
* 
*   "It can also do this by using the Diffie-hellman keys to sign the
* request".
* 
* Replace "sign" by "authenticate".
* 
* END OF COMMENTS
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7K6Wru046853; Tue, 7 Dec 2004 12:06:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7K6W6h046852; Tue, 7 Dec 2004 12:06:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7K6R5L046755 for <[e-mail]>; Tue, 7 Dec 2004 12:06:27 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Tue, 7 Dec 2004 12:06:31 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Tue, 7 Dec 2004 12:06:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Tue, 7 Dec 2004 12:06:18 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTbzTKZYkKja+lJS6qAXcRjj/eW7wAHBqAg
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 07 Dec 2004 20:06:30.0290 (UTC) FILETIME=[3DC86720:01C4DC98]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB7K6R5L046803
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Dan,
Thanks for the feedback. Answers below.
Thanks
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Dan Proietti
* Sent: Monday, December 06, 2004 11:08 AM
* To: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* 
* Hi, Trevor.  I have a few comments re: default validation policy.
* 
* a) Section 1.3 states, "The default policy can be requested for
* validation and the client can override any default value in the
* request if required.  The default values are also used when processing
* requests which reference a validation policy other than the default
* one that does not contain the full set of parameters necessary for
* validation and the client has also omitted the missing values in the
* request." Section 6.14 is also quite clear about this.  However, in
* section 3.1.4, the field descriptions for the ValidationPolicy type
* imply that a fixed default is used when an OPTIONAL item is not
* included.  For instance the description for userPolicySet (section
* 3.1.5.3) states, "If userPolicySet is not specified, then any-policy
* MUST be used."  If section 1.3 still holds, the correct description
* should be something like, "If userPolicySet is not specified, then the
* value from the default validation policy will be used."  Same goes for
* the other ValidationPolicy field descriptions: inhibitPolicyMapping,
* requireExplicitPolicy, inhibitAnyPolicy, isCA, keyUsages,
* extendedKeyUsages.  If this is indeed the intent.

[TF] The conflict with default policy and user policy set has been
recognized and the requirement around any-policy in 3.1.5.3 has been
removed. Are there any other specifics in the section you reference
where you feel there is a conflict? I have reread those sections and
don't see any other clauses which appear to contradict the default
policy.

* 
* b) Section 3.1.5.1 is titled "Default Validation Algorithm" but
* discusses the default validation policy.

[TF] This should have read algorithm not policy and is now fixed.

  This is very confusing.  I
* presume this should be titled "Default Validation Policy" and be
* re-located to a sub-section of the validationPolRef description
* (3.1.4.1)?
* 
* c) Section 3.1.5.2.1 (Basic Validation Algorithm) defines the "meaning
* of the default validation algorithm".  This is extremely confusing as
* this is the first time this term is mentioned.  I presume "algorithm"
* should be changed to "policy" and the remainder of this sub-section
* should be merged into the "Default Validation Policy" section?

[TF] The basic validation algorithm is an algorithm not a policy in that
it defines how the parameters are compared not their values. 

* 
* d) Related to c) above, the second bullet states, "The acceptable
* policy set will come from the userPolicySet item.  If no certificate
* policies are specified in the userPolicySet item, then the SCVP server
* will use any-policy."  What if the server has defined the default

[TF] The clause in 3.1.5.3 around use of any-policy has been removed.


* validation policy with a userPolicySet of {1.2.3.4} and the client
* requests the default validation policy and does not specify a
* userPolicySet override?  Does the server use {1.2.3.4} or
* {any-policy}?  Or is it invalid for a server to define a default
* validation policy with a userPolicySet other than {any-policy}?
* 
* Personally, I think the specification needs to be more concise re:
* constructing the actual validation policy based on a) the referenced
* policy, b) the explicit overrides, and c) the default policy
fallbacks.
* An
* example with a hypothetical agreed upon validation policy would do it.

[TF] OK I will add an example of how this works to 17.

* 
* Thanks for your time,
* Dan Proietti
* 
* 
* 
* 
* On Thu, 2 Dec 2004 12:22:31 -0800, Trevor Freeman
* <[e-mail]> wrote:
* >
* >
* >
* > The deadline communicated at the DC meeting for making comments on
SCVP
* 16
* > was Nov 30th which has now passed. I have had only three people send
me
* > comments to date. SCVP 17 will be closing very shortly so this is
the
* last
* > reminder.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7Hr0C0058462; Tue, 7 Dec 2004 09:53:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7Hr0QY058461; Tue, 7 Dec 2004 09:53:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB7HqrBh058414 for <[e-mail]>; Tue, 7 Dec 2004 09:53:00 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 38902 invoked by uid 1236); 7 Dec 2004 17:52:44 -0000
Received: from 146.87.80.63 by iapetus.salford.ac.uk (envelope-from <[e-mail]>, uid 401) with qmail-scanner-1.23  (clamdscan: 0.75.1. uvscan: v4.3.20/v4411. spamassassin: 2.64.   Clear:RC:1(146.87.80.63):.  Processed in 0.448546 secs); 07 Dec 2004 17:52:44 -0000
Received: from 146-87-80-63.salford.ac.uk (HELO [146.87.80.63]) (146.87.80.63) by iapetus.salford.ac.uk (qpsmtpd/0.29-cvs-20040817) with ESMTP; Tue, 07 Dec 2004 17:52:44 +0000
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 2004 17:52:41 +0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Attribute Certificate Tool
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear All

we have just released our latest X.509 PMI tool, the Attribute 
Certificate Manager. It can be downloaded from

http://sec.isi.salford.ac.uk/permis/private/wip.html#ACM

Note that you will have to register to get a un and pw first, but the 
tool is free to use for research and educational purposes.

This first version creates X.509 standard ACs, and will store them (add 
them) in your local filestore or an LDAP directory. It can also retrieve 
sample ACs from our publicly available LDAP server. Note that version 1 
does not support revocation of ACs. This will be added to version 2.

All comments about its usefulness, wrinkles or other bugs will be gladly 
received, as well as requests for other features that you might like to 
see added.

regards

David



*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7EHcaO035136; Tue, 7 Dec 2004 06:17:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7EHc7o035126; Tue, 7 Dec 2004 06:17:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7EHbCM034788 for <[e-mail]>; Tue, 7 Dec 2004 06:17:37 -0800 (PST) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iB7EHLw03930; Tue, 7 Dec 2004 15:17:21 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iB7EHKSj013712; Tue, 7 Dec 2004 15:17:21 +0100 (CET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: Peter Sylvester <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: SCVP 16 comments deadline 
In-reply-to: Your message of Tue, 07 Dec 2004 13:14:42 +0100. <[e-mail]> 
Date: Tue, 07 Dec 2004 15:17:20 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I take benefit of this message of my friend Peter to apologize...
I have many comments but I haven't able to send them before the deadline
because of network problems and overloaded phased. I expect to send 
them before the next week.

Regards

[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7CEmoj006796; Tue, 7 Dec 2004 04:14:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7CEmBe006795; Tue, 7 Dec 2004 04:14:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7CEkZv006760 for <[e-mail]>; Tue, 7 Dec 2004 04:14:47 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB7CEkn24503; Tue, 7 Dec 2004 13:14:46 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 7 Dec 2004 13:14:46 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB7CEkb16127; Tue, 7 Dec 2004 13:14:46 +0100 (MET)
Date: Tue, 7 Dec 2004 13:14:46 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To have an independant issue:


4.8 requestorName 
   
  The optional requestorName item is used by the server with signed 
  requests to return the identity of the client in the response.  
  Mechanisms for matching this identifier with the authenticated 
  identity are a matter of local server policy. 
   
  In the case of non-cached responses to signed requests, the SCVP 
  server MUST return a requestor name.  A server SHOULD copy the 
  selected identifier from a certificate or other credential used to 
  authenticate the request.  A SCVP server MAY use a client 
  identifier from an out-of-band mechanism or omit the identifier 
  from the response. 
   
  In the case of cached responses to signed requests, the 
  RequestorName MAY be present in the response. 
   
  SCVP server that supports signed requests MUST support this item.

This chapter is new and pretty uncomprehensible:

"matching" is IMO an action where you have two inputs, I don't see
where the identifier comes from, or when it is extracted from
some authenticated information, why there is a "matching" at all. 
"The identity" of the client is not defined anywhere in the document.

The 3379 text says:

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  

The client has no way to declare its identity in the protocol, 
and there no provision of what this could be from what it would
be derived from (IP address, DNS name of the host, ...), ...

Why is this restricted to signed requests, and not to 'authenticated'?

As already said in another may, this text could make sense if there
would be a corresponding requestorName in the request. 

 
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7CElmH006783; Tue, 7 Dec 2004 04:14:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7CElR6006782; Tue, 7 Dec 2004 04:14:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7CEiMk006751 for <[e-mail]>; Tue, 7 Dec 2004 04:14:45 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB7CEen24487; Tue, 7 Dec 2004 13:14:40 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 7 Dec 2004 13:14:40 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB7CEc216121; Tue, 7 Dec 2004 13:14:38 +0100 (MET)
Date: Tue, 7 Dec 2004 13:14:38 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We have

  Query ::= SEQUENCE { 
   queriedCerts               SEQUENCE SIZE (1..MAX) OF CertReference, 

   ...
   validationPolicy           ValidationPolicy, 

with 
  ValidationPolicy ::= SEQUENCE { 
    ...
    validationAlg         [0] ValidationAlg OPTIONAL, 


3.1.5 validationAlg 
   
  The validationAlg item, defines the validation algorithm to be used 
  by the SCVP server during certificate validation.  The value of 
  this item can be determined by agreement between the client and the 
  server, and is represented as an object identifier.  The server 
  might want to assign additional object identifiers that indicate 
  that some settings are used in addition to others given in the 
  request.  In this way, the validation algorithm object identifier 
  can be a shorthand for some SCVP options, but not others. 
   
  The validationAlg item uses the ValidationAlg type, which has the 
  following syntax: 
   
    ValidationAlg ::= SEQUENCE { 
      valAlgId              OBJECT IDENTIFIER, 
      parameters            ANY DEFINED BY valAlgId OPTIONAL } 


and also


3.1.5.2 validationAlg 
   
  The optional validationAlg item defines the validation algorithm to 
  be used by the SCVP server during certificate validation.  The 
  value of this item can be determined by agreement between the 
  client and the server, and the validation algorithm is represented 
  by an object identifier. 
   
   The syntax of the validationAlg is: 
   
    ValidationAlg ::= SEQUENCE { 
      valAlgId              OBJECT IDENTIFIER, 
      parameters            ANY DEFINED BY valAlgId OPTIONAL } 
   
  The following section specifies the basic validation algorithm and 
  the name validation algorithm.  SCVP clients and servers MUST 
  support both validation algorithms defined in this section.  Other 
  validation algorithms can be specified in other documents for use 
  with specific applications.  SCVP clients and servers MAY support 
  any such validation algorithms.  

---------------

3.1.5.2.3 Name Validation Algorithm 
   
  The name validation algorithm allows the client to supply an 
  application identifier and a name to the server.  The application 
  identifier defines the name matching rules to use in comparing the 
  name supplied in the request with the names in the certificate. 

There may be more than one certificate in the request. 

  
    NameValidationAlgParms ::= SEQUENCE { 
      keyPurposeId      KeyPurposeId, 
      validationNames   GeneralNames } 

What is the relation between the KeyPurposeId and the extendeddkeyusage
3.1.5.10 extendedKeyUsages 

  If the keyPurposeID supplied in the request is id-kp-mailProtection 
  [PKIX-1], then GeneralNames supplied in the request MUST be a 
  rfc822Name, and the matching rules are defined in [SMIME-CERT]. 

'an rfc822Name".

what is the meaning of this if I have more than one email certificate,
i.e. I want to validate all encryption certs before using them. 


Does this means that the validate Algorithm is cert specific and not
request specific? 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7CEk6u006768; Tue, 7 Dec 2004 04:14:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7CEk15006766; Tue, 7 Dec 2004 04:14:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7CEh1t006744 for <[e-mail]>; Tue, 7 Dec 2004 04:14:44 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB7CEhn24495; Tue, 7 Dec 2004 13:14:43 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 7 Dec 2004 13:14:43 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB7CEgW16124; Tue, 7 Dec 2004 13:14:42 +0100 (MET)
Date: Tue, 7 Dec 2004 13:14:42 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There are several boolean values like

  ValidationPolicy ::= SEQUENCE { 
    ...
    inhibitPolicyMapping  [2] BOOLEAN OPTIONAL, 

and a policy definition. 

  ValidationPolValues ::=SEQUENCE  { 
    ...
    inhibitPolMap            BOOLEAN, 


- It would be nice to use the same field names.

- I suggest BOOLEAN DEFAULT FALSE for the inhibitPolMap together
  with some apppropriate tagging, it doesn't make much sense to
  me to code useless values. 

Would it be possible to add some statement about the intended
meaning of the 6 possible combination:


inhibitPolMap = FALSE 

inhibitPolicyMapping absent  1
                     FALSE   2
                     TRUE    3

inhibitPolMap = TRUE 

inhibitPolicyMapping absent  4
                     FALSE   5
                     TRUE    6


Does it mean that when the client value takes preceedence over the
server value? 

1 = FALSE
2 = FALSE
3 = TRUE
4 = TRUE
5 = FALSE
6 = TRUE


It had been said some time ago (as far as I remember) that these
inputs are not global ones but in principle for each of the
certs to be asked for. what was the conclusion why they stay global
for all certs? 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6NiIKE052068; Mon, 6 Dec 2004 15:44:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6NiIB7052067; Mon, 6 Dec 2004 15:44:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6NiHOJ051975 for <[e-mail]>; Mon, 6 Dec 2004 15:44:17 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB6NiIZv076585; Mon, 6 Dec 2004 23:44:19 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041206153655.03099520@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Mon, 06 Dec 2004 15:44:48 -0800
To: "Jong-Hyuk" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: "David Chadwick" <[e-mail]>, <[e-mail]>
In-Reply-To: <008601c4dbd8$15c2bfc0$[e-mail]>
References: <001301c4d82f$d27e1f80$[e-mail]> <[e-mail]> <008601c4dbd8$15c2bfc0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:10 PM 12/6/2004, Jong-Hyuk wrote:
>> This is a neat idea. Are you using the schema we have defined for this
>> attribute aliasing, or have you defined your own? If you are using the
>> schema we have defined in the 3 PKIX IDs, then this would be another
>> good reason for publishing the IDs as Informational. If you have defined
>> your own schema, then it will need to be published widely so that
>> clients that dont support extensible matching (the majority of them)
>> will know which attribute types to use. But I dont think it would be
>> helpful to define a different set of attributes to refer to the same set
>> of X.509 attribute components.
>
>The aliasing feature of OpenLDAP is provided as a mechanism which can work
>out the compatibility issue for the legacy / inflexible clients. However, it
>should not be considered as a mechanism which may potentially encourage the
>use of non-standard schema and access method. We instead need to consider
>the definition of the standardized schema for attribute / matching rule
>aliases in Component Matching.

It should also be noted that as an value extraction compatibility
mechanism, it is not 100% compatible with the value extraction
approach.  For instance, when the client uses a complex value
extraction filter and the entity has multiple certificates.

Kurt 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6MGLCl001829; Mon, 6 Dec 2004 14:16:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6MGLtO001828; Mon, 6 Dec 2004 14:16:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6MGLAw001683 for <[e-mail]>; Mon, 6 Dec 2004 14:16:21 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB6MGJZv075997 for <[e-mail]>; Mon, 6 Dec 2004 22:16:19 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041206140940.03114f30@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Mon, 06 Dec 2004 14:16:49 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: draft-ietf-pkix-ldap-* review notes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Due to the size of my raw review notes, I've placed them
on the web for independent download:
  http://www.openldap.org/ietf/pkix/comments-ietf-pkix-ldap-pkc-schema-01.txt
  http://www.openldap.org/ietf/pkix/comments-ietf-pkix-ldap-ac-schema-02.txt
  http://www.openldap.org/ietf/pkix/comments-ietf-pkix-ldap-crl-schema-03.txt

Regards, Kurt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6LBCWW076595; Mon, 6 Dec 2004 13:11:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6LBCpA076594; Mon, 6 Dec 2004 13:11:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6LB7kW076524 for <[e-mail]>; Mon, 6 Dec 2004 13:11:08 -0800 (PST) (envelope-from [e-mail])
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iB6LB0jd259960 for <[e-mail]>; Mon, 6 Dec 2004 16:11:00 -0500
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB6LB0Xm213818 for <[e-mail]>; Mon, 6 Dec 2004 14:11:00 -0700
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB6LAxDR013698 for <[e-mail]>; Mon, 6 Dec 2004 14:10:59 -0700
Received: from CORE (CORE.watson.ibm.com [9.2.219.120]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id iB6LAx0m013604; Mon, 6 Dec 2004 14:10:59 -0700
Message-ID: <008601c4dbd8$15c2bfc0$[e-mail]>
From: "Jong-Hyuk" <[e-mail]>
To: "David Chadwick" <[e-mail]>
Cc: <[e-mail]>
References: <001301c4d82f$d27e1f80$[e-mail]> <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Date: Mon, 6 Dec 2004 16:10:53 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> This is a neat idea. Are you using the schema we have defined for this
> attribute aliasing, or have you defined your own? If you are using the
> schema we have defined in the 3 PKIX IDs, then this would be another
> good reason for publishing the IDs as Informational. If you have defined
> your own schema, then it will need to be published widely so that
> clients that dont support extensible matching (the majority of them)
> will know which attribute types to use. But I dont think it would be
> helpful to define a different set of attributes to refer to the same set
> of X.509 attribute components.

The aliasing feature of OpenLDAP is provided as a mechanism which can work
out the compatibility issue for the legacy / inflexible clients. However, it
should not be considered as a mechanism which may potentially encourage the
use of non-standard schema and access method. We instead need to consider
the definition of the standardized schema for attribute / matching rule
aliases in Component Matching.
- Jong-Hyuk

--------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P.O. Box 218, Yorktown Heights, NY 10598
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6J87if011776; Mon, 6 Dec 2004 11:08:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6J87pv011775; Mon, 6 Dec 2004 11:08:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6J86ZU011765 for <[e-mail]>; Mon, 6 Dec 2004 11:08:06 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id y7so307674rne for <[e-mail]>; Mon, 06 Dec 2004 11:08:09 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=IIK5jItWACOZrj1js7zbVa5HrwNVTw1d8sDI+iOrM6VdaehW51wh2MD/d8jwBTmKZrgsxG6IKbNYpfABoWOKcWXxh4YHDWe+JsreKfra1aIRw0YZnJSuTwmoLilXVvqmGEtPbD/TiKkM8qmEI9xRnao+iVZQiHC3QsB+J9TD738=
Received: by 10.38.104.72 with SMTP id b72mr1074893rnc; Mon, 06 Dec 2004 11:08:05 -0800 (PST)
Received: by 10.38.78.47 with HTTP; Mon, 6 Dec 2004 11:08:04 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 6 Dec 2004 14:08:04 -0500
From: Dan Proietti <[e-mail]>
Reply-To: [e-mail]
To: [e-mail]
Subject: RE: SCVP 16 comments deadline
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, Trevor.  I have a few comments re: default validation policy.

a) Section 1.3 states, "The default policy can be requested for
validation and the client can override any default value in the
request if required.  The default values are also used when processing
requests which reference a validation policy other than the default
one that does not contain the full set of parameters necessary for
validation and the client has also omitted the missing values in the
request." Section 6.14 is also quite clear about this.  However, in
section 3.1.4, the field descriptions for the ValidationPolicy type
imply that a fixed default is used when an OPTIONAL item is not
included.  For instance the description for userPolicySet (section
3.1.5.3) states, "If userPolicySet is not specified, then any-policy
MUST be used."  If section 1.3 still holds, the correct description
should be something like, "If userPolicySet is not specified, then the
value from the default validation policy will be used."  Same goes for
the other ValidationPolicy field descriptions: inhibitPolicyMapping,
requireExplicitPolicy, inhibitAnyPolicy, isCA, keyUsages,
extendedKeyUsages.  If this is indeed the intent.

b) Section 3.1.5.1 is titled "Default Validation Algorithm" but
discusses the default validation policy.  This is very confusing.  I
presume this should be titled "Default Validation Policy" and be
re-located to a sub-section of the validationPolRef description
(3.1.4.1)?

c) Section 3.1.5.2.1 (Basic Validation Algorithm) defines the "meaning
of the default validation algorithm".  This is extremely confusing as
this is the first time this term is mentioned.  I presume "algorithm"
should be changed to "policy" and the remainder of this sub-section
should be merged into the "Default Validation Policy" section?

d) Related to c) above, the second bullet states, "The acceptable
policy set will come from the userPolicySet item.  If no certificate
policies are specified in the userPolicySet item, then the SCVP server
will use any-policy."  What if the server has defined the default
validation policy with a userPolicySet of {1.2.3.4} and the client
requests the default validation policy and does not specify a
userPolicySet override?  Does the server use {1.2.3.4} or
{any-policy}?  Or is it invalid for a server to define a default
validation policy with a userPolicySet other than {any-policy}?

Personally, I think the specification needs to be more concise re:
constructing the actual validation policy based on a) the referenced
policy, b) the explicit overrides, and c) the default policy fallbacks.  An
example with a hypothetical agreed upon validation policy would do it.

Thanks for your time,
Dan Proietti




On Thu, 2 Dec 2004 12:22:31 -0800, Trevor Freeman
<[e-mail]> wrote:
>
>
>
> The deadline communicated at the DC meeting for making comments on SCVP 16
> was Nov 30th which has now passed. I have had only three people send me
> comments to date. SCVP 17 will be closing very shortly so this is the last
> reminder.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6IRIrV083262; Mon, 6 Dec 2004 10:27:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6IRIAA083261; Mon, 6 Dec 2004 10:27:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6IRGXU083234 for <[e-mail]>; Mon, 6 Dec 2004 10:27:17 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB6IRJn12667; Mon, 6 Dec 2004 19:27:19 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 6 Dec 2004 19:27:19 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB6IRIW13226; Mon, 6 Dec 2004 19:27:18 +0100 (MET)
Date: Mon, 6 Dec 2004 19:27:18 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Hi Peter,
> The announcement was made and documented in the SCVP 16 slides. If you
> have any comments on the distribution of the minutes and slides, I
> suggest you take that up with the chairs.

No, there are no slides available. (see below XX) 

> * 
> * The minutes had not been challenged by Trevor.
> * 

You have made a statement about what you might or might not have
presented in the meeting, and you are discriminating people that
were present in the meeting from those who only read the mailing list.

I request you to present your excuses for ignoring mailing list participants
not having the microsoft travel budget possibilities. 

It is not up to other mailing list participants to guess, and you
were certainly able to detect whether the slides were made available
since, and furthermore, if you would really believe that this is
important, you could have announced the date by yourself (unless
you don't want to interfere with the chairmen's work, which you did
by announcing the end of the deadline.

XX: Besides that, I agree with you that not distributing the slides and
refering to them in minutes is not exactly professional work.

I have started some comments. 

Peter
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6I9gWL071139; Mon, 6 Dec 2004 10:09:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6I9gl6071137; Mon, 6 Dec 2004 10:09:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6I9e3X070996 for <[e-mail]>; Mon, 6 Dec 2004 10:09:40 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Mon, 6 Dec 2004 10:09:35 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Mon, 6 Dec 2004 10:09:35 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Mon, 6 Dec 2004 10:09:39 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTbiEbqK5RrEGbPQxKYlVOzV/QhLgANgsgg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 Dec 2004 18:09:35.0210 (UTC) FILETIME=[BE0E64A0:01C4DBBE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB6I9e3X071079
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
The announcement was made and documented in the SCVP 16 slides. If you
have any comments on the distribution of the minutes and slides, I
suggest you take that up with the chairs.
If you have comments on SCVP 16 can you please submit them ASAP as Denis
did.
Thanks
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Monday, December 06, 2004 3:39 AM
* To: Trevor Freeman; [e-mail]
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* Denis and Trevor, >
* > Trevor,
* >
* > > The deadline communicated at the DC meeting for making comments on
* SCVP
* > > 16 was Nov 30th which has now passed. I have had only three people
* send
* > > me comments to date. SCVP 17 will be closing very shortly so this
is
* the
* > > last reminder.
* >
* > Thank for the remainder. I missed the initial announcement.
* What announcement?
* what I can read here is:
* 
* The minutes say (17 nov)
* 
* > SCVP (version 16) - Trevor Freeman (Microsoft)
* 	Lots of changes have been made from v15; many were editorial
* > but also many substantive changes and some new features. Another rev
* > of the document will be needed. We need to ensure that the ASN.1 is
* > correct, once we agree on the functionality, and so we will compile
* > it to verify. Presentation reviewed changes and new features
* > (relative to v15). See slides for additional details.
* 
* The minutes had not been challenged by Trevor.
* 
* I cannot see any announcement on the list about that date. There
* are "no presentation files and no minutes' available in the IETF
* server.
* 
* According to my understanding of how IETF working groups
* function, an announement during a meeting is non-existant
* if not reflected in the mailing list message.
* 
* (It may be that someone filters the content of the imc server for me).
* 
* Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6I9Dlw070417; Mon, 6 Dec 2004 10:09:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6I9D2B070415; Mon, 6 Dec 2004 10:09:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6I9BFq070295 for <[e-mail]>; Mon, 6 Dec 2004 10:09:12 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB6I9Dn12471; Mon, 6 Dec 2004 19:09:13 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 6 Dec 2004 19:09:13 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB6I9DN13166; Mon, 6 Dec 2004 19:09:13 +0100 (MET)
Date: Mon, 6 Dec 2004 19:09:13 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am quite pleased that about the addition
of requestorName in the responsea and that 
the convention of  consecutive null terminated
strings in a requestorRef have been replaced,

But: 

The syntax is GeneralNames. how many ids is the server intended
to extract from a certificate? The subject + all alternate ids?

Why not having this id declared by the client, and the authentication
methods matches against it. ==> Add a corresponding field in the request.
Which is required: 

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

It is an identifer identifying the client and not the request. 

The new text replacing "requestor" in chapter 7 by "requestorRef".

> however, 
>  all of the octets MUST have values other than zero. 
Why? I would find it quite useful to add a 
hash of something local, if at all, the hash of its IP address for example
(for which I can use the Nonce as well).  

  The requestRef item allows the client to associate a response with 
  a request.  The requestNonce provides an alternative mechanism ..

  and you have also the requestorRef. 

The concept of trying to make loop control with values which are explicitely 
defined as not globally unique sounds strange to me.

 "The requestorRef item is also needed 
  to prevent looping in some configurations" 

 "No provisions are 
  made to ensure uniqueness of the requestorRef octet string"

The usefulness of "requestorRef" as an identifier for the request
is pretty weak, since you can have a nonce if it is for each
request. use GeneralName(s) in a requestorName sequence as for the
response. 

page 34:

  The requestorRef and the responder items MUST be included if the request included a 
  requestor item. 

what does this mean? what is the relationship between a requesterRef and responder?  

If I'd be interested in anything identifying the response, then it is
a sequence of identifiers of the servers that have partipated, and some
local ids or "serial number' like thing if I want to go to that server and
asks 'did you really tell this to my friend'.  


Chapter 7: Denis is right that the spec does not describe how relaying is
performed, i.e. how a response is created from a response received from another
server by a 'proxy'. 

 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6I6NVs067282; Mon, 6 Dec 2004 10:06:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6I6N2Y067272; Mon, 6 Dec 2004 10:06:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6I6H8O066990 for <[e-mail]>; Mon, 6 Dec 2004 10:06:22 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Mon, 6 Dec 2004 10:06:05 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Mon, 6 Dec 2004 10:06:05 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 comments deadline
Date: Mon, 6 Dec 2004 10:06:12 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTbfdnnQM8sCGUwQ1+o/ms74r26bAAQE3/A
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 Dec 2004 18:06:05.0169 (UTC) FILETIME=[40DCAE10:01C4DBBE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB6I6M8O067262
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis,
Thanks for these comments. I will replay in detail shortly.
Trevor

* -----Original Message-----
* From: Denis Pinkas [mailto:[e-mail]]
* Sent: Monday, December 06, 2004 2:25 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP 16 comments deadline
* 
* Trevor,
* 
* > The deadline communicated at the DC meeting for making comments on
SCVP
* > 16 was Nov 30th which has now passed. I have had only three people
send
* > me comments to date. SCVP 17 will be closing very shortly so this is
the
* > last reminder.
* 
* Thank for the remainder. I missed the initial announcement.
* My comments are below.
* 
* 
* 1. Typo. There are two IPR statements related to RFC 3668 on the first
* page. Delete one.
* 
* " By submitting this Internet-Draft, I certify that any applicable
*    patent or other IPR claims of which I am aware have been disclosed,
*    or will be disclosed, and any of which I become aware will be
*    disclosed, in accordance with RFC 3668".
* 
* 
* 2. Page 11. Typos. First paragraph on top of the page.
* Replace "signers" by "signer's".
* 
* 
* 3. Page 11. Typo. First paragraph on top of the page. Last sentence.
* Replace "certificate" by "certificates".
* 
* 
* 4. Page 13. Typo. Section 3.1.2 "checks"
* The two following lines are in fact one line:
* 
* Change:
* 
*      - Build a validated certification path to a trust anchor; and
* 
*      - Do revocation status checks on the certification path.
* 
* into:
* 
*      - Build a validated certification path to a trust anchor and
*        do revocation status checks on the certification path.
* 
* 
* 5. Page 15. Typo. Section 3.1.4 validationPolicy
* 
* This is the error left intentionally by the editor to know who read
the
* document. The following sentence is duplicated: " The validationPolicy
* item, defines the validation policy". Please delete one sentence.
* 
* 
* 6. Page 24. Typo. Section 3.1.5.9 keyUsages
* 
* Change "keyUasge" into "keyUsage".
* 
* 
* 7. Page 27. Typo. Section 3.1.8 valididationTime
* Last line of the first paragraph. Change "servers" into "server's"
* 
* 
* 8. Page 32. Typo. Section 3.5 dhPublicKey
* Change: Diffie-Hellamn into Diffie-Hellman.
* 
* 
* 9. Page 32. Typo. Section 3.5 dhPublicKey
* Fifth line. Change "an does" into "and does"
* 
* 
* 10. Page 32. Typo. Section 3.5 dhPublicKey
* Delete: (see section Error! Reference source not found.)
* 
* 
* 11. Page 33. Typo. Section 4. Validation Response
* 
* After the eight items. The following sentence has a grammar problem:
*   "Successful responses are be made when the server has fully complied
*    with the request".
* 
* 
* 12. Page 52. Typo. Section 6 Validation Policy Response
* 
* The second sentence is incorrect. It is:
* The valPolResponse MAY not unique to any valPolRequest, ..."
* 
* Change into:
* "The valPolResponse MAY not be unique to any valPolRequest, ..."
* 
* 
* 13. The abstract does not reflect accurately the content of the
* document.
* "certificate handling" is too vague.
* 
* Proposed abstract:
* 
*    SCVP allows a client to delegate certificate path construction and
*    certificate path validation to a server. The path construction or
*    validation (i.e. making sure that none of the certificates of the
*    path is revoked) is made according to a validation policy which
*    contains one or more trust anchors. It allows to simplify client
*    implementations and to use a set of predefined validation policies.
* 
* 
* 14. Section 1.3
* 
* The text on validation policy is new. There is no concept of "mutually
* agreed" validation policy between the client on the server. The server
* supports a set of validation policies which may or may not fit the
need
* of the client.
* 
* Change the second sentence of section 1.3 which is:
* 
* " In SCVP, a validation policy can be either mutually
*    agreed between client and server, and subsequently referenced in
*    request, or explicitly expressed in the request by passing all of
*    the necessary parameters."
* 
* into:
* 
* " In SCVP, the validation policy to be used by the server can be
either
* fully referenced in the request by the client (and thus no additional
* parameter is necessary), referenced in the request by the client with
* additional parameters or supported by default by the server if the
* client does not reference it."
* 
* 
* 15. Section 1.3. The second paragraph needs to be reworded. Currently,
* it is the following:
* 
* " Policy definitions can be quite long and complex, and some policies
*    may allow for the setting of a few parameters such as a set of
*    trust anchors.  The request can therefore be simplified if these
*    previously agreed policy dependent parameters are referenced in the
*    request by a mutually agreed OBJECT IDENTIFIER (OID) or URL value.
*    The referenced value indicates either a partial or full set of
*    parameters. The client can therefore omit these agreed parameters
*    from the request, only passing any parameters which are not
*    specified by the previously agreed policy.  Therefore in the
*    simplest form, with validation polices which define every parameter
*    necessary, a SCVP request need only contain the certificate to be
*    validated, the validation policy and any run-time parameters for
*    the request".
* 
* Proposed rewording:
* 
* " Policy definitions can be quite long and complex, and some policies
*    may allow for the setting of a few parameters.  The request can
*    therefore be very simple if OBJECT IDENTIFIERS (OIDs) are used to
*    specify both the algorithm to be used and all the associated
*    parameters of the validation policy. The request can be more
complex
*    if the validation policy fixes many of the parameters but allows
the
*    client to specify some of them. When the validation policy defines
*    every parameter necessary, a SCVP request needs only to contain the
*    certificate to be validated, the referenced validation policy and
any
*    run-time parameters for the request. In its simplest form, a SCVP
*    request contains the certificate to be validated and any run-time
*    parameters for the request. In that case the server uses a default
*    validation policy".
* 
* 
* 16. Section 1.3. Paragraph 3.
* 
* The text is missing the fact that at least one validation policy must
* be supported by the server. This is the default policy which is used
* when the client omits to specify it.
* 
* The current text is the following:
* 
*   "SCVP server also publishes its default validation policy settings.
*    The default policy can be requested for validation and the client
*    can override any default value in the request if required.  The
*    default values are also used when processing requests which
*    reference a validation policy other than the default one that does
*    not contain the full set of parameters necessary for validation and
*    the client has also omitted the missing values in the request.
* 
*    Therefore a client can also simplify the request by omitting a
*    parameter from a request if the default value published by the
*    server is acceptable".
* 
* Replace it with:
* 
* " A SCVP server must support a default validation policy which will
*    be used if the client does not specify any in its request. A server
*    publishes the references of the validation policies it supports.
*    When these policies have parameters that may be overridden, the
*    default value for these parameters are communicated by the server
as
*    well. The client can simplify the request by omitting a parameter
*    from a request if the default value published by the server for a
*    given validation policy reference is acceptable. However if there
is
*    a desire to demonstrate to someone else that a specific validation
*    policy with all its parameters has been used, it will need to ask
the
*    server for the inclusion of the full validation policy with all the
*    parameters in the response".
* 
* 
* 17. On top of page 7, the relationship between the validation policy
* and the basic certification path algorithm is not explained. Then in
* section 1.4 The concept of validation algorithm is introduced but its
* relationship with the validation policy is not explained. This is
* confusing.
* 
* Later on when observing the ASN.1 syntax it may be discovered that two
* OIDs are being used:
* 
*   - one for the validation policy (ValidationPolRef) and
*   - one for the validation algorithm (ValidationAlg).
* 
* This is overcomplicated and unnecessary.
* 
* An important simplification is obtained if, as the previous text
* states, there is an OID to defined the validation policy and there may
* be or may not be additional parameters.
* 
* We could then have:
* 
* valPolByOID::= SEQUENCE {
*        valPolId              OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY ValPolId OPTIONAL }
* 
* Specifying a path processing compliant with section 6.1 of RFC 3280
* would be possible (notice however that the text from RFC 3280 is too
* vague to support the case where a CRL is not signed by the CA).
* 
* It would be desirable to be able to communicate easily and in a
* standard way the parameters that may be set in section 6.1 from RFC
* 3280. In addition, key usage should be added to that list.
* 
* The document should then define a bundle of all these previous useful
* parameters and allow for the addition of other parameters.
* 
* It is thus proposed to define an OID for a validation policy compliant
* with section 6.1 of RFC 3280 (some differences with section 6 from
* 3280bis, i.e. adding precision, may be expected)
* 
* It is thus proposed to modify the text starting from :
* 
* " The inputs to the basic certification path processing algorithm
*    used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise"
*    up to the end of section 1.3 with the following:
* 
* "For clients able to specify the parameters of a validation policy, it
* may be useful to define a standard data structure (using a bundle)
able
* to support the parameters of the basic certification path processing
* algorithm defined by in section 6.1.1 from [PKIX-1] :
* 
*   - a set of Trust Anchors (by value or by reference),
*   - the initial Certificate Policy set,
*   - initial Certificate Policy mapping setting,
*   - initial any-Policy setting,
*   - initial explicit Certificate Policy setting.
* 
* as well as :
* 
*    - the usage of the key contained in the certificate (e.g., key
*      encipherment, key agreement, signature)
* 
* This will be done using a bundle which encapsulates all these
* parameters.
* 
* Other application-specific purposes parameters may be added".
* 
* 
* 18. Section 1.4 is about a "Validation Algorithm". Given what was said
* before, the header of this section should be changed. If we make a
* subsection 1.3.1 called "1.3.1. General" for encapsulating the
previous
* text, then we can introduce a new section 1.3.2 called:
* 
* "1.3.2. Validation policy according to section 6.1 of RFC 3280"
* 
* Some of the text present in the current section 1.4 has been used to
* build the new text that is proposed below:
* 
* "1.3.2. Validation policy according to section 6.1 of RFC 3280
* 
*    SCVP defines a specific validation policy which implements the
*    certification path validation algorithm as defined in section 6.1
of
*    [PKIX-1]. This specific validation policy, called "rfc-3280 basic
*    validation policy" uses the parameters defined in the bundle
*    mentioned above.
* 
*    Note that this algorithm does not support in its full generality
the
*    algorithm described in section 6.2 of [PKIX-1] since, when more
than
*    one trust anchor is being defined, all the conditions that are
*    specified apply to all trust anchors, whereas section 6.2 allows to
*    have different conditions for every trust anchor.
* 
*    The rfc-3280 basic validation policy may be the default validation
*    policy supported by the server, but does not need to".
* 
* 
* 19. Section 2 "Protocol Overview"
* 
* In order to allow for interoperability and testing a common protocol
* needs to be supported. It should be defined.
* 
* 
* 20. Section 3 "Validation Request"
* 
* The unsigned request form is not explained and there is a confusion
for
* the signed request which indeed authenticates the client and is thus
* not anonymous. The current text is :
* 
*    "A signed
*    request is used to authenticate the client to the server or to
*    provide an anonymous client integrity over the request-response
*    pair."
* 
* It should be rephrased as:
* 
*    "An unsigned request provides an anonymous client integrity over
*     the request since the hash of the request or the full request is
*     incorporated in the response. A signed request is used to
*     authenticate the client to the server".
* 
* 
* 21. Page 13. Section 3.1.2 "checks"
* 
* The following sentence adds nothing and should be removed:
* 
*    "A server may still choose to
*    perform revocation status checks when performing path construction,
*    although this information cannot be returned to the client."
* 
* 
* 22. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
*      - Proof of revocation status for each certificate in the AC
*         issuer certification path;
* 
* It would be important to refer the section of the RFC which explains
* how to
* check the "revocation status for each certificate in the AC issuer
* certification path".
* 
* 
* 23. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
*    The client can also request a non-cached response to the request by
*    including wantback id-swb-non-cached-resp in the request.
* 
* The default behavior should be the reverse: fresh information is
* provided, unless the client accept cached information. The item should
* be changed into:
* id-swb-cached-resp
* 
* 
* 24. Page 15. Section 3.1.3 "wantBack"
* 
* The text states:
* 
* id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
* 
* It should be mentioned that this item is only possible for DPD.
* 
* 
* 25. Page 16. Section 3.1.4 validationPolicy
* 
* The following sentence is talking of an agreement whereas such
* agreement does not exist. Delete the sentence:
* 
*   "The client and server can optionally agree on a set of parameters
*    which may fully or partially define a validation policy".
* 
* 
* 26. Page 16. Section 3.1.4 validationPolicy
* The text states:
* 
*    "If a partial set of parameters has been agreed upon,
*    then the client supplies a reference to the policy plus whatever
*    parameters are necessary to complete the request in this item.
* 
* This should be replaced with:
* 
*    "If the validation policy does not define all parameters necessary
*    for processing an SCVP request, then the client need to supply
these
*    parameters".
* 
* 27. Page 16. Section 3.1.4 validationPolicy
* 
*    The syntax of the validationPolicy item is defined as:
* 
*    ValidationPolicy ::= SEQUENCE {
*      validationPolRef          ValidationPolRef,
*      validationAlg         [0] ValidationAlg OPTIONAL,
*      userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
*                                  IDENTIFIER OPTIONAL,
*      inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
*      requireExplicitPolicy [3] BOOLEAN OPTIONAL,
*      inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
*      isCA                  [5] BOOLEAN OPTIONAL,
*      trustAnchors          [6] TrustAnchors OPTIONAL,
*      keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
*                                   OPTIONAL,
*      extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}
* 
* 
* This structure is quite odd, because it only allows to pass additional
* parameters as parameters of the validationAlg. Suppressing the
* validationAlg item add adding validationParamExtensions would be a
* simpler and cleaner way.
* 
* Each validation policies uses its own parameters.
* We should have something like :
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* More details follow.
* 
* 
* 28. It is highly debatable if URIs should be supported or not to
* reference a validation policy. URIs are not stable over time and thus
* unless there are dereferenced and a hash value is computed over them,
* it is insecure to use them. There is a discussion in the security
* consideration section, but no warning and no pointer here. If we keep
* them, we should warn the user.
* 
* If the WG should decides that they should be supported (and if the
IESG
* agrees) on page 17, the ASN.1 description should then be:
* 
* ValidationPolicy ::= CHOICE {
*      valPolByOID         [0] ValPolByOID,
*      valPolByURI         [1] ValPolByURI }
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* ValPolByURI ::= SEQUENCE {
*      uri            IA5String,
*      hashAlgo       OBJECT IDENTIFIER,
*      hashValue      OCTET STRING}
* 
* 
* 29. It is proposed to define the following bundle:
* 
* ValidationParamBundle ::= SEQUENCE {
*      certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF OBJECT
*                                    IDENTIFIER OPTIONAL,
*      inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
*      requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
*      inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
*      isCA                      [4] BOOLEAN OPTIONAL,
*      trustAnchors              [5] TrustAnchors OPTIONAL,
*      keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF KeyUsage
*                                    OPTIONAL,
*      extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
*      extensions                [8] EXPLICIT Extensions OPTIONAL }
* 
* Note that userPolicySet" is unclear and has been changed into
* "certificatePolicySet".
* 
* The text would need to be aligned with the new structure and, of
course
* the parameters of the rfc-3280 basic validation policy will simply
* include the bundle above as its parameters.
* 
* It should also be mentioned somewhere in the document that the support
* of the rfc-3280 basic validation policy is not mandatory for
* conformance but, if supported then the bundle needs to be supported.
* 
* 
* 30. Page 17. Section 3.1.5 validationAlg should be deleted.
* 
* 
* 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
* deleted and replaced by a section later on the "rfc-3280 basic
* validation policy", which should have its OID defined under the scvp
* tree for OIDs.
* 
* 
* 32. Page 17. Section 3.1.5.1. Some text of this section might be re-
* sued to build a new section on the rfc-3280 basic validation policy.
* Note that the last sentence at the bottom of page 17, should be
* removed. This sentence is: "The default validation policy MUST use the
* basic validation algorithm". Any default validation policy can be
used.
* 
* 
* 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
* should be as well deleted.
* 
* 
* 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
* 
* This goal of this section seems to introduce an additional test to the
* basic "rfc-3280 basic validation policy". It would come naturally as
an
* extension of ValidationParamBundle, rather than as a parameter of the
* validationAlgo which has been proposed to be removed. The text should
* be modified accordingly.
* 
* 
* 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
* 
*      NameValidationAlgParms ::= SEQUENCE {
*        keyPurposeId      KeyPurposeId,
*        validationNames   GeneralNames }
* 
* This construct is artificial since KeyPurposeId is about the Extended
* Key Usage and has nothing to do with name validation.
* 
* It could indeed be interesting to test the Extended Key Usage
extension
* of a certificate, but this should be supported as an extension of
* ValidationParamBundle. The text should be modified accordingly.
* 
* 
* 36. Page 22. Section 3.1.5.3 userPolicySet
* 
* userPolicySet should be changed everywhere into certificatePolicySet.
* 
* 
* 37. Page 22. Section 3.1.5.3 userPolicySet
* 
* The text has many sentences like:
* 
*    SCVP clients SHOULD support userPolicySet item in requests, and
*    SCVP servers MUST support userPolicySet item in requests.
* 
* These requirements only apply for the rfc-3280 basic validation
policy,
* and this should be clearly mentioned.
* 
* 
* 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
* 
* The text states:
* 
*    By default the server allows policy mapping as
*    part of certification path validation.
* 
* For simplicity, this should be the reverse. Replace with:
* 
*   "By default the server does not perform policy mapping as
*    part of certification path validation. If the client wants the
*    server to support policy mapping, allowPolicyMapping must be set
*    to TRUE in the request".
* 
* 
* 39. Page 24. Section 3.1.5.8 trustAnchors
* 
* The text states:
* 
*   "A certificate reference can be used to identify the
*    trust anchor by certificate hash and optionally a distinguished
*    name with serial number".
* 
* This is not consistent with the ASN.1 definition of PKCReference which
* is:
* 
*    PKCReference ::= CHOICE {
*      cert                   [0] Certificate,
*      pkcRef                 [1] ESSCertID }
* 
* Please correct.
* 
* 
* 40. Page 25. Section 3.1.6 responseRefHash
* 
* The text states:
* 
*    "By default, the server includes a hash
*    of the request in the response.  If the client wants the server to
*    include the full request in the response, responseRefHash is set to
*    FALSE."
* 
* The server shall always include a hash of the request in the response.
* This is an easy way to allow to test the integrity of the request.
* Since the full description of the validation policy may be much longer
* a flag should be used to say that the full validation policy is not
* returned unless requested. It is thus proposed to have instead the
* following:
* 
* "3.1.6.1 fullRequestInResponse
* 
*    The fullRequestInResponse controls if the client wants the server
*    to include the full request in the response. By default,
*    fullRequestInResponse is set to FALSE. If the client wants back
*    the full request then it must set this parameter to TRUE. The main
*    reason a client would request the server to include the full
request
*    in the response is to archive the request-response exchange in a
*    single object.  That is, the client wants to archive a single
object
*    which includes both request and response".
* 
* 
* 41. Page 26. Section 3.1.6.2 responseValidationPolByRef
* 
* This item should be renamed: fullValPolInResponse
* 
* The text should be changed into:
* 
* "The fullValPolInResponse controls whether the response includes the
* identifier of the validation policy with all the parameters that have
* been used by the server, i.e. all the variable parameters independent
* from the fact that there were specified by the client or defaulted if
* not specified. By default, fullValPolInResponse is set to FALSE. If
the
* client wants the full validation policy to be included, then
* fullValPolInResponse is set to TRUE. The main reason a client would
* request the server to include validation policy to be included by
value
* is to archive the request-response exchange in a single object. That
* is, the client wants to archive the CVResponse and have it include
* every aspect of the validation policy."
* 
* The ResponseFlags should be changed as follows:
* 
*    ResponseFlags ::= SEQUENCE {
*      fullRequestInResponse      BOOLEAN DEFAULT FALSE,
*      fullValPolInResponse       BOOLEAN DEFAULT FALSE,
*      signResponse               BOOLEAN DEFAULT TRUE }
* 
* 
* 42. Page 28. Section 3.1.9 intermediateCerts. Minor.
* 
* Change:
* 
*    The optional intermediateCerts item helps the SCVP server create
*    valid certification paths.
* 
* into:
* 
*    The optional intermediateCerts item may help the SCVP server to
* create
*    valid certification paths.
* 
* 43. Page 29. Section 3.1.11. producedAt
* 
* Last sentence. Change:
* 
*    SCVP server SHOULD support the producedAt values in the request.
* 
* into:
* 
*    SCVP server MAY support the producedAt values in the request.
* 
* Reason: cached responses should not need to be implemented in order to
* be compliant with the specification.
* 
* 
* 44. Page 32. Section 3.5 dhPublicKey
* 
* The text states:
* 
*   "For the server to compute the shared
*    secret, it must lean the public values the client generates,
*    therefore the client MUST include this in the request if it uses
*    this mechanism to integrity protect the request-response pair."
* 
* Replace:
* 
* "to integrity protect the request-response pair"
* 
* with :
* 
* "to authenticate and integrity protect the first response and
* authenticate and integrity protect subsequent request-response pairs".
* 
* 45. Page 32. Section 3.6 SCVP Request Authentication
* 
* The text states:
* 
*   "It is a matter of local policy what validation policy is used by
*    the server when validating requests".
* 
* This sentence could be misinterpreted because the word "validating" is
* being used. Change into:
* 
*    It is a matter of local policy what validation policy is used by
*    the server when authentication requests".
* 
* 
* 46. Page 35. Section 4. Validation Response
* 
*    The CVResponse is defined as follows:
* 
*      CVResponse ::= SEQUENCE {
*        cvResponseVersion         cvResponseVersion        INTEGER,
*        policyID                  INTEGER,
*        producedAt                GeneralizedTime,
*        ....
* 
* On the next page the test states:
* 
*   "The policy ID used by the SCVP server when it processed the
request.
*    See section 6.4 for details."
* 
* In section 6.4 the text states:
* 
* "6.4 defaultPolicyID
* 
*    An integer that uniquely represents the version of the default
*    validation policy as represented by the trustAnchors, ..."
* 
* This is not understandable, over-engineering and very complicated.
* Please delete this item.
* 
* 
* 47. Page 35. Section 4. Validation Response
* 
*    The CVResponse contains:
* 
*        requestRef            [1] RequestReference OPTIONAL,
* 
* Remove "OPTIONAL" since it is very beneficial to mandate this item
* since it allows to make sure that the request has not be modified if
* the response is integrity protected. The computation is fast and easy
* and the hash value does not overload the response.
* 
* 
* 48. Page 38. Section 4.5 respValidationPolicy
* 
* The definition of this item is overcomplicated and not tailored to
* support any kind of validation policy.
* 
* If the client does not specify the validation policy or if the client
* specifies a validation policy which has default parameters, then the
* full description of the validation policy shall be given back.
* 
* If the client specifies a validation policy which has no default
* parameters, then the reference and parameters, if any, of the
* validation policy are in the request.
* 
* The full description of the validation policy shall be given back in
* any case, if the fullValPolInResponse Boolean in ResponseFlags is set.
* 
* respValidationPolicy :: = ValidationPolicy
* 
* 
* 
* 49. Page 41. Section 4.6 requestRef
* 
* As stated earlier, requestRef should be mandatory and always be a hash
* of the request.
* 
* In addition a fullRequest OPTIONAL parameter should be added as an
* optional item for CVResponse.
* 
* The full description of the validation policy shall be given back in
* any case, if the fullRequestInResponse Boolean in ResponseFlags is
set.
* 
* Change the text and the syntax accordingly.
* 
* 
* 50. Page 41. Section 4.6 requestRef
* 
* The text states:
* 
*    "The requestRef item allows the client to associate a response with
*    a request"
* 
* This is wrong. This does not protect against a replay.
* 
* Change with:
* 
* "When the response is authenticated, the requestRef item allows the
* client to make sure that the request was not modified in transit".
* 
* 
* 51. Page 41. Section 4.6 requestRef
* 
* The text states:
* 
* " The requestNonce provides an alternative mechanism for
*    matching requests and responses if the client has selected to
*    include a full response."
* 
* This is wrong. This is not an alternative for matching requests and
* responses.
* 
* Replace with:
* 
*   "The requestNonce allows to protect against replay, even if time
* synchronization is not good between the client and the server".
* 
* 
* 52. Page 42. Section 4.6.1 requestHash
* 
* The text states:
* 
* " The requestNonce provides an alternative mechanism for matching
* requests and responses".
* 
* This is wrong. See above. Delete.
* 
* 
* 53. Page 45. Section 4.10.4 replyChecks
* 
* ReplyCheck is defined as:
* 
*      ReplyCheck ::= SEQUENCE {
*        check                      OBJECT IDENTIFIER,
*        status                     INTEGER }
* 
* It should be defined as:
* 
*      ReplyCheck ::= SEQUENCE {
*        check                      OBJECT IDENTIFIER,
*        status                     INTEGER DEFAULT 0}
* 
* 
* 54. Page 46. Section 4.10.4 replyChecks
* 
* The text states
* 
*    "The status value for public key certification path building to a
*    trusted root along with complete status checking, { id-stc 3 }, can
*    be one of the following:
* 
*        0: Good
*        1: Revoked
*        2: Revocation Offline
*        3: Revocation Unavailable
* 
* It is unclear to understand the benefits that a client can have from
* the difference between "Revocation Offline" and "Revocation
* Unavailable". In addition, these wordings do not match the
explanations
* of what there are.
* 
* A much more important response is missing: suspended. Suspended is a
* variation of revoked, but the client then knows it may attempt another
* try later on.
* 
* It is thus suggested to change it into:
* 
*        0: Good
*        1: Revoked
*        2: Suspended
*        3: Revocation info unavailable"
* 
* 
* 55. Page 46. Section 4.10.4 replyChecks
* 
* 
* The same comment applies for the status value for AC issuer
* certification path.
* 
* 
* 56. Page 48. Section 4.10.6 validationAlg
* For reasons given before, delete validationAlg.
* 
* 
* 57. Page 48. Section 4.10.8 nextUpdate
* 
* If CRLs are used, should this field contain the value of the next
* update field for the smallest value of all the CRLs ? What is the real
* benefit of supporting this element besides added complexity ? It is
* suggested to delete that item.
* 
* 
* 58. Page 49. Section 4.11 responseNonce
* 
* The text states:
* 
* "The responseNonce item contains an identifier to binds the request
* to the response."
* 
* This is incorrect. The nonce is to detect replay.
* 
* Change into:
* 
* "The responseNonce item contains a unique number which allows to
detect
* replay".
* 
* 
* 59. Page 51. Section 5 Server Policy Request
* 
* The text states:
* 
*   "A SCVP client uses the valPolRequest item to request the list of
*    validation policies supported by the SCVP server."
* 
* This is not a correct description of what this request is doing. When
* looking at the ASN.1 it is doing much more. So the question is whether
* two requests should be provided or one. In the later case, it is
* important to advertise correctly what the request is doing.
* 
* 
* 60. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
* The first three items are overengineering:
* 
*        vpResponseVersion          INTEGER,
*        maxCVResponseVersion       INTEGER,
*        maxVPResponseVersion       INTEGER,
* 
* Further more they are mandatory. Please delete.
* 
* 
* 61. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
*         defaultPolicyID            INTEGER,
* 
* This item does not make sense. When an OID references a validation
* policy, there is no concept of versioning. Another version will simply
* get another OID (hopefully in the same branch). Please delete.
* 
* 
* 62. Page 52. Section 6 Validation Policy Response
* 
* The ASN.1 of the VPResponse is over-complicated.
* 
*        validationPolices          SEQUENCE OF ValidationPolRef,
*        validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
* 
* validationAlgs is unnecessary. Please delete.
* 
* validationPolicies (not validationPolices) is the main component. See
* below for a full proposal for restructuring VPResponse.
* 
* 
* 63. Page 52. Section 6 Validation Policy Response
* 
*        authPolicies               SEQUENCE OF AuthPolicy,
*        responseTypes              ResponseTypes,
*        dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
* 
* are elements which have nothing to do with the list of validation
* policies, and they are mandatory ! Either group them in one OPTIONAL
* item or define another command to get them.
* 
* 
* 64. Page 52. Section 6 Validation Policy Response
* 
*       defaultPolicyValues        ValidationPolValues,
* 
* This is simply the set of parameters which are related to the rfc-3280
* basic validation policy. This set could be used by other validation
* policies. Please delete.
* 
* 
* 65. Page 52. Section 6 Validation Policy Response
* 
* What follows is a sketch for a proposal for VPResponse.
* 
*     VPResponse ::= SEQUENCE {
*        requestNonce               OCTET STRING      OPTIONAL
*        thisUpdate                 GeneralizedTime,
*        nextUpdate                 GeneralizedTime   OPTIONAL,
*        validationPolicies         SEQUENCE OF ValidationPolicy,
*        serverParams               ServerParams      OPTIONAL }
* 
* 
*     ServerParams ::= SEQUENCE {
*        responseTypes              ResponseTypes,
*        authPolicies           [0] SEQUENCE OF AuthPolicy
OPTIONAL,
*        dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo
OPTIONAL,
*        clockSkew              [2] INTEGER OPTIONAL }
* 
* Note: it is re-called that ValidationPolicy should be redefined as:
* 
* ValidationPolicy ::= CHOICE {
*      valPolByOID         [0] ValPolByOID,
*      valPolByURI         [1] ValPolByURI }
* 
* ValPolByOID  ::= SEQUENCE {
*        valPolgId             OBJECT IDENTIFIER,
*        parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* ValPolByURI ::= SEQUENCE {
*      uri            IA5String,
*      hashAlgo       OBJECT IDENTIFIER,
*      hashValue      OCTET STRING}
* 
* 
* 
* 66. Page 56. Section 7 SCVP Server Relay
* 
* This section is incomplete and lacking explanations. Please explain
how
* relaying is achieved.
* 
* 
* 67. Page 65. Section 9 Security Considerations
* 
* In the second paragraph, there is a discussion about the use of URIs
to
* reference validation policies.
* 
* Firstly, if URIs are going to stay, a pointer to the security
* consideration section should be present in the main body of the
* document.
* 
* Secondly, the text should mention the need for the ability to
* dereference the URI and the need to compute a hash, while the main
body
* of the document should explain the computation of a hash on the
content
* of the URI.
* 
* 
* 68. Page 65. Section 9 Security Considerations
* 
* The text states:
* 
*   "It can also do this by using the Diffie-hellman keys to sign the
* request".
* 
* Replace "sign" by "authenticate".
* 
* END OF COMMENTS
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6HHjUt028926; Mon, 6 Dec 2004 09:17:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6HHjEW028925; Mon, 6 Dec 2004 09:17:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6HHinI028848 for <[e-mail]>; Mon, 6 Dec 2004 09:17:44 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB6HHglC017108 for <[e-mail]>; Mon, 6 Dec 2004 12:17:42 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB6HHgOM280532 for <[e-mail]>; Mon, 6 Dec 2004 12:17:42 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB6HHgZt022331 for <[e-mail]>; Mon, 6 Dec 2004 12:17:42 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB6HHgKn022328; Mon, 6 Dec 2004 12:17:42 -0500
In-Reply-To: <[e-mail]>
To: Andrew Sciberras <[e-mail]>
Cc: [e-mail], "Kurt D. Zeilenga" <[e-mail]>
MIME-Version: 1.0
Subject: Re: Component Matching Performance
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Sang s Lim <[e-mail]>
Date: Mon, 6 Dec 2004 12:17:41 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M3_11102004|November 10, 2004) at 12/06/2004 12:17:41, Serialize complete at 12/06/2004 12:17:41
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I must apologize, I probably should have started a new thread.
>I wasn't questioning the accuracy of your performance testing, my 
>concerns were based around interoperability issues.

Regarding the interoperability issues, you are right. We will update our 
ASN.1 specification in OpenLDAP.

Sang Seok
Regards.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6GRjWJ090191; Mon, 6 Dec 2004 08:27:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6GRj76090190; Mon, 6 Dec 2004 08:27:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6GRjFc090183 for <[e-mail]>; Mon, 6 Dec 2004 08:27:45 -0800 (PST) (envelope-from [e-mail])
Received: by mproxy.gmail.com with SMTP id u33so44884cwc for <[e-mail]>; Mon, 06 Dec 2004 08:27:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:return-path:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qOaR9MkzgZJyYbSrri69x/4kR3tgLU660+cylD8m4MGW1LUke8dcgxtpUzxnB4rKD41U3NfqFuWLbadmVvQdp5TMNH68L+/vClvidbldRA85CK8DUQTnssfX33/WgOoF0xJN3ebuXy6eDwmsvIMpIorZFn9A6ec/koZIHJtRsmA=
Received: by 10.11.100.16 with SMTP id x16mr981442cwb; Mon, 06 Dec 2004 08:27:48 -0800 (PST)
Received: from ?192.168.1.158? ([202.63.62.31]) by smtp.gmail.com with ESMTP id v71sm29934cwb.2004.12.06.08.27.46; Mon, 06 Dec 2004 08:27:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 2004 03:31:11 +1100
From: Andrew Sciberras <[e-mail]>
Organization: eB2Bcom
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-au, en-gb, en
MIME-Version: 1.0
To: Sang s Lim <[e-mail]>
CC: [e-mail], "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: Component Matching Performance
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sang,

Sang s Lim wrote:

>Andrew,
>  
>
>The ASN.1 specification defined in RFC 3280 was used in our experiment. 
>During development, we initially had a separate componentCertificate 
>attribute with an experimental syntax for Component Matching. It was only 
>recently that it was merged to userCertificate. We have yet to reflect 
>this change to the ASN.1 specification in OpenLDAP. Nevertheless, the 
>search was performed without any problem and the experimental result 
>should be valid, because they are equivalent and the component reference 
>used the identifier defined in the ASN.1 specification. Although we need 
>update the ASN.1 specification in OpenLDAP Component Matching to use X.509 
>syntax, the performance results should not be affected by this change.
>
>  
>
I must apologize, I probably should have started a new thread.
I wasn't questioning the accuracy of your performance testing, my 
concerns were based around interoperability issues.

Regards,
Andrew Sciberras.

>Sang Seok
>
>Sang Seok Lim
>IBM T.J Watson Research Center
>Enterprise Linux Group
>[e-mail]
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6GMsvI085806; Mon, 6 Dec 2004 08:22:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6GMrZp085802; Mon, 6 Dec 2004 08:22:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6GMqs6085656 for <[e-mail]>; Mon, 6 Dec 2004 08:22:53 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB6GMoBX029269 for <[e-mail]>; Mon, 6 Dec 2004 11:22:50 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB6GMnOM182324 for <[e-mail]>; Mon, 6 Dec 2004 11:22:49 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB6GMnuc009639 for <[e-mail]>; Mon, 6 Dec 2004 11:22:49 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB6GMnxW009634; Mon, 6 Dec 2004 11:22:49 -0500
In-Reply-To: <[e-mail]>
To: Andrew Sciberras <[e-mail]>
Cc: [e-mail], "Kurt D. Zeilenga" <[e-mail]>
MIME-Version: 1.0
Subject: Re: Component Matching Performance
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Sang s Lim <[e-mail]>
Date: Mon, 6 Dec 2004 11:22:48 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M3_11102004|November 10, 2004) at 12/06/2004 11:22:49, Serialize complete at 12/06/2004 11:22:49
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andrew,

>I haven't used OpenLDAP or explored its Component Matching capabilities 
>yet, so I'm going to take the content of the operation mentioned above 
>literally.
>The mention of 'tbsCertificate' is both surprising and confusing...  The 
>userCertificate attribute within LDAP and X.500 does not have a syntax 
>of Certificate as defined within RFC3280; it has a syntax of Certificate 
>as defined with X.509. This is stated in both RFC2252 and Kurt's 
>individual submission of "LDAP X.509 Certificate Schema" 
>(draft-zeilenga-ldap-x509-00.txt).
>Even though these definitions may be syntactically equivalent, an 
>LDAP/X.500 userCertificate does not have a tbsCertificate component.

The ASN.1 specification defined in RFC 3280 was used in our experiment. 
During development, we initially had a separate componentCertificate 
attribute with an experimental syntax for Component Matching. It was only 
recently that it was merged to userCertificate. We have yet to reflect 
this change to the ASN.1 specification in OpenLDAP. Nevertheless, the 
search was performed without any problem and the experimental result 
should be valid, because they are equivalent and the component reference 
used the identifier defined in the ASN.1 specification. Although we need 
update the ASN.1 specification in OpenLDAP Component Matching to use X.509 
syntax, the performance results should not be affected by this change.

Sang Seok

Sang Seok Lim
IBM T.J Watson Research Center
Enterprise Linux Group
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6BcqqS074595; Mon, 6 Dec 2004 03:38:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6BcqPr074594; Mon, 6 Dec 2004 03:38:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6Bco0V074577 for <[e-mail]>; Mon, 6 Dec 2004 03:38:51 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iB6Bcon07074; Mon, 6 Dec 2004 12:38:50 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 6 Dec 2004 12:38:50 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iB6Bco011946; Mon, 6 Dec 2004 12:38:50 +0100 (MET)
Date: Mon, 6 Dec 2004 12:38:50 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP 16 comments deadline
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis and Trevor, > 
> Trevor,
> 
> > The deadline communicated at the DC meeting for making comments on SCVP 
> > 16 was Nov 30th which has now passed. I have had only three people send 
> > me comments to date. SCVP 17 will be closing very shortly so this is the 
> > last reminder.
> 
> Thank for the remainder. I missed the initial announcement.
What announcement?
what I can read here is: 

The minutes say (17 nov)

> SCVP (version 16) - Trevor Freeman (Microsoft)
	Lots of changes have been made from v15; many were editorial 
> but also many substantive changes and some new features. Another rev 
> of the document will be needed. We need to ensure that the ASN.1 is 
> correct, once we agree on the functionality, and so we will compile 
> it to verify. Presentation reviewed changes and new features 
> (relative to v15). See slides for additional details.

The minutes had not been challenged by Trevor.

I cannot see any announcement on the list about that date. There
are "no presentation files and no minutes' available in the IETF
server. 

According to my understanding of how IETF working groups
function, an announement during a meeting is non-existant 
if not reflected in the mailing list message. 

(It may be that someone filters the content of the imc server for me).

Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6APJuw078292; Mon, 6 Dec 2004 02:25:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6APJBM078290; Mon, 6 Dec 2004 02:25:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6APFVE077975 for <[e-mail]>; Mon, 6 Dec 2004 02:25:16 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA36814; Mon, 6 Dec 2004 11:37:27 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004120611245153:3101 ; Mon, 6 Dec 2004 11:24:51 +0100 
Message-ID: <[e-mail]>
Date: Mon, 06 Dec 2004 11:24:50 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP 16 comments deadline
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 06/12/2004 11:24:51, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 06/12/2004 11:24:57, Serialize complete at 06/12/2004 11:24:57
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB6APJVE078279
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

> The deadline communicated at the DC meeting for making comments on SCVP 
> 16 was Nov 30th which has now passed. I have had only three people send 
> me comments to date. SCVP 17 will be closing very shortly so this is the 
> last reminder.

Thank for the remainder. I missed the initial announcement.
My comments are below.


1. Typo. There are two IPR statements related to RFC 3668 on the first
page. Delete one.

“ By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668”.


2. Page 11. Typos. First paragraph on top of the page.
Replace “signers” by “signer’s”.


3. Page 11. Typo. First paragraph on top of the page. Last sentence.
Replace “certificate” by “certificates”.


4. Page 13. Typo. Section 3.1.2 “checks”
The two following lines are in fact one line:

Change:

     - Build a validated certification path to a trust anchor; and

     - Do revocation status checks on the certification path.

into:

     - Build a validated certification path to a trust anchor and
       do revocation status checks on the certification path.


5. Page 15. Typo. Section 3.1.4 validationPolicy

This is the error left intentionally by the editor to know who read the
document. The following sentence is duplicated: “ The validationPolicy
item, defines the validation policy”. Please delete one sentence.


6. Page 24. Typo. Section 3.1.5.9 keyUsages

Change “keyUasge” into “keyUsage”.


7. Page 27. Typo. Section 3.1.8 valididationTime
Last line of the first paragraph. Change “servers” into “server’s”


8. Page 32. Typo. Section 3.5 dhPublicKey
Change: Diffie-Hellamn into Diffie-Hellman.


9. Page 32. Typo. Section 3.5 dhPublicKey
Fifth line. Change “an does” into “and does”


10. Page 32. Typo. Section 3.5 dhPublicKey
Delete: (see section Error! Reference source not found.)


11. Page 33. Typo. Section 4. Validation Response

After the eight items. The following sentence has a grammar problem:
  “Successful responses are be made when the server has fully complied
   with the request”.


12. Page 52. Typo. Section 6 Validation Policy Response

The second sentence is incorrect. It is:
The valPolResponse MAY not unique to any valPolRequest, …”

Change into:
“The valPolResponse MAY not be unique to any valPolRequest, …”


13. The abstract does not reflect accurately the content of the
document.
“certificate handling” is too vague.

Proposed abstract:

   SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server. The path construction or
   validation (i.e. making sure that none of the certificates of the
   path is revoked) is made according to a validation policy which
   contains one or more trust anchors. It allows to simplify client
   implementations and to use a set of predefined validation policies.


14. Section 1.3

The text on validation policy is new. There is no concept of “mutually
agreed” validation policy between the client on the server. The server
supports a set of validation policies which may or may not fit the need
of the client.

Change the second sentence of section 1.3 which is:

“ In SCVP, a validation policy can be either mutually
   agreed between client and server, and subsequently referenced in
   request, or explicitly expressed in the request by passing all of
   the necessary parameters.”

into:

“ In SCVP, the validation policy to be used by the server can be either
fully referenced in the request by the client (and thus no additional
parameter is necessary), referenced in the request by the client with
additional parameters or supported by default by the server if the
client does not reference it.”


15. Section 1.3. The second paragraph needs to be reworded. Currently,
it is the following:

“ Policy definitions can be quite long and complex, and some policies
   may allow for the setting of a few parameters such as a set of
   trust anchors.  The request can therefore be simplified if these
   previously agreed policy dependent parameters are referenced in the
   request by a mutually agreed OBJECT IDENTIFIER (OID) or URL value.
   The referenced value indicates either a partial or full set of
   parameters. The client can therefore omit these agreed parameters
   from the request, only passing any parameters which are not
   specified by the previously agreed policy.  Therefore in the
   simplest form, with validation polices which define every parameter
   necessary, a SCVP request need only contain the certificate to be
   validated, the validation policy and any run-time parameters for
   the request”.

Proposed rewording:

“ Policy definitions can be quite long and complex, and some policies
   may allow for the setting of a few parameters.  The request can
   therefore be very simple if OBJECT IDENTIFIERS (OIDs) are used to
   specify both the algorithm to be used and all the associated
   parameters of the validation policy. The request can be more complex
   if the validation policy fixes many of the parameters but allows the
   client to specify some of them. When the validation policy defines
   every parameter necessary, a SCVP request needs only to contain the
   certificate to be validated, the referenced validation policy and any
   run-time parameters for the request. In its simplest form, a SCVP
   request contains the certificate to be validated and any run-time
   parameters for the request. In that case the server uses a default
   validation policy”.


16. Section 1.3. Paragraph 3.

The text is missing the fact that at least one validation policy must
be supported by the server. This is the default policy which is used
when the client omits to specify it.

The current text is the following:

  “SCVP server also publishes its default validation policy settings.
   The default policy can be requested for validation and the client
   can override any default value in the request if required.  The
   default values are also used when processing requests which
   reference a validation policy other than the default one that does
   not contain the full set of parameters necessary for validation and
   the client has also omitted the missing values in the request.

   Therefore a client can also simplify the request by omitting a
   parameter from a request if the default value published by the
   server is acceptable”.

Replace it with:

“ A SCVP server must support a default validation policy which will
   be used if the client does not specify any in its request. A server
   publishes the references of the validation policies it supports.
   When these policies have parameters that may be overridden, the
   default value for these parameters are communicated by the server as
   well. The client can simplify the request by omitting a parameter
   from a request if the default value published by the server for a
   given validation policy reference is acceptable. However if there is
   a desire to demonstrate to someone else that a specific validation
   policy with all its parameters has been used, it will need to ask the
   server for the inclusion of the full validation policy with all the
   parameters in the response”.


17. On top of page 7, the relationship between the validation policy
and the basic certification path algorithm is not explained. Then in
section 1.4 The concept of validation algorithm is introduced but its
relationship with the validation policy is not explained. This is
confusing.

Later on when observing the ASN.1 syntax it may be discovered that two
OIDs are being used:

  - one for the validation policy (ValidationPolRef) and
  - one for the validation algorithm (ValidationAlg).

This is overcomplicated and unnecessary.

An important simplification is obtained if, as the previous text
states, there is an OID to defined the validation policy and there may
be or may not be additional parameters.

We could then have:

valPolByOID::= SEQUENCE {
       valPolId              OBJECT IDENTIFIER,
       parameters            ANY DEFINED BY ValPolId OPTIONAL }

Specifying a path processing compliant with section 6.1 of RFC 3280
would be possible (notice however that the text from RFC 3280 is too
vague to support the case where a CRL is not signed by the CA).

It would be desirable to be able to communicate easily and in a
standard way the parameters that may be set in section 6.1 from RFC
3280. In addition, key usage should be added to that list.

The document should then define a bundle of all these previous useful
parameters and allow for the addition of other parameters.

It is thus proposed to define an OID for a validation policy compliant
with section 6.1 of RFC 3280 (some differences with section 6 from
3280bis, i.e. adding precision, may be expected)

It is thus proposed to modify the text starting from :

“ The inputs to the basic certification path processing algorithm
   used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise”
   up to the end of section 1.3 with the following:

“For clients able to specify the parameters of a validation policy, it
may be useful to define a standard data structure (using a bundle) able
to support the parameters of the basic certification path processing
algorithm defined by in section 6.1.1 from [PKIX-1] :

  - a set of Trust Anchors (by value or by reference),
  - the initial Certificate Policy set,
  - initial Certificate Policy mapping setting,
  - initial any-Policy setting,
  - initial explicit Certificate Policy setting.

as well as :

   - the usage of the key contained in the certificate (e.g., key
     encipherment, key agreement, signature)

This will be done using a bundle which encapsulates all these
parameters.

Other application-specific purposes parameters may be added”.


18. Section 1.4 is about a “Validation Algorithm”. Given what was said
before, the header of this section should be changed. If we make a
subsection 1.3.1 called “1.3.1. General” for encapsulating the previous
text, then we can introduce a new section 1.3.2 called:

“1.3.2. Validation policy according to section 6.1 of RFC 3280”

Some of the text present in the current section 1.4 has been used to
build the new text that is proposed below:

“1.3.2. Validation policy according to section 6.1 of RFC 3280

   SCVP defines a specific validation policy which implements the
   certification path validation algorithm as defined in section 6.1 of
   [PKIX-1]. This specific validation policy, called “rfc-3280 basic
   validation policy” uses the parameters defined in the bundle
   mentioned above.

   Note that this algorithm does not support in its full generality the
   algorithm described in section 6.2 of [PKIX-1] since, when more than
   one trust anchor is being defined, all the conditions that are
   specified apply to all trust anchors, whereas section 6.2 allows to
   have different conditions for every trust anchor.

   The rfc-3280 basic validation policy may be the default validation
   policy supported by the server, but does not need to”.


19. Section 2 “Protocol Overview”

In order to allow for interoperability and testing a common protocol
needs to be supported. It should be defined.


20. Section 3 “Validation Request”

The unsigned request form is not explained and there is a confusion for
the signed request which indeed authenticates the client and is thus
not anonymous. The current text is :

   “A signed
   request is used to authenticate the client to the server or to
   provide an anonymous client integrity over the request-response
   pair.”

It should be rephrased as:

   “An unsigned request provides an anonymous client integrity over
    the request since the hash of the request or the full request is
    incorporated in the response. A signed request is used to
    authenticate the client to the server”.


21. Page 13. Section 3.1.2 “checks”

The following sentence adds nothing and should be removed:

   “A server may still choose to
   perform revocation status checks when performing path construction,
   although this information cannot be returned to the client.”


22. Page 15. Section 3.1.3 “wantBack”

The text states:

     - Proof of revocation status for each certificate in the AC
        issuer certification path;

It would be important to refer the section of the RFC which explains
how to
check the “revocation status for each certificate in the AC issuer
certification path”.


23. Page 15. Section 3.1.3 “wantBack”

The text states:

   The client can also request a non-cached response to the request by
   including wantback id-swb-non-cached-resp in the request.

The default behavior should be the reverse: fresh information is
provided, unless the client accept cached information. The item should
be changed into:
id-swb-cached-resp


24. Page 15. Section 3.1.3 “wantBack”

The text states:

id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}

It should be mentioned that this item is only possible for DPD.


25. Page 16. Section 3.1.4 validationPolicy

The following sentence is talking of an agreement whereas such
agreement does not exist. Delete the sentence:

  “The client and server can optionally agree on a set of parameters
   which may fully or partially define a validation policy”.


26. Page 16. Section 3.1.4 validationPolicy
The text states:

   "If a partial set of parameters has been agreed upon,
   then the client supplies a reference to the policy plus whatever
   parameters are necessary to complete the request in this item.

This should be replaced with:

   “If the validation policy does not define all parameters necessary
   for processing an SCVP request, then the client need to supply these
   parameters”.

27. Page 16. Section 3.1.4 validationPolicy

   The syntax of the validationPolicy item is defined as:

   ValidationPolicy ::= SEQUENCE {
     validationPolRef          ValidationPolRef,
     validationAlg         [0] ValidationAlg OPTIONAL,
     userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                 IDENTIFIER OPTIONAL,
     inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
     requireExplicitPolicy [3] BOOLEAN OPTIONAL,
     inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
     isCA                  [5] BOOLEAN OPTIONAL,
     trustAnchors          [6] TrustAnchors OPTIONAL,
     keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
                                  OPTIONAL,
     extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}


This structure is quite odd, because it only allows to pass additional
parameters as parameters of the validationAlg. Suppressing the
validationAlg item add adding validationParamExtensions would be a
simpler and cleaner way.

Each validation policies uses its own parameters.
We should have something like :

ValPolByOID  ::= SEQUENCE {
       valPolgId             OBJECT IDENTIFIER,
       parameters            ANY DEFINED BY valPolId OPTIONAL }

More details follow.


28. It is highly debatable if URIs should be supported or not to
reference a validation policy. URIs are not stable over time and thus
unless there are dereferenced and a hash value is computed over them,
it is insecure to use them. There is a discussion in the security
consideration section, but no warning and no pointer here. If we keep
them, we should warn the user.

If the WG should decides that they should be supported (and if the IESG
agrees) on page 17, the ASN.1 description should then be:

ValidationPolicy ::= CHOICE {
     valPolByOID         [0] ValPolByOID,
     valPolByURI         [1] ValPolByURI }

ValPolByOID  ::= SEQUENCE {
       valPolgId             OBJECT IDENTIFIER,
       parameters            ANY DEFINED BY valPolId OPTIONAL }

ValPolByURI ::= SEQUENCE {
     uri            IA5String,
     hashAlgo       OBJECT IDENTIFIER,
     hashValue      OCTET STRING}


29. It is proposed to define the following bundle:

ValidationParamBundle ::= SEQUENCE {
     certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF OBJECT
                                   IDENTIFIER OPTIONAL,
     inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
     requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
     inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
     isCA                      [4] BOOLEAN OPTIONAL,
     trustAnchors              [5] TrustAnchors OPTIONAL,
     keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF KeyUsage
                                   OPTIONAL,
     extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
     extensions                [8] EXPLICIT Extensions OPTIONAL }

Note that userPolicySet” is unclear and has been changed into
“certificatePolicySet”.

The text would need to be aligned with the new structure and, of course
the parameters of the rfc-3280 basic validation policy will simply
include the bundle above as its parameters.

It should also be mentioned somewhere in the document that the support
of the rfc-3280 basic validation policy is not mandatory for
conformance but, if supported then the bundle needs to be supported.


30. Page 17. Section 3.1.5 validationAlg should be deleted.


31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
deleted and replaced by a section later on the “rfc-3280 basic
validation policy”, which should have its OID defined under the scvp
tree for OIDs.


32. Page 17. Section 3.1.5.1. Some text of this section might be re-
sued to build a new section on the rfc-3280 basic validation policy.
Note that the last sentence at the bottom of page 17, should be
removed. This sentence is: “The default validation policy MUST use the
basic validation algorithm”. Any default validation policy can be used.


33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
should be as well deleted.


34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm

This goal of this section seems to introduce an additional test to the
basic “rfc-3280 basic validation policy”. It would come naturally as an
extension of ValidationParamBundle, rather than as a parameter of the
validationAlgo which has been proposed to be removed. The text should
be modified accordingly.


35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm

     NameValidationAlgParms ::= SEQUENCE {
       keyPurposeId      KeyPurposeId,
       validationNames   GeneralNames }

This construct is artificial since KeyPurposeId is about the Extended
Key Usage and has nothing to do with name validation.

It could indeed be interesting to test the Extended Key Usage extension
of a certificate, but this should be supported as an extension of
ValidationParamBundle. The text should be modified accordingly.


36. Page 22. Section 3.1.5.3 userPolicySet

userPolicySet should be changed everywhere into certificatePolicySet.


37. Page 22. Section 3.1.5.3 userPolicySet

The text has many sentences like:

   SCVP clients SHOULD support userPolicySet item in requests, and
   SCVP servers MUST support userPolicySet item in requests.

These requirements only apply for the rfc-3280 basic validation policy,
and this should be clearly mentioned.


38. Page 22. Section 3.1.5.4 inhibitPolicyMapping

The text states:

   By default the server allows policy mapping as
   part of certification path validation.

For simplicity, this should be the reverse. Replace with:

  “By default the server does not perform policy mapping as
   part of certification path validation. If the client wants the
   server to support policy mapping, allowPolicyMapping must be set
   to TRUE in the request”.


39. Page 24. Section 3.1.5.8 trustAnchors

The text states:

  “A certificate reference can be used to identify the
   trust anchor by certificate hash and optionally a distinguished
   name with serial number”.

This is not consistent with the ASN.1 definition of PKCReference which
is:

   PKCReference ::= CHOICE {
     cert                   [0] Certificate,
     pkcRef                 [1] ESSCertID }

Please correct.


40. Page 25. Section 3.1.6 responseRefHash

The text states:

   “By default, the server includes a hash
   of the request in the response.  If the client wants the server to
   include the full request in the response, responseRefHash is set to
   FALSE.”

The server shall always include a hash of the request in the response.
This is an easy way to allow to test the integrity of the request.
Since the full description of the validation policy may be much longer
a flag should be used to say that the full validation policy is not
returned unless requested. It is thus proposed to have instead the
following:

“3.1.6.1 fullRequestInResponse

   The fullRequestInResponse controls if the client wants the server
   to include the full request in the response. By default,
   fullRequestInResponse is set to FALSE. If the client wants back
   the full request then it must set this parameter to TRUE. The main
   reason a client would request the server to include the full request
   in the response is to archive the request-response exchange in a
   single object.  That is, the client wants to archive a single object
   which includes both request and response”.


41. Page 26. Section 3.1.6.2 responseValidationPolByRef

This item should be renamed: fullValPolInResponse

The text should be changed into:

“The fullValPolInResponse controls whether the response includes the
identifier of the validation policy with all the parameters that have
been used by the server, i.e. all the variable parameters independent
from the fact that there were specified by the client or defaulted if
not specified. By default, fullValPolInResponse is set to FALSE. If the
client wants the full validation policy to be included, then
fullValPolInResponse is set to TRUE. The main reason a client would
request the server to include validation policy to be included by value
is to archive the request-response exchange in a single object. That
is, the client wants to archive the CVResponse and have it include
every aspect of the validation policy.”

The ResponseFlags should be changed as follows:

   ResponseFlags ::= SEQUENCE {
     fullRequestInResponse      BOOLEAN DEFAULT FALSE,
     fullValPolInResponse       BOOLEAN DEFAULT FALSE,
     signResponse               BOOLEAN DEFAULT TRUE }


42. Page 28. Section 3.1.9 intermediateCerts. Minor.

Change:

   The optional intermediateCerts item helps the SCVP server create
   valid certification paths.

into:

   The optional intermediateCerts item may help the SCVP server to
create
   valid certification paths.

43. Page 29. Section 3.1.11. producedAt

Last sentence. Change:

   SCVP server SHOULD support the producedAt values in the request.

into:

   SCVP server MAY support the producedAt values in the request.

Reason: cached responses should not need to be implemented in order to
be compliant with the specification.


44. Page 32. Section 3.5 dhPublicKey

The text states:

  “For the server to compute the shared
   secret, it must lean the public values the client generates,
   therefore the client MUST include this in the request if it uses
   this mechanism to integrity protect the request-response pair.”

Replace:

“to integrity protect the request-response pair”

with :

“to authenticate and integrity protect the first response and
authenticate and integrity protect subsequent request-response pairs”.

45. Page 32. Section 3.6 SCVP Request Authentication

The text states:

  “It is a matter of local policy what validation policy is used by
   the server when validating requests”.

This sentence could be misinterpreted because the word “validating” is
being used. Change into:

   It is a matter of local policy what validation policy is used by
   the server when authentication requests”.


46. Page 35. Section 4. Validation Response

   The CVResponse is defined as follows:

     CVResponse ::= SEQUENCE {
       cvResponseVersion         cvResponseVersion        INTEGER,
       policyID                  INTEGER,
       producedAt                GeneralizedTime,
       ....

On the next page the test states:

  “The policy ID used by the SCVP server when it processed the request.
   See section 6.4 for details.”

In section 6.4 the text states:

“6.4 defaultPolicyID

   An integer that uniquely represents the version of the default
   validation policy as represented by the trustAnchors, …”

This is not understandable, over-engineering and very complicated.
Please delete this item.


47. Page 35. Section 4. Validation Response

   The CVResponse contains:

       requestRef            [1] RequestReference OPTIONAL,

Remove “OPTIONAL” since it is very beneficial to mandate this item
since it allows to make sure that the request has not be modified if
the response is integrity protected. The computation is fast and easy
and the hash value does not overload the response.


48. Page 38. Section 4.5 respValidationPolicy

The definition of this item is overcomplicated and not tailored to
support any kind of validation policy.

If the client does not specify the validation policy or if the client
specifies a validation policy which has default parameters, then the
full description of the validation policy shall be given back.

If the client specifies a validation policy which has no default
parameters, then the reference and parameters, if any, of the
validation policy are in the request.

The full description of the validation policy shall be given back in
any case, if the fullValPolInResponse Boolean in ResponseFlags is set.

respValidationPolicy :: = ValidationPolicy



49. Page 41. Section 4.6 requestRef

As stated earlier, requestRef should be mandatory and always be a hash
of the request.

In addition a fullRequest OPTIONAL parameter should be added as an
optional item for CVResponse.

The full description of the validation policy shall be given back in
any case, if the fullRequestInResponse Boolean in ResponseFlags is set.

Change the text and the syntax accordingly.


50. Page 41. Section 4.6 requestRef

The text states:

   “The requestRef item allows the client to associate a response with
   a request”

This is wrong. This does not protect against a replay.

Change with:

“When the response is authenticated, the requestRef item allows the
client to make sure that the request was not modified in transit”.


51. Page 41. Section 4.6 requestRef

The text states:

“ The requestNonce provides an alternative mechanism for
   matching requests and responses if the client has selected to
   include a full response.”

This is wrong. This is not an alternative for matching requests and
responses.

Replace with:

  “The requestNonce allows to protect against replay, even if time
synchronization is not good between the client and the server”.


52. Page 42. Section 4.6.1 requestHash

The text states:

“ The requestNonce provides an alternative mechanism for matching
requests and responses”.

This is wrong. See above. Delete.


53. Page 45. Section 4.10.4 replyChecks

ReplyCheck is defined as:

     ReplyCheck ::= SEQUENCE {
       check                      OBJECT IDENTIFIER,
       status                     INTEGER }

It should be defined as:

     ReplyCheck ::= SEQUENCE {
       check                      OBJECT IDENTIFIER,
       status                     INTEGER DEFAULT 0}


54. Page 46. Section 4.10.4 replyChecks

The text states

   “The status value for public key certification path building to a
   trusted root along with complete status checking, { id-stc 3 }, can
   be one of the following:

       0: Good
       1: Revoked
       2: Revocation Offline
       3: Revocation Unavailable

It is unclear to understand the benefits that a client can have from
the difference between “Revocation Offline” and “Revocation
Unavailable”. In addition, these wordings do not match the explanations
of what there are.

A much more important response is missing: suspended. Suspended is a
variation of revoked, but the client then knows it may attempt another
try later on.

It is thus suggested to change it into:

       0: Good
       1: Revoked
       2: Suspended
       3: Revocation info unavailable”


55. Page 46. Section 4.10.4 replyChecks


The same comment applies for the status value for AC issuer
certification path.


56. Page 48. Section 4.10.6 validationAlg
For reasons given before, delete validationAlg.


57. Page 48. Section 4.10.8 nextUpdate

If CRLs are used, should this field contain the value of the next
update field for the smallest value of all the CRLs ? What is the real
benefit of supporting this element besides added complexity ? It is
suggested to delete that item.


58. Page 49. Section 4.11 responseNonce

The text states:

“The responseNonce item contains an identifier to binds the request
to the response.”

This is incorrect. The nonce is to detect replay.

Change into:

“The responseNonce item contains a unique number which allows to detect
replay”.


59. Page 51. Section 5 Server Policy Request

The text states:

  “A SCVP client uses the valPolRequest item to request the list of
   validation policies supported by the SCVP server.”

This is not a correct description of what this request is doing. When
looking at the ASN.1 it is doing much more. So the question is whether
two requests should be provided or one. In the later case, it is
important to advertise correctly what the request is doing.


60. Page 52. Section 6 Validation Policy Response

The ASN.1 of the VPResponse is over-complicated.

The first three items are overengineering:

       vpResponseVersion          INTEGER,
       maxCVResponseVersion       INTEGER,
       maxVPResponseVersion       INTEGER,

Further more they are mandatory. Please delete.


61. Page 52. Section 6 Validation Policy Response

The ASN.1 of the VPResponse is over-complicated.

        defaultPolicyID            INTEGER,

This item does not make sense. When an OID references a validation
policy, there is no concept of versioning. Another version will simply
get another OID (hopefully in the same branch). Please delete.


62. Page 52. Section 6 Validation Policy Response

The ASN.1 of the VPResponse is over-complicated.

       validationPolices          SEQUENCE OF ValidationPolRef,
       validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,

validationAlgs is unnecessary. Please delete.

validationPolicies (not validationPolices) is the main component. See
below for a full proposal for restructuring VPResponse.


63. Page 52. Section 6 Validation Policy Response

       authPolicies               SEQUENCE OF AuthPolicy,
       responseTypes              ResponseTypes,
       dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,

are elements which have nothing to do with the list of validation
policies, and they are mandatory ! Either group them in one OPTIONAL
item or define another command to get them.


64. Page 52. Section 6 Validation Policy Response

      defaultPolicyValues        ValidationPolValues,

This is simply the set of parameters which are related to the rfc-3280
basic validation policy. This set could be used by other validation
policies. Please delete.


65. Page 52. Section 6 Validation Policy Response

What follows is a sketch for a proposal for VPResponse.

    VPResponse ::= SEQUENCE {
       requestNonce               OCTET STRING      OPTIONAL
       thisUpdate                 GeneralizedTime,
       nextUpdate                 GeneralizedTime   OPTIONAL,
       validationPolicies         SEQUENCE OF ValidationPolicy,
       serverParams               ServerParams      OPTIONAL }


    ServerParams ::= SEQUENCE {
       responseTypes              ResponseTypes,
       authPolicies           [0] SEQUENCE OF AuthPolicy      OPTIONAL,
       dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo OPTIONAL,
       clockSkew              [2] INTEGER OPTIONAL }

Note: it is re-called that ValidationPolicy should be redefined as:

ValidationPolicy ::= CHOICE {
     valPolByOID         [0] ValPolByOID,
     valPolByURI         [1] ValPolByURI }

ValPolByOID  ::= SEQUENCE {
       valPolgId             OBJECT IDENTIFIER,
       parameters            ANY DEFINED BY valPolId OPTIONAL }

ValPolByURI ::= SEQUENCE {
     uri            IA5String,
     hashAlgo       OBJECT IDENTIFIER,
     hashValue      OCTET STRING}



66. Page 56. Section 7 SCVP Server Relay

This section is incomplete and lacking explanations. Please explain how
relaying is achieved.


67. Page 65. Section 9 Security Considerations

In the second paragraph, there is a discussion about the use of URIs to
reference validation policies.

Firstly, if URIs are going to stay, a pointer to the security
consideration section should be present in the main body of the
document.

Secondly, the text should mention the need for the ability to
dereference the URI and the need to compute a hash, while the main body
of the document should explain the computation of a hash on the content
of the URI.


68. Page 65. Section 9 Security Considerations

The text states:

  “It can also do this by using the Diffie-hellman keys to sign the
request”.

Replace “sign” by “authenticate”.

END OF COMMENTS






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB685Ydq095985; Mon, 6 Dec 2004 00:05:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB685YoR095984; Mon, 6 Dec 2004 00:05:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB685RXF095784 for <[e-mail]>; Mon, 6 Dec 2004 00:05:32 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iB685DNf027592; Mon, 6 Dec 2004 16:05:13 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iB685DsO023938; Mon, 6 Dec 2004 16:05:13 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iB685CZG023869; Mon, 6 Dec 2004 16:05:12 +0800
Message-ID: <007601c4db6a$4f6c2400$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "alan" <[e-mail]>, "ietf-pkix " <[e-mail]>
References: <[e-mail]> <p06200700bdd997a17603@[10.20.30.249]>
Subject: Re: What's mean about "bis" in the 2510bis?
Date: Mon, 6 Dec 2004 16:05:11 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In the following web pages, you can find more detail explanations
about the meaning of "bis":

http://www.groupstudy.com/archives/cisco/200107/msg01264.html

http://www.cs.columbia.edu/sip/faq/index.php?sid=231127&aktion=artikel&rubrik=001&id=8&lang=en

"bis" is the latin adverb for "two". That is why "bis" is used in ID
naming to indicate that it a revision of an existing RFC.


Wen-Cheng Wang


----- Original Message ----- 
From: "Paul Hoffman / VPNC" <[e-mail]>
To: "alan" <[e-mail]>; "ietf-pkix " <[e-mail]>
Sent: Monday, December 06, 2004 12:59 PM
Subject: Re: What's mean about "bis" in the 2510bis?


> 
> At 11:01 AM +0800 12/6/04, alan wrote:
> >       I usually found some "bis" in the IETF,such as 
> >draft-ietf-pkix-rfc2510bis.
> >       Who can tell me what's mean about "bis"?Thanks!
> 
>  From a future version of the Tao of the IETF:
> 
>     There are some informal rules for Internet Draft naming that have
>     evolved over the years.  Internet Drafts that revise existing RFCs
>     often have draft names with "bis" in them, meaning "the thing after
>     the RFC"; for example, a draft might be called
>     "draft-someone-rfc2345bis-00.txt".
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB64xcZV048574; Sun, 5 Dec 2004 20:59:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB64xbYl048559; Sun, 5 Dec 2004 20:59:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB64xYrU048370; Sun, 5 Dec 2004 20:59:36 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06200700bdd997a17603@[10.20.30.249]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 5 Dec 2004 20:59:37 -0800
To: "alan" <[e-mail]>, "ietf-pkix " <[e-mail]>
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: What's mean about "bis" in the 2510bis?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:01 AM +0800 12/6/04, alan wrote:
>       I usually found some "bis" in the IETF,such as 
>draft-ietf-pkix-rfc2510bis.
>       Who can tell me what's mean about "bis"?Thanks!

 From a future version of the Tao of the IETF:

    There are some informal rules for Internet Draft naming that have
    evolved over the years.  Internet Drafts that revise existing RFCs
    often have draft names with "bis" in them, meaning "the thing after
    the RFC"; for example, a draft might be called
    "draft-someone-rfc2345bis-00.txt".

--Paul Hoffman, Director
--VPN Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB63CKxp010208; Sun, 5 Dec 2004 19:12:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB63CK1F010202; Sun, 5 Dec 2004 19:12:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.243]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB63CKoV010160 for <[e-mail]>; Sun, 5 Dec 2004 19:12:20 -0800 (PST) (envelope-from [e-mail])
Received: by mproxy.gmail.com with SMTP id w67so23916cwb for <[e-mail]>; Sun, 05 Dec 2004 19:12:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:return-path:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KH63WXN3T2uYtHskqh1OQooKVShwVIt208Y2j/pCRbkwIsDWx5cp6TpKd+J6Xvst4ptTGBaOf7mwhfJL9qk4xopd7DL0hVMcOOkZ7+JPyfoZzmSo6kR+UdFNr5U4XK4cLKnfwoDfL2WFZNgjAtTfVDFDR4GMnxxukE5TC+CDdfg=
Received: by 10.11.119.19 with SMTP id r19mr201273cwc; Sun, 05 Dec 2004 19:12:25 -0800 (PST)
Received: from ?192.168.1.158? ([202.63.62.31]) by smtp.gmail.com with ESMTP id p77sm4849cwc.2004.12.05.19.12.24; Sun, 05 Dec 2004 19:12:25 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Dec 2004 14:15:43 +1100
From: Andrew Sciberras <[e-mail]>
Organization: eB2Bcom
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-au, en-gb, en
MIME-Version: 1.0
To: [e-mail]
CC: Sang s Lim <[e-mail]>, "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: Component Matching Performance
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Sang s Lim wrote:

>Directory
>        - 100,000 entry DIT
>        - Each entry is a person entry with one userCertificate attribute
>        - Operations: Random searches on tbsCertificate.serialNumber 
>(serialNumber in userCertificate)
>        - Indexing: tbsCertificate.serialNumber
>
>
>  
>

I haven't used OpenLDAP or explored its Component Matching capabilities 
yet, so I'm going to take the content of the operation mentioned above 
literally.
The mention of 'tbsCertificate' is both surprising and confusing...  The 
userCertificate attribute within LDAP and X.500 does not have a syntax 
of Certificate as defined within RFC3280; it has a syntax of Certificate 
as defined with X.509. This is stated in both RFC2252 and Kurt's 
individual submission of "LDAP X.509 Certificate Schema" 
(draft-zeilenga-ldap-x509-00.txt).
Even though these definitions may be syntactically equivalent, an 
LDAP/X.500 userCertificate does not have a tbsCertificate component.

It is my opinion that the component tbsCertificate should not be used 
within an LDAP search for the userCertificate attribute and in doing so 
should result in zero entries being returned.


Regards,
Andrew Sciberras
eB2Bcom

>Sang Seok Lim
>
>IBM T.J Watson Research Center
>Enterprise Linux Group
>[e-mail]
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6325si089890; Sun, 5 Dec 2004 19:02:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6325DP089889; Sun, 5 Dec 2004 19:02:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hotmail.com (bay24-dav11.bay24.hotmail.com [64.4.18.191]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6324Rq089693 for <[e-mail]>; Sun, 5 Dec 2004 19:02:04 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 5 Dec 2004 19:02:03 -0800
Message-ID: <[e-mail]>
Received: from 202.196.53.253 by BAY24-DAV11.phx.gbl with DAV; Mon, 06 Dec 2004 03:01:01 +0000
X-Originating-IP: [202.196.53.253]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
Date: Mon, 6 Dec 2004 11:01:23 +0800
From: "alan" <[e-mail]>
To: "ietf-pkix " <[e-mail]>
Subject: What's mean about "bis" in the 2510bis?
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Dec 2004 03:02:03.0842 (UTC) FILETIME=[F6830220:01C4DB3F]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

      I usually found some "bis" in the IETF,such as draft-ietf-pkix-rfc2510bis.
      Who can tell me what's mean about "bis"?Thanks!

alan,



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB60wxGv025938; Sun, 5 Dec 2004 16:58:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB60wxFx025936; Sun, 5 Dec 2004 16:58:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.241]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB60wgq7025366 for <[e-mail]>; Sun, 5 Dec 2004 16:58:42 -0800 (PST) (envelope-from [e-mail])
Received: by mproxy.gmail.com with SMTP id q44so37890cwc for <[e-mail]>; Sun, 05 Dec 2004 16:58:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:return-path:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZRApPpzmUI3y/C2eFEXED1hmSJkmMF/LirMvH2VBcHnSdoi3VQQRHUxEp6wjzL4bUCVXVAQ6Ayd10DO44goPOHpDZl/fxU+FqRasokGlKWJC4Yi/qWbQvf/g7F1m+725XO1JN9Fn6NJFHkuTcLvci85MeT/wzBMY0nLMrCiMM7A=
Received: by 10.11.94.56 with SMTP id r56mr939773cwb; Sun, 05 Dec 2004 16:58:45 -0800 (PST)
Received: from ?192.168.1.158? ([202.63.62.31]) by smtp.gmail.com with ESMTP id o9sm9008cwc.2004.12.05.16.58.42; Sun, 05 Dec 2004 16:58:45 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Dec 2004 12:01:51 +1100
From: Andrew Sciberras <[e-mail]>
Organization: eB2Bcom
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-au, en-gb, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: Steven Legg <[e-mail]>, Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

G'Day David,

David Chadwick wrote:

>>
>> Incidentally, yesterday a colleague of mine configured a third-party
>> LDAP client with no built-in knowledge of component matching to use
>> component matches in its filters. No re-coding was necessary. Any client
>> that is configured with LDAP filters in string format or LDAP URLs is
>> already able to use component matching or the X.509 matching rules.
>
>
> Could your colleague send us the string that he had to type in e.g. to 
> find a certificate containing a particular email address or key usage


What Steven was referring to was an activity that I conducted with the 
Calendra Directory Manager. One of the things that this application can 
do is provide user's with different view's to the directory based on who 
they are. The 'who' can be determined dynamically by the application 
based on an ldap search filter.
So, using your suggestion (i.e Email Address) suppose I want to group 
people with an email address that equals "[e-mail]". The email 
address in this case is the email address within the rfc822Name within a 
subjectAltName extension.

The search filter that I used is:

(userCertificate:componentFilterMatch:=item:{ component 
"toBeSigned.extensions.*.extnValue.content.(2.5.29.17).*.rfc822Name", 
rule caseIgnoreIA5Match, value "[e-mail]"})


A better example however is centered around the Mozilla Address book. In 
my address book I can configure a number of different instances of the 
same directory.  With Mozilla, your directory configuration has an 
Advanced setting where you can specify an ldap filter that will be added 
to any searches that you make on the directory.
So, I have a single View500 directory that contains information about 
people. In my Mozilla application I can create the following address 
book instances of the directory:

1.
Title "All Entries"
Filter: objectClass=*
Purpose: I will use this "address book" to attempt to match against 
every entry in the directory

2.
Title "Cert v3 People"
Filter: (userCertificate:componentFilterMatch:=item:{ component 
"toBeSigned.version",  rule integerMatch, value 2})
Purpose: Only search for people that have a Version 3 certificate.

3.
Title "Certificates with a KeyUsage Extension"
Filter: (userCertificate:componentFilterMatch:=item:{ component 
"toBeSigned.extensions.*.extnValue.content.(2.5.29.15)", rule 
presentMatch, value NULL})
Purpose: This is simply here to illustrate the usage of the presentMatch 
and how it can be applied to single out specific extensions.

4.
Title "Certificates of people from COMPANY"
Filter: (userCertificate:componentFilterMatch:=item:{ component 
"toBeSigned.subject.rdnSequence.*", rule rdnMatch, value "O=COMPANY"})
Purpose: To only search for people with certificates whose subject 
indicates that they belong to an Organization called COMPANY


These filters should work against an LDAP Directory that supports 
Component Matching (I've only used View500) with the current build of 
Mozilla. The filters above are simply 4 examples of, what is 
essentially, an infinite amount of filters that can be applied to any 
component of any ASN.1 type used as a syntax of an attribute.

Cheers,
Andrew Sciberras

>
> thanks
>
> David
>
>>
>> Regards,
>> Steven
>>
>>
>>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB42Bavj025196; Fri, 3 Dec 2004 18:11:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB42BaXX025191; Fri, 3 Dec 2004 18:11:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB42BZfi025009 for <[e-mail]>; Fri, 3 Dec 2004 18:11:35 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB42BaGW022461 for <[e-mail]>; Fri, 3 Dec 2004 21:11:36 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB42BZet274652 for <[e-mail]>; Fri, 3 Dec 2004 21:11:35 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB42BZ3x004706 for <[e-mail]>; Fri, 3 Dec 2004 21:11:35 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB42BZpQ004701 for <[e-mail]>; Fri, 3 Dec 2004 21:11:35 -0500
To: [e-mail]
MIME-Version: 1.0
Subject: Component Matching Performance
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Sang s Lim <[e-mail]>
Date: Fri, 3 Dec 2004 21:11:34 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M3_11102004|November 10, 2004) at 12/03/2004 21:11:35, Serialize complete at 12/03/2004 21:11:35
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Attached is a preliminary performance numbers of Component Matching. We 
compared the performance of Component Matching and the existing 
certificateExactMatch implementation of OpenLDAP which utilizes openssl 
certificate decoder. We were able to use the DirectoryMark benchmarking 
tool for Component Matching because DirectoryMark clients naturally 
support component matching without modification.

Experimental platform
        - Server: IBM BladeCenter blade node with 2x2.4G HT Xeon, Linux 
Kernel 2.4.20
        - Client: IBM BladeCenter blade node with 2x2.4G HT Xeon, Windows 
2000
        - Network: 1Gbps Ethernet
 
Directory
        - 100,000 entry DIT
        - Each entry is a person entry with one userCertificate attribute
        - Operations: Random searches on tbsCertificate.serialNumber 
(serialNumber in userCertificate)
        - Indexing: tbsCertificate.serialNumber

Result (average of 3 runs)
        - Component Matching: 
                - Throughput: 3273.66 ops/sec
                - Max latency: 20ms
        - certificateExactMatch in OpenLDAP
                - Throughput: 3674.73 ops/sec
                - Max latency: 18ms
 
The performance numbers show that the overhead of Component Matching is 
around 10% which we attribute to the component filter parsing overhead. 
However, we expect that Component Matching performs on par with the custom 
openssl matching when the attribute aliasing mechanism is used in 
Component Matching because this will eliminate the additional component 
filter parsing steps.

Sang Seok Lim

IBM T.J Watson Research Center
Enterprise Linux Group
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3MYgUm023964; Fri, 3 Dec 2004 14:34:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3MYgu7023963; Fri, 3 Dec 2004 14:34:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3MYZBR023315 for <[e-mail]>; Fri, 3 Dec 2004 14:34:36 -0800 (PST) (envelope-from [e-mail])
Received: from trilmail.funk.com ([192.168.21.75]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6GVYRJ; Fri, 3 Dec 2004 17:33:55 -0500
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJKX90N2; Fri, 3 Dec 2004 17:34:21 -0500
Message-ID: <[e-mail]>
Date: Fri, 03 Dec 2004 17:34:13 -0500
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

I'm talking about CertificateAssertion, not
CertificateExactAssertion. The former allows
matching by issuer, subject, subjectAltName,
and several other useful fields. The latter
only allows matching on issuer and serial
number. Of course, you must know all about
this if you invented them both. But I want
to be clear about what I was talking about.

With respect to your argument that all clients
support your schema without code changes, not
all clients do a full subtree search. Some just
retrieve the certificates directly from the user's
or CA's directory entry. Yes, you can work around
the problem by storing the certificates in both
the old and the new location but that has all
the consistency problems that have been described
elsewhere.

Thanks,

Steve

David Chadwick wrote:
> 
> 
> Steve Hanna wrote:
> 
>>
>> David,
>>
>> Thanks for providing some information on server
>> support for your schema and for component matching.
>> I would like to mention that component matching
>> is not the only server-side solution. X.509 and
>> draft-zeilenga-ldap-x509-00.txt (the successor
>> to RFC 2587) include a CertificateAssertion that
>> should be easy to implement on the server side.
> 
> 
> Steve
> 
> I believe that this matching rule and assertion was first provided by 
> myself in "Additional LDAP Schema for PKIs and PMIs" 
> <draft-pkix-ldap-schema-00.txt> in July 2000. And the exact match was 
> implemented shortly afterwards in OpenLDAP. So exact certificate 
> matching is not difficult. It is when you want to match on arbitrary 
> certificate contents that it gets difficult.
> 
> All LDAP clients that allow configuration of the attributes to be 
> searched for support attribute extraction
> 
> regards
> 
> David
> 
> 
>>
>> You say that "all clients can naturally support
>> [your schema] without any code change". This isn't
>> true. 
> 
> 
> Sorry, but it is. In your argument below you forget two things. Firstly 
> when searching for an entry you do NOT know the DN of the entry 
> (otherwise a full subtree search is not needed, and a pseudo-read 
> [search base entry only] is used). Thus is makes no difference where the 
> certificate is located with a full search. Secondly, by storing the 
> certificate in both places, which is specifically allowed for, then both 
> sets of clients can be supported ie. ones that know where to read, and 
> ones that dont.
> 
> 
> 
> 
>  >
> Any client that tries to retrieve certificates
> 
>> from an LDAP directory will need to look in a
>> different location. If the client doesn't know
>> which schema is in use (which will often happen
>> since clients are rarely configured with schema
>> information), it must look in both places.
>> Maybe you mean that clients don't need to change
>> if the certificates are stored in both locations,
>> but this is only a transitional situation.
>>
>> So I would say it's more accurate to say that
>> clients must change for your solution but need
>> not change for the CertificateAssertion or
>> component matching solutions. Could you tell me
>> about any clients that support your solution?
>> I believe it's true that there are many more
>> client applications than server applications
>> so it will be much more difficult to change
>> the clients than the servers.
>>
>> Thanks,
>>
>> Steve
>>
>> David Chadwick wrote:
>>
>>> Steve
>>>
>>> we have had the meeting at IETF 56 and the majority agreed that 
>>> component matching was the best long term solution to aim for. That 
>>> is on the record. But also on the record is the note that vendors 
>>> appear to be reluctant to support this, and that support for 
>>> attribute extraction is a short term pragmatic solution that is much 
>>> easier for suppliers and users to support. It does not add complexity 
>>> to clients, on the contrary it makes it easier for clients. 
>>> Consequently the ADs agreed that component matching should be 
>>> published as Information RFCs.
>>>
>>> Since that time (Spring 2003) suppliers have not moved that far (if 
>>> at all) towards supporting component matching. Only Steven Legg's 
>>> Australian company, which had supported component matching prior to 
>>> publication of the RFCs, and OpenLDAP which I believe can now support 
>>> it, have done anything in this direction. Attribute extraction on the 
>>> other hand has double that amount of supporting implementations, plus 
>>> all clients can naturally support it without any code change.
>>>
>>> So whilst we might all like the ideal today, pragmatically we need to 
>>> recognise that this is not the situation on the ground today. If it 
>>> were I would happily forget the attribute extraction IDs. My main 
>>> desire is that we need to provide LDAP support to X.509 users today. 
>>> We should recognise that it will be many years before the big LDAP 
>>> suppliers might eventually decide to support component matching. 
>>> After all, there are several very basic features of LDAP that some 
>>> large LDAP suppliers dont yet support, even though they have been 
>>> standardised for over 10 years. As several well known people have 
>>> already said, LDAP has not done a good job at supporting PKI. So why 
>>> believe things will miraculously change overnight with component 
>>> matching. Be realistic, it wont. Unless of course Stefan Santesson 
>>> can now stand up for his supplier and tell us when they will support 
>>> component matching. That would indeed be very encouraging to us all.
>>>
>>> thanks
>>>
>>> David
>>>
>>>
>>> Steve Hanna wrote:
>>>
>>>>
>>>> David Chadwick wrote:
>>>>  > what ever happened to the concept of let a thousand flowers bloom?
>>>>
>>>> Standards work is not about "let a thousand flowers bloom".
>>>> It's about agreeing on standards that will help systems
>>>> interoperate and work well together. From my analysis,
>>>> your proposals do not provide substantial benefit and
>>>> they do add substantial complexity. I don't think that
>>>> the Internet community will be well served by publishing
>>>> these documents. They will only increase confusion for
>>>> implementors and add complexity for directory clients,
>>>> which will now need to support several directory schemas.
>>>>
>>>> In a separate email, David wrote:
>>>>
>>>>> At no time to my knowledge was it suggested that this work be removed
>>>>> from the PKIX set of IDs, otherwise why would they have continued 
>>>>> to be
>>>>> published with PKIX IDs instead of individual IDs for more than a year
>>>>> after the meeting. And why would I have continued to report on their
>>>>> progress at PKIX meetings?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> At IETF 56, there was a discussion about whether to move
>>>> to your proposed schemas (at that time, an independent
>>>> submission) or stick with the current schema and use
>>>> component matching to solve the problem. I raised concerns
>>>> about your proposal at that meeting. As noted in the meeting
>>>> minutes, a straw poll favored component matching but it was
>>>> agreed to take this discussion to the mailing list. I never
>>>> saw any discussion on the mailing list.
>>>>
>>>> At IETF 57, it was explained that the question had been
>>>> decided in favor of your schema (with no discussion
>>>> on the email list). I sent an email to the PKIX list
>>>> complaining about this and reiterating my concerns about
>>>> your proposal. Sharon Boeyen sent email supporting my
>>>> concerns. Nobody sent email favoring the proposals.
>>>>
>>>> Now these documents are in Working Group Last Call.
>>>> I have seen several emails from experienced PKI and
>>>> directory folks raising concerns about your proposal
>>>> and little email supporting it. I think it's clear
>>>> there's no WG consensus in favor of your proposals.
>>>> I suspect there never was a consensus in favor of
>>>> them becoming WG drafts. If anything, the consensus
>>>> seems to be that these documents are not representative
>>>> of the IETF's future direction and should only be
>>>> published with an Experimental status and some sort
>>>> of warning.
>>>>
>>>> I'm sorry for any confusion caused by the status of
>>>> your documents as WG drafts. It seems clear to me that
>>>> they should never have received such a status since
>>>> there was never rough consensus in the PKIX WG about
>>>> taking them on as work items. However, it is better to
>>>> remove this confusion now by publishing them as
>>>> Experimental with a warning than to expand the confusion
>>>> by publishing them as Informational without a warning.
>>>>
>>>> Thanks,
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>
>>
>>
>>
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3InpPQ016226; Fri, 3 Dec 2004 10:49:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3Inpqr016225; Fri, 3 Dec 2004 10:49:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3Inoba016182 for <[e-mail]>; Fri, 3 Dec 2004 10:49:50 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB3InNZv054328; Fri, 3 Dec 2004 18:49:23 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041203103449.02fc8b78@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 03 Dec 2004 10:49:58 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:46 AM 12/2/2004, David Chadwick wrote:
>I believe that this matching rule and assertion was first provided by myself in "Additional LDAP Schema for PKIs and PMIs" <draft-pkix-ldap-schema-00.txt> in July 2000. And the exact match was implemented shortly afterwards in OpenLDAP. So exact certificate matching is not difficult.

I note that one of your draft says:
   A couple of Internet Drafts [9,10] have been specified,
   but implementation of them is complex.

[9,10] respectively refer to draft-ietf-pkix-ldap-pki-schema
and draft-ietf-pkix-ldap-pmi-schema, which appear
to have replaced draft-ietf-pkix-ldap-schema.

This reflects another problem with these I-Ds, much
of the material doesn't appear to reflect the current
state of works in progress, as well as the current
state of works on the Standards Track.  Some updating
here would be useful.

Kurt 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3IGIA2058784; Fri, 3 Dec 2004 10:16:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3IGI3W058782; Fri, 3 Dec 2004 10:16:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3IGGkE058547 for <[e-mail]>; Fri, 3 Dec 2004 10:16:16 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB3IGEZv054102; Fri, 3 Dec 2004 18:16:14 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041203100708.02e78698@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 03 Dec 2004 10:16:49 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: progression of Component Matching (Was: WG Last Call: Certificate Schema)
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:33 AM 12/2/2004, David Chadwick wrote:
>and that the latter [component matching] never gets past proposed standard. 

Given that we already (within a year of the publication of the
that proposed standard) have two independently developed
server implementations, and a number of independently developed
client implementations, and will likely be able to demonstrate
a high degree of interoperability between them, I have no doubt
that component matching will be progressed to Draft Standard
status once the base LDAP TS does (which, of course, is at
least a year out).

Kurt 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3GlkkC039142; Fri, 3 Dec 2004 08:47:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3GlkJb039141; Fri, 3 Dec 2004 08:47:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3GljoB039026 for <[e-mail]>; Fri, 3 Dec 2004 08:47:45 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB3GlfZv053530; Fri, 3 Dec 2004 16:47:42 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041203081500.02d39e70@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 03 Dec 2004 08:48:16 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: draft-ietf-pkix-ldap-*: security considerations
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <6.1.2.0.0.20041130162830.02e9f3f0@127.0.0.1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:05 AM 12/2/2004, David Chadwick wrote:

>Kurt
>
>data inconsistency could arise because of
>a)bad implementations and
>b) an attack.

Note that draft-ietf-pkix-ldap-pkc says:
>   If certificates are stored redundantly in person entries and in
>   certificate entries below the person entries, maintainers of     
>   repositories MUST make sure that the same certificates are stored in
>   the person entry and the respective certificate entries and keep this
>   consistency. 

I assume "maintainers" here refers to humans maintaining the
repository.  But even if this referred to automated "maintainers",
I would argue that inconsistencies are inherit in the approach.

>I dont believe RFCs address concerns of bad implementations.

Actually, RFCs often do need to concern themselves about bad
implementations.

>In the case of attack, the attributes may not match the stored certificate, so the "wrong" certificate or no certificate could be returned.

You are assuming the client is requesting the return of the
certificate.  The client may merely be matching components
of the certificate, but requesting the return of non-certificate
information.   The existing text does not appear to consider
this case.

>But since only the stored certificate is being requested (the attributes are only used to aid fitering), and this is digitally signed, then it cannot be tampered with without detection.  Providing the client checks that certificate that is returned is the correct one, then all we have is a denial of service attack.

I see no mention of this attack in the documents.

>And this can happen if an attacker modifies any LDAP server, including a component matching one. So the security concerns apply equally well to the component matching implementations, and to LDAP servers that dont support any certificate matching.

Maybe so, but regardless, this document needs to discuss security
issues that are applicable to it.  And, as I noted previously,
because of certain aspects of this particular approach (including
duplication of information), the manner in which these issues
might need to be addressed is not necessarily the same how those
issues are more generally addressed.

>But since this RFC does not address protocol issues,

The document cannot escape discussing relevant protocol issues.
And, I note, some of the issues have more to do with the
model aspects used in this approach than protocol.

>then I dont believe any additional security concerns need be added to it. The concerns should be applied to the base LDAP protocol spec "warning, if the LDAP server is tampered with, the information that is returned in the LDAP protocol may not be that which is required".
>
>regards
>
>David
>
>
>Kurt D. Zeilenga wrote:
>>The security considerations sections of these documents
>>are inadequate and seem to nothing more than echo
>>general security concerns.  Given the nature of the
>>information being stored, I would suspect there would
>>be some significant other considerations.  In particular,
>>I am surprised not to see any discussion (in the security
>>consideration section or elsewhere) on the impact of
>>data inconsistencies between user and certificate objects.
>>Kurt
>>
>
>-- 
>
>*****************************************************************
>
>David W. Chadwick, BSc PhD
>Professor of Information Systems Security
>IS Institute, University of Salford, Salford M5 4WT
>Tel: [phone]  Fax [phone]
>Mobile: [phone]
>Email: [e-mail]
>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>Research Web site: http://sec.isi.salford.ac.uk
>Entrust key validation string: MLJ9-DU5T-HV8J
>PGP Key ID is 0xBC238DE5
>
>*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3C9gpT008852; Fri, 3 Dec 2004 04:09:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3C9gI7008850; Fri, 3 Dec 2004 04:09:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3C9fdh008518 for <[e-mail]>; Fri, 3 Dec 2004 04:09:41 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB3C9aZv051627; Fri, 3 Dec 2004 12:09:36 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041203034524.02f526d0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 03 Dec 2004 04:10:11 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: draft-ietf-pkix-ldap-* consistency issues
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <6.1.2.0.0.20041130155245.02ea1880@127.0.0.1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:14 AM 12/2/2004, David Chadwick wrote:
>I agree that certificates should be stored in the person's entry if that is what clients require or expect. I do not see data redundancy as being a problem do you?

Yes.  Aside from consistency issues (which I will touch on in response to
one of your other posts), there are other concerns.  By duplicating the
data, you are creating separate points of access which must be properly
controlled.  Obviously, the burden (and a significant burden at that)
to duplicate the access controls would fall onto the directory administrator.
It is quite possible, due to aspects of current access facilities, that the
directory administrator will not be easily able to duplicate the access
controls.  For instance, to support value extraction, the administrator
needs to give entry creation rights to entities which previously only
had the right to create values of certificate attributes and, by doing
so, granting more access than desirable.  Or, because other entities
have permission to create entries subordinate to the person entries
(for instance, the person herself might be allowed to create subordinate
entries at will), some of which could contain certificates, these entities
can potentially (intentionally or unintentionally) spoof others into
believing that certificates of subordinate entries belong to superior
entries.

>Its not rocket science but standard database stuff.
>After all, most LDAP servers support single master or multiple master replication. So what is all the fuss about?

These are services provided by and managed by LDAP servers.  The value
extraction approach, by its very nature, is managed by LDAP clients or,
as the pkix-pkc-schema document suggests, managed by the maintainer of
the directory service.

Kurt 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3BcXTx048771; Fri, 3 Dec 2004 03:38:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3BcXZn048769; Fri, 3 Dec 2004 03:38:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3BcWVH048748 for <[e-mail]>; Fri, 3 Dec 2004 03:38:32 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB3BcYZv051509; Fri, 3 Dec 2004 11:38:34 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041203031221.02f3f228@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 03 Dec 2004 03:39:09 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: differences in procedures (Was: draft-ietf-pkix-ldap-*-schema WG LC comments)
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1> <[e-mail]> <6.1.2.0.0.20041129192445.030f2008@127.0.0.1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 09:04 AM 12/2/2004, David Chadwick wrote:
>Finally, once they are published as information RFCs, what is the difference between a WG or individual submission?  Is there a note to say that it is or is not the product of a working group?

It is general practice for the IESG to add a note to individual
submissions to the RFC Editor of this basic form:
   This RFC itself is not a candidate for any level of Internet
   Standard.  The IETF disclaims any knowledge of the fitness of this
   RFC for any purpose, and in particular notes that it has not had
   complete IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion.

Additionally, where an individual submission proposes an alternative to
a standard track approach, the IESG commonly adds additional notes
regarding the applicability of the approaches.

>And since we are at the end of one procedure

These I-Ds are no where near the end of the IETF procedure.

>there is little point in switching horses to another procedure now,
>unless of course you would like to slow down publication (which of course you do)

If I truly wanted to delay publication (which I don't), I would
not have suggested the alternative procedure.  Keeping it in the
WG will be dead slow.

Switching to Individual Submission to RFC Editor procedure would
likely significantly speed up publication.   The IETF process
is much slower, especially in cases where there is significant
contention.

However, I do not recommend Individual Submission because it will
be faster, I recommend it because it is more appropriate given the
significant contention over technical issues.

Regards, Kurt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3BBaYN096253; Fri, 3 Dec 2004 03:11:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3BBaD1096252; Fri, 3 Dec 2004 03:11:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3BBZYK096213 for <[e-mail]>; Fri, 3 Dec 2004 03:11:35 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB3BBXZv051372; Fri, 3 Dec 2004 11:11:33 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041203014801.02f3f228@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 03 Dec 2004 03:12:09 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: draft-ietf-pkix-ldap-*-schema WG LC comments
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1> <[e-mail]> <6.1.2.0.0.20041129192445.030f2008@127.0.0.1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 09:04 AM 12/2/2004, David Chadwick wrote:
>Kurt D. Zeilenga wrote:
>>David,
>>We obviously have different recollections of the prior
>>conversations.  This may in part due to the fact that there
>>were many different conversations involving different
>>participants.  I recall reaching a general consensus (amongst
>>the participants) that these I-D were to progressed to the RFC
>>Editor on an Individual basis as either Informational or
>>Experimental.
>
>Kurt
>
>We obviously have different recollections here.  The IDs have always contained a status note saying they were from the PKIX working group along with a request to send email comments to the PKIX list.  I am sure the PKIX chairs would not have countenanced this 
>or WG time to present them, or the ID names they have had, if they were meant to be individual submissions.

I am sure you meant them to be WG I-Ds.  I am sure that at present
they, in terms of process, are regarded as WG I-D.  You'll note that
I framed my recommendations and comments with this in mind.

However, I doubt that the WG has paid them much mind.  But regardless,
what matters at this time is whether or not the WG believes at present
the document is technical sound and otherwise appropriate to publish.

>On the contrary, by making them WG drafts, we were meant to tease out all the issues that you are raising now during the last call.  So really it would have been more beneficial to everyone if you had said something earlier.

I think I have made evident over the years my general concerns regarding
this approach, and my position that it should not be ordained by the IETF.
Because of the nature of the concerns, no amount of teasing that will
resolve them.

I note that I do have some vague recollection of noting some process concerns
to the chairs in regards to these I-Ds, but I also recollect not wanting to
turn things into a process debate.

>And given that you were acting as a consultant on the project that actually implemented the extraction IDs, you cannot actually plead ignorance of them.

I don't believe I plead ignorance.  I can be regarded as being a consultant
to many projects, even projects which I do not believe are taking the right
approach.  I think I've been vocal regarding my concerns with the value
extraction approach, in the IETF, in the OpenLDAP Project, and in other
projects (such as your TERENA-funded project).

>Could it be that because you have only just recently implemented component matching in OpenLDAP that you are now happy for the attribute extraction IDs to be forgotten, but prior to this, you were happy to have them?

My concerns with the value extraction approach are long standing and
well known.

I will comment to remainder in a separate note.

Kurt 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3B156K082382; Fri, 3 Dec 2004 03:01:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3B15nJ082381; Fri, 3 Dec 2004 03:01:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3B13hK082160 for <[e-mail]>; Fri, 3 Dec 2004 03:01:04 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB3B0wZv051288; Fri, 3 Dec 2004 11:00:58 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041203024442.02fba4b8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 03 Dec 2004 03:01:33 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6.1.2.0.0.20041130072120.03443f28@127.0.0.1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:28 AM 12/2/2004, David Chadwick wrote:
>>In particular, how does this approach providing for matching
>>upon components of the subject (or other) DNs in the certificate?
>
>As you know, distinguished names only support exact matching.

You seem to have missed my point(s).

The purpose of value extraction is to allow the client to match
on components of the certificate.  My point is that is that
the approach fails to allow the client to match on all components
of the certificate.  It only allows the client to match on
extracted components of each of the certificates, and then only
on an separate basis.

(The separate basis part I raised in separate email.)

>Thus if the client does not know the DN of the subject, he would have to do a standard search for this first,

In my example, the client wasn't asking for the return of the subject DN,
it was asking for the return of the entry containing a subject DN
with contained certain components.

>and then use it to find the certificates containing this DN.

In my example, the client was interested in non-certificate
information in the entry representing the entity possessing the
certificate.

>The same for the issuer DN. Perhaps you are arguing for a DN substring matching rule or component matching rule to be added to X.520? 

As Component matching supports DNs, there is no reason to ask for
it.  My point is that the value extraction approach is an
incomplete and problematic solution to matching of components.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37HDWR034391; Thu, 2 Dec 2004 23:17:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB37HDs9034390; Thu, 2 Dec 2004 23:17:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from he203war.uk.vianw.net (he203war.uk.vianw.net [195.102.244.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37HCb6034372 for <[e-mail]>; Thu, 2 Dec 2004 23:17:12 -0800 (PST) (envelope-from [e-mail])
Received: from [195.102.204.63] (helo=[195.102.204.63]) by he203war.uk.vianw.net with esmtp (Exim 4.20) id 1Ca7gf-0001iY-V5; Fri, 03 Dec 2004 07:17:16 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 17:04:15 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-ldap-*-schema WG LC comments
References: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1> <[e-mail]> <6.1.2.0.0.20041129192445.030f2008@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041129192445.030f2008@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt D. Zeilenga wrote:
> David,
> 
> We obviously have different recollections of the prior
> conversations.  This may in part due to the fact that there
> were many different conversations involving different
> participants.  I recall reaching a general consensus (amongst
> the participants) that these I-D were to progressed to the RFC
> Editor on an Individual basis as either Informational or
> Experimental.

Kurt

We obviously have different recollections here. The IDs have always 
contained a status note saying they were from the PKIX working group 
along with a request to send email comments to the PKIX list. I am sure 
the PKIX chairs would not have countenanced this or WG time to present 
them, or the ID names they have had, if they were meant to be individual 
submissions. On the contrary, by making them WG drafts, we were meant to 
tease out all the issues that you are raising now during the last call. 
So really it would have been more beneficial to everyone if you had said 
something earlier. And given that you were acting as a consultant on the 
project that actually implemented the extraction IDs, you cannot 
actually plead ignorance of them. Could it be that because you have only 
just recently implemented component matching in OpenLDAP that you are 
now happy for the attribute extraction IDs to be forgotten, but prior to 
this, you were happy to have them?

Finally, once they are published as information RFCs, what is the 
difference between a WG or individual submission? Is there a note to say 
that it is or is not the product of a working group? Or is the only 
difference in the procedure used to get publication? And since we are at 
the end of one procedure there is little point in switching horses to 
another procedure now, unless of course you would like to slow down 
publication (which of course you do)

regards

David


> 
> Anyways, the reason why I noted my understandings of the prior
> conversations was to lead into my comments regarding IESG notes,
> as well as to serve as a basis for my recommendation that you
> withdraw the I-Ds from WG consideration and take these directly
> to the RFC Editor.  I recommend this approach because I do not
> believe consensus exists to progress as products of this WG,
> or of the IETF.
> 
> Please note that I don't dispute that the documents are
> presently WG documents and that this is a WG LC.  I personally
> don't put any weight in these facts towards the issue of
> whether the WG should or should not progress these documents.
> 
> At 10:51 AM 11/29/2004, David Chadwick wrote:
> 
>>Your objections really do sound like those of someone who is frightened that the component matching approach will not be adopted and that the the current approach will kill it off.
> 
> 
> I believe that component matching will become widely implemented,
> regardless of the proposed extraction approach is published or not.
> However publishing these documents without appropriate caution (which
> I believe they currently do not) they offer an alternative approach
> to standard track approaches, and that these standard track approaches
> should be favored, may not only cause confusion in the community,
> but may lead to interoperability problems.
> 
> 
>>I hope this is not the case, because I would like to see component matching approach ubiquitously supported. However, many people need LDAP search support today for PKIs, and the current approach provides the simplest and quickest fix for this, though as we all agree, not the most elegant.
> 
> 
> The problem with value extraction is that the fix brings far more problems
> than it purports to resolve.  You have completely glossed over the complexity
> this approach pushes onto clients.   Dealing with multiple entries is simply
> not as simple as dealing with one entry.
> 
> 
>>regards
>>
>>David
>>
>>p.s your technical argument below is flawed. People are not the only entities that possess certificates, and so the object class person is not necessary nor required for the search.
> 
> 
> I fully realize that persons are not the only entity that might
> possess a certificate.  My point is that the object representing
> the entity is not returned by the certificate search.
> 
> 
>>The user is only interested in obtaining the certificate containing the subject name with a particular RDN, and the current approach supports this kind of search.
> 
> 
> There are a wide range of applications which need to acquir
> non-certificate information about the user based upon information
> they know about the user's certificate.
> 
> 
> 
>>Kurt D. Zeilenga wrote:
>>
>>>It was my understanding after previous discussions (involving
>>>the authors, chairs, ADs, myself, and others) that these I-Ds
>>>would be individually submitted to the RFC Editor for
>>>consideration.  I am a bit surprised that they are now being
>>>last called in PKIX WG as I was under the impression that the
>>>WG has already reached consensus that these I-Ds would not be
>>>progressed as products of the PKIX WG.
>>>If these had been submitted directly to the RFC Editor, I
>>>would have recommended to the IESG that an "IESG note" be
>>>added to each I-D that clearly stated the I-D was not a
>>>product of the IETF, provided an alternative to a standard
>>>track approach, and that the standard track approach
>>>should be favored by implementors and deployers.
>>>However, as these I-Ds have been submitted to the PKIX WG
>>>for consideration, the PXIX WG must reach consensus that the
>>>I-Ds are technical sound and appropriate for publication as
>>>a products of this WG.  I seriously doubt this WG will now
>>>reach consensus that these I-Ds should be published as
>>>products of the PKIX WG.
>>>I do not believe the value extraction approach to be sound as
>>>it doesn't actually address the key problem: matching against
>>>arbitrary component values of a certificate (or other complex
>>>structures).  For instance, say the application wanted to match
>>>all person objects containing a certificate whose subject DN
>>>contained an RDN containing an AVA with a common name of X.  This
>>>schema simply doesn't support that kind of matching because only
>>>select values of the certificate, some of which are themselves
>>>complex structures, have been extracted AND, even if they had
>>>been, the operation would not find the person object holding
>>>the certificate, but a certificate object.
>>>I believe the existing standard track approach more than
>>>adequately addresses application needs in this area, and that
>>>it can and will be implemented.  Not only are there two
>>>existing implementations today, one is open source (and available
>>>for reuse under non-restrictive terms).  While I cannot speak for
>>>the plans of other vendors, I can say that I have been contacted
>>>by a number of vendors who made it clear to me that they intend
>>>to put implementation of the standard track approach into their
>>>product plans.
>>>Hence, I oppose progression of the I-Ds as products of the PKIX
>>>WG (regardless of track).  I encourage the authors to withdraw
>>>the I-Ds from IETF consideration and to submit them directly to
>>>the RFC Editor for consideration.
>>>I note that I found a number of other issues in the I-Ds.  I will
>>>separately provide the WG with my review notes.
>>>Regards, Kurt
>>
>>-- 
>>
>>*****************************************************************
>>
>>David W. Chadwick, BSc PhD
>>Professor of Information Systems Security
>>IS Institute, University of Salford, Salford M5 4WT
>>Tel: [phone]  Fax [phone]
>>Mobile: [phone]
>>Email: [e-mail]
>>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>>Research Web site: http://sec.isi.salford.ac.uk
>>Entrust key validation string: MLJ9-DU5T-HV8J
>>PGP Key ID is 0xBC238DE5
>>
>>*****************************************************************
> 
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37Gb1u033441; Thu, 2 Dec 2004 23:16:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB37GbZ4033440; Thu, 2 Dec 2004 23:16:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from he204war.uk.vianw.net (he204war.uk.vianw.net [195.102.244.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37Ga43033403 for <[e-mail]>; Thu, 2 Dec 2004 23:16:36 -0800 (PST) (envelope-from [e-mail])
Received: from [195.102.204.63] (helo=[195.102.204.63]) by he204war.uk.vianw.net with esmtp (Exim 4.20) id 1Ca7gH-0007je-IV; Fri, 03 Dec 2004 07:16:42 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 16:46:26 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna wrote:
> 
> David,
> 
> Thanks for providing some information on server
> support for your schema and for component matching.
> I would like to mention that component matching
> is not the only server-side solution. X.509 and
> draft-zeilenga-ldap-x509-00.txt (the successor
> to RFC 2587) include a CertificateAssertion that
> should be easy to implement on the server side.

Steve

I believe that this matching rule and assertion was first provided by 
myself in "Additional LDAP Schema for PKIs and PMIs" 
<draft-pkix-ldap-schema-00.txt> in July 2000. And the exact match was 
implemented shortly afterwards in OpenLDAP. So exact certificate 
matching is not difficult. It is when you want to match on arbitrary 
certificate contents that it gets difficult.

All LDAP clients that allow configuration of the attributes to be 
searched for support attribute extraction

regards

David


> 
> You say that "all clients can naturally support
> [your schema] without any code change". This isn't
> true. 

Sorry, but it is. In your argument below you forget two things. Firstly 
when searching for an entry you do NOT know the DN of the entry 
(otherwise a full subtree search is not needed, and a pseudo-read 
[search base entry only] is used). Thus is makes no difference where the 
certificate is located with a full search. Secondly, by storing the 
certificate in both places, which is specifically allowed for, then both 
sets of clients can be supported ie. ones that know where to read, and 
ones that dont.




 >
Any client that tries to retrieve certificates
> from an LDAP directory will need to look in a
> different location. If the client doesn't know
> which schema is in use (which will often happen
> since clients are rarely configured with schema
> information), it must look in both places.
> Maybe you mean that clients don't need to change
> if the certificates are stored in both locations,
> but this is only a transitional situation.
> 
> So I would say it's more accurate to say that
> clients must change for your solution but need
> not change for the CertificateAssertion or
> component matching solutions. Could you tell me
> about any clients that support your solution?
> I believe it's true that there are many more
> client applications than server applications
> so it will be much more difficult to change
> the clients than the servers.
> 
> Thanks,
> 
> Steve
> 
> David Chadwick wrote:
> 
>> Steve
>>
>> we have had the meeting at IETF 56 and the majority agreed that 
>> component matching was the best long term solution to aim for. That is 
>> on the record. But also on the record is the note that vendors appear 
>> to be reluctant to support this, and that support for attribute 
>> extraction is a short term pragmatic solution that is much easier for 
>> suppliers and users to support. It does not add complexity to clients, 
>> on the contrary it makes it easier for clients. Consequently the ADs 
>> agreed that component matching should be published as Information RFCs.
>>
>> Since that time (Spring 2003) suppliers have not moved that far (if at 
>> all) towards supporting component matching. Only Steven Legg's 
>> Australian company, which had supported component matching prior to 
>> publication of the RFCs, and OpenLDAP which I believe can now support 
>> it, have done anything in this direction. Attribute extraction on the 
>> other hand has double that amount of supporting implementations, plus 
>> all clients can naturally support it without any code change.
>>
>> So whilst we might all like the ideal today, pragmatically we need to 
>> recognise that this is not the situation on the ground today. If it 
>> were I would happily forget the attribute extraction IDs. My main 
>> desire is that we need to provide LDAP support to X.509 users today. 
>> We should recognise that it will be many years before the big LDAP 
>> suppliers might eventually decide to support component matching. After 
>> all, there are several very basic features of LDAP that some large 
>> LDAP suppliers dont yet support, even though they have been 
>> standardised for over 10 years. As several well known people have 
>> already said, LDAP has not done a good job at supporting PKI. So why 
>> believe things will miraculously change overnight with component 
>> matching. Be realistic, it wont. Unless of course Stefan Santesson can 
>> now stand up for his supplier and tell us when they will support 
>> component matching. That would indeed be very encouraging to us all.
>>
>> thanks
>>
>> David
>>
>>
>> Steve Hanna wrote:
>>
>>>
>>> David Chadwick wrote:
>>>  > what ever happened to the concept of let a thousand flowers bloom?
>>>
>>> Standards work is not about "let a thousand flowers bloom".
>>> It's about agreeing on standards that will help systems
>>> interoperate and work well together. From my analysis,
>>> your proposals do not provide substantial benefit and
>>> they do add substantial complexity. I don't think that
>>> the Internet community will be well served by publishing
>>> these documents. They will only increase confusion for
>>> implementors and add complexity for directory clients,
>>> which will now need to support several directory schemas.
>>>
>>> In a separate email, David wrote:
>>>
>>>> At no time to my knowledge was it suggested that this work be removed
>>>> from the PKIX set of IDs, otherwise why would they have continued to be
>>>> published with PKIX IDs instead of individual IDs for more than a year
>>>> after the meeting. And why would I have continued to report on their
>>>> progress at PKIX meetings?
>>>
>>>
>>>
>>>
>>> At IETF 56, there was a discussion about whether to move
>>> to your proposed schemas (at that time, an independent
>>> submission) or stick with the current schema and use
>>> component matching to solve the problem. I raised concerns
>>> about your proposal at that meeting. As noted in the meeting
>>> minutes, a straw poll favored component matching but it was
>>> agreed to take this discussion to the mailing list. I never
>>> saw any discussion on the mailing list.
>>>
>>> At IETF 57, it was explained that the question had been
>>> decided in favor of your schema (with no discussion
>>> on the email list). I sent an email to the PKIX list
>>> complaining about this and reiterating my concerns about
>>> your proposal. Sharon Boeyen sent email supporting my
>>> concerns. Nobody sent email favoring the proposals.
>>>
>>> Now these documents are in Working Group Last Call.
>>> I have seen several emails from experienced PKI and
>>> directory folks raising concerns about your proposal
>>> and little email supporting it. I think it's clear
>>> there's no WG consensus in favor of your proposals.
>>> I suspect there never was a consensus in favor of
>>> them becoming WG drafts. If anything, the consensus
>>> seems to be that these documents are not representative
>>> of the IETF's future direction and should only be
>>> published with an Experimental status and some sort
>>> of warning.
>>>
>>> I'm sorry for any confusion caused by the status of
>>> your documents as WG drafts. It seems clear to me that
>>> they should never have received such a status since
>>> there was never rough consensus in the PKIX WG about
>>> taking them on as work items. However, it is better to
>>> remove this confusion now by publishing them as
>>> Experimental with a warning than to expand the confusion
>>> by publishing them as Informational without a warning.
>>>
>>> Thanks,
>>>
>>> Steve
>>>
>>>
>>>
>>
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37GOxT033117; Thu, 2 Dec 2004 23:16:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB37GOUF033116; Thu, 2 Dec 2004 23:16:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from he201war.uk.vianw.net (he201war.uk.vianw.net [195.102.244.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37GNjH033000 for <[e-mail]>; Thu, 2 Dec 2004 23:16:23 -0800 (PST) (envelope-from [e-mail])
Received: from [195.102.204.63] (helo=[195.102.204.63]) by he201war.uk.vianw.net with esmtp (Exim 4.04) id 1Ca7g1-0005eN-00; Fri, 03 Dec 2004 07:16:25 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 16:33:59 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson wrote:
> David,
> 
> It seems that we all agree that these documents don't represent the
> desired future direction.
> 
> If this is the easy fix solution to overcome temporary shortcomings of
> current implementation of existing standards, then we shouldn't make
> this into a standard, or anything that looks like a standard or guidance
> on future direction.

Stefan

this was agreed at the IETF 56 meeting, which is why we agreed to 
downgrade it to informational. I am happy with experimental either, and 
even more happy to convert it to historical once MS and others support 
component matching. But we also have to consider that the majority of 
suppliers might choose to implement attribute extraction rather than 
component matching and that the latter never gets past proposed 
standard. After all, we technies are not always that good at predicting 
market trends are we?

regards

David



> 
> I lack the discussion and insight on the potential harm that may follow
> from diversity in applications where some decide to go the component
> matching way or do some other tweak to make use of current schema, while
> other implementations chooses the attribute extraction path and creation
> of separate entries for certificates.
> 
> I fear a great mess out of this diversity and it probably won't help us
> get to the target we all seems to agree on.
> 
> I regret not speaking up on this before, but a document can be
> challenged until it has left the WG, and the fact that a document has
> been processed as a WG document is not by itself a guarantee that it
> will be published as one.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of David Chadwick
>>Sent: den 30 november 2004 14:29
>>To: Steve Hanna
>>Cc: Tim Polk; [e-mail]; [e-mail]; [e-mail];
>>[e-mail]
>>Subject: Re: WG Last Call: Certificate Schema
>>
>>
>>Steve
>>
>>we have had the meeting at IETF 56 and the majority agreed that
>>component matching was the best long term solution to aim for. That is
>>on the record. But also on the record is the note that vendors appear
> 
> to
> 
>>be reluctant to support this, and that support for attribute
> 
> extraction
> 
>>is a short term pragmatic solution that is much easier for suppliers
> 
> and
> 
>>users to support. It does not add complexity to clients, on the
> 
> contrary
> 
>>it makes it easier for clients. Consequently the ADs agreed that
>>component matching should be published as Information RFCs.
>>
>>Since that time (Spring 2003) suppliers have not moved that far (if at
>>all) towards supporting component matching. Only Steven Legg's
>>Australian company, which had supported component matching prior to
>>publication of the RFCs, and OpenLDAP which I believe can now support
>>it, have done anything in this direction. Attribute extraction on the
>>other hand has double that amount of supporting implementations, plus
>>all clients can naturally support it without any code change.
>>
>>So whilst we might all like the ideal today, pragmatically we need to
>>recognise that this is not the situation on the ground today. If it
> 
> were
> 
>>I would happily forget the attribute extraction IDs. My main desire is
>>that we need to provide LDAP support to X.509 users today. We should
>>recognise that it will be many years before the big LDAP suppliers
> 
> might
> 
>>eventually decide to support component matching. After all, there are
>>several very basic features of LDAP that some large LDAP suppliers
> 
> dont
> 
>>yet support, even though they have been standardised for over 10
> 
> years.
> 
>>As several well known people have already said, LDAP has not done a
> 
> good
> 
>>job at supporting PKI. So why believe things will miraculously change
>>overnight with component matching. Be realistic, it wont. Unless of
>>course Stefan Santesson can now stand up for his supplier and tell us
>>when they will support component matching. That would indeed be very
>>encouraging to us all.
>>
>>thanks
>>
>>David
>>
>>
>>Steve Hanna wrote:
>>
>>>David Chadwick wrote:
>>> > what ever happened to the concept of let a thousand flowers
> 
> bloom?
> 
>>>Standards work is not about "let a thousand flowers bloom".
>>>It's about agreeing on standards that will help systems
>>>interoperate and work well together. From my analysis,
>>>your proposals do not provide substantial benefit and
>>>they do add substantial complexity. I don't think that
>>>the Internet community will be well served by publishing
>>>these documents. They will only increase confusion for
>>>implementors and add complexity for directory clients,
>>>which will now need to support several directory schemas.
>>>
>>>In a separate email, David wrote:
>>>
>>>
>>>>At no time to my knowledge was it suggested that this work be
> 
> removed
> 
>>>>from the PKIX set of IDs, otherwise why would they have continued
> 
> to be
> 
>>>>published with PKIX IDs instead of individual IDs for more than a
> 
> year
> 
>>>>after the meeting. And why would I have continued to report on
> 
> their
> 
>>>>progress at PKIX meetings?
>>>
>>>
>>>At IETF 56, there was a discussion about whether to move
>>>to your proposed schemas (at that time, an independent
>>>submission) or stick with the current schema and use
>>>component matching to solve the problem. I raised concerns
>>>about your proposal at that meeting. As noted in the meeting
>>>minutes, a straw poll favored component matching but it was
>>>agreed to take this discussion to the mailing list. I never
>>>saw any discussion on the mailing list.
>>>
>>>At IETF 57, it was explained that the question had been
>>>decided in favor of your schema (with no discussion
>>>on the email list). I sent an email to the PKIX list
>>>complaining about this and reiterating my concerns about
>>>your proposal. Sharon Boeyen sent email supporting my
>>>concerns. Nobody sent email favoring the proposals.
>>>
>>>Now these documents are in Working Group Last Call.
>>>I have seen several emails from experienced PKI and
>>>directory folks raising concerns about your proposal
>>>and little email supporting it. I think it's clear
>>>there's no WG consensus in favor of your proposals.
>>>I suspect there never was a consensus in favor of
>>>them becoming WG drafts. If anything, the consensus
>>>seems to be that these documents are not representative
>>>of the IETF's future direction and should only be
>>>published with an Experimental status and some sort
>>>of warning.
>>>
>>>I'm sorry for any confusion caused by the status of
>>>your documents as WG drafts. It seems clear to me that
>>>they should never have received such a status since
>>>there was never rough consensus in the PKIX WG about
>>>taking them on as work items. However, it is better to
>>>remove this confusion now by publishing them as
>>>Experimental with a warning than to expand the confusion
>>>by publishing them as Informational without a warning.
>>>
>>>Thanks,
>>>
>>>Steve
>>>
>>>
>>>
>>
>>--
>>
>>*****************************************************************
>>
>>David W. Chadwick, BSc PhD
>>Professor of Information Systems Security
>>IS Institute, University of Salford, Salford M5 4WT
>>Tel: [phone]  Fax [phone]
>>Mobile: [phone]
>>Email: [e-mail]
>>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>>Research Web site: http://sec.isi.salford.ac.uk
>>Entrust key validation string: MLJ9-DU5T-HV8J
>>PGP Key ID is 0xBC238DE5
>>
>>*****************************************************************
> 
> 
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37G33n032569; Thu, 2 Dec 2004 23:16:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB37G3Ok032567; Thu, 2 Dec 2004 23:16:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from he204war.uk.vianw.net (he204war.uk.vianw.net [195.102.244.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37G2bi032550 for <[e-mail]>; Thu, 2 Dec 2004 23:16:02 -0800 (PST) (envelope-from [e-mail])
Received: from [195.102.204.63] (helo=[195.102.204.63]) by he204war.uk.vianw.net with esmtp (Exim 4.20) id 1Ca7fl-0007iK-92; Fri, 03 Dec 2004 07:16:09 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 16:28:55 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6.1.2.0.0.20041130072120.03443f28@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041130072120.03443f28@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt D. Zeilenga wrote:
> David,
> 
> While there may have been some in this WG that viewed the
> value extraction approach as a pragmatic solution to various
> specific issues, I believe there are also many, like myself,
> who have never considered the value extraction approach, in
> general, to be practical.  

Others take a different view. Take a look at a paper from a recent IEEE 
conference in Portugal this summer "Multi-level trust in e-government 
certification practice" by Amel Meddeb et al, National Digital 
Certification Agency, Tunisia (I can send you a copy if you need it). 
This proposes using the attribute extraction approach to search for 
certificates of a particular trust level.


noted in my previous
> response, I do not consider the value extraction approach
> as applied here to certificates and such to be pragmatic
> as it simply does not address requirements I am faced with.

It does solve all the ones that I and others have been faced with so 
far. Please give me a real use-case example that cant be solved with it 
(ie. not some esoteric dreamt up case that we know it cannot solve)


> 
> In particular, how does this approach providing for matching
> upon components of the subject (or other) DNs in the certificate?

As you know, distinguished names only support exact matching. Thus if 
the client does not know the DN of the subject, he would have to do a 
standard search for this first, and then use it to find the certificates 
containing this DN. The same for the issuer DN. Perhaps you are arguing 
for a DN substring matching rule or component matching rule to be added 
to X.520?

regards

David

-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37Fvok032416; Thu, 2 Dec 2004 23:15:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB37Fv1g032415; Thu, 2 Dec 2004 23:15:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from he203war.uk.vianw.net (he203war.uk.vianw.net [195.102.244.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37FuQ5032370 for <[e-mail]>; Thu, 2 Dec 2004 23:15:57 -0800 (PST) (envelope-from [e-mail])
Received: from [195.102.204.63] (helo=[195.102.204.63]) by he203war.uk.vianw.net with esmtp (Exim 4.20) id 1Ca7ff-0001gh-9P; Fri, 03 Dec 2004 07:16:03 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 16:14:18 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-ldap-* consistency issues
References: <6.1.2.0.0.20041130155245.02ea1880@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041130155245.02ea1880@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt

I agree that certificates should be stored in the person's entry if that 
is what clients require or expect. I do not see data redundancy as being 
a problem do you? Its not rocket science but standard database stuff. 
After all, most LDAP servers support single master or multiple master 
replication. So what is all the fuss about?

I think we should simply water down this text by removing the MUSTs and 
replace it with something like the following (note that people are not 
the only objects to have certificates)

Note. If certificates are stored redundantly in subject entries and in
certificate entries below the subject entries, these obviously should be
consistent.

regards

David



Kurt D. Zeilenga wrote:
> draft-ietf-pkix-ldap-pkc-schema-01 basically proposes to copy certificate
> information from the entries representing the entity which possess the
> certificate to a separate certificate entry.  I consider relocation not to
> be feasible option whatsoever as it will simply break some
> existing clients which use basic certificate matching, as well as
> existing and future clients which makes component matching with
> certificates.  However, the document actually reads as if relocation
> of the information is intended.
> 
> This text causes me concern:
> 
>>  If certificates are stored redundantly in person entries and in      
>>  certificate entries below the person entries, maintainers of
>>  repositories MUST make sure that the same certificates are stored in
>>  the person entry and the respective certificate entries and keep this
>>  consistency.  Alternatively, they MUST leave out any certificates in
>>  the person entry.
> 
> 
> Now, given that maintainers will be hard pressed to ensure
> consistency, this specification has stated that the standard
> track approach of storing certificates in the person entry
> is not to be followed.   This MUST will lead to breakage.
> 
> Instead, this document needs to needs to make it clear that
> certificates will be stored redundantly, there will be
> consistency issues, and then discuss how applications are
> to address these consistency issues.
> 
> Kurt
> 
> PS: I note that these MUSTs appear to apply to users, not to
> implementations... they likely should be downcased.
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37FsdJ032290; Thu, 2 Dec 2004 23:15:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB37Fs2K032289; Thu, 2 Dec 2004 23:15:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from he204war.uk.vianw.net (he204war.uk.vianw.net [195.102.244.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37Fqe0032224 for <[e-mail]>; Thu, 2 Dec 2004 23:15:53 -0800 (PST) (envelope-from [e-mail])
Received: from [195.102.204.63] (helo=[195.102.204.63]) by he204war.uk.vianw.net with esmtp (Exim 4.20) id 1Ca7fQ-0007hg-Hf; Fri, 03 Dec 2004 07:15:59 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 16:05:26 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-ldap-*: security considerations
References: <6.1.2.0.0.20041130162830.02e9f3f0@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041130162830.02e9f3f0@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt

data inconsistency could arise because of
a)bad implementations and
b) an attack.
I dont believe RFCs address concerns of bad implementations. In the case 
of attack, the attributes may not match the stored certificate, so the 
"wrong" certificate or no certificate could be returned. But since only 
the stored certificate is being requested (the attributes are only used 
to aid fitering), and this is digitally signed, then it cannot be 
tampered with without detection. Providing the client checks that 
certificate that is returned is the correct one, then all we have is a 
denial of service attack.  And this can happen if an attacker modifies 
any LDAP server, including a component matching one. So the security 
concerns apply equally well to the component matching implementations, 
and to LDAP servers that dont support any certificate matching.

But since this RFC does not address protocol issues, then I dont believe 
any additional security concerns need be added to it. The concerns 
should be applied to the base LDAP protocol spec "warning, if the LDAP 
server is tampered with, the information that is returned in the LDAP 
protocol may not be that which is required".

regards

David


Kurt D. Zeilenga wrote:
> The security considerations sections of these documents
> are inadequate and seem to nothing more than echo
> general security concerns.  Given the nature of the
> information being stored, I would suspect there would
> be some significant other considerations.  In particular,
> I am surprised not to see any discussion (in the security
> consideration section or elsewhere) on the impact of
> data inconsistencies between user and certificate objects.
> 
> Kurt
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37FqU0032196; Thu, 2 Dec 2004 23:15:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB37Fqdv032193; Thu, 2 Dec 2004 23:15:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from he203war.uk.vianw.net (he203war.uk.vianw.net [195.102.244.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37FjK1032018 for <[e-mail]>; Thu, 2 Dec 2004 23:15:46 -0800 (PST) (envelope-from [e-mail])
Received: from [195.102.204.63] (helo=[195.102.204.63]) by he203war.uk.vianw.net with esmtp (Exim 4.20) id 1Ca7fN-0001fW-2i; Fri, 03 Dec 2004 07:15:45 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 15:54:48 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steven Legg <[e-mail]>
CC: Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steven Legg wrote:
> 
> 
> David,
> 
> David Chadwick wrote:
> 
>> Since that time (Spring 2003) suppliers have not moved that far (if at 
>> all) towards supporting component matching. Only Steven Legg's 
>> Australian company, which had supported component matching prior to 
>> publication of the RFCs, and OpenLDAP which I believe can now support 
>> it, have done anything in this direction. Attribute extraction on the 
>> other hand has double that amount of supporting implementations, plus 
>> all clients can naturally support it without any code change.
> 
> 
> So is that four client implementations that have support for adding and
> modifying entries with certificates according to the attribute extraction
> schema using any LDAP directory, or is that four client implementations
> that depend on the XPS server to do the attribute extraction for them ?
> Isn't there only one XPS(-like) server implementation ? I'm not sure you 
> are
> comparing like with like.

Steven

Peter listed the implementations in an earlier message (which I have now 
deleted) but I believe it was 3 of the former and 1 of the latter (which 
actually equates to a very large number of clients).

> 
> Incidentally, yesterday a colleague of mine configured a third-party
> LDAP client with no built-in knowledge of component matching to use
> component matches in its filters. No re-coding was necessary. Any client
> that is configured with LDAP filters in string format or LDAP URLs is
> already able to use component matching or the X.509 matching rules.

Could your colleague send us the string that he had to type in e.g. to 
find a certificate containing a particular email address or key usage

thanks

David

> 
> Regards,
> Steven
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37Ffvj031972; Thu, 2 Dec 2004 23:15:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB37FfNF031971; Thu, 2 Dec 2004 23:15:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from he204war.uk.vianw.net (he204war.uk.vianw.net [195.102.244.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB37Fext031722 for <[e-mail]>; Thu, 2 Dec 2004 23:15:41 -0800 (PST) (envelope-from [e-mail])
Received: from [195.102.204.63] (helo=[195.102.204.63]) by he204war.uk.vianw.net with esmtp (Exim 4.20) id 1Ca7fG-0007hD-Hj; Fri, 03 Dec 2004 07:15:39 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 15:48:39 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jong-Hyuk <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <001301c4d82f$d27e1f80$[e-mail]>
In-Reply-To: <001301c4d82f$d27e1f80$[e-mail]>
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jong-Hyuk wrote:
>>Since that time (Spring 2003) suppliers have not moved that far (if at
>>all) towards supporting component matching. Only Steven Legg's Australian
>>company, which had supported component matching prior to publication of
>>the RFCs, and OpenLDAP which I believe can now support it, have done
>>anything in this direction. Attribute extraction on the other hand has
>>double that amount of supporting implementations, plus all clients can
>>naturally support it without any code change.
> 
> 
> Clients can be considered to naturally support Component Matching if they
> accept search filters in a text form and they support extensibleMatch. It is
> observed that many clients fall into this category. For those clients who
> have search filters hard-coded and / or do not support extensibleMatch, the
> OpenLDAP implementation of Component Matching further supports attribute and
> matching rule aliases. In attribute aliasing, an alias attribute in the
> search filter is converted by the server into the predefined aliased
> component reference and the assertion value is used as the corresponding
> component assertion value. 

Jong,

This is a neat idea. Are you using the schema we have defined for this
attribute aliasing, or have you defined your own? If you are using the
schema we have defined in the 3 PKIX IDs, then this would be another
good reason for publishing the IDs as Informational. If you have defined
your own schema, then it will need to be published widely so that
clients that dont support extensible matching (the majority of them)
will know which attribute types to use. But I dont think it would be
helpful to define a different set of attributes to refer to the same set
of X.509 attribute components.

regards

David



>The matching rule alias is used in a similar way.
> The aliasing mechanism can also be considered as an optimization which
> eliminates the extra processing steps for ComponentFilter parsing. We will
> provide performance evaluation results of Component Matching to show that it
> can be implemented in LDAP servers without performance degradation and
> increase in complexity.
> - Jong-Hyuk
> 
> ------------------------
> Jong Hyuk Choi
> IBM Thomas J. Watson Research Center - Enterprise Linux Group
> P.O. Box 218, Yorktown Heights, NY 10598
> [e-mail]
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2Ninj1081799; Thu, 2 Dec 2004 15:44:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2NimcJ081798; Thu, 2 Dec 2004 15:44:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2Niko0081573 for <[e-mail]>; Thu, 2 Dec 2004 15:44:46 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: SCVP 16 Comments
Date: Thu, 2 Dec 2004 18:46:55 -0500
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02F7_01C4D89F.4B83B920"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 Comments
Thread-Index: AcTXy0criAKL84HQT7Gfw8ImIST1bgA4mTFgAAbHceA=
From: "Seth Hitchings" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_02F7_01C4D89F.4B83B920
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks Trevor,

For item 4, I believe that support for DH should be optional for the server as well as the
client. If a server doesn't wish to support that form of integrity protection, it
shouldn't have to. Currently, the VPResponse requires support for DH.

Seth 

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]] 
Sent: Thursday, December 02, 2004 3:55 PM
To: Seth Hitchings; [e-mail]
Subject: RE: SCVP 16 Comments

Hi Seth

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Seth Hitchings
* Sent: Wednesday, December 01, 2004 9:29 AM
* To: [e-mail]
* Subject: SCVP 16 Comments
*
* Hi all,
*
* My company, CoreStreet Ltd, is currently developing an implementation of
* SCVP. We've recently updated our software to reflect the
* changes made in draft 16 and have found that there are many ambiguities in
* the specification, both in the ASN.1 module and in the
* descriptions of how various elements are meant to be used.
*
* Given the number of changes that will have to be made to draft 16, I
* wonder if it won't be necessary to permit another round of
* review before submitting the final draft to the RFC editors. I know that
* there is a lot of pressure for draft 17 to be the final
* draft and to get this process completed, but it is in all of our best
* interest that the final draft be as clear and usable as
* possible.
*
* I have sent most of my feedback on draft 16 directly to the editors, but I
* have a few questions that I'd like the entire list
* consider.
*
* 1) The 'check' for building a certification path to a trusted root has
* been removed, implying that an SCVP server can only returns
* paths that meet a local validation policy on the server. In a DPD
* environment, I believe that the client should be able to control
* whether the server performs validation. As such, I would like to see
id-
* stc-build-pkc-path and id-stc-build-aa-path restored in
* draft 17.
*
[TF] Fixed
* 2) The want back for all paths, id-swb-pkc-all-valid-cert-paths, should be
* changed to id-swb-pkc-all-cert-paths. The level of
* validation that is performed on the path is defined by the requested
* checks, not the want back. We don't have a separate want back
* for status checked certification paths.
[TF] OK
*
* 3) The new RespValidationPolicy contains the userFinalPolicySet,
* permittedSubtrees and excludedSubtrees items that result from
* validation. Each unique path that is validated may produce different
* values for these three items but only one value for each item
* may be returned because only one RespValidationPolicy is returned with
* each CVResponse. There are two ways that more than one path
* can be returned in a CVResponse: a single CVRequest can contain more than
* one query certificate, and multiple paths can be returned
* for each query certificate using the new 'want back'
id-swb-pkc-all-valid-
* cert-paths. There is no way for the validation algorithm
* output can be included as the specification is currently written.
[TF] the user final policy set is only for validating CA certificates and there have been
a number of off list comments to back out this feature from 17 which is want I plan to do.
*
* 4) Draft 16 requires SCVP servers to maintain a Diffie-Hellman public key
* for use in authenticated requests. Given that SCVP servers
* are not required to support AuthenticatedData requests and that, in
* general, authentication should be a matter of local server
* policy, I believe that the new DH functionality should be optional for
* SCVP servers.
[TF] The DH key role depends on the client and transport to the server.
The DH key was added to allow anonymous clients to also gain integrity over the
request/response pair where the client is not using a secure transport. Its use is
optional. 
*
* 5) The VPResponse contains a sequence of ValidationPolRef that enumerates
* the set of validation policies supported by the SCVP
* server. However, these validation policies are not defined by value in the
* VPResponse, they are merely listed by OID or URI. I
* believe that there is value in allowing a client to determine the actual
* policy values that are used in each server policy. As such,
* I believe that the type for the validationPolicies item in VPResponse
* should be 'SEQUENCE OF ValidationPolicy'.
[TF] ]The premise for the use of policy by reference is both client and server understand
the policy by is reference. What is the value in client learning the value for polices
references it otherwise doesn't know?
*
* Thanks. I'd be interested to hear thoughts on any of these issues,
* especially from other folks who are developing SCVP servers.
*
* Seth Hitchings
* CoreStreet, Ltd.

------=_NextPart_000_02F7_01C4D89F.4B83B920
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICASEwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzE0MTQyNDExWhcNMDUw
NzI4MTQyNDExWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD
VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApU+vUXkZtNS8zIbCun9DLBIPm3s0KGJ7
Zi8g1nng+sa1AQYZWl0+E66CVVtqz87H2rJeRuWPSTlP3aLBh24tHWHh5Yifx6PGJ2aDzYa6BMrz
+dscn7MASmDOk3gVJyl0enKKzhpfwu32YzgoftV0oMXk5iFYDbejwrTDJgGWEhUCAwEAAaOB2jCB
1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j
b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu
Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr
BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB
BQUAA4GBAHaph4KaKdbtUyu1sgOlvLWWR6N4MDr3Kecna8npqNUs6bs2Ym77r8UtdvNbVpC9QnLl
6YgxvEN/kLiOYCgakyA1kIFefeZEL1WiRFkFoW7Y2OAHowT20LaRoOJnDuOiqDPUJb6fI88JHBad
gIg4rjN62pQIhj63BoZ4OpFGDVzaMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE
ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv
cml0eQIBITAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNDEyMDIyMzQ2NTVaMCMGCSqGSIb3DQEJBDEWBBTqt5/u9JjzKXtPiohWX8zFAyxb
4DBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0
ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgEhMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg
VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl
U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBITANBgkqhkiG9w0BAQEFAASBgHPi4NNVTWYQ
bkRon8rGCfgdrKvaN5InJVxxMfcKempNk3wf9FXT3ir66vUVIj957zkp0a9EHayTWA5Lld4bjiVu
Ch12uz5ZAmJkfzQrQo1rA/j4Q2H/pQmtBHHmeRTHkNKA2K6FfHHwvZbNzP/bVDvuVZP7jWjhVeG+
EaJB6URiAAAAAAAA

------=_NextPart_000_02F7_01C4D89F.4B83B920--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2KtCEB040744; Thu, 2 Dec 2004 12:55:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2KtCuB040743; Thu, 2 Dec 2004 12:55:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2KtBWe040634 for <[e-mail]>; Thu, 2 Dec 2004 12:55:11 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Dec 2004 12:55:08 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Thu, 2 Dec 2004 12:55:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP 16 Comments
Date: Thu, 2 Dec 2004 12:55:04 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 Comments
Thread-Index: AcTXy0criAKL84HQT7Gfw8ImIST1bgA4mTFg
From: "Trevor Freeman" <[e-mail]>
To: "Seth Hitchings" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 Dec 2004 20:55:01.0715 (UTC) FILETIME=[310FDA30:01C4D8B1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB2KtBWe040728
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Seth

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Seth Hitchings
* Sent: Wednesday, December 01, 2004 9:29 AM
* To: [e-mail]
* Subject: SCVP 16 Comments
* 
* Hi all,
* 
* My company, CoreStreet Ltd, is currently developing an implementation
of
* SCVP. We've recently updated our software to reflect the
* changes made in draft 16 and have found that there are many
ambiguities in
* the specification, both in the ASN.1 module and in the
* descriptions of how various elements are meant to be used.
* 
* Given the number of changes that will have to be made to draft 16, I
* wonder if it won't be necessary to permit another round of
* review before submitting the final draft to the RFC editors. I know
that
* there is a lot of pressure for draft 17 to be the final
* draft and to get this process completed, but it is in all of our best
* interest that the final draft be as clear and usable as
* possible.
* 
* I have sent most of my feedback on draft 16 directly to the editors,
but I
* have a few questions that I'd like the entire list
* consider.
* 
* 1) The 'check' for building a certification path to a trusted root has
* been removed, implying that an SCVP server can only returns
* paths that meet a local validation policy on the server. In a DPD
* environment, I believe that the client should be able to control
* whether the server performs validation. As such, I would like to see
id-
* stc-build-pkc-path and id-stc-build-aa-path restored in
* draft 17.
* 
[TF] Fixed
* 2) The want back for all paths, id-swb-pkc-all-valid-cert-paths,
should be
* changed to id-swb-pkc-all-cert-paths. The level of
* validation that is performed on the path is defined by the requested
* checks, not the want back. We don't have a separate want back
* for status checked certification paths.
[TF] OK
* 
* 3) The new RespValidationPolicy contains the userFinalPolicySet,
* permittedSubtrees and excludedSubtrees items that result from
* validation. Each unique path that is validated may produce different
* values for these three items but only one value for each item
* may be returned because only one RespValidationPolicy is returned with
* each CVResponse. There are two ways that more than one path
* can be returned in a CVResponse: a single CVRequest can contain more
than
* one query certificate, and multiple paths can be returned
* for each query certificate using the new 'want back'
id-swb-pkc-all-valid-
* cert-paths. There is no way for the validation algorithm
* output can be included as the specification is currently written.
[TF] the user final policy set is only for validating CA certificates
and there have been a number of off list comments to back out this
feature from 17 which is want I plan to do.
* 
* 4) Draft 16 requires SCVP servers to maintain a Diffie-Hellman public
key
* for use in authenticated requests. Given that SCVP servers
* are not required to support AuthenticatedData requests and that, in
* general, authentication should be a matter of local server
* policy, I believe that the new DH functionality should be optional for
* SCVP servers.
[TF] The DH key role depends on the client and transport to the server.
The DH key was added to allow anonymous clients to also gain integrity
over the request/response pair where the client is not using a secure
transport. Its use is optional. 
* 
* 5) The VPResponse contains a sequence of ValidationPolRef that
enumerates
* the set of validation policies supported by the SCVP
* server. However, these validation policies are not defined by value in
the
* VPResponse, they are merely listed by OID or URI. I
* believe that there is value in allowing a client to determine the
actual
* policy values that are used in each server policy. As such,
* I believe that the type for the validationPolicies item in VPResponse
* should be 'SEQUENCE OF ValidationPolicy'.
[TF] ]The premise for the use of policy by reference is both client and
server understand the policy by is reference. What is the value in
client learning the value for polices references it otherwise doesn't
know?
* 
* Thanks. I'd be interested to hear thoughts on any of these issues,
* especially from other folks who are developing SCVP servers.
* 
* Seth Hitchings
* CoreStreet, Ltd.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2KMc89087525; Thu, 2 Dec 2004 12:22:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2KMc2w087524; Thu, 2 Dec 2004 12:22:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2KMald087405 for <[e-mail]>; Thu, 2 Dec 2004 12:22:38 -0800 (PST) (envelope-from [e-mail])
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Thu, 2 Dec 2004 12:22:27 -0800
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Dec 2004 12:22:32 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D8AC.A71FFE1E"
Subject: SCVP 16 comments deadline
Date: Thu, 2 Dec 2004 12:22:31 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTYrKZ0ZfENfLmkRgOfz4mAp8pWsQ==
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 02 Dec 2004 20:22:32.0365 (UTC) FILETIME=[A728A5D0:01C4D8AC]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4D8AC.A71FFE1E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The deadline communicated at the DC meeting for making comments on SCVP
16 was Nov 30th which has now passed. I have had only three people send
me comments to date. SCVP 17 will be closing very shortly so this is the
last reminder.


------_=_NextPart_001_01C4D8AC.A71FFE1E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 201.0pt 0pt 0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The deadline communicated at the DC meeting for =
making
comments on SCVP 16 was Nov 30<sup>th </sup>which has now passed. I have =
had
only three people send me comments to date. SCVP 17 will be closing very =
shortly
so this is the last reminder.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C4D8AC.A71FFE1E--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2Hwhdp092491; Thu, 2 Dec 2004 09:58:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2HwhNn092490; Thu, 2 Dec 2004 09:58:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.um.es (smtp.um.es [155.54.212.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2Hwgjd092443 for <[e-mail]>; Thu, 2 Dec 2004 09:58:42 -0800 (PST) (envelope-from [e-mail])
Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D3846371E for <[e-mail]>; Thu,  2 Dec 2004 18:58:39 +0100 (CET)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with SMTP id D3051636C0 for <[e-mail]>; Thu,  2 Dec 2004 18:58:38 +0100 (CET)
Received: (qmail 23812 invoked from network); 2 Dec 2004 17:58:17 -0000
Received: from pirania2.dif.um.es (HELO ?155.54.210.105?) (155.54.210.105) by aries.dif.um.es with SMTP; 2 Dec 2004 17:58:17 -0000
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 19:03:26 +0100
From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Farrell <[e-mail]>
Cc: [e-mail]
Subject: Re: Attribute Certificates request and response protocol
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Farrell wrote:

>
>
> Hi,
>
> Once upon a time we did start work on such a thing [1]. To be
> honest, I can't even remember why we stopped - probably due
> to lack of interest;-)

    now I'm interesed :)

    If I'm right, an entity can request an AC to a service using the 
actual CMP draft specification, so, that's ok for me.

    Thanks and regards, Gabi.

>
> Regards,
> Stephen.
>
> [1] 
> http://www.netzmafia.de/rfc/internet-drafts/draft-ietf-pkix-laap-01.txt
>
> Gabriel López wrote:
>
>>
>>
>>    Dear all,
>>
>>    I'm looking for a transport protocol able to encapsulate an AC 
>> request and response messages.
>>    The idea es how an entity can requet an user's AC to another 
>> entity, instead to access directly to a LDAP repository.
>>    I have saw that CMP (draft-ietf-pkix-rfc2510bis-09.txt) can 
>> transport a x509v3PKCert object, which could be instantiated like a 
>> x509 certificate, AC, etc..
>>
>>    There is any other alternative to the use of  LDAP or CMP? 
>> TLS/SSL, ...?
>>  
>>     Thanks, Gabi.
>>  
>
>
>
>


-- 
Gabriel López Millán (http://pki.dif.um.es)
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
Apartado 4021
30001 Murcia
Telf: [phone]
fax: [phone]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2H1Ead048102; Thu, 2 Dec 2004 09:01:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2H1E1e048097; Thu, 2 Dec 2004 09:01:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2H1B5x047962 for <[e-mail]>; Thu, 2 Dec 2004 09:01:13 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB2H18Zv045363 for <[e-mail]>; Thu, 2 Dec 2004 17:01:08 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041202084947.02f3f730@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 02 Dec 2004 09:01:44 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
In-Reply-To: <6.1.2.0.0.20041130072120.03443f28@127.0.0.1>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6.1.2.0.0.20041130072120.03443f28@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 07:58 AM 11/30/2004, Kurt D. Zeilenga wrote:
>And, as I noted in my previous
>response, I do not consider the value extraction approach
>as applied here to certificates and such to be pragmatic
>as it simply does not address requirements I am faced with.

Here's another kind of search which the value extraction
approach does not address well:

A client wants to obtain the user information for each
user which possess both a certificate issued by CA A
and a certificate issued by CA B.  With value extraction,
the client must issue two search, one for certificates
of CA A and one for CA B, and then correlate the results
itself, and then fetch the users individually.  For 1M
users with certificates, with 1K having certificates
from both CAs, the client will have to obtain 2M
certificate objects to find the 1K certificates,
then will have to issue 1K searches to obtain
the user information (or fetch 1M user entries
to get the 1K user entries).

With component matching, this is done in one search
request.

Kurt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2DhQ91007823; Thu, 2 Dec 2004 05:43:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2DhQUg007822; Thu, 2 Dec 2004 05:43:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2DhK47007486 for <[e-mail]>; Thu, 2 Dec 2004 05:43:24 -0800 (PST) (envelope-from [e-mail])
Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with ESMTP id 3744714C06A; Thu,  2 Dec 2004 13:43:17 +0000 (GMT)
Received: from smtp3.tcd.ie by localhost.localdomain (VaMailArmor-2.0.1.16) id 28663-6FD99D40; Thu, 02 Dec 2004 13:43:17 +0000
Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 057C114C06A; Thu,  2 Dec 2004 13:43:17 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Thu, 02 Dec 2004 13:47:33 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Gabriel_L=F3pez?= <[e-mail]>
Cc: [e-mail]
Subject: Re: Attribute Certificates request and response protocol
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.28.0.18; VDF: 6.28.0.102; host: smtp3.tcd.ie)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB2DhP47007746
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Once upon a time we did start work on such a thing [1]. To be
honest, I can't even remember why we stopped - probably due
to lack of interest;-)

Regards,
Stephen.

[1] http://www.netzmafia.de/rfc/internet-drafts/draft-ietf-pkix-laap-01.txt

Gabriel López wrote:

> 
> 
>    Dear all,
> 
>    I'm looking for a transport protocol able to encapsulate an AC 
> request and response messages.
>    The idea es how an entity can requet an user's AC to another entity, 
> instead to access directly to a LDAP repository.
>    I have saw that CMP (draft-ietf-pkix-rfc2510bis-09.txt) can transport 
> a x509v3PKCert object, which could be instantiated like a x509 
> certificate, AC, etc..
> 
>    There is any other alternative to the use of  LDAP or CMP? TLS/SSL, ...?
>  
>     Thanks, Gabi.
>  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB25T5Lf068249; Wed, 1 Dec 2004 21:29:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB25T5mH068248; Wed, 1 Dec 2004 21:29:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB25T04Z067801 for <[e-mail]>; Wed, 1 Dec 2004 21:29:00 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB25SwFt005185 for <[e-mail]>; Thu, 2 Dec 2004 00:28:58 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB25Swkb259496 for <[e-mail]>; Thu, 2 Dec 2004 00:28:58 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB25SwQc014147 for <[e-mail]>; Thu, 2 Dec 2004 00:28:58 -0500
Received: from CORE (sig-9-65-84-75.mts.ibm.com [9.65.84.75]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id iB25Svtl014138; Thu, 2 Dec 2004 00:28:57 -0500
Message-ID: <001301c4d82f$d27e1f80$[e-mail]>
From: "Jong-Hyuk" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Date: Thu, 2 Dec 2004 00:28:45 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Since that time (Spring 2003) suppliers have not moved that far (if at
> all) towards supporting component matching. Only Steven Legg's Australian
> company, which had supported component matching prior to publication of
> the RFCs, and OpenLDAP which I believe can now support it, have done
> anything in this direction. Attribute extraction on the other hand has
> double that amount of supporting implementations, plus all clients can
> naturally support it without any code change.

Clients can be considered to naturally support Component Matching if they
accept search filters in a text form and they support extensibleMatch. It is
observed that many clients fall into this category. For those clients who
have search filters hard-coded and / or do not support extensibleMatch, the
OpenLDAP implementation of Component Matching further supports attribute and
matching rule aliases. In attribute aliasing, an alias attribute in the
search filter is converted by the server into the predefined aliased
component reference and the assertion value is used as the corresponding
component assertion value. The matching rule alias is used in a similar way.
The aliasing mechanism can also be considered as an optimization which
eliminates the extra processing steps for ComponentFilter parsing. We will
provide performance evaluation results of Component Matching to show that it
can be implemented in LDAP servers without performance degradation and
increase in complexity.
- Jong-Hyuk

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P.O. Box 218, Yorktown Heights, NY 10598
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB1HRCPe030991; Wed, 1 Dec 2004 09:27:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB1HRB3H030988; Wed, 1 Dec 2004 09:27:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB1HR9go030813 for <[e-mail]>; Wed, 1 Dec 2004 09:27:09 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: SCVP 16 Comments
Date: Wed, 1 Dec 2004 12:29:14 -0500
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0280_01C4D7A1.5E5EE3C0"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 Comments
Thread-Index: AcTXy0criAKL84HQT7Gfw8ImIST1bg==
From: "Seth Hitchings" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0280_01C4D7A1.5E5EE3C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,

My company, CoreStreet Ltd, is currently developing an implementation of SCVP. We've recently updated our software to reflect the
changes made in draft 16 and have found that there are many ambiguities in the specification, both in the ASN.1 module and in the
descriptions of how various elements are meant to be used. 

Given the number of changes that will have to be made to draft 16, I wonder if it won't be necessary to permit another round of
review before submitting the final draft to the RFC editors. I know that there is a lot of pressure for draft 17 to be the final
draft and to get this process completed, but it is in all of our best interest that the final draft be as clear and usable as
possible.

I have sent most of my feedback on draft 16 directly to the editors, but I have a few questions that I'd like the entire list
consider.

1) The 'check' for building a certification path to a trusted root has been removed, implying that an SCVP server can only returns
paths that meet a local validation policy on the server. In a DPD environment, I believe that the client should be able to control
whether the server performs validation. As such, I would like to see id-stc-build-pkc-path and id-stc-build-aa-path restored in
draft 17. 

2) The want back for all paths, id-swb-pkc-all-valid-cert-paths, should be changed to id-swb-pkc-all-cert-paths. The level of
validation that is performed on the path is defined by the requested checks, not the want back. We don't have a separate want back
for status checked certification paths.

3) The new RespValidationPolicy contains the userFinalPolicySet, permittedSubtrees and excludedSubtrees items that result from
validation. Each unique path that is validated may produce different values for these three items but only one value for each item
may be returned because only one RespValidationPolicy is returned with each CVResponse. There are two ways that more than one path
can be returned in a CVResponse: a single CVRequest can contain more than one query certificate, and multiple paths can be returned
for each query certificate using the new 'want back' id-swb-pkc-all-valid-cert-paths. There is no way for the validation algorithm
output can be included as the specification is currently written.

4) Draft 16 requires SCVP servers to maintain a Diffie-Hellman public key for use in authenticated requests. Given that SCVP servers
are not required to support AuthenticatedData requests and that, in general, authentication should be a matter of local server
policy, I believe that the new DH functionality should be optional for SCVP servers.

5) The VPResponse contains a sequence of ValidationPolRef that enumerates the set of validation policies supported by the SCVP
server. However, these validation policies are not defined by value in the VPResponse, they are merely listed by OID or URI. I
believe that there is value in allowing a client to determine the actual policy values that are used in each server policy. As such,
I believe that the type for the validationPolicies item in VPResponse should be 'SEQUENCE OF ValidationPolicy'.

Thanks. I'd be interested to hear thoughts on any of these issues, especially from other folks who are developing SCVP servers.

Seth Hitchings
CoreStreet, Ltd.

------=_NextPart_000_0280_01C4D7A1.5E5EE3C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICASEwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzE0MTQyNDExWhcNMDUw
NzI4MTQyNDExWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD
VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApU+vUXkZtNS8zIbCun9DLBIPm3s0KGJ7
Zi8g1nng+sa1AQYZWl0+E66CVVtqz87H2rJeRuWPSTlP3aLBh24tHWHh5Yifx6PGJ2aDzYa6BMrz
+dscn7MASmDOk3gVJyl0enKKzhpfwu32YzgoftV0oMXk5iFYDbejwrTDJgGWEhUCAwEAAaOB2jCB
1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j
b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu
Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr
BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB
BQUAA4GBAHaph4KaKdbtUyu1sgOlvLWWR6N4MDr3Kecna8npqNUs6bs2Ym77r8UtdvNbVpC9QnLl
6YgxvEN/kLiOYCgakyA1kIFefeZEL1WiRFkFoW7Y2OAHowT20LaRoOJnDuOiqDPUJb6fI88JHBad
gIg4rjN62pQIhj63BoZ4OpFGDVzaMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE
ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv
cml0eQIBITAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNDEyMDExNzI5MTRaMCMGCSqGSIb3DQEJBDEWBBRK+Cy8KNUwTM5iXxkwMPXPSdYU
ZTBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0
ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgEhMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg
VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl
U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBITANBgkqhkiG9w0BAQEFAASBgJoagxLngmvH
jYVFHmpJO19JFbbyfjQ694gQUu1nxvjqw6ZdtEdI0Fgv2OHPVbv9SxSyK+Y+qp94fekASCM1vGdE
HOQkYNsAuSFSLdVlFdFtNBg+ZiNGl/FBRLz7UA9WVvcfjVEgbVZ5CM+IYKeYymt376WzjDiGLfDs
C4akwNVAAAAAAAAA

------=_NextPart_000_0280_01C4D7A1.5E5EE3C0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB1GvjY4006428; Wed, 1 Dec 2004 08:57:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB1Gvjo4006427; Wed, 1 Dec 2004 08:57:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB1GvhYF006318 for <[e-mail]>; Wed, 1 Dec 2004 08:57:43 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB1GvZZv035748; Wed, 1 Dec 2004 16:57:35 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041201065112.02d4c0d0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Wed, 01 Dec 2004 08:57:57 -0800
To: Peter Gietz <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6.1.2.0.0.20041130072120.03443f28@127.0.0.1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iB1GviYF006421
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:20 AM 12/1/2004, Peter Gietz wrote:
>Kurt,
>
>some more remarks from my side.
>
>Kurt D. Zeilenga wrote:
>
>>David,
>>
>>While there may have been some in this WG that viewed the
>>value extraction approach as a pragmatic solution to various
>>specific issues, I believe there are also many, like myself,
>>who have never considered the value extraction approach, in
>>general, to be practical.  And, as I noted in my previous
>>response, I do not consider the value extraction approach
>>as applied here to certificates and such to be pragmatic
>>as it simply does not address requirements I am faced with.
>> 
>One requirement addressed by value extraction is to return to the client only the certificate the client needs.

Which certificate is that?  Maybe what the client wants is all certificates of
the person which holds a certificate whose subject DN contains a CN of X.

This highlights one of the problems with this approach.  It seems to be designed
with a specific subset of PKI applications in mind.  The solution, IMO, is not as
broadly applicable as its being made out to be.

>This requirement is not addressed by Component Matching. Only in combination with the return value filter (RFC 3876), which defines an LDAP control that again has to be supported by Clients and Servers, such a behaviour could be implemented. I guess that vendor's support for this is even less than for component matching.

Well, given that it was published as an RFC in September 2004, I would
be surprised if it were widely implemented.  It is implemented in
OpenLDAP Software.

>>In particular, how does this approach providing for matching
>>upon components of the subject (or other) DNs in the certificate?
>Well in our implementation we created another objectclass for such data (cn,o,ou,c,dc,emailadress, etc.) and our certificate2LDIF converter stores all rdn values of the dn in these attributes.

Stores? or maintains?  Sounds to me that this is simply a certificate object
creation tool (to be used in conjunction with ldapadd(1) or the like).  Do you
have a tool which ensures these certificate objects are consistent with
information in the person objects?

Anyways, having an ou attribute in the certificate object doesn't meet all the
needs.  Some applications might want to match only on ou's of the person
(plus certificate information), others on ou's of in the subject DN of the
person, others on ou's in the issuers DN.  With only one ou in the certificate
object, all clients cannot be properly supported.  Applications require
flexibility.  And this is one of the key problems with this approach, it is
not flexible.

Clients can only match on the components which have been extracted, and then
only in a manner consistent with that extraction.  Clients cannot match on
arbitrary components of the certificate.  Clients cannot match on extracted
components of the certificates and arbitrary components of the person entry.

>Such an objectclass - let me call it "additional metadata objectclass" for now - could be specified in a separate document, as well as other extensions objectclasses for things like qualified certs etc.
>
>>As we understood long ago, it will take time for this to get on
>>the radar of LDAP server developers.  That seems to be happening
>>now.
>I hope this discussion about value extraction, will help to get it on their radar.
>
>>>Attribute extraction on the other hand has double that amount of supporting implementations, plus all clients can naturally support it without any code change.
>>>   
>>
>>How does an existing client designed to work with person objects
>>become aware of, and make use of, subordinate certificate objects
>>without being changed?
>>
>> 
>Well by sending a search filter and getting back a userCertificate attribute.

But the client happens to have a hard-coded scope of oneLevel as it was looking
for persons under a specific ou object.  Just changing the filter won't help here.

Even if the scope was configurable, changing it to subtree would bring into
scope not only certificates of the desired persons, but certificates of objects
subordinate to the person objects.  These may not be desirable.

>With the above mentioned additional metadata objectclass all items of the search filter can be found in the certificate entry.

While they might be found, the matching precise semantics are not preserved.
That is, depending on the precise filter specification undesirable entries
may be returned.  This will be bad for any client expecting the filter to
match one and only one entry (such as clients doing identity mapping).

>The client (provided it does not have things like "objectclass=inetorgperson" in its filter)

But it might do that.  Maybe the client is only interested in certificates assigned
to persons, and hence has a (objectClass=person) in the filter.

>doesn't even  note that the answer is from a server supporting our schema. Clients that can have their search filters configured could additionally make use of the x509schema attributes like x509keyUsage etc.

But you also need to adjust the scope.  And then the actual attributes of the person
the client is after may not be in certificate object.  So the client would have to
then go find the person object after finding the certificate object.  And the
client will have to weed out non-desirable certificate objects that might get
returned due to the expansion of scope and/or the less precise matching behavior.

>>>So whilst we might all like the ideal today, pragmatically we need to recognise that this is not the situation on the ground today.
>>>   
>>
>>Pragmatically, we have to realize that the so-called pragmatic
>>solution will introduce numerous problems which we could have
>>avoided if we would have stuck with the so-called elegant solution
>>we knew avoided these problems.
>> 
>The only "problem" I see with our solution is that, as Steve noted, the number of entries increases. With the scalability of LDAP servers  I don't see this as a real problem.

Scalability is the least of my worries here.  I am more worried about
interoperability, consistency issues, management issues, and security issues.

For instance, having duplicates makes it much harder to control access...
making it far more likely that information will be mistakenly disclosed.

There will be data inconsistencies, and I haven't thought through all the
problems that will cause.

And managing all these duplicates certainly will get messy.  It seems for this
approach to be deployed, one might have to change a number of existing clients
(clients which one might not have source to).

>>>If it were I would happily forget the attribute extraction IDs. My main desire is that we need to provide LDAP support to X.509 users today. We should recognise that it will be many years before the big LDAP suppliers might eventually decide to support component matching. After all, there are several very basic features of LDAP that some large LDAP suppliers dont yet support, even though they have been standardised for over 10 years.
>>>As several well known people have already said, LDAP has not done a good job at supporting PKI.
>>>  
>>
>>To the LDAP community, PKI is just another application of the
>>directory.  The LDAP community tends to focused on mechanisms
>>which support a wide range of applications (including PKI).
>>Component matching does this.
>>
>>I am not sure the LDAP community as a whole sees the danger
>>in moving to a value extraction approach generally.  I shutter
>>at the thought of having components of every complex value
>>extracted into new values, and them in term extracted into more
>>values.  I would hope it would be obvious that value extraction
>>is not a wise approach, and will lead to numerous other problems.
>>
>> 
>such as?

See above.

>I agree with you that component matching is generally a good solution. But I also see that a lot of LDAP deployments use similiar approaches than ours for solving the problem of establishing relations between values of different LDAP attributes (e.g. this telephone number belongs to this room number). I shutter if in future for any such case people each time start to define complex syntaxes. Putting such information into separate entries does not look too harmfull to me.  Of course the family of entries approach would make it look even less harmfull.

The family of entries approach failed to gain any traction in
the LDAP community for good reason, but that's another debate.

>BTW: hasn't "Keep it simple" not always been a rule at IETF?

Component matching and value matched control are far more simple
than value extraction approach.   Value extraction does nothing but
push the complexity of compound structures onto clients.  Component
matching and values matched control keeps the complexity in the
directory service.

I argue that implementation of XPS-like systems, especially ones that
deal with non-certificate matching issues, consistency issues, etc.,
and their deployment, is actually quite complex.

Kurt


>Cheers,
>
>Peter
>
>
>
>
>>>So why believe things will miraculously change overnight with component matching. Be realistic, it wont.
>>>   
>>
>>I don't believe I've ever said that we'd miraculously have wide
>>adoption of component matching overnight.  I expect it will be
>>years before we see that.
>>
>>However, I fear that if we are not careful in how we publish
>>the value extraction approach, we will be living with the
>>problems of value extraction long after we have broad server
>>support for component matching.   By noting, using appropriately
>>strong language, the standard track approach is to be favored,
>>we might be able to minimize this.  Of course, we'd likely
>>suffer regardless.
>>
>> 
>>
>>>Unless of course Stefan Santesson can now stand up for his supplier and tell us when they will support component matching. That would indeed be very encouraging to us all.
>>>
>>>thanks
>>>
>>>David
>>>
>>>
>>>Steve Hanna wrote:
>>>   
>>>
>>>>David Chadwick wrote:
>>>>     
>>>>
>>>>>what ever happened to the concept of let a thousand flowers bloom?
>>>>>       
>>>>Standards work is not about "let a thousand flowers bloom".
>>>>It's about agreeing on standards that will help systems
>>>>interoperate and work well together. From my analysis,
>>>>your proposals do not provide substantial benefit and
>>>>they do add substantial complexity. I don't think that
>>>>the Internet community will be well served by publishing
>>>>these documents. They will only increase confusion for
>>>>implementors and add complexity for directory clients,
>>>>which will now need to support several directory schemas.
>>>>In a separate email, David wrote:
>>>>
>>>>     
>>>>
>>>>>At no time to my knowledge was it suggested that this work be removed
>>>>>       
>>>>>
>>>>>from the PKIX set of IDs, otherwise why would they have continued to be
>>>>     
>>>>
>>>>>published with PKIX IDs instead of individual IDs for more than a year
>>>>>after the meeting. And why would I have continued to report on their
>>>>>progress at PKIX meetings?
>>>>>       
>>>>At IETF 56, there was a discussion about whether to move
>>>>to your proposed schemas (at that time, an independent
>>>>submission) or stick with the current schema and use
>>>>component matching to solve the problem. I raised concerns
>>>>about your proposal at that meeting. As noted in the meeting
>>>>minutes, a straw poll favored component matching but it was
>>>>agreed to take this discussion to the mailing list. I never
>>>>saw any discussion on the mailing list.
>>>>At IETF 57, it was explained that the question had been
>>>>decided in favor of your schema (with no discussion
>>>>on the email list). I sent an email to the PKIX list
>>>>complaining about this and reiterating my concerns about
>>>>your proposal. Sharon Boeyen sent email supporting my
>>>>concerns. Nobody sent email favoring the proposals.
>>>>Now these documents are in Working Group Last Call.
>>>>I have seen several emails from experienced PKI and
>>>>directory folks raising concerns about your proposal
>>>>and little email supporting it. I think it's clear
>>>>there's no WG consensus in favor of your proposals.
>>>>I suspect there never was a consensus in favor of
>>>>them becoming WG drafts. If anything, the consensus
>>>>seems to be that these documents are not representative
>>>>of the IETF's future direction and should only be
>>>>published with an Experimental status and some sort
>>>>of warning.
>>>>I'm sorry for any confusion caused by the status of
>>>>your documents as WG drafts. It seems clear to me that
>>>>they should never have received such a status since
>>>>there was never rough consensus in the PKIX WG about
>>>>taking them on as work items. However, it is better to
>>>>remove this confusion now by publishing them as
>>>>Experimental with a warning than to expand the confusion
>>>>by publishing them as Informational without a warning.
>>>>Thanks,
>>>>Steve
>>>>
>>>>     
>>>-- 
>>>*****************************************************************
>>>
>>>David W. Chadwick, BSc PhD
>>>Professor of Information Systems Security
>>>IS Institute, University of Salford, Salford M5 4WT
>>>Tel: [phone]  Fax [phone]
>>>Mobile: [phone]
>>>Email: [e-mail]
>>>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>>>Research Web site: http://sec.isi.salford.ac.uk
>>>Entrust key validation string: MLJ9-DU5T-HV8J
>>>PGP Key ID is 0xBC238DE5
>>>
>>>*****************************************************************
>>>   
>>
>>
>> 
>
>
>-- 
>_______________________________________________________________________
>Peter Gietz (CEO)
>DAASI International GmbH                phone: [phone]
>Wilhelmstr. 106                         Fax:   [phone]  
>D-72074 Tübingen                        email: [e-mail]
>Germany                                 Web:   www.daasi.de
>
>Directory Applications for Advanced Security and Information Management
>_______________________________________________________________________




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB1GWkeP079548; Wed, 1 Dec 2004 08:32:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB1GWkH7079547; Wed, 1 Dec 2004 08:32:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.um.es (smtp.um.es [155.54.212.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB1GWiph079393 for <[e-mail]>; Wed, 1 Dec 2004 08:32:45 -0800 (PST) (envelope-from [e-mail])
Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C8271447 for <[e-mail]>; Wed,  1 Dec 2004 17:32:34 +0100 (CET)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with SMTP id 9019B17816 for <[e-mail]>; Wed,  1 Dec 2004 17:32:32 +0100 (CET)
Received: (qmail 27868 invoked from network); 1 Dec 2004 16:32:10 -0000
Received: from pirania2.dif.um.es (HELO ?155.54.210.105?) (155.54.210.105) by aries.dif.um.es with SMTP; 1 Dec 2004 16:32:10 -0000
Message-ID: <[e-mail]>
Date: Wed, 01 Dec 2004 17:37:15 +0100
From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Attribute Certificates request and response protocol
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

    Dear all,

    I'm looking for a transport protocol able to encapsulate an AC 
request and response messages.
    The idea es how an entity can requet an user's AC to another entity, 
instead to access directly to a LDAP repository.
    I have saw that CMP (draft-ietf-pkix-rfc2510bis-09.txt) can 
transport a x509v3PKCert object, which could be instantiated like a x509 
certificate, AC, etc..

    There is any other alternative to the use of  LDAP or CMP? TLS/SSL, ...?
   

     Thanks, Gabi.
   

-- 
Gabriel López Millán (http://pki.dif.um.es)
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
Apartado 4021
30001 Murcia
Telf: [phone]
fax: [phone]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB1DKdlX057032; Wed, 1 Dec 2004 05:20:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB1DKdP0057031; Wed, 1 Dec 2004 05:20:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.daasi.de (rhea.directory.dfn.de [134.2.217.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB1DKc22057008 for <[e-mail]>; Wed, 1 Dec 2004 05:20:38 -0800 (PST) (envelope-from [e-mail])
Received: by smtp.daasi.de (Postfix, from userid 1009) id 74738C0EF; Wed,  1 Dec 2004 14:20:39 +0100 (CET)
Received: from daasi.de (marie.directory.dfn.de [134.2.217.72]) by smtp.daasi.de (Postfix) with ESMTP id C3413C0F0; Wed,  1 Dec 2004 14:20:32 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 01 Dec 2004 14:20:32 +0100
From: Peter Gietz <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: David Chadwick <[e-mail]>, Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6.1.2.0.0.20041130072120.03443f28@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041130072120.03443f28@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=-2.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE, USER_AGENT version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt,

some more remarks from my side.

Kurt D. Zeilenga wrote:

>David,
>
>While there may have been some in this WG that viewed the
>value extraction approach as a pragmatic solution to various
>specific issues, I believe there are also many, like myself,
>who have never considered the value extraction approach, in
>general, to be practical.  And, as I noted in my previous
>response, I do not consider the value extraction approach
>as applied here to certificates and such to be pragmatic
>as it simply does not address requirements I am faced with.
>  
>
One requirement addressed by value extraction is to return to the client 
only the certificate the client needs.
This requirement is not addressed by Component Matching. Only in 
combination with the return value filter (RFC 3876), which defines an 
LDAP control that again has to be supported by Clients and Servers, such 
a behaviour could be implemented. I guess that vendor's support for this 
is even less than for component matching.

>In particular, how does this approach providing for matching
>upon components of the subject (or other) DNs in the certificate?
>
>  
>
Well in our implementation we created another objectclass for such data 
(cn,o,ou,c,dc,emailadress, etc.) and our certificate2LDIF converter 
stores all rdn values of the dn in these attributes. Such an objectclass 
- let me call it "additional metadata objectclass" for now - could be 
specified in a separate document, as well as other extensions 
objectclasses for things like qualified certs etc.

>As we understood long ago, it will take time for this to get on
>the radar of LDAP server developers.  That seems to be happening
>now.
>
>  
>
I hope this discussion about value extraction, will help to get it on 
their radar.

>>Attribute extraction on the other hand has double that amount of supporting implementations, plus all clients can naturally support it without any code change.
>>    
>>
>
>How does an existing client designed to work with person objects
>become aware of, and make use of, subordinate certificate objects
>without being changed?
>
>  
>
Well by sending a search filter and getting back a userCertificate 
attribute. With the above mentioned additional metadata objectclass all 
items of the search filter can be found in the certificate entry. The 
client (provided it does not have things like 
"objectclass=inetorgperson" in its filter) doesn't even  note that the 
answer is from a server supporting our schema. Clients that can have 
their search filters configured could additionally make use of the 
x509schema attributes like x509keyUsage etc.

>>So whilst we might all like the ideal today, pragmatically we need to recognise that this is not the situation on the ground today.
>>    
>>
>
>Pragmatically, we have to realize that the so-called pragmatic
>solution will introduce numerous problems which we could have
>avoided if we would have stuck with the so-called elegant solution
>we knew avoided these problems.
>  
>
The only "problem" I see with our solution is that, as Steve noted, the 
number of entries increases. With the scalability of LDAP servers  I 
don't see this as a real problem.

>  
>
>>If it were I would happily forget the attribute extraction IDs. My main desire is that we need to provide LDAP support to X.509 users today. We should recognise that it will be many years before the big LDAP suppliers might eventually decide to support component matching. After all, there are several very basic features of LDAP that some large LDAP suppliers dont yet support, even though they have been standardised for over 10 years.
>>As several well known people have already said, LDAP has not done a good job at supporting PKI.
>>    
>>
>
>To the LDAP community, PKI is just another application of the
>directory.  The LDAP community tends to focused on mechanisms
>which support a wide range of applications (including PKI).
>Component matching does this.
>
>I am not sure the LDAP community as a whole sees the danger
>in moving to a value extraction approach generally.  I shutter
>at the thought of having components of every complex value
>extracted into new values, and them in term extracted into more
>values.  I would hope it would be obvious that value extraction
>is not a wise approach, and will lead to numerous other problems.
>
>  
>
such as?

I agree with you that component matching is generally a good solution. 
But I also see that a lot of LDAP deployments use similiar approaches 
than ours for solving the problem of establishing relations between 
values of different LDAP attributes (e.g. this telephone number belongs 
to this room number). I shutter if in future for any such case people 
each time start to define complex syntaxes. Putting such information 
into separate entries does not look too harmfull to me.  Of course the 
family of entries approach would make it look even less harmfull.

BTW: hasn't "Keep it simple" not always been a rule at IETF?


Cheers,

Peter




>>So why believe things will miraculously change overnight with component matching. Be realistic, it wont.
>>    
>>
>
>I don't believe I've ever said that we'd miraculously have wide
>adoption of component matching overnight.  I expect it will be
>years before we see that.
>
>However, I fear that if we are not careful in how we publish
>the value extraction approach, we will be living with the
>problems of value extraction long after we have broad server
>support for component matching.   By noting, using appropriately
>strong language, the standard track approach is to be favored,
>we might be able to minimize this.  Of course, we'd likely
>suffer regardless.
>
>  
>
>>Unless of course Stefan Santesson can now stand up for his supplier and tell us when they will support component matching. That would indeed be very encouraging to us all.
>>
>>thanks
>>
>>David
>>
>>
>>Steve Hanna wrote:
>>    
>>
>>>David Chadwick wrote:
>>>      
>>>
>>>>what ever happened to the concept of let a thousand flowers bloom?
>>>>        
>>>>
>>>Standards work is not about "let a thousand flowers bloom".
>>>It's about agreeing on standards that will help systems
>>>interoperate and work well together. From my analysis,
>>>your proposals do not provide substantial benefit and
>>>they do add substantial complexity. I don't think that
>>>the Internet community will be well served by publishing
>>>these documents. They will only increase confusion for
>>>implementors and add complexity for directory clients,
>>>which will now need to support several directory schemas.
>>>In a separate email, David wrote:
>>>
>>>      
>>>
>>>>At no time to my knowledge was it suggested that this work be removed
>>>>        
>>>>
>>>>from the PKIX set of IDs, otherwise why would they have continued to be
>>>      
>>>
>>>>published with PKIX IDs instead of individual IDs for more than a year
>>>>after the meeting. And why would I have continued to report on their
>>>>progress at PKIX meetings?
>>>>        
>>>>
>>>At IETF 56, there was a discussion about whether to move
>>>to your proposed schemas (at that time, an independent
>>>submission) or stick with the current schema and use
>>>component matching to solve the problem. I raised concerns
>>>about your proposal at that meeting. As noted in the meeting
>>>minutes, a straw poll favored component matching but it was
>>>agreed to take this discussion to the mailing list. I never
>>>saw any discussion on the mailing list.
>>>At IETF 57, it was explained that the question had been
>>>decided in favor of your schema (with no discussion
>>>on the email list). I sent an email to the PKIX list
>>>complaining about this and reiterating my concerns about
>>>your proposal. Sharon Boeyen sent email supporting my
>>>concerns. Nobody sent email favoring the proposals.
>>>Now these documents are in Working Group Last Call.
>>>I have seen several emails from experienced PKI and
>>>directory folks raising concerns about your proposal
>>>and little email supporting it. I think it's clear
>>>there's no WG consensus in favor of your proposals.
>>>I suspect there never was a consensus in favor of
>>>them becoming WG drafts. If anything, the consensus
>>>seems to be that these documents are not representative
>>>of the IETF's future direction and should only be
>>>published with an Experimental status and some sort
>>>of warning.
>>>I'm sorry for any confusion caused by the status of
>>>your documents as WG drafts. It seems clear to me that
>>>they should never have received such a status since
>>>there was never rough consensus in the PKIX WG about
>>>taking them on as work items. However, it is better to
>>>remove this confusion now by publishing them as
>>>Experimental with a warning than to expand the confusion
>>>by publishing them as Informational without a warning.
>>>Thanks,
>>>Steve
>>>
>>>      
>>>
>>-- 
>>
>>*****************************************************************
>>
>>David W. Chadwick, BSc PhD
>>Professor of Information Systems Security
>>IS Institute, University of Salford, Salford M5 4WT
>>Tel: [phone]  Fax [phone]
>>Mobile: [phone]
>>Email: [e-mail]
>>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>>Research Web site: http://sec.isi.salford.ac.uk
>>Entrust key validation string: MLJ9-DU5T-HV8J
>>PGP Key ID is 0xBC238DE5
>>
>>*****************************************************************
>>    
>>
>
>
>  
>


-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________