Subject: Re: Making PKI universally usable - was: Re: Acquisition Problem Solved for some certs?

From: [email-masked]
Date: Tue, 1 Jul 2003 00:11:46 MET

Hi,

Isn't the telephone solution an "online" solution? ;-)

Antonio Maña.
 
> Peter - Tom - in addition to the really powerful set of verification rules
> that Tom came up with here (bravo TG!), there is another problem with making
> PKI acceptable to the real-world... and that problem is that this type of
> verification **mandates** online services and for any number of certificate
> based infrastructures.
> 
> The problem is that we as commercial users **would** really like to be able
> to use x509 PKI's offline, and that also can be done. To meet this need I
> would suggest that an OOB validation process using the Telephone (yes a
> standard Touch Tone POTS should work just fine)...
> 
> All you would have to do is to call the number and key in the finger print
> of the cert which the provider could tell you if its valid from them
> currently - or could the 'responder' issue a One-Time Token to satisfy some
> installer function with this certificate as part of OOB installer practice.
> 
> The way to do this is with a local OCSP or CRL responder applet that uses a
> soft-token as part of the verification process based on the certs
> fingerprint... or somesuch.
> 
> This simple addition to the technology base totally makes x509 certs capable
> of being used offline as well as the basis of a stand-alone process...
> 
> Just my two cents
> 
> Todd Glassey
> 
> 
> ----- Original Message ----- 
> From: "Tom Gindin" <[email-masked]>
> To: "Peter Gutmann" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Sunday, June 29, 2003 7:14 PM
> Subject: Acquisition Problem Solved for some certs? (Was: Re: RFC 3280: same
> certificate in a certification path)
> 
> 
> >
> >
> >
> >
> >
> >       Peter:
> >
> >       I believe I can specify a set of standard conditions on certificates
> > that would permit all the CA certificates and CRL's relevant to them to be
> > retrieved by a generic PKIX-compliant RP, assuming that the mechanisms in
> > the certificate work as expected.  These mechanisms don't need to include,
> > and for practical operation probably should exclude, any directory access
> > except those where the entry name is supplied along with the network
> > location of its authoritative directory.  First, the subject certificate
> > must have an AIA extension containing either a caIssuers access descriptor
> > whose location is an LDAP URI including a host name or an HTTP Certs
> access
> > descriptor.  Second, each certificate in the chain must contain one of the
> > following three things: a CRL Distribution Point with a URI
> > DistributionPointName, an AIA extension with an OCSP access descriptor, or
> > an AIA extension with an HTTP CRL access descriptor.  If one condition
> from
> > each set is true, the RP can get the full set of required CA certificates
> > and CRL's (or status responses) from known Internet locations using a
> > well-defined protocol, and he gets to choose his own cross certification
> > path from among the ones found using the AIA method.
> >       I don't believe that an RP can rely on the world wide directory
> > working any more than you do.  Despite the implied endorsement of
> caIssuers
> > above, I don't know the format to be retrieved using either HTTP or FTP
> for
> > that access descriptor and I would have included those two mechanisms if I
> > could find it.  I don't see a data format for that in RFC 3280 4.2.2.1,
> and
> > I apologize for not having complained about it while that was a draft -
> the
> > format could be .p7c, but how can anyone be sure?  It's odd that YOU think
> > this problem requires X.500 (actually the global directory), since two of
> > the five solution pieces above come from "Certstore" - admittedly that's a
> > draft, not a standard.
> >       The above set of conditions are not necessarily the only ones which
> > will work, but they are the only ones which I can see will work without
> > requiring global interoperation of directories.  In particular, anybody
> who
> > has a heuristic that permits the acquisition of the full set of CA
> > certificates without requiring the subject certificate to have an AIA or
> > SIA extension is challenged to put one forward.  In the meantime, these
> > conditions exclude most real certificates today, and it is not plausible
> > that this technique will ever include all cross-certification paths,
> > because it relies on the presence of those certificates in a repository
> > known to the immediate CA.
> >
> >             Tom Gindin
> >
> > P.S. -      The opinions above are mine, and not necessarily those of my
> > employer.
> >
> >
> >
> >                       [email-masked]
> >                       nd.ac.nz (Peter          To:
> [email-masked], [email-masked], [email-masked]
> >                       Gutmann)                 cc:
> >                       Sent by:                 Subject:  Re: RFC 3280:
> same certificate in a certification path
> >                       owner-ietf-pkix@m
> >                       ail.imc.org
> >
> >
> >                       06/26/2003 09:53
> >                       PM
> >
> 
> >
> >
> >
> >
> >
> >
> > Stephen Kent <[email-masked]> writes:
> >
> > >Huh? the RP is responsible for acquiring the necessary certs and CRLs to
> > >validate a signature.
> >
> > Right, and the fact that that works so well in practice is why every
> > widely-
> > used protocol that uses certs has the sender supply them.  The end user's
> > options are to either have the sender supply all the certs, or to wait for
> > X.500 (or however the receiver is supposed to find the certs it needs) to
> > suddenly start working.  I'll put my money on sender-supplies-certs,
> > thanks.
> >
> > >>I'll even go so far as to say that it's OK for the receiver to deny
> > >>verification if the sender doesn't supply all the certificates needed.
> > >
> > >You'll be treading on very thin ice if you make this assertion.
> >
> > Seems to be a sensible way to ensure that things work in the real world.
> >
> > I guess I'll finish up with a quote from my home page:
> >
> >   I think a lot of purists would rather have PKI be useless to anyone in
> > any
> >   practical terms than to have it made simple enough to use, but
> > potentially
> >   "flawed".
> >          -- Chris Zimman.
> >
> > Peter.
> >
> >
> >
> >
> 
> 

------------------------------------------------------
Mensaje enviado desde el Servidor de Correo del
Departamento de Lenguajes y Ciencias de la Computacion
de la Universidad de Malaga
------------------------------------------------------

To: "todd glassey" <[email-masked]>, "Peter Gutmann" <[email-masked]>, "Tom Gindin" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Roger Spreen" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, "Hoyt L. Kesterson II" <[email-masked]>
From: [email-masked]
Subject: Re: Making PKI universally usable - was: Re: Acquisition Problem Solved for some certs? 
Date: Tue, 1 Jul 2003 00:11:46 MET
Sender: [email-masked]

Hi,

Isn't the telephone solution an "online" solution? ;-)

Antonio Maña.
 
> Peter - Tom - in addition to the really powerful set of verification rules
> that Tom came up with here (bravo TG!), there is another problem with making
> PKI acceptable to the real-world... and that problem is that this type of
> verification **mandates** online services and for any number of certificate
> based infrastructures.
> 
> The problem is that we as commercial users **would** really like to be able
> to use x509 PKI's offline, and that also can be done. To meet this need I
> would suggest that an OOB validation process using the Telephone (yes a
> standard Touch Tone POTS should work just fine)...
> 
> All you would have to do is to call the number and key in the finger print
> of the cert which the provider could tell you if its valid from them
> currently - or could the 'responder' issue a One-Time Token to satisfy some
> installer function with this certificate as part of OOB installer practice.
> 
> The way to do this is with a local OCSP or CRL responder applet that uses a
> soft-token as part of the verification process based on the certs
> fingerprint... or somesuch.
> 
> This simple addition to the technology base totally makes x509 certs capable
> of being used offline as well as the basis of a stand-alone process...
> 
> Just my two cents
> 
> Todd Glassey
> 
> 
> ----- Original Message ----- 
> From: "Tom Gindin" <[email-masked]>
> To: "Peter Gutmann" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Sunday, June 29, 2003 7:14 PM
> Subject: Acquisition Problem Solved for some certs? (Was: Re: RFC 3280: same
> certificate in a certification path)
> 
> 
> >
> >
> >
> >
> >
> >       Peter:
> >
> >       I believe I can specify a set of standard conditions on certificates
> > that would permit all the CA certificates and CRL's relevant to them to be
> > retrieved by a generic PKIX-compliant RP, assuming that the mechanisms in
> > the certificate work as expected.  These mechanisms don't need to include,
> > and for practical operation probably should exclude, any directory access
> > except those where the entry name is supplied along with the network
> > location of its authoritative directory.  First, the subject certificate
> > must have an AIA extension containing either a caIssuers access descriptor
> > whose location is an LDAP URI including a host name or an HTTP Certs
> access
> > descriptor.  Second, each certificate in the chain must contain one of the
> > following three things: a CRL Distribution Point with a URI
> > DistributionPointName, an AIA extension with an OCSP access descriptor, or
> > an AIA extension with an HTTP CRL access descriptor.  If one condition
> from
> > each set is true, the RP can get the full set of required CA certificates
> > and CRL's (or status responses) from known Internet locations using a
> > well-defined protocol, and he gets to choose his own cross certification
> > path from among the ones found using the AIA method.
> >       I don't believe that an RP can rely on the world wide directory
> > working any more than you do.  Despite the implied endorsement of
> caIssuers
> > above, I don't know the format to be retrieved using either HTTP or FTP
> for
> > that access descriptor and I would have included those two mechanisms if I
> > could find it.  I don't see a data format for that in RFC 3280 4.2.2.1,
> and
> > I apologize for not having complained about it while that was a draft -
> the
> > format could be .p7c, but how can anyone be sure?  It's odd that YOU think
> > this problem requires X.500 (actually the global directory), since two of
> > the five solution pieces above come from "Certstore" - admittedly that's a
> > draft, not a standard.
> >       The above set of conditions are not necessarily the only ones which
> > will work, but they are the only ones which I can see will work without
> > requiring global interoperation of directories.  In particular, anybody
> who
> > has a heuristic that permits the acquisition of the full set of CA
> > certificates without requiring the subject certificate to have an AIA or
> > SIA extension is challenged to put one forward.  In the meantime, these
> > conditions exclude most real certificates today, and it is not plausible
> > that this technique will ever include all cross-certification paths,
> > because it relies on the presence of those certificates in a repository
> > known to the immediate CA.
> >
> >             Tom Gindin
> >
> > P.S. -      The opinions above are mine, and not necessarily those of my
> > employer.
> >
> >
> >
> >                       [email-masked]
> >                       nd.ac.nz (Peter          To:
> [email-masked], [email-masked], [email-masked]
> >                       Gutmann)                 cc:
> >                       Sent by:                 Subject:  Re: RFC 3280:
> same certificate in a certification path
> >                       owner-ietf-pkix@m
> >                       ail.imc.org
> >
> >
> >                       06/26/2003 09:53
> >                       PM
> >
> 
> >
> >
> >
> >
> >
> >
> > Stephen Kent <[email-masked]> writes:
> >
> > >Huh? the RP is responsible for acquiring the necessary certs and CRLs to
> > >validate a signature.
> >
> > Right, and the fact that that works so well in practice is why every
> > widely-
> > used protocol that uses certs has the sender supply them.  The end user's
> > options are to either have the sender supply all the certs, or to wait for
> > X.500 (or however the receiver is supposed to find the certs it needs) to
> > suddenly start working.  I'll put my money on sender-supplies-certs,
> > thanks.
> >
> > >>I'll even go so far as to say that it's OK for the receiver to deny
> > >>verification if the sender doesn't supply all the certificates needed.
> > >
> > >You'll be treading on very thin ice if you make this assertion.
> >
> > Seems to be a sensible way to ensure that things work in the real world.
> >
> > I guess I'll finish up with a quote from my home page:
> >
> >   I think a lot of purists would rather have PKI be useless to anyone in
> > any
> >   practical terms than to have it made simple enough to use, but
> > potentially
> >   "flawed".
> >          -- Chris Zimman.
> >
> > Peter.
> >
> >
> >
> >
> 
> 

------------------------------------------------------
Mensaje enviado desde el Servidor de Correo del
Departamento de Lenguajes y Ciencias de la Computacion
de la Universidad de Malaga
------------------------------------------------------

From: "todd glassey" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Roger Spreen" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, "Hoyt L. Kesterson II" <[email-masked]>
Subject: Making PKI universally usable - was: Re: Acquisition Problem Solved for some certs? 
Date: Mon, 30 Jun 2003 06:49:16 -0700
Sender: [email-masked]

Peter - Tom - in addition to the really powerful set of verification rules
that Tom came up with here (bravo TG!), there is another problem with making
PKI acceptable to the real-world... and that problem is that this type of
verification **mandates** online services and for any number of certificate
based infrastructures.

The problem is that we as commercial users **would** really like to be able
to use x509 PKI's offline, and that also can be done. To meet this need I
would suggest that an OOB validation process using the Telephone (yes a
standard Touch Tone POTS should work just fine)...

All you would have to do is to call the number and key in the finger print
of the cert which the provider could tell you if its valid from them
currently - or could the 'responder' issue a One-Time Token to satisfy some
installer function with this certificate as part of OOB installer practice.

The way to do this is with a local OCSP or CRL responder applet that uses a
soft-token as part of the verification process based on the certs
fingerprint... or somesuch.

This simple addition to the technology base totally makes x509 certs capable
of being used offline as well as the basis of a stand-alone process...

Just my two cents

Todd Glassey

----- Original Message ----- 
From: "Tom Gindin" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, June 29, 2003 7:14 PM
Subject: Acquisition Problem Solved for some certs? (Was: Re: RFC 3280: same
certificate in a certification path)

>
>
>
>
>
>       Peter:
>
>       I believe I can specify a set of standard conditions on certificates
> that would permit all the CA certificates and CRL's relevant to them to be
> retrieved by a generic PKIX-compliant RP, assuming that the mechanisms in
> the certificate work as expected.  These mechanisms don't need to include,
> and for practical operation probably should exclude, any directory access
> except those where the entry name is supplied along with the network
> location of its authoritative directory.  First, the subject certificate
> must have an AIA extension containing either a caIssuers access descriptor
> whose location is an LDAP URI including a host name or an HTTP Certs
access
> descriptor.  Second, each certificate in the chain must contain one of the
> following three things: a CRL Distribution Point with a URI
> DistributionPointName, an AIA extension with an OCSP access descriptor, or
> an AIA extension with an HTTP CRL access descriptor.  If one condition
from
> each set is true, the RP can get the full set of required CA certificates
> and CRL's (or status responses) from known Internet locations using a
> well-defined protocol, and he gets to choose his own cross certification
> path from among the ones found using the AIA method.
>       I don't believe that an RP can rely on the world wide directory
> working any more than you do.  Despite the implied endorsement of
caIssuers
> above, I don't know the format to be retrieved using either HTTP or FTP
for
> that access descriptor and I would have included those two mechanisms if I
> could find it.  I don't see a data format for that in RFC 3280 4.2.2.1,
and
> I apologize for not having complained about it while that was a draft -
the
> format could be .p7c, but how can anyone be sure?  It's odd that YOU think
> this problem requires X.500 (actually the global directory), since two of
> the five solution pieces above come from "Certstore" - admittedly that's a
> draft, not a standard.
>       The above set of conditions are not necessarily the only ones which
> will work, but they are the only ones which I can see will work without
> requiring global interoperation of directories.  In particular, anybody
who
> has a heuristic that permits the acquisition of the full set of CA
> certificates without requiring the subject certificate to have an AIA or
> SIA extension is challenged to put one forward.  In the meantime, these
> conditions exclude most real certificates today, and it is not plausible
> that this technique will ever include all cross-certification paths,
> because it relies on the presence of those certificates in a repository
> known to the immediate CA.
>
>             Tom Gindin
>
> P.S. -      The opinions above are mine, and not necessarily those of my
> employer.
>
>
>
>                       [email-masked]
>                       nd.ac.nz (Peter          To:
[email-masked], [email-masked], [email-masked]
>                       Gutmann)                 cc:
>                       Sent by:                 Subject:  Re: RFC 3280:
same certificate in a certification path
>                       owner-ietf-pkix@m
>                       ail.imc.org
>                       06/26/2003 09:53
>                       PM

>
>
>
>
>
>
> Stephen Kent <[email-masked]> writes:
>
> >Huh? the RP is responsible for acquiring the necessary certs and CRLs to
> >validate a signature.
>
> Right, and the fact that that works so well in practice is why every
> widely-
> used protocol that uses certs has the sender supply them.  The end user's
> options are to either have the sender supply all the certs, or to wait for
> X.500 (or however the receiver is supposed to find the certs it needs) to
> suddenly start working.  I'll put my money on sender-supplies-certs,
> thanks.
>
> >>I'll even go so far as to say that it's OK for the receiver to deny
> >>verification if the sender doesn't supply all the certificates needed.
> >
> >You'll be treading on very thin ice if you make this assertion.
>
> Seems to be a sensible way to ensure that things work in the real world.
>
> I guess I'll finish up with a quote from my home page:
>
>   I think a lot of purists would rather have PKI be useless to anyone in
> any
>   practical terms than to have it made simple enough to use, but
> potentially
>   "flawed".
>          -- Chris Zimman.
>
> Peter.
>
>
>
>

Date: Mon, 30 Jun 2003 09:24:22 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 4:00 PM +1200 6/28/03, Peter Gutmann wrote:
>  >I favor creating standards that show the way, and hoping that the 
>market will
>>eventually persuade vendors to follow these standards.
>
>At the risk of always having to get the last word in, I'll make my word:
>
>   OSI.
>
>Peter :-).

We can both select good examples of bad examples.

My last word is Microsoft.

Steve :-)

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Mon, 30 Jun 2003 07:53:35 -0400
Sender: [email-masked]

--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 Warranty 
                          Certificate Extension
	Author(s)	: D. Linsenbardt, S. Pontius, A. Sturgeon
	Filename	: draft-ietf-pkix-warranty-extn-03.txt
	Pages		: 8
	Date		: 2003-6-27
	
This document describes a certificate extension to explicitly state
the warranty offered by a Certificate Authority (CA) for a the
certificate containing the extension.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-warranty-extn-03.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Subject: Acquisition Problem Solved for some certs? (Was: Re: RFC 3280: same certificate in a certification path)
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked]
From: Tom Gindin <[email-masked]>
Date: Sun, 29 Jun 2003 22:14:37 -0400
Sender: [email-masked]

      Peter:

      I believe I can specify a set of standard conditions on certificates
that would permit all the CA certificates and CRL's relevant to them to be
retrieved by a generic PKIX-compliant RP, assuming that the mechanisms in
the certificate work as expected.  These mechanisms don't need to include,
and for practical operation probably should exclude, any directory access
except those where the entry name is supplied along with the network
location of its authoritative directory.  First, the subject certificate
must have an AIA extension containing either a caIssuers access descriptor
whose location is an LDAP URI including a host name or an HTTP Certs access
descriptor.  Second, each certificate in the chain must contain one of the
following three things: a CRL Distribution Point with a URI
DistributionPointName, an AIA extension with an OCSP access descriptor, or
an AIA extension with an HTTP CRL access descriptor.  If one condition from
each set is true, the RP can get the full set of required CA certificates
and CRL's (or status responses) from known Internet locations using a
well-defined protocol, and he gets to choose his own cross certification
path from among the ones found using the AIA method.
      I don't believe that an RP can rely on the world wide directory
working any more than you do.  Despite the implied endorsement of caIssuers
above, I don't know the format to be retrieved using either HTTP or FTP for
that access descriptor and I would have included those two mechanisms if I
could find it.  I don't see a data format for that in RFC 3280 4.2.2.1, and
I apologize for not having complained about it while that was a draft - the
format could be .p7c, but how can anyone be sure?  It's odd that YOU think
this problem requires X.500 (actually the global directory), since two of
the five solution pieces above come from "Certstore" - admittedly that's a
draft, not a standard.
      The above set of conditions are not necessarily the only ones which
will work, but they are the only ones which I can see will work without
requiring global interoperation of directories.  In particular, anybody who
has a heuristic that permits the acquisition of the full set of CA
certificates without requiring the subject certificate to have an AIA or
SIA extension is challenged to put one forward.  In the meantime, these
conditions exclude most real certificates today, and it is not plausible
that this technique will ever include all cross-certification paths,
because it relies on the presence of those certificates in a repository
known to the immediate CA.

            Tom Gindin

P.S. -      The opinions above are mine, and not necessarily those of my
employer.

                      [email-masked]                                                                                                
                      nd.ac.nz (Peter          To:       [email-masked], [email-masked], [email-masked]                       
                      Gutmann)                 cc:                                                                                     
                      Sent by:                 Subject:  Re: RFC 3280: same certificate in a certification path                        
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      06/26/2003 09:53                                                                                                 
                      PM                                                                                                               

Stephen Kent <[email-masked]> writes:

>Huh? the RP is responsible for acquiring the necessary certs and CRLs to
>validate a signature.

Right, and the fact that that works so well in practice is why every
widely-
used protocol that uses certs has the sender supply them.  The end user's
options are to either have the sender supply all the certs, or to wait for
X.500 (or however the receiver is supposed to find the certs it needs) to
suddenly start working.  I'll put my money on sender-supplies-certs,
thanks.

>>I'll even go so far as to say that it's OK for the receiver to deny
>>verification if the sender doesn't supply all the certificates needed.
>
>You'll be treading on very thin ice if you make this assertion.

Seems to be a sensible way to ensure that things work in the real world.

I guess I'll finish up with a quote from my home page:

  I think a lot of purists would rather have PKI be useless to anyone in
any
  practical terms than to have it made simple enough to use, but
potentially
  "flawed".
         -- Chris Zimman.

Peter.

From: "todd glassey" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Date: Sun, 29 Jun 2003 13:29:33 -0700
Sender: [email-masked]

I actually favor being proactive and working with industry to develop
protocols that do exactly what **they** need in the most efficient and
secure way possible. What a concept eh? To bad its a fantasy.

Todd

----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, June 27, 2003 9:00 PM
Subject: Re: RFC 3280: same certificate in a certification path

>
> >I favor creating standards that show the way, and hoping that the market
will
> >eventually persuade vendors to follow these standards.
>
> At the risk of always having to get the last word in, I'll make my word:
>
>   OSI.
>
> Peter :-).
>

Date: Sat, 28 Jun 2003 01:23:05 -0500 (CDT)
Subject: =?iso-8859-1?Q?"Lel_Bruce_Peto"_on_some_info_per_Renewable_energy?=
From: <[email-masked]>
To: [email-masked]
Sender: [email-masked]

"Lel Bruce Peto" on some info per Renewable energy, 

Renewable energy: 

Renewable energy sources are continuously and sustainably available in our 
environment. They are non-polluting, emission free and their waste can 
also often be used as a fuel source.

Renewable energy sources will become increasingly important as fossil fuel 
supplies dwindle. Some renewable energy sources are at more advanced 
stages of development than others, for example hydro is already well 
established. And 
some sources are used more in certain countries than others due to local 
availability, for example the UK has a favorable location to develop wind 
power but is poorly located for hydro.

The Kyoto Protocol proposals to cut greenhouse gas emissions will also 
favor the development of renewable energy sources.

Around 50% of the world's energy needs could be meet by renewable energy 
by 2050, according to industry estimates. Currently, only 15-20% of global 
energy consumption is met by renewable energy. Total energy consumption is 
forecast to grow an average 1.3% to 2020. Residential energy consumption 
growth will be driven by the increase in computer and electronic usage. 
Commercial energy demand is expected to rise 1.4% on average annually to 
2020, according to US Energy Information Administration statistics. This 
growth will also be fueled by increased usage of computers, electronic 
equipment and telecommunications. 

Date: Sat, 28 Jun 2003 16:00:03 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>I favor creating standards that show the way, and hoping that the market will
>eventually persuade vendors to follow these standards.

At the risk of always having to get the last word in, I'll make my word:

  OSI.

Peter :-).

Date: Fri, 27 Jun 2003 10:28:53 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 1:53 PM +1200 6/27/03, Peter Gutmann wrote:
>Stephen Kent <[email-masked]> writes:
>
>>Huh? the RP is responsible for acquiring the necessary certs and CRLs to
>>validate a signature.
>
>Right, and the fact that that works so well in practice is why every widely-
>used protocol that uses certs has the sender supply them.  The end user's
>options are to either have the sender supply all the certs, or to wait for
>X.500 (or however the receiver is supposed to find the certs it needs) to
>suddenly start working.  I'll put my money on sender-supplies-certs, thanks.
>
>>>I'll even go so far as to say that it's OK for the receiver to deny
>>>verification if the sender doesn't supply all the certificates needed.
>>
>>You'll be treading on very thin ice if you make this assertion.
>
>Seems to be a sensible way to ensure that things work in the real world.
>
>I guess I'll finish up with a quote from my home page:
>
>   I think a lot of purists would rather have PKI be useless to anyone in any
>   practical terms than to have it made simple enough to use, but potentially
>   "flawed".
>          -- Chris Zimman.

Peter,

You and I fundamentally disagree about how to make things work 
better. I favor creating standards that show the way, and hoping that 
the market will eventually persuade vendors to follow these 
standards.  You seem to want to create ad hoc workarounds to 
accommodate whatever a vendor had done. I see merit in your approach, 
from the perspective of a user who merely wants things to work NOW, 
and does not care how or why.  However, in the long run this has been 
show to be a bad approach, at least in terms of Internet standards 
experience.

In that light, I am still comfortable with my advice above.

Steve

Date: Fri, 27 Jun 2003 13:53:31 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>Huh? the RP is responsible for acquiring the necessary certs and CRLs to
>validate a signature.

Right, and the fact that that works so well in practice is why every widely-
used protocol that uses certs has the sender supply them.  The end user's
options are to either have the sender supply all the certs, or to wait for
X.500 (or however the receiver is supposed to find the certs it needs) to
suddenly start working.  I'll put my money on sender-supplies-certs, thanks.

>>I'll even go so far as to say that it's OK for the receiver to deny
>>verification if the sender doesn't supply all the certificates needed.
>
>You'll be treading on very thin ice if you make this assertion.

Seems to be a sensible way to ensure that things work in the real world.

I guess I'll finish up with a quote from my home page:

  I think a lot of purists would rather have PKI be useless to anyone in any
  practical terms than to have it made simple enough to use, but potentially
  "flawed".
         -- Chris Zimman.

Peter.

Date: Wed, 25 Jun 2003 16:15:31 -0400
To: Eric Norman <[email-masked]>, PKIX list <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

At 10:39 PM -0500 6/17/03, Eric Norman wrote:
>On Tue, 17 Jun 2003, Steve Hanna wrote:
>
>>  What will help in a huge and complex PKI?
>>
>>  * Sending partial paths or, even better, bags of certs
>>    (as S/MIME and SSL/TLS allow). Ideally, these certs
>>    should go beyond the EE's trust anchor to include
>>    other certs linking into relevant trust points.
>
>Now this is getting close to a subject that hasn't been
>mentioned much in this discussion.  Who's job is it to
>round up the certificates needed to verify?  Sender or
>receiver?  Standard practice that has evolved over eons
>puts this burden on the sender; i.e, the user is expected
>to "show up with the proper papers".

Huh? the RP is responsible for acquiring the necessary certs and CRLs 
to validate a signature. Although it is true that several protocols 
provide a facility to enable a sender to assist an RP by providing 
certs or CRLs that might be useful, this is not a great solution in 
general. This is because the sender usually cannot know what certs 
and companion CRLs will be needed by an RP, especially if there are 
multiple RPs (e.g., in S/MIME). Much of the motivation for sending 
this info arises because of the lack of a readily accessible 
directory infrastructure.

>Yes, part of the reason for that is the "something you have"
>stuff; nevertheless, putting the burden on the sender as RFCs
>suggest seems like it should alleviate a lot of the performance
>concerns.

Again I am puzzled by your apparent reference to the vernacular user 
authentication phrase "something you have." Possession of a cert does 
nothing to verify an identity; certs are generally public. It is only 
possession of the corresponding private key that established identity.

>I'll even go so far as to say that it's OK for the receiver
>to deny verification if the sender doesn't supply all the
>certificates needed.

You'll be treading on very thin ice if you make this assertion.

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Cc: Stephen Kent <[email-masked]>, [email-masked]
Subject: RE: XKMS Version 2
Date: Wed, 25 Jun 2003 07:08:25 -0700
Sender: [email-masked]

Denis,

	The last call has closed and I am currently working on composing
replies to the points raised in last call and making appropriate edits to
the document.

		Phill

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, June 25, 2003 3:44 AM
> To: Hallam-Baker, Phillip
> Cc: Stephen Kent; [email-masked]
> Subject: XKMS Version 2
> 
> 
> 
> Phill,
> 
> You wrote:
> 
> >> In which case the IETF PKIX group will kindly stop work on 
> SCVP which
> >> duplicates functionality of the XKMS specification which 
> has already
> >> passed last call.
> 
> Following a request made to the PKIX WG on May 7, I sent 35 
> comments on XKMS 
> Version 2 (April 18, 2003) to the editor - 
> [email-masked] and cc: 
> [email-masked]. The Last Call review period ended on 23 May, 2003.
> 
> I am quite surprised you say that the XKMS specification has 
> already passed 
> last call, since my 35 comments have never been discussed 
> with me, nor answered.
> 
> Hereafter is again a copy of my comments (note sure that this 
> message will 
> go to the list, since it might be too long):
> 
> Comments on XKMS Version 2 (April 18, 2003)
> 
> The model has severe limitations which are not mentioned in 
> the document.
> 
> 1. The overall model is making the silent assumption that 
> only names that 
> are unique by their structure, i.e. DNS names, RFC 822 names or IP 
> addresses, shall be used. Since DNS names, RFC 822 names and 
> IP addresses 
> are unique, there is no difference between such names 
> certified by CA1 or 
> CA2. If Distinguished Names (DNs) were being used, a DN 
> certified by CA1 and 
> the same DN certified by CA2 could correspond to the same or 
> to different 
> entities. XKMS currently prohibits the use of DNs or, said in 
> other words, 
> exhibits security problems if such names were being used. 
> This should be 
> clearly advertised, or a fix to this problem should be made.
> 
> 
> 2. A major error in XKMS is to consider to obtain information 
> about keys, 
> rather than information against certificates, which bind a 
> public key to a 
> name for a specific key usage and under a Certification 
> Policy. Since there 
> is not a one-to-one relationship between a key and a 
> certificate, but a 
> one-to-many relationship, it is not possible to make an 
> unambiguous binding 
> with a public key but only an unambiguous binding with a (public key) 
> certificate.
> 
> 
> 3. The Certification Policy is a concept which seems to be 
> ignored at the 
> level of the interfaces that are being proposed.
> 
> 
> 4. In section [46] the text says:
> 
> "The XKMS specification defines three types of request:
> 
> X-KRSS Request
>       A Register, Reissue, Revoke or Recover request as 
> specified by the Key 
> Information Service Specification".
> 
> There is indeed a typo, probably intentionally left by the 
> editor, to make 
> sure that at least someone read the specification: "Key 
> Information Service 
> Specification" should be changed into "Key *Registration* Service 
> Specification".
> 
> 
> 5. The <ds:KeyInfo> (see [135]) is described as an "hint". 
> This should not 
> be the case since it is important to make sure under which 
> certificate a 
> signer wanted to sign. Several certificates may include the 
> same public key 
> and for that reason it is important to make sure that the 
> certificate (or an 
> unambiguous reference to it) is linked to the data that has 
> been signed and 
> is indeed protected by the signature. Without that link 
> certificates could 
> be substituted without notice. The concept is similar to 
> ESSCertID that is 
> used in CMS (see RFC 2634).
> 
> 
> 6. The fact that ds:KeyInfo> may or may not be 
> cryptographically bound to 
> the signature itself is advertised as an important property 
> (see [136]). It 
> is said: "This allows the <ds:KeyInfo> to be substituted or 
> supplemented 
> without "breaking" the digital signature". This should be 
> considered as a 
> severe weakness, since such a substitution is not desirable 
> (see above). A 
> certificate could be added, but the reference to the 
> certificate should 
> remain unchanged and unchangeable.
> 
> 
> 7. The XKISS Validate service verifies a binding with a 
> public key, while 
> the binding should be verified with a certificate (which 
> contains a public 
> key), instead of directly a public key value. CAs may deliver 
> different 
> certificates with the same public key but with different 
> attributes in them. 
> It is important to know which certificate has been used, 
> rather than which 
> public key has been used, since several certificates may 
> include the same 
> public key.
> 
> 
> 8. The two overviews from sections 1.5 and 1.6 do not provide a clear 
> picture of the functions that are supported. They should be 
> both revised. A 
> text is proposed as an annex at the end of these comments.
> 
> 
> 9. The document provides several examples which are quite 
> interesting. 
> However the core of a standard should not include examples. 
> Such examples 
> should be placed in an annex. However if these examples were 
> removed the 
> text would not be understandable anymore, because the 
> remaining explanations 
> would be insufficient. It is thus requested to add more 
> normative text and 
> to move the examples in an informative annex.
> 
> 
> 10. The XKISS Locate service is defined as " The XKISS Locate service 
> resolves a <ds:Keyinfo> element but does NOT REQUIRE the 
> service to make an 
> assertion concerning the validity of the binding between the 
> data in the 
> <ds:Keyinfo> element". What means "resolving <ds:Keyinfo> 
> element" is not 
> self-understandable. The exact processing that is supposed to 
> be done by the 
> service should be described in details.
> 
> 
> 11. The example (see [145]) is insufficient to describe what 
> that service 
> really does. The various input (and output) parameters should 
> be clearly 
> described. This is not the case.
> 
> The service seems to return only a key value, while it should 
> return the 
> main components from a certificate.
> 
>  From the example, it can be seen that the input parameters 
> are a DNS name 
> and the name of a protocol. Since no key usage is mentioned, 
> the service is 
> unable to know whether a certificate that includes a 
> signature verification 
> key or includes an encryption key is requested. A certificate 
> should be 
> returned and not a key, so that the user can verify the 
> validity period of 
> the certificate, otherwise a validity date should be included in the 
> request. The certification policy contained in the 
> certificate may also be 
> helpful, unless it is specified in the request.
> 
> 
> 12. The XKISS Validate service is defined as : "The XKISS 
> Validate Service 
> allows all that the Locate Service does, and in addition, the 
> client may 
> obtain an assertion specifying the status of the binding 
> between the public 
> key and other data, for example a name or a set of extended 
> attributes". 
> What means "other data" is not self-understandable. The exact 
> processing 
> that is supposed to be done by the service should be 
> described in details.
> 
> 
> 13. In [152] it is mentioned: "Furthermore the service 
> represents that the 
> status of each of the data elements returned is valid and 
> that all are bound 
> to the same public key". A <ds:Keyinfo> element may contain a 
> <ds:X509Data> 
> element. Therefore the binding is not with a key but with a 
> certificate.
> 
> 
> 14. The example (see [155]) is insufficient to describe what 
> that service 
> really does. The various input (and output) parameters should 
> be clearly 
> described. This is not the case.
> In particular, is the validation done only for the current 
> time or can it be 
> done for a time in the past ? Even, if this is the current 
> time, is that 
> time indicated in the response? The answer is only given 
> (hidden) in section 
> [215], but this should be clearly advertised upfront.
> 
> 
> 15. From its name, the XKISS Validate Service present a few 
> similarities 
> with the validation service requirements that have been 
> defined by the PKIX 
> WG from the IETF. This working group has produced RFC 3379 
> (Delegated Path 
> Validation and Delegated Path Discovery Protocol 
> Requirements) which is a 
> set of requirements.
> 
> However, the XKMS specification is leaving aside many, if not 
> most, of the 
> these requirements. An important concept from RFC3379 is the 
> concept of 
> "validation policy". When a validation is done, it must be 
> done according to 
> a set of rules. These rules depends upon the application. In 
> particular some 
> root keys may be adequate for an application, but not for 
> another. Trust 
> elements cannot be uniform and cannot be left open to the 
> Validate Server.
> 
> The text is speaking of a "validation criteria (see [161]), but it is 
> unclear what it really is. This is one of the most severe 
> limitations of 
> XKMS and this limitation is not advertised.
> 
> It would be quite interesting to understand why the requirements from 
> RFC3379 have not been followed.
> 
> 
> 16. The text is speaking of some means to locate the correct 
> XKMS service 
> (see [163]) but does not provide any guidance in order to solve this 
> problem, in particular in the context of multiple servers 
> offering their 
> services to the users.
> 
> 
> 17. The text in [168] states: "the Service represents to the client 
> accessing the service and to that client alone that the 
> binding between the 
> data elements is valid under whatever trust policy the 
> service offers to 
> that client." Unless the service can clearly advertise which 
> trust policy is 
> being used, the client cannot use any kind of trust policy 
> without even 
> knowing which one it is. As already stated, the concept of 
> validation policy 
> is not supported, but should be supported.
> 
> 
> 18. The text under [171] mentions: "The Id identifier is 
> defined to provide 
> a means by which the key binding may be signed using XML 
> Signature. Clients 
> MUST NOT rely on the key binding identifier being either 
> unique or stable". 
> On the contrary it is believed that a key identifier should 
> be unique. The 
> ESSCertID from RFC 2634 is a good example of such a unique binding.
> 
> 
> 19. The text under [174] considers only three intended uses 
> of the key:
> 
>    1) Encryption : The key pair may be used for encryption 
> and decryption,
>    2) Signature : The key pair may be used for signature and 
> verification,
>    3) Exchange: The key pair may be used for key exchange.
> 
> However, the key usages should be defined in terms of 
> security services (see 
> ISO 7498-2), i.e. authentication service, confidentiality service and 
> non-repudiation service.
> 
> To avoid some security problems it is particularly important 
> to make a 
> difference between a key usable for authentication and a key 
> usable for 
> non-repudiation. This cannot be covered by a single key usage called 
> "signature".
> 
> 
> 20. The text under [177] mentions the <UseKeyWith> element 
> which specifies a 
> subject identifier and application identifier that determine 
> a use of the 
> key. The <UseKeyWith> must contain "Application" which is a URI that 
> specifies the application protocol with which the key may be used and 
> "Identifier" which specifies the subject to which the key 
> corresponds within 
> the specified application protocol. A protocol can support a 
> sender and a 
> receiver. It is unclear whether the Identifier corresponds to 
> the sender or 
> the receiver. It seems that the notion is by itself 
> insufficient and should 
> be extended to make such difference.
> 
> 
> 21. The text under [180] mentions S/MIME as a protocol. Why is CMS 
> (Cryptographic Message Syntax) not considered as a protocol as well ?
> 
> 
> 22. The text under [180] mentions PKIX. It is very unclear to 
> understand why 
> PKIX is considered as a "protocol" since it is only a set of 
> data structures.
> 
> 
> 23. The text under [180] mentions the use of "Certificate 
> Subject Name" as 
> an appropriate identifier. It should be observed that this 
> name only is 
> insufficient to correctly identify an entity, since two CAs 
> may certify the 
> same name and that this name may correspond to the same or to 
> different 
> entities. Unless a sequence of CAs names is added to the 
> entity name up to a 
> root key, such names are ambiguous. This relates to the 
> non-uniqueness of DN 
> names already mentioned.
> 
> 
> 24. The text under [180] identifies various protocols. To 
> this list, XAdES 
> (XML Advanced Electronic Signature) which is a W3C Note 
> issued on February 
> 20, 2003 should be added (see: http://www.w3.org/TR/XAdES/). The 
> "identifier" type is such a case is a SigningCertificate 
> element, i.e. *not* 
> a DN.
> 
> 
> 25. The description of the Validate Service are confusing. It 
> seems to 
> relate more to the Locate Service rather than the Validate 
> Service where the 
> primary response should be "valid according to some policy" 
> or "invalid 
> according to some trust policy". The exact service performed 
> by the Validate 
> Service is not sufficiently detailed.
> 
> 
> 26. In [221] it is mentioned: "The server returns one or more 
> <KeyBinding> 
> elements that meet the criteria specified in the request." It is 
> questionable why not simply a valid, invalid or don't know 
> assertion is made 
> against the proposed binding.
> 
> 
> 27. In the case of validation, the "yet not valid" response should be 
> considered, in particular when a certificate is suspended. 
> This means that 
> another validation request made later on may succeed.
> 
> 
> 28. The Register Service from KRSS is not sufficiently 
> described. The two 
> examples provide more information, but that information is 
> not normative. 
>  From the example, two features are mentioned:
> 
> 1° authentication information to be used later on for 
> revocation can be 
> transmitted. However, it is unfortunate that the data does 
> not also include 
> the question to be answered.
> 
> 2° it is necessary to have a face to face contact with the 
> LRA before being 
> able to use the register request. During that face to face 
> information is 
> captured by the LRA and the secret "authentication code" is 
> provide to the 
> end-user. However, this method is time consuming and does not 
> allow a cost 
> effective deployment of a PKI.
> 
> It is suggested to use another technique that places all the 
> burden of the 
> typing for the end-user, who receives back both a 
> registration number and 
> the hash of his request (signed by the service) so that the 
> end-user can 
> then authenticate to the LRA in a face to face where the 
> Register Service 
> has only to verify the information (and to only "click" to accept or 
> reject). Another advantage is that no secret information is 
> being used.
> 
> 
> 29. In the example [241] several identifiers are included :
> 
> <UseKeyWith Application="urn:ietf:rfc:2459"
> Identifier="C=&quot;US&quot; O=&quot;Alice Corp&quot;
> CN=&quot;Alice Aardvark&quot;"/>
> <UseKeyWith Application="urn:ietf:rfc:2633"
> Identifier="[email-masked]"/>
> <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
> Identifier="[email-masked]"/>
> 
> It is unclear to understand how the concept of "UseKeyWith 
> Application" will 
> be translated in an X.509 certificate, since an X.509 
> certificate does not 
> support the concept of "UseKeyWith Application".
> 
> 
> 30. In the example [245] the private key is returned in the 
> response. It 
> will be quite uneasy for the end-user to memorize the 
> authentication code 
> 3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 previously obtained through some 
> out-of-band mechanism. This method would be quite difficult 
> to use and would 
> not allow an easy and cost effective deployment of a PKI. It 
> is suggested to 
> use another technique that allows the end user to locally 
> generate a key 
> pair, so that the public key can be sent in the Register 
> Service request and 
> then used by the Register Service to encrypt the private key 
> once generated. 
> The main advantage is that no secret information is being used and no 
> out-of-bands mechanism is necessary.
> 
> 
> 31. The Reissue request mentions "A reissue request is made 
> in the same 
> manner as the initial registration of a key". It is not 
> believed that this 
> statement is correct. The user should provide the previously obtained 
> certificate and ask for another validity period. There is no 
> need to specify 
> again secret information obtained through an out of bands mechanism.
> 
> 
> 32. The Revocation request should allow the possibility to 
> carry a reason 
> code and an Invalidity Date (RFC 2459 sates that CRL issuers 
> are strongly 
> encouraged to include meaningful reason codes in CRL entries).
> 
> 
> 33. The Revocation request example includes the certificate. 
> It is very 
> doubtful that the user will be able to provide its full 
> certificate, if his 
> smart card has been stolen. However he could more easily 
> provide his subject 
> name instead. The input and the output parameters are not 
> sufficiently 
> described.
> 
> 
> 34. The Recovery request mentions "A key recovery request is 
> made in the 
> same manner as the initial registration of a key". It is not 
> believed that 
> this statement is correct. There is no need to specify again secret 
> information obtained through an out of bands mechanism.
> Users do not have only a confidentiality key, but also an 
> authentication 
> key. They could use it to authenticate. If they loose 
> everything, they could 
> encrypt the authentication code under a key they wish their 
> private key to 
> be recovered (using PKCS#12) and authenticate their request 
> by phone using 
> the non-secret registration number of their request. For this to be 
> possible, a hash of the request should be present in the response.
> 
> 
> 35. The security considerations section should be augmented 
> to mention the 
> severe limitations that are indicated above.
> 
> 
> ANNEX
> 
> The following text is proposed as a global overview of these 
> two sections.
> 
> Note: This text is re-using text already present and does not include 
> changes that are suggested in the other comments.
> 
> 
> "The XKMS specification defines three types of requests:
> 
> 1. X-KISS (Key Information Service Specification) Request : A 
> Locate or a 
> Validate request.
> 
> The XKISS Locate service provides one or more unverified key 
> bindings to the 
> best of its knowledge but does not provide any assurance 
> about that binding. 
> Information obtained from a Locate service SHOULD NOT be 
> relied upon unless 
> it is validated. Validation may be achieved by forwarding the 
> data to a 
> Validate service or by performing the necessary trust path 
> verification locally.
> 
> The XKISS Validate service allows a client to query the 
> binding between a 
> <ds:Keyinfo> element (i.e. <ds:X509Data>, <ds:X509Data>*, 
> <ds:KeyName>, 
> <ds:KeyValue>) and one or more <UseKeyWith> elements (i.e. an 
> application 
> protocol with which the key may be used and an "identifier" 
> which specifies 
> the subject to which the key corresponds within the specified 
> application 
> protocol).
> 
> 2. X-KRSS (Key Registration Service Specification) Request 
> :The XML Key 
> Registration Service Specification permits management of 
> information that is 
> bound to a public key pair. The XKRSS service specification 
> supports the 
> following operations:
> 
> a)  Register : The Registration request message contains a 
> prototype of the 
> requested key binding which may contain only partial 
> information, a key 
> without a name or a name without a key. The registration 
> service MAY require 
> the client to provide additional information to authenticate 
> the request. If 
> the public key pair is generated by the client, the service 
> MAY require the 
> client to provide Proof of Possession of the private key.
> 
> b)  Reissue : A previously registered key binding is reissued 
> unchanged 
> except the validity period.
> 
> c)  Revoke : A previously registered key binding is revoked.
> 
> d)  Recover : The private key associated with a key binding 
> is recovered.
> 
> 3. Compound Request : A compound request allows multiple 
> X-KISS or X-KRSS 
> requests and the corresponding responses to be sent in a 
> single message. 
> This allows considerable processing resources to be saved as a single 
> signature on the compound message may be used in place of multiple 
> signatures on the individual requests or responses.
> 
> Denis
> 
> 
> 
> 
> 

Date: Wed, 25 Jun 2003 09:44:10 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Hallam-Baker, Phillip" <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: XKMS Version 2
Sender: [email-masked]

Phill,

You wrote:

>> In which case the IETF PKIX group will kindly stop work on SCVP which
>> duplicates functionality of the XKMS specification which has already
>> passed last call.

Following a request made to the PKIX WG on May 7, I sent 35 comments on XKMS 
Version 2 (April 18, 2003) to the editor - [email-masked] and cc: 
[email-masked]. The Last Call review period ended on 23 May, 2003.

I am quite surprised you say that the XKMS specification has already passed 
last call, since my 35 comments have never been discussed with me, nor answered.

Hereafter is again a copy of my comments (note sure that this message will 
go to the list, since it might be too long):

Comments on XKMS Version 2 (April 18, 2003)

The model has severe limitations which are not mentioned in the document.

1. The overall model is making the silent assumption that only names that 
are unique by their structure, i.e. DNS names, RFC 822 names or IP 
addresses, shall be used. Since DNS names, RFC 822 names and IP addresses 
are unique, there is no difference between such names certified by CA1 or 
CA2. If Distinguished Names (DNs) were being used, a DN certified by CA1 and 
the same DN certified by CA2 could correspond to the same or to different 
entities. XKMS currently prohibits the use of DNs or, said in other words, 
exhibits security problems if such names were being used. This should be 
clearly advertised, or a fix to this problem should be made.

2. A major error in XKMS is to consider to obtain information about keys, 
rather than information against certificates, which bind a public key to a 
name for a specific key usage and under a Certification Policy. Since there 
is not a one-to-one relationship between a key and a certificate, but a 
one-to-many relationship, it is not possible to make an unambiguous binding 
with a public key but only an unambiguous binding with a (public key) 
certificate.

3. The Certification Policy is a concept which seems to be ignored at the 
level of the interfaces that are being proposed.

4. In section [46] the text says:

"The XKMS specification defines three types of request:

X-KRSS Request
      A Register, Reissue, Revoke or Recover request as specified by the Key 
Information Service Specification".

There is indeed a typo, probably intentionally left by the editor, to make 
sure that at least someone read the specification: "Key Information Service 
Specification" should be changed into "Key *Registration* Service 
Specification".

5. The <ds:KeyInfo> (see [135]) is described as an "hint". This should not 
be the case since it is important to make sure under which certificate a 
signer wanted to sign. Several certificates may include the same public key 
and for that reason it is important to make sure that the certificate (or an 
unambiguous reference to it) is linked to the data that has been signed and 
is indeed protected by the signature. Without that link certificates could 
be substituted without notice. The concept is similar to ESSCertID that is 
used in CMS (see RFC 2634).

6. The fact that ds:KeyInfo> may or may not be cryptographically bound to 
the signature itself is advertised as an important property (see [136]). It 
is said: "This allows the <ds:KeyInfo> to be substituted or supplemented 
without "breaking" the digital signature". This should be considered as a 
severe weakness, since such a substitution is not desirable (see above). A 
certificate could be added, but the reference to the certificate should 
remain unchanged and unchangeable.

7. The XKISS Validate service verifies a binding with a public key, while 
the binding should be verified with a certificate (which contains a public 
key), instead of directly a public key value. CAs may deliver different 
certificates with the same public key but with different attributes in them. 
It is important to know which certificate has been used, rather than which 
public key has been used, since several certificates may include the same 
public key.

8. The two overviews from sections 1.5 and 1.6 do not provide a clear 
picture of the functions that are supported. They should be both revised. A 
text is proposed as an annex at the end of these comments.

9. The document provides several examples which are quite interesting. 
However the core of a standard should not include examples. Such examples 
should be placed in an annex. However if these examples were removed the 
text would not be understandable anymore, because the remaining explanations 
would be insufficient. It is thus requested to add more normative text and 
to move the examples in an informative annex.

10. The XKISS Locate service is defined as " The XKISS Locate service 
resolves a <ds:Keyinfo> element but does NOT REQUIRE the service to make an 
assertion concerning the validity of the binding between the data in the 
<ds:Keyinfo> element". What means "resolving <ds:Keyinfo> element" is not 
self-understandable. The exact processing that is supposed to be done by the 
service should be described in details.

11. The example (see [145]) is insufficient to describe what that service 
really does. The various input (and output) parameters should be clearly 
described. This is not the case.

The service seems to return only a key value, while it should return the 
main components from a certificate.

 From the example, it can be seen that the input parameters are a DNS name 
and the name of a protocol. Since no key usage is mentioned, the service is 
unable to know whether a certificate that includes a signature verification 
key or includes an encryption key is requested. A certificate should be 
returned and not a key, so that the user can verify the validity period of 
the certificate, otherwise a validity date should be included in the 
request. The certification policy contained in the certificate may also be 
helpful, unless it is specified in the request.

12. The XKISS Validate service is defined as : "The XKISS Validate Service 
allows all that the Locate Service does, and in addition, the client may 
obtain an assertion specifying the status of the binding between the public 
key and other data, for example a name or a set of extended attributes". 
What means "other data" is not self-understandable. The exact processing 
that is supposed to be done by the service should be described in details.

13. In [152] it is mentioned: "Furthermore the service represents that the 
status of each of the data elements returned is valid and that all are bound 
to the same public key". A <ds:Keyinfo> element may contain a <ds:X509Data> 
element. Therefore the binding is not with a key but with a certificate.

14. The example (see [155]) is insufficient to describe what that service 
really does. The various input (and output) parameters should be clearly 
described. This is not the case.
In particular, is the validation done only for the current time or can it be 
done for a time in the past ? Even, if this is the current time, is that 
time indicated in the response? The answer is only given (hidden) in section 
[215], but this should be clearly advertised upfront.

15. From its name, the XKISS Validate Service present a few similarities 
with the validation service requirements that have been defined by the PKIX 
WG from the IETF. This working group has produced RFC 3379 (Delegated Path 
Validation and Delegated Path Discovery Protocol Requirements) which is a 
set of requirements.

However, the XKMS specification is leaving aside many, if not most, of the 
these requirements. An important concept from RFC3379 is the concept of 
"validation policy". When a validation is done, it must be done according to 
a set of rules. These rules depends upon the application. In particular some 
root keys may be adequate for an application, but not for another. Trust 
elements cannot be uniform and cannot be left open to the Validate Server.

The text is speaking of a "validation criteria (see [161]), but it is 
unclear what it really is. This is one of the most severe limitations of 
XKMS and this limitation is not advertised.

It would be quite interesting to understand why the requirements from 
RFC3379 have not been followed.

16. The text is speaking of some means to locate the correct XKMS service 
(see [163]) but does not provide any guidance in order to solve this 
problem, in particular in the context of multiple servers offering their 
services to the users.

17. The text in [168] states: "the Service represents to the client 
accessing the service and to that client alone that the binding between the 
data elements is valid under whatever trust policy the service offers to 
that client." Unless the service can clearly advertise which trust policy is 
being used, the client cannot use any kind of trust policy without even 
knowing which one it is. As already stated, the concept of validation policy 
is not supported, but should be supported.

18. The text under [171] mentions: "The Id identifier is defined to provide 
a means by which the key binding may be signed using XML Signature. Clients 
MUST NOT rely on the key binding identifier being either unique or stable". 
On the contrary it is believed that a key identifier should be unique. The 
ESSCertID from RFC 2634 is a good example of such a unique binding.

19. The text under [174] considers only three intended uses of the key:

   1) Encryption : The key pair may be used for encryption and decryption,
   2) Signature : The key pair may be used for signature and verification,
   3) Exchange: The key pair may be used for key exchange.

However, the key usages should be defined in terms of security services (see 
ISO 7498-2), i.e. authentication service, confidentiality service and 
non-repudiation service.

To avoid some security problems it is particularly important to make a 
difference between a key usable for authentication and a key usable for 
non-repudiation. This cannot be covered by a single key usage called 
"signature".

20. The text under [177] mentions the <UseKeyWith> element which specifies a 
subject identifier and application identifier that determine a use of the 
key. The <UseKeyWith> must contain "Application" which is a URI that 
specifies the application protocol with which the key may be used and 
"Identifier" which specifies the subject to which the key corresponds within 
the specified application protocol. A protocol can support a sender and a 
receiver. It is unclear whether the Identifier corresponds to the sender or 
the receiver. It seems that the notion is by itself insufficient and should 
be extended to make such difference.

21. The text under [180] mentions S/MIME as a protocol. Why is CMS 
(Cryptographic Message Syntax) not considered as a protocol as well ?

22. The text under [180] mentions PKIX. It is very unclear to understand why 
PKIX is considered as a "protocol" since it is only a set of data structures.

23. The text under [180] mentions the use of "Certificate Subject Name" as 
an appropriate identifier. It should be observed that this name only is 
insufficient to correctly identify an entity, since two CAs may certify the 
same name and that this name may correspond to the same or to different 
entities. Unless a sequence of CAs names is added to the entity name up to a 
root key, such names are ambiguous. This relates to the non-uniqueness of DN 
names already mentioned.

24. The text under [180] identifies various protocols. To this list, XAdES 
(XML Advanced Electronic Signature) which is a W3C Note issued on February 
20, 2003 should be added (see: http://www.w3.org/TR/XAdES/). The 
"identifier" type is such a case is a SigningCertificate element, i.e. *not* 
a DN.

25. The description of the Validate Service are confusing. It seems to 
relate more to the Locate Service rather than the Validate Service where the 
primary response should be "valid according to some policy" or "invalid 
according to some trust policy". The exact service performed by the Validate 
Service is not sufficiently detailed.

26. In [221] it is mentioned: "The server returns one or more <KeyBinding> 
elements that meet the criteria specified in the request." It is 
questionable why not simply a valid, invalid or don't know assertion is made 
against the proposed binding.

27. In the case of validation, the "yet not valid" response should be 
considered, in particular when a certificate is suspended. This means that 
another validation request made later on may succeed.

28. The Register Service from KRSS is not sufficiently described. The two 
examples provide more information, but that information is not normative. 
 From the example, two features are mentioned:

1° authentication information to be used later on for revocation can be 
transmitted. However, it is unfortunate that the data does not also include 
the question to be answered.

2° it is necessary to have a face to face contact with the LRA before being 
able to use the register request. During that face to face information is 
captured by the LRA and the secret "authentication code" is provide to the 
end-user. However, this method is time consuming and does not allow a cost 
effective deployment of a PKI.

It is suggested to use another technique that places all the burden of the 
typing for the end-user, who receives back both a registration number and 
the hash of his request (signed by the service) so that the end-user can 
then authenticate to the LRA in a face to face where the Register Service 
has only to verify the information (and to only "click" to accept or 
reject). Another advantage is that no secret information is being used.

29. In the example [241] several identifiers are included :

<UseKeyWith Application="urn:ietf:rfc:2459"
Identifier="C=&quot;US&quot; O=&quot;Alice Corp&quot;
CN=&quot;Alice Aardvark&quot;"/>
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="[email-masked]"/>
<UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
Identifier="[email-masked]"/>

It is unclear to understand how the concept of "UseKeyWith Application" will 
be translated in an X.509 certificate, since an X.509 certificate does not 
support the concept of "UseKeyWith Application".

30. In the example [245] the private key is returned in the response. It 
will be quite uneasy for the end-user to memorize the authentication code 
3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 previously obtained through some 
out-of-band mechanism. This method would be quite difficult to use and would 
not allow an easy and cost effective deployment of a PKI. It is suggested to 
use another technique that allows the end user to locally generate a key 
pair, so that the public key can be sent in the Register Service request and 
then used by the Register Service to encrypt the private key once generated. 
The main advantage is that no secret information is being used and no 
out-of-bands mechanism is necessary.

31. The Reissue request mentions "A reissue request is made in the same 
manner as the initial registration of a key". It is not believed that this 
statement is correct. The user should provide the previously obtained 
certificate and ask for another validity period. There is no need to specify 
again secret information obtained through an out of bands mechanism.

32. The Revocation request should allow the possibility to carry a reason 
code and an Invalidity Date (RFC 2459 sates that CRL issuers are strongly 
encouraged to include meaningful reason codes in CRL entries).

33. The Revocation request example includes the certificate. It is very 
doubtful that the user will be able to provide its full certificate, if his 
smart card has been stolen. However he could more easily provide his subject 
name instead. The input and the output parameters are not sufficiently 
described.

34. The Recovery request mentions "A key recovery request is made in the 
same manner as the initial registration of a key". It is not believed that 
this statement is correct. There is no need to specify again secret 
information obtained through an out of bands mechanism.
Users do not have only a confidentiality key, but also an authentication 
key. They could use it to authenticate. If they loose everything, they could 
encrypt the authentication code under a key they wish their private key to 
be recovered (using PKCS#12) and authenticate their request by phone using 
the non-secret registration number of their request. For this to be 
possible, a hash of the request should be present in the response.

35. The security considerations section should be augmented to mention the 
severe limitations that are indicated above.

ANNEX

The following text is proposed as a global overview of these two sections.

Note: This text is re-using text already present and does not include 
changes that are suggested in the other comments.

"The XKMS specification defines three types of requests:

1. X-KISS (Key Information Service Specification) Request : A Locate or a 
Validate request.

The XKISS Locate service provides one or more unverified key bindings to the 
best of its knowledge but does not provide any assurance about that binding. 
Information obtained from a Locate service SHOULD NOT be relied upon unless 
it is validated. Validation may be achieved by forwarding the data to a 
Validate service or by performing the necessary trust path verification locally.

The XKISS Validate service allows a client to query the binding between a 
<ds:Keyinfo> element (i.e. <ds:X509Data>, <ds:X509Data>*, <ds:KeyName>, 
<ds:KeyValue>) and one or more <UseKeyWith> elements (i.e. an application 
protocol with which the key may be used and an "identifier" which specifies 
the subject to which the key corresponds within the specified application 
protocol).

2. X-KRSS (Key Registration Service Specification) Request :The XML Key 
Registration Service Specification permits management of information that is 
bound to a public key pair. The XKRSS service specification supports the 
following operations:

a)  Register : The Registration request message contains a prototype of the 
requested key binding which may contain only partial information, a key 
without a name or a name without a key. The registration service MAY require 
the client to provide additional information to authenticate the request. If 
the public key pair is generated by the client, the service MAY require the 
client to provide Proof of Possession of the private key.

b)  Reissue : A previously registered key binding is reissued unchanged 
except the validity period.

c)  Revoke : A previously registered key binding is revoked.

d)  Recover : The private key associated with a key binding is recovered.

3. Compound Request : A compound request allows multiple X-KISS or X-KRSS 
requests and the corresponding responses to be sent in a single message. 
This allows considerable processing resources to be saved as a single 
signature on the compound message may be used in place of multiple 
signatures on the individual requests or responses.

Denis

Date: Tue, 24 Jun 2003 22:07:41 -0400
To: "Hallam-Baker, Phillip" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SCEP newest spec
Cc: [email-masked]
Sender: [email-masked]

At 10:47 AM -0700 6/23/03, Hallam-Baker, Phillip wrote:
>  > All IETF WGs have (or should have) as a goal not creating duplicative
>>  standards.
>
>In which case the IETF PKIX group will kindly stop work on SCVP which
>duplicates functionality of the XKMS specification which has already
>passed last call.
>
>
>The way the IETF used to work was by recognizing de-facto standards
>that had achieved acceptance.
>
>>  By all means, feel free to bring SCEP to OASIS, a standards body
>>  where architectural concerns do not seem to interfere with the
>>  promotion of vendor protocols.
>
>I used to believe all that stuff about architecture, but no longer.
>
>IETF is hierarchy for the sake of hierarchy. The real reason they created
>the IAB, IESG etc. was to keep control out of the wrong hands which
>empirically would appear to be anyone who is willing to submit to its closed
>process with no accountability.
>
>The IETF stopped working as soon as it broke the rule of 150.
>
>		Phill

Phill,

Is this an April fool's message that was delayed?

Steve

Date: Tue, 24 Jun 2003 17:54:33 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG Last Call: Proxy Certificates
Sender: [email-masked]

This message initiates working group Last Call for the proxy specification. 
Last Call will run for (at least) two weeks. That is, Last Call will not 
close before July 9.

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

The editors have informed us that all working group issues have been resolved.

Thanks,

Tim Polk

Date: Tue, 24 Jun 2003 17:22:07 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Agenda requests, please
Sender: [email-masked]

Folks,

I will be putting together the agenda for the PKIX WG next week.  I would 
like to receive all agenda requests by the second of July.  I intend to 
sort through the requests and post the agenda on the 3rd.  WG activities 
will, as always, get preference for agenda time.

A few notes:
	(1) Please put the word agenda in the subject line!  It helps me navigate 
through the spam.
	(2) Please submit a request *even if you sent me mail before*.
	(3) I will be out of touch until the third, so I will not be able to 
respond immediately.
	
Thanks,

Tim Polk

Subject: Re: UK: PKI "not working"
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Date: Tue, 24 Jun 2003 09:47:33 -0600
Sender: [email-masked]

[email-masked] on 6/23/2003 1:44 am wrote:

I fully agree with Mitchell's conclusions of what PKI is good for as it
stands today.  To be able to serve millions of citizens at thousands of
independent e-government portals, either requires TTP identity-portals
(using SAML etc.), or client-side PKI using TTP CAs.  No other methods have
proven to be technically or economically feasible.

I cannot verify any major 100000-foot legal problems, but quite a bunch of
down-to-earth (zero-foot?) problems like "lousy browsers", and the lack of
ubiquitous, secure, and mobile key-containers.  IMO, it is really only the
latter that hampers enterprise-PKIs as a userid/password-replacement on a
wider scale.  This problem is neither a standards problem, nor a technical
ditto.   It is rather an example of blatant stupidity among "certain
manufacturers".

Regarding "legally binding", virtually anything that offers reasonable
technical integrity is likely to be applicable as evidence in a court trial
in most countries.  Examples of this are phone-operators' call-lists that
may prove "association" or DNA-fingerprints that may prove "It wasn't me".
What is a bit puzzling is that non-PKI e-solutions never seem to be
questioned regarding their.merits in courts...

A "legal" aspect that though really is an issue, is TTP CA liability.
However, this is mostly a US issue where suing people is a part of the
system.  I believe this will have a negative impact on PKI usage in the US,
unless there is a way to automatically accomplish what Identrus et al
"achieves" by requiring relying parties to sign agreements freeing the
issuer from liability.  Here I would like to address the PKIX WG with a
request for some kind of remedy.

Anders

============

I believe it is the electronic signature act ... and there are other parts
of the same bill. it allows various kinds of electronic  marks .... but the
main issue for a legal signature (& non-repudiation) is demonstration of
some sort of intent, agreement, etc. The EULAs that require clicking in
various places after reading variouis directions meet more of the criteria
of demonstrating intent & agreement than does almost all of the CA PKIs
that effectively don't enforce any process after the certificate has been
returned to the key owner.

The main issues addressed by the vairous public key digital signatures are
message authentication and integrity ..... as been repeated in numerous
past threads involving non-repudiation ... there is still an enormous gap
between message authentication/integrity and non-repudiation.

The big issue of TTP CA PKI and legaly issue is that  almost all legal
relationship (like contracts) are between two parties where one has paid
money and received something in return.  That describes the relationship
between the TTP CA PKI entity and the key owner. The legal objective seems
to be to create some legal fiction that involves a relationship between the
TTP CA PKI and the relying-party. The traditonal legal relationship doesn't
apply to anything between the TTP CA PKI and the relying-party. As been
mentioned in numerous, repeated threads on this subject in the past, GSA
manufactored such a relationship by some sort of contract between GSA and
the TTP CA PKI's ...  and GSA and the relying-parties .... so that the
facade of legal relationship between the relying parties and the TTPs. For
the most part, the traditional TTP CA PKI's enforce little or no process
after the certificate has been retruned to the key-owner.

Note that the GSA model is similar to the business/legal relationships
established as part of the online debit/credit infrastructures. The
debit/credit infrastructure used to be an offline, manual process. Starting
in the mid-70s, they skipped over the TTP CA PKI paradigm of offline,
electronic process and went directly to an online, electronic process. For
the debit/credit infrastructure the paradigm represented by TTP CA PKI
represents a 30 yuear old technology option that they decided to skip.

somewhat related is the recent thread on confusing authentication and
identification:
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and
Identiification?
http://www.garlic.com/~lynn/aepay11.htm#67 Confusing Authentication and
Identiification?
http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and
Identiification?
http://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and
Identiification?

past threads with mention of pair-wise GSA contracts with both TTPs and
relying-parties created
some sort of legal relationship between relying-parties and TTPs:
http://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/aadsm12.htm#41 I-D
ACTION:draft-ietf-pkix-sim-00.txt
http://www.garlic.com/~lynn/aadsm12.htm#42
draft-ietf-pkix-warranty-extn-01.txt
http://www.garlic.com/~lynn/aadsm14.htm#37 Keyservers and Spam

misc. past threads that reference non-repudiation as well listing other
threads on non-repudiation:
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2003h.html#38 entity authentication with
nonrepudiation
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

From: "todd glassey" <[email-masked]>
To: "Al Arsenault" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, <[email-masked]>, "Steven M. Bellovin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: SCEP newest spec
Date: Tue, 24 Jun 2003 07:32:58 -0700
Sender: [email-masked]

I can buy into that this is particular to XKMS or SCEP as an effort as a
thread here in PKIX because PKIX has particular need to be able to be
interoperable in the Security and Information Assurance space. But at the
bigger-picture view, it seems to me that this is turning into a POISED/IPR
issue about how to induct external works for formal reference in IETF
efforts, because that is clearly from this and other conversations one of
the IP management issues that this governance team needs to address, and
soon I would say.

Todd

----- Original Message ----- 
From: "Al Arsenault" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>; "'Stephen Kent'"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 23, 2003 12:16 PM
Subject: Re: SCEP newest spec

>
>
>
>
> >
> >
> > > All IETF WGs have (or should have) as a goal not creating duplicative
> > > standards.
> >
> > In which case the IETF PKIX group will kindly stop work on SCVP which
> > duplicates functionality of the XKMS specification which has already
> > passed last call.
> >
>
> AWA:  Gee, I can't find any references to XKMS having been submitted for
> IETF last call.  It's not in the queue.  Can you provide a pointer to the
> action?
>
> When I "SWFG" (to use your acronym) on IETF & XKMS I got a bunch of
> references to SACRED work, a document in the TRADE group, and a bunch of
> stuff about "W3C XKMS" meetings in conjunction with IETF meetings.
>
> What?  Oh, you mean that XKMS hasn't been through an IETF last call; it's
> some other standards group (specifically, W3C)?  Ah, yes, then, IETF
should
> clearly bow out of this area and accept what W3C has done as "gospel
truth".
> Nahhh!
>
> If IETF is going to get into the mode of simply accepting what somebody
else
> has done, even if we regard it as not correct or not applicable or
applying
> to a different context or ..., then we're going to get into trouble
quickly.
> For example, should we accept/endorse X9.68 certificates?  Why not? What
> about WTLS?  etc., ad infinitum, ad nauseum
>
> >
> > The way the IETF used to work was by recognizing de-facto standards
> > that had achieved acceptance.
> >
>
> AWA:  In general, I find that approach more palatable than "here's the
> answer a priori from us experts on high, before the technology has even
been
> developed".  With caveats, of course - just because it has achieved
> acceptance doesn't mean it's free from major security problems.
>
> And the fact that a company that styles itself as the leader in a
particular
> area has done something doesn't mean that everybody else must do it as
well.
>
> WRT XKMS:  it has achieved some measure of acceptance in IETF (the SACRED
> working group, among others).  That's fine.  But that doesn't mean that
XKMS
> is the single solution that will be used, or even that it is  the best
> solution to solve a specific problem.
>
> > > By all means, feel free to bring SCEP to OASIS, a standards body
> > > where architectural concerns do not seem to interfere with the
> > > promotion of vendor protocols.
> >
> > I used to believe all that stuff about architecture, but no longer.
> >
> > IETF is hierarchy for the sake of hierarchy. The real reason they
created
> > the IAB, IESG etc. was to keep control out of the wrong hands which
> > empirically would appear to be anyone who is willing to submit to its
> closed
> > process with no accountability.
> >
> > The IETF stopped working as soon as it broke the rule of 150.
> >
> > Phill
>
> AWA:  The IETF clearly has a lot of problems, many of which are brought
> about because (a) the size has gotten so large that most
> attendees/participants don't actually provide anything useful; they're
just
> their to report back on what's happening; (b) certain personalities seem
to
> be in the way of what others would consider progress (sometimes that's
good,
> sometimes bad; it depends on what you consider "progress"); (c) the market
> is so large and the competing interests so powerful that it's hard to
> overcome the inertia and get everybody to actually make a change; (d)
> probably other reasons as well.
>
> On the other hand, given some of the other standards and industry groups
in
> which I've worked, IETF often looks really good.
>
>
>                 Al Arsenault
>
>

From: "Dean Adams" <[email-masked]>
To: <[email-masked]>
Subject: RE: Revocation status checking of self-issued certificates
Date: Tue, 24 Jun 2003 14:46:25 +0100
Importance: Normal
Sender: [email-masked]

Hi,
	In some recent tests with IIS 5.0, I am led to suspect that if end-entity
certs have a CDP, then IIS wants to do revocation checking all the way up
the chain - including the self-signed root.  Can anyone else confirm or
correct this?

Dean Adams

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Brian Hunter
Sent: 19 June 2003 20:16
To: Matt Cooper; [email-masked]
Subject: Re: Revocation status checking of self-issued certificates

Matt,

Thanks for correcting my comment on Santosh's comment.  However, it still
leaves
my original question open, that is, what is done in regards to revocation
checks
for self-issued certificates.  Any comments?

Regards,
Brian

Matt Cooper wrote:
>
> Brian,
>
> I think what Santosh was saying is the names in the cert path should match
> the names for the CRL's cert path, irrespective of traversing a self
issued
> certificate on one or the other.
>
> For example, this would be ok -
> ====================================
> CertPath: A->B->C->Target Cert
> CRL Path:  A->B->B->C->CRL
>
> This is not ok:
> ====================================
> CertPath: A->B->C->Target Cert
> CRL Path:  A->C->B->C->CRL
>
> You might end up with the first example as the result of a rekey.
>
> Best Regards,
> Matt Cooper
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Brian Hunter
> > Sent: Wednesday, June 18, 2003 12:16 PM
> > To: [email-masked]
> > Subject: Revocation status checking of self-issued certificates
> >
> >
> >
> > Hello,
> >
> > I have a question of whether self-issued certificates need to
> > have their revocation status checked.  I am referring to only
> > intermediate or path ending self-issued certificates and not
> > trust anchors.
> >
> > I have read through some PKIX discussions, in particular
> > "Identifying the right CRL for a given certificate", where
> > Santosh seemed to imply that no check was
> > required:
> >   2.  The DNs for the certification path for the certificate
> > should match
> >   the DNs for the certification path for the CRL (ignoring self-issued
> >   certificates).  Of course, the last DN (namely the
> > subscriber DN) will
> >   be missing from the CRL certification path.
> >
> > (This is not exactly the same context, but I believe similar.
> >  I take "ignoring self-issued certificates" to imply that
> > there would be no revocation checks for
> > them.)
> > Another discussion, "CDP in self signed root CA", dealed only
> > with root CAs.
> >
> > I see the benefit of both, no checking saves time and rather
> > redundant checks.
> > The self-issued certificate could be revoked by having the
> > original CA certificate revoked, this is however costly.
> > Doing revocation checks allows the CA to revoke individual
> > self-issued certificates itself, without having to have its
> > own certificate revoked, provided that the self-issued
> > certificate wasn't the one delegated to be used as a CRLIssuer.
> >
> > However by reading X509 and RFC3280, it says to me that the
> > status of all self-issued certificates must be checked.
> > (Self-issued certificates tend to be excluded from such
> > things as name constraint processing and path lengths, but
> > not status checking).
> >
> > Could someone help clarify this for me, whether these certs
> > need to have their revocation status checked?
> >
> > Many thanks,
> > Brian
> >

Date: Mon, 23 Jun 2003 22:41:47 -0700 (PDT)
From: Max Pritikin <[email-masked]>
To: Massimiliano Pala <[email-masked]>
cc: [email-masked]
Subject: Re: SCEP newest spec
Sender: [email-masked]

Massimiliano,

For specific questions and concerns about SCEP you could send mail to:
	[email-masked]
I assure you your comments will be appreciated.

I really wish there was only one enrollment protocol. From my perspective
the current stalemate has done more to harm public key infrastructure
deployment than anything else.

So, is there any way for PKIX to settle on a single enrollment protocol?

	- max

On Mon, 23 Jun 2003, Massimiliano Pala wrote:

> Al Arsenault wrote:
> [ ... ]
> >
> >>The way the IETF used to work was by recognizing de-facto standards
> >>that had achieved acceptance.
> >>
> >
> > AWA:  In general, I find that approach more palatable than "here's the
> > answer a priori from us experts on high, before the technology has even been
> > developed".  With caveats, of course - just because it has achieved
> > acceptance doesn't mean it's free from major security problems.
> >
> > And the fact that a company that styles itself as the leader in a particular
> > area has done something doesn't mean that everybody else must do it as well.
>
> [ ... ]
>
> I have been working on the SCEP and really I find there are some flaws and
> some things could have been done in a better way. Anyway there is a de
> facto "quasi" standard and my position is that ietf should try to address
> the problem.
>
> I am just addressing the issue from a practical point of view, I guess that if
> we can take over the SCEP protocol and make it a standard - improving what
> should be improved - a wider and wiser discussion can be made and from which the
> whole community will be having benefits.
>
> Also, new versions of the protocol could be made stronger and somehow not
> colliding to other existing IETF standards.
>
> Just think about the possibility (and this is referred to the whole list) and
> if enough people agree we could start some work, otherwise we close the thread
> once for all.
>
> IMHO we should address the issue.
>
> --
>
> C'you,
>
> 	Massimiliano Pala
>
> --o-------------------------------------------------------------------------
> Massimiliano Pala [OpenCA Project Manager]                [email-masked]
>                                                   Tel.:   +39 (0)59  270  094
> http://www.openca.org                            Fax:    +39   178  221 8225
> http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365
>

From: "todd glassey" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "'Al Arsenault'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: SCEP newest spec
Date: Mon, 23 Jun 2003 14:32:57 -0700
Sender: [email-masked]

Phillip - the issues is whether the IETF is an Open and Fair "Standards
Body" or not. All of the paperwork says that it is, but when you ask people
how they implement fairness, or Openness,  they retort about
no-constituency, no votes, and no records of what anyone did or how it was
done. And then it seems that they vote on it with the rest of the IESG in a
secret session that makes a session of the FISA Judges look like a public
meeting

As to the IETF picking one "standard" over another, as it's own standard -
that also is blatantly unfair since anyone with enough money can clearly buy
a working group, and they can do that by just sticking enough bodies into
the mailing list such that they have a voting control during the straw
polls.

What needs to happen is that the IETF needs to be reduced to a mechanical
set of standards processes such that the real value here is the vetting of a
standard instead of the clandestine creation of a conspiracy to do damage to
all the other players besides the ones that control the WG's or the WG
Chairs.

Todd Glassey

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Al Arsenault'" <[email-masked]>; "Hallam-Baker, Phillip"
<[email-masked]>; "'Stephen Kent'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 23, 2003 12:32 PM
Subject: RE: SCEP newest spec

>
> > If IETF is going to get into the mode of simply accepting
> > what somebody else
> > has done, even if we regard it as not correct or not
> > applicable or applying
> > to a different context or ..., then we're going to get into
> > trouble quickly.
>
> Why differentiate between internal and external?
>
> If there is an argument for not reinventing the wheel then apply it
> uniformly. If on the other hand there is an argument for duplication on
> occasion then accept that.
>
>
> Phill

From: "todd glassey" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Subject: Re: UK: PKI "not working"
Date: Mon, 23 Jun 2003 13:41:09 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Actually - the real issue is that the US Digital Signature Act, nor any =
others that I am aware of "brought into  the play" that there would be =
protected signatures along side unprotected ones, since to invoke eSign =
it would take both parties making an "informed consent decision" to =
do...

So no, PKI is still a long way from prime-time availability.=20

Todd

  ----- Original Message -----=20
  From: Anders Rundgren=20
  To: [email-masked]=20
  Sent: Monday, June 23, 2003 12:44 AM
  Subject: Re: UK: PKI "not working"

  I fully agree with Mitchell's conclusions of what PKI is good for as =
it stands today.  To be able to serve millions of citizens at thousands =
of independent e-government portals, either requires TTP =
identity-portals (using SAML etc.), or client-side PKI using TTP CAs.  =
No other methods have proven to be technically or economically feasible.

  I cannot verify any major 100000-foot legal problems, but quite a =
bunch of down-to-earth (zero-foot?) problems like "lousy browsers", and =
the lack of ubiquitous, secure, and mobile key-containers.  IMO, it is =
really only the latter that hampers enterprise-PKIs as a =
userid/password-replacement on a wider scale.  This problem is neither a =
standards problem, nor a technical ditto.   It is rather an example of =
blatant stupidity among "certain manufacturers".

  Regarding "legally binding", virtually anything that offers reasonable =
technical integrity is likely to be applicable as evidence in a court =
trial in most countries.  Examples of this are phone-operators' =
call-lists that may prove "association" or DNA-fingerprints that may =
prove "It wasn't me".   What is a bit puzzling is that non-PKI =
e-solutions never seem to be questioned regarding their.merits in =
courts...

  A "legal" aspect that though really is an issue, is TTP CA liability.  =
However, this is mostly a US issue where suing people is a part of the =
system.  I believe this will have a negative impact on PKI usage in the =
US, unless there is a way to automatically accomplish what Identrus et =
al "achieves" by requiring relying parties to sign agreements freeing =
the issuer from liability.  Here I would like to address the PKIX WG =
with a request for some kind of remedy.

  Anders
    ----- Original Message -----=20
    From: Mitchell Arnone=20
    To: todd glassey ; Anders Rundgren ; [email-masked]=20
    Sent: Sunday, June 22, 2003 14:26
    Subject: Re: UK: PKI "not working"

    While PKI certainly has significant value with regards to applying =
digital signatures and other issues regarding non-repudiation, I believe =
that we often seem to overlook the main benefits that are used to =
justify deploying PKI today.

    PKI is the core component of any real Identity Management =
infrastructure.  It provides for strong authentication to networking =
systems and applications.  It serves to help reduce the number of =
managed identities for corporate employees and thereby improve security =
by eliminating passwords.  It provides integrity and confidentiality of =
email and assures recipients as to who actually sent the message.  It is =
used to validate software and make it more difficult to spread viruses.

    We are all familiar with these well advertised benefits but for some =
reason we seem to constantly dismiss them when talking about whether of =
not PKI is ready for prime time and or commercial desirability. =20

    Trust me... it is commercially desirable today.  Maybe one day we =
can figure out how to incorporate it into the legal infrastructure but =
that is not the driving force, at least not today.

    Identity management is the driving force for PKI and identity =
management is one of the most desirable solutions on the market today.

    At 11:18 PM 6/21/2003, todd glassey wrote:

      Anders, you are certainly a powerful force in the development of
      cryptography in Europe (and I do mean this, no sarcasm intended), =
so I
      respect the commentary.

      I do however respectfully disagree.  People use PKI because they =
have to not
      because it makes sense to yet and that is the problem in a nut =
shell. It is
      still not commercially viable to rely on PKI systems... and there =
is no
      proof yet that any of the EU's stringent privacy directives are =
ever going
      to be met. So even though some of the smaller nations have started =
to force
      their population to rely on PKI's in the form of Public x.509 =
certs (ala
      Verisign/Thawte etc etc etc)...

      My feeling from a higher-ground perspective is that PKI as a whole =
to date
      has failed to address 2000 years of human process and legal =
development and
      has actually sought to eliminate much of the ceremony in favor of =
a
      mechanical infrastructure ... i.e. to replace "it". But in =
response to that,
      I want to point out that PKI processes can be made to conform to =
paper
      signing ceremonies and that is the best way to get people to feel
      comfortable with PKI...because so far the only reasons to use a =
certificate
      are the ones where its mandated by law.  Which leads me to think =
that PKI is
      still years away from commercial desirability.

      In closing, I want to reiterate that in all the examples you cited =
we were
      talking about a legal mandate, not generally a choice, so that =
implies to me
      that so far the only reason to use PKI is for the Force of Law =
that the
      eSign legislation brought into it...

      Todd
      ----- Original Message -----=20
      From: "Anders Rundgren" <[email-masked]>
      To: "todd glassey" <[email-masked]>; =
<[email-masked]>
      Sent: Saturday, June 21, 2003 10:56 AM
      Subject: Re: UK: PKI "not working"

      > Todd,
      > May I comment on the UK e-envoy's complaints?
      >
      > Firstly, the UK do not have the concept of a "citizen identity".
      > It is IMHO fairly impossible to create useful TTP PKIs for =
on-line
      > authentication and signing without working naming schemes.
      > Not to mention creating multi-authority work-flow tasks
      > (or "one-stop shopping" as it is coined in Sweden).
      >
      > Secondly, in Sweden 3 million citizens out of 9 million total =
can
      > get a citizen certificate at the click of a button in their =
on-line bank
      > which is an indication that "not working" is not a universal =
truth.
      >
      > To be honest the Swedish bank consortium do not rely on the
      > browsers' built-in crypto-functions as these were considered as
      > unwieldy, and not sufficiently standardized.  Here your comments
      > regarding lacking or not accepted standards apply, as "web-sign"
      > is a major activity since years backs but still not covered by =
any
      > standards WG!  To circumvent this blatant deficiency, the banks
      > selected a proprietary Java applet from an IBM lab in Zurich.
      >
      > What indeed is not working [on a practical and wide scale] is =
the
      > concept of mobile PKI resources that can be used at home, in an
      > Internet caf=E9 or at work.  Here I believe ETSI's and EU's work =
in
      > the field of smart cards has generally failed.
      >
      > What is also not working is many-to-many encrypted e-mail.
      > But that does not really matter as the on-line paradigm using
      > https + web has effectively replaced encrypted e-mail for
      > both on-line banking and e-government services.
      >
      > Anders R
      >
      > ----- Original Message -----
      > From: "todd glassey" <[email-masked]>
      > To: <[email-masked]>; "el-sign: electronic signatures - open
      discussion" <[email-masked]>
      > Sent: Thursday, June 12, 2003 16:28
      > Subject: Fw: PKI "not working"
      >
      >
      >
      > This is a cross posting from the ISC's mailing lists of the Bar
      Association.
      >
      > Why it is important here is that it documents perceived problems =
in the
      PKI
      > marketplace and I perceive that a number of these issues are =
failures in
      the
      > IETF's and potentially the ETSI standards processes, since they =
allow
      > processes that are at best incomplete from a deployment stance =
to be
      > elevated into standards status IMHO.
      >
      > My concern is that the value of the IETF and ETSI is growing =
less and less
      > with these types of realizations in the marketplace.
      >
      > Todd
      >
      >
      > To: <[email-masked]>
      > Sent: Thursday, June 12, 2003 7:00 AM
      > Subject: UK: PKI "not working"
      >
      >
      > > PKI is 'not working'
      > >
      > > Inadequate technology for online transactions is a 'huge =
problem' for
      > those
      > > in charge of e-government, admits a leading Whitehall official =
The
      > e-envoy's
      > > office has started searching for new ways to authenticate the =
users of
      > > e-services as the existing technology being used is "not =
working", a
      > senior
      > > Government official revealed on 11 June 2003. Although PKI =
(public key
      > > infrastructure) and digital certificate technology has played =
a major
      role
      > > in leading projects such as the Government Gateway, there is =
now growing
      > > recognition that it is unsuited for wider public use. While =
digital
      > > certificates would not be scrapped, and would be retained as =
an option
      for
      > > e-service users, one possible alternative being suggested is =
that
      > employers,
      > > banks, the voluntary sector and other "trusted organisations" =
would
      verify
      > a
      > > person's identity before transacting online for services. =
Speaking on
      > > condition of anonymity, the official said the Government is =
now looking
      at
      > > "radical ways" of solving the authentication problem. "Trust =
and
      > > authentication has been a huge problem for us. We haven't got =
a solution
      > for
      > > authentication. We've been trying with PKI for about 10 years =
now and
      its
      > > not working because it's a pain to implement and to use. We've =
been
      > looking
      > > to take the pain out of PKI. "What we are saying with =
authentication is
      > that
      > > if another trusted organisation such as a bank can provide =
proof saying
      > you
      > > are who you say you are that should take the need away for =
digital
      > > certificates." The move comes as the e-envoy's office is =
acutely aware
      > that
      > > it needs to step up the pace of e-government leading up to the =
2005
      > target.
      =
http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA=
?Op
      > > enDocument
      =
<http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176E=
A?O> > penDocument>
      > >
      > > Michael Power
      > >
      > > Partner & Chief Privacy Officer
      > > Gowling Lafleur Henderson LLP
      > > Barristers & Solicitors
      > > Patent & Trade Mark Agents
      > > Suite 2600
      > > 160 Elgin Street
      > > Ottawa, Ontario, CANADA
      > > K1P 1C3
      > >
      > >
      > >
      >
      >
    ***********************************************************
    Mitchell Arnone
    Managing Consultant
    SchlumbergerSema
    Technical Consulting Practice, Northeast Region

    [email-masked]
    www.slb.com/nws

    SchlumbergerSema=20
    Network & Infrastructure Solutions
    194 Wood Avenue, South
    Iselin, NJ 08830
    Direct Line- (410) 579-8691
    Mobile - (443) 864-1590

------=_NextPart_000_007B_01C3398D.1A4C0EF0
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Actually - the real issue is that the =
US Digital=20
Signature Act, nor any others that I am aware of "brought into&nbsp; the =
play"=20
that there would be protected signatures along side unprotected ones, =
since to=20
invoke eSign it would take both parties making an "informed consent =
decision" to=20
do...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So no, PKI is still a long way from =
prime-time=20
availability. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, June 23, 2003 =
12:44=20
AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: UK: PKI "not =
working"</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>I fully agree with Mitchell's =
conclusions of what=20
  PKI is good for as it stands today.&nbsp; To be able to serve millions =
of=20
  citizens at thousands of independent e-government portals, either =
requires TTP=20
  identity-portals (using SAML etc.),&nbsp;or client-side PKI using TTP=20
  CAs.&nbsp; <EM>No other methods have proven to be technically or =
economically=20
  feasible</EM>.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I cannot verify any major 100000-foot =
legal=20
  problems, but quite a bunch of&nbsp;down-to-earth =
(zero-foot?)&nbsp;problems=20
  like "lousy browsers", and the lack of ubiquitous,&nbsp;secure,=20
  and&nbsp;mobile key-containers.&nbsp; IMO, it is really only the =
latter that=20
  hampers enterprise-PKIs as a userid/password-replacement on a =
<EM>wider=20
  scale</EM>.&nbsp; This problem is neither a standards problem, =
nor&nbsp;a=20
  technical ditto.&nbsp;&nbsp; It is rather an example of blatant =
stupidity=20
  among&nbsp;"certain manufacturers".</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>
  <DIV><FONT face=3DArial size=3D2>Regarding "legally binding",=20
  virtually&nbsp;<EM>anything</EM> that offers reasonable=20
  technical&nbsp;integrity&nbsp;is likely to be&nbsp;applicable as =
evidence in a=20
  court trial in most countries.&nbsp; Examples of this are =
phone-operators'=20
  call-lists that may prove "association" or DNA-fingerprints that may =
prove "It=20
  wasn't me".&nbsp;&nbsp; What is a bit puzzling is that&nbsp;non-PKI=20
  e-solutions never seem to be questioned&nbsp;regarding their.merits in =

  courts...</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>A&nbsp;"legal" =
aspect that=20
  though really is an issue, is TTP CA liability.&nbsp; However, this is =
mostly=20
  a US issue where suing people is a&nbsp;part of the system.&nbsp; I =
believe=20
  this will have a negative impact on PKI usage in the US, unless there =
is a way=20
  to <EM>automatically accomplish</EM> what Identrus et al "achieves" by =

  requiring relying parties to sign agreements freeing the=20
  issuer&nbsp;from&nbsp;liability.&nbsp; Here I would like to address =
the PKIX=20
  WG with a request for some kind of remedy.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=[email-masked]=20
    href=3D"mailto:[email-masked]">Mitchell Arnone</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
    title=[email-masked]=20
    href=3D"mailto:[email-masked]">todd glassey</A> ; <A=20
    title=[email-masked]=20
    href=3D"mailto:[email-masked]">Anders Rundgren</A> ; <A=20
    title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, June 22, 2003 =
14:26</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: UK: PKI "not=20
working"</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>While PKI =
certainly has=20
    significant value with regards to applying digital signatures and =
other=20
    issues regarding non-repudiation, I believe that we often seem to =
overlook=20
    the main benefits that are used to justify deploying PKI =
today.<BR><BR>PKI=20
    is the core component of any real Identity Management =
infrastructure.&nbsp;=20
    It provides for strong authentication to networking systems and=20
    applications.&nbsp; It serves to help reduce the number of managed=20
    identities for corporate employees and thereby improve security by=20
    eliminating passwords.&nbsp; It provides integrity and =
confidentiality of=20
    email and assures recipients as to who actually sent the =
message.&nbsp; It=20
    is used to validate software and make it more difficult to spread=20
    viruses.<BR><BR>We are all familiar with these well advertised =
benefits but=20
    for some reason we seem to constantly dismiss them when talking =
about=20
    whether of not PKI is ready for prime time and or commercial=20
    desirability.&nbsp; <BR><BR>Trust me... it is commercially desirable =

    today.&nbsp; Maybe one day we can figure out how to incorporate it =
into the=20
    legal infrastructure but that is not the driving force, at least not =

    today.<BR><BR>Identity management is the driving force for PKI and =
identity=20
    management is one of the most desirable solutions on the market=20
    today.<BR><BR><BR><BR>At 11:18 PM 6/21/2003, todd glassey =
wrote:<BR><BR>
    <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">Anders, you are =
certainly a=20
      powerful force in the development of<BR>cryptography in Europe =
(and I do=20
      mean this, no sarcasm intended), so I<BR>respect the =
commentary.<BR><BR>I=20
      do however respectfully disagree.&nbsp; People use PKI because =
they have=20
      to not<BR>because it makes sense to yet and that is the problem in =
a nut=20
      shell. It is<BR>still not commercially viable to rely on PKI =
systems...=20
      and there is no<BR>proof yet that any of the EU's stringent =
privacy=20
      directives are ever going<BR>to be met. So even though some of the =
smaller=20
      nations have started to force<BR>their population to rely on PKI's =
in the=20
      form of Public x.509 certs (ala<BR>Verisign/Thawte etc etc=20
      etc)...<BR><BR>My feeling from a higher-ground perspective is that =
PKI as=20
      a whole to date<BR>has failed to address 2000 years of human =
process and=20
      legal development and<BR>has actually sought to eliminate much of =
the=20
      ceremony in favor of a<BR>mechanical infrastructure ... i.e. to =
replace=20
      "it". But in response to that,<BR>I want to point out that PKI =
processes=20
      can be made to conform to paper<BR>signing ceremonies and that is =
the best=20
      way to get people to feel<BR>comfortable with PKI...because so far =
the=20
      only reasons to use a certificate<BR>are the ones where its =
mandated by=20
      law.&nbsp; Which leads me to think that PKI is<BR>still years away =
from=20
      commercial desirability.<BR><BR>In closing, I want to reiterate =
that in=20
      all the examples you cited we were<BR>talking about a legal =
mandate, not=20
      generally a choice, so that implies to me<BR>that so far the only =
reason=20
      to use PKI is for the Force of Law that the<BR>eSign legislation =
brought=20
      into it...<BR><BR>Todd<BR>----- Original Message ----- <BR>From: =
"Anders=20
      Rundgren" &lt;[email-masked]&gt;<BR>To: "todd glassey"=20
      &lt;[email-masked]&gt;; =
&lt;[email-masked]&gt;<BR>Sent:=20
      Saturday, June 21, 2003 10:56 AM<BR>Subject: Re: UK: PKI "not=20
      working"<BR><BR><BR>&gt; Todd,<BR>&gt; May I comment on the UK =
e-envoy's=20
      complaints?<BR>&gt;<BR>&gt; Firstly, the UK do not have the =
concept of a=20
      "citizen identity".<BR>&gt; It is IMHO fairly impossible to create =
useful=20
      TTP PKIs for on-line<BR>&gt; authentication and signing without =
working=20
      naming schemes.<BR>&gt; Not to mention creating multi-authority =
work-flow=20
      tasks<BR>&gt; (or "one-stop shopping" as it is coined in=20
      Sweden).<BR>&gt;<BR>&gt; Secondly, in Sweden 3 million citizens =
out of 9=20
      million total can<BR>&gt; get a citizen certificate at the click =
of a=20
      button in their on-line bank<BR>&gt; which is an indication that =
"not=20
      working" is not a universal truth.<BR>&gt;<BR>&gt; To be honest =
the=20
      Swedish bank consortium do not rely on the<BR>&gt; browsers' =
built-in=20
      crypto-functions as these were considered as<BR>&gt; unwieldy, and =
not=20
      sufficiently standardized.&nbsp; Here your comments<BR>&gt; =
regarding=20
      lacking or not accepted standards apply, as "web-sign"<BR>&gt; is =
a major=20
      activity since years backs but still not covered by any<BR>&gt; =
standards=20
      WG!&nbsp; To circumvent this blatant deficiency, the banks<BR>&gt; =

      selected a proprietary Java applet from an IBM lab in=20
      Zurich.<BR>&gt;<BR>&gt; What indeed is not working [on a practical =
and=20
      wide scale] is the<BR>&gt; concept of mobile PKI resources that =
can be=20
      used at home, in an<BR>&gt; Internet caf=E9 or at work.&nbsp; Here =
I believe=20
      ETSI's and EU's work in<BR>&gt; the field of smart cards has =
generally=20
      failed.<BR>&gt;<BR>&gt; What is also not working is many-to-many =
encrypted=20
      e-mail.<BR>&gt; But that does not really matter as the on-line =
paradigm=20
      using<BR>&gt; https + web has effectively replaced encrypted =
e-mail=20
      for<BR>&gt; both on-line banking and e-government=20
      services.<BR>&gt;<BR>&gt; Anders R<BR>&gt;<BR>&gt; ----- Original =
Message=20
      -----<BR>&gt; From: "todd glassey"=20
      &lt;[email-masked]&gt;<BR>&gt; To:=20
      &lt;[email-masked]&gt;; "el-sign: electronic signatures -=20
      open<BR>discussion" &lt;[email-masked]&gt;<BR>&gt; Sent: =
Thursday,=20
      June 12, 2003 16:28<BR>&gt; Subject: Fw: PKI "not=20
      working"<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; This is a cross posting =
from the=20
      ISC's mailing lists of the Bar<BR>Association.<BR>&gt;<BR>&gt; Why =
it is=20
      important here is that it documents perceived problems in=20
      the<BR>PKI<BR>&gt; marketplace and I perceive that a number of =
these=20
      issues are failures in<BR>the<BR>&gt; IETF's and potentially the =
ETSI=20
      standards processes, since they allow<BR>&gt; processes that are =
at best=20
      incomplete from a deployment stance to be<BR>&gt; elevated into =
standards=20
      status IMHO.<BR>&gt;<BR>&gt; My concern is that the value of the =
IETF and=20
      ETSI is growing less and less<BR>&gt; with these types of =
realizations in=20
      the marketplace.<BR>&gt;<BR>&gt; Todd<BR>&gt;<BR>&gt;<BR>&gt; To:=20
      &lt;[email-masked]&gt;<BR>&gt; Sent: Thursday, June 12, =
2003 7:00=20
      AM<BR>&gt; Subject: UK: PKI "not working"<BR>&gt;<BR>&gt;<BR>&gt; =
&gt; PKI=20
      is 'not working'<BR>&gt; &gt;<BR>&gt; &gt; Inadequate technology =
for=20
      online transactions is a 'huge problem' for<BR>&gt; those<BR>&gt; =
&gt; in=20
      charge of e-government, admits a leading Whitehall official =
The<BR>&gt;=20
      e-envoy's<BR>&gt; &gt; office has started searching for new ways =
to=20
      authenticate the users of<BR>&gt; &gt; e-services as the existing=20
      technology being used is "not working", a<BR>&gt; senior<BR>&gt; =
&gt;=20
      Government official revealed on 11 June 2003. Although PKI (public =

      key<BR>&gt; &gt; infrastructure) and digital certificate =
technology has=20
      played a major<BR>role<BR>&gt; &gt; in leading projects such as =
the=20
      Government Gateway, there is now growing<BR>&gt; &gt; recognition =
that it=20
      is unsuited for wider public use. While digital<BR>&gt; &gt; =
certificates=20
      would not be scrapped, and would be retained as an =
option<BR>for<BR>&gt;=20
      &gt; e-service users, one possible alternative being suggested is=20
      that<BR>&gt; employers,<BR>&gt; &gt; banks, the voluntary sector =
and other=20
      "trusted organisations" would<BR>verify<BR>&gt; a<BR>&gt; &gt; =
person's=20
      identity before transacting online for services. Speaking =
on<BR>&gt; &gt;=20
      condition of anonymity, the official said the Government is now=20
      looking<BR>at<BR>&gt; &gt; "radical ways" of solving the =
authentication=20
      problem. "Trust and<BR>&gt; &gt; authentication has been a huge =
problem=20
      for us. We haven't got a solution<BR>&gt; for<BR>&gt; &gt; =
authentication.=20
      We've been trying with PKI for about 10 years now =
and<BR>its<BR>&gt; &gt;=20
      not working because it's a pain to implement and to use. We've=20
      been<BR>&gt; looking<BR>&gt; &gt; to take the pain out of PKI. =
"What we=20
      are saying with authentication is<BR>&gt; that<BR>&gt; &gt; if =
another=20
      trusted organisation such as a bank can provide proof =
saying<BR>&gt;=20
      you<BR>&gt; &gt; are who you say you are that should take the need =
away=20
      for digital<BR>&gt; &gt; certificates." The move comes as the =
e-envoy's=20
      office is acutely aware<BR>&gt; that<BR>&gt; &gt; it needs to step =
up the=20
      pace of e-government leading up to the 2005<BR>&gt; =
target.<BR>&gt;=20
      &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt;<BR><A=20
      =
href=3D"http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43=
004176EA?Op"=20
      =
eudora=3D"autourl">http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5=
A1680256D43004176EA?Op</A><BR>&gt;=20
      &gt; enDocument<BR>&gt; &gt;<BR>&gt;<BR>&lt;<A=20
      =
href=3D"http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43=
004176EA?O"=20
      =
eudora=3D"autourl">http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5=
A1680256D43004176EA?O</A>&gt;=20
      &gt; penDocument&gt;<BR>&gt; &gt;<BR>&gt; &gt; Michael =
Power<BR>&gt;=20
      &gt;<BR>&gt; &gt; Partner &amp; Chief Privacy Officer<BR>&gt; &gt; =
Gowling=20
      Lafleur Henderson LLP<BR>&gt; &gt; Barristers &amp; =
Solicitors<BR>&gt;=20
      &gt; Patent &amp; Trade Mark Agents<BR>&gt; &gt; Suite =
2600<BR>&gt; &gt;=20
      160 Elgin Street<BR>&gt; &gt; Ottawa, Ontario, CANADA<BR>&gt; &gt; =
K1P=20
      1C3<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt;=20
    &gt;<BR>&gt;<BR>&gt;</BLOCKQUOTE><X-SIGSEP>
    =
<P></X-SIGSEP>***********************************************************=
<BR>Mitchell=20
    Arnone<BR>Managing Consultant<BR>SchlumbergerSema<BR>Technical =
Consulting=20
    Practice, Northeast Region<BR><BR>[email-masked]<BR><A=20
    href=3D"http://www.slb.com/nws"=20
    eudora=3D"autourl">www.slb.com/nws</A><BR><BR><FONT face=3Dimpact =
color=3D#0000ff=20
    size=3D4>Schlumberger</FONT><FONT face=3Dimpact color=3D#ff0000=20
    size=3D4>S</FONT><FONT face=3Dimpact color=3D#0000ff =
size=3D4>ema</FONT><FONT=20
    face=3Darial color=3D#0000ff size=3D4> <BR></FONT><FONT=20
    face=3D"Univers 47 CondensedLight" color=3D#808080 size=3D4>Network =
&amp;=20
    Infrastructure Solutions<BR></FONT><FONT color=3D#000080>194 Wood =
Avenue,=20
    South<BR>Iselin, NJ 08830<BR>Direct Line- (410) 579-8691<BR>Mobile - =
(443)=20
    864-1590<BR><BR></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_007B_01C3398D.1A4C0EF0--

Date: Mon, 23 Jun 2003 22:39:34 +0200
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
To: [email-masked]
Subject: Re: SCEP newest spec
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090700020307090905080703
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Al Arsenault wrote:
[ ... ]
> 
>>The way the IETF used to work was by recognizing de-facto standards
>>that had achieved acceptance.
>>
> 
> AWA:  In general, I find that approach more palatable than "here's the
> answer a priori from us experts on high, before the technology has even been
> developed".  With caveats, of course - just because it has achieved
> acceptance doesn't mean it's free from major security problems.
> 
> And the fact that a company that styles itself as the leader in a particular
> area has done something doesn't mean that everybody else must do it as well.

[ ... ]

I have been working on the SCEP and really I find there are some flaws and
some things could have been done in a better way. Anyway there is a de
facto "quasi" standard and my position is that ietf should try to address
the problem.

I am just addressing the issue from a practical point of view, I guess that if
we can take over the SCEP protocol and make it a standard - improving what
should be improved - a wider and wiser discussion can be made and from which the
whole community will be having benefits.

Also, new versions of the protocol could be made stronger and somehow not
colliding to other existing IETF standards.

Just think about the possibility (and this is referred to the whole list) and
if enough people agree we could start some work, otherwise we close the thread
once for all.

IMHO we should address the issue.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [email-masked]
                                                  Tel.:   +39 (0)59  270  094
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

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

--------------ms090700020307090905080703--

From: "Al Arsenault" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: SCEP newest spec
Date: Mon, 23 Jun 2003 16:29:56 -0400
Sender: [email-masked]

> > If IETF is going to get into the mode of simply accepting
> > what somebody else
> > has done, even if we regard it as not correct or not
> > applicable or applying
> > to a different context or ..., then we're going to get into
> > trouble quickly.
>
> Why differentiate between internal and external?
>
> If there is an argument for not reinventing the wheel then apply it
> uniformly. If on the other hand there is an argument for duplication on
> occasion then accept that.
>
>

Al Arsenault's personal opinion:  Phill's comment is essentially correct.
However, it ignores some facts.

One of the first things that I would hope any working group (IETF or
otherwise) would do is establish some sort of requirements.  That is,
exactly what problems do you think you're trying to solve, and what
constitutes a successful solution?  Then you move on to finding your
solutions.  (I recognize that this is often not what's done - there are too
many times when people run around with solutions, just looking for that
perfect problem.  But that's another thread.)

If IETF has identified a problem, and there is an acceptable solution
developed in a different forum - ANSI, ETSI, OASIS,
Joe's-Standards-and-Storm-Doors, wherever - then certainly IETF should look
at adopting or pointing to that solution.  There is no point in creating a
new, competing technology that will simply harm interoperability and
fragment the Internet.

Sometimes IETF would simply publish the existing solution as an RFC;
sometimes IETF would tailor/profile the solution; sometimes IETF would work
with the other group to jointly "develop" the solution; sometimes IETF would
not publish a document but would simply point to the other solution.

This is often done - to wit, ANSI or IEEE versions of crypto-algorithm
specs; the X.509 certificate spec; the jointly-developed XML DSIG spec; etc.

However, sometimes what is accepted as a solution by another group is deemed
unacceptable by IETF, for one reason or another.  It might be because that
other solution has unacceptable IPR constraints.  It might be because it
doesn't apply to the "Internet context".  It might be because it doesn't
meet the entire set of IETF requirements (see above).  It might be because,
to use the technical term, it creates a partial vacuum.  In that case, then
it's not inappropriate at all for IETF to "ignore" the external solution,
and develop one for the Internet that meets IETF requirements.

In the case that came up earlier in this thread:  the PKIX working group
developed a set of requirements for a DPV/DPD solution.  A number of
proposed solutions were set forth.  One was chosen.  It wasn't XKMS. I can't
find anywhere that XKMS was seriously advanced as a potential DPD/DPV
solution; I certainly can't find the compliance matrix for it.  (Apologies
if I didn't search hard enough; pointers would be appreciated.)

Thus, the IETF - PKIX in particular - is perfectly justified in developing a
solution to meet its requirements, notwithstanding the fact that another
standards group with some level of overlap in membership has chosen to use
another solution to meet ITS identified requirements.

Now, if XKMS had clearly met the DPD/DPV requirements in RFC 3379, and IETF
ignored/rejected it because of a "not invented here" attitude, then Phill's
complaints would be legitimate. Otherwise, they're not.

Hence my comments about X9.68, and WTLS.  Two other "standards" bodies -
ANSI X9F1 and WAP Forum, respectively - thought that they had their own sets
of requirements, and established solutions for them.  Good for them.
There's no reason for IETF to adopt those solutions, UNLESS we believe that
our consituency - which is theoretically "the Internet" - has the same
requirements.  It doesn't.

WRT SCEP: regardless of how they came into being, we already have two
protocols that do the same task.  Unless there's a clear reason why SCEP is
"better", which would justify obsoleting the two solutions we have and
adopting SCEP, Steve Kent's answer is appropriate:  we ain't gonna make the
situation worse by publishing a third way to do the same thing.

                        Al Arsenault

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Al Arsenault'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: SCEP newest spec
Date: Mon, 23 Jun 2003 12:32:03 -0700
Sender: [email-masked]

> If IETF is going to get into the mode of simply accepting 
> what somebody else
> has done, even if we regard it as not correct or not 
> applicable or applying
> to a different context or ..., then we're going to get into 
> trouble quickly.

Why differentiate between internal and external?

If there is an argument for not reinventing the wheel then apply it
uniformly. If on the other hand there is an argument for duplication on
occasion then accept that.

		Phill 

From: "Al Arsenault" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: SCEP newest spec
Date: Mon, 23 Jun 2003 15:16:07 -0400
Sender: [email-masked]

>
>
> > All IETF WGs have (or should have) as a goal not creating duplicative
> > standards.
>
> In which case the IETF PKIX group will kindly stop work on SCVP which
> duplicates functionality of the XKMS specification which has already
> passed last call.
>

AWA:  Gee, I can't find any references to XKMS having been submitted for
IETF last call.  It's not in the queue.  Can you provide a pointer to the
action?

When I "SWFG" (to use your acronym) on IETF & XKMS I got a bunch of
references to SACRED work, a document in the TRADE group, and a bunch of
stuff about "W3C XKMS" meetings in conjunction with IETF meetings.

What?  Oh, you mean that XKMS hasn't been through an IETF last call; it's
some other standards group (specifically, W3C)?  Ah, yes, then, IETF should
clearly bow out of this area and accept what W3C has done as "gospel truth".
Nahhh!

If IETF is going to get into the mode of simply accepting what somebody else
has done, even if we regard it as not correct or not applicable or applying
to a different context or ..., then we're going to get into trouble quickly.
For example, should we accept/endorse X9.68 certificates?  Why not? What
about WTLS?  etc., ad infinitum, ad nauseum

>
> The way the IETF used to work was by recognizing de-facto standards
> that had achieved acceptance.
>

AWA:  In general, I find that approach more palatable than "here's the
answer a priori from us experts on high, before the technology has even been
developed".  With caveats, of course - just because it has achieved
acceptance doesn't mean it's free from major security problems.

And the fact that a company that styles itself as the leader in a particular
area has done something doesn't mean that everybody else must do it as well.

WRT XKMS:  it has achieved some measure of acceptance in IETF (the SACRED
working group, among others).  That's fine.  But that doesn't mean that XKMS
is the single solution that will be used, or even that it is  the best
solution to solve a specific problem.

> > By all means, feel free to bring SCEP to OASIS, a standards body
> > where architectural concerns do not seem to interfere with the
> > promotion of vendor protocols.
>
> I used to believe all that stuff about architecture, but no longer.
>
> IETF is hierarchy for the sake of hierarchy. The real reason they created
> the IAB, IESG etc. was to keep control out of the wrong hands which
> empirically would appear to be anyone who is willing to submit to its
closed
> process with no accountability.
>
> The IETF stopped working as soon as it broke the rule of 150.
>
> Phill

AWA:  The IETF clearly has a lot of problems, many of which are brought
about because (a) the size has gotten so large that most
attendees/participants don't actually provide anything useful; they're just
their to report back on what's happening; (b) certain personalities seem to
be in the way of what others would consider progress (sometimes that's good,
sometimes bad; it depends on what you consider "progress"); (c) the market
is so large and the competing interests so powerful that it's hard to
overcome the inertia and get everybody to actually make a change; (d)
probably other reasons as well.

On the other hand, given some of the other standards and industry groups in
which I've worked, IETF often looks really good.

                Al Arsenault

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: SCEP newest spec
Date: Mon, 23 Jun 2003 10:47:14 -0700
Sender: [email-masked]

> All IETF WGs have (or should have) as a goal not creating duplicative 
> standards. 

In which case the IETF PKIX group will kindly stop work on SCVP which
duplicates functionality of the XKMS specification which has already
passed last call.

The way the IETF used to work was by recognizing de-facto standards
that had achieved acceptance.

> By all means, feel free to bring SCEP to OASIS, a standards body 
> where architectural concerns do not seem to interfere with the 
> promotion of vendor protocols.

I used to believe all that stuff about architecture, but no longer.

IETF is hierarchy for the sake of hierarchy. The real reason they created
the IAB, IESG etc. was to keep control out of the wrong hands which
empirically would appear to be anyone who is willing to submit to its closed
process with no accountability.

The IETF stopped working as soon as it broke the rule of 150.

		Phill

Date: Mon, 23 Jun 2003 10:29:29 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: poll for a meeting agenda
Cc: [email-masked]
Sender: [email-masked]

At 5:21 PM +0200 6/18/03, Peter Sylvester wrote:
>Would it be possible for the chair to indicate whether they
>have approved new working drafts before the cut of date
>last Monday?

I have been away on vacation for about 2 weeks, and then a business 
trip. I have not approved any new IDs. (And I'm still trying to catch 
up on over 1K of non-spam messages.) Tim may have approved some while 
I was away. I have not corresponded with him yet

Steve

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: UK: PKI "not working"
Date: Mon, 23 Jun 2003 09:44:48 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C3396C.15D46C80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I fully agree with Mitchell's conclusions of what PKI is good for as it =
stands today.  To be able to serve millions of citizens at thousands of =
independent e-government portals, either requires TTP identity-portals =
(using SAML etc.), or client-side PKI using TTP CAs.  No other methods =
have proven to be technically or economically feasible.

I cannot verify any major 100000-foot legal problems, but quite a bunch =
of down-to-earth (zero-foot?) problems like "lousy browsers", and the =
lack of ubiquitous, secure, and mobile key-containers.  IMO, it is =
really only the latter that hampers enterprise-PKIs as a =
userid/password-replacement on a wider scale.  This problem is neither a =
standards problem, nor a technical ditto.   It is rather an example of =
blatant stupidity among "certain manufacturers".

Regarding "legally binding", virtually anything that offers reasonable =
technical integrity is likely to be applicable as evidence in a court =
trial in most countries.  Examples of this are phone-operators' =
call-lists that may prove "association" or DNA-fingerprints that may =
prove "It wasn't me".   What is a bit puzzling is that non-PKI =
e-solutions never seem to be questioned regarding their.merits in =
courts...

A "legal" aspect that though really is an issue, is TTP CA liability.  =
However, this is mostly a US issue where suing people is a part of the =
system.  I believe this will have a negative impact on PKI usage in the =
US, unless there is a way to automatically accomplish what Identrus et =
al "achieves" by requiring relying parties to sign agreements freeing =
the issuer from liability.  Here I would like to address the PKIX WG =
with a request for some kind of remedy.

Anders
  ----- Original Message -----=20
  From: Mitchell Arnone=20
  To: todd glassey ; Anders Rundgren ; [email-masked]=20
  Sent: Sunday, June 22, 2003 14:26
  Subject: Re: UK: PKI "not working"

  While PKI certainly has significant value with regards to applying =
digital signatures and other issues regarding non-repudiation, I believe =
that we often seem to overlook the main benefits that are used to =
justify deploying PKI today.

  PKI is the core component of any real Identity Management =
infrastructure.  It provides for strong authentication to networking =
systems and applications.  It serves to help reduce the number of =
managed identities for corporate employees and thereby improve security =
by eliminating passwords.  It provides integrity and confidentiality of =
email and assures recipients as to who actually sent the message.  It is =
used to validate software and make it more difficult to spread viruses.

  We are all familiar with these well advertised benefits but for some =
reason we seem to constantly dismiss them when talking about whether of =
not PKI is ready for prime time and or commercial desirability. =20

  Trust me... it is commercially desirable today.  Maybe one day we can =
figure out how to incorporate it into the legal infrastructure but that =
is not the driving force, at least not today.

  Identity management is the driving force for PKI and identity =
management is one of the most desirable solutions on the market today.

  At 11:18 PM 6/21/2003, todd glassey wrote:

    Anders, you are certainly a powerful force in the development of
    cryptography in Europe (and I do mean this, no sarcasm intended), so =
I
    respect the commentary.

    I do however respectfully disagree.  People use PKI because they =
have to not
    because it makes sense to yet and that is the problem in a nut =
shell. It is
    still not commercially viable to rely on PKI systems... and there is =
no
    proof yet that any of the EU's stringent privacy directives are ever =
going
    to be met. So even though some of the smaller nations have started =
to force
    their population to rely on PKI's in the form of Public x.509 certs =
(ala
    Verisign/Thawte etc etc etc)...

    My feeling from a higher-ground perspective is that PKI as a whole =
to date
    has failed to address 2000 years of human process and legal =
development and
    has actually sought to eliminate much of the ceremony in favor of a
    mechanical infrastructure ... i.e. to replace "it". But in response =
to that,
    I want to point out that PKI processes can be made to conform to =
paper
    signing ceremonies and that is the best way to get people to feel
    comfortable with PKI...because so far the only reasons to use a =
certificate
    are the ones where its mandated by law.  Which leads me to think =
that PKI is
    still years away from commercial desirability.

    In closing, I want to reiterate that in all the examples you cited =
we were
    talking about a legal mandate, not generally a choice, so that =
implies to me
    that so far the only reason to use PKI is for the Force of Law that =
the
    eSign legislation brought into it...

    Todd
    ----- Original Message -----=20
    From: "Anders Rundgren" <[email-masked]>
    To: "todd glassey" <[email-masked]>; =
<[email-masked]>
    Sent: Saturday, June 21, 2003 10:56 AM
    Subject: Re: UK: PKI "not working"

    > Todd,
    > May I comment on the UK e-envoy's complaints?
    >
    > Firstly, the UK do not have the concept of a "citizen identity".
    > It is IMHO fairly impossible to create useful TTP PKIs for on-line
    > authentication and signing without working naming schemes.
    > Not to mention creating multi-authority work-flow tasks
    > (or "one-stop shopping" as it is coined in Sweden).
    >
    > Secondly, in Sweden 3 million citizens out of 9 million total can
    > get a citizen certificate at the click of a button in their =
on-line bank
    > which is an indication that "not working" is not a universal =
truth.
    >
    > To be honest the Swedish bank consortium do not rely on the
    > browsers' built-in crypto-functions as these were considered as
    > unwieldy, and not sufficiently standardized.  Here your comments
    > regarding lacking or not accepted standards apply, as "web-sign"
    > is a major activity since years backs but still not covered by any
    > standards WG!  To circumvent this blatant deficiency, the banks
    > selected a proprietary Java applet from an IBM lab in Zurich.
    >
    > What indeed is not working [on a practical and wide scale] is the
    > concept of mobile PKI resources that can be used at home, in an
    > Internet caf=E9 or at work.  Here I believe ETSI's and EU's work =
in
    > the field of smart cards has generally failed.
    >
    > What is also not working is many-to-many encrypted e-mail.
    > But that does not really matter as the on-line paradigm using
    > https + web has effectively replaced encrypted e-mail for
    > both on-line banking and e-government services.
    >
    > Anders R
    >
    > ----- Original Message -----
    > From: "todd glassey" <[email-masked]>
    > To: <[email-masked]>; "el-sign: electronic signatures - open
    discussion" <[email-masked]>
    > Sent: Thursday, June 12, 2003 16:28
    > Subject: Fw: PKI "not working"
    >
    >
    >
    > This is a cross posting from the ISC's mailing lists of the Bar
    Association.
    >
    > Why it is important here is that it documents perceived problems =
in the
    PKI
    > marketplace and I perceive that a number of these issues are =
failures in
    the
    > IETF's and potentially the ETSI standards processes, since they =
allow
    > processes that are at best incomplete from a deployment stance to =
be
    > elevated into standards status IMHO.
    >
    > My concern is that the value of the IETF and ETSI is growing less =
and less
    > with these types of realizations in the marketplace.
    >
    > Todd
    >
    >
    > To: <[email-masked]>
    > Sent: Thursday, June 12, 2003 7:00 AM
    > Subject: UK: PKI "not working"
    >
    >
    > > PKI is 'not working'
    > >
    > > Inadequate technology for online transactions is a 'huge =
problem' for
    > those
    > > in charge of e-government, admits a leading Whitehall official =
The
    > e-envoy's
    > > office has started searching for new ways to authenticate the =
users of
    > > e-services as the existing technology being used is "not =
working", a
    > senior
    > > Government official revealed on 11 June 2003. Although PKI =
(public key
    > > infrastructure) and digital certificate technology has played a =
major
    role
    > > in leading projects such as the Government Gateway, there is now =
growing
    > > recognition that it is unsuited for wider public use. While =
digital
    > > certificates would not be scrapped, and would be retained as an =
option
    for
    > > e-service users, one possible alternative being suggested is =
that
    > employers,
    > > banks, the voluntary sector and other "trusted organisations" =
would
    verify
    > a
    > > person's identity before transacting online for services. =
Speaking on
    > > condition of anonymity, the official said the Government is now =
looking
    at
    > > "radical ways" of solving the authentication problem. "Trust and
    > > authentication has been a huge problem for us. We haven't got a =
solution
    > for
    > > authentication. We've been trying with PKI for about 10 years =
now and
    its
    > > not working because it's a pain to implement and to use. We've =
been
    > looking
    > > to take the pain out of PKI. "What we are saying with =
authentication is
    > that
    > > if another trusted organisation such as a bank can provide proof =
saying
    > you
    > > are who you say you are that should take the need away for =
digital
    > > certificates." The move comes as the e-envoy's office is acutely =
aware
    > that
    > > it needs to step up the pace of e-government leading up to the =
2005
    > target.
    =
http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA=
?Op
    > > enDocument
    =
<http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176E=
A?O> > penDocument>
    > >
    > > Michael Power
    > >
    > > Partner & Chief Privacy Officer
    > > Gowling Lafleur Henderson LLP
    > > Barristers & Solicitors
    > > Patent & Trade Mark Agents
    > > Suite 2600
    > > 160 Elgin Street
    > > Ottawa, Ontario, CANADA
    > > K1P 1C3
    > >
    > >
    > >
    >
    >
  ***********************************************************
  Mitchell Arnone
  Managing Consultant
  SchlumbergerSema
  Technical Consulting Practice, Northeast Region

  [email-masked]
  www.slb.com/nws

  SchlumbergerSema=20
  Network & Infrastructure Solutions
  194 Wood Avenue, South
  Iselin, NJ 08830
  Direct Line- (410) 579-8691
  Mobile - (443) 864-1590

------=_NextPart_000_0010_01C3396C.15D46C80
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I fully agree with Mitchell's =
conclusions of what=20
PKI is good for as it stands today.&nbsp; To be able to serve millions =
of=20
citizens at thousands of independent e-government portals, either =
requires TTP=20
identity-portals (using SAML etc.),&nbsp;or client-side PKI using TTP =
CAs.&nbsp;=20
<EM>No other methods have proven to be technically or economically=20
feasible</EM>.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I cannot verify any major 100000-foot =
legal=20
problems, but quite a bunch of&nbsp;down-to-earth =
(zero-foot?)&nbsp;problems=20
like "lousy browsers", and the lack of ubiquitous,&nbsp;secure, =
and&nbsp;mobile=20
key-containers.&nbsp; IMO, it is really only the latter that hampers=20
enterprise-PKIs as a userid/password-replacement on a <EM>wider=20
scale</EM>.&nbsp; This problem is neither a standards problem, =
nor&nbsp;a=20
technical ditto.&nbsp;&nbsp; It is rather an example of blatant =
stupidity=20
among&nbsp;"certain manufacturers".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Regarding "legally binding",=20
virtually&nbsp;<EM>anything</EM> that offers reasonable=20
technical&nbsp;integrity&nbsp;is likely to be&nbsp;applicable as =
evidence in a=20
court trial in most countries.&nbsp; Examples of this are =
phone-operators'=20
call-lists that may prove "association" or DNA-fingerprints that may =
prove "It=20
wasn't me".&nbsp;&nbsp; What is a bit puzzling is that&nbsp;non-PKI =
e-solutions=20
never seem to be questioned&nbsp;regarding their.merits in=20
courts...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>A&nbsp;"legal" =
aspect that=20
though really is an issue, is TTP CA liability.&nbsp; However, this is =
mostly a=20
US issue where suing people is a&nbsp;part of the system.&nbsp; I =
believe this=20
will have a negative impact on PKI usage in the US, unless there is a =
way to=20
<EM>automatically accomplish</EM> what Identrus et al "achieves" by =
requiring=20
relying parties to sign agreements freeing the=20
issuer&nbsp;from&nbsp;liability.&nbsp; Here I would like to address the =
PKIX WG=20
with a request for some kind of remedy.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Mitchell Arnone</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">todd glassey</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">Anders=20
  Rundgren</A> ; <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, June 22, 2003 =
14:26</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: UK: PKI "not =
working"</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>While PKI certainly =
has=20
  significant value with regards to applying digital signatures and =
other issues=20
  regarding non-repudiation, I believe that we often seem to overlook =
the main=20
  benefits that are used to justify deploying PKI today.<BR><BR>PKI is =
the core=20
  component of any real Identity Management infrastructure.&nbsp; It =
provides=20
  for strong authentication to networking systems and =
applications.&nbsp; It=20
  serves to help reduce the number of managed identities for corporate =
employees=20
  and thereby improve security by eliminating passwords.&nbsp; It =
provides=20
  integrity and confidentiality of email and assures recipients as to =
who=20
  actually sent the message.&nbsp; It is used to validate software and =
make it=20
  more difficult to spread viruses.<BR><BR>We are all familiar with =
these well=20
  advertised benefits but for some reason we seem to constantly dismiss =
them=20
  when talking about whether of not PKI is ready for prime time and or=20
  commercial desirability.&nbsp; <BR><BR>Trust me... it is commercially=20
  desirable today.&nbsp; Maybe one day we can figure out how to =
incorporate it=20
  into the legal infrastructure but that is not the driving force, at =
least not=20
  today.<BR><BR>Identity management is the driving force for PKI and =
identity=20
  management is one of the most desirable solutions on the market=20
  today.<BR><BR><BR><BR>At 11:18 PM 6/21/2003, todd glassey =
wrote:<BR><BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">Anders, you are =
certainly a=20
    powerful force in the development of<BR>cryptography in Europe (and =
I do=20
    mean this, no sarcasm intended), so I<BR>respect the =
commentary.<BR><BR>I do=20
    however respectfully disagree.&nbsp; People use PKI because they =
have to=20
    not<BR>because it makes sense to yet and that is the problem in a =
nut shell.=20
    It is<BR>still not commercially viable to rely on PKI systems... and =
there=20
    is no<BR>proof yet that any of the EU's stringent privacy directives =
are=20
    ever going<BR>to be met. So even though some of the smaller nations =
have=20
    started to force<BR>their population to rely on PKI's in the form of =
Public=20
    x.509 certs (ala<BR>Verisign/Thawte etc etc etc)...<BR><BR>My =
feeling from a=20
    higher-ground perspective is that PKI as a whole to date<BR>has =
failed to=20
    address 2000 years of human process and legal development and<BR>has =

    actually sought to eliminate much of the ceremony in favor of=20
    a<BR>mechanical infrastructure ... i.e. to replace "it". But in =
response to=20
    that,<BR>I want to point out that PKI processes can be made to =
conform to=20
    paper<BR>signing ceremonies and that is the best way to get people =
to=20
    feel<BR>comfortable with PKI...because so far the only reasons to =
use a=20
    certificate<BR>are the ones where its mandated by law.&nbsp; Which =
leads me=20
    to think that PKI is<BR>still years away from commercial=20
    desirability.<BR><BR>In closing, I want to reiterate that in all the =

    examples you cited we were<BR>talking about a legal mandate, not =
generally a=20
    choice, so that implies to me<BR>that so far the only reason to use =
PKI is=20
    for the Force of Law that the<BR>eSign legislation brought into=20
    it...<BR><BR>Todd<BR>----- Original Message ----- <BR>From: "Anders=20
    Rundgren" &lt;[email-masked]&gt;<BR>To: "todd glassey"=20
    &lt;[email-masked]&gt;; =
&lt;[email-masked]&gt;<BR>Sent:=20
    Saturday, June 21, 2003 10:56 AM<BR>Subject: Re: UK: PKI "not=20
    working"<BR><BR><BR>&gt; Todd,<BR>&gt; May I comment on the UK =
e-envoy's=20
    complaints?<BR>&gt;<BR>&gt; Firstly, the UK do not have the concept =
of a=20
    "citizen identity".<BR>&gt; It is IMHO fairly impossible to create =
useful=20
    TTP PKIs for on-line<BR>&gt; authentication and signing without =
working=20
    naming schemes.<BR>&gt; Not to mention creating multi-authority =
work-flow=20
    tasks<BR>&gt; (or "one-stop shopping" as it is coined in=20
    Sweden).<BR>&gt;<BR>&gt; Secondly, in Sweden 3 million citizens out =
of 9=20
    million total can<BR>&gt; get a citizen certificate at the click of =
a button=20
    in their on-line bank<BR>&gt; which is an indication that "not =
working" is=20
    not a universal truth.<BR>&gt;<BR>&gt; To be honest the Swedish bank =

    consortium do not rely on the<BR>&gt; browsers' built-in =
crypto-functions as=20
    these were considered as<BR>&gt; unwieldy, and not sufficiently=20
    standardized.&nbsp; Here your comments<BR>&gt; regarding lacking or =
not=20
    accepted standards apply, as "web-sign"<BR>&gt; is a major activity =
since=20
    years backs but still not covered by any<BR>&gt; standards WG!&nbsp; =
To=20
    circumvent this blatant deficiency, the banks<BR>&gt; selected a =
proprietary=20
    Java applet from an IBM lab in Zurich.<BR>&gt;<BR>&gt; What indeed =
is not=20
    working [on a practical and wide scale] is the<BR>&gt; concept of =
mobile PKI=20
    resources that can be used at home, in an<BR>&gt; Internet caf=E9 or =
at=20
    work.&nbsp; Here I believe ETSI's and EU's work in<BR>&gt; the field =
of=20
    smart cards has generally failed.<BR>&gt;<BR>&gt; What is also not =
working=20
    is many-to-many encrypted e-mail.<BR>&gt; But that does not really =
matter as=20
    the on-line paradigm using<BR>&gt; https + web has effectively =
replaced=20
    encrypted e-mail for<BR>&gt; both on-line banking and e-government=20
    services.<BR>&gt;<BR>&gt; Anders R<BR>&gt;<BR>&gt; ----- Original =
Message=20
    -----<BR>&gt; From: "todd glassey"=20
    &lt;[email-masked]&gt;<BR>&gt; To: =
&lt;[email-masked]&gt;;=20
    "el-sign: electronic signatures - open<BR>discussion"=20
    &lt;[email-masked]&gt;<BR>&gt; Sent: Thursday, June 12, 2003=20
    16:28<BR>&gt; Subject: Fw: PKI "not =
working"<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;=20
    This is a cross posting from the ISC's mailing lists of the=20
    Bar<BR>Association.<BR>&gt;<BR>&gt; Why it is important here is that =
it=20
    documents perceived problems in the<BR>PKI<BR>&gt; marketplace and I =

    perceive that a number of these issues are failures =
in<BR>the<BR>&gt; IETF's=20
    and potentially the ETSI standards processes, since they =
allow<BR>&gt;=20
    processes that are at best incomplete from a deployment stance to =
be<BR>&gt;=20
    elevated into standards status IMHO.<BR>&gt;<BR>&gt; My concern is =
that the=20
    value of the IETF and ETSI is growing less and less<BR>&gt; with =
these types=20
    of realizations in the marketplace.<BR>&gt;<BR>&gt;=20
    Todd<BR>&gt;<BR>&gt;<BR>&gt; To: =
&lt;[email-masked]&gt;<BR>&gt;=20
    Sent: Thursday, June 12, 2003 7:00 AM<BR>&gt; Subject: UK: PKI "not=20
    working"<BR>&gt;<BR>&gt;<BR>&gt; &gt; PKI is 'not working'<BR>&gt;=20
    &gt;<BR>&gt; &gt; Inadequate technology for online transactions is a =
'huge=20
    problem' for<BR>&gt; those<BR>&gt; &gt; in charge of e-government, =
admits a=20
    leading Whitehall official The<BR>&gt; e-envoy's<BR>&gt; &gt; office =
has=20
    started searching for new ways to authenticate the users of<BR>&gt; =
&gt;=20
    e-services as the existing technology being used is "not working", =
a<BR>&gt;=20
    senior<BR>&gt; &gt; Government official revealed on 11 June 2003. =
Although=20
    PKI (public key<BR>&gt; &gt; infrastructure) and digital certificate =

    technology has played a major<BR>role<BR>&gt; &gt; in leading =
projects such=20
    as the Government Gateway, there is now growing<BR>&gt; &gt; =
recognition=20
    that it is unsuited for wider public use. While digital<BR>&gt; &gt; =

    certificates would not be scrapped, and would be retained as an=20
    option<BR>for<BR>&gt; &gt; e-service users, one possible alternative =
being=20
    suggested is that<BR>&gt; employers,<BR>&gt; &gt; banks, the =
voluntary=20
    sector and other "trusted organisations" would<BR>verify<BR>&gt; =
a<BR>&gt;=20
    &gt; person's identity before transacting online for services. =
Speaking=20
    on<BR>&gt; &gt; condition of anonymity, the official said the =
Government is=20
    now looking<BR>at<BR>&gt; &gt; "radical ways" of solving the =
authentication=20
    problem. "Trust and<BR>&gt; &gt; authentication has been a huge =
problem for=20
    us. We haven't got a solution<BR>&gt; for<BR>&gt; &gt; =
authentication. We've=20
    been trying with PKI for about 10 years now and<BR>its<BR>&gt; &gt; =
not=20
    working because it's a pain to implement and to use. We've =
been<BR>&gt;=20
    looking<BR>&gt; &gt; to take the pain out of PKI. "What we are =
saying with=20
    authentication is<BR>&gt; that<BR>&gt; &gt; if another trusted =
organisation=20
    such as a bank can provide proof saying<BR>&gt; you<BR>&gt; &gt; are =
who you=20
    say you are that should take the need away for digital<BR>&gt; &gt;=20
    certificates." The move comes as the e-envoy's office is acutely=20
    aware<BR>&gt; that<BR>&gt; &gt; it needs to step up the pace of =
e-government=20
    leading up to the 2005<BR>&gt; target.<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt;=20
    &gt;<BR>&gt;<BR><A=20
    =
href=3D"http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43=
004176EA?Op"=20
    =
eudora=3D"autourl">http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5=
A1680256D43004176EA?Op</A><BR>&gt;=20
    &gt; enDocument<BR>&gt; &gt;<BR>&gt;<BR>&lt;<A=20
    =
href=3D"http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43=
004176EA?O"=20
    =
eudora=3D"autourl">http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5=
A1680256D43004176EA?O</A>&gt;=20
    &gt; penDocument&gt;<BR>&gt; &gt;<BR>&gt; &gt; Michael Power<BR>&gt; =

    &gt;<BR>&gt; &gt; Partner &amp; Chief Privacy Officer<BR>&gt; &gt; =
Gowling=20
    Lafleur Henderson LLP<BR>&gt; &gt; Barristers &amp; =
Solicitors<BR>&gt; &gt;=20
    Patent &amp; Trade Mark Agents<BR>&gt; &gt; Suite 2600<BR>&gt; &gt; =
160=20
    Elgin Street<BR>&gt; &gt; Ottawa, Ontario, CANADA<BR>&gt; &gt; K1P=20
    1C3<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt;=20
  &gt;<BR>&gt;<BR>&gt;</BLOCKQUOTE><X-SIGSEP>
  =
<P></X-SIGSEP>***********************************************************=
<BR>Mitchell=20
  Arnone<BR>Managing Consultant<BR>SchlumbergerSema<BR>Technical =
Consulting=20
  Practice, Northeast Region<BR><BR>[email-masked]<BR><A=20
  href=3D"http://www.slb.com/nws"=20
  eudora=3D"autourl">www.slb.com/nws</A><BR><BR><FONT face=3Dimpact =
color=3D#0000ff=20
  size=3D4>Schlumberger</FONT><FONT face=3Dimpact color=3D#ff0000 =
size=3D4>S</FONT><FONT=20
  face=3Dimpact color=3D#0000ff size=3D4>ema</FONT><FONT face=3Darial =
color=3D#0000ff=20
  size=3D4> <BR></FONT><FONT face=3D"Univers 47 CondensedLight" =
color=3D#808080=20
  size=3D4>Network &amp; Infrastructure Solutions<BR></FONT><FONT=20
  color=3D#000080>194 Wood Avenue, South<BR>Iselin, NJ 08830<BR>Direct =
Line- (410)=20
  579-8691<BR>Mobile - (443)=20
864-1590<BR><BR></FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0010_01C3396C.15D46C80--

Date: Mon, 23 Jun 2003 07:41:44 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: UK: PKI "not working"
Sender: [email-masked]

Jean-Marc Desperrier wrote:
> 
> todd glassey wrote:
> 
>> *(RPM, HP Depot Packages, Sun or other UNIX PgkAdd formats etc), only 
>> use Md5 Hashes so where is the PKI here?

RPM packages can be signed with PGP (gpg). E.g. SuSE Linux does it that way.

> Here a pki based system could significantly improve the result.
> That would ring a bell to a not too stupid administrator if when 
> installing the nth package from RH, he suddenly had a message "The 
> certificate used to sign this package is not in your trust list. Do you 
> want to accept it anyway ?" if all the packages before did not trigger 
> such a message, because _they_ were signed with a genuine certicate.

Already done but not with X.509-based PKI. Many source distribution files 
are also signed with PGP, e.g. the Linux kernel.

Ciao, Michael.

From: "todd glassey" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: Re: UK: PKI "not working"
Date: Sun, 22 Jun 2003 22:13:02 -0700
Sender: [email-masked]

Jean-Marc,
Am I right in assuming that you think that it really matters what is
uploaded to a public FTP server???... Ones operated in the public interest
require stronger levels of certification and I have no complaint that in
instances where a Government wants to assign an individual identity token to
identify you, what i have is a statement that you nor anyone else here has
yet to refute, and that simply is that there are very few commercial reasons
for PKI's and even fewer for public PKI's beyond those of a national
identity system.

What is really funny to me is the about face across the European Continent.
This would NEVER have flown 20 years ago...
----- Original Message ----- 
From: "Jean-Marc Desperrier" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, June 22, 2003 11:37 AM
Subject: Re: UK: PKI "not working"

>
> todd glassey wrote:
>
> > *(RPM, HP Depot Packages, Sun or other UNIX PgkAdd formats etc), only
> > use Md5 Hashes so where is the PKI here?  The hashes may additionally
> > be signed to insure that they are not altered, but in most instances a
> > hashed finger print is all that is distributed with a code package so
> > that its installer routine or the person installing it can perform
> > these task inline.
>
> You seem to be ignorant there has been cases of corrupted archives with
> a trojan horse being somehow uploaded to a public ftp server, and they
> have shown the limits of the system, administrator don't always go check
> the hash value on the main source site.

This has to do with sloppy operating processes and procedures and not
whether the package was encrypted for upload with a PKI bassed crypto
system.

>
> Here a pki based system could significantly improve the result.

Sure - at a significant cost to manage it as well.

> That would ring a bell to a not too stupid administrator if when
> installing the nth package from RH, he suddenly had a message "The
> certificate used to sign this package is not in your trust list. Do you
> want to accept it anyway ?" if all the packages before did not trigger
> such a message, because _they_ were signed with a genuine certicate.

SW installers have to work offline too.

Reply-To: <[email-masked]>
From: "Steven Legg" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: FW: I-D ACTION:draft-legg-ldap-binary-00.txt
Date: Mon, 23 Jun 2003 11:42:15 +1000
Importance: Normal
Sender: [email-masked]

Folks,

For the benefit of PKI LDAP clients (among other things), this is
the I-D that reintroduces the ";binary" attribute option that has been
removed from the LDAPbis core documents for the LDAPv3 draft standard.

Regards,
Steven

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Friday, 20 June 2003 21:34
To: IETF-Announce: ;
Subject: I-D ACTION:draft-legg-ldap-binary-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: LDAP: The Binary Encoding Option
	Author(s)	: S. Legg
	Filename	: draft-legg-ldap-binary-00.txt
	Pages		: 9
	Date		: 2003-6-19

Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory has a defined syntax (i.e. data type).  A syntax
definition specifies how attribute values conforming to the syntax
are normally represented when transferred in LDAP operations.  This
representation is referred to as the LDAP-specific encoding to
distinguish it from other methods of encoding attribute values.  This
document defines an attribute option, the binary option, which can be
used to specify that the associated attribute values are instead
encoded according to the Basic Encoding Rules (BER) used by X.500
directories.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-legg-ldap-binary-00.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-legg-ldap-binary-00.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-legg-ldap-binary-00.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.

Date: Sun, 22 Jun 2003 20:37:33 +0200
From: Jean-Marc Desperrier <[email-masked]>
Organization: totalement desorganise
To: [email-masked]
Subject: Re: UK: PKI "not working"
Sender: [email-masked]

todd glassey wrote:

> *(RPM, HP Depot Packages, Sun or other UNIX PgkAdd formats etc), only 
> use Md5 Hashes so where is the PKI here?  The hashes may additionally 
> be signed to insure that they are not altered, but in most instances a 
> hashed finger print is all that is distributed with a code package so 
> that its installer routine or the person installing it can perform 
> these task inline.

You seem to be ignorant there has been cases of corrupted archives with 
a trojan horse being somehow uploaded to a public ftp server, and they 
have shown the limits of the system, administrator don't always go check 
the hash value on the main source site.

Here a pki based system could significantly improve the result.
That would ring a bell to a not too stupid administrator if when 
installing the nth package from RH, he suddenly had a message "The 
certificate used to sign this package is not in your trust list. Do you 
want to accept it anyway ?" if all the packages before did not trigger 
such a message, because _they_ were signed with a genuine certicate.

From: "todd glassey" <[email-masked]>
To: "Mitchell Arnone" <[email-masked]>, "Anders Rundgren" <[email-masked]>, <[email-masked]>
Subject: Re: UK: PKI "not working"
Date: Sun, 22 Jun 2003 09:53:30 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0077_01C338A4.22A979F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Mitchell - My apologies to you and the group - that last posting of mine =
was a mistake - this is what should have been send out.

----
Mitchell - having already been sanctioned in the IPR wg for too many =
postings I need to be careful of how many of these responses I answer =
while we are sorting out damages due to RFC2418's discriminatory use. =
But in response to your posting, come up to 100000 feet and look down =
and try and make these same comments. I don't believe that they hold =
water at this altitude. Sorry.
  ----- Original Message -----=20
  From: Mitchell Arnone=20
  To: todd glassey ; Anders Rundgren ; [email-masked]=20
  Sent: Sunday, June 22, 2003 5:26 AM
  Subject: Re: UK: PKI "not working"

  While PKI certainly has significant value with regards to applying =
digital signatures and other issues regarding non-repudiation, I believe =
that we often seem to overlook the main benefits that are used to =
justify deploying PKI today.

I agree generally, but there is a flaw in this as a blanket statement, =
and that is that there is an implication that PKI is the entirety of the =
crypto process. In short that simply is not true. PKI is a Public Key =
Infrastructure, which mandates the use of a split-key (public/private =
keys) model for the use of cryptographic functions.=20

It (PKI) is not the only, nor is it the most efficient use of =
cryptographic keying  for proofing in transaction models, and in fact =
PKI has any number of liabilities (including OCSP or CRL overhead) =
specific to the key management processes which other keying systems =
simply don't face, like symmetric or PAD systems as just two of the many =
examples available ...=20

  PKI is the core component of any real Identity Management =
infrastructure. =20

So how much of your own personal money are you willing to risk on this =
statement of yours? - we will come back to this later.

  It provides for strong authentication to networking systems and =
applications.  It serves to help reduce the number of managed identities =
for corporate employees and thereby improve security by eliminating =
passwords. =20

No offense meant by this next comment but - Garbage - you talk about PKI =
as if this was a universally rolled out product and its not. Yes, the =
use of a PKI model for addressing these issues of managed identities can =
and in many instances does involve PKI but that is because products have =
been built that use x509 rather than DH or other types of keying =
solutions. And this is a statement of productization and not by =
developing a market by the creation of a standard.

  It provides integrity and confidentiality of email and assures =
recipients as to who actually sent the message. =20

Only if the email is encrypted. If SSL or OpenSSH tools are used to =
provide these functions then they too are PKI-less in nature. So my =
response is probably something like "No it doesn't. SSL is used more =
than anything to insure confidentiality." and although it may use an =
x509 certificate, it (the process) does not use the formal PKI you are =
talking about. It  (the SSL Process) can be used to encrypt and sign =
mail but most people don't use it for these options.  By the way - =
notice that most people equate VPN's as better than encrypted email and =
that is why the comment above holds water.

As to whether PKI is ready for prime time, if we assume that your =
commentary is right, then ask yourself why when you toggle through this =
list why you only see one in 1000 postings having any use of this PKI =
you are fond of telling us that is ready for use. What this says to me =
is that the totality of your retort is simply untrue or we would all be =
seeing notices about the certificates that were used to sign our email.

  It is used to validate software and make it more difficult to spread =
viruses.

Well, it could be - Code Authentication (Authenticode) can use Microsoft =
official Certs, but any x509 cert can be made to be used herein. So I =
would say that this is true only of "Microsoft Installer Packages".  by =
contrast, most all UNIX packages *(RPM, HP Depot Packages, Sun or other =
UNIX PgkAdd formats etc), only use MD5 Hashes so where is the PKI here?  =
The hashes may additionally be signed to insure that they are not =
altered, but in most instances a hashed finger print is all that is =
distributed with a code package so that its installer routine or the =
person installing it can perform these task inline.

  We are all familiar with these well advertised benefits but for some =
reason we seem to constantly dismiss them when talking about whether of =
not PKI is ready for prime time and or commercial desirability. =20

You missed the point here. Business does not do things because they like =
it. Business does things because (1) they can, and WILL make more money =
that way(and you have to prove both of these assertions to qualify =
here), or (2) because someone forces it on them through regulation or =
through some other legal channel like a lawsuit's settlement as has been =
done by several governments in mandating their citizens MUST have a =
eEntity under their eSign legislation whatever that is.

  Trust me... it is commercially desirable today. =20

Ahahahahahaha - your funny. Again - are you or your employer's willing =
to back that statement with money?=20

  Maybe one day we can figure out how to incorporate it into the legal =
infrastructure but that is not the driving force, at least not today.

Hmmm- Here again I would disagree. In fact I would day that this is =
exactly 180 degrees out of synch with reality... right now the legal =
reasons are the only ones to bear the costs of PKI today, and if you =
doubt that look at the people that are ramming PKI down their citizens =
throats and why!.

  Identity management is the driving force for PKI and identity =
management is one of the most desirable solutions on the market today.

OK that is something I can agree with. But what PKI really brings to the =
party is a recognized set of rules for applying legal status to a =
digital signature as though it were a wet one, and all that this implies =
and means.=20

lets keep our eyes on the ball here.

Todd

------=_NextPart_000_0077_01C338A4.22A979F0
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Mitchell - My apologies to you and the =
group - that=20
last posting of mine was a mistake - this is what should have been send=20
out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>----</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Mitchell - having already been =
sanctioned in the=20
IPR wg for too many postings I need to be careful of how many of these =
responses=20
I answer while we are sorting out damages due to RFC2418's =
discriminatory use.=20
But in response to your posting, come up to 100000 feet and look down =
and try=20
and make these same comments. I don't believe that they hold water at =
this=20
altitude.</FONT><FONT face=3DArial size=3D2>&nbsp;Sorry.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Mitchell Arnone</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">todd glassey</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">Anders=20
  Rundgren</A> ; <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, June 22, 2003 =
5:26 AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: UK: PKI "not =
working"</DIV>
  <DIV><BR></DIV>
  <DIV>While PKI certainly has significant value with regards to =
applying=20
  digital signatures and other issues regarding non-repudiation, I =
believe that=20
  we often seem to overlook the main benefits that are used to justify =
deploying=20
  PKI today.</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I agree generally, but there =
is a flaw in=20
this as a blanket statement,&nbsp;and that is that there is an =
implication that=20
PKI is the entirety of the crypto process. In short that simply is not =
true.=20
</FONT><FONT face=3DArial size=3D2>PKI is a Public Key Infrastructure, =
which=20
mandates the use of a split-key (public/private keys) model for the use =
of=20
cryptographic functions. </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>It (PKI)&nbsp;is not the =
only, nor is it=20
the most efficient use of cryptographic keying&nbsp; for proofing in =
transaction=20
models, and in fact PKI has any number of liabilities (including OCSP or =
CRL=20
overhead)&nbsp;specific to the key management processes which other =
keying=20
systems simply don't face, like symmetric or PAD systems as just two of =
the many=20
examples available ... </FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"><FONT=20
  face=3DArial size=3D2></FONT>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><BR>PKI is the core component of any real =
Identity=20
  Management infrastructure.&nbsp; </DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>So how much of your own =
personal money are=20
you willing to risk on this statement of yours? - we will come back to =
this=20
later.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV>&nbsp;</DIV>
  <DIV>It provides for strong authentication to networking systems and=20
  applications.&nbsp; It serves to help reduce the number of managed =
identities=20
  for corporate employees and thereby improve security by eliminating=20
  passwords.&nbsp; </DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>No offense meant by this next comment =
but - Garbage=20
- you talk about&nbsp;PKI as if this was a universally rolled out =
product and=20
its not. Yes, the use of a PKI model for addressing these issues of =
managed=20
identities can and in many instances does involve PKI but that is =
because=20
products have been built that use x509 rather than DH or other types of =
keying=20
solutions. And this is a statement of productization and not by =
developing a=20
market by the creation of a standard.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>It provides integrity and confidentiality of email and assures =
recipients=20
  as to who actually sent the message.&nbsp; </DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Only if the email is =
encrypted. If SSL or=20
OpenSSH tools are used to provide these functions then they too are =
PKI-less in=20
nature. So my response is probably something like "No it doesn't. SSL is =
used=20
more than anything to insure confidentiality." and although it&nbsp;may =
use an=20
x509 certificate, it (the process)&nbsp;does not use the formal PKI you =
are=20
talking about.&nbsp;</FONT><FONT face=3DArial size=3D2>It&nbsp; (the SSL =
Process)=20
can be used to encrypt and sign mail but most people don't use it for =
these=20
options.&nbsp; </FONT><FONT face=3DArial size=3D2>By the way - notice =
that most=20
people equate VPN's as better than encrypted email and that is why the =
comment=20
above holds water.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>As to whether PKI is ready =
for prime time,=20
if we assume that your commentary is right, then ask yourself why when =
you=20
toggle through this list why you only see one in 1000 postings having =
any use of=20
this PKI you are fond of telling us that is ready for use. </FONT><FONT=20
face=3DArial size=3D2>What this says to me&nbsp;is that the totality of =
your retort=20
is simply untrue or we would all be seeing notices about the =
certificates that=20
were used to sign our email.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>It is used to validate software and make it more difficult to =
spread=20
  viruses.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Well, it could be - Code =
Authentication=20
(Authenticode) can use Microsoft official Certs, but any x509 cert can =
be made=20
to be used herein. So I would say that this is true only of "Microsoft =
Installer=20
Packages".&nbsp; by contrast, most all UNIX packages *(RPM, HP Depot =
Packages,=20
Sun or other UNIX PgkAdd formats etc), only use MD5 Hashes so where is =
the PKI=20
here?&nbsp; The hashes&nbsp;may additionally be signed&nbsp;to insure =
that they=20
are not altered, but in most instances a hashed finger print is all that =
is=20
distributed with a code package so that its installer routine or the =
person=20
installing it can perform these task inline.</FONT></DIV><FONT =
face=3DArial=20
size=3D2></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><BR><BR>We are all familiar with these well advertised benefits =
but for=20
  some reason we seem to constantly dismiss them when talking about =
whether of=20
  not PKI is ready for prime time and or commercial desirability.&nbsp; =
</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>You missed the point here. =
Business does=20
not do things because they like it. Business does things because (1) =
they can,=20
and WILL make more money that way(and you have to prove both of these =
assertions=20
to qualify here), or (2) because someone forces it on them through =
regulation or=20
through some other legal channel like a lawsuit's settlement as has been =
done by=20
several governments in mandating their citizens MUST have a eEntity =
under their=20
eSign legislation whatever that is.</FONT></DIV><FONT face=3DArial =
size=3D2></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"><FONT=20
  face=3DArial size=3D2></FONT>
  <DIV><BR>Trust me... it is commercially desirable today.&nbsp; </DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ahahahahahaha - your funny. =
Again - are you=20
or your employer's willing to back that statement with money? =
</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>Maybe one day we can figure out how to incorporate it into the =
legal=20
  infrastructure but that is not the driving force, at least not =
today.</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Hmmm- Here again I would =
disagree.&nbsp;In=20
fact I would day that this is&nbsp;exactly 180 degrees out of synch with =

reality...&nbsp;right now the legal reasons are the only ones to bear =
the costs=20
of PKI today, and if you doubt that look at the people that are ramming =
PKI down=20
their citizens throats and why!.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT>
  <DIV><FONT face=3DArial size=3D2></FONT><BR>Identity management is the =
driving=20
  force for PKI and identity management is one of the most desirable =
solutions=20
  on the market today.</DIV><FONT face=3DArial =
size=3D2></FONT></BLOCKQUOTE><FONT=20
face=3DArial size=3D2>
<DIV dir=3Dltr><BR>OK that is something I can agree with. But =
w</FONT><FONT=20
face=3DArial size=3D2>hat PKI really brings to the party is a recognized =
set of=20
rules for applying legal status to a digital signature as though it were =
a wet=20
one, and all that this implies and means. </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>lets keep our eyes on the =
ball=20
here.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Todd</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0077_01C338A4.22A979F0--

From: "todd glassey" <[email-masked]>
To: "Mitchell Arnone" <[email-masked]>, "Anders Rundgren" <[email-masked]>, <[email-masked]>
Subject: Re: UK: PKI "not working"
Date: Sun, 22 Jun 2003 09:40:15 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0047_01C338A2.490AAE40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Mitchell - come up to 100000 feet and look down and try and make these =
same comments. They simply don't hold water. Sorry.
  ----- Original Message -----=20
  From: Mitchell Arnone=20
  To: todd glassey ; Anders Rundgren ; [email-masked]=20
  Sent: Sunday, June 22, 2003 5:26 AM
  Subject: Re: UK: PKI "not working"

  While PKI certainly has significant value with regards to applying =
digital signatures and other issues regarding non-repudiation, I believe =
that we often seem to overlook the main benefits that are used to =
justify deploying PKI today.

I agree gernerally,but there is a flaw in this as a blanket statement, =
and that is that there is an implication that PKI is the entirety of the =
crypto process. In short that simply is not true. PKI is a Public Key =
Infrastructure, which mandates the use of a split-key (public/private =
keys) model for the use opf cryptographic functions. It (PKI) is not the =
only nor is it the most efficient use of cryptographic keying  for =
proofing in transaction models, and in fact PKI has any number of =
liabilities specific to the key management processes which other keying =
systems simply dont face, like symmetric or PAD systems as just two of =
the many examples avalible ...=20

  PKI is the core component of any real Identity Management =
infrastructure. =20

So how much of your own personal money are you willing to risk on this =
statement of yours?

  It provides for strong authentication to networking systems and =
applications.  It serves to help reduce the number of managed identities =
for corporate employees and thereby improve security by eliminating =
passwords. =20

No offense ment by this next comment but - Garbage - you talk about PKI =
as if this was a rolled out product and its not. Yes the use of a PKI =
model for addressing these issues of managed identities, can and in many =
instances does involve PKI but that is becuase products have been built =
that use x509 rather than DH or other types of keying solutions. And =
this is a statement of productization and not by developing a market by =
the creation of a standard.

  It provides integrity and confidentiality of email and assures =
recipients as to who actually sent the message. =20

Only if the email is encrypted. If SSl is used to provide these =
functions too, it is likely that no formal PKI service is used. So my =
response is probably somethinglike "No it doesnt. SSL is used more than =
anything to insure confdentiality." and although it may use an x509 =
certificate, it (the process) does not use the formal PKI you are =
talking about. It  (the SSL Process) can be used to encrypt and sign =
mail but most people dont use it for these options.=20

As to whether PKI is ready for prime time, if we assume that your =
commentary is right, then ask yourself why when you toggle through this =
list why you only see one in 1000 postings having any use of this PKI =
you are fond of telling us that is ready for use. What this says to me =
is that the totality of your retort is simply untrue or we would all be =
seeing notinces about the certificates that were used to sign our email.

  It is used to validate software and make it more difficult to spread =
viruses.

Well, it could be - Code Authentication (Authnticode) can use Microsoft =
official Certs, but any x509 cert can be made to be used herein. So I =
would say that this is true only of "Micosoft Installer Packages".  by =
contrast, most all UNIX packages *(RPM, HP Depot Packages, Sun or other =
UNIX PgkAdd formats etc), only use Md5 Hashes so where is the PKI here?  =
The hashes may additionally be signed to insure that they are not =
altered, but in most instances a hashed finger print is all that is =
distributed with a code package so that its installer routine or the =
person installing it can perform these task inline.

  We are all familiar with these well advertised benefits but for some =
reason we seem to constantly dismiss them when talking about whether of =
not PKI is ready for prime time and or commercial desirability. =20

You missed the point here. Business does not do things becuase they like =
it. Business does things becuasse (1) they can, and WILL make more money =
that way(and you have to prove both of these assertions to qualify =
here), or (2) becuase someone forces it on them through regulation or =
through some other legal channel like a lawsuit's settlement as has been =
done by several governments in mandating their citizens MUST have a =
eEntity under their eSign legislation whatever that is.

  Trust me... it is commercially desirable today. =20

Ahahahahahaha - your funny. Are you or your employer's willing to back =
that statement with money?=20

  Maybe one day we can figure out how to incorporate it into the legal =
infrastructure but that is not the driving force, at least not today.

Boy is this wrong. In fact I think its exactly 180 degrees out of synch =
with reality... The legal reasons are right now the only ones to bear =
the costs of PKI today and if you doubt that look at the people that are =
ramming PKI down their citizens throats and why!.

  Identity management is the driving force for PKI and identity =
management is one of the most desirable solutions on the market today.

OK that is something I can agree with. But what PKI really brings to the =
party is a recognized set of rules for applying legal status to a =
digital signature as though it were a wet one, and all that this implies =
and means.=20

lets keep our eyes on the ball here.

Todd

------=_NextPart_000_0047_01C338A2.490AAE40
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Mitchell - come up to 100000 feet and =
look down and=20
try and make these same comments. They simply don't hold water.=20
Sorry.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Mitchell Arnone</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">todd glassey</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">Anders=20
  Rundgren</A> ; <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, June 22, 2003 =
5:26 AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: UK: PKI "not =
working"</DIV>
  <DIV><BR></DIV>
  <DIV>While PKI certainly has significant value with regards to =
applying=20
  digital signatures and other issues regarding non-repudiation, I =
believe that=20
  we often seem to overlook the main benefits that are used to justify =
deploying=20
  PKI today.</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I agree gernerally,but there =
is a flaw in=20
this as a blanket statement,&nbsp;and that is that there is an =
implication that=20
PKI is the entirety of the crypto process. In short that simply is not =
true.=20
</FONT><FONT face=3DArial size=3D2>PKI is a Public Key Infrastructure, =
which=20
mandates the use of a split-key (public/private keys) model for the use =
opf=20
cryptographic functions. It (PKI)&nbsp;is not the only nor is it the =
most=20
efficient use of cryptographic keying&nbsp; for proofing in transaction =
models,=20
and in fact PKI has any number of liabilities specific to the key =
management=20
processes which other keying systems simply dont face, like symmetric or =
PAD=20
systems as just two of the many examples avalible ... </FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"><FONT=20
  face=3DArial size=3D2></FONT>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><BR>PKI is the core component of any real =
Identity=20
  Management infrastructure.&nbsp; </DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>So how much of your own =
personal money are=20
you willing to risk on this statement of yours?</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV>&nbsp;</DIV>
  <DIV>It provides for strong authentication to networking systems and=20
  applications.&nbsp; It serves to help reduce the number of managed =
identities=20
  for corporate employees and thereby improve security by eliminating=20
  passwords.&nbsp; </DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>No offense ment by this next comment =
but - Garbage=20
- you talk about&nbsp;PKI as if this was a rolled out product and its =
not. Yes=20
the use of a PKI model for addressing these issues of managed =
identities, can=20
and in many instances does involve PKI but that is becuase products have =
been=20
built that use x509 rather than DH or other types of keying solutions. =
And this=20
is a statement of productization and not by developing a market by the =
creation=20
of a standard.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>It provides integrity and confidentiality of email and assures =
recipients=20
  as to who actually sent the message.&nbsp; </DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Only if the email is =
encrypted. If SSl is=20
used to provide these functions too, it is likely that no formal PKI =
service is=20
used. So my response is probably somethinglike "No it doesnt. SSL is =
used more=20
than anything to insure confdentiality." and although it&nbsp;may use an =
x509=20
certificate, it (the process)&nbsp;does not use the formal PKI you are =
talking=20
about.&nbsp;</FONT><FONT face=3DArial size=3D2>It&nbsp; (the SSL =
Process) can be=20
used to encrypt and sign mail but most people dont use it for these =
options.=20
</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>As to whether PKI is ready =
for prime time,=20
if we assume that your commentary is right, then ask yourself why when =
you=20
toggle through this list why you only see one in 1000 postings having =
any use of=20
this PKI you are fond of telling us that is ready for use. </FONT><FONT=20
face=3DArial size=3D2>What this says to me&nbsp;is that the totality of =
your retort=20
is simply untrue or we would all be seeing notinces about the =
certificates that=20
were used to sign our email.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>It is used to validate software and make it more difficult to =
spread=20
  viruses.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Well, it could be - Code =
Authentication=20
(Authnticode) can use Microsoft official Certs, but any x509 cert can be =
made to=20
be used herein. So I would say that this is true only of "Micosoft =
Installer=20
Packages".&nbsp; by contrast, most all UNIX packages *(RPM, HP Depot =
Packages,=20
Sun or other UNIX PgkAdd formats etc), only use Md5 Hashes so where is =
the PKI=20
here?&nbsp; The hashes&nbsp;may additionally be signed&nbsp;to insure =
that they=20
are not altered, but in most instances a hashed finger print is all that =
is=20
distributed with a code package so that its installer routine or the =
person=20
installing it can perform these task inline.</FONT></DIV><FONT =
face=3DArial=20
size=3D2></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><BR><BR>We are all familiar with these well advertised benefits =
but for=20
  some reason we seem to constantly dismiss them when talking about =
whether of=20
  not PKI is ready for prime time and or commercial desirability.&nbsp; =
</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>You missed the point here. =
Business does=20
not do things becuase they like it. Business does things becuasse (1) =
they can,=20
and WILL make more money that way(and you have to prove both of these =
assertions=20
to qualify here), or (2) becuase someone forces it on them through =
regulation or=20
through some other legal channel like a lawsuit's settlement as has been =
done by=20
several governments in mandating their citizens MUST have a eEntity =
under their=20
eSign legislation whatever that is.</FONT></DIV><FONT face=3DArial =
size=3D2></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"><FONT=20
  face=3DArial size=3D2></FONT>
  <DIV><BR>Trust me... it is commercially desirable today.&nbsp; </DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ahahahahahaha - your funny. =
Are you or your=20
employer's willing to back that statement with money? </FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>Maybe one day we can figure out how to incorporate it into the =
legal=20
  infrastructure but that is not the driving force, at least not =
today.</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Boy is this wrong. In fact I =
think&nbsp;its=20
exactly 180 degrees out of synch with reality...&nbsp;The legal reasons =
are=20
right now the only ones to bear the costs of PKI today and if you doubt =
that=20
look at the people that are ramming PKI down their citizens throats and=20
why!.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT>
  <DIV><FONT face=3DArial size=3D2></FONT><BR>Identity management is the =
driving=20
  force for PKI and identity management is one of the most desirable =
solutions=20
  on the market today.</DIV><FONT face=3DArial =
size=3D2></FONT></BLOCKQUOTE><FONT=20
face=3DArial size=3D2>
<DIV dir=3Dltr><BR>OK that is something I can agree with. But =
w</FONT><FONT=20
face=3DArial size=3D2>hat PKI really brings to the party is a recognized =
set of=20
rules for applying legal status to a digital signature as though it were =
a wet=20
one, and all that this implies and means. </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>lets keep our eyes on the =
ball=20
here.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Todd</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0047_01C338A2.490AAE40--

Content-return: prohibited
Date: Sun, 22 Jun 2003 08:26:34 -0400
From: Mitchell Arnone <[email-masked]>
Subject: Re: UK: PKI "not working"
To: todd glassey <[email-masked]>, Anders Rundgren <[email-masked]>, [email-masked]
Sender: [email-masked]

--Boundary_(ID_0OuWU9GhMsXY5C0yhhHB5w)
Content-type: text/plain; charset=iso-8859-1; format=flowed
Content-transfer-encoding: QUOTED-PRINTABLE

While PKI certainly has significant value with regards to applying di=
gital=20
signatures and other issues regarding non-repudiation, I believe that=
 we=20
often seem to overlook the main benefits that are used to justify dep=
loying=20
PKI today.

PKI is the core component of any real Identity Management=20
infrastructure.  It provides for strong authentication to networking=
=20
systems and applications.  It serves to help reduce the number of man=
aged=20
identities for corporate employees and thereby improve security by=
=20
eliminating passwords.  It provides integrity and confidentiality of =
email=20
and assures recipients as to who actually sent the message.  It is us=
ed to=20
validate software and make it more difficult to spread viruses.

We are all familiar with these well advertised benefits but for some =
reason=20
we seem to constantly dismiss them when talking about whether of not =
PKI is=20
ready for prime time and or commercial desirability.

Trust me... it is commercially desirable today.  Maybe one day we can=
=20
figure out how to incorporate it into the legal infrastructure but th=
at is=20
not the driving force, at least not today.

Identity management is the driving force for PKI and identity managem=
ent is=20
one of the most desirable solutions on the market today.

At 11:18 PM 6/21/2003, todd glassey wrote:

>Anders, you are certainly a powerful force in the development of
>cryptography in Europe (and I do mean this, no sarcasm intended), so=
 I
>respect the commentary.
>
>I do however respectfully disagree.  People use PKI because they hav=
e to not
>because it makes sense to yet and that is the problem in a nut shell=
. It is
>still not commercially viable to rely on PKI systems... and there is=
 no
>proof yet that any of the EU's stringent privacy directives are ever=
 going
>to be met. So even though some of the smaller nations have started t=
o force
>their population to rely on PKI's in the form of Public x.509 certs =
(ala
>Verisign/Thawte etc etc etc)...
>
>My feeling from a higher-ground perspective is that PKI as a whole t=
o date
>has failed to address 2000 years of human process and legal developm=
ent and
>has actually sought to eliminate much of the ceremony in favor of a
>mechanical infrastructure ... i.e. to replace "it". But in response =
to that,
>I want to point out that PKI processes can be made to conform to pap=
er
>signing ceremonies and that is the best way to get people to feel
>comfortable with PKI...because so far the only reasons to use a cert=
ificate
>are the ones where its mandated by law.  Which leads me to think tha=
t PKI is
>still years away from commercial desirability.
>
>In closing, I want to reiterate that in all the examples you cited w=
e were
>talking about a legal mandate, not generally a choice, so that impli=
es to me
>that so far the only reason to use PKI is for the Force of Law that =
the
>eSign legislation brought into it...
>
>Todd
>----- Original Message -----
>From: "Anders Rundgren" <[email-masked]>
>To: "todd glassey" <[email-masked]>; <[email-masked]=
rg>
>Sent: Saturday, June 21, 2003 10:56 AM
>Subject: Re: UK: PKI "not working"
>
>
> > Todd,
> > May I comment on the UK e-envoy's complaints?
> >
> > Firstly, the UK do not have the concept of a "citizen identity".
> > It is IMHO fairly impossible to create useful TTP PKIs for on-lin=
e
> > authentication and signing without working naming schemes.
> > Not to mention creating multi-authority work-flow tasks
> > (or "one-stop shopping" as it is coined in Sweden).
> >
> > Secondly, in Sweden 3 million citizens out of 9 million total can
> > get a citizen certificate at the click of a button in their on-li=
ne bank
> > which is an indication that "not working" is not a universal trut=
h.
> >
> > To be honest the Swedish bank consortium do not rely on the
> > browsers' built-in crypto-functions as these were considered as
> > unwieldy, and not sufficiently standardized.  Here your comments
> > regarding lacking or not accepted standards apply, as "web-sign"
> > is a major activity since years backs but still not covered by an=
y
> > standards WG!  To circumvent this blatant deficiency, the banks
> > selected a proprietary Java applet from an IBM lab in Zurich.
> >
> > What indeed is not working [on a practical and wide scale] is the
> > concept of mobile PKI resources that can be used at home, in an
> > Internet caf=E9 or at work.  Here I believe ETSI's and EU's work =
in
> > the field of smart cards has generally failed.
> >
> > What is also not working is many-to-many encrypted e-mail.
> > But that does not really matter as the on-line paradigm using
> > https + web has effectively replaced encrypted e-mail for
> > both on-line banking and e-government services.
> >
> > Anders R
> >
> > ----- Original Message -----
> > From: "todd glassey" <[email-masked]>
> > To: <[email-masked]>; "el-sign: electronic signatures - open
>discussion" <[email-masked]>
> > Sent: Thursday, June 12, 2003 16:28
> > Subject: Fw: PKI "not working"
> >
> >
> >
> > This is a cross posting from the ISC's mailing lists of the Bar
>Association.
> >
> > Why it is important here is that it documents perceived problems =
in the
>PKI
> > marketplace and I perceive that a number of these issues are fail=
ures in
>the
> > IETF's and potentially the ETSI standards processes, since they a=
llow
> > processes that are at best incomplete from a deployment stance to=
 be
> > elevated into standards status IMHO.
> >
> > My concern is that the value of the IETF and ETSI is growing less=
 and less
> > with these types of realizations in the marketplace.
> >
> > Todd
> >
> >
> > To: <[email-masked]>
> > Sent: Thursday, June 12, 2003 7:00 AM
> > Subject: UK: PKI "not working"
> >
> >
> > > PKI is 'not working'
> > >
> > > Inadequate technology for online transactions is a 'huge proble=
m' for
> > those
> > > in charge of e-government, admits a leading Whitehall official =
The
> > e-envoy's
> > > office has started searching for new ways to authenticate the u=
sers of
> > > e-services as the existing technology being used is "not workin=
g", a
> > senior
> > > Government official revealed on 11 June 2003. Although PKI (pub=
lic key
> > > infrastructure) and digital certificate technology has played a=
 major
>role
> > > in leading projects such as the Government Gateway, there is no=
w growing
> > > recognition that it is unsuited for wider public use. While dig=
ital
> > > certificates would not be scrapped, and would be retained as an=
 option
>for
> > > e-service users, one possible alternative being suggested is th=
at
> > employers,
> > > banks, the voluntary sector and other "trusted organisations" w=
ould
>verify
> > a
> > > person's identity before transacting online for services. Speak=
ing on
> > > condition of anonymity, the official said the Government is now=
 looking
>at
> > > "radical ways" of solving the authentication problem. "Trust an=
d
> > > authentication has been a huge problem for us. We haven't got a=
 solution
> > for
> > > authentication. We've been trying with PKI for about 10 years n=
ow and
>its
> > > not working because it's a pain to implement and to use. We've =
been
> > looking
> > > to take the pain out of PKI. "What we are saying with authentic=
ation is
> > that
> > > if another trusted organisation such as a bank can provide proo=
f saying
> > you
> > > are who you say you are that should take the need away for digi=
tal
> > > certificates." The move comes as the e-envoy's office is acutel=
y aware
> > that
> > > it needs to step up the pace of e-government leading up to the =
2005
> > target.
> > >
> > >
> > >
> >
>http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004=
176EA?Op
> > > enDocument
> > >
> >
><http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D4300=
4176EA?O> =20
> > penDocument>
> > >
> > > Michael Power
> > >
> > > Partner & Chief Privacy Officer
> > > Gowling Lafleur Henderson LLP
> > > Barristers & Solicitors
> > > Patent & Trade Mark Agents
> > > Suite 2600
> > > 160 Elgin Street
> > > Ottawa, Ontario, CANADA
> > > K1P 1C3
> > >
> > >
> > >
> >
> >

***********************************************************
Mitchell Arnone
Managing Consultant
SchlumbergerSema
Technical Consulting Practice, Northeast Region

[email-masked]
www.slb.com/nws

SchlumbergerSema
Network & Infrastructure Solutions
194 Wood Avenue, South
Iselin, NJ 08830
Direct Line- (410) 579-8691
Mobile - (443) 864-1590

--Boundary_(ID_0OuWU9GhMsXY5C0yhhHB5w)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

<html>
While PKI certainly has significant value with regards to applying
digital signatures and other issues regarding non-repudiation, I beli=
eve
that we often seem to overlook the main benefits that are used to jus=
tify
deploying PKI today.<br><br>
PKI is the core component of any real Identity Management
infrastructure.&nbsp; It provides for strong authentication to networ=
king
systems and applications.&nbsp; It serves to help reduce the number o=
f
managed identities for corporate employees and thereby improve securi=
ty
by eliminating passwords.&nbsp; It provides integrity and confidentia=
lity
of email and assures recipients as to who actually sent the
message.&nbsp; It is used to validate software and make it more diffi=
cult
to spread viruses.<br><br>
We are all familiar with these well advertised benefits but for some
reason we seem to constantly dismiss them when talking about whether =
of
not PKI is ready for prime time and or commercial desirability.&nbsp;
<br><br>
Trust me... it is commercially desirable today.&nbsp; Maybe one day w=
e
can figure out how to incorporate it into the legal infrastructure bu=
t
that is not the driving force, at least not today.<br><br>
Identity management is the driving force for PKI and identity managem=
ent
is one of the most desirable solutions on the market today.<br><br>
<br><br>
At 11:18 PM 6/21/2003, todd glassey wrote:<br><br>
<blockquote type=3Dcite class=3Dcite cite>Anders, you are certainly a
powerful force in the development of<br>
cryptography in Europe (and I do mean this, no sarcasm intended), so
I<br>
respect the commentary.<br><br>
I do however respectfully disagree.&nbsp; People use PKI because they
have to not<br>
because it makes sense to yet and that is the problem in a nut shell.=
 It
is<br>
still not commercially viable to rely on PKI systems... and there is
no<br>
proof yet that any of the EU's stringent privacy directives are ever
going<br>
to be met. So even though some of the smaller nations have started to
force<br>
their population to rely on PKI's in the form of Public x.509 certs
(ala<br>
Verisign/Thawte etc etc etc)...<br><br>
My feeling from a higher-ground perspective is that PKI as a whole to
date<br>
has failed to address 2000 years of human process and legal developme=
nt
and<br>
has actually sought to eliminate much of the ceremony in favor of a<b=
r>
mechanical infrastructure ... i.e. to replace &quot;it&quot;. But in
response to that,<br>
I want to point out that PKI processes can be made to conform to
paper<br>
signing ceremonies and that is the best way to get people to feel<br>
comfortable with PKI...because so far the only reasons to use a
certificate<br>
are the ones where its mandated by law.&nbsp; Which leads me to think
that PKI is<br>
still years away from commercial desirability.<br><br>
In closing, I want to reiterate that in all the examples you cited we
were<br>
talking about a legal mandate, not generally a choice, so that implie=
s to
me<br>
that so far the only reason to use PKI is for the Force of Law that
the<br>
eSign legislation brought into it...<br><br>
Todd<br>
----- Original Message ----- <br>
=46rom: &quot;Anders Rundgren&quot; &lt;[email-masked]&gt;=
<br>
To: &quot;todd glassey&quot; &lt;[email-masked]&gt;;
&lt;[email-masked]&gt;<br>
Sent: Saturday, June 21, 2003 10:56 AM<br>
Subject: Re: UK: PKI &quot;not working&quot;<br><br>
<br>
&gt; Todd,<br>
&gt; May I comment on the UK e-envoy's complaints?<br>
&gt;<br>
&gt; Firstly, the UK do not have the concept of a &quot;citizen
identity&quot;.<br>
&gt; It is IMHO fairly impossible to create useful TTP PKIs for
on-line<br>
&gt; authentication and signing without working naming schemes.<br>
&gt; Not to mention creating multi-authority work-flow tasks<br>
&gt; (or &quot;one-stop shopping&quot; as it is coined in Sweden).<br=
&gt;<br>
&gt; Secondly, in Sweden 3 million citizens out of 9 million total
can<br>
&gt; get a citizen certificate at the click of a button in their on-l=
ine
bank<br>
&gt; which is an indication that &quot;not working&quot; is not a
universal truth.<br>
&gt;<br>
&gt; To be honest the Swedish bank consortium do not rely on the<br>
&gt; browsers' built-in crypto-functions as these were considered=
=20
as<br>
&gt; unwieldy, and not sufficiently standardized.&nbsp; Here your
comments<br>
&gt; regarding lacking or not accepted standards apply, as
&quot;web-sign&quot;<br>
&gt; is a major activity since years backs but still not covered by
any<br>
&gt; standards WG!&nbsp; To circumvent this blatant deficiency, the
banks<br>
&gt; selected a proprietary Java applet from an IBM lab in Zurich.<br=
&gt;<br>
&gt; What indeed is not working [on a practical and wide scale] is
the<br>
&gt; concept of mobile PKI resources that can be used at home, in=
=20
an<br>
&gt; Internet caf=E9 or at work.&nbsp; Here I believe ETSI's and EU's=
 work
in<br>
&gt; the field of smart cards has generally failed.<br>
&gt;<br>
&gt; What is also not working is many-to-many encrypted e-mail.<br>
&gt; But that does not really matter as the on-line paradigm using<br=
&gt; https + web has effectively replaced encrypted e-mail for<br>
&gt; both on-line banking and e-government services.<br>
&gt;<br>
&gt; Anders R<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; From: &quot;todd glassey&quot;
&lt;[email-masked]&gt;<br>
&gt; To: &lt;[email-masked]&gt;; &quot;el-sign: electronic signatu=
res
- open<br>
discussion&quot; &lt;[email-masked]&gt;<br>
&gt; Sent: Thursday, June 12, 2003 16:28<br>
&gt; Subject: Fw: PKI &quot;not working&quot;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; This is a cross posting from the ISC's mailing lists of the=20
Bar<br>
Association.<br>
&gt;<br>
&gt; Why it is important here is that it documents perceived problems=
 in
the<br>
PKI<br>
&gt; marketplace and I perceive that a number of these issues are
failures in<br>
the<br>
&gt; IETF's and potentially the ETSI standards processes, since they
allow<br>
&gt; processes that are at best incomplete from a deployment stance t=
o
be<br>
&gt; elevated into standards status IMHO.<br>
&gt;<br>
&gt; My concern is that the value of the IETF and ETSI is growing les=
s
and less<br>
&gt; with these types of realizations in the marketplace.<br>
&gt;<br>
&gt; Todd<br>
&gt;<br>
&gt;<br>
&gt; To: &lt;[email-masked]&gt;<br>
&gt; Sent: Thursday, June 12, 2003 7:00 AM<br>
&gt; Subject: UK: PKI &quot;not working&quot;<br>
&gt;<br>
&gt;<br>
&gt; &gt; PKI is 'not working'<br>
&gt; &gt;<br>
&gt; &gt; Inadequate technology for online transactions is a 'huge
problem' for<br>
&gt; those<br>
&gt; &gt; in charge of e-government, admits a leading Whitehall offic=
ial
The<br>
&gt; e-envoy's<br>
&gt; &gt; office has started searching for new ways to authenticate t=
he
users of<br>
&gt; &gt; e-services as the existing technology being used is &quot;n=
ot
working&quot;, a<br>
&gt; senior<br>
&gt; &gt; Government official revealed on 11 June 2003. Although PKI
(public key<br>
&gt; &gt; infrastructure) and digital certificate technology has play=
ed a
major<br>
role<br>
&gt; &gt; in leading projects such as the Government Gateway, there i=
s
now growing<br>
&gt; &gt; recognition that it is unsuited for wider public use. While
digital<br>
&gt; &gt; certificates would not be scrapped, and would be retained a=
s an
option<br>
for<br>
&gt; &gt; e-service users, one possible alternative being suggested i=
s
that<br>
&gt; employers,<br>
&gt; &gt; banks, the voluntary sector and other &quot;trusted
organisations&quot; would<br>
verify<br>
&gt; a<br>
&gt; &gt; person's identity before transacting online for services.
Speaking on<br>
&gt; &gt; condition of anonymity, the official said the Government is=
 now
looking<br>
at<br>
&gt; &gt; &quot;radical ways&quot; of solving the authentication prob=
lem.
&quot;Trust and<br>
&gt; &gt; authentication has been a huge problem for us. We haven't g=
ot a
solution<br>
&gt; for<br>
&gt; &gt; authentication. We've been trying with PKI for about 10 yea=
rs
now and<br>
its<br>
&gt; &gt; not working because it's a pain to implement and to use. We=
've
been<br>
&gt; looking<br>
&gt; &gt; to take the pain out of PKI. &quot;What we are saying with
authentication is<br>
&gt; that<br>
&gt; &gt; if another trusted organisation such as a bank can provide
proof saying<br>
&gt; you<br>
&gt; &gt; are who you say you are that should take the need away for
digital<br>
&gt; &gt; certificates.&quot; The move comes as the e-envoy's office =
is
acutely aware<br>
&gt; that<br>
&gt; &gt; it needs to step up the pace of e-government leading up to =
the
2005<br>
&gt; target.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
<a href=3D"http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A168=
0256D43004176EA?Op" eudora=3D"autourl">http://www.kablenet.com/kd.nsf=
/Frontpage/2FBC229CDE8C5A1680256D43004176EA?Op</a><br>
&gt; &gt; enDocument<br>
&gt; &gt;<br>
&gt;<br>
&lt;<a href=3D"http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5=
A1680256D43004176EA?O" eudora=3D"autourl">http://www.kablenet.com/kd.=
nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?O</a>&gt;
&gt; penDocument&gt;<br>
&gt; &gt;<br>
&gt; &gt; Michael Power<br>
&gt; &gt;<br>
&gt; &gt; Partner &amp; Chief Privacy Officer<br>
&gt; &gt; Gowling Lafleur Henderson LLP<br>
&gt; &gt; Barristers &amp; Solicitors<br>
&gt; &gt; Patent &amp; Trade Mark Agents<br>
&gt; &gt; Suite 2600<br>
&gt; &gt; 160 Elgin Street<br>
&gt; &gt; Ottawa, Ontario, CANADA<br>
&gt; &gt; K1P 1C3<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;</blockquote>
<x-sigsep><p></x-sigsep>
***********************************************************<br>
Mitchell Arnone<br>
Managing Consultant<br>
SchlumbergerSema<br>
Technical Consulting Practice, Northeast Region<br><br>
[email-masked]<br>
<a href=3D"http://www.slb.com/nws" eudora=3D"autourl">www.slb.com/nws=
</a><br><br>
<font face=3D"impact" size=3D4 color=3D"#0000FF">Schlumberger</font><=
font face=3D"impact" size=3D4 color=3D"#FF0000">S</font><font face=
=3D"impact" size=3D4 color=3D"#0000FF">ema</font><font face=3D"arial"=
 size=3D4 color=3D"#0000FF">
<br>
</font><font face=3D"Univers 47 CondensedLight" size=3D4 color=3D"#80=
8080">Network &amp; Infrastructure Solutions<br>
</font><font color=3D"#000080">194 Wood Avenue, South<br>
Iselin, NJ 08830<br>
Direct Line- (410) 579-8691<br>
Mobile - (443) 864-1590<br><br>
</font></html>

--Boundary_(ID_0OuWU9GhMsXY5C0yhhHB5w)--

From: "todd glassey" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Subject: Re: UK: PKI "not working"
Date: Sat, 21 Jun 2003 20:18:59 -0700
Sender: [email-masked]

Anders, you are certainly a powerful force in the development of
cryptography in Europe (and I do mean this, no sarcasm intended), so I
respect the commentary.

I do however respectfully disagree.  People use PKI because they have to not
because it makes sense to yet and that is the problem in a nut shell. It is
still not commercially viable to rely on PKI systems... and there is no
proof yet that any of the EU's stringent privacy directives are ever going
to be met. So even though some of the smaller nations have started to force
their population to rely on PKI's in the form of Public x.509 certs (ala
Verisign/Thawte etc etc etc)...

My feeling from a higher-ground perspective is that PKI as a whole to date
has failed to address 2000 years of human process and legal development and
has actually sought to eliminate much of the ceremony in favor of a
mechanical infrastructure ... i.e. to replace "it". But in response to that,
I want to point out that PKI processes can be made to conform to paper
signing ceremonies and that is the best way to get people to feel
comfortable with PKI...because so far the only reasons to use a certificate
are the ones where its mandated by law.  Which leads me to think that PKI is
still years away from commercial desirability.

In closing, I want to reiterate that in all the examples you cited we were
talking about a legal mandate, not generally a choice, so that implies to me
that so far the only reason to use PKI is for the Force of Law that the
eSign legislation brought into it...

Todd
----- Original Message ----- 
From: "Anders Rundgren" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>
Sent: Saturday, June 21, 2003 10:56 AM
Subject: Re: UK: PKI "not working"

> Todd,
> May I comment on the UK e-envoy's complaints?
>
> Firstly, the UK do not have the concept of a "citizen identity".
> It is IMHO fairly impossible to create useful TTP PKIs for on-line
> authentication and signing without working naming schemes.
> Not to mention creating multi-authority work-flow tasks
> (or "one-stop shopping" as it is coined in Sweden).
>
> Secondly, in Sweden 3 million citizens out of 9 million total can
> get a citizen certificate at the click of a button in their on-line bank
> which is an indication that "not working" is not a universal truth.
>
> To be honest the Swedish bank consortium do not rely on the
> browsers' built-in crypto-functions as these were considered as
> unwieldy, and not sufficiently standardized.  Here your comments
> regarding lacking or not accepted standards apply, as "web-sign"
> is a major activity since years backs but still not covered by any
> standards WG!  To circumvent this blatant deficiency, the banks
> selected a proprietary Java applet from an IBM lab in Zurich.
>
> What indeed is not working [on a practical and wide scale] is the
> concept of mobile PKI resources that can be used at home, in an
> Internet café or at work.  Here I believe ETSI's and EU's work in
> the field of smart cards has generally failed.
>
> What is also not working is many-to-many encrypted e-mail.
> But that does not really matter as the on-line paradigm using
> https + web has effectively replaced encrypted e-mail for
> both on-line banking and e-government services.
>
> Anders R
>
> ----- Original Message -----
> From: "todd glassey" <[email-masked]>
> To: <[email-masked]>; "el-sign: electronic signatures - open
discussion" <[email-masked]>
> Sent: Thursday, June 12, 2003 16:28
> Subject: Fw: PKI "not working"
>
>
>
> This is a cross posting from the ISC's mailing lists of the Bar
Association.
>
> Why it is important here is that it documents perceived problems in the
PKI
> marketplace and I perceive that a number of these issues are failures in
the
> IETF's and potentially the ETSI standards processes, since they allow
> processes that are at best incomplete from a deployment stance to be
> elevated into standards status IMHO.
>
> My concern is that the value of the IETF and ETSI is growing less and less
> with these types of realizations in the marketplace.
>
> Todd
>
>
> To: <[email-masked]>
> Sent: Thursday, June 12, 2003 7:00 AM
> Subject: UK: PKI "not working"
>
>
> > PKI is 'not working'
> >
> > Inadequate technology for online transactions is a 'huge problem' for
> those
> > in charge of e-government, admits a leading Whitehall official The
> e-envoy's
> > office has started searching for new ways to authenticate the users of
> > e-services as the existing technology being used is "not working", a
> senior
> > Government official revealed on 11 June 2003. Although PKI (public key
> > infrastructure) and digital certificate technology has played a major
role
> > in leading projects such as the Government Gateway, there is now growing
> > recognition that it is unsuited for wider public use. While digital
> > certificates would not be scrapped, and would be retained as an option
for
> > e-service users, one possible alternative being suggested is that
> employers,
> > banks, the voluntary sector and other "trusted organisations" would
verify
> a
> > person's identity before transacting online for services. Speaking on
> > condition of anonymity, the official said the Government is now looking
at
> > "radical ways" of solving the authentication problem. "Trust and
> > authentication has been a huge problem for us. We haven't got a solution
> for
> > authentication. We've been trying with PKI for about 10 years now and
its
> > not working because it's a pain to implement and to use. We've been
> looking
> > to take the pain out of PKI. "What we are saying with authentication is
> that
> > if another trusted organisation such as a bank can provide proof saying
> you
> > are who you say you are that should take the need away for digital
> > certificates." The move comes as the e-envoy's office is acutely aware
> that
> > it needs to step up the pace of e-government leading up to the 2005
> target.
> >
> >
> >
>
http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?Op
> > enDocument
<http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?O
> > penDocument>
> >
> > Michael Power
> >
> > Partner & Chief Privacy Officer
> > Gowling Lafleur Henderson LLP
> > Barristers & Solicitors
> > Patent & Trade Mark Agents
> > Suite 2600
> > 160 Elgin Street
> > Ottawa, Ontario, CANADA
> > K1P 1C3
> >
> >
> >
>
>

From: "Anders Rundgren" <[email-masked]>
To: "todd glassey" <[email-masked]>, <[email-masked]>
Subject: Re: UK: PKI "not working"
Date: Sat, 21 Jun 2003 19:56:15 +0200
Sender: [email-masked]

Todd,
May I comment on the UK e-envoy's complaints?

Firstly, the UK do not have the concept of a "citizen identity".
It is IMHO fairly impossible to create useful TTP PKIs for on-line
authentication and signing without working naming schemes.
Not to mention creating multi-authority work-flow tasks
(or "one-stop shopping" as it is coined in Sweden).

Secondly, in Sweden 3 million citizens out of 9 million total can
get a citizen certificate at the click of a button in their on-line bank
which is an indication that "not working" is not a universal truth.

To be honest the Swedish bank consortium do not rely on the
browsers' built-in crypto-functions as these were considered as
unwieldy, and not sufficiently standardized.  Here your comments
regarding lacking or not accepted standards apply, as "web-sign"
is a major activity since years backs but still not covered by any
standards WG!  To circumvent this blatant deficiency, the banks
selected a proprietary Java applet from an IBM lab in Zurich.

What indeed is not working [on a practical and wide scale] is the
concept of mobile PKI resources that can be used at home, in an
Internet café or at work.  Here I believe ETSI's and EU's work in
the field of smart cards has generally failed.

What is also not working is many-to-many encrypted e-mail.
But that does not really matter as the on-line paradigm using
https + web has effectively replaced encrypted e-mail for
both on-line banking and e-government services.

Anders R

----- Original Message -----
From: "todd glassey" <[email-masked]>
To: <[email-masked]>; "el-sign: electronic signatures - open discussion" <[email-masked]>
Sent: Thursday, June 12, 2003 16:28
Subject: Fw: PKI "not working"

This is a cross posting from the ISC's mailing lists of the Bar Association.

Why it is important here is that it documents perceived problems in the PKI
marketplace and I perceive that a number of these issues are failures in the
IETF's and potentially the ETSI standards processes, since they allow
processes that are at best incomplete from a deployment stance to be
elevated into standards status IMHO.

My concern is that the value of the IETF and ETSI is growing less and less
with these types of realizations in the marketplace.

Todd

To: <[email-masked]>
Sent: Thursday, June 12, 2003 7:00 AM
Subject: UK: PKI "not working"

> PKI is 'not working'
>
> Inadequate technology for online transactions is a 'huge problem' for
those
> in charge of e-government, admits a leading Whitehall official The
e-envoy's
> office has started searching for new ways to authenticate the users of
> e-services as the existing technology being used is "not working", a
senior
> Government official revealed on 11 June 2003. Although PKI (public key
> infrastructure) and digital certificate technology has played a major role
> in leading projects such as the Government Gateway, there is now growing
> recognition that it is unsuited for wider public use. While digital
> certificates would not be scrapped, and would be retained as an option for
> e-service users, one possible alternative being suggested is that
employers,
> banks, the voluntary sector and other "trusted organisations" would verify
a
> person's identity before transacting online for services. Speaking on
> condition of anonymity, the official said the Government is now looking at
> "radical ways" of solving the authentication problem. "Trust and
> authentication has been a huge problem for us. We haven't got a solution
for
> authentication. We've been trying with PKI for about 10 years now and its
> not working because it's a pain to implement and to use. We've been
looking
> to take the pain out of PKI. "What we are saying with authentication is
that
> if another trusted organisation such as a bank can provide proof saying
you
> are who you say you are that should take the need away for digital
> certificates." The move comes as the e-envoy's office is acutely aware
that
> it needs to step up the pace of e-government leading up to the 2005
target.
http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?Op
> enDocument
<http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?O
> penDocument>
>
> Michael Power
>
> Partner & Chief Privacy Officer
> Gowling Lafleur Henderson LLP
> Barristers & Solicitors
> Patent & Trade Mark Agents
> Suite 2600
> 160 Elgin Street
> Ottawa, Ontario, CANADA
> K1P 1C3
>
>
>

From: "Matt Cooper" <[email-masked]>
To: "'Brian Hunter'" <[email-masked]>, <[email-masked]>
Subject: RE: Revocation status checking of self-issued certificates
Date: Thu, 19 Jun 2003 17:58:00 -0400
Importance: Normal
Sender: [email-masked]

Hi Brian,

Sorry for the lack of clarity;  Skipping CRL checks for intermediate self
issued certs would not be desirable.

-Matt

> -----Original Message-----
> From: Brian Hunter [mailto:[email-masked]] 
> Sent: Thursday, June 19, 2003 3:16 PM
> To: Matt Cooper; [email-masked]
> Subject: Re: Revocation status checking of self-issued certificates
> 
> 
> Matt,
> 
> Thanks for correcting my comment on Santosh's comment.  
> However, it still leaves my original question open, that is, 
> what is done in regards to revocation checks for self-issued 
> certificates.  Any comments?
> 
> Regards,
> Brian
> 
> Matt Cooper wrote:
> > 
> > Brian,
> > 
> > I think what Santosh was saying is the names in the cert 
> path should 
> > match the names for the CRL's cert path, irrespective of 
> traversing a 
> > self issued certificate on one or the other.
> > 
> > For example, this would be ok - ====================================
> > CertPath: A->B->C->Target Cert
> > CRL Path:  A->B->B->C->CRL
> > 
> > This is not ok:
> > ====================================
> > CertPath: A->B->C->Target Cert
> > CRL Path:  A->C->B->C->CRL
> > 
> > You might end up with the first example as the result of a rekey.
> > 
> > Best Regards,
> > Matt Cooper
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Brian Hunter
> > > Sent: Wednesday, June 18, 2003 12:16 PM
> > > To: [email-masked]
> > > Subject: Revocation status checking of self-issued certificates
> > >
> > >
> > >
> > > Hello,
> > >
> > > I have a question of whether self-issued certificates 
> need to have 
> > > their revocation status checked.  I am referring to only 
> > > intermediate or path ending self-issued certificates and 
> not trust 
> > > anchors.
> > >
> > > I have read through some PKIX discussions, in particular 
> > > "Identifying the right CRL for a given certificate", 
> where Santosh 
> > > seemed to imply that no check was
> > > required:
> > >   2.  The DNs for the certification path for the 
> certificate should 
> > > match
> > >   the DNs for the certification path for the CRL 
> (ignoring self-issued
> > >   certificates).  Of course, the last DN (namely the 
> subscriber DN) 
> > > will
> > >   be missing from the CRL certification path.
> > >
> > > (This is not exactly the same context, but I believe similar.  I 
> > > take "ignoring self-issued certificates" to imply that 
> there would 
> > > be no revocation checks for
> > > them.)
> > > Another discussion, "CDP in self signed root CA", dealed 
> only with 
> > > root CAs.
> > >
> > > I see the benefit of both, no checking saves time and rather 
> > > redundant checks. The self-issued certificate could be revoked by 
> > > having the original CA certificate revoked, this is 
> however costly.
> > > Doing revocation checks allows the CA to revoke individual
> > > self-issued certificates itself, without having to have its
> > > own certificate revoked, provided that the self-issued
> > > certificate wasn't the one delegated to be used as a CRLIssuer.
> > >
> > > However by reading X509 and RFC3280, it says to me that 
> the status 
> > > of all self-issued certificates must be checked. (Self-issued 
> > > certificates tend to be excluded from such things as name 
> constraint 
> > > processing and path lengths, but not status checking).
> > >
> > > Could someone help clarify this for me, whether these 
> certs need to 
> > > have their revocation status checked?
> > >
> > > Many thanks,
> > > Brian
> > >
> 

Date: Thu, 19 Jun 2003 21:16:28 +0200
From: Brian Hunter <[email-masked]>
To: Matt Cooper <[email-masked]>, [email-masked]
Subject: Re: Revocation status checking of self-issued certificates
Sender: [email-masked]

Matt,

Thanks for correcting my comment on Santosh's comment.  However, it still leaves
my original question open, that is, what is done in regards to revocation checks
for self-issued certificates.  Any comments?

Regards,
Brian

Matt Cooper wrote:
> 
> Brian,
> 
> I think what Santosh was saying is the names in the cert path should match
> the names for the CRL's cert path, irrespective of traversing a self issued
> certificate on one or the other.
> 
> For example, this would be ok -
> ====================================
> CertPath: A->B->C->Target Cert
> CRL Path:  A->B->B->C->CRL
> 
> This is not ok:
> ====================================
> CertPath: A->B->C->Target Cert
> CRL Path:  A->C->B->C->CRL
> 
> You might end up with the first example as the result of a rekey.
> 
> Best Regards,
> Matt Cooper
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Brian Hunter
> > Sent: Wednesday, June 18, 2003 12:16 PM
> > To: [email-masked]
> > Subject: Revocation status checking of self-issued certificates
> >
> >
> >
> > Hello,
> >
> > I have a question of whether self-issued certificates need to
> > have their revocation status checked.  I am referring to only
> > intermediate or path ending self-issued certificates and not
> > trust anchors.
> >
> > I have read through some PKIX discussions, in particular
> > "Identifying the right CRL for a given certificate", where
> > Santosh seemed to imply that no check was
> > required:
> >   2.  The DNs for the certification path for the certificate
> > should match
> >   the DNs for the certification path for the CRL (ignoring self-issued
> >   certificates).  Of course, the last DN (namely the
> > subscriber DN) will
> >   be missing from the CRL certification path.
> >
> > (This is not exactly the same context, but I believe similar.
> >  I take "ignoring self-issued certificates" to imply that
> > there would be no revocation checks for
> > them.)
> > Another discussion, "CDP in self signed root CA", dealed only
> > with root CAs.
> >
> > I see the benefit of both, no checking saves time and rather
> > redundant checks.
> > The self-issued certificate could be revoked by having the
> > original CA certificate revoked, this is however costly.
> > Doing revocation checks allows the CA to revoke individual
> > self-issued certificates itself, without having to have its
> > own certificate revoked, provided that the self-issued
> > certificate wasn't the one delegated to be used as a CRLIssuer.
> >
> > However by reading X509 and RFC3280, it says to me that the
> > status of all self-issued certificates must be checked.
> > (Self-issued certificates tend to be excluded from such
> > things as name constraint processing and path lengths, but
> > not status checking).
> >
> > Could someone help clarify this for me, whether these certs
> > need to have their revocation status checked?
> >
> > Many thanks,
> > Brian
> >

From: "todd glassey" <[email-masked]>
To: "Margus Freudenthal" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a    specific flag in the TST to represent an official TST?)
Date: Thu, 19 Jun 2003 08:04:24 -0700
Sender: [email-masked]

----- Original Message ----- 
From: "Margus Freudenthal" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 19, 2003 5:38 AM
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside
a specific flag in the TST to represent an official TST?)

>
> todd glassey wrote:
> >
> > Margus, part of the issue with the TST is that it is intended to be the
> > "universal" receipt. That is that it is supposed to stand as evidence of
> > some transaction... so then the issues become specific to what is the
"best
> > case" evidentiary model, and what is the greatest common denominator
amongst
> > all use models based on the need of a light-weight evidentiary
declaration
> > as to ANYTHING.
> >
> > because the mandates of evidentiary testimony are not well served by
today's
> > TST...
>
> ... and adding one bit of information would change that? In that case,

if it can be agreed to, yes, that's the point.

> you can simply mandate that all time-stamp tokens which are meant to be
> used for evidentiary purposes, MUST have policy OID whose last part is 1
> (e.g. 1.2.3.4.1).

Which means that mechanical policy is not also implemented as part of the
transactional policy... making the number of interpretable OIDS much larger
since for each instance of LEGAL_STATUS_OID there would be an accompaning
PHYSICAL_POLICY_Designator...

so with the proposed model you set forth , the total OID's = p*l rather than
the much smaller number represented by p+l for the model I proposed.

Both solutions work, except one is much smaller in the potential size of the
policy table that would have to be maintained and evaluated for each and all
timestamps issued or processed.

> Otherwise, last part of policy OID MUST be 2 (e.g.
> 1.2.3.4.2). Compliant implementations MUST NOT use any other numbers as
> last part of the policy OID.
>
> With that rule in place, we can boldly go where no time stamps have
> never gone before.
>
> >    which is why I keep asking this WG to think of what the real uses of
> > the token are.
> >
> What I personally would do with time stamps is a very long story and
> most of it doesn't concern activities of PKIX. However, I see no way how
> addition of a boolean field would change field of possible uses. As a
> matter of fact, I can't see how removal of time-stamping policy field
> would change possible use cases.
>
> > The other thing that the Data Structure itself needs to take into
account
> > aside from evidentiary data payload requirements, is what its supposed
to do
> > relative to eSign or other DSA and this is of course something that PKIX
> > refused to look at all the way through the RFC3161 process. Also
apparently
> > something  no-one ever looked at.
> >
> I have asked several times that you describe how exactly would you use
> time-stamp in legal context (with the help of "legal context bit"). So
> far you have not given any examples.
>
>
> -- 
> Margus

To: [email-masked]
Cc: [email-masked], [email-masked]
From: "Matt Crawford" <[email-masked]>
Subject: please clarify 3280
Date: Thu, 19 Jun 2003 09:39:55 -0500
Sender: [email-masked]

When 3280 is considered for advancement to DS, could the following
paragraph of 4.2.1.11 (Name Constraints) please be clarified?

   DNS name restrictions are expressed as foo.bar.com.  Any DNS name
   that can be constructed by simply adding to the left hand side of the
   name satisfies the name constraint.  For example, www.foo.bar.com
   would satisfy the constraint but foo1.bar.com would not.

As written, myfoo.bar.com would satisfy the constraint, but I doubt
that is what was intended.  Some verbiage about dots would be needed.

From: "todd glassey" <[email-masked]>
To: "Margus Freudenthal" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a    specific flag in the TST to represent an official TST?)
Date: Thu, 19 Jun 2003 07:12:13 -0700
Sender: [email-masked]

Margus, I have no problem in using the extensions to represent this. I just
want to predefine the use model as part of the AS for the Specification.

----- Original Message ----- 
From: "Margus Freudenthal" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 19, 2003 5:38 AM
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside
a specific flag in the TST to represent an official TST?)

> todd glassey wrote:
> >
> > Margus, part of the issue with the TST is that it is intended to be the
> > "universal" receipt. That is that it is supposed to stand as evidence of
> > some transaction... so then the issues become specific to what is the
"best
> > case" evidentiary model, and what is the greatest common denominator
amongst
> > all use models based on the need of a light-weight evidentiary
declaration
> > as to ANYTHING.
> >
> > because the mandates of evidentiary testimony are not well served by
today's
> > TST...
>
> ... and adding one bit of information would change that? In that case,
> you can simply mandate that all time-stamp tokens which are meant to be
> used for evidentiary purposes, MUST have policy OID whose last part is 1
> (e.g. 1.2.3.4.1). Otherwise, last part of policy OID MUST be 2 (e.g.
> 1.2.3.4.2). Compliant implementations MUST NOT use any other numbers as
> last part of the policy OID.
>
> With that rule in place, we can boldly go where no time stamps have
> never gone before.
>
> >    which is why I keep asking this WG to think of what the real uses of
> > the token are.
> >
> What I personally would do with time stamps is a very long story and
> most of it doesn't concern activities of PKIX. However, I see no way how
> addition of a boolean field would change field of possible uses. As a
> matter of fact, I can't see how removal of time-stamping policy field
> would change possible use cases.
>
> > The other thing that the Data Structure itself needs to take into
account
> > aside from evidentiary data payload requirements, is what its supposed
to do
> > relative to eSign or other DSA and this is of course something that PKIX
> > refused to look at all the way through the RFC3161 process. Also
apparently
> > something  no-one ever looked at.
> >
> I have asked several times that you describe how exactly would you use
> time-stamp in legal context (with the help of "legal context bit"). So
> far you have not given any examples.
>
>
> -- 
> Margus

Date: Thu, 19 Jun 2003 15:38:14 +0300
From: Margus Freudenthal <[email-masked]>
To: todd glassey <[email-masked]>
CC: [email-masked]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a    specific flag in the TST to represent an official TST?)
Sender: [email-masked]

todd glassey wrote:
> 
> Margus, part of the issue with the TST is that it is intended to be the
> "universal" receipt. That is that it is supposed to stand as evidence of
> some transaction... so then the issues become specific to what is the "best
> case" evidentiary model, and what is the greatest common denominator amongst
> all use models based on the need of a light-weight evidentiary declaration
> as to ANYTHING.
> 
> because the mandates of evidentiary testimony are not well served by today's
> TST... 

... and adding one bit of information would change that? In that case,
you can simply mandate that all time-stamp tokens which are meant to be
used for evidentiary purposes, MUST have policy OID whose last part is 1
(e.g. 1.2.3.4.1). Otherwise, last part of policy OID MUST be 2 (e.g.
1.2.3.4.2). Compliant implementations MUST NOT use any other numbers as
last part of the policy OID.

With that rule in place, we can boldly go where no time stamps have
never gone before.

>    which is why I keep asking this WG to think of what the real uses of
> the token are.
> 
What I personally would do with time stamps is a very long story and
most of it doesn't concern activities of PKIX. However, I see no way how
addition of a boolean field would change field of possible uses. As a
matter of fact, I can't see how removal of time-stamping policy field
would change possible use cases.

> The other thing that the Data Structure itself needs to take into account
> aside from evidentiary data payload requirements, is what its supposed to do
> relative to eSign or other DSA and this is of course something that PKIX
> refused to look at all the way through the RFC3161 process. Also apparently
> something  no-one ever looked at.
> 
I have asked several times that you describe how exactly would you use
time-stamp in legal context (with the help of "legal context bit"). So
far you have not given any examples.

-- 
Margus

From: "todd glassey" <[email-masked]>
To: "Margus Freudenthal" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a   specific flag in the TST to represent an official TST?)
Date: Thu, 19 Jun 2003 04:23:27 -0700
Sender: [email-masked]

Margus, part of the issue with the TST is that it is intended to be the
"universal" receipt. That is that it is supposed to stand as evidence of
some transaction... so then the issues become specific to what is the "best
case" evidentiary model, and what is the greatest common denominator amongst
all use models based on the need of a light-weight evidentiary declaration
as to ANYTHING.

because the mandates of evidentiary testimony are not well served by today's
TST... which is why I keep asking this WG to think of what the real uses of
the token are.

So then - how would you use a token in commercial processes? - It is
essentially useless if I have to create one-off solutions for use in
commercial venues, because its them that need the standardization. So with
that said, the current RFC is still incomplete as far as methods of using
it.

The other thing that the Data Structure itself needs to take into account
aside from evidentiary data payload requirements, is what its supposed to do
relative to eSign or other DSA and this is of course something that PKIX
refused to look at all the way through the RFC3161 process. Also apparently
something  no-one ever looked at.

Todd
----- Original Message ----- 
From: "Margus Freudenthal" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 19, 2003 12:29 AM
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside
a specific flag in the TST to represent an official TST?)

> todd glassey wrote:
> >
> > because the use of these is critical to making these more useful in
> > commercial and OLTP auditing. I want to see the specific use models
penned
> > into the standard so they will be cast in concrete.
> >
> Sorry, but he first sentence is confusing. What are critical and what
> will be more useful?
>
> Can you specify unambigously how this new extension would be processed
> by the TSP-s and relying parties?
>
>
> -- 
> Margus
>

Date: Thu, 19 Jun 2003 10:29:33 +0300
From: Margus Freudenthal <[email-masked]>
To: todd glassey <[email-masked]>
CC: [email-masked]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a   specific flag in the TST to represent an official TST?)
Sender: [email-masked]

todd glassey wrote:
> 
> because the use of these is critical to making these more useful in
> commercial and OLTP auditing. I want to see the specific use models penned
> into the standard so they will be cast in concrete.
> 
Sorry, but he first sentence is confusing. What are critical and what
will be more useful?

Can you specify unambigously how this new extension would be processed
by the TSP-s and relying parties?

-- 
Margus

From: "todd glassey" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a  specific flag in the TST to represent an official TST?)
Date: Wed, 18 Jun 2003 20:05:06 -0700
Sender: [email-masked]

because the use of these is critical to making these more useful in
commercial and OLTP auditing. I want to see the specific use models penned
into the standard so they will be cast in concrete.

Todd

----- Original Message ----- 
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 18, 2003 7:53 AM
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside
a specific flag in the TST to represent an official TST?)

> >
> >
> > Thanks Margus - yes they are different, both technically and
"legally"...
> > and so that is why they need the Policy Extension.
>
> Margus seems to ask why just two different policy OID won't work?
>
>

From: "Matt Cooper" <[email-masked]>
To: "'Brian Hunter'" <[email-masked]>, <[email-masked]>
Subject: RE: Revocation status checking of self-issued certificates
Date: Wed, 18 Jun 2003 18:15:26 -0400
Importance: Normal
Sender: [email-masked]

Brian,

I think what Santosh was saying is the names in the cert path should match
the names for the CRL's cert path, irrespective of traversing a self issued
certificate on one or the other.

For example, this would be ok - 
====================================
CertPath: A->B->C->Target Cert
CRL Path:  A->B->B->C->CRL

This is not ok:
====================================
CertPath: A->B->C->Target Cert
CRL Path:  A->C->B->C->CRL

You might end up with the first example as the result of a rekey.

Best Regards,
Matt Cooper

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Hunter
> Sent: Wednesday, June 18, 2003 12:16 PM
> To: [email-masked]
> Subject: Revocation status checking of self-issued certificates
> 
> 
> 
> Hello,
> 
> I have a question of whether self-issued certificates need to 
> have their revocation status checked.  I am referring to only 
> intermediate or path ending self-issued certificates and not 
> trust anchors.
> 
> I have read through some PKIX discussions, in particular 
> "Identifying the right CRL for a given certificate", where 
> Santosh seemed to imply that no check was
> required:
>   2.  The DNs for the certification path for the certificate 
> should match
>   the DNs for the certification path for the CRL (ignoring self-issued
>   certificates).  Of course, the last DN (namely the 
> subscriber DN) will
>   be missing from the CRL certification path.
> 
> (This is not exactly the same context, but I believe similar. 
>  I take "ignoring self-issued certificates" to imply that 
> there would be no revocation checks for
> them.)
> Another discussion, "CDP in self signed root CA", dealed only 
> with root CAs.
> 
> I see the benefit of both, no checking saves time and rather 
> redundant checks. 
> The self-issued certificate could be revoked by having the 
> original CA certificate revoked, this is however costly.  
> Doing revocation checks allows the CA to revoke individual 
> self-issued certificates itself, without having to have its 
> own certificate revoked, provided that the self-issued 
> certificate wasn't the one delegated to be used as a CRLIssuer.
> 
> However by reading X509 and RFC3280, it says to me that the 
> status of all self-issued certificates must be checked.  
> (Self-issued certificates tend to be excluded from such 
> things as name constraint processing and path lengths, but 
> not status checking).
> 
> Could someone help clarify this for me, whether these certs 
> need to have their revocation status checked?
> 
> Many thanks,
> Brian
> 

Date: Wed, 18 Jun 2003 10:22:45 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Sender: [email-masked]

At 7:27 PM -0700 6/17/03, todd glassey wrote:
>I disagree Steve, and I believe your specific zeal in keeping this as a
>purely technical process instead of one that businesses and other entities
>can use is more than obnoxious its negligent , but anything less from you to
>one of my suggestions would go against virtually all of the communications
>between us for the last seven years so Steve, your retort was expected.

Todd, in your original message on this thread, you asked:

>Anyone have a problem with this?, other than it is me suggesting it?

I avoided that question in my response because it sounded like that 
you recognized your previous problems with your behavior and might 
not repeat them. Your reply above indicates that, no, you are going 
to repeat them.

So, let me add a comment to my first reply: yes, I now have a problem 
with the person suggesting it being you. I would strongly prefer 
suggestions to come from people who act maturely on the mailing list 
and, when confronted with a problem that might stymie them, chooses 
to follow the established rules of the forum in which they are 
working. In this case, that would mean you not writing messages such 
as the one above, and instead writing an Internet Draft and seeing if 
there is interest in the IETF for making it an RFC. You don't need to 
discuss it any more on this mailing list until we have an Internet 
Draft to look at; at that point, we can judge your proposal on its 
technical and procedural merits. Given your track record, I would 
suggest that you get a co-author and let them do most of the posting 
to the mailing list, at least if you are serious about wanting this 
work to become an RFC.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Sharon Boeyen <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, Matt Cooper <[email-masked]>
Cc: [email-masked]
Subject: RE: RFC 3280: same certificate in a certification path
Date: Wed, 18 Jun 2003 13:07:31 -0400
Sender: [email-masked]

Date: Wed, 18 Jun 2003 18:15:40 +0200
From: Brian Hunter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Revocation status checking of self-issued certificates
Sender: [email-masked]

Hello,

I have a question of whether self-issued certificates need to have their
revocation status checked.  I am referring to only intermediate or path ending
self-issued certificates and not trust anchors.

I have read through some PKIX discussions, in particular "Identifying the right
CRL for a given certificate", where Santosh seemed to imply that no check was
required:
  2.  The DNs for the certification path for the certificate should match
  the DNs for the certification path for the CRL (ignoring self-issued
  certificates).  Of course, the last DN (namely the subscriber DN) will
  be missing from the CRL certification path.

(This is not exactly the same context, but I believe similar.  I take "ignoring
self-issued certificates" to imply that there would be no revocation checks for
them.)
Another discussion, "CDP in self signed root CA", dealed only with root CAs.

I see the benefit of both, no checking saves time and rather redundant checks. 
The self-issued certificate could be revoked by having the original CA
certificate revoked, this is however costly.  Doing revocation checks allows the
CA to revoke individual self-issued certificates itself, without having to have
its own certificate revoked, provided that the self-issued certificate wasn't
the one delegated to be used as a CRLIssuer.

However by reading X509 and RFC3280, it says to me that the status of all
self-issued certificates must be checked.  (Self-issued certificates tend to be
excluded from such things as name constraint processing and path lengths, but
not status checking).

Could someone help clarify this for me, whether these certs need to have their
revocation status checked?

Many thanks,
Brian

Date: Wed, 18 Jun 2003 17:21:17 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: poll for a meeting agenda  
Sender: [email-masked]

Would it be possible for the chair to indicate whether they
have approved new working drafts before the cut of date
last Monday? 

Date: Wed, 18 Jun 2003 16:53:18 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a  specific flag in the TST to represent an official TST?)
Cc: [email-masked]
Sender: [email-masked]

> 
> 
> Thanks Margus - yes they are different, both technically and "legally"...
> and so that is why they need the Policy Extension.

Margus seems to ask why just two different policy OID won't work?

From: "todd glassey" <[email-masked]>
To: "Margus Freudenthal" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a  specific flag in the TST to represent an official TST?)
Date: Wed, 18 Jun 2003 06:17:19 -0700
Sender: [email-masked]

Thanks Margus - yes they are different, both technically and "legally"...
and so that is why they need the Policy Extension.

Todd

----- Original Message ----- 
From: "Margus Freudenthal" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 18, 2003 1:34 AM
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside
a specific flag in the TST to represent an official TST?)

> Hi.
>
> todd glassey wrote:
> >
> > The problem is that the TS Policy is about the structural policy under
which
> > the TST was fabricated or under which it is to be evaluated and what we
are
> > looking for is a method of having two identical tokens made in the same
> > system, right next to each other for which one is a "legally
enforceable"
> > record of an event and the other is just a pki-signed TST.
> >
> I'm confused. Are these tokens _identical_ or not? If they are, then I
> see no reason why both of them cannot be used in the same context,
> whether it is "legally enforceable" or whatever. If they are not
> identical, then I assume that they are produced under different policies
> or whatever. In that case, the TSA can specify in his policy, whether
> this token is meant to used in "legally enforceable" context.
>
> Following your logic, it would make sense to replace the policy
> identifier with bit string which contains answers to various questions
> about the service.
>
> -- 
> Margus

Date: Wed, 18 Jun 2003 11:34:41 +0300
From: Margus Freudenthal <[email-masked]>
To: todd glassey <[email-masked]>
CC: [email-masked]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a  specific flag in the TST to represent an official TST?)
Sender: [email-masked]

Hi.

todd glassey wrote:
> 
> The problem is that the TS Policy is about the structural policy under which
> the TST was fabricated or under which it is to be evaluated and what we are
> looking for is a method of having two identical tokens made in the same
> system, right next to each other for which one is a "legally enforceable"
> record of an event and the other is just a pki-signed TST.
> 
I'm confused. Are these tokens _identical_ or not? If they are, then I
see no reason why both of them cannot be used in the same context,
whether it is "legally enforceable" or whatever. If they are not
identical, then I assume that they are produced under different policies
or whatever. In that case, the TSA can specify in his policy, whether
this token is meant to used in "legally enforceable" context.

Following your logic, it would make sense to replace the policy
identifier with bit string which contains answers to various questions
about the service.

-- 
Margus

content-class: urn:content-classes:message
Subject: RE: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Date: Wed, 18 Jun 2003 13:55:54 +1000
From: "Ramsay, Ron" <[email-masked]>
To: "todd glassey" <[email-masked]>, <[email-masked]>, "Stephen Kent" <[email-masked]>
Sender: [email-masked]

So was yours!

-----Original Message-----
From: todd glassey [mailto:[email-masked]]
Sent: Wednesday, 18 June 2003 12:28
To: [email-masked]; Paul Hoffman / IMC; Stephen Kent
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

I disagree Steve, and I believe your specific zeal in keeping this as a
purely technical process instead of one that businesses and other entities
can use is more than obnoxious its negligent , but anything less from you to
one of my suggestions would go against virtually all of the communications
between us for the last seven years so Steve, your retort was expected.

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>;
"Paul Hoffman / IMC" <[email-masked]>
Sent: Tuesday, June 17, 2003 5:44 PM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

> Todd,
>
> None of the additions suggested by you are critical to the basic time
> stamping function defined by the RFC. The function of the protocol is
> to deliver a TST in response to a request by a client, to establish
> the existence of the data represented by the contained hash, at the
> point in time that the TST is issued.
>
> The interpretation of the TST in a legal context is outside the scope
> of this WG, and will likely vary in different "jurisdictions" around
> the world. Thus if any of these additional data items are relevant,
> they may be relevant only in selected contexts and thus are
> inappropriate as data items in the base standard.  As Paul noted,
> these might be considered as extensions to the base protocol, but it
> would be inappropriate to burden the base protocol with such data.
>
> Steve

Date: Tue, 17 Jun 2003 22:39:23 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---2140662931-1832476801-1055907567=:11026
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-ID: <[email-masked]>

On Tue, 17 Jun 2003, Steve Hanna wrote:

> What will help in a huge and complex PKI?
>
> * Sending partial paths or, even better, bags of certs
>   (as S/MIME and SSL/TLS allow). Ideally, these certs
>   should go beyond the EE's trust anchor to include
>   other certs linking into relevant trust points.

Now this is getting close to a subject that hasn't been
mentioned much in this discussion.  Who's job is it to
round up the certificates needed to verify?  Sender or
receiver?  Standard practice that has evolved over eons
puts this burden on the sender; i.e, the user is expected
to "show up with the proper papers".

Yes, part of the reason for that is the "something you have"
stuff; nevertheless, putting the burden on the sender as RFCs
suggest seems like it should alleviate a lot of the performance
concerns.

I'll even go so far as to say that it's OK for the receiver
to deny verification if the sender doesn't supply all the
certificates needed.

On a tangential note that's prompted by "beyond the trust
anchor" phrase, I think a sender should send the final
certificate as well as all the others even if it is known
that the receiver has that one already (some RFCs seem to
forbid this).  The reason for this is that they can be
compared and alarms sounded if they differ.

> * Having each side tell the other what its trust anchors
>   are (as SSL/TLS allows servers to do). This helps
>   determine which trust points are relevant.

Whoops, I sure don't read section 7.4.4 of RFC2246 as saying
that.  I read it as meaning "send me a client certificate with
one of these DNs in the chain".  In most cases, that would be
the DN of the issuer of the client certificate, but one can
imagine cases where it would be farther away.  (This comment
is just about the use of the phrase "trust anchor"; it isn't
related to the above).

Furthermore, what happened to the problem identified in the
paper that Steve referred us to a while ago?  Namely, that
there are cases what you have to visit a certificate twice
to complete policy mappings (I think it was).

> Let's return to the question of whether the proposed rule
> against repeating a (name, key) pair in a path has a net
> benefit. The downside as I see it is increased complexity
> in the validation algorithm and less flexibility for the
> CA operator. And the upside? We're not plugging a security
> hole here. The main advantage is that builders can knock
> out those paths as invalid. But builders could accomplish
> almost the same thing by just rating them as unpromising
> in their heuristic.

Isn't the real problem here that there's an implicit assumption
that certificates lie in a strict hierarchy?  This assumption
seems to appear in suggested algorithms and perhaps even in
some extension semantics.  I think a better approach is to
fix the algorithm instead of restricting CAs.  (Here he comes
with the garbage collection algorithm again)!

Eric Norman

		"I may be just a butterfly,
		 but watch out if I flap my wings".

---2140662931-1832476801-1055907567=:11026
Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename="smime.p7s"

---2140662931-1832476801-1055907567=:11026--

From: "George Lake" <[email-masked]>
To: "Miguel Rodriguez" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: SCEP newest spec
Date: Tue, 17 Jun 2003 20:10:00 -0700
Importance: Normal
Sender: [email-masked]

[email-masked] wrote:
> What is the latest (or current) draft version specifying the SCEP
> protocol? 

Hi Miguel,

http://www.ietf.org/internet-drafts/draft-nourse-scep-07.txt

-George

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>, "Stephen Kent" <[email-masked]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Date: Tue, 17 Jun 2003 19:27:41 -0700
Sender: [email-masked]

I disagree Steve, and I believe your specific zeal in keeping this as a
purely technical process instead of one that businesses and other entities
can use is more than obnoxious its negligent , but anything less from you to
one of my suggestions would go against virtually all of the communications
between us for the last seven years so Steve, your retort was expected.

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>;
"Paul Hoffman / IMC" <[email-masked]>
Sent: Tuesday, June 17, 2003 5:44 PM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

> Todd,
>
> None of the additions suggested by you are critical to the basic time
> stamping function defined by the RFC. The function of the protocol is
> to deliver a TST in response to a request by a client, to establish
> the existence of the data represented by the contained hash, at the
> point in time that the TST is issued.
>
> The interpretation of the TST in a legal context is outside the scope
> of this WG, and will likely vary in different "jurisdictions" around
> the world. Thus if any of these additional data items are relevant,
> they may be relevant only in selected contexts and thus are
> inappropriate as data items in the base standard.  As Paul noted,
> these might be considered as extensions to the base protocol, but it
> would be inappropriate to burden the base protocol with such data.
>
> Steve

Date: Tue, 17 Jun 2003 22:27:07 -0400
To: "Hallam-Baker, Phillip" <[email-masked]>, [email-masked]
From: Stephen Kent <[email-masked]>
Subject: RE: SCEP newest spec
Cc: [email-masked]
Sender: [email-masked]

At 6:59 PM -0700 6/3/03, Hallam-Baker, Phillip wrote:
>That might be the less cynical version.
>
>The more helpful version would be give the URL
>http://www.cisco.com/warp/public/cc/pd/sqsw/tech/scep_wp.htm
>
>The abusive reply would be SWFG, it only took 2 minutes to find on Google. I
>only mention it because I want to claim authorship of the acronym.
>
>If the PKIX group is not interested in documenting current practice then it
>might be useful if the OASIS PKIForum took on the spec. You might also take
>a look at the W3C XKMS specification currently in last call.
>
>	Phill

All IETF WGs have (or should have) as a goal not creating duplicative 
standards. PKIX failed in this regard with CMC vs. CMP (in no small 
part due to the efforts of a fellow VeriSign colleague). SCEP has 
never been submitted to PKIX for consideration, but it is fair to say 
that it would not be endorsed as a third protocol for cert management.

By all means, feel free to bring SCEP to OASIS, a standards body 
where architectural concerns do not seem to interfere with the 
promotion of vendor protocols.

Steve

Date: Tue, 17 Jun 2003 20:44:32 -0400
To: "todd glassey" <[email-masked]>, <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Sender: [email-masked]

Todd,

None of the additions suggested by you are critical to the basic time 
stamping function defined by the RFC. The function of the protocol is 
to deliver a TST in response to a request by a client, to establish 
the existence of the data represented by the contained hash, at the 
point in time that the TST is issued.

The interpretation of the TST in a legal context is outside the scope 
of this WG, and will likely vary in different "jurisdictions" around 
the world. Thus if any of these additional data items are relevant, 
they may be relevant only in selected contexts and thus are 
inappropriate as data items in the base standard.  As Paul noted, 
these might be considered as extensions to the base protocol, but it 
would be inappropriate to burden the base protocol with such data.

Steve

From: "todd glassey" <[email-masked]>
To: "Margus Freudenthal" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>, "Cain, Patrick" <[email-masked]>, <[email-masked]>
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)
Date: Tue, 17 Jun 2003 17:10:01 -0700
Sender: [email-masked]

The problem is that the TS Policy is about the structural policy under which
the TST was fabricated or under which it is to be evaluated and what we are
looking for is a method of having two identical tokens made in the same
system, right next to each other for which one is a "legally enforceable"
record of an event and the other is just a pki-signed TST.

That's why two levels of policy are needed.

Todd

----- Original Message ----- 
From: "Margus Freudenthal" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>; "Cain, Patrick"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 17, 2003 2:08 PM
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside
a specific flag in the TST to represent an official TST?)

>
> On Tue, 17 Jun 2003, todd glassey wrote:
> >
> >                           Remember that the only possible use of a TST
> >is as a receipt. So then it becomes inherently obvious that it is likely
> >that a single TSA will be issuing any number of TST's to their customers
> >under different sets of legal and cultural requirements, and with that as
a
> >realization one has to asks how with the current token would this be
done?
> >
> Pardon my ignorance, but wasn't the time-stamping policy identifier
> invented exactly for this purpose?
>
> If you want to issue several kinds of time stamps, just define several
> policies and use them.
>
> --
> Margus

Date: Tue, 17 Jun 2003 18:01:41 -0400
From: Steve Hanna <[email-masked]>
To: Matt Cooper <[email-masked]>, [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms4EC12D87596C44FBECB03C40
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Matt Cooper wrote:
> > I'm envisioning a future PKI environment where trust is
> > communicated across large and diverse realms that make
> > today's Bridge CA just a drop in the decision tree bucket.

And then I wrote:
> I agree this is a likely future as more PKIs are interconnected.

I should have said that this is a *possible* future. It's not
likely unless we can remove some of the obstacles to PKI
deployment and usage. But it's still important for researchers
to work on these problems so that PKI can scale better.

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

--------------ms4EC12D87596C44FBECB03C40--

Date: Wed, 18 Jun 2003 00:08:13 +0300 (EEST)
From: Margus Freudenthal <[email-masked]>
To: todd glassey <[email-masked]>
cc: Tom Gindin <[email-masked]>, "Cain, Patrick" <[email-masked]>, [email-masked]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)
Sender: [email-masked]

On Tue, 17 Jun 2003, todd glassey wrote:
>
>                           Remember that the only possible use of a TST
>is as a receipt. So then it becomes inherently obvious that it is likely
>that a single TSA will be issuing any number of TST's to their customers
>under different sets of legal and cultural requirements, and with that as a
>realization one has to asks how with the current token would this be done?
>
Pardon my ignorance, but wasn't the time-stamping policy identifier
invented exactly for this purpose?

If you want to issue several kinds of time stamps, just define several
policies and use them.

--
Margus

Date: Tue, 17 Jun 2003 16:31:33 -0400
From: Steve Hanna <[email-masked]>
To: Matt Cooper <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msF3486CF1F706D9276DD478ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Matt Cooper wrote:
> > So I'm not terribly concerned about the size of the
> > builder's decision tree.
> 
> I Strongly Disagree. Reducing the size of the decision tree
> is absolutely instrumental to making path development more
> efficient.

We both agree that the entire decision tree may be too large
to work with. We both agree that builders should prune the
tree as they go by eliminating paths that could never be valid
and use heuristics to decide which paths are most promising.

You would like to have a rule against repeating a (name, key)
pair in a path. I think this can be a heuristic, since I'm
not yet sure that there's no valid reason to want to do this.

I don't think we're so far apart here.

> I'm envisioning a future PKI environment where trust is
> communicated across large and diverse realms that make
> today's Bridge CA just a drop in the decision tree bucket.
> ...
> With the current rule set, users could wait all day and
> not exhaust all possible paths while looking for a valid
> one.

I agree this is a likely future as more PKIs are interconnected.
But adding a rule against repeating a (name, key) pair in a
path will not solve the problem of path building in a huge
environment. It won't even help much. You can always have a
heuristic that steers you away from these paths if you don't
believe they're promising.

What will help in a huge and complex PKI?

* Sending partial paths or, even better, bags of certs
  (as S/MIME and SSL/TLS allow). Ideally, these certs
  should go beyond the EE's trust anchor to include
  other certs linking into relevant trust points.

* Having each side tell the other what its trust anchors
  are (as SSL/TLS allows servers to do). This helps
  determine which trust points are relevant.

* Using delegated path discovery so that the DPD servers can
  build and use knowledge across many queries.

* And, of course, validating as you build to prune out
  paths that could never be valid. And using heuristics
  to steer you toward paths that look promising. Including
  name constraints and policy constraints in certs helps
  heuristics find their way.

Other ideas, anyone?

> The number of nodes in the decision tree a builder visits
> depends on the design of the builder. Or, in the case of no
> valid path existing, it visits every reachable node.

In a large environment, it isn't feasible to try every
possible path. That could take days. And if certs are
issued rapidly enough, it could simply never end. At a
certain point, you (or maybe the user) must just say
"Enough!" and stop looking. Builders need to provide
for this.

Let's return to the question of whether the proposed rule
against repeating a (name, key) pair in a path has a net
benefit. The downside as I see it is increased complexity
in the validation algorithm and less flexibility for the
CA operator. And the upside? We're not plugging a security
hole here. The main advantage is that builders can knock
out those paths as invalid. But builders could accomplish
almost the same thing by just rating them as unpromising
in their heuristic.

I'd say you should take your case to the ISO/ITU X.509 group.
If they are convinced, then the PKIX working group can
follow suit. But I don't think this is not a sufficiently
convincing argument that PKIX should break new ground
and jump out ahead of ISO/ITU, especially when we're trying
to take RFC 3280 to Draft Standard. The fewer changes,
the better.

Thanks,

Steve

P.S. Thanks for an intelligent discussion.
--------------msF3486CF1F706D9276DD478ED
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

--------------msF3486CF1F706D9276DD478ED--

To: "todd glassey" <[email-masked]>
Cc: [email-masked], "Cain, Patrick" <[email-masked]>
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)
From: Tom Gindin <[email-masked]>
Date: Tue, 17 Jun 2003 14:24:43 -0400
Sender: [email-masked]

        Responses below.  I'm not recommending a private extension, but a 
standard published one.  I don't think this belongs in pr-tsa.

                Tom Gindin

"todd glassey" <[email-masked]>
06/17/2003 01:48 PM

        To:     Tom Gindin/Watson/IBM@IBMUS, "Cain, Patrick" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a 
specific flag in the TST to represent an official TST?)

Tom and Pat (and all TST fans out there in PKIX land) -

I agree that with the contention over the NR bit that any issues that 
impact
the use of the TST in commercial instances are a problem. But my concerns
for this are simple, and that is from a governance or commercial
applications process, I think. Remember that the only possible use of a 
TST
is as a receipt. So then it becomes inherently obvious that it is likely
that a single TSA will be issuing any number of TST's to their customers
under different sets of legal and cultural requirements, and with that as 
a
realization one has to asks how with the current token would this be done?

[TG]    It's not the only possible use, but it is an important one.  Proof 
that a digital object has not been modified is not a receipt.

You are right that we could force each and very user to come up with their
own interpretation and system, since he extensions  but is that a good 
idea?

[TG]    We need a standard extension, profiled in son-of-3161 (if any) or 
a separate informational RFC.  Private extensions are not very 
interoperable.

For instance one could argue that the extensions and their use are 
something
for a BCP, but since these really are what make the token usable in the
first place I think that its uses are too limited without these defined as
at least optional in nature, that we will not succeed in getting 3161
ubiquitously integrated in eBusiness and eGovernment processes.

With that said, I would support the addition of a small section to the RFC
to address this or an additional SonOf RFC3161 being done that uses this.

BTW - I know this group is winding down but as part of this specific 
effort
I would also encourage this group to also look at creating an ORACLE
Compliant API for use of these services in the 11i and subsequent
applications packages.

Todd

----- Original Message ----- 
From: "Tom Gindin" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 17, 2003 6:59 AM
Subject: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a
specific flag in the TST to represent an official TST?)

>
>         Todd:
>
>         Shouldn't this be an extension?  It seems to me that the 
extension
> facility was included in both TimeStampReq and TSTInfo for just this 
sort
> of thing.  If you use an extension, since it's characterized by an OID,
> you don't need a version number.  Thus the ASN.1 of the request form is
> just SEQUENCE OF JurisdictionID, with
> JurisdictionID ::= CHOICE {
>         iso3166         PRINTABLE STRING,
>         statuteID       OBJECT IDENTIFIER
> }
>         The response is another extension with the same syntax.
>         Legal evidence is not the only reason for a TSA, but it's
> certainly a potentially important one.
>
>                         Tom Gindin
>
>
>
>
>
> "todd glassey" <[email-masked]>
> Sent by: [email-masked]
> 06/15/2003 09:09 PM
>
>
>         To:     "Paul Hoffman / IMC" <[email-masked]>
>         cc:     <[email-masked]>
>         Subject:        Re: gentlemen... can we set aside a specific 
flag
in the TST to represent
> an official TST?
>
>
>
>
> Paul, thanks for answering. Considering my "persona non grata" status I
> figured I would ask the general question first.
>
> The problem is this - How when you use an RFC3161 token to mark
> (memorialize) an event do you ascribe jurisdiction or the specific piece
> of
> "commercial policy" or legislative process you want to invoke with it?
>
> The general solution I think it to add an OID of some kind to represent
> each
> Digital Signature Act such that you can reference inside of the TST 
policy
> models. The intent is to make the token more usable by incorporating
> features into it that allow Business to more readily use it. The issue 
of
> Jurisdictional notice is an issue.  But some flag also needs to be added
> to
> the request too then
>
> Also there is a concept that there are instances where I would want to
> invoke some form of legal coverage on this TST request and not that one,
> so
> how do I differentiate them? The answer I think is that the TST's need 
to
> allow for one to switch on a request to make a TST under eSign for
> instance
> and others under no legislative cover.
>
> So what I was looking initially for was a single bit we could all agree 
on
> that would be interpreted to have an official status to the TST.  But 
that
> likely wont work under further review. So how about an OID in the 
request
> packet and response packet to indicate that this TOKEN was requested and
> signed with a Local Legal Standard brought into play:
>
>    A time-stamping request is as follows:
>
> TimeStampReq ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    messageImprint               MessageImprint,
>      --a hash algorithm OID and the hash value of the data to be
>      --time-stamped
>    reqPolicy             TSAPolicyId              OPTIONAL,
>    nonce                 INTEGER                  OPTIONAL,
>    certReq               BOOLEAN                  DEFAULT FALSE,
>    officialReq           BOOLEAN                  DEFAULT FALSE,
>       -- Setting OfficialReq to TRUE causes the local digital signature
> act
> to be invoked
>       -- marking this event as a legally enforceable one (whatever that
> means).
>    extensions            [0] IMPLICIT Extensions  OPTIONAL  }
>
>
> the other possibility is this:
>
> TimeStampReq ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    messageImprint               MessageImprint,
>      --a hash algorithm OID and the hash value of the data to be
>      --time-stamped
>    reqPolicy             TSAPolicyId              OPTIONAL,
>    nonce                 INTEGER                  OPTIONAL,
>    certReq               BOOLEAN                  DEFAULT FALSE,
>    officialReq          requestTerms                  OPTIONAL,
>       -- requestTerms are a structure defining the three types or
>       -- jurisdictional requirements for this TSA.
>    extensions            [0] IMPLICIT Extensions  OPTIONAL  }
>
> requestTerms ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    requestJurisdiction     jurisdictionOIDs,
>      -- Standard ISO 3166-1 Country and City Codes,
>      -- and/or possibly ISO/IEC 7501-1 codes,
>      -- or OIDS registered to represent the specific
>      -- law's under which this token was built
> }
>
> The intent is to include a list of the requested "jurisdictions" or
> specific
> digital signature acts under which this TST was fabricated. This is a
> valuable extension to making the TST's more useful.
>
> So here then is a possible response TST:
>
> TSTInfo ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    policy                       TSAPolicyId,
>    messageImprint               MessageImprint,
>      -- MUST have the same value as the similar field in
>      -- TimeStampReq
>    serialNumber                 INTEGER,
>     -- Time-Stamping users MUST be ready to accommodate integers
>     -- up to 160 bits.
>    genTime                      GeneralizedTime,
>    accuracy                     Accuracy                 OPTIONAL,
>    ordering                     BOOLEAN             DEFAULT FALSE,
>    nonce                        INTEGER                  OPTIONAL,
>      -- MUST be present if the similar field was present
>      -- in TimeStampReq.  In that case it MUST have the same value.
>    officialStatus             StatusResponse           OPTIONAL,
>      --a jurisdiction OID as per ISO location country codes of the TSA,
>      -- these can be State and Country Codes, Country Codes, or OID
>      -- Structures built to represent the actual specific piece of
> legislation
>      -- that the parties agree to (ISO 3166-1 et al).
>    tsa                          [0] GeneralName          OPTIONAL,
>    extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
>
> There are probably any number of other ways to do this, and I am open to
> all
> of them so if anyone has any other ideas, lets hear them, but the goal 
is
> to
> find someway of indicating inside the token "under what terms it was
> created" and I am not referring to just the mechanical policy under 
which
> its creation was negotiated.
>
> The vision behind this is that a global TSA could very probably operate
> any
> number of International Timing Services inside the same TSA, and as such
> could be creating TST's for clients under any number of legal 
"agreements"
> or criteria. The question is, inside the TSA or other services how you
> tell
> one token's legal ramifications from another. My feeling is that these
> will
> be key features in any commercial TSA moving forward and if we are to
> resolve the issues with 3161's then these are things that need to happen
> to
> it IMHO.
>
>
> Todd Glassey
>
>
> ----- Original Message ----- 
> From: "Paul Hoffman / IMC" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, June 15, 2003 1:26 PM
> Subject: Re: gentlemen... can we set aside a specific flag in the TST to
> represent an official TST?
>
>
> >
> > At 1:27 PM -0700 6/14/03, todd glassey wrote:
> > >I want to specify a flag as an attribute that specifies that this TST
> was
> > >created under the local DSA of the jurisdiction it was done in. For
> instance
> > >I want an official eSign flag in the TST.
> > >
> > >Anyone have a problem with this?,
> >
> > Yes: it's not specific enough. Please show the exact changes to the
> > ASN.1 you propose.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
>
>
>

From: "todd glassey" <[email-masked]>
To: "Tom Gindin" <[email-masked]>, "Cain, Patrick" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)
Date: Tue, 17 Jun 2003 10:48:57 -0700
Sender: [email-masked]

Tom and Pat (and all TST fans out there in PKIX land) -

I agree that with the contention over the NR bit that any issues that impact
the use of the TST in commercial instances are a problem. But my concerns
for this are simple, and that is from a governance or commercial
applications process, I think. Remember that the only possible use of a TST
is as a receipt. So then it becomes inherently obvious that it is likely
that a single TSA will be issuing any number of TST's to their customers
under different sets of legal and cultural requirements, and with that as a
realization one has to asks how with the current token would this be done?

You are right that we could force each and very user to come up with their
own interpretation and system, since he extensions  but is that a good idea?

For instance one could argue that the extensions and their use are something
for a BCP, but since these really are what make the token usable in the
first place I think that its uses are too limited without these defined as
at least optional in nature, that we will not succeed in getting 3161
ubiquitously integrated in eBusiness and eGovernment processes.

With that said, I would support the addition of a small section to the RFC
to address this or an additional SonOf RFC3161 being done that uses this.

BTW - I know this group is winding down but as part of this specific effort
I would also encourage this group to also look at creating an ORACLE
Compliant API for use of these services in the 11i and subsequent
applications packages.

Todd

----- Original Message ----- 
From: "Tom Gindin" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 17, 2003 6:59 AM
Subject: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a
specific flag in the TST to represent an official TST?)

>
>         Todd:
>
>         Shouldn't this be an extension?  It seems to me that the extension
> facility was included in both TimeStampReq and TSTInfo for just this sort
> of thing.  If you use an extension, since it's characterized by an OID,
> you don't need a version number.  Thus the ASN.1 of the request form is
> just SEQUENCE OF JurisdictionID, with
> JurisdictionID ::= CHOICE {
>         iso3166         PRINTABLE STRING,
>         statuteID       OBJECT IDENTIFIER
> }
>         The response is another extension with the same syntax.
>         Legal evidence is not the only reason for a TSA, but it's
> certainly a potentially important one.
>
>                         Tom Gindin
>
>
>
>
>
> "todd glassey" <[email-masked]>
> Sent by: [email-masked]
> 06/15/2003 09:09 PM
>
>
>         To:     "Paul Hoffman / IMC" <[email-masked]>
>         cc:     <[email-masked]>
>         Subject:        Re: gentlemen... can we set aside a specific flag
in the TST to represent
> an official TST?
>
>
>
>
> Paul, thanks for answering. Considering my "persona non grata" status I
> figured I would ask the general question first.
>
> The problem is this - How when you use an RFC3161 token to mark
> (memorialize) an event do you ascribe jurisdiction or the specific piece
> of
> "commercial policy" or legislative process you want to invoke with it?
>
> The general solution I think it to add an OID of some kind to represent
> each
> Digital Signature Act such that you can reference inside of the TST policy
> models. The intent is to make the token more usable by incorporating
> features into it that allow Business to more readily use it. The issue of
> Jurisdictional notice is an issue.  But some flag also needs to be added
> to
> the request too then
>
> Also there is a concept that there are instances where I would want to
> invoke some form of legal coverage on this TST request and not that  one,
> so
> how do I differentiate them? The answer I think is that the TST's need to
> allow for one to switch on a request to make a TST under eSign for
> instance
> and others under no legislative cover.
>
> So what I was looking initially for was a single bit we could all agree on
> that would be interpreted to have an official status to the TST.  But that
> likely wont work under further review. So how about an OID in the request
> packet and response packet to indicate that this TOKEN was requested and
> signed with a Local Legal Standard brought into play:
>
>    A time-stamping request is as follows:
>
> TimeStampReq ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    messageImprint               MessageImprint,
>      --a hash algorithm OID and the hash value of the data to be
>      --time-stamped
>    reqPolicy             TSAPolicyId              OPTIONAL,
>    nonce                 INTEGER                  OPTIONAL,
>    certReq               BOOLEAN                  DEFAULT FALSE,
>    officialReq           BOOLEAN                  DEFAULT FALSE,
>       -- Setting OfficialReq to TRUE causes the local digital signature
> act
> to be invoked
>       -- marking this event as a legally enforceable one (whatever that
> means).
>    extensions            [0] IMPLICIT Extensions  OPTIONAL  }
>
>
> the other possibility is this:
>
> TimeStampReq ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    messageImprint               MessageImprint,
>      --a hash algorithm OID and the hash value of the data to be
>      --time-stamped
>    reqPolicy             TSAPolicyId              OPTIONAL,
>    nonce                 INTEGER                  OPTIONAL,
>    certReq               BOOLEAN                  DEFAULT FALSE,
>    officialReq          requestTerms                  OPTIONAL,
>       -- requestTerms are a structure defining the three types or
>       -- jurisdictional requirements for this TSA.
>    extensions            [0] IMPLICIT Extensions  OPTIONAL  }
>
> requestTerms ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    requestJurisdiction     jurisdictionOIDs,
>      -- Standard ISO 3166-1 Country and City Codes,
>      -- and/or possibly ISO/IEC 7501-1 codes,
>      -- or OIDS registered to represent the specific
>      -- law's under which this token was built
> }
>
> The intent is to include a list of the requested "jurisdictions" or
> specific
> digital signature acts under which this TST was fabricated. This is a
> valuable extension to making the TST's more useful.
>
> So here then is a possible response TST:
>
> TSTInfo ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    policy                       TSAPolicyId,
>    messageImprint               MessageImprint,
>      -- MUST have the same value as the similar field in
>      -- TimeStampReq
>    serialNumber                 INTEGER,
>     -- Time-Stamping users MUST be ready to accommodate integers
>     -- up to 160 bits.
>    genTime                      GeneralizedTime,
>    accuracy                     Accuracy                 OPTIONAL,
>    ordering                     BOOLEAN             DEFAULT FALSE,
>    nonce                        INTEGER                  OPTIONAL,
>      -- MUST be present if the similar field was present
>      -- in TimeStampReq.  In that case it MUST have the same value.
>    officialStatus             StatusResponse           OPTIONAL,
>      --a jurisdiction OID as per ISO location country codes of the TSA,
>      -- these can be State and Country Codes, Country Codes, or OID
>      -- Structures built to represent the actual specific piece of
> legislation
>      -- that the parties agree to (ISO 3166-1 et al).
>    tsa                          [0] GeneralName          OPTIONAL,
>    extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
>
> There are probably any number of other ways to do this, and I am open to
> all
> of them so if anyone has any other ideas, lets hear them, but the goal is
> to
> find someway of indicating inside the token "under what terms it was
> created" and I am not referring to just the mechanical policy under which
> its creation was negotiated.
>
> The vision behind this is that a global TSA could very probably operate
> any
> number of International Timing Services inside the same TSA, and as such
> could be creating TST's for clients under any number of legal "agreements"
> or criteria. The question is, inside the TSA or other services how you
> tell
> one token's legal ramifications from another. My feeling is that these
> will
> be key features in any commercial TSA moving forward and if we are to
> resolve the issues with 3161's then these are things that need to happen
> to
> it IMHO.
>
>
> Todd Glassey
>
>
> ----- Original Message ----- 
> From: "Paul Hoffman / IMC" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, June 15, 2003 1:26 PM
> Subject: Re: gentlemen... can we set aside a specific flag in the TST to
> represent an official TST?
>
>
> >
> > At 1:27 PM -0700 6/14/03, todd glassey wrote:
> > >I want to specify a flag as an attribute that specifies that this TST
> was
> > >created under the local DSA of the jurisdiction it was done in. For
> instance
> > >I want an official eSign flag in the TST.
> > >
> > >Anyone have a problem with this?,
> >
> > Yes: it's not specific enough. Please show the exact changes to the
> > ASN.1 you propose.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
>
>
>

To: "todd glassey" <[email-masked]>
Cc: [email-masked]
Subject: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)
From: Tom Gindin <[email-masked]>
Date: Tue, 17 Jun 2003 09:59:55 -0400
Sender: [email-masked]

        Todd:

        Shouldn't this be an extension?  It seems to me that the extension 
facility was included in both TimeStampReq and TSTInfo for just this sort 
of thing.  If you use an extension, since it's characterized by an OID, 
you don't need a version number.  Thus the ASN.1 of the request form is 
just SEQUENCE OF JurisdictionID, with 
JurisdictionID ::= CHOICE {
        iso3166         PRINTABLE STRING,
        statuteID       OBJECT IDENTIFIER
}
        The response is another extension with the same syntax.
        Legal evidence is not the only reason for a TSA, but it's 
certainly a potentially important one.

                        Tom Gindin

"todd glassey" <[email-masked]>
Sent by: [email-masked]
06/15/2003 09:09 PM

        To:     "Paul Hoffman / IMC" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        Re: gentlemen... can we set aside a specific flag in the TST to represent 
an official TST?

Paul, thanks for answering. Considering my "persona non grata" status I
figured I would ask the general question first.

The problem is this - How when you use an RFC3161 token to mark
(memorialize) an event do you ascribe jurisdiction or the specific piece 
of
"commercial policy" or legislative process you want to invoke with it?

The general solution I think it to add an OID of some kind to represent 
each
Digital Signature Act such that you can reference inside of the TST policy
models. The intent is to make the token more usable by incorporating
features into it that allow Business to more readily use it. The issue of
Jurisdictional notice is an issue.  But some flag also needs to be added 
to
the request too then

Also there is a concept that there are instances where I would want to
invoke some form of legal coverage on this TST request and not that  one, 
so
how do I differentiate them? The answer I think is that the TST's need to
allow for one to switch on a request to make a TST under eSign for 
instance
and others under no legislative cover.

So what I was looking initially for was a single bit we could all agree on
that would be interpreted to have an official status to the TST.  But that
likely wont work under further review. So how about an OID in the request
packet and response packet to indicate that this TOKEN was requested and
signed with a Local Legal Standard brought into play:

   A time-stamping request is as follows:

TimeStampReq ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   messageImprint               MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
     --time-stamped
   reqPolicy             TSAPolicyId              OPTIONAL,
   nonce                 INTEGER                  OPTIONAL,
   certReq               BOOLEAN                  DEFAULT FALSE,
   officialReq           BOOLEAN                  DEFAULT FALSE,
      -- Setting OfficialReq to TRUE causes the local digital signature 
act
to be invoked
      -- marking this event as a legally enforceable one (whatever that
means).
   extensions            [0] IMPLICIT Extensions  OPTIONAL  }

the other possibility is this:

TimeStampReq ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   messageImprint               MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
     --time-stamped
   reqPolicy             TSAPolicyId              OPTIONAL,
   nonce                 INTEGER                  OPTIONAL,
   certReq               BOOLEAN                  DEFAULT FALSE,
   officialReq          requestTerms                  OPTIONAL,
      -- requestTerms are a structure defining the three types or
      -- jurisdictional requirements for this TSA.
   extensions            [0] IMPLICIT Extensions  OPTIONAL  }

requestTerms ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   requestJurisdiction     jurisdictionOIDs,
     -- Standard ISO 3166-1 Country and City Codes,
     -- and/or possibly ISO/IEC 7501-1 codes,
     -- or OIDS registered to represent the specific
     -- law's under which this token was built
}

The intent is to include a list of the requested "jurisdictions" or 
specific
digital signature acts under which this TST was fabricated. This is a
valuable extension to making the TST's more useful.

So here then is a possible response TST:

TSTInfo ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   policy                       TSAPolicyId,
   messageImprint               MessageImprint,
     -- MUST have the same value as the similar field in
     -- TimeStampReq
   serialNumber                 INTEGER,
    -- Time-Stamping users MUST be ready to accommodate integers
    -- up to 160 bits.
   genTime                      GeneralizedTime,
   accuracy                     Accuracy                 OPTIONAL,
   ordering                     BOOLEAN             DEFAULT FALSE,
   nonce                        INTEGER                  OPTIONAL,
     -- MUST be present if the similar field was present
     -- in TimeStampReq.  In that case it MUST have the same value.
   officialStatus             StatusResponse           OPTIONAL,
     --a jurisdiction OID as per ISO location country codes of the TSA,
     -- these can be State and Country Codes, Country Codes, or OID
     -- Structures built to represent the actual specific piece of
legislation
     -- that the parties agree to (ISO 3166-1 et al).
   tsa                          [0] GeneralName          OPTIONAL,
   extensions                   [1] IMPLICIT Extensions   OPTIONAL  }

There are probably any number of other ways to do this, and I am open to 
all
of them so if anyone has any other ideas, lets hear them, but the goal is 
to
find someway of indicating inside the token "under what terms it was
created" and I am not referring to just the mechanical policy under which
its creation was negotiated.

The vision behind this is that a global TSA could very probably operate 
any
number of International Timing Services inside the same TSA, and as such
could be creating TST's for clients under any number of legal "agreements"
or criteria. The question is, inside the TSA or other services how you 
tell
one token's legal ramifications from another. My feeling is that these 
will
be key features in any commercial TSA moving forward and if we are to
resolve the issues with 3161's then these are things that need to happen 
to
it IMHO.

Todd Glassey

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, June 15, 2003 1:26 PM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

>
> At 1:27 PM -0700 6/14/03, todd glassey wrote:
> >I want to specify a flag as an attribute that specifies that this TST 
was
> >created under the local DSA of the jurisdiction it was done in. For
instance
> >I want an official eSign flag in the TST.
> >
> >Anyone have a problem with this?,
>
> Yes: it's not specific enough. Please show the exact changes to the
> ASN.1 you propose.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Tue, 17 Jun 2003 15:19:43 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: rfc316: PKIStatus
Sender: [email-masked]

"Al Arsenault" <[email-masked]> writes:

>I'm not sure if that's what the 2510 authors had in mind, but it was the best
>we could figure out at the time.

This is a good summary of quite a bit of 2510 :-).

("WTF??!?" is another version of this that I've heard from some implementors).

Peter.

From: "todd glassey" <[email-masked]>
To: "todd glassey" <[email-masked]>, "Peter Sylvester" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Date: Mon, 16 Jun 2003 18:38:41 -0700
Sender: [email-masked]

The other justification for this would be in having multiple tokens all
generated from the same infrastructure but under differing legal structures
or constraints...

Todd

----- Original Message ----- 
From: "todd glassey" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, June 16, 2003 7:15 AM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

>
> Peter - there are two separate sets of policy that this was never built to
> address. The first is the mechanical policies under which the TST was
> requested and created, as well as its (the TS Client's audit instructions
to
> the back-end).
>
> The OTHER policy that was never addressed in this structure was the
> "Transaction Type" or specific set of policies under which the TST was
> created or to be evaluated. We talked about this a bunch and nothing was
> done with it, and now after the issues of credibility and audit that have
> come to light over the past couple of years, it is now obvious that any
> declarative structure needs to have some internal method of demonstrating
> its bounds.
>
> Todd
>
> ----- Original Message ----- 
> From: "Peter Sylvester" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
> Sent: Monday, June 16, 2003 2:50 AM
> Subject: Re: gentlemen... can we set aside a specific flag in the TST to
> represent an official TST?
>
>
> >
> >
> > Until draft 9 the TSApolicy was PolicyInformation and not just an OID.
> >
> >
> >
> >
>
>

From: "Matt Cooper" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RFC 3280: same certificate in a certification path
Date: Mon, 16 Jun 2003 19:24:48 -0400
Importance: Normal
Sender: [email-masked]

Responses inline:

> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]] 
> Sent: Thursday, June 12, 2003 10:38 AM
> To: Matt Cooper
> Cc: [email-masked]
> Subject: Re: RFC 3280: same certificate in a certification path
> 
> 
> Matt Cooper wrote:
> > The biggest advantage to this rule is when you have a 
> bridge (or any 
> > CA with certs from multiple CAs - such as in a mesh
> > environment) - it prevents multiple passes through the same bridge 
> > point. (Or CA.) This eliminates unnecessary and unintended 
> paths and 
> > can also very significantly reduce the size of the 
> builder's decision 
> > tree.
> 
> In many real-world PKIs, the builder's complete decision tree 
> is impossibly large. And determining that tree requires 
> fetching all the certificates in the PKI, which is not 
> feasible. 

Agreed. I wasn't advocating any approach that requires you to retrieve every
certificate. The point is, the decision tree looms out in the darkness in
front of the builder. The number of nodes in the decision tree a builder
visits depends on the design of the builder. Or, in the case of no valid
path existing, it visits every reachable node. By choosing to never traverse
certain branches, the builder eliminates an unknown, but possibly quite
large, number of nodes from the tree.

> So I'm not terribly concerned about the size of the 
> builder's decision tree.

I Strongly Disagree. Reducing the size of the decision tree is absolutely
instrumental to making path development more efficient. You can not
guarantee that any set of heuristics will consistently guide path
development in the desirable direction every time, so the less choices that
exist, the better off you are. (And that is not to say that optimizing
heuristics are not instrumental as well.)

Think of the simple ways to improve path building. What would you call a
simple "validate validity period while you build" approach if it is not a
way to limit the size of the decision tree? Such an approach lops whole
branches from the tree when it realizes that traversing a particular branch
is of no value because the validity period is out of range. What I am
proposing does the same thing but using a different condition for the
pruning.

> A more reasonable solution to path building is one that uses
> a tree search algorithm that works with partial knowledge of 
> the tree, using heuristics to decide which branches to 
> pursue.

Yes. Absolutely agree!

> If the builder uses such an algorithm, the example 
> you gave below is quickly and easily solved. Assuming you're 
> building forward (from EE to Z), you will find the answer as 
> soon as you get to the Bridge CA.

Again, spot on!

> I expect there are examples that can show some benefit to 
> prohibiting paths that include two certs with the same 
> (subject DN, subject public key) pair.

Yes, how about when the cert between Z and the Bridge is expired? Your
builder now has to traverse every possible path in the graph (there are
quite a few, especially if you want to hang a couple mesh PKIs off that
bridge as well) before concluding no path can be found.

> But I doubt that the 
> benefit will be substantial (assuming that a decent path 
> building algorithm is used). 

I agree until such time as no valid path exists. Or if the graph eliminated
simple leaps from the bridge to your destination. (For example, if you were
building from EE to F [add the cross cert from F to W]) It is possible
(though not likely given the diagram) that no hint would exist to guide the
builder to W from the Bridge. The builder may now run off on a tangent
building some convoluted paths through the other CA's in the example. Even
more fun is if the F->W cert were invalid for some reason.

> And I'm not yet convinced that 
> there is no reasonable use for such a path.

Like you, I am also not convinced. I always have some doubt remaining on
this topic. However, no one has yet presented me a necessary use case.
(Perhaps today someone will!)

> In general, I'd rather not make rules that tell people
> how they MUST set up their PKIs unless there's a very
> good reason to do so.

With the ideal I agree, but I believe in this case the benefit outweighs it.
Especially given the lack of examples in which such a rule would break
something. When I'm thinking about building paths and trying to find the
valid path that doesn't exist, I'm envisioning a future PKI environment
where trust is communicated across large and diverse realms that make
today's Bridge CA just a drop in the decision tree bucket. In my mind, the
current thinking of only prohibiting the repetition of certificates is not
sufficient when looking forward to that kind of environment. If just a dozen
certs can yield hundreds and hundreds of paths, what about hundreds, or even
pie-in-the-sky thousands of certs? Thousands of corporate and government
PKIs linked together with bridges? With the current rule set, users could
wait all day and not exhaust all possible paths while looking for a valid
one.

-Matt

> -Steve
> 
> ------------
> 
> >          +---+    +---+
> >          | F |--->| H |
> >          +---+    +---+
> >           ^ ^       ^
> >           |  \       \
> >           |   \       \
> >           |    v       v
> >           |  +---+    +---+
> >           |  | G |--->| I |
> >           |  +---+    +---+
> >           |   ^
> >           |  /
> >           | /
> >       +------+       +-----------+        +------+   +---+   +---+
> >       | TR W |<----->| Bridge CA |<------>| TR X |-->| L |-->| M |
> >       +------+       +-----------+        +------+   +---+   +---+
> >                         ^      ^               \        \
> >                        /        \               \        \
> >                       /          \               \        \
> >                      v            v               v        v
> >                +------+         +------+        +---+    +---+
> >                | TR Y |         | TR Z |        | J |    | N |
> >                +------+         +------+        +---+    +---+
> >                 ^   ^              / \            |        |
> >                /     \            /   \           |        |
> >               /       \          /     \          v        v
> >              v         v        v       v       +---+    +----+
> >            +---+     +---+    +---+   +---+     | K |    | EE |
> >            | A |<--->| C |    | O |   | P |     +---+    +----+
> >            +---+     +---+    +---+   +---+
> >              \         /      /  \       \
> >               \       /      /    \       \
> >                \     /      v      v       v
> >                 v   v    +---+    +---+   +---+
> >                 +---+    | Q |    | R |   | S |
> >                 | B |    +---+    +---+   +---+
> >                 +---+               |
> >                   /\                |
> >                  /  \               |
> >                 v    v              v
> >              +---+  +---+         +---+
> >              | E |  | D |         | T |
> >              +---+  +---+         +---+
> 

From: "todd glassey" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Date: Mon, 16 Jun 2003 07:15:53 -0700
Sender: [email-masked]

Peter - there are two separate sets of policy that this was never built to
address. The first is the mechanical policies under which the TST was
requested and created, as well as its (the TS Client's audit instructions to
the back-end).

The OTHER policy that was never addressed in this structure was the
"Transaction Type" or specific set of policies under which the TST was
created or to be evaluated. We talked about this a bunch and nothing was
done with it, and now after the issues of credibility and audit that have
come to light over the past couple of years, it is now obvious that any
declarative structure needs to have some internal method of demonstrating
its bounds.

Todd

----- Original Message ----- 
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, June 16, 2003 2:50 AM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

>
>
> Until draft 9 the TSApolicy was PolicyInformation and not just an OID.
>
>
>
>

From: "Al Arsenault" <[email-masked]>
To: "Massimiliano Pala" <[email-masked]>, "Peter Sylvester" <[email-masked]>, <[email-masked]>
Subject: Re: rfc316: PKIStatus
Date: Mon, 16 Jun 2003 08:23:51 -0400
Sender: [email-masked]

Massimiliano,

The only time I ever played around with those status values was in a
previous life, implementing a pilot system for a customer who:

a - insisted on using CRLs for revocation information (actually supplemented
by OCSP, but the CRLs still had to be issued once per 24 hours); and

b - had an investigation procedure, whereby if you requested that a
certificate be revoked, e.g., because of key compromise, they wouldn't
revoke it immediately.  To defend against certain denial of service attacks
("please immediately revoke all certificates in the large-company PKI; all
the private keys are compromised"), they'd investigate to see if they should
really revoke.  So you had a gap.

For that company, we'd use code 4 to indicate either (a) the certificate had
been revoked, but hadn't yet appeared on a CRL; or (b) it was under
investigation, but hadn't been decided yet.

As for WHICH certificate, it depended on what type of message the PKIStatus
was being sent in response to.

Now, for (a) we could have used reason 5 instead of 4. And we had some
questions about whether 4 was really appropriate for (b). (How do you KNOW
that the revocation is imminent - are you guessing about the outcome of the
investigation?) We argued about it for a while. Then we gave up and ust used
reason code 2 for all rejections, and put whatever other information we
wanted the requester to know about in the message.

I'm not sure if that's what the 2510 authors had in mind, but it was the
best we could figure out at the time.

>From personal experience, unless you have a real reason to use 4, 5, etc.;
I'd recommend that you just stick to reason code 2 for all rejections.

                Al Arsenault

----- Original Message -----
From: "Massimiliano Pala" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>; <[email-masked]>
Sent: Friday, June 13, 2003 7:07 AM
Subject: Re: rfc316: PKIStatus

> Peter Sylvester wrote:
>
> >>PKIStatusInfo is defined in Section 3.2.3 of [RFC2510]. A valid time
> >>stamp token will always have value 0 (granted) in the PKIStatus field of
> >>PKIStatusInfo.  If the PKIStatus field has value `waiting' (3), then
> >>this token is a receipt, as defined in Section 2.1.  Otherwise, the
> >>status field is present to indicate whether or not the time stamping
> >>request was fulfilled and, if not, the reason it was rejected. Since not
> >>all environments will require the use of receipts, support for the value
> >>`waiting' is OPTIONAL.
> >
> >
> > I cannot remember any discussion for having other values than 0 and 2
> > except maybe 1.
>
> Thanks for the answer, so if I got all the pieces I can simply just not
> care about other vaules >2 ? Usually when I get PKIStatus <> 0 there
> has been an error... so something whent wrong and the answer is to be
> rejected, right ?
>
> Anyway I would like to know, if anyone can remember, the meaning of the:
>
>        revocationWarning      (4),
>        -- this message contains a warning that a revocation is
>        -- imminent
>
> as I'd like to know what this is meant to mean :-D (if I receive a message
> with this PKIStatus what am I supposed to do? what to say to the user ?
> what action(s) should be taken?).
>
> I am a little bit confused about it :-D Thanks for any help.
>
> --
>
> C'you,
>
> Massimiliano Pala
>
> --o-----------------------------------------------------------------------
--
> Massimiliano Pala [OpenCA Project Manager]
[email-masked]
>                                                   Tel.:   +39 (0)59  270
094
> http://www.openca.org                            Fax:    +39   178  221
8225
> http://openca.sourceforge.net                    Mobile: +39 (0)347 7222
365

Date: Mon, 16 Jun 2003 11:50:27 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Sender: [email-masked]

Until draft 9 the TSApolicy was PolicyInformation and not just an OID.

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Date: Sun, 15 Jun 2003 19:19:48 -0700
Sender: [email-masked]

Paul - for the US we also for establishing the selected jurisdiction would
need  to probably include some way of noting the FIPS 5-2 State Name's as
well as the US ISO Country Codes. Germany, the former Soviet Republic,
China, Japan and others will want the same type of granularity so they also
can specify a specific jurisdictional location. We could easily bundle the
legal declaration type into this as well.

Location::    SEQUENCE {
    countryName    ISO-3166-1,
    stateName        stateNameTypes    OPTIONAL,
    -- where stateName can be a FIPS 5-2 or
    -- other 2 ASCII character state name
    legalStatus        lawOID    OPTIONAL,
   -- where lawOID is a registered OID or PENOID
   -- representing the legal constraints under which
   -- this token is issued.
}

Todd

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, June 15, 2003 1:26 PM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

>
> At 1:27 PM -0700 6/14/03, todd glassey wrote:
> >I want to specify a flag as an attribute that specifies that this TST was
> >created under the local DSA of the jurisdiction it was done in. For
instance
> >I want an official eSign flag in the TST.
> >
> >Anyone have a problem with this?,
>
> Yes: it's not specific enough. Please show the exact changes to the
> ASN.1 you propose.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: "todd glassey" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Date: Sun, 15 Jun 2003 18:09:42 -0700
Sender: [email-masked]

Paul, thanks for answering. Considering my "persona non grata" status I
figured I would ask the general question first.

The problem is this - How when you use an RFC3161 token to mark
(memorialize) an event do you ascribe jurisdiction or the specific piece of
"commercial policy" or legislative process you want to invoke with it?

The general solution I think it to add an OID of some kind to represent each
Digital Signature Act such that you can reference inside of the TST policy
models. The intent is to make the token more usable by incorporating
features into it that allow Business to more readily use it. The issue of
Jurisdictional notice is an issue.  But some flag also needs to be added to
the request too then

Also there is a concept that there are instances where I would want to
invoke some form of legal coverage on this TST request and not that  one, so
how do I differentiate them? The answer I think is that the TST's need to
allow for one to switch on a request to make a TST under eSign for instance
and others under no legislative cover.

So what I was looking initially for was a single bit we could all agree on
that would be interpreted to have an official status to the TST.  But that
likely wont work under further review. So how about an OID in the request
packet and response packet to indicate that this TOKEN was requested and
signed with a Local Legal Standard brought into play:

   A time-stamping request is as follows:

TimeStampReq ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   messageImprint               MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
     --time-stamped
   reqPolicy             TSAPolicyId              OPTIONAL,
   nonce                 INTEGER                  OPTIONAL,
   certReq               BOOLEAN                  DEFAULT FALSE,
   officialReq           BOOLEAN                  DEFAULT FALSE,
      -- Setting OfficialReq to TRUE causes the local digital signature act
to be invoked
      -- marking this event as a legally enforceable one (whatever that
means).
   extensions            [0] IMPLICIT Extensions  OPTIONAL  }

the other possibility is this:

TimeStampReq ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   messageImprint               MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
     --time-stamped
   reqPolicy             TSAPolicyId              OPTIONAL,
   nonce                 INTEGER                  OPTIONAL,
   certReq               BOOLEAN                  DEFAULT FALSE,
   officialReq          requestTerms                  OPTIONAL,
      -- requestTerms are a structure defining the three types or
      -- jurisdictional requirements for this TSA.
   extensions            [0] IMPLICIT Extensions  OPTIONAL  }

requestTerms ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   requestJurisdiction     jurisdictionOIDs,
     -- Standard ISO 3166-1 Country and City Codes,
     -- and/or possibly ISO/IEC 7501-1 codes,
     -- or OIDS registered to represent the specific
     -- law's under which this token was built
}

The intent is to include a list of the requested "jurisdictions" or specific
digital signature acts under which this TST was fabricated. This is a
valuable extension to making the TST's more useful.

So here then is a possible response TST:

TSTInfo ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   policy                       TSAPolicyId,
   messageImprint               MessageImprint,
     -- MUST have the same value as the similar field in
     -- TimeStampReq
   serialNumber                 INTEGER,
    -- Time-Stamping users MUST be ready to accommodate integers
    -- up to 160 bits.
   genTime                      GeneralizedTime,
   accuracy                     Accuracy                 OPTIONAL,
   ordering                     BOOLEAN             DEFAULT FALSE,
   nonce                        INTEGER                  OPTIONAL,
     -- MUST be present if the similar field was present
     -- in TimeStampReq.  In that case it MUST have the same value.
   officialStatus             StatusResponse           OPTIONAL,
     --a jurisdiction OID as per ISO location country codes of the TSA,
     -- these can be State and Country Codes, Country Codes, or OID
     -- Structures built to represent the actual specific piece of
legislation
     -- that the parties agree to (ISO 3166-1 et al).
   tsa                          [0] GeneralName          OPTIONAL,
   extensions                   [1] IMPLICIT Extensions   OPTIONAL  }

There are probably any number of other ways to do this, and I am open to all
of them so if anyone has any other ideas, lets hear them, but the goal is to
find someway of indicating inside the token "under what terms it was
created" and I am not referring to just the mechanical policy under which
its creation was negotiated.

The vision behind this is that a global TSA could very probably operate any
number of International Timing Services inside the same TSA, and as such
could be creating TST's for clients under any number of legal "agreements"
or criteria. The question is, inside the TSA or other services how you tell
one token's legal ramifications from another. My feeling is that these will
be key features in any commercial TSA moving forward and if we are to
resolve the issues with 3161's then these are things that need to happen to
it IMHO.

Todd Glassey

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, June 15, 2003 1:26 PM
Subject: Re: gentlemen... can we set aside a specific flag in the TST to
represent an official TST?

>
> At 1:27 PM -0700 6/14/03, todd glassey wrote:
> >I want to specify a flag as an attribute that specifies that this TST was
> >created under the local DSA of the jurisdiction it was done in. For
instance
> >I want an official eSign flag in the TST.
> >
> >Anyone have a problem with this?,
>
> Yes: it's not specific enough. Please show the exact changes to the
> ASN.1 you propose.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Sun, 15 Jun 2003 13:26:44 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Sender: [email-masked]

At 1:27 PM -0700 6/14/03, todd glassey wrote:
>I want to specify a flag as an attribute that specifies that this TST was
>created under the local DSA of the jurisdiction it was done in. For instance
>I want an official eSign flag in the TST.
>
>Anyone have a problem with this?,

Yes: it's not specific enough. Please show the exact changes to the 
ASN.1 you propose.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "todd glassey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
Subject: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Date: Sat, 14 Jun 2003 13:27:33 -0700
Sender: [email-masked]

I want to specify a flag as an attribute that specifies that this TST was
created under the local DSA of the jurisdiction it was done in. For instance
I want an official eSign flag in the TST.

Anyone have a problem with this?, other than it is me suggesting it?

Todd

Date: Fri, 13 Jun 2003 13:07:23 +0200
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
To: Peter Sylvester <[email-masked]>, [email-masked]
Subject: Re: rfc316: PKIStatus
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010208070807000406000102
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:

>>PKIStatusInfo is defined in Section 3.2.3 of [RFC2510]. A valid time 
>>stamp token will always have value 0 (granted) in the PKIStatus field of 
>>PKIStatusInfo.  If the PKIStatus field has value `waiting' (3), then 
>>this token is a receipt, as defined in Section 2.1.  Otherwise, the 
>>status field is present to indicate whether or not the time stamping 
>>request was fulfilled and, if not, the reason it was rejected. Since not 
>>all environments will require the use of receipts, support for the value 
>>`waiting' is OPTIONAL.
> 
> 
> I cannot remember any discussion for having other values than 0 and 2
> except maybe 1. 

Thanks for the answer, so if I got all the pieces I can simply just not
care about other vaules >2 ? Usually when I get PKIStatus <> 0 there
has been an error... so something whent wrong and the answer is to be
rejected, right ?

Anyway I would like to know, if anyone can remember, the meaning of the:

       revocationWarning      (4),
       -- this message contains a warning that a revocation is
       -- imminent

as I'd like to know what this is meant to mean :-D (if I receive a message
with this PKIStatus what am I supposed to do? what to say to the user ?
what action(s) should be taken?).

I am a little bit confused about it :-D Thanks for any help.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [email-masked]
                                                  Tel.:   +39 (0)59  270  094
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

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

--------------ms010208070807000406000102--

From: [email-masked]
To: [email-masked]
Date: Fri, 13 Jun 2003 09:43:03 +0000
Subject: Re: Fw: PKI "not working"
Sender: [email-masked]

"Not working" is a bit too broad. It is working in limited deployments but
in that the mechanism that makes it truly global (publicly accessible
directory) is missing it has yet to fulfil its potential.

I must admit I get as frustrated with the anti-hype as much as I do the
hype. I imagine both are put about by people who don't really understand
just how much has to be accomplished before it will all work as envisaged.

I will continue to be an optimist until someone gives me a darn good
reason as to why it cannot be done  :-)

Apologies for the top post

Chris

|--------+------------------------------->
|        |          "todd glassey"       |
|        |          <todd.glassey@worldne|
|        |          t.att.net>           |
|        |          Sent by:             |
|        |          owner-ietf-pkix@mail.|
|        |          imc.org              |
|        |                               |
|        |                               |
|        |          12/06/2003 14:28     |
|        |                               |
|--------+------------------------------->
  >-------------------------------------------------------------------------------|
  |                                                                               |
  |       To:     <[email-masked]>, "el-sign: electronic signatures - open     |
  |       discussion" <[email-masked]>                                     |
  |       cc:                                                                     |
  |       Subject:     Fw: PKI "not working"                                      |
  >-------------------------------------------------------------------------------|

This is a cross posting from the ISC's mailing lists of the Bar Association.

Why it is important here is that it documents perceived problems in the PKI
marketplace and I perceive that a number of these issues are failures in the
IETF's and potentially the ETSI standards processes, since they allow
processes that are at best incomplete from a deployment stance to be
elevated into standards status IMHO.

My concern is that the value of the IETF and ETSI is growing less and less
with these types of realizations in the marketplace.

Todd

To: <[email-masked]>
Sent: Thursday, June 12, 2003 7:00 AM
Subject: UK: PKI "not working"

> PKI is 'not working'
>
> Inadequate technology for online transactions is a 'huge problem' for
those
> in charge of e-government, admits a leading Whitehall official The
e-envoy's
> office has started searching for new ways to authenticate the users of
> e-services as the existing technology being used is "not working", a
senior
> Government official revealed on 11 June 2003. Although PKI (public key
> infrastructure) and digital certificate technology has played a major role
> in leading projects such as the Government Gateway, there is now growing
> recognition that it is unsuited for wider public use. While digital
> certificates would not be scrapped, and would be retained as an option for
> e-service users, one possible alternative being suggested is that
employers,
> banks, the voluntary sector and other "trusted organisations" would verify
a
> person's identity before transacting online for services. Speaking on
> condition of anonymity, the official said the Government is now looking at
> "radical ways" of solving the authentication problem. "Trust and
> authentication has been a huge problem for us. We haven't got a solution
for
> authentication. We've been trying with PKI for about 10 years now and its
> not working because it's a pain to implement and to use. We've been
looking
> to take the pain out of PKI. "What we are saying with authentication is
that
> if another trusted organisation such as a bank can provide proof saying
you
> are who you say you are that should take the need away for digital
> certificates." The move comes as the e-envoy's office is acutely aware
that
> it needs to step up the pace of e-government leading up to the 2005
target.
http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?Op
> enDocument
<http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?O
> penDocument>
>
> Michael Power
>
> Partner & Chief Privacy Officer
> Gowling Lafleur Henderson LLP
> Barristers & Solicitors
> Patent & Trade Mark Agents
> Suite 2600
> 160 Elgin Street
> Ottawa, Ontario, CANADA
> K1P 1C3
>
>
>

Subject: Re: Fw: PKI "not working"
To: "todd glassey" <[email-masked]>
Cc: "el-sign: electronic signatures - open discussion" <[email-masked]>, [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 12 Jun 2003 12:07:44 -0600
Sender: [email-masked]

something similar in threads on https (and other online) failings from the
cryptography mailing list
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates and an alternative
view

http://www.garlic.com/~lynn/aadsm14.htm#5 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#9 "Marginot Web" (SSL, payments,
etc)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way
Down
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#34 virus attack on banks (was
attack on paypal)
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has
conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm14.htm#36 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia
addenda)
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has
conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal

todd glossary <[email-masked] on 6/12/2003 8:28 am wrote:

This is a cross posting from the ISC's mailing lists of the Bar
Association.

Why it is important here is that it documents perceived problems in
the PKI marketplace and I perceive that a number of these issues are
failures in the IETF's and potentially the ETSI standards processes,
since they allow processes that are at best incomplete from a
deployment stance to be elevated into standards status IMHO.

My concern is that the value of the IETF and ETSI is growing less and
less with these types of realizations in the marketplace.

Todd

To: <[email-masked]>
Sent: Thursday, June 12, 2003 7:00 AM
Subject: UK: PKI "not working"

PKI is 'not working'

Inadequate technology for online transactions is a 'huge problem' for
those in charge of e-government, admits a leading Whitehall official
The e-envoy's office has started searching for new ways to
authenticate the users of e-services as the existing technology being
used is "not working", a senior Government official revealed on 11
June 2003. Although PKI (public key infrastructure) and digital
certificate technology has played a major role in leading projects
such as the Government Gateway, there is now growing recognition that
it is unsuited for wider public use. While digital certificates would
not be scrapped, and would be retained as an option for e-service
users, one possible alternative being suggested is that employers,
banks, the voluntary sector and other "trusted organisations" would
verify a person's identity before transacting online for
services. Speaking on condition of anonymity, the official said the
Government is now looking at "radical ways" of solving the
authentication problem. "Trust and authentication has been a huge
problem for us. We haven't got a solution for authentication. We've
been trying with PKI for about 10 years now and its not working
because it's a pain to implement and to use. We've been looking to
take the pain out of PKI. "What we are saying with authentication is
that if another trusted organisation such as a bank can provide proof
saying you are who you say you are that should take the need away for
digital certificates." The move comes as the e-envoy's office is
acutely aware that it needs to step up the pace of e-government
leading up to the 2005 target.

http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?Op
enDocument

<http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?O
penDocument>

Michael Power

Partner & Chief Privacy Officer
Gowling Lafleur Henderson LLP
Barristers & Solicitors
Patent & Trade Mark Agents
Suite 2600
160 Elgin Street
Ottawa, Ontario, CANADA
K1P 1C3

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Date: Thu, 12 Jun 2003 10:38:04 -0400
From: Steve Hanna <[email-masked]>
To: Matt Cooper <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

Matt Cooper wrote:
> The biggest advantage to this rule is when you have a bridge
> (or any CA with certs from multiple CAs - such as in a mesh
> environment) - it prevents multiple passes through the same
> bridge point. (Or CA.) This eliminates unnecessary and unintended
> paths and can also very significantly reduce the size of the
> builder's decision tree.

In many real-world PKIs, the builder's complete decision tree
is impossibly large. And determining that tree requires fetching
all the certificates in the PKI, which is not feasible. So I'm
not terribly concerned about the size of the builder's decision
tree.

A more reasonable solution to path building is one that uses
a tree search algorithm that works with partial knowledge of
the tree, using heuristics to decide which branches to pursue.
If the builder uses such an algorithm, the example you gave below
is quickly and easily solved. Assuming you're building forward
(from EE to Z), you will find the answer as soon as you get
to the Bridge CA.

I expect there are examples that can show some benefit to
prohibiting paths that include two certs with the same
(subject DN, subject public key) pair. But I doubt that the
benefit will be substantial (assuming that a decent path
building algorithm is used). And I'm not yet convinced
that there is no reasonable use for such a path.

In general, I'd rather not make rules that tell people
how they MUST set up their PKIs unless there's a very
good reason to do so.

-Steve

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

>          +---+    +---+
>          | F |--->| H |
>          +---+    +---+
>           ^ ^       ^
>           |  \       \
>           |   \       \
>           |    v       v
>           |  +---+    +---+
>           |  | G |--->| I |
>           |  +---+    +---+
>           |   ^
>           |  /
>           | /
>       +------+       +-----------+        +------+   +---+   +---+
>       | TR W |<----->| Bridge CA |<------>| TR X |-->| L |-->| M |
>       +------+       +-----------+        +------+   +---+   +---+
>                         ^      ^               \        \
>                        /        \               \        \
>                       /          \               \        \
>                      v            v               v        v
>                +------+         +------+        +---+    +---+
>                | TR Y |         | TR Z |        | J |    | N |
>                +------+         +------+        +---+    +---+
>                 ^   ^              / \            |        |
>                /     \            /   \           |        |
>               /       \          /     \          v        v
>              v         v        v       v       +---+    +----+
>            +---+     +---+    +---+   +---+     | K |    | EE |
>            | A |<--->| C |    | O |   | P |     +---+    +----+
>            +---+     +---+    +---+   +---+
>              \         /      /  \       \
>               \       /      /    \       \
>                \     /      v      v       v
>                 v   v    +---+    +---+   +---+
>                 +---+    | Q |    | R |   | S |
>                 | B |    +---+    +---+   +---+
>                 +---+               |
>                   /\                |
>                  /  \               |
>                 v    v              v
>              +---+  +---+         +---+
>              | E |  | D |         | T |
>              +---+  +---+         +---+

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "el-sign: electronic signatures - open discussion" <[email-masked]>
Subject: Fw: PKI "not working"
Date: Thu, 12 Jun 2003 07:28:26 -0700
Sender: [email-masked]

This is a cross posting from the ISC's mailing lists of the Bar Association.

Why it is important here is that it documents perceived problems in the PKI
marketplace and I perceive that a number of these issues are failures in the
IETF's and potentially the ETSI standards processes, since they allow
processes that are at best incomplete from a deployment stance to be
elevated into standards status IMHO.

My concern is that the value of the IETF and ETSI is growing less and less
with these types of realizations in the marketplace.

Todd

To: <[email-masked]>
Sent: Thursday, June 12, 2003 7:00 AM
Subject: UK: PKI "not working"

> PKI is 'not working'
>
> Inadequate technology for online transactions is a 'huge problem' for
those
> in charge of e-government, admits a leading Whitehall official The
e-envoy's
> office has started searching for new ways to authenticate the users of
> e-services as the existing technology being used is "not working", a
senior
> Government official revealed on 11 June 2003. Although PKI (public key
> infrastructure) and digital certificate technology has played a major role
> in leading projects such as the Government Gateway, there is now growing
> recognition that it is unsuited for wider public use. While digital
> certificates would not be scrapped, and would be retained as an option for
> e-service users, one possible alternative being suggested is that
employers,
> banks, the voluntary sector and other "trusted organisations" would verify
a
> person's identity before transacting online for services. Speaking on
> condition of anonymity, the official said the Government is now looking at
> "radical ways" of solving the authentication problem. "Trust and
> authentication has been a huge problem for us. We haven't got a solution
for
> authentication. We've been trying with PKI for about 10 years now and its
> not working because it's a pain to implement and to use. We've been
looking
> to take the pain out of PKI. "What we are saying with authentication is
that
> if another trusted organisation such as a bank can provide proof saying
you
> are who you say you are that should take the need away for digital
> certificates." The move comes as the e-envoy's office is acutely aware
that
> it needs to step up the pace of e-government leading up to the 2005
target.
http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?Op
> enDocument
<http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?O
> penDocument>
>
> Michael Power
>
> Partner & Chief Privacy Officer
> Gowling Lafleur Henderson LLP
> Barristers & Solicitors
> Patent & Trade Mark Agents
> Suite 2600
> 160 Elgin Street
> Ottawa, Ontario, CANADA
> K1P 1C3
>
>
>

From: "Matt Cooper" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC 3280: same certificate in a certification path - message mangled
Date: Thu, 12 Jun 2003 10:18:11 -0400
Importance: Normal
Sender: [email-masked]

Not sure what happened to this message; it seems that the remailer mangled
it a bit by adding the example paths again about 20 characters after they
first appeared. (Perhaps there's a buffer overflow in the remailer?) In any
event, it doesn't look like any of the content is lost. If you ignore the
second (and short the "Z") instance as you read, the result is the original
message.

-Matt

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Matt Cooper
> Sent: Wednesday, June 11, 2003 12:04 PM
> To: 'Steve Hanna'
> Cc: [email-masked]
> Subject: RE: RFC 3280: same certificate in a certification path
> 
> 
> 
> Hi Steve,
> 
> The biggest advantage to this rule is when you have a bridge 
> (or any CA with certs from multiple CAs - such as in a mesh 
> environment) - it prevents multiple passes through the same 
> bridge point. (Or CA.) This eliminates unnecessary and 
> unintended paths and can also very significantly reduce the 
> size of the builder's decision tree.
> 
> Given the diagram below, the path
> EE->N->L->X->BCA->W->BCA->Y->C->A->Y->BCA->Z is perfectly valid 
> EE->N->L->X->BCA->W->BCA->Y->C->A->Y->BCA->(assuming
> policies, etc., validate) - meaning, you don't repeat any 
> certs. I will happily argue that such a path not only was not 
> intended by the people who hung the PKIs together off that 
> bridge, but that such a path should never be necessary in 
> order to validate EE. If such a path *is* necessary - I would 
> also argue that this is likely indicative of a flaw. It is 
> possible that unintended trust is being communicated in such 
> a scenario. 
> 
> One could also argue about trust dilution in such a 
> convoluted path. (I won't argue that one because it has been 
> argued at length before!)
> 
> Of course, you could now double a couple more arrows or add a 
> couple more PKIs and make the path even longer. (For example, 
> you could add G->W and
> F->W, which would of course then allow a path like
> EE->N->L->X->BCA->W->G->F->W->BCA->Y->C->A->Y->BCA->Z) At 
> some point I 
> EE->N->L->X->BCA->W->G->F->W->BCA->Y->C->A->Y->BCA->think
> we have to conclude the path becomes ridiculously and 
> unnecessarily long.
> 
> On the other hand, if you do not allow key + dn to repeat, 
> only one path exists between Z and EE. That is the simplest 
> possible path:
> EE->N->L->X->BCA->Z. So, my thinking is that you are exactly 
> right - the
> small number of certs, or possibly dozens of certs, 
> especially at the bridge, is the most likely cause of the 
> builder doing large amounts of unnecessary work while it 
> wanders around from one PKI to the bridge to another PKI and 
> back through the bridge and to another PKI and so on, each 
> time using a different bridge cert. If you imagine 50 cross 
> certified PKIs here and you do allow multiple traversals of 
> key + dn - the decision tree for the builder can become 
> outrageously large. Now if you chain PKI's with multiple 
> bridges on an international scale... And then perform 
> validation over a 28k dialup line on a laptop from your hotel room...
> 
>  -{Please see response to the X.500 alt name question below 
> the diagram.}-
> 
>          +---+    +---+
>          | F |--->| H |
>          +---+    +---+
>           ^ ^       ^
>           |  \       \
>           |   \       \
>           |    v       v
>           |  +---+    +---+
>           |  | G |--->| I |
>           |  +---+    +---+
>           |   ^
>           |  /
>           | /
>       +------+       +-----------+        +------+   +---+   +---+
>       | TR W |<----->| Bridge CA |<------>| TR X |-->| L |-->| M |
>       +------+       +-----------+        +------+   +---+   +---+
>                         ^      ^               \        \
>                        /        \               \        \
>                       /          \               \        \
>                      v            v               v        v
>                +------+         +------+        +---+    +---+
>                | TR Y |         | TR Z |        | J |    | N |
>                +------+         +------+        +---+    +---+
>                 ^   ^              / \            |        |
>                /     \            /   \           |        |
>               /       \          /     \          v        v
>              v         v        v       v       +---+    +----+
>            +---+     +---+    +---+   +---+     | K |    | EE |
>            | A |<--->| C |    | O |   | P |     +---+    +----+
>            +---+     +---+    +---+   +---+
>              \         /      /  \       \
>               \       /      /    \       \
>                \     /      v      v       v
>                 v   v    +---+    +---+   +---+
>                 +---+    | Q |    | R |   | S |
>                 | B |    +---+    +---+   +---+
>                 +---+               |
>                   /\                | 
>                  /  \               |
>                 v    v              v
>              +---+  +---+         +---+
>              | E |  | D |         | T |
>              +---+  +---+         +---+
> 
> 
> [Steve Hanna (June 04, 2003 5:30 PM)]
> > How would this rule prohibiting the re-use of a subject
> > key and subject name pair in a chain apply in the presence
> > of X.500 alt names? Would they be checked also?
> 
> [Matt Cooper] I've given some thought to this question and 
> the only scenario I can come up with where this could be an 
> issue is if for some reason a CA needed to issue itself a 
> cert with a different alt name but with the same key. If this 
> isn't a root cert, I'm not sure I see why this would be 
> necessary; the issuing CA could simply issue another cert 
> with the new alt name. Unless I'm missing something, if it's 
> a root, then I don't think alt names have any utility in the 
> cert so this issue wouldn't apply to root certs. Is this 
> where your question was coming from or did you have something 
> else in mind that I haven't thought of?
> 
> Specifically, of the alt names and renaming: If a cert (1) is 
> named XYZ with alt name A, issues itself a cert (2) -> XYZ 
> with alt name B, which then issues a cert (3), would 
> [(?)]->[(1)->(2)]->[(3)] be considered by the path builder? 
> (I think that is Steve's question with regard to x.500 alt 
> names.) In the case where (1) is not a root, you could just 
> get (?) to issue a new cert to eliminate the problem. If (1) 
> is a root, it's messier because you have to update all the 
> clients if you don't allow re-use of the key when alt names 
> differ. But why does the root cert need an alt name? Should 
> the builder even be looking at it?
> 
> So then, are the alt names considered (allowing 
> [(1)->(2)]->[(3)] and complicating the code.) or ignored 
> (eliminating [(1)->(2)]->(3) and simplifying the code.)?
> 
> The purpose of preventing the name + key from repeating is 
> only to eliminate / reduce the number of unintended and/or 
> extraneous paths. To that end, at least with existing 
> implementations that I've seen, I think just using DN + key 
> will provide for 99.9% of cases. I haven't personally ever 
> seen a scenario in production that would have this as a 
> problem. That said however, I would not be at all opposed to 
> making the rule "(dn + alt names + key) can not repeat" if 
> people feel that there is a need for including the alt names. 
> That certainly will not decrease the utility of the rule, it 
> adds flexibility, and may well allow for some situations that 
> I haven't yet considered.
> 
> Very Best Regards,
> 
> Matt Cooper
> Orion Security Solutions
> 
> 
> > -----Original Message-----
> > From: Steve Hanna [mailto:[email-masked]]
> > Sent: Wednesday, June 04, 2003 5:30 PM
> > To: Matt Cooper
> > Cc: PKIX List
> > Subject: Re: RFC 3280: same certificate in a certification path
> > 
> > 
> > How would this rule prohibiting the re-use of a subject
> > key and subject name pair in a chain apply in the presence
> > of X.500 alt names? Would they be checked also?
> >
> > I'm not convinced that this rule is worth adding. One big reason to 
> > prohibit loops (identical certs) in a path is that it's 
> very hard for 
> > a builder to know that running through the loop one more time won't 
> > result in a valid path (especially if policy mapping is on 
> and there 
> > are complicated mappings in the certs in the loop). A small 
> number of 
> > certs can cause a huge amount of work for the builder. This 
> argument 
> > doesn't apply in the case you cited. No cert would ever 
> appear in the
> > path more than once.
> > 
> > -Steve
> > 
> > Matt Cooper wrote:
> > > 
> > > Walt Tuvell noticed and brought to my attention that I 
> left out an 
> > > important detail -
> > > 
> > > The basic idea is to not re-use keys at the same point in 
> the cert 
> > > graph, so the rule I proposed should be "Don't re-use the
> > same key and
> > > subject name pair." This is the same idea (prevents multiple 
> > > traversals across the bridge, policy loops, etc.) but still
> > allows a
> > > CA to perform a "name change" on itself should the need 
> arise. (For 
> > > example, as Walt pointed out, during migration to DNS
> > naming from X500
> > > naming.)
> > > 
> > > For those of you reading this (if any) who may be using 
> one of the 
> > > path builders I put together, never fear, it is implemented
> > with the
> > > Key / DN pair, not just the key, so name changes should
> > work without a
> > > problem.
> > > 
> > > Matt Cooper
> > > Orion Security Solutions
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] 
> > > > [mailto:[email-masked]] On Behalf Of Matt Cooper
> > > > Sent: Friday, May 23, 2003 12:32 AM
> > > > To: [email-masked]; 'PKIX list'
> > > > Subject: RE: RFC 3280: same certificate in a certification path
> > > >
> > > >
> > > >
> > > > Very well put!
> > > >
> > > > Now, what say you to the assertion that there is no need
> > to repeat
> > > > keys in a path, much less certificates? There are a couple very 
> > > > attractive properties to such a rule such as preventing 
> multiple 
> > > > traversals through a Bridge CA, or preventing "policy
> > loops" like in
> > > > your example but more complicated - through multiple CAs
> > and looped
> > > > back via a different path - duplicate certs not required.
> > > >
> > > > I have yet to encounter a real world example where it was
> > necessary
> > > > to repeat a key. In fact, the last two path builders I 
> wrote used 
> > > > that rule, and they have yet to run into a snag (as far
> > as I know!)
> > > > in testing or in the wild as a result of that
> > restriction. Your (and
> > > > others') thoughts would be welcome!
> > > >
> > > > Very Best Regards,
> > > >
> > > > Matt Cooper
> > > > Orion Security Solutions
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> > > > > [mailto:[email-masked]] On Behalf Of Steve Hanna
> > > > > Sent: Monday, May 19, 2003 5:59 AM
> > > > > To: Eric Norman; PKIX list
> > > > > Subject: Re: RFC 3280: same certificate in a 
> certification path
> > > > >
> > > > >
> > > > >
> > > > > Eric Norman wrote:
> > > > > >To say that a path is prohibited or is invalid does not mean
> > > > > that the
> > > > > >answer to the question of trust that you're trying to
> > > > > establish is "not
> > > > > >trusted".  What I think the intent is, and what I think
> > > > > works, is that
> > > > > >when you say a path is prohibited, you mean that it 
> needn't be 
> > > > > >considered farther because it will contribute nothing more.
> > > > >
> > > > > Yes, that's it. There's no reason to consider paths
> > that contain
> > > > > the same certificate twice because nobody can come up 
> with any 
> > > > > real-world scenario where they have any value. But if
> > we consider
> > > > > them valid there are some rather preposterous scenarios
> > where the
> > > > > only valid path would be one that contains the same 
> certificate 
> > > > > twice.
> > > > >
> > > > > For instance, in a path CA1->CA2->CA1->CA2->EE where 
> the user's 
> > > > > acceptable policy is High and policy mapping is enabled and
> > > > CA1->CA2
> > > > > has HIGH and TOP SECRET policies and maps HIGH to CONF and
> > > > TOP SECRET
> > > > > to Z, CA2->CA1 has CONF policy and maps CONF to TOP 
> SECRET, and
> > > > > CA2->EE has Z policy. See the example in our paper. This
> > > > example makes
> > > > > no real world sense, but it shows that if paths with 
> duplicate 
> > > > > certificates are considered valid then path builders
> > must try them
> > > > > (at least, when policy mapping is involved).
> > > > >
> > > > > The best solution, as you suggest, is for people to not
> > just stick
> > > > > certs together casually, perform path validation, and
> > give up if
> > > > > it fails. They should move on to try path building. The path 
> > > > > builder will build a valid path if one can be built (omitting 
> > > > > pointless duplicate certificates). But there's no 
> problem with 
> > > > > declaring paths that contain duplicate certificates to
> > be invalid.
> > > > >
> > > > > I'd love to chat more about the interesting 
> theoretical issues 
> > > > > that you raised (and I will return to do so), but I 
> have to run 
> > > > > off to Jury Duty today. I'll catch up with you tomorrow
> > and we can
> > > > > discuss this more.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Steve
> > > > >
> > > > > >On Fri, 16 May 2003, Steve Hanna wrote:
> > > > > >
> > > > > >> A path that includes the same cert twice might look
> > like this:
> > > > > >>
> > > > > >> CA1 -> CA2 -> CA1 -> CA2 -> EE
> > > > > >
> > > > > >[for reference below].
> > > > > >
> > > > > >> Eric Norman asks why we want to prohibit paths that
> > > > > contain the same
> > > > > >> certificate twice. I agree that there's nothing inherently
> > > > > wrong with
> > > > > >> such a path. But nobody has been able to show any 
> reason why 
> > > > > >> it's desirable to support such a path. And if we
> > prohibit such
> > > > > paths, then
> > > > > >> path builders can be somewhat simpler and more efficient.
> > > > > They don't
> > > > > >> have to consider building paths with loops.
> > > > > >>
> > > > > >> Eric, do you have a good reason why we should not prohibit
> > > > > paths that
> > > > > >> contain the same certificate twice? I don't find
> > > > > >
> > > > > >Because they can happen.  There's nothing that will
> > prevent, and
> > > > > >there's also probably no way to prevent autonomous CAs
> > > > from creating
> > > > > >loops in the certificate network.  Ergo, this must be
> > dealt with
> > > > > >somehow; more below.
> > > > > >
> > > > > >> your argument about sticking two paths together
> > > > convincing. That's
> > > > > >> not how PKIX path building is generally done, since it
> > > > > often doesn't
> > > > > >> work (if one of the certs in the first part of the path
> > > > > includes name
> > > > > >> constraints violated by a cert in the second part of the
> > > > path, for
> > > > > >> instance).
> > > > > >
> > > > > >In fact, the examples chosen here, e.g. the path
> > segment CA1 ->
> > > > > >CA2 -> CA1  (append another -> CA2 if you prefer) are
> > > > > precisely
> > > > > >what happens when two CAs cross certify each other 
> by signing 
> > > > > >each others keys (really attesting to each other's
> > > > > >identity) and then publish the fact that they have
> > done so with a
> > > > > >CrossCertificatePair with both parts filled in (e.g. bridge
> > > > > stuff and
> > > > > >the like).
> > > > > >
> > > > > >Actually, it's even simpler than that.  Continuing with the
> > > > > distinction
> > > > > >you're trying to make above, you could just as well have a
> > > > path like
> > > > > >CA1 -> CA2 -> CA2 -> CA2 -> CA2 -> CA3. The same certificate
> > > > > >(self-signed) appears multiple times. However, this path can
> > > > > be used to
> > > > > >verify a trust relationship between CA1 and CA3 (just
> > > > > pretend CA2 never
> > > > > >issued the self- signed certificate).
> > > > > >
> > > > > >I think that we're really talking about here is what exactly
> > > > > is meant,
> > > > > >and what is implied, and what will be inferred by 
> implementors 
> > > > > >when they see words like "prohibit", "valid" and so forth.
> > > > > >
> > > > > >To say that a path is prohibited or is invalid does not mean
> > > > > that the
> > > > > >answer to the question of trust that you're trying to
> > > > > establish is "not
> > > > > >trusted".  What I think the intent is, and what I think
> > > > > works, is that
> > > > > >when you say a path is prohibited, you mean that it 
> needn't be 
> > > > > >considered farther because it will contribute nothing more.
> > > > > >
> > > > > >What my real problem might be is that I think the language
> > > > > could lead
> > > > > >to enough confusion for implementors that they'll 
> get it wrong.
> > > > > >
> > > > > >The implication this has for constraints is that if
> > > > they're properly
> > > > > >designed (and I think they probably are) then when you
> > > > > encounter some
> > > > > >constraints a second time (because you've encountered a 
> > > > > >certificate again), then applying the contraints again
> > will yield
> > > > nothing new.
> > > > > >Actually, what I really think is that this shouldn't
> > even happen
> > > > > >because you should create a spanning tree or something like
> > > > > that before
> > > > > >you begin the trust evaluation process; i.e. you 
> should never 
> > > > > >even encounter a certificate twice, but if you do, 
> you'll still
> > > > > get the same
> > > > > >answer as far as trust.  All that's left is to worry about 
> > > > > >termination when you have loops in the certificate graph.
> > > > > >
> > > > > >Hence,
> > > > > >
> > > > > >> P.S. Eric, thanks for tooting your own horn. It's
> > good for us
> > > > > >> to consider and understand earlier work so we 
> don't reinvent 
> > > > > >> things.
> > > > > >
> > > > > >FWIW, I'll say a bit more about garbage collection 
> in LISP. If 
> > > > > >you mimic the simplistic recursive descent -- leave spoor
> > > > > everywhere
> > > > > >-- back out when you encounter it garbage collection
> > > > > algorithm to try
> > > > > >to find a known "trust anchor", then you are guaranteed that:
> > > > > >
> > > > > >(1) you will find a path if one exists, and
> > > > > >
> > > > > >(2) the algorithm will always terminate.
> > > > > >
> > > > > >What you are not guaranteed is that this simplistic
> > > > > algorithm will find
> > > > > >the best path by whatever metric you use to determine what's 
> > > > > >best.
> > > > > >
> > > > > >> Certificate path building is at heart a graph 
> theory problem.
> > > > > >
> > > > > >And category theory is at the heart of graph theory;
> > however, I
> > > > > >not going to suggest that everyone needs to take 
> time out and 
> > > > > >read the works of Saunders MacLane before discussion
> > can continue
> > > > > >:) :) :)
> > > > > >
> > > > > >I do have a "hidden agenda", though.  I will now try 
> to change 
> > > > > >its status from covert to overt.  I would like to see sound
> > > > theoretical
> > > > > >underpinnings to all this stuff.  That means mathematics,
> > > > the branch
> > > > > >called "algebra" in particular.  I'm not claiming that
> > > > concepts like
> > > > > >splicing chains together completely provide such
> > > > > underpinnings, but I
> > > > > >believe that they come real close.  There's a pretty direct
> > > > > translation
> > > > > >between splicing chains and the mathematical concepts of
> > > > transitive
> > > > > >relations and composition of functions, and the algorithm
> > > > above does
> > > > > >nothing more than compute what is known as a closure 
> or limit.
> > > > > >
> > > > > >> But the problem is complicated by adding constraints to
> > > > > certificates
> > > > > >> and by performance concerns. I recently talked
> > > > > >
> > > > > >What you want is for constraints to have a "monotonic"
> > > > > property. That's
> > > > > >just another way of saying that they'll contribute
> > nothing new if
> > > > > >applied again (well, actually that they won't try to
> > > > > contradict what's
> > > > > >been done before).
> > > > > >
> > > > > >> with someone who said "Cert path building isn't
> > hard. It's only
> > > > > >> O(n+e) where n is the number of entities and e is
> > the number of
> > > > > >> certificates." That's true, but you have to 
> download all the 
> > > > > >> certificates in the PKI first! Not very practical in most 
> > > > > >> environments.
> > > > > >
> > > > > >It sounds I'm another one who's says "it's easy", doesn't it?
> > > > > >
> > > > > >I don't think I'm saying that you have to download all the
> > > > > certificates
> > > > > >in the PKI first.  What I think I'm saying is that you
> > > > > aren't going to
> > > > > >have much luck if you try to solve such problems by
> > > > > restrictions of the
> > > > > >possible topologies. The way to do it is to make sure you
> > > > > notice that
> > > > > >you're in a loop.  And when you do notice that, you
> > > > certainly can't
> > > > > >give up and pronounce that whole thing 
> untrustworthy; you just 
> > > > > >try something else until you run out of possiblities.
> > > > > >
> > > > > >Now the practical performance problems and the "as yet
> > > > unknown link"
> > > > > >problems have been introduced.  I'll offer the opinion
> > > > that the very
> > > > > >best thing that can to done to alleviate such problems is to
> > > > > follow the
> > > > > >often written advice to send all certificates to the other
> > > > > end that you
> > > > > >suspect they might need. Every certificate using 
> protocol has 
> > > > > >facilities to do this. In the circles where I've heard this
> > > > > discussed,
> > > > > >I'm having a real hard time understanding why there's such
> > > > > resistance
> > > > > >to doing this.
> > > > > >
> > > > > >
> > > > > >Eric Norman
> > > > > >
> > > > > >   "Congress shall make no law restricting the size 
> of integers
> > > > > >   that may be multiplied together, or the number of 
> times that
> > > > > >   an integer may be multiplied by itself, or the modulus by
> > > > > >   which an integer may be reduced".
> > > > >
> > > > >
> > > >
> > > >
> > 
> 
> 

Date: Thu, 12 Jun 2003 09:40:15 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked]
Subject: Re: Last Call: Internet X.509 Public Key Infrastructure:         Logotypes in X.509 certificates to Proposed Standard
Sender: [email-masked]

> The IESG has received a request from the Public-Key Infrastructure 
> (X.509) Working Group to consider Internet X.509 Public Key 
> Infrastructure: Logotypes in X.509 certificates 
> <draft-ietf-pkix-logotypes-10.txt> as a Proposed Standard.  

> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the 
> [email-masked] or [email-masked] mailing lists by 2003-6-19.

Comments on <draft-ietf-pkix-logotypes-10.txt>

Please find attached two minor comemnts and three editorial comments.

1. Page 7. Section 3. 5 th paragraph. Last sentence.

The current sentence is:

Compliant applications MUST display one or none of the images and play one 
or none of the audio sequences at the same time.

It should be:

Compliant applications MUST be able to display one or none of the images and 
SHOULD be able to play one or none of the audio sequences at the same time.

2. Editorial. Page 11. Section 4.2. Since the logotype loyalty is explained 
first, it would be better to switch the certificate background logotype and 
the loyalty logotype.

So instead of the following:

    - certificate Background logotype
    - loyalty logotype.

we should have:

    - loyalty logotype,
    - certificate Background logotype.

3. Page 14. Section 7. First of the two last bullets at the bottom of the 
page. Is "a severance pay" really appropriate to protect a parent CA from a 
subordinate CA ? Otherwise, please, delete "and severance pay".

4. Editorial. Page 17. It would be nice to add in the ASN.1 module:

-- EXPORTS ALL --

5. Editorial. Page 21.

It would be appropriate to update the address from Stefan Santesson,
since his address has recently changed.

Denis

Date: Wed, 11 Jun 2003 23:08:30 +0200 (CEST)
To: [email-masked]
CC: [email-masked]
Subject: Re: Acquire OID for CP?
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Wed, 11 Jun 2003 12:02:38 -0700, Jana Nguyen <[email-masked]> said:

jnguyen> How do I acquire an OID for the certificate policy (CP) for my
jnguyen> organization?

You get yourself an arc, then define your OIDs within that arc.

Take a look at http://www.alvestrand.no/objectid/ and
http://www.alvestrand.no/objectid/1.3.6.1.4.1.html

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 11 Jun 2003 12:02:38 -0700
From: Jana Nguyen <[email-masked]>
Organization: NAS - NASA Ames Research Center, Moffett Field, CA
To: [email-masked]
Subject: Acquire OID for CP?
Sender: [email-masked]

Hi,

How do I acquire an OID for the certificate policy (CP) for my
organization?

Thank you,
Jana

From: Sharon Boeyen <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: son-of-rfc3280 (grandson-of-rfc2459)
Date: Wed, 11 Jun 2003 12:11:26 -0400
Sender: [email-masked]

Russ there are probably some additional X.509 defect reports that have 
been approved and reflected in formal Technical Corrigenda that should 
be at least considered to see if any of them also impact this update. 

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, June 11, 2003 9:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: son-of-rfc3280 (grandson-of-rfc2459)

Dear PKIX WG:

I believe that an update to RFC 3280 is needed.  There are three major 
reasons that I believe an update is necessary:

1.  ITU-T is looking at changes to X.509 key usage extension.  The text in 
RFC 3280 section 4.2.1.3 has lead to a debate, which is not completely 
resolved.  Hoyt Kesterson has agreed to let the PKIX WG comment on the 
proposed text prior to publication.  So, once everyone is equally unhappy 
with the text, then both the ITU-T and the IETF should update their 
respective documents.

2.  Issues with UTF8 needs to be handled more clearly.  I believe that this 
should not be done until all of the issues associated with the use of UTF8 
in DNS are resolved.  I believe that certificates must use many of the same 
string comparison mechanisms as the DNS, and two solutions are unacceptable.

3.  Correct the error in section 6.3.3.  (see 
http://www.rfc-editor.org/errata.html).

Speaking as a co-author of RFC 3280, not as the Security Area Director,
    Russ

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: son-of-rfc3280 (grandson-of-rfc2459)
Date: Wed, 11 Jun 2003 09:05:09 -0700
Sender: [email-masked]

I support Russ' assertion and also agree that a new revision of 3280 is
necessary too.

Todd

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 11, 2003 6:55 AM
Subject: son-of-rfc3280 (grandson-of-rfc2459)

>
> Dear PKIX WG:
>
> I believe that an update to RFC 3280 is needed.  There are three major
> reasons that I believe an update is necessary:
>
> 1.  ITU-T is looking at changes to X.509 key usage extension.  The text in
> RFC 3280 section 4.2.1.3 has lead to a debate, which is not completely
> resolved.  Hoyt Kesterson has agreed to let the PKIX WG comment on the
> proposed text prior to publication.  So, once everyone is equally unhappy
> with the text, then both the ITU-T and the IETF should update their
> respective documents.
>
> 2.  Issues with UTF8 needs to be handled more clearly.  I believe that
this
> should not be done until all of the issues associated with the use of UTF8
> in DNS are resolved.  I believe that certificates must use many of the
same
> string comparison mechanisms as the DNS, and two solutions are
unacceptable.
>
> 3.  Correct the error in section 6.3.3.  (see
> http://www.rfc-editor.org/errata.html).
>
> Speaking as a co-author of RFC 3280, not as the Security Area Director,
>     Russ
>

From: "Matt Cooper" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RFC 3280: same certificate in a certification path
Date: Wed, 11 Jun 2003 12:03:42 -0400
Importance: Normal
Sender: [email-masked]

Hi Steve,

The biggest advantage to this rule is when you have a bridge (or any CA with
certs from multiple CAs - such as in a mesh environment) - it prevents
multiple passes through the same bridge point. (Or CA.) This eliminates
unnecessary and unintended paths and can also very significantly reduce the
size of the builder's decision tree.

Given the diagram below, the path
EE->N->L->X->BCA->W->BCA->Y->C->A->Y->BCA->Z is perfectly valid (assuming
policies, etc., validate) - meaning, you don't repeat any certs. I will
happily argue that such a path not only was not intended by the people who
hung the PKIs together off that bridge, but that such a path should never be
necessary in order to validate EE. If such a path *is* necessary - I would
also argue that this is likely indicative of a flaw. It is possible that
unintended trust is being communicated in such a scenario. 

One could also argue about trust dilution in such a convoluted path. (I
won't argue that one because it has been argued at length before!)

Of course, you could now double a couple more arrows or add a couple more
PKIs and make the path even longer. (For example, you could add G->W and
F->W, which would of course then allow a path like
EE->N->L->X->BCA->W->G->F->W->BCA->Y->C->A->Y->BCA->Z) At some point I think
we have to conclude the path becomes ridiculously and unnecessarily long.

On the other hand, if you do not allow key + dn to repeat, only one path
exists between Z and EE. That is the simplest possible path:
EE->N->L->X->BCA->Z. So, my thinking is that you are exactly right - the
small number of certs, or possibly dozens of certs, especially at the
bridge, is the most likely cause of the builder doing large amounts of
unnecessary work while it wanders around from one PKI to the bridge to
another PKI and back through the bridge and to another PKI and so on, each
time using a different bridge cert. If you imagine 50 cross certified PKIs
here and you do allow multiple traversals of key + dn - the decision tree
for the builder can become outrageously large. Now if you chain PKI's with
multiple bridges on an international scale... And then perform validation
over a 28k dialup line on a laptop from your hotel room...

 -{Please see response to the X.500 alt name question below the diagram.}-

         +---+    +---+
         | F |--->| H |
         +---+    +---+
          ^ ^       ^
          |  \       \
          |   \       \
          |    v       v
          |  +---+    +---+
          |  | G |--->| I |
          |  +---+    +---+
          |   ^
          |  /
          | /
      +------+       +-----------+        +------+   +---+   +---+
      | TR W |<----->| Bridge CA |<------>| TR X |-->| L |-->| M |
      +------+       +-----------+        +------+   +---+   +---+
                        ^      ^               \        \
                       /        \               \        \
                      /          \               \        \
                     v            v               v        v
               +------+         +------+        +---+    +---+
               | TR Y |         | TR Z |        | J |    | N |
               +------+         +------+        +---+    +---+
                ^   ^              / \            |        |
               /     \            /   \           |        |
              /       \          /     \          v        v
             v         v        v       v       +---+    +----+
           +---+     +---+    +---+   +---+     | K |    | EE |
           | A |<--->| C |    | O |   | P |     +---+    +----+
           +---+     +---+    +---+   +---+
             \         /      /  \       \
              \       /      /    \       \
               \     /      v      v       v
                v   v    +---+    +---+   +---+
                +---+    | Q |    | R |   | S |
                | B |    +---+    +---+   +---+
                +---+               |
                  /\                | 
                 /  \               |
                v    v              v
             +---+  +---+         +---+
             | E |  | D |         | T |
             +---+  +---+         +---+

[Steve Hanna (June 04, 2003 5:30 PM)]
> How would this rule prohibiting the re-use of a subject
> key and subject name pair in a chain apply in the presence
> of X.500 alt names? Would they be checked also?

[Matt Cooper] I've given some thought to this question and the only scenario
I can come up with where this could be an issue is if for some reason a CA
needed to issue itself a cert with a different alt name but with the same
key. If this isn't a root cert, I'm not sure I see why this would be
necessary; the issuing CA could simply issue another cert with the new alt
name. Unless I'm missing something, if it's a root, then I don't think alt
names have any utility in the cert so this issue wouldn't apply to root
certs. Is this where your question was coming from or did you have something
else in mind that I haven't thought of?

Specifically, of the alt names and renaming: If a cert (1) is named XYZ with
alt name A, issues itself a cert (2) -> XYZ with alt name B, which then
issues a cert (3), would [(?)]->[(1)->(2)]->[(3)] be considered by the path
builder? (I think that is Steve's question with regard to x.500 alt names.)
In the case where (1) is not a root, you could just get (?) to issue a new
cert to eliminate the problem. If (1) is a root, it's messier because you
have to update all the clients if you don't allow re-use of the key when alt
names differ. But why does the root cert need an alt name? Should the
builder even be looking at it?

So then, are the alt names considered (allowing [(1)->(2)]->[(3)] and
complicating the code.) or ignored (eliminating [(1)->(2)]->(3) and
simplifying the code.)?

The purpose of preventing the name + key from repeating is only to eliminate
/ reduce the number of unintended and/or extraneous paths. To that end, at
least with existing implementations that I've seen, I think just using DN +
key will provide for 99.9% of cases. I haven't personally ever seen a
scenario in production that would have this as a problem. That said however,
I would not be at all opposed to making the rule "(dn + alt names + key) can
not repeat" if people feel that there is a need for including the alt names.
That certainly will not decrease the utility of the rule, it adds
flexibility, and may well allow for some situations that I haven't yet
considered.

Very Best Regards,

Matt Cooper
Orion Security Solutions

> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2003 5:30 PM
> To: Matt Cooper
> Cc: PKIX List
> Subject: Re: RFC 3280: same certificate in a certification path
> 
> 
> How would this rule prohibiting the re-use of a subject
> key and subject name pair in a chain apply in the presence
> of X.500 alt names? Would they be checked also?
>
> I'm not convinced that this rule is worth adding. One big
> reason to prohibit loops (identical certs) in a path is that 
> it's very hard for a builder to know that running through the 
> loop one more time won't result in a valid path (especially 
> if policy mapping is on and there are complicated mappings in 
> the certs in the loop). A small number of certs can cause a 
> huge amount of work for the builder. This argument doesn't 
> apply in the case you cited. No cert would ever appear in the 
> path more than once.
> 
> -Steve
> 
> Matt Cooper wrote:
> > 
> > Walt Tuvell noticed and brought to my attention that I left out an
> > important detail -
> > 
> > The basic idea is to not re-use keys at the same point in the cert
> > graph, so the rule I proposed should be "Don't re-use the 
> same key and
> > subject name pair." This is the same idea (prevents multiple
> > traversals across the bridge, policy loops, etc.) but still 
> allows a
> > CA to perform a "name change" on itself should the need arise. (For
> > example, as Walt pointed out, during migration to DNS 
> naming from X500
> > naming.)
> > 
> > For those of you reading this (if any) who may be using one of the
> > path builders I put together, never fear, it is implemented 
> with the
> > Key / DN pair, not just the key, so name changes should
> work without a
> > problem.
> > 
> > Matt Cooper
> > Orion Security Solutions
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Matt Cooper
> > > Sent: Friday, May 23, 2003 12:32 AM
> > > To: [email-masked]; 'PKIX list'
> > > Subject: RE: RFC 3280: same certificate in a certification path
> > >
> > >
> > >
> > > Very well put!
> > >
> > > Now, what say you to the assertion that there is no need
> to repeat
> > > keys in a path, much less certificates? There are a couple very
> > > attractive properties to such a rule such as preventing multiple 
> > > traversals through a Bridge CA, or preventing "policy 
> loops" like in
> > > your example but more complicated - through multiple CAs
> and looped
> > > back via a different path - duplicate certs not required.
> > >
> > > I have yet to encounter a real world example where it was
> necessary
> > > to repeat a key. In fact, the last two path builders I wrote used
> > > that rule, and they have yet to run into a snag (as far 
> as I know!)
> > > in testing or in the wild as a result of that
> restriction. Your (and
> > > others') thoughts would be welcome!
> > >
> > > Very Best Regards,
> > >
> > > Matt Cooper
> > > Orion Security Solutions
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Steve Hanna
> > > > Sent: Monday, May 19, 2003 5:59 AM
> > > > To: Eric Norman; PKIX list
> > > > Subject: Re: RFC 3280: same certificate in a certification path
> > > >
> > > >
> > > >
> > > > Eric Norman wrote:
> > > > >To say that a path is prohibited or is invalid does not mean
> > > > that the
> > > > >answer to the question of trust that you're trying to
> > > > establish is "not
> > > > >trusted".  What I think the intent is, and what I think
> > > > works, is that
> > > > >when you say a path is prohibited, you mean that it needn't be
> > > > >considered farther because it will contribute nothing more.
> > > >
> > > > Yes, that's it. There's no reason to consider paths
> that contain
> > > > the same certificate twice because nobody can come up with any
> > > > real-world scenario where they have any value. But if 
> we consider
> > > > them valid there are some rather preposterous scenarios
> where the
> > > > only valid path would be one that contains the same certificate
> > > > twice.
> > > >
> > > > For instance, in a path CA1->CA2->CA1->CA2->EE where the user's
> > > > acceptable policy is High and policy mapping is enabled and
> > > CA1->CA2
> > > > has HIGH and TOP SECRET policies and maps HIGH to CONF and
> > > TOP SECRET
> > > > to Z, CA2->CA1 has CONF policy and maps CONF to TOP SECRET, and
> > > > CA2->EE has Z policy. See the example in our paper. This
> > > example makes
> > > > no real world sense, but it shows that if paths with duplicate
> > > > certificates are considered valid then path builders 
> must try them
> > > > (at least, when policy mapping is involved).
> > > >
> > > > The best solution, as you suggest, is for people to not
> just stick
> > > > certs together casually, perform path validation, and
> give up if
> > > > it fails. They should move on to try path building. The path
> > > > builder will build a valid path if one can be built (omitting 
> > > > pointless duplicate certificates). But there's no problem with 
> > > > declaring paths that contain duplicate certificates to 
> be invalid.
> > > >
> > > > I'd love to chat more about the interesting theoretical issues
> > > > that you raised (and I will return to do so), but I have to run 
> > > > off to Jury Duty today. I'll catch up with you tomorrow 
> and we can
> > > > discuss this more.
> > > >
> > > > Thanks,
> > > >
> > > > Steve
> > > >
> > > > >On Fri, 16 May 2003, Steve Hanna wrote:
> > > > >
> > > > >> A path that includes the same cert twice might look
> like this:
> > > > >>
> > > > >> CA1 -> CA2 -> CA1 -> CA2 -> EE
> > > > >
> > > > >[for reference below].
> > > > >
> > > > >> Eric Norman asks why we want to prohibit paths that
> > > > contain the same
> > > > >> certificate twice. I agree that there's nothing inherently
> > > > wrong with
> > > > >> such a path. But nobody has been able to show any reason why
> > > > >> it's desirable to support such a path. And if we 
> prohibit such
> > > > paths, then
> > > > >> path builders can be somewhat simpler and more efficient.
> > > > They don't
> > > > >> have to consider building paths with loops.
> > > > >>
> > > > >> Eric, do you have a good reason why we should not prohibit
> > > > paths that
> > > > >> contain the same certificate twice? I don't find
> > > > >
> > > > >Because they can happen.  There's nothing that will
> prevent, and
> > > > >there's also probably no way to prevent autonomous CAs
> > > from creating
> > > > >loops in the certificate network.  Ergo, this must be
> dealt with
> > > > >somehow; more below.
> > > > >
> > > > >> your argument about sticking two paths together
> > > convincing. That's
> > > > >> not how PKIX path building is generally done, since it
> > > > often doesn't
> > > > >> work (if one of the certs in the first part of the path
> > > > includes name
> > > > >> constraints violated by a cert in the second part of the
> > > path, for
> > > > >> instance).
> > > > >
> > > > >In fact, the examples chosen here, e.g. the path
> segment CA1 ->
> > > > >CA2 -> CA1  (append another -> CA2 if you prefer) are
> > > > precisely
> > > > >what happens when two CAs cross certify each other by signing
> > > > >each others keys (really attesting to each other's
> > > > >identity) and then publish the fact that they have 
> done so with a
> > > > >CrossCertificatePair with both parts filled in (e.g. bridge
> > > > stuff and
> > > > >the like).
> > > > >
> > > > >Actually, it's even simpler than that.  Continuing with the
> > > > distinction
> > > > >you're trying to make above, you could just as well have a
> > > path like
> > > > >CA1 -> CA2 -> CA2 -> CA2 -> CA2 -> CA3. The same certificate
> > > > >(self-signed) appears multiple times. However, this path can
> > > > be used to
> > > > >verify a trust relationship between CA1 and CA3 (just
> > > > pretend CA2 never
> > > > >issued the self- signed certificate).
> > > > >
> > > > >I think that we're really talking about here is what exactly
> > > > is meant,
> > > > >and what is implied, and what will be inferred by implementors
> > > > >when they see words like "prohibit", "valid" and so forth.
> > > > >
> > > > >To say that a path is prohibited or is invalid does not mean
> > > > that the
> > > > >answer to the question of trust that you're trying to
> > > > establish is "not
> > > > >trusted".  What I think the intent is, and what I think
> > > > works, is that
> > > > >when you say a path is prohibited, you mean that it needn't be
> > > > >considered farther because it will contribute nothing more.
> > > > >
> > > > >What my real problem might be is that I think the language
> > > > could lead
> > > > >to enough confusion for implementors that they'll get it wrong.
> > > > >
> > > > >The implication this has for constraints is that if
> > > they're properly
> > > > >designed (and I think they probably are) then when you
> > > > encounter some
> > > > >constraints a second time (because you've encountered a
> > > > >certificate again), then applying the contraints again 
> will yield
> > > nothing new.
> > > > >Actually, what I really think is that this shouldn't
> even happen
> > > > >because you should create a spanning tree or something like
> > > > that before
> > > > >you begin the trust evaluation process; i.e. you should never
> > > > >even encounter a certificate twice, but if you do, you'll still
> > > > get the same
> > > > >answer as far as trust.  All that's left is to worry about
> > > > >termination when you have loops in the certificate graph.
> > > > >
> > > > >Hence,
> > > > >
> > > > >> P.S. Eric, thanks for tooting your own horn. It's
> good for us
> > > > >> to consider and understand earlier work so we don't reinvent
> > > > >> things.
> > > > >
> > > > >FWIW, I'll say a bit more about garbage collection in LISP. If
> > > > >you mimic the simplistic recursive descent -- leave spoor
> > > > everywhere
> > > > >-- back out when you encounter it garbage collection
> > > > algorithm to try
> > > > >to find a known "trust anchor", then you are guaranteed that:
> > > > >
> > > > >(1) you will find a path if one exists, and
> > > > >
> > > > >(2) the algorithm will always terminate.
> > > > >
> > > > >What you are not guaranteed is that this simplistic
> > > > algorithm will find
> > > > >the best path by whatever metric you use to determine what's
> > > > >best.
> > > > >
> > > > >> Certificate path building is at heart a graph theory problem.
> > > > >
> > > > >And category theory is at the heart of graph theory;
> however, I
> > > > >not going to suggest that everyone needs to take time out and
> > > > >read the works of Saunders MacLane before discussion 
> can continue
> > > > >:) :) :)
> > > > >
> > > > >I do have a "hidden agenda", though.  I will now try to change
> > > > >its status from covert to overt.  I would like to see sound
> > > theoretical
> > > > >underpinnings to all this stuff.  That means mathematics,
> > > the branch
> > > > >called "algebra" in particular.  I'm not claiming that
> > > concepts like
> > > > >splicing chains together completely provide such
> > > > underpinnings, but I
> > > > >believe that they come real close.  There's a pretty direct
> > > > translation
> > > > >between splicing chains and the mathematical concepts of
> > > transitive
> > > > >relations and composition of functions, and the algorithm
> > > above does
> > > > >nothing more than compute what is known as a closure or limit.
> > > > >
> > > > >> But the problem is complicated by adding constraints to
> > > > certificates
> > > > >> and by performance concerns. I recently talked
> > > > >
> > > > >What you want is for constraints to have a "monotonic"
> > > > property. That's
> > > > >just another way of saying that they'll contribute
> nothing new if
> > > > >applied again (well, actually that they won't try to
> > > > contradict what's
> > > > >been done before).
> > > > >
> > > > >> with someone who said "Cert path building isn't
> hard. It's only
> > > > >> O(n+e) where n is the number of entities and e is
> the number of
> > > > >> certificates." That's true, but you have to download all the
> > > > >> certificates in the PKI first! Not very practical in most 
> > > > >> environments.
> > > > >
> > > > >It sounds I'm another one who's says "it's easy", doesn't it?
> > > > >
> > > > >I don't think I'm saying that you have to download all the
> > > > certificates
> > > > >in the PKI first.  What I think I'm saying is that you
> > > > aren't going to
> > > > >have much luck if you try to solve such problems by
> > > > restrictions of the
> > > > >possible topologies. The way to do it is to make sure you
> > > > notice that
> > > > >you're in a loop.  And when you do notice that, you
> > > certainly can't
> > > > >give up and pronounce that whole thing untrustworthy; you just
> > > > >try something else until you run out of possiblities.
> > > > >
> > > > >Now the practical performance problems and the "as yet
> > > unknown link"
> > > > >problems have been introduced.  I'll offer the opinion
> > > that the very
> > > > >best thing that can to done to alleviate such problems is to
> > > > follow the
> > > > >often written advice to send all certificates to the other
> > > > end that you
> > > > >suspect they might need. Every certificate using protocol has
> > > > >facilities to do this. In the circles where I've heard this
> > > > discussed,
> > > > >I'm having a real hard time understanding why there's such
> > > > resistance
> > > > >to doing this.
> > > > >
> > > > >
> > > > >Eric Norman
> > > > >
> > > > >   "Congress shall make no law restricting the size of integers
> > > > >   that may be multiplied together, or the number of times that
> > > > >   an integer may be multiplied by itself, or the modulus by
> > > > >   which an integer may be reduced".
> > > >
> > > >
> > >
> > >
> 

Date: Wed, 11 Jun 2003 11:43:01 -0400
From: Steve Hanna <[email-masked]>
To: Terry Hayes <[email-masked]>
CC: [email-masked]
Subject: Re: Name Constraints Processing
Sender: [email-masked]

I apologize for taking so long to respond to your questions.
I agree that there are a few potential ambiguities in the
discussion of name constraints in RFC 3280. Let me address
your comments directly.

Terry Hayes wrote:
> RFC 3280 seems to be unclear as to the handling of certain
> unusual cases that may be encountered while processing the
> Name Constraints extension.  While these cases are not likely
> to be seen in real deployments, the certificate processing
> code needs to respond to them correctly, both to avoid incorrect
> behavior of the application and to avoid introducing security
> holes.  I'll describe each situation below along with my best
> guess at the correct handling.  I'd appreciate comments.
> 
> 1. Name constraints containing an empty Directory Name sequence
> 
> What is the correct processing of a name constraint extension
> that contains an empty sequence in the directoryName choice?
> 
> The empty sequence value for a directory name is used in other
> places in this RFC to indicate that no name is present. However,
> here I think it means that the constraint matches all possible
> names. Therefore, in the permitted subtrees field, this allows
> certificates to be issued to any directory name (equivalent to
> no constraint), and in the excluded subtrees field, prevents
> certificates from being issued that contain any directory name.

You're right. The X.500 specs are pretty clear about this.
The name of the root of the DIT is a zero length sequence.
So if you include such an empty DN in permitted subtrees,
it allows and DN (subject of course to any other name constraints
defined in the excluded subtrees or in other certs in the chain).
And if you include such an empty DN in excluded subtrees,
it prohibits any subsequent certificates from containing any
distinguished name as a subject or subject alt name.

RFC 3280 should probably be more clear about this.

> 2.  Name constraints with other empty values
> 
> What is the meaning of an empty (zero length) value for the
> RFC822 name, DNS name, Uniform Resource Identifier and IP
> Address forms of a name constraint extension?
> 
> An empty value in these fields might be interpreted as matching
> all names of the corresponding type.  Again, this is not very
> useful in the permitted subtrees area, but might be use to
> disallow all names of that type by including the empty value
> in the excluded subtrees field.
>
> For RFC822, DNS and URI types, the empty value seems equivalent
> to "." (just the dot).  Do current implementations interpret
> that string as matching all names?  For IP addresses, there is
> already a mechanism to match all names (an all-zero "subnet"
> mask value) so I would be tempted to declare that an empty value
> is invalid (see the following question).

A strict reading of section 4.2.1.11 of RFC 3280 seems to
indicate that an empty value for rfc822Name indicates all
mailboxes on the root domain (since the root domain has
a null string for its name). A value of "." would indicate
all mailboxes in all domains except the root domain.

A strict reading with respect to an empty DNS name would
say that it indicates all DNS names. And a strict reading
with respect to an empty URI name would say that it indicates
only URIs whose host part is empty.

And RFC 3280 says clearly that a name constraint whose syntax
is iPAddress MUST have a length of 8 or 32 bytes (for IPv4
and IPv6 addresses). So a zero length IP address name constraint
is definitely invalid.

I agree with you that it would be useful to have an easy
way to indicate "all names" for each name type. This would
make it easier to exclude all rfc822Names in subsequent certs,
for instance. In the case of Distinguished Names and IP
addresses, this is already provided for in the current
spec (although it could be clearer for DNs). I don't think
it would be a problem if a subsequent draft of RFC 3280
changed (or clarified) the meaning of an empty name constraint
of type rfc822Name, dNSName, and uniformResourceIdentifier
to say that this value should match all names of that name
type. Why wouldn't this be a problem? Because I suspect that
no certs have been issued with such name constraints.

It would also be nice to have a way for a CA to say "no names
except in these explicitly listed types". I don't think there's
any way to do that with name constraints as currently defined.
If enough people think this is important, perhaps a new flag
for this could be added.

> 3. Name constraints with badly formed name values
> 
> What is the correct handling of a name constraint that contains
> invalid data?  Should the constraint value ever match?  What if
> the incorrect value is in the excluded subtrees field?

If any field in a certificate is badly formed or incorrectly
encoded and it's not possible to unambiguously determine
the intent of the certificate issuer, then I'd say the
relying party should discard the certificate.

> Since it is the CAs responsibility to put the correct values
> into the name constraints that are needed to enforce the
> issuance policy, I think it is reasonable for applications
> to ignore name constraints values that don't make sense.

Maybe. But maybe the CA is using a later version of the spec
that defines some new meaning for this previously malformed
value. Or maybe the CA has a private understanding with relying
parties within its domain about what this value means. And
the relying party that doesn't understand the value just
hasn't been upgraded yet.

I think it's pretty dangerous to ignore values in critical
extensions if you don't understand them.

Thanks,

Steve

Date: Wed, 11 Jun 2003 11:19:06 -0400
From: Steve Hanna <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: son-of-rfc3280 (grandson-of-rfc2459)
Sender: [email-masked]

Russ Housley wrote:
> I believe that an update to RFC 3280 is needed.

I think this is a great idea. As RFC 3280 interoperability
testing proceeds, we will have a list of minor glitches and
clarifications for RFC 3280 that need to be fixed. In fact,
I have a long list already. As long as we avoid making any
disruptive changes to the document (and assuming that
interoperability testing goes well), maybe son-of-3280 can be
published as a Draft Standard. I hope so!

As for UTF8 handling, I'm not sure that RFC 3280 is unclear.
It's just not very demanding (since it allows people to just
do a binary comparison when matching UTF8Strings). Maybe it
could/should be clearer in saying that relying parties MUST
support UTF8String. Right now it says that UTF8String is the
preferred encoding and that all certs issued after December
31, 2003 MUST use UTF8String. It seems to follow pretty clearly
that relying parties MUST be able to handle UTF8String. But
maybe that isn't clear enough. It would be nice if it was
explicit.

I do think that we should have another document that talks
about how to handle UTF8String properly, beyond binary matching.
Binary matching for UTF8String was OK in 1999 (maybe), but
it's certainly not any more. PKI usage in Japan and Korea is
moving along quickly and poor support for UTF8String is holding
it back.

Fortunately, a lot of work has already been done on defining
proper handling for UTF8String in X.500 names. Kurt Zeilenga
and others from the IETF have been working with the ITU/ISO
X.500 team to develop a clear algorithm for UTF8String matching,
based on the work of the Internationalized Domain Names working
group (RFC 3454, etc.). The ldapbis working group has a new
Internet Draft (draft-ietf-ldapbis-strprep-00.txt) that describes
this algorithm and how it should be used in LDAP. Something
similar should be done for PKIX. I don't think this is ready
to jump into son-of-3280, since I don't think we have enough
implementation and deployment experience yet. But it could go
Proposed Standard while son-of-3280 goes Draft Standard. And
maybe it could catch up eventually.

Who will be the primary editor for son-of-3280? Will you be
able to fit it into your busy schedule? I hope so. You did
a great job with RFC 3280.

Thanks,

Steve Hanna

Russ Housley wrote:
> 
> Dear PKIX WG:
> 
> I believe that an update to RFC 3280 is needed.  There are three major
> reasons that I believe an update is necessary:
> 
> 1.  ITU-T is looking at changes to X.509 key usage extension.  The text in
> RFC 3280 section 4.2.1.3 has lead to a debate, which is not completely
> resolved.  Hoyt Kesterson has agreed to let the PKIX WG comment on the
> proposed text prior to publication.  So, once everyone is equally unhappy
> with the text, then both the ITU-T and the IETF should update their
> respective documents.
> 
> 2.  Issues with UTF8 needs to be handled more clearly.  I believe that this
> should not be done until all of the issues associated with the use of UTF8
> in DNS are resolved.  I believe that certificates must use many of the same
> string comparison mechanisms as the DNS, and two solutions are unacceptable.
> 
> 3.  Correct the error in section 6.3.3.  (see
> http://www.rfc-editor.org/errata.html).
> 
> Speaking as a co-author of RFC 3280, not as the Security Area Director,
>     Russ

Date: Wed, 11 Jun 2003 16:22:18 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
Sender: [email-masked]

David,

Thank you for this very prompt response.

> Denis,
> 
> I believe that RFC 3280 is quite clear on this issue.  If the 
> certificate does not include a cRLDistributionPoints extension with 
> cRLIssuer present, then the CRL used to determine the certificate's 
> status must have the same issuer name as the certificate:
> 
>     6.3.3  CRL Processing
> 
>        For each distribution point (DP) in the certificate CRL distribution
>        points extension, for each corresponding CRL in the local CRL cache,
>        while ((reasons_mask is not all-reasons) and (cert_status is
>        UNREVOKED)) perform the following:
>
>           (a) ...
> 
>           (b)  Verify the issuer and scope of the complete CRL as follows
> 
>              (1)  If the DP includes cRLIssuer, then verify that the issuer
>              field in the complete CRL matches cRLIssuer in the DP and that
>              the complete CRL contains an issuing distribution point
>              extension with the indrectCRL boolean asserted.  Otherwise,
>              verify that the CRL issuer matches the certificate issuer.
> 
>        ...
> 
>        If the revocation status has not been determined, repeat the process
>        above with any available CRLs not specified in a distribution point
>        but issued by the certificate issuer.  

This text only mentions the case of a CRL issued by the CA, not the case of 
a CRL issued by a CRL Issuer nominated by the CA. So implicitly the case of 
a CRL issuer without a CDP does not exist.

 >        For the processing of such a
>        CRL, assume a DP with both the reasons and the cRLIssuer fields
>        omitted and a distribution point name of the certificate issuer.
>        That is, the sequence of names in fullName is generated from the
>        certificate issuer field as well as the certificate issuerAltName
>        extension.

> So, if the cRLDistributionPoints extension is absent, revocation status 
> must be determined as specified in the final paragraph of 6.3.3 which 
> states that the CRL issuer and certificate issuer must match (this is 
> stated in the first sentence and backed up in the second sentence which 
> states that the CRL should be processed as if the certificate included a 
> CDP with the cRLIssuer field absent).  Step (b)(1) states that if the 
> cRLIssuer field is absent, the certificate and CRL issuer names must match.

Thank you for the clarification. This answers my main question.

So I understand, when no CDP is being used, that different keys can still be 
used for cert signing and CRL signing, as long as the CA name is the same.

A minor point: in section 5.2.5 Issuing Distribution Point we still have:

     The CRL issuer MUST assert the indirectCRL boolean, if the scope of
     the CRL includes certificates issued by authorities other than the
     CRL issuer.

Certificates are NOT issued by CRL issuers. Isn't there some typo here ?

Denis

> Dave
> 
> Denis Pinkas wrote:
> 
>> David,
>>
>> It has been a long time since we exchanged e-mails on delta CRLs. :-)
>>
>>> Juergen,
>>>
>>> What you are describing below is an indirect CRL, a CRL that covers 
>>> certificates issued different entity.  (I know you stated that same 
>>> CA issues both the certificates and the CRL, but since the issuer 
>>> names are different, they are considered different entities.  
>>> Furthermore, there is no way for a relying party to know whether the 
>>> certificate issuer and CRL issuer are the same entity).
>>>
>>> Usually, a CRL can not be used to determine the status of a 
>>> certificate unless the certificate and CRL both have the same issuer 
>>> name.  The value of the AKI extension does not matter, as it is only 
>>> a hint that can aid in building paths and in selecting the right CRL.
>>>
>>> In order to allow a relying party to use a CRL to determine the 
>>> status of a certificate where the issuer names differ, you need to do 
>>> the following:
>>>
>>> 1) Each certificate issued by "CA1" must include a 
>>> cRLDistributionPoints extension with a cRLIssuer field that indicates 
>>> that "CRL1" is the CRL issuer.
>>>
>>> 2) The CRLs issued by "CRL1" must include an issuingDistributionPoint 
>>> extension with the indirectCRL flag set to TRUE.
>>>
>>> 3)  If any of CA1's certificates have been revoked, the 
>>> certificateIssuer CRL entry extension must be used within the CRLs 
>>> issued by "CRL1" to indicate that list of revoked serial numbers are 
>>> of certificates issued by "CA1" (see RFC 3280 for details on the use 
>>> of these three extensions).
>>
>>
>> While what is above is true, I wonder that is the *only* case "to 
>> allow a relying party to use a CRL to determine the status of a 
>> certificate where the issuer names differ".
>>
>> In particular, if CDP are *not* used, then it is still possible to 
>> have a CRL issuer.
>>
>> RFC 3280 states:
>>
>>    CRL issuer: an optional system to which a CA delegates the
>>                publication of certificate revocation lists;
>>
>>    CRL issuers issue CRLs.  In general, the CRL issuer is the CA.
>>    CAs publish CRLs to provide status information about the certificates
>>    they issued.  However, a CA may delegate this responsibility to
>>    another trusted authority.  Whenever the CRL issuer is not the CA
>>    that issued the certificates, the CRL is referred to as an indirect
>>    CRL.
>>
>> The wording may be confusing. A CRL issuer name is a name that is 
>> different from the name of the CA. However, since the CA may delegate 
>> the publication of the CRLs to a CRL issuer, is it still the CA or a 
>> CRL issuer ? I would think the later.
> 
> A CA may delegate CRL issuing, but must use the cRLIssuer field of the 
> cRLDistributionPoints extension to indicate that it has done so.
> 
>>    Whenever the CRL issuer is not the CA that issued the certificates,
>>    the CRL is referred to as an indirect CRL.
>>
>> I wonder whether the wording indirect CRL is fine, since it has a 
>> different meaning in section 5.2.5  Issuing Distribution Point.
>>
>>    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>>    the CRL includes certificates issued by authorities other than the
>>    CRL issuer.
>>
>> The indirectCRL boolean flag is something that may be present or 
>> absent in what is currently called a indirect CRL. A little bit 
>> confusing. A change or a clarification would be apropriate. 
> 
> If the indirectCRL flag is absent, then the CRL is not an indirect CRL.  
> If the indirectCRL flag is not set to TRUE, then the CRL may only covers 
> certificates issued by the CRL issuer.  Such a CRL is not an indirect CRL.
> 
>>
>>> While the rules for issuing and processing indirect CRLs are 
>>> specified in RFC 3280, RFC 3280 compliant clients are not required to 
>>> be able to process indirect CRLs.
>>
>>
>> Section 6.3 CRL Validation is almost silent on how to determine that 
>> the CRL is the right one, in particular when the CRL issuer name is 
>> different from the CA name and when no CDP is being used. The only 
>> guidance is:
>>
>> " (f)  Obtain and validate the certification path for the complete CRL 
>> issuer."
>>
>> I would assume that this means find out a certificate issued by the CA 
>> which has issued the certificate to be tested and which includes the 
>> cRLSign bit 6 in the keyUsage extension. Then, use that certificate to 
>> validate CRLs that seem to be originating from that CRL issuer name.
>>
>> It would be useful to include such additional information in a revised 
>> version of RFC 3280.
>>
>>    Conforming applications are NOT
>>    REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
>>    with a scope other than all certificates issued by one CA.
>>
>> Conforming applications are certainly not required to be able to 
>> process the indirectCRL boolean, when CDP are being used. What does 
>> mean however mean "not required to processing of indirect CRLs" in 
>> case the CA nominates a single CRL issuer ?
>>
>> Denis
>>
>>
>>> Dave
>>>
>>> Juergen Brauckmann wrote:
>>>
>>>> Hi.
>>>>
>>>> I have a question regarding the naming scheme for CRLs. Consider the
>>>> following:
>>>>
>>>> EE certificates are issued by a CA, Issuer-DN "CA1".
>>>> The CA uses a CA certificate issued by a root ca: Issuer-DN "Root1",
>>>> Subject-DN "CA1", serialnumber "1".
>>>> The CA issues CRLs, and signs them with a CRL certificate wich was also
>>>> issued by a root CA, but with another distinguished name than the main
>>>> CA certificate: Issuer-DN "Root1", Subject-DN "CRL1", serialnumber "2"
>>>>
>>>> Is an RFC 3280 compliant client supposed to be able to process the CRLs
>>>> if the CRL Issuer-DN is set to "CA1" and the CRL contains an
>>>> AuthorityKeyIdentifier pointing to the CRL certificate with Subject-DN
>>>> "CRL1"?
>>>>
>>>> Is this scheme, where the issuer name from CRL does not match 
>>>> Subject DN
>>>> from CRL signing certificate, covered by step f) from chapter 6.3.3 
>>>> from
>>>> RFC 3280?
>>>>
>>>> "f) Obtain and validate the certification path for the complete CRL
>>>>   issuer.  If a key usage extension is present in the CRL issuer's
>>>>   certificate, verify that the cRLSign bit is set."
>>>>
>>>>
>>>> Regards,
>>>>   Juergen
>>>>  
>>>>
>>>
>>>
>>
>>
>>
> 

Date: Wed, 11 Jun 2003 09:55:28 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: son-of-rfc3280 (grandson-of-rfc2459)
Cc: [email-masked]
Sender: [email-masked]

Dear PKIX WG:

I believe that an update to RFC 3280 is needed.  There are three major 
reasons that I believe an update is necessary:

1.  ITU-T is looking at changes to X.509 key usage extension.  The text in 
RFC 3280 section 4.2.1.3 has lead to a debate, which is not completely 
resolved.  Hoyt Kesterson has agreed to let the PKIX WG comment on the 
proposed text prior to publication.  So, once everyone is equally unhappy 
with the text, then both the ITU-T and the IETF should update their 
respective documents.

2.  Issues with UTF8 needs to be handled more clearly.  I believe that this 
should not be done until all of the issues associated with the use of UTF8 
in DNS are resolved.  I believe that certificates must use many of the same 
string comparison mechanisms as the DNS, and two solutions are unacceptable.

3.  Correct the error in section 6.3.3.  (see 
http://www.rfc-editor.org/errata.html).

Speaking as a co-author of RFC 3280, not as the Security Area Director,
    Russ

Date: Wed, 11 Jun 2003 09:36:06 -0400
From: "David A. Cooper" <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010106060303010505050502
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Denis,

I believe that RFC 3280 is quite clear on this issue.  If the 
certificate does not include a cRLDistributionPoints extension with 
cRLIssuer present, then the CRL used to determine the certificate's 
status must have the same issuer name as the certificate:

    6.3.3  CRL Processing

       For each distribution point (DP) in the certificate CRL distribution
       points extension, for each corresponding CRL in the local CRL cache,
       while ((reasons_mask is not all-reasons) and (cert_status is
       UNREVOKED)) perform the following:

          (a) ...

          (b)  Verify the issuer and scope of the complete CRL as follows

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

       ...

       If the revocation status has not been determined, repeat the process
       above with any available CRLs not specified in a distribution point
       but issued by the certificate issuer.  For the processing of such a
       CRL, assume a DP with both the reasons and the cRLIssuer fields
       omitted and a distribution point name of the certificate issuer.
       That is, the sequence of names in fullName is generated from the
       certificate issuer field as well as the certificate issuerAltName
       extension.

So, if the cRLDistributionPoints extension is absent, revocation status 
must be determined as specified in the final paragraph of 6.3.3 which 
states that the CRL issuer and certificate issuer must match (this is 
stated in the first sentence and backed up in the second sentence which 
states that the CRL should be processed as if the certificate included a 
CDP with the cRLIssuer field absent).  Step (b)(1) states that if the 
cRLIssuer field is absent, the certificate and CRL issuer names must match.

Dave

Denis Pinkas wrote:

> David,
>
> It has been a long time since we exchanged e-mails on delta CRLs. :-)
>
>> Juergen,
>>
>> What you are describing below is an indirect CRL, a CRL that covers 
>> certificates issued different entity.  (I know you stated that same 
>> CA issues both the certificates and the CRL, but since the issuer 
>> names are different, they are considered different entities.  
>> Furthermore, there is no way for a relying party to know whether the 
>> certificate issuer and CRL issuer are the same entity).
>>
>> Usually, a CRL can not be used to determine the status of a 
>> certificate unless the certificate and CRL both have the same issuer 
>> name.  The value of the AKI extension does not matter, as it is only 
>> a hint that can aid in building paths and in selecting the right CRL.
>>
>> In order to allow a relying party to use a CRL to determine the 
>> status of a certificate where the issuer names differ, you need to do 
>> the following:
>>
>> 1) Each certificate issued by "CA1" must include a 
>> cRLDistributionPoints extension with a cRLIssuer field that indicates 
>> that "CRL1" is the CRL issuer.
>>
>> 2) The CRLs issued by "CRL1" must include an issuingDistributionPoint 
>> extension with the indirectCRL flag set to TRUE.
>>
>> 3)  If any of CA1's certificates have been revoked, the 
>> certificateIssuer CRL entry extension must be used within the CRLs 
>> issued by "CRL1" to indicate that list of revoked serial numbers are 
>> of certificates issued by "CA1" (see RFC 3280 for details on the use 
>> of these three extensions).
>
>
> While what is above is true, I wonder that is the *only* case "to 
> allow a relying party to use a CRL to determine the status of a 
> certificate where the issuer names differ".
>
> In particular, if CDP are *not* used, then it is still possible to 
> have a CRL issuer.
>
> RFC 3280 states:
>
>    CRL issuer: an optional system to which a CA delegates the
>                publication of certificate revocation lists;
>
>    CRL issuers issue CRLs.  In general, the CRL issuer is the CA.
>    CAs publish CRLs to provide status information about the certificates
>    they issued.  However, a CA may delegate this responsibility to
>    another trusted authority.  Whenever the CRL issuer is not the CA
>    that issued the certificates, the CRL is referred to as an indirect
>    CRL.
>
> The wording may be confusing. A CRL issuer name is a name that is 
> different from the name of the CA. However, since the CA may delegate 
> the publication of the CRLs to a CRL issuer, is it still the CA or a 
> CRL issuer ? I would think the later.

A CA may delegate CRL issuing, but must use the cRLIssuer field of the 
cRLDistributionPoints extension to indicate that it has done so.

>    Whenever the CRL issuer is not the CA that issued the certificates,
>    the CRL is referred to as an indirect CRL.
>
> I wonder whether the wording indirect CRL is fine, since it has a 
> different meaning in section 5.2.5  Issuing Distribution Point.
>
>    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>    the CRL includes certificates issued by authorities other than the
>    CRL issuer.
>
> The indirectCRL boolean flag is something that may be present or 
> absent in what is currently called a indirect CRL. A little bit 
> confusing. A change or a clarification would be apropriate. 

If the indirectCRL flag is absent, then the CRL is not an indirect CRL.  
If the indirectCRL flag is not set to TRUE, then the CRL may only covers 
certificates issued by the CRL issuer.  Such a CRL is not an indirect CRL.

>
>> While the rules for issuing and processing indirect CRLs are 
>> specified in RFC 3280, RFC 3280 compliant clients are not required to 
>> be able to process indirect CRLs.
>
>
> Section 6.3 CRL Validation is almost silent on how to determine that 
> the CRL is the right one, in particular when the CRL issuer name is 
> different from the CA name and when no CDP is being used. The only 
> guidance is:
>
> " (f)  Obtain and validate the certification path for the complete CRL 
> issuer."
>
> I would assume that this means find out a certificate issued by the CA 
> which has issued the certificate to be tested and which includes the 
> cRLSign bit 6 in the keyUsage extension. Then, use that certificate to 
> validate CRLs that seem to be originating from that CRL issuer name.
>
> It would be useful to include such additional information in a revised 
> version of RFC 3280.
>
>    Conforming applications are NOT
>    REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
>    with a scope other than all certificates issued by one CA.
>
> Conforming applications are certainly not required to be able to 
> process the indirectCRL boolean, when CDP are being used. What does 
> mean however mean "not required to processing of indirect CRLs" in 
> case the CA nominates a single CRL issuer ?
>
> Denis
>
>
>> Dave
>>
>> Juergen Brauckmann wrote:
>>
>>> Hi.
>>>
>>> I have a question regarding the naming scheme for CRLs. Consider the
>>> following:
>>>
>>> EE certificates are issued by a CA, Issuer-DN "CA1".
>>> The CA uses a CA certificate issued by a root ca: Issuer-DN "Root1",
>>> Subject-DN "CA1", serialnumber "1".
>>> The CA issues CRLs, and signs them with a CRL certificate wich was also
>>> issued by a root CA, but with another distinguished name than the main
>>> CA certificate: Issuer-DN "Root1", Subject-DN "CRL1", serialnumber "2"
>>>
>>> Is an RFC 3280 compliant client supposed to be able to process the CRLs
>>> if the CRL Issuer-DN is set to "CA1" and the CRL contains an
>>> AuthorityKeyIdentifier pointing to the CRL certificate with Subject-DN
>>> "CRL1"?
>>>
>>> Is this scheme, where the issuer name from CRL does not match 
>>> Subject DN
>>> from CRL signing certificate, covered by step f) from chapter 6.3.3 
>>> from
>>> RFC 3280?
>>>
>>> "f) Obtain and validate the certification path for the complete CRL
>>>   issuer.  If a key usage extension is present in the CRL issuer's
>>>   certificate, verify that the cRLSign bit is set."
>>>
>>>
>>> Regards,
>>>   Juergen
>>>  
>>>
>>
>>
>
>
>

--------------010106060303010505050502
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Denis,<br>
<br>
I believe that RFC 3280 is quite clear on this issue.&nbsp; If the
certificate does not include a cRLDistributionPoints extension with
cRLIssuer present, then the CRL used to determine the certificate's
status must have the same issuer name as the certificate:<br>
<blockquote><tt>6.3.3&nbsp; CRL Processing</tt><br>
  <br>
  <tt>&nbsp;&nbsp; For each distribution point (DP) in the certificate CRL
distribution</tt><br>
  <tt>&nbsp;&nbsp; points extension, for each corresponding CRL in the local CRL
cache,</tt><br>
  <tt>&nbsp;&nbsp; while ((reasons_mask is not all-reasons) and (cert_status is</tt><br>
  <tt>&nbsp;&nbsp; UNREVOKED)) perform the following:</tt><br>
  <br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) ...<br>
  <br>
  </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; Verify the issuer and scope of the complete CRL
as follows</tt><br>
  <br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp; If the DP includes cRLIssuer, then verify that the
issuer</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field in the complete CRL matches cRLIssuer in the DP
and that</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the complete CRL contains an issuing distribution point</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extension with the indrectCRL boolean asserted.&nbsp;
Otherwise,</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify that the CRL issuer matches the certificate
issuer.</tt><br>
  <br>
  <tt>&nbsp;&nbsp; ...</tt><br>
  <br>
  <tt>&nbsp;&nbsp; If the revocation status has not been determined, repeat the
process</tt><br>
  <tt>&nbsp;&nbsp; above with any available CRLs not specified in a distribution
point</tt><br>
  <tt>&nbsp;&nbsp; but issued by the certificate issuer.&nbsp; For the processing of
such a</tt><br>
  <tt>&nbsp;&nbsp; CRL, assume a DP with both the reasons and the cRLIssuer fields</tt><br>
  <tt>&nbsp;&nbsp; omitted and a distribution point name of the certificate
issuer.</tt><br>
  <tt>&nbsp;&nbsp; That is, the sequence of names in fullName is generated from
the</tt><br>
  <tt>&nbsp;&nbsp; certificate issuer field as well as the certificate
issuerAltName</tt><br>
  <tt>&nbsp;&nbsp; extension.</tt><br>
</blockquote>
<br>
So, if the cRLDistributionPoints extension is absent, revocation status
must be determined as specified in the final paragraph of 6.3.3 which
states that the CRL issuer and certificate issuer must match (this is
stated in the first sentence and backed up in the second sentence which
states that the CRL should be processed as if the certificate included
a CDP with the cRLIssuer field absent).&nbsp; Step (b)(1) states that if the
cRLIssuer field is absent, the certificate and CRL issuer names must
match.<br>
<br>
Dave<br>
<br>
Denis Pinkas wrote:<br>
<blockquote type="cite" cite="[email-masked]">David, <br>
  <br>
It has been a long time since we exchanged e-mails on delta CRLs. :-) <br>
  <br>
  <blockquote type="cite">Juergen, <br>
    <br>
What you are describing below is an indirect CRL, a CRL that covers
certificates issued different entity.&nbsp; (I know you stated that same CA
issues both the certificates and the CRL, but since the issuer names are
different, they are considered different entities.&nbsp; Furthermore, there
is no way for a relying party to know whether the certificate issuer and
CRL issuer are the same entity). <br>
    <br>
Usually, a CRL can not be used to determine the status of a certificate
unless the certificate and CRL both have the same issuer name.&nbsp; The
value of the AKI extension does not matter, as it is only a hint that
can aid in building paths and in selecting the right CRL. <br>
    <br>
In order to allow a relying party to use a CRL to determine the status
of a certificate where the issuer names differ, you need to do the
following: <br>
    <br>
1) Each certificate issued by "CA1" must include a
cRLDistributionPoints extension with a cRLIssuer field that indicates
that "CRL1" is the CRL issuer. <br>
    <br>
2) The CRLs issued by "CRL1" must include an issuingDistributionPoint
extension with the indirectCRL flag set to TRUE. <br>
    <br>
3)&nbsp; If any of CA1's certificates have been revoked, the
certificateIssuer CRL entry extension must be used within the CRLs
issued by "CRL1" to indicate that list of revoked serial numbers are of
certificates issued by "CA1" (see RFC 3280 for details on the use of
these three extensions). <br>
  </blockquote>
  <br>
While what is above is true, I wonder that is the *only* case "to allow
a relying party to use a CRL to determine the status of a certificate
where the issuer names differ". <br>
  <br>
In particular, if CDP are *not* used, then it is still possible to have
a CRL issuer. <br>
  <br>
RFC 3280 states: <br>
  <br>
&nbsp;&nbsp; CRL issuer: an optional system to which a CA delegates the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; publication of certificate revocation lists; <br>
  <br>
&nbsp;&nbsp; CRL issuers issue CRLs.&nbsp; In general, the CRL issuer is the CA. <br>
&nbsp;&nbsp; CAs publish CRLs to provide status information about the
certificates <br>
&nbsp;&nbsp; they issued.&nbsp; However, a CA may delegate this responsibility to <br>
&nbsp;&nbsp; another trusted authority.&nbsp; Whenever the CRL issuer is not the CA <br>
&nbsp;&nbsp; that issued the certificates, the CRL is referred to as an indirect <br>
&nbsp;&nbsp; CRL. <br>
  <br>
The wording may be confusing. A CRL issuer name is a name that is
different from the name of the CA. However, since the CA may delegate
the publication of the CRLs to a CRL issuer, is it still the CA or a
CRL issuer ? I would think the later.</blockquote>
A CA may delegate CRL issuing, but must use the cRLIssuer field of the
cRLDistributionPoints extension to indicate that it has done so.<br>
<blockquote type="cite" cite="[email-masked]">&nbsp;&nbsp; Whenever
the CRL issuer is not the CA that issued the certificates, <br>
&nbsp;&nbsp; the CRL is referred to as an indirect CRL. <br>
  <br>
I wonder whether the wording indirect CRL is fine, since it has a
different meaning in section 5.2.5&nbsp; Issuing Distribution Point. <br>
  <br>
&nbsp;&nbsp; The CRL issuer MUST assert the indirectCRL boolean, if the scope of <br>
&nbsp;&nbsp; the CRL includes certificates issued by authorities other than the <br>
&nbsp;&nbsp; CRL issuer. <br>
  <br>
The indirectCRL boolean flag is something that may be present or absent
in what is currently called a indirect CRL. A little bit confusing. A
change or a clarification would be apropriate. </blockquote>
If the indirectCRL flag is absent, then the CRL is not an indirect
CRL.&nbsp; If the indirectCRL flag is not set to TRUE, then the CRL may only
covers certificates issued by the CRL issuer.&nbsp; Such a CRL is not an
indirect CRL.<br>
<blockquote type="cite" cite="[email-masked]"><br>
  <blockquote type="cite">While the rules for issuing and processing
indirect CRLs are specified in RFC 3280, RFC 3280 compliant clients
are not required to be able to process indirect CRLs. <br>
  </blockquote>
  <br>
Section 6.3 CRL Validation is almost silent on how to determine that
the CRL is the right one, in particular when the CRL issuer name is
different from the CA name and when no CDP is being used. The only
guidance is: <br>
  <br>
" (f)&nbsp; Obtain and validate the certification path for the complete CRL
issuer." <br>
  <br>
I would assume that this means find out a certificate issued by the CA
which has issued the certificate to be tested and which includes the
cRLSign bit 6 in the keyUsage extension. Then, use that certificate to
validate CRLs that seem to be originating from that CRL issuer name. <br>
  <br>
It would be useful to include such additional information in a revised
version of RFC 3280. <br>
  <br>
&nbsp;&nbsp; Conforming applications are NOT <br>
&nbsp;&nbsp; REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs <br>
&nbsp;&nbsp; with a scope other than all certificates issued by one CA. <br>
  <br>
Conforming applications are certainly not required to be able to
process the indirectCRL boolean, when CDP are being used. What does
mean however mean "not required to processing of indirect CRLs" in
case the CA nominates a single CRL issuer ? <br>
  <br>
Denis <br>
  <br>
  <br>
  <blockquote type="cite">Dave <br>
    <br>
Juergen Brauckmann wrote: <br>
    <br>
    <blockquote type="cite">Hi. <br>
      <br>
I have a question regarding the naming scheme for CRLs. Consider the <br>
following: <br>
      <br>
EE certificates are issued by a CA, Issuer-DN "CA1". <br>
The CA uses a CA certificate issued by a root ca: Issuer-DN "Root1", <br>
Subject-DN "CA1", serialnumber "1". <br>
The CA issues CRLs, and signs them with a CRL certificate wich was also <br>
issued by a root CA, but with another distinguished name than the main <br>
CA certificate: Issuer-DN "Root1", Subject-DN "CRL1", serialnumber "2" <br>
      <br>
Is an RFC 3280 compliant client supposed to be able to process the CRLs <br>
if the CRL Issuer-DN is set to "CA1" and the CRL contains an <br>
AuthorityKeyIdentifier pointing to the CRL certificate with Subject-DN <br>
"CRL1"? <br>
      <br>
Is this scheme, where the issuer name from CRL does not match Subject
DN <br>
from CRL signing certificate, covered by step f) from chapter 6.3.3
from <br>
RFC 3280? <br>
      <br>
"f) Obtain and validate the certification path for the complete CRL <br>
&nbsp; issuer.&nbsp; If a key usage extension is present in the CRL issuer's <br>
&nbsp; certificate, verify that the cRLSign bit is set." <br>
      <br>
      <br>
Regards, <br>
&nbsp; Juergen <br>
&nbsp; <br>
      <br>
    </blockquote>
    <br>
    <br>
  </blockquote>
  <br>
  <br>
  <br>
</blockquote>
<br>
</body>
</html>

--------------010106060303010505050502--

Date: Thu, 12 Jun 2003 01:20:33 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Possible deficiency in the current OCSP Standard (RFC 2560)
Sender: [email-masked]

"Ryan M. Hurst" <[email-masked]> writes:

>Nabil - Here is my stance on that, I believe the problem is actually in the
>responseStatus structure, I think there should be a notAuthoritative
>response.

I had to look at exactly the same issue in RTCS, the solution to this is
pretty simple:

-- Snip --

3.2.2.3 Extended status non-authoritative response

This response type may appear when the response is non-authoritative.  This
situation may occur when the responder being queried obtains information by
chaining to another, authoritative responder (an origin server in HTTP
terminology) which is temporarily unavailable.  Authoritative responders MUST
NOT return the statusNonAuthoritative status.  Non-authoritative responders
may either indicate that no authoritative response is available by omitting
the NonAuthoritativeInfo, or provide a non-authoritative response (for example
from cached data) in NonAuthoritativeInfo:

  NonAuthCertStatus ::= CertStatus ( EXCEPT statusNonAuthoritative )

  NonAuthoritativeInfo ::= SEQUENCE {
    lastAuthTime     RelativeTime,
    status           RESPONSEINFO.&status({ NonAuthCertStatus }),
    statusInfo       RESPONSEINFO.&StatusInfo({ NonAuthCertStatus }{ @status })
    }

  lastAuthTime indicates the time at which the last authoritative response was
  obtained.

-- Snip --

In other words you just encapsulate a standard response inside a wrapper
indicating that it's non-authoritative (the response info is optional if no
info at all is available, not shown above).

The rationale is:

-- Snip --

Responders can be operated in one of two modes.  In the most common mode, the
responder is authoritative and returns responses directly from the certificate
store or a shapshot of the certificate store.  In the less common mode, the
responder acts as an access concentrator/transaction coordinator/proxy for
other responders.  The following discussion of non-authoritative responses and
responders borrows from DNS concepts and terminology, which faces a similar
situation when handling DNS queries.

When a responder is non-authoritative, it may not be able to return a response
to a query directly from the authoritative source, or for performance reasons
may return a cached response, just as with DNS and HTTP servers.  In this case
the responder can return the last authoritative response, along with an
indication as to how low ago the response was authoritative.  The relying
party can then make a decision, based on the age of the cached response and
the value of the data involved, to rely on the cached information or to wait
for a fresh, authoritative response to become available.

Note that the use of the term "authoritative" differs slightly from its use in
DNS.  In DNS, cacheing for load-distribution purposes is very common, and
mechanisms to handle it are built ito the DNS, whereas with RTCS it would only
be used when there isn't a requirement for a hard real-time response.
However, RTCS can return an authoritative response (via an access
concentrator/transaction coordinator/proxy) without the responder which is
being queried itself being authoritative.  In HTTP terminology, the source of
the authoritative response is an origin server, with caches acting as
intermediaries to improve performance.  In this case the response is regarded
as being authoritative, since it is being forwarded from an authoritative
source/origin server. Only a cached response is non-authoritative.  This
differs from DNS, where the authority of an answer and the authority of a DNS
server are synonymous.  Further discussion of this style of cacheing model may
be found in section 13 of [RFC2068].  This document is recommended reading for
anyone considering the use of response cacheing for RTCS performance
enhancement purposes.

-- Snip --

Peter.

Date: Wed, 11 Jun 2003 12:40:32 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
Sender: [email-masked]

David,

It has been a long time since we exchanged e-mails on delta CRLs. :-)

> Juergen,
> 
> What you are describing below is an indirect CRL, a CRL that covers 
> certificates issued different entity.  (I know you stated that same CA 
> issues both the certificates and the CRL, but since the issuer names are 
> different, they are considered different entities.  Furthermore, there 
> is no way for a relying party to know whether the certificate issuer and 
> CRL issuer are the same entity).
> 
> Usually, a CRL can not be used to determine the status of a certificate 
> unless the certificate and CRL both have the same issuer name.  The 
> value of the AKI extension does not matter, as it is only a hint that 
> can aid in building paths and in selecting the right CRL.
> 
> In order to allow a relying party to use a CRL to determine the status 
> of a certificate where the issuer names differ, you need to do the 
> following:
> 
> 1) Each certificate issued by "CA1" must include a cRLDistributionPoints 
> extension with a cRLIssuer field that indicates that "CRL1" is the CRL 
> issuer.
> 
> 2) The CRLs issued by "CRL1" must include an issuingDistributionPoint 
> extension with the indirectCRL flag set to TRUE.
> 
> 3)  If any of CA1's certificates have been revoked, the 
> certificateIssuer CRL entry extension must be used within the CRLs 
> issued by "CRL1" to indicate that list of revoked serial numbers are of 
> certificates issued by "CA1" (see RFC 3280 for details on the use of 
> these three extensions).

While what is above is true, I wonder that is the *only* case "to allow a 
relying party to use a CRL to determine the status of a certificate where 
the issuer names differ".

In particular, if CDP are *not* used, then it is still possible to have a 
CRL issuer.

RFC 3280 states:

    CRL issuer: an optional system to which a CA delegates the
                publication of certificate revocation lists;

    CRL issuers issue CRLs.  In general, the CRL issuer is the CA.
    CAs publish CRLs to provide status information about the certificates
    they issued.  However, a CA may delegate this responsibility to
    another trusted authority.  Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

The wording may be confusing. A CRL issuer name is a name that is different 
from the name of the CA. However, since the CA may delegate the publication 
of the CRLs to a CRL issuer, is it still the CA or a CRL issuer ? I would 
think the later.

    Whenever the CRL issuer is not the CA that issued the certificates,
    the CRL is referred to as an indirect CRL.

I wonder whether the wording indirect CRL is fine, since it has a different 
meaning in section 5.2.5  Issuing Distribution Point.

    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
    the CRL includes certificates issued by authorities other than the
    CRL issuer.

The indirectCRL boolean flag is something that may be present or absent in 
what is currently called a indirect CRL. A little bit confusing. A change or 
a clarification would be apropriate.

> While the rules for issuing and processing indirect CRLs are specified 
> in RFC 3280, RFC 3280 compliant clients are not required to be able to 
> process indirect CRLs.

Section 6.3 CRL Validation is almost silent on how to determine that the CRL 
is the right one, in particular when the CRL issuer name is different from 
the CA name and when no CDP is being used. The only guidance is:

" (f)  Obtain and validate the certification path for the complete CRL issuer."

I would assume that this means find out a certificate issued by the CA which 
has issued the certificate to be tested and which includes the cRLSign bit 6 
in the keyUsage extension. Then, use that certificate to validate CRLs that 
seem to be originating from that CRL issuer name.

It would be useful to include such additional information in a revised 
version of RFC 3280.

    Conforming applications are NOT
    REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
    with a scope other than all certificates issued by one CA.

Conforming applications are certainly not required to be able to process the 
indirectCRL boolean, when CDP are being used. What does mean however mean 
"not required to processing of indirect CRLs" in case the CA nominates a 
single CRL issuer ?

Denis

> Dave
> 
> Juergen Brauckmann wrote:
> 
>> Hi.
>>
>> I have a question regarding the naming scheme for CRLs. Consider the
>> following:
>>
>> EE certificates are issued by a CA, Issuer-DN "CA1".
>> The CA uses a CA certificate issued by a root ca: Issuer-DN "Root1",
>> Subject-DN "CA1", serialnumber "1".
>> The CA issues CRLs, and signs them with a CRL certificate wich was also
>> issued by a root CA, but with another distinguished name than the main
>> CA certificate: Issuer-DN "Root1", Subject-DN "CRL1", serialnumber "2"
>>
>> Is an RFC 3280 compliant client supposed to be able to process the CRLs
>> if the CRL Issuer-DN is set to "CA1" and the CRL contains an
>> AuthorityKeyIdentifier pointing to the CRL certificate with Subject-DN
>> "CRL1"?
>>
>> Is this scheme, where the issuer name from CRL does not match Subject DN
>> from CRL signing certificate, covered by step f) from chapter 6.3.3 from
>> RFC 3280?
>>
>> "f) Obtain and validate the certification path for the complete CRL
>>   issuer.  If a key usage extension is present in the CRL issuer's
>>   certificate, verify that the cRLSign bit is set."
>>
>>
>> Regards,
>>   Juergen
>>  
>>
> 
> 

Date: Tue, 10 Jun 2003 11:45:12 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: rfc316: PKIStatus
Sender: [email-masked]

Welcome in the world of time stamping. 

> Hi all,
> 
> I have one question for you. I find difficulties in understanding the meaning
> of the revocationWarning PKIStatus. Indeed I wonder what this field is
> intended to mean. As reported on the rfc:
> 
>      revocationWarning      (4),
>       -- this message contains a warning that a revocation is
>       -- imminent
> 
> In details my doubts are about:
> 
> 	o What revocation is imminent (of the CA certificate? of the
> 	  TSA certificate ? or what ?). Or, this means that a new CRL is
> 	  "imminent" ?
> 
> 	o What is to be considered "imminent" ? (next few seconds, hours
> 	  or days ?)
> 
> Thanks for all the help you can give me.
> 
> -- 
> 
> Best Regards,
> 
> 	Massimiliano Pala

The definition of PKIStatus was copied unmodified from CMP
into draft version 7 of 3161, and all previous texts
explaining which fields are set etc had been simply removed.

in draft 4 one still had:

> When the PKIStatusInfo contains the value zero a Time Stamp Token is 
> present. Otherwise, the status indicates the reason why the time stamp 
> request was rejected.

and in the 

in draft 1 the text was

> PKIStatusInfo is defined in Section 3.2.3 of [RFC2510]. A valid time 
> stamp token will always have value 0 (granted) in the PKIStatus field of 
> PKIStatusInfo.  If the PKIStatus field has value `waiting' (3), then 
> this token is a receipt, as defined in Section 2.1.  Otherwise, the 
> status field is present to indicate whether or not the time stamping 
> request was fulfilled and, if not, the reason it was rejected. Since not 
> all environments will require the use of receipts, support for the value 
> `waiting' is OPTIONAL.

I cannot remember any discussion for having other values than 0 and 2
except maybe 1. 

Have fun.
Peter

Date: Mon, 09 Jun 2003 17:53:31 -0400
From: Steve Hanna <[email-masked]>
To: PKIX List <[email-masked]>
Subject: OASIS Survey on PKI Obstacles
Sender: [email-masked]

The OASIS Public Key Infrastructure Technical Committee
(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pki)
is dedicated to addressing issues related to the successful
deployment of digital certificates.

As part of this mission, we are conducting a web-based survey
to identify the key barriers to PKI deployment and usage so
that they can be addressed. If you have expertise or experience
with PKI or certificates, we invite you to participate in
this survey by going to:

http://www.oasis-open.org/committees/pki/pkiobstacles.html

This survey will only be available from June 9 to June 22,
so please act promptly. Only respond to the survey once.
Feel free to forward this invitation to other people with
PKI expertise or experience. But please don't forward it
to the press or post it on Slashdot. If you have questions
about the survey, send email to our co-chair, Steve Hanna,
at [email-masked].

Thanks,

The OASIS PKI Technical Committee

------

Privacy Note: The data collected in this survey will only
be reported in aggregate form. Individual responses
will be used by OASIS PKI TC members and OASIS staff members
in tabulating our results. If you choose to provide your
email address (optional), we will send you a copy of the
survey results and invitations to participate in future
surveys conducted by the OASIS PKI TC. But your email address
will not be used for any other purposes or disclosed to
anyone outside of OASIS.

Content-class: urn:content-classes:message
Subject: RE: Possible deficiency in the current OCSP Standard (RFC 2560)
Date: Mon, 9 Jun 2003 14:41:39 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Nabil Ghadiali" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Nabil - Here is my stance on that, I believe the problem is actually in
the responseStatus structure, I think there should be a notAuthoritative
response. 

You see 2560, indicates response pre-production is a reasonable thing;
in-fact I don't think it's possible to scale to internet volumes without
this concept. But for it to be practical one needs to be able to return
an un-signed response indicating that that responder is not
authoritative for the certificates being queried. 

This has some potential issues with scenarios where a single response
caries CertIds from multiple CAs and only one is "unknown" but
in-practice I don't know how realistic that scenario is in the most
common CA signed and CA delegated models since discovery happens via a
AIA. If this was something that needed to be supported (which I do not
think is the case) a responseStatus of notAuthoritative would be needed
for the cases when the responder could respond for none of the
referenced CertID's and a new CertStatus of notAuthoritative would also
be needed. I personally think this adds un-needed complexity given the
protocols usage but it could be done none the less.

The existing protocol implies that a responder that pre-produces
generate a signed basic responses for all unknown certificates which
negates the value of pre-production. As such responders that support
this today return a responseStatus of notAuthorized to save the signing
operation.

As for your specific query of how does a responder indicate
authoritatively he doesn't have the answer now but may in the future? I
think the existing unknown status is appropriate for that. In-fact in my
experience that is exactly how it's been interpreted by the
implementations I have seen.

As for tryAgainLater, this is (in my opinion) more for server issues
e.g. database rebuild, server re-start, etc.

Ryan M. Hurst
Program Manager
Windows Trusted Platform Infrastructure
Microsoft Corporation
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nabil Ghadiali
Sent: Monday, June 09, 2003 10:14 AM
To: [email-masked]
Subject: Possible deficiency in the current OCSP Standard (RFC 2560)

Our view is that there is a possible deficiency in the standard (RFC
2560)
in that the "CertStatus" field for each certificate (contained in an
OCSP
Response) does not provide an appropriate value to indicate that the
certificate status is temporarily unavailable.

We would recommend that the OCSP standard be updated to add another
value as
a possible "CertStatus", clearly indicating that the Responder knows
about
this CA, but cannot respond at this moment. One could propose a
recommendation to update this standard with another explicit
"CertStatus"
along with the "Good", "Revoked" and "Unknown", for example,
"temporarilyUnavailable".

1. Background
-------------------
An OCSP request can contain status requests for more than one
certificate.
Hence the OCSP response can also provide status for more than one
certificate. The OCSP Response has an overall status field named
"responseStatus" which indicates the overall result of the Response
received. The possible values for "responseStatus" are:
	- successful
	- malformedRequest
	- internalError
	- tryLater
	- sigRequired
	- unauthorized

The OCSP Response also has a field named "CertStatus" for each
certificate
on which status is provided. The possible values for "CertStatus" are:
	- good
	- revoked
	- unknown

The "unknown" state indicates that the Responder doesn't know about the
certificate being requested - (RFC 2560). This could be because 1) the
Responder is not authorized to respond for that particular CA, or 2) the
Responder doesn't have the latest CRL to make a valid Response. Although
this sentence can be interpreted in any which way, both cases fit the
description as per RFC 2560.

In the event that the OCSP Responder is operational, but unable to
return a
status for the requested certificate, the "tryLater" response can be
used to
indicate that the service exists, but is temporarily unable to respond
(RFC
2560) - this could be because the Responder doesn't have the latest CRL
to
make a valid Response.

2. A Working Example with the Possible Options
------------------------------------------------------------------
Let us take an example of an OCSP request sent to a Responder requesting
the
status on 3 certificates issued by 3 different CA's. The Responder has
valid
CRLs for 2 of them, but the last CRL has passed its NextUpdate time.
There
are two ways to handle this issue:

1) If the Responder responds with an overall  "responseStatus of
"tryLater",
then the OCSP Client will try again and may get the proper response at a
later time. However, in this case, the first OCSP Response will not
allow
the Client to receive the status of the 2 valid certificates. The client
will interpret the "tryLater" as applicable for all 3 certificates.

2) If the Responder responds with a "responseStatus" of "successful",
and a
"CertStatus" of "good" for the 2 valid certificates and "unknown" for
the
third certificate, this would allow the status of the first two
certificates
to be received by the Client. However, in this case, the Client does not
know how to interpret the "unknown" value for the third certificate
-whether
it is because 1) the CRL was temporarily unavailable to make a valid
response or 2) The Responder does not respond for that CA in the first
place.

Thus each option has its own strengths and weaknesses.

Regards,
Nabil

Nabil Ghadiali
Security Engineer
Electrosoft Services, Inc.
7918 Jones Branch Drive, Suite 600, McLean, VA 22102
Tel:- (703)-918-4905, Tel:- (703)-918-4906 (Direct), Fax:-
(703)-918-4908
www.electrosoft-inc.com

From: "Nabil Ghadiali" <[email-masked]>
To: <[email-masked]>
Subject: Possible deficiency in the current OCSP Standard (RFC 2560)
Date: Mon, 9 Jun 2003 13:13:47 -0400
Importance: Normal
Sender: [email-masked]

Our view is that there is a possible deficiency in the standard (RFC 2560)
in that the “CertStatus” field for each certificate (contained in an OCSP
Response) does not provide an appropriate value to indicate that the
certificate status is temporarily unavailable.

We would recommend that the OCSP standard be updated to add another value as
a possible “CertStatus”, clearly indicating that the Responder knows about
this CA, but cannot respond at this moment. One could propose a
recommendation to update this standard with another explicit “CertStatus”
along with the "Good", "Revoked" and "Unknown", for example,
"temporarilyUnavailable”.

1. Background
-------------------
An OCSP request can contain status requests for more than one certificate.
Hence the OCSP response can also provide status for more than one
certificate. The OCSP Response has an overall status field named
"responseStatus" which indicates the overall result of the Response
received. The possible values for "responseStatus" are:
	- successful
	- malformedRequest
	- internalError
	- tryLater
	- sigRequired
	- unauthorized

The OCSP Response also has a field named "CertStatus" for each certificate
on which status is provided. The possible values for "CertStatus" are:
	- good
	- revoked
	- unknown

The "unknown" state indicates that the Responder doesn't know about the
certificate being requested - (RFC 2560). This could be because 1) the
Responder is not authorized to respond for that particular CA, or 2) the
Responder doesn't have the latest CRL to make a valid Response. Although
this sentence can be interpreted in any which way, both cases fit the
description as per RFC 2560.

In the event that the OCSP Responder is operational, but unable to return a
status for the requested certificate, the "tryLater" response can be used to
indicate that the service exists, but is temporarily unable to respond (RFC
2560) - this could be because the Responder doesn't have the latest CRL to
make a valid Response.

2. A Working Example with the Possible Options
------------------------------------------------------------------
Let us take an example of an OCSP request sent to a Responder requesting the
status on 3 certificates issued by 3 different CA's. The Responder has valid
CRLs for 2 of them, but the last CRL has passed its NextUpdate time. There
are two ways to handle this issue:

1) If the Responder responds with an overall  “responseStatus of "tryLater",
then the OCSP Client will try again and may get the proper response at a
later time. However, in this case, the first OCSP Response will not allow
the Client to receive the status of the 2 valid certificates. The client
will interpret the “tryLater" as applicable for all 3 certificates.

2) If the Responder responds with a “responseStatus” of "successful", and a
“CertStatus” of "good" for the 2 valid certificates and "unknown" for the
third certificate, this would allow the status of the first two certificates
to be received by the Client. However, in this case, the Client does not
know how to interpret the “unknown” value for the third certificate –whether
it is because 1) the CRL was temporarily unavailable to make a valid
response or 2) The Responder does not respond for that CA in the first
place.

Thus each option has its own strengths and weaknesses.

Regards,
Nabil

Nabil Ghadiali
Security Engineer
Electrosoft Services, Inc.
7918 Jones Branch Drive, Suite 600, McLean, VA 22102
Tel:- (703)-918-4905, Tel:- (703)-918-4906 (Direct), Fax:- (703)-918-4908
www.electrosoft-inc.com

Date: Sat, 07 Jun 2003 11:12:10 +0200
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
To: [email-masked]
Subject: rfc316: PKIStatus
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090407000604000905000404
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

I have one question for you. I find difficulties in understanding the meaning
of the revocationWarning PKIStatus. Indeed I wonder what this field is
intended to mean. As reported on the rfc:

     revocationWarning      (4),
      -- this message contains a warning that a revocation is
      -- imminent

In details my doubts are about:

	o What revocation is imminent (of the CA certificate? of the
	  TSA certificate ? or what ?). Or, this means that a new CRL is
	  "imminent" ?

	o What is to be considered "imminent" ? (next few seconds, hours
	  or days ?)

Thanks for all the help you can give me.

-- 

Best Regards,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [email-masked]
                                                  Tel.:   +39 (0)59  270  094
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

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

--------------ms090407000604000905000404--

From: "Hallam-Baker, Phillip" <[email-masked]>
To: 
Cc: [email-masked]
Subject: RE: Last Call: Internet X.509 Public Key Infrastructure:  Logotyp es in X.509 certificates to Proposed Standard
Date: Fri, 6 Jun 2003 08:09:08 -0700 
Sender: [email-masked]

I think this is a very important specification that should be approved.

[And if you want to know why I am saying that read the DNSEXT group]

> -----Original Message-----
> From: The IESG [mailto:[email-masked]]
> Sent: Thursday, June 05, 2003 2:04 PM
> To: IETF-Announce; @mail.imc.org
> Cc: [email-masked]
> Subject: Last Call: Internet X.509 Public Key Infrastructure: 
> Logotypes
> in X.509 certificates to Proposed Standard
> 
> 
> 
> 
> The IESG has received a request from the Public-Key Infrastructure 
> (X.509) Working Group to consider Internet X.509 Public Key 
> Infrastructure: Logotypes in X.509 certificates 
> <draft-ietf-pkix-logotypes-10.txt> as a Proposed Standard.  
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the 
> [email-masked] or [email-masked] mailing lists by 2003-6-19.
> 
> Files can be obtained via 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-10.txt
> 
> 
> 

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Internet X.509 Public Key Infrastructure:  Logotypes in X.509 certificates to Proposed Standard
Reply-to: [email-masked]
Date: Thu, 05 Jun 2003 14:03:36 -0400
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure 
(X.509) Working Group to consider Internet X.509 Public Key 
Infrastructure: Logotypes in X.509 certificates 
<draft-ietf-pkix-logotypes-10.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[email-masked] or [email-masked] mailing lists by 2003-6-19.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-10.txt

From: "todd glassey" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>
Subject: Re: Notice of a new protocol concept.
Date: Wed, 4 Jun 2003 20:36:18 -0700
Sender: [email-masked]

Phillip - actually no it doesn't. This is an auto configuration protocol and
that's not quite what i am talking about here, although you could probably
write policy for my system in XML too I guess.

Todd

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'todd glassey'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 04, 2003 5:52 PM
Subject: RE: Notice of a new protocol concept.

> In which case you should note that Automatic Cryptographic Configuration
> addresses this problem and constitutes prior art.
>
> http://research.verisign.com/Papers/ACC1.html
>
>
> phill
>
> > -----Original Message-----
> > From: todd glassey [mailto:[email-masked]]
> > Sent: Wednesday, June 04, 2003 6:04 PM
> > To: [email-masked]
> > Subject: Notice of a new protocol concept.
> >
> >
> >
> > I am working on a form of one-time tokens that are generated
> > by using a
> > keying system that will allow us to identify through PKI,
> > every component of
> > a computing environment.
> >
> > This is both a system and the API to use it, and lives as
> > part of the BIOS
> > environment of a system. While it is traditionally outside
> > the realm of this
> > group to deal with such low-level services these technologies
> > allow for any
> > end-node in a network to also be described and identified by the same
> > technologies system making it of key interest (pardon the
> > pun) here. In fact
> > I intend to create a PKI Node Identification Protocol to check these
> > services as part of this effort and that will be directly
> > applicable to this
> > WG's efforts.
> >
> > This is a needed step in effecting proper controls for Law
> > Enforcement and
> > as such making the nasties that people perpetrated on computers more
> > prosecutable. The system will allow each piece of a setup to
> > be uniquely
> > identified and as such a forensics' team can detect if any
> > changes in the
> > underlying HW on a particular OS's instance was altered or checked.
> >
> > I intend on filing a patent on this technology as well, and
> > in this case
> > will be allowing open use of the patent for nocom users and
> > very aggressive
> > licensing (probably GPL or Lesser based but no decision has
> > been made yet)
> > so that this will become a real workable system.
> >
> > The idea is that from a security standpoint that without such
> > a system that
> > there was no real way to detect when a computer system had
> > been forensically
> > washed if the person doing the washing was any good. This
> > eliminates this
> > and allows for any number of cool services to be put up based on the
> > end-node enablement and entitlement controls that this enables.
> >
> > If you are interested in this send me a note off the list and
> > I will respond
> > and the draft should be here soon.
> >
> >
> > Todd Glassey
> >
>

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'todd glassey'" <[email-masked]>, [email-masked]
Subject: RE: Notice of a new protocol concept.
Date: Wed, 4 Jun 2003 17:52:44 -0700 
Sender: [email-masked]

In which case you should note that Automatic Cryptographic Configuration
addresses this problem and constitutes prior art.

http://research.verisign.com/Papers/ACC1.html

	phill

> -----Original Message-----
> From: todd glassey [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2003 6:04 PM
> To: [email-masked]
> Subject: Notice of a new protocol concept.
> 
> 
> 
> I am working on a form of one-time tokens that are generated 
> by using a
> keying system that will allow us to identify through PKI, 
> every component of
> a computing environment.
> 
> This is both a system and the API to use it, and lives as 
> part of the BIOS
> environment of a system. While it is traditionally outside 
> the realm of this
> group to deal with such low-level services these technologies 
> allow for any
> end-node in a network to also be described and identified by the same
> technologies system making it of key interest (pardon the 
> pun) here. In fact
> I intend to create a PKI Node Identification Protocol to check these
> services as part of this effort and that will be directly 
> applicable to this
> WG's efforts.
> 
> This is a needed step in effecting proper controls for Law 
> Enforcement and
> as such making the nasties that people perpetrated on computers more
> prosecutable. The system will allow each piece of a setup to 
> be uniquely
> identified and as such a forensics' team can detect if any 
> changes in the
> underlying HW on a particular OS's instance was altered or checked.
> 
> I intend on filing a patent on this technology as well, and 
> in this case
> will be allowing open use of the patent for nocom users and 
> very aggressive
> licensing (probably GPL or Lesser based but no decision has 
> been made yet)
> so that this will become a real workable system.
> 
> The idea is that from a security standpoint that without such 
> a system that
> there was no real way to detect when a computer system had 
> been forensically
> washed if the person doing the washing was any good. This 
> eliminates this
> and allows for any number of cool services to be put up based on the
> end-node enablement and entitlement controls that this enables.
> 
> If you are interested in this send me a note off the list and 
> I will respond
> and the draft should be here soon.
> 
> 
> Todd Glassey
> 

From: "todd glassey" <[email-masked]>
To: <[email-masked]>
Subject: Notice of a new protocol concept.
Date: Wed, 4 Jun 2003 15:03:54 -0700
Sender: [email-masked]

I am working on a form of one-time tokens that are generated by using a
keying system that will allow us to identify through PKI, every component of
a computing environment.

This is both a system and the API to use it, and lives as part of the BIOS
environment of a system. While it is traditionally outside the realm of this
group to deal with such low-level services these technologies allow for any
end-node in a network to also be described and identified by the same
technologies system making it of key interest (pardon the pun) here. In fact
I intend to create a PKI Node Identification Protocol to check these
services as part of this effort and that will be directly applicable to this
WG's efforts.

This is a needed step in effecting proper controls for Law Enforcement and
as such making the nasties that people perpetrated on computers more
prosecutable. The system will allow each piece of a setup to be uniquely
identified and as such a forensics' team can detect if any changes in the
underlying HW on a particular OS's instance was altered or checked.

I intend on filing a patent on this technology as well, and in this case
will be allowing open use of the patent for nocom users and very aggressive
licensing (probably GPL or Lesser based but no decision has been made yet)
so that this will become a real workable system.

The idea is that from a security standpoint that without such a system that
there was no real way to detect when a computer system had been forensically
washed if the person doing the washing was any good. This eliminates this
and allows for any number of cool services to be put up based on the
end-node enablement and entitlement controls that this enables.

If you are interested in this send me a note off the list and I will respond
and the draft should be here soon.

Todd Glassey

Date: Wed, 04 Jun 2003 17:29:31 -0400
From: Steve Hanna <[email-masked]>
To: Matt Cooper <[email-masked]>
CC: PKIX List <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

How would this rule prohibiting the re-use of a subject
key and subject name pair in a chain apply in the presence
of X.500 alt names? Would they be checked also?

I'm not convinced that this rule is worth adding. One big
reason to prohibit loops (identical certs) in a path is that
it's very hard for a builder to know that running through
the loop one more time won't result in a valid path (especially
if policy mapping is on and there are complicated mappings
in the certs in the loop). A small number of certs can cause
a huge amount of work for the builder. This argument doesn't
apply in the case you cited. No cert would ever appear in
the path more than once.

-Steve

Matt Cooper wrote:
> 
> Walt Tuvell noticed and brought to my attention that I left out an important
> detail -
> 
> The basic idea is to not re-use keys at the same point in the cert graph, so
> the rule I proposed should be "Don't re-use the same key and subject name
> pair." This is the same idea (prevents multiple traversals across the
> bridge, policy loops, etc.) but still allows a CA to perform a "name change"
> on itself should the need arise. (For example, as Walt pointed out, during
> migration to DNS naming from X500 naming.)
> 
> For those of you reading this (if any) who may be using one of the path
> builders I put together, never fear, it is implemented with the Key / DN
> pair, not just the key, so name changes should work without a problem.
> 
> Matt Cooper
> Orion Security Solutions
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Matt Cooper
> > Sent: Friday, May 23, 2003 12:32 AM
> > To: [email-masked]; 'PKIX list'
> > Subject: RE: RFC 3280: same certificate in a certification path
> >
> >
> >
> > Very well put!
> >
> > Now, what say you to the assertion that there is no need to
> > repeat keys in a path, much less certificates? There are a
> > couple very attractive properties to such a rule such as
> > preventing multiple traversals through a Bridge CA, or
> > preventing "policy loops" like in your example but more
> > complicated - through multiple CAs and looped back via a
> > different path - duplicate certs not required.
> >
> > I have yet to encounter a real world example where it was
> > necessary to repeat a key. In fact, the last two path
> > builders I wrote used that rule, and they have yet to run
> > into a snag (as far as I know!) in testing or in the wild as
> > a result of that restriction. Your (and others') thoughts
> > would be welcome!
> >
> > Very Best Regards,
> >
> > Matt Cooper
> > Orion Security Solutions
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Steve Hanna
> > > Sent: Monday, May 19, 2003 5:59 AM
> > > To: Eric Norman; PKIX list
> > > Subject: Re: RFC 3280: same certificate in a certification path
> > >
> > >
> > >
> > > Eric Norman wrote:
> > > >To say that a path is prohibited or is invalid does not mean
> > > that the
> > > >answer to the question of trust that you're trying to
> > > establish is "not
> > > >trusted".  What I think the intent is, and what I think
> > > works, is that
> > > >when you say a path is prohibited, you mean that it needn't be
> > > >considered farther because it will contribute nothing more.
> > >
> > > Yes, that's it. There's no reason to consider paths that
> > > contain the same certificate twice because nobody can come up
> > > with any real-world scenario where they have any value. But
> > > if we consider them valid there are some rather preposterous
> > > scenarios where the only valid path would be one that
> > > contains the same certificate twice.
> > >
> > > For instance, in a path CA1->CA2->CA1->CA2->EE where the user's
> > > acceptable policy is High and policy mapping is enabled and
> > CA1->CA2
> > > has HIGH and TOP SECRET policies and maps HIGH to CONF and
> > TOP SECRET
> > > to Z, CA2->CA1 has CONF policy and maps CONF to TOP SECRET, and
> > > CA2->EE has Z policy. See the example in our paper. This
> > example makes
> > > no real world sense, but it shows that if paths with duplicate
> > > certificates are considered valid then path builders must try
> > > them (at least, when policy mapping is involved).
> > >
> > > The best solution, as you suggest, is for people to not just
> > > stick certs together casually, perform path validation, and
> > > give up if it fails. They should move on to try path
> > > building. The path builder will build a valid path if one can
> > > be built (omitting pointless duplicate certificates). But
> > > there's no problem with declaring paths that contain
> > > duplicate certificates to be invalid.
> > >
> > > I'd love to chat more about the interesting theoretical
> > > issues that you raised (and I will return to do so), but I
> > > have to run off to Jury Duty today. I'll catch up with you
> > > tomorrow and we can discuss this more.
> > >
> > > Thanks,
> > >
> > > Steve
> > >
> > > >On Fri, 16 May 2003, Steve Hanna wrote:
> > > >
> > > >> A path that includes the same cert twice might look like this:
> > > >>
> > > >> CA1 -> CA2 -> CA1 -> CA2 -> EE
> > > >
> > > >[for reference below].
> > > >
> > > >> Eric Norman asks why we want to prohibit paths that
> > > contain the same
> > > >> certificate twice. I agree that there's nothing inherently
> > > wrong with
> > > >> such a path. But nobody has been able to show any reason why it's
> > > >> desirable to support such a path. And if we prohibit such
> > > paths, then
> > > >> path builders can be somewhat simpler and more efficient.
> > > They don't
> > > >> have to consider building paths with loops.
> > > >>
> > > >> Eric, do you have a good reason why we should not prohibit
> > > paths that
> > > >> contain the same certificate twice? I don't find
> > > >
> > > >Because they can happen.  There's nothing that will prevent, and
> > > >there's also probably no way to prevent autonomous CAs
> > from creating
> > > >loops in the certificate network.  Ergo, this must be dealt with
> > > >somehow; more below.
> > > >
> > > >> your argument about sticking two paths together
> > convincing. That's
> > > >> not how PKIX path building is generally done, since it
> > > often doesn't
> > > >> work (if one of the certs in the first part of the path
> > > includes name
> > > >> constraints violated by a cert in the second part of the
> > path, for
> > > >> instance).
> > > >
> > > >In fact, the examples chosen here, e.g. the path segment
> > > >CA1 -> CA2 -> CA1  (append another -> CA2 if you prefer) are
> > > precisely
> > > >what happens when two CAs cross certify each other by signing each
> > > >others keys (really attesting to each other's
> > > >identity) and then publish the fact that they have done so with a
> > > >CrossCertificatePair with both parts filled in (e.g. bridge
> > > stuff and
> > > >the like).
> > > >
> > > >Actually, it's even simpler than that.  Continuing with the
> > > distinction
> > > >you're trying to make above, you could just as well have a
> > path like
> > > >CA1 -> CA2 -> CA2 -> CA2 -> CA2 -> CA3. The same certificate
> > > >(self-signed) appears multiple times. However, this path can
> > > be used to
> > > >verify a trust relationship between CA1 and CA3 (just
> > > pretend CA2 never
> > > >issued the self- signed certificate).
> > > >
> > > >I think that we're really talking about here is what exactly
> > > is meant,
> > > >and what is implied, and what will be inferred by implementors when
> > > >they see words like "prohibit", "valid" and so forth.
> > > >
> > > >To say that a path is prohibited or is invalid does not mean
> > > that the
> > > >answer to the question of trust that you're trying to
> > > establish is "not
> > > >trusted".  What I think the intent is, and what I think
> > > works, is that
> > > >when you say a path is prohibited, you mean that it needn't be
> > > >considered farther because it will contribute nothing more.
> > > >
> > > >What my real problem might be is that I think the language
> > > could lead
> > > >to enough confusion for implementors that they'll get it wrong.
> > > >
> > > >The implication this has for constraints is that if
> > they're properly
> > > >designed (and I think they probably are) then when you
> > > encounter some
> > > >constraints a second time (because you've encountered a certificate
> > > >again), then applying the contraints again will yield
> > nothing new.
> > > >Actually, what I really think is that this shouldn't even happen
> > > >because you should create a spanning tree or something like
> > > that before
> > > >you begin the trust evaluation process; i.e. you should never even
> > > >encounter a certificate twice, but if you do, you'll still
> > > get the same
> > > >answer as far as trust.  All that's left is to worry about
> > > >termination when you have loops in the certificate graph.
> > > >
> > > >Hence,
> > > >
> > > >> P.S. Eric, thanks for tooting your own horn. It's good for us to
> > > >> consider and understand earlier work so we don't reinvent things.
> > > >
> > > >FWIW, I'll say a bit more about garbage collection in LISP. If you
> > > >mimic the simplistic recursive descent -- leave spoor
> > > everywhere
> > > >-- back out when you encounter it garbage collection
> > > algorithm to try
> > > >to find a known "trust anchor", then you are guaranteed that:
> > > >
> > > >(1) you will find a path if one exists, and
> > > >
> > > >(2) the algorithm will always terminate.
> > > >
> > > >What you are not guaranteed is that this simplistic
> > > algorithm will find
> > > >the best path by whatever metric you use to determine what's best.
> > > >
> > > >> Certificate path building is at heart a graph theory problem.
> > > >
> > > >And category theory is at the heart of graph theory; however, I not
> > > >going to suggest that everyone needs to take time out and read the
> > > >works of Saunders MacLane before discussion can continue :) :) :)
> > > >
> > > >I do have a "hidden agenda", though.  I will now try to change its
> > > >status from covert to overt.  I would like to see sound
> > theoretical
> > > >underpinnings to all this stuff.  That means mathematics,
> > the branch
> > > >called "algebra" in particular.  I'm not claiming that
> > concepts like
> > > >splicing chains together completely provide such
> > > underpinnings, but I
> > > >believe that they come real close.  There's a pretty direct
> > > translation
> > > >between splicing chains and the mathematical concepts of
> > transitive
> > > >relations and composition of functions, and the algorithm
> > above does
> > > >nothing more than compute what is known as a closure or limit.
> > > >
> > > >> But the problem is complicated by adding constraints to
> > > certificates
> > > >> and by performance concerns. I recently talked
> > > >
> > > >What you want is for constraints to have a "monotonic"
> > > property. That's
> > > >just another way of saying that they'll contribute nothing new if
> > > >applied again (well, actually that they won't try to
> > > contradict what's
> > > >been done before).
> > > >
> > > >> with someone who said "Cert path building isn't hard. It's only
> > > >> O(n+e) where n is the number of entities and e is the number of
> > > >> certificates." That's true, but you have to download all the
> > > >> certificates in the PKI first! Not very practical in most
> > > >> environments.
> > > >
> > > >It sounds I'm another one who's says "it's easy", doesn't it?
> > > >
> > > >I don't think I'm saying that you have to download all the
> > > certificates
> > > >in the PKI first.  What I think I'm saying is that you
> > > aren't going to
> > > >have much luck if you try to solve such problems by
> > > restrictions of the
> > > >possible topologies. The way to do it is to make sure you
> > > notice that
> > > >you're in a loop.  And when you do notice that, you
> > certainly can't
> > > >give up and pronounce that whole thing untrustworthy; you just try
> > > >something else until you run out of possiblities.
> > > >
> > > >Now the practical performance problems and the "as yet
> > unknown link"
> > > >problems have been introduced.  I'll offer the opinion
> > that the very
> > > >best thing that can to done to alleviate such problems is to
> > > follow the
> > > >often written advice to send all certificates to the other
> > > end that you
> > > >suspect they might need. Every certificate using protocol has
> > > >facilities to do this. In the circles where I've heard this
> > > discussed,
> > > >I'm having a real hard time understanding why there's such
> > > resistance
> > > >to doing this.
> > > >
> > > >
> > > >Eric Norman
> > > >
> > > >   "Congress shall make no law restricting the size of integers
> > > >   that may be multiplied together, or the number of times that
> > > >   an integer may be multiplied by itself, or the modulus by
> > > >   which an integer may be reduced".
> > >
> > >
> >
> >

Content-class: urn:content-classes:message
Subject: RE: SCVP Internal Error...
Date: Wed, 4 Jun 2003 12:24:09 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Faisal" <[email-masked]>, "Peter Sylvester <Peter.Sylvester" <[email-masked]>, "Frank Balluffi" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Faisal,
While you proposal does make the exchange between the client and server
more economic, it does so at the cost of code complexity which leads to
more complicated client testing. We would open up testing combinations
of responses to ensure the client deals with any sequence of status from
the server. 
That is not good, so I think bandwidth will have to suffer.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Faisal
Sent: Wednesday, June 04, 2003 3:43 AM
To: Peter Sylvester <Peter.Sylvester; Frank Balluffi
Cc: [email-masked]; [email-masked]
Subject: Re: SCVP Internal Error...

Hi,

    I prefer additional status code value rather than modifying the
structure

Regards,
Faisal

----- Original Message -----
From: "Frank Balluffi" <[email-masked]>
To: "Peter Sylvester <Peter.Sylvester" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 03, 2003 10:15 PM
Subject: Re: SCVP Internal Error...

>
>
> I prefer adding additional SCVPStatusCode values over modifying the
structure of ResponseStatus. It may also be necessary to add additional
ReplyStatus values.
> Frank
>                       Peter Sylvester
>                       <Peter.Sylvester@        To:
[email-masked]
>                       edelweb.fr>              cc:
>                       Sent by:                 Subject:  Re: SCVP
Internal
Error...
>                       owner-ietf-pkix@m
>                       ail.imc.org

>
>                       06/03/2003 11:33
>                       AM
>
>
>
>
>
>
>
> >
> > I agree.  An additional error code should be defined.
> >
>
> Or :
>
>       ResponseStatus ::= SEQUENCE {
>         statusCode            SCVPStatusCode,
>         errorMessage      [0] UTF8String OPTIONAL }
>
>       SCVPStatusCode ::= ENUMERATED {
>         okay                    (0),
>         skipUnrecognizedItems   (1),
>         tooBusy                (10),
>         badStructure           (20),
>         unsupportedVersion     (21),
>         abortUnrecognizedItems (22),
>         unrecognizedSigKey     (23),
>         badSignature           (24),
>         unableToDecode         (25),
>         notAuthorized          (26),
>         unsupportedChecks      (27),
>         unsupportedWantBacks   (28),
>         unsupportedSignature   (29),
>         invalidSignature       (30),
>         relayingLoop           (40) }
>
> could be replaced by (after adding one code for relaying and
> removing the the word TSA).
>
>
>   PKIStatusInfo ::= SEQUENCE {
>       status        PKIStatus,
>       statusString  PKIFreeText     OPTIONAL,
>       failInfo      PKIFailureInfo  OPTIONAL
>   }
>
>   PKIStatus ::= INTEGER {
>       accepted                (0),
>       -- you got exactly what you asked for
>       grantedWithMods        (1),
>       -- you got something like what you asked for; the
>       -- requester is responsible for ascertaining the differences
>       rejection              (2),
>       -- you don't get it, more information elsewhere in the message
>       waiting                (3),
>       -- the request body part has not yet been processed; expect to
hear
>       -- more later (note: proper handling of this status response MAY
>       -- use the polling req/rep PKIMessages specified in Section
3.3.22;
>       -- alternatively, polling in the underlying transport layer MAY
>       -- have some utility in this regard)
>       revocationWarning      (4),
>       -- this message contains a warning that a revocation is
>       -- imminent
>       revocationNotification (5),
>       -- notification that a revocation has occurred
>       keyUpdateWarning       (6)
>       -- update already done for the oldCertId specified in
>       -- CertReqMsg
>   }
>
>   PKIFailureInfo ::= BIT STRING {
>   -- since we can fail in more than one way!
>   -- More codes may be added in the future if/when required.
>       badAlg              (0),
>       -- unrecognized or unsupported Algorithm Identifier
>       badMessageCheck     (1),
>       -- integrity check failed (e.g., signature did not verify)
>       badRequest          (2),
>       -- transaction not permitted or supported
>       badTime             (3),
>       -- messageTime was not sufficiently close to the system time,
>       -- as defined by local policy
>       badCertId           (4),
>       -- no certificate could be found matching the provided criteria
>       badDataFormat       (5),
>       -- the data submitted has the wrong format
>       wrongAuthority      (6),
>       -- the authority indicated in the request is different from the
>       -- one creating the response token
>       incorrectData       (7),
>       -- the requester's data is incorrect (for notary services)
>       missingTimeStamp    (8),
>       -- when the timestamp is missing but should be there (by policy)
>       badPOP              (9),
>       -- the proof-of-possession failed
>       certRevoked         (10),
>          -- the certificate has already been revoked
>       certConfirmed       (11),
>          -- the certificate has already been confirmed
>       wrongIntegrity      (12),
>          -- invalid integrity, password based instead of signature or
>          -- vice versa
>       badRecipientNonce   (13),
>          -- invalid recipient nonce, either missing or wrong value
>       timeNotAvailable    (14),
>          -- the TSA's time source is not available
>       unacceptedPolicy    (15),
>          -- the requested TSA policy is not supported by the TSA.
>       unacceptedExtension (16),
>          -- the requested extension is not supported by the TSA.
>       addInfoNotAvailable (17),
>          -- the additional information requested could not be
understood
>          -- or is not available
>       badSenderNonce      (18),
>          -- invalid sender nonce, either missing or wrong size
>       badCertTemplate     (19),
>          -- invalid cert. template or missing mandatory information
>       signerNotTrusted    (20),
>          -- signer of the message unknown or not trusted
>       transactionIdInUse  (21),
>          -- the transaction identifier is already in use
>       unsupportedVersion  (22),
>          -- the version of the message is not supported
>       notAuthorized       (23),
>          -- the sender was not authorized to make the preceding
request
>          -- or perform the preceding action
>       systemUnavail       (24),
>       -- the request cannot be handled due to system unavailability
>       systemFailure       (25),
>       -- the request cannot be handled due to system failure
>       duplicateCertReq    (26)
>       -- certificate cannot be issued because a duplicate certificate
>       -- already exists
>   }
>
>
>
>
>
>
>
>
>
>
> --
>
> This e-mail may contain confidential and/or privileged information. If
you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

Date: Wed, 04 Jun 2003 13:30:37 -0400
From: "David A. Cooper" <[email-masked]>
To: Juergen Brauckmann <[email-masked]>
CC: [email-masked]
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
Sender: [email-masked]

Juergen,

What you are describing below is an indirect CRL, a CRL that covers 
certificates issued different entity.  (I know you stated that same CA 
issues both the certificates and the CRL, but since the issuer names are 
different, they are considered different entities.  Furthermore, there 
is no way for a relying party to know whether the certificate issuer and 
CRL issuer are the same entity).

Usually, a CRL can not be used to determine the status of a certificate 
unless the certificate and CRL both have the same issuer name.  The 
value of the AKI extension does not matter, as it is only a hint that 
can aid in building paths and in selecting the right CRL.

In order to allow a relying party to use a CRL to determine the status 
of a certificate where the issuer names differ, you need to do the 
following:

1) Each certificate issued by "CA1" must include a cRLDistributionPoints 
extension with a cRLIssuer field that indicates that "CRL1" is the CRL 
issuer.

2) The CRLs issued by "CRL1" must include an issuingDistributionPoint 
extension with the indirectCRL flag set to TRUE.

3)  If any of CA1's certificates have been revoked, the 
certificateIssuer CRL entry extension must be used within the CRLs 
issued by "CRL1" to indicate that list of revoked serial numbers are of 
certificates issued by "CA1" (see RFC 3280 for details on the use of 
these three extensions).

While the rules for issuing and processing indirect CRLs are specified 
in RFC 3280, RFC 3280 compliant clients are not required to be able to 
process indirect CRLs.

Dave

Juergen Brauckmann wrote:

>Hi.
>
>I have a question regarding the naming scheme for CRLs. Consider the
>following:
>
>EE certificates are issued by a CA, Issuer-DN "CA1". 
>
>The CA uses a CA certificate issued by a root ca: Issuer-DN "Root1",
>Subject-DN "CA1", serialnumber "1". 
>
>The CA issues CRLs, and signs them with a CRL certificate wich was also
>issued by a root CA, but with another distinguished name than the main
>CA certificate: Issuer-DN "Root1", Subject-DN "CRL1", serialnumber "2"
>
>Is an RFC 3280 compliant client supposed to be able to process the CRLs
>if the CRL Issuer-DN is set to "CA1" and the CRL contains an
>AuthorityKeyIdentifier pointing to the CRL certificate with Subject-DN
>"CRL1"?
>
>Is this scheme, where the issuer name from CRL does not match Subject DN
>from CRL signing certificate, covered by step f) from chapter 6.3.3 from
>RFC 3280?
>
> "f) Obtain and validate the certification path for the complete CRL
>   issuer.  If a key usage extension is present in the CRL issuer's
>   certificate, verify that the cRLSign bit is set."
>
>
>Regards,
>   Juergen
>  
>

Date: Wed, 04 Jun 2003 15:27:04 +0200
From: Juergen Brauckmann <[email-masked]>
Organization: TC TrustCenter AG
To: [email-masked]
Subject: CRL Issuer Name = Subject name from crl signer cert?
Sender: [email-masked]

Hi.

I have a question regarding the naming scheme for CRLs. Consider the
following:

EE certificates are issued by a CA, Issuer-DN "CA1". 

The CA uses a CA certificate issued by a root ca: Issuer-DN "Root1",
Subject-DN "CA1", serialnumber "1". 

The CA issues CRLs, and signs them with a CRL certificate wich was also
issued by a root CA, but with another distinguished name than the main
CA certificate: Issuer-DN "Root1", Subject-DN "CRL1", serialnumber "2"

Is an RFC 3280 compliant client supposed to be able to process the CRLs
if the CRL Issuer-DN is set to "CA1" and the CRL contains an
AuthorityKeyIdentifier pointing to the CRL certificate with Subject-DN
"CRL1"?

Is this scheme, where the issuer name from CRL does not match Subject DN
from CRL signing certificate, covered by step f) from chapter 6.3.3 from
RFC 3280?

 "f) Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's
   certificate, verify that the cRLSign bit is set."

Regards,
   Juergen

From: "Faisal" <[email-masked]>
To: "Peter Sylvester <Peter.Sylvester" <[email-masked]>, "Frank Balluffi" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: SCVP Internal Error...
Date: Wed, 4 Jun 2003 15:42:54 +0500
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Hi,

    I prefer additional status code value rather than modifying the
structure

Regards,
Faisal

----- Original Message -----
From: "Frank Balluffi" <[email-masked]>
To: "Peter Sylvester <Peter.Sylvester" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 03, 2003 10:15 PM
Subject: Re: SCVP Internal Error...

>
>
> I prefer adding additional SCVPStatusCode values over modifying the
structure of ResponseStatus. It may also be necessary to add additional
ReplyStatus values.
>
> Frank
>
>
>
>
>                       Peter Sylvester
>                       <Peter.Sylvester@        To:       [email-masked]
>                       edelweb.fr>              cc:
>                       Sent by:                 Subject:  Re: SCVP Internal
Error...
>                       owner-ietf-pkix@m
>                       ail.imc.org

>
>                       06/03/2003 11:33
>                       AM
>
>
>
>
>
>
>
> >
> > I agree.  An additional error code should be defined.
> >
>
> Or :
>
>       ResponseStatus ::= SEQUENCE {
>         statusCode            SCVPStatusCode,
>         errorMessage      [0] UTF8String OPTIONAL }
>
>       SCVPStatusCode ::= ENUMERATED {
>         okay                    (0),
>         skipUnrecognizedItems   (1),
>         tooBusy                (10),
>         badStructure           (20),
>         unsupportedVersion     (21),
>         abortUnrecognizedItems (22),
>         unrecognizedSigKey     (23),
>         badSignature           (24),
>         unableToDecode         (25),
>         notAuthorized          (26),
>         unsupportedChecks      (27),
>         unsupportedWantBacks   (28),
>         unsupportedSignature   (29),
>         invalidSignature       (30),
>         relayingLoop           (40) }
>
> could be replaced by (after adding one code for relaying and
> removing the the word TSA).
>
>
>   PKIStatusInfo ::= SEQUENCE {
>       status        PKIStatus,
>       statusString  PKIFreeText     OPTIONAL,
>       failInfo      PKIFailureInfo  OPTIONAL
>   }
>
>   PKIStatus ::= INTEGER {
>       accepted                (0),
>       -- you got exactly what you asked for
>       grantedWithMods        (1),
>       -- you got something like what you asked for; the
>       -- requester is responsible for ascertaining the differences
>       rejection              (2),
>       -- you don't get it, more information elsewhere in the message
>       waiting                (3),
>       -- the request body part has not yet been processed; expect to hear
>       -- more later (note: proper handling of this status response MAY
>       -- use the polling req/rep PKIMessages specified in Section 3.3.22;
>       -- alternatively, polling in the underlying transport layer MAY
>       -- have some utility in this regard)
>       revocationWarning      (4),
>       -- this message contains a warning that a revocation is
>       -- imminent
>       revocationNotification (5),
>       -- notification that a revocation has occurred
>       keyUpdateWarning       (6)
>       -- update already done for the oldCertId specified in
>       -- CertReqMsg
>   }
>
>   PKIFailureInfo ::= BIT STRING {
>   -- since we can fail in more than one way!
>   -- More codes may be added in the future if/when required.
>       badAlg              (0),
>       -- unrecognized or unsupported Algorithm Identifier
>       badMessageCheck     (1),
>       -- integrity check failed (e.g., signature did not verify)
>       badRequest          (2),
>       -- transaction not permitted or supported
>       badTime             (3),
>       -- messageTime was not sufficiently close to the system time,
>       -- as defined by local policy
>       badCertId           (4),
>       -- no certificate could be found matching the provided criteria
>       badDataFormat       (5),
>       -- the data submitted has the wrong format
>       wrongAuthority      (6),
>       -- the authority indicated in the request is different from the
>       -- one creating the response token
>       incorrectData       (7),
>       -- the requester's data is incorrect (for notary services)
>       missingTimeStamp    (8),
>       -- when the timestamp is missing but should be there (by policy)
>       badPOP              (9),
>       -- the proof-of-possession failed
>       certRevoked         (10),
>          -- the certificate has already been revoked
>       certConfirmed       (11),
>          -- the certificate has already been confirmed
>       wrongIntegrity      (12),
>          -- invalid integrity, password based instead of signature or
>          -- vice versa
>       badRecipientNonce   (13),
>          -- invalid recipient nonce, either missing or wrong value
>       timeNotAvailable    (14),
>          -- the TSA's time source is not available
>       unacceptedPolicy    (15),
>          -- the requested TSA policy is not supported by the TSA.
>       unacceptedExtension (16),
>          -- the requested extension is not supported by the TSA.
>       addInfoNotAvailable (17),
>          -- the additional information requested could not be understood
>          -- or is not available
>       badSenderNonce      (18),
>          -- invalid sender nonce, either missing or wrong size
>       badCertTemplate     (19),
>          -- invalid cert. template or missing mandatory information
>       signerNotTrusted    (20),
>          -- signer of the message unknown or not trusted
>       transactionIdInUse  (21),
>          -- the transaction identifier is already in use
>       unsupportedVersion  (22),
>          -- the version of the message is not supported
>       notAuthorized       (23),
>          -- the sender was not authorized to make the preceding request
>          -- or perform the preceding action
>       systemUnavail       (24),
>       -- the request cannot be handled due to system unavailability
>       systemFailure       (25),
>       -- the request cannot be handled due to system failure
>       duplicateCertReq    (26)
>       -- certificate cannot be issued because a duplicate certificate
>       -- already exists
>   }
>
>
>
>
>
>
>
>
>
>
> --
>
> This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

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

------=_NextPart_000_0033_01C32AAF.F75370F0--

From: "Faisal" <[email-masked]>
To: <[email-masked]>
Subject: CVResponse [ResponseStatus] may need to change
Date: Wed, 4 Jun 2003 12:29:32 +0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B5_01C32A94.F3F2D510
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_001_00B6_01C32A94.F3F2D510"

------=_NextPart_001_00B6_01C32A94.F3F2D510
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_00B7_01C32A94.F3F2D510"

------=_NextPart_002_00B7_01C32A94.F3F2D510
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

When a user requests a SCVPRequest to SCVPServer, and request contains =
following unsupported fields by SCVPServer

1- scvpversion
2- checks
3- want backs

the SCVPServer will process the request and will send response back with =
SCVPStatusCode as unsupportedVersion (21)
Now if requestor again sends the same request with scvpversion changes =
(supported), SCVPServer will send response back with SCVPCode as =
unsupportedChecks (27) and third time unsupportedWantBacks (28) code.

This will happen because requestor has no knowledge about other =
unsupported items, and all this will waste time, so what I think to =
prefer is that a change is CVResponse structure

It should be like this: (Note: blue text is prefered)

Suggested:
CVResponse ::=3D SEQUENCE {
    scvpVersion                    INTEGER,
    producedAt                    GeneralizedTime,
    responseStatus                SEQUENCE SIZE (1..MAX) OF =
ResponseStatus,
...
...
            }

instead of existing:

Existing:
CVResponse ::=3D SEQUENCE {
    scvpVersion                    INTEGER,
    producedAt                    GeneralizedTime,
    responseStatus                ResponseStatus,
...
...
            }

So if we use Suggested ASN.1, SCVPServer can send one response with more =
than one SCVPStatusCode.

Regards,
Faisal Maqsood       Analyst
     a leading provider of real-time Certificate Validation solutions

 TrustFinderOCSP - provides the latest and most sophisticated OCSP =
(Online Certificate Status Protocol) server on the market.=20

ARP - is an essential plug-in for enabling OCSP client functionality in =
leading Microsoft=AE applications.

) Phone: +44 (0) 1784 497 321
& Fax: +44 (0) 1784 497 301
* Email: [email-masked]

Adding Trust to your PKI

www.ascertia.com

The opinions expressed are those of the individual and not the company. =
Internet communications are not secure and therefore the company does =
not accept legal responsibility for the contents of this message.  If =
the reader of this message is not the intended recipient, or the =
employee responsible for delivering this communication to the intended =
recipient, you are hereby notified that any disclosure, distribution or =
copying of this communication is strictly prohibited.=20

------=_NextPart_002_00B7_01C32A94.F3F2D510
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3D"file://F:\_BackUp-FM\Email Signature\">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>When a user requests a SCVPRequest to SCVPServer, and request =
contains=20
following unsupported fields by SCVPServer</DIV>
<DIV>&nbsp;</DIV>
<DIV>1- scvpversion</DIV>
<DIV>2- checks</DIV>
<DIV>3- want backs</DIV>
<DIV>&nbsp;</DIV>
<DIV>the SCVPServer will process the request and&nbsp;will send response =
back=20
with SCVPStatusCode as unsupportedVersion (21)</DIV>
<DIV>Now&nbsp;if requestor again sends the&nbsp;same request with =
scvpversion=20
changes (supported),&nbsp;SCVPServer will send response back with =
SCVPCode as=20
unsupportedChecks (27) and third time unsupportedWantBacks (28) =
code.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This&nbsp;will happen because requestor has no knowledge<FONT=20
color=3D#ffff00> </FONT>about other unsupported items, and all this will =
waste=20
time, so what I think to prefer is that a change is CVResponse =
structure</DIV>
<DIV>&nbsp;</DIV>
<DIV>It should be like this: (<FONT color=3D#0000ff>Note: blue text is=20
prefered</FONT>)</DIV>
<DIV>&nbsp;</DIV>
<DIV><U><STRONG>Suggested:</STRONG></U></DIV>
<DIV>CVResponse ::=3D SEQUENCE {</DIV>
<DIV>&nbsp;&nbsp;&nbsp; scvpVersion&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; INTEGER,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; producedAt&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
GeneralizedTime,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; responseStatus&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <FONT color=3D#0000ff>SEQUENCE =
SIZE (1..MAX)=20
OF ResponseStatus,</FONT></DIV>
<DIV>...</DIV>
<DIV>...</DIV>
<DIV>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</DIV>
<DIV>&nbsp;</DIV>
<DIV>instead of existing:</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><U><STRONG>Existing:</STRONG></U></DIV>
<DIV>CVResponse ::=3D SEQUENCE {</DIV>
<DIV>&nbsp;&nbsp;&nbsp; scvpVersion&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; INTEGER,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; producedAt&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
GeneralizedTime,</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
responseStatus&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<FONT color=3D#0000ff>ResponseStatus,</FONT></DIV>
<DIV>...</DIV>
<DIV>...</DIV>
<DIV>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
}</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>So if we use Suggested ASN.1, SCVPServer can send one response with =
more=20
than one SCVPStatusCode.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV><FONT color=3D#008080 size=3D2><SPAN style=3D"FONT-WEIGHT: =
700"><EM><SPAN=20
style=3D"FONT-FAMILY: Arial">Faisal=20
Maqsood</SPAN></EM></SPAN></FONT><EM><B><I><FONT face=3DArial =
color=3Dteal=20
size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: =
Arial; mso-no-proof: yes">&nbsp;&nbsp;</SPAN></FONT></I></B></EM><FONT=20
face=3DArial color=3Dblack size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial; =
mso-no-proof: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
Analyst</SPAN></FONT></DIV></DIV>
<DIV>
<DIV class=3DSection1>
<DIV>
<P><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><IMG =
height=3D58=20
src=3D"cid:00b401c32a6b$0ab18820$1400a8c0@ascertiafm" width=3D90=20
border=3D0>&nbsp;&nbsp;&nbsp;&nbsp; a leading provider of=20
real-time&nbsp;Certificate Validation solutions</SPAN></FONT></P>
<P>&nbsp;<FONT face=3D"Verdana, Arial, Helvetica, sans-serif" =
size=3D1><A=20
href=3D"http://www.ascertia.com/client/products/trust_finder.htm"=20
target=3D_blank>TrustFinderOCSP</A> - provides the latest and most =
sophisticated=20
OCSP (Online Certificate Status Protocol) server on the =
market.&nbsp;</FONT></P>
<P><FONT face=3D"Verdana, Arial, Helvetica, sans-serif" size=3D1><A=20
href=3D"http://www.ascertia.com/client/products/ocsp-revok-provider.htm" =

target=3D_blank>ARP </A>- is an essential plug-in for enabling OCSP =
client=20
functionality in leading Microsoft=AE applications.</FONT></P>
<P><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: =
yes"><BR></SPAN></FONT><ST1:CITY><ST1:PLACE><SPAN=20
style=3D"FONT-WEIGHT: bold"><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT =
face=3DArial=20
size=3D1><FONT size=3D3><FONT face=3DWingdings>)</FONT></FONT><FONT =
face=3DVerdana=20
size=3D2> </FONT></FONT></SPAN><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-WEIGHT: bold; mso-no-proof: yes">Phone: +44 (0) 1784 497=20
321<BR></SPAN></FONT><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT=20
face=3DWingdings size=3D3>&amp;</FONT><FONT face=3DVerdana size=3D2>=20
</FONT></SPAN></FONT><SPAN style=3D"FONT-WEIGHT: bold; mso-no-proof: =
yes"><FONT=20
face=3DArial size=3D1>Fax: +44 (0) 1784 497 301</FONT></SPAN><SPAN=20
style=3D"FONT-SIZE: 7.5pt; FONT-FAMILY: Arial; mso-no-proof: yes"><FONT =
face=3DArial=20
size=3D1><FONT face=3DVerdana color=3D#808080 size=3D2><BR></FONT><FONT =
size=3D3><FONT=20
face=3DWingdings>*</FONT><FONT face=3D"Times New Roman">=20
</FONT></FONT></FONT></SPAN><FONT face=3DArial size=3D1><SPAN=20
style=3D"FONT-WEIGHT: bold; mso-no-proof: yes">Email: <A=20
style=3D"TEXT-DECORATION: none"=20
href=3D"mailto:[email-masked]">faisal.maqsood</A><A=20
style=3D"TEXT-DECORATION: none"=20
href=3D"mailto:[email-masked]">@ascertia.com</A></SPAN></FON=
T></SPAN></ST1:PLACE></ST1:CITY></P>
<P style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT face=3D"Times New =
Roman"=20
color=3Dteal size=3D6><SPAN=20
style=3D"FONT-SIZE: 24pt; COLOR: teal; mso-no-proof: yes">Adding =
<EM><I><FONT=20
face=3D"Times New Roman">Trust</FONT></I></EM> to your =
PKI</SPAN></FONT><SPAN=20
style=3D"mso-no-proof: yes"><O:P></O:P></SPAN></P>
<P style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT face=3D"Times New =
Roman"=20
size=3D3><SPAN style=3D"FONT-SIZE: 12pt; mso-no-proof: yes"><A=20
href=3D"http://www.ascertia.com/"><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">www.ascertia.com</SPAN></FONT></A></SPAN></FONT></P>
<P><FONT face=3DArial color=3Dgray size=3D1><SPAN=20
style=3D"FONT-SIZE: 7.5pt; COLOR: gray; FONT-FAMILY: Arial; =
mso-no-proof: yes">The=20
opinions expressed are those of the individual and not the company. =
Internet=20
communications are not secure and therefore the company does not accept =
legal=20
responsibility for the contents of this message.&nbsp; If the reader of =
this=20
message is not the intended recipient, or the employee responsible for=20
delivering this communication to the intended recipient, you are hereby =
notified=20
that any disclosure, distribution or copying of this communication is =
strictly=20
prohibited.</SPAN></FONT><SPAN style=3D"mso-no-proof: yes">=20
</SPAN><O:P></O:P></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_002_00B7_01C32A94.F3F2D510--

------=_NextPart_001_00B6_01C32A94.F3F2D510
Content-Type: image/gif;
	name="Ascertia-Logo.gif"
Content-Transfer-Encoding: base64
Content-ID: <00b401c32a6b$0ab18820$1400a8c0@ascertiafm>

------=_NextPart_001_00B6_01C32A94.F3F2D510--

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

------=_NextPart_000_00B5_01C32A94.F3F2D510--

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: SCEP newest spec
Date: Tue, 3 Jun 2003 18:59:18 -0700 
Sender: [email-masked]

That might be the less cynical version.

The more helpful version would be give the URL
http://www.cisco.com/warp/public/cc/pd/sqsw/tech/scep_wp.htm

The abusive reply would be SWFG, it only took 2 minutes to find on Google. I
only mention it because I want to claim authorship of the acronym. 

If the PKIX group is not interested in documenting current practice then it
might be useful if the OASIS PKIForum took on the spec. You might also take
a look at the W3C XKMS specification currently in last call.

	Phill

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, June 03, 2003 5:17 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: SCEP newest spec
> 
> 
> 
> At 3:00 AM +1200 6/4/03, Peter Gutmann wrote:
> >"Miguel Rodriguez" <[email-masked]> writes:
> >
> >>What is the latest (or current) draft version specifying 
> the SCEP protocol?
> >
> >Wrong list, we're supposed to be pretending that SCEP 
> doesn't exist :-).
> >However, the last draft of the non-existant SCEP protocol 
> that doesn't exist
> >was the year-old -06, which would have expired late last 
> year if it existed.
> >
> >Peter.
> 
> The less cynical form of Peter's response is that SCEP is not an IETF 
> work product. It is a vendor protocol developed outside of the IETF 
> and it competes with two PKIX standard protocols (CMP and CMC). Since 
> PKIX, like most WGs, does not want to encourage additional ways of 
> performing the same functions, we have not considered SCEP as a PKIX 
> work item.
> 
> Hope this answers your question.
> 
> Steve
> 

Date: Tue, 3 Jun 2003 17:17:15 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: SCEP newest spec
Cc: [email-masked]
Sender: [email-masked]

At 3:00 AM +1200 6/4/03, Peter Gutmann wrote:
>"Miguel Rodriguez" <[email-masked]> writes:
>
>>What is the latest (or current) draft version specifying the SCEP protocol?
>
>Wrong list, we're supposed to be pretending that SCEP doesn't exist :-).
>However, the last draft of the non-existant SCEP protocol that doesn't exist
>was the year-old -06, which would have expired late last year if it existed.
>
>Peter.

The less cynical form of Peter's response is that SCEP is not an IETF 
work product. It is a vendor protocol developed outside of the IETF 
and it competes with two PKIX standard protocols (CMP and CMC). Since 
PKIX, like most WGs, does not want to encourage additional ways of 
performing the same functions, we have not considered SCEP as a PKIX 
work item.

Hope this answers your question.

Steve

Subject: Re: SCVP Internal Error...
To: "Peter Sylvester <Peter.Sylvester" <[email-masked]>
Cc: [email-masked], [email-masked]
From: "Frank Balluffi" <[email-masked]>
Date: Tue, 3 Jun 2003 13:15:30 -0400
Sender: [email-masked]

I prefer adding additional SCVPStatusCode values over modifying the structure of ResponseStatus. It may also be necessary to add additional ReplyStatus values.

Frank

                      Peter Sylvester                                                                                                  
                      <Peter.Sylvester@        To:       [email-masked]                                                             
                      edelweb.fr>              cc:                                                                                     
                      Sent by:                 Subject:  Re: SCVP Internal Error...                                                    
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      06/03/2003 11:33                                                                                                 
                      AM                                                                                                               

>
> I agree.  An additional error code should be defined.
>

Or :

      ResponseStatus ::= SEQUENCE {
        statusCode            SCVPStatusCode,
        errorMessage      [0] UTF8String OPTIONAL }

      SCVPStatusCode ::= ENUMERATED {
        okay                    (0),
        skipUnrecognizedItems   (1),
        tooBusy                (10),
        badStructure           (20),
        unsupportedVersion     (21),
        abortUnrecognizedItems (22),
        unrecognizedSigKey     (23),
        badSignature           (24),
        unableToDecode         (25),
        notAuthorized          (26),
        unsupportedChecks      (27),
        unsupportedWantBacks   (28),
        unsupportedSignature   (29),
        invalidSignature       (30),
        relayingLoop           (40) }

could be replaced by (after adding one code for relaying and
removing the the word TSA).

  PKIStatusInfo ::= SEQUENCE {
      status        PKIStatus,
      statusString  PKIFreeText     OPTIONAL,
      failInfo      PKIFailureInfo  OPTIONAL
  }

  PKIStatus ::= INTEGER {
      accepted                (0),
      -- you got exactly what you asked for
      grantedWithMods        (1),
      -- you got something like what you asked for; the
      -- requester is responsible for ascertaining the differences
      rejection              (2),
      -- you don't get it, more information elsewhere in the message
      waiting                (3),
      -- the request body part has not yet been processed; expect to hear
      -- more later (note: proper handling of this status response MAY
      -- use the polling req/rep PKIMessages specified in Section 3.3.22;
      -- alternatively, polling in the underlying transport layer MAY
      -- have some utility in this regard)
      revocationWarning      (4),
      -- this message contains a warning that a revocation is
      -- imminent
      revocationNotification (5),
      -- notification that a revocation has occurred
      keyUpdateWarning       (6)
      -- update already done for the oldCertId specified in
      -- CertReqMsg
  }

  PKIFailureInfo ::= BIT STRING {
  -- since we can fail in more than one way!
  -- More codes may be added in the future if/when required.
      badAlg              (0),
      -- unrecognized or unsupported Algorithm Identifier
      badMessageCheck     (1),
      -- integrity check failed (e.g., signature did not verify)
      badRequest          (2),
      -- transaction not permitted or supported
      badTime             (3),
      -- messageTime was not sufficiently close to the system time,
      -- as defined by local policy
      badCertId           (4),
      -- no certificate could be found matching the provided criteria
      badDataFormat       (5),
      -- the data submitted has the wrong format
      wrongAuthority      (6),
      -- the authority indicated in the request is different from the
      -- one creating the response token
      incorrectData       (7),
      -- the requester's data is incorrect (for notary services)
      missingTimeStamp    (8),
      -- when the timestamp is missing but should be there (by policy)
      badPOP              (9),
      -- the proof-of-possession failed
      certRevoked         (10),
         -- the certificate has already been revoked
      certConfirmed       (11),
         -- the certificate has already been confirmed
      wrongIntegrity      (12),
         -- invalid integrity, password based instead of signature or
         -- vice versa
      badRecipientNonce   (13),
         -- invalid recipient nonce, either missing or wrong value
      timeNotAvailable    (14),
         -- the TSA's time source is not available
      unacceptedPolicy    (15),
         -- the requested TSA policy is not supported by the TSA.
      unacceptedExtension (16),
         -- the requested extension is not supported by the TSA.
      addInfoNotAvailable (17),
         -- the additional information requested could not be understood
         -- or is not available
      badSenderNonce      (18),
         -- invalid sender nonce, either missing or wrong size
      badCertTemplate     (19),
         -- invalid cert. template or missing mandatory information
      signerNotTrusted    (20),
         -- signer of the message unknown or not trusted
      transactionIdInUse  (21),
         -- the transaction identifier is already in use
      unsupportedVersion  (22),
         -- the version of the message is not supported
      notAuthorized       (23),
         -- the sender was not authorized to make the preceding request
         -- or perform the preceding action
      systemUnavail       (24),
      -- the request cannot be handled due to system unavailability
      systemFailure       (25),
      -- the request cannot be handled due to system failure
      duplicateCertReq    (26)
      -- certificate cannot be issued because a duplicate certificate
      -- already exists
  }

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Date: Tue, 3 Jun 2003 17:33:58 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: SCVP Internal Error...
Sender: [email-masked]

> 
> I agree.  An additional error code should be defined.
> 

Or :

      ResponseStatus ::= SEQUENCE {
        statusCode            SCVPStatusCode,
        errorMessage      [0] UTF8String OPTIONAL }

      SCVPStatusCode ::= ENUMERATED {
        okay                    (0),
        skipUnrecognizedItems   (1),
        tooBusy                (10),
        badStructure           (20),
        unsupportedVersion     (21),
        abortUnrecognizedItems (22),
        unrecognizedSigKey     (23),
        badSignature           (24),
        unableToDecode         (25),
        notAuthorized          (26),
        unsupportedChecks      (27),
        unsupportedWantBacks   (28),
        unsupportedSignature   (29),
        invalidSignature       (30),
        relayingLoop           (40) }

could be replaced by (after adding one code for relaying and 
removing the the word TSA). 

  PKIStatusInfo ::= SEQUENCE {
      status        PKIStatus,
      statusString  PKIFreeText     OPTIONAL,
      failInfo      PKIFailureInfo  OPTIONAL
  }

  PKIStatus ::= INTEGER {
      accepted                (0),
      -- you got exactly what you asked for
      grantedWithMods        (1),
      -- you got something like what you asked for; the
      -- requester is responsible for ascertaining the differences
      rejection              (2),
      -- you don't get it, more information elsewhere in the message
      waiting                (3),
      -- the request body part has not yet been processed; expect to hear
      -- more later (note: proper handling of this status response MAY
      -- use the polling req/rep PKIMessages specified in Section 3.3.22;
      -- alternatively, polling in the underlying transport layer MAY
      -- have some utility in this regard)
      revocationWarning      (4),
      -- this message contains a warning that a revocation is
      -- imminent
      revocationNotification (5),
      -- notification that a revocation has occurred
      keyUpdateWarning       (6)
      -- update already done for the oldCertId specified in
      -- CertReqMsg
  }

  PKIFailureInfo ::= BIT STRING {
  -- since we can fail in more than one way!
  -- More codes may be added in the future if/when required.
      badAlg              (0),
      -- unrecognized or unsupported Algorithm Identifier
      badMessageCheck     (1),
      -- integrity check failed (e.g., signature did not verify)
      badRequest          (2),
      -- transaction not permitted or supported
      badTime             (3),
      -- messageTime was not sufficiently close to the system time,
      -- as defined by local policy
      badCertId           (4),
      -- no certificate could be found matching the provided criteria
      badDataFormat       (5),
      -- the data submitted has the wrong format
      wrongAuthority      (6),
      -- the authority indicated in the request is different from the
      -- one creating the response token
      incorrectData       (7),
      -- the requester's data is incorrect (for notary services)
      missingTimeStamp    (8),
      -- when the timestamp is missing but should be there (by policy)
      badPOP              (9),
      -- the proof-of-possession failed
      certRevoked         (10),
         -- the certificate has already been revoked
      certConfirmed       (11),
         -- the certificate has already been confirmed
      wrongIntegrity      (12),
         -- invalid integrity, password based instead of signature or 
         -- vice versa
      badRecipientNonce   (13),
         -- invalid recipient nonce, either missing or wrong value
      timeNotAvailable    (14),
         -- the TSA's time source is not available
      unacceptedPolicy    (15),
         -- the requested TSA policy is not supported by the TSA.
      unacceptedExtension (16),
         -- the requested extension is not supported by the TSA. 
      addInfoNotAvailable (17),
         -- the additional information requested could not be understood
         -- or is not available
      badSenderNonce      (18),
         -- invalid sender nonce, either missing or wrong size
      badCertTemplate     (19),
         -- invalid cert. template or missing mandatory information
      signerNotTrusted    (20),
         -- signer of the message unknown or not trusted
      transactionIdInUse  (21),
         -- the transaction identifier is already in use
      unsupportedVersion  (22),
         -- the version of the message is not supported  
      notAuthorized       (23),
         -- the sender was not authorized to make the preceding request
         -- or perform the preceding action
      systemUnavail       (24),
      -- the request cannot be handled due to system unavailability
      systemFailure       (25),
      -- the request cannot be handled due to system failure
      duplicateCertReq    (26)
      -- certificate cannot be issued because a duplicate certificate
      -- already exists
  }

Date: Wed, 4 Jun 2003 03:00:24 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: SCEP newest spec
Sender: [email-masked]

"Miguel Rodriguez" <[email-masked]> writes:

>What is the latest (or current) draft version specifying the SCEP protocol?

Wrong list, we're supposed to be pretending that SCEP doesn't exist :-).
However, the last draft of the non-existant SCEP protocol that doesn't exist
was the year-old -06, which would have expired late last year if it existed.

Peter.

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: about RFC 3126
Date: Tue, 3 Jun 2003 09:36:09 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C329B3.90E298C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Some questions about RFC 3126 "Electronic signature formats for long
term electronic signatures":
 
1.	For a multiple independent signature format, should each
signature have its own X-timestamp (type 1 or type 2)? 
2.	When using OCSP for revocation information the X-timestamp must
be of type 1 only? 
3.	For a multiple independent signature format, does the Archive
timestamp cover all the signatures or does it have to be one archive
timestamp per signature? 
 
Thanks in advance,
 
Miguel A. Rodriguez
Software Engineer
SeguriDATA
Mexico

------=_NextPart_000_000E_01C329B3.90E298C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Narrow";
	panose-1:2 11 5 6 2 2 2 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1615558362;
	mso-list-type:hybrid;
	mso-list-template-ids:356800280 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Some questions about RFC 3126 &#8220;Electronic =
signature
formats for long term electronic =
signatures&#8221;:<o:p></o:p></span></font></p>

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

<ol style=3D'mso-margin-top-alt:0cm' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1;tab-stops:list =
36.0pt'><font
     size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>For a
     multiple independent signature format, should each signature have =
its own
     X-timestamp (type 1 or type 2)?</span></font> <font size=3D2 =
face=3DArial><span
     =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></l=
i>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1;tab-stops:list =
36.0pt'><font
     size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>When
     using OCSP for revocation information the X-timestamp must be of =
type 1
     only?</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
     font-family:Arial'><o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1;tab-stops:list =
36.0pt'><font
     size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>For a
     multiple independent signature format, does the Archive timestamp =
cover
     all the signatures or does it have to be one archive timestamp per
     signature?</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:
     10.0pt;font-family:Arial'><o:p></o:p></span></font></li>
</ol>

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

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;mso-no-proof:
yes'>Miguel A. Rodriguez</span></font><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Software =
Engineer</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>SeguriDATA</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Mexico</span></font><span =
lang=3DES-MX
style=3D'mso-ansi-language:ES-MX'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DES-MX
style=3D'font-size:12.0pt;mso-ansi-language:ES-MX'><o:p>&nbsp;</o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DES-MX
style=3D'font-size:12.0pt;mso-ansi-language:ES-MX'><o:p>&nbsp;</o:p></spa=
n></font></p>

</div>

</body>

</html>

------=_NextPart_000_000E_01C329B3.90E298C0--

Date: Tue, 03 Jun 2003 09:47:34 -0400
To: "Wahaj" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SCVP Internal Error...
Sender: [email-masked]

I agree.  An additional error code should be defined.

Russ

At 06:37 PM 6/2/2003 +0500, Wahaj wrote:
>Hi,
>
>I am working on SCVP Server and to some condition I am confused for some 
>response selection, the scenario is as follows:
>
>SCVPServer is trying to get revocation information using local store and 
>failed due to some communication so got null as revocation information, 
>and when making SCVPResponse in this case what should be the error code I 
>think it should be like an Internal Error similarly using in OCSP, but 
>code like this is not mentioned in SCVP Protocol, can any one help 
>regarding this.
>
>
>Regards
>Wahaj

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: SCEP newest spec
Date: Tue, 3 Jun 2003 09:03:21 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

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

What is the latest (or current) draft version specifying the SCEP
protocol?
 
Thanks,
 
Miguel A. Rodriguez
Software Engineer
SeguriDATA
Mexico

------=_NextPart_000_0006_01C329AE.FBC536C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Narrow";
	panose-1:2 11 5 6 2 2 2 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>What is the latest (or current) draft version =
specifying the
SCEP protocol?<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Miguel A. =
Rodriguez</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Software =
Engineer</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>SeguriDATA</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><span class=3DSpellE><font size=3D3 face=3D"Times =
New Roman"><span
lang=3DES-MX =
style=3D'font-size:12.0pt;mso-ansi-language:ES-MX'>Mexico</span></font></=
span><span
lang=3DES-MX style=3D'mso-ansi-language:ES-MX'><o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0006_01C329AE.FBC536C0--

From: "Wahaj" <[email-masked]>
To: <[email-masked]>
Subject: SCVP Internal Error...
Date: Mon, 2 Jun 2003 18:37:01 +0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0119_01C32935.F4D2FF60
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_011A_01C32935.F4D2FF60"

------=_NextPart_001_011A_01C32935.F4D2FF60
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

I am working on SCVP Server and to some condition I am confused for some =
response selection, the scenario is as follows:

SCVPServer is trying to get revocation information using local store and =
failed due to some communication so got null as revocation information, =
and when making SCVPResponse in this case what should be the error code =
I think it should be like an Internal Error similarly using in OCSP, but =
code like this is not mentioned in SCVP Protocol, can any one help =
regarding this.

Regards
Wahaj
------=_NextPart_001_011A_01C32935.F4D2FF60
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3D"file://F:\Data\Document\General\Ascertia\Ascertia Email =
signature\">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2><SPAN style=3D"FONT-WEIGHT: 700"><SPAN=20
style=3D"FONT-FAMILY: Arial">Hi,</DIV>
<DIV>
<DIV class=3DSection1>
<DIV>
<DIV>&nbsp;</DIV>
<DIV>I am working on SCVP Server and to some condition I am confused for =
some=20
response selection, the scenario is as follows:</DIV>
<DIV>&nbsp;</DIV>
<DIV>SCVPServer is trying to get revocation information using local =
store and=20
failed due to some communication so got null as revocation information, =
and when=20
making SCVPResponse in this case what should be the error code I think =
it should=20
be like an Internal Error similarly using in OCSP, but code like this is =
not=20
mentioned in SCVP Protocol, can any one help regarding this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards</DIV>
<DIV>Wahaj</DIV></SPAN></SPAN></FONT></DIV></DIV></DIV></BODY></HTML>

------=_NextPart_001_011A_01C32935.F4D2FF60--

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

------=_NextPart_000_0119_01C32935.F4D2FF60--