Re: CMS and PKCS7 signedAndEnvelopedData

[Russ Housley <[e-mail]>]

Alicia:

The SignedAndEnvelopedData was dropped because of a security concern.  An 
attacker can remove the signature, essentially making an EnvelopedData, and 
the recipient has no way to tell that the originator intended to sign and 
encrypt the protected content.

Russ

At 08:13 AM 8/27/2005, Alicia da Conceicao wrote:

>Greetings:
>
>Does CMS (Cryptographic Message Syntax) support signedAndEnvelopedData
>as specified in PKCS7 v 1.5?  I cannot find any references to
>signedAndEnvelopedData in RFC-2630.
>
>Has signedAndEnvelopedData been deprecated in favour of placing signedData
>within encrypted envelopedData, in order to protect the identity of the
>signer?
>
>Thank you in advance.
>Alicia.





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 j7TGujoP020205; Mon, 29 Aug 2005 09:56:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TGujrU020203; Mon, 29 Aug 2005 09:56:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7TGuiSt020191 for <[e-mail]>; Mon, 29 Aug 2005 09:56:44 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 946 invoked by uid 0); 29 Aug 2005 16:56:39 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.189.146) by woodstock.binhost.com with SMTP; 29 Aug 2005 16:56:39 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 29 Aug 2005 12:56:38 -0400
To: Alicia da Conceicao <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: CMS and PKCS7 signedAndEnvelopedData
Cc: [e-mail], [e-mail]
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>

Alicia:

The SignedAndEnvelopedData was dropped because of a security concern.  An 
attacker can remove the signature, essentially making an EnvelopedData, and 
the recipient has no way to tell that the originator intended to sign and 
encrypt the protected content.

Russ

At 08:13 AM 8/27/2005, Alicia da Conceicao wrote:

>Greetings:
>
>Does CMS (Cryptographic Message Syntax) support signedAndEnvelopedData
>as specified in PKCS7 v 1.5?  I cannot find any references to
>signedAndEnvelopedData in RFC-2630.
>
>Has signedAndEnvelopedData been deprecated in favour of placing signedData
>within encrypted envelopedData, in order to protect the identity of the
>signer?
>
>Thank you in advance.
>Alicia.



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 j7TEwrP1012704; Mon, 29 Aug 2005 07:58:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TEwrT5012703; Mon, 29 Aug 2005 07:58:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7TEwq5c012697 for <[e-mail]>; Mon, 29 Aug 2005 07:58:52 -0700 (PDT) (envelope-from [e-mail])
Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id D3F9C100B5; Mon, 29 Aug 2005 10:58:51 -0400 (EDT)
Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11640-19; Mon, 29 Aug 2005 10:58:50 -0400 (EDT)
Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id DF4F9100B3; Mon, 29 Aug 2005 10:58:49 -0400 (EDT)
Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.4) with ESMTP id 2005082911002299-4156 ; Mon, 29 Aug 2005 11:00:22 -0400 
Date: Mon, 29 Aug 2005 10:58:48 -0400
From: Sam Roberts <[e-mail]>
To: Alicia da Conceicao <[e-mail]>
Cc: [e-mail]
Subject: Re: CMS and PKCS7 signedAndEnvelopedData
Message-ID: <[e-mail]>
Mail-Followup-To: Alicia da Conceicao <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.0i
X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 08/29/2005 11:00:23 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 08/29/2005 11:00:24 AM, Serialize complete at 08/29/2005 11:00:24 AM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

Wrote Alicia da Conceicao <[e-mail]>, on Mon, Aug 29, 2005 at 07:41:25AM -0400:
> 
> > This should be discussed on the S/MIME mailing list not on the PKIX mailing
> > list.
> 
> Hi Jim:
> 
> Thank you for answering my question.  However, I am working on a CMS
> application which deals with pure binary data and DER encoded ASN.1.  And
> my CMS application nothing to do with S/MIME, e-mail, mime types, or any
> type of text headers or fields.  If the PKIX group does not directly
> maintain the CMS specification, then please let me know who does.

You have some interesting observations, but whether CMS is used within
e-mail applications or not, it is still the S/MIME working group that
maintains and publishes the specs, not the Public Key Infrastructure
(X.509) working group. This is the wrong mailing list.

See:

  http://www.ietf.org/html.charters/smime-charter.html

Cheers,
Sam

-- 
http://www.certicom.com



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 j7TBfOCC097285; Mon, 29 Aug 2005 04:41:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TBfOR0097284; Mon, 29 Aug 2005 04:41:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eevee.engine.ca (gate1.engine.ca [207.188.86.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TBfOMI097277 for <[e-mail]>; Mon, 29 Aug 2005 04:41:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from alicia@localhost) by eevee.engine.ca (8.11.3nb1/8.6.12) id j7TBfQq03639; Mon, 29 Aug 2005 07:41:26 -0400 (EDT)
From: Alicia da Conceicao <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: CMS and PKCS7 signedAndEnvelopedData
To: [e-mail] (Jim Schaad)
Date: Mon, 29 Aug 2005 07:41:25 -0400 (EDT)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from "Jim Schaad" at Aug 28, 2005 06:13:34 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

> This should be discussed on the S/MIME mailing list not on the PKIX mailing
> list.

Hi Jim:

Thank you for answering my question.  However, I am working on a CMS
application which deals with pure binary data and DER encoded ASN.1.  And
my CMS application nothing to do with S/MIME, e-mail, mime types, or any
type of text headers or fields.  If the PKIX group does not directly
maintain the CMS specification, then please let me know who does.

> signedAndEnvelopedData was dropped from the CMS specification when we moved
> from PKCS#7 to CMS on purpose.  The issue is that there are very few cases
> where you want to both sign and encrypt a message, but allow the world to
> know the party that signed the message.  The correct action now would be to
> sign the message and then encrypt it in almost all cases.

CMS SignedData allows for detached (external) signatures of arbitary
binary data.  One can also detached (external) CMS EnvelopedData with the
decryption details from the actual encrypted data typically placed in the
optional EncryptedContent.

==================================================================
EncryptedContentInfo ::= SEQUENCE {
        contentType ContentType,
        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
==================================================================
 
But if I want to encrypt just the data into a file, then put into a
separate file the digital signature of the original data along with
the decryption details?  Without SignedAndEnvelopedData, there does not
appear to be a way to combine the CMS SignedData and CMS EnvelopedData
structures for external signatures with decryption details in a way
that would meet the CMS standard.  Note that detaching the signed and
encrypted data from the CMS structures is very useful when one is
dealing with larged amounts of streamed data.
 
There are many real world cases where you want to both sign and
encrypt a message, and don't care if others can see who signed it.
Especially when one has a centralized trusted organiation, like a CA,
software company, or service provider.  These trusted organiations can
digital signed and distribute CUSTOMIZED secure data that is encrypted
with the customers public keys.  This is useful for provisioning, VoIP,
video on demand, etc.

If anyone has any reasonable work around for SignedAndEnvelopedData that
works with detached encrypted data and still meets the CMS standards,
please let me know.  Otherwise it may be useful to look at ammending
the CMS specification to include SignedAndEnvelopedData.

Thank you in advance.
Alicia.

PS. Note that detached encrypted data is not used in S/MIME so I am
	directing my questions to this mailing list.



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 j7T1B1YI047062; Sun, 28 Aug 2005 18:11:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7T1B1cb047061; Sun, 28 Aug 2005 18:11:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T1AweY047046 for <[e-mail]>; Sun, 28 Aug 2005 18:11:00 -0700 (PDT) (envelope-from [e-mail])
Received: from romans (unknown [66.52.193.76]) by smtp3.pacifier.net (Postfix) with ESMTP id C5CDD6F1A4; Sun, 28 Aug 2005 18:10:52 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Alicia da Conceicao'" <[e-mail]>, <[e-mail]>
Subject: RE: CMS and PKCS7 signedAndEnvelopedData
Date: Sun, 28 Aug 2005 18:13:34 -0700
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.2670
In-Reply-To: <[e-mail]>
Thread-Index: AcWrAl951B4cJGxfQqOWTSQEwcZ+bgBNETkg
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>

Alicia,

This should be discussed on the S/MIME mailing list not on the PKIX mailing
list.

However here is the answer you are looking for:

signedAndEnvelopedData was dropped from the CMS specification when we moved
from PKCS#7 to CMS on purpose.  The issue is that there are very few cases
where you want to both sign and encrypt a message, but allow the world to
know the party that signed the message.  The correct action now would be to
sign the message and then encrypt it in almost all cases.

jim 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alicia da Conceicao
> Sent: Saturday, August 27, 2005 5:13 AM
> To: [e-mail]
> Subject: CMS and PKCS7 signedAndEnvelopedData
> 
> 
> Greetings:
> 
> Does CMS (Cryptographic Message Syntax) support 
> signedAndEnvelopedData as specified in PKCS7 v 1.5?  I cannot 
> find any references to signedAndEnvelopedData in RFC-2630.
> 
> Has signedAndEnvelopedData been deprecated in favour of 
> placing signedData within encrypted envelopedData, in order 
> to protect the identity of the signer?
> 
> Thank you in advance.
> Alicia.
> 
> 
> 




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 j7RCD2aY064333; Sat, 27 Aug 2005 05:13:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7RCD26l064332; Sat, 27 Aug 2005 05:13:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eevee.engine.ca (gate1.engine.ca [207.188.86.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RCD1fX064317 for <[e-mail]>; Sat, 27 Aug 2005 05:13:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from alicia@localhost) by eevee.engine.ca (8.11.3nb1/8.6.12) id j7RCDPa05376; Sat, 27 Aug 2005 08:13:25 -0400 (EDT)
From: Alicia da Conceicao <[e-mail]>
Message-Id: <[e-mail]>
Subject: CMS and PKCS7 signedAndEnvelopedData
To: [e-mail]
Date: Sat, 27 Aug 2005 08:13:25 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

Greetings:

Does CMS (Cryptographic Message Syntax) support signedAndEnvelopedData
as specified in PKCS7 v 1.5?  I cannot find any references to
signedAndEnvelopedData in RFC-2630.

Has signedAndEnvelopedData been deprecated in favour of placing signedData
within encrypted envelopedData, in order to protect the identity of the
signer?

Thank you in advance.
Alicia.



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 j7QJo3Ww046507; Fri, 26 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJo3XF046506; Fri, 26 Aug 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJo2j4046496 for <[e-mail]>; Fri, 26 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E8kDC-0001pm-7L; Fri, 26 Aug 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-crlaia-03.txt 
Message-Id: <[e-mail]>
Date: Fri, 26 Aug 2005 15:50:02 -0400
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 
                          Authority Information Access CRL Extension
	Author(s)	: S. Santesson, R. Housley
	Filename	: draft-ietf-pkix-crlaia-03.txt
	Pages		: 8
	Date		: 2005-8-26
	
This document updates RFC 3280 by defining the Authority Information
   Access Certificate Revocation Lists (CRL) extension.  RFC 3280
   defines the Authority Information Access certificate extension using
   the same syntax.  The CRL extension provides a means of discovering
   and retrieving CRL issuer certificates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-03.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-crlaia-03.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-crlaia-03.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-crlaia-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-crlaia-03.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 j7QCmRCJ075767; Fri, 26 Aug 2005 05:48:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QCmRTR075766; Fri, 26 Aug 2005 05:48:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QCmPpH075729 for <[e-mail]>; Fri, 26 Aug 2005 05:48:26 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 13:48:19 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: IESG last call changes to the CRL AIA draft
Date: Fri, 26 Aug 2005 13:48:18 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IESG last call changes to the CRL AIA draft
Thread-Index: AcWqPG7Kcz5ma0x/Ti2yrp82cAZZlg==
From: "Stefan Santesson" <[e-mail]>
To: "PKIX" <[e-mail]>
X-OriginalArrivalTime: 26 Aug 2005 12:48:19.0953 (UTC) FILETIME=[6FBFD610:01C5AA3C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QCmQpH075760
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>

During IESG last call on the CRL AIA draft, David Cooper submitted some
editorial comments which has been corrected and included in a new draft
03, submitted today.

The changes are:

1) Clarification that a certificate located through this extension, used
to validate signatures on CRLs may not be a CA certificate and thus may
be found in the userCertificate attribute. The old text in section 2
was:

     When the accessLocation is a directoryName, the information is to
     be obtained by the application from whatever directory server is
     locally configured.  The entry for the directoryName contains CA
     certificates in the crossCertificatePair and/or cACertificate
     attributes as specified in [RFC 2587].  The protocol that
     application uses to access the directory (e.g., DAP or LDAP) is a
     local matter.

The new text reads:

     When the accessLocation is a directoryName, the information is to
     be obtained by the application from whatever directory server is
     locally configured.  When one CA public key is used to validate
     signatures on certificates and CRLs, the desired CA certificate is
     stored in the crossCertificatePair and/or cACertificate attributes
     as specified in [RFC 2587].  When different public keys are used to
     validate signatures on certificates and CRLs, the desired
     certificate is stored in the userCertificate attribute as specified
     in [RFC 2587]. Thus, implementations that support the directoryName
     form of accessLocation MUST be prepared to find the needed
     certificate in any of these three attributes.  The protocol that an
     application uses to access the directory (e.g., DAP or LDAP) is a
     local matter.

2) Removing the DER encoded requirement for CMS messages and instead use
reliance on RFC 2797 to specify necessary coding conventions.

3) Aligning the ldap examples so that all now includes the ";binary"
option.

The changes have been concluded and edited in cooperation with Russ,
Sam, Steve and Tim.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 




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 j7OIoNti031083; Wed, 24 Aug 2005 11:50:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OIoNi6031082; Wed, 24 Aug 2005 11:50:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7OIoM2Y031076 for <[e-mail]>; Wed, 24 Aug 2005 11:50:23 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 27019 invoked by uid 0); 24 Aug 2005 18:50:16 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.185.43) by woodstock.binhost.com with SMTP; 24 Aug 2005 18:50:16 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 24 Aug 2005 14:22:55 -0400
To: Jean-Marc Desperrier <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Can't find info on certificate validity dates
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

My recollection of that discussion is that we will remove all discussion of 
the private key validity period extension altogether in RFC 3280bis.  It 
was pointed out that this is the only extension for which use is actively 
discouraged.  There are many other extensions that have been defined in 
subsequent editions of X.509 for which there is no discussion at all.  It 
was agreed to remove discussion of this one rather than adding discussion 
of all of the new ones.

Russ

At 12:00 PM 8/24/2005, Jean-Marc Desperrier wrote:
>>   There is a certificate extension (private key usage period) for this 
>> purpose, and the PKIX WG has decided long ago (before RFC 2459 was 
>> published in 1999) to discourage its use.
>I think is missing here the fact that this point has been rediscussed in 
>the last IETF meeting, with the suggestion that there might be valid cases 
>of using that extension, and AFAIR the resolution is that we'll remove 
>from RFC3280bis the paragraph discouraging its use.



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 j7OGUdAR018066; Wed, 24 Aug 2005 09:30:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OGUd0n018065; Wed, 24 Aug 2005 09:30:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OGUc9r018056 for <[e-mail]>; Wed, 24 Aug 2005 09:30:38 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft5.fr.colt.net (8.13.4/8.13.4/Debian-3) with ESMTP id j7OGUbUf008749 for <[e-mail]>; Wed, 24 Aug 2005 18:30:37 +0200
Message-ID: <[e-mail]>
Date: Wed, 24 Aug 2005 18:30:28 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b4) Gecko/20050807 SeaMonkey/1.0a
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: Rollover pair sufficient or not?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; 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>

sravan wrote:
> Is there any place where this key rollover & certificate rollover 
> issues are documented?
> I was searching(in vain) for them in the internet for the past one week.
> Please point me to some resources where I can get the following info:
> - certificate rollover process
> - key rollover process
In the standard you should check rfc2510 2.4., and 4.2.
If you need an operational description, you'll need other resources.

> also, during the certificate and/ or key rollover process should the 
> CA maintain 2 sets of CRL dps(one of the old cert & one for new cert) ?
If you do a key rollover, you *must* do the following to simultaneously 
be compatible with existing implementation and do the right thing 
according to the correct implementation of the standard :
- have 2 sets of CRL
- the serial numbers of the certificates issued under the new key must 
not overlap the serial numbers of the certificate issued under the old key
- the crl emitted with the new key must also include the serial numbers 
of the revoked certificat issued under the old key (until the end of the 
validity of the old CA)
- the crl emitted with the old key must also include the serial numbers 
of the revoked certificat issued under the new key (until the old CA is 
no more valid and you can stop creating new one)

Unfortunately, not all software will allow you to do things that way.
If all softwares were doing the right thing according to the standard, 
you could issue only one crl with the new key and including all serial 
numbers. When they are not correct, they need both the crl with the old 
and the new key, but don't care about the serial number issues listed above.

In constrast if you do a cert rollover where you only change the 
validity date, the impact is only to update the cert everywhere.



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 j7OG0Nbv014754; Wed, 24 Aug 2005 09:00:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OG0NqV014753; Wed, 24 Aug 2005 09:00:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OG0Mtw014735 for <[e-mail]>; Wed, 24 Aug 2005 09:00:23 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft4.fr.colt.net (8.13.4/8.13.4/Debian-3) with ESMTP id j7OG0GAw015892 for <[e-mail]>; Wed, 24 Aug 2005 18:00:21 +0200
Message-ID: <[e-mail]>
Date: Wed, 24 Aug 2005 18:00:06 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b4) Gecko/20050807 SeaMonkey/1.0a
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Can't find info on certificate validity dates
References: <[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>

Russ Housley wrote:
> Do not expect a relying party to recognize a certificate policy OID 
> and take any special actions to enforce a policy like: "certificate 
> validity period is two years, but it should only be used for signing 
> during the first."
But the certificate policy solution seems quite adequate in that use 
case where we more want to simply inform that the key won't be used 
anymore to sign certificate after the initial period than really want to 
enforce the non-signing rule through that extension.
>   There is a certificate extension (private key usage period) for this 
> purpose, and the PKIX WG has decided long ago (before RFC 2459 was 
> published in 1999) to discourage its use.
I think is missing here the fact that this point has been rediscussed in 
the last IETF meeting, with the suggestion that there might be valid 
cases of using that extension, and AFAIR the resolution is that we'll 
remove from RFC3280bis the paragraph discouraging its use.
>> Would there be problems with using overlapping certificates even when
>> the key doesn't change?
Nope. Many people are doing that. But they usually more extend the 
notAfter date, and keep the same notBefore.
>> I'm thinking a rollover pair in such a setup would be one certificate
>> more than necessary, but then superfluity is not always evil.
That the only way to handle it that situation on long term you will 
after the initial run almost always have two valid certificate at any 
given time.
But when you only change the validity period you don't really need the 
first anymore after you create the new 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 j7ODteTq086720; Wed, 24 Aug 2005 06:55:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ODted2086719; Wed, 24 Aug 2005 06:55:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atcmail.atc.tcs.co.in (atcmail.atc.tcs.co.in [203.200.212.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ODtaOT086654 for <[e-mail]>; Wed, 24 Aug 2005 06:55:38 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.19.58.128] (sravan.atc.tcs.co.in [172.19.58.128]) by atcmail.atc.tcs.co.in (8.12.11/8.12.11) with ESMTP id j7ODt8YV019649 for <[e-mail]>; Wed, 24 Aug 2005 19:25:08 +0530
Message-ID: <[e-mail]>
Date: Wed, 24 Aug 2005 19:25:03 +0530
From: sravan <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Rollover pair sufficient or not?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV version 0.86.1, clamav-milter version 0.86 on atcmail.atc.tcs.co.in
X-Virus-Status: Clean
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,
Is there any place where this key rollover & certificate rollover issues 
are documented?
I was searching(in vain) for them in the internet for the past one week.
Please point me to some resources where I can get the following info:
- certificate rollover process
- key rollover process
also, during the certificate and/ or key rollover process should the CA 
maintain 2 sets of CRL dps(one of the old cert & one for new cert) ?

thnx,
sravan


PS: Russ Housley, I am sorry for my previous post. I thought it was 
posted to the group; but it was posted to you.

Russ Housley wrote:

>
> End users that have the new key as a trust anchor will be able to 
> validate certificates signed with the new key in the usual way. 
> However, if they encounter a certificate that is signed with the old 
> key, the key rollover certificate allow them to validate it with a 
> path that leads to the new key trust anchor.
>
> Hope this helps,
> Russ
>
> At 02:09 AM 8/23/2005, Joel Rees wrote:
>
>> I'm reading Planning for PKI and and I've got this ambiguity in my
>> head. The rollover pair is sufficient for building a path back to the
>> original certificate. Therefore, it kind of seems that there might be
>> no need for a normal new CA certificate with just the new key.
>>
>> Or would you want, in addition, a plain CA certificate with just the
>> new key, so that end users who have never seen the old key don't need
>> to think about the old key?
>>
>> Joel Rees <[e-mail]>
>> digitcom, inc. æ ªå¼ä¼šç¤¾ãƒ‡ã‚¸ã‚³ãƒ
>> Kobe, Japan [phone]
>> ** <http://www.ddcom.co.jp> **
>>
>>
>>
>>
>>



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 j7ODq6X9084977; Wed, 24 Aug 2005 06:52:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ODq6i1084976; Wed, 24 Aug 2005 06:52:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7ODq5OA084962 for <[e-mail]>; Wed, 24 Aug 2005 06:52:05 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 19939 invoked by uid 0); 24 Aug 2005 13:52:02 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.132.219) by woodstock.binhost.com with SMTP; 24 Aug 2005 13:52:02 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 24 Aug 2005 09:47:21 -0400
To: Joel Rees <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Can't find info on certificate validity dates
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
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>

Joel:

Do not expect a relying party to recognize a certificate policy OID and 
take any special actions to enforce a policy like: "certificate validity 
period is two years, but it should only be used for signing during the 
first."  There is a certificate extension (private key usage period) for 
this purpose, and the PKIX WG has decided long ago (before RFC 2459 was 
published in 1999) to discourage its use.

I do not understand your question:
 > Would there be problems with using overlapping certificates even when
 > the key doesn't change?

Did you mean to say: "... even when the key does change?"

You encourage key change over to limit the scope of compromise.  I agree 
with this suggestion.

Russ


At 01:49 AM 8/23/2005, Joel Rees wrote:

>I'm a little late here, but I'd like to check on this --
>
>On 平成 17/08/18, at 2:57, Russ Housley wrote:
>
>>
>>It is best if all of the certificates that will be validated by a
>>given CA certificate have a notAfter data that is earlier (or the
>>same) as the the notAfter date in the CA certificate.
>>
>>If the CA certificate is renewed (the same subject name and the
>>same public key are used with a different validity period), it is
>>possible to avoid this dependence.  However, I believe that most
>>CAs will change their key pair when a new certificate is needed.
>>
>>Russ
>>
>>At 07:58 PM 8/11/2005, Aram Perez wrote:
>>
>>>Hi Folks,
>>>
>>>Is there an RFC that talks about the validity dates on CA
>>>certificates and the validity dates for the certificates it (the CA)
>>>issues? For example, if a "conformant" CA certificate has a notAfter
>>>date of Dec. 31, 2005, should it issue certificates that have a
>>>notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and
>>>couldn't find anything related to my question. The cert path
>>>validation algorithm of 3280 only mentions that the current time be
>>>within the validity dates of the cert being processed.
>
>Would there be problems with using overlapping certificates even when
>the key doesn't change?
>
>I'm inclined to think the key should change anyway, to limit the
>scope of compromise, but would there be anything specifically wrong
>with issuing the initial certificate for, say, two years, with a
>policy that indicates that it will only be used for signing during
>the first year, etc., then issuing a new certificate on the same key
>at the end of each year until whoever makes the decision thinks it
>would be good to roll the key over?
>
>I'm thinking a rollover pair in such a setup would be one certificate
>more than necessary, but then superfluity is not always evil.
>
>My intent with such a plan would be to push period refresh. I'm not
>inclined to trust machines for very long periods of time.
>
>How far out in left field is this idea?
>
>--
>Joel Rees   <[e-mail]>
>digitcom, inc.   æ ªå¼ä¼šç¤¾ãƒ‡ã‚¸ã‚³ãƒ
>Kobe, Japan   [phone]
>** <http://www.ddcom.co.jp> **
>
>
>
>
>



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 j7ODWcCb077660; Wed, 24 Aug 2005 06:32:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ODWcbM077659; Wed, 24 Aug 2005 06:32:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7ODWbNK077644 for <[e-mail]>; Wed, 24 Aug 2005 06:32:37 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 26598 invoked by uid 0); 24 Aug 2005 13:32:30 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.132.219) by woodstock.binhost.com with SMTP; 24 Aug 2005 13:32:30 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 24 Aug 2005 09:32:06 -0400
To: Joel Rees <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Rollover pair sufficient or not?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
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>

End users that have the new key as a trust anchor will be able to validate 
certificates signed with the new key in the usual way.  However, if they 
encounter a certificate that is signed with the old key, the key rollover 
certificate allow them to validate it with a path that leads to the new key 
trust anchor.

Hope this helps,
   Russ

At 02:09 AM 8/23/2005, Joel Rees wrote:

>I'm reading Planning for PKI and and I've got this ambiguity in my
>head. The rollover pair is sufficient for building a path back to the
>original certificate. Therefore, it kind of seems that there might be
>no need for a normal new CA certificate with just the new key.
>
>Or would you want, in addition, a plain CA certificate with just the
>new key, so that end users who have never seen the old key don't need
>to think about the old key?
>
>Joel Rees   <[e-mail]>
>digitcom, inc.   æ ªå¼ä¼šç¤¾ãƒ‡ã‚¸ã‚³ãƒ
>Kobe, Japan   [phone]
>** <http://www.ddcom.co.jp> **
>
>
>
>
>



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 j7NKNEeV094528; Tue, 23 Aug 2005 13:23:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NKNEGS094527; Tue, 23 Aug 2005 13:23:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NKNC4h094502 for <[e-mail]>; Tue, 23 Aug 2005 13:23:13 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E7fIY-0000q5-1k; Tue, 23 Aug 2005 16:23:06 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, pkix mailing list <[e-mail]>, pkix chair <[e-mail]>, pkix chair <[e-mail]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure  Operational Protocols: Certificate Store Access via HTTP' to Proposed  Standard 
Message-Id: <[e-mail]>
Date: Tue, 23 Aug 2005 16:23:06 -0400
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>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Operational Protocols: Certificate 
   Store Access via HTTP '
   <draft-ietf-pkix-certstore-http-09.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Russ Housley and Sam Hartman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-09.txt

Technical Summary

  The protocol conventions described in this document satisfy some of
  the operational requirements of the Internet Public Key Infrastructure
  (PKI).  This document specifies the conventions for using the
  Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to
  obtain certificates and certificate revocation lists (CRLs) from PKI
  repositories.

Working Group Summary

  The PKIX Working Group reached rough consensus on this document.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.



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 j7N6BmAN092582; Mon, 22 Aug 2005 23:11:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N6BmVH092578; Mon, 22 Aug 2005 23:11:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7N6BkFD092554 for <[e-mail]>; Mon, 22 Aug 2005 23:11:47 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 24171 invoked by alias); 23 Aug 2005 06:20:19 -0000
Received: from unknown (HELO ?172.16.1.133?) (10.10.10.11) by mail.ddcom.local with SMTP; 23 Aug 2005 06:20:19 -0000
Mime-Version: 1.0 (Apple Message framework v734)
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
To: [e-mail]
From: Joel Rees <[e-mail]>
Subject: Rollover pair sufficient or not?
Date: Tue, 23 Aug 2005 15:09:17 +0900
X-Mailer: Apple Mail (2.734)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7N6BlFD092570
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'm reading Planning for PKI and and I've got this ambiguity in my  
head. The rollover pair is sufficient for building a path back to the  
original certificate. Therefore, it kind of seems that there might be  
no need for a normal new CA certificate with just the new key.

Or would you want, in addition, a plain CA certificate with just the  
new key, so that end users who have never seen the old key don't need  
to think about the old key?

Joel Rees   <[e-mail]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   [phone]
** <http://www.ddcom.co.jp> **







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 j7N5q9Dd073699; Mon, 22 Aug 2005 22:52:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N5q8au073698; Mon, 22 Aug 2005 22:52:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7N5q774073645 for <[e-mail]>; Mon, 22 Aug 2005 22:52:08 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 23379 invoked by alias); 23 Aug 2005 06:00:39 -0000
Received: from unknown (HELO ?172.16.1.133?) (10.10.10.11) by mail.ddcom.local with SMTP; 23 Aug 2005 06:00:39 -0000
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
Message-Id: <[e-mail]>
From: Joel Rees <[e-mail]>
Subject: Re: Can't find info on certificate validity dates
Date: Tue, 23 Aug 2005 14:49:37 +0900
To: [e-mail]
X-Mailer: Apple Mail (2.734)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7N5q874073690
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'm a little late here, but I'd like to check on this --

On 平成 17/08/18, at 2:57, Russ Housley wrote:

>
> It is best if all of the certificates that will be validated by a  
> given CA certificate have a notAfter data that is earlier (or the  
> same) as the the notAfter date in the CA certificate.
>
> If the CA certificate is renewed (the same subject name and the  
> same public key are used with a different validity period), it is  
> possible to avoid this dependence.  However, I believe that most  
> CAs will change their key pair when a new certificate is needed.
>
> Russ
>
> At 07:58 PM 8/11/2005, Aram Perez wrote:
>
>> Hi Folks,
>>
>> Is there an RFC that talks about the validity dates on CA
>> certificates and the validity dates for the certificates it (the CA)
>> issues? For example, if a "conformant" CA certificate has a notAfter
>> date of Dec. 31, 2005, should it issue certificates that have a
>> notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and
>> couldn't find anything related to my question. The cert path
>> validation algorithm of 3280 only mentions that the current time be
>> within the validity dates of the cert being processed.

Would there be problems with using overlapping certificates even when  
the key doesn't change?

I'm inclined to think the key should change anyway, to limit the  
scope of compromise, but would there be anything specifically wrong  
with issuing the initial certificate for, say, two years, with a  
policy that indicates that it will only be used for signing during  
the first year, etc., then issuing a new certificate on the same key  
at the end of each year until whoever makes the decision thinks it  
would be good to roll the key over?

I'm thinking a rollover pair in such a setup would be one certificate  
more than necessary, but then superfluity is not always evil.

My intent with such a plan would be to push period refresh. I'm not  
inclined to trust machines for very long periods of time.

How far out in left field is this idea?

--
Joel Rees   <[e-mail]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   [phone]
** <http://www.ddcom.co.jp> **







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 j7MN0hK7006476; Mon, 22 Aug 2005 16:00:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MN0hWX006475; Mon, 22 Aug 2005 16:00:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7MN0g24006458 for <[e-mail]>; Mon, 22 Aug 2005 16:00:42 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 11161 invoked by uid 0); 22 Aug 2005 23:00:33 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.174.212) by woodstock.binhost.com with SMTP; 22 Aug 2005 23:00:33 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 22 Aug 2005 18:57:52 -0400
To: "Stefan Santesson" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Where to store SRV based names
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail] .corp.microsoft.com>
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>

I went to the DNS tutorial at IETF63. One of the points that was made was 
that the DNS itself did not limit the character set.  It stores an octet 
string.

I suggest that we ask the DNS Directorate for advice.  Perhaps you can work 
with Steve Bellovin, who is a member of the DNS Directorate to carry the 
question forward.  I suspect you will have to help him formulate a concise 
question.

Russ

At 10:55 AM 8/22/2005, Stefan Santesson wrote:

>Originally I suggested IA5String but many voices suggested UTF-8, so
>that is what will go into next draft unless someone has a reason to
>suggest otherwise.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
> > -----Original Message-----
> > From: [e-mail]
>[mailto:[e-mail]]
> > On Behalf Of David Chadwick
> > Sent: den 22 augusti 2005 12:22
> > To: Tom Gindin
> > Cc: PKIX
> > Subject: Re: Where to store SRV based names
> >
> >
> >
> >
> > Tom Gindin wrote:
> > >         David:
> > >
> > >         We shouldn't use the OID assigned to the subjectAltName
> > extension.
> > >  Instead we should assign a new OID, to be assigned to an
>OTHER-NAME.
> >
> >
> > Hi Tom
> >
> > this is what I intended. Sorry if my last email was not clear enough
> >
> >
> >    We
> > > also can't use PrintableString with Stefan's syntax, because
> > > PrintableString doesn't include underscore and the SRV key normally
> > > contains underscores.  So what is the right string type: IA5String,
> > > VisibleString (a tighter fit than IA5String, but less familiar), or
> > > UTF8String (internationalizable)?
> >
> > It all depends upon what the DNS can store in its SRV RR. IA5string
> > would surely work, but maybe internationalised DNS can store
>UFT8Strings
> > as well, which would be better. We need a DNS expert to advise.
> >
> > >         I agree with the general approach of defining a syntax which
>can
> > > be used either within GeneralName or in a directory attribute.
> >
> > thanks
> >
> > David
> >
> > >
> > >                 Tom Gindin
> > >
> > >
> > >
> > >
> > >
> > >
> > > David Chadwick <[e-mail]>
> > > Sent by: [e-mail]
> > > 08/11/2005 05:25 AM
> > >
> > >         To:     PKIX <[e-mail]>
> > >         cc:
> > >         Subject:        Where to store SRV based names
> > >
> > >
> > >
> > > As a result of my previous message and the various replies to it, it
> > > seems like the arguments against using the
>subjectDirectoryAttributes
> > > extension to store the attribute are
> > >
> > > i) we only have a hammer, so the extension has to be a nail (i.e. we
> > > only support subjectAltNames (and not SDA) so it has to go there),
>and
> > >
> > > ii) since attributes can be anything, we dont want to use them to
>store
> > > this attribute, since attributes are a catch all.
> > >
> > > I dont actually find either arguement technically convincing,
>although I
> > > do find i) pragmatically convincing. (But if we were to extend this
> > > argument PKIX could have been stillborn, because by using this
>argument
> > > we could have said ten years ago that few people were supporting
> > > certificate extensions so lets not use any of them :-)
> > >
> > > However, I do have a solution to offer as follows. Assume that n.n.n
>is
> > > the OID assigned to the subjectAltNames extension. The we define the
> > > following attribute using this OID
> > >
> > > srvName ATTRIBUTE                ::=             {
> > > WITH SYNTAX                              PrintableString (SIZE
>(1..128))
> > > EQUALITY MATCHING RULE                           caseIgnoreMatch
> > > ID                               n.n.n }
> > >
> > > By doing this we ensure:
> > > i) the extension will be carried in the subjectAltNames extension
> > > ii) the syntax and matching rules for the srv string are fully and
> > > compactly defined
> > > iii) If anyone also wanted to store the string in LDAP as an
>attribute
> > > they could do so using the above definition.
> > >
> > > regards
> > >
> > > David
> > >
> > >
> >
> > --
> >
> > *****************************************************************
> > David W. Chadwick, BSc PhD
> > Professor of Information Systems Security
> > The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> > Tel: [phone]
> > Fax [phone]
> > Mobile: [phone]
> > Email: [e-mail]
> > Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> > Research Web site: http://sec.cs.kent.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 j7MI97Yr000382; Mon, 22 Aug 2005 11:09:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MI97JL000381; Mon, 22 Aug 2005 11:09:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7MI96Ba000359 for <[e-mail]>; Mon, 22 Aug 2005 11:09:06 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 19564 invoked by uid 0); 22 Aug 2005 18:08:14 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.174.212) by woodstock.binhost.com with SMTP; 22 Aug 2005 18:08:14 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 22 Aug 2005 14:01:14 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: last call for SIM
In-Reply-To: <002101c5a6ec$a1565710$720710ac@5434d1>
References: <p06230908bf1d686988af@[128.33.244.163]> <[e-mail]> <002101c5a6ec$a1565710$720710ac@5434d1>
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>

These is no problem with this dependency.  However, it means that both 
documents must be approved before the RFC Editor will publish the SIM document.

Russ

At 03:39 AM 8/22/2005, Jaeho Yoon wrote:
> > 16. Page 9.
> >
> >   "Before calculating a PEPSI, conforming implementations MUST process
> >   the userPassword with the six step [LDAPBIS STRPREP] string
> >   preparation algorithm as follows":
> >
> > [LDAPBIS STRPREP] is only an I-D it is not possible to refer to an I-D
> > that is an informative reference and use a MUST.
>
>I think it needs to reach an agreement because there remain a lot of 
>further discussion on whether I-D can be referred to use a MUST.
>If the IESG or you give me an appropriate comment, I will reflect it on 
>SIM draft.



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 j7MEth0L079745; Mon, 22 Aug 2005 07:55:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MEthNq079744; Mon, 22 Aug 2005 07:55:43 -0700 (PDT)
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 j7MEtftn079707 for <[e-mail]>; Mon, 22 Aug 2005 07:55:42 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Aug 2005 15:55:35 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Where to store SRV based names
Date: Mon, 22 Aug 2005 15:55:32 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Where to store SRV based names
Thread-Index: AcWnCxCu3QuHlVoqSLq1Ucp2uIS7dgAHiyUw
From: "Stefan Santesson" <[e-mail]>
To: "David Chadwick" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: "PKIX" <[e-mail]>
X-OriginalArrivalTime: 22 Aug 2005 14:55:35.0552 (UTC) FILETIME=[8D44C800:01C5A729]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7MEtgtn079738
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>

Originally I suggested IA5String but many voices suggested UTF-8, so
that is what will go into next draft unless someone has a reason to
suggest otherwise.
 

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of David Chadwick
> Sent: den 22 augusti 2005 12:22
> To: Tom Gindin
> Cc: PKIX
> Subject: Re: Where to store SRV based names
> 
> 
> 
> 
> Tom Gindin wrote:
> >         David:
> >
> >         We shouldn't use the OID assigned to the subjectAltName
> extension.
> >  Instead we should assign a new OID, to be assigned to an
OTHER-NAME.
> 
> 
> Hi Tom
> 
> this is what I intended. Sorry if my last email was not clear enough
> 
> 
>    We
> > also can't use PrintableString with Stefan's syntax, because
> > PrintableString doesn't include underscore and the SRV key normally
> > contains underscores.  So what is the right string type: IA5String,
> > VisibleString (a tighter fit than IA5String, but less familiar), or
> > UTF8String (internationalizable)?
> 
> It all depends upon what the DNS can store in its SRV RR. IA5string
> would surely work, but maybe internationalised DNS can store
UFT8Strings
> as well, which would be better. We need a DNS expert to advise.
> 
> >         I agree with the general approach of defining a syntax which
can
> > be used either within GeneralName or in a directory attribute.
> 
> thanks
> 
> David
> 
> >
> >                 Tom Gindin
> >
> >
> >
> >
> >
> >
> > David Chadwick <[e-mail]>
> > Sent by: [e-mail]
> > 08/11/2005 05:25 AM
> >
> >         To:     PKIX <[e-mail]>
> >         cc:
> >         Subject:        Where to store SRV based names
> >
> >
> >
> > As a result of my previous message and the various replies to it, it
> > seems like the arguments against using the
subjectDirectoryAttributes
> > extension to store the attribute are
> >
> > i) we only have a hammer, so the extension has to be a nail (i.e. we
> > only support subjectAltNames (and not SDA) so it has to go there),
and
> >
> > ii) since attributes can be anything, we dont want to use them to
store
> > this attribute, since attributes are a catch all.
> >
> > I dont actually find either arguement technically convincing,
although I
> > do find i) pragmatically convincing. (But if we were to extend this
> > argument PKIX could have been stillborn, because by using this
argument
> > we could have said ten years ago that few people were supporting
> > certificate extensions so lets not use any of them :-)
> >
> > However, I do have a solution to offer as follows. Assume that n.n.n
is
> > the OID assigned to the subjectAltNames extension. The we define the
> > following attribute using this OID
> >
> > srvName ATTRIBUTE                ::=             {
> > WITH SYNTAX                              PrintableString (SIZE
(1..128))
> > EQUALITY MATCHING RULE                           caseIgnoreMatch
> > ID                               n.n.n }
> >
> > By doing this we ensure:
> > i) the extension will be carried in the subjectAltNames extension
> > ii) the syntax and matching rules for the srv string are fully and
> > compactly defined
> > iii) If anyone also wanted to store the string in LDAP as an
attribute
> > they could do so using the above definition.
> >
> > regards
> >
> > David
> >
> >
> 
> --
> 
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Tel: [phone]
> Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://sec.cs.kent.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 j7MAMAmU044543; Mon, 22 Aug 2005 03:22:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MAMALs044542; Mon, 22 Aug 2005 03:22:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-2.visp.demon.net (IDENT:[e-mail] [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MAM8LA044512 for <[e-mail]>; Mon, 22 Aug 2005 03:22:09 -0700 (PDT) (envelope-from [e-mail])
Received: from [82.32.148.24] (82-32-148-24.cable.ubr01.nail.blueyonder.co.uk [82.32.148.24]) by lon1-mail-2.visp.demon.net (MOS 3.5.8-GR) with ESMTP id CQO55212 (AUTH [e-mail]); Mon, 22 Aug 2005 11:22:05 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 11:22:05 +0100
From: David Chadwick <[e-mail]>
Organization: University of Kent
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: Where to store SRV based names
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>

Tom Gindin wrote:
>         David:
> 
>         We shouldn't use the OID assigned to the subjectAltName extension. 
>  Instead we should assign a new OID, to be assigned to an OTHER-NAME.


Hi Tom

this is what I intended. Sorry if my last email was not clear enough


   We
> also can't use PrintableString with Stefan's syntax, because 
> PrintableString doesn't include underscore and the SRV key normally 
> contains underscores.  So what is the right string type: IA5String, 
> VisibleString (a tighter fit than IA5String, but less familiar), or 
> UTF8String (internationalizable)?

It all depends upon what the DNS can store in its SRV RR. IA5string 
would surely work, but maybe internationalised DNS can store UFT8Strings 
as well, which would be better. We need a DNS expert to advise.

>         I agree with the general approach of defining a syntax which can 
> be used either within GeneralName or in a directory attribute.

thanks

David

> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> David Chadwick <[e-mail]>
> Sent by: [e-mail]
> 08/11/2005 05:25 AM
>  
>         To:     PKIX <[e-mail]>
>         cc: 
>         Subject:        Where to store SRV based names
> 
> 
> 
> As a result of my previous message and the various replies to it, it 
> seems like the arguments against using the subjectDirectoryAttributes 
> extension to store the attribute are
> 
> i) we only have a hammer, so the extension has to be a nail (i.e. we 
> only support subjectAltNames (and not SDA) so it has to go there), and
> 
> ii) since attributes can be anything, we dont want to use them to store 
> this attribute, since attributes are a catch all.
> 
> I dont actually find either arguement technically convincing, although I 
> do find i) pragmatically convincing. (But if we were to extend this 
> argument PKIX could have been stillborn, because by using this argument 
> we could have said ten years ago that few people were supporting 
> certificate extensions so lets not use any of them :-)
> 
> However, I do have a solution to offer as follows. Assume that n.n.n is 
> the OID assigned to the subjectAltNames extension. The we define the 
> following attribute using this OID
> 
> srvName ATTRIBUTE                ::=             {
> WITH SYNTAX                              PrintableString (SIZE (1..128))
> EQUALITY MATCHING RULE                           caseIgnoreMatch
> ID                               n.n.n }
> 
> By doing this we ensure:
> i) the extension will be carried in the subjectAltNames extension
> ii) the syntax and matching rules for the srv string are fully and 
> compactly defined
> iii) If anyone also wanted to store the string in LDAP as an attribute 
> they could do so using the above definition.
> 
> regards
> 
> David
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: [phone]
Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.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 j7M7dZwA015354; Mon, 22 Aug 2005 00:39:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M7dZcG015353; Mon, 22 Aug 2005 00:39:35 -0700 (PDT)
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 j7M7dUU6015180 for <[e-mail]>; Mon, 22 Aug 2005 00:39:31 -0700 (PDT) (envelope-from [e-mail])
Received: (snipe 11678 invoked by alias); 22 Aug 2005 16:43:45 +0900
Received: from [e-mail] with  Spamsniper 2.83.29 (Processed in 0.055839 secs);
Received: from unknown (HELO 5434d1) (172.16.7.114) by unknown with SMTP; 22 Aug 2005 16:43:45 +0900
X-RCPTTO: [e-mail], [e-mail], [e-mail]
Message-ID: <002101c5a6ec$a1565710$720710ac@5434d1>
From: "Jaeho Yoon" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <p06230908bf1d686988af@[128.33.244.163]> <[e-mail]>
Subject: Re: last call for SIM
Date: Mon, 22 Aug 2005 16:39:29 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j7M7dWU6015302
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 Denis Pinkas,

Thank you for your comments on SIM document.  

The comments you pointed out were very useful to make this document better.

Here are my opinions against your comments. 

At first, as for typos
I will correct them. (5, 7, 8, 9, 11, 14, 15, 17, 18, 19, 22).

and as for the other comments (1, 2, 3, 4, 6, 10, 12, 13, 16, 20, 21)

> 1. Page 2 :
> 
>   "Where the subject is a person, the name that is specified in the
>   subject field of the certificate typically reflects the legal name of
>   the individual and affiliated entities (e.g., their corporate
>   affiliation)".
> 
> "legal name" should not be used.
> 
> Change into:
> 
>   Where the subject is a person, the name that is specified in the
>   subject field of the certificate may reflect the name of
>   the individual and affiliated entities (e.g., their corporate
>   affiliation).

I will accept your opinion.

> 2. Page 2:
> 
>   "Therefore, privacy sensitive identifiers cannot be included in
>   certificates as plaintext".
> 
> There is a case which should be mentioned. Using some QCStatements
> it is possible to include the hash of a picture or of a fingerprint
> in a certificate. This respects privacy and if the picture is sent,
> it can be matched against the hash. ESTI has defined such QCStatements
> in ETSI TS 101 862.
> 
> This is very analogous. In PEPSI a "short" character string is used,
> whereas when a picture or a fingerprint is used the complexity from
> PEPSI is not needed. Users should be informed that there exists an
> alternative to PEPSI.

I can accept your opinion. But for clarification, I'd like to ask you whether a picture or a fingerprint in QCStatements is the equivalent usage to PEPSI.
These seem a bit different types from SIM, I think. 
 
> 3. Page 3 :
> 
>   "Furthermore, the subject can prove to the
>   relying party that they are associated with a valid identification
>   without disclosing the identifier. For example, a person could prove
>   they possessed a valid social security number without disclosing the
>   identifier itself."
> 
> These sentences are unclear. What is the identifier ? It is the social
> security number ?

Text will be changed to :
Furthermore, the subject can prove to the  relying party that they are associated with an identifier without disclosing the identifier. 
For example, a person could prove he/she possessed a specific social security number without actually disclosing the actual social security number itself. 

> 4. Page 3 :
> 
>   "In addition, this document defines an Encrypted PEPSI(EPEPSI) so that
>   sensitive identifier information can be exchanged without disclosing
>   the identifier".
> 
> Later on it can be discovered that this is only useful for a RA - CA 
> protocol but this sentence may let think it is appropriate in a client-server 
> protocol. This should be clarified.

There is nothing to suggest that another specification could not use the EPEPSI structure for communication between items where are not RA/CA.
I don't think this needs to be changed.

> 6. Page 5:
> 
>   "If Alice wishes to prove she has a valid identifier, without
>   disclosing it, then steps 7 and 8 are as follows:"
> 
> It should be mentioned that using this method Bob could "impersonate"
> Alice using the same protocol with another party. This should be addressed
> in the security considerations section. This is fact the most severe
> limitation of PEPSI.

Yes, you are right. And this part was already pointed out by my colleague. It will be added at security consideration part.
 
> 10. Page 7:
> 
>   "One of SHA-1 or SHA-256 MUST be used for ensuring the integrity of PEPSI."
> 
> Since an OID is permitted, any kind of hash function may be used.

We are dealing with standard items which MUST be implemented. Although other algorithms can be used, for interoperability, specific functions needs to be mentioned at "Standard", I think

> 12. Page 7.
> 
>   To meet this requirement, RAs SHOULD encrypt the
>   SIItype, SII, and PEPSI with the CA's public key
> 
> Usually a CA has no public key for encryption but only a public signing key.
> All the features related to the dialog with the CA should be placed in a
> separate section that is NOT mandatory to implement to claim conformance
> with this specification. In particular EPEPSI should be not mandatory to 
> implement.

"Usually a CA has no public key for encryption but only a public signing key." -> CA can have a public key suitable for encryption and it is not the same key as is used for signing certificates. And in that requirement, I intended that the information which should be sent according to circumstances must be sent securely by encryption method.
 
> 13. Page 8.
> 
>   "As described above, the certificate request message MAY contain the
>   PEPSI. [RFC2314] and [RFC2511] are widely used message syntaxes for
>   certification requests".
> 
> This is not possible since it is said that R is generated by the RA.

It will be added that "RA sends the SIM to Alice" in page 4

> 16. Page 9.
> 
>   "Before calculating a PEPSI, conforming implementations MUST process
>   the userPassword with the six step [LDAPBIS STRPREP] string
>   preparation algorithm as follows":
> 
> [LDAPBIS STRPREP] is only an I-D it is not possible to refer to an I-D
> that is an informative reference and use a MUST.

I think it needs to reach an agreement because there remain a lot of further discussion on whether I-D can be referred to use a MUST.
If the IESG or you give me an appropriate comment, I will reflect it on SIM draft.

> 20. Page 10.
> 
>   "A cryptographically secure hash function such as SHA-1 and SHA-256"
> 
> Should we really mention SHA-1 and SHA-256 ?
>
> 21. Page 10.
> 
>   "since SHA-1 requires 2^80 work factor where 160 is the bit-length of the hash value of SHA-1".
> 
> Is the work factor really 2^80 ?

Concerning about SHA-1, SHA-256, please refer to answer of comment 10. 

And the text will be changed to :
The security of a SIM value is created by the hashing of the R, SIItype and SII values. A SIM value depends on two properties of a hash function; the fact that the it cannot be inverted and the fact that collisions (especially with correctly formatted data) are rare. The current attacks by [WANG] are not applicable to SIM values since the end-entity supplying the SII and SIItype values does not supply all of the data being hashed. Some of the SIM value is provided by the RA in the form of R value.

Jaeho Yoon



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 j7HHxF5J071676; Wed, 17 Aug 2005 10:59:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HHxFos071675; Wed, 17 Aug 2005 10:59:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7HHxEOT071664 for <[e-mail]>; Wed, 17 Aug 2005 10:59:14 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 28132 invoked by uid 0); 17 Aug 2005 17:59:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.37.210) by woodstock.binhost.com with SMTP; 17 Aug 2005 17:59:08 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 17 Aug 2005 13:57:06 -0400
To: Aram Perez <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Can't find info on certificate validity dates
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>

It is best if all of the certificates that will be validated by a given CA 
certificate have a notAfter data that is earlier (or the same) as the the 
notAfter date in the CA certificate.

If the CA certificate is renewed (the same subject name and the same public 
key are used with a different validity period), it is possible to avoid 
this dependence.  However, I believe that most CAs will change their key 
pair when a new certificate is needed.

Russ

At 07:58 PM 8/11/2005, Aram Perez wrote:
>Hi Folks,
>
>Is there an RFC that talks about the validity dates on CA
>certificates and the validity dates for the certificates it (the CA)
>issues? For example, if a "conformant" CA certificate has a notAfter
>date of Dec. 31, 2005, should it issue certificates that have a
>notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and
>couldn't find anything related to my question. The cert path
>validation algorithm of 3280 only mentions that the current time be
>within the validity dates of the cert being processed.
>
>Thanks,
>Aram Perez
>



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 j7H0UbIq013431; Tue, 16 Aug 2005 17:30:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H0UbGS013430; Tue, 16 Aug 2005 17:30:37 -0700 (PDT)
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 j7H0UZfp013419 for <[e-mail]>; Tue, 16 Aug 2005 17:30:36 -0700 (PDT) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7H0UTii025913 for <[e-mail]>; Tue, 16 Aug 2005 20:30:30 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7H0UTYp271962 for <[e-mail]>; Tue, 16 Aug 2005 20:30:29 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7H0UTfU013748 for <[e-mail]>; Tue, 16 Aug 2005 20:30:29 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7H0UT8P013741; Tue, 16 Aug 2005 20:30:29 -0400
In-Reply-To: <[e-mail]>
To: David Chadwick <[e-mail]>
Cc: PKIX <[e-mail]>
MIME-Version: 1.0
Subject: Re: Where to store SRV based names
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 16 Aug 2005 20:30:26 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 08/16/2005 20:30:28, Serialize complete at 08/16/2005 20:30:28
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>

        David:

        We shouldn't use the OID assigned to the subjectAltName extension. 
 Instead we should assign a new OID, to be assigned to an OTHER-NAME.  We 
also can't use PrintableString with Stefan's syntax, because 
PrintableString doesn't include underscore and the SRV key normally 
contains underscores.  So what is the right string type: IA5String, 
VisibleString (a tighter fit than IA5String, but less familiar), or 
UTF8String (internationalizable)?
        I agree with the general approach of defining a syntax which can 
be used either within GeneralName or in a directory attribute.

                Tom Gindin






David Chadwick <[e-mail]>
Sent by: [e-mail]
08/11/2005 05:25 AM
 
        To:     PKIX <[e-mail]>
        cc: 
        Subject:        Where to store SRV based names



As a result of my previous message and the various replies to it, it 
seems like the arguments against using the subjectDirectoryAttributes 
extension to store the attribute are

i) we only have a hammer, so the extension has to be a nail (i.e. we 
only support subjectAltNames (and not SDA) so it has to go there), and

ii) since attributes can be anything, we dont want to use them to store 
this attribute, since attributes are a catch all.

I dont actually find either arguement technically convincing, although I 
do find i) pragmatically convincing. (But if we were to extend this 
argument PKIX could have been stillborn, because by using this argument 
we could have said ten years ago that few people were supporting 
certificate extensions so lets not use any of them :-)

However, I do have a solution to offer as follows. Assume that n.n.n is 
the OID assigned to the subjectAltNames extension. The we define the 
following attribute using this OID

srvName ATTRIBUTE                ::=             {
WITH SYNTAX                              PrintableString (SIZE (1..128))
EQUALITY MATCHING RULE                           caseIgnoreMatch
ID                               n.n.n }

By doing this we ensure:
i) the extension will be carried in the subjectAltNames extension
ii) the syntax and matching rules for the srv string are fully and 
compactly defined
iii) If anyone also wanted to store the string in LDAP as an attribute 
they could do so using the above definition.

regards

David


-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: [phone]
Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.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 j7G7SH7k014958; Tue, 16 Aug 2005 00:28:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G7SHkI014957; Tue, 16 Aug 2005 00:28:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mizar.origin-it.net (mail.de.atosorigin.com [194.8.96.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G7SFds014911 for <[e-mail]>; Tue, 16 Aug 2005 00:28:16 -0700 (PDT) (envelope-from [e-mail])
Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68]) by mizar.origin-it.net (8.13.3/8.13.3/hmo30jul04) with ESMTP id j7G7S9bt086876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 16 Aug 2005 09:28:09 +0200 (CEST) (envelope-from [e-mail])
Received: from ascalon.mpn.de.int.atosorigin.com (ascalon.mpn.de.int.atosorigin.com [161.90.190.36]) by matar.hbg.de.int.atosorigin.com (8.13.3/8.13.3/hmo30jul04) with ESMTP id j7G7S9NB001698 for <[e-mail]>; Tue, 16 Aug 2005 09:28:09 +0200 (CEST) (envelope-from [e-mail])
Received: by ascalon.mpn.de.int.atosorigin.com with Internet Mail Service (5.5.2653.19) id <Q5DX4BAH>; Tue, 16 Aug 2005 09:29:00 +0200
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: WG: Can't find info on certificate validity dates
Date: Tue, 16 Aug 2005 09:28:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 j7G7SGds014950
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>

-----Ursprüngliche Nachricht-----
Von: Beckmann, Thomas 
Gesendet: Freitag, 12. August 2005 10:17
An: 'Aram Perez'
Betreff: AW: Can't find info on certificate validity dates


Aram,

it's a matter of policy. In gerneral a CA is not prohibited to issue
certificates with a notAfter entry later than the notAfter entry in the CA
certificate.
In the context of the german signature act this is done almost ervery time
because the root is only valid one year and enduser certificates can be
valid up to five years. The idea behind is to have a validation mechanism
different from them PEM and PKIX one. A signature is not checked valid a the
actual time at the time of signature creation. I. e. a certificate should
have been valid at the time of signature creation and can be invalid now but
the signature is still valid.

I hope this helps

Regards

Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: [e-mail]
> [mailto:[e-mail]]Im Auftrag von Aram Perez
> Gesendet: Freitag, 12. August 2005 01:59
> An: [e-mail]
> Betreff: Can't find info on certificate validity dates
> 
> 
> 
> Hi Folks,
> 
> Is there an RFC that talks about the validity dates on CA  
> certificates and the validity dates for the certificates it (the CA)  
> issues? For example, if a "conformant" CA certificate has a notAfter  
> date of Dec. 31, 2005, should it issue certificates that have a  
> notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and  
> couldn't find anything related to my question. The cert path  
> validation algorithm of 3280 only mentions that the current time be  
> within the validity dates of the cert being processed.
> 
> Thanks,
> Aram Perez
> 
> 



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 j7G1lVo9031753; Mon, 15 Aug 2005 18:47:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G1lVUb031752; Mon, 15 Aug 2005 18:47:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G1lUpw031746 for <[e-mail]>; Mon, 15 Aug 2005 18:47:30 -0700 (PDT) (envelope-from [e-mail])
Received: from phys-ha14sca-2.sfbay.sun.com ([129.145.155.211]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7G1lTBN006680 for <[e-mail]>; Mon, 15 Aug 2005 19:47:29 -0600 (MDT)
Received: from [192.18.148.182] by ha14sca-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2 Patch 1 (built Jan 31 2005)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 15 Aug 2005 18:47:27 -0700 (PDT)
Date: Mon, 15 Aug 2005 18:45:20 -0700
From: Julien Pierre <[e-mail]>
Subject: Re: Can't find info on certificate validity dates
In-reply-to: <5.1.0.14.0.20050812085708.02aac8f0@172.16.146.192>
To: "Kazin, Joel" <[e-mail]>
Cc: Aram Perez <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms050800070009030100050908
X-Accept-Language: en-us, en
References: <5.1.0.14.0.20050812085708.02aac8f0@172.16.146.192>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7.8) Gecko/20050512
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.

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

Kazin, Joel wrote:

> My recollection is that RFC 3280 is silent on the issue.  The 
> Microsoft 2003 CA will not sign certificates that have a notAfter date 
> that is greater than its own signing certificate.

If there is no override for this, that sounds like an unfortunate 
restriction. The CA can always choose to renew its own certificate at a 
later date, which would then allow the EE cert to be validated until its 
expiration date. Perhaps it was done this way because the clients don't 
have an automatic way to update the renewed CA cert when/if it is made 
available .


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJmzCC
AygwggKRoAMCAQICAw5X7zANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMzI1MDAwNTM1WhcNMDYwMzI1MDAwNTM1
WjCBgzEPMA0GA1UEBBMGUGllcnJlMQ8wDQYDVQQqEwZKdWxpZW4xFjAUBgNVBAMTDUp1bGll
biBQaWVycmUxJDAiBgkqhkiG9w0BCQEWFWp1bGllbi5waWVycmVAc3VuLmNvbTEhMB8GCSqG
SIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAvS98p2nm3vre0L1suVDR2cCdRNgz2WUcBwYKhkiHz9JvwiDSoM2htuG9X5U81Zg9
fZgA8MnN2R6Ox0glpHYAM/A0dvN5tuoF/eD0thdbc1p7cUeJ1Pk4c3txNtpuo+s7/2zK+ykM
DCLFpslsBDgUZU1m+p+103xGrUK3gIV7a1rVbfUjk4mLP7A4V45beErr/LKGQgFIRBzkW1Iv
fOWvk10J2j6ne0CrlS1gmRlcjdGUIwMZAA5vwI3CpU2Mz/VS8rj+VzkUmtHMaDIPBVrCFrmC
BJyVkWTzy7akP4DMSl7ZjBDXjxejI/lu+lE/RGxYsLn/8rsuoCq28Z3DF2zS8wIDAQABo0Yw
RDA0BgNVHREELTArgRVqdWxpZW4ucGllcnJlQHN1bi5jb22BEm1hZGJyYWluQHJhd2J3LmNv
bTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAHQcuvn2efqZpJImLT6CvbLZw/eh
D+IKz/ZcAb250hQLyw/9TUnoPZpaSA1VA4ECv/7vFMuegqtnXUi84kSU4ZZzth2TjrrccHZK
/cUabvipb3PS+gJdUedULMLY17K8o3s9412Io4+OTeENtzmGNk9awlNXi4W4f0vDCd6r/uKT
MIIDKDCCApGgAwIBAgIDDlfvMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYD
VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNTAzMjUwMDA1MzVaFw0wNjAzMjUwMDA1
MzVaMIGDMQ8wDQYDVQQEEwZQaWVycmUxDzANBgNVBCoTBkp1bGllbjEWMBQGA1UEAxMNSnVs
aWVuIFBpZXJyZTEkMCIGCSqGSIb3DQEJARYVanVsaWVuLnBpZXJyZUBzdW4uY29tMSEwHwYJ
KoZIhvcNAQkBFhJtYWRicmFpbkByYXdidy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQC9L3ynaebe+t7QvWy5UNHZwJ1E2DPZZRwHBgqGSIfP0m/CINKgzaG24b1flTzV
mD19mADwyc3ZHo7HSCWkdgAz8DR283m26gX94PS2F1tzWntxR4nU+Thze3E22m6j6zv/bMr7
KQwMIsWmyWwEOBRlTWb6n7XTfEatQreAhXtrWtVt9SOTiYs/sDhXjlt4Suv8soZCAUhEHORb
Ui985a+TXQnaPqd7QKuVLWCZGVyN0ZQjAxkADm/AjcKlTYzP9VLyuP5XORSa0cxoMg8FWsIW
uYIEnJWRZPPLtqQ/gMxKXtmMENePF6Mj+W76UT9EbFiwuf/yuy6gKrbxncMXbNLzAgMBAAGj
RjBEMDQGA1UdEQQtMCuBFWp1bGllbi5waWVycmVAc3VuLmNvbYESbWFkYnJhaW5AcmF3Yncu
Y29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAdBy6+fZ5+pmkkiYtPoK9stnD
96EP4grP9lwBvbnSFAvLD/1NSeg9mlpIDVUDgQK//u8Uy56Cq2ddSLziRJThlnO2HZOOutxw
dkr9xRpu+Klvc9L6Al1R51QswtjXsryjez3jXYijj45N4Q23OYY2T1rCU1eLhbh/S8MJ3qv+
4pMwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMG
A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0
ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u
MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEW
HHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2
MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0
eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9
zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPP
K9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGj
gZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw
KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEB
BQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9
reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo0
5RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw5X7zAJBgUrDgMCGgUAoIIBpzAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MTYwMTQ1MjBa
MCMGCSqGSIb3DQEJBDEWBBQKskoXFBU9d+dPW0PfQHzsHT22cTBSBgkqhkiG9w0BCQ8xRTBD
MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN
BggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u
YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDlfvMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw5X7zANBgkqhkiG9w0B
AQEFAASCAQBNUUwI2WrvX2+R6LAapgtYWaild1U2zhxbmbf0RXtCTH+OIBGudBG+QMvmLVqw
j5KKIRpRbIeCxeHdRIvC33H11mpmMt4EFS5SjCA/7ffdDbNVK/acQaciZIzdA1np5pcF8jQY
ItjrkL+lNmTTJ1XfuPDnEtObPYl0vvmtU1cYY3+ViBLowuVWSH2//BpsXNAmzWaH3SE38qjz
+Ur56DLu70nTH3U6jSpyGiRZAsSZw/GEnNUcQRYhOBlFAUO4JSnQcrSoZw8/92FB7zu6pfAz
R3SV7IVHfUH2M4XdMfA79B77kuS1Vi65OTHVkZCE3EZQZ55+e/rOaNzFxVOvweDVAAAAAAAA

--------------ms050800070009030100050908--



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 j7FJo32C000327; Mon, 15 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FJo3eC000326; Mon, 15 Aug 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FJo25v000320 for <[e-mail]>; Mon, 15 Aug 2005 12:50:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E4ky9-0002qd-LF; Mon, 15 Aug 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-09.txt 
Message-Id: <[e-mail]>
Date: Mon, 15 Aug 2005 15:50:01 -0400
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 
                          Operational Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-09.txt
	Pages		: 0
	Date		: 2005-8-15
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI).
This document specifies the conventions for using the Hypertext Transfer
Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and
certificate revocation lists (CRLs) from PKI repositories.  Additional
mechanisms addressing PKIX operational requirements are specified in separate
documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-09.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-certstore-http-09.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-certstore-http-09.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-certstore-http-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-certstore-http-09.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 j7CJo3p4040994; Fri, 12 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CJo31W040993; Fri, 12 Aug 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CJo2mq040970 for <[e-mail]>; Fri, 12 Aug 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E3fXW-0004Fi-6o; Fri, 12 Aug 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-20.txt 
Message-Id: <[e-mail]>
Date: Fri, 12 Aug 2005 15:50:02 -0400
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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-20.txt
	Pages		: 77
	Date		: 2005-8-12
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-20.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-scvp-20.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-scvp-20.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-scvp-20.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-20.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 j7CHYRVS029683; Fri, 12 Aug 2005 10:34:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CHYRQR029682; Fri, 12 Aug 2005 10:34:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CHYRTR029664 for <[e-mail]>; Fri, 12 Aug 2005 10:34:27 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.4.10] (adsl-69-232-142-170.dsl.snfc21.pacbell.net [69.232.142.170]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 12 Aug 2005 10:04:24 -0700 (PDT)
Date: Fri, 12 Aug 2005 10:34:18 -0700
From: Arshad Noor <[e-mail]>
Subject: Re: Can't find info on certificate validity dates
In-reply-to: <5.1.0.14.0.20050812085708.02aac8f0@172.16.146.192>
To: [e-mail]
Message-id: <[e-mail]>
Organization: StrongAuth, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
References: <5.1.0.14.0.20050812085708.02aac8f0@172.16.146.192>
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>

On the other hand, I am familiar with another product that provides the
flexibility to issue certificates past its own expiration date.

It is a useful operational practice in a situation where the "Root CA"
certificate of a private company is issued by a public CA and is of a
short duration (1 year), and the PKI operations team would prefer not
to reissue their internal subordinate CA certificates every year, but
just renew the "Root CA" certificate every year and publish it at their
well-known locations so cert-chain validation can continue as usual.
This does help in optimizing some operational procedures when the
key-pair for the "Root CA" does not change.

Arshad Noor
StrongAuth, Inc.


Kazin, Joel wrote:
> My recollection is that RFC 3280 is silent on the issue.  The Microsoft 
> 2003 CA will not sign certificates that have a notAfter date that is 
> greater than its own signing certificate.
> 
> At 06:58 PM 8/11/2005 -0500, Aram Perez wrote:
> 
>> Hi Folks,
>>
>> Is there an RFC that talks about the validity dates on CA 
>> certificates and the validity dates for the certificates it (the CA) 
>> issues? For example, if a "conformant" CA certificate has a notAfter 
>> date of Dec. 31, 2005, should it issue certificates that have a 
>> notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and 
>> couldn't find anything related to my question. The cert path 
>> validation algorithm of 3280 only mentions that the current time be 
>> within the validity dates of the cert being processed.
>>
>> Thanks,
>> Aram Perez 
> 
> 
> Joel S. Kazin CPA, CISA, CISSP, CISM
> Senior Consultant
> Atos Origin
> 40 Old Sleepy Hollow Road
> Pleasantville, New York 10570-3802
> USA
> Phone  [phone]
> Mobile  [phone]
> email    [e-mail]
> www.atosorigin.com
> <http://www.atosorigin.com/>
> 



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 j7CFkLpg021410; Fri, 12 Aug 2005 08:46:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CFkLa7021409; Fri, 12 Aug 2005 08:46:21 -0700 (PDT)
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 j7CFkKZQ021384 for <[e-mail]>; Fri, 12 Aug 2005 08:46:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j7CFjxDd026177; Fri, 12 Aug 2005 11:45:59 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p0623091bbf227409c983@[128.89.89.106]>
Date: Fri, 12 Aug 2005 11:46:05 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: PKIX meeting minutes, final
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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>

PKIX WG Meeting 8/2/05

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]> & Tim Polk <[e-mail]>

The PKIX WG met once during the 63nd IETF. A total of approximately 
53 individuals participated in the meeting.


Document status - Tim Polk (NIST)

	Two new RFCs (PK Algorithms and Permanent Identifier) have 
been issued since the last meeting. Four additional documents have 
been approved by the IESG and are in the RFC editor's queue 
(Certificate path building, warranty extension, 2510bis and 2511bis). 
Three documents are being reviewed by the ADs (AC policies, CertStire 
HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for 
SIM will be initiated after this IETF meeting. More detailed 
discussions of 3280bis and SCVP will follow. (see slides)

PKIX WG Document Presentations


SRV RR otherName - Stefan Santesson (Microsoft)
	This individual submission is being adopted by PKIX. The 
proposal specifies a way to embed a service name in a certificate, 
employing the syntax used to identify a service in DNS SRV records. 
The intent is to securely bind the DNS-specified service to a named 
entity, using the otherName type of GeneralName to carry the 
specified SRV RR query string. Denis noted that this proposal is a 
somewhat odd use of the subject alt name, in that the string is not 
the name of the certificate subject, but the name of a service 
provided by this subject. Instead he proposed use of the subject 
directory attributes extension. Others objected to this specific way 
of binding service authorization info to a certificate, vs. other 
approaches, e.g., EKU, or other subject alt name forms. There was 
general agreement that the proposal needs to be carefully vetted by 
DNS experts. (see slides)

Simple Certificate Validation Protocol (SCVP) - Tim Polk (NIST)
	IPR issues have been resolved since the last IETF meeting. 
Russ Housely said that CoreStreet indicated that compliant SCVP 
implementations could be developed that would not infringe their 
patents. However, Russ also reminded attendees that ultimately each 
vendor needs to evaluate the formal, legal statements from 
CoreStreet. The base specification has not changed significantly 
since the -18 draft. The draft meets most of the requirements 
specified in RFC 3379, but return of (relayed) SCVP responses was not 
included. This will be fixed in the next draft. Also, the conformance 
requirements seem to impose undue burdens on all clients, contrary to 
the goal of supporting thin clients. Remaining open issues will be 
discussed on the list, e.g., syntax details. (see slides)

SCVP Open Issues - Denis Pinkas (Bull)
	Denis emphasizes the need for thin clients, e.g., on cell 
phones, to be supported. Denis suggested that several OPTIONAL fields 
should be omitted to facilitate thin client support. However, because 
these are optional, it appears that the document can be worded to 
ensure that they impose no burden on a client that does not wish to 
invoke them. Denis would like to see a facility to allow per-trust 
anchor validation parameters, obviously not for thin clients, since 
only a sophisticated client would be able to take advantage of this 
facility. Denis also would like to represent both the validation 
policy and validation algorithm into a single OID. It was agreed that 
the URI pointer to a policy will be deleted. Is also was agreed that 
the terms "validation policy" and "validation algorithm" need to be 
better defined in the document. (see slides)

3280bis - Tim Polk (NIST)
	A new draft has been submitted with relatively minor 
enhancements. Several open issues remain to be resolved. In 
particular, questions involving name ambiguity have been raised, 
particularly as they impact CRL validation. We may deal with this 
issue by adding text in the security considerations section that 
discusses this issue. The text has been changed to clarify what 
conforming CAs MUST do in issuing a certificate, vs. what conforming 
RPs MUST do re certificate path processing. The path validation 
algorithm notes that it accepts paths that are X.509 compliant, but 
not PKIX compliant, in support of interoperability. Peter Sylvester 
asked whether there would be support to help him write a defect 
report against x.509 concerning the change of the name of the 
non-repudiation bit, since this change breaks applications that are 
based on standard ASN.1 compiler outputs (and it changes the XER 
encoding on the wire). (see slides)

3280bis Open Issues - Denis Pinkas (Bull)
	Denis reviewed seven topics that he considers open issues. He 
suggests that text on TA key update should be explicitly covered 
here, not just a reference to RFC 2510. He also suggests that we find 
a better compromise with the latest X.509 technical corrigendum, with 
respect to key usage. Denis reviewed the name ambiguity debate that 
has taken place on the list. He suggested that the private key usage 
extension not be deprecated universally, but rather be allowed in 
certain contexts, e.g., time stamp crypto modules. He proposed to 
soften the prohibition against private key usage or to delete annex 
D.1. (and thus annex D) which is the only section that
addresses this topic. Denis asked for a simplified revocation status 
checking algorithm description, that addresses only the PKIX-mandated 
certificate extensions. He also suggests clarification of the text 
that says what CRLs are "available" in the local cache. Finally, 
Denis discussed several subtle issues associated with indirect CRLs. 
At the microphone a series of individuals responded to Denis's 
suggestions, most disagreed with one of more of his points. (see 
slides)


Related Specifications & Liaison Presentations

CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf 
of ETSI TC ESI)
	This document is based on RFC 3126 and is aligned with a 
re-issue of ETSI TS 101 733. CAdES is a new name, intended to 
distinguish it from the XML-based version spec. Denis said that the 
document now presents the basic electronic signature formats in the 
main body of the document while placing features to achieve the 
maintenance of long term signatures in informative annexes, thus the 
informative annexes may equally be interesting. (see slides)

XKMS - Stephen Farrell (on behalf of W3C)
	This presentation noted that the XKMS specification in W3C 
was completed and multiple interoperable implementations have been 
tested. Interested PKIX members are encouraged to visit the W3C web 
site and review the spec. (no slides)



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 j7CCwHrt006737; Fri, 12 Aug 2005 05:58:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CCwHPN006736; Fri, 12 Aug 2005 05:58:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CCwGpg006725 for <[e-mail]>; Fri, 12 Aug 2005 05:58:16 -0700 (PDT) (envelope-from [e-mail])
Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id 8FAD55FE33; Fri, 12 Aug 2005 07:57:46 -0500 (CDT)
Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id <PPMW6BXH>; Fri, 12 Aug 2005 07:57:46 -0500
Message-ID: <5.1.0.14.0.20050812085708.02aac8f0@172.16.146.192>
From: "Kazin, Joel" <[e-mail]>
To: Aram Perez <[e-mail]>, [e-mail]
Subject: Re: Can't find info on certificate validity dates
Date: Fri, 12 Aug 2005 07:59:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59F3D.6F564B78"
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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C59F3D.6F564B78
Content-Type: text/plain;
	charset="iso-8859-1"

My recollection is that RFC 3280 is silent on the issue.  The Microsoft 2003
CA will not sign certificates that have a notAfter date that is greater than
its own signing certificate.

At 06:58 PM 8/11/2005 -0500, Aram Perez wrote:



Hi Folks, 

Is there an RFC that talks about the validity dates on CA  
certificates and the validity dates for the certificates it (the CA)  
issues? For example, if a "conformant" CA certificate has a notAfter  
date of Dec. 31, 2005, should it issue certificates that have a  
notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and  
couldn't find anything related to my question. The cert path  
validation algorithm of 3280 only mentions that the current time be  
within the validity dates of the cert being processed. 

Thanks, 
Aram Perez 


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  [phone]
Mobile  [phone]
email    [e-mail]
www.atosorigin.com <http://www.atosorigin.com/> 



------_=_NextPart_001_01C59F3D.6F564B78
Content-Type: text/html;
	charset="iso-8859-1"

<html>



<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
My recollection is that RFC 3280 is silent on the issue.&nbsp; The
Microsoft 2003 CA will not sign certificates that have a notAfter date
that is greater than its own signing certificate.<br><br>
At 06:58 PM 8/11/2005 -0500, Aram Perez wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Hi Folks,</font>
<br><br>
<font size=2>Is there an RFC that talks about the validity dates on CA&nbsp; </font><br>
<font size=2>certificates and the validity dates for the certificates it (the CA)&nbsp; </font><br>
<font size=2>issues? For example, if a &quot;conformant&quot; CA certificate has a notAfter&nbsp; </font><br>
<font size=2>date of Dec. 31, 2005, should it issue certificates that have a&nbsp; </font><br>
<font size=2>notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and&nbsp; </font><br>
<font size=2>couldn't find anything related to my question. The cert path&nbsp; </font><br>
<font size=2>validation algorithm of 3280 only mentions that the current time be&nbsp; </font><br>
<font size=2>within the validity dates of the cert being processed.</font> <br><br>
<font size=2>Thanks,</font> <br>
<font size=2>Aram Perez</font> </blockquote>
<x-sigsep><p></x-sigsep>
<br>
Joel S. Kazin CPA, CISA, CISSP, CISM<br>
Senior Consultant<br>
Atos Origin<br>
40 Old Sleepy Hollow Road<br>
Pleasantville, New York 10570-3802<br>
USA<br>
Phone&nbsp; [phone]<br>
Mobile&nbsp; [phone]<br>
email<x-tab>&nbsp;&nbsp;&nbsp;</x-tab> [e-mail]<br>
<a href="http://www.atosorigin.com/" eudora="autourl">www.atosorigin.com<br>
</a></html>

------_=_NextPart_001_01C59F3D.6F564B78--



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 j7C9qZN1085280; Fri, 12 Aug 2005 02:52:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C9qZ2S085279; Fri, 12 Aug 2005 02:52:35 -0700 (PDT)
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 j7C9qX4u085262 for <[e-mail]>; Fri, 12 Aug 2005 02:52:34 -0700 (PDT) (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 MAA15504; Fri, 12 Aug 2005 12:08:41 +0200
Received: from bull.net ([129.181.81.32]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005081211541748:736 ; Fri, 12 Aug 2005 11:54:17 +0200 
Message-ID: <[e-mail]>
Date: Fri, 12 Aug 2005 11:52:31 +0200
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: last call for SIM
References: <p06230908bf1d686988af@[128.33.244.163]>
In-Reply-To: <p06230908bf1d686988af@[128.33.244.163]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/08/2005 11:54:18, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/08/2005 11:54:20, Serialize complete at 12/08/2005 11:54:20
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; 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>

Steve,

Herafter are my comments for the WG last call.

1. Page 2 :

   "Where the subject is a person, the name that is specified in the
   subject field of the certificate typically reflects the legal name of
   the individual and affiliated entities (e.g., their corporate
   affiliation)".

"legal name" should not be used.

Change into:

   Where the subject is a person, the name that is specified in the
   subject field of the certificate may reflect the name of
   the individual and affiliated entities (e.g., their corporate
   affiliation).

2. Page 2:

   "Therefore, privacy sensitive identifiers cannot be included in
   certificates as plaintext".

There is a case which should be mentioned. Using some QCStatements
it is possible to include the hash of a picture or of a fingerprint
in a certificate. This respects privacy and if the picture is sent,
it can be matched against the hash. ESTI has defined such QCStatements
in ETSI TS 101 862.

This is very analogous. In PEPSI a "short" character string is used,
whereas when a picture or a fingerprint is used the complexity from
PEPSI is not needed. Users should be informed that there exists an
alternative to PEPSI.

3. Page 3 :

   "Furthermore, the subject can prove to the
   relying party that they are associated with a valid identification
   without disclosing the identifier. For example, a person could prove
   they possessed a valid social security number without disclosing the
   identifier itself."

These sentences are unclear. What is the identifier ? It is the social
security number ?

4. Page 3 :

   "In addition, this document defines an Encrypted PEPSI(EPEPSI) so that
   sensitive identifier information can be exchanged without disclosing
   the identifier".

Later on it can be discovered that this is only useful for a RA - CA 
protocol
but this sentence may let think it is appropriate in a client-server 
protocol.
This should be clarified.

5. Page 4. Typo :

     - The CA can treat the PEPSI as an additional name form in the
       "subjectAltName" extesnion with no special processing; and
                        ^^^^^^^^^

6. Page 5:

   "If Alice wishes to prove she has a valid identifier, without
   disclosing it, then steps 7 and 8 are as follows:"

It should be mentioned that using this method Bob could "impersonate"
Alice using the same protocol with another party. This should be addressed
in the security considerations section. This is fact the most severe
limitation of PEPSI.


7. Page 5. Typo:

       H()        Cryptographically secure hash algorithm.
                  SHA-1[FIPS 180-1] or more secure hash function is
                  specification required.
                  ^^^^^^^^^^^^^
The above sentence is not English.


8. Page 6. Typo:

   difficult to guess and long enough to protect against bute force
                                                         brute

9. Page 7. Typo:

   A The RA generates a random number, R. A new R MUST be generated for
   ^^^^^


10. Page 7:

   "One of SHA-1 or SHA-256
   MUST be used for ensuring the integrity of PEPSI."

Since an OID is permitted, any kind of hash function may be used.


11. Page 7. Typo:

   "it may be required where the CA itself verifies SII before issuing
                       ^^^^^
   the certificate"


12. Page 7.

   To meet this requirement, RAs SHOULD encrypt the
   SIItype, SII, and PEPSI with the CA's public key

Usually a CA has no public key for encryption but only a public signing key.
All the features related to the dialog with the CA should be placed in a
separate section that is NOT mandatory to implement to claim conformance
with this specification. In particular EPEPSI should be not mandatory to 
implement.


13. Page 8.

   "As described above, the certificate request message MAY contain the
   PEPSI. [RFC2314] and [RFC2511] are widely used message syntaxes for
   certification requests".

This is not possible since it is said that R is generated by the RA.


14. Page 8. Typo. The following sentence has no end.

   "The PEPSI SHOULD be included in the attribute field of ????"


15. Page 8. Typo.

   "A CA issue certificate containing the SIM as a form of otherName from
         ^^^^^ ^^^^^^^^^^^

16. Page 9.

   "Before calculating a PEPSI, conforming implementations MUST process
   the userPassword with the six step [LDAPBIS STRPREP] string
   preparation algorithm as follows":

[LDAPBIS STRPREP] is only an I-D it is not possible to refer to an I-D
that is an informative reference and use a MUST.


17. Page 9. Typo.

      * In step 2, Map, the mapping shall include procedssing of
                                                  ^^^^^^^^^^^

18. Page 10. Typos.

   Threfore, a certificate user transmit simply the password, P, and the
   ^^^^^^^^^                    ^^^^^^^^

19. Page 10. Typo.

   For the last speical use case that a certificate user want to
                ^^^^^^^
   disclose his SII, the only information sent by a ceritificate user is
                                                    ^^^^^^^^^^^^

20. Page 10.

   "A cryptographically secure hash function such as SHA-1 and SHA-256"

Should we really mention SHA-1 and SHA-256 ?


21. Page 10.

   "since SHA-1 requires
   2^80 work factor where 160 is the bit-length of the hash value of
   SHA-1".

Is the work factor really 2^80 ?


22. Page 12. typo.

   illumination. Also, thanks for Russell Housely, Stephen Kent for
                                          ^^^^^^^
Denis

> As per discussions at the IETF meetings last week, I am initiating WG 
> last call on this document:
>
> Internet X.509 Public Key Infrastructure Subject Identification Method 
> (SIM) <draft-ietf-pkix-sim-05.txt>
>
> Although we received a few suggestions for changes, these can be 
> folded in during last call, rather than  waiting for a 06 draft.
>
> The last call will be for 2 weeks.  I will be away on vacation when it 
> ends.  Tim has recused himself from this last call since he is a 
> co-author. So, when I return from vacation and plow through all the 
> e-mail, I'll get back to the list on this topic, after labor day (Sept 
> 6).
>
> 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 j7C8Z5vS079931; Fri, 12 Aug 2005 01:35:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C8Z5CX079928; Fri, 12 Aug 2005 01:35:05 -0700 (PDT)
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 j7C8Z3Ah079870; Fri, 12 Aug 2005 01:35:04 -0700 (PDT) (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 KAA16080; Fri, 12 Aug 2005 10:51:16 +0200
Received: from bull.net ([129.181.81.22]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005081210365403:713 ; Fri, 12 Aug 2005 10:36:54 +0200 
Message-ID: <[e-mail]>
Date: Fri, 12 Aug 2005 10:35:08 +0200
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: S-MIME / IETF <[e-mail]>
CC: pkix <[e-mail]>
Subject: CAdES: <draft-pinkas-smime-cades-01.txt>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/08/2005 10:36:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/08/2005 10:36:55, Serialize complete at 12/08/2005 10:36:55
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>

The I-D for CMS Advanced Electronic Signatures (CAdES) has been updated
to correct a few typos and ASN.1 errors in the ASN.1 modules.

It is now available at:

http://www.ietf.org/internet-drafts/draft-pinkas-smime-cades-01.txt

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 j7BNx8GD024963; Thu, 11 Aug 2005 16:59:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BNx8Zi024962; Thu, 11 Aug 2005 16:59:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7BNx8iV024953 for <[e-mail]>; Thu, 11 Aug 2005 16:59:08 -0700 (PDT) (envelope-from [e-mail])
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7BNx0S0001637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 11 Aug 2005 16:59:01 -0700 (PDT)
Received: from [129.46.159.211] (boricubano.qualcomm.com [129.46.159.211]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7BNwwVF003641 for <[e-mail]>; Thu, 11 Aug 2005 16:58:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v733)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: [e-mail]
From: Aram Perez <[e-mail]>
Subject: Can't find info on certificate validity dates
Date: Thu, 11 Aug 2005 16:58:57 -0700
X-Mailer: Apple Mail (2.733)
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 Folks,

Is there an RFC that talks about the validity dates on CA  
certificates and the validity dates for the certificates it (the CA)  
issues? For example, if a "conformant" CA certificate has a notAfter  
date of Dec. 31, 2005, should it issue certificates that have a  
notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and  
couldn't find anything related to my question. The cert path  
validation algorithm of 3280 only mentions that the current time be  
within the validity dates of the cert being processed.

Thanks,
Aram Perez



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 j7B9P243073388; Thu, 11 Aug 2005 02:25:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B9P2Qu073387; Thu, 11 Aug 2005 02:25:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-2.visp.demon.net (IDENT:[e-mail] [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B9P11t073373 for <[e-mail]>; Thu, 11 Aug 2005 02:25:02 -0700 (PDT) (envelope-from [e-mail])
Received: from [82.33.120.95] (82-33-120-95.cable.ubr01.nail.blueyonder.co.uk [82.33.120.95]) by lon1-mail-2.visp.demon.net (MOS 3.5.8-GR) with ESMTP id CPQ52369 (AUTH [e-mail]); Thu, 11 Aug 2005 10:24:59 +0100 (BST)
Message-ID: <[e-mail]>
Date: Thu, 11 Aug 2005 10:25:00 +0100
From: David Chadwick <[e-mail]>
Organization: University of Kent
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Where to store SRV based names
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>

As a result of my previous message and the various replies to it, it 
seems like the arguments against using the subjectDirectoryAttributes 
extension to store the attribute are

i) we only have a hammer, so the extension has to be a nail (i.e. we 
only support subjectAltNames (and not SDA) so it has to go there), and

ii) since attributes can be anything, we dont want to use them to store 
this attribute, since attributes are a catch all.

I dont actually find either arguement technically convincing, although I 
do find i) pragmatically convincing. (But if we were to extend this 
argument PKIX could have been stillborn, because by using this argument 
we could have said ten years ago that few people were supporting 
certificate extensions so lets not use any of them :-)

However, I do have a solution to offer as follows. Assume that n.n.n is 
the OID assigned to the subjectAltNames extension. The we define the 
following attribute using this OID

srvName ATTRIBUTE	::=	{
WITH SYNTAX		PrintableString (SIZE (1..128))
EQUALITY MATCHING RULE		caseIgnoreMatch
ID		n.n.n }

By doing this we ensure:
i) the extension will be carried in the subjectAltNames extension
ii) the syntax and matching rules for the srv string are fully and 
compactly defined
iii) If anyone also wanted to store the string in LDAP as an attribute 
they could do so using the above definition.

regards

David


-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: [phone]
Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.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 j79LTxil084234; Tue, 9 Aug 2005 14:29:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79LTxJ5084233; Tue, 9 Aug 2005 14:29:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79LTvtk084222 for <[e-mail]>; Tue, 9 Aug 2005 14:29:58 -0700 (PDT) (envelope-from [e-mail])
Received: from arport2v (62.20.229.11) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 42B94E290076777C; Tue, 9 Aug 2005 23:29:51 +0200
Message-ID: <01a701c59d29$f6d76b60$8217a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, =?iso-8859-1?Q?Philipp_G=FChring?= <[e-mail]>, "Joel Rees" <[e-mail]>
Subject: New CSR schemes - Requirements
Date: Tue, 9 Aug 2005 23:33:18 +0200
MIME-Version: 1.0
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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

Gentlemen,
Since you have both expressed interest in revised CSR schemes,
you may want to look at a recent counterpart for OTP tokens:

http://www.rsasecurity.com/rsalabs/node.asp?id=2817

Compared to PKCS #10 and CRMF, CT-KIP is:
1. XML based
2. Multi pass

That is, revising existing RFCs is not likely to be a good idea since
on-line certification needs multi-pass protocols in order to support
users with limited, or no knowledge of PKI.  Certificate renewal
also requires mult-pass including an atomic replacement operation.

A difference with on-line certification schemes compared to for example
the creation of web-server certificates is that in the former case the CA
is usually the originator of all vital information including key length, subject
DN etc.  This is principally about the opposite of PKCS #10 and CRMF.

So IMHO a new CSR scheme should [at least] allow the CA to define
- key length and type
- PIN/passphrase policy
- key export policy
- All but the public key of the EE certificate(s) to be generated

As well as optionally requiring HW key container PoP & ID.

The goal must be to eliminate as much as possible, any requirements on
the user regarding answering questions that they would never have to
bother with if they got a token distributed in a physical form, while still
providing for a secure process.

Using XML it would not be a PKIX work item.  PKIX is also said to
be shutting down so in case you are interested in such a task we must
find another home for it.

Comments?

Anders Rundgren



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 j79DMRKN027536; Tue, 9 Aug 2005 06:22:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79DMRJQ027535; Tue, 9 Aug 2005 06:22:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79DMPm9027473 for <[e-mail]>; Tue, 9 Aug 2005 06:22:25 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 14:22:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft minutes for comment
Date: Tue, 9 Aug 2005 14:22:14 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft minutes for comment
Thread-Index: AcWcXG40xe5pAWMhSR+zdcblPo5SSQAhxa1A
From: "Stefan Santesson" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Aug 2005 13:22:24.0694 (UTC) FILETIME=[617CCD60:01C59CE5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j79DMPm9027522
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,

I think the SRV RR text is not entirely correct. The proposal is not to
include a pointer to a SRV record. The proposal is to create a name form
that holds a service name and the domain of that service in a way that
matches the content of a dns SRV resource record (not points to it).

This might be a gradual difference but it is important one since the
name in the cert is not intended to be used to construct a dns query,
only to validate a servers authorization to provide a service.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: den 8 augusti 2005 22:16
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: Re: draft minutes for comment
> 
> 
> Denis,
> 
> >...
> >  >SRV RR otherName - Stefan Santesson (Microsoft)
> >>	An individual submission, now being adopted by PKIX. The
> >>proposal specifies a way to embed a pointer to a DNS SRV record in a
> >>certificate, to securely bind the DNS record to a named entity,
using
> >>the otherName type of GeneralName to carry the specific SRV RR query
> >>string. Denis noted that this proposal is a somewhat odd use of the
> >>subject alt name, in that the string is not the name of the
> >>certificate subject, but the name of a service provided by this
> >>subject.
> >
> >Add:
> >
> >"Denis proposed to use the subject directory attributes extension"
> >which is well suited to carry this kind of extension..
> 
> I'll add the first line.
> 
> >...
> >
> >Russ said a few words about the patent issue. I would not dare to say
it,
> >but it would be useful for the WG to know what was said in the room.
> 
> I added ytext re Russ's comments on the IPR issue.
> 
> >...
> >SCVP - Open Issues - Denis Pinkas (Bull)
> >
> >>	Denis emphasizes the need for thin clients, e.g., on cell
> >>phones, to be supported. Denis suggested that several OPTIONAL
fields
> >>should be omitted to facilitate thin client support. However,
because
> >>these are optional, it appears that the document can be worded to
> >>ensure that they impose no burden on a client that does not wish to
> >>invoke them. Denis would like to see a facility to allow per-trust
> >>anchor validation parameters, obviously not for thin clients, since
> >>only a sophisticated client would be able to take advantage of this
> >>facility. Denis also would like to represent both the validation
> >  >policy and validation algorithm into a single OID,
> >
> >Please delete: "although this seems to yield a minor space/complexity
> saving",
> >since the topic is much more important than space saving.
> 
> I deleted the text representing my value judgement on space/complexity
> savings.
> 
> >...
> >  >3280bis - Tim Polk (NIST)
> >>	A new draft has been submitted with relatively minor
> >>enhancements. Several open issues remain to be resolved. In
> >>particular, questions involving name ambiguity have been raised,
> >>particularly as they impact CRL validation.
> >
> >
> >Please delete:
> >>  We may deal with this issue by adding text in the security
> considerations
> >>  section that discusses this issue.
> >
> >Replace with: "This issue will need to be discused in the security
> >considerations
> >section and it has been proposed to add an informative annex for
> explaining
> >in more depth the issue and the solutions.
> 
> I will not make this requested change as I do not believe that it
> accurately reflects the resolution of the discussion.
> 
> >...
> >
> >3280bis - Open Issues - Denis Pinkas (Bull)
> >
> >>	Denis reviewed seven topics that he considers open issues. He
> >>suggests that text on TA key update should be explicitly covered
> >>here, not just a reference to RFC 2510. He also suggests that we
> >>align out text with the latest X.509 technical corrigendum, with
> >
> >Replace with :
> >"find a better compromise with the latest X.509 technical
corrigendum, "]
> 
> done
> 
> >  >respect to key usage. Denis reviewed the name ambiguity debate
that
> >>has taken place on the list. He suggested that the private key usage
> >>extension not be deprecated universally, but rather be allowed in
> >>certain contexts, e.g., time stamp crypto modules.
> >
> >It has been proposed to soften the prohibition against private key
usage
> >or to delete annex D.1. (and thus annex D) which is the only section
that
> >adresses this topic.
> 
> done.
> 
> >
> >>  Denis asked for a
> >>simplified revocation status checking algorithm description, that
> >>addresses only the PKIX-mandated certificate extensions. He also
> >>suggests clarification of the text that says what CRLs are
> >>"available" in the local cache. Finally, Denis discussed several
> >>subtle issues associated with indirect CRLs. At the microphone a
> >>series of individuals responded to Denis's suggestions, most
> >>disagreed with one of more of his points.
> >
> >Delete the remaining of the sentence which is:
> >
> >>, although there appeared to
> >  >be agreement to soften the prohibition against private key usage.
> 
> done.
> 
> >  >
> >>
> >>Related Specifications & Liaison Presentations
> >>
> >>CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf
> >>of ETSI TC ESI)
> >>	This document is based on RFC 3126 and is aligned with a
> >>re-issue of ETSI TS 101 733. CAdES is a new name, intended to
> >>distinguish it from the XML-based version spec.
> >
> >Add: XAdES.
> >
> >"Denis said that the document is now presenting the basic electronic
> >signature formats
> >in the main body of the document while placing the features to
> >achieve the maintenance
> >of long term signatures in informative annexes. So the informative
> >annexes may equally be
> >interresting".
> >
> I reworded this slightly and added it to the XAdES section.
> 
> 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 j79BgWik090162; Tue, 9 Aug 2005 04:42:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79BgWAO090160; Tue, 9 Aug 2005 04:42:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by above.proper.com (8.12.11/8.12.9) with SMTP id j79BgUNG090141 for <[e-mail]>; Tue, 9 Aug 2005 04:42:31 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 30788 invoked by alias); 9 Aug 2005 11:51:26 -0000
Received: from unknown (HELO ?172.16.1.133?) (10.10.10.11) by mail.ddcom.local with SMTP; 9 Aug 2005 11:51:26 -0000
In-Reply-To: <00a501c59cb6$5ac52e60$8217a8c0@arport2v>
References: <[e-mail]> <00a501c59cb6$5ac52e60$8217a8c0@arport2v>
Mime-Version: 1.0 (Apple Message framework v733)
X-Priority: 3
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: <[e-mail]>
From: Joel Rees <[e-mail]>
Subject: Re: defined format for renewal requests?
Date: Tue, 9 Aug 2005 20:40:38 +0900
To: Anders Rundgren <[e-mail]>
X-Mailer: Apple Mail (2.733)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j79BgVNG090152
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>

On 平成 17/08/09, at 16:45, Anders Rundgren wrote:

> Joel,
>
> AFAIK a CSR does not authenticate the subscriber.  That is, the CSRs
> origin is verified out OOB using a method that the CA considers  
> suitable.

Right.

> For renewals it seems logical to use the soon-to-be-expired  
> certificate
> as authentication.

That's what I expect to do.

> There are BTW two different use-cases hidden here.
> 1) Certificate renewal.
> 2) Certificate "cloning".

Not sure what you mean by cloning.

I am aware of the difference between renewing to roll the key over,  
renewing while keeping the same key, and renewing for policy or usage  
changes.

> I agree that a renewal CSR option would be nice because then the  
> original
> certificate (c|w)ould also be deleted.

So I'm safe in understanding that there are no recommended practices  
or true standards in that regard?

> Note, the latter would have to be
> implemented as an "atomic" operation in order to not create more  
> troubles
> than it was supposed to solve...

I've been assuming we would set a policy such that once a renewed  
certificate was in the VA's (Is Validation Authority in in-company  
invention?) database, the old certificate would be considered invalid  
for signing. I suppose that would require putting the old certificate  
in the CRL us "suspended", but I don't recall an appropriate standard  
reason.

It's an internal system, so we don't have to maintain standards  
compatibility, but I do want to keep the options open if there are  
any recognized best practices that don't involve mind-reading the big  
players' documentation.

> In fact, current CSR schemes are much too primitive for serious  
> uses and
> have thus been replaced by custom solutions in many cases.  For  
> example
> there is no standard way of identifying the "key container" or define
> PIN-code policies in spite of being high on most CAs whish-lists.
>
> The biggest problem is that the entire CSR-stuff is convoluted by  
> proprietary
> methods such as Microsoft's XENROLL, making progress in this area  
> hard.

I sure wish Microsoft could learn that when they let their cattle  
water upstream, they're gonna end up drinking the polluted water  
downstream just like the rest of us.

Thanks, Anders.

> Anders Rundgren
> Security Architect
>
>
> ----- Original Message -----
> From: "Joel Rees" <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, August 09, 2005 07:51
> Subject: defined format for renewal requests?
>
>
>
> Apologies in advance for the noise.
>
> I've done quick searches on what looked like the relevant RFCs and
> not really found much more than a suggestion that the renewal request
> be the same as the original certificate request. (Which would imply
> that the RA would check the database for existing certificates and
> treat, for instance, a CSR for a DN already in the database as a
> request for renewal, perhaps if it is some policy specified number of
> days before expiration? but that would seem to conflict with
> something else I read about requiring an error response if a CSR for
> a DN already issued is received.)
>
> I did find RFC 2797, and I'm trying to digest it, but a quick search
> for the word "renew" turned up
>
>     No special services are provided for doing either renewal (new
>     certificates with the same key) or re-keying (new certificates on
> new
>     keys) of clients.  Instead a renewal/re-key message looks the
> same as
>     any enrollment message, with the identity proof being supplied by
>     existing certificates from the CA.
>
> but this looks at first blush like definitions of protocols between
> servers, say the LRA and the CA?
>
> Is this perhaps primarily an implementation detail?
>
> I was thinking perhaps of defining a custom, system internal
> extension to the CSR, containing simply a flag that says this is a
> renewal request, to eliminate ambiguity. But I seem to remember that
> CSRs are v1 and thus would not have extensions?
>
> And, while I'm being the noisy newbie here, is automatic renewal
> generally preferred in implementations where there are no specific
> policy issues that would require the certificate subject to actively
> request the renewal? I've read parts of a thread or two in the
> archives that seemed to contain an assumption that renewal requests
> were not considered ordinary procedure.

Joel Rees   <[e-mail]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   [phone]
** <http://www.ddcom.co.jp> **







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 j797hGdo005603; Tue, 9 Aug 2005 00:43:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j797hGaa005602; Tue, 9 Aug 2005 00:43:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j797hF2F005551 for <[e-mail]>; Tue, 9 Aug 2005 00:43:15 -0700 (PDT) (envelope-from [e-mail])
Received: from arport2v (213.64.36.89) by pne-smtpout1-sn2.hy.skanova.net (7.2.060.1) id 42BFBBD20068CF27; Tue, 9 Aug 2005 09:43:08 +0200
Message-ID: <00a501c59cb6$5ac52e60$8217a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Joel Rees" <[e-mail]>
References: <[e-mail]>
Subject: Re: defined format for renewal requests?
Date: Tue, 9 Aug 2005 09:45:44 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

Joel,

AFAIK a CSR does not authenticate the subscriber.  That is, the CSRs
origin is verified out OOB using a method that the CA considers suitable.

For renewals it seems logical to use the soon-to-be-expired certificate
as authentication.

There are BTW two different use-cases hidden here.
1) Certificate renewal.
2) Certificate "cloning".

I agree that a renewal CSR option would be nice because then the original
certificate (c|w)ould also be deleted.  Note, the latter would have to be
implemented as an "atomic" operation in order to not create more troubles
than it was supposed to solve...

In fact, current CSR schemes are much too primitive for serious uses and
have thus been replaced by custom solutions in many cases.  For example
there is no standard way of identifying the "key container" or define
PIN-code policies in spite of being high on most CAs whish-lists.

The biggest problem is that the entire CSR-stuff is convoluted by proprietary
methods such as Microsoft's XENROLL, making progress in this area hard.

Anders Rundgren
Security Architect


----- Original Message -----
From: "Joel Rees" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, August 09, 2005 07:51
Subject: defined format for renewal requests?



Apologies in advance for the noise.

I've done quick searches on what looked like the relevant RFCs and
not really found much more than a suggestion that the renewal request
be the same as the original certificate request. (Which would imply
that the RA would check the database for existing certificates and
treat, for instance, a CSR for a DN already in the database as a
request for renewal, perhaps if it is some policy specified number of
days before expiration? but that would seem to conflict with
something else I read about requiring an error response if a CSR for
a DN already issued is received.)

I did find RFC 2797, and I'm trying to digest it, but a quick search
for the word "renew" turned up

    No special services are provided for doing either renewal (new
    certificates with the same key) or re-keying (new certificates on
new
    keys) of clients.  Instead a renewal/re-key message looks the
same as
    any enrollment message, with the identity proof being supplied by
    existing certificates from the CA.

but this looks at first blush like definitions of protocols between
servers, say the LRA and the CA?

Is this perhaps primarily an implementation detail?

I was thinking perhaps of defining a custom, system internal
extension to the CSR, containing simply a flag that says this is a
renewal request, to eliminate ambiguity. But I seem to remember that
CSRs are v1 and thus would not have extensions?

And, while I'm being the noisy newbie here, is automatic renewal
generally preferred in implementations where there are no specific
policy issues that would require the certificate subject to actively
request the renewal? I've read parts of a thread or two in the
archives that seemed to contain an assumption that renewal requests
were not considered ordinary procedure.

--
Joel Rees   <[e-mail]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   [phone]
** <http://www.ddcom.co.jp> **






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 j795rVMA057408; Mon, 8 Aug 2005 22:53:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j795rVod057407; Mon, 8 Aug 2005 22:53:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by above.proper.com (8.12.11/8.12.9) with SMTP id j795rTgS057393 for <[e-mail]>; Mon, 8 Aug 2005 22:53:30 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 16603 invoked by alias); 9 Aug 2005 06:02:26 -0000
Received: from unknown (HELO ?172.16.1.133?) (10.10.10.11) by mail.ddcom.local with SMTP; 9 Aug 2005 06:02:26 -0000
Mime-Version: 1.0 (Apple Message framework v733)
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
To: [e-mail]
From: Joel Rees <[e-mail]>
Subject: defined format for renewal requests?
Date: Tue, 9 Aug 2005 14:51:38 +0900
X-Mailer: Apple Mail (2.733)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j795rUgS057400
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>

Apologies in advance for the noise.

I've done quick searches on what looked like the relevant RFCs and  
not really found much more than a suggestion that the renewal request  
be the same as the original certificate request. (Which would imply  
that the RA would check the database for existing certificates and  
treat, for instance, a CSR for a DN already in the database as a  
request for renewal, perhaps if it is some policy specified number of  
days before expiration? but that would seem to conflict with  
something else I read about requiring an error response if a CSR for  
a DN already issued is received.)

I did find RFC 2797, and I'm trying to digest it, but a quick search  
for the word "renew" turned up

    No special services are provided for doing either renewal (new
    certificates with the same key) or re-keying (new certificates on  
new
    keys) of clients.  Instead a renewal/re-key message looks the  
same as
    any enrollment message, with the identity proof being supplied by
    existing certificates from the CA.

but this looks at first blush like definitions of protocols between  
servers, say the LRA and the CA?

Is this perhaps primarily an implementation detail?

I was thinking perhaps of defining a custom, system internal  
extension to the CSR, containing simply a flag that says this is a  
renewal request, to eliminate ambiguity. But I seem to remember that  
CSRs are v1 and thus would not have extensions?

And, while I'm being the noisy newbie here, is automatic renewal  
generally preferred in implementations where there are no specific  
policy issues that would require the certificate subject to actively  
request the renewal? I've read parts of a thread or two in the  
archives that seemed to contain an assumption that renewal requests  
were not considered ordinary procedure.

--
Joel Rees   <[e-mail]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   [phone]
** <http://www.ddcom.co.jp> **






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 j78KG9rW091161; Mon, 8 Aug 2005 13:16:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78KG96U091160; Mon, 8 Aug 2005 13:16:09 -0700 (PDT)
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 j78KG8oS091145 for <[e-mail]>; Mon, 8 Aug 2005 13:16:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.33.244.163] (col-dhcp33-244-163.bbn.com [128.33.244.163]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j78KFtDd023759; Mon, 8 Aug 2005 16:15:56 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p0623090bbf1d6baa4bd3@[128.33.244.163]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 8 Aug 2005 16:15:46 -0400
To: "Denis Pinkas" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft minutes for comment
Cc: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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,

>...
>  >SRV RR otherName - Stefan Santesson (Microsoft)
>>	An individual submission, now being adopted by PKIX. The
>>proposal specifies a way to embed a pointer to a DNS SRV record in a
>>certificate, to securely bind the DNS record to a named entity, using
>>the otherName type of GeneralName to carry the specific SRV RR query
>>string. Denis noted that this proposal is a somewhat odd use of the
>>subject alt name, in that the string is not the name of the
>>certificate subject, but the name of a service provided by this
>>subject.
>
>Add:
>
>"Denis proposed to use the subject directory attributes extension"
>which is well suited to carry this kind of extension..

I'll add the first line.

>...
>
>Russ said a few words about the patent issue. I would not dare to say it,
>but it would be useful for the WG to know what was said in the room.

I added ytext re Russ's comments on the IPR issue.

>...
>SCVP - Open Issues - Denis Pinkas (Bull)
>
>>	Denis emphasizes the need for thin clients, e.g., on cell
>>phones, to be supported. Denis suggested that several OPTIONAL fields
>>should be omitted to facilitate thin client support. However, because
>>these are optional, it appears that the document can be worded to
>>ensure that they impose no burden on a client that does not wish to
>>invoke them. Denis would like to see a facility to allow per-trust
>>anchor validation parameters, obviously not for thin clients, since
>>only a sophisticated client would be able to take advantage of this
>>facility. Denis also would like to represent both the validation
>  >policy and validation algorithm into a single OID,
>
>Please delete: "although this seems to yield a minor space/complexity saving",
>since the topic is much more important than space saving.

I deleted the text representing my value judgement on space/complexity savings.

>...
>  >3280bis - Tim Polk (NIST)
>>	A new draft has been submitted with relatively minor
>>enhancements. Several open issues remain to be resolved. In
>>particular, questions involving name ambiguity have been raised,
>>particularly as they impact CRL validation. 
>
>
>Please delete:
>>  We may deal with this issue by adding text in the security considerations
>>  section that discusses this issue.
>
>Replace with: "This issue will need to be discused in the security 
>considerations
>section and it has been proposed to add an informative annex for explaining
>in more depth the issue and the solutions.

I will not make this requested change as I do not believe that it 
accurately reflects the resolution of the discussion.

>...
>
>3280bis - Open Issues - Denis Pinkas (Bull)
>
>>	Denis reviewed seven topics that he considers open issues. He
>>suggests that text on TA key update should be explicitly covered
>>here, not just a reference to RFC 2510. He also suggests that we
>>align out text with the latest X.509 technical corrigendum, with
>
>Replace with :
>"find a better compromise with the latest X.509 technical corrigendum, "]

done

>  >respect to key usage. Denis reviewed the name ambiguity debate that
>>has taken place on the list. He suggested that the private key usage
>>extension not be deprecated universally, but rather be allowed in
>>certain contexts, e.g., time stamp crypto modules.
>
>It has been proposed to soften the prohibition against private key usage
>or to delete annex D.1. (and thus annex D) which is the only section that
>adresses this topic.

done.

>
>>  Denis asked for a
>>simplified revocation status checking algorithm description, that
>>addresses only the PKIX-mandated certificate extensions. He also
>>suggests clarification of the text that says what CRLs are
>>"available" in the local cache. Finally, Denis discussed several
>>subtle issues associated with indirect CRLs. At the microphone a
>>series of individuals responded to Denis's suggestions, most
>>disagreed with one of more of his points.
>
>Delete the remaining of the sentence which is:
>
>>, although there appeared to
>  >be agreement to soften the prohibition against private key usage.

done.

>  >
>>
>>Related Specifications & Liaison Presentations
>>
>>CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf
>>of ETSI TC ESI)
>>	This document is based on RFC 3126 and is aligned with a
>>re-issue of ETSI TS 101 733. CAdES is a new name, intended to
>>distinguish it from the XML-based version spec.
>
>Add: XAdES.
>
>"Denis said that the document is now presenting the basic electronic 
>signature formats
>in the main body of the document while placing the features to 
>achieve the maintenance
>of long term signatures in informative annexes. So the informative 
>annexes may equally be
>interresting".
>
I reworded this slightly and added it to the XAdES section.

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 j78JtgcD089849; Mon, 8 Aug 2005 12:55:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78Jtg1u089848; Mon, 8 Aug 2005 12:55:42 -0700 (PDT)
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 j78JtfNs089829 for <[e-mail]>; Mon, 8 Aug 2005 12:55:42 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.33.244.163] (col-dhcp33-244-163.bbn.com [128.33.244.163]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j78JtYDf022700 for <[e-mail]>; Mon, 8 Aug 2005 15:55:36 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p06230908bf1d686988af@[128.33.244.163]>
Date: Mon, 8 Aug 2005 15:55:40 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: last call for SIM
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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 per discussions at the IETF meetings last week, I am initiating WG 
last call on this document:

Internet X.509 Public Key Infrastructure Subject Identification 
Method (SIM) <draft-ietf-pkix-sim-05.txt>

Although we received a few suggestions for changes, these can be 
folded in during last call, rather than  waiting for a 06 draft.

The last call will be for 2 weeks.  I will be away on vacation when 
it ends.  Tim has recused himself from this last call since he is a 
co-author. So, when I return from vacation and plow through all the 
e-mail, I'll get back to the list on this topic, after labor day 
(Sept 6).


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 j78JblAW088310; Mon, 8 Aug 2005 12:37:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78JbljA088309; Mon, 8 Aug 2005 12:37:47 -0700 (PDT)
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 j78Jbkhd088279 for <[e-mail]>; Mon, 8 Aug 2005 12:37:47 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.33.244.163] (col-dhcp33-244-163.bbn.com [128.33.244.163]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j78JbcDd021817; Mon, 8 Aug 2005 15:37:38 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p06230903bf1be950ebfe@[192.168.0.100]>
In-Reply-To: <006d01c59933$338ce260$8217a8c0@arport2v>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <002a01c598c3$ef32dda0$8217a8c0@arport2v> <p0623090abf1773daa7a9@[86.255.25.238]> <006d01c59933$338ce260$8217a8c0@arport2v>
Date: Mon, 8 Aug 2005 15:36:59 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Qualified Certificate Requests - RFC
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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,

You may choose to redefine terms in your circle of friends, but for 
purposes of the list let's stick with terms that are widely accepted. 
In this case, the term has a meaning relevant to the PKI context, and 
it is not the one you espouse.

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 j78IR8v2080933; Mon, 8 Aug 2005 11:27:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78IR8Ea080932; Mon, 8 Aug 2005 11:27:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78IR7oG080926 for <[e-mail]>; Mon, 8 Aug 2005 11:27:08 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j78IR4Zh003785; Mon, 8 Aug 2005 14:27:05 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'pkix'" <[e-mail]>
Subject: RE: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Mon, 8 Aug 2005 14:26:59 -0400
Message-ID: <007e01c59c46$c68f48d0$[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.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j78IR8oG080927
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,

See the responses in-line.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Monday, August 08, 2005 12:49 PM
To: 'pkix'; Santosh Chokhani
Subject: Re: RE: RE: 3280bis: suggested words for ambiguous DNs and
delegated CRLs



Santosh,

>Denis,

>I agree that the rule of an ancestor may not be sufficient (specially 
>theoretically).  An alternative is to permit only the following:

>1.  Indirect CRL is signed using the same trust anchor DN as the 
>certificate certification path; or

Your sentence above is not crystal clear to me. 
If you only mean "same TA", then this is insufficient.

[Santosh: Let us say that the certification path for the certificate begins
with a trust anchor whose subject DN is X, then an indirect CRL can be
signed by a trust anchor whose subject DN is X.  Please note that the keys
need not be the same due to the trust anchor re-key.]

>2.  Indirect CRL is signed using an authority that is issued a 
>certificate by the same trust anchor DN as the certificate 
>certification path; or

The same applies.

[Santosh: Let us say that the certification path for the certificate begins
with a trust anchor whose subject DN is X, then an indirect CRL can be
signed by an authority which is issued a certificate by a trust anchor where
trust anchor subject DN = X.]

>3.  Certificate issuer CA delegates the Indirect CRL issuer.  In this 
>case, depending on the reason for indirect CRL, the revocation status 
>of the delegation certificate may need to contain no check or verified 
>using partitioned CRL.

I can't understand.

[Santosh: What part you do not understand?  Delegation or revocation status
checking of the indirect CRL issuer certificate?]

>The implementations I know that use Indirect CRL are consistent with 
>the above.  But, it a further constraint/profiling/change to the 
>Standard.

???

>BTW, what are the examples of "locally known constraints" and/or how 
>would you articulate these in an RFC?

Quite hard to articulate these in an RFC. The only *example* I have in mind
is 
a validation policy that is using a *single* TA, where that TA imposes to 
the CAs it certifies some naming constraints, and where these CA also impose

naming constraints on subsequent CAs. The naming constraints may be such 
that there cannot be name collisions *if these naming constraints are really

followed*.



Denis

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>Sent: Friday, August 05, 2005 7:50 AM
>To: 'pkix'; Santosh Chokhani
>Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>
>>Tom,
>
>>That would be fine for indirect CRL.
>
>This is insufficient, unless additional naming constrains are localy 
>known.
>
>> I assume you are not recommending this
>>for a direct CRL (i.e., when Cert Issuer = CRL issuer)
>
>>-----Original Message-----
>>From: Tom Gindin [mailto:[e-mail]]
>>Sent: Thursday, August 04, 2005 9:38 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated 
>>CRLs
>>
>>        Santosh:
>>
>>        Actually, I have been arguing for requiring the CRL issuer's 
>>certification path to be a subset of the subject certificate's path.  
>>I
>
>Unless additional naming constrains are localy known, this may be 
>insecure.
>
>Denis
>
>>don't see any major issue if the hierarchical superior of a CA issues 
>>a CRL signing certificate which can issue CRL's for the subordinate 
>>CA's. However, I don't see how to go beyond that.
>>
>>Tom Gindin
>
>>"Santosh Chokhani" <[e-mail]>
>>Sent by: [e-mail]
>>08/03/2005 10:17 AM
>> 
>>        To:     "'pkix'" <[e-mail]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and

>>delegated CRLs
>>
>>
>>
>>Tom Gindin,
>>
>>You seem to be arguing for matching CRL certification path with that 
>>of the certificate.
>>
>>If so, you will not get an argument from me.
>>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]
>>On
>>Behalf Of Tom Gindin
>>Sent: Tuesday, August 02, 2005 11:17 PM
>>To: Manger, James H; [e-mail]
>>Cc: pkix
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>>
>>
>>
>>        James, Santosh:
>>
>>        You certainly can construct unambiguous names for CA's, and I 
>>think that Denis already knows that (Permanent Identifier is certainly 
>>a way of constructing unambiguous names, for example).  The difficulty 
>>we have is when one issuer issues a certificate to an organizational 
>>CA with a subject name which is convenient and in common use for its 
>>organization,
>>
>>but ambiguous, and then a different issuer issues a certificate to an 
>>organizational CA with the same subject name which is also in common 
>>use for its organization.  This case is most common when both 
>>organizations use an acronym.  I do not see why the issuers of the two 
>>organizational CA
>>
>>certificates should be assumed to originate at different trust 
>>anchors, although they will be different issuers.  In fact, I don't 
>>understand why organizational name collisions are thought to be much 
>>rarer with a "common
>>
>>trust anchor" than with "different trust anchors" if the actual 
>>issuers
>>of
>>
>>the colliding certificates are both public CA's.
>>        Such collisions will have negative effects in other parts of
>>the
>>global PKI, of course.  However, unless we are prepared to issue guidance 
>>to deprecate the assignment of DN's for organizations with geographical 
>>scopes wider than the one for which they are registered and guaranteed to 
>>be unique (and many existing CA certificates have such DN's), I don't see 
>>how we can be certain or nearly certain that such collisions won't occur. 
>>A typical example of what I mean by an organization having a DN with a 
>>geographical scope wider than the one for which it's registered is a 
>>corporation registered in a single American state and operating in several

>>
>>states while having a DN without the stateOrProvinceName attribute.
>>
>>                Tom Gindin
>>
>>
>>
>>
>>
>>
>>"Manger, James H" <[e-mail]>
>>Sent by: [e-mail]
>>08/01/2005 11:05 PM
>> 
>>        To:     "pkix" <[e-mail]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and

>>
>>delegated CRLs
>>
>>
>>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know
>>the
>>trust anchors environment of the relying parties to know if the CRL issuer

>>
>>DN will be unambiguous.]
>>You can construct unambiguous DNs regardless of trust anchors.  For 
>>instance, including DC components can make a DN as unambiguous as a 
>>DNS name.  As another example, the following DN
>>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>>is unambiguous as it lists a registered business name, its Australian
>>Business Number (ABN) and the jurisdiction where those are unambiguous 
>>(Australia).  It is inconceivable that any CA could issue such a DN to 
>>another entity in good faith.
>>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>>issuing CA, but would be ambiguous in a wider context so it should not be 
>>used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
>>instance.
>>
>>
>>
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

Regards,

Denis Pinkas





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 j78Fx2QE067824; Mon, 8 Aug 2005 08:59:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78Fx2rf067823; Mon, 8 Aug 2005 08:59:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78Fx14U067817 for <[e-mail]>; Mon, 8 Aug 2005 08:59:02 -0700 (PDT) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D6880E0049; Mon,  8 Aug 2005 11:58:17 -0400 (EDT)
To: [e-mail]
Subject: Delay on 3770bis
From: Sam Hartman <[e-mail]>
Date: Mon, 08 Aug 2005 11:58:17 -0400
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
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>

Hi.  The chairs have proposed what I think will be resolution for the
discuss on 3770bis.  However I failed to get ahold of the AD holding
the discuss before he went on vacation, so we'll have around a one
week delay.



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 j78Fm9Em066590; Mon, 8 Aug 2005 08:48:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78Fm98X066589; Mon, 8 Aug 2005 08:48:09 -0700 (PDT)
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 j78Fm7D0066578 for <[e-mail]>; Mon, 8 Aug 2005 08:48:07 -0700 (PDT) (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 SAA13032; Mon, 8 Aug 2005 18:04:18 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005080817494905:1387 ; Mon, 8 Aug 2005 17:49:49 +0200 
Date: Mon, 8 Aug 2005 17:49:23 +0100
From: "Denis Pinkas" <[e-mail]>
To: "'pkix'" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Subject: Re: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/08/2005 05:49:50 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/08/2005 05:49:52 PM, Serialize complete at 08/08/2005 05:49:52 PM
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
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>

Santosh,

>Denis,

>I agree that the rule of an ancestor may not be sufficient (specially
>theoretically).  An alternative is to permit only the following:

>1.  Indirect CRL is signed using the same trust anchor DN as the certificate
>certification path; or

Your sentence above is not crystal clear to me. 
If you only mean "same TA", then this is insufficient.

>2.  Indirect CRL is signed using an authority that is issued a certificate
>by the same trust anchor DN as the certificate certification path; or

The same applies.

>3.  Certificate issuer CA delegates the Indirect CRL issuer.  In this case,
>depending on the reason for indirect CRL, the revocation status of the
>delegation certificate may need to contain no check or verified using
>partitioned CRL.

I can't understand.

>The implementations I know that use Indirect CRL are consistent with the
>above.  But, it a further constraint/profiling/change to the Standard.

???

>BTW, what are the examples of "locally known constraints" and/or how would
>you articulate these in an RFC?

Quite hard to articulate these in an RFC. The only *example* I have in mind is 
a validation policy that is using a *single* TA, where that TA imposes to 
the CAs it certifies some naming constraints, and where these CA also impose 
naming constraints on subsequent CAs. The naming constraints may be such 
that there cannot be name collisions *if these naming constraints are really 
followed*.

Denis

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Denis Pinkas
>Sent: Friday, August 05, 2005 7:50 AM
>To: 'pkix'; Santosh Chokhani
>Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated
>CRLs
>
>
>
>>Tom,
>
>>That would be fine for indirect CRL.
>
>This is insufficient, unless additional naming constrains are localy known.
>
>> I assume you are not recommending this
>>for a direct CRL (i.e., when Cert Issuer = CRL issuer)
>
>>-----Original Message-----
>>From: Tom Gindin [mailto:[e-mail]]
>>Sent: Thursday, August 04, 2005 9:38 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>>
>>        Santosh:
>>
>>        Actually, I have been arguing for requiring the CRL issuer's
>>certification path to be a subset of the subject certificate's path.  I 
>
>Unless additional naming constrains are localy known, this may be insecure.
>
>Denis
>
>>don't see any major issue if the hierarchical superior of a CA issues a
>>CRL signing certificate which can issue CRL's for the subordinate CA's. 
>>However, I don't see how to go beyond that.
>>
>>Tom Gindin
>
>>"Santosh Chokhani" <[e-mail]>
>>Sent by: [e-mail]
>>08/03/2005 10:17 AM
>> 
>>        To:     "'pkix'" <[e-mail]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>>delegated CRLs
>>
>>
>>
>>Tom Gindin,
>>
>>You seem to be arguing for matching CRL certification path with that of
>>the
>>certificate.
>>
>>If so, you will not get an argument from me.
>>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]]
>>On
>>Behalf Of Tom Gindin
>>Sent: Tuesday, August 02, 2005 11:17 PM
>>To: Manger, James H; [e-mail]
>>Cc: pkix
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>>
>>
>>
>>        James, Santosh:
>>
>>        You certainly can construct unambiguous names for CA's, and I
>>think that Denis already knows that (Permanent Identifier is certainly a 
>>way of constructing unambiguous names, for example).  The difficulty we 
>>have is when one issuer issues a certificate to an organizational CA with 
>>a subject name which is convenient and in common use for its organization, 
>>
>>but ambiguous, and then a different issuer issues a certificate to an
>>organizational CA with the same subject name which is also in common use 
>>for its organization.  This case is most common when both organizations 
>>use an acronym.  I do not see why the issuers of the two organizational CA 
>>
>>certificates should be assumed to originate at different trust anchors,
>>although they will be different issuers.  In fact, I don't understand why 
>>organizational name collisions are thought to be much rarer with a "common 
>>
>>trust anchor" than with "different trust anchors" if the actual issuers 
>>of
>>
>>the colliding certificates are both public CA's.
>>        Such collisions will have negative effects in other parts of 
>>the
>>global PKI, of course.  However, unless we are prepared to issue guidance 
>>to deprecate the assignment of DN's for organizations with geographical 
>>scopes wider than the one for which they are registered and guaranteed to 
>>be unique (and many existing CA certificates have such DN's), I don't see 
>>how we can be certain or nearly certain that such collisions won't occur. 
>>A typical example of what I mean by an organization having a DN with a 
>>geographical scope wider than the one for which it's registered is a 
>>corporation registered in a single American state and operating in several 
>>
>>states while having a DN without the stateOrProvinceName attribute.
>>
>>                Tom Gindin
>>
>>
>>
>>
>>
>>
>>"Manger, James H" <[e-mail]>
>>Sent by: [e-mail]
>>08/01/2005 11:05 PM
>> 
>>        To:     "pkix" <[e-mail]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>>
>>delegated CRLs
>>
>>
>>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know 
>>the
>>trust anchors environment of the relying parties to know if the CRL issuer 
>>
>>DN will be unambiguous.]
>>You can construct unambiguous DNs regardless of trust anchors.  For
>>instance, including DC components can make a DN as unambiguous as a DNS 
>>name.  As another example, the following DN
>>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>>is unambiguous as it lists a registered business name, its Australian 
>>Business Number (ABN) and the jurisdiction where those are unambiguous 
>>(Australia).  It is inconceivable that any CA could issue such a DN to 
>>another entity in good faith.
>>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>>issuing CA, but would be ambiguous in a wider context so it should not be 
>>used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
>>instance.
>>
>>
>>
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

Regards,

Denis Pinkas




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 j78FcOYQ065880; Mon, 8 Aug 2005 08:38:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78FcO80065879; Mon, 8 Aug 2005 08:38:24 -0700 (PDT)
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 j78FcNM4065867 for <[e-mail]>; Mon, 8 Aug 2005 08:38:23 -0700 (PDT) (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 RAA16338; Mon, 8 Aug 2005 17:54:33 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005080817400513:1385 ; Mon, 8 Aug 2005 17:40:05 +0200 
Date: Mon, 8 Aug 2005 17:39:40 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "Stephen Kent" <[e-mail]>
Subject: Re: draft minutes for comment
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/08/2005 05:40:05 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/08/2005 05:40:07 PM, Serialize complete at 08/08/2005 05:40:07 PM
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
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 few coments.

>PKIX WG Meeting 8/2/05
>
>Edited by Steve Kent
>
>Chairs: Stephen Kent <[e-mail]> & Tim Polk <[e-mail]>
>
>The PKIX WG met once during the 63nd IETF. A total of approximately 
>53 individuals participated in the meeting.
>
>
>Document status - Tim Polk (NIST)
>
>	Two new RFCs (PK Algorithms and Permanent Identifier) have 
>been issued since the last meeting. Four additional documents have 
>been approved by the IESG and are in the RFC editor's queue 
>(Certificate path building, warranty extension, 2510bis and 2511bis). 
>Three documents are being reviewed by the ADs (AC policies, CertStire 
>HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for 
>SIM will be initiated after this IETF meeting. More detailed 
>discussions of 3280bis and SCVP will follow. (see slides)
>
>PKIX WG Document Presentations
>
>
>SRV RR otherName - Stefan Santesson (Microsoft)
>	An individual submission, now being adopted by PKIX. The 
>proposal specifies a way to embed a pointer to a DNS SRV record in a 
>certificate, to securely bind the DNS record to a named entity, using 
>the otherName type of GeneralName to carry the specific SRV RR query 
>string. Denis noted that this proposal is a somewhat odd use of the 
>subject alt name, in that the string is not the name of the 
>certificate subject, but the name of a service provided by this 
>subject. 

Add:

"Denis proposed to use the subject directory attributes extension" 
which is well suited to carry this kind of extension..

> Others objected to this specific way of binding service 
>authorization info to a certificate, vs. other approaches, e.g., EKU, 
>or other subject alt name forms. There was general agreement that the 
>proposal needs to be carefully vetted by DNS experts. (see slides)

>Simple Certificate Validation Protocol (SCVP) - Tim Polk (NIST)
>	IPR issues have been resolved since the last IETF meeting, 
>but the core specification has not changed significantly since the 
>-18 draft. The draft meets most of the requirements specified in RFC 
>3379, but return of (relayed) SCVP responses was not included. This 
>will be fixed in the next draft. Also, the conformance requirements 
>seem to impose undue burdens on all clients, contrary to the goal of 
>supporting thin clients. Remaining open issues will be discussed on 
>the list, e.g., syntax details. (see slides)

Russ said a few words about the patent issue. I would not dare to say it, 
but it would be useful for the WG to know what was said in the room.

>3280bis Open Issues - Denis Pinkas (Bull)

SCVP - Open Issues - Denis Pinkas (Bull)

>	Denis emphasizes the need for thin clients, e.g., on cell 
>phones, to be supported. Denis suggested that several OPTIONAL fields 
>should be omitted to facilitate thin client support. However, because 
>these are optional, it appears that the document can be worded to 
>ensure that they impose no burden on a client that does not wish to 
>invoke them. Denis would like to see a facility to allow per-trust 
>anchor validation parameters, obviously not for thin clients, since 
>only a sophisticated client would be able to take advantage of this 
>facility. Denis also would like to represent both the validation 
>policy and validation algorithm into a single OID, 

Please delete: "although this seems to yield a minor space/complexity saving", 
since the topic is much more important than space saving. 

> although this seems to yield a minor space/complexity savings. 

> It was agreed that 
>the URI pointer to a policy will be deleted. Is also was agreed that 
>the terms "validation policy" and "validation algorithm" need to be 
>better defined in the document.
>
>3280bis - Tim Polk (NIST)
>	A new draft has been submitted with relatively minor 
>enhancements. Several open issues remain to be resolved. In 
>particular, questions involving name ambiguity have been raised, 
>particularly as they impact CRL validation.  


Please delete: 
> We may deal with this issue by adding text in the security considerations 
> section that discusses this issue. 

Replace with: "This issue will need to be discused in the security considerations 
section and it has been proposed to add an informative annex for explaining 
in more depth the issue and the solutions.

> The text has been changed to clarify what 
>conforming CAs MUST do in issuing a certificate, vs. what conforming 
>RPs MUST do re certificate path processing. The path validation 
>algorithm notes that it accepts paths that are X.509 compliant, but 
>not PKIX compliant, in support of interoperability.

>SCVP Open Issues - Denis Pinkas (Bull)

3280bis - Open Issues - Denis Pinkas (Bull)

>	Denis reviewed seven topics that he considers open issues. He 
>suggests that text on TA key update should be explicitly covered 
>here, not just a reference to RFC 2510. He also suggests that we
>align out text with the latest X.509 technical corrigendum, with 

Replace with : 
"find a better compromise with the latest X.509 technical corrigendum, "

>respect to key usage. Denis reviewed the name ambiguity debate that 
>has taken place on the list. He suggested that the private key usage 
>extension not be deprecated universally, but rather be allowed in 
>certain contexts, e.g., time stamp crypto modules. 

It has been proposed to soften the prohibition against private key usage 
or to delete annex D.1. (and thus annex D) which is the only section that 
adresses this topic.

> Denis asked for a 
>simplified revocation status checking algorithm description, that 
>addresses only the PKIX-mandated certificate extensions. He also 
>suggests clarification of the text that says what CRLs are 
>"available" in the local cache. Finally, Denis discussed several 
>subtle issues associated with indirect CRLs. At the microphone a 
>series of individuals responded to Denis's suggestions, most 
>disagreed with one of more of his points.

Delete the remaining of the sentence which is:
 
>, although there appeared to 
>be agreement to soften the prohibition against private key usage.
>
>
>Related Specifications & Liaison Presentations
>
>CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf 
>of ETSI TC ESI)
>	This document is based on RFC 3126 and is aligned with a 
>re-issue of ETSI TS 101 733. CAdES is a new name, intended to 
>distinguish it from the XML-based version spec.

Add: XAdES.

"Denis said that the document is now presenting the basic electronic signature formats 
in the main body of the document while placing the features to achieve the maintenance 
of long term signatures in informative annexes. So the informative annexes may equally be 
interresting".

>XKMS - Stephen Farrell (on behalf of W3C)
>	This presentation noted that the XKMS specification in W3C 
>was completed and multiple interoperable implementations are being 
>tested. Interested PKIX members are encouraged to visit the W3C web 
>site and review the spec.

End of revised comments,

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 j75CjZDF091284; Fri, 5 Aug 2005 05:45:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75CjZ6V091283; Fri, 5 Aug 2005 05:45:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75CjZNv091269 for <[e-mail]>; Fri, 5 Aug 2005 05:45:35 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j75CjWdN031737 for <[e-mail]>; Fri, 5 Aug 2005 08:45:34 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Fri, 5 Aug 2005 08:45:27 -0400
Message-ID: <000b01c599bb$91a76d10$[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.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j75CjZNv091277
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 agree that the rule of an ancestor may not be sufficient (specially
theoretically).  An alternative is to permit only the following:

1.  Indirect CRL is signed using the same trust anchor DN as the certificate
certification path; or

2.  Indirect CRL is signed using an authority that is issued a certificate
by the same trust anchor DN as the certificate certification path; or

3.  Certificate issuer CA delegates the Indirect CRL issuer.  In this case,
depending on the reason for indirect CRL, the revocation status of the
delegation certificate may need to contain no check or verified using
partitioned CRL.

The implementations I know that use Indirect CRL are consistent with the
above.  But, it a further constraint/profiling/change to the Standard.

BTW, what are the examples of "locally known constraints" and/or how would
you articulate these in an RFC?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Friday, August 05, 2005 7:50 AM
To: 'pkix'; Santosh Chokhani
Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated
CRLs



>Tom,

>That would be fine for indirect CRL.

This is insufficient, unless additional naming constrains are localy known.

> I assume you are not recommending this
>for a direct CRL (i.e., when Cert Issuer = CRL issuer)

>-----Original Message-----
>From: Tom Gindin [mailto:[e-mail]]
>Sent: Thursday, August 04, 2005 9:38 AM
>To: Santosh Chokhani
>Cc: 'pkix'
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>        Santosh:
>
>        Actually, I have been arguing for requiring the CRL issuer's
>certification path to be a subset of the subject certificate's path.  I 

Unless additional naming constrains are localy known, this may be insecure.

Denis

>don't see any major issue if the hierarchical superior of a CA issues a
>CRL signing certificate which can issue CRL's for the subordinate CA's. 
>However, I don't see how to go beyond that.
>
>Tom Gindin

>"Santosh Chokhani" <[e-mail]>
>Sent by: [e-mail]
>08/03/2005 10:17 AM
> 
>        To:     "'pkix'" <[e-mail]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>
>Tom Gindin,
>
>You seem to be arguing for matching CRL certification path with that of
>the
>certificate.
>
>If so, you will not get an argument from me.
>
>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]]
>On
>Behalf Of Tom Gindin
>Sent: Tuesday, August 02, 2005 11:17 PM
>To: Manger, James H; [e-mail]
>Cc: pkix
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>
>        James, Santosh:
>
>        You certainly can construct unambiguous names for CA's, and I
>think that Denis already knows that (Permanent Identifier is certainly a 
>way of constructing unambiguous names, for example).  The difficulty we 
>have is when one issuer issues a certificate to an organizational CA with 
>a subject name which is convenient and in common use for its organization, 
>
>but ambiguous, and then a different issuer issues a certificate to an
>organizational CA with the same subject name which is also in common use 
>for its organization.  This case is most common when both organizations 
>use an acronym.  I do not see why the issuers of the two organizational CA 
>
>certificates should be assumed to originate at different trust anchors,
>although they will be different issuers.  In fact, I don't understand why 
>organizational name collisions are thought to be much rarer with a "common 
>
>trust anchor" than with "different trust anchors" if the actual issuers 
>of
>
>the colliding certificates are both public CA's.
>        Such collisions will have negative effects in other parts of 
>the
>global PKI, of course.  However, unless we are prepared to issue guidance 
>to deprecate the assignment of DN's for organizations with geographical 
>scopes wider than the one for which they are registered and guaranteed to 
>be unique (and many existing CA certificates have such DN's), I don't see 
>how we can be certain or nearly certain that such collisions won't occur. 
>A typical example of what I mean by an organization having a DN with a 
>geographical scope wider than the one for which it's registered is a 
>corporation registered in a single American state and operating in several 
>
>states while having a DN without the stateOrProvinceName attribute.
>
>                Tom Gindin
>
>
>
>
>
>
>"Manger, James H" <[e-mail]>
>Sent by: [e-mail]
>08/01/2005 11:05 PM
> 
>        To:     "pkix" <[e-mail]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>
>delegated CRLs
>
>
>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know 
>the
>trust anchors environment of the relying parties to know if the CRL issuer 
>
>DN will be unambiguous.]
>You can construct unambiguous DNs regardless of trust anchors.  For
>instance, including DC components can make a DN as unambiguous as a DNS 
>name.  As another example, the following DN
>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>is unambiguous as it lists a registered business name, its Australian 
>Business Number (ABN) and the jurisdiction where those are unambiguous 
>(Australia).  It is inconceivable that any CA could issue such a DN to 
>another entity in good faith.
>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>issuing CA, but would be ambiguous in a wider context so it should not be 
>used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
>instance.
>
>
>
>
>

Regards,

Denis Pinkas





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 j75Amw40050448; Fri, 5 Aug 2005 03:48:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75Amwhg050447; Fri, 5 Aug 2005 03:48:58 -0700 (PDT)
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 j75AmuxL050388 for <[e-mail]>; Fri, 5 Aug 2005 03:48:57 -0700 (PDT) (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 NAA41612; Fri, 5 Aug 2005 13:05:04 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005080512503260:954 ; Fri, 5 Aug 2005 12:50:32 +0200 
Date: Fri, 5 Aug 2005 12:50:14 +0100
From: "Denis Pinkas" <[e-mail]>
To: "'pkix'" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/08/2005 12:50:32, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/08/2005 12:50:34, Serialize complete at 05/08/2005 12:50:34
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
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>

>Tom,

>That would be fine for indirect CRL.  

This is insufficient, unless additional naming constrains are localy known.

> I assume you are not recommending this
>for a direct CRL (i.e., when Cert Issuer = CRL issuer)

>-----Original Message-----
>From: Tom Gindin [mailto:[e-mail]] 
>Sent: Thursday, August 04, 2005 9:38 AM
>To: Santosh Chokhani
>Cc: 'pkix'
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>        Santosh:
>
>        Actually, I have been arguing for requiring the CRL issuer's 
>certification path to be a subset of the subject certificate's path.  I 

Unless additional naming constrains are localy known, this may be insecure.

Denis

>don't see any major issue if the hierarchical superior of a CA issues a 
>CRL signing certificate which can issue CRL's for the subordinate CA's. 
>However, I don't see how to go beyond that.
>
>Tom Gindin

>"Santosh Chokhani" <[e-mail]>
>Sent by: [e-mail]
>08/03/2005 10:17 AM
> 
>        To:     "'pkix'" <[e-mail]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>
>Tom Gindin,
>
>You seem to be arguing for matching CRL certification path with that of 
>the
>certificate.
>
>If so, you will not get an argument from me.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On
>Behalf Of Tom Gindin
>Sent: Tuesday, August 02, 2005 11:17 PM
>To: Manger, James H; [e-mail]
>Cc: pkix
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>
>        James, Santosh:
>
>        You certainly can construct unambiguous names for CA's, and I 
>think that Denis already knows that (Permanent Identifier is certainly a 
>way of constructing unambiguous names, for example).  The difficulty we 
>have is when one issuer issues a certificate to an organizational CA with 
>a subject name which is convenient and in common use for its organization, 
>
>but ambiguous, and then a different issuer issues a certificate to an 
>organizational CA with the same subject name which is also in common use 
>for its organization.  This case is most common when both organizations 
>use an acronym.  I do not see why the issuers of the two organizational CA 
>
>certificates should be assumed to originate at different trust anchors, 
>although they will be different issuers.  In fact, I don't understand why 
>organizational name collisions are thought to be much rarer with a "common 
>
>trust anchor" than with "different trust anchors" if the actual issuers of 
>
>the colliding certificates are both public CA's.
>        Such collisions will have negative effects in other parts of the 
>global PKI, of course.  However, unless we are prepared to issue guidance 
>to deprecate the assignment of DN's for organizations with geographical 
>scopes wider than the one for which they are registered and guaranteed to 
>be unique (and many existing CA certificates have such DN's), I don't see 
>how we can be certain or nearly certain that such collisions won't occur. 
>A typical example of what I mean by an organization having a DN with a 
>geographical scope wider than the one for which it's registered is a 
>corporation registered in a single American state and operating in several 
>
>states while having a DN without the stateOrProvinceName attribute.
>
>                Tom Gindin
>
>
>
>
>
>
>"Manger, James H" <[e-mail]>
>Sent by: [e-mail]
>08/01/2005 11:05 PM
> 
>        To:     "pkix" <[e-mail]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>
>delegated CRLs
>
>
>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
>trust anchors environment of the relying parties to know if the CRL issuer 
>
>DN will be unambiguous.]
>You can construct unambiguous DNs regardless of trust anchors.  For 
>instance, including DC components can make a DN as unambiguous as a DNS 
>name.  As another example, the following DN
>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>is unambiguous as it lists a registered business name, its Australian 
>Business Number (ABN) and the jurisdiction where those are unambiguous 
>(Australia).  It is inconceivable that any CA could issue such a DN to 
>another entity in good faith.
>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>issuing CA, but would be ambiguous in a wider context so it should not be 
>used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
>instance.
>
>
>
>
>

Regards,

Denis Pinkas




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 j74Mq9vM084325; Thu, 4 Aug 2005 15:52:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Mq9kg084324; Thu, 4 Aug 2005 15:52:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.na.baesystems.com (smtp4.na.baesystems.com [63.164.202.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Mq8Yr084318 for <[e-mail]>; Thu, 4 Aug 2005 15:52:09 -0700 (PDT) (envelope-from [e-mail])
Received: from BLUMS0022.bluelnk.net (blums0022.na.baesystems.com [10.40.96.145]) by smtp4.na.baesystems.com (8.12.10/8.12.10) with ESMTP id j74Mq8Ka017248 for <[e-mail]>; Thu, 4 Aug 2005 18:52:08 -0400 (EDT)
Received: from vahqex1.digitalnet.com (vahqex1.gfgsi.com [159.94.37.41]) by smtp1.na.baesystems.com (8.12.10/8.12.10) with ESMTP id j74Mq7Ga008915 for <[e-mail]>; Thu, 4 Aug 2005 18:52:07 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: Freeware Certificate Management Library (CML)
Date: Thu, 4 Aug 2005 18:51:39 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Freeware Certificate Management Library (CML)
Thread-Index: AcU6yNml1jlJ9PKMSiqHayRk3snwVBeeRO4w
From: "Pawling, John" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j74Mq9Yr084319
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>

All,

The freeware, open-source Version 2.5 Certificate Management Library
(CML) for Microsoft Windows, Sun Solaris and Linux is freely available
at:
<http://www.digitalnet.com/knowledge/cml_home.htm>.

Applications requiring Public Key Infrastructure (PKI) security services
can use the CML to meet their X.509 certificate and Certificate
Revocation List (CRL) processing requirements. The CML provides X.509
certification path building and validation services through a
developer-friendly C and C++ Application Programming Interface (API).  

The CML performs all of the required certification path processing as
specified in X.509 Recommendation (2000) and IETF PKIX RFC 3280
Certificate/CRL Profile. The CML is capable of building certification
paths through simple and complex PKI topologies including hierarchical,
mesh, and bridge topologies, and any combination of the same.  The CML
has been successfully used to Public Key Enable (PKE) a variety of
applications to meet their X.509 certificate processing requirements.  

The CML supports digital signature verification using a variety of
cryptographic algorithms.  It supports revocation checking using CRLs
and the On-Line Certificate Status Protocol (OCSP). The accompanying
Storage and Retrieval Library (SRL) optionally provides local
certificate and CRL storage management functions.  The SRL also
optionally provides remote directory retrieval capabilities using the
Lightweight Directory Access Protocol (LDAP).  

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations
can use the CML without paying any royalties or licensing fees.  BAE
Systems is
enhancing and supporting the CML under contract to the U.S. Government.
The U.S. Government is furnishing the CML software at no cost to the
vendor subject to the conditions of the CML Public License provided with
the CML software.
  
The v2.5 CML Abstract Syntax Notation.1 (ASN.1) encodes and decodes
X.509 Certificates, CRLs and Attribute Certificates.  It requires the
v1.7 Enhanced SNACC ASN.1 software that is freely available from: 
<http://www.digitalnet.com/knowledge/snacc_home.htm>

The CML has been thoroughly tested including validating X.509
Certificates and CRLs created by a variety of Certification Authority
(CA) products, and signed using the Digital Signature Algorithm (DSA)
and RSA algorithms.  Further enhancements, ports and testing of the CML
are still in process.  Further releases of the CML will be provided as
significant capabilities are added. 

Public Key Interoperability Test Suite (PKITS) Testing: PKITS is a
comprehensive X.509 path validation test suite designed to cover most of
the features specified in X.509 and RFC 3280.  The National Institute of
Standards and Technology (NIST) is providing PKITS at 
<http://csrc.nist.gov/pki/testing/x509paths.html>. The CML was used to
successfully build and validate the X.509 certification paths included
in PKITS.

CML v2.5 includes the following enhancements (compared to v2.4 CML
release):

1. Enhanced path validation functions to allow a date to be specified
which is used as the validation date/time.
 
2. Added capability to return CRLs or OCSP responses that are used
during certificate path validation. 

3. Added Online Certificate Status Protocol (OCSP) client library, using
OpenSSL, to check revocation status of certificates using OCSP. 

4. Added new path validation error code, CM_INVALID_POLICY_MAPPING, that
is returned when a CA cert contains an invalid policy mapping (i.e.
either a policy is mapped from or to the special any-policy.)

The CML makes calls to PKCS #11-compliant libraries for cryptographic
support. BAE Systems provides a PKCS #11 implementation of Wei Dai's
Crypto++ <http://www.eskimo.com/~weidai/cryptlib.html> for use with the
CML. The underlying, external crypto libraries are not distributed as
part of the CML software. 

The CML has been successfully tested with the v2.5 S/MIME Freeware
Library (SFL) that is freely available from 
<http://www.DigitalNet.com/knowledge/sfl_home.htm>. 

The CML has been successfully tested with the v2.5 Access Control
Library (ACL) that is freely available to everyone from: 
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to: 
distribute information regarding CML releases; discuss CML-related
issues; and allow CML users to provide feedback, comments, bug reports,
etc. Subscription information for the imc-cml mailing list is at the IMC
web site listed above. 

All comments regarding the CML source code and documents are welcome.
This CML release announcement was sent to several mail lists, but please
send all messages regarding the CML to the imc-cml mail list ONLY.
Please do not send messages regarding the CML to any of the IETF mail
lists. We will respond to all messages sent to the imc-cml mail list. 

=============================
John Pawling
BAE SYSTEMS Information Technology
[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 j74KRoqS074194; Thu, 4 Aug 2005 13:27:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74KRopb074193; Thu, 4 Aug 2005 13:27:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74KRniG074174 for <[e-mail]>; Thu, 4 Aug 2005 13:27:50 -0700 (PDT) (envelope-from [e-mail])
Received: from arport2v (213.64.145.131) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 42B94E29006B54B4; Thu, 4 Aug 2005 22:27:37 +0200
Message-ID: <006d01c59933$338ce260$8217a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <002a01c598c3$ef32dda0$8217a8c0@arport2v> <p0623090abf1773daa7a9@[86.255.25.238]>
Subject: Re: Qualified Certificate Requests - RFC
Date: Thu, 4 Aug 2005 22:29:19 +0200
MIME-Version: 1.0
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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

TPMs are actually used in contexts outside of trustedcomputingroup (which
I BTW am a member of).  TPMs do not by definition have to be in HW but we
are unlikely to see much SW versions except for reference designs.
A TPM does not by definition have to bolted to a motherboard to perform
useful functions.  That is, TPMs can do many other things than protecting
operating systems including secure crypto operations on user keys in the same
was as typically associated with smart cards and HSMs.

Smart cards OTOH is not only an soon-to-be obsoleted technology, but also
a meaningless term, as "smart" does not say anything about its functionality.
Sounds more like a marketing phrase to me.  

It takes a NIST, GSA and a DoD to come up with "smart" card readers for $234:
http://www.karbonsystems.com/BlackBerry-SMIME-CAC-products_detail-83.html
when a TPM-based scheme will soon be for free and add zero weight to a mobile unit.
In addition to supporting a magnitude more use cases than a discrete card is able to.

Regarding the privacy issue with binding certs to TPM IDs including
serial number, the comparison with Intel's removed CPU number
is pretty flawed as the binding in the former case is only known by the CA
while the in the Intel case, more or less any program could read and use this
information.  In case you have a privacy issue also with the CA, I suggest
that you run it yourself.

/anders

----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, August 04, 2005 09:40
Subject: Re: Qualified Certificate Requests - RFC


At 9:12 AM +0200 8/4/05, Anders Rundgren wrote:
>Stephen,
>Your suggestion seems to be the right way of doing this.
>
>I would though equip each TPM [1] with a unique certificate containing
>the device serial number etc.   This has the advantage that a CA may
>record this data together with other issuance data making it possible
>to trace credential misuses (theft) down to a particular "container".
>
>Regarding the name of the RFC, "Qualified Certificate Request", I would
>not associate this with qualified certificates in the EU sense, as TPM
>requirements is by no means limited to this particular class of certificates.
>
>Anders Rundgren
>
>1] Trusted Processing Module is becoming the collective term for things
>that were previously known as smart card or HSM

More accurately, TPM is a reference to a set of hardware functions 
that are intended for inclusion in general purpose computers, as 
defined by the Trusted Computing Group 
(www.trustedcomputinggroup.org/home). Smart cards and most HSMs would 
not qualify under this more precise use of the acronym.

Also note that the creation of a cert bound to a device serial 
number, at least for PCs, is precisely the sort of concept that got 
Intel a lot of bad PR a few years ago.

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 j74Djde3030429; Thu, 4 Aug 2005 06:45:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74DjdwT030428; Thu, 4 Aug 2005 06:45:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Djcq8030410 for <[e-mail]>; Thu, 4 Aug 2005 06:45:38 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.87  (authenticated user [e-mail]) by mx2.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 51-md50000000563.tmp for <[e-mail]>; Thu, 04 Aug 2005 15:45:36 +0200
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: [e-mail], [e-mail]
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate
Date: Thu, 4 Aug 2005 15:45:37 +0200
User-Agent: KMail/1.8
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Spam-Processed: mx2.go-now.at, Thu, 04 Aug 2005 15:45:36 +0200 (not processed: message from valid local sender)
X-Lookup-Warning: HELO/EHLO lookup on 192.168.0.87 does not match 80.120.131.105
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j74Djdq8030421
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 should've qualified the statement. Its clear now I've read the full
> details that a certificate isn't appopriate to sign the public key of a
> smart card key. Where it might be appropriate is in signing the vendor's
> key for trust purposes, see below.

Ok.

> So how does a CA processing the CSR and vendor key know that it can
> trust the vendor's key?

The vendor has to undergo an audit to proof the security and trustworthyness 
of the system and the vendor´s operations.
That audit can be done by any third party (Common Criteria would be an idea 
here, FIPS certification would be good too), or by the CA itself (to reduce 
the costs).

> That's a case where I believe certificates could have a role. An
> authority could certify each vendor key and the vendor would include
> references to this information in the form of a URI on its site.

Yes, that´s also possible to use authorities who certify the vendor key.
Anyway, there has to be a relationship between the vendor and the CA, I think. 
An external audit or approval by an authority just helps in that 
relationship, but I wouldn´t suggest to do it anonymously.

I think even the CA has to proof to the authorities that the overall solution 
(both the CA and the SmartCard, ...) is good enough for qualified 
certificates to be issued. So both CA and Vendor might have to be audited 
together by the authority ...

Regards,
Philipp Gühring




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 j74DiELN029764; Thu, 4 Aug 2005 06:44:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74DiEqp029763; Thu, 4 Aug 2005 06:44:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74DiDnG029750 for <[e-mail]>; Thu, 4 Aug 2005 06:44:13 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (ASQ2-127-177.usae.bah.com [156.80.127.177]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j74DiBD5011905 for <[e-mail]>; Thu, 4 Aug 2005 09:44:12 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Thu, 4 Aug 2005 09:44:06 -0400
Message-ID: <003e01c598fa$98491720$[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.6626
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j74DiEnG029756
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>

Tom,

That would be fine for indirect CRL.  I assume you are not recommending this
for a direct CRL (i.e., when Cert Issuer = CRL issuer)

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Thursday, August 04, 2005 9:38 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs


        Santosh:

        Actually, I have been arguing for requiring the CRL issuer's 
certification path to be a subset of the subject certificate's path.  I 
don't see any major issue if the hierarchical superior of a CA issues a 
CRL signing certificate which can issue CRL's for the subordinate CA's. 
However, I don't see how to go beyond that.

Tom Gindin






"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
08/03/2005 10:17 AM
 
        To:     "'pkix'" <[e-mail]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
delegated CRLs



Tom Gindin,

You seem to be arguing for matching CRL certification path with that of 
the
certificate.

If so, you will not get an argument from me.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, August 02, 2005 11:17 PM
To: Manger, James H; [e-mail]
Cc: pkix
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs



        James, Santosh:

        You certainly can construct unambiguous names for CA's, and I 
think that Denis already knows that (Permanent Identifier is certainly a 
way of constructing unambiguous names, for example).  The difficulty we 
have is when one issuer issues a certificate to an organizational CA with 
a subject name which is convenient and in common use for its organization, 

but ambiguous, and then a different issuer issues a certificate to an 
organizational CA with the same subject name which is also in common use 
for its organization.  This case is most common when both organizations 
use an acronym.  I do not see why the issuers of the two organizational CA 

certificates should be assumed to originate at different trust anchors, 
although they will be different issuers.  In fact, I don't understand why 
organizational name collisions are thought to be much rarer with a "common 

trust anchor" than with "different trust anchors" if the actual issuers of 

the colliding certificates are both public CA's.
        Such collisions will have negative effects in other parts of the 
global PKI, of course.  However, unless we are prepared to issue guidance 
to deprecate the assignment of DN's for organizations with geographical 
scopes wider than the one for which they are registered and guaranteed to 
be unique (and many existing CA certificates have such DN's), I don't see 
how we can be certain or nearly certain that such collisions won't occur. 
A typical example of what I mean by an organization having a DN with a 
geographical scope wider than the one for which it's registered is a 
corporation registered in a single American state and operating in several 

states while having a DN without the stateOrProvinceName attribute.

                Tom Gindin






"Manger, James H" <[e-mail]>
Sent by: [e-mail]
08/01/2005 11:05 PM
 
        To:     "pkix" <[e-mail]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 

delegated CRLs


[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
trust anchors environment of the relying parties to know if the CRL issuer 

DN will be unambiguous.]
You can construct unambiguous DNs regardless of trust anchors.  For 
instance, including DC components can make a DN as unambiguous as a DNS 
name.  As another example, the following DN
  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
is unambiguous as it lists a registered business name, its Australian 
Business Number (ABN) and the jurisdiction where those are unambiguous 
(Australia).  It is inconceivable that any CA could issue such a DN to 
another entity in good faith.
The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
issuing CA, but would be ambiguous in a wider context so it should not be 
used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
instance.







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 j74DcM3v027354; Thu, 4 Aug 2005 06:38:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74DcM9w027352; Thu, 4 Aug 2005 06:38:22 -0700 (PDT)
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 j74DcLgh027301 for <[e-mail]>; Thu, 4 Aug 2005 06:38:21 -0700 (PDT) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j74DcDtn004541 for <[e-mail]>; Thu, 4 Aug 2005 09:38:13 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j74DcDuN247642 for <[e-mail]>; Thu, 4 Aug 2005 09:38:13 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j74DcDjU005581 for <[e-mail]>; Thu, 4 Aug 2005 09:38:13 -0400
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 j74DcDKp005571; Thu, 4 Aug 2005 09:38:13 -0400
In-Reply-To: <001801c59836$28f24870$[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: "'pkix'" <[e-mail]>
MIME-Version: 1.0
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 4 Aug 2005 09:38:11 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 08/04/2005 09:38:12, Serialize complete at 08/04/2005 09:38:12
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>

        Santosh:

        Actually, I have been arguing for requiring the CRL issuer's 
certification path to be a subset of the subject certificate's path.  I 
don't see any major issue if the hierarchical superior of a CA issues a 
CRL signing certificate which can issue CRL's for the subordinate CA's. 
However, I don't see how to go beyond that.

Tom Gindin






"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
08/03/2005 10:17 AM
 
        To:     "'pkix'" <[e-mail]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
delegated CRLs



Tom Gindin,

You seem to be arguing for matching CRL certification path with that of 
the
certificate.

If so, you will not get an argument from me.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, August 02, 2005 11:17 PM
To: Manger, James H; [e-mail]
Cc: pkix
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs



        James, Santosh:

        You certainly can construct unambiguous names for CA's, and I 
think that Denis already knows that (Permanent Identifier is certainly a 
way of constructing unambiguous names, for example).  The difficulty we 
have is when one issuer issues a certificate to an organizational CA with 
a subject name which is convenient and in common use for its organization, 

but ambiguous, and then a different issuer issues a certificate to an 
organizational CA with the same subject name which is also in common use 
for its organization.  This case is most common when both organizations 
use an acronym.  I do not see why the issuers of the two organizational CA 

certificates should be assumed to originate at different trust anchors, 
although they will be different issuers.  In fact, I don't understand why 
organizational name collisions are thought to be much rarer with a "common 

trust anchor" than with "different trust anchors" if the actual issuers of 

the colliding certificates are both public CA's.
        Such collisions will have negative effects in other parts of the 
global PKI, of course.  However, unless we are prepared to issue guidance 
to deprecate the assignment of DN's for organizations with geographical 
scopes wider than the one for which they are registered and guaranteed to 
be unique (and many existing CA certificates have such DN's), I don't see 
how we can be certain or nearly certain that such collisions won't occur. 
A typical example of what I mean by an organization having a DN with a 
geographical scope wider than the one for which it's registered is a 
corporation registered in a single American state and operating in several 

states while having a DN without the stateOrProvinceName attribute.

                Tom Gindin






"Manger, James H" <[e-mail]>
Sent by: [e-mail]
08/01/2005 11:05 PM
 
        To:     "pkix" <[e-mail]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 

delegated CRLs


[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
trust anchors environment of the relying parties to know if the CRL issuer 

DN will be unambiguous.]
You can construct unambiguous DNs regardless of trust anchors.  For 
instance, including DC components can make a DN as unambiguous as a DNS 
name.  As another example, the following DN
  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
is unambiguous as it lists a registered business name, its Australian 
Business Number (ABN) and the jurisdiction where those are unambiguous 
(Australia).  It is inconceivable that any CA could issue such a DN to 
another entity in good faith.
The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
issuing CA, but would be ambiguous in a wider context so it should not be 
used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
instance.






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 j74ApVd6064011; Thu, 4 Aug 2005 03:51:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74ApVq7064010; Thu, 4 Aug 2005 03:51:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74ApU9G063998 for <[e-mail]>; Thu, 4 Aug 2005 03:51:30 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j74ApLD5026743 for <[e-mail]>; Thu, 4 Aug 2005 06:51:29 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Thu, 4 Aug 2005 06:51:15 -0400
Message-ID: <006b01c598e2$76def040$[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.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j74ApU9G064004
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,

Thanks for agreeing that RFC for my approach is simple and the approach is
not complex (You capture the rules in 2 sentences below).

Now, for the alternative as to what the relying party knows about each PKI,
what would you say in an RFC?  Please provide specific words.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Thursday, August 04, 2005 5:58 AM
To: 'pkix'; Santosh Chokhani
Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated
CRLs




>Tom Gindin,
>
>You seem to be arguing for matching CRL certification path with that of 
>the certificate.
>
>If so, you will not get an argument from me.

Matching the CRL certification path with that of the target certificate is
certainly secure. However, after some discussions with some PKIX members, it
appears that is can be made 
more general without loosing any security.

If the same TA is used and the same sequence of CA DNs (below that TA) is
used, 
then it is always secure.

Now if the RP locally "knows" some additional naming rules that apply to
every CA below 
each trusted TA from the validation policy that is being used, then this
rule may not be necessary.

Denis

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Tom Gindin
>Sent: Tuesday, August 02, 2005 11:17 PM
>To: Manger, James H; [e-mail]
>Cc: pkix
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated 
>CRLs
>
>
>
>        James, Santosh:
>
>        You certainly can construct unambiguous names for CA's, and I
>think that Denis already knows that (Permanent Identifier is certainly a 
>way of constructing unambiguous names, for example).  The difficulty we 
>have is when one issuer issues a certificate to an organizational CA with 
>a subject name which is convenient and in common use for its organization, 
>but ambiguous, and then a different issuer issues a certificate to an 
>organizational CA with the same subject name which is also in common use 
>for its organization.  This case is most common when both organizations 
>use an acronym.  I do not see why the issuers of the two organizational CA 
>certificates should be assumed to originate at different trust anchors, 
>although they will be different issuers.  In fact, I don't understand why 
>organizational name collisions are thought to be much rarer with a "common 
>trust anchor" than with "different trust anchors" if the actual issuers of 
>the colliding certificates are both public CA's.
>        Such collisions will have negative effects in other parts of the 
>global PKI, of course.  However, unless we are prepared to issue guidance 
>to deprecate the assignment of DN's for organizations with geographical 
>scopes wider than the one for which they are registered and guaranteed to 
>be unique (and many existing CA certificates have such DN's), I don't see 
>how we can be certain or nearly certain that such collisions won't occur. 
>A typical example of what I mean by an organization having a DN with a 
>geographical scope wider than the one for which it's registered is a 
>corporation registered in a single American state and operating in several 
>states while having a DN without the stateOrProvinceName attribute.
>
>                Tom Gindin
>
>
>
>
>
>
>"Manger, James H" <[e-mail]>
>Sent by: [e-mail]
>08/01/2005 11:05 PM
> 
>        To:     "pkix" <[e-mail]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know 
>the
>trust anchors environment of the relying parties to know if the CRL issuer 
>DN will be unambiguous.]
>You can construct unambiguous DNs regardless of trust anchors.  For 
>instance, including DC components can make a DN as unambiguous as a DNS 
>name.  As another example, the following DN
>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>is unambiguous as it lists a registered business name, its Australian 
>Business Number (ABN) and the jurisdiction where those are unambiguous 
>(Australia).  It is inconceivable that any CA could issue such a DN to 
>another entity in good faith.
>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>issuing CA, but would be ambiguous in a wider context so it should not be 
>used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
>instance.
>
>

Regards,

Denis Pinkas





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 j749nIGq038278; Thu, 4 Aug 2005 02:49:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j749nIlj038277; Thu, 4 Aug 2005 02:49:18 -0700 (PDT)
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 j749nH1c038228 for <[e-mail]>; Thu, 4 Aug 2005 02:49:17 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 10:49:11 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: srv based names
Date: Thu, 4 Aug 2005 10:49:03 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: srv based names
Thread-Index: AcWYzhJVYAfKW0NLTu25PrfRM4F6XQAChITg
From: "Stefan Santesson" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 04 Aug 2005 09:49:11.0539 (UTC) FILETIME=[C41B8430:01C598D9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j749nI1c038268
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,

Thank you for pointing to this relevant document.

Looking at the draft, and also the IESG log raises some concerns though.
It seems to me that the content in the dns URI and the SRV RR, even
though seems identical, is defined with different semantics and that is
also the source of concerns raised in IESG.

While the domain part of the SRV RR query string refers to the domain
where the service resides, the dns host name in the URI specifies host
name of the dns server.

The difference seems to me is that I can use the SRV RR query to ask any
locally configured DNS to resolve the location of the requested service
on the requested domain, the URI on the other hand points specifically
to the dns server which holds a specific record.

I think we should keep a close eye on the progress of the dns URI draft
but I don't see that it for now should prevent us from proceeding with
the proposed otherName definition.

 

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[e-mail]]
> Sent: den 4 augusti 2005 10:25
> To: Stefan Santesson
> Cc: Russ Housley; [e-mail]
> Subject: RE: srv based names
> 
> I note that the IESG is considering:
> http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-12.txt
> 
> Given the ability to write this service identification
> information as the URL:
>         dns:///_kerberos._tcp.example.com?class=IN;type=SRV
> 
> in a certificate, why we need another way express this
> service identification information in a certificate.
> 
> Kurt
> 
> 
> At 07:56 AM 8/4/2005, Stefan Santesson wrote:
> >The mechanism of SRV RR corresponds to domain names so names are not
> >ambiguous.
> >
> >The SRV RR is interesting as a way to approach a domain searching for
> >appropriate recourses/services on that domain. That service may or
may
> >not correspond to a URI scheme, but it will always correspond to a
> >specific SRV tag (or you could not search for it).
> >
> >What do you gain by preventing me from binding to that service name
in a
> >cert?
> >
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
> >
> >
> >> -----Original Message-----
> >> From: Kurt D. Zeilenga [mailto:[e-mail]]
> >> Sent: den 4 augusti 2005 02:18
> >> To: Stefan Santesson
> >> Cc: Russ Housley; [e-mail]
> >> Subject: RE: srv based names
> >>
> >> At 07:16 PM 8/3/2005, Stefan Santesson wrote:
> >>
> >> >Manual validation by users is hardly the target here.
> >> >It rather a way for a client application to determine that it has
> >reached
> >> a host that is authorized to deliver the service it searched for.
> >>
> >> I see no reason why uniformResourceIdentifier cannot be used
> >> for this excepting for the point that the current set of
> >> URI schemes is insufficient.
> >>
> >> I think it for more appropriate to engineer additional
> >> URI schemes where needed than to use the strings intended
> >> to be used to locate DNS SRV RR records as a more general
> >> service identifier than they were intended to be.
> >>
> >> It was noted your proposal was intended for use with
> >> Kerberos.  I find this quite problematic given that
> >> "EXAMPLE.COM" and "example.com" are two different
> >> realms but one domain.  That is, the string
> >> _kerberos._tcp.example.com is ambiguous.
> >>
> >> Consider a realm called "REALM.TLD" (picking TLD for some
> >> reason other than it being a valid TLD) operating using
> >> non DNS SRV based location services and a client attempting
> >> to verify that the server it contacted has an appropriate
> >> issued certificate.  That client is not only configured
> >> with knowledge of the CA which issued the certificate
> >> for this service, but a collection of other trusted CAs.
> >> An attacker can register REALM.TLD and then get one
> >> of the other trusted CAs to issue a certificate to a
> >> rough service.
> >>
> >> Now, it might be argued that this example is a bit
> >> contrived, however I think it illustrates a class of
> >> problems one will find using names of DNS RRs as
> >> alt subjects.
> >>
> >> >If you approach a service knowing its SRV service name then
binding
> >to
> >> that SRV name is most appropriate and functional.
> >>
> >> To know the name of the SRV RR implies knowledge of
> >> service-specific service information, such as a realm in
> >> the Kerberos case and an ability to map this
> >> information to a (purported) name of a DNS SRV RR.
> >> Just because one can map a realm to a (purported) name
> >> of a DNS SRV RR does mean it is appropriate to use the
> >> result of this mapping as a subject identifier in a
> >> certificate.  In the case of Kerberos, I think it
> >> can be argued that the (purported) name of a DNS
> >> SRV RR should not be used, or only used when the
> >> service location policy for that realm is DNS SRV.
> >> If the service location policy was to use a configured
> >> location, use of the (purported) name would be
> >> inappropriate.
> >>
> >> I argue it is far more appropriate to use the
> >> service-specific information in the subject identifier.
> >> That is, use the Kerberos realm as the subject identifier.
> >> Why wouldn't a Kerberos realm URI scheme met your needs
> >> in this case?
> >>
> >> 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 j748uZEX018268; Thu, 4 Aug 2005 01:56:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j748uZqu018267; Thu, 4 Aug 2005 01:56:35 -0700 (PDT)
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 j748uYv6018221 for <[e-mail]>; Thu, 4 Aug 2005 01:56:34 -0700 (PDT) (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 LAA06134; Thu, 4 Aug 2005 11:12:41 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005080410580799:631 ; Thu, 4 Aug 2005 10:58:07 +0200 
Date: Thu, 4 Aug 2005 10:57:50 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Re: AW: Qualified Certificate Requests - RFC
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/08/2005 10:58:08, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/08/2005 10:58:10, Serialize complete at 04/08/2005 10:58:10
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j748uZv6018261
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>

Philipp,

Yes, there is something wrong in that method, as described below. 
It would be insecure to use a single vendor public key for all 
the smart cards from that vendor.

Denis

>Hello,
>
>> how do you imagine a "qualified CSR"? The problem is, that a CA must get a
>> prove that the CSR is generated by a smartcard or an HSM and not by a peace
>> of fake software.
>> Until now, IMHO, there's no feasible concept to prove that.
>
>My concept is the following:
>
>First the SmartCard vendor generates a public/private keypair, the so-called 
>vendorkey.
>
>When the SmardCard (or HSM) is manufactured (or initialized), the private 
>vendorkey is burnt into the SmartCard.
>The SmartCard has to enforce two things:
>  The private vendor key can´t leave the SmartCard
>  The private vendor key can only be used to sign public keys, for which the 
>corresponding private key´s were generated in the SmartCard, and are also 
>securely stored in it.
>
>The SmartCard (and it´s vendor) has to be audited (by a third party auditor, 
>or by the CA).
>When the audit succeeds, the CA approves the public vendorkey for qualified 
>certificates.
>
>Now the user buys the SmartCard.
>
>Then the user let´s the SmartCard generate a User-Keypair.
>The SmartCard signs the user´s public-key with the vendor´s secret key.
>The software requests both the user-public key and the signature of the users
>´s public key from the Smartcard.
>The software generates a certificate request for the User-Keypair, and 
>includes the signature as a extension (or attribute) in the request.
>
>The certificate request is sent to the CA in the normal way.
>
>The CA detects the qualification signature, verifies it against the public key 
>of the vendor, and if everyhting matches, the CA can issue a qualified 
>signature.
>
>Anything wrong in that method?
>
>Regards,
>Philipp Gühring





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 j748uMoi018187; Thu, 4 Aug 2005 01:56:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j748uMAB018186; Thu, 4 Aug 2005 01:56:22 -0700 (PDT)
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 j748uKGB018148 for <[e-mail]>; Thu, 4 Aug 2005 01:56:21 -0700 (PDT) (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 LAA26054; Thu, 4 Aug 2005 11:12:27 +0200
Received: from frcls4013 ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with SMTP id 2005080410575358:630 ; Thu, 4 Aug 2005 10:57:53 +0200 
Date: Thu, 4 Aug 2005 10:57:36 +0100
From: "Denis Pinkas" <[e-mail]>
To: "'pkix'" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/08/2005 10:57:53, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/08/2005 10:57:56, Serialize complete at 04/08/2005 10:57:56
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
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>

>Tom Gindin,
>
>You seem to be arguing for matching CRL certification path with that of the
>certificate.
>
>If so, you will not get an argument from me.

Matching the CRL certification path with that of the target certificate is certainly secure.
However, after some discussions with some PKIX members, it appears that is can be made 
more general without loosing any security.

If the same TA is used and the same sequence of CA DNs (below that TA) is used, 
then it is always secure.

Now if the RP locally "knows" some additional naming rules that apply to every CA below 
each trusted TA from the validation policy that is being used, then this rule may not
be necessary.

Denis

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Tom Gindin
>Sent: Tuesday, August 02, 2005 11:17 PM
>To: Manger, James H; [e-mail]
>Cc: pkix
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>
>        James, Santosh:
>
>        You certainly can construct unambiguous names for CA's, and I 
>think that Denis already knows that (Permanent Identifier is certainly a 
>way of constructing unambiguous names, for example).  The difficulty we 
>have is when one issuer issues a certificate to an organizational CA with 
>a subject name which is convenient and in common use for its organization, 
>but ambiguous, and then a different issuer issues a certificate to an 
>organizational CA with the same subject name which is also in common use 
>for its organization.  This case is most common when both organizations 
>use an acronym.  I do not see why the issuers of the two organizational CA 
>certificates should be assumed to originate at different trust anchors, 
>although they will be different issuers.  In fact, I don't understand why 
>organizational name collisions are thought to be much rarer with a "common 
>trust anchor" than with "different trust anchors" if the actual issuers of 
>the colliding certificates are both public CA's.
>        Such collisions will have negative effects in other parts of the 
>global PKI, of course.  However, unless we are prepared to issue guidance 
>to deprecate the assignment of DN's for organizations with geographical 
>scopes wider than the one for which they are registered and guaranteed to 
>be unique (and many existing CA certificates have such DN's), I don't see 
>how we can be certain or nearly certain that such collisions won't occur. 
>A typical example of what I mean by an organization having a DN with a 
>geographical scope wider than the one for which it's registered is a 
>corporation registered in a single American state and operating in several 
>states while having a DN without the stateOrProvinceName attribute.
>
>                Tom Gindin
>
>
>
>
>
>
>"Manger, James H" <[e-mail]>
>Sent by: [e-mail]
>08/01/2005 11:05 PM
> 
>        To:     "pkix" <[e-mail]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
>trust anchors environment of the relying parties to know if the CRL issuer 
>DN will be unambiguous.]
>You can construct unambiguous DNs regardless of trust anchors.  For 
>instance, including DC components can make a DN as unambiguous as a DNS 
>name.  As another example, the following DN
>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>is unambiguous as it lists a registered business name, its Australian 
>Business Number (ABN) and the jurisdiction where those are unambiguous 
>(Australia).  It is inconceivable that any CA could issue such a DN to 
>another entity in good faith.
>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>issuing CA, but would be ambiguous in a wider context so it should not be 
>used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
>instance.
>
>

Regards,

Denis Pinkas




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 j748sMQb017532; Thu, 4 Aug 2005 01:54:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j748sMpO017531; Thu, 4 Aug 2005 01:54:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j748sMHW017519 for <[e-mail]>; Thu, 4 Aug 2005 01:54:22 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 31224 invoked by uid 0); 4 Aug 2005 08:54:07 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (86.255.29.52) by woodstock.binhost.com with SMTP; 4 Aug 2005 08:54:07 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 04 Aug 2005 04:54:15 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Where to story srv based names
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>

[ Speaking as a PKIX WG member and document author. ]

I do not want to see names appear in subjectDirectoryAttributes.  Not 
everything that can be done should be done.  If we agree that a standard is 
appropriate at all, I strongly prefer subjectAltName.



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 j748PMfY006734; Thu, 4 Aug 2005 01:25:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j748PMJo006733; Thu, 4 Aug 2005 01:25:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j748PLFe006725 for <[e-mail]>; Thu, 4 Aug 2005 01:25:21 -0700 (PDT) (envelope-from [e-mail])
Received: from gyspy.OpenLDAP.org (wep-14-56.ietf63.ietf.org [86.255.14.56]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j748PIIS007997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Aug 2005 08:25:20 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 04 Aug 2005 10:25:17 +0200
To: "Stefan Santesson" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: srv based names
Cc: "Russ Housley" <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail] .corp.microsoft.com>
References: <[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>

I note that the IESG is considering:
http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-12.txt

Given the ability to write this service identification
information as the URL:
        dns:///_kerberos._tcp.example.com?class=IN;type=SRV

in a certificate, why we need another way express this
service identification information in a certificate.

Kurt


At 07:56 AM 8/4/2005, Stefan Santesson wrote:
>The mechanism of SRV RR corresponds to domain names so names are not
>ambiguous.
>
>The SRV RR is interesting as a way to approach a domain searching for
>appropriate recourses/services on that domain. That service may or may
>not correspond to a URI scheme, but it will always correspond to a
>specific SRV tag (or you could not search for it).
>
>What do you gain by preventing me from binding to that service name in a
>cert?
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
> 
>
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:[e-mail]]
>> Sent: den 4 augusti 2005 02:18
>> To: Stefan Santesson
>> Cc: Russ Housley; [e-mail]
>> Subject: RE: srv based names
>> 
>> At 07:16 PM 8/3/2005, Stefan Santesson wrote:
>> 
>> >Manual validation by users is hardly the target here.
>> >It rather a way for a client application to determine that it has
>reached
>> a host that is authorized to deliver the service it searched for.
>> 
>> I see no reason why uniformResourceIdentifier cannot be used
>> for this excepting for the point that the current set of
>> URI schemes is insufficient.
>> 
>> I think it for more appropriate to engineer additional
>> URI schemes where needed than to use the strings intended
>> to be used to locate DNS SRV RR records as a more general
>> service identifier than they were intended to be.
>> 
>> It was noted your proposal was intended for use with
>> Kerberos.  I find this quite problematic given that
>> "EXAMPLE.COM" and "example.com" are two different
>> realms but one domain.  That is, the string
>> _kerberos._tcp.example.com is ambiguous.
>> 
>> Consider a realm called "REALM.TLD" (picking TLD for some
>> reason other than it being a valid TLD) operating using
>> non DNS SRV based location services and a client attempting
>> to verify that the server it contacted has an appropriate
>> issued certificate.  That client is not only configured
>> with knowledge of the CA which issued the certificate
>> for this service, but a collection of other trusted CAs.
>> An attacker can register REALM.TLD and then get one
>> of the other trusted CAs to issue a certificate to a
>> rough service.
>> 
>> Now, it might be argued that this example is a bit
>> contrived, however I think it illustrates a class of
>> problems one will find using names of DNS RRs as
>> alt subjects.
>> 
>> >If you approach a service knowing its SRV service name then binding
>to
>> that SRV name is most appropriate and functional.
>> 
>> To know the name of the SRV RR implies knowledge of
>> service-specific service information, such as a realm in
>> the Kerberos case and an ability to map this
>> information to a (purported) name of a DNS SRV RR.
>> Just because one can map a realm to a (purported) name
>> of a DNS SRV RR does mean it is appropriate to use the
>> result of this mapping as a subject identifier in a
>> certificate.  In the case of Kerberos, I think it
>> can be argued that the (purported) name of a DNS
>> SRV RR should not be used, or only used when the
>> service location policy for that realm is DNS SRV.
>> If the service location policy was to use a configured
>> location, use of the (purported) name would be
>> inappropriate.
>> 
>> I argue it is far more appropriate to use the
>> service-specific information in the subject identifier.
>> That is, use the Kerberos realm as the subject identifier.
>> Why wouldn't a Kerberos realm URI scheme met your needs
>> in this case?
>> 
>> 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 j747f8JW089759; Thu, 4 Aug 2005 00:41:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j747f8T9089758; Thu, 4 Aug 2005 00:41:08 -0700 (PDT)
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 j747f8B1089713 for <[e-mail]>; Thu, 4 Aug 2005 00:41:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.25.238] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j747f1Dd001008; Thu, 4 Aug 2005 03:41:02 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p0623090abf1773daa7a9@[86.255.25.238]>
In-Reply-To: <002a01c598c3$ef32dda0$8217a8c0@arport2v>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <002a01c598c3$ef32dda0$8217a8c0@arport2v>
Date: Thu, 4 Aug 2005 03:40:55 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Qualified Certificate Requests - RFC
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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 9:12 AM +0200 8/4/05, Anders Rundgren wrote:
>Stephen,
>Your suggestion seems to be the right way of doing this.
>
>I would though equip each TPM [1] with a unique certificate containing
>the device serial number etc.   This has the advantage that a CA may
>record this data together with other issuance data making it possible
>to trace credential misuses (theft) down to a particular "container".
>
>Regarding the name of the RFC, "Qualified Certificate Request", I would
>not associate this with qualified certificates in the EU sense, as TPM
>requirements is by no means limited to this particular class of certificates.
>
>Anders Rundgren
>
>1] Trusted Processing Module is becoming the collective term for things
>that were previously known as smart card or HSM

More accurately, TPM is a reference to a set of hardware functions 
that are intended for inclusion in general purpose computers, as 
defined by the Trusted Computing Group 
(www.trustedcomputinggroup.org/home). Smart cards and most HSMs would 
not qualify under this more precise use of the acronym.

Also note that the creation of a cert bound to a device serial 
number, at least for PCs, is precisely the sort of concept that got 
Intel a lot of bad PR a few years ago.

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 j747R2GW083842; Thu, 4 Aug 2005 00:27:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j747R23M083841; Thu, 4 Aug 2005 00:27:02 -0700 (PDT)
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 j747R1xA083797 for <[e-mail]>; Thu, 4 Aug 2005 00:27:02 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.25.238] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j747QsDd000723; Thu, 4 Aug 2005 03:26:55 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p06230909bf176f3e931f@[86.255.25.238]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p06230913bf16922c7f9f@[86.255.29.174]> <[e-mail]>
Date: Thu, 4 Aug 2005 03:25:12 -0400
To: David Chadwick <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Where to story srv based names
Cc: "Kurt D. Zeilenga" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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 5:28 PM +0100 8/3/05, David Chadwick wrote:
>Steve
>
>as everyone at the meeting seemed to agree (I did not hear any 
>dissent on this point), was that the SRV name was an attribute of 
>the certificate holder.
>
>The discussion then ranged over what is the best place to store this 
>attribute in the certificate.
>
>Dennis suggested the subjectDirectoryAttributes extension. You 
>disagreed  and one of your reasons was that an OID would be needed 
>for this. But an OID is also needed for the subjectAltName 
>extension. So this cannot be a valid reason for discounting 
>subjectDirectoryAttributes. You also said that the attribute may not 
>be stored in a directory, but that also is not a valid reason for 
>not using this extension. There are many attribute types defined in 
>X.520 (and some RFCs) that are never actually stored in the 
>directory :-)

I suggested that storing a DNS-centric attribute in the X.500 
directory was anomalous, and merely noted that the lack of an 
existing OID for such an attribute was indicative of this being 
anomalous. Of course one can assign an OID for anything, but that 
does not make it appropriate :-).  Also, as Stefan noted in his 
reply, I'm not sure that this extension is widely used in any uniform 
fashion, since it is a catch-all that could contain a wide range of 
arbitrary data.

>I agree with Dennis for the following reasons.
>
>i) using the subjectDirectoryAttributes extension allows you to 
>define this attribute in a complete and compact way. This is what we 
>actually want to do, regardless of whether it is stored in the 
>directory or not. In particular, we need to specify the matching 
>rules for the attribute value. How is the value stored in the DNS RR 
>to be compared with the value stored in the cert. Bitstring 
>comparison? Case ignore string comparison? Defining the attribute as 
>a directory attribute will ensure that you cover this point 
>properly. If you define it as a subjectAltName extension you will 
>still need to specify the matching rules. Have you thought of that?

I agree that we need to specify matching rules, but one need not make 
this string a directory attribute to specify matching rules. After 
all, the DNS has matching rules for its entries. Assigning an OID and 
using the existing subject directory attribute extension would be 
compact, but I'm not sure how much weight to give to that 
consideration.

>2) if the attribute is defined as a directory attribute, then we 
>also have the option of storing it in the directory, and creating a 
>virtuous circle as shown in the attached diagram. The DNS SRV RR 
>points to a field in the cert, and this points to an attribute in 
>the directory, and this directory entry can point to the DNS.

An interesting observation, but it would be more compelling if we had 
some text explaining how this cyclic linkage improves security, as 
opposed to opportunities for creating more things that have to be 
maintained in synch.

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 j746B5tu055378; Wed, 3 Aug 2005 23:11:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j746B5Db055377; Wed, 3 Aug 2005 23:11:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j746B4KO055336 for <[e-mail]>; Wed, 3 Aug 2005 23:11:04 -0700 (PDT) (envelope-from [e-mail])
Received: from arport2v (195.252.45.62) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 42B94E29006974A8; Thu, 4 Aug 2005 08:10:57 +0200
Message-ID: <002a01c598c3$ef32dda0$8217a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Henson" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Qualified Certificate Requests - RFC
Date: Thu, 4 Aug 2005 09:12:47 +0200
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.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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,
Your suggestion seems to be the right way of doing this.

I would though equip each TPM [1] with a unique certificate containing
the device serial number etc.   This has the advantage that a CA may
record this data together with other issuance data making it possible
to trace credential misuses (theft) down to a particular "container".

Regarding the name of the RFC, "Qualified Certificate Request", I would
not associate this with qualified certificates in the EU sense, as TPM
requirements is by no means limited to this particular class of certificates.

Anders Rundgren

1] Trusted Processing Module is becoming the collective term for things
that were previously known as smart card or HSM

----- Original Message -----
From: "Stephen Henson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, August 04, 2005 01:29
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate



Philipp Gühring wrote:

>
>>>Including a certificate as an OCTETSTRING into a CSR?
>>
>>Note the "or a reference to one" including a URI where it could be
>>downloaded would have a smaller overhead.
>
>
> The problem is that the scenario is a normal user requesting a qualified
> certificate.
> The keypair is generated directly before the request is sent. If it were
> generated by the vendor before, it would make sense to put the certs on a
> server. But that´s not the case.
> And the request should be processed as fast as possible. I don´t see where a
> normal user has a webserver available, where the PKCS#11 driver or CSP could
> upload the certificate. And I don´t think that the user will be happy doing
> that himself.
> So referencing an external certificate is not an option, I would say.
>

I should've qualified the statement. Its clear now I've read the full
details that a certificate isn't appopriate to sign the public key of a
smart card key. Where it might be appropriate is in signing the vendor's
key for trust purposes, see below.

>
>>Ah now that's another issue. Would this "vendor key" be the same on each
>>smartcard or different for each one? Presumably it would have to be
>>different for each vendor?
>
> Every vendor has his own key, or a couple of keys, perhaps one for each kind
> of device the vendor produces. Let´s say normally a vendor should have <10
> keys. But definitly not for every single device.
>

So how does a CA processing the CSR and vendor key know that it can
trust the vendor's key?

That's a case where I believe certificates could have a role. An
authority could certify each vendor key and the vendor would include
references to this information in the form of a URI on its site.

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



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 j745wbN6050100; Wed, 3 Aug 2005 22:58:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j745wb3a050099; Wed, 3 Aug 2005 22:58:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j745waZq050047 for <[e-mail]>; Wed, 3 Aug 2005 22:58:36 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 06:58:35 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: srv based names
Date: Thu, 4 Aug 2005 06:56:36 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: srv based names
Thread-Index: AcWYihPrgXnUSua+QP+7xIubJHiXVQALh20A
From: "Stefan Santesson" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 04 Aug 2005 05:58:35.0133 (UTC) FILETIME=[8CF782D0:01C598B9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j745waZq050090
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>

The mechanism of SRV RR corresponds to domain names so names are not
ambiguous.

The SRV RR is interesting as a way to approach a domain searching for
appropriate recourses/services on that domain. That service may or may
not correspond to a URI scheme, but it will always correspond to a
specific SRV tag (or you could not search for it).

What do you gain by preventing me from binding to that service name in a
cert?

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[e-mail]]
> Sent: den 4 augusti 2005 02:18
> To: Stefan Santesson
> Cc: Russ Housley; [e-mail]
> Subject: RE: srv based names
> 
> At 07:16 PM 8/3/2005, Stefan Santesson wrote:
> 
> >Manual validation by users is hardly the target here.
> >It rather a way for a client application to determine that it has
reached
> a host that is authorized to deliver the service it searched for.
> 
> I see no reason why uniformResourceIdentifier cannot be used
> for this excepting for the point that the current set of
> URI schemes is insufficient.
> 
> I think it for more appropriate to engineer additional
> URI schemes where needed than to use the strings intended
> to be used to locate DNS SRV RR records as a more general
> service identifier than they were intended to be.
> 
> It was noted your proposal was intended for use with
> Kerberos.  I find this quite problematic given that
> "EXAMPLE.COM" and "example.com" are two different
> realms but one domain.  That is, the string
> _kerberos._tcp.example.com is ambiguous.
> 
> Consider a realm called "REALM.TLD" (picking TLD for some
> reason other than it being a valid TLD) operating using
> non DNS SRV based location services and a client attempting
> to verify that the server it contacted has an appropriate
> issued certificate.  That client is not only configured
> with knowledge of the CA which issued the certificate
> for this service, but a collection of other trusted CAs.
> An attacker can register REALM.TLD and then get one
> of the other trusted CAs to issue a certificate to a
> rough service.
> 
> Now, it might be argued that this example is a bit
> contrived, however I think it illustrates a class of
> problems one will find using names of DNS RRs as
> alt subjects.
> 
> >If you approach a service knowing its SRV service name then binding
to
> that SRV name is most appropriate and functional.
> 
> To know the name of the SRV RR implies knowledge of
> service-specific service information, such as a realm in
> the Kerberos case and an ability to map this
> information to a (purported) name of a DNS SRV RR.
> Just because one can map a realm to a (purported) name
> of a DNS SRV RR does mean it is appropriate to use the
> result of this mapping as a subject identifier in a
> certificate.  In the case of Kerberos, I think it
> can be argued that the (purported) name of a DNS
> SRV RR should not be used, or only used when the
> service location policy for that realm is DNS SRV.
> If the service location policy was to use a configured
> location, use of the (purported) name would be
> inappropriate.
> 
> I argue it is far more appropriate to use the
> service-specific information in the subject identifier.
> That is, use the Kerberos realm as the subject identifier.
> Why wouldn't a Kerberos realm URI scheme met your needs
> in this case?
> 
> 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 j740IUEc000193; Wed, 3 Aug 2005 17:18:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j740IUcC000192; Wed, 3 Aug 2005 17:18:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j740IT9Y000185 for <[e-mail]>; Wed, 3 Aug 2005 17:18:30 -0700 (PDT) (envelope-from [e-mail])
Received: from gyspy.OpenLDAP.org (wep-15-50.ietf63.ietf.org [86.255.15.50]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j740IRDL092292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Aug 2005 00:18:28 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 04 Aug 2005 02:17:34 +0200
To: "Stefan Santesson" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: srv based names
Cc: "Russ Housley" <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail] .corp.microsoft.com>
References: <[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 07:16 PM 8/3/2005, Stefan Santesson wrote:

>Manual validation by users is hardly the target here.
>It rather a way for a client application to determine that it has reached a host that is authorized to deliver the service it searched for.

I see no reason why uniformResourceIdentifier cannot be used
for this excepting for the point that the current set of
URI schemes is insufficient.

I think it for more appropriate to engineer additional
URI schemes where needed than to use the strings intended
to be used to locate DNS SRV RR records as a more general
service identifier than they were intended to be.

It was noted your proposal was intended for use with
Kerberos.  I find this quite problematic given that
"EXAMPLE.COM" and "example.com" are two different
realms but one domain.  That is, the string
_kerberos._tcp.example.com is ambiguous.

Consider a realm called "REALM.TLD" (picking TLD for some
reason other than it being a valid TLD) operating using
non DNS SRV based location services and a client attempting
to verify that the server it contacted has an appropriate
issued certificate.  That client is not only configured
with knowledge of the CA which issued the certificate
for this service, but a collection of other trusted CAs.
An attacker can register REALM.TLD and then get one
of the other trusted CAs to issue a certificate to a
rough service.

Now, it might be argued that this example is a bit
contrived, however I think it illustrates a class of
problems one will find using names of DNS RRs as
alt subjects.

>If you approach a service knowing its SRV service name then binding to that SRV name is most appropriate and functional.

To know the name of the SRV RR implies knowledge of
service-specific service information, such as a realm in
the Kerberos case and an ability to map this
information to a (purported) name of a DNS SRV RR.
Just because one can map a realm to a (purported) name
of a DNS SRV RR does mean it is appropriate to use the
result of this mapping as a subject identifier in a
certificate.  In the case of Kerberos, I think it
can be argued that the (purported) name of a DNS
SRV RR should not be used, or only used when the
service location policy for that realm is DNS SRV.
If the service location policy was to use a configured
location, use of the (purported) name would be
inappropriate.

I argue it is far more appropriate to use the
service-specific information in the subject identifier.
That is, use the Kerberos realm as the subject identifier.
Why wouldn't a Kerberos realm URI scheme met your needs
in this case? 

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 j740IKuF000155; Wed, 3 Aug 2005 17:18:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j740IKFi000154; Wed, 3 Aug 2005 17:18:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j740IKY3000146 for <[e-mail]>; Wed, 3 Aug 2005 17:18:20 -0700 (PDT) (envelope-from [e-mail])
Received: from gyspy.OpenLDAP.org (wep-15-50.ietf63.ietf.org [86.255.15.50]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j740I0QW092265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Aug 2005 00:18:02 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 04 Aug 2005 02:15:49 +0200
To: Stephen Kent <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: srv based names
Cc: Love Hörnquist Åstrand  <[e-mail]>, "pkix" <[e-mail]>
In-Reply-To: <p0623090ebf1678a8f0c9@[86.255.29.174]>
References: <[e-mail]> <[e-mail]> <p0623090ebf1678a8f0c9@[86.255.29.174]>
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>

At 03:38 PM 8/3/2005, Stephen Kent wrote:

>At 12:17 PM +0200 8/3/05, Love Hörnquist Åstrand wrote:
>>Love Hörnquist Åstrand <[e-mail]> writes:
>>
>>> I talked to Kurt Zeilenga after the meeting, and then understood what he
>>> was talking about. The uniformResourceIdentifier part of GeneralName (and
>>> this SubjectAltName) can be used instead of srv based names to limit what
>>> service the certificate is allowed to serve.
>>
>>to hopefully clarify,
>>
>>If the service we want to bind the certificate have a uri defined. Example:
>>jabber:[node@]domain[/resource]. Then the step of its to bind the DNS
>>SRV-rr lookup to the service is not needed. Instead the client can bind the
>>thing that user entered (user@domain) to the certificate containing the uri
>>for the same service.
>>
>>The only problem is that services need to specify uri for itself. That
>>might not be obvious when the protocol using DNS SRV-rr is written to
>>support certificates, for example, by using TLS.
>>
>>Love
>
>The clarification is helpful, and it suggests that this solution works best if the application expresses the service name in a URI form. Many apps do that, but not all, as Russ noted.

The lack of sufficient URI schemes implies a need for
additional URI schemes, possibly a general service
URI scheme.

The lack of sufficient URI schemes does not imply that we
should use names of DNS SRVs RRs as general service identifiers.

-- 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 j73NTMoP096819; Wed, 3 Aug 2005 16:29:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73NTM5H096818; Wed, 3 Aug 2005 16:29:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73NTLaR096812 for <[e-mail]>; Wed, 3 Aug 2005 16:29:21 -0700 (PDT) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1E0Sfn-00084C-8U; Wed, 03 Aug 2005 23:29:20 +0000
Message-ID: <[e-mail]>
Date: Thu, 04 Aug 2005 00:29:19 +0100
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Philipp Gühring wrote:

> 
>>>Including a certificate as an OCTETSTRING into a CSR?
>>
>>Note the "or a reference to one" including a URI where it could be
>>downloaded would have a smaller overhead.
> 
> 
> The problem is that the scenario is a normal user requesting a qualified 
> certificate. 
> The keypair is generated directly before the request is sent. If it were 
> generated by the vendor before, it would make sense to put the certs on a 
> server. But that´s not the case.
> And the request should be processed as fast as possible. I don´t see where a 
> normal user has a webserver available, where the PKCS#11 driver or CSP could 
> upload the certificate. And I don´t think that the user will be happy doing 
> that himself.
> So referencing an external certificate is not an option, I would say.
> 

I should've qualified the statement. Its clear now I've read the full
details that a certificate isn't appopriate to sign the public key of a
smart card key. Where it might be appropriate is in signing the vendor's
key for trust purposes, see below.

> 
>>Ah now that's another issue. Would this "vendor key" be the same on each
>>smartcard or different for each one? Presumably it would have to be
>>different for each vendor?
> 
> Every vendor has his own key, or a couple of keys, perhaps one for each kind 
> of device the vendor produces. Let´s say normally a vendor should have <10 
> keys. But definitly not for every single device.
> 

So how does a CA processing the CSR and vendor key know that it can
trust the vendor's key?

That's a case where I believe certificates could have a role. An
authority could certify each vendor key and the vendor would include
references to this information in the form of a URI on its site.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



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 j73MgrVF093862; Wed, 3 Aug 2005 15:42:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73MgrYY093861; Wed, 3 Aug 2005 15:42:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73MgqYT093849 for <[e-mail]>; Wed, 3 Aug 2005 15:42:53 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.1.112 M216P020.dipool.highway.telekom.at  (authenticated user [e-mail]) by mx2.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 54-md50000000543.tmp for <[e-mail]>; Thu, 04 Aug 2005 00:42:47 +0200
From: Philipp =?utf-8?q?G=C3=BChring?= <[e-mail]>
Organization: Futureware 2001
To: [e-mail], [e-mail]
Subject: Re: AW: Qualified Certificate Requests - RFC
Date: Thu, 4 Aug 2005 00:42:45 +0200
User-Agent: KMail/1.8
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Spam-Processed: mx2.go-now.at, Thu, 04 Aug 2005 00:42:47 +0200 (not processed: message from valid local sender)
X-Lookup-Warning: HELO/EHLO lookup on 192.168.1.112 does not match 62.46.16.244
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73MgrYT093851
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>

Hans-Peter,

> Nothing is wrong with this concept 

Thanks.

> but it's not new.   

I already heard about several similar concepts:
* One complex one from Novell with a point system (abandoned, too complex)
* TPM (it could be compatible)
* IBM HSM (not officially documented)
* The first generation of Crypto iButtons (before they used Java)
* Fortezza Cards (I didn´t found information about it, but I guess that I do
   not need it anymore)

The technical model behind is not new, obviously.

But most of them are overly complex, and there is no standard way for doing 
it.
But we need a standard method now for qualified certificates, that can be used 
by all the vendors (SmartCards, HSM´s, TPM´s, other Tokens)

And we need to integrate it into the standard software now.

> You need to pay 
> attention to the different keys, though.  

What exactly do you mean?

> If you want to be able to 
> determine that the certificate request was signed by a specific smart card,
> then the number of manufacturer keys is huge.

No, I just need to make sure that it comes from a secure smart card. I don´t 
care, which one. (And I don´t want to know which one)

> The concept, as far as I am aware of, was developed by TC TrustCenter (they
> are an accredited CA in Germany).  The concept was implemented with one of
> the major HSM vendors.  I don't know which one but it might be Eracom.

Thanks for the information, I´ll ask them both about it.

Regards,
Philipp Gühring




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 j73Mdlue093671; Wed, 3 Aug 2005 15:39:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73MdlBv093670; Wed, 3 Aug 2005 15:39:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73MdkfX093659 for <[e-mail]>; Wed, 3 Aug 2005 15:39:46 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.1.112 M216P020.dipool.highway.telekom.at  (authenticated user [e-mail]) by mx2.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 51-md50000000543.tmp for <[e-mail]>; Thu, 04 Aug 2005 00:39:42 +0200
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: [e-mail], [e-mail]
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate
Date: Thu, 4 Aug 2005 00:39:35 +0200
User-Agent: KMail/1.8
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Spam-Processed: mx2.go-now.at, Thu, 04 Aug 2005 00:39:42 +0200 (not processed: message from valid local sender)
X-Lookup-Warning: HELO/EHLO lookup on 192.168.1.112 does not match 62.46.16.244
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73MdlfX093664
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,

> > Including a certificate as an OCTETSTRING into a CSR?
>
> Note the "or a reference to one" including a URI where it could be
> downloaded would have a smaller overhead.

The problem is that the scenario is a normal user requesting a qualified 
certificate. 
The keypair is generated directly before the request is sent. If it were 
generated by the vendor before, it would make sense to put the certs on a 
server. But that´s not the case.
And the request should be processed as fast as possible. I don´t see where a 
normal user has a webserver available, where the PKCS#11 driver or CSP could 
upload the certificate. And I don´t think that the user will be happy doing 
that himself.
So referencing an external certificate is not an option, I would say.

> Ah now that's another issue. Would this "vendor key" be the same on each
> smartcard or different for each one? Presumably it would have to be
> different for each vendor?

Every vendor has his own key, or a couple of keys, perhaps one for each kind 
of device the vendor produces. Let´s say normally a vendor should have <10 
keys. But definitly not for every single device.

Regards,
Philipp Gühring




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 j73MCDgG091572; Wed, 3 Aug 2005 15:12:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73MCDRa091571; Wed, 3 Aug 2005 15:12:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73MCCNm091565 for <[e-mail]>; Wed, 3 Aug 2005 15:12:13 -0700 (PDT) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1E0RT9-000Nxe-LM; Wed, 03 Aug 2005 22:12:11 +0000
Message-ID: <[e-mail]>
Date: Wed, 03 Aug 2005 23:12:11 +0100
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.92.0.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>

Philipp Gühring wrote:

> Hi,
> 
> 
>>I was instead suggesting that an appropriate certificate (or a reference
>>to one) is included in the CSR. That is the signature format is a
>>certificate, with optional appropriate additional conditions.
> 
> 
> Including a certificate as an OCTETSTRING into a CSR?
> 

Note the "or a reference to one" including a URI where it could be
downloaded would have a smaller overhead.

> 
>>The format is already standardised as are mechanisms for verification,
>>policy checking and revocation. For revocation consider what would
>>happen if the key becomes compromised or inaccessible meaning a new key
>>is required.
> 
> 
> That means that you can´t use your SmartCard for any new qualified 
> certificates then.
> 

I hadn't seen the full details when I suggested a certificate. Since
I've now seen that the vendor key signs other keys generated on the
smartcard it wouldn't serve the purpose I originally thought.

It could serve a different purpose of certifying vendor keys though: see
below...

> 
> 
>>In the system you have AFAICS the trust model is for a single RSA key
>>which asserts that the key resides on a smart card. In the certificate
>>model you can have an appropriate hierarchy which can certify individual
>>manufacturers. A verifier then just has to trust a root.
> 
> Can´t the RSA key be externally linked in a X.509 or OpenPGP chain?
> 

Ah now that's another issue. Would this "vendor key" be the same on each
smartcard or different for each one? Presumably it would have to be
different for each vendor?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



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 j73LqIS1090191; Wed, 3 Aug 2005 14:52:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73LqIRU090190; Wed, 3 Aug 2005 14:52:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73LqGvS090183 for <[e-mail]>; Wed, 3 Aug 2005 14:52:17 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.1.112 M216P020.dipool.highway.telekom.at  (authenticated user [e-mail]) by mx2.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 49-md50000000542.tmp for <[e-mail]>; Wed, 03 Aug 2005 23:52:14 +0200
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: [e-mail], [e-mail]
Subject: Qualified Certificate Requests - Signature vs. Certificate
Date: Wed, 3 Aug 2005 23:52:25 +0200
User-Agent: KMail/1.8
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <[e-mail]>
X-Spam-Processed: mx2.go-now.at, Wed, 03 Aug 2005 23:52:14 +0200 (not processed: message from valid local sender)
X-Lookup-Warning: HELO/EHLO lookup on 192.168.1.112 does not match 62.46.16.244
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73LqHvS090185
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 was instead suggesting that an appropriate certificate (or a reference
> to one) is included in the CSR. That is the signature format is a
> certificate, with optional appropriate additional conditions.

Including a certificate as an OCTETSTRING into a CSR?

The more I think about it, the less I like that idea.
* Possibly not enough memory in SmartCards
* unnecessary overhead
* possibly interoperability issues

I am more for the keep it simple stupid method here. Let us find one good and 
simple way, and implement that everywhere.

> The "identity" can be anything appopriate. The subject DN could be empty
> and an appropriate subjectAltName identity used instead which asserts
> something appropriate. This might for example be and encoded version of
> "Foobar smart card manufacturer, FIPS140-2 level 4 card, Serial number
> 1234".

Hmm. Either a card is secure enough for qualified signatures, or not.

I even heard of a concept that had a complex point system for the 
qualification of a signature. You get points for each FIPS level, for 
biometrics, ...

But I think we should keep it as simple as possible.

That´s the only way to get it implemented, I think.

> Doing this has a number of advantages.
>
> It can be used with other signing algorithms, not just RSA.

Hmmm. That´s an interesting point.
On the other hand, if you want to use a different signing algorithm, you will 
likely have to change your hardware, which should be re-evaluated anyway.

And I don´t see a problem in assigning OID´s to every new parameter set.

> The format is already standardised as are mechanisms for verification,
> policy checking and revocation. For revocation consider what would
> happen if the key becomes compromised or inaccessible meaning a new key
> is required.

That means that you can´t use your SmartCard for any new qualified 
certificates then.

I don´t think that the hardware vendor will operate it´s own CA to publish the 
certificates, CRL´s, ...
Do you know any hardware vendor that wants to operate it´s own CA?
So I guess that the CA service for the qualified tokens would have to be done 
by the same CA, being just more work, to operate yet another root ...
The other variant would be to have the auditor operate the CA.
I also doubt that an auditor wants to run a CA. (Altough it would make sense 
to do so)

> In the system you have AFAICS the trust model is for a single RSA key
> which asserts that the key resides on a smart card. In the certificate
> model you can have an appropriate hierarchy which can certify individual
> manufacturers. A verifier then just has to trust a root.

Can´t the RSA key be externally linked in a X.509 or OpenPGP chain?

> Policy processing allows finer control over the asserted features, a
> given policy might assert additional levels of security. For example
> FIPS level 3 or higher.

Yes, it would be nice to have all information inside the request. But I don´t 
see a real need for it.
Do you know any existing policy system, where I can decide which FIPS level 
the card has to minimum have?

Any other opinions on the topic Signature vs. Certificate?

Regards,
Philipp Gühring




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 j73HdDMA068696; Wed, 3 Aug 2005 10:39:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73HdDue068695; Wed, 3 Aug 2005 10:39:13 -0700 (PDT)
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 j73HdBi3068677 for <[e-mail]>; Wed, 3 Aug 2005 10:39:12 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 18:39:06 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Where to story srv based names
Date: Wed, 3 Aug 2005 18:39:09 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Where to story srv based names
Thread-Index: AcWYUG1gwy0eRq8QRzKEbi0ggizINgAAJo1A
From: "Stefan Santesson" <[e-mail]>
To: "David Chadwick" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Kurt D. Zeilenga" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2005 17:39:06.0297 (UTC) FILETIME=[3F146A90:01C59852]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73HdCi3068690
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 don't want to see this in subjectDirectoryAttributes.

A major reason is that many implementations (ours included) doesn't
parse that extension at all since it is practically not utilized.

But even despite that, I don't think this is a directory attribute and I
don't foresee it used as such. In my mind it fits much better within the
same extension as is used for URI, dnsName, IP address etc.

The matching is not dramatic. It is practically a case ignore exact
match. But you are right that we probably need to address it.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of David Chadwick
> Sent: den 3 augusti 2005 09:28
> To: Stephen Kent
> Cc: Kurt D. Zeilenga; Russ Housley; [e-mail]
> Subject: Where to story srv based names
> 
> Steve
> 
> as everyone at the meeting seemed to agree (I did not hear any dissent
> on this point), was that the SRV name was an attribute of the
> certificate holder.
> 
> The discussion then ranged over what is the best place to store this
> attribute in the certificate.
> 
> Dennis suggested the subjectDirectoryAttributes extension. You
disagreed
>   and one of your reasons was that an OID would be needed for this.
But
> an OID is also needed for the subjectAltName extension. So this cannot
> be a valid reason for discounting subjectDirectoryAttributes. You also
> said that the attribute may not be stored in a directory, but that
also
> is not a valid reason for not using this extension. There are many
> attribute types defined in X.520 (and some RFCs) that are never
actually
> stored in the directory :-)
> 
> I agree with Dennis for the following reasons.
> 
> i) using the subjectDirectoryAttributes extension allows you to define
> this attribute in a complete and compact way. This is what we actually
> want to do, regardless of whether it is stored in the directory or
not.
> In particular, we need to specify the matching rules for the attribute
> value. How is the value stored in the DNS RR to be compared with the
> value stored in the cert. Bitstring comparison? Case ignore string
> comparison? Defining the attribute as a directory attribute will
ensure
> that you cover this point properly. If you define it as a
subjectAltName
> extension you will still need to specify the matching rules. Have you
> thought of that?
> 
> 2) if the attribute is defined as a directory attribute, then we also
> have the option of storing it in the directory, and creating a
virtuous
> circle as shown in the attached diagram. The DNS SRV RR points to a
> field in the cert, and this points to an attribute in the directory,
and
> this directory entry can point to the DNS.
> 
> regards
> 
> David
> 
> 
> --
> 
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Tel: [phone]
> Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://sec.cs.kent.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 j73HQx6V067716; Wed, 3 Aug 2005 10:26:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73HQxQW067715; Wed, 3 Aug 2005 10:26:59 -0700 (PDT)
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 j73HQw8Z067703 for <[e-mail]>; Wed, 3 Aug 2005 10:26:58 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 18:26:52 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: srv based names
Date: Wed, 3 Aug 2005 18:26:56 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: srv based names
Thread-Index: AcWYPOvru8VkdU5EQsuuUYLfbRiL1gAEkx+g
From: "Stefan Santesson" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2005 17:26:52.0566 (UTC) FILETIME=[89BDF360:01C59850]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73HQw8Z067710
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 totally disagree.

I you approach a service knowing its URI, then binding to the URI is most appropriate.

If you approach a system with a specific e-mail address, then binding to the rfc822Name is probably most appropriate.

If you approach a service knowing its SRV service name then binding to that SRV name is most appropriate and functional.

All depends on context and what your prior knowledge is. There is no single name form that will always work.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Kurt D. Zeilenga
> Sent: den 3 augusti 2005 07:18
> To: Russ Housley
> Cc: [e-mail]
> Subject: Re: srv based names
> 
> 
> At 02:49 PM 8/3/2005, Russ Housley wrote:
> 
> >Thanks for following up; however, I do not think that Kurt's observation
> matters in many important contexts.  Stefan made a mistake by using a
> collection of LDAP servers as an example in his slides.
> 
> I don't view it as a mistake as most protocols which use SRV RRs
> use them similar to how LDAP does.  I would have said the same
> thing if he had used http, smtp, imap, etc..
> 
> >There are other services that do not have URLs.  As the discussion in the
> meeting showed, there are services for which we do not have URIs.
> Kerberos KDC is one important example.  KRB-WG is specifying the use of
> certificates in their PK-INIT document, and the Kerberos KDC will be the
> subject of the certificate.
> 
> So create more URI schemes.   Names of SRV RRs are not, IMO,
> good service identifiers.  URIs, in particular, URLs, are.
> 
> I note that there are also services which don't have SRV support,
> one could take the argument that since some services don't have
> URIs and some services don't have SRV RRs specifications, we
> should introduce yet another service identifier form for use
> as alternative subject names in certificates.
> 
> We only need one general way of specify Internet services
> as alternative subject names.  I think URLs is the best
> general service identifier form available, certainly far
> more general than the DNS name of an SRV RR.
> 
> Kurt
> 
> 
> >Russ
> >
> >At 04:51 AM 8/3/2005, Love Hörnquist Åstrand wrote:
> >>I talked to Kurt Zeilenga after the meeting, and then understood what he
> >>was talking about. The uniformResourceIdentifier part of GeneralName
> (and
> >>this SubjectAltName) can be used instead of srv based names to limit
> what
> >>service the certificate is allowed to serve.
> >>
> >>Love




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 j73HGooQ066559; Wed, 3 Aug 2005 10:16:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73HGoQR066558; Wed, 3 Aug 2005 10:16:50 -0700 (PDT)
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 j73HGnNp066547 for <[e-mail]>; Wed, 3 Aug 2005 10:16:49 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 18:16:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: srv based names
Date: Wed, 3 Aug 2005 18:16:47 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: srv based names
Thread-Index: AcWYPNT3Sv4ACBxBQmy9bucycyv/rgAEerhg
From: "Stefan Santesson" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2005 17:16:43.0254 (UTC) FILETIME=[1E905160:01C5984F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73HGoNp066552
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>

Manual validation by users is hardly the target here.
It rather a way for a client application to determine that it has reached a host that is authorized to deliver the service it searched for.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Kurt D. Zeilenga
> Sent: den 3 augusti 2005 07:24
> To: Russ Housley
> Cc: [e-mail]
> Subject: Re: srv based names
> 
> 
> Another problem with using the DNS name of a SRV RR as a
> service identifier is that they are totally alien to the
> user community.
> 
> URIs are not alien.  In fact, its a URI which the user
> actually sees on a side of the bus and enters into their
> user agent
> 
> What do you want your users' certificate view to see when
> manually checking the validity of a certificate (in clients
> which don't understand the necessary alternative subject
> name)?
> 
> Kurt
> 
> At 02:49 PM 8/3/2005, Russ Housley wrote:
> 
> >Thanks for following up; however, I do not think that Kurt's observation
> matters in many important contexts.  Stefan made a mistake by using a
> collection of LDAP servers as an example in his slides.  There are other
> services that do not have URLs.  As the discussion in the meeting showed,
> there are services for which we do not have URIs.  Kerberos KDC is one
> important example.  KRB-WG is specifying the use of certificates in their
> PK-INIT document, and the Kerberos KDC will be the subject of the
> certificate.
> >
> >Russ
> >
> >At 04:51 AM 8/3/2005, Love Hörnquist Åstrand wrote:
> >>I talked to Kurt Zeilenga after the meeting, and then understood what he
> >>was talking about. The uniformResourceIdentifier part of GeneralName
> (and
> >>this SubjectAltName) can be used instead of srv based names to limit
> what
> >>service the certificate is allowed to serve.
> >>
> >>Love




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 j73GlDUd064488; Wed, 3 Aug 2005 09:47:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73GlDKu064487; Wed, 3 Aug 2005 09:47:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73GlCbm064481 for <[e-mail]>; Wed, 3 Aug 2005 09:47:13 -0700 (PDT) (envelope-from [e-mail])
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.12.11) with ESMTP id j73GlC3U002513; Wed, 3 Aug 2005 09:47:12 -0700
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Aug 2005 09:47:12 -0700
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: srv based names
Date: Wed, 3 Aug 2005 09:47:12 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: srv based names
Thread-Index: AcWYPonAHsQezxyNTdCs1tZqIx2WSQAC2E6A
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2005 16:47:12.0648 (UTC) FILETIME=[FF334880:01C5984A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73GlDbm064482
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>

> So create more URI schemes.   Names of SRV RRs are not, IMO,
> good service identifiers.  URIs, in particular, URLs, are.

The way that we create new URI schemes these days is essentially to
assign an SRV or NAPTR prefix value. NAPTR was created expressly for URN
resolution.

All an SRV record is is a substitute for a protocol port assignment. It
is not something that is alien to the IETF way of designing protocols. 


What we see on the side of a bus is usually something like www.ipod.com
or even just ipod.com. It is actually becomming rare these days to see
http://www.ipod.com/ in advertising litterature.

In the original Internet architecture a domain name stood for a machine.
Today people want the domain name to be a logical access point for a
collection of services. mailto:[e-mail] and
jabber:[e-mail] are surely both references to the same person.

In the Web world we would much rather have a URN of the form
user:[e-mail] that can stand for all the uses of the address. 




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 j73GSlfL062601; Wed, 3 Aug 2005 09:28:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73GSlwq062600; Wed, 3 Aug 2005 09:28:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-2.visp.demon.net (IDENT:[e-mail] [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73GSkKl062589 for <[e-mail]>; Wed, 3 Aug 2005 09:28:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.31.254] (open-31-254.ietf63.ietf.org [86.255.31.254]) by lon1-mail-2.visp.demon.net (MOS 3.5.8-GR) with ESMTP id CPA82697 (AUTH [e-mail]); Wed, 3 Aug 2005 17:28:26 +0100 (BST)
Message-ID: <[e-mail]>
Date: Wed, 03 Aug 2005 17:28:28 +0100
From: David Chadwick <[e-mail]>
Organization: University of Kent
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: "Kurt D. Zeilenga" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: Where to story srv based names
References: <[e-mail]> <[e-mail]> <[e-mail]> <p06230913bf16922c7f9f@[86.255.29.174]>
In-Reply-To: <p06230913bf16922c7f9f@[86.255.29.174]>
Content-Type: multipart/mixed; boundary="------------070600040704010704070103"
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.
--------------070600040704010704070103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Steve

as everyone at the meeting seemed to agree (I did not hear any dissent 
on this point), was that the SRV name was an attribute of the 
certificate holder.

The discussion then ranged over what is the best place to store this 
attribute in the certificate.

Dennis suggested the subjectDirectoryAttributes extension. You disagreed 
  and one of your reasons was that an OID would be needed for this. But 
an OID is also needed for the subjectAltName extension. So this cannot 
be a valid reason for discounting subjectDirectoryAttributes. You also 
said that the attribute may not be stored in a directory, but that also 
is not a valid reason for not using this extension. There are many 
attribute types defined in X.520 (and some RFCs) that are never actually 
stored in the directory :-)

I agree with Dennis for the following reasons.

i) using the subjectDirectoryAttributes extension allows you to define 
this attribute in a complete and compact way. This is what we actually 
want to do, regardless of whether it is stored in the directory or not. 
In particular, we need to specify the matching rules for the attribute 
value. How is the value stored in the DNS RR to be compared with the 
value stored in the cert. Bitstring comparison? Case ignore string 
comparison? Defining the attribute as a directory attribute will ensure 
that you cover this point properly. If you define it as a subjectAltName 
extension you will still need to specify the matching rules. Have you 
thought of that?

2) if the attribute is defined as a directory attribute, then we also 
have the option of storing it in the directory, and creating a virtuous 
circle as shown in the attached diagram. The DNS SRV RR points to a 
field in the cert, and this points to an attribute in the directory, and 
this directory entry can point to the DNS.

regards

David


-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: [phone]
Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

--------------070600040704010704070103
Content-Type: image/jpeg;
 name="SRV-RR.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="SRV-RR.jpg"

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR
CALQA8ADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKqz
6lYWpxcXttEc4/eSqvP4mgC1RWHL408KwkCTxLo6seim9jyfoN2TULeO/DI+5qiTf9cInlz9
NqnNAHRUVzR8d6Of9VDq0vuuk3IH1BMYB/Coz42Q/wCp8P63KfQQxpz/AMDkX/CnZi5l3Opo
rkz4v1B/9T4Wv19PPubdf/QXamHxN4jf/VeHbBR/031RlP8A47C3P+c0crJ9pHudfRXGnWvF
b/dttFh9zJLL+PRfy/WrHhjVNf1LV9Qjv5dNextAsWba2eNjMQGI3NIwICkZ4HLY7HI00NTi
3ZHVUUUUigooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiio57iG1gee4mjhhjG55JGCqo9S
TwBQBJRXKXHi24vcpoFh58Z/5frsmOH6quN8n5Kp7NWdNpl1qOTrOq3d4D1gjY28A9tiHLD2
dmqlFszlVjE6bUPFGhaXKYbzVrSKf/nh5oaU/RBlj+VZzeOdPb/j00/WLr/d0+SIH8ZQgqnZ
6fZadF5VlaQW0f8AdhjCD8hVmq5DJ130QHxnct/q/Cms89GeS1Uf+jiR+VA8aTj/AFnhXW1H
dg1qw/SfJ/KiijkRPt5Ei+OtLX/j6tdVtD383T5WUfVkVlH4mtTTvEGjauxXTtUs7px96OKZ
Wdfqucj8ax6p32lafqQAvbK3uMfdMsYYr7g9QfpRyFKv3R21FcLDaanpnOk6xcKg6W18TcxH
2yx8xfbD4Hoa0rbxgtuwi160/s1jwLkP5lsx/wCumAU/4GFHYE1Di0axqRkdRRSKyuoZSCpG
QQeCKWkaBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFUNcvv7L0DUtQzj7Layz5/3ULf0oA4p7Wz8WXd3qOqWsN5bee8NnDcIHRIkO3dtPGWZ
WbPXBUdqsQ+HdEtxiHRtPjGMfJaoOPwFSaNZ/wBn6HYWeMGC3jjOeuQoBq9WyWhwyk27jI4Y
oQRFGiA9dqgU+iimQFFFFABRRRQAhIUEk4A5Jqz4GjI8HWFyw+e+Vr589czMZMfgGA/CsXxD
ObXwzqtwpw0VnM4/BCa7LTLdbPSrO2QYWGBIwPYKB/Ss5nTQW7LVFFFQdAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFY2ua2dPMdnZos2pTqTGjfdjXoZHx/COw6seB3IBN21ZJrOuwaSEhSN
rm/mBMNrGcM3+0x/hQd2P0GSQDzb2U+pXCXetypdSo26K3UYggPbap+83+22T6bQcVNaWS2p
kkZ2mupjunuJPvyt7+gHYDgDgVZrVRsctSq5aLYKKKKoxCiiigAooooAKKKKACkIDKQQCDwQ
e9LRQBQtoLzQm8zRGT7PnL6dKcQt6+Wf+WR+mVPcZOa6nSdYtdYt2kty6SRnbNBKNskLf3WH
8iMgjkEjmsWqlxav9ojvrOQQahEMJLjIZf7jj+JD6duoweaiUb7G1Oq1oztaKzdG1iPV7d8x
mC6gbZcW7HJjbGeD3U9Q3cehBA0qzOvcKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACue8dn/AIoXWV/v2zJ+fH9a6Guc8ef8iVqX+6n/AKGtAMgooorc
84KKKKACiiigAooooAxfGHPgvW1/vWMy/XKEf1r0SvO/F3/Ipar/ANe7fyr0Ss5nVQ2YUUUV
BuFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGfrOqxaNpkl26GR8hIYVPzSyHhUH1PfsMk8Cuasba
WLzLm8kE1/cEPcSgcE9lX0RegH4nkkkurn+2vEss4ObLTC1vAOzz9JX/AOA/6seh8z1q3WkF
1OWtO75UFFFFWYBRRRQB55pHjzxVrulw6lpvgTz7Sbd5cn9rxLnDFTwyg9Qe1b3hfxfFr893
p13ZvpmtWTEXOnyuGZVzw6tgb1II5HqOxUnP+En/ACTDR/8Att/6Oko8Q/uPin4Mki/dvcR3
0MzJwZUWMMqse6huQDwDzU62uaNK7Vi14b8dWfiHxHrOhG3e2vtNnkQAtvWaNH2FwcDBzjKn
1GCecaGp+IP7O8T6Fo32XzP7V+0fvvMx5XlIG6Y+bOcdRj3rgNM0W81PTvEl9pCp/bWmeKrq
6sizbA5GwPEzddrrkEZAJ25IFaL63B4k8W/DfV7cbUuY79imSdjCEBlyQM4YEZxzjNFxuKvp
/Wh0Os+LLu21iTR9C0KbWdQgjSa4VLiOGKFWzgM7E4c4BC45U57VV03xxcrr8GjeJtDfQrm7
XNk73SzxztnBTeoADdMDvkdCV3QX+kas/iS817wXrGlGaZkt9Ss7oGSN5IlZcs6ksrKGUbBt
6ZPoYV8QatZ63p+l+OdBsGjuLtRYalZqZYBcYGwbWyyNksAxxz0GAWouKysd/RRRVGYUUUUA
Urxbm0uE1XT03XkAw0QOPtEWctGffqVPZvYkHr7G+t9SsIL21k8yCZA6NjHB9R2PqO1c7UOg
3P8AZPiCTTWOLTUi09t6JOBmRP8AgQ+ce4kPeomup0UZ/ZZ2FFFFZnSFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFc548/wCRK1L/AHU/9DWujrnPHf8AyJWp
f7qH/wAfWgT2IKKKK3PPCiiigAooooAKKKKAMXxd/wAilqv/AF7t/KvRK878X8eDtZPcWcpH
1Ck16JWc9zqobMKKKKg3CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACszxFqjaN4fvL+NA80aYhQ9HlYhU
X8WKj8a065XxlJ51zoenZ+Wa88+UeqRIWH/kTyjQhSdlcqaZYrpumW9mHMhiQBpG6u3VmPuS
ST9at0UVueeFFFFABRRRQB5t4d0H4jeGdBttHspPC0lvb7tjTG4LncxY5IAHVj2rofDfh3Ub
bUp9e8RXkN3rc0Zt1+zLtht4N5cRoMAtzzubJ6DsSeoopWKcmznvCeg3Whf259qkhf7fq099
F5RJwj7cBsgfNxzjI96x5PAUsPxMsfE9jdItiGmlubNsqFleLYXjAGMt8pbODlc5OcDuaKLB
zPc4rUPDHiLTdeutW8JapZwpeyCW60y+iP2dn2lTICg3Bj8pIGCTkljwKLXw74l1nWLW78X3
mmm0sJEuLWy0xXCNOu7Ejs43cZ+6Dg8Z6EN2tFFg5mFFFFMkKKKKACs3XIpm01rm1Gbyzdbq
3Hq6Hdt+jDKn2Y1pUUDTs7nR2V3Df2NveW7bobiJZY29VYZB/I1PXNeBZNvhw2JP/HhczWij
0RXJjH/fspXS1gd6d1cKKKKBhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFc947/wCRH1g9ltyx9gCCT+VdDWb4hsv7R8NarY4z9ps5oceu5CP60AY9FU9Juvt2jWN5
nPn28cufXcoP9auVuecFFFFABRRRQAUUUUAZ2v2323w5qdqBzNaSxj6lCK7DSrwaho9leg5F
xbxy5/3lB/rWB1qx4EfPgnSou9tEbQ/WJjF/7JUTOmg90dFRRRWZ0BRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABXHa8fM8c6ep5EOmzkD0LyRf/EV2NcbrQ2+PLY/89NMfH/AZV/+KFOO5nV+Bliiiitj
iCiiigAooooA85ghufGfiTW7a98S6rpLafdtDa6ZYXKwSeUqpmZvl3OrkgjIwM8E5rU0XSPE
nhvxILRb651rw9dqWae+uA1xZSBfU/fViAMAcZ7YJfOsrLwf8RZJH1jSLOLX7aSWK8s0uSJo
yjBCWZNpkXATDcgZwD1qHSbP/hEfiHYaBoWqTXelXcc7Xemyyed/Z20b0ZcHMasXAG7rnksS
CJNX2INA0C68U33iS6uvFPiS1+za3c2sUVpqBSNUUggAEHH3sccYAq1ax3nhL4jaNo0PiK/1
S11aCYz2+pT+dJCY1ZldTxtDHI6YO1uvG3L8O+A/D3iufxbc6rZu90NdvIEnSZ1aNcgggA7S
QWJ5B981a+GFhB4b1zV/DF5pkMOq226aC/8AKIkvLZmA3Z5AUEJwGxk4xuViUhvqb3g3UpYd
b8Q+GL69e4utPuzNbebKZG+yyAMi7mO9yucMTnG5Rk8UanqUup/ErSNAsr10hsIJNQ1GKOUp
v6LEhKnJIZgxQ4UqQTngVB4umi8O+MvDviaSRIbaZm0q+csMlHBeLO75VVXUszZBx6jipPhz
/wATO11bxU/zPrV67xMeHFvGTHEjKPlDLhumc5GSafkT05jtaKKKozCiiigAooooATwgdmre
JIR0N3FNj/egjX/2Surrk/CQzr3iN+wlgT8RED/7MK6ysXud8PhQVi3fh6S4upLiHXdXtGkO
dsMyMi/RXVgK2qKRRz/9i69F/qPFdzJ/192UD/nsVKPs/i+H7up6LcjsHsJYj+JErD9BXQUU
Ac/9q8XRff0jRrgf3o9RkjP/AHyYSP8Ax786P7c1uL/XeEr1/wDr1u7d/wD0N0roKKAOf/4S
tY/+PnQtdg/7cTL/AOii1H/CbaCv+vuLm1/6+7GeDH13oMV0FFAGLb+MPDN02yDxDpUj9Ci3
ke4H0IzkVrQ3ENym+CaOVP7yMGH6U24tLa7Xbc28Uy+kiBh+tZM3gzwvcP5knh3SjJ/z0FpG
G/76AzQBuUVz/wDwhWiL/qY722/69dRuIf8A0CQUf8Is0f8Ax7eIddg/7ehL/wCjVagDoKK5
/wDsXXov9R4ruZP+vuygf89ipR9n8Xw/d1PRbkdg9hLEfxIlYfoKAOgorn/tXi6L7+kaNcD+
9HqMkZ/75MJH/j350f25rcX+u8JXr/8AXrd27/8AobpQB0FFc/8A8JWsf/HzoWuwf9uJl/8A
RRaj/hNtBX/X3Fza/wDX3YzwY+u9BigDoKKxbfxh4Zum2QeIdKkfoUW8j3A+hGcitaG4huU3
wTRyp/eRgw/SgCSiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKAPPfC6+T4ft7X/nzeWzx6eVI0eP/HK2KzdPT7Pq+v2fQRaizr7i
VElz/wB9O35VpVstjgmrSYUUUUyQooooAKKKKACneCH2W2r2X/PtqcuB7SBZv5yn9abUXht/
I8X6xbk4W4tbe5UerAyI/wCgj/OpnsbUH7x19FFFZHWFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFcl4q
TyPEfh+86CT7RZH/AIGglH/og/nXW1z3jW2ebwzNcQoXnsXS9jCjJPlsGYD6oGX/AIFTW5Ml
eLRWopsUiTRJLGwaN1DKw6EHoadWxwBRRRQAUUUUAc9rfgXwz4juhdappEM1wOsqM0bvwB8x
QgtgAAZzjtVrQPC+i+F4JodGsEtVmYNIQzOzEDAyzEnA5wM4GT6mteuK/wCFt+B/+g3/AOSk
/wD8RS0RS5mrI6jTtIsdJ+1/YYPK+13L3c/zs2+V8bm5JxnA4HFQXvh3StR1iy1a5tc6hZf6
i4jkaN1HoSpG5evByOTxycs0DxRoviiCabRr9LpYWCyAKyMpIyMqwBwecHGDg+hrHvPih4O0
++uLK61jy7i3kaKVPs0x2spwRkJg8jtRoFpXOi1fSLHXdLm03UoPPtJtvmR72XOGDDlSD1A7
1NZ2kGn2NvZWqeXb28axRJknaqjAGTyeB3rI0Dxp4e8UTzQaPqSXM0Kh3jMbxttJxkBgMjPU
jpkZ6it6mJ3WjCiiigQUUUUAFFFVNUvhpul3V4V3mGMsqDq7dlHuTgfjQBd8EJvtNVvv+fvU
piD7RhYP/aR/OuorM8Paa2j+HdP09zulggVZW/vSYy7fixJ/GtOsGeglZWCiiigYUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAENxaW12u25t4pl9JEDD9ayZvBnhe4fzJPDulGT
/noLSMN/30BmtyigDn/+EK0Rf9Sl9bf9eupXEP8A6BIKP+EWaP8A49vEOuwen+lLLj/v6rV0
FFAHP/2Lr0X+o8V3En/X3ZQP+exUo+z+L4emp6LcjsGsJYT+JErD9BXQUUAc/wDa/F0X39I0
e4H96PUpEP8A3yYSP/HqP7d1uL/XeEr5/wDr1urd/wD0ORK6CigDn/8AhK1j/wCPnQ9dg9f9
BaX/ANFFqP8AhNtBX/X3Nxa/9fdlPBj670GK6CigDFt/GHhm7bbB4h0qR+hRbyPcD6EZyK1o
Z4bhN8Escqf3kYMP0ptxZ212u25t4Zl9JEDD9ayZvBfhed/Mk8O6UZP74tEDfmBmgDcorn/+
EK0Rf9Sl9bf9eupXEP8A6BIKP+EWaP8A49vEOuwen+lLLj/v6rUAdBRXP/2Lr0X+o8V3En/X
3ZQP+exUo+z+L4emp6LcjsGsJYT+JErD9BQB0FFc/wDa/F0X39I0e4H96PUpEP8A3yYSP/Hq
P7d1uL/XeEr5/wDr1urd/wD0ORKAOgorn/8AhK1j/wCPnQ9dg9f9BaX/ANFFqP8AhNtBX/X3
Nxa/9fdlPBj670GKAOgorFt/GHhm7bZb+IdKkfoUW8jLD2IzkVrQzw3Cb4ZUkT+8jAj9KAJK
KKKACiiigAooooAKKKKACiiigDir5Ps3jy9XGFu7GCZfdkZ0f9DHVum+LI/s2t6Hqf8AAWls
ZD6CUBlJ/wCBRKv/AAOnVrDY46ytIK4bXNc8Qat4tl8L+F5ra0NrAk1/qM8LSGAsykIgI2li
nODkEEjKlSa7muG8Pyrb/FrxhazB0muoLO4gDIQJI0j2MwOMEBmA+ufQ4bIj1ZDdf8Jz4Unt
9Rn1F/FOnbvLu7SCwSGeNSRiSMJ98g9R6f8AfS9Rr/ijRfC8EM2s36WqzMVjBVnZiBk4VQTg
cZOMDI9RU2u61Z+HdEutWv2cW1soZti7mJJAAA9SSBzgc8kDmvM7qbxLqnxfW70vT9NguF0S
OW0XV43DJCxG4kISVlDu6duAR3yU9CkubVno2geKNF8UQTTaNfpdLCwWQBWRlJGRlWAODzg4
wcH0NYOk/Ei18RRj+w9D1i7do5CrNAI4UlVWYRPLkqrNhcHkfOvuBl2S61D8UdLn8Q6loNvq
E1lLAltpqzPJcxDLgNvGEUMGYNwSVK89tD4QzRS/DPTEjkR2iaZJFVgSjeazYPocMDj0I9aL
g4pK5D8IdQ1O+8Fwi+s3WFWkeG9e4EjXbNLIXJXqpDcZPXOa7KN/snjXRrk8LcRz2LHtlgsq
5/78sB/ve9cb8MZ7O0TxBoUN0gNlrF0ttZtPueK3UqBhSSdu4nn1J7muu1yCebTGktF3Xdq6
XVuv96SNg4X/AIFjafZjRa8R3tUud3RVewvYNS0+2vrV98FxEssbeqsMj+dWKyOwKKKKACii
vP8AUPHviL/hL9Y0DQPBn9r/ANleR50/9qR2/wDrYw6/K6/7w4J6ds0AegUV5/bfELWbLXNN
sPFfg6fQ7fUpfs1rdpepdoZzjbG2wfLu5wT6dMBivoFABRRRQAUUUUAFFZ93d6jDrGnW1tpf
2ixn837XefaFT7LtXKfIeX3Hjjp1NaFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQBwemwHSbq60FxgWZ32v+1bMT5eP93Bj/wCAA9xWlVvx
Ppc1xFDqljGX1CxDFYx/y3iON8X1O0Ef7SjsTWda3MN7axXNu4eKVQyt6g1rF3Rx1Ycsrk1F
FFUZBRRRQAV434G+INr4Z+HVhHe6Fr0lvb+ZvvYbQG3O6VsYcsB1YD68V7JXG/DbTZYPhnp2
napZPGxWdJra6iIJVpX4ZWHQg9D1BpPcuLVncpeFo7nX/Hc/jOLSX07S7nS1toWuNqzXTFw3
mFVzgYXAJPICEZB4xPDvjKLwzP4tSfRNbvIV128ne5srQSRRrkZDMWGCAuT6AitvwPY3/g/W
9Q8Jzw39xpJb7Tpl80LMgVhl43cEqhBHAwuTuPG5QdDwFZ3Vn/wk/wBqtpoPO1+6mi81Cu9D
twy56qccEcUim1qYul3cnjvxroHinTdHmtNK0+O4SS9u9iSXBZSoRVUklVJJznGS44I59Jrz
zRtLuvBHj26s7W1vJvDutfv4zDbl47K43cqQnCIQfvFRxsGcIxr0OmiZ76bBRRRTICiiigAq
kkH9seJLOwAzb2LLe3Z7ZBPkp9d43+3lj1FSX96thaNMUaVyQkUSfelcnCoPcnit3w9pDaTp
7faHWS+uX8+7kXo0hAGB/sqAFHso75qZvSxtRhd3NaiiisjrCiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigCG4s7W7Xbc20My+kiBh+tZM3gvwvO/mSeHdKMn98WiBvzAzW5RQBz//AAhWir/qFv7b
/r21K4h/9AkFH/CLPH/x7eItdg9P9JWXH/f1X/X+VdBRQBz/APYuvRf6jxXPJ/192UL/APoC
pR9n8Xw9NS0S5HYNYywn8SJWH6fhXQUUAc/9r8XRff0fR5x/ej1KRD/3yYSP/HqP7d1qL/X+
Er9/+va6t3/9DkSugooA5/8A4StI/wDj50PXYMdf9AaXH/frd+n864/xl8ZrHwrqekpHYXVz
aXPm/axLbS280WNm0qsirnq2R7DkV6hXO674H8P+JtWtNR1qxF7JaIUhjlY+WMnJJUcN+OR7
UAW/DvibSPFelrqOjXqXMB4YDho2/usp5B+ta9Q2tpbWNsltaW8VvAgwkUSBFUewHAqagDN8
QaX/AGzod1Yq4jldQ0Mh/wCWcqkNG34MFP4VzmmXv2+wjnaMxS8pNEesUinDofcMCK7WuW8R
6a2n+frtgrEqA97bKMiZAMFwOvmKo7feA2nnaRUXYyqw5loJXPeIvBuneI7q1vZJ7yx1C1yI
r2wl8qYKQQU3YPy8n6ZOMZOd+ORJY0kjYOjgMrKcgg9CKQTRNO8AkQzIqu0YYblUkgEjsCVb
B9j6VqcibWxxqfD+TUrq2ufFev3muG2kDx2xjSC1OAdu6JchmBZuc8jAII4O14g8L2PiL7PJ
PNeWt3a7vs13Z3DRSw7sbtpHHIGDkHgnpW3RSsPmZg6B4R0zw9PNdwm5u9RnUJPf3sxlnkUH
gFj0AGBgAZCrnOKu6PoWmaBBPBpVolrDPO1w8aE7d7AAkAn5RgDgYAxwK0aKdhNtlL+xtL/t
T+1P7Ns/7Q/5+/IXzfu7fv4z93jr04q7UF5LPBY3Etrb/abhI2aKDeE81gMhdx4GTxk9M1V0
7ULmTRFvtZs00qZVd54XuFkWFVJ5MgwMbQGz2z7UAWdKv/8AhG5mtpx/xKbictHL/wA+rueV
Yf3CxJB/hLEH5cEdlXAQavoOvrPp9tqen3/mRMJYYLhJCUPByFOccgfjUVj8TvDmgac2m+Jd
aEGp6dILaYPFI7yDkxyYVTncgDEjgE4OMjOUl1OqlNvRnolFY/hvxTo3i7TpL/Q7z7XaxymF
n8p48OACRhwD0YfnWxUmwV4/B/wmH/C3vHf/AAin9h/8w/7T/avnf8+/y7PL/wCBZz7V7BXL
6H4bvNM8d+K9cmkga11f7H9nRGJdfKiKNuBGBknjBP4UAef+HbvxB8R/FEdh4uu7HSLrwzqE
d62j2luyzTuo+SQu7MPLBI5TOQ5zjKMa/jTUrfxB8R9V0bxDoniPWtI0X7Obaw0SAvGXkhLM
9wQQ275sJgjAVuOWz3HiPwdft400vxf4Y+ww6nDuh1CK5eSJL6AgABmQH5lxxlT/AAk52AGP
X/CGvW3ixvFPgvULS31C7QRalZ6izm1ulVcI+FyVdcADGOO4+YOAcX4R1bWPC/8AwlMWk6Pr
ln4ZtdKuNTsINesXj+zXC8+Sj7jujOS2M54PfczbHhf4bW+reHrPxZc6vfHxhqMSagmtByGt
3dFKoIs7GjC/IVI5UsBtBAXrPDfh3Wtl7d+MdUj1O8vUeBrKDIsYICxOxYyAHJBwXcFsYXOA
S3P6b4N8daVbt4ZtvEtoPC4cpDesHOpwW+B+6Q42AjlQ5yVByAMKoAOL/wCbQ/8AP/P/AF6B
8bf+SQ67/wBu/wD6UR1h+AvDUPjD9nWy0Ge4kt0u0mAmQAlGW6d1OD1G5RkcZGeR1o8Q+B/i
N4y8JzaTruuaNG8SR+Slj5iJdyBly1wxXoFDEKigFmBONooA3PFv/JXvh1/3E/8A0nWuf8Ae
DNG1zxD4o1vU4p7m6sPFd2bNGuHWOB1dX3qikAsTtznOQijHHPca54bvNT8d+FNchkgW10j7
Z9oR2IdvNiCLtAGDgjnJH40eC/Dd54c/4SH7ZJA/9pa3c6hD5LE7Y5Nu0NkDDcHIGR70AeKW
M+keOLCXXvFnhPxrrWqXyOi3Om2ha1tVV3Ci2wwGACMh93zA5zls9G48e+IPgzdWk0GqvcWm
oGGaOaE2l9qGnKoJHzB/3jbsHGchSPnJIboIvBfjjwl9u03wNq2lDQrjMltDqxleTT3bO4RE
Agrkhhuzz1BO5m3NS8Ha0/g5bHTvFmpJr0VwL0ajLKds8/OUdOQsBzgRqNq4Bw2DuAPN/DZ8
Bw+PNNg8OnWfBWuQXCRzWepQuRqETjcYGDuwUkBdpJHLDAZtpX3yvNz4W8ceJdc0aXxdfaHB
pmlXa36Q6OspeadP9XuMo4UZbODzkjHIZfSKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAK5LWNOfRruXU7SMtp8xL3kKDJifvKo9D/EB/vf3s9bRTTsTK
KkrM5NHWRFdGDIwBVlOQR6inU3UNDudJke70iIz2bEtNYL1T1aH+qHg/w4PDRWd7b38HnW0g
dMlTwQVYdVYHlSO4PIrVO5xzg4snooopkBRRRQAUUUUAFFFFABRRRQAVFcXENpbvPPIEiQZZ
jUV5fwWIjEm95ZTthgiUtJK3oqjk/wAgOTgVoaToNxLcR6jrIXzkO63s1O5ID/eY/wAcnv0X
t/eKcrGkKbkJoWkzTXa6xqURjkAIs7Z+sCkYLMP+ejD/AL5HHds9LWXrXiTR/DqQPrGoQ2Uc
7FI3mJClh2z0H4+/pS6V4i0TXCw0nV7G+ZAGdba4WQqPcA5H41i3c7EklZGnRRRQMKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKw/Gk81r4F8Q3FvLJDPFply
8ckbFWRhExBBHIIPOa3Kz9d0z+2/D2p6T53k/brSW283bu2b0K7sZGcZzjIoA8z0j4bfD668
FaX4j8R2Ufn3dlBdXt9d6jMgeWRVLOzGQDLM35muk0waF4T8Dalc/D3ToNZhilMxs7G/Mvmy
YQOA5L/MEAO0cnAAGTXn/wAM/C/w6t/Amg6/4lh0qPUrr7Rh9Su8JLtldP8AVu2xsLt/h44P
XmvVND1bwTa29zb+H9Q8PwwRI11PHYTQqqKAA0jBDgADaCx9qAPMdF+IemDS7Ox0SCW+uLm+
a2sLVgYykXyv+8IDbViRwpIBzsJGR8wi8JHxG3xW8Um4TSkhLWxvljeRmVfJbyRESBk4xuLA
d8AVzgutR0zxkfiS3hsf2bqz3MyWywKk0dovlD7So3HEjByW/vDe2drbh09/q+j6F8XbbWLu
eG2sNT0RYor0JmKeUzLglwMH5AnzE4C7ckDFaJnNONm0updHiLxfr+sarH4Ys9Hh0/TrlrJ5
dUaQvLMn39ojPCjI69cg55IWrrvjbU4/h7rtzHs0/wAQ6RPHbXKooZQxkQCRFcZ8t1JKlh64
zjNcja+GPAvhO91PTfGlpchlu2awvJBcbJ7cqpADRgAsufm4GC3BPbQfw3e3Pw28VRaT4T/s
u3upInsrRt5vZljkBdpN7E9FJVB/tYByCxditE1/EsvjnwrpH/CR3XiW2u4LeeKS702KySJN
jOA0cchDMRkhQSAcc9Rg2viPqL2eqaLFqGr6lo+gS+aZ7zTS3mGYL8iMQuUXG4jG7cc5Ubdw
1PFun6j4v+GU9tbWn2fUL22hmFrM20owZJDGSQPm4K8gc9cdjVf+E0Sx0jVtN8mS7jjj/tHR
W8tY5SR8+yU5KspJ/iIwAecEMyU9ir4CvtMuJ7mPSPGNzrdqV3G21ElrmNwRl1ZtreXgqMbS
M9COQeAsme6+H3w+0W5Wb+x9R1KSO9aJW+cidtkTEMoCsWJPcbdwyVwe80vQ9V1nxraeJ9Y0
Gz0Q2UcqrHFcLLPcSsqoGkdVwUCZAGdwI9DRoPw/nt/BT+GtZ1DzEgvTPYXVnhJYFDB1ZSV+
R92/PXAYgGiw7pFL4jeHtL0Dww3iPQ7OHStV0uSOS3nsYlizudUZXAGGUhuh+nQkHV8EXUMf
x38YWrQRmaazt3ScqNyhY48oD2DbgSO+welIngO71O6tpPFviGbXYLWQSwWn2WO3hLYIzIq5
8ztjOMcjkMRV5vD9jpfxI0vxXA0yXV3MLK6XfmN1aJlVsYyG3CMcHGB0zzSktCqckmlcs+Df
sdp8Y/iHZxeRDJL9hnWFMKX/AHRMjhe/zOCT6vzya9IrLj8OaRD4lm8RRWMaatNb/ZpblSQX
jyDhhnBPyr8xGcADOBitSszpCiivJzptx8VvFuuxaneX1v4T0a7FhHYW8giF7OjK0vnEMSVB
UY4HDKVKsGyAesUV5fq3wg07SbOXU/Akt9omu20TNALa6ZkumBVhHIJGIKkoBjIXnLBgMVn6
54k/4S7wX8NtcMflyXXiWx81AuAJFMiPtGT8u5Wxk5xjPNAHsFFeT+JPC2jeLvjrHYa5Z/a7
WPw0JlTzXjw4uSAcoQejH86PEXw4svBGnSeK/Ah/snUtKiknniklklhvIANzxSBmJ6LkYxz6
HDKAekaJomneHNHg0nSbf7PYwbvLi3s+3cxY8sSTySeTWhVPSdSh1nRrHVLdZFgvbeO4jWQA
MFdQwBwSM4Pqa5fWvHd3D4guvD/hvw5d67qlkkcl4omS2ggVxlQZX4LkbSFA5BPPykAA7Siu
X8HeMf8AhKP7Rs7zTJ9K1nTJRFe2Ezb/AC92SjK4ADqwBII9O4IJ5PS/i3q/iLw+uqeHfA93
qZhRzfot4EW3YE7URmTMzlQGIReN6jkmgD1SiuTk+I3hyHwHD4xluZE0yZP3SMmJXkyR5Srn
l9ysODjgnO0ZrzP4n+OdZvPhnd2XiDwZfaL/AGp5AspvtCToSrrIyy4CtE21eFIyfm4G00Ae
8UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFY
mreGrbUbg3tvNJY6jgD7TAB84HQSKeHH15HYituigGr7nC3E+p6OSusWDPCP+X6xRpIiPVk5
eP8AJlH96rVrd297brcWk8U8L/dkicMp/EV2FYl/4R0XULh7prT7NePy11aO0ErH/aZCN30b
Iq1PuYSoJ7FCio5PC+tW3Nj4gW4UfwajaKxPsHiKY+pU1Xa08Vwf6zSdNuB622oMGP8AwF4w
B/30armRk6M0XKKzzPr68t4T1Bh6R3NqT+sopRL4gf7vhW9UHp5t1bAj67ZD+mafMifZz7F+
iqi2Piyf7unaVaqe8187sP8AgKx4/wDHv8asx+E9TuOdS8QyBT1i0+3WAEehZy7fiCv4UudF
KjJkF7qFnp0IlvLmKBCcKXbG4+gHc+wqO3j1nWSBY2jafanreX0ZDEf7EOQ2fd9uPRuldDpn
hnRtIm8+0sYxdEYNzKTLMR7yOSx/Otapc2bRoJbmVpHh+z0hnmQyXF7IMS3dwQ0rj0yAAq/7
KgD2rVooqDYwPGnhW18ZeFbzRrnCmVd0MpH+qlH3W/Pr6gkd64vwB4J1n4a6EssVvBqUt0qy
ajbR4WeNhnAic/K4AP3TjJyQ3OK9TooAoaVrNhrVs01jPv2NsljZSkkTd1dDgq3sRV+sfVfD
ttqNyt9BLJYapGu2O+tsB8f3XB4kT/ZYEemDzVKLxFdaRKlr4nhjt9xCR6lDn7LKT0DZ5hY+
jHB7MelAHS0UAgjIORRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQBxem/CXwHpVw09v4atHdkKEXTPcLjIPCyMwB464z19TWxH4L8KwpMkXhrRkSZNkqrYRA
Ou4Nhvl5G5VOD3APatyigDkfFdrDYf8ACOS20McMFrei2EcahVSN4nRVAHAG7y+PalihigQp
DGkalmcqigAsxLMeO5JJJ7kmrXjtf+KQu5x1tZIbrPp5UqSH9FNQVpDY5a61TCiiirMAoooo
AKKq6hfRaZYS3k4cxRAFtgycEgf1q1QAVkeJX8nRTd/8+c8F3n2jlRz+imtes/XbX7d4f1K0
xnz7WWPH1Uj+tDHF2aZ3VFUtHvP7R0Swvs5+020c2fXcoP8AWrtYHoBXk+ka9b/Dfxz4g0Xx
JL9l03WtQbU9M1B4SI5HlKiWNmBIXadoyQMAFmIDLXrFV76ws9Ts5LO/tILu1kxvhnjEiNgg
jKng4IB/CgDi/FHxV8OaRpbrpOqWmraxcIyWFnYn7UZZjgIGEZ4G5hwSCQDtyeK5O+8PXHhX
4f8Awy0e8bN1D4lsnmGB8ju0sjJwSDtLFcg84z3r1TTfDWg6NcNcaXomm2M7IUaS1tUiYrkH
BKgHGQDj2FXLqws77yPtlpBceRKs8PnRh/LkX7rrnowycEcigDzvUtW03Rvj6txqmoWljA3h
cIsl1MsSlvtROAWIGcAnHsaseN/G+i6j4avdA0C+tNa1rWLeSztLOxnEpYuNrMzLlUCqxf5i
oIU8jBI7DUvDWg6zcLcapomm306oEWS6tUlYLknALAnGSTj3NGm+GtB0a4a40vRNNsZ2Qo0l
rapExXIOCVAOMgHHsKAJNC0z+xPD2maT53nfYbSK283bt37EC7sZOM4zjJrzvxP4mu73x5fe
GbrxZH4P0+0t4nErxIH1KOQfvDHNJgRFfuqVyc7jztwvqlZ+p6Fo+t+V/a2lWN/5OfL+126S
7M4zjcDjOB09BQB5f8G5tOuPF/jeXSdXvtXsW+weXfX7s00v7uTO4sqng5UZA4AroPgl/wAk
h0L/ALeP/SiSu4+wWf8AaP8AaP2SD7d5XkfafLHmeXnds3dduecdM0WNhZ6ZZx2dhaQWlrHn
ZDBGI0XJJOFHAyST+NAHhekwTL8AfBuspFJNBoWsLql1HEpaRoY7mUPsHQkBtxyQAASTxWx8
XvHnhzV/hheWWkajHqM98kMgW0+fyI1ljYvN3iGSq4bB3MBjrj1yxsLPTLOOzsLSC0tY87IY
IxGi5JJwo4GSSfxrPh8J+G7ezubOHw/pUdrdbftEKWUYSXacruUDDYPIz0oA2KKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKbLFHNE8UqLJG4KsjDIYHqCO9OooA5g6LqPh7954cdZ
rIctpFw+EUf9MHP+rP8AsnKem3rWnpGv2WsGSKIyQ3kOPPs7hdk0P+8vp6MMqexNalZmr6DY
6yI3nWSK6hyYLu3bZNCf9lh29Qcg9waANOiuY/tnUvDv7vxEouLEfd1a3jwqj/pvGPuf765X
udnSukimjuIUmhkSSJwGR0YFWB6EEdRQA+iiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKAMzxFZ/2j4Y1ayxn7RZzRf8AfSEf1rndKuvt2kWV3nPnwJLn/eUH+tdr
XnnhRfL8LafB/wA+8X2f/v2Sn/stXA5660TNmiiitDmCiiigDI8UxNP4S1iNPvtZTbf97Ycf
rWnBKtxbxTL92RA4+hGaLiFbi2lgb7siFD9CMVm+FpmuPCWjyt99rKEt/vbBn9aB9DWooooE
WfAjZ8DaPH/zwtxbf9+yY/8A2WuhrmvAnHhlk/uahfL+H2qXH6YrpawPQWwVy/iTx3p3hzUY
9M+warqmpvELj7Fplm08iwklfMPRQu4Y65yRxzXUV53q+l+K/DXjfUfEfhjSbTWbTWEt1v7O
W6EM6vEjqrRswCKmNmc7iTnAA5AM1PD3xG0vXtcOiS2Gq6PqZi86G11a2+zvcJzkxjJzjafy
JGcNjcstfsdQ8Qapotu0jXelpA11lcKplDMqg9ztXJ7fMOc5A4MeJtL1/wAUaTpHjzwlPoet
W92J9Jlnm8yF5VCMBHOm0MxJGU5UlVBJbC1j+DvBez4r+K4v+Em8Rt/ZUuny72v8teZjL7bg
7f3ijG0Dj5SRQB7RWfpWq/2p9t/0C+s/st3Ja/6XD5fnbcfvI+TujOeG74Neb+C9J1TxJ4h8
Q6lfeK9cS10vxLcxWthBc7YyEdWKyE5LxkbVCcBQGx941j6trusR/C34j3keq3yXVp4lmgtp
luHDwxieEBEbOVXBIwOOTQB7hRXj/jPTvFPhHw5J45k8XX02tWksUtzp6sTprq7iMxJDwQoD
gbiSx2k8Mcr0HjG51TxB4y07wRpOqz6TG1odT1K8t/lmMAkCLHC4PysWzk4GBjkjKkA9Aory
c2fiDwx8UvBuiyeJL7UdEuftrxC6mZp2IgyyTMMLKqthkJGRuYdAK7zxjp19qvg7VbPS7m7t
9Qe3ZrWS0n8mTzV+ZFD9gzAKeRwTyOtAG5RXmet+ObnUvg1Y6rpMsf8AbWupDYWqxB4x9rkO
yRUJIKFSJdrE4yoOTxmPxNp9xYTmLxJ8Q59F8O2tpGtgtreCK/u3jQCSSWQrukbk/KgO7KnA
I+YA9QrH8LeJLPxd4ctNcsI547W637EnUBxtdkOQCR1U964f4ReJH1a88SaTDrs+u6TpssL2
F/downdJQ7FHLYLbSuASB37bQOXsb+80z9k6O8sLue0uo87JoJDG65viDhhyMgkfjQB7xRXD
/F+/vNM+Fus3lhdz2l1H5GyaCQxuuZ4wcMORkEj8a5/4n+MorPxNZ+Fr3xDP4b02S0W+uNRt
I3knm/elRAhQZiyFZi/PQDGMhgD1iivE/AnjeC3+Idt4c0fxTd+J9F1RHdZNR837VZSpGWPz
ugDowXgDofTBL+2UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVzc3h250qZ7vwxNHaszF
5dOmz9lmJ6kAcxMf7y8eqtXSUUAY2leI7fULk2FzDJp+qIu57K5wHI7shHEi/wC0pPvg8Vs1
R1TR7HWbYQX0AkCMHjcEq8TDoyMMFW9wQaxvtWs+GeL8TaxpS9LuKPN1AP8Apoi/6wf7SDd6
qeTQB09FV7K+tNSs47uyuYri3kGUliYMp/EVYoAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACvP/AA5xpUi/3b27X8riQf0r0CuA8P8A/Hne/wDYV1D/ANK5quG5jX+E1aKK
K0OQKKKKACsTwn8vh6KL/nhPPB/3xM6f+y1t1ieHPkGrW/8Azy1Kbj/fxJ/7PQPobdFFFAiT
wN/yBLsdhqV5j/v85/rXTVzHgf8A5Bmof9hO5/8AQ66esXuehHZBXm9zpPjHwb4j1K+8K6bY
6zomq3f2ufTXn8ieKdkIkdZHO3azKrHOeuFUDLV6RRSGebrp/i7xxrmmt4k0ODw9pGkXcOoR
xpdpcz3Nwm7aAynasfIyCueMA8krJDY+KNB+Kmt6jZ+H49S0nXnsg92t8kRtFjTy3LIwy5GS
2B2xzkkD0SigDj/AGiajon/CUf2jb+T9u8QXd7b/ADq2+F9u1uCcZweDg+1cfqfgnxFcfDjx
7pMWn7r7VfEEt7ZRedGPNhM0LBs7sLwjHBIPHSvYKKAOP+KWiaj4j+HGraTpNv8AaL6fyfLi
3qm7bMjHliAOATyaz/GNlqNv4y07X/Cr2N14htrQw3mkTTqkl5YtIOVLH5Nr5IbAyTyTjY3o
Fcv4p8B6X4qvLK/luL7TtTs8iHUNNm8mcIQQU3YOV5P0ycEZbIBw883iW9+L3gS/8Q2sGmrN
/aCW2lxSLM1uFt/md5RwzOT0HCqq9y1ewVyfhf4e6R4W1S51aK51LUNWuUMct/qN0ZZWj+T5
OwIGxcEjPbOOK6ygDzPR/h5fWHxUuNYleP8AsWC4utSsnEmZXubpESVHGMbFEbEYwfmTlvmA
j8QaB4i034i3PiOy8MWPiy1u4ofIjuZ44ZtMkh6eW0mQFYln+UZ3HtjLeoUUAef+CNE8U6Z4
08San4lt7FpNXitZBcaa5MCtEGj2bXPmBiCp6FevIPFZel/D/V7z4Ar4NvfL0/VGRziRhIqs
LkyqCUJGCABkZxnocYr1SigDxvxfZ/E3x14IutKn8O2mkuiRNNEt5FM2oOHX5U+bEKLhnO5i
ThVBPzV1Hi/QNftvFVj408LLHeahBbixu9MmZUW6ti+4hHP3HDHOSccD0Kv3lFAHH+G5vG2r
6xJf+ILWDQdNgykGlwyR3ElwSoy8soyAoOdoTaST83AG7sKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigDAvfDZS8k1LQ7kabqDndKAu6C5P8A01jyMn/aXDe5HFLYeJAb
yPTNZtjpmpvxGjvuiuD6wycBv904Yd1xzW9Va/0+z1Sze0v7aK4t3+9HIuR7H2I7HtQBZorm
PJ1rwzzbGfWtJX/lg7Zu4B/ssf8AXKPRiG926VtaXq1jrNp9psLhZowxVgAQyMOqsp5Vh3BA
IoAu0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVwHh/wD4877/ALCuof8ApZNXf15/
4d5065f+/qN8/wD31dSn+tXDcxr/AAmtRRRWhyBRRRQAViaR+78QeIIv708M/wD31Cif+062
6xLf93421Be02n27D6rJMD+jLQNdTbooooEP8D/8gq/bsdTusfhIR/SunrmvAoz4emk7Saje
sD6j7TIAf0rpaxZ6EdkFFFFIYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFYup+HILy7/tGynk07VQMC8twM
uB0WRTxIvseR2IPNbVFAHOW/iOfT547LxLBHZTOQkV7GSbWcnoAx/wBWx/uP9AWro6jnt4bq
3kguIY5oZFKvHIoZWB7EHgiuc/srVPDnz6ExvdOHJ0u4k+ZB/wBMJD0/3G+X0KigDp6KzdJ1
yx1pJPsrss8JCz20ylJoW9HQ8j2PQ9iRWlQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUABIAyTgV
574WbzPDVlcYwLlWuRn0kYyD/wBCrpvGF49l4UvzA2LmeP7Nb/8AXWQ7EP4FgfoDWZbW8dpa
w20QxHEixoPQAYFXA5670SJaKKK0OYKKKKACsSf9342sG7TafcKfqskJH6M1as13bW+fPuIo
scne4XH51zOs+IdEt9f0S4fWNPVUlmikJuUAQNEzZPPAygH1IpMpI6yq9/eR6fp1zezf6q3i
aV/ooJP8qzh4r0N/9VqCT/8AXBWl/wDQQacD/wAJRc2+m21teCzaVZLyae0liTykIYoC6gMW
ICkD+EsaG0OMG3sdV4WsJdL8K6XZzjFxHbJ53/XQjL/+PE1r0UVidwUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAZWreH7PVnjuGMltfwjEF7bNsmi9gehX1VgVPcVnLrt9oBEPiZENqO
F1e3QiE/9dl5MR9+U916V01IQGUqwBBGCD3oAEdZEV0YMjDKspyCPUUtc0/h+80V2uPDEkcU
RJaTSpyRbuf+mZGTCfoCvqueavaT4htdUnezdJbPUol3S2NyAsqj+8McOv8AtKSPfPFAGvRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFAHOeJdC1XWL7T5bLULO3gtC0nl3Fs0oMhG0PhXXOAWAGf4s9hioP
C+vv/rfElsv/AFw03b/6FI1ddRTu0S4RerRyg8HXj/63xVqo9oYbZQfziY/rT18EW5/12ta1
N9boJ/6Aq11FFF2HJHsc0PAmhn/WnU5j/wBNdVumH1x5mB+Ap48CeF/49Ftpv+u4Mv8A6ET/
APXroqKQ7IxoPCPhq1INv4e0mEjkeXZRrj8lql4is7Wx/sS4t7aGEQapAP3aBcB90Xb/AK6V
01c942+XwxJP/wA+9za3P08u4jf/ANloGdDRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAVn6tothrUKJeQkvE2+GaNiksLf3kccqfp+PFaFFAHMf2hq/hv5dXWTU9
MXpqMEf76If9No1+8P8AbQfVQOa6G1u7e+tY7q0nint5V3RyxOGVh6gjg1NXPXXhyS1upNQ8
PXC6fdyMXmgZS1tcn/bQfdY/31wfXd0oA6GisPTfEkc94um6nbtpuqkZFvKwKzY6mJ+kg/Jh
3UVuUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWH4zga48D69En320+fZ7MEJH64rcqG7gW6s5
7dvuyxshz6EYoAW2nW5tYZ0+7KgcfQjNS1ieDp2uvBOhTP8AffT4C/s3ljI/PNbdABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAVNS0yy1eza01C2juICQ2
1x0I6MD1BHYjkVh51rw118/W9JXv968gH/tZR+D/AO+a6eigCpp2p2Wr2a3dhcx3EDHG5D0I
6gjqCO4PI71brD1Hw5HPeNqWmXDabqhA3XES5SbHQTR9JB78MOzCorTxHJbXUWn+IbddPvJD
timVt1tcn0Rz0Y/3GwfTd1oA6GiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiqeralDo2jX2qXCyNBZW8lxIsYBYqiliBkgZwPUUAXKK8z0nT/iJ4
n0ax10+ObTSRqFvHcLZWmjxzRxKygqA8jbiSME56EkDgCtjwr4k1q30bVYvGthJZ3ehpuudR
jjJt7yIKW82PA5O1csoHBI4BO1QDtKKz/wC29O/4R7+3/tH/ABLPsn23z9jf6nZv3bcbvu84
xn2rl/GHim4t9O8HX+h3m211fW7KFn8oHzbaUMSMOMrkY9CPagDuKK5fR/iL4R1/XH0XS9bg
ub9d+I1VwH2/e2MQFfuflJyASOBmrGkah9o8X+I7L+3Ptn2X7N/xL/snl/Yd0ZP+sx+83/e/
2cYoA6CiuPvvin4J03XJNGu9fgivo5RDIpjkKI5wMNIF2DBODk/Lg5xg10mq6rY6Hpdxqep3
MdtZ26b5ZX6KP5kk4AA5JIAyTQBcork9J+Jfg/XLfUJ9O1qOZNOt2urkGGRGSJQSzhWUFgMc
7QcZHqM8/wCAPitpnijW9S0u51KNryfU510uBLaRQ9oiAq2duASFdjuIOSeAMCgD0yivH/BM
HxD8Y+ELHX/+FifY/tXmfuP7Ft5Nu2Rk+9xnO3PTvXSeFdf1/TvEsvhDxg0c94yPcabqyKsS
X8QI3LsGAJVByVXsCTwAzgG34J+XwtBB/wA+09zbY9PLnkT/ANlroa8/8NeI9O0LRPFuo6pq
27TrDxBdRtJ9nYfZ9zqfLwoJbDyH5sd/QV0Gj+OPDWvf2odM1eCePS+bybDLHEPm+bewClfk
Y7gSMDOcUAdBRXJ6B8S/B/ijVF0zR9ajnvGQusTQyRFwOu3eoBOOcDnAJ6A1oeJfGGgeD7eC
fXtSjs0ncpECjOzkDJwqgnA4ycYGR6igDcorh9a+KHh208A3PibTdUguI28y3sy0UhD3QRmS
N1ADLnb/ABbeCDnBBqTwF4+0jxP4VjuDq0c15p9lC+rSSRmFYpChLkkqq4yjnK8DHpigDtKK
5PQPiX4P8UaoumaPrUc94yF1iaGSIuB1271AJxzgc4BPQGrGv+PvC/ha9az1rVo7S4FuLny2
jdi0ZfYCu1TuO7PyjJwCcYBNAHSUVj6L4p0bxDPcQ6VefaJLeKCaUeU6bUmTzIj8wGcrzx07
4NWLTW9OvtY1HSba4332m+V9ri2MPL8xdyckYOQM8E470AaFFeP638SdUs/Gl3qVvJOPCOja
hBpeoKLXckjuJBLMZNhZfKfy1KjO75cEbxnpPiv47XwT4Tla1uo4dau0K2CvCzhiGQO3TaCq
vkbuCccHpQB3lFeR+Jvjj4bRNKXQNajkL6nbrfM1nNmO03ZlZdyAZwAOMnDHAzgjsJfiX4Pg
0vT9Tm1qOKz1FJ3tZXhkUSCH/WdVyCDwAcFjgLkkUAdZRXHxeK9O1rWPCtzpPiTZY6l9r8uz
+wsf7Q8tcH52AMXlkE843dKw9G+JdjpVv4hn8Xa1HCkPiO7sLIGHLeVGFIULGuSFzyxB6jJ5
FAHplFZcPiPSLnw0fEUF9HLpIt2uTcoCwEagljgDORg5XGQQRjPFSf23p3/CPf2/9o/4ln2T
7b5+xv8AU7N+7bjd93nGM+1AGhRXmfjr4raZoKeHVsNSjU6jcWl3MzW0jEac7EtIvy4BIXGO
WwTgA4I6iTx94Xh8Jw+KJdWjTR5n2RXDRuC7biuFTbvJyrcAdAT0GaAOkorD8NeMNA8YW88+
g6lHeJA4SUBGRkJGRlWAODzg4wcH0NblABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFQ3dpbX1rJa3cEVxbyjbJFKgZWHo
QeDU1FAHM/YNX8N/NpTSappi8nT55czxD/pjIx+Yf7Dn6MBgVraTrVjrUDyWcxLxHbNDIpSW
Fv7roeVP1FaFZGq+HrXU50vI3lstSiGIr62IWRR/dbIw6/7LAj8eaANeiuaTxBd6LItv4nij
ijJCx6pACLZ+w8wHJhb/AHiV9GzxXSAhgCCCDyCKAFooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKy/EeuQ+GvD95rNxa3dzBaIHkjtIw8m3IBIBIGADuJzwAT2rU
qOeCG6t5be4ijmglQpJHIoZXUjBBB4II4xQB5vH8JNIWyml8KeKfEGjWl2nnW8enakTa7igA
kx1cHAJ+fkdCBjFMa3rs/hT4keGfENxBfX2iafJjUIUEf2iOaCR03IAArADnHHOOcbm1I/g9
pFi8y6L4g8T6JaSPv+x6dqZSINtAJwwJJO0ZJJ/LAHUaB4R0Xw34aXQLCyjNgUKzLMoc3BYY
ZpOMMWHB4xjAAAAAAOXmnhtv2dg88scSHwuqBnYKCzWwVRz3LEADuSBXL+L4bG5+Efwzg1Qx
jT5L3S0ujJJsURGBg+WyNo255yMV1EXwa8OR289m99rM+mskwttPnvPMt7NpAw3xIVwHUO20
tuwTnk81uaj4C0fVPD2haHeGeWx0aW3lhRijed5KFFWUFSGUgncABn2oA5v4y6VYp8PIns7a
OLVLG4t49E+zfJLHKZEUJCFwc7QcKP7oOPlBGfNPNa+JPjNcW8skM8WmWrxyRsVZGFnIQQRy
CDzmtyL4c+GvDV4viO/v9Vu7TRopJrW21C5a4g09FAOYkxu+VVAHJ6A8sART+HGqWniHx947
17S3kn0u7ewSC5MTosjJCQ4G4A5BIyPceooA5vwvofjPVvhrZ2GnWHw/m0K/tELoyXAeU7VB
aUx8ecCo3MOQy9QRVeHS7dP+FUeH9e1ax1fTTLfiRorwy2lw6f6hcnAfaSsYUj1TBBwe0ufg
14cuLi5WO+1m10u6uBcT6Pa3nl2UjAqSDGFyASo6EY424wMdZrHhjS9a0NNImg8i3h2G1a1/
dPaOn+reEj7jL2x9MEEigCO/0vw5L4s0jUr5LRdeiSVLB2l2Suu07wq5HmAKxOCDt3EjGa5v
4Wf8zr/2Nd9/7JWh4e+HOl6Drh1uW/1XWNTEXkw3WrXP2h7dOciM4GM7j+ZAxlsyad4AsdJ8
WXGvWGq6zALi4kuptOW7/wBEklddrO0eMkk/N14IGMAAUAZfwS/5JDoX/bx/6USUeIv9O+NH
gu2tvnm020vr27Xp5cMiCJGyeuXGMDJHUjHNV7H4O2emWcdnYeMvGVpax52QwamI0XJJOFCY
GSSfxrqPCng7S/B9ncRWHnz3F1KZrq9u38ye4cknLvgZxk447k9SSQDxbVrnf8NPiza/88/E
jSf99XMY/wDZK7n4y/8AEv8ACXh6zsvsNtanW7SAw3XyWZjVXKpMo48kFVJHQBfanN8O9JuN
c8X+H5bq+Fn4gjg1KZldN6S/aJWYIduAuQnBBPXmvQtV0qx1zS7jTNTto7mzuE2SxP0YfzBB
wQRyCARgigDx/wAZeFfHOp+H7ZdWm8B6Rb6W8b2l/BLc2zWJBUL5bnhAcKMdPu45CkdB4fhs
b347+MZ70xzahYW9mmniWTc0MTQ5l8tSeBuYZIHG8/3znQ0T4T6Lo+qaffz6lrOrnTU22EGq
XQmitTwA0aBQAQFGOwwDjIBGx4l8F2PiW4gvDe6lpeoQoYhfaXceRO0ROTEzYO5N2GwRwRxj
JyAY/iTS/Dlh4c+IM2kpaR6pc6ZK+ppDLlg3kSFC6ZwhIZjnA3ZJOetcn4qNu/wg+HFrfz+V
pl3d6VDfhpjEjwGElg7AjC8A9eNoPavQNC8AaFoWh6jpUcc92uqeZ/aF1dylp7vfkHfIMHox
AxjqT1JJr6N8OdL0vQ77RLq/1XWdMu4o4Ta6pc+akKJnaIgAuzqOnTapGMUAc/8AGyx0ux+G
f2uOOC0vtMlgGkSRN5TwPvQbYtuMfICdo/uA4+UEXJIIZv2iYXlijd4fC++JmUEo32krlfQ7
WYZHYkd6saJ8J9F0fVNPv59S1nVzpqbbCDVLoTRWp4AaNAoAICjHYYBxkAjpP+Ebs/8AhMv+
Eo8yf7d/Z/8AZ/l7h5fl+Z5mcYzuz3zjHagDk/EU8Pgz4m6d4mupY7fR9Zt/7LvpCwjSO4Ul
4ZZMffJUNHkgBAMlgOKz/BmtL4W+D+o+NdUgkS41G4uNWnt2DIrSyybY1TglUfEeCd33s5xU
nxhvdO1nTIfAkKef4i1SWB7KMwMwgXzDumZgDtUKkgJGWAJ4xk12GqeDtL1TQ9M0STz4tM0+
WB0tY3ykyQ/dilDBt8fAyD12g5oA8n0ix8dj4X3Phqf4d/a5NSimkmv7nUoEkkllJZZpI3G7
zFyn3juyg6EcWNf8Qv4h/Zo1B7pZ01Kw8iwv0uCxkWeKeINvLAEsRtY9cFsEkg17hXJ3vw80
W/t/ElrM92LTX3jlubeOQJHFKoH72MAcOzBWYnO4qM5HFAGX8U/+ZK/7Gux/9nqPxnBDc/Fv
4cpPFHKgfUHCuoYBlhRlPPcMAQexANaE3w2sbvw0NGvtc8QXhjvVvre/uL7ddW8qgAFH24AA
zwQcFiRzgi5a+B7O3vPD15Nqmq3t1oX2n7PNeXAkeXzxhvNYrlsDhcYxgdaAMfxb/wAle+HX
/cT/APSdaz/hTY6X/wAJD47v1jgOrjxBdQyPuzIsG/KjH8Klt/puK99ox3Go+G7PU/Eei65N
JOt1pHn/AGdEYBG81AjbgRk4A4wR+Nc3N8J9Fa4vby01LWdO1C8vZryW+sLoQz4lILQ7gvMW
5QwUgkEdeTkA5O2sbfTbf4x2mkx+VokdoRBHCxMCTm1czqn8IYMVDKPu4UYAAFdJNPDbfs7B
55Y4kPhdUDOwUFmtgqjnuWIAHckCuo0Dwjovhvw0ugWFlGbAoVmWZQ5uCwwzScYYsODxjGAA
AABy8Xwa8OR289m99rM+mskwttPnvPMt7NpAw3xIVwHUO20tuwTnk80AYesf8k8+Ev8A2FdH
/wDRRo8af2xd/HDTLPSf7DmuotE8+1h1ze0KSeexLxKvImwinI52ofSu41TwHpeq+EtM8Oy3
F9FDpnkGzuoJtk8TwrtRwwGN2Mjp3yADgivqHw50vVfDlhpN/f6rc3Gnyma11aS5zfRPv3ZE
uPoOnRV7qCADl9P8O+J4/ivo/iDX7vwpY3UsU8MsOmXE0c2oIIzgFH4k2HYfYAZztXHrFcv4
W8B6X4VvL2/iuL7UdTvMCbUNSm86coAAE3YGF4H1wMk4XHUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADX
RJY2jkRXRgVZWGQQeoIrnDod/oLGXw26Na5y+k3DkRf9sW5MR/2eU9l610tFAGVpOv2ervJA
oktr6EAz2VyuyaLPcjuvoykqexrVrN1bQrHWUjNyjJPCd0FzCxSaE+quOR7joehBFZf9q6p4
c+TXlN5p69NVt4+UH/TeMdP99fl9QgoA6aio4J4bmBJ7eVJYZFDJJGwZWB6EEdRUlABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FAHPXP7r4haa3a40u5Q/VJYSB+Tt+VdDXPa3+68U+GJ/7889tn/egd//AGlXQ0AFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFAHOz+HJtOne98NTx2UrsXmspATa3BPUlRzGx/vJ9SGqxpfiKG9u/7OvIJNO1YLuNnORlw
OrRsOJF9xyO4B4raqlqmk2Os2n2a/t1mjDB1OSrIw6MrDlWHYgg0AXaK5nz9a8NcXQm1nSh/
y3RM3cA/2kH+tA9VAb/Zbk1u2GoWmqWcd5Y3MdxbyDKyRtkH/wCv7dqALNFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBz3ir92dDuenk
6tBz/vhov/aldDXPeNvl8MST/wDPvc2tz9PLuI3/APZa6GgAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsK/8A
DgN5JqWjXP8AZupOcyOqbobg/wDTWPgN/vDDD1xxW7RQBg2PiMreR6brlt/ZuoudsWW3QXJ/
6ZScZP8AsnDexHNb1V76xtNSs5LO+t4ri3kGHilUMp/A1g/ZtZ8N82Rm1jSh1tZXzdQD/pm7
f60f7Lnd/tHgUAdNRVHS9XsdZtTcWM4kVTtkQgq8bd1dTgq3sQDV6gAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAoorJ1DxPoWlTeTfavZQT9oWmXzD9E+8fyoA1qK5pv
G9i//Hlp2sXh7eXYPED9Gl2A/XOKibxRrEv/AB7+F5kH/T5exRn/AMhmSnZkuSXU6qiuSOte
K5Oml6Nb+5vpZv8A2klMN74vfpd6HFn/AKcpZMf+RVz+lHKxe0j3NTxnA1x4H16JPvtp8+z2
YISP1xWxbzLcW0U6/dkQOPoRmuOuT4turWa3k1bRCkqMjY0mUHBGD/y8ms7wxeeKpvCukTQ6
vpgV7OE7J9NdyvyDjKzLkjpmjlYe0j3PRqK4/wC1eL15/tPQ3/2f7LmXP4/aD/KlGp+LY+se
iXH082H/AOLo5WHtI9zr6K5MeIfEkf8ArfD1g49bfVGJP4NCv86kXxhNH/x9+G9YhHd4xDMv
5JIW/wDHaLMfPHudRRXOp468O5xc35sD/wBRCCS1H5yqoP4Gt23ube7hWa2njmibo8ThlP4i
kUS0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAY+qeHbe/uhf200lhqigKt7b4DMB0VweJF9mBx2weaqQ+IbjS5ktPE0Md
qzHbHqEWfssx7Ak8xMf7rcdgzV0dMmhiuIXhnjSWKRSro6hlYHqCD1FAD6K5n+yNS8PHf4ff
7TYjltKuJMBB/wBMJD9z/cbK9hsrT0nXbLWRIsDPFdQ4E9pOuyaEn+8h7ehGQexNAGnRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQBXvb61020ku72dIIE+87nA9h7kngDqTXNza/rOp8a
TZpY2x6XWoIS7D1WEEEfV2Uj+6aqQ3aa94i1O4lPmRaXdmztoiOI3VFLyY/vEuVz2UcY3NnW
q1ExnUadkZEmhfbedX1K/wBRJ6pLN5cX08uPapH+8D9avWWnWOmxeVY2Vvax/wByCJUH5AVZ
oqrGLbe4UUUUCCiiigArD8I/L4bhh/54TT2//fuZ0/8AZa3Kw/DXyLq1v/zx1Of/AMfIk/8A
alAdDcooooAKKKKAAjIwelZMvhnR5JzcR2S2tyetxZs1vIfq8ZBP4mtaigE7GdF/wkGmc2eq
LqEI/wCXfUlG7HosqAEfVletfS/EtvfXK2V1BLYagQSLefGJMdTG4+Vx34OQOoFQ1BeWcF9b
mG4TcuQykHDIw6MpHIYHkEcik4o0jVa3OoorD8JarNq2giS5k8y5t7ia0lkC48xopGj346fM
FB44BJFblZnSFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFZmraDZauY5ZPMgvIf8AUXlu2yaL6N3Hqpyp7g1p0UAcyNa1Dw+f
L8RostmPu6tbpiNR/wBNk6xn/aGU9dvSukjkSaJZInV43AZWU5DA9CDTiARgjIrnJPD9zpEr
XPhmWO3DMWk02Yn7NKe+3HMLe6gr6qTzQB0dFZGleIbbUbhrGaKSx1SNd0ljc4Dgf3lI4df9
pSR64PFa9ABRRRQAUUUUAFFFFABRRRQAUUUUAeY2cV5Z6zr2oWCefv1KVbi1LBfMAxhkJ4Dj
OOeCMAkYBrd0/W7DUpGhhm2XSDMlrMCkqfVDzj36HsTVPSv+P3XP+wpN/wCy1Yv9LsdTjVL2
2jm2HKMw+ZD6qw5U+4NapaHHOXvO5qUVzw0rU7P/AJBuuThB0hv0+0oP+BZWT83NOGp6/bf8
fOjQXaj+KyugGP8AwCQKB/32aBaG/RWEPFVtH/x+adq1oe++yeQD/gUQcfrT08X+HXYIdasY
nPRJphEx/BsGgLM2qKqwanYXWPs99bTZxjy5VbOenQ1aoAKw9H/d+IfEUP8AeuIZ8f70CJ/7
TrcrDtv3XjjUV7TafbOPqskwP6FaBo3KKKZJLHCu6WREXpljigQ+isufxLoNsP8ASNb02Lv+
8ukX+ZqsfF+jN/x7zz3Z7fZLSWbP4opH4mgLM3aKwT4gvZ+LLw9fv6SXLRwJ+OWL/wDjtNP/
AAkt5/rLjT9OQ9RAjXEn4O21R/3waAN2WWOCJpZpEjjQZZ3OAB6kmsRtal1b9zogJhbh9Rdc
RqP+mef9Y3oR8vqTjaWx+HLNpVmv5J9TnU5V7194U+qoAEU+4UVr07C5l0G/Dy2js/Dc1tFu
KRahdIpZixIErcknkn3rrK5nwN/yBbz/ALCV3/6OaumrJnbHZBRRRSGFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFDVd
Gsdat1hvYd+xt8UisUkib+8jjBU+4NZH2zWPDfGpCXVdLHS9hj/0iAf9NY1++P8AaQZ9V6mu
mooAgs7y21C0iu7O4iuLeVd0csTBlYexFT1gXnhxobuXUdBuRp19Id0ybd1vcn/ppHkc/wC2
uG9SRxT9P8RrJeJpuq2x03VGzshkbdHPjvFJwH+nDDuooA3KKKKACiiigAooooAKKKKAOC0r
/j91z/sKTf8AstadZmlf8fuuf9hSb/2WtOto7HDU+JhRRRTICmuiSKVdVZT1DDIp1FAGdPoG
jXWftGkWEuc58y2Rs569RVb/AIRDw4Pu6JYoP7qQKoH4Ditqiiw7sxf+ES0P/ny/8iv/APFV
kT+GNHi8X2MX2T91PYzkjzX+8jxY7+jtXY14v49+HV1qPxB0ya2aZ9O1ScLONxIgYfM+PQFQ
SPcH2pMuGr1Z6aPCXh9gC2mQSjsZCX/LJNPj8J+HYm3JoWm7zwXNqhY/UkZNa0caRRrHGoVE
AVVAwAB0FOp2IuyCCytLY/uLWGLv+7jC/wAqnoooEFFFFABRRRQBJ4G/5At5/wBhK7/9HNXT
VzPgb/kC3n/YSu//AEc1dNWL3PQjsgooopDCiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKq6hp1nqtk9nf20dxb
v1SQZGR0I9COoI5FWqKAOZ2a14b/ANX5+taUP4GObu3HsT/rlHocP7ueK29N1Sy1ezF1YXCT
wklSVyCrDqrA8qw7ggEVbrF1Lw5FdXh1GwuH07VcAG6hUESAdFlQ8SL9eR2IoA2qK5628RS2
dzHY+IrdLG5kbbFcoSbW4PYK5+4x/uNg+hbrXQ0AFFFFABRRRQBwWlf8fuuf9hSb/wBlrTrM
0r/j91z/ALCk3/stadbR2OGp8TCiiimQFchqXxBtdP1690eLQte1C4svL85rC0EqLvUMvO7I
4PcDoa6+uK8M/wDJT/HX/bh/6JNJlRS1uXdE8d6drOsHSZLLUtL1Ax+bFb6nb+S8y85KDJzj
B/XGcHG3/aP/ABPP7L+xXn/Ht9o+1+V+4+9t2b8/f74x05rk/ivDFF4Lk1lI0Go6XPDcWVwV
BaF/NQEjPUEdQcg4HHAq19suv+Fw/YftM32T+wPO8jefL3/aMbtvTdjjPXFFx2TV0dfRXlHg
hdRTwNF411LX9Yv5bS2upksWutsLqnmDa+QS7ZBIY9PlGMKK55vFFhf2MmqzfEnUrTX5ds8d
rFBMllbthT5LRhWDKCCpbJz1IbncuYfs9bHvFFeXy+MNb8U+HfC9jpph0y/8RfaEmu1Yn7Os
PEhjHXcwBI546Zz8w27Xwfremao0dr4o1K70e8tpIbtb+5L3MLbTskgcDCtk98Yxn5jja7ic
bbnSaVrVnrL6gtmzsLG7ezlZlwDIoUtj1ALYz6g44wTo15F4N0z+w7fxX4g/tTWLj+xtSvx9
ke8xFdeXH96Ubfmc5+96gHHFaGn+GfE/iDQE8Rt4uv7XWb1VvLW3t5StlEpAZI2jwcjHBPvy
HwSxcbgr7nptFeWat4n1bxF4D8IanZXb6TfajrENu8luSyg5kQnaT8ykqG2HI7HPWtDVrG68
EzeH9QXXNYvtPj1IxX32+7LKEnQIHkfgBI2UEBhjL9Rmi4uQ9DorkPtl1qvxR+xwXMy6fotl
vuUicor3E33UkU8OojG4YHB79q6+mS1Yk8Df8gW8/wCwld/+jmrpq5nwN/yBbz/sJXf/AKOa
umrF7nfHZBRRRSGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEVzbQXltJbXUMc8EqlZI5FDKwPYg
8EVz/wDZuq+Hfm0Zm1DTh97TbiT95GP+mEjdv9hzj0ZRxXS0UAZ+k63Y6zE7WkjCWI7ZreVS
ksLejoeVP8+oyK0KytV8P2mqSpdBpbTUIhiG+tiFlQemcEMv+ywKn0qguu3mhuIPEscawZwm
qwKRAf8ArqOTCfckr/tDpQB0lFIrK6hlYMpGQQcgiloA4LSv+P3XP+wpN/7LWnWZpX/H7rn/
AGFJv/Za062jscNT4mFFFFMgK88kj8VaF478R6lpvhf+1LTUvs3lyf2hFBjy4tp4bJ6k9h09
69DooaGnY4M2XibxnfQW/iHSIdG0S2kjuJLYXK3El66kkIxX5fK+6SGXOQMdcrqf2Rff8LT/
ALZ8j/iX/wBifZPO3r/rfP3bcZz93nOMV1FFKw+Y43wb4Zubb4Xw+HNZie2mkguIJ1R1ZlWR
35BGRnawPesvT2+Iegacnh+10aw1FbZlgtNWluFjjEAwFMkIO8lVyDg54/ixlvRqKLBz9zjd
c8M6vJBoeq2uovfa5ojNIPNWOJb1XAEsfC4jLKMKecd+fmD9IufGmq+IoZ9S06HQtIto28y1
86O5ku3bIHzr9xV4PY545B+Xr6KLBzaHnmk6JrlrqHiPQL3Rt+i61e3c76pDeIDGkycARkbi
3AGemT3AyYbVfiLomjnw3ZaXZ3fkYt7PWzcJGkcPAVmhOSWVcjv0HD4y3pNFFh8/kcBeeCbn
TvDfhHRtL33i6XrFvdXErsqHYGdpHwT0y/CjJxjr1rrte0mLXtAv9Km2BbqBogzxhwjEfK+D
1KnBHTkDpWjWR4k8PxeJtKOnT39/Zws2XaymEbSLtKlGyDlSG5HfAosLmbepyfwhtrqfwzN4
g1Gb7Rf6pIAZyxLtFCPKQN23Aq/PJOQSSenodQWdpBp9jb2Vqnl29vGsUSZJ2qowBk8ngd6n
ppWCTu7kngb/AJAt5/2Erv8A9HNXTVzPgb/kC3n/AGErv/0c1dNWL3O6OyCiiikMKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigApGVXUqyhlIwQRkEUtFAHNtoV5obmfw1JGsGcvpU7EQH/r
keTCfYAr/sjrV/StftNUlktSslpqEQzNY3ICyoPXGSGX0ZSVPrWrWfq2iWOsxIt3GwliO6G4
iYpLC3qjjlT/AD6HIoA5LSv+P3XP+wpN/wCy1p1yGm397od5rCaikt5ZLqMobUI0BdDxzLGo
6f7SjHXIUc11cE8N1Ak9vKksMg3JJGwZWHqCOtbR2OGoveZJRRRTICiiigAooooAKKKKACii
igAooooAKKKKACiiigCTwN/yBbz/ALCV3/6OaumrmfA3/IFvP+wld/8Ao5q6asXuehHZBRRR
SGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHBaV/x+65/wBhSb/2Wq8+hSWs
73mhzrZzud0lu4Jt5z33KPusf7y8+obpVjSv+P3XP+wpN/7LWnWy2OGbtJkVs80ltG9xCIZi
uXjD7gp9Ae/1qWiuD1658R6h8Rk0DR/EH9k240kXrH7HHPubzih+9yOCO/bpzTJSud5RXnmo
TeNPBnl6xfat/wAJJpEeRfQR2UcEsCcfvU2/exzkE4x7ZZZPHHirWtK1fwy3hxE1GG9W4mkt
Y9rC6jREf5G5OdpYjb1OOG6FXK5G9jv6KwdT12KfwJqOuaNdpIo0+a4tp0AIDKjEHBHUEcgj
gggisi88U6jZeAvDt7D5M+sav9jt4nuE/dedKoJZwpBC4Dfd744xRcSi2drRXB3eh/EKytXu
rLxlDqNxDh0s5tMihSfByULg5GRkdvqOo6vQtTl1jRLW/n0+50+aZSXtblSrxsCQQc44yMg4
GQQcDOKLg1bW5o0UVxWoahr/AIg8V6loWharDpEGlRwNcXL2gnlklkDMFUMduzbgk4Dbh3Bp
iSudrRXDW0vjLw3r9nDqly/iPSb5lha4t7NYZLKQk4ZlXrGR1YnjHbAD1ZJPFWu+O/Eem6b4
o/su0037N5cf9nxT58yLceWweoPc9falcrl8z0OivPLq58W+ENY0WTUvEEOuafqN6mnyRPZp
bPE0n3XUpnOMHIP0xzlduXV77T/iPBpd1Pu0zU7Jnsw6KStxGfnRSoyF2Hcd+eehHSi4uU6i
iua8da1eaL4bZtLZP7WvJ47OwV1yGmkbA68AhdxBbjIGc9D0UKNFBHG8rzMqhTI4AZyB1O0A
ZPXgAe1MVtLk/gb/AJAt5/2Erv8A9HNXTV5lpHxD8J+FLC5tNZ1qG3uW1K8Pkojyuo80n5lQ
ErkEYzjPbODW74l+IWjaP4BbxPa38EsNzEw05zG7pNPsYojBRleUIOduMEEg1i9zvjsjsKK8
T1P446ZF8MkbTtajm8WmygVlezkAE5CiVvuBMjLkfw5A4I4PoEHxL8H3OjRawmtRjT5L0WC3
EkMiKJyu7adyjaNvO44UdzSGdZRXDzeOdG17TtIv9D8UfZLWTW4bFn/s95PtTkZNth1BTcCP
3nbHWqa+PodF8Z+Nk8R6tHb6Ppj2CWitGCVaWIswXau9ySM45wATwAaAPRKKy9A8R6R4p0td
S0W+ju7QuU3qCpVh1DKwBU9DggcEHoRUmia3p3iPR4NW0m4+0WM+7y5djJu2sVPDAEcgjkUA
aFFeZ+PPitpmmfDxdY0DUo2vNSR10t3tpCHKSKkrYZQAVBJG7AJA4YcHqLDx94X1Lw1eeIrX
VozpNm5Se5eN4wrAKcYZQSfmXAAOSQBk8UAdJRXN+GvH3hfxfcT2+hatHdTwIHkjMbxttJxk
B1BIzgEjOMjPUV0lABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHBaV/x+65/2FJv/AGWtOszSv+P7XP8A
sKTf+y1p1tHY4anxMK4r/mt//ct/+3NdrXL694Htdd1xNY/tfWNPu0tha7tPuRDlAxbBO0nq
fXHAoYotdSfx5dwWXgLXZbh9iNZSxA4J+Z1KKOPVmA/GuXNpPp/iX4XWV0nl3FvZXMUqZB2s
tqgIyODyO1bWn/DzTrTWLXU73U9Y1ie0ybZdUuvOSFjj51GB83A/Q9QCNu+0G11DXtJ1iWSZ
bjTPO8lUICN5ihW3DGTwOMEfjRYpNLQ4DXEbwVaeJNIllddA1bT7mXTmkAWO2uSrlrZcDgMD
uUHaOMAEkk69vPo9x4H8JeH9ctJpbTWLK3hD52RK6Ro6q7hgQzEfKBySCK6jxB4f07xPo8um
anD5kD8qw4eNuzqezDP8wcgkVBceE9HvfDNr4fv7b7ZYW0cccYlbD/IAFbcuCGwOSMdSOhxR
YOZNanNv8O9T0u0iPhvxlrcFzbrthivpxPb7QpATZtAA6c4OMcDOMdD4L1+XxR4R0/WJ4Ehm
uFYOiEldyuyEjPQErnHOM4yetYI+FWnNaxWVz4g8SXWnpsBspr/MLKpBCFQo+XgdMY7YrR1H
x94Q8M3raNd6glnNaqifZ0tZCsa7QVA2qRjaRwOlLYH72i1OrrhrvRtC8da3dXIk1XS9a0ec
2bTwT+ROEwxBAyf3bh2IbALAHtUn/C2/A/8A0G//ACUn/wDiKu694C0fXdUTVd95p+qpgfbt
Pn8mUgKVwTgjocZxnAAzjinuJJx30MGaLXfAWt6SRrtzrOi6nqCWTW+otvnheQAB1lxyAVY4
4GOMEncKsPhz/hIPif4x/wCJzrGm+R9i/wCQbdeT5m6H+Lg5xjj6muo0TwJp2jawdWkvdS1T
UBH5UVxqdx5zwrzkIcDGcn9cYyc6ljoNrp+vatrEUkzXGp+T5yuQUXy1KrtGMjg85J/ClYfM
lsebeEdMjs/iHPofi24vNV1ey/0rSbu9uXaJkwMmNHP3+5xuAMZxgpk9X8StNabw2us2tuku
o6HOmoW27GMIwLhicHbtBJAIJKr6YrX17wza69dadePdXlne6dI0ltc2kgV13DDKQwKlTgZB
HbHQkHYmhiuYJIJ40lhkUo8bqGVlIwQQeoI7U7dAc9Uzg1ls/GfxK0+4hCXOm6Jp63aSbMf6
RcYaMMHGSPLUOMAYYcnPFd/XPeEfBml+DLGe100zSefJ5kks+0yHAAC5VR8o5IHYsfWuhoRM
mr6HC+E73XY7nxDb+C/C9g002r3K3utahdbYhMrltjRrmRlCMAMYAZycdSa/hCCa1+EfxMt7
iK0hnivdUSSOzUrAjCBQRGDyEB4A9MVp6B8NdJ1uTVNUk1HWLT7Xf3Ed9aWV4YoLxVmcYlUD
JBVipwRwT0JJPY6L4A0LQNJ1bR7GOcaRqefNsXlLIm6MRvtb/WfMAM5Y4xxisnud0dkcP4y/
5Netv+wVpv8A6FDW58W4Ibq38H29xFHNBL4oskkjkUMrqQ4IIPBBHGKuWnwv0uDwvqPhy61f
XNR029iiiEd7eb/swjOU8nCgJg7TjBB2qCMcGxH8PLP+ztPs7zW9c1D7BqseqwzX12JZPMQY
VCxX/V9TgYOSeaQzP+Kf/Mlf9jXY/wDs9Z/hqx0u4+Pfja6uY4H1O2iszaF2+dEaACRlX/vg
FscbsZG457jX/Ddn4j/sv7ZJOn9m6hFqEPksBukjztDZByvJyBg+9YeqfDLRdV1vU9aa61K1
1S+eF1vLScRS2pjQx/umC5AZSQwOQfbAwAZek2NvY/HzWBpMfl2s2iJNqSwMfL+1tN8pkA4W
Qplh0JBZv4iTJ8GZ4bX4MaPcXEscMESXLySSMFVFE8hJJPAAHOa6Twp4O0vwfZ3EVh589xdS
ma6vbt/MnuHJJy74GcZOOO5PUknDj+EnhyHVJp4ptSTTJrj7TLoa3ONPeTjloccjcqttJxwB
jaNtAHnf/Nof+f8An/rqPi39suPF/gfTrX+ypftMt5i21nLWcsgjRU8xR95vnYJ33MMda6yH
4eaLF8PD4Jd7ubSyjLveQCUEyGQNuUAZDHI4xwMg85jf4c6XeeErrw7q9/qusW88pmW51K58
6eB9oAMb4G3GCRx/EwOQSKAOP1bw74zvvFvhnW/EV34N06az1CFI7qzuLiGedC3zW4L8PuG7
C+5AwC2fYK4/w98OdL0HXDrct/qusamIvJhutWuftD26c5EZwMZ3H8yBjLZ7CgAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigDkNX0+bRtSu9UghknsbthJdJEpZ4ZAoXzAo5ZSqrkDkEZwcnCW11b3tulx
azxzwuMrJGwZT9CK7CsLUfCWm3ty93AZtPvnOXubJgjOfV1IKOf95TVqVjGdHmd0UqKry6R4
nsf9U+n6rEP7xa2lx/48rH/vgVUfV5rTjUdF1azPr9mM6/XdCXAH1xVqSMHSkuhp0VlweJdD
uZPKi1ayMveIzKrj6qTkflWmrBlDKQQeQR3pkNWFooooEFFFFABRRRQAUUVWutQsrFd13eW9
uvrNKqfzNAFmishPE+l3H/HjLNqB7fYLeS5H5xqQPxNWY/8AhIb7iz0E26npLqNwsQ+oVN7f
gQtLmRapyeyL1UZL8z3h07TUF3f8bkB+SAH+KVv4R7dT2Bq7D4Rurv5ta1iWVD1trFTbxH2L
ZMh/BgD6V0Vjp9nplqtrY2sNtAvSOJAoz3PHf3qXPsaxofzEGiaUmi6TDYpIZSpZ5JWGDJI7
F3bHbLMxx2zWhRRWZ0hRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQBBdWVrfReVd20NxH/AHZYw4/I1jSeBvCzsWXQrKBiclraPyST65TH+celdBRQBzR8
CaKP9U+qQn/pnqtzj/vkyEfpUZ8ERg/ute1uMegnR/1ZCa6mindi5V2OVPgpx/q/E+uIfXNu
36NCRR/whc5+94s1xh3Gy0GfxEANdVRRdi5I9jlv+EJ/6mPW/wDv5D/8apw8Daef9fqGszfX
UZY//RZWunoouw5Y9jnF8B+HP+WllLcf9fN3NNn673OavWXhjQNObfZaJpts/wDeitUU/mBm
tWikVYKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD//Z
--------------070600040704010704070103--



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 j73FT9eZ057555; Wed, 3 Aug 2005 08:29:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73FT9vi057554; Wed, 3 Aug 2005 08:29:09 -0700 (PDT)
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 j73FT82q057532 for <[e-mail]>; Wed, 3 Aug 2005 08:29:09 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.29.174] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j73FT1Dd026169; Wed, 3 Aug 2005 11:29:02 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p06230913bf16922c7f9f@[86.255.29.174]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 3 Aug 2005 11:28:54 -0400
To: "Kurt D. Zeilenga" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: srv based names
Cc: Russ Housley <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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:24 PM +0200 8/3/05, Kurt D. Zeilenga wrote:
>Another problem with using the DNS name of a SRV RR as a
>service identifier is that they are totally alien to the
>user community.

To the extent that a user (vs. an app developer) has to deal with the 
string, I agree that URIs are much less alien, but I don't think that 
we're discussing examples where a user will be dealing with these 
values.

>URIs are not alien.  In fact, its a URI which the user
>actually sees on a side of the bus and enters into their
>user agent

"side of the bus?" A user enters a URI for web-based accesses, but 
not for all applications. Stefan's major motivation, as he noted 
later, is Kerberos, and I would not expect to see a URI used there.

>What do you want your users' certificate view to see when
>manually checking the validity of a certificate (in clients
>which don't understand the necessary alternative subject name)?

I don't think anyone is suggesting that a user will view a cert to 
perform the check. It should be automated, performed by software.  So 
the last argument above is not relevant.



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 j73FPEmd057256; Wed, 3 Aug 2005 08:25:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73FPElw057255; Wed, 3 Aug 2005 08:25:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx2.trusecure.com (mx2.trusecure.com [208.251.192.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73FPEb2057245 for <[e-mail]>; Wed, 3 Aug 2005 08:25:14 -0700 (PDT) (envelope-from [e-mail])
Received: from VAMAIL01.corp.trusecure.net (vamail01.corp.cybertrust.net [172.19.1.52]) by mx2.trusecure.com (Postfix) with ESMTP id 4957FC91FD for <[e-mail]>; Wed,  3 Aug 2005 11:25:08 -0400 (EDT)
Received: from HRN-MSC-EXCH-01.mscore.trusecure.net (hrn-msc-exch-01.corp.cybertrust.net [172.19.1.49]) by VAMAIL01.corp.trusecure.net (8.12.10/maybe_its_not_even_really_Sendmail....) with ESMTP id j73FP7JK025422 for <[e-mail]>; Wed, 3 Aug 2005 11:25:08 -0400 (EDT)
Received: from usvastrcybexch1.ms.cybertrust.net ([172.18.1.10]) by HRN-MSC-EXCH-01.mscore.trusecure.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 11:25:07 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: AW: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 11:25:06 -0400
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0020_01C5981E.001E8C50"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: AW: Qualified Certificate Requests - RFC
thread-index: AcWYPhActVf6NAlcQgO7k6t1BatlowAAHdCA
From: "Schwebler, Hans-Peter" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2005 15:25:07.0870 (UTC) FILETIME=[87CDCBE0:01C5983F]
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_0020_01C5981E.001E8C50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Phillip,

Nothing is wrong with this concept but it's not new.  You need to pay
attention to the different keys, though.  If you want to be able to
determine that the certificate request was signed by a specific smart =
card,
then the number of manufacturer keys is huge. =20

The concept, as far as I am aware of, was developed by TC TrustCenter =
(they
are an accredited CA in Germany).  The concept was implemented with one =
of
the major HSM vendors.  I don't know which one but it might be Eracom.

Best regards,
Hans-Peter

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Philipp G=FChring
Sent: Wednesday, August 03, 2005 10:58 AM
To: [e-mail]
Subject: Re: AW: Qualified Certificate Requests - RFC


Hello,

> how do you imagine a "qualified CSR"? The problem is, that a CA must =
get a
> prove that the CSR is generated by a smartcard or an HSM and not by a
peace
> of fake software.
> Until now, IMHO, there's no feasible concept to prove that.

My concept is the following:

First the SmartCard vendor generates a public/private keypair, the =
so-called

vendorkey.

When the SmardCard (or HSM) is manufactured (or initialized), the =
private=20
vendorkey is burnt into the SmartCard.
The SmartCard has to enforce two things:
  The private vendor key can=B4t leave the SmartCard
  The private vendor key can only be used to sign public keys, for which =
the

corresponding private key=B4s were generated in the SmartCard, and are =
also=20
securely stored in it.

The SmartCard (and it=B4s vendor) has to be audited (by a third party =
auditor,

or by the CA).
When the audit succeeds, the CA approves the public vendorkey for =
qualified=20
certificates.

Now the user buys the SmartCard.

Then the user let=B4s the SmartCard generate a User-Keypair.
The SmartCard signs the user=B4s public-key with the vendor=B4s secret =
key.
The software requests both the user-public key and the signature of the
users
=B4s public key from the Smartcard.
The software generates a certificate request for the User-Keypair, and=20
includes the signature as a extension (or attribute) in the request.

The certificate request is sent to the CA in the normal way.

The CA detects the qualification signature, verifies it against the =
public
key=20
of the vendor, and if everyhting matches, the CA can issue a qualified=20
signature.

Anything wrong in that method?

Regards,
Philipp G=FChring



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUajCCAykw
ggKSoAMCAQICDmFBAQAAAoR0bpoG36C2MA0GCSqGSIb3DQEBBAUAMIGcMQswCQYDVQQGEwJERTEQ
MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEaMBgGA1UEChMRVEMgVHJ1c3RDZW50
ZXIgQUcxIjAgBgNVBAsTGVByZS1Qcm9kdWN0aW9uIENsYXNzIDIgQ0ExKTAnBgkqhkiG9w0BCQEW
GmNlcnRpZmljYXRlQHRydXN0Y2VudGVyLmRlMB4XDTAzMDYyMDEwMDAwM1oXDTExMDEwMTExNTk1
OVowgZwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMRow
GAYDVQQKExFUQyBUcnVzdENlbnRlciBBRzEiMCAGA1UECxMZUHJlLVByb2R1Y3Rpb24gQ2xhc3Mg
MiBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAOXTk5aKFE1wX0mBHUH1qVB8GrCFytfG/267zOm3use0vfwnUw0a
4V8Ps+Bl1OsL7kWNgwIj6iqVTd8rra0EV2OM9fRQ6Ml81YDAXyqlPxozdtwVbhV1osGe0dFDycCU
q6UU9N8ODRANR9GlYH/tf+ER0zGwe3FvYpPLrQKWKmhNAgMBAAGjbDBqMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgGGMDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vZGVtby50cnVzdGNlbnRl
ci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQQFAAOBgQCQuTXY
ExxiA6XFO8WaJW+z5p1Zz0JSO1/Ka4kAyxpkhThCZjD4OITxq1nyP9MtPQiGiuuzQl8MOz4ldcNO
Q0uAdYC/Jb4vVJeJF3AsLDYh56BAnclPn4w7X9EWPUca3Z7j6O2P8wruZ6HSckdGVg6T6Rcj0Guk
zeGnk63PS6m/szCCA/0wggLloAMCAQICDllqAQAAHcvlM+F2ReFUMA0GCSqGSIb3DQEBBQUAMIGI
MQswCQYDVQQGEwJERTEaMBgGA1UEChMRVEMgVHJ1c3RDZW50ZXIgQUcxJTAjBgNVBAsTHFByZS1Q
cm9kdWN0aW9uIENsYXNzIDIgTDEgQ0ExNjA0BgNVBAMTLVRDIFRydXN0Q2VudGVyIFByZS1Qcm9k
dWN0aW9uIENsYXNzIDIgTDEgQ0EgSTAeFw0wNDAzMTUxODI5MTNaFw0xMjAzMTMxODI5MTNaMIGI
MQswCQYDVQQGEwJERTEaMBgGA1UEChMRVEMgVHJ1c3RDZW50ZXIgQUcxJTAjBgNVBAsTHFByZS1Q
cm9kdWN0aW9uIENsYXNzIDIgTDIgQ0ExNjA0BgNVBAMTLVRDIFRydXN0Q2VudGVyIFByZS1Qcm9k
dWN0aW9uIENsYXNzIDIgTDIgQ0EgSTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBv
ExYFilWvoaQaUdbBek5iRHcUs5+3sAx5hIInREIzfDaVp7Y0ZT34sTqiAIKgAEgoo5ufpLSsRWva
7RIwRr8Mho8s7F0aGlu/3+6bBJhoCMGxnBfGkjQcqdinzClkNMAPPkD77nSKruVr8JDgsrvNZSbM
3R0UW9bwfduLUdvQWHF2ILIyzi5zULr2HeOEyCe85yhyq7r0rqKmFcqjaSzEyhY21mTHT2VOx9mP
RJVDUPvi7LE67QAcZvBnqpZ37hbGqXtoEEK0SvfI5aHvinwFoRgtwis9YIlmcZVThcMjESdEzhxM
pEK9o5giCMVbZcTqe1zFZrkLlXUrhoQ6Ct8CAwEAAaNjMGEwHwYDVR0jBBgwFoAUb8CPfpvTjKPQ
UpHZ270i7x9rbTgwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFKP9
0vpHY5H/bDQeBMcgdsuao73/MA0GCSqGSIb3DQEBBQUAA4IBAQBUt/2hr0zppKL48lVM1Lzwuiju
rlMpe3RKpWdP7aUt5jOpdlHtzwjqBkMekgsSh3DslMpNeeTJNXmjwLKzFb8MMJo+9ZhPpzzjf3PK
A4uDaYEZOoR3vTMnedW66Io4fCpkdS4s8lgzEPZmkVUGgvGyyfD3akf121w9Kw3rd9nXV24k8pOe
N71NbQRMrkT8SewcRDlYoFm37oOGvDdYvm/UBj/VwWwg1DdIKnqlwBPKDMXxsMpoAnJi0MOwxVjU
fyxoKxQkrTxFo4ltwUAphB2htgtpbnBafOUx1J3cxV5Z5a6o+JA5LiL77N3DWQIclBw/NjzUx5ML
+YYZFNUh07nCMIIEJzCCA5CgAwIBAgIOGOMBAAACR6U+XAIUhp8wDQYJKoZIhvcNAQEFBQAwgZwx
CzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMRowGAYDVQQK
ExFUQyBUcnVzdENlbnRlciBBRzEiMCAGA1UECxMZUHJlLVByb2R1Y3Rpb24gQ2xhc3MgMiBDQTEp
MCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDQwMzE1MTgwOTEw
WhcNMTUwMzEzMTgwOTEwWjCBiDELMAkGA1UEBhMCREUxGjAYBgNVBAoTEVRDIFRydXN0Q2VudGVy
IEFHMSUwIwYDVQQLExxQcmUtUHJvZHVjdGlvbiBDbGFzcyAyIEwxIENBMTYwNAYDVQQDEy1UQyBU
cnVzdENlbnRlciBQcmUtUHJvZHVjdGlvbiBDbGFzcyAyIEwxIENBIEkwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCbQBknlk25kpMqz1kUazTXlGzMobket7/UpxPuAYfnD9MlgVPdM10l
NHpeX03HXFK4ksdsgJ/34mDTEqPIXBURHpCcLCoS87jM5MhypXPk5e1mNsXkyXHoRhr1XSrOQ8cs
8DRy3BbY+Q5+8fD4A5Rr1e/z60CdhxQOhjIMcsD7jIXu9U+LieEpHGXFLnb9jyqQSKCgTwRusyUq
RLgjUUQmsSjPMvNJ8vomW7iquT/YW3nXLVXRgxX/14wjOfG/vPFQSts0j0sYf+TY4UoFwMRDM91H
aFtMa0DBCkTHkif8pvtzguiGrJbrojRu17k2EiGsMigniZD4CFo44jHV2kxRAgMBAAGjgfkwgfYw
ZwYIKwYBBQUHAQEEWzBZMFcGCCsGAQUFBzAChktodHRwOi8vd3d3LnBwLnRydXN0Y2VudGVyLmRl
L3BwL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjY2xhc3MyLTIwMTFfdGVzdC5jcnQwDwYDVR0TAQH/
BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFG/Aj36b04yj0FKR2du9Iu8fa204MEsG
A1UdHwREMEIwQKA+oDyGOmh0dHA6Ly93d3cucHAudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjY2xh
c3MyLTIwMTFfdGVzdC5jcmwwDQYJKoZIhvcNAQEFBQADgYEAZIdrVT6ncymS4lJu46cBlnIxc0JV
XcO3qbhxgT05oKmfqA75MAG3H6ofLpO3vTotGyP162M2U23ELoKUba2gc0oU6KZtJgifhVfJv+C7
pmNrIPysyV3eolXO/aTVd/Fdh4wUBfStTyJnGQfU0nh2lfUm/5MSXQDXmL/6aVYFguwwggSEMIID
bKADAgECAg5GpQEBAB3EIAHPaYxsVzANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMCREUxGjAY
BgNVBAoTEVRDIFRydXN0Q2VudGVyIEFHMSUwIwYDVQQLExxQcmUtUHJvZHVjdGlvbiBDbGFzcyAy
IEwyIENBMTYwNAYDVQQDEy1UQyBUcnVzdENlbnRlciBQcmUtUHJvZHVjdGlvbiBDbGFzcyAyIEwy
IENBIEkwHhcNMDUwNzI2MTcxNDIwWhcNMDgwNzI2MTcxNDIwWjCBmTETMBEGCgmSJomT8ixkARkW
A2NvbTEbMBkGCgmSJomT8ixkARkWC2JpZ2J1c2luZXNzMRgwFgYDVQQKEw9Db21wYW55IE9uZSBJ
TkMxDTALBgNVBAsTBEVNRUExHTAbBgNVBAUTFEhhbnMtUGV0ZXIgU2Nod2VibGVyMR0wGwYDVQQD
ExRIYW5zLVBldGVyIFNjaHdlYmxlcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtFZLuqn6
ZU/WyvnkJ+2aqfHbBk9a0IMW05O42CnIIpCJv0IIr881hoz6tFAAASssjYsDHwkSRPk/aKPBeEb+
5IHVro8Ljd8p2gvn8vpFdZ6LPhixHPaT54s9NabSvhYej14vVrdQn/m15h8eTFUm31LmMz4+QuLu
WOWqIJFXdscCAwEAAaOCAVswggFXMGYGCCsGAQUFBwEBBFowWDBWBggrBgEFBQcwAoZKaHR0cDov
L3d3dy5wcC50cnVzdGNlbnRlci5kZS9wcC9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFzczJf
TDJfQ0FfSS5jcnQwHwYDVR0jBBgwFoAUo/3S+kdjkf9sNB4ExyB2y5qjvf8wDAYDVR0TAQH/BAIw
ADAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0OBBYEFP5sYhtDspFxd3rchWMPkF9Bbo0kMEoGA1UdHwRD
MEEwP6A9oDuGOWh0dHA6Ly93d3cucHAudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX2NsYXNzMl9M
Ml9DQV9JLmNybDATBgNVHSUEDDAKBggrBgEFBQcDBDAuBgNVHREEJzAlgSNoYW5zLXBldGVyLnNj
aHdlYmxlckBjeWJlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAY+ghMzeJ7/hlUcAeA6tj
ITkCEo59mmkl1lz3yIxmZdBrv1XbKCDsTrMUhCu3efi94z89HdkuuubiHVTT+NGRFbVPx+/7tXSD
/ruiA1o56E/29aczEGxdKA831IRLbwE2Q50s9mzvF07ka7mNAXkiPGe2Pf4PH5ZjtOyK2Kx1nkjZ
bmeFciwtGDEMMezp22pCgBnsXBCneyRP/1Opuxp7C1yx+gAHIthpOL8qxR6fUAk31u/MKrygGSDH
zEl7RWg63SYCoTH68yYPOfYaS2FVaDzFshdyCN8zNbx7CDP5me1xRfBdWjGPoNnFANDh6x9KbN+9
M7XXHrGxoXfg9PLPnDCCBIUwggNtoAMCAQICDwC7jQEBAB1hm1UE97XEljANBgkqhkiG9w0BAQUF
ADCBiDELMAkGA1UEBhMCREUxGjAYBgNVBAoTEVRDIFRydXN0Q2VudGVyIEFHMSUwIwYDVQQLExxQ
cmUtUHJvZHVjdGlvbiBDbGFzcyAyIEwyIENBMTYwNAYDVQQDEy1UQyBUcnVzdENlbnRlciBQcmUt
UHJvZHVjdGlvbiBDbGFzcyAyIEwyIENBIEkwHhcNMDUwNzI2MTQ1NDQyWhcNMDgwNzI2MTQ1NDQy
WjCBmTETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC2JpZ2J1c2luZXNzMRgw
FgYDVQQKEw9Db21wYW55IE9uZSBJTkMxDTALBgNVBAsTBEVNRUExHTAbBgNVBAUTFEhhbnMtUGV0
ZXIgU2Nod2VibGVyMR0wGwYDVQQDExRIYW5zLVBldGVyIFNjaHdlYmxlcjCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAz1RJT/JPXROuKz/3cKojKvT1pCHAabqy2jSMoVY8mdEngHjLTabBBRaP
Z8OFD6N4/3HkzN7OG+yxzmU7IRDYSmSTf2dkq8OEW31AjT9KepcaIuMLo2EgUhJLOQKRXFV7RyuS
BfF/GPAMgF32RUwFdSqURTQhRgbt5tsHWPNOaOcCAwEAAaOCAVswggFXMGYGCCsGAQUFBwEBBFow
WDBWBggrBgEFBQcwAoZKaHR0cDovL3d3dy5wcC50cnVzdGNlbnRlci5kZS9wcC9jZXJ0c2Vydmlj
ZXMvY2FjZXJ0cy90Y19jbGFzczJfTDJfQ0FfSS5jcnQwHwYDVR0jBBgwFoAUo/3S+kdjkf9sNB4E
xyB2y5qjvf8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBDAwHQYDVR0OBBYEFDmp4ADQ4u+r
cbnDPOyiVFSUi9SnMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly93d3cucHAudHJ1c3RjZW50ZXIu
ZGUvY3JsL3YyL3RjX2NsYXNzMl9MMl9DQV9JLmNybDATBgNVHSUEDDAKBggrBgEFBQcDBDAuBgNV
HREEJzAlgSNoYW5zLXBldGVyLnNjaHdlYmxlckBjeWJlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUF
AAOCAQEAZSrlXjlGb6OWGn5R7CSUX4OHljv6tTHLeSiPokgpirXv/Q1scQ99I8EdHta4bzT46e4r
ObbQOqEI/fwtd648MrIkOuEKiQSAA4DfEBUNEexd8XhpKjQn4JzuwoBKCZmxElnGO7KbLUEazCgH
eQM/WOwyWbJTDi60pjLhESsCd2WaHY0Qmlww24O1fSX5mzI87hr4vtrvMDSNxTnqTItTu2ooh5ZI
kByCkwkgUB0nKTwu9x+CUZz98DhTfcRp+24LCPzMf2rZhoS0ulvTCxeT5g7LfkZyJydYPbyDN9Gg
ppeXzexqZXSzT7PGshk4+DDkZoP5MATrOrg7/rAvcXHW3jGCA24wggNqAgEBMIGbMIGIMQswCQYD
VQQGEwJERTEaMBgGA1UEChMRVEMgVHJ1c3RDZW50ZXIgQUcxJTAjBgNVBAsTHFByZS1Qcm9kdWN0
aW9uIENsYXNzIDIgTDIgQ0ExNjA0BgNVBAMTLVRDIFRydXN0Q2VudGVyIFByZS1Qcm9kdWN0aW9u
IENsYXNzIDIgTDIgQ0EgSQIORqUBAQAdxCABz2mMbFcwCQYFKw4DAhoFAKCCAigwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwODAzMTUyNTA2WjAjBgkqhkiG9w0B
CQQxFgQU1qoA765EUWZdCVPxfP6Xl9JQ9swwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF
Kw4DAhowCgYIKoZIhvcNAgUwga0GCSsGAQQBgjcQBDGBnzCBnDCBiDELMAkGA1UEBhMCREUxGjAY
BgNVBAoTEVRDIFRydXN0Q2VudGVyIEFHMSUwIwYDVQQLExxQcmUtUHJvZHVjdGlvbiBDbGFzcyAy
IEwyIENBMTYwNAYDVQQDEy1UQyBUcnVzdENlbnRlciBQcmUtUHJvZHVjdGlvbiBDbGFzcyAyIEwy
IENBIEkCDwC7jQEBAB1hm1UE97XEljCBrwYLKoZIhvcNAQkQAgsxgZ+ggZwwgYgxCzAJBgNVBAYT
AkRFMRowGAYDVQQKExFUQyBUcnVzdENlbnRlciBBRzElMCMGA1UECxMcUHJlLVByb2R1Y3Rpb24g
Q2xhc3MgMiBMMiBDQTE2MDQGA1UEAxMtVEMgVHJ1c3RDZW50ZXIgUHJlLVByb2R1Y3Rpb24gQ2xh
c3MgMiBMMiBDQSBJAg8Au40BAQAdYZtVBPe1xJYwDQYJKoZIhvcNAQEBBQAEgYBbOiqjG118QCW/
dVknXhSywX0kE3njb33sClSKwD8GMxIjF/Fid3Ii/0boIRK87zxaQUsV0wZ5kAH3U6tL5bhLhVfb
HPwotXzuU3dfRgwm4LwEoEaFTzvyOpt8i/7ClN5bfQc6Rjn/J7mydeHGw/H0jp9658bRKynJEklo
RXg1HAAAAAAAAA==

------=_NextPart_000_0020_01C5981E.001E8C50--



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 j73FNUrr057117; Wed, 3 Aug 2005 08:23:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73FNUAD057116; Wed, 3 Aug 2005 08:23:30 -0700 (PDT)
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 j73FNTm3057102 for <[e-mail]>; Wed, 3 Aug 2005 08:23:29 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.29.174] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j73FNLDf025826 for <[e-mail]>; Wed, 3 Aug 2005 11:23:23 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p06230912bf1691ad619d@[86.255.29.174]>
Date: Wed, 3 Aug 2005 11:23:16 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: whoops
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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>

A couple of folks have pointed out an obvious error in the minutes, 
i.e., I swapped the subjects of Denis's presentations.

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 j73EwKaE054509; Wed, 3 Aug 2005 07:58:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73EwK19054508; Wed, 3 Aug 2005 07:58:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73EwJ2t054501 for <[e-mail]>; Wed, 3 Aug 2005 07:58:19 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.87  (authenticated user [e-mail]) by mx2.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 33-md50000000533.tmp for <[e-mail]>; Wed, 03 Aug 2005 16:58:17 +0200
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: [e-mail]
Subject: Re: AW: Qualified Certificate Requests - RFC
User-Agent: KMail/1.8
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
Date: Wed, 3 Aug 2005 16:58:27 +0200
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <[e-mail]>
X-Spam-Processed: mx2.go-now.at, Wed, 03 Aug 2005 16:58:17 +0200 (not processed: message from valid local sender)
X-Lookup-Warning: HELO/EHLO lookup on 192.168.0.87 does not match 80.120.131.105
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73EwJ2t054503
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,

> how do you imagine a "qualified CSR"? The problem is, that a CA must get a
> prove that the CSR is generated by a smartcard or an HSM and not by a peace
> of fake software.
> Until now, IMHO, there's no feasible concept to prove that.

My concept is the following:

First the SmartCard vendor generates a public/private keypair, the so-called 
vendorkey.

When the SmardCard (or HSM) is manufactured (or initialized), the private 
vendorkey is burnt into the SmartCard.
The SmartCard has to enforce two things:
  The private vendor key can´t leave the SmartCard
  The private vendor key can only be used to sign public keys, for which the 
corresponding private key´s were generated in the SmartCard, and are also 
securely stored in it.

The SmartCard (and it´s vendor) has to be audited (by a third party auditor, 
or by the CA).
When the audit succeeds, the CA approves the public vendorkey for qualified 
certificates.

Now the user buys the SmartCard.

Then the user let´s the SmartCard generate a User-Keypair.
The SmartCard signs the user´s public-key with the vendor´s secret key.
The software requests both the user-public key and the signature of the users
´s public key from the Smartcard.
The software generates a certificate request for the User-Keypair, and 
includes the signature as a extension (or attribute) in the request.

The certificate request is sent to the CA in the normal way.

The CA detects the qualification signature, verifies it against the public key 
of the vendor, and if everyhting matches, the CA can issue a qualified 
signature.

Anything wrong in that method?

Regards,
Philipp Gühring




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 j73EOWLL051610; Wed, 3 Aug 2005 07:24:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73EOWvX051609; Wed, 3 Aug 2005 07:24:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73EOW9R051601 for <[e-mail]>; Wed, 3 Aug 2005 07:24:32 -0700 (PDT) (envelope-from [e-mail])
Received: from gyspy.OpenLDAP.org (wep-14-123.ietf63.ietf.org [86.255.14.123]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j73EOTH9069672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2005 14:24:31 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 03 Aug 2005 16:24:28 +0200
To: Russ Housley <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: srv based names
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
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>

Another problem with using the DNS name of a SRV RR as a
service identifier is that they are totally alien to the
user community.

URIs are not alien.  In fact, its a URI which the user
actually sees on a side of the bus and enters into their
user agent

What do you want your users' certificate view to see when
manually checking the validity of a certificate (in clients
which don't understand the necessary alternative subject
name)? 

Kurt

At 02:49 PM 8/3/2005, Russ Housley wrote:

>Thanks for following up; however, I do not think that Kurt's observation matters in many important contexts.  Stefan made a mistake by using a collection of LDAP servers as an example in his slides.  There are other services that do not have URLs.  As the discussion in the meeting showed, there are services for which we do not have URIs.  Kerberos KDC is one important example.  KRB-WG is specifying the use of certificates in their PK-INIT document, and the Kerberos KDC will be the subject of the certificate.
>
>Russ
>
>At 04:51 AM 8/3/2005, Love Hörnquist Åstrand wrote:
>>I talked to Kurt Zeilenga after the meeting, and then understood what he
>>was talking about. The uniformResourceIdentifier part of GeneralName (and
>>this SubjectAltName) can be used instead of srv based names to limit what
>>service the certificate is allowed to serve.
>>
>>Love



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 j73EI5qZ051063; Wed, 3 Aug 2005 07:18:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73EI5Is051062; Wed, 3 Aug 2005 07:18:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73EI529051054 for <[e-mail]>; Wed, 3 Aug 2005 07:18:05 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j73EI2FJ001135 for <[e-mail]>; Wed, 3 Aug 2005 10:18:04 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Wed, 3 Aug 2005 10:17:57 -0400
Message-ID: <001801c59836$28f24870$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
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>

Tom Gindin,

You seem to be arguing for matching CRL certification path with that of the
certificate.

If so, you will not get an argument from me.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Tuesday, August 02, 2005 11:17 PM
To: Manger, James H; [e-mail]
Cc: pkix
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs



        James, Santosh:

        You certainly can construct unambiguous names for CA's, and I 
think that Denis already knows that (Permanent Identifier is certainly a 
way of constructing unambiguous names, for example).  The difficulty we 
have is when one issuer issues a certificate to an organizational CA with 
a subject name which is convenient and in common use for its organization, 
but ambiguous, and then a different issuer issues a certificate to an 
organizational CA with the same subject name which is also in common use 
for its organization.  This case is most common when both organizations 
use an acronym.  I do not see why the issuers of the two organizational CA 
certificates should be assumed to originate at different trust anchors, 
although they will be different issuers.  In fact, I don't understand why 
organizational name collisions are thought to be much rarer with a "common 
trust anchor" than with "different trust anchors" if the actual issuers of 
the colliding certificates are both public CA's.
        Such collisions will have negative effects in other parts of the 
global PKI, of course.  However, unless we are prepared to issue guidance 
to deprecate the assignment of DN's for organizations with geographical 
scopes wider than the one for which they are registered and guaranteed to 
be unique (and many existing CA certificates have such DN's), I don't see 
how we can be certain or nearly certain that such collisions won't occur. 
A typical example of what I mean by an organization having a DN with a 
geographical scope wider than the one for which it's registered is a 
corporation registered in a single American state and operating in several 
states while having a DN without the stateOrProvinceName attribute.

                Tom Gindin






"Manger, James H" <[e-mail]>
Sent by: [e-mail]
08/01/2005 11:05 PM
 
        To:     "pkix" <[e-mail]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
delegated CRLs


[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
trust anchors environment of the relying parties to know if the CRL issuer 
DN will be unambiguous.]
You can construct unambiguous DNs regardless of trust anchors.  For 
instance, including DC components can make a DN as unambiguous as a DNS 
name.  As another example, the following DN
  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
is unambiguous as it lists a registered business name, its Australian 
Business Number (ABN) and the jurisdiction where those are unambiguous 
(Australia).  It is inconceivable that any CA could issue such a DN to 
another entity in good faith.
The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
issuing CA, but would be ambiguous in a wider context so it should not be 
used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
instance.




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 j73EHsc3051043; Wed, 3 Aug 2005 07:17:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73EHs9m051042; Wed, 3 Aug 2005 07:17:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73EHsHe051035 for <[e-mail]>; Wed, 3 Aug 2005 07:17:54 -0700 (PDT) (envelope-from [e-mail])
Received: from gyspy.OpenLDAP.org (wep-14-123.ietf63.ietf.org [86.255.14.123]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j73EHp41069032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2005 14:17:53 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 03 Aug 2005 16:17:49 +0200
To: Russ Housley <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: srv based names
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
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>

At 02:49 PM 8/3/2005, Russ Housley wrote:

>Thanks for following up; however, I do not think that Kurt's observation matters in many important contexts.  Stefan made a mistake by using a collection of LDAP servers as an example in his slides. 

I don't view it as a mistake as most protocols which use SRV RRs
use them similar to how LDAP does.  I would have said the same
thing if he had used http, smtp, imap, etc..

>There are other services that do not have URLs.  As the discussion in the meeting showed, there are services for which we do not have URIs.  Kerberos KDC is one important example.  KRB-WG is specifying the use of certificates in their PK-INIT document, and the Kerberos KDC will be the subject of the certificate.

So create more URI schemes.   Names of SRV RRs are not, IMO,
good service identifiers.  URIs, in particular, URLs, are.

I note that there are also services which don't have SRV support,
one could take the argument that since some services don't have
URIs and some services don't have SRV RRs specifications, we
should introduce yet another service identifier form for use
as alternative subject names in certificates.

We only need one general way of specify Internet services
as alternative subject names.  I think URLs is the best
general service identifier form available, certainly far
more general than the DNS name of an SRV RR.

Kurt


>Russ
>
>At 04:51 AM 8/3/2005, Love Hörnquist Åstrand wrote:
>>I talked to Kurt Zeilenga after the meeting, and then understood what he
>>was talking about. The uniformResourceIdentifier part of GeneralName (and
>>this SubjectAltName) can be used instead of srv based names to limit what
>>service the certificate is allowed to serve.
>>
>>Love



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 j73E1SY5048941; Wed, 3 Aug 2005 07:01:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73E1Rj8048940; Wed, 3 Aug 2005 07:01:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mizar.origin-it.net (mail.de.atosorigin.com [194.8.96.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73E1QOx048891 for <[e-mail]>; Wed, 3 Aug 2005 07:01:26 -0700 (PDT) (envelope-from [e-mail])
Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68]) by mizar.origin-it.net (8.13.3/8.13.3/hmo30jul04) with ESMTP id j73E1ECE044780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2005 16:01:15 +0200 (CEST) (envelope-from [e-mail])
Received: from ascalon.mpn.de.int.atosorigin.com (ascalon.mpn.de.int.atosorigin.com [161.90.190.36]) by matar.hbg.de.int.atosorigin.com (8.13.3/8.13.3/hmo30jul04) with ESMTP id j73E1E00022710; Wed, 3 Aug 2005 16:01:14 +0200 (CEST) (envelope-from [e-mail])
Received: by ascalon.mpn.de.int.atosorigin.com with Internet Mail Service (5.5.2653.19) id <QFQNRMY2>; Wed, 3 Aug 2005 16:01:32 +0200
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: AW: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 16:01:32 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 j73E1ROx048932
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>

Philipp,

how do you imagine a "qualified CSR"? The problem is, that a CA must get a
prove that the CSR is generated by a smartcard or an HSM and not by a peace
of fake software.
Until now, IMHO, there's no feasible concept to prove that.

Best Regards

Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: [e-mail]
> [mailto:[e-mail]]Im Auftrag von Anders Rundgren
> Gesendet: Mittwoch, 3. August 2005 15:11
> An: [e-mail]; [e-mail]; [e-mail]
> Betreff: Re: Qualified Certificate Requests - RFC
> 
> 
> 
> Hi Philipp,
> 
> <snip>
> >For the Browser vendors it will be a short amount 
> of additional 
> >code, that I will try to offer them as easy to apply 
> patches for their code.
> <snip>
> 
> You mean that MSFT would dump their 
> proprietary Xenroll scheme? That is a hard sell.
> 
> Although I don't see 
> much vendor interest in this area at all[1], I believe that an XML-
> based "certgen" browser object triggered by a specific 
> MIME-type would 
> be considerably better than improving an outdated ASN.1 based 
> pkcs #10 
> scheme driven by arbitrary amounts of Javascript and ActiveX code. 
> 
> regards
> Anders Rundgren
> 
> 1]  In spite of the fact that web-browser-
> based on-line signatures are MUCH more used (and useful) than 
> signed e-
> mail, no browser vendor or standardization organization have to date 
> publicly not even mentioned the possibility of a standard.  There are 
> virtually HUNDREDS of proprietary signature schemes in use, including 
> the Austrian bürgerkarte scheme:  http://www.buergerkarte.at
> 
> 
> 



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 j73DcRYU039341; Wed, 3 Aug 2005 06:38:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73DcRVf039340; Wed, 3 Aug 2005 06:38:27 -0700 (PDT)
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 j73DcQVn039294 for <[e-mail]>; Wed, 3 Aug 2005 06:38:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.29.174] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j73DcHDf019439; Wed, 3 Aug 2005 09:38:19 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p0623090ebf1678a8f0c9@[86.255.29.174]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 3 Aug 2005 09:38:07 -0400
To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?=  <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: srv based names
Cc: "pkix" <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73DcRVn039332
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:17 PM +0200 8/3/05, Love Hörnquist Åstrand wrote:
>Love Hörnquist Åstrand <[e-mail]> writes:
>
>>  I talked to Kurt Zeilenga after the meeting, and then understood what he
>>  was talking about. The uniformResourceIdentifier part of GeneralName (and
>>  this SubjectAltName) can be used instead of srv based names to limit what
>>  service the certificate is allowed to serve.
>
>to hopefully clarify,
>
>If the service we want to bind the certificate have a uri defined. Example:
>jabber:[node@]domain[/resource]. Then the step of its to bind the DNS
>SRV-rr lookup to the service is not needed. Instead the client can bind the
>thing that user entered (user@domain) to the certificate containing the uri
>for the same service.
>
>The only problem is that services need to specify uri for itself. That
>might not be obvious when the protocol using DNS SRV-rr is written to
>support certificates, for example, by using TLS.
>
>Love

The clarification is helpful, and it suggests 
that this solution works best if the application 
expresses the service name in a URI form. Many 
apps do that, but not all, as Russ noted.

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 j73DB2x8029027; Wed, 3 Aug 2005 06:11:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73DB2wA029026; Wed, 3 Aug 2005 06:11:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73DB1dW028986 for <[e-mail]>; Wed, 3 Aug 2005 06:11:02 -0700 (PDT) (envelope-from [e-mail])
Received: from pne-ps1-sn2 (81.228.8.118) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 42B813B0006A0C36; Wed, 3 Aug 2005 15:10:54 +0200
Message-ID: <291352.1123074654370.JavaMail.root@pne-ps1-sn2>
Date: Wed, 3 Aug 2005 15:10:54 +0200 (MEST)
From: Anders Rundgren <[e-mail]>
Reply-To: Anders Rundgren <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Qualified Certificate Requests - RFC
Mime-Version: 1.0
Content-Type: text/plain;charset="ISO-8859-1"
X-Mailer: CP Presentation Server
X-clientstamp: [195.153.160.113]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73DB2dW029021
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 Philipp,

<snip>
>For the Browser vendors it will be a short amount 
of additional 
>code, that I will try to offer them as easy to apply 
patches for their code.
<snip>

You mean that MSFT would dump their 
proprietary Xenroll scheme? That is a hard sell.

Although I don't see 
much vendor interest in this area at all[1], I believe that an XML-
based "certgen" browser object triggered by a specific MIME-type would 
be considerably better than improving an outdated ASN.1 based pkcs #10 
scheme driven by arbitrary amounts of Javascript and ActiveX code. 

regards
Anders Rundgren

1]  In spite of the fact that web-browser-
based on-line signatures are MUCH more used (and useful) than signed e-
mail, no browser vendor or standardization organization have to date 
publicly not even mentioned the possibility of a standard.  There are 
virtually HUNDREDS of proprietary signature schemes in use, including 
the Austrian bürgerkarte scheme:  http://www.buergerkarte.at




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 j73D6UfI027367; Wed, 3 Aug 2005 06:06:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73D6U2s027366; Wed, 3 Aug 2005 06:06:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73D6Tos027316 for <[e-mail]>; Wed, 3 Aug 2005 06:06:29 -0700 (PDT) (envelope-from [e-mail])
Received: from pne-ps1-sn2 (81.228.8.118) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 42B94E2900680893; Wed, 3 Aug 2005 15:06:21 +0200
Message-ID: <8358290.1123074381629.JavaMail.root@pne-ps1-sn2>
Date: Wed, 3 Aug 2005 15:06:21 +0200 (MEST)
From: Anders Rundgren <[e-mail]>
Reply-To: Anders Rundgren <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Qualified Certificate Requests - RFC
Mime-Version: 1.0
Content-Type: text/plain;charset="ISO-8859-1"
X-Mailer: CP Presentation Server
X-clientstamp: [195.153.160.113]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j73D6Tos027357
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>

Philipp,

<snip>
>For the Browser vendors it will be a short amount of 
additional 
>code, that I will try to offer them as easy to apply 
patches for their code.
<snip>

You mean that MSFT would dump their 
proprietary Xenroll scheme? That is a hard sell.

Although I don't see 
much vendor interest in this area at all[1], I personally feel that an 
XML-based "certgen" browser object triggered by a specific MIME-type 
would be considerably better than improving an outdated ASN.1 based 
pkcs #10 scheme driven by arbitrary amounts of Javascript and ActiveX 
code. 

Anders Rundgren

1]  In spite of the fact that web-browser-
based on-line signatures are MUCH more used than signed e-mail, no 
browser vendor or standardization organization has to date publicly not 
even mentioned the possibility of a standard.  There are virtually 
HUNDREDS of proprietary schemes in use, including the Austrian 
bürgerkarte scheme.  http://www.buergerkarte.at







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 j73Cn8F9020767; Wed, 3 Aug 2005 05:49:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73Cn8Q0020766; Wed, 3 Aug 2005 05:49:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j73Cn7q7020751 for <[e-mail]>; Wed, 3 Aug 2005 05:49:07 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 6334 invoked by uid 0); 3 Aug 2005 12:49:04 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (86.255.29.52) by woodstock.binhost.com with SMTP; 3 Aug 2005 12:49:04 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 03 Aug 2005 08:49:02 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: srv based names
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
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>

Thanks for following up; however, I do not think that Kurt's observation 
matters in many important contexts.  Stefan made a mistake by using a 
collection of LDAP servers as an example in his slides.  There are other 
services that do not have URLs.  As the discussion in the meeting showed, 
there are services for which we do not have URIs.  Kerberos KDC is one 
important example.  KRB-WG is specifying the use of certificates in their 
PK-INIT document, and the Kerberos KDC will be the subject of the certificate.

Russ

At 04:51 AM 8/3/2005, Love Hörnquist Åstrand wrote:
>I talked to Kurt Zeilenga after the meeting, and then understood what he
>was talking about. The uniformResourceIdentifier part of GeneralName (and
>this SubjectAltName) can be used instead of srv based names to limit what
>service the certificate is allowed to serve.
>
>Love



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 j73AKlFO066120; Wed, 3 Aug 2005 03:20:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73AKlVn066119; Wed, 3 Aug 2005 03:20:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nutcracker.it.su.se (open-26-190.ietf63.ietf.org [86.255.26.190]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73AKjvp066104 for <[e-mail]>; Wed, 3 Aug 2005 03:20:46 -0700 (PDT) (envelope-from [e-mail])
Received: by nutcracker.it.su.se (Postfix, from userid 913) id C2AA834C17E; Wed,  3 Aug 2005 12:17:17 +0200 (CEST)
To: "pkix" <[e-mail]>
Subject: Re: srv based names
References: <[e-mail]>
From: =?iso-8859-1?q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
Date: Wed, 03 Aug 2005 12:17:15 +0200
In-Reply-To: <[e-mail]> (Love =?iso-8859-1?q?H=F6rnquist_=C5strand's?= message of "Wed, 03 Aug 2005 10:51:54 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
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>

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


Love H=F6rnquist =C5strand <[e-mail]> writes:

> I talked to Kurt Zeilenga after the meeting, and then understood what he
> was talking about. The uniformResourceIdentifier part of GeneralName (and
> this SubjectAltName) can be used instead of srv based names to limit what
> service the certificate is allowed to serve.

to hopefully clarify,

If the service we want to bind the certificate have a uri defined. Example:
jabber:[node@]domain[/resource]. Then the step of its to bind the DNS
SRV-rr lookup to the service is not needed. Instead the client can bind the
thing that user entered (user@domain) to the certificate containing the uri
for the same service.

The only problem is that services need to specify uri for itself. That
might not be obvious when the protocol using DNS SRV-rr is written to
support certificates, for example, by using TLS.

Love


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (NetBSD)

iQEVAwUAQvCZrdo1gLFKFEjAAQKj1Qf8DktC6iqSzm2wNuf8rwbL+msUjVVydFyX
ZMjZAbiJjSG6x+X1fxcIh4fl/J9Gsl2eeoNkVCT9hCp0UtU9xZ728ec7JHJnwZ0I
URaYREvvI1hfULbSS8FDR5YRf/PUcXdFhfXLZo4ZMCWzU8NevhTPU6K4/iNT9EtM
zTnAO4MMSAV08/N4xL3y+lngxWhbeAlUvegq0jDgRtRXJAMAoPDdaulRngbBr9u5
u7okBAZJcWUqAlNNE/5+cDGkCmo8PbWuuCHV9s419wuCDoEp35/e5O/LNhtr3qBB
LYAOBjH4xXX/JIJL1tsCJIkFt81qYZOTUq0Ip5G86PdGFG+r5dFRww==
=Y79I
-----END PGP SIGNATURE-----
--=-=-=--



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 j73A7nuI061219; Wed, 3 Aug 2005 03:07:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73A7nNk061218; Wed, 3 Aug 2005 03:07:49 -0700 (PDT)
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 j73A7mrD061178 for <[e-mail]>; Wed, 3 Aug 2005 03:07:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [86.255.29.174] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j73A7gDd012605 for <[e-mail]>; Wed, 3 Aug 2005 06:07:42 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p0623090abf164794eeb1@[86.255.29.174]>
Date: Wed, 3 Aug 2005 06:07:36 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft minutes for comment
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
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>

PKIX WG Meeting 8/2/05

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]> & Tim Polk <[e-mail]>

The PKIX WG met once during the 63nd IETF. A total of approximately 
53 individuals participated in the meeting.


Document status - Tim Polk (NIST)

	Two new RFCs (PK Algorithms and Permanent Identifier) have 
been issued since the last meeting. Four additional documents have 
been approved by the IESG and are in the RFC editor's queue 
(Certificate path building, warranty extension, 2510bis and 2511bis). 
Three documents are being reviewed by the ADs (AC policies, CertStire 
HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for 
SIM will be initiated after this IETF meeting. More detailed 
discussions of 3280bis and SCVP will follow. (see slides)

PKIX WG Document Presentations


SRV RR otherName - Stefan Santesson (Microsoft)
	An individual submission, now being adopted by PKIX. The 
proposal specifies a way to embed a pointer to a DNS SRV record in a 
certificate, to securely bind the DNS record to a named entity, using 
the otherName type of GeneralName to carry the specific SRV RR query 
string. Denis noted that this proposal is a somewhat odd use of the 
subject alt name, in that the string is not the name of the 
certificate subject, but the name of a service provided by this 
subject. Others objected to this specific way of binding service 
authorization info to a certificate, vs. other approaches, e.g., EKU, 
or other subject alt name forms. There was general agreement that the 
proposal needs to be carefully vetted by DNS experts. (see slides)

Simple Certificate Validation Protocol (SCVP) - Tim Polk (NIST)
	IPR issues have been resolved since the last IETF meeting, 
but the core specification has not changed significantly since the 
-18 draft. The draft meets most of the requirements specified in RFC 
3379, but return of (relayed) SCVP responses was not included. This 
will be fixed in the next draft. Also, the conformance requirements 
seem to impose undue burdens on all clients, contrary to the goal of 
supporting thin clients. Remaining open issues will be discussed on 
the list, e.g., syntax details. (see slides)

3280bis Open Issues - Denis Pinkas (Bull)
	Denis emphasizes the need for thin clients, e.g., on cell 
phones, to be supported. Denis suggested that several OPTIONAL fields 
should be omitted to facilitate thin client support. However, because 
these are optional, it appears that the document can be worded to 
ensure that they impose no burden on a client that does not wish to 
invoke them. Denis would like to see a facility to allow per-trust 
anchor validation parameters, obviously not for thin clients, since 
only a sophisticated client would be able to take advantage of this 
facility. Denis also would like to represent both the validation 
policy and validation algorithm into a single OID, although this 
seems to yield a minor space/complexity savings. It was agreed that 
the URI pointer to a policy will be deleted. Is also was agreed that 
the terms "validation policy" and "validation algorithm" need to be 
better defined in the document.

3280bis - Tim Polk (NIST)
	A new draft has been submitted with relatively minor 
enhancements. Several open issues remain to be resolved. In 
particular, questions involving name ambiguity have been raised, 
particularly as they impact CRL validation. We may deal with this 
issue by adding text in the security considerations section that 
discusses this issue. The text has been changed to clarify what 
conforming CAs MUST do in issuing a certificate, vs. what conforming 
RPs MUST do re certificate path processing. The path validation 
algorithm notes that it accepts paths that are X.509 compliant, but 
not PKIX compliant, in support of interoperability.

SCVP Open Issues - Denis Pinkas (Bull)
	Denis reviewed seven topics that he considers open issues. He 
suggests that text on TA key update should be explicitly covered 
here, not just a reference to RFC 2510. He also suggests that we 
align out text with the latest X.509 technical corrigendum, with 
respect to key usage. Denis reviewed the name ambiguity debate that 
has taken place on the list. He suggested that the private key usage 
extension not be deprecated universally, but rather be allowed in 
certain contexts, e.g., time stamp crypto modules. Denis asked for a 
simplified revocation status checking algorithm description, that 
addresses only the PKIX-mandated certificate extensions. He also 
suggests clarification of the text that says what CRLs are 
"available" in the local cache. Finally, Denis discussed several 
subtle issues associated with indirect CRLs. At the microphone a 
series of individuals responded to Denis's suggestions, most 
disagreed with one of more of his points, although there appeared to 
be agreement to soften the prohibition against private key usage.


Related Specifications & Liaison Presentations

CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf 
of ETSI TC ESI)
	This document is based on RFC 3126 and is aligned with a 
re-issue of ETSI TS 101 733. CAdES is a new name, intended to 
distinguish it from the XML-based version spec.

XKMS - Stephen Farrell (on behalf of W3C)
	This presentation noted that the XKMS specification in W3C 
was completed and multiple interoperable implementations are being 
tested. Interested PKIX members are encouraged to visit the W3C web 
site and review the spec.



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 j739mJIL053214; Wed, 3 Aug 2005 02:48:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j739mJME053213; Wed, 3 Aug 2005 02:48:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j739mIDM053199 for <[e-mail]>; Wed, 3 Aug 2005 02:48:18 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 12665 invoked from network); 3 Aug 2005 09:48:15 -0000
Received: from unknown (HELO presidente) (unknown) by unknown with SMTP; 3 Aug 2005 09:48:15 -0000
X-pair-Authenticated: 83.40.14.202
Message-ID: <11d001c59810$77e915b0$107e020a@presidente>
Reply-To: "Julian Inza" <[e-mail]>
From: "Julian Inza" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <9028463.1123056668930.JavaMail.root@pne-ps1-sn2>
Subject: Re: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 11:48:11 +0200
Organization: =?iso-8859-1?Q?Direcci=F3n_Privada?=
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-Antivirus: avast! (VPS 0531-1, 02/08/2005), Outbound message
X-Antivirus-Status: Clean
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 friends,

I completly support the position of Mr. Philipp Gühring

By the way, I have been acting as special Registration Authority Support 
Expert in order to assure in the registration process of a Qualified 
Certificates Issuer CA that a specific certificate request has been 
generated inside of a secure signature creation device.So I can atest that 
this specific need exists.

This is not only the case of smartcards but also of Hardware Security 
Modules when qualified certificates are managed in behalf of a legal 
persons.

Things would be a lot easier if the request could be backed by a device 
signature.

Best regards,

_____________________________________________________
-Julián Inza (mailto:[e-mail])
-President
-Interactiva (http://www.interactiva.com.es)

This e-mail message could contain CONFIDENTIAL INFORMATION  property of 
Albalia Interactiva. If received by mistake, please ignore it, delete it and 
notify the sender. Your personal information can be added to a relationships 
file (that can include marketing information) at Albalia Interactiva where 
you can exercise your rights to access, rectify or cancel your data 
according spanish 15/1999 Organic Law (Act). You are authorised to use 
personal data of the signer of this message as long as there is a way to 
exercise the mentioned rights by the signer.
_____________________________________________________

----- Original Message ----- 
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Wednesday, August 03, 2005 10:11 AM
Subject: Re: Qualified Certificate Requests - RFC


>
> Hi,
>
> Most QCs are probably manufactured in closed processes making
> standards less applicable.
>
> For on-line generated and distributed
> certificates, practically the entire process is currently non-standard,
> beginning with browsers.   Few on-line certificate systems therefore
> use the browser stuff and have introduced their own proprietary
> methods.  These methods typically also address PIN-code policies,
> something which seems to be missing in PKCS #10.  The
> OpenMobileAlliance have created additional standards but I don't think
> these have much acceptance by browser vendors.
>
> Anders Rundgren
>
> ----
> Original Message----
> From: [e-mail]
> Date: Aug 2, 2005 10:13:55
> PM
> To: [e-mail]
> Subj: Qualified Certificate Requests - RFC
>
>
> Hello,
>
> I have been reading through the PKIX archive, and found a lot
> of interesting
> material on the topic of qualified certificates.
>
> But
> what I am completely missing is the necessary foundation of qualified
> certificate requests.
>
> Regarding the requirements for qualified
> certificates, the only obstacle I
> currently have is the problem, that
> I have to make sure, that the private key
> for the certificate is
> generated and stored securely in a SmartCard, or
> another Hardware
> Token.
>
> Since the users should be able to issue the certificates at
> home, I need a
> technical solution to make sure, that the private key
> is from within a
> SmartCard, when we receive a certificate request.
>
> Therefore I designed "Qualified Certificate Requests", which
> cryptographically
> signs the public key in the CSR with a vendor key,
> to state that it comes
> from a secure device.
>
> Now I created a software-
> based reference implementation, so that the security
> of the system can
> be evaluated, and that the Token Vendors can see how to do
> it, and can
> do interoperability testing:
>
> http://www2.futureware.
> at/svn/sourcerer/CAcert/QCSR/
>
> The following parameters are still open
> and can be changed by the vendor:
>  The crypto algorithm (we have
> chosen RSA here)
>  The encoding of the public key (we have chosen PEM
> encoding from OpenSSL)
>  The signature method (we have chosen the RSA
> signature from OpenSSL,
>     which normally gives 128 binary bytes as
> signature)
>  The encoding into the qcsr field in the CSR (I have
> chosen Hex-encoding,
>     since I didn´t found an easy way to do it
> directly binary yet)
>  The OID for the qcsr field (we have allocated a
> OID range below our range
>     for all QCSR OID´s. Feel free to contact
> me if you want an OID for your
>     parameters)
>
> If a hardware vendor
> wants to change something on the implementation, please
> provide a
> software reference-implementation, that is bit-compatible to the
> proposed hardware implementation, so that the security can be
> evaluated.
> (I guess it will be best, if it is based on our reference-
> implementation)
>
> Should qualified certificate requests be documented in
> a own RFC, or added to
> the Qualified Certificates RFC?
>
> Regards,
> Philipp Gühring
>
>
>
>
>
>
> 



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 j738tcnZ034033; Wed, 3 Aug 2005 01:55:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j738tceb034032; Wed, 3 Aug 2005 01:55:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nutcracker.it.su.se (open-26-190.ietf63.ietf.org [86.255.26.190]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j738taaS034019 for <[e-mail]>; Wed, 3 Aug 2005 01:55:37 -0700 (PDT) (envelope-from [e-mail])
Received: by nutcracker.it.su.se (Postfix, from userid 913) id 480CE34C1B9; Wed,  3 Aug 2005 10:52:04 +0200 (CEST)
To: "pkix" <[e-mail]>
Subject: srv based names
From: =?iso-8859-1?q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix)
Date: Wed, 03 Aug 2005 10:51:54 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
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 talked to Kurt Zeilenga after the meeting, and then understood what he
was talking about. The uniformResourceIdentifier part of GeneralName (and
this SubjectAltName) can be used instead of srv based names to limit what
service the certificate is allowed to serve.

Love


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (NetBSD)

iQEUAwUAQvCFtNo1gLFKFEjAAQLgXAf4sah1luKwxg9XdhwIEFYlMTjyvAODMjdL
a69MxYOpRzLVgYDfX2j84oxkilC03M8DnvVenWbXnsax82QGPOfAZQ9anzGVJNId
XArhiQYHEYVCYtDqgPEQGnaFn127kjmg9oAwyWgN3ok3HoJEllqave4OGFku20Bx
rDE8M2rSAgRCvGt3JR2oYohhUWLvn/xDkuKkVCKfSEaJ1K4lqlup5owNHkB8iarE
PyhVLZdCRxjfqwUa5/66cotuCaReAfRY7XcnzId7TSNhqwIlD2OkihsBp/rxg05+
ZebMTmp/bWS4A6fBJFsgMzDpMZTN7oUIptnxfA13/KvJ5KbOsXJa
=jh81
-----END PGP SIGNATURE-----
--=-=-=--



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 j738oZ9h032264; Wed, 3 Aug 2005 01:50:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j738oZJu032263; Wed, 3 Aug 2005 01:50:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j738oYJT032250 for <[e-mail]>; Wed, 3 Aug 2005 01:50:34 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.87  (authenticated user [e-mail]) by mx2.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 61-md50000000520.tmp for <[e-mail]>; Wed, 03 Aug 2005 10:50:29 +0200
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: [e-mail]
Subject: Re: Qualified Certificate Requests - RFC
User-Agent: KMail/1.8
References: <9028463.1123056668930.JavaMail.root@pne-ps1-sn2>
In-Reply-To: <9028463.1123056668930.JavaMail.root@pne-ps1-sn2>
MIME-Version: 1.0
Content-Disposition: inline
Date: Wed, 3 Aug 2005 10:50:36 +0200
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <[e-mail]>
X-Spam-Processed: mx2.go-now.at, Wed, 03 Aug 2005 10:50:29 +0200 (not processed: message from valid local sender)
X-Lookup-Warning: HELO/EHLO lookup on 192.168.0.87 does not match 80.120.131.105
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j738oYJT032256
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,

> Most QCs are probably manufactured in closed processes making
> standards less applicable.

Yes, and the reason for that is that there are no qualified certificate 
requests yet.
Having no QCSR´s makes it expensive for the manufacturing process, and 
impossible for QC creation at home.

If it is just an standardized, additional field in the CSR´s, then it should 
be easy to adopt for browser vendors, smartcard vendors and CA´s.

Overall it makes it possible to create it at home, and the manufacturing 
process will be cheaper. Vendors will produce standard "Qualified 
SmartCards". For the Browser vendors it will be a short amount of additional 
code, that I will try to offer them as easy to apply patches for their code.

Ah, good that you remind me, I haven´t worked out the PKCS#11 and CSP 
integration yet.

> For on-line generated and distributed
> certificates, practically the entire process is currently non-standard,
> beginning with browsers.

Yes, non-standard and therefore unnecessary costly.

> Few on-line certificate systems therefore 
> use the browser stuff and have introduced their own proprietary
> methods.  These methods typically also address PIN-code policies,
> something which seems to be missing in PKCS #10.  The
> OpenMobileAlliance have created additional standards but I don't think
> these have much acceptance by browser vendors.

Thanks. I´ll take a look at it.

Regards,
Philipp Gühring




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 j738kj6g030810; Wed, 3 Aug 2005 01:46:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j738kjvv030809; Wed, 3 Aug 2005 01:46:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j738kiUx030787 for <[e-mail]>; Wed, 3 Aug 2005 01:46:44 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.0.87  (authenticated user [e-mail]) by mx2.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 51-md50000000520.tmp for <[e-mail]>; Wed, 03 Aug 2005 10:46:38 +0200
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: [e-mail], [e-mail]
Subject: Re: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 10:46:46 +0200
User-Agent: KMail/1.8
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Spam-Processed: mx2.go-now.at, Wed, 03 Aug 2005 10:46:38 +0200 (not processed: message from valid local sender)
X-Lookup-Warning: HELO/EHLO lookup on 192.168.0.87 does not match 80.120.131.105
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j738kjUx030799
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,

> The PEM format for OpenSSL is not standard by any means, the DER format
> is equivalent to the SubjectPublicKeyInfo format which is standard (its
> is used in certificates).

Ok, then I will try to switch to that format.

> In fact since the aim seems to be to sign one public key (which resides
> on a smart card) with another (certifying it is on a smart card) and
> possibly include additional parameters why not just do this with a
> standard certificate?

Good question, thank you!

* There is no "identity" attached to the public key, at the point of time, 
where the CSR is generated.
* I want to reuse the normal Certificate Request workflow with PKCS#11, 
browsers, and CSR´s, the <keygen> integration in the browsers and the HTTP 
based communication with the CA.
* I don´t want difficult to secure out-of-band communication (having to 
transport the raw certificate additionally to the CSR for the real 
certificate)

So I think I need an additional field in the CSR.

At the beginning of the project, I thought that it would be necessary to sign 
the whole CSR, so I would need an external signature, and could not send it 
in the normal certificate request. (Which would have meant, that I would have 
to redesign the whole communication.) 
Then I had the good idea, that a signature of only the public key would be 
enough, and that I could put the signature into the CSR itself.

I have to make sure that the generated private key is in the smartcard. Since 
the generated public key determines the private key, it is enough to sign the 
generated public key.
I also thought about a secret-key signing system, which could be 
computationally easier, but then the CA would have to keep it secret, and a 
secret key couldn´t easily be shared between several CA´s, all trusting the 
same vendor´s tokens.

Regards,
Philipp Gühring




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 j738BIYe017289; Wed, 3 Aug 2005 01:11:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j738BHsj017287; Wed, 3 Aug 2005 01:11:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j738BGKE017244 for <[e-mail]>; Wed, 3 Aug 2005 01:11:17 -0700 (PDT) (envelope-from [e-mail])
Received: from pne-ps1-sn2 (81.228.8.118) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 42B813B000694A85; Wed, 3 Aug 2005 10:11:09 +0200
Message-ID: <9028463.1123056668930.JavaMail.root@pne-ps1-sn2>
Date: Wed, 3 Aug 2005 10:11:08 +0200 (MEST)
From: Anders Rundgren <[e-mail]>
Reply-To: Anders Rundgren <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Qualified Certificate Requests - RFC
Mime-Version: 1.0
Content-Type: text/plain;charset="ISO-8859-1"
X-Mailer: CP Presentation Server
X-clientstamp: [195.153.160.113]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j738BHKE017277
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,

Most QCs are probably manufactured in closed processes making 
standards less applicable.

For on-line generated and distributed 
certificates, practically the entire process is currently non-standard, 
beginning with browsers.   Few on-line certificate systems therefore 
use the browser stuff and have introduced their own proprietary 
methods.  These methods typically also address PIN-code policies, 
something which seems to be missing in PKCS #10.  The 
OpenMobileAlliance have created additional standards but I don't think 
these have much acceptance by browser vendors.

Anders Rundgren

----
Original Message----
From: [e-mail]
Date: Aug 2, 2005 10:13:55 
PM
To: [e-mail]
Subj: Qualified Certificate Requests - RFC


Hello,

I have been reading through the PKIX archive, and found a lot 
of interesting 
material on the topic of qualified certificates.

But 
what I am completely missing is the necessary foundation of qualified 
certificate requests.

Regarding the requirements for qualified 
certificates, the only obstacle I 
currently have is the problem, that 
I have to make sure, that the private key 
for the certificate is 
generated and stored securely in a SmartCard, or 
another Hardware 
Token.

Since the users should be able to issue the certificates at 
home, I need a 
technical solution to make sure, that the private key 
is from within a 
SmartCard, when we receive a certificate request.

Therefore I designed "Qualified Certificate Requests", which 
cryptographically 
signs the public key in the CSR with a vendor key, 
to state that it comes 
from a secure device.

Now I created a software-
based reference implementation, so that the security 
of the system can 
be evaluated, and that the Token Vendors can see how to do 
it, and can 
do interoperability testing:

http://www2.futureware.
at/svn/sourcerer/CAcert/QCSR/
 
The following parameters are still open 
and can be changed by the vendor: 
  The crypto algorithm (we have 
chosen RSA here)
  The encoding of the public key (we have chosen PEM 
encoding from OpenSSL) 
  The signature method (we have chosen the RSA 
signature from OpenSSL,
     which normally gives 128 binary bytes as 
signature) 
  The encoding into the qcsr field in the CSR (I have 
chosen Hex-encoding,
     since I didn´t found an easy way to do it 
directly binary yet) 
  The OID for the qcsr field (we have allocated a 
OID range below our range
     for all QCSR OID´s. Feel free to contact 
me if you want an OID for your
     parameters)

If a hardware vendor 
wants to change something on the implementation, please 
provide a 
software reference-implementation, that is bit-compatible to the 
proposed hardware implementation, so that the security can be 
evaluated. 
(I guess it will be best, if it is based on our reference-
implementation)

Should qualified certificate requests be documented in 
a own RFC, or added to 
the Qualified Certificates RFC?

Regards,
Philipp Gühring








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 j737IFJw097412; Wed, 3 Aug 2005 00:18:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j737IFEr097411; Wed, 3 Aug 2005 00:18:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (open-30-253.ietf63.ietf.org [86.255.30.253]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j737IEfe097396 for <[e-mail]>; Wed, 3 Aug 2005 00:18:14 -0700 (PDT) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3EA44E004B; Wed,  3 Aug 2005 03:18:08 -0400 (EDT)
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: EKU ambiguity in RFC 3280
References: <[e-mail]> <[e-mail]>
From: Sam Hartman <[e-mail]>
Date: Wed, 03 Aug 2005 03:18:08 -0400
In-Reply-To: <[e-mail]> (Russ Housley's message of "Tue, 02 Aug 2005 13:14:12 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
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>

>>>>> "Russ" == Russ Housley <[e-mail]> writes:

    Russ> Such applications can reject a certificate for their use if
    Russ> the expected EKU value is not present, even if the anyEKU
    Russ> OID is present.


Such applications would presumably require the EKU to be present too.



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 j733GiMl028658; Tue, 2 Aug 2005 20:16:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j733Gi4b028657; Tue, 2 Aug 2005 20:16:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j733GhFP028646 for <[e-mail]>; Tue, 2 Aug 2005 20:16:43 -0700 (PDT) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j733Gb6X018325 for <[e-mail]>; Tue, 2 Aug 2005 23:16:37 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j733GbmZ263994 for <[e-mail]>; Tue, 2 Aug 2005 23:16:37 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j733GbAx014449 for <[e-mail]>; Tue, 2 Aug 2005 23:16:37 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j733GbVI014443; Tue, 2 Aug 2005 23:16:37 -0400
In-Reply-To: <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
Cc: "pkix" <[e-mail]>
MIME-Version: 1.0
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 2 Aug 2005 23:16:35 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 08/02/2005 23:16:36, Serialize complete at 08/02/2005 23:16:36
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 j733GhFP028652
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>

        James, Santosh:

        You certainly can construct unambiguous names for CA's, and I 
think that Denis already knows that (Permanent Identifier is certainly a 
way of constructing unambiguous names, for example).  The difficulty we 
have is when one issuer issues a certificate to an organizational CA with 
a subject name which is convenient and in common use for its organization, 
but ambiguous, and then a different issuer issues a certificate to an 
organizational CA with the same subject name which is also in common use 
for its organization.  This case is most common when both organizations 
use an acronym.  I do not see why the issuers of the two organizational CA 
certificates should be assumed to originate at different trust anchors, 
although they will be different issuers.  In fact, I don't understand why 
organizational name collisions are thought to be much rarer with a "common 
trust anchor" than with "different trust anchors" if the actual issuers of 
the colliding certificates are both public CA's.
        Such collisions will have negative effects in other parts of the 
global PKI, of course.  However, unless we are prepared to issue guidance 
to deprecate the assignment of DN's for organizations with geographical 
scopes wider than the one for which they are registered and guaranteed to 
be unique (and many existing CA certificates have such DN's), I don't see 
how we can be certain or nearly certain that such collisions won't occur. 
A typical example of what I mean by an organization having a DN with a 
geographical scope wider than the one for which it's registered is a 
corporation registered in a single American state and operating in several 
states while having a DN without the stateOrProvinceName attribute.

                Tom Gindin






"Manger, James H" <[e-mail]>
Sent by: [e-mail]
08/01/2005 11:05 PM
 
        To:     "pkix" <[e-mail]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
delegated CRLs


[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
trust anchors environment of the relying parties to know if the CRL issuer 
DN will be unambiguous.]
You can construct unambiguous DNs regardless of trust anchors.  For 
instance, including DC components can make a DN as unambiguous as a DNS 
name.  As another example, the following DN
  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
is unambiguous as it lists a registered business name, its Australian 
Business Number (ABN) and the jurisdiction where those are unambiguous 
(Australia).  It is inconceivable that any CA could issue such a DN to 
another entity in good faith.
The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
issuing CA, but would be ambiguous in a wider context so it should not be 
used in cRLIssuer ? use rfc822Name=?[e-mail]? instead, for 
instance.




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 j7331spC027545; Tue, 2 Aug 2005 20:01:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7331stV027544; Tue, 2 Aug 2005 20:01:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.ntcif.telstra.com.au (mailbo.ntcif.telstra.com.au [202.12.233.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7331qSI027538 for <[e-mail]>; Tue, 2 Aug 2005 20:01:53 -0700 (PDT) (envelope-from [e-mail])
Received: from mailbi.ntcif.telstra.com.au (mailbi.ntcif.telstra.com.au [202.12.162.19]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id 4AE721342E for <[e-mail]>; Wed,  3 Aug 2005 13:01:51 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id E68A6FF81 for <[e-mail]>; Wed,  3 Aug 2005 13:01:50 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA11249 for <[e-mail]>; Wed, 3 Aug 2005 13:01:50 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C597D7.2B861EE0"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: EKU: ambiguity in RFC 3280
Date: Wed, 3 Aug 2005 12:58:05 +1000
Message-ID: <[e-mail]>
Thread-Topic: EKU: ambiguity in RFC 3280
Thread-Index: AcWWvGfQOL42YAFcQTqFJEKs9ZOppQAgRY4wACNYyEA=
From: "Manger, James H" <[e-mail]>
To: "pkix" <[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_01C597D7.2B861EE0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

T24gdGhlIHRvcGljIG9mIEVLVXPigKYNCg0KRG8gYW55IHB1YmxpYyBDQXMgYWxsb3cgdGhlIHVz
ZXIgdG8gY2hvb3NlIHRoZSBFS1UgdmFsdWVzIChvciB3aGV0aGVyIG9yIG5vdCB0byBpbmNsdWRl
IHRoZSBleHRlbnNpb24pPw0KRG8gYW55IGluY2x1ZGUgYW55RXh0ZW5kZWRLZXlVc2FnZT8NCg0K
VmVyaVNpZ24sIGZvciBpbnN0YW5jZSwgb2ZmZXIgU1NMIChhY3R1YWxseSBIVFRQUyksIHBlcnNv
bmFsIChlbWFpbCkgYW5kIGNvZGUgc2lnbmluZyBjZXJ0aWZpY2F0ZXMuICBJIGFzc3VtZSB0aGVz
ZSBpbmNsdWRlIHsgaWQta3Atc2VydmVyQXV0aCwgaWQta3AtY2xpZW50QXV0aCB9LCB7IGlkLWtw
LWVtYWlsUHJvdGVjdGlvbiB9IGFuZCB7IGlkLWtwLWNvZGVTaWduaW5nIH0gRUtVIGV4dGVuc2lv
biB2YWx1ZXMgcmVzcGVjdGl2ZWx5LiAgTm9uZSBvZiB0aGVzZSBjZXJ0aWZpY2F0ZXMgY2FuIGJl
IHJlbGlhYmx5IHVzZWQgZm9yIGFub3RoZXIgcHVycG9zZSwgc3VjaCBhcyBzaWduaW5nIGEgU09B
UCBtZXNzYWdlLCBhcyByZWx5aW5nIHBhcnRpZXMgdGhhdCB1bmRlcnN0YW5kICh0aGUgbm9uLWNy
aXRpY2FsKSBFS1Ugd2lsbCByZWplY3QgdGhlIGNlcnRpZmljYXRlIGFzIGl0IGRvZXMgbm90IGlu
Y2x1ZGUgYW55RXh0ZW5kZWRLZXlVc2FnZS4NCg0KUC5TLiBUaGUgbWluaW1hbCB0ZXh0IGFzc29j
aWF0ZWQgd2l0aCB0aGUgaWQta3Ate2NsaWVudHxzZXJ2ZXJ9QXV0aCBFS1UgdmFsdWVzIGlzIOKA
nFRMUyBXV1cge2NsaWVudHxzZXJ2ZXJ9IGF1dGhlbnRpY2F0aW9u4oCdLiAg4oCcV1dX4oCdIGlt
cGxpZXMgKHRvIG1lKSB0aGF0IHRoZXNlIHB1cnBvc2VzIGFyZSBzcGVjaWZpY2FsbHkgZm9yIEhU
VFBTLiAgT3RoZXIgdXNlcyBvZiBUTFMvU1NMIChzdWNoIGFzIExEQVAgb3ZlciBUTFMpIGFyZSBu
b3QgY292ZXJlZCBieSB0aGVzZSBpZGVudGlmaWVycy4gIFBlcmhhcHMgMzI4MGJpcyBjb3VsZCBt
YWtlIHRoaXMgYSBiaXQgY2xlYXJlciBieSBleHBsaWNpdGx5IG1lbnRpb25pbmcgSFRUUCwgaW5z
dGVhZCBvZiBqdXN0IFdXVy4NCg==

------_=_NextPart_001_01C597D7.2B861EE0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg
RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41LjcyMzIuMTEiPg0KPFRJVExFPlJFOiBFS1U6IGFt
YmlndWl0eSBpbiBSRkMgMzI4MDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVy
dGVkIGZyb20gdGV4dC9ydGYgZm9ybWF0IC0tPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9
ImVuLWF1Ij48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5PbiB0aGUg
dG9waWMgb2YgRUtVczwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BB
TiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+
4oCmPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVu
LWF1Ij48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9O
VCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5EbyBhbnkgcHVibGljIENBcyBh
bGxvdyB0aGUgdXNlciB0byBjaG9vc2UgdGhlIEVLVTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0i
ZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+IHZhbHVlcyAob3Igd2hldGhlciBvciBub3QgdG88L0ZPTlQ+PC9T
UEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9OVCBD
T0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5pbmNsdWRlIHRoZSBleHRlbnNpb24p
PzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1h
dSI+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQg
Q09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+RG8gYW55IGluY2x1ZGUgYW55RXh0
ZW5kZWRLZXlVc2FnZT88L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQ
QU4gTEFORz0iZW4tYXUiPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0i
ZW4tYXUiPjxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPlZlcmlTaWdu
LCBmb3IgaW5zdGFuY2UsIG9mZmVyIFNTTCAoYWN0dWFsbHkgSFRUUFMpLCBwZXJzb25hbCAoPC9G
T05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48
Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5lbWFpbDwvRk9OVD48L1NQ
QU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09M
T1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+KSBhbmQ8L0ZPTlQ+PC9TUEFOPjxTUEFO
IExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAw
MDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPiBjb2RlIHNpZ25pbmcgY2VydGlmaWNhdGVzLiZuYnNw
OyBJIGFzc3VtZSB0aGVzZTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48
U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJp
YWwiPmluY2x1ZGU8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4g
TEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPiB7
PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1
Ij4gPEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+aWQta3Atc2VydmVy
QXV0aDwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJl
bi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+LDwvRk9OVD48
L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05U
IENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPmlkLWtwLTwvRk9OVD48L1NQQU4+
PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9
IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+Y2xpZW50PC9GT05UPjwvU1BBTj48U1BBTiBM
QU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBDT0xPUj0iIzAwMDA4
MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5BdXRoPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1h
dSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0y
IEZBQ0U9IkFyaWFsIj4gfSwgezwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BB
Tj48U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0i
QXJpYWwiPmlkLWtwLWVtYWlsUHJvdGVjdGlvbjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4t
YXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9
MiBGQUNFPSJBcmlhbCI+IH0gYW5kIHs8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48
L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZB
Q0U9IkFyaWFsIj5pZC1rcC1jb2RlU2lnbmluZzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4t
YXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9
MiBGQUNFPSJBcmlhbCI+IH0gRUtVIGV4dGVuc2lvbiB2YWx1ZXMgcmVzcGVjdGl2ZWx5LiZuYnNw
OyBOb25lIG9mIHRoZXNlIGNlcnRpZmljYXRlczwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4t
YXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpF
PTIgRkFDRT0iQXJpYWwiPmNhbiBiZTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwv
U1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFD
RT0iQXJpYWwiPnJlbGlhYmx5PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFO
PjxTUEFOIExBTkc9ImVuLWF1Ij4gPEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJB
cmlhbCI+dXNlZCBmb3IgYW5vdGhlciBwdXJwb3NlLCBzdWNoIGFzIHNpZ25pbmcgYSBTT0FQIG1l
c3NhZ2UsIGFzIHJlbHlpbmcgcGFydGllcyB0aGF0IHVuZGVyc3RhbmQ8L0ZPTlQ+PC9TUEFOPjxT
UEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9OVCBDT0xPUj0i
IzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj4odGhlIG5vbi1jcml0aWNhbCk8L0ZPTlQ+PC9T
UEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9OVCBD
T0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5FS1U8L0ZPTlQ+PC9TUEFOPjxTUEFO
IExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAw
MDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPiB3aWxsIHJlamVjdCB0aGUgY2VydGlmaWNhdGUgYXMg
aXQgZG9lcyBub3QgaW5jbHVkZSBhbnlFeHRlbmRlZEtleVVzYWdlLjwvRk9OVD48L1NQQU4+PFNQ
QU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjwvUD4NCg0K
PFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+UC5TLjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwv
U1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFD
RT0iQXJpYWwiPlRoZSBtaW5pbWFsIHRleHQgYXNzb2NpYXRlZCB3aXRoPC9GT05UPjwvU1BBTj48
U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij4gPEZPTlQgQ09MT1I9
IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+dGhlPC9GT05UPjwvU1BBTj48U1BBTiBMQU5H
PSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij4gPEZPTlQgQ09MT1I9IiMwMDAwODAi
IFNJWkU9MiBGQUNFPSJBcmlhbCI+aWQta3Ate2NsaWVudHxzZXJ2ZXJ9QXV0aDwvRk9OVD48L1NQ
QU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09M
T1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+IEVLVSB2YWx1ZXM8L0ZPTlQ+PC9TUEFO
PjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9OVCBDT0xP
Uj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5pczwvRk9OVD48L1NQQU4+PFNQQU4gTEFO
Rz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05UIENPTE9SPSIjMDAwMDgw
IiBTSVpFPTIgRkFDRT0iQXJpYWwiPuKAnDwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUi
PjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBG
QUNFPSJBcmlhbCI+VExTIFdXVyB7Y2xpZW50fHNlcnZlcn0gYXV0aGVudGljYXRpb248L0ZPTlQ+
PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05U
IENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPuKAnTwvRk9OVD48L1NQQU4+PFNQ
QU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMw
MDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+LiZuYnNwOzwvRk9OVD48L1NQQU4+PFNQQU4gTEFO
Rz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05UIENPTE9SPSIjMDAwMDgw
IiBTSVpFPTIgRkFDRT0iQXJpYWwiPuKAnDwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUi
PjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBG
QUNFPSJBcmlhbCI+V1dXPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxT
UEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFs
Ij7igJ08L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0i
ZW4tYXUiPjxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPiBpbXBsaWVz
PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1
Ij4gPEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+KHRvIG1lKTwvRk9O
VD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+IDxG
T05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPnRoYXQgdGhlc2U8L0ZPTlQ+
PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9O
VCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5wdXJwb3NlcyBhcmUgc3BlY2lm
aWNhbGx5IGZvciBIVFRQUzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48
U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlh
bCI+LiZuYnNwOyBPdGhlciB1c2VzIG9mIFRMUy9TU0wgKHN1Y2ggYXMgTERBUCBvdmVyIFRMUykg
YXJlIG5vdCBjb3ZlcmVkIGJ5IHRoZXNlIGlkZW50aWZpZXI8L0ZPTlQ+PC9TUEFOPjxTUEFOIExB
Tkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAwMDgw
IiBTSVpFPTIgRkFDRT0iQXJpYWwiPnM8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48
L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFD
RT0iQXJpYWwiPi48L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4g
TEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPiZu
YnNwOyBQZXJoYXBzIDMyODBiaXMgY291bGQgbWFrZSB0aGlzIGEgYml0IGNsZWFyZXIgYnkgZXhw
bGljaXRseSBtZW50aW9uaW5nIEhUVFAsIGluc3RlYWQgb2YganVzdCBXV1cuPC9GT05UPjwvU1BB
Tj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PC9Q
Pg0KDQo8L0JPRFk+DQo8L0hUTUw+

------_=_NextPart_001_01C597D7.2B861EE0--



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 j72KDtOL088686; Tue, 2 Aug 2005 13:13:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72KDt44088685; Tue, 2 Aug 2005 13:13:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72KDstM088676 for <[e-mail]>; Tue, 2 Aug 2005 13:13:54 -0700 (PDT) (envelope-from [e-mail])
Received: from 192.168.20.6 wien-rasumofsky.xdsl-line.inode.at  (authenticated user [e-mail]) by mx2.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 32-md50000000507.tmp for <[e-mail]>; Tue, 02 Aug 2005 22:13:53 +0200
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: [e-mail]
Subject: Qualified Certificate Requests - RFC
User-Agent: KMail/1.8
MIME-Version: 1.0
Content-Disposition: inline
Date: Tue, 2 Aug 2005 22:13:55 +0200
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <[e-mail]>
X-Spam-Processed: mx2.go-now.at, Tue, 02 Aug 2005 22:13:53 +0200 (not processed: message from valid local sender)
X-Lookup-Warning: HELO/EHLO lookup on 192.168.20.6 does not match 62.99.234.10
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72KDstM088677
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,

I have been reading through the PKIX archive, and found a lot of interesting 
material on the topic of qualified certificates.

But what I am completely missing is the necessary foundation of qualified 
certificate requests.

Regarding the requirements for qualified certificates, the only obstacle I 
currently have is the problem, that I have to make sure, that the private key 
for the certificate is generated and stored securely in a SmartCard, or 
another Hardware Token.

Since the users should be able to issue the certificates at home, I need a 
technical solution to make sure, that the private key is from within a 
SmartCard, when we receive a certificate request.

Therefore I designed "Qualified Certificate Requests", which cryptographically 
signs the public key in the CSR with a vendor key, to state that it comes 
from a secure device.

Now I created a software-based reference implementation, so that the security 
of the system can be evaluated, and that the Token Vendors can see how to do 
it, and can do interoperability testing:

http://www2.futureware.at/svn/sourcerer/CAcert/QCSR/
 
The following parameters are still open and can be changed by the vendor: 
  The crypto algorithm (we have chosen RSA here)
  The encoding of the public key (we have chosen PEM encoding from OpenSSL) 
  The signature method (we have chosen the RSA signature from OpenSSL,
     which normally gives 128 binary bytes as signature) 
  The encoding into the qcsr field in the CSR (I have chosen Hex-encoding,
     since I didn´t found an easy way to do it directly binary yet) 
  The OID for the qcsr field (we have allocated a OID range below our range
     for all QCSR OID´s. Feel free to contact me if you want an OID for your
     parameters)

If a hardware vendor wants to change something on the implementation, please 
provide a software reference-implementation, that is bit-compatible to the 
proposed hardware implementation, so that the security can be evaluated. 
(I guess it will be best, if it is based on our reference-implementation)

Should qualified certificate requests be documented in a own RFC, or added to 
the Qualified Certificates RFC?

Regards,
Philipp Gühring




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 j72HEHH9070155; Tue, 2 Aug 2005 10:14:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72HEHm8070154; Tue, 2 Aug 2005 10:14:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72HEGNp070145 for <[e-mail]>; Tue, 2 Aug 2005 10:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 16910 invoked by uid 0); 2 Aug 2005 17:14:11 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (86.255.31.117) by woodstock.binhost.com with SMTP; 2 Aug 2005 17:14:11 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 02 Aug 2005 13:14:12 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: EKU ambiguity in RFC 3280
Cc: [e-mail]
In-Reply-To: <[e-mail] .corp.microsoft.com>
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>

I agree with this interpretation.  This is what is meant by:

    Certificate using applications MAY require that a particular purpose
    be indicated in order for the certificate to be acceptable to that 
application.

Such applications can reject a certificate for their use if the expected 
EKU value is not present, even if the anyEKU OID is present.

Russ

At 09:12 AM 8/2/2005, Stefan Santesson wrote:

>Are what you say that presence of anyEKU just allows an application who
>don't care about EKUs to ignore the EKU extension content?
>
>That is, that anyEKY is never considered a match when a specific EKU is
>required in a certificate?
>
>I could live with that, it just needs to be said more clearly.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: Jim Schaad [mailto:[e-mail]]
> > Sent: den 2 augusti 2005 05:11
> > To: Stefan Santesson; 'pkix'
> > Subject: RE: EKU ambiguity in RFC 3280
> >
> > Stefan,
> >
> > It is my opionion that what the Kerbros working group wants is
>correct.
> > The
> > anyExtendedKeyUsage is provided so that one can place a specific EKU
>into
> > a
> > certificate, but still allow the certificate to be used for other
>usages
> > as
> > well.
> >
> > jim
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Stefan Santesson
> > > Sent: Tuesday, August 02, 2005 12:04 PM
> > > To: pkix
> > > Subject: EKU ambiguity in RFC 3280
> > >
> > >
> > >
> > > I would like to raise an issue of potential ambiguity of the
> > > specification of the EKU extension and the meaning of the anyEKU
>OID.
> > >
> > > RFC 3280 states:
> > >    If the extension is present, then the certificate MUST only be
>used
> > >    for one of the purposes indicated.  If multiple purposes are
> > >    indicated the application need not recognize all purposes
> > > indicated,
> > >    as long as the intended purpose is present.  Certificate using
> > >    applications MAY require that a particular purpose be indicated
>in
> > >    order for the certificate to be acceptable to that application.
> > >
> > >    If a CA includes extended key usages to satisfy such
>applications,
> > >    but does not wish to restrict usages of the key, the CA can
>include
> > >    the special keyPurposeID anyExtendedKeyUsage.  Conforming
> > > CAs SHOULD
> > >    NOT mark this extension as critical if the anyExtendedKeyUsage
> > >    keyPurposeID is present.
> > >
> > >
> > > The statement of concern is:
> > >    "Certificate using
> > >    applications MAY require that a particular purpose be indicated
>in
> > >    order for the certificate to be acceptable to that application."
> > >
> > >
> > > The ambiguity is whether that requirement is satisfied by
> > > presence of anyEKU in the certificate or not.
> > >
> > > On one hand you could argue that this means that an
> > > application can require that a specific EKU is explicitly
> > > listed (anyEKU would not be enough), but on the other hand
> > > you could argue that the succeeding paragraph defines the
> > > meaning of anyEKU to be equivalent to explicit presence of
> > > all possible EKUs and thus would satisfy this requirement.
> > >
> > > Compare with how we process certificate policies, where the
> > > special policy anyPolicy actually satisfies requirement for
> > > any specific policy in the path validation algorithm. That
> > > is, there is no way to specify that a particular policy must
> > > be explicitly present and that anyPolicy will not satisfy as
> > > substitution.
> > >
> > > This issue became recently highlighted in the Kerberos WG
> > > where it was suggested that the Kerberos PKINIT specification
> > > could require the Kerberos EKU to be explicitly present but
> > > would not accept the anyEKU as substitution.
> > >
> > > The practical problem arises if EKU matching is performed by
> > > a standard library which automatically match anyEKU to any
> > > specific EKU requested for the certificate. Following the
> > > logic of the Kerberos logic it would require that library to
> > > accept an argument that anyEKU matching should be disabled,
> > > which adds complexity and introduces confusion.
> > >
> > > At least I think this issue needs to be clarified in RFC 3280bis.
> > >
> > >
> > >
> >



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 j72E62DU053181; Tue, 2 Aug 2005 07:06:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72E62e4053180; Tue, 2 Aug 2005 07:06:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72E61r8053166 for <[e-mail]>; Tue, 2 Aug 2005 07:06:01 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 31307 invoked by uid 0); 2 Aug 2005 14:05:57 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (86.255.31.117) by woodstock.binhost.com with SMTP; 2 Aug 2005 14:05:57 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 02 Aug 2005 10:05:56 -0400
To: "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: 3280bis: KeyUsage NR/CC bit
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
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>

[ Responding as an author of RFC 3280, not as a Security AD. ]

We have had more discussion of this bit than any other bit.  In my opinion, 
way too much.  I am quite reluctant to engage in another discussion of it.

My recollection of the last time we discussed this topic is quite 
clear.  Consensus was that the text in RFC 3280 was a good compromise and 
that any further effort have a very low probability of improving it.

Yet, the discussion happened in the ITU-T.  The result is the text in the 
message from Denis.

It seems to me that this leaves us in the same position we were in a few 
years ago.  I still do not think that the new text is providing any clarity 
over the text that is in RFC 3280.  I expect we will spend a huge amount of 
time discussing it.

The ITU-T should not have changed the name of the bit.  Several 
implementors discouraged the ITU-T from making this name change, but they 
did so anyway.  I am strongly apposed to changing the name of this bit in 
our specification, and I am very please to see that Denis is not advocating 
doing so.  I think that we should probably add a note that tells the reader 
that the ITU-T did elect to make this change.

Russ


At 06:10 AM 7/28/2005, Denis Pinkas wrote:


>Extract from: draft-ietf-pkix-rfc3280bis-01.txt :
>
>« The nonRepudiation bit is asserted when the subject public key
>is used to verify digital signatures, other than signatures on
>certificates (bit 5) and CRLs (bit 6), used to provide a non-repudiation
>service which protects against the signing entity falsely denying
>some action. In the case of later conflict, a reliable third party may
>determine the authenticity of the signed data ».
>
>I can live with the proposed ASN.1.
>
>I would however suggest to re-use some of the key words of X.509.
>In the last sentence "authenticity of the signed data" may be misleading
>since it is missing the notion of time.
>
>Proposal for a compromise with X.509 2000)/Cor.3 (04/2004):
>
>" The nonRepudiation bit is asserted when the subject public key
>is used to verify digital signatures, other than signatures on
>certificates (bit 5) and CRLs (bit 6), which are intended to signal
>that the signer is committing to the content being signed.
>In the case of later conflict, this allows to provide a non-repudiation
>service which protects against the signing entity falsely denying some 
>action ».
>
>Denis
>
>PS: The original text from the TC of X.509 is:
>
>b) contentCommitment: for verifying digital signatures which
>are intended to signal that the signer is committing to the content being 
>signed.
>The precise level of commitment, e.g. "with the intent to be bound"
>may be signaled by additional methods, e.g. certificate policy.
>
>Since a content commitment signing is considered to be a digitally signed
>transaction, the digitalSignature bit need not be set in the certificate.
>If it is set, it does not affect the level of commitment the signer has
>endowed in the signed content.
>
>Note that it is not incorrect to refer to this keyUsage bit using the
>identifier nonRepudiation. However, the use this identifier has been
>deprecated. Regardless of the identifier used, the semantics of this
>bit are as specified in this standard.



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 j72DCUZR033083; Tue, 2 Aug 2005 06:12:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72DCU5G033082; Tue, 2 Aug 2005 06:12:30 -0700 (PDT)
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 j72DCSAP033042 for <[e-mail]>; Tue, 2 Aug 2005 06:12:29 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 14:12:23 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: EKU ambiguity in RFC 3280
Date: Tue, 2 Aug 2005 14:12:18 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: EKU ambiguity in RFC 3280
Thread-Index: AcWWvGfQOL42YAFcQTqFJEKs9ZOppQAgRY4wAAdgs9AAAV2CEA==
From: "Stefan Santesson" <[e-mail]>
To: "Jim Schaad" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 02 Aug 2005 13:12:23.0449 (UTC) FILETIME=[D239D890:01C59763]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72DCTAP033072
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>

Are what you say that presence of anyEKU just allows an application who
don't care about EKUs to ignore the EKU extension content? 

That is, that anyEKY is never considered a match when a specific EKU is
required in a certificate?

I could live with that, it just needs to be said more clearly.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: den 2 augusti 2005 05:11
> To: Stefan Santesson; 'pkix'
> Subject: RE: EKU ambiguity in RFC 3280
> 
> Stefan,
> 
> It is my opionion that what the Kerbros working group wants is
correct.
> The
> anyExtendedKeyUsage is provided so that one can place a specific EKU
into
> a
> certificate, but still allow the certificate to be used for other
usages
> as
> well.
> 
> jim
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Stefan Santesson
> > Sent: Tuesday, August 02, 2005 12:04 PM
> > To: pkix
> > Subject: EKU ambiguity in RFC 3280
> >
> >
> >
> > I would like to raise an issue of potential ambiguity of the
> > specification of the EKU extension and the meaning of the anyEKU
OID.
> >
> > RFC 3280 states:
> >    If the extension is present, then the certificate MUST only be
used
> >    for one of the purposes indicated.  If multiple purposes are
> >    indicated the application need not recognize all purposes
> > indicated,
> >    as long as the intended purpose is present.  Certificate using
> >    applications MAY require that a particular purpose be indicated
in
> >    order for the certificate to be acceptable to that application.
> >
> >    If a CA includes extended key usages to satisfy such
applications,
> >    but does not wish to restrict usages of the key, the CA can
include
> >    the special keyPurposeID anyExtendedKeyUsage.  Conforming
> > CAs SHOULD
> >    NOT mark this extension as critical if the anyExtendedKeyUsage
> >    keyPurposeID is present.
> >
> >
> > The statement of concern is:
> >    "Certificate using
> >    applications MAY require that a particular purpose be indicated
in
> >    order for the certificate to be acceptable to that application."
> >
> >
> > The ambiguity is whether that requirement is satisfied by
> > presence of anyEKU in the certificate or not.
> >
> > On one hand you could argue that this means that an
> > application can require that a specific EKU is explicitly
> > listed (anyEKU would not be enough), but on the other hand
> > you could argue that the succeeding paragraph defines the
> > meaning of anyEKU to be equivalent to explicit presence of
> > all possible EKUs and thus would satisfy this requirement.
> >
> > Compare with how we process certificate policies, where the
> > special policy anyPolicy actually satisfies requirement for
> > any specific policy in the path validation algorithm. That
> > is, there is no way to specify that a particular policy must
> > be explicitly present and that anyPolicy will not satisfy as
> > substitution.
> >
> > This issue became recently highlighted in the Kerberos WG
> > where it was suggested that the Kerberos PKINIT specification
> > could require the Kerberos EKU to be explicitly present but
> > would not accept the anyEKU as substitution.
> >
> > The practical problem arises if EKU matching is performed by
> > a standard library which automatically match anyEKU to any
> > specific EKU requested for the certificate. Following the
> > logic of the Kerberos logic it would require that library to
> > accept an argument that anyEKU matching should be disabled,
> > which adds complexity and introduces confusion.
> >
> > At least I think this issue needs to be clarified in RFC 3280bis.
> >
> >
> >
> 




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 j72C8WNX009563; Tue, 2 Aug 2005 05:08:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72C8WZC009562; Tue, 2 Aug 2005 05:08:32 -0700 (PDT)
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 j72C8VaA009552 for <[e-mail]>; Tue, 2 Aug 2005 05:08:32 -0700 (PDT) (envelope-from [e-mail])
Received: from romans (open-29-1.ietf63.ietf.org [86.255.29.1]) by smtp1.pacifier.net (Postfix) with ESMTP id 5790D74B64; Tue,  2 Aug 2005 05:08:30 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'pkix'" <[e-mail]>
Subject: RE: EKU ambiguity in RFC 3280
Date: Tue, 2 Aug 2005 14:10:53 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcWWvGfQOL42YAFcQTqFJEKs9ZOppQAgRY4wAAdgs9A=
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>

Stefan,

It is my opionion that what the Kerbros working group wants is correct.  The
anyExtendedKeyUsage is provided so that one can place a specific EKU into a
certificate, but still allow the certificate to be used for other usages as
well.

jim 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Stefan Santesson
> Sent: Tuesday, August 02, 2005 12:04 PM
> To: pkix
> Subject: EKU ambiguity in RFC 3280
> 
> 
> 
> I would like to raise an issue of potential ambiguity of the 
> specification of the EKU extension and the meaning of the anyEKU OID.
> 
> RFC 3280 states:
>    If the extension is present, then the certificate MUST only be used
>    for one of the purposes indicated.  If multiple purposes are
>    indicated the application need not recognize all purposes 
> indicated,
>    as long as the intended purpose is present.  Certificate using
>    applications MAY require that a particular purpose be indicated in
>    order for the certificate to be acceptable to that application.
> 
>    If a CA includes extended key usages to satisfy such applications,
>    but does not wish to restrict usages of the key, the CA can include
>    the special keyPurposeID anyExtendedKeyUsage.  Conforming 
> CAs SHOULD
>    NOT mark this extension as critical if the anyExtendedKeyUsage
>    keyPurposeID is present.
> 
> 
> The statement of concern is:
>    "Certificate using
>    applications MAY require that a particular purpose be indicated in
>    order for the certificate to be acceptable to that application."
> 
> 
> The ambiguity is whether that requirement is satisfied by 
> presence of anyEKU in the certificate or not.
> 
> On one hand you could argue that this means that an 
> application can require that a specific EKU is explicitly 
> listed (anyEKU would not be enough), but on the other hand 
> you could argue that the succeeding paragraph defines the 
> meaning of anyEKU to be equivalent to explicit presence of 
> all possible EKUs and thus would satisfy this requirement.
> 
> Compare with how we process certificate policies, where the 
> special policy anyPolicy actually satisfies requirement for 
> any specific policy in the path validation algorithm. That 
> is, there is no way to specify that a particular policy must 
> be explicitly present and that anyPolicy will not satisfy as 
> substitution.
> 
> This issue became recently highlighted in the Kerberos WG 
> where it was suggested that the Kerberos PKINIT specification 
> could require the Kerberos EKU to be explicitly present but 
> would not accept the anyEKU as substitution.
> 
> The practical problem arises if EKU matching is performed by 
> a standard library which automatically match anyEKU to any 
> specific EKU requested for the certificate. Following the 
> logic of the Kerberos logic it would require that library to 
> accept an argument that anyEKU matching should be disabled, 
> which adds complexity and introduces confusion.
> 
> At least I think this issue needs to be clarified in RFC 3280bis.
> 
> 
> 




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 j72A4VNh066052; Tue, 2 Aug 2005 03:04:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72A4VZL066043; Tue, 2 Aug 2005 03:04:31 -0700 (PDT)
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 j72A4SUc065893 for <[e-mail]>; Tue, 2 Aug 2005 03:04:29 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 11:04:22 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: EKU ambiguity in RFC 3280
Date: Tue, 2 Aug 2005 11:04:16 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: EKU ambiguity in RFC 3280
Thread-Index: AcWWvGfQOL42YAFcQTqFJEKs9ZOppQAgRY4w
From: "Stefan Santesson" <[e-mail]>
To: "pkix" <[e-mail]>
X-OriginalArrivalTime: 02 Aug 2005 10:04:22.0757 (UTC) FILETIME=[8E68D950:01C59749]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72A4UUc066022
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 would like to raise an issue of potential ambiguity of the
specification of the EKU extension and the meaning of the anyEKU OID.

RFC 3280 states:
   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.  If multiple purposes are
   indicated the application need not recognize all purposes indicated,
   as long as the intended purpose is present.  Certificate using
   applications MAY require that a particular purpose be indicated in
   order for the certificate to be acceptable to that application.

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special keyPurposeID anyExtendedKeyUsage.  Conforming CAs SHOULD
   NOT mark this extension as critical if the anyExtendedKeyUsage
   keyPurposeID is present.


The statement of concern is:
   "Certificate using
   applications MAY require that a particular purpose be indicated in
   order for the certificate to be acceptable to that application."


The ambiguity is whether that requirement is satisfied by presence of
anyEKU in the certificate or not.

On one hand you could argue that this means that an application can
require that a specific EKU is explicitly listed (anyEKU would not be
enough), but on the other hand you could argue that the succeeding
paragraph defines the meaning of anyEKU to be equivalent to explicit
presence of all possible EKUs and thus would satisfy this requirement.

Compare with how we process certificate policies, where the special
policy anyPolicy actually satisfies requirement for any specific policy
in the path validation algorithm. That is, there is no way to specify
that a particular policy must be explicitly present and that anyPolicy
will not satisfy as substitution.

This issue became recently highlighted in the Kerberos WG where it was
suggested that the Kerberos PKINIT specification could require the
Kerberos EKU to be explicitly present but would not accept the anyEKU as
substitution.

The practical problem arises if EKU matching is performed by a standard
library which automatically match anyEKU to any specific EKU requested
for the certificate. Following the logic of the Kerberos logic it would
require that library to accept an argument that anyEKU matching should
be disabled, which adds complexity and introduces confusion.

At least I think this issue needs to be clarified in RFC 3280bis.



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 j7239JZ0015746; Mon, 1 Aug 2005 20:09:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7239JNG015745; Mon, 1 Aug 2005 20:09:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.ntcif.telstra.com.au (mailbo.ntcif.telstra.com.au [202.12.233.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7239Hx1015733 for <[e-mail]>; Mon, 1 Aug 2005 20:09:18 -0700 (PDT) (envelope-from [e-mail])
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id D2A4412F36 for <[e-mail]>; Tue,  2 Aug 2005 13:09:15 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 3FC4FFF86 for <[e-mail]>; Tue,  2 Aug 2005 13:09:15 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA21310 for <[e-mail]>; Tue, 2 Aug 2005 13:09:14 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5970F.0318AEA0"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Tue, 2 Aug 2005 13:05:18 +1000
Message-ID: <[e-mail]>
Thread-Topic: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Thread-Index: AcWOAMGfO1zobKO0R76z+h7EPd2VuwAUanEgAgRUHSAAJOZJkA==
From: "Manger, James H" <[e-mail]>
To: "pkix" <[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_01C5970F.0318AEA0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

CVtTYW50b3NoOiBSZXF1aXJpbmcgYSB1bmlxdWUgRE5TIG1heSBiZSBmaW5lLiAgQnV0LCBDQSBk
b2VzIG5vdCBrbm93IHRoZSB0cnVzdCBhbmNob3JzIGVudmlyb25tZW50IG9mIHRoZSByZWx5aW5n
IHBhcnRpZXMgdG8ga25vdyBpZiB0aGUgQ1JMIGlzc3VlciBETiB3aWxsIGJlIHVuYW1iaWd1b3Vz
Ll0NCg0KWW91IGNhbiBjb25zdHJ1Y3QgdW5hbWJpZ3VvdXMgRE5zIHJlZ2FyZGxlc3Mgb2YgdHJ1
c3QgYW5jaG9ycy4gIEZvciBpbnN0YW5jZSwgaW5jbHVkaW5nIERDIGNvbXBvbmVudHMgY2FuIG1h
a2UgYSBETiBhcyB1bmFtYmlndW91cyBhcyBhIEROUyBuYW1lLiAgQXMgYW5vdGhlciBleGFtcGxl
LCB0aGUgZm9sbG93aW5nIERODQogIG894oCdUWFudGFzIEFpcndheXMgTGltaXRlZCwgQUJOIDE2
IDAwOSA2NjEgOTAx4oCdLCBjPeKAnUFV4oCdDQppcyB1bmFtYmlndW91cyBhcyBpdCBsaXN0cyBh
IHJlZ2lzdGVyZWQgYnVzaW5lc3MgbmFtZSwgaXRzIEF1c3RyYWxpYW4gQnVzaW5lc3MgTnVtYmVy
IChBQk4pIGFuZCB0aGUganVyaXNkaWN0aW9uIHdoZXJlIHRob3NlIGFyZSB1bmFtYmlndW91cyAo
QXVzdHJhbGlhKS4gIEl0IGlzIGluY29uY2VpdmFibGUgdGhhdCBhbnkgQ0EgY291bGQgaXNzdWUg
c3VjaCBhIEROIHRvIGFub3RoZXIgZW50aXR5IGluIGdvb2QgZmFpdGguDQpUaGUgRE4gY2494oCd
Sm9obiBTbWl0aOKAnSwgYz3igJ1VU+KAnSBtYXkgYmUgdW5hbWJpZ3VvdXMgaW4gdGhlIGNvbnRl
eHQgb2YgYW4gaXNzdWluZyBDQSwgYnV0IHdvdWxkIGJlIGFtYmlndW91cyBpbiBhIHdpZGVyIGNv
bnRleHQgc28gaXQgc2hvdWxkIG5vdCBiZSB1c2VkIGluIGNSTElzc3VlciDigJMgdXNlIHJmYzgy
Mk5hbWU94oCdSm9oblNtaXRoNTU1QHlhaG9vLmNvbeKAnSBpbnN0ZWFkLCBmb3IgaW5zdGFuY2Uu
DQoNCg==

------_=_NextPart_001_01C5970F.0318AEA0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg
RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41LjcyMzIuMTEiPg0KPFRJVExFPlJFOiAzMjgwYmlz
OiBzdWdnZXN0ZWQgd29yZHMgZm9yIGFtYmlndW91cyBETnMgYW5kIGRlbGVnYXRlZCBDUkxzPC9U
SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3J0ZiBmb3Jt
YXQgLS0+DQo8VUw+DQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPltTYW50b3NoOiBSZXF1aXJpbmcgYSB1bmlxdWUgRE5TIG1heSBiZSBm
aW5lLiZuYnNwOyBCdXQsIENBIGRvZXMgbm90IGtub3cgdGhlIHRydXN0IGFuY2hvcnMgZW52aXJv
bm1lbnQgb2YgdGhlIHJlbHlpbmcgcGFydGllcyB0byBrbm93IGlmIHRoZSBDUkwgaXNzdWVyIERO
IHdpbGwgYmUgdW5hbWJpZ3VvdXMuXTwvRk9OVD48L1NQQU4+PC9QPg0KPC9VTD4NCjxQIEFMSUdO
PUxFRlQ+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFD
RT0iQXJpYWwiPllvdSBjYW4gY29uc3RydWN0IHVuYW1iaWd1b3VzIEROcyByZWdhcmRsZXNzIG9m
IHRydXN0IGFuY2hvcnMuJm5ic3A7PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9T
UEFOPjxTUEFOIExBTkc9ImVuLWF1Ij4gPEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNF
PSJBcmlhbCI+Rm9yIGluc3RhbmNlLCBpPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+
PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZB
Q0U9IkFyaWFsIj5uY2x1ZGluZyBEQyBjb21wb25lbnRzIGNhbiBtYWtlIGEgRE4gYTwvRk9OVD48
L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQg
Q09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+czwvRk9OVD48L1NQQU4+PFNQQU4g
TEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAw
ODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+IHVuYW1iaWd1b3VzIGFzIGEgRE5TIG5hbWU8L0ZPTlQ+
PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05U
IENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPi4mbmJzcDs8L0ZPTlQ+PC9TUEFO
PjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9OVCBDT0xP
Uj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5BcyBhbm90aGVyIGV4YW1wbGUsIHQ8L0ZP
TlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxG
T05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPmhlIGZvbGxvd2luZyBETjwv
Rk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9O
VCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDs8L0ZPTlQ+PC9TUEFO
PjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9OVCBDT0xP
Uj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5vPTwvRk9OVD48L1NQQU4+PFNQQU4gTEFO
Rz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAi
IFNJWkU9MiBGQUNFPSJBcmlhbCI+4oCdPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+
PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZB
Q0U9IkFyaWFsIj5RYW50YXMgQWlyd2F5czwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUi
PjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBG
QUNFPSJBcmlhbCI+IExpbWl0ZWQsIEFCTiAxNiAwMDkgNjYxIDkwMTwvRk9OVD48L1NQQU4+PFNQ
QU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMw
MDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+4oCdPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJl
bi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0la
RT0yIEZBQ0U9IkFyaWFsIj4sPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFO
PjxTUEFOIExBTkc9ImVuLWF1Ij4gPEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Yz08L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFO
Rz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPuKAnTwv
Rk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+
PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+QVU8L0ZPTlQ+PC9TUEFO
PjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9S
PSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPuKAnTwvRk9OVD48L1NQQU4+PFNQQU4gTEFO
Rz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjwvUD4NCg0KPFAgQUxJ
R049TEVGVD48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBG
QUNFPSJBcmlhbCI+aXMgdW5hbWJpZ3VvdXMgYXMgaXQgbGlzdHMgYSByZWdpc3RlcmVkIGJ1c2lu
ZXNzIG5hbWUsIGl0cyBBdXN0cmFsaWFuIEJ1c2luZXNzIE51bWJlciAoQUJOKSBhbmQgdGhlPC9G
T05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij4g
PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+anVyaXNkaWN0aW9uIHdo
ZXJlIHRob3NlIGFyZSB1bmFtYmlndW91cyAoQXVzdHJhbGlhKS48L0ZPTlQ+PC9TUEFOPjxTUEFO
IExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIjMDAw
MDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBJdCBpcyBpbmNvbmNlaXZhYmxlIHRoYXQg
YW55IENBIGNvdWxkIGlzc3VlIHN1Y2ggYSBETiB0byBhbm90aGVyIGVudGl0eSBpbiBnb29kIGZh
aXRoLjwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLWF1
Ij48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgRE4gY249PC9G
T05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48
Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj7igJ08L0ZPTlQ+PC9TUEFO
PjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9S
PSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPkpvaG4gU21pdGg8L0ZPTlQ+PC9TUEFOPjxT
UEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIj
MDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPuKAnTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0i
ZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+LCBjPTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwv
U1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNF
PSJBcmlhbCI+4oCdPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFO
IExBTkc9ImVuLWF1Ij48Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5V
UzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1h
dSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+4oCdPC9GT05UPjwv
U1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBD
T0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj48L0ZPTlQ+PC9TUEFOPjxTUEFOIExB
Tkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPiA8Rk9OVCBDT0xPUj0iIzAwMDA4
MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5tYXkgYmUgdW5hbWJpZ3VvdXMgaW4gdGhlIGNvbnRleHQg
b2Y8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4t
YXUiPiA8Rk9OVCBDT0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj5hbjwvRk9OVD48
L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQg
Q09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+IGlzc3VpbmcgQ0EsIGJ1dDwvRk9O
VD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+IDxG
T05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPnc8L0ZPTlQ+PC9TUEFOPjxT
UEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9SPSIj
MDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPm91bGQgYmUgYW1iaWd1b3VzPC9GT05UPjwvU1BB
Tj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij4gPEZPTlQgQ09M
T1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+aW4gYSB3aWRlciBjb250ZXh0PC9GT05U
PjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij4gPEZP
TlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+c28gaXQgc2hvdWxkIG5vdCBi
ZSB1c2VkIGluIGNSTElzc3VlcjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BB
Tj48U1BBTiBMQU5HPSJlbi1hdSI+IDxGT05UIENPTE9SPSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0i
QXJpYWwiPuKAkzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBM
QU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+IHVz
ZSByZmM4MjJOYW1lPTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BB
TiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+
4oCdPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxBIEhSRUY9Im1haWx0
bzpKb2huU21pdGg1NTVAeWFob28uY29tIj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFO
IExBTkc9ImVuLWF1Ij48VT48Rk9OVCBDT0xPUj0iIzAwMDBGRiIgU0laRT0yIEZBQ0U9IkFyaWFs
Ij5Kb2huU21pdGg1NTVAeWFob28uY29tPC9GT05UPjwvVT48L1NQQU4+PFNQQU4gTEFORz0iZW4t
YXUiPjwvU1BBTj48L0E+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1h
dSI+PEZPTlQgQ09MT1I9IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+4oCdPC9GT05UPjwv
U1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PC9TUEFOPjxTUEFOIExBTkc9ImVuLWF1Ij48Rk9OVCBD
T0xPUj0iIzAwMDA4MCIgU0laRT0yIEZBQ0U9IkFyaWFsIj4gaW5zdGVhZDwvRk9OVD48L1NQQU4+
PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48U1BBTiBMQU5HPSJlbi1hdSI+PEZPTlQgQ09MT1I9
IiMwMDAwODAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+LCBmb3IgaW5zdGFuY2U8L0ZPTlQ+PC9TUEFO
PjxTUEFOIExBTkc9ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjxGT05UIENPTE9S
PSIjMDAwMDgwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPi48L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9
ImVuLWF1Ij48L1NQQU4+PFNQQU4gTEFORz0iZW4tYXUiPjwvU1BBTj48L1A+DQoNCjwvQk9EWT4N
CjwvSFRNTD4=

------_=_NextPart_001_01C5970F.0318AEA0--



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 j71HZY2i069857; Mon, 1 Aug 2005 10:35:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71HZYb5069856; Mon, 1 Aug 2005 10:35:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71HZYUS069848 for <[e-mail]>; Mon, 1 Aug 2005 10:35:34 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j71HZVBW012188 for <[e-mail]>; Mon, 1 Aug 2005 13:35:33 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Mon, 1 Aug 2005 13:35:26 -0400
Message-ID: <00cd01c596bf$6af24770$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-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>

David,

I stand corrected.

For what it is worth, X.509 does not seem to have rules for matching issuer
alt name.

Given the syntax of CRL issuer field in CRL DP (General Names), it is
logical that non-DN names will be matched with the issuer alt name.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of David A. Cooper
Sent: Monday, August 01, 2005 12:26 PM
Cc: pkix
Subject: Re: 3280bis: suggested words for ambiguous DNs and delegated CRLs



Santosh,

Actually, the standard DOES require that the name in the cRLIssuer field 
match one of the names in the issuer field of issuerAltName extension of 
the CRL.

In RFC 3280 (and 3280bis), section 6.3.3 step (b)(1) states:

         (1)  If the DP includes cRLIssuer, then verify that the issuer
         field in the complete CRL matches cRLIssuer in the DP and that
         the complete CRL contains an issuing distribution point
         extension with the indirectCRL boolean asserted.  Otherwise,
         verify that the CRL issuer matches the certificate issuer.

It is true that according to section 6.3.3 step (b)(2), if the CRL 
contains an IDP extension with a distribution point name and the 
distribution point in the CDP extension of the certificate includes a 
cRLIssuer field but does not include a distribution point name, then the 
contents of the cRLIssuer field can be compared to the distribution 
point name in the IDP extension in the CRL.  However, this does not 
eliminate the requirement from step (b)(1) to for the issuer field (or 
issuerAltName extension) in the CRL to include a name that matches the 
contents of the cRLIssuer field in the CDP extension.

Dave

Santosh Chokhani wrote:

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Manger, James H
>Sent: Monday, August 01, 2005 3:34 AM
>To: pkix
>Subject: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>Replace the last text paragraph in 4.2.1.13 with the following: "The 
>cRLIssuer field identifies the entity who signs and issues the CRL. Any 
>CRL it selects must include at least one of the names from cRLIssuer in 
>the CRL's issuer field or issuerAltName extension.
>
>[Santosh: This is not a requirement of the standard today.  The 
>standard permits the CRL issuer name to be matched to a DP in the IDP.  
>In retrospect, the standard should have matched CRL issuer from CRL DP 
>to issuer field or issuer alt name field in the CRL and matched DPs 
>from CRL DP and IDP.  That would have been a more appropriate 
>solution.]
>



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 j71GgFik063696; Mon, 1 Aug 2005 09:42:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71GgFLv063695; Mon, 1 Aug 2005 09:42:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71GgEqg063688 for <[e-mail]>; Mon, 1 Aug 2005 09:42:14 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j71GgCP7028408 for <[e-mail]>; Mon, 1 Aug 2005 12:42:12 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j71Gg56u006106 for <[e-mail]>; Mon, 1 Aug 2005 12:42:05 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 01 Aug 2005 12:42:20 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: 3280bis: suggested words for ambiguous DNs and delegated CRLs
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner: Found to be clean
X-NIST-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>

Manger, James H wrote:

>Change 4.2.1.13 "CRL Distribution Points" to allow non-DN names in the cRLIssuer field and to avoid this field when the CRL issuer only works for one CA.  With any luck this could solve the "ambiguous DN in CRL processing" issue, as well as Denis’s "simplified processing for 'delegated CRLs'".  Replace the last text paragraph in 4.2.1.13 with the following:
>
>
>"The cRLIssuer field identifies the entity who signs and issues the CRL.  Any CRL it selects must include at least one of the names from cRLIssuer in the CRL’s issuer field or issuerAltName extension.  The CRL MUST also include an issuingDistributionPoint extension with indirectCRL set to TRUE.
>
>A CRL issuer SHOULD use the same DN as the CA if it will only ever cover certificates from that single CA.  This avoids the need for cRLIssuer values in certificates and, more importantly, avoids the need for the indirectCRL flag and certificateIssuer values in critical extensions in CRLs.  A separate name for the CRL issuer can still be included in a CRL via the issuerAltName extension if desired.
>  
>
I think we need to be careful about saying that this method "SHOULD" be 
used.  While it is interesting to note that one can delegate CRL issuing 
to a different system without the use of indirect CRLs, it may not be 
considered appropriate for the CRL issuer to use the same name as the 
certificate issuer if the two systems are being run by different 
organizations.  Even if there is a decision to point out in 3280bis that 
it is possible to delegate the issuance to CRLs to a different system 
without using indirect CRLs, I think such guidance should go in section 
5 rather than section 4.2.1.13.

>It is important that the cRLIssuer field in a certificate unambiguously identifies a single CRL issuer.  A CA MUST only include names in the cRLIssuer field that are unambiguous within the environment where the certificate may be used, which will often mean cRLIssuer names MUST be globally unambiguous.  A globally unambiguous name, such as a DNS name, MUST be used in cRLIssuer when the CRL issuer’s DN is ambiguous."
>  
>
I have a problem with this paragraph since X.509 requires that ALL names 
be unambiguous.  Including language such as this implies that it is OK 
to use ambiguous names expect in cases such as this.  If a CA or CRL 
issuer can have a DNS name that is globally unambiguous, then it can 
certainly use domainComponent naming to construct a DN is that unambiguous.

Dave



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 j71GQGIo062222; Mon, 1 Aug 2005 09:26:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71GQGnN062221; Mon, 1 Aug 2005 09:26:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71GQG3S062215 for <[e-mail]>; Mon, 1 Aug 2005 09:26:16 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j71GQCX3019755 for <[e-mail]>; Mon, 1 Aug 2005 12:26:13 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j71GPT6u029527 for <[e-mail]>; Mon, 1 Aug 2005 12:25:30 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 01 Aug 2005 12:25:45 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: pkix <[e-mail]>
Subject: Re: 3280bis: suggested words for ambiguous DNs and delegated CRLs
References: <004001c596a7$f488ad70$[e-mail]>
In-Reply-To: <004001c596a7$f488ad70$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-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>

Santosh,

Actually, the standard DOES require that the name in the cRLIssuer field 
match one of the names in the issuer field of issuerAltName extension of 
the CRL.

In RFC 3280 (and 3280bis), section 6.3.3 step (b)(1) states:

         (1)  If the DP includes cRLIssuer, then verify that the issuer
         field in the complete CRL matches cRLIssuer in the DP and that
         the complete CRL contains an issuing distribution point
         extension with the indirectCRL boolean asserted.  Otherwise,
         verify that the CRL issuer matches the certificate issuer.

It is true that according to section 6.3.3 step (b)(2), if the CRL 
contains an IDP extension with a distribution point name and the 
distribution point in the CDP extension of the certificate includes a 
cRLIssuer field but does not include a distribution point name, then the 
contents of the cRLIssuer field can be compared to the distribution 
point name in the IDP extension in the CRL.  However, this does not 
eliminate the requirement from step (b)(1) to for the issuer field (or 
issuerAltName extension) in the CRL to include a name that matches the 
contents of the cRLIssuer field in the CDP extension.

Dave

Santosh Chokhani wrote:

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Manger, James H
>Sent: Monday, August 01, 2005 3:34 AM
>To: pkix
>Subject: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>Replace the last text paragraph in 4.2.1.13 with the following:
>"The cRLIssuer field identifies the entity who signs and issues the CRL.
>Any CRL it selects must include at least one of the names from cRLIssuer in
>the CRL's issuer field or issuerAltName extension.
>
>[Santosh: This is not a requirement of the standard today.  The standard
>permits the CRL issuer name to be matched to a DP in the IDP.  In
>retrospect, the standard should have matched CRL issuer from CRL DP to
>issuer field or issuer alt name field in the CRL and matched DPs from CRL DP
>and IDP.  That would have been a more appropriate solution.]
>



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 j71Elc9W052704; Mon, 1 Aug 2005 07:47:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71ElcWI052703; Mon, 1 Aug 2005 07:47:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71Elb5p052697 for <[e-mail]>; Mon, 1 Aug 2005 07:47:37 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j71ElYBW008983 for <[e-mail]>; Mon, 1 Aug 2005 10:47:36 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Mon, 1 Aug 2005 10:47:29 -0400
Message-ID: <004001c596a7$f488ad70$[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.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j71Elb5p052698
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>

James Manger,

See responses in-line under [Santosh:]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Manger, James H
Sent: Monday, August 01, 2005 3:34 AM
To: pkix
Subject: 3280bis: suggested words for ambiguous DNs and delegated CRLs

Change 4.2.1.13 "CRL Distribution Points" to allow non-DN names in the
cRLIssuer field and to avoid this field when the CRL issuer only works for
one CA.

[Santosh: The syntax has always allowed non-DN names.  In terms of avoiding
this field, the standard requires that if the Issuer field in the CRL is not
the same as the Issuer field in the certificate, the certificate issuing CA
assert the CRL Issuer in the CRL DP.  Not doing this can lead to any one
acting as a revocation authority for a CA and that would be bad.]

With any luck this could solve the "ambiguous DN in CRL processing" issue,
as well as Denis's "simplified processing for 'delegated CRLs'".

[Santosh: Having multiple names in the CRL issuer field of CRL DP and
checking them all might reduce the chances of name collision, if that is
what you mean.]

Replace the last text paragraph in 4.2.1.13 with the following:
"The cRLIssuer field identifies the entity who signs and issues the CRL.
Any CRL it selects must include at least one of the names from cRLIssuer in
the CRL's issuer field or issuerAltName extension.

[Santosh: This is not a requirement of the standard today.  The standard
permits the CRL issuer name to be matched to a DP in the IDP.  In
retrospect, the standard should have matched CRL issuer from CRL DP to
issuer field or issuer alt name field in the CRL and matched DPs from CRL DP
and IDP.  That would have been a more appropriate solution.]

The CRL MUST also include an issuingDistributionPoint extension with
indirectCRL set to TRUE.

A CRL issuer SHOULD use the same DN as the CA if it will only ever cover
certificates from that single CA.

[Santosh: This by definition is not an indirect CRL.  This is the case where
the CA is using a different key to sign the CRL.]

This avoids the need for cRLIssuer values in certificates and, more
importantly, avoids the need for the indirectCRL flag and certificateIssuer
values in critical extensions in CRLs.  A separate name for the CRL issuer
can still be included in a CRL via the issuerAltName extension if desired.

[Santosh: While I can support a change in the standard to match CRL issuer
in CRL DP to issuer or issuer alt name in CRL and match the DPs, I do not
want another authority to assert the issuer field in a name and assert its
name in the alt name.]

It is important that the cRLIssuer field in a certificate unambiguously
identifies a single CRL issuer.  A CA MUST only include names in the
cRLIssuer field that are unambiguous within the environment where the
certificate may be used, which will often mean cRLIssuer names MUST be
globally unambiguous.  A globally unambiguous name, such as a DNS name, MUST
be used in cRLIssuer when the CRL issuer's DN is ambiguous."

[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the
trust anchors environment of the relying parties to know if the CRL issuer
DN will be unambiguous.]

(There are probably some parts of the CRL processing text that need to
change to match this text.)




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 j717bvbJ009439; Mon, 1 Aug 2005 00:37:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j717bvvM009438; Mon, 1 Aug 2005 00:37:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j717bubb009422 for <[e-mail]>; Mon, 1 Aug 2005 00:37:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id E9A9B257FC for <[e-mail]>; Mon,  1 Aug 2005 17:37:54 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 8AE2D1DA81 for <[e-mail]>; Mon,  1 Aug 2005 17:37:54 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA19335 for <[e-mail]>; Mon, 1 Aug 2005 17:37:54 +1000 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Mon, 1 Aug 2005 17:34:07 +1000
Message-ID: <[e-mail]>
Thread-Topic: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Thread-Index: AcWOAMGfO1zobKO0R76z+h7EPd2VuwAUanEgAgRUHSA=
From: "Manger, James H" <[e-mail]>
To: "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j717bubb009431
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>

Change 4.2.1.13 "CRL Distribution Points" to allow non-DN names in the cRLIssuer field and to avoid this field when the CRL issuer only works for one CA.  With any luck this could solve the "ambiguous DN in CRL processing" issue, as well as Denis’s "simplified processing for 'delegated CRLs'".  Replace the last text paragraph in 4.2.1.13 with the following:


"The cRLIssuer field identifies the entity who signs and issues the CRL.  Any CRL it selects must include at least one of the names from cRLIssuer in the CRL’s issuer field or issuerAltName extension.  The CRL MUST also include an issuingDistributionPoint extension with indirectCRL set to TRUE.

A CRL issuer SHOULD use the same DN as the CA if it will only ever cover certificates from that single CA.  This avoids the need for cRLIssuer values in certificates and, more importantly, avoids the need for the indirectCRL flag and certificateIssuer values in critical extensions in CRLs.  A separate name for the CRL issuer can still be included in a CRL via the issuerAltName extension if desired.

It is important that the cRLIssuer field in a certificate unambiguously identifies a single CRL issuer.  A CA MUST only include names in the cRLIssuer field that are unambiguous within the environment where the certificate may be used, which will often mean cRLIssuer names MUST be globally unambiguous.  A globally unambiguous name, such as a DNS name, MUST be used in cRLIssuer when the CRL issuer’s DN is ambiguous."


(There are probably some parts of the CRL processing text that need to change to match this text.)