Re: Attribute Certificate for IP address allocation object

["Housley, Russ" <[e-mail]>]

Sanjaya:

This seems like a straightforward application of 
draft-ietf-pkix-ac509prof-09.txt.

Russ


At 11:49 AM 12/31/2001 +1000, Sanjaya wrote:

>Hi,
>We are investigating the use of Attribute Certificate for IP address
>allocation object. The idea is to bind the right to use certain IP blocks
>to the organization that receives the allocation from an IP registry
>(e.g APNIC/ARIN/RIPE). This certificate can be validated by
>the service provider before inserting the block into the routing table.
>
>Is this topic within the scope of PKIX working group? Appreciate
>any advise. Thanks!
>
>Happy New Year 2001!
>Sanjaya
>Senior Project Manager
>APNIC (http://www.apnic.net)




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBVE17701548 for ietf-pkix-bks; Mon, 31 Dec 2001 06:01:07 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBVE15301544 for <[e-mail]>; Mon, 31 Dec 2001 06:01:05 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Dec 2001 14:00:48 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA09500 for <[e-mail]>; Mon, 31 Dec 2001 09:01:05 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBVE14A18513 for <[e-mail]>; Mon, 31 Dec 2001 09:01:04 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NC2F2>; Mon, 31 Dec 2001 09:01:03 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.108]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NC2FG; Mon, 31 Dec 2001 09:00:59 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Sanjaya <[e-mail]>
Cc: [e-mail]
Subject: Re: Attribute Certificate for IP address allocation object
Date: Mon, 31 Dec 2001 09:00:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>
List-ID: <ietf-pkix.imc.org>

Sanjaya:

This seems like a straightforward application of 
draft-ietf-pkix-ac509prof-09.txt.

Russ


At 11:49 AM 12/31/2001 +1000, Sanjaya wrote:

>Hi,
>We are investigating the use of Attribute Certificate for IP address
>allocation object. The idea is to bind the right to use certain IP blocks
>to the organization that receives the allocation from an IP registry
>(e.g APNIC/ARIN/RIPE). This certificate can be validated by
>the service provider before inserting the block into the routing table.
>
>Is this topic within the scope of PKIX working group? Appreciate
>any advise. Thanks!
>
>Happy New Year 2001!
>Sanjaya
>Senior Project Manager
>APNIC (http://www.apnic.net)




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBV1nCH11099 for ietf-pkix-bks; Sun, 30 Dec 2001 17:49:12 -0800 (PST)
Received: from cumin.apnic.net (cumin.apnic.net [202.12.29.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBV1n9311095 for <[e-mail]>; Sun, 30 Dec 2001 17:49:10 -0800 (PST)
Received: from SANJAYA (as-sanjaya.apnic.net [202.12.29.217]) by cumin.apnic.net (8.12.1/8.12.1) with SMTP id fBV1j5Tl009410 for <[e-mail]>; Mon, 31 Dec 2001 11:45:05 +1000
Message-ID: <013a01c1919d$61c3f610$d91d0cca@SANJAYA>
From: "Sanjaya" <[e-mail]>
To: <[e-mail]>
Subject: Attribute Certificate for IP address allocation object
Date: Mon, 31 Dec 2001 11:49:26 +1000
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi,
We are investigating the use of Attribute Certificate for IP address
allocation object. The idea is to bind the right to use certain IP blocks
to the organization that receives the allocation from an IP registry
(e.g APNIC/ARIN/RIPE). This certificate can be validated by
the service provider before inserting the block into the routing table.

Is this topic within the scope of PKIX working group? Appreciate
any advise. Thanks!

Happy New Year 2001!
Sanjaya
Senior Project Manager
APNIC (http://www.apnic.net)



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRFxR928460 for ietf-pkix-bks; Thu, 27 Dec 2001 07:59:27 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBRFxN228443 for <[e-mail]>; Thu, 27 Dec 2001 07:59:23 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Dec 2001 15:59:09 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA07690 for <[e-mail]>; Thu, 27 Dec 2001 10:59:24 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBRFxNR20244 for <[e-mail]>; Thu, 27 Dec 2001 10:59:23 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NBR0L>; Thu, 27 Dec 2001 10:59:22 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.34]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NBR0H; Thu, 27 Dec 2001 10:59:17 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: XKMS
Date: Thu, 27 Dec 2001 10:57:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>
List-ID: <ietf-pkix.imc.org>

I am not sure why your question is in a message with this subject.

Please take a look at RFC 2630.  If this does not answer your questions, 
please post specific questions to the S/MIME WG mail list
([e-mail]).

Russ

At 04:19 PM 12/27/2001 +0530, [e-mail] wrote:

>Hi All!
>         Merry Christmas and a very happy new year ...
>         Can any one tell me what is counter signature and how can I verify
a
>counter signature
>         Pkcs#9 standard says that the counter signature is an pkcs#9
>attribute and the structure is like signer info of pkcs#7 then what is the
>difference.
>The standard also tells that counter signature is a signature on the
>encrypted hash...
>"Encrypted hash " of what???? If it is of original data then which key is
>used for the encryption.
>If there are more than 1 signer infos and then I perform the counter
>signature then how is counter signature made.
>
>Thanks in advance.
>Regards
>Tarun
>
>
>  -----Original Message-----
>From:   Denis Pinkas [mailto:[e-mail]]
>Sent:   Friday, November 30, 2001 10:43 PM
>To:     Hallam-Baker, Phillip
>Cc:     [e-mail]
>Subject:        Re: XKMS
>
>
>Phill,
>
>I noticed that my original question is still not answered:
>
>Does XKMS make a difference between the name of an entity
>certified by CA1 and the same name certified by CA2 ?
>
>Would you be able to answer it ?
>
> > To tie the issue back to the DPD/DPV issue which is probably your
>immediate
> > interest:
> >
> > 1) In the XKMS model the client is not 'in normal circumstances' going
to
>be
> > defining and configuring the trust model, that is the job for the
server.
>
>In the DPV model, this may be pre-defined at the server or set-up by a
>client, but not an ordinary client, an administrator acting as a client. So
>there is no major difference on that aspect.
>
> > 2) The XKMS client may select between different trust models by
accessing
> > different XKMS services, possibly different ports on the same service.
> >
> >         [This has lead to the understanding that the XKMS request and
> > response should contain the authenticated port URI to prevent
substitution
> > attacks].
>
>This means that a model can be selected via a reference, e.g. an OID or a
>URI.
>
> > 3) If it was decided to support client definition (as opposed to
>selection)
> > of the trust model there would be an additional set of services to
support
> > that use. These services would fall within the 'tier 3' of the original
>TAXI
> > (Trust Assertion XML Infrastructure) model, i.e. something that would
not
>be
> > supported by the average client application.
>
>This is the optional Policy definition protocol (PDP) defined in section
10.
>
> > I can certainly see a role in which XKMS and DPD/DPV would interoperate.
>In
> > particular the case of an XKMS gateway which recieves XKMS requests from
> > lightweight clients, applies local, (possibly proprietary) set of rules
>and
> > fires off OCSP, DPD/DPV, LDAP requests as appropriate.
>
>The only problem is the matter of transitive trust, since when transposing
>one protocol into another, all the security (in particular the digital
>signature) is lost at the gateway.
>
>Denis
>
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > [e-mail]
> > 781 245 6996 x227
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Friday, November 30, 2001 7:03 AM
> > > To: Hallam-Baker, Phillip
> > > Cc: [e-mail]
> > > Subject: Re: XKMS
> > >
> > >
> > > Phill,
> > >
> > > Thank you for your e-mail. Your response leads to the
> > > following question:
> > >
> > > Can a user select/ specify the trust model to be used ? If yes, how ?
> > >
> > > A reply to the question raised in my previous e-mail would still
> > > be interresting:
> > >
> > > Does XKMS make a difference between the name of an entity
> > > certified by CA1 and the same name certified by CA2 ?
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > >
> > > > All,
> > > >
> > > >         The Working Group is currently working on a version
> > > 2.0 of the XKMS
> > > > spec. It is (currently) functionally and structurally
> > > identical to 1.1 but
> > > > has a number of important revisions to the schema. These
> > > align the schema
> > > > more closely with the new XML Signature schema and SAML and
> > > make for much
> > > > better extensibility. The other major change is to the
> > > structure of the
> > > > Register function which previously combined 4 functions
> > > that are now broken
> > > > out into separate calls.
> > > >
> > > >         To answer Denis' point, XKMS does not define a
> > > trust model, the XKMS
> > > > service defines its own trust model. The client is
> > > delegating the definition
> > > > and concept of trust, not merely the mechanics of
> > > processing the trust.
> > > >
> > > >         This has lead to debate over whether XKMS should
> > > support multiple
> > > > trust models, so that the client could choose between them.
> > > At present this
> > > > is possible by introducing multiple XKMS service point URLs, e.g.
> > > >
> > > >         http://xkms.xmltrustcenter.org/vtn_class_1
> > > >         http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential
> > > >         http://xkms.xmltrustcenter.org/us_gov_bridge_ca_classified
> > > >         http://xkms.xmltrustcenter.org/bal_keyserver
> > > >
> > > >         Philosophically, the reason for taking this
> > > approach is that real
> > > > world trust relationships tend to turn out to be slightly
> > > more complex than
> > > > whatever closed form declarative mechanism is available to
> > > describe them -
> > > > until the closed form becomes turing complete.
> > > >
> > > >         It is a separation of concerns issue, by avoiding
> > > any commitment on
> > > > the issue XKMS can support trust models that would probably
> > > be impossible to
> > > > specify completely in a standards forum - providing a
> > > bridge CA across the
> > > > VTN, the federal Bridge CA and BAL's PGP keyserver for
> > > example. While a
> > > > perfectly good and usefull trust service could easily be
> > > configured for
> > > > limited purposes any attempt to completely specify how to
> > > interoperate PGP
> > > > and PKIX for all applications, cert issuers etc. is
> > > probably a futile task.
> > > >
> > > >         As Steve said, this is the sort of issue we will be
> > > debating on the
> > > > WG list.
> > > >
> > > >                 Phill
> > > >
> > > > Phillip Hallam-Baker FBCS C.Eng.
> > > > Principal Scientist
> > > > VeriSign Inc.
> > > > [e-mail]
> > > > 781 245 6996 x227
> > > >
> > > > > -----Original Message-----
> > > > > From: Denis Pinkas [mailto:[e-mail]]
> > > > > Sent: Thursday, November 22, 2001 4:59 AM
> > > > > To: Hallam-Baker, Phillip
> > > > > Cc: [e-mail]
> > > > > Subject: Re: XKMS
> > > > >
> > > > >
> > > > > Phill,
> > > > >
> > > > > I have XKMS Draft Version 1.1 draft 4. January 30 th, 2001.
> > > > >
> > > > > Since the document advertises at a bottom of a page an amendment
> > > > > for a version 1.2, is there a more recent document available ?
> > > > >
> > > > > Is there a document that explains in a few pages the philosophy
> > > > > besides XKMS in particular in terms of the trust model when
> > > > > multiple trust points are used (i.e. multiple self-signed
> > > > > certificates) ?
> > > > >
> > > > > Here is a related question: Does XKMS make a difference
> > > > > between the name
> > > > > of an entity certified by CA1 and the same name certified by CA2 ?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Denis
> > > > >
> > > > > > > Now I don't think that the folks working on XML-DSIG
> > > and XKMS are
> > > > > > > really doing it better. There's also the tendency to be most
> > > > > > > flexible by integrating as many PKI standards as
> > > > > possible. Same old
> > > > > > > problems...
> > > > > >
> > > > > > I think you are misunderstanding what we are doing. XKMS is an
> > > > > > interface to a PKI. It is not by itself a PKI.
> > > > > >
> > > > > > Although it is quite possible to use XKMS in a network
> > > of peer-peer
> > > > > > real time responders without the support of a backing
> > > PKI the more
> > > > > > usual configuration would be as an interface to a PKI.
> > > In most cases
> > > > > > that PKI would be PKIX based.
> > > > > >
> > > > > > The observations that the design of XKMS is based upon are:
> > > > > >
> > > > > > 1) Despite every effort, most developers hate, loathe and
> > > > > detest ASN.1
> > > > > > 2) Client developers complain that PKIX is too complex
> > > to implement.
> > > > > > 3) We continue to add to the PKIX specification.
> > > > > > 4) Implementation suggests that inter-organizational trust
> > > > > justifies the
> > > > > >         complexity of PKIX.
> > > > > > 5) XML based applications have a different risk profile
> > > to the email
> > > > > >         messaging applications that X.509 was
> > > originally intended to
> > > > > >         support.
> > > > > >
> > > > > > The point is that we have come a long way in 10 years
> > > and there are
> > > > > > occasions when the thing to do is to attack a problem from
> > > > > a different
> > > > > > angle for a while. I find it very unhelpful for people to start
> > > > > > throwing arround the 'do you think you know better' question.
> > > > > > Clearly the people who put that question think they know better
> > > > > > or they would not have asked it.
> > > > > >
> > > > > > Anyway, the proposal to form an XKMS working group is currently
> > > > > > before the W3C AC reps. The first face to face is
> > > planned for 8th
> > > > > > December in Salt Lake city. It is an open meeting.
> > > > > >
> > > > > >         Phill
> > > > >
> > >
>---------------------------------------------------------------------------
-
>
>This message contains privileged and confidential information and is
>intended only for the individual named. If you are not the intended
>recipient you should not disseminate, distribute, store, print, copy or
>deliver this message. Please notify the sender immediately by e-mail if you
>have received this e-mail by mistake and immediately delete this e-mail
from
>your system.
>
>
>E-mail transmission cannot be guaranteed to be secure or error-free as
>information could be intercepted, corrupted, lost, destroyed, arrive late
or
>incomplete, or contain viruses. The sender therefore does not accept
>liability for any errors or omissions in the contents of this message which
>arise as a result of e-mail transmission.  If verification is required
>please request a hard-copy version.
>
>
>--------------------------------------------------------------------------




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRAm8m06166 for ietf-pkix-bks; Thu, 27 Dec 2001 02:48:08 -0800 (PST)
Received: from email.iflexsolutions.com (lan-202-144-33-235.maa.sify.net [202.144.33.235] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBRAm5206156 for <[e-mail]>; Thu, 27 Dec 2001 02:48:05 -0800 (PST)
Received: from pppserver.iflexsolutions.com (pppserver [192.168.50.2]) by email.iflexsolutions.com (8.11.0/8.11.0) with ESMTP id fBRLKlb06150; Thu, 27 Dec 2001 16:20:49 -0500 (GMT)
Received: by FMG-NT with Internet Mail Service (5.5.2653.19) id <ZW35WTQJ>; Thu, 27 Dec 2001 16:21:01 +0530
Message-ID: <6EA3A69FF9F9D51191EE0002554AF1851582@FMG-PUNE>
From: [e-mail]
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: XKMS
Date: Thu, 27 Dec 2001 16:19:56 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>
List-ID: <ietf-pkix.imc.org>

Hi All!
	Merry Christmas and a very happy new year ...
	Can any one tell me what is counter signature and how can I verify a
counter signature
	Pkcs#9 standard says that the counter signature is an pkcs#9
attribute and the structure is like signer info of pkcs#7 then what is the
difference.
The standard also tells that counter signature is a signature on the
encrypted hash...
"Encrypted hash " of what???? If it is of original data then which key is
used for the encryption.
If there are more than 1 signer infos and then I perform the counter
signature then how is counter signature made.

Thanks in advance.
Regards
Tarun 


 -----Original Message-----
From: 	Denis Pinkas [mailto:[e-mail]] 
Sent:	Friday, November 30, 2001 10:43 PM
To:	Hallam-Baker, Phillip
Cc:	[e-mail]
Subject:	Re: XKMS


Phill,

I noticed that my original question is still not answered:

Does XKMS make a difference between the name of an entity
certified by CA1 and the same name certified by CA2 ?

Would you be able to answer it ?

> To tie the issue back to the DPD/DPV issue which is probably your
immediate
> interest:
> 
> 1) In the XKMS model the client is not 'in normal circumstances' going to
be
> defining and configuring the trust model, that is the job for the server.

In the DPV model, this may be pre-defined at the server or set-up by a
client, but not an ordinary client, an administrator acting as a client. So
there is no major difference on that aspect.
 
> 2) The XKMS client may select between different trust models by accessing
> different XKMS services, possibly different ports on the same service.
> 
>         [This has lead to the understanding that the XKMS request and
> response should contain the authenticated port URI to prevent substitution
> attacks].

This means that a model can be selected via a reference, e.g. an OID or a
URI.
 
> 3) If it was decided to support client definition (as opposed to
selection)
> of the trust model there would be an additional set of services to support
> that use. These services would fall within the 'tier 3' of the original
TAXI
> (Trust Assertion XML Infrastructure) model, i.e. something that would not
be
> supported by the average client application.

This is the optional Policy definition protocol (PDP) defined in section 10.

> I can certainly see a role in which XKMS and DPD/DPV would interoperate.
In
> particular the case of an XKMS gateway which recieves XKMS requests from
> lightweight clients, applies local, (possibly proprietary) set of rules
and
> fires off OCSP, DPD/DPV, LDAP requests as appropriate.

The only problem is the matter of transitive trust, since when transposing
one protocol into another, all the security (in particular the digital
signature) is lost at the gateway.

Denis

> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> [e-mail]
> 781 245 6996 x227
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Friday, November 30, 2001 7:03 AM
> > To: Hallam-Baker, Phillip
> > Cc: [e-mail]
> > Subject: Re: XKMS
> >
> >
> > Phill,
> >
> > Thank you for your e-mail. Your response leads to the
> > following question:
> >
> > Can a user select/ specify the trust model to be used ? If yes, how ?
> >
> > A reply to the question raised in my previous e-mail would still
> > be interresting:
> >
> > Does XKMS make a difference between the name of an entity
> > certified by CA1 and the same name certified by CA2 ?
> >
> > Regards,
> >
> > Denis
> >
> >
> > > All,
> > >
> > >         The Working Group is currently working on a version
> > 2.0 of the XKMS
> > > spec. It is (currently) functionally and structurally
> > identical to 1.1 but
> > > has a number of important revisions to the schema. These
> > align the schema
> > > more closely with the new XML Signature schema and SAML and
> > make for much
> > > better extensibility. The other major change is to the
> > structure of the
> > > Register function which previously combined 4 functions
> > that are now broken
> > > out into separate calls.
> > >
> > >         To answer Denis' point, XKMS does not define a
> > trust model, the XKMS
> > > service defines its own trust model. The client is
> > delegating the definition
> > > and concept of trust, not merely the mechanics of
> > processing the trust.
> > >
> > >         This has lead to debate over whether XKMS should
> > support multiple
> > > trust models, so that the client could choose between them.
> > At present this
> > > is possible by introducing multiple XKMS service point URLs, e.g.
> > >
> > >         http://xkms.xmltrustcenter.org/vtn_class_1
> > >         http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential
> > >         http://xkms.xmltrustcenter.org/us_gov_bridge_ca_classified
> > >         http://xkms.xmltrustcenter.org/bal_keyserver
> > >
> > >         Philosophically, the reason for taking this
> > approach is that real
> > > world trust relationships tend to turn out to be slightly
> > more complex than
> > > whatever closed form declarative mechanism is available to
> > describe them -
> > > until the closed form becomes turing complete.
> > >
> > >         It is a separation of concerns issue, by avoiding
> > any commitment on
> > > the issue XKMS can support trust models that would probably
> > be impossible to
> > > specify completely in a standards forum - providing a
> > bridge CA across the
> > > VTN, the federal Bridge CA and BAL's PGP keyserver for
> > example. While a
> > > perfectly good and usefull trust service could easily be
> > configured for
> > > limited purposes any attempt to completely specify how to
> > interoperate PGP
> > > and PKIX for all applications, cert issuers etc. is
> > probably a futile task.
> > >
> > >         As Steve said, this is the sort of issue we will be
> > debating on the
> > > WG list.
> > >
> > >                 Phill
> > >
> > > Phillip Hallam-Baker FBCS C.Eng.
> > > Principal Scientist
> > > VeriSign Inc.
> > > [e-mail]
> > > 781 245 6996 x227
> > >
> > > > -----Original Message-----
> > > > From: Denis Pinkas [mailto:[e-mail]]
> > > > Sent: Thursday, November 22, 2001 4:59 AM
> > > > To: Hallam-Baker, Phillip
> > > > Cc: [e-mail]
> > > > Subject: Re: XKMS
> > > >
> > > >
> > > > Phill,
> > > >
> > > > I have XKMS Draft Version 1.1 draft 4. January 30 th, 2001.
> > > >
> > > > Since the document advertises at a bottom of a page an amendment
> > > > for a version 1.2, is there a more recent document available ?
> > > >
> > > > Is there a document that explains in a few pages the philosophy
> > > > besides XKMS in particular in terms of the trust model when
> > > > multiple trust points are used (i.e. multiple self-signed
> > > > certificates) ?
> > > >
> > > > Here is a related question: Does XKMS make a difference
> > > > between the name
> > > > of an entity certified by CA1 and the same name certified by CA2 ?
> > > >
> > > > Thanks.
> > > >
> > > > Denis
> > > >
> > > > > > Now I don't think that the folks working on XML-DSIG
> > and XKMS are
> > > > > > really doing it better. There's also the tendency to be most
> > > > > > flexible by integrating as many PKI standards as
> > > > possible. Same old
> > > > > > problems...
> > > > >
> > > > > I think you are misunderstanding what we are doing. XKMS is an
> > > > > interface to a PKI. It is not by itself a PKI.
> > > > >
> > > > > Although it is quite possible to use XKMS in a network
> > of peer-peer
> > > > > real time responders without the support of a backing
> > PKI the more
> > > > > usual configuration would be as an interface to a PKI.
> > In most cases
> > > > > that PKI would be PKIX based.
> > > > >
> > > > > The observations that the design of XKMS is based upon are:
> > > > >
> > > > > 1) Despite every effort, most developers hate, loathe and
> > > > detest ASN.1
> > > > > 2) Client developers complain that PKIX is too complex
> > to implement.
> > > > > 3) We continue to add to the PKIX specification.
> > > > > 4) Implementation suggests that inter-organizational trust
> > > > justifies the
> > > > >         complexity of PKIX.
> > > > > 5) XML based applications have a different risk profile
> > to the email
> > > > >         messaging applications that X.509 was
> > originally intended to
> > > > >         support.
> > > > >
> > > > > The point is that we have come a long way in 10 years
> > and there are
> > > > > occasions when the thing to do is to attack a problem from
> > > > a different
> > > > > angle for a while. I find it very unhelpful for people to start
> > > > > throwing arround the 'do you think you know better' question.
> > > > > Clearly the people who put that question think they know better
> > > > > or they would not have asked it.
> > > > >
> > > > > Anyway, the proposal to form an XKMS working group is currently
> > > > > before the W3C AC reps. The first face to face is
> > planned for 8th
> > > > > December in Salt Lake city. It is an open meeting.
> > > > >
> > > > >         Phill
> > > >
> >
----------------------------------------------------------------------------

This message contains privileged and confidential information and is
intended only for the individual named. If you are not the intended
recipient you should not disseminate, distribute, store, print, copy or
deliver this message. Please notify the sender immediately by e-mail if you
have received this e-mail by mistake and immediately delete this e-mail from
your system.


E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. The sender therefore does not accept
liability for any errors or omissions in the contents of this message which
arise as a result of e-mail transmission.  If verification is required
please request a hard-copy version.


--------------------------------------------------------------------------


Received: by above.proper.com (8.11.6/8.11.3) id fBKJegs20776 for ietf-pkix-bks; Thu, 20 Dec 2001 11:40:42 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBKJee220772 for <[e-mail]>; Thu, 20 Dec 2001 11:40:41 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Dec 2001 19:40:30 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA18966 for <[e-mail]>; Thu, 20 Dec 2001 14:40:42 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBKJefb12977 for <[e-mail]>; Thu, 20 Dec 2001 14:40:41 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NA281>; Thu, 20 Dec 2001 14:40:41 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.105]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NA28B; Thu, 20 Dec 2001 14:40:36 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "Di Sivo ing. Francesco" <[e-mail]>
Cc: [e-mail]
Subject: Re: pkcs #6
Date: Thu, 20 Dec 2001 14:19:58 -0500
Importance: high
X-Priority: 1
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 fBKJef220773
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>
List-ID: <ietf-pkix.imc.org>

PKCS#6 was developed prior to the X.509 v3 certificate 
specification.  PKCS#6 remains available for historical reasons.  X.509 v3 
certificates should be used on lieu of PKCS#6 extended certificates.

Russ

At 04:22 PM 12/20/2001 +0100, Di Sivo ing. Francesco wrote:

>Hi to all,
>can someone resolve his question: on the RSA site there is on-line the
>version 1.5 of the pkcs#6: Extended certificate but in the RFC 2630 :
>cryptographic message syntax the pkcs#6 certificate is marked as obsolete.
>What is the situation? Why RSA does not say anything about this question?
>Thank to all.
>
>francesco di sivo
>security engineer
>università degli studi di napoli - federico II
>via claudio 5
>napoli - italia
>[e-mail]




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: by above.proper.com (8.11.6/8.11.3) id fBKHZZ915001 for ietf-pkix-bks; Thu, 20 Dec 2001 09:35:35 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKHZY214992 for <[e-mail]>; Thu, 20 Dec 2001 09:35:34 -0800 (PST)
Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id JAA26796; Thu, 20 Dec 2001 09:35:33 -0800 (PST)
Message-Id: <[e-mail]>
X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net
To: "Housley, Russ" <[e-mail]>
cc: [e-mail]
Reply-to: [e-mail]
Subject: Re: Name constraints 
In-reply-to: Your message of "Thu, 20 Dec 2001 10:14:00 EST." <[e-mail]> 
Date: Thu, 20 Dec 2001 09:35:33 -0800
From: Michael Helm <[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>
List-ID: <ietf-pkix.imc.org>

"Housley, Russ" writes:
> Part of the slow implementation may be related to the fact that CAs are not 
> required to support name constraints.  I think that this is appropriate 

Curiously, the ca software I was using for this test is from one 
of those browser implementors.  Support decisions are
probably done on completely different bases!

> Son-of-2459 continues to include name constraints.    It says:
> 
>     At a minimum, applications conforming to this profile MUST recognize
>     4.2.1.7), basic constraints (section 4.2.1.10), name constraints
>     (section 4.2.1.11), policy constraints (section 4.2.1.12), extended

It does seem to be safe to say that at least some of the browser
revs can't meet this profile spec.


Received: by above.proper.com (8.11.6/8.11.3) id fBKGGab11591 for ietf-pkix-bks; Thu, 20 Dec 2001 08:16:36 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKGGZ211587 for <[e-mail]>; Thu, 20 Dec 2001 08:16:35 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10987; Thu, 20 Dec 2001 11:16:33 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc2511bis-04.txt
Date: Thu, 20 Dec 2001 11:16:33 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Request Message Format (CRMF)
	Author(s)	: M. Myers, C. Adams, D. Solo, D. Kemp
	Filename	: draft-ietf-pkix-rfc2511bis-04.txt
	Pages		: 25
	Date		: 17-Dec-01
	
This document describes the Certificate Request Message Format
(CRMF).  This syntax is used to convey a request for a certificate to
a Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKGGWD11581 for ietf-pkix-bks; Thu, 20 Dec 2001 08:16:32 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKGGU211574 for <[e-mail]>; Thu, 20 Dec 2001 08:16:31 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10973; Thu, 20 Dec 2001 11:16:28 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc2510bis-06.txt
Date: Thu, 20 Dec 2001 11:16:28 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-rfc2510bis-06.txt
	Pages		: 92
	Date		: 17-Dec-01
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.
Note that 'certificate' in this document refers to an X.509v3
Certificate as defined in [COR95, X509-AM].

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2510bis-06.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-rfc2510bis-06.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-rfc2510bis-06.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKFEfv04671 for ietf-pkix-bks; Thu, 20 Dec 2001 07:14:41 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBKFEd204667 for <[e-mail]>; Thu, 20 Dec 2001 07:14:39 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Dec 2001 15:14:28 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA23827 for <[e-mail]>; Thu, 20 Dec 2001 10:14:40 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBKFEdI14247 for <[e-mail]>; Thu, 20 Dec 2001 10:14:39 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NA1HT>; Thu, 20 Dec 2001 10:14:38 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.65]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NA1HS; Thu, 20 Dec 2001 10:14:33 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Name constraints
Date: Thu, 20 Dec 2001 10:14:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>
List-ID: <ietf-pkix.imc.org>

No, the name constraints extension is not dead.  There are several 
environments that need it.  I have heard from other people frustration 
about the lack of support it browsers.

Son-of-2459 continues to include name constraints.    It says:

    Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
    4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
    4.2.1.3), and certificate policies (section 4.2.1.5) extensions.  If
    the CA issues certificates with an empty sequence for the subject
    field, the CA MUST support the subject alternative name extension
    (section 4.2.1.7).  Support for the remaining extensions is OPTIONAL.
    Conforming CAs MAY support extensions that are not identified within
    this specification; certificate issuers are cautioned that marking
    such extensions as critical may inhibit interoperability.

    At a minimum, applications conforming to this profile MUST recognize
    the following extensions: key usage (section 4.2.1.3), certificate
    policies (section 4.2.1.5), the subject alternative name (section
    4.2.1.7), basic constraints (section 4.2.1.10), name constraints
    (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
    key usage (section 4.2.1.13), and inhibit any-policy (section
    4.2.1.15).

    In addition, applications conforming to this profile SHOULD recognize
    the authority and subject key identifier (sections 4.2.1.1 and
    4.2.1.2), and policy mapping (section 4.2.1.6) extensions.

Part of the slow implementation may be related to the fact that CAs are not 
required to support name constraints.  I think that this is appropriate 
because some environments do not need name constraints, but other 
environments do.

Russ


At 12:44 PM 12/19/2001 -0800, Michael Helm wrote:

>... or the lack of support for them (rfc 2459 4.2.1.11)
>
>I recently "had occasion" to try out name contraints and
>their support in various revisions of the popular web
>browsers, and results are certainly disappointing.
>
>Let "NC" stand for some text along the lines of, "a certificate
>that chains to a CA signing certificate that has a name constraints
>extension set according to rfc 2459 4.2.1.11, marked critical"
>
>Netscape communicator 4.x rejects connection with an NC, saying that
>it has an unknown critical extension.   Disappointing, given that
>rfc 2459 is approaching its 3rd birthday.
>
>IE 5.5 connected  fine with the NC ; but it displays it as a blob.
>
>Netscape 6.x connect with the NC, and in successive revisions display
>or manage the certificate a little better each rev.  However, they still
>don't translate the 2.5.29.30 OID into anything sensible, leaving it
>as hex data.
>
>IE 6 connects with the NC fine, and displays a sensible translation of the
>name constraint info.
>
>Just for kicks, openssl-096b doesn't translate this OID into anything
>readable either (don't see any sign of name constraint support
>in the source).
>
>Note that I haven't had time to generate some bogus certificates (out
>of conformance with name constraints) to test actual compliance.
>But the poor translation behavior by the browsers doesn't inspire
>a lot of confidence.
>
>Is this extension dead?




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKFA3K04562 for ietf-pkix-bks; Thu, 20 Dec 2001 07:10:03 -0800 (PST)
Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKFA2204557 for <[e-mail]>; Thu, 20 Dec 2001 07:10:02 -0800 (PST)
Received: from gaetanus (151.26.18.168) by smtp1.libero.it (6.0.032) id 3BF1798A00E40794 for [e-mail]; Thu, 20 Dec 2001 16:09:51 +0100
From: "Di Sivo ing. Francesco" <[e-mail]>
To: <[e-mail]>
Subject: pkcs #6
Date: Thu, 20 Dec 2001 16:22:19 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: High
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>
List-ID: <ietf-pkix.imc.org>

Hi to all,
can someone resolve his question: on the RSA site there is on-line the
version 1.5 of the pkcs#6: Extended certificate but in the RFC 2630 :
cryptographic message syntax the pkcs#6 certificate is marked as obsolete.
What is the situation? Why RSA does not say anything about this question?
Thank to all.

francesco di sivo
security engineer
università degli studi di napoli - federico II
via claudio 5
napoli - italia
[e-mail]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBK4uJ309455 for ietf-pkix-bks; Wed, 19 Dec 2001 20:56:19 -0800 (PST)
Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBK4uH209442 for <[e-mail]>; Wed, 19 Dec 2001 20:56:18 -0800 (PST)
Received: from jamessonyvaio (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id AB68FFFC14 for <[e-mail]>; Thu, 20 Dec 2001 12:54:58 +0800 (SGT)
Message-ID: <00a801c18912$93815d70$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: SLC minutes
Date: Thu, 20 Dec 2001 12:55:36 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
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>
List-ID: <ietf-pkix.imc.org>

is SLC meeting minutes available?

james



Received: by above.proper.com (8.11.6/8.11.3) id fBK2na307152 for ietf-pkix-bks; Wed, 19 Dec 2001 18:49:36 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBK2nZ207148 for <[e-mail]>; Wed, 19 Dec 2001 18:49:35 -0800 (PST)
Received: from arport (t6o69p107.telia.com [213.64.110.227]) by mailg.telia.com (8.11.6/8.11.6) with SMTP id fBK2nan21596 for <[e-mail]>; Thu, 20 Dec 2001 03:49:36 +0100 (CET)
Message-ID: <004501c18900$f7bf28b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: DoD's smart card program
Date: Thu, 20 Dec 2001 03:49:37 +0100
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>
List-ID: <ietf-pkix.imc.org>

For people interested in smart PKI-cards

[extracts from mailings with a major PKI vendor]

The only *advanced* smart card that so far has been a smash hit
is the ubiquitous SIM-card that has been delivered in over
*one billion* copies.

These 1 billion SIM-cards are *fully interchangeable* in any
compliant GSM-phone.  No SW installation required!

What does this say: In order to succeed with a PKI-card, you must
define a "card-edge-standard" that supports a *deliberately limited*,
*well-defined* set of commands (i.e. a profile).

The Operating System-thing that people are fighting about is
just a very *time-consuming*, and *contra-productive* "detour",
as SIM-cards works without requiring a specific OS.
There are at least 10 different card-OSes that are up to the task
supporting a PKI card.

Unfortunately the PKI-industry lacks players like Ericsson and Nokia
that defined the rules for the SIM-manufacturers, so I guess the PKI-
cards will continue [year after year] to be a battleground (playground?)
instead of simply products.


[A response to a person involved in DoD's huge smart card program]

All this sounds great but the program you are mentioning is unfortunately
just one of several such activities going on.   I also see a lot of
references to Java in your message.  This is exciting as a technology
but SIMs shows that you don't need Java [in the card].   I guess DoD are
into multi-function cards which indicates multi-issuers etc?
Personally, I think all this will fail completely due to *endless*
political and technological fights.  Also interoperability
is a *tremendous* problem when you run "arbitrary" applets
in the smart card, as it is a "client-server" solution with all
the associated problems .  Unlike a simple PKI-card which is
a "thin client" where the "intelligence" is somewhere
else.  I thought the SW industry had already learned this lesson?

>Another issue is finding the appropriate standards body to endorse
>a card-edge standard.  A DoD standard, for example, will not
>likely be embraced by the european community.

This is indeed where the PKI industry seems to halt.   My hope was that
somebody would launch a $5-$7 pre-personalized PKI-card that
*anybody* (except you know who...) could buy over the net in quantity #1 and up,
*free* SW and is compatible with Windows' CSP and with any CA.
Marketing and selling, instead of waiting on yet another standard.

Is this *technically* possible? Yes, GemSAFE et al are essentially having
this today (although GemPlus have yet to write a CSP that works).

Will this happen? I don't think so.  Beacuse we are dealing with
"smart" cards created by considerably less "smart" manufacturers.

Regards
Anders Rundgren




Received: by above.proper.com (8.11.6/8.11.3) id fBJKihi16858 for ietf-pkix-bks; Wed, 19 Dec 2001 12:44:43 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJKig216852 for <[e-mail]>; Wed, 19 Dec 2001 12:44:42 -0800 (PST)
Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id MAA15795 for <[e-mail]>; Wed, 19 Dec 2001 12:44:45 -0800 (PST)
Message-Id: <[e-mail]>
X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net
To: [e-mail]
Reply-to: [e-mail]
Subject: Name constraints
Date: Wed, 19 Dec 2001 12:44:45 -0800
From: Michael Helm <[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>
List-ID: <ietf-pkix.imc.org>

... or the lack of support for them (rfc 2459 4.2.1.11)

I recently "had occasion" to try out name contraints and
their support in various revisions of the popular web
browsers, and results are certainly disappointing.

Let "NC" stand for some text along the lines of, "a certificate
that chains to a CA signing certificate that has a name constraints
extension set according to rfc 2459 4.2.1.11, marked critical"

Netscape communicator 4.x rejects connection with an NC, saying that
it has an unknown critical extension.   Disappointing, given that
rfc 2459 is approaching its 3rd birthday.

IE 5.5 connected  fine with the NC ; but it displays it as a blob.

Netscape 6.x connect with the NC, and in successive revisions display
or manage the certificate a little better each rev.  However, they still 
don't translate the 2.5.29.30 OID into anything sensible, leaving it
as hex data.

IE 6 connects with the NC fine, and displays a sensible translation of the
name constraint info.

Just for kicks, openssl-096b doesn't translate this OID into anything
readable either (don't see any sign of name constraint support
in the source).

Note that I haven't had time to generate some bogus certificates (out
of conformance with name constraints) to test actual compliance.
But the poor translation behavior by the browsers doesn't inspire
a lot of confidence.

Is this extension dead? 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBE76GK16402 for ietf-pkix-bks; Thu, 13 Dec 2001 23:06:16 -0800 (PST)
Received: from fork.computel.sk (fork.computel.sk [195.28.96.96]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE76D216385; Thu, 13 Dec 2001 23:06:13 -0800 (PST)
Received: from domino1.tempest.sk (domino1.tempest.sk [195.28.100.38]) by fork.computel.sk  with ESMTP id IAA22321; Fri, 14 Dec 2001 08:05:23 +0100
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re:  web browser support for several CRLs for the same CA
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
From: [e-mail]
X-MIMETrack: S/MIME Sign by Notes Client on Pavol Adamec/Tempest/DGRP(Release 5.0.8 |June 18, 2001) at 14.12.2001 08:05:16, Serialize by Notes Client on Pavol Adamec/Tempest/DGRP(Release 5.0.8 |June 18, 2001) at 14.12.2001 08:05:16, Serialize complete at 14.12.2001 08:05:16, Itemize by Notes Client on Pavol Adamec/Tempest/DGRP(Release 5.0.8 |June 18, 2001) at 14.12.2001 08:05:16, S/MIME Sign complete at 14.12.2001 08:05:16, S/MIME Sign by Idle on Pavol Adamec/Tempest/DGRP(Release 5.0.8 |June 18, 2001) at 14.12.2001 08:05:23, S/MIME Sign complete at 14.12.2001 08:05:23, Serialize by Router on Domino1/DGRP(Release 5.0.8 |June 18, 2001) at 14.12.2001 08:05:34, Serialize complete at 14.12.2001 08:05:34
Message-ID: <[e-mail]>
Date: Fri, 14 Dec 2001 08:05:21 +0100
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z14839_boundary_sign
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>
List-ID: <ietf-pkix.imc.org>

This is an S/MIME signed message.

---------z14839_boundary_sign
Content-Type: text/plain; charset="us-ascii"

Well, I think the meaning of the question was: 
"Is there a tool (web browser, or a module for a web browser) that 
supports CRL Distribution Point extension?"

Paul

--
Pavol Adamec, Security Analyst
Tempest Ltd.                            tel: [phone]
Landererova 1                           fax: [phone]
811 09 Bratislava                       mail: [e-mail]
Slovak Republic                         web: http://www.tempest.sk




[e-mail] (Peter Gutmann)
Sent by: [e-mail]
13.12.2001 16:39

 
        To:     [e-mail], [e-mail]
        cc: 
        Subject:        Re:  web browser support for several CRLs for the same CA



[e-mail] writes:

>I was wondering if anybody would now a tool (web browser, or a module for 
a
>web browser) that would support having several CRLs for the same CA the 
way
>Entrust does it. It looks like mod_ssl does not support that (you can 
only
>have 1 CRL per CA).

I'm not sure what you're after in terms of "a tool" (a means of checking 
any
cert against a CRL?), but cryptlib,
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/, will support any number of
CRLs from any number of CAs.  It's open source, so you can build it into a
browser in whatever way you want.

Peter.




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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggKIMIIB8aADAgECAgME+a8wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA2
MDcxMjUxMjdaFw0wMjA2MDcxMjUxMjdaMEkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVl
bWFpbCBNZW1iZXIxJjAkBgkqhkiG9w0BCQEWF3Bhdm9sX2FkYW1lY0B0ZW1wZXN0
LnNrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDIpQrTP7lxpSO7wYHEhLjH
7LFSmXCWTF60jDnuzUGPQR1anFt7ZfEGrAy2fI1dWAxpoej3E8NA9m05pl8Tmb2L
IXMiZj6LChjrtgAdS31osvCoa7leSdh3o3y6zQ+RVmYtyGm5u+yOrAV6jkKAHwIr
9JaesYRpJKVD1tVgvUy88wIDAQABozQwMjAiBgNVHREEGzAZgRdwYXZvbF9hZGFt
ZWNAdGVtcGVzdC5zazAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE0f
6t/FnYeVz9sh0dzm5bcsopbvpepGgn+JK3yrFNxtZ++7Gx+VRDbrwepa75HEdlCz
wx8L4gW0OANhjsigkGRo+VzAVWD3nJx/pjcmodnU2XHR4gQVZWquNUwIxzLZg4l+
EsU9+poPIb64dONJHBgvr7aWG+hdSCM2px/dNJOaMIIDKTCCApKgAwIBAgIBDDAN
BgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk
MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN
AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAw
MFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/
+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB
/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZl
i/8VNEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0
kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5
fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMIIDLTCCApagAwIBAgIBADANBgkq
hkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw
ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu
ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoX
DTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0
OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZe
rerAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkC
AwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+
Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp
352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95D
qYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigQAAMYAwggHrAgEBMIGaMIGSMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl
IFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy
dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAC
AwT5rzAJBgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTAxMTIxNDA3MDUxNlowIwYJKoZIhvcNAQkEMRYEFH4YRbge
skC1BcODD1PWrp+Kd9OkMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZI
hvcNAwICAgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGArB16pSY4vAcq0rOC+zBZunTLg+Mt+O5D7iBbnMuKUT04
SZG1uCryPafNWh/o6Kug39MO6Uv0gyhVNihvXXqjYREG7VBotpTsp2Vvv8Soouf/
6sdZjMJLWIQA0FubngeGKIrwLwBZXQaXQBcMjPb4zuhOiQ3+tgySJ9VBD5dtPO8A
AAAAAAAAAA==

---------z14839_boundary_sign--


Received: by above.proper.com (8.11.6/8.11.3) id fBE3IRP08814 for ietf-pkix-bks; Thu, 13 Dec 2001 19:18:27 -0800 (PST)
Received: from web13704.mail.yahoo.com (web13704.mail.yahoo.com [216.136.175.137]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBE3IQ208810 for <[e-mail]>; Thu, 13 Dec 2001 19:18:26 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [61.139.82.150] by web13704.mail.yahoo.com via HTTP; Fri, 14 Dec 2001 11:18:30 CST
Date: Fri, 14 Dec 2001 11:18:30 +0800 (CST)
From: =?gb2312?q?li=20yunfeng?= <[e-mail]>
Subject: Re: Using DSA generated keys for RSA encryption
To: "Raghavendran H. \(SSG\) - CTD, Chennai." <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
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>
List-ID: <ietf-pkix.imc.org>

 --- "Raghavendran H. (SSG) - CTD, Chennai."
<[e-mail]> µÄÕýÎÄ£º> 
> Hi List:
> 
> I know this might be a rather dumb question:
> 
> Can I use DSA keys for RSA encryption? If yes, why?
> If no, why not?
> 
> Regards,
> Raghav
> 
>
These two have different paraments and algorithem!
forward.li
****************************************************************************
> **********************************************
> Disclaimer:
> 
> This document is intended for transmission to the
> named recipient only.  If
> you are not that person, you should note that legal
> rights reside in this
> document and you are not authorized to access, read,
> disclose, copy, use or
> otherwise deal with it and any such actions are
> prohibited and may be
> unlawful. The views expressed in this document are
> not necessarily those of
> HCL Technologies Ltd. Notice is hereby given that no
> representation,
> contract or other binding obligation shall be
> created by this e-mail, which
> must be interpreted accordingly. Any
> representations, contractual rights or
> obligations shall be separately communicated in
> writing and signed in the
> original by a duly authorized officer of the
> relevant company.
> 
>
****************************************************************************
> ********************************************** 

_________________________________________________________
Do You Yahoo!? µÇ¼Ãâ·ÑÑÅ»¢µçÓÊ! http://mail.yahoo.com.cn

<font color=#6666FF>ÎÞÁÄ£¿ÓôÃÆ£¿¸ßÐË£¿Ã»ÀíÓÉ£¿¶¼À´ÁÄÌì°É£¡</font>¡ª¡ª 
ÑÅ»¢È«ÐÂÁÄÌìÊÒ! http://cn.chat.yahoo.com/c/roomlist.html


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBDNkjR28388 for ietf-pkix-bks; Thu, 13 Dec 2001 15:46:45 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBDNkh228384 for <[e-mail]>; Thu, 13 Dec 2001 15:46:43 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Dec 2001 23:46:37 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA10701 for <[e-mail]>; Thu, 13 Dec 2001 18:46:42 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBDNkft11800 for <[e-mail]>; Thu, 13 Dec 2001 18:46:41 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y57CGAC5>; Thu, 13 Dec 2001 18:46:40 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y57CGACZ; Thu, 13 Dec 2001 18:46:38 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "Raghavendran H. (SSG) - CTD, Chennai." <[e-mail]>
Cc: [e-mail]
Subject: Re: Using DSA generated keys for RSA encryption
Date: Thu, 13 Dec 2001 18:45:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>
List-ID: <ietf-pkix.imc.org>

At 09:07 PM 12/13/2001 +0530, Raghavendran H. (SSG) - CTD, Chennai. wrote:
>Can I use DSA keys for RSA encryption? If yes, why? If no, why not?


No they have a different mathematical structure.

Russ




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBDINMI09611 for ietf-pkix-bks; Thu, 13 Dec 2001 10:23:22 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDINJ209607 for <[e-mail]>; Thu, 13 Dec 2001 10:23:20 -0800 (PST)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 13 Dec 2001 11:24:37 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0.1
Date: Thu, 13 Dec 2001 11:24:33 -0700
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Using DSA generated keys for RSA encryption
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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>
List-ID: <ietf-pkix.imc.org>

No.
They are different algorithms, and keys are not interchangeable.

Why not: RSA is finding the e-th root of an integer module a composite
integer (integer factorization problem would provide a solution as
well), while DSA is based on the discrete logarithm problem in the
subgroup Zp*.

More plain words, you don't have the primes in RSA [public] key to
construct the DSA subgroup.

Best,
- Tolga
>>> "Raghavendran H. (SSG) - CTD, Chennai." <[e-mail]>
12/13/01 8:37:28 >>>

Hi List:

I know this might be a rather dumb question:

Can I use DSA keys for RSA encryption? If yes, why? If no, why not?

Regards,
Raghav

****************************************************************************
**********************************************
Disclaimer:

This document is intended for transmission to the named recipient only.
 If
you are not that person, you should note that legal rights reside in
this
document and you are not authorized to access, read, disclose, copy,
use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily
those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail,
which
must be interpreted accordingly. Any representations, contractual
rights or
obligations shall be separately communicated in writing and signed in
the
original by a duly authorized officer of the relevant company.

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBDFtU428618 for ietf-pkix-bks; Thu, 13 Dec 2001 07:55:30 -0800 (PST)
Received: from ganesh.ctd.hctech.com ([202.54.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDFtR228603 for <[e-mail]>; Thu, 13 Dec 2001 07:55:27 -0800 (PST)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <YFN0652S>; Thu, 13 Dec 2001 21:20:28 +0530
Message-ID: <[e-mail]>
From: "Raghavendran H. (SSG) - CTD, Chennai." <[e-mail]>
To: [e-mail]
Subject: Using DSA generated keys for RSA encryption
Date: Thu, 13 Dec 2001 21:07:28 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>
List-ID: <ietf-pkix.imc.org>

Hi List:

I know this might be a rather dumb question:

Can I use DSA keys for RSA encryption? If yes, why? If no, why not?

Regards,
Raghav

****************************************************************************
**********************************************
Disclaimer:

This document is intended for transmission to the named recipient only.  If
you are not that person, you should note that legal rights reside in this
document and you are not authorized to access, read, disclose, copy, use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail, which
must be interpreted accordingly. Any representations, contractual rights or
obligations shall be separately communicated in writing and signed in the
original by a duly authorized officer of the relevant company.

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBDFqDd27654 for ietf-pkix-bks; Thu, 13 Dec 2001 07:52:13 -0800 (PST)
Received: from phaostec.temp.veriohosting.com (phaostec.temp.veriohosting.com [161.58.151.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDFqC227644 for <[e-mail]>; Thu, 13 Dec 2001 07:52:12 -0800 (PST)
Received: from phaos_arik.phaos.com ([198.78.132.60]) by phaostec.temp.veriohosting.com (8.11.6) id fBDFobp45130; Thu, 13 Dec 2001 08:50:47 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 13 Dec 2001 10:59:07 -0500
To: monte <[e-mail]>
From: Ari Kermaier <[e-mail]>
Subject: Re: OCSP avaliable?
Cc: [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>
List-ID: <ietf-pkix.imc.org>

Oops. its http://www.phaos.com/e_security/prod_pki.html

::Ari

> >See http://www.phaos.com/e_security/prod_pki/ for more info. You should be
> >able to get a free evaluation copy, although source code is not currently
> >available for download.
>
>I'm sorry, this link is wrong



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBD2e9O25036 for ietf-pkix-bks; Wed, 12 Dec 2001 18:40:09 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBD2e7225031 for <[e-mail]>; Wed, 12 Dec 2001 18:40:07 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA02934; Thu, 13 Dec 2001 15:40:00 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA464253; Thu, 13 Dec 2001 15:39:59 +1300 (NZDT) (sender [e-mail])
Date: Thu, 13 Dec 2001 15:39:59 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  web browser support for several CRLs for the same CA
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>
List-ID: <ietf-pkix.imc.org>

[e-mail] writes:

>I was wondering if anybody would now a tool (web browser, or a module for a
>web browser) that would support having several CRLs for the same CA the way
>Entrust does it. It looks like mod_ssl does not support that (you can only
>have 1 CRL per CA).

I'm not sure what you're after in terms of "a tool" (a means of checking any
cert against a CRL?), but cryptlib,
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/, will support any number of
CRLs from any number of CAs.  It's open source, so you can build it into a
browser in whatever way you want.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCL7bs04985 for ietf-pkix-bks; Wed, 12 Dec 2001 13:07:37 -0800 (PST)
Received: from phaostec.temp.veriohosting.com (phaostec.temp.veriohosting.com [161.58.151.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCL7a204981 for <[e-mail]>; Wed, 12 Dec 2001 13:07:36 -0800 (PST)
Received: from phaos_arik.phaos.com ([198.78.132.60]) by phaostec.temp.veriohosting.com (8.11.6) id fBCL6dh60964; Wed, 12 Dec 2001 14:06:39 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 12 Dec 2001 16:15:03 -0500
To: Jose Antonio Onieva =?iso-8859-1?Q?Gonz=E1lez?= <[e-mail]>, [e-mail]
From: Ari Kermaier <[e-mail]>
Subject: Re: OCSP avaliable?
In-Reply-To: <[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>
List-ID: <ietf-pkix.imc.org>

>
>Hi!
>  Firtly of all, sorry for my poor english. I'm a student that NEED an
>implementation of OCSP if it's posible. What I really need is source
>code of OCSP (implemented in OpenSSL) ready for use it. If i'm not wrong
>few time ago I searched for it in new versions of OpenSSL (0.9.6b) and
>it wasn't yet. I'm very interested in code like OpenCA-OCSP-0.2.1 (that
>itsn't completed and abandoned if i'm not wrong again).
>
>could anybody help me?
>
>thank's a lot!
>
>(oh, by the way, i have been searching for it in some links that appears
>in the mailing list and i think that i've not find exactly what i need.
>It must exist.Doesn't it?)

The current release of the Phaos Centuris PKI toolkit includes a compliant 
OCSP implementation.
See http://www.phaos.com/e_security/prod_pki/ for more info. You should be 
able to get a free evaluation copy, although source code is not currently 
available for download.


Ari Kermaier    [e-mail]
Senior Software Engineer
Phaos Technology Corp.    http://www.phaos.com/



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCJbjM27970 for ietf-pkix-bks; Wed, 12 Dec 2001 11:37:45 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCJbi227966 for <[e-mail]>; Wed, 12 Dec 2001 11:37:44 -0800 (PST)
Received: from [128.33.238.98] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA21082 for <[e-mail]>; Wed, 12 Dec 2001 14:37:39 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040eb83d4ea45993@[128.33.238.98]>
Date: Wed, 12 Dec 2001 13:15:06 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: slides
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>
List-ID: <ietf-pkix.imc.org>

Everyone who made a presentation at yesterday's PKIX meeting, and 
used slides, should send a copy of the slides to me, for 
consolidation and later forwarding to the IETF Secretariat.

The award for first set of slides to be submitted goes to Jim Schaad, 
who mailed them BEFORE the meeting took place!

Steve


Received: by above.proper.com (8.11.6/8.11.3) id fBCF4lv08058 for ietf-pkix-bks; Wed, 12 Dec 2001 07:04:47 -0800 (PST)
Received: from mx1.sita.int (mx1.sita.int [57.250.224.237]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCF4k208054 for <[e-mail]>; Wed, 12 Dec 2001 07:04:46 -0800 (PST)
Received: from montreal1.yul.sita.int (montreal1.yul.sita.int [57.4.233.253]) by mx1.sita.int  with ESMTP id fBCF4fq14022 for <[e-mail]>; Wed, 12 Dec 2001 15:04:41 GMT
Subject: web browser support for several CRLs for the same CA
To: [e-mail]
From: [e-mail]
Date: Wed, 12 Dec 2001 10:04:38 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on Montreal1/Montreal/SITA/WW(Release 5.0.6a |January 17, 2001) at 12/12/2001 10:04:40 AM
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>
List-ID: <ietf-pkix.imc.org>

Hi there,

I was wondering if anybody would now a tool (web browser, or a module for a
web browser) that would support having several CRLs for the same CA the way
Entrust does it. It looks like mod_ssl does not support that (you can only
have 1 CRL per CA).

Regards,

Alec Barea

--------------------------------------------------------------------------------------------

Alec Barea
PKI engineering team
Equant
Tel:  [phone]
CVS: 225 3436



Received: by above.proper.com (8.11.6/8.11.3) id fBCCcIK25685 for ietf-pkix-bks; Wed, 12 Dec 2001 04:38:18 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCCc6225655 for <[e-mail]>; Wed, 12 Dec 2001 04:38:16 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id BAA13978; Thu, 13 Dec 2001 01:35:53 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id BAA446852; Thu, 13 Dec 2001 01:35:40 +1300 (NZDT) (sender [e-mail])
Date: Thu, 13 Dec 2001 01:35:40 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: OCSP avaliable?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

>Current releases of the iPlanet CMS have OCSP responder built-in. Have a=20
>look at
>
>http://www.iplanet.com/downloads/download/
>
>for an eval download - fully functional.

cryptlib also has an OCSP responder built in, you can get it from
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC9Yw008824 for ietf-pkix-bks; Wed, 12 Dec 2001 01:34:58 -0800 (PST)
Received: from fork.computel.sk (fork.computel.sk [195.28.96.96]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC9Yu208814 for <[e-mail]>; Wed, 12 Dec 2001 01:34:56 -0800 (PST)
Received: from domino1.tempest.sk (domino1.tempest.sk [195.28.100.38]) by fork.computel.sk  with ESMTP id KAA31313; Wed, 12 Dec 2001 10:34:29 +0100
To: Jose Antonio Onieva =?iso-8859-2?Q?Gonz=E1lez?= <[e-mail]>
Cc: [e-mail]
Subject: Re: OCSP avaliable?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
From: [e-mail]
X-MIMETrack: S/MIME Sign by Notes Client on Pavol Adamec/Tempest/DGRP(Release 5.0.8 |June 18, 2001) at 12.12.2001 10:34:17, Serialize by Notes Client on Pavol Adamec/Tempest/DGRP(Release 5.0.8 |June 18, 2001) at 12.12.2001 10:34:17, Serialize complete at 12.12.2001 10:34:17, Itemize by Notes Client on Pavol Adamec/Tempest/DGRP(Release 5.0.8 |June 18, 2001) at 12.12.2001 10:34:20, S/MIME Sign complete at 12.12.2001 10:34:20, S/MIME Sign by Idle on Pavol Adamec/Tempest/DGRP(Release 5.0.8 |June 18, 2001) at 12.12.2001 10:34:28, S/MIME Sign complete at 12.12.2001 10:34:28, Serialize by Router on Domino1/DGRP(Release 5.0.8 |June 18, 2001) at 12.12.2001 10:34:29, Serialize complete at 12.12.2001 10:34:29
Message-ID: <[e-mail]>
Date: Wed, 12 Dec 2001 10:34:28 +0100
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z49758_boundary_sign
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>
List-ID: <ietf-pkix.imc.org>

This is an S/MIME signed message.

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

Current releases of the iPlanet CMS have OCSP responder built-in. Have a=20
look at

http://www.iplanet.com/downloads/download/

for an eval download - fully functional.

Paul

--
Pavol Adamec, Security Analyst
Tempest Ltd.                            tel: [phone]
Landererova 1                           fax: [phone]
811 09 Bratislava                       mail: pavol=[e-mail]
Slovak Republic                         web: http://www.tempest.sk




Jose Antonio Onieva Gonz=E1lez <[e-mail]>
Sent by: [e-mail]
11.12.2001 16:15

=20
        To:     [e-mail]
        cc:=20
        Subject:        OCSP avaliable?



Hi!
 Firtly of all, sorry for my poor english. I'm a student that NEED an
implementation of OCSP if it's posible. What I really need is source
code of OCSP (implemented in OpenSSL) ready for use it. If i'm not wrong
few time ago I searched for it in new versions of OpenSSL (0.9.6b) and
it wasn't yet. I'm very interested in code like OpenCA-OCSP-0.2.1 (that
itsn't completed and abandoned if i'm not wrong again).

could anybody help me?

thank's a lot!

(oh, by the way, i have been searching for it in some links that appears
in the mailing list and i think that i've not find exactly what i need.
It must exist.Doesn't it?)




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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggKIMIIB8aADAgECAgME+a8wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA2
MDcxMjUxMjdaFw0wMjA2MDcxMjUxMjdaMEkxHzAdBgNVBAMTFlRoYXd0ZSBGcmVl
bWFpbCBNZW1iZXIxJjAkBgkqhkiG9w0BCQEWF3Bhdm9sX2FkYW1lY0B0ZW1wZXN0
LnNrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDIpQrTP7lxpSO7wYHEhLjH
7LFSmXCWTF60jDnuzUGPQR1anFt7ZfEGrAy2fI1dWAxpoej3E8NA9m05pl8Tmb2L
IXMiZj6LChjrtgAdS31osvCoa7leSdh3o3y6zQ+RVmYtyGm5u+yOrAV6jkKAHwIr
9JaesYRpJKVD1tVgvUy88wIDAQABozQwMjAiBgNVHREEGzAZgRdwYXZvbF9hZGFt
ZWNAdGVtcGVzdC5zazAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE0f
6t/FnYeVz9sh0dzm5bcsopbvpepGgn+JK3yrFNxtZ++7Gx+VRDbrwepa75HEdlCz
wx8L4gW0OANhjsigkGRo+VzAVWD3nJx/pjcmodnU2XHR4gQVZWquNUwIxzLZg4l+
EsU9+poPIb64dONJHBgvr7aWG+hdSCM2px/dNJOaMIIDKTCCApKgAwIBAgIBDDAN
BgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk
MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN
AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAw
MFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/
+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB
/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZl
i/8VNEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0
kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5
fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMIIDLTCCApagAwIBAgIBADANBgkq
hkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw
ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu
ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoX
DTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0
OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZe
rerAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkC
AwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+
Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp
352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95D
qYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigQAAMYAwggHrAgEBMIGaMIGSMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl
IFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy
dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAC
AwT5rzAJBgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTAxMTIxMjA5MzQyMFowIwYJKoZIhvcNAQkEMRYEFIQlBcVk
16y0kXqfJzEPDWJ41bsJMEwGCSqGSIb3DQEJDzE/MD0wBwYFKw4DAh0wDgYIKoZI
hvcNAwICAgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAFGcW9KWC/b2AwCjB/0PNLKjYyOJq9bh4AAzUfjVjD9Xi
flGQn/kA2PbJ43+Hq1Olf+9J7dqDZU/PTTrdC/lgTAG0NyguvICd6dmT4Uhrmz1D
deU3GAa2P441h3wtb3Npr7djunetE9wOnAqrDAvLvrzED0pIHtoPUDkv5OYcc2MA
AAAAAAAAAA==

---------z49758_boundary_sign--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC2UQQ07610 for ietf-pkix-bks; Tue, 11 Dec 2001 18:30:26 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC2UO207605 for <[e-mail]>; Tue, 11 Dec 2001 18:30:24 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id <Y2YR70DX>; Wed, 12 Dec 2001 13:21:29 +1100
Message-ID: <[e-mail]>
From: "Mortimer, Ken" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: OCSP avaliable?
Date: Wed, 12 Dec 2001 13:21:36 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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 fBC2UP207607
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>
List-ID: <ietf-pkix.imc.org>

> From: Jose Antonio Onieva González [mailto:[e-mail]]
> 
> Hi!
>  Firtly of all, sorry for my poor english. I'm a student that NEED an
> implementation of OCSP if it's posible. What I really need is source
> code of OCSP (implemented in OpenSSL) ready for use it. If 
> i'm not wrong
> few time ago I searched for it in new versions of OpenSSL (0.9.6b) and
> it wasn't yet. I'm very interested in code like 
> OpenCA-OCSP-0.2.1 (that
> itsn't completed and abandoned if i'm not wrong again).

OpenSSL 0.9.7 will have an OCSP component.  It isn't released yet (the
current version is 0.9.6b) so it isn't exactly "ready for use" but the
latest source snapshot is available from openssl.org if you would like to
have a look at it:
  ftp://ftp.openssl.org/snapshot/

It's worth a download to see if its OCSP routines suit you. You can post any
questions you have about it to the OpenSSL mailing list (you can join here:
http://www.openssl.org/support/) but as it's not officially released yet and
still in development, answers to your questions may be limited...

Ken.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBJH4k08702 for ietf-pkix-bks; Tue, 11 Dec 2001 11:17:04 -0800 (PST)
Received: from nala.ctima.uma.es (nala.ctima.uma.es [150.214.57.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBJH1208698 for <[e-mail]>; Tue, 11 Dec 2001 11:17:02 -0800 (PST)
Received: from nala.ctima.uma.es (localhost [127.0.0.1]) by nala.ctima.uma.es (8.11.1/8.9.1) with ESMTP id fBBJGqB10929 for <[e-mail]>; Tue, 11 Dec 2001 20:16:52 +0100 (MET)
Received: from crypto.lcc.uma.es (odal.crypto.lcc.uma.es [150.214.108.163]) by nala.ctima.uma.es (8.11.1/8.11.1) with ESMTP id fBBJGpk10925 for <[e-mail]>; Tue, 11 Dec 2001 20:16:51 +0100 (MET)
Received: from crypto.lcc.uma.es (IDENT:onieva@[150.214.214.57]) by crypto.lcc.uma.es (8.9.3/8.9.3) with ESMTP id UAA21517 for <[e-mail]>; Tue, 11 Dec 2001 20:26:43 +0100
Message-ID: <[e-mail]>
Date: Tue, 11 Dec 2001 20:15:58 +0500
From: Jose Antonio Onieva =?iso-8859-1?Q?Gonz=E1lez?=  <[e-mail]>
X-Mailer: Mozilla 4.75 [es] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: es-ES, en
MIME-Version: 1.0
To: [e-mail]
Subject: OCSP avaliable?
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>
List-ID: <ietf-pkix.imc.org>

Hi!
 Firtly of all, sorry for my poor english. I'm a student that NEED an
implementation of OCSP if it's posible. What I really need is source
code of OCSP (implemented in OpenSSL) ready for use it. If i'm not wrong
few time ago I searched for it in new versions of OpenSSL (0.9.6b) and
it wasn't yet. I'm very interested in code like OpenCA-OCSP-0.2.1 (that
itsn't completed and abandoned if i'm not wrong again).

could anybody help me?

thank's a lot!

(oh, by the way, i have been searching for it in some links that appears
in the mailing list and i think that i've not find exactly what i need.
It must exist.Doesn't it?)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBD4IB12542 for ietf-pkix-bks; Tue, 11 Dec 2001 05:04:18 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBD4G212535 for <[e-mail]>; Tue, 11 Dec 2001 05:04:16 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA09878; Tue, 11 Dec 2001 08:01:22 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBBD49079988; Tue, 11 Dec 2001 08:04:09 -0500
Importance: Normal
Subject: Re: Title attribute type
To: "Franco Ruggieri" <[e-mail]>
Cc: <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 11 Dec 2001 08:04:27 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #s MIAS4UTJ8H JPOS4U8UWQ CMCY4QLP6R |August 29, 2001) at 12/11/2001 08:04:10 AM
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>
List-ID: <ietf-pkix.imc.org>

     Franco:

     Since QC is effectively a sub-profile of RFC 2459, and almost any
directory attribute omitted from subject can go into
subjectDirectoryAttributes, I would think that QC means what it says, while
RFC 2459 is just saying that for SOME legal certificates title goes in the
DN's.

          Tom Gindin


"Franco Ruggieri" <[e-mail]>@mail.imc.org on 12/11/2001
02:58:06 AM

Sent by:  [e-mail]


To:   <[e-mail]>
cc:
Subject:  Title attribute type



I will very much appreciate having the following doubt solved.

In RFC 3039 section 3.2.1, the "title" attribute (defind in section X.520,
5.4.3) is included in the subjectDirectoryAttributes extension.
In RFC 2459 (and in its "son") the same "title" attribute is included among
the issuer & subject fields, as per sections 4.1.2.4 and 4.1.2.6.

Where is it to be correctly located, namely in a Qualified Certificate?

Moreover: regardless of its collocation, since it may be a bmpString (or,
preferably, a UTF8String), do you deem it acceptable it has a format
like the following one:
"0.1.234.5.6.7.#LousyFirm - Italy Country Manager"

Once more: Thanks in advance whomever helps :-)
Franco
------------------------------------------
Ing. Franco RUGGIERI
FIR DIG Consultants
Lungomare delle Sirene 138
00040 POMEZIA (ROMA)
tel.   [phone]
cell: [phone]





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBB7vUS12469 for ietf-pkix-bks; Mon, 10 Dec 2001 23:57:30 -0800 (PST)
Received: from smtp2.flashnet.it (smtp2.flashnet.it [194.247.160.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBB7vS212463 for <[e-mail]>; Mon, 10 Dec 2001 23:57:28 -0800 (PST)
Received: from FIR3D64VWTXIJO (ip009.pool-02.cyb.it [195.191.2.138]) by smtp2.flashnet.it (8.10.2/8.10.2) with SMTP id fBB8peP21205 for <[e-mail]>; Tue, 11 Dec 2001 08:51:40 GMT
Message-ID: <008001c18219$9192b9f0$dd02bfc3@FIR3D64VWTXIJO>
From: "Franco Ruggieri" <[e-mail]>
To: <[e-mail]>
Subject: Title attribute type
Date: Tue, 11 Dec 2001 08:58:06 +0100
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 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
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>
List-ID: <ietf-pkix.imc.org>

I will very much appreciate having the following doubt solved.

In RFC 3039 section 3.2.1, the "title" attribute (defind in section X.520,
5.4.3) is included in the subjectDirectoryAttributes extension.
In RFC 2459 (and in its "son") the same "title" attribute is included among
the issuer & subject fields, as per sections 4.1.2.4 and 4.1.2.6.

Where is it to be correctly located, namely in a Qualified Certificate?

Moreover: regardless of its collocation, since it may be a bmpString (or,
preferably, a UTF8String), do you deem it acceptable it has a format
like the following one:
"0.1.234.5.6.7.#LousyFirm - Italy Country Manager"

Once more: Thanks in advance whomever helps :-)
Franco
------------------------------------------
Ing. Franco RUGGIERI
FIR DIG Consultants
Lungomare delle Sirene 138
00040 POMEZIA (ROMA)
tel.   [phone]
cell: [phone]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBAL1Da00665 for ietf-pkix-bks; Mon, 10 Dec 2001 13:01:13 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fBAL1B200660 for <[e-mail]>; Mon, 10 Dec 2001 13:01:11 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Dec 2001 21:01:05 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA25259 for <[e-mail]>; Mon, 10 Dec 2001 16:01:13 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fBAL1AX14648 for <[e-mail]>; Mon, 10 Dec 2001 16:01:11 -0500 (EST)
Received: by EXNA00 with Internet Mail Service (5.5.2653.19) id <YQMZBNSJ>; Mon, 10 Dec 2001 16:01:09 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.122 [10.3.1.122]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YQMZBNSG; Mon, 10 Dec 2001 16:01:06 -0500
From: "Housley, Russ" <[e-mail]>
To: Steve Tuecke <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 10 Dec 2001 11:46:10 -0500
Subject: Re: Names in Proxy Certificate 
In-Reply-To: <[e-mail]>
References: <[e-mail]. com>
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>
List-ID: <ietf-pkix.imc.org>

Steve Tuecke:

>>In draft-ietf-pkix-proxy-01, section 6.4, the authors talk about end 
>>entity names.  Mostly the specification talks about an approach that was 
>>rejected.  Finally, I think that the conclusion is that the parent of the 
>>proxy certificate contains the real identity information.
>
>Note that section 6.4 is the commentary section.  It is not intended to be 
>the specification, but rather to help give some insight on the 
>specification (e.g. what was considered but rejected).  At some point it 
>may make sense to move this out to a separate informational draft, but we 
>figured it was better to keep it all in one spot to begin with.
>
>The relevant portions of the spec here are sections 3.1 and 3.2.

Section 6.4 was the place that these problems jumped out at me.  I will 
take a look at these sections in the future.

>>If I have it right, then have a few concerns.
>>
>>First, in PKIX, we require that all issuers have a subject DN.  So, empty 
>>DNs cannot be used in the long-term certificates if proxy certificates 
>>are to be associated with them.  Further, the proxy certificate needs to 
>>include a subject DN if proxy certificates are permitted to issue 
>>subordinate proxy certificates.
>
>First, let me say that we're not at all married to this particular 
>approach to subjects and issuers.  What is in this draft is, in fact, 
>different from what we did in the Globus Toolkit.  In writing this draft, 
>we changed the approach (though not the proxy concept) to try to make it 
>live better with son-of-2459.  But in going back to son-of-2459, I see I 
>missed the relevant statement here in 4.1.2.4, of "The issuer field MUST 
>contain a non-empty distinguished name (DN)."  I don't know how I missed 
>this one!

This is a very important requirement.  It is in RFC 2459; it is not new in 
Son-of-2459.  If you want all of the discussion, you will have to review 
the mail list archive.  Off the top of my head, I recall two major 
points.  First, CRL entries are identified by issuer DN and serial 
number.  Second, S/MIME v2 identifies the recipient public key only with 
issuer DN and serial number.  S/MIME v3 continues to supports this method 
as well as the subject public key identifiers.

>The problem (and perhaps why I subconsciously ignored this issuer 
>requirement :-) is that I think the current son-of-2459 language puts us 
>between a rock and a hard place.  As your comment suggests, what if the 
>End Entity Certificate (EEC, or what I think you are referring to as the 
>long-term cert) has an empty subject field, and instead only has a 
>subjectAltName?  What do we use as the issuer in proxy that is signed by 
>that EEC?

Yes, I see the end entity certificate as long-lived, and the proxy 
certificate as short-lived.

>Maybe the best thing to do is explain what we are trying to accomplish, 
>what I observe the constraints to be, and you might be able to advise us 
>of an approach that lives better with son-of-2459.
>
>First, what are we trying to accomplish...  The point of proxies is that 
>we are specifically not trying to create a new identity.  Rather, we are 
>trying to define a mechanism by which a proxy can be created that is 
>associated back only to the subject or subjectAltName of the EEC that is 
>at the top of the proxy signing chain.  In essence, we want to bind a new 
>key pair back to the subject of the EEC, so that the holder of the new 
>private key can make a verifiable claim on the EEC subject name.
>
>What is the nature of that claim?  That's really up to the authorizing 
>party.  Having authenticated with a party that is using a proxy 
>certificate, and verified its path up through the proxy chain, EEC, and 
>CA, I know that this party has a valid proxy that was issued by an EEC 
>with a particular subject name.  In practice, the way that we use this is 
>as a way to delegate authorization rights.  That is, if I have 
>authenticated a proxy that is tied to an EEC with a subject of "Steve", 
>then I apply whatever authorization that I would normally apply to "Steve".
>
>And this is where the proxyRestriction field (3.6.1.3) comes into 
>play.  What the holder of an EEC typically wants to do is issue a proxy 
>that implies a subset of the rights normally associated with that EEC 
>subject.  So when such a proxy is presented to me, I would apply the 
>intersection of whatever authorization rights I would normally grant to 
>"Steve", with those that are defined in the proxyRestriction field of all 
>proxies in the signing path.
>
>In the current Globus Toolkit code, the way we handle subject and issuers 
>is that we require that the EEC subject be a DN, and then we extend that 
>DN with a "/CN=proxy" attribute in each proxy certificate.  Then in the 
>path validation we check that the proxy subject is the same as the issuer, 
>except for an extra "/CN=proxy" attribute.

In PEM (see RFC 1114 and RFC 1422), similar name subordination rules were 
specified.  Such rules were defined because version 1 certificates were 
employed.  Version 3 extensions allow much better answers (i.e., name 
constraints extensions).  I suggest that you avoid name-oriented conventions.

>So now what are the issues and constraints in making this play nicely with 
>son-of-2459:
>
>   * What do we do if the EEC does not have a subject, but instead only 
> has a subjectAltName?  Obviously, the approach that we used in the Globus 
> Toolkit doesn't work in this case.  And it doesn't seem particularly 
> satisfying to say that you can only create a proxy certificate from an 
> EEC that has a subject DN.

Some implementations use names to construct paths.  Others use public keys 
(or identifiers of them).  So, if you want all currently fielded software 
to be able to construct a certification path from the proxy certificate 
(PC) to the trust anchor, then you should mandate the subject DN.  On the 
other hand, if you want such software to only construct the certification 
path from the end entity certificate (EEC), then you have more design 
freedom; however, your applications will have to include their own software 
to validate the PCs.

>   * One of the uses of the subject is for path discovery.  So whatever 
> approach we choose needs to address this.  What we did in this draft is 
> give the proxy subjectAltName a (statistically) unique name, so that the 
> path can be discovered from these names.  Another option would be to use 
> (or invent) a different field for path discovery, such as 
> SubjectKeyIdentifier and AuthorityKeyIdentifier.

As I said above, there is fielded software that works with both 
approaches.  I would prefer both approaches to be supported by the 
specification.

>   * If we choose a different field for path discovery, this obviously 
> liberates us some with respect to the subject and issuer.  Nonetheless, 
> requiring a non-empty issuer still seems like a problem.  But ignoring 
> that for the moment, what would we want for the subject or 
> subjectAltName?  Would it just be a duplicate of the EEC's?  Are there 
> any issues with have multiple certificates with the same subject, even 
> though the proxies are clearly marked as such with a critical extensions?

Self-signed certificates are part of the architecture in several 
places.  So far, I do not see any reason to invent a new concept.

I think that the PC should contain the identity.  Looking up the chain for 
the first non-PC seems like work that can easily be avoided.  Further, I 
think that you would want to minimize any special processing.  In other 
words, the processing of a PC and an EEC should be kept as similar as possible.

>   * We must be very careful to not allow proxies to carry, or somehow 
> imply, the subject of some other EEC than the one at the top of the proxy 
> signing chain.  It seems we have basically 2 choices.  Either make the 
> subject (or subjectAltName) meaningless and ignore it.  Or give it 
> meaning (e.g. carry along the EEC subject) and check it in the path 
> validation code so that some other subject cannot be substituted.  We 
> went with the former (modulo path discovery), in the interest of avoiding 
> yet another thing that needs to be checked in the path validation 
> code.  But I'd also be comfortable with the latter.

Again, I recommend the inclusion of the EEC names in the PC.

>Anyway, I'm eager to hear if you have any suggestions for alternative 
>approaches.

If you are going to be at the IETF in Salt Lake City, we can discuss these 
issues further.

>>Second, in PKIX, we allow attribute certificates to be associated with 
>>subject DN or issuer/serial.  Wouldn't it be useful for authorizations in 
>>attribute certificates issued against the long-term certificate to apply 
>>to the proxy certificates as well?  This seems possible if the attribute 
>>certificate uses the subject DN and the proxy certificates also contain 
>>this same DN.
>
>Yes, I can certainly imagine this being useful.
>
>Perhaps this is motivation for changing the approach to proxy subject 
>names.  For example, we might consider carrying the EEC subject in the 
>proxy unchanged, check it in the path validation to make sure it 
>identical, and use the KeyIdentifiers for path discovery.  But there is 
>still the question of what goes in the issuer field.

If you require the EEC to contain a subject DN, then this gets pretty simple.

>But an interesting question with the combination of attribute certs and 
>proxy certs is what constraints might you want to put on this?  Do you 
>want to be able to associate attribute certs with just EEC's, but not 
>their proxies.  Or just with proxies?  Or just with a particular 
>proxy?  Or a set of proxies signed by a particular proxy?   Or some other 
>set of proxies?  I can imagine arguments for all of these.  This would 
>clearly be an interesting avenue to pursue.

If the Attribute Authority (AA) wants to associate a set of attributes with 
the EEC, or with a particular PC, then the AA can issue the Attribute 
Certificate (AC) with the holder set to the appropriate issuer DN/serial 
number pair.  If the AA wants to associate a set of attributes with the 
identity, then the AA can issue the AC with the holder set to the subject DN.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB9Mm5Z26084 for ietf-pkix-bks; Sun, 9 Dec 2001 14:48:05 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id fB9Mm3226077 for <[e-mail]>; Sun, 9 Dec 2001 14:48:03 -0800 (PST)
Received: (qmail 17154 invoked from network); 9 Dec 2001 22:43:08 -0000
Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 9 Dec 2001 22:43:08 -0000
Reply-To: <[e-mail]>
From: "Andrew Sciberras" <[e-mail]>
To: "Pkix \(E-mail\)" <[e-mail]>
Subject: Error Codes in OCSPv1
Date: Mon, 10 Dec 2001 09:48:30 +1100
Message-ID: <007d01c18103$a01dd840$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01C1815F.D38E5040"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_007E_01C1815F.D38E5040
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

G'day,

I'm not sure if this has been discussed before, so please excuse me if it
has.

Of the OCSPResponseStatus codes defined in RFC2560 I am unsure what should
be used if the following errors occur:
  a.. The OCSP Server receives a signed request that it cannot verify due to
lack of information. In the case where the OCSP Server requires all requests
to be signed, I would imagine that the sigRequired or unauthorized errors
messages could be used as the ResponseStatus. However, neither of these
responses provide the Client with any sort of indication as to what the
problem is.

  b.. In Section 4.1.1, it is stated that the issuerNameHash (and
issuerKeyHash) are hashed with an algorithm identified in hashAlgorithm.
Section 4.3 then states that an OCSP Server SHALL support SHA1. From what I
can tell, it would be reasonable for Clients to use any hashing algorithm
they like. If the Server received a request that used a hash algorithm that
it didn't support, what should be returned? All I can really think of is
successful ResponseStatus and an unknown CertStatus. However, I feel that a
successful ResponseStatus should not be used if the OCSP Server cannot fully
understand/decode/process the request which it is given.

  c.. Unsupported Request Version. If the version number is unsupported is
it appropriate to return the malformedRequest status?
Each of the scenarios described above could fit into some of the preexisting
status codes, however in each case the Client would have created a request
that is correct, but received a reply which indicates otherwise. Perhaps
another error response needs to be included that lets the OCSP Client know
that they have not done anything wrong, but should try another OCSP Server,
since the one they are currently using cannot handle the request
appropriately.

Any feedback on this would be appreciated..


Andrew Sciberras
Software Engineer
Adacel Technologies Ltd


------=_NextPart_000_007E_01C1815F.D38E5040
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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


<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D869175004-07122001>G'day,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D869175004-07122001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D869175004-07122001>I'm =
not sure if this=20
has been discussed before, so please excuse me if it =
has.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D869175004-07122001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D869175004-07122001>Of the =

OCSPResponseStatus&nbsp;codes defined in RFC2560 I am unsure what should =
be used=20
if the following errors occur:</SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
class=3D869175004-07122001>&nbsp;&nbsp;&nbsp; </SPAN></FONT></DIV>
<UL>
  <LI><FONT face=3DArial size=3D2><SPAN class=3D869175004-07122001>The =
OCSP Server=20
  receives a signed request that it cannot verify due to lack of =
information. In=20
  the case where the OCSP Server requires all requests to be signed, I =
would=20
  imagine that the sigRequired or unauthorized errors messages could be =
used as=20
  the ResponseStatus. However, neither of these responses provide the =
Client=20
  with any sort of indication as to what the problem is. =
<BR></SPAN></FONT>
  <LI><FONT face=3DArial size=3D2><SPAN class=3D869175004-07122001>In =
Section=20
  4.1.1,&nbsp;it is&nbsp;stated that the issuerNameHash (and =
issuerKeyHash) are=20
  hashed with an algorithm identified in hashAlgorithm. Section 4.3 then =
states=20
  that an OCSP Server SHALL support SHA1. From what I can tell, it would =
be=20
  reasonable for Clients to use any hashing algorithm they like. =
If&nbsp;the=20
  Server received a request that used a hash algorithm that it didn't =
support,=20
  what should be returned? All I can really think of is successful=20
  ResponseStatus and an unknown CertStatus. However, I feel&nbsp;that a=20
  successful ResponseStatus should not be used if the OCSP Server cannot =
fully=20
  understand/decode/process the request which it is =
given.<BR></SPAN></FONT>
  <LI><FONT face=3DArial size=3D2><SPAN=20
  class=3D869175004-07122001>Unsupported&nbsp;Request Version. If the =
version=20
  number is unsupported is it appropriate to return the malformedRequest =

  status?</SPAN></FONT></LI></UL>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D869175004-07122001>Each =
of the=20
scenarios described above could fit into some of the preexisting status =
codes,=20
however in each case the Client would have created a request that is =
correct,=20
but received a reply which indicates otherwise. Perhaps another error =
response=20
needs to be included that lets the OCSP Client know that they have not =
done=20
anything wrong, but should try another OCSP Server, since the one they =
are=20
currently using cannot handle the request appropriately. =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D869175004-07122001>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D869175004-07122001>Any =
feedback on this=20
would be appreciated..</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D869175004-07122001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Andrew =
Sciberras</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Software Engineer</FONT></DIV>
<DIV><FONT face=3DGeorgia size=3D2>Adacel Technologies Ltd</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_007E_01C1815F.D38E5040--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB9HW0t12466 for ietf-pkix-bks; Sun, 9 Dec 2001 09:32:00 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB9HVv212462 for <[e-mail]>; Sun, 9 Dec 2001 09:31:58 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA25306 for <[e-mail]>; Sun, 9 Dec 2001 18:31:58 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Sun, 9 Dec 2001 18:31:58 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA01192 for <[e-mail]>; Sun, 9 Dec 2001 18:31:56 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA20241 for [e-mail]; Sun, 9 Dec 2001 18:31:55 +0100 (MET)
Date: Sun, 9 Dec 2001 18:31:55 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-pkix-dpv-dpd-req-00.txt
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>
List-ID: <ietf-pkix.imc.org>

here some comments to DPV/DPD


- Ceterum censeo: I'd prefer to have the text in several documents,
  one for DPV and another for DPD, and a third one containing policy 
  management. 
 
- Abstract

  Instead of 'request/response pairs' I propose something like
  'service accessible by a client-server protocol' 

- Section 2:

> These delegated processing provides two primary services: delegated 
> signature validation, delegated path validation and delegated path 
> discovery. Not all clients require both services in all scenarios.

There are only two services. "signature validation" is not here.

Are there clients that require both services in any scenario?

> Some clients have requirements for offloaded path validation and have 
> no need for data acquisition, while some other clients require only 
> delegated path discovery to help them perform their own path 
> validation.

Is 'data acquisition' a synonym for 'path discovery' ? 

chapter 3:

I second Russ's comment about the last paragraph. To what degree a DPV
client 'trusts' the contents of the response is outside of the 
scope of the protocol. Nevertheless tha protocol should allow
a client to trust either in a blind or reproducing way depending
on policy, i.e. a server may be required to return all information
that has led to its decision. 

> The time required to send the target certificate to the validation 
> server, receive the response, and verify the signature on the response, 

The sentence should only say: 'authenticate the response'. There
is no unconditional requirement of having a signature. (see also below)

> Even clients that are able to 
> do their own path validation may rely on a trusted server to do path 
> validation if clients are in an environment where centralized 
> management of validation policies is needed for some applications.

There is also the case where 'centralised validation of certificates'
is a 'MUST' for all client contexts of some applications. For example 
in order to leave centralised traces of such activities, or simply
because in some contexts the trust management performed in
a centralised way. 

chapter 6:

> The Delegated Path Validation (DPV) protocol allows to validate one or 
> more certificate for the current time and according to a single set of 
> rules, called a validation policy. 

I propose:

  The Delegated Path Validation (DPV) protocol allows to validate
  one or more certificate according to a validation policy selected
  by the client and/or the server. A time other than the current 
  time may be usable to determine the validity.


Here is a list of some requirements for a DPV protocol. Some of
them may be already in the actual text.

- Requirements for obtaining a status

  - a method to authenticate a server before sending any request 
    (for example this can be achieved by SSL).

  - a method to authenticate a client (idem or by mail encryption)

  - a method that client and server provide their identity
    in the requests and responses: 'You, the client X, has
    asked me, the server Y, the following question, and
    I, the server Y, with the help of server Z respond.' 
 
  - a way to link a request from the response, i.e., the
    response MUST include links to determine the essential
    parts of the request. (essential to be determined, this
    is said in order to avoid 'response must include a
    copy of the request.')

  - a method to ensure confidentiality of the transport

- Requirements for later verification of the status.
  
  - the server should be able (depending on piolicy) to return all
    information that had been used to determine the validity status
    of a set of certificates.  

  - a method to determine the authenticity of a response
    independantly of the authentication of the server
    communication (signature validation on a signed response
    for example).

  - a long term method to determine the authenticity of a response 
    may be provided.   

  - information to be collected by a client (for example
    from a previous response) may be provided as a hints to the
    server. 

- Relaying requirements: 

  - depending on policy, a server may just impersonate another
    server, i.e., take the responses of another server, and create
    its own reponse out of them. 

  - a server should be able to include the response of a relayed
    server into his response. 

  - a server should be able to simple add another authentication
    scheme to a response from another server (for example by
    using a second signature or a counter signature.)

  - a server that acts as a relay should be able to tell to the
    next server that it is acting on behalf of a end user, and
    the final server should be able to note this in the response. 

  - For relaying, the protocol MUST provide an efficient means
    to detect loops. 
 
  - The DPV protocol should be usable to determine the validity
    of CA certificates in a path.

- Requirements for incomplete answers:
  
  - a server may indicate an incomplete response, 
    and provide a method to update the response later.  


PS


Received: by above.proper.com (8.11.6/8.11.3) id fB9DrCV27715 for ietf-pkix-bks; Sun, 9 Dec 2001 05:53:12 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB9DrA227711 for <[e-mail]>; Sun, 9 Dec 2001 05:53:11 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id D9D65B745; Sun,  9 Dec 2001 14:54:35 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YN33V8TW; Sun, 9 Dec 2001 14:54:35 +0100
Message-ID: <[e-mail]>
Date: Sun, 09 Dec 2001 14:54:28 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-dpv-dpd-req-00.txt & draft-ietf-pkix-dsv-req-00.txt
References: <[e-mail]> <[e-mail]>
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>
List-ID: <ietf-pkix.imc.org>

Denis,

I have three questions/comments regarding your DPV / DPD document:

- I would like to see the signature to be only optional in a DPV response.
You require the DPV response to be integrity protected. But you could
authenticate the server using other means, for example SSL server
authentication.

- A DPV or DPD request can only contain one certificate. Shouldn't it be
possible to include more than one certifiacte in a request?

- Why do I need the optional requestor name in the DPV request and
response? And why is this requestor name not included in the DPD protocol?

Bye - Petra

Denis Pinkas schrieb:

> I have been asked by the co-chairs to prepare a requirements document for
> DPV/DPD. While doing that task, requirements slighly different have been
> identified for DSV. As a result of this request, you will find:
>
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-00.txt
>
> a document which describes a protocol for the validation of CERTIFICATES
> (and for the discovery of certification paths), and
>
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dsv-req-00.txt
>
> a separate document which describes a protocol for the validation of
> DIGITAL SIGNATURES.
>
> Both documents, which share several common points, will be presented
> at the next IETF meeting.
>
> Denis



Received: by above.proper.com (8.11.6/8.11.3) id fB9DeTF26159 for ietf-pkix-bks; Sun, 9 Dec 2001 05:40:29 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB9DeS226153 for <[e-mail]>; Sun, 9 Dec 2001 05:40:28 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 488AAB745; Sun,  9 Dec 2001 14:41:50 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YN33V8TS; Sun, 9 Dec 2001 14:41:49 +0100
Message-ID: <[e-mail]>
Date: Sun, 09 Dec 2001 14:41:42 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-dpv-dpd-req-00.txt
References: <[e-mail]>
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>
List-ID: <ietf-pkix.imc.org>

Russ,

I agree with most of your comments - except the following:

"Housley, Russ" schrieb:

> In section 4, 1st paragraph, I think that we do trust the DPD server to
> return the most current information that is available.  Clearly, this is a
> radically different situation than a DPV server, but it is a security
> relevant point, especially if the DPD client does not have a good source of
> time.  In other words, the DPD client trusts the server to provide up to
> date data, not stale data.

Like Denis I see a DPD server as an untrusted server. A client doesn't need
to trust a DPD server because all information returned is integrity protected
and he can check the content, e.g. the validity period. The client needs to have
a good source of time! Otherwise he couldn't locally validate a certificate.
You must trust an DPD server as much as an LDAP server or an OCSP
responder. They are all untrusted servers, even so you have to trust the
administrator to always update the database in time.

> In section 5, 8th paragraph, I understand the reasons why a client might
> want to perform DPV based on some previous time T.  DPD for  some previous
> time T is another matter, and I do not think that repositories provide the
> information necessary to implement such a service.

I think the DPD protocol MUST provide the possibilty to request and return
cert pathes based on some previous time T. That's an important requirement.
You agree that an DPV request/response need to be based on a previous
time T. Well, if the client only delegates the path discovery but does the
validation locally he may need the certificates from a previous time T.
An implementation of a DPD server MAY not support it or the repositories
MAY not provide this information. In this case the DPD server simply
returns an error.

Petra



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB7KGn910393 for ietf-pkix-bks; Fri, 7 Dec 2001 12:16:49 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB7KGl210389 for <[e-mail]>; Fri, 7 Dec 2001 12:16:47 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Dec 2001 20:16:43 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA14201 for <[e-mail]>; Fri, 7 Dec 2001 15:16:49 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB7KGmv25987 for <[e-mail]>; Fri, 7 Dec 2001 15:16:48 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <YH8311W8>; Fri, 7 Dec 2001 15:16:47 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.76 [10.3.1.76]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YH8311W5; Fri, 7 Dec 2001 15:16:42 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 07 Dec 2001 15:15:55 -0500
Subject: draft-ietf-pkix-dpv-dpd-req-00.txt
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>
List-ID: <ietf-pkix.imc.org>

Denis:

You have done a nice job on the document.  I think that we are close to 
consensus, but I do have a few comments.  I have divided my comments into 
technical and editorial.

Russ

= = = = = = = = = =

TECHNICAL

In section 3, 9th paragraph, I am surprised to see SHALL in a section on 
rationale.  I propose the following:

    Clients can direct the server about to perform path
    validation in accordance with a particular validation
    policy.

In section 3, last paragraph, I do not consider this a statement of 
rationale.  While it is obvious that the client must trust the server, I 
think that a discussion of this point belongs elsewhere.

In section 4, 1st paragraph, I think that we do trust the DPD server to 
return the most current information that is available.  Clearly, this is a 
radically different situation than a DPV server, but it is a security 
relevant point, especially if the DPD client does not have a good source of 
time.  In other words, the DPD client trusts the server to provide up to 
date data, not stale data.

In section 5, 5th paragraph, please change "self-signed certificates" to 
"trust anchors."  While trust anchors are often specified with self-signed 
certificates, other approaches are also effective.

In section 5, 8th paragraph, I understand the reasons why a client might 
want to perform DPV based on some previous time T.  DPD for  some previous 
time T is another matter, and I do not think that repositories provide the 
information necessary to implement such a service.

In section 5, last four paragraphs, the points made in these paragraphs 
belong in section 5.1.  They apply only to DPV.  They do not apply to DPD.

In section 5.2, last three paragraphs, the points made here do not apply to 
policy.  I think that these paragraphs describe protocol requirements.  I 
think these concepts belong in section 7.

In section 6, 1st paragraph, I am concerned about the structure of the MUST 
requirement.  I think that we agree on the concepts, but not on the 
wording.  These are requirements of the protocol, and the protocol MUST 
include support for client defined policies.  Thus, there are three cases 
that the protocol MUST support.  However, implementations of the protocol 
MUST support the first two cases, and implementations MAY also support the 
third case.  The three cases are:

    1. Client uses the DPV server's default policy.  When
       this is done, the response indicates the policy
       that was employed by the DPV server.
    2. Client selects one policy from a set of policies
       offered by the DPV server.  In the extreme case,
       the server only offers one policy.
    3. Client defines a new policy.

In section 6, 2nd paragraph, I am concerned about the structure.  The 
reference to the certificate MUST be unambiguous.  This MAY be accomplished 
by providing the certificate, or using ESSCertID, or something else.

In section 6, I think that the client should be able to get the 
certification path that was constructed by the DPV server and any 
revocation status information that was used to validate it.  Return of this 
information should not be the default, but it should be available in case 
the client wants to archive it.

In section 8.2, last paragraph, I am concerned about the structure.  While 
I agree that the stated conditions MAY apply to any particular policy, the 
protocol MUST support all of the choices.  Further, an additional policy 
alternative ought to permit the server to select any available revocation 
status information.

In section 8.3, 1st paragraph, I am concerned about the structure.  The 
protocol MUST allow the client to specify end-entity certificate requirements.

In section 8.4, I am do not see a requirement statement.  Is the protocol 
required to support cautionary period in the request to specify a new policy?

In section 9, I am concerned about the structure.  While I agree that the 
stated conditions MAY apply to any particular policy, the protocol MUST 
support all of these capabilities.

In section 10, 1st paragraph, I am concerned about the structure.  Is the 
protocol required to support policy definition?  This says that this 
capability is OPTIONAL.  I think that the protocol MUST include the 
capability, but that the capability is optional to implement.

In section 11, 1st paragraph, I have a strong disagreement.  The DPV server 
out to be able to return this information.  Most times it will not be 
requested, but I think that the capability ought to be available to all 
clients.

In section 11, 2nd paragraph, please delete this paragraph.  I am not 
concerned with any particular words in it, but I am concerned with the 
reference.  I do not want to delay publication of this document while 
[DSV-REQ] is being debated.  Please break the linkage.

In section 12, clients MUST trust their DPV server.

EDITORIAL

The subtitle and the upper left heading on the title page have two 
different file names.  I believe that the subtitle is correct.

Please change "rational" to "rationale" throughout the document.

Please change "end-certificate" to "end-entity certificate" throughout the 
document.

Please use the term "trust anchor" throughout the document.  The term "root 
key" is also used, but I do not think that this term is appropriate since 
the validity period and issuer name are needed as well as the public key.

In the Abstract (Section 1), 3rd paragraph, please change "leaf 
certificate" to "end-entity certificate."  Also, the Abstract does not 
usually get a section number.

In Section 2, please merge the two paragraphs.  The last sentence of the 
first paragraph really says the same thing as the whole second 
paragraph.  I suggest:

    These delegated processing provides two primary services:
    delegated signature validation, delegated path validation and
    delegated path discovery. Some clients require a server to
    perform path validation and have no need for data acquisition,
    while other clients require only delegated path discovery in
    support of local path validation.

In section 3, paragraph 7, please reword the second sentence:

    Even clients that are able to do their own path validation
    may rely on a trusted server to do path validation if
    centralized management of validation policies is needed.

Please delete the last paragraph in section 4.

I do not understand the 6th paragraph in section 5.  I think that it says 
different policies may be constructed to support the construction of 
certification paths in support of the provision of different security 
services.  Please reword.

In section 5.1, last paragraph, please change "leaf certificate" to 
"end-entity certificate."

In section 7, 1st paragraph, please change "to use" to "the client to use."

In section 7, 9th paragraph, item number 3, please change the comma to a 
period.

In section 8.2, 2nd paragraph, please change "It can then specified if" to 
"The policy can specify the source of revocation status information:"

Please add RFC 2634 to the list of references.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB7F5BY22572 for ietf-pkix-bks; Fri, 7 Dec 2001 07:05:11 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB7F5A222568 for <[e-mail]>; Fri, 7 Dec 2001 07:05:10 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Dec 2001 15:05:05 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA18762 for <[e-mail]>; Fri, 7 Dec 2001 10:05:02 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB7F50X27069 for <[e-mail]>; Fri, 7 Dec 2001 10:05:00 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <YH83D0WW>; Fri, 7 Dec 2001 10:04:59 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.127 [10.3.1.127]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YH83D0WS; Fri, 7 Dec 2001 10:04:56 -0500
From: "Housley, Russ" <[e-mail]>
To: "Eissa, Mohamed" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 06 Dec 2001 19:14:47 -0500
Subject: Re: Types of CDP in RFC2459
In-Reply-To: <[e-mail]. com>
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>
List-ID: <ietf-pkix.imc.org>

RFC 2459 includes the syntax:

    CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

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

       GeneralName ::= CHOICE {
            otherName                       [0]     OtherName,
            rfc822Name                      [1]     IA5String,
            dNSName                         [2]     IA5String,
            x400Address                     [3]     ORAddress,
            directoryName                   [4]     Name,
            ediPartyName                    [5]     EDIPartyName,
            uniformResourceIdentifier       [6]     IA5String,
            iPAddress                       [7]     OCTET STRING,
            registeredID                    [8]     OBJECT IDENTIFIER}

Each of these name forms can be used.  For example, directoryName points to 
an entry in an X.500 directory.

In the PKIX WG we did not make any statements about name forms associated 
with non-Internet protocols.  The standards groups associated with those 
protocols should construct such profiles, if approriate.

Russ

At 09:12 AM 12/6/2001 -0800, Eissa, Mohamed wrote:

>Hi all,
>In RFC2459 (Internet X.509 Public Key Infrastructure Certificate and CRL
>Profile)  http://www.ietf.org/rfc/rfc2459.txt
>4.2.1.14 CRL Distribution Points
>         The CRL distribution points extension identifies how CRL information
>is obtained. The extension SHOULD be non-critical, but this profile
>recommends support for this extension by CAs and applications. Further
>discussion of CRL management is contained in section 5.
>         If the cRLDistributionPoints extension contains a
>DistributionPointName of type URI, the following semantics MUST be assumed:
>the URI is a pointer to the current CRL for ...
>
>
>Can someone please help me to list what are the other possible types for CDP
>if it is not a URI?
>
>Mohamed Eissa
>Intel of Canada


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6NE4315328 for ietf-pkix-bks; Thu, 6 Dec 2001 15:14:04 -0800 (PST)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6NE2215324 for <[e-mail]>; Thu, 6 Dec 2001 15:14:02 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id SAA16265; Thu, 6 Dec 2001 18:14:03 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 06 Dec 2001 18:13:56 -0500
To: Denis Pinkas <[e-mail]>, pkix <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: PKIX meeting agenda for Salt Lake City
In-Reply-To: <[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>
List-ID: <ietf-pkix.imc.org>

Denis (& the list),

As requested, here is the draft PKIX WG agenda.  I say "draft" since there 
are a couple of slots with TBDs for the speakers.  I believe I've covered 
all the active documents, excepting logotypes and certstore, as the authors 
will not be in Salt Lake.  I expect these to be discussed in Minneapolis.

If there are other topics I've missed please email me and I'll work them 
into the schedule.  I'm looking forward to seeing all of you next week and 
having a productive meeting!

Thanks,

Tim Polk

-------------------------------------------------draft PKIX meeting 
agenda------------------------------------


PKIX WG (pkix-wg) Agenda
52nd IETF Meeting

TUESDAY, December 11 at 0900-1130
=================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

I.      Agenda bashing                  Tim Polk        (1 min.)
II.     Document Status Review          Tim Polk        (5 min.)
III.    PKIX Certificate And CRL Profile and Algorithms
         draft-ietf-pkix-ipki-new-part1-11.txt
         draft-ietf-pkix-ipki-pkalgs-05.txt
         a.      Status                          Russ Housley    (5 min.)
         b.      Interoperability testing                Jim 
Schaad      (10 min.)
         c.      Implementation Experience       Steve Hanna     (15 min.)
IV.     Attribute Certificate Profile           Steve Farrell   (5 min.)
         draft-ietf-pkix-ac509prof-09.txt
V.      PKIX Roadmap                            TBD             (5 min.)
VI.     Delegated Path Development/Delegated Path Validation
         a.      Requirements Draft              Denis Pinkas    (10 min.)
                 draft-ietf-pkix-dpd-dpv-req-00.txt
         b.      Protocol Draft                  Russ Housley    (10 min.)
                 draft-ietf-pkix-scvp-06.txt
VII.    Certificate Management Profiles
         a.      CMP progression                 Tim Polk        (5 min.)
         draft-ietf-pkix-rfc2511bis-03.txt
         draft-ietf-pkix-rfc2510bis-05.txt
         b.      CMC progression                 Jim Schaad      (5 min.)
         draft-ietf-pkix-rfc2797-bis-01.txt
         c.      CMC development                 Jim Schaad      (5 min.)
         draft-ietf-pkix-cmc-trans-00.txt
         draft-ietf-pkix-cmc-compl-00.txt
         draft-ietf-pkix-cmc-archive-00.txt
VIII.   Proxy Draft                             TBD             (5 min.)
         draft-ietf-pkix-proxy-00.txt
IX.     Delegated Signature Validation          Denis Pinkas    (10 min.)
         draft-ietf-pkix-dsv-req-00.txt
X.      Policy Framework                        TBD             (5 min.)
         draft-ietf-pkix-ipki-new-rfc2527-00.txt
XI.     Supplemental Algorithms                 Ari Singer      (5 min.)
         draft-ietf-pkix-pkalgs-supp-00.txt
XII.    LDAP documents                  David Chadwick  (10 min.)
         draft-ietf-pkix-ldap-schema-02.txt
         draft-ietf-pkix-ldap-v3-04.txt
XIII.   Liaison/New Work Items
         a.      Policy Requirements for Time-Stamping
                 Authorities (ETSI)                      Denis 
Pinkas    (10 min.)
         b.      The Missing Link for Large PKIs Denis Pinkas    (5 min.)





At 04:20 PM 12/6/01 +0100, Denis Pinkas wrote:

>To the co-chairs,
>
>Would'nt it be nice to get the agenda of the PKIX meeting in advance ?
>
>:-)
>
>Denis



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6HBJA24166 for ietf-pkix-bks; Thu, 6 Dec 2001 09:11:19 -0800 (PST)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6HBI224161 for <[e-mail]>; Thu, 6 Dec 2001 09:11:18 -0800 (PST)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id RAA23768 for <[e-mail]>; Thu, 6 Dec 2001 17:11:19 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001120609103214076 ; Thu, 06 Dec 2001 09:10:32 -0800
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id <X7DKKGHL>; Thu, 6 Dec 2001 09:11:20 -0800
Message-ID: <[e-mail]>
From: "Eissa, Mohamed" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Types of CDP in RFC2459
Date: Thu, 6 Dec 2001 09:12:48 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>
List-ID: <ietf-pkix.imc.org>

Hi all,
In RFC2459 (Internet X.509 Public Key Infrastructure Certificate and CRL
Profile)  http://www.ietf.org/rfc/rfc2459.txt
4.2.1.14 CRL Distribution Points 
	The CRL distribution points extension identifies how CRL information
is obtained. The extension SHOULD be non-critical, but this profile
recommends support for this extension by CAs and applications. Further
discussion of CRL management is contained in section 5. 
	If the cRLDistributionPoints extension contains a
DistributionPointName of type URI, the following semantics MUST be assumed:
the URI is a pointer to the current CRL for ...


Can someone please help me to list what are the other possible types for CDP
if it is not a URI?

Mohamed Eissa
Intel of Canada




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB6FKdx14152 for ietf-pkix-bks; Thu, 6 Dec 2001 07:20:39 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6FKb214148 for <[e-mail]>; Thu, 6 Dec 2001 07:20:37 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA29426 for <[e-mail]>; Thu, 6 Dec 2001 16:21:06 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA16276 for <[e-mail]>; Thu, 6 Dec 2001 16:20:02 +0100
Message-ID: <[e-mail]>
Date: Thu, 06 Dec 2001 16:20:05 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: PKIX meeting agenda for Salt Lake City
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>
List-ID: <ietf-pkix.imc.org>

To the co-chairs,

Would'nt it be nice to get the agenda of the PKIX meeting in advance ?

:-)

Denis


Received: by above.proper.com (8.11.6/8.11.3) id fB5Ia9l19118 for ietf-pkix-bks; Wed, 5 Dec 2001 10:36:09 -0800 (PST)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Ia7219113 for <[e-mail]>; Wed, 5 Dec 2001 10:36:07 -0800 (PST)
Received: from arport (t6o69p73.telia.com [213.64.110.193]) by maila.telia.com (8.11.6/8.11.6) with SMTP id fB5Ia7t10521 for <[e-mail]>; Wed, 5 Dec 2001 19:36:07 +0100 (CET)
Message-ID: <004a01c17dbb$bf74e530$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Too limiting: One subject type/CA?
Date: Wed, 5 Dec 2001 19:36:25 +0100
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 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>
List-ID: <ietf-pkix.imc.org>

List,
I'm plotting with a scheme that would benefit a *lot* if CAs restricted
issuance to various subjects (e-mail certs, ID-card-like certs, web-server
certs etc.) to one subject type (and CPS) per CA-cert/key.  It *seems* that
this is the case for most (all?) commercial vendors but I would like to
know if anybody has other input on this.

Actually it becomes very akward for any RP scheme, after accepting
a certain CA, not be able to *easy* figure out if the EE-cert is an identity
certificate or server ditto.   To read and interpret various non-standard
(de-facto-wise rather than w.r.t. PKIX) extensons is not an option if
we are talking open PKI.

Anders



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB5DjFA29392 for ietf-pkix-bks; Wed, 5 Dec 2001 05:45:15 -0800 (PST)
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5DjD229388 for <[e-mail]>; Wed, 5 Dec 2001 05:45:13 -0800 (PST)
Received: from steiner.cc.vt.edu (IDENT:[e-mail] [10.1.1.14]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id fB5DjEj403169 for <[e-mail]>; Wed, 5 Dec 2001 08:45:14 -0500 (EST)
Received: from vaio (h80ad2653.async.vt.edu [128.173.38.83]) by steiner.cc.vt.edu (Mirapoint) with SMTP id AGL54601; Wed, 5 Dec 2001 08:45:12 -0500 (EST)
From: "Markus Lorch" <[e-mail]>
To: <[e-mail]>
Subject: Re: Names in Proxy Certificate
Date: Wed, 5 Dec 2001 08:51:04 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
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>
List-ID: <ietf-pkix.imc.org>

Steve,

the application of attribute certificates to the GSI and to proxy
certificates is work we are currently looking into here at Virginia
Tech in the context of a collaborative high-level grid interface.
Russ Housley had pointed out the question to what certificate
our attribute certs should be bound if proxy certs are used in a recent
meeting at VT. See comments on our intended usage at end of your quote:

>>Second, in PKIX, we allow attribute certificates to be associated with
>>subject DN or issuer/serial.  Wouldn't it be useful for authorizations in
>>attribute certificates issued against the long-term certificate to apply
>>to the proxy certificates as well?  This seems possible if the attribute
>>certificate uses the subject DN and the proxy certificates also contain
>>this same DN.

>Yes, I can certainly imagine this being useful.

>Perhaps this is motivation for changing the approach to proxy subject
>names.  For example, we might consider carrying the EEC subject in the
>proxy unchanged, check it in the path validation to make sure it identical,
>and use the KeyIdentifiers for path discovery.  But there is still the
>question of what goes in the issuer field.

>But an interesting question with the combination of attribute certs and
>proxy certs is what constraints might you want to put on this?  Do you want
>to be able to associate attribute certs with just EEC's, but not their
>proxies.  Or just with proxies?  Or just with a particular proxy?  Or a set
>of proxies signed by a particular proxy?   Or some other set of proxies?  I
>can imagine arguments for all of these.  This would clearly be an
>interesting avenue to pursue.

Our plan is to use proxy certs for authentication and granting of a basic
set of user rights and then use attribute certs to grant additional rights,
e.g.
for group collaboration and role support. Collaboration support is the main
concern.
We envision users (end entities) to issue to each other ACs that convey
access rights
to files, program components, devices etc.

Right now we believe a viable approach might be to bind the ACs to the DN or
the
issuer/serial combination of the EEC. The path validation of a PC would
give us this information. We did not think of having ACs for proxies that
differ
from the set of ACs associated with the delegating EEC. However, this might
be
an interesting case to consider. If we use ACs also for proxies, a subset of
an
entities rights can be created through a new, more restricted PCs together
with
a set of attributes associated with this PC. This would allow for finer
grained
control over which PCs can actually be used with which ACs. In turn this
would
require that a process delegating a PC can also delegate ACs which appears
to make
this system more complex than originally envisioned.
A resource would have to do a path validation on the PC as well as an
independent
path validation on an AC. Also as PCs are rather short lived it may lead to
a number of problems when the PC expires. Right now the PC draft proposes to
use
random subject names, thus we could not bind such ACs to the subject of the
PC
but only to the serial and thus bind it to the lifetime of the PC.

Markus

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Markus Lorch
Graduate Student in Computer Science
Virginia Tech
http://csgrad.cs.vt.edu/~mlorch



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB530PO27908 for ietf-pkix-bks; Tue, 4 Dec 2001 19:00:25 -0800 (PST)
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB530N227904 for <[e-mail]>; Tue, 4 Dec 2001 19:00:23 -0800 (PST)
Received: from monkeyboy2001.mcs.anl.gov (vpnclient158.mcs.anl.gov [140.221.11.158]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id VAA22326; Tue, 4 Dec 2001 21:00:15 -0600
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 04 Dec 2001 20:55:48 -0600
To: "Housley, Russ" <[e-mail]>
From: Steve Tuecke <[e-mail]>
Subject: Re: Names in Proxy Certificate 
Cc: [e-mail]
In-Reply-To: <[e-mail]. com>
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>
List-ID: <ietf-pkix.imc.org>

At 11:19 AM 12/3/2001, Housley, Russ wrote:
>All:
>
>Please excuse my previous posting with this subject.  I got interrupted 
>while composing the note, and sent it when I wanted to save it and work on 
>it some more.  I hope I have done a better job this time.
>
>In draft-ietf-pkix-proxy-01, section 6.4, the authors talk about end 
>entity names.  Mostly the specification talks about an approach that was 
>rejected.  Finally, I think that the conclusion is that the parent of the 
>proxy certificate contains the real identity information.  Please correct 
>me if I am misreading the text (attached below for simplicity).

Note that section 6.4 is the commentary section.  It is not intended to be 
the specification, but rather to help give some insight on the 
specification (e.g. what was considered but rejected).  At some point it 
may make sense to move this out to a separate informational draft, but we 
figured it was better to keep it all in one spot to begin with.

The relevant portions of the spec here are sections 3.1 and 3.2.

>If I have it right, then have a few concerns.
>
>First, in PKIX, we require that all issuers have a subject DN.  So, empty 
>DNs cannot be used in the long-term certificates if proxy certificates are 
>to be associated with them.  Further, the proxy certificate needs to 
>include a subject DN if proxy certificates are permitted to issue 
>subordinate proxy certificates.

First, let me say that we're not at all married to this particular approach 
to subjects and issuers.  What is in this draft is, in fact, different from 
what we did in the Globus Toolkit.  In writing this draft, we changed the 
approach (though not the proxy concept) to try to make it live better with 
son-of-2459.  But in going back to son-of-2459, I see I missed the relevant 
statement here in 4.1.2.4, of "The issuer field MUST contain a non-empty 
distinguished name (DN)."  I don't know how I missed this one!

The problem (and perhaps why I subconsciously ignored this issuer 
requirement :-) is that I think the current son-of-2459 language puts us 
between a rock and a hard place.  As your comment suggests, what if the End 
Entity Certificate (EEC, or what I think you are referring to as the 
long-term cert) has an empty subject field, and instead only has a 
subjectAltName?  What do we use as the issuer in proxy that is signed by 
that EEC?

Maybe the best thing to do is explain what we are trying to accomplish, 
what I observe the constraints to be, and you might be able to advise us of 
an approach that lives better with son-of-2459.

First, what are we trying to accomplish...  The point of proxies is that we 
are specifically not trying to create a new identity.  Rather, we are 
trying to define a mechanism by which a proxy can be created that is 
associated back only to the subject or subjectAltName of the EEC that is at 
the top of the proxy signing chain.  In essence, we want to bind a new key 
pair back to the subject of the EEC, so that the holder of the new private 
key can make a verifiable claim on the EEC subject name.

What is the nature of that claim?  That's really up to the authorizing 
party.  Having authenticated with a party that is using a proxy 
certificate, and verified its path up through the proxy chain, EEC, and CA, 
I know that this party has a valid proxy that was issued by an EEC with a 
particular subject name.  In practice, the way that we use this is as a way 
to delegate authorization rights.  That is, if I have authenticated a proxy 
that is tied to an EEC with a subject of "Steve", then I apply whatever 
authorization that I would normally apply to "Steve".

And this is where the proxyRestriction field (3.6.1.3) comes into 
play.  What the holder of an EEC typically wants to do is issue a proxy 
that implies a subset of the rights normally associated with that EEC 
subject.  So when such a proxy is presented to me, I would apply the 
intersection of whatever authorization rights I would normally grant to 
"Steve", with those that are defined in the proxyRestriction field of all 
proxies in the signing path.

In the current Globus Toolkit code, the way we handle subject and issuers 
is that we require that the EEC subject be a DN, and then we extend that DN 
with a "/CN=proxy" attribute in each proxy certificate.  Then in the path 
validation we check that the proxy subject is the same as the issuer, 
except for an extra "/CN=proxy" attribute.

So now what are the issues and constraints in making this play nicely with 
son-of-2459:

   * What do we do if the EEC does not have a subject, but instead only has 
a subjectAltName?  Obviously, the approach that we used in the Globus 
Toolkit doesn't work in this case.  And it doesn't seem particularly 
satisfying to say that you can only create a proxy certificate from an EEC 
that has a subject DN.

   * One of the uses of the subject is for path discovery.  So whatever 
approach we choose needs to address this.  What we did in this draft is 
give the proxy subjectAltName a (statistically) unique name, so that the 
path can be discovered from these names.  Another option would be to use 
(or invent) a different field for path discovery, such as 
SubjectKeyIdentifier and AuthorityKeyIdentifier.

   * If we choose a different field for path discovery, this obviously 
liberates us some with respect to the subject and issuer.  Nonetheless, 
requiring a non-empty issuer still seems like a problem.  But ignoring that 
for the moment, what would we want for the subject or 
subjectAltName?  Would it just be a duplicate of the EEC's?  Are there any 
issues with have multiple certificates with the same subject, even though 
the proxies are clearly marked as such with a critical extensions?

   * We must be very careful to not allow proxies to carry, or somehow 
imply, the subject of some other EEC than the one at the top of the proxy 
signing chain.  It seems we have basically 2 choices.  Either make the 
subject (or subjectAltName) meaningless and ignore it.  Or give it meaning 
(e.g. carry along the EEC subject) and check it in the path validation code 
so that some other subject cannot be substituted.  We went with the former 
(modulo path discovery), in the interest of avoiding yet another thing that 
needs to be checked in the path validation code.  But I'd also be 
comfortable with the latter.

Anyway, I'm eager to hear if you have any suggestions for alternative 
approaches.

>Second, in PKIX, we allow attribute certificates to be associated with 
>subject DN or issuer/serial.  Wouldn't it be useful for authorizations in 
>attribute certificates issued against the long-term certificate to apply 
>to the proxy certificates as well?  This seems possible if the attribute 
>certificate uses the subject DN and the proxy certificates also contain 
>this same DN.

Yes, I can certainly imagine this being useful.

Perhaps this is motivation for changing the approach to proxy subject 
names.  For example, we might consider carrying the EEC subject in the 
proxy unchanged, check it in the path validation to make sure it identical, 
and use the KeyIdentifiers for path discovery.  But there is still the 
question of what goes in the issuer field.

But an interesting question with the combination of attribute certs and 
proxy certs is what constraints might you want to put on this?  Do you want 
to be able to associate attribute certs with just EEC's, but not their 
proxies.  Or just with proxies?  Or just with a particular proxy?  Or a set 
of proxies signed by a particular proxy?   Or some other set of proxies?  I 
can imagine arguments for all of these.  This would clearly be an 
interesting avenue to pursue.

-Steve

>Russ
>
>
>
>TEXT FROM THE DRAFT ...
>
>6.4 Carrying Along the End Entity Subject
>
>    Another suggestion was to include the subject of the signing EEC as
>    an informational field in the PC.  This would allow an authorizing
>    process to use only information in the final PC in the chain to
>    determine identity, and not need to walk the chain in order to find
>    out the subject (or subjectAltName) of the EEC that the PC is
>    derived from.
>
>    This approach was rejected for the following reasons:
>
>    *  It would be easy to spoof this informational field.  For example,
>       a PC with an informational subject of "Steve" could be used to
>       create a PC with an informational subject set to "Doug".  This
>       leaves us with two alternatives:
>
>       * We can augment the path validation to check that this
>         informational field of the PC is the same as in the signing PC
>         or EEC.  But this is not desirable, as it complicates the path
>         validation.
>
>       * But if we do not validate this field, we cannot trust the
>         contents of this informational field.  So then there is no
>         point in including this informational field.
>
>    *  Upon closer examination, there is a lot of information in the
>       certificate chain that may be needed during authorization, such
>       as the number of levels of delegation, the CA (or multiple levels
>       of CAs) who signed the original EEC, the constraints and keyUsage
>       values of the signing EEC, possibly Certificate Policies
>       associated with CAs or IAs.  All of these require essentially the
>       same amount of work as retrieving the subject of the EEC that
>       signed the PC.  So why threat the EEC subject specially by
>       including it in an information field?
>
>    In the end, just including the EEC subject name does not seem to be
>    sufficiently useful to justify the addition of another field and the
>    work of verifying that name during the path validation.
>
>    Therefore, to determine the identity of a PC for authorization
>    purposes, the subject of the EEC must be retrieved directly from the
>    EEC in the signing chain.  This approach also has the beneficial
>    side effect of further stressing that a Proxy Certificate has no
>    identity of its own, but rather inherits it from its signing EEC.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3L0AF16754 for ietf-pkix-bks; Mon, 3 Dec 2001 13:00:10 -0800 (PST)
Received: from sottmxs02.entrust.com ([216.191.251.52]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3L09216750 for <[e-mail]>; Mon, 3 Dec 2001 13:00:09 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <XZTVMLVZ>; Mon, 3 Dec 2001 15:59:21 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-03.txt
Date: Mon, 3 Dec 2001 15:59:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17C3D.61224650"
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>
List-ID: <ietf-pkix.imc.org>

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_01C17C3D.61224650
Content-Type: text/plain

Hi Francois,

Thanks again for keeping us all up-to-date and for doing your part to keep
various specifications in sync!

I will update 2511bis when I update 2510bis (i.e., immediately after Salt
Lake City) and re-submit both.

Carlisle.


> ----------
> From:
> [e-mail][SMTP:[e-mail]]
> Sent: 	Monday, December 03, 2001 12:49 PM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-03.txt
> 
> Hi Carlisle,
> 
> I understand that you have submitted an update to rfc2511bis, since that
> draft was due to expire this month and that it is completely unchanged,
> other than to adjust the publication and expiry dates appropriately.
> 
> Since PKCS #11 v2.11 was published in June 2001
> (http://www.rsa.com/rsalabs/pkcs/pkcs-11/index.html), this Internet Draft
> should now refer to this version under the references under Section 9.  In
> addition, your comment about the encValue field under Section 6.4 and
> Appendix C could now be amended to remove the exception about D-H
> algorithm
> OID and parameters since ANSI X9.42 mechanisms are now covered under PKCS
> #11 v2.11.  Note also that your comment should refer to Section 12.11 of
> PKCS #11, which is about wrapping/unwrapping private keys, instead of
> Section 12.9.
> 
> Feel free to distribute this comment and your response on the mailing list
> since I am not currently a member of the PKIX mailing list, but I only
> monitor its status on the PKIX web site.
> 
> Best regards,
> 
> Francois
> ---------------------------------
> Francois Rousseau
> IT Standards, Senior Advisor - CSE
> Conseiller Superieur, Normes TI - CST
> [e-mail]
> [phone]
> Edward Drake Building
> 1500 Bronson, Ottawa, Ontario, K1G 3Z4
> 

------_=_NextPart_001_01C17C3D.61224650
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-03.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Francois,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Thanks =
again for keeping us all up-to-date and for doing your part to keep =
various specifications in sync!</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I will =
update 2511bis when I update 2510bis (i.e., immediately after Salt Lake =
City) and re-submit both.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail][SMTP:[e-mail]=
.CA]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, December 03, 2001 12:49 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-03.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I understand that you have submitted =
an update to rfc2511bis, since that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">draft was due to expire this month =
and that it is completely unchanged,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">other than to adjust the publication =
and expiry dates appropriately.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Since PKCS #11 v2.11 was published in =
June 2001</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(</FONT><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.rsa.com/rsalabs/pkcs/pkcs-11/index.html" =
TARGET=3D"_blank">http://www.rsa.com/rsalabs/pkcs/pkcs-11/index.html</A>=
</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">), this Internet Draft</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should now refer to this version =
under the references under Section 9.&nbsp; In</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">addition, your comment about the =
encValue field under Section 6.4 and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Appendix C could now be amended to =
remove the exception about D-H algorithm</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OID and parameters since ANSI X9.42 =
mechanisms are now covered under PKCS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">#11 v2.11.&nbsp; Note also that your =
comment should refer to Section 12.11 of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PKCS #11, which is about =
wrapping/unwrapping private keys, instead of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Section 12.9.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Feel free to distribute this comment =
and your response on the mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">since I am not currently a member of =
the PKIX mailing list, but I only</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">monitor its status on the PKIX web =
site.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Francois</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Francois Rousseau</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IT Standards, Senior Advisor - =
CSE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Conseiller Superieur, Normes TI - =
CST</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">[e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[phone]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Edward Drake Building</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1500 Bronson, Ottawa, Ontario, K1G =
3Z4</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C17C3D.61224650--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3JrQj14385 for ietf-pkix-bks; Mon, 3 Dec 2001 11:53:26 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB3JrO214381 for <[e-mail]>; Mon, 3 Dec 2001 11:53:24 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Dec 2001 19:53:22 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA08655 for <[e-mail]>; Mon, 3 Dec 2001 14:53:18 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB3JrAY28709 for <[e-mail]>; Mon, 3 Dec 2001 14:53:10 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <YFW8S7A6>; Mon, 3 Dec 2001 14:48:38 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.11 [10.3.1.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YFW8SZF7; Mon, 3 Dec 2001 12:19:44 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 03 Dec 2001 12:19:00 -0500
Subject: Names in Proxy Certificate 
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>
List-ID: <ietf-pkix.imc.org>

All:

Please excuse my previous posting with this subject.  I got interrupted 
while composing the note, and sent it when I wanted to save it and work on 
it some more.  I hope I have done a better job this time.

In draft-ietf-pkix-proxy-01, section 6.4, the authors talk about end entity 
names.  Mostly the specification talks about an approach that was 
rejected.  Finally, I think that the conclusion is that the parent of the 
proxy certificate contains the real identity information.  Please correct 
me if I am misreading the text (attached below for simplicity).

If I have it right, then have a few concerns.

First, in PKIX, we require that all issuers have a subject DN.  So, empty 
DNs cannot be used in the long-term certificates if proxy certificates are 
to be associated with them.  Further, the proxy certificate needs to 
include a subject DN if proxy certificates are permitted to issue 
subordinate proxy certificates.

Second, in PKIX, we allow attribute certificates to be associated with 
subject DN or issuer/serial.  Wouldn't it be useful for authorizations in 
attribute certificates issued against the long-term certificate to apply to 
the proxy certificates as well?  This seems possible if the attribute 
certificate uses the subject DN and the proxy certificates also contain 
this same DN.

Russ



TEXT FROM THE DRAFT ...

6.4 Carrying Along the End Entity Subject

    Another suggestion was to include the subject of the signing EEC as
    an informational field in the PC.  This would allow an authorizing
    process to use only information in the final PC in the chain to
    determine identity, and not need to walk the chain in order to find
    out the subject (or subjectAltName) of the EEC that the PC is
    derived from.

    This approach was rejected for the following reasons:

    *  It would be easy to spoof this informational field.  For example,
       a PC with an informational subject of "Steve" could be used to
       create a PC with an informational subject set to "Doug".  This
       leaves us with two alternatives:

       * We can augment the path validation to check that this
         informational field of the PC is the same as in the signing PC
         or EEC.  But this is not desirable, as it complicates the path
         validation.

       * But if we do not validate this field, we cannot trust the
         contents of this informational field.  So then there is no
         point in including this informational field.

    *  Upon closer examination, there is a lot of information in the
       certificate chain that may be needed during authorization, such
       as the number of levels of delegation, the CA (or multiple levels
       of CAs) who signed the original EEC, the constraints and keyUsage
       values of the signing EEC, possibly Certificate Policies
       associated with CAs or IAs.  All of these require essentially the
       same amount of work as retrieving the subject of the EEC that
       signed the PC.  So why threat the EEC subject specially by
       including it in an information field?

    In the end, just including the EEC subject name does not seem to be
    sufficiently useful to justify the addition of another field and the
    work of verifying that name during the path validation.

    Therefore, to determine the identity of a PC for authorization
    purposes, the subject of the EEC must be retrieved directly from the
    EEC in the signing chain.  This approach also has the beneficial
    side effect of further stressing that a Proxy Certificate has no
    identity of its own, but rather inherits it from its signing EEC. 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3FqVM29133 for ietf-pkix-bks; Mon, 3 Dec 2001 07:52:31 -0800 (PST)
Received: from mnmai05.mn.mediaone.net (mnmai05.mn.mediaone.net [24.131.1.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3FqU229124 for <[e-mail]>; Mon, 3 Dec 2001 07:52:30 -0800 (PST)
Received: from bpsi.net (nic-245-c18-151.mn.mediaone.net [24.245.18.151]) by mnmai05.mn.mediaone.net (8.11.1/8.11.1) with ESMTP id fB3Fqvu26669; Mon, 3 Dec 2001 10:52:57 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 03 Dec 2001 09:53:57 -0600
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Farrell <[e-mail]>, PKIX List <[e-mail]>
Subject: Re: Review Comments:  draft-ietf-sacred-protocol-bss-00.txt
References: <[e-mail]>
Content-Type: text/html; 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>
List-ID: <ietf-pkix.imc.org>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Oops, wrong list -- please ignore.
<p>Apparently I shouldn't be sending out list messages from one machine
while, at same time, I'm trying to get a new Intenet connection running
on other machines :-)
<p>Best Regards,
<p>Dale Gustafson
<br>&nbsp;</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3Fd3j28336 for ietf-pkix-bks; Mon, 3 Dec 2001 07:39:03 -0800 (PST)
Received: from mnmai05.mn.mediaone.net (mnmai05.mn.mediaone.net [24.131.1.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Fd2228332 for <[e-mail]>; Mon, 3 Dec 2001 07:39:02 -0800 (PST)
Received: from bpsi.net (nic-245-c18-151.mn.mediaone.net [24.245.18.151]) by mnmai05.mn.mediaone.net (8.11.1/8.11.1) with ESMTP id fB3FdDu21350; Mon, 3 Dec 2001 10:39:18 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 03 Dec 2001 09:40:14 -0600
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Farrell <[e-mail]>
CC: PKIX List <[e-mail]>
Subject: Review Comments:  draft-ietf-sacred-protocol-bss-00.txt
Content-Type: text/html; 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>
List-ID: <ietf-pkix.imc.org>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Stephen,
<p>A few comments on the latest revision of the SACRED protocol specification.
<p>2.1.4 Password Change
<p>Perhaps the terminology can be clarified to differentiate the passwords
involved;&nbsp; one password may be needed for the authentication/session
security method (when SRP-3 is used in this document); the other (2nd)
password is used to derive a secret key that provides persistent encryption
for the credential per se.
<p>Some have suggested that server implementations may want to ensure the
two passwords are always the same (e.g., for user convenience).
<p>From a security standpoint, it would be preferrable that the server
does not need to have access to the credential password -- or at least
the protocol does not require the server to handle the password in it's
plaintext form for change password (or any other) function.
<br>&nbsp;
<p>2.1.5 Credential Upload
<p>The current text uses different forms of the Upload request to;&nbsp;
add a new credential, update (replace) an existing credential, or delete
a credential.&nbsp; This seems like it could lead to confusion when multiple
credentials are being accessed from several internet devices.
<p>Client software should be able to allow the user to clearly see/verify
what they are overwriting or deleting (assuming that such decisions are
not always easily reversed).
<br>&nbsp;
<p>2.2 Session Security
<p>Allowing clients to support either authentication/session security method
(and requiring servers to support both) is a big workability improvement.
<p>This is of paramount importance for SACRED because fitting all needed
functions into memory constrainedROM or firmware-based internet devices
is often way harder than it looks.&nbsp; We may want to add some words
to that effect.
<br>&nbsp;
<p>2.4 Handling Multiple Credentials for an Account
<p>Similar comment to 2.1.5.
<p>Should be possible for the user to manage multiple credentials on a
server in a airly controlled fashion.
<br>&nbsp;
<p>3.2 Credential Format
<p>The format for xbulk:pkcs-15 may need to be defined in this document
(if/as needed to satisfy current IETF guidelines for referenced standards).
<br>&nbsp;
<p>4. BEEP Profile for SACRED
<p>Stephen mentioned recently that SACRED is using BEEP but the XML groups
appear to be committed to SOAP and SAML.
<p>Since the transactions defined in this document are very simple (generally,
a one message client request with a one message server reply), it's not
clear to me how much elegance we need at the session layer other than setting
up a security environment to protect the transaction data during network
transfer and clearly identifying the data types.
<p>We began with the simple notion of requiring user login via secure password
(or equivalent method) to ensure credentials are delivered to the rightful
user and no others.&nbsp; I assume we'd strongly prefer to retain that
level of functionality and flexibility.
<p>Is BEEP the right direction here?
<br>&nbsp;
<p>5. IANA Considerations
<p>&nbsp;... IANA registers the BEEP profile specified in Section <u>4</u>
...
<br>&nbsp;
<p>6. Security Considerations
<p>No mention of the need to limit password guesses via the network.&nbsp;
We really need to mention the different forms of password guessing that
should be limited by servers.
<br>&nbsp;
<br>&nbsp;</html>



Received: by above.proper.com (8.11.6/8.11.3) id fB3FC6127455 for ietf-pkix-bks; Mon, 3 Dec 2001 07:12:06 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fB3FC4227445 for <[e-mail]>; Mon, 3 Dec 2001 07:12:04 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Dec 2001 15:12:01 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA08977 for <[e-mail]>; Mon, 3 Dec 2001 10:12:05 -0500 (EST)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fB3FC3B01937 for <[e-mail]>; Mon, 3 Dec 2001 10:12:03 -0500 (EST)
Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id <VMZB432W>; Mon, 3 Dec 2001 15:12:07 -0000
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.1.29 [10.3.1.29]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DRLAAQ; Mon, 3 Dec 2001 08:18:04 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 30 Nov 2001 09:50:45 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Names in Proxy Certificate 
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>
List-ID: <ietf-pkix.imc.org>

6.4 Carrying Along the End Entity Subject

    Another suggestion was to include the subject of the signing EEC as
    an informational field in the PC.  This would allow an authorizing
    process to use only information in the final PC in the chain to
    determine identity, and not need to walk the chain in order to find
    out the subject (or subjectAltName) of the EEC that the PC is
    derived from.

    This approach was rejected for the following reasons:

    *  It would be easy to spoof this informational field.  For example,
       a PC with an informational subject of "Steve" could be used to
       create a PC with an informational subject set to "Doug".  This
       leaves us with two alternatives:

       * We can augment the path validation to check that this
         informational field of the PC is the same as in the signing PC
         or EEC.  But this is not desirable, as it complicates the path
         validation.

       * But if we do not validate this field, we cannot trust the
         contents of this informational field.  So then there is no
         point in including this informational field.

    *  Upon closer examination, there is a lot of information in the
       certificate chain that may be needed during authorization, such
       as the number of levels of delegation, the CA (or multiple levels
       of CAs) who signed the original EEC, the constraints and keyUsage
       values of the signing EEC, possibly Certificate Policies
       associated with CAs or IAs.  All of these require essentially the
       same amount of work as retrieving the subject of the EEC that
       signed the PC.  So why threat the EEC subject specially by
       including it in an information field?

    In the end, just including the EEC subject name does not seem to be
    sufficiently useful to justify the addition of another field and the
    work of verifying that name during the path validation.

    Therefore, to determine the identity of a PC for authorization
    purposes, the subject of the EEC must be retrieved directly from the
    EEC in the signing chain.  This approach also has the beneficial
    side effect of further stressing that a Proxy Certificate has no
    identity of its own, but rather inherits it from its signing EEC. 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3D4M619632 for ietf-pkix-bks; Mon, 3 Dec 2001 05:04:22 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3D4K219628 for <[e-mail]>; Mon, 3 Dec 2001 05:04:20 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA22624 for <[e-mail]>; Mon, 3 Dec 2001 14:04:19 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 3 Dec 2001 14:04:19 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA09279 for <[e-mail]>; Mon, 3 Dec 2001 14:04:18 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA17842 for [e-mail]; Mon, 3 Dec 2001 14:04:17 +0100 (MET)
Date: Mon, 3 Dec 2001 14:04:17 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: Is there any avaliable TSA?
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>
List-ID: <ietf-pkix.imc.org>

See the descriptions in  http://www.edelweb.fr/tsa.html 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3CsGp19087 for ietf-pkix-bks; Mon, 3 Dec 2001 04:54:16 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3CsE219078 for <[e-mail]>; Mon, 3 Dec 2001 04:54:14 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id BAA07979 for <[e-mail]>; Tue, 4 Dec 2001 01:54:06 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id BAA195974 for [e-mail]; Tue, 4 Dec 2001 01:54:06 +1300 (NZDT) (sender [e-mail])
Date: Tue, 4 Dec 2001 01:54:06 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Is there any avaliable TSA?
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>
List-ID: <ietf-pkix.imc.org>

ChungKil Kim <[e-mail]> writes:

>for interop test.

tsa.cryptoapps.com, port 3318.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3CO6x17316 for ietf-pkix-bks; Mon, 3 Dec 2001 04:24:06 -0800 (PST)
Received: from pol88b.polito.it (pol88b.polito.it [130.192.2.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3CO3217312 for <[e-mail]>; Mon, 3 Dec 2001 04:24:04 -0800 (PST)
Received: from RAMUNNO (ramunno.polito.it) by polito.it (PMDF V5.2-27 #3020) with SMTP id <[e-mail]> for [e-mail]; Mon, 3 Dec 2001 13:23:51 +0100
Date: Mon, 03 Dec 2001 13:22:07 +0100
From: Gianluca Ramunno <[e-mail]>
Subject: RE: Is there any avaliable TSA?
In-reply-to: <[e-mail]>
To: "'ChungKil Kim'" <[e-mail]>
Cc: [e-mail]
Reply-to: [e-mail]
Message-id: <005401c17bf5$2181c040$df01c082@RAMUNNO>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_6PU+ngfVBvA+sy3k2ifaZg)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-MS-TNEF-Correlator: 0000000081D39B1DE965BF119EF4CAA9387D4C2844DC7400
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>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

--Boundary_(ID_6PU+ngfVBvA+sy3k2ifaZg)
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: 8BIT

Dear All,
we are preparing a TSA service freely available for testing purposes. The
related web pages are almost ready, the TSA service instead is under
advanced testing.

The service will be publicly available in few weeks as well as the binaries
of a client freely downloadable.
When available, it will be announced on this list.

Best regards
Gianluca Ramunno


-----------------------------------------------------------
Gianluca Ramunno, Computer and Network Security Group
Dipartimento di Automatica ed Informatica
Politecnico di Torino
c/o ICT - Laboratorio di sicurezza
Via Cardinal Massaia 83, 10143 Torino - Italy

e-mail: [e-mail]



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of ChungKil Kim
> Sent: lunedì 3 dicembre 2001 12.53
> To: [e-mail]
> Subject: RE: Is there any avaliable TSA?
> 
> 
> 
> host tsp.test.polito.it resolving error!
> 
> > -----Original Message-----
> > From: Cristian Marinescu [mailto:[e-mail]]
> > Sent: Monday, December 03, 2001 8:39 PM
> > To: ChungKil Kim; [e-mail]
> > Subject: RE: Is there any avaliable TSA?
> > 
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hi,
> > 
> > Please take a look to
> > http://security.polito.it/test/tsp/
> > 
> > Kindly regards,
> > Cristian Marinescu
> > 
> > =====================
> > Dipl-Ing. Cristian Marinescu
> > Software Developer
> > OMICRON electronics GmbH
> > Oberes Ried 1
> > A-6833 Klaus
> > AUSTRIA
> > Tel. [phone]
> > Fax. [phone]
> > E-Mail: [e-mail]
> > WWW: www.omicron.at
> > 
> > 
> > > -----Original Message-----
> > > From: ChungKil Kim [mailto:[e-mail]]
> > > Sent: Montag, 3. Dezember 2001 09:34
> > > To: [e-mail]
> > > Subject: Is there any avaliable TSA?
> > > 
> > > 
> > > 
> > > for interop test.
> > > 
> > > Thanks.
> > > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 6.0.2i
> > 
> > iQA/AwUBPAtWP8V5iyNCxCiSEQKC6QCgnTUzGYazWetDNz+SNr5pB8NeAKkAoLan
> > 9I+LHzrdJ3yWZFtEPqJ4QJkO
> > =mnUW
> > -----END PGP SIGNATURE-----
> > 

--Boundary_(ID_6PU+ngfVBvA+sy3k2ifaZg)
Content-type: application/ms-tnef; name=winmail.dat
Content-disposition: attachment; filename=winmail.dat
Content-transfer-encoding: base64

eJ8+IgkMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHDAADAA0AFgAAAAEACwEB
A5AGAMwLAAAqAAAACwACAAEAAAALACMAAQAAAAMAJgAAAAAACwApAAEAAAADAC4AAAAAAAIBMQAB
AAAAIAEAAFBDREZFQjA5AAEAAgCbAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAA
AAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXEFkbWluaXN0cmF0
b3JcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xtYWls
Ym94LnBzdAAYAAAAAAAAAIHTmx3pZb8RnvTKqTh9TCjCgAAAAAAAABgAAAAAAAAAgdObHellvxGe
9MqpOH1MKOKAAAAQAAAA5UNdD2om1k+zO1kbaRaMNCAAAABSRTogSXMgdGhlcmUgYW55IGF2YWxp
YWJsZSBUU0E/AAMANgAAAAAAHgBwAAEAAAAcAAAASXMgdGhlcmUgYW55IGF2YWxpYWJsZSBUU0E/
AAIBcQABAAAAFgAAAAHBe/Ufz6NSU9ZLs0QVlkJ1VUmhhBIAAAIBHQwBAAAAFwAAAFNNVFA6UkFN
VU5OT0BQT0xJVE8uSVQAAAsAAQ4AAAAAQAAGDgCkZhv1e8EBAgEKDgEAAAAYAAAAAAAAAIHTmx3p
Zb8RnvTKqTh9TCjigAAAAwAUDgEAAAALAB8OAQAAAAIBCRABAAAA6QUAAOUFAAAfCwAATFpGdQDI
18UDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAfdPCoACpAPjAgBjaArAc/BldDAgBxMCgA/zAFB/BFYI
VQeyEcUOUQMBEMcy9wYABsMRxTMERhDJEtsR09sI7wn3Oxi/DjA1EcIMYM5jAFALCQFkMzYRUAum
CCBEZQrBQWxsLGMKogqAd2UgCsAekHAXGMAKsQuAZx6gIFRT5EEgESBydg3gHpADUOkJ4Gx5HqB2
C3ALYAJgpyBRBbEOsHN0H1JwCHCkcG8RIHMuH6BoHpCnGMALYA6wZCAegGIe4PxhZweRHrIHQARg
IeAjEfBhZHksIbAi8R+6C4DPIeAlASZQBCB1bgSBHqC6ZCDwbiBAI4AhxS4eJJ8eJCLiH/YD8B3w
IGIe0f51AmAN4CC7C4AgYAfRHoD8ZWskIQQgHoAqISyBJWLOYguAHzEHkW9mH4Eq0IcIkAIwIGZk
b3duGFD3JRAhMih1VyLwA6Ag5yVA7mkFQCoGAHBuCGAnswIg3yVRJuEqsCHgKHtCIdEjEe5nCxEQ
sB4zRwcwL2AbcPEfkFJhbScQMjAoih4k/i03jzifOa86JTUPNhMlQH0IUG0iQA6wJ1EnIAexdKp3
BbBrBlFjCHF0IMDSRwNgdXAeJEQFIArA1yHwB4ACMG8vIGkRYDzwzwNxIfA1wSNxSW4hgUCE/R4k
UAbwMWAFkAMABaBAAk5UBbALgDZVYy8/8EnAQ1QgLSBMAaAFsB8jUEMxP/MN0QhwZXp6fUHFVgcw
EsALES2BAyBNTSyAcwtwH5A4MyVAMbAwMTQzQxVEUUkBkLMgsCiKZS0AwAMQOiMQzTYEQCJwQlFv
LjFgNm+tKNU+RFA6Ik8FEGdG5N8HkEdgJAA66U0ARgNhSlAbL0EEkC0IkAAwLXBrGGl4QEoSS1Bt
Yy61BbBnTKZbShI/4DpPr7lQuV1PA6A0QBDwbC4Qkk8uEENoJxBnSwMR/VVQbUymBmACMEpQCkBS
gPULMCcFkCBIMEAQIEAG0I8ewQHQSABH4DIuNRXQX0y1QyBKUFLPURtTKpBq0wWQVnFSRUpQSS0T
JFLebiDDKrAhMx+xP0ymXb+FTLVoJLJ0c3AuIcL2Lkr3IxFzBvAgIB9hBJD5A2ByIV4+TQ9OH2MS
T0T+QwUQIeEDkUcwH0EHkD4gt1HXBQFmIy4AwGalQANwbw3gA2BoECNQXWK4VkRNvwIgL6AlMR2Q
V4ITITBHwQFX8zg6MzkgUE33YrhZElUKO1lPUQxbH1wvB10+YppivUJFR0lOCWxgR1AGAElHTkWS
RAXQRVMfwEdFZK2KSCyAaEpQU0hBG5PZcx5IaR4VczxQIVAsgJsekAGQax6RMyBvbz3gCz/gYrho
AkBwOi8vdxEgPiRgiC8hwn5AYBAv/3mPYyFVUCcgILE0lXl5Zf/3DHB+/2MwPYQfhFFiuD9BvGwt
QSAoYIGvgrpTLgCXPaAesh2QdiCgb3AEkMliuE9NRCBST3VAIKCvcJFpEQ3gBCBHBtBIiYk7a1EH
kVIIkCOAeAlBLdY2R7BIMEsLYHU09Y1zwFVTVFJJQWyZIKBVIsArSCAtGwAykJEwMDctMTFYh08h
YXj9kF05kzBiuHZwRzBKMmev22i6YrhXlvBKUHeXQFEg/5XPc19jA2M/ZE+ZxGWVVRllZxhobrBt
QAuAQmJoui4FoG1peWoJAZBnJUA2MyLAHZB6azRX8zA5/WwwNJlqWR9vL3AbcS9yP/+Z06e/qM+a
ACGCC4A9AYlA/yGzKHWpnyLRAHAsUKu/dF+xdWZBVFVw4GStVgSQPwCQAiBKUHVhIHKIozYuODAu
MgCgmN+aAGlRAEEvQXdVQlBBAHRXUDhWNWl5AE5DeENpU0VRgEtDNlFDZ26wUEB6R1lhelcRMEQA
TnorU05yNXAEQjgHwEFLa0FvB0SAC5BixzlJK0xIAnoLIEozeVdaRgB0RVBxSjRRSoRrT4N5bW5V
V2K9vEVOdfCvz2TpHiR9vuAAAAAeAEIQAQAAADoAAAA8MDRBRERCQkI0QzdFQkY0NjhFM0RGMzU1
Qjc1MDE5NUUwODkxODdAZmlsZS5pbml0ZWNoLmNvbT4AAAADAAlZAQAAAAMAAW4gAAAACwALgAgg
BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAyACCAGAAAAAADAAAAAAAAARgAAAABShQAAJ2oB
AB4ADYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAADABuACCAGAAAAAADAAAAA
AAAARgAAAAABhQAAAAAAAAsAHIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAdgAggBgAA
AAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAB6ACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMA
H4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAggAggBgAAAAAAwAAAAAAAAEYAAAAANoUA
AAEAAAABAAAAAAAAAB4AIYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeACKA
CCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwApgAggBgAAAAAAwAAAAAAAAEYA
AAAABoUAAAAAAAACAfgPAQAAABAAAACB05sd6WW/EZ70yqk4fUwoAgH6DwEAAAAQAAAAgdObHell
vxGe9MqpOH1MKAIB+w8BAAAAmwAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAA
AE5JVEH5v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5nc1xBZG1pbmlzdHJhdG9y
XExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcbWFpbGJv
eC5wc3QAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDgxRDM5QjFERTk2NUJG
MTE5RUY0Q0FBOTM4N0Q0QzI4NDREQzc0MDAAAAAAAwAGEIV0yhgDAAcQVgYAAAMAEBAAAAAAAwAR
EAIAAAAeAAgQAQAAAGUAAABERUFSQUxMLFdFQVJFUFJFUEFSSU5HQVRTQVNFUlZJQ0VGUkVFTFlB
VkFJTEFCTEVGT1JURVNUSU5HUFVSUE9TRVNUSEVSRUxBVEVEV0VCUEFHRVNBUkVBTE1PU1RSRUFE
WSxUAAAAAJA3

--Boundary_(ID_6PU+ngfVBvA+sy3k2ifaZg)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3BncZ14529 for ietf-pkix-bks; Mon, 3 Dec 2001 03:49:38 -0800 (PST)
Received: from file.initech.com ([61.74.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Bnb214525 for <[e-mail]>; Mon, 3 Dec 2001 03:49:38 -0800 (PST)
Subject: RE: Is there any avaliable TSA?
Date: Mon, 3 Dec 2001 20:52:38 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
Thread-Topic: Is there any avaliable TSA?
Thread-Index: AcF78I/zViFHTFTsSKSKyhFzzYPAwA==
From: "ChungKil Kim" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fB3Bnc214526
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>
List-ID: <ietf-pkix.imc.org>

host tsp.test.polito.it resolving error!

> -----Original Message-----
> From: Cristian Marinescu [mailto:[e-mail]]
> Sent: Monday, December 03, 2001 8:39 PM
> To: ChungKil Kim; [e-mail]
> Subject: RE: Is there any avaliable TSA?
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Please take a look to
> http://security.polito.it/test/tsp/
> 
> Kindly regards,
> Cristian Marinescu
> 
> =====================
> Dipl-Ing. Cristian Marinescu
> Software Developer
> OMICRON electronics GmbH
> Oberes Ried 1
> A-6833 Klaus
> AUSTRIA
> Tel. [phone]
> Fax. [phone]
> E-Mail: [e-mail]
> WWW: www.omicron.at
> 
> 
> > -----Original Message-----
> > From: ChungKil Kim [mailto:[e-mail]]
> > Sent: Montag, 3. Dezember 2001 09:34
> > To: [e-mail]
> > Subject: Is there any avaliable TSA?
> > 
> > 
> > 
> > for interop test.
> > 
> > Thanks.
> > 
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.0.2i
> 
> iQA/AwUBPAtWP8V5iyNCxCiSEQKC6QCgnTUzGYazWetDNz+SNr5pB8NeAKkAoLan
> 9I+LHzrdJ3yWZFtEPqJ4QJkO
> =mnUW
> -----END PGP SIGNATURE-----
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3Bd7H13254 for ietf-pkix-bks; Mon, 3 Dec 2001 03:39:07 -0800 (PST)
Received: from Cream.omicron.at (cream.omicron.at [212.183.10.28]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Bd5213247 for <[e-mail]>; Mon, 3 Dec 2001 03:39:06 -0800 (PST)
Received: from Counter.omicron.at (gw.omicron.at [212.183.10.29]) by Cream.omicron.at (8.11.6/0.0.0) with ESMTP id fB3Bd1f22847; Mon, 3 Dec 2001 12:39:01 +0100
Received: from trillian.omicron.at (trillian.omicron.at [172.22.100.2]) by Counter.omicron.at (8.9.3/8.9.3) with ESMTP id MAA18644; Mon, 3 Dec 2001 12:39:00 +0100
Received: by trillian.omicron.at with Internet Mail Service (5.0.1460.8) id <X7ZT60XC>; Mon, 3 Dec 2001 12:39:00 +0100
Message-ID: <[e-mail]>
From: Cristian Marinescu <[e-mail]>
To: ChungKil Kim <[e-mail]>, [e-mail]
Subject: RE: Is there any avaliable TSA?
Date: Mon, 3 Dec 2001 12:38:56 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="windows-1252"
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>
List-ID: <ietf-pkix.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Please take a look to
http://security.polito.it/test/tsp/

Kindly regards,
Cristian Marinescu

=====================
Dipl-Ing. Cristian Marinescu
Software Developer
OMICRON electronics GmbH
Oberes Ried 1
A-6833 Klaus
AUSTRIA
Tel. [phone]
Fax. [phone]
E-Mail: [e-mail]
WWW: www.omicron.at


> -----Original Message-----
> From: ChungKil Kim [mailto:[e-mail]]
> Sent: Montag, 3. Dezember 2001 09:34
> To: [e-mail]
> Subject: Is there any avaliable TSA?
> 
> 
> 
> for interop test.
> 
> Thanks.
> 
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i

iQA/AwUBPAtWP8V5iyNCxCiSEQKC6QCgnTUzGYazWetDNz+SNr5pB8NeAKkAoLan
9I+LHzrdJ3yWZFtEPqJ4QJkO
=mnUW
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB38X4p23242 for ietf-pkix-bks; Mon, 3 Dec 2001 00:33:04 -0800 (PST)
Received: from file.initech.com ([61.74.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB38Ww223217 for <[e-mail]>; Mon, 3 Dec 2001 00:33:03 -0800 (PST)
Subject: Is there any avaliable TSA?
Date: Mon, 3 Dec 2001 17:34:20 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
Thread-Topic: Is there any avaliable TSA?
Thread-Index: AcF71NyuK/vLlO3BS1iDLudnFN5OGA==
From: "ChungKil Kim" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id fB38X3223237
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>
List-ID: <ietf-pkix.imc.org>

for interop test.

Thanks.