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

[[e-mail]]

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" <[e-mail]>
> To: "Peter Gutmann" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
> 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.
> >
> >
> >
> >                       [e-mail]
> >                       nd.ac.nz (Peter          To:
> [e-mail], [e-mail], [e-mail]
> >                       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 <[e-mail]> 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
------------------------------------------------------





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMZaFK083073 for <[e-mail]>; Mon, 30 Jun 2003 15:35:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5UMZaLc083072 for ietf-pkix-bks; Mon, 30 Jun 2003 15:35:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cartero2.sci.uma.es (cartero2.sci.uma.es [150.214.40.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMZXFK083048 for <[e-mail]>; Mon, 30 Jun 2003 15:35:34 -0700 (PDT) (envelope-from [e-mail])
Received: from correo2.uma.es (vesta2.sci.uma.es [150.214.40.7]) by cartero2.sci.uma.es (Postfix) with ESMTP id D5D789F18A; Tue,  1 Jul 2003 00:35:20 +0200 (CEST)
Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1]) by correo2.uma.es (Postfix) with ESMTP id 7060A6CF88; Tue,  1 Jul 2003 00:14:08 +0200 (CEST)
Received: from Debug by sol10.lcc.uma.es (8.8.8+Sun/SMI-SVR4) id AAA15085; Tue, 1 Jul 2003 00:11:36 +0200 (MET DST)
Message-Id: <[e-mail]>
To: "todd glassey" <[e-mail]>, "Peter Gutmann" <[e-mail]>, "Tom Gindin" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Roger Spreen" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>, "Hoyt L. Kesterson II" <[e-mail]>
From: [e-mail]
Subject: Re: Making PKI universally usable - was: Re: Acquisition Problem Solved for some certs? 
Date: Tue, 1 Jul 2003 00:11:46 MET
X-Mailer: Endymion MailMan Standard Edition v3.0.33
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

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" <[e-mail]>
> To: "Peter Gutmann" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
> 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.
> >
> >
> >
> >                       [e-mail]
> >                       nd.ac.nz (Peter          To:
> [e-mail], [e-mail], [e-mail]
> >                       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 <[e-mail]> 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
------------------------------------------------------




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UDoTFK064851 for <[e-mail]>; Mon, 30 Jun 2003 06:50:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5UDoSLn064850 for ietf-pkix-bks; Mon, 30 Jun 2003 06:50:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UDoRFK064836 for <[e-mail]>; Mon, 30 Jun 2003 06:50:27 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (135.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.135]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030630135008112003jipie>; Mon, 30 Jun 2003 13:50:11 +0000
Message-ID: <006001c33f0e$85635f00$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Roger Spreen" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>, "Hoyt L. Kesterson II" <[e-mail]>
References: <[e-mail]>
Subject: Making PKI universally usable - was: Re: Acquisition Problem Solved for some certs? 
Date: Mon, 30 Jun 2003 06:49:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter - 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" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
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.
>
>
>
>                       [e-mail]
>                       nd.ac.nz (Peter          To:
[e-mail], [e-mail], [e-mail]
>                       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 <[e-mail]> 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.
>
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UDTSFK063899 for <[e-mail]>; Mon, 30 Jun 2003 06:29:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5UDTSHg063898 for ietf-pkix-bks; Mon, 30 Jun 2003 06:29:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UDTQFK063887 for <[e-mail]>; Mon, 30 Jun 2003 06:29:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5UDSnD9010223; Mon, 30 Jun 2003 09:28:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100303bb25ea3e125d@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 30 Jun 2003 09:24:22 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UBriFK060829 for <[e-mail]>; Mon, 30 Jun 2003 04:53:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5UBrivL060828 for ietf-pkix-bks; Mon, 30 Jun 2003 04:53:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UBraFK060818 for <[e-mail]>; Mon, 30 Jun 2003 04:53:41 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12503; Mon, 30 Jun 2003 07:53:36 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Mon, 30 Jun 2003 07:53:35 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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:
	[e-mail].
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="[e-mail]"

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

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5U2GtFK041630 for <[e-mail]>; Sun, 29 Jun 2003 19:16:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5U2GtlN041629 for ietf-pkix-bks; Sun, 29 Jun 2003 19:16:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5U2GrFK041624 for <[e-mail]>; Sun, 29 Jun 2003 19:16:53 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5U2Gatd159668; Sun, 29 Jun 2003 22:16:36 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5U2GXP4150452; Sun, 29 Jun 2003 22:16:34 -0400
Subject: Acquisition Problem Solved for some certs? (Was: Re: RFC 3280: same certificate in a certification path)
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Sun, 29 Jun 2003 22:14:37 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPRs JHEG5JQ5CD, THTO5KLVS6, JHEG5HMLFK, JCHN5K5PG9|March 27, 2003) at 06/29/2003 22:16:34
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      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.


                                                                                                                                       
                      [e-mail]                                                                                                
                      nd.ac.nz (Peter          To:       [e-mail], [e-mail], [e-mail]                       
                      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 <[e-mail]> 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.






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5TKUTFK034788 for <[e-mail]>; Sun, 29 Jun 2003 13:30:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5TKUTf1034787 for ietf-pkix-bks; Sun, 29 Jun 2003 13:30:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5TKUQFK034781 for <[e-mail]>; Sun, 29 Jun 2003 13:30:26 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (93.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.93]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003062920300311100ri9k7e>; Sun, 29 Jun 2003 20:30:16 +0000
Message-ID: <00c301c33e7d$40601a60$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
Date: Sun, 29 Jun 2003 13:29:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I 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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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 :-).
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S5QQrb076022 for <[e-mail]>; Fri, 27 Jun 2003 22:26:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5S5QQLT076021 for ietf-pkix-bks; Fri, 27 Jun 2003 22:26:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from srv01.imagineitinternet.com ([64.246.18.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S5QPrb076016 for <[e-mail]>; Fri, 27 Jun 2003 22:26:25 -0700 (PDT) (envelope-from [e-mail])
Received: from lelpeto.com (localhost.localdomain [127.0.0.1]) (authenticated (0 bits)) by srv01.imagineitinternet.com (8.11.6/8.11.6) with SMTP id h5S6N5r30207 for <[e-mail]>; Sat, 28 Jun 2003 01:23:05 -0500
Received: from 63.164.145.33 (SquirrelMail authenticated user [e-mail]) by www.lelpeto.com with HTTP; Sat, 28 Jun 2003 01:23:05 -0500 (CDT)
Message-ID: <[e-mail]>
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: <[e-mail]>
To: [e-mail]
X-Mailer: SquirrelMail (version 1.0.6)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S40Qrb073978 for <[e-mail]>; Fri, 27 Jun 2003 21:00:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5S40Qti073977 for ietf-pkix-bks; Fri, 27 Jun 2003 21:00:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S40Nrb073968 for <[e-mail]>; Fri, 27 Jun 2003 21:00:24 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h5S406Wk032019; Sat, 28 Jun 2003 16:00:06 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h5S403L24632; Sat, 28 Jun 2003 16:00:03 +1200
Date: Sat, 28 Jun 2003 16:00:03 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5REaUrb043205 for <[e-mail]>; Fri, 27 Jun 2003 07:36:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5REaUb9043204 for ietf-pkix-bks; Fri, 27 Jun 2003 07:36:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5REaSrb043198 for <[e-mail]>; Fri, 27 Jun 2003 07:36:28 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5REZfD9008125; Fri, 27 Jun 2003 10:35:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100306bb220447e79a@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 27 Jun 2003 10:28:53 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:53 PM +1200 6/27/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5R1rvrb082232 for <[e-mail]>; Thu, 26 Jun 2003 18:53:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5R1rvYI082231 for ietf-pkix-bks; Thu, 26 Jun 2003 18:53:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5R1rtrb082224 for <[e-mail]>; Thu, 26 Jun 2003 18:53:55 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h5R1rWWk009459; Fri, 27 Jun 2003 13:53:32 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h5R1rVk15188; Fri, 27 Jun 2003 13:53:31 +1200
Date: Fri, 27 Jun 2003 13:53:31 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> 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.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PMdqrb089477 for <[e-mail]>; Wed, 25 Jun 2003 15:39:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5PMdqQG089476 for ietf-pkix-bks; Wed, 25 Jun 2003 15:39:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PMdorb089471 for <[e-mail]>; Wed, 25 Jun 2003 15:39:51 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.1.71.211] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5PMc4Db011829; Wed, 25 Jun 2003 18:39:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210612bb1fb1fa0c8e@[192.168.0.149]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 25 Jun 2003 16:15:31 -0400
To: Eric Norman <[e-mail]>, PKIX list <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PE91rb064469 for <[e-mail]>; Wed, 25 Jun 2003 07:09:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5PE91EI064468 for ietf-pkix-bks; Wed, 25 Jun 2003 07:09:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PE90rb064463 for <[e-mail]>; Wed, 25 Jun 2003 07:09:00 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h5PE8U2Q016936; Wed, 25 Jun 2003 07:08:30 -0700 (PDT)
Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <LMLH4QFH>; Wed, 25 Jun 2003 07:08:30 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: Stephen Kent <[e-mail]>, [e-mail]
Subject: RE: XKMS Version 2
Date: Wed, 25 Jun 2003 07:08:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: Wednesday, June 25, 2003 3:44 AM
> To: Hallam-Baker, Phillip
> Cc: Stephen Kent; [e-mail]
> 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 - 
> [e-mail] and cc: 
> [e-mail]. 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="[e-mail]"/>
> <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
> Identifier="[e-mail]"/>
> 
> 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
> 
> 
> 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P7idrb029790 for <[e-mail]>; Wed, 25 Jun 2003 00:44:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5P7idvO029789 for ietf-pkix-bks; Wed, 25 Jun 2003 00:44:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P7iLrb029702 for <[e-mail]>; Wed, 25 Jun 2003 00:44:31 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA11904; Wed, 25 Jun 2003 09:48:32 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA20542; Wed, 25 Jun 2003 09:44:04 +0200
Message-ID: <[e-mail]>
Date: Wed, 25 Jun 2003 09:44:10 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Hallam-Baker, Phillip" <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: XKMS Version 2
References: <[e-mail]> <p05210601bb1eb3d3336c@[192.168.0.149]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5P7iWrb029760
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 - [e-mail] and cc: 
[e-mail]. 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="[e-mail]"/>
<UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
Identifier="[e-mail]"/>

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







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P2F5rb002571 for <[e-mail]>; Tue, 24 Jun 2003 19:15:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5P2F56Q002570 for ietf-pkix-bks; Tue, 24 Jun 2003 19:15:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P2F4rb002560 for <[e-mail]>; Tue, 24 Jun 2003 19:15:04 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.149] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5P2EvDB029296; Tue, 24 Jun 2003 22:15:00 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210601bb1eb3d3336c@[192.168.0.149]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 24 Jun 2003 22:07:41 -0400
To: "Hallam-Baker, Phillip" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SCEP newest spec
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OLqQrb095135 for <[e-mail]>; Tue, 24 Jun 2003 14:52:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OLqQ17095134 for ietf-pkix-bks; Tue, 24 Jun 2003 14:52:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OLqOrb095128 for <[e-mail]>; Tue, 24 Jun 2003 14:52:24 -0700 (PDT) (envelope-from [e-mail])
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h5OLpxbe007259 for <[e-mail]>; Tue, 24 Jun 2003 17:51:59 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 24 Jun 2003 17:54:33 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: Proxy Certificates
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This 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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OLJnrb094091 for <[e-mail]>; Tue, 24 Jun 2003 14:19:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OLJnrE094090 for ietf-pkix-bks; Tue, 24 Jun 2003 14:19:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OLJlrb094082 for <[e-mail]>; Tue, 24 Jun 2003 14:19:47 -0700 (PDT) (envelope-from [e-mail])
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h5OLJWbe025541 for <[e-mail]>; Tue, 24 Jun 2003 17:19:32 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 24 Jun 2003 17:22:07 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Agenda requests, please
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OFlsrb072299 for <[e-mail]>; Tue, 24 Jun 2003 08:47:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OFls2j072298 for ietf-pkix-bks; Tue, 24 Jun 2003 08:47:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OFlrrb072287 for <[e-mail]>; Tue, 24 Jun 2003 08:47:53 -0700 (PDT) (envelope-from [e-mail])
Subject: Re: UK: PKI "not working"
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 24 Jun 2003 09:47:33 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 06/24/2003 11:47:54 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] 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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OEXQrb066067 for <[e-mail]>; Tue, 24 Jun 2003 07:33:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OEXQi9066066 for ietf-pkix-bks; Tue, 24 Jun 2003 07:33:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OEXOrb066039 for <[e-mail]>; Tue, 24 Jun 2003 07:33:24 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.13.175]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003062414331711100qoec1e>; Tue, 24 Jun 2003 14:33:19 +0000
Message-ID: <015401c33a5d$87222fc0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, <[e-mail]>, "Steven M. Bellovin" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <00a701c339bb$e649ce10$acf42180@arsenaultd2>
Subject: Re: SCEP newest spec
Date: Tue, 24 Jun 2003 07:32:58 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I 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" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>; "'Stephen Kent'"
<[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ODkKrb062553 for <[e-mail]>; Tue, 24 Jun 2003 06:46:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5ODkKVH062552 for ietf-pkix-bks; Tue, 24 Jun 2003 06:46:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cmailm2.svr.pol.co.uk (cmailm2.svr.pol.co.uk [195.92.193.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ODkJrb062545 for <[e-mail]>; Tue, 24 Jun 2003 06:46:19 -0700 (PDT) (envelope-from [e-mail])
Received: from modem-1099.lemur.dialup.pol.co.uk ([217.135.132.75] helo=PEDIGREE) by cmailm2.svr.pol.co.uk with smtp (Exim 4.14) id 19Uo7k-0000RE-KN for [e-mail]; Tue, 24 Jun 2003 14:46:17 +0100
From: "Dean Adams" <[e-mail]>
To: <[e-mail]>
Subject: RE: Revocation status checking of self-issued certificates
Date: Tue, 24 Jun 2003 14:46:25 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
	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: [e-mail]
[mailto:[e-mail]]On Behalf Of Brian Hunter
Sent: 19 June 2003 20:16
To: Matt Cooper; [e-mail]
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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Brian Hunter
> > Sent: Wednesday, June 18, 2003 12:16 PM
> > To: [e-mail]
> > 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
> >




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5O5frrb002407 for <[e-mail]>; Mon, 23 Jun 2003 22:41:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5O5frH2002406 for ietf-pkix-bks; Mon, 23 Jun 2003 22:41:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5O5fprb002399 for <[e-mail]>; Mon, 23 Jun 2003 22:41:51 -0700 (PDT) (envelope-from [e-mail])
Received: from cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 22:43:39 -0800
Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5O5fl4w004518; Mon, 23 Jun 2003 22:41:48 -0700 (PDT)
Date: Mon, 23 Jun 2003 22:41:47 -0700 (PDT)
From: Max Pritikin <[e-mail]>
To: Massimiliano Pala <[e-mail]>
cc: [e-mail]
Subject: Re: SCEP newest spec
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <00a701c339bb$e649ce10$acf42180@arsenaultd2> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano,

For specific questions and concerns about SCEP you could send mail to:
	[e-mail]
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]                [e-mail]
>                                                   Tel.:   [phone]
> http://www.openca.org                            Fax:    +39   178  221 8225
> http://openca.sourceforge.net                    Mobile: [phone]
>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NLYNrb084283 for <[e-mail]>; Mon, 23 Jun 2003 14:34:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NLYNle084282 for ietf-pkix-bks; Mon, 23 Jun 2003 14:34:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NLYLrb084271 for <[e-mail]>; Mon, 23 Jun 2003 14:34:21 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.11.100]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003062321341511200jva13e>; Mon, 23 Jun 2003 21:34:16 +0000
Message-ID: <015b01c339cf$2b339480$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "'Al Arsenault'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: SCEP newest spec
Date: Mon, 23 Jun 2003 14:32:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>; "Hallam-Baker, Phillip"
<[e-mail]>; "'Stephen Kent'" <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NL21rb082850 for <[e-mail]>; Mon, 23 Jun 2003 14:02:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NL21R7082849 for ietf-pkix-bks; Mon, 23 Jun 2003 14:02:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NL1wrb082836 for <[e-mail]>; Mon, 23 Jun 2003 14:01:59 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.11.100]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003062321005611300chqite>; Mon, 23 Jun 2003 21:01:13 +0000
Message-ID: <009701c339ca$8eadd5c0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport> <[e-mail]> <001301c3395b$556dc410$0500a8c0@arport>
Subject: Re: UK: PKI "not working"
Date: Mon, 23 Jun 2003 13:41:09 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01C3398D.1A4C0EF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_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: [e-mail]=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 ; [e-mail]=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" <[e-mail]>
      To: "todd glassey" <[e-mail]>; =
<[e-mail]>
      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" <[e-mail]>
      > To: <[e-mail]>; "el-sign: electronic signatures - open
      discussion" <[e-mail]>
      > 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: <[e-mail]>
      > 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

    [e-mail]
    www.slb.com/nws

    SchlumbergerSema=20
    Network & Infrastructure Solutions
    194 Wood Avenue, South
    Iselin, NJ 08830
    Direct Line- [phone]
    Mobile - [phone]



------=_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=[e-mail]=20
  href=3D"mailto:[e-mail]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</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=[e-mail]=20
    href=3D"mailto:[e-mail]">Mitchell Arnone</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
    title=[e-mail]=20
    href=3D"mailto:[e-mail]">todd glassey</A> ; <A=20
    title=[e-mail]=20
    href=3D"mailto:[e-mail]">Anders Rundgren</A> ; <A=20
    title=[e-mail]=20
    href=3D"mailto:[e-mail]">[e-mail]</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;[e-mail]&gt;<BR>To: "todd glassey"=20
      &lt;[e-mail]&gt;; =
&lt;[e-mail]&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;[e-mail]&gt;<BR>&gt; To:=20
      &lt;[e-mail]&gt;; "el-sign: electronic signatures -=20
      open<BR>discussion" &lt;[e-mail]&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;[e-mail]&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>[e-mail]<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- [phone]<BR>Mobile - =
(443)=20
    864-1590<BR><BR></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NKdhrb080874 for <[e-mail]>; Mon, 23 Jun 2003 13:39:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NKdhbO080873 for ietf-pkix-bks; Mon, 23 Jun 2003 13:39:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.hackmasters.net (ppp-217-133-8-148.cust-adsl.tiscali.it [217.133.8.148]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NKderb080861 for <[e-mail]>; Mon, 23 Jun 2003 13:39:41 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 50102F357 for <[e-mail]>; Mon, 23 Jun 2003 22:43:59 +0200 (CEST)
Received: by mail.hackmasters.net (Postfix, from userid 509) id 9A695F90B; Mon, 23 Jun 2003 22:43:57 +0200 (CEST)
Received: from hackmasters.net (galadriel.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id F2E95F357 for <[e-mail]>; Mon, 23 Jun 2003 22:43:54 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 23 Jun 2003 22:39:34 +0200
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: SCEP newest spec
References: <[e-mail]> <00a701c339bb$e649ce10$acf42180@arsenaultd2>
In-Reply-To: <00a701c339bb$e649ce10$acf42180@arsenaultd2>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090700020307090905080703"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------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]                [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC
By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j
aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u
ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG
A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR
TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh
IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl
VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm
l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K
S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB
MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo
14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi
MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF
bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg
ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0
dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg
UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v
cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku
dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku
dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt
by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0
L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu
ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD
VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w
DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex
Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr
RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S
NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL
oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI
mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB
FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm
aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls
aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n
ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs
BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT
AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG
aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4
/Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID
AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/
BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz
D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk
gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu
aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg
TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W
W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v
ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk
d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU
aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw
Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w
a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51
bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v
Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu
MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93
d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB
BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo
EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl
bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78
rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk
poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm
63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1
J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN
txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwNjIzMjAzOTM3WjAjBgkqhkiG9w0BCQQxFgQUAolKf9qgcD9WLxvP
+OILqNNhJF4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB
kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe
VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk
aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ
AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV
BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN
AQEBBQAEgYAA0nvYBGH4+slK5EygDVZy9Cy8DZQHYQvLwhnDo8pTmhjqgQ9hb32+Uim4L97J
ltFNkSZRCOBj5+kyRwRbN0eV8PNS6krSCMMKZJVoYLjhGIC/aUGt1U48EXr+z2k5h31+ib67
8qsbXzyywuXjp9EzjZ1SV8qjcb8xTMVAIUjdcgAAAAAAAA==
--------------ms090700020307090905080703--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NKUvrb080290 for <[e-mail]>; Mon, 23 Jun 2003 13:30:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NKUvTJ080289 for ietf-pkix-bks; Mon, 23 Jun 2003 13:30:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NKUurb080279 for <[e-mail]>; Mon, 23 Jun 2003 13:30:56 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id h5NKUoD8028300; Mon, 23 Jun 2003 16:30:50 -0400 (EDT)
Message-ID: <014a01c339c6$35c55ae0$acf42180@arsenaultd2>
From: "Al Arsenault" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: SCEP newest spec
Date: Mon, 23 Jun 2003 16:29:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJWGrb076664 for <[e-mail]>; Mon, 23 Jun 2003 12:32:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NJWGOj076663 for ietf-pkix-bks; Mon, 23 Jun 2003 12:32:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJWErb076653 for <[e-mail]>; Mon, 23 Jun 2003 12:32:15 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5NJWAch015754; Mon, 23 Jun 2003 12:32:10 -0700 (PDT)
Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <LYL0H460>; Mon, 23 Jun 2003 12:32:06 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: SCEP newest spec
Date: Mon, 23 Jun 2003 12:32:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJHDrb076187 for <[e-mail]>; Mon, 23 Jun 2003 12:17:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NJHDhZ076186 for ietf-pkix-bks; Mon, 23 Jun 2003 12:17:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJHCrb076174 for <[e-mail]>; Mon, 23 Jun 2003 12:17:12 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id h5NJH2D8023555; Mon, 23 Jun 2003 15:17:02 -0400 (EDT)
Message-ID: <00a701c339bb$e649ce10$acf42180@arsenaultd2>
From: "Al Arsenault" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: SCEP newest spec
Date: Mon, 23 Jun 2003 15:16:07 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NHlKrb072269 for <[e-mail]>; Mon, 23 Jun 2003 10:47:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NHlKLN072268 for ietf-pkix-bks; Mon, 23 Jun 2003 10:47:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NHlJrb072263 for <[e-mail]>; Mon, 23 Jun 2003 10:47:19 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h5NHlE2Q027953; Mon, 23 Jun 2003 10:47:14 -0700 (PDT)
Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <LMLHP00A>; Mon, 23 Jun 2003 10:47:14 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: SCEP newest spec
Date: Mon, 23 Jun 2003 10:47:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NEWHrb058416 for <[e-mail]>; Mon, 23 Jun 2003 07:32:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5NEWHPt058415 for ietf-pkix-bks; Mon, 23 Jun 2003 07:32:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NEW9rb058366 for <[e-mail]>; Mon, 23 Jun 2003 07:32:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5NEVgD9028283; Mon, 23 Jun 2003 10:31:43 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100305bb1cbda0d980@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 23 Jun 2003 10:29:29 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: poll for a meeting agenda
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5N7ixrb020032 for <[e-mail]>; Mon, 23 Jun 2003 00:44:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5N7ix2C020031 for ietf-pkix-bks; Mon, 23 Jun 2003 00:44:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5N7ivrb020001 for <[e-mail]>; Mon, 23 Jun 2003 00:44:57 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailb.telia.com (8.12.9/8.12.9) with SMTP id h5N7imC5006023 for <[e-mail]>; Mon, 23 Jun 2003 09:44:53 +0200 (CEST)
X-Original-Recipient: <[e-mail]>
Message-ID: <001301c3395b$556dc410$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport> <[e-mail]>
Subject: Re: UK: PKI "not working"
Date: Mon, 23 Jun 2003 09:44:48 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C3396C.15D46C80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 ; [e-mail]=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" <[e-mail]>
    To: "todd glassey" <[e-mail]>; =
<[e-mail]>
    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" <[e-mail]>
    > To: <[e-mail]>; "el-sign: electronic signatures - open
    discussion" <[e-mail]>
    > 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: <[e-mail]>
    > 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

  [e-mail]
  www.slb.com/nws

  SchlumbergerSema=20
  Network & Infrastructure Solutions
  194 Wood Avenue, South
  Iselin, NJ 08830
  Direct Line- [phone]
  Mobile - [phone]



------=_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=[e-mail]=20
  href=3D"mailto:[e-mail]">Mitchell Arnone</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">todd glassey</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">Anders=20
  Rundgren</A> ; <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</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;[e-mail]&gt;<BR>To: "todd glassey"=20
    &lt;[e-mail]&gt;; =
&lt;[e-mail]&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;[e-mail]&gt;<BR>&gt; To: =
&lt;[e-mail]&gt;;=20
    "el-sign: electronic signatures - open<BR>discussion"=20
    &lt;[e-mail]&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;[e-mail]&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>[e-mail]<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--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5N5fqrb098735 for <[e-mail]>; Sun, 22 Jun 2003 22:41:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5N5fqYN098734 for ietf-pkix-bks; Sun, 22 Jun 2003 22:41:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4c4c.pool.mediaWays.net [217.187.76.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5N5forb098723 for <[e-mail]>; Sun, 22 Jun 2003 22:41:51 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B8F3B930F5 for <[e-mail]>; Mon, 23 Jun 2003 07:41:45 +0200 (CEST)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 13E278C2AF for <[e-mail]>; Mon, 23 Jun 2003 07:41:45 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 23 Jun 2003 07:41:44 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: UK: PKI "not working"
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport> <[e-mail]> <005001c338dd$54707590$020aff0a@tsg1> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.74.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5N5Mjrb098204 for <[e-mail]>; Sun, 22 Jun 2003 22:22:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5N5MjmR098203 for ietf-pkix-bks; Sun, 22 Jun 2003 22:22:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5N5Mgrb098197 for <[e-mail]>; Sun, 22 Jun 2003 22:22:43 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.11.100]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003062305223911300lcolde>; Mon, 23 Jun 2003 05:22:40 +0000
Message-ID: <003e01c33947$72de2c10$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport> <[e-mail]> <005001c338dd$54707590$020aff0a@tsg1> <[e-mail]>
Subject: Re: UK: PKI "not working"
Date: Sun, 22 Jun 2003 22:13:02 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: <[e-mail]>
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.


>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5N1gRrb090538 for <[e-mail]>; Sun, 22 Jun 2003 18:42:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5N1gPZa090535 for ietf-pkix-bks; Sun, 22 Jun 2003 18:42:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5N1gMrb090524 for <[e-mail]>; Sun, 22 Jun 2003 18:42:23 -0700 (PDT) (envelope-from [e-mail])
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id <B0000e2624>; Mon, 23 Jun 2003 11:39:01 +1000
Received: (qmail 3764 invoked from network); 23 Jun 2003 01:41:59 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 23 Jun 2003 01:41:59 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: FW: I-D ACTION:draft-legg-ldap-binary-00.txt
Date: Mon, 23 Jun 2003 11:42:15 +1000
Message-ID: <00c701c33928$ad83d8c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
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:
	[e-mail].
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.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5MIY6rb076017 for <[e-mail]>; Sun, 22 Jun 2003 11:34:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5MIY6X9076016 for ietf-pkix-bks; Sun, 22 Jun 2003 11:34:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.28]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5MIY5rb076008 for <[e-mail]>; Sun, 22 Jun 2003 11:34:05 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (unknown [62.39.220.64]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id E8A519BC51 for <[e-mail]>; Sun, 22 Jun 2003 20:33:55 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sun, 22 Jun 2003 20:37:33 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030509
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: UK: PKI "not working"
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport> <[e-mail]> <005001c338dd$54707590$020aff0a@tsg1>
In-Reply-To: <005001c338dd$54707590$020aff0a@tsg1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5MGs6rb069404 for <[e-mail]>; Sun, 22 Jun 2003 09:54:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5MGs66V069403 for ietf-pkix-bks; Sun, 22 Jun 2003 09:54:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5MGs5rb069378 for <[e-mail]>; Sun, 22 Jun 2003 09:54:05 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (16.sanjose-13-14rs16rt.ca.dial-access.att.net[12.81.5.16]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003062216535111300e841ge>; Sun, 22 Jun 2003 16:53:52 +0000
Message-ID: <007e01c338de$d5142bf0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Mitchell Arnone" <[e-mail]>, "Anders Rundgren" <[e-mail]>, <[e-mail]>
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport> <[e-mail]>
Subject: Re: UK: PKI "not working"
Date: Sun, 22 Jun 2003 09:53:30 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C338A4.22A979F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_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 ; [e-mail]=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=[e-mail]=20
  href=3D"mailto:[e-mail]">Mitchell Arnone</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">todd glassey</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">Anders=20
  Rundgren</A> ; <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</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--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5MGhLrb068000 for <[e-mail]>; Sun, 22 Jun 2003 09:43:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5MGhL4H067999 for ietf-pkix-bks; Sun, 22 Jun 2003 09:43:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5MGhJrb067994 for <[e-mail]>; Sun, 22 Jun 2003 09:43:19 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (16.sanjose-13-14rs16rt.ca.dial-access.att.net[12.81.5.16]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003062216430611100en85ue>; Sun, 22 Jun 2003 16:43:07 +0000
Message-ID: <005001c338dd$54707590$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Mitchell Arnone" <[e-mail]>, "Anders Rundgren" <[e-mail]>, <[e-mail]>
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport> <[e-mail]>
Subject: Re: UK: PKI "not working"
Date: Sun, 22 Jun 2003 09:40:15 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C338A2.490AAE40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_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 ; [e-mail]=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=[e-mail]=20
  href=3D"mailto:[e-mail]">Mitchell Arnone</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">todd glassey</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">Anders=20
  Rundgren</A> ; <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</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--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5MCTLrb055256 for <[e-mail]>; Sun, 22 Jun 2003 05:29:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5MCTJKX055255 for ietf-pkix-bks; Sun, 22 Jun 2003 05:29:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5MCTHrb055246 for <[e-mail]>; Sun, 22 Jun 2003 05:29:18 -0700 (PDT) (envelope-from [e-mail])
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <[e-mail]> for [e-mail]; Sun, 22 Jun 2003 12:27:06 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]> for [e-mail]; Sun, 22 Jun 2003 12:27:04 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <[e-mail]> for [e-mail]; Sun, 22 Jun 2003 12:27:02 +0000 (GMT)
Received: from MArnone-NIS.HOUSTON-OMH (vpnpool114.houston.sinet.slb.com [163.188.124.114]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]>; Sun, 22 Jun 2003 12:27:02 +0000 (GMT)
Content-return: prohibited
Date: Sun, 22 Jun 2003 08:26:34 -0400
From: Mitchell Arnone <[e-mail]>
Subject: Re: UK: PKI "not working"
In-reply-to: <001a01c3386d$88e14040$020aff0a@tsg1>
X-Sender: [e-mail]
To: todd glassey <[e-mail]>, Anders Rundgren <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: multipart/alternative; boundary="Boundary_(ID_0OuWU9GhMsXY5C0yhhHB5w)"
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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" <[e-mail]>
>To: "todd glassey" <[e-mail]>; <ietf-pkix@imc.o=
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" <[e-mail]>
> > To: <[e-mail]>; "el-sign: electronic signatures - open
>discussion" <[e-mail]>
> > 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: <[e-mail]>
> > 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

[e-mail]
www.slb.com/nws

SchlumbergerSema
Network & Infrastructure Solutions
194 Wood Avenue, South
Iselin, NJ 08830
Direct Line- [phone]
Mobile - [phone]


--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;[e-mail]&gt;=
<br>
To: &quot;todd glassey&quot; &lt;[e-mail]&gt;;
&lt;[e-mail]&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;[e-mail]&gt;<br>
&gt; To: &lt;[e-mail]&gt;; &quot;el-sign: electronic signatu=
res
- open<br>
discussion&quot; &lt;[e-mail]&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;[e-mail]&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>
[e-mail]<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- [phone]<br>
Mobile - [phone]<br><br>
</font></html>

--Boundary_(ID_0OuWU9GhMsXY5C0yhhHB5w)--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5M3N4rb005948 for <[e-mail]>; Sat, 21 Jun 2003 20:23:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5M3N2eb005947 for ietf-pkix-bks; Sat, 21 Jun 2003 20:23:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5M3N0rb005942 for <[e-mail]>; Sat, 21 Jun 2003 20:23:00 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (16.sanjose-13-14rs16rt.ca.dial-access.att.net[12.81.5.16]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003062203224411200fnr09e>; Sun, 22 Jun 2003 03:22:45 +0000
Message-ID: <001a01c3386d$88e14040$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
References: <046d01c330ef$6ce50050$020aff0a@tsg1> <008201c3381e$689b5310$0500a8c0@arport>
Subject: Re: UK: PKI "not working"
Date: Sat, 21 Jun 2003 20:18:59 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders, you 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" <[e-mail]>
To: "todd glassey" <[e-mail]>; <[e-mail]>
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" <[e-mail]>
> To: <[e-mail]>; "el-sign: electronic signatures - open
discussion" <[e-mail]>
> 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: <[e-mail]>
> 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
> >
> >
> >
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5LHuKrb091083 for <[e-mail]>; Sat, 21 Jun 2003 10:56:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5LHuKmc091082 for ietf-pkix-bks; Sat, 21 Jun 2003 10:56:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5LHuIrb091075 for <[e-mail]>; Sat, 21 Jun 2003 10:56:19 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.9/8.12.9) with SMTP id h5LHuD7V019352; Sat, 21 Jun 2003 19:56:13 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <008201c3381e$689b5310$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "todd glassey" <[e-mail]>, <[e-mail]>
References: <046d01c330ef$6ce50050$020aff0a@tsg1>
Subject: Re: UK: PKI "not working"
Date: Sat, 21 Jun 2003 19:56:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: <[e-mail]>; "el-sign: electronic signatures - open discussion" <[e-mail]>
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: <[e-mail]>
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
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JLw7rb005221 for <[e-mail]>; Thu, 19 Jun 2003 14:58:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JLw7qD005220 for ietf-pkix-bks; Thu, 19 Jun 2003 14:58:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JLw5rb005215 for <[e-mail]>; Thu, 19 Jun 2003 14:58:05 -0700 (PDT) (envelope-from [e-mail])
Received: from wmcooper (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.10.2/8.10.2) with ESMTP id h5JLw6L15744; Thu, 19 Jun 2003 17:58:06 -0400
From: "Matt Cooper" <[e-mail]>
To: "'Brian Hunter'" <[e-mail]>, <[e-mail]>
Subject: RE: Revocation status checking of self-issued certificates
Date: Thu, 19 Jun 2003 17:58:00 -0400
Message-ID: <001f01c336ad$dcf7b810$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]] 
> Sent: Thursday, June 19, 2003 3:16 PM
> To: Matt Cooper; [e-mail]
> 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: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of Brian Hunter
> > > Sent: Wednesday, June 18, 2003 12:16 PM
> > > To: [e-mail]
> > > 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
> > >
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JJG4rb097333 for <[e-mail]>; Thu, 19 Jun 2003 12:16:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JJG4qx097332 for ietf-pkix-bks; Thu, 19 Jun 2003 12:16:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JJG2rb097319 for <[e-mail]>; Thu, 19 Jun 2003 12:16:03 -0700 (PDT) (envelope-from [e-mail])
Received: from sit.fraunhofer.de (vpnclient02.darmstadt.gmd.de [141.12.37.23]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id VAA21488; Thu, 19 Jun 2003 21:15:42 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 19 Jun 2003 21:16:28 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matt Cooper <[e-mail]>, [e-mail]
Subject: Re: Revocation status checking of self-issued certificates
References: <00b501c335e7$220f9570$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Brian Hunter
> > Sent: Wednesday, June 18, 2003 12:16 PM
> > To: [e-mail]
> > 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
> >


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JF75rb083021 for <[e-mail]>; Thu, 19 Jun 2003 08:07:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JF747J083020 for ietf-pkix-bks; Thu, 19 Jun 2003 08:07:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JF73rb083013 for <[e-mail]>; Thu, 19 Jun 2003 08:07:03 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (56.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.56]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030619150657111003vju2e>; Thu, 19 Jun 2003 15:06:58 +0000
Message-ID: <019e01c33674$6abe79c0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Margus Freudenthal" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <007901c3360f$ae384b00$020aff0a@tsg1> <[e-mail]> <00e401c33658$779018a0$020aff0a@tsg1> <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message ----- 
From: "Margus Freudenthal" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JEdurb081913 for <[e-mail]>; Thu, 19 Jun 2003 07:39:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JEduZT081912 for ietf-pkix-bks; Thu, 19 Jun 2003 07:39:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JEdtrb081906 for <[e-mail]>; Thu, 19 Jun 2003 07:39:55 -0700 (PDT) (envelope-from [e-mail])
Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.12.8/8.12.8) with ESMTP id h5JEdtV1021160; Thu, 19 Jun 2003 09:39:55 -0500 (CDT)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
From: "Matt Crawford" <[e-mail]>
Subject: please clarify 3280
Date: Thu, 19 Jun 2003 09:39:55 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JECZrb078266 for <[e-mail]>; Thu, 19 Jun 2003 07:12:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JECYAp078263 for ietf-pkix-bks; Thu, 19 Jun 2003 07:12:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JECXrb078239 for <[e-mail]>; Thu, 19 Jun 2003 07:12:33 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (56.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.56]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030619141227113001bmi4e>; Thu, 19 Jun 2003 14:12:27 +0000
Message-ID: <015e01c3366c$cdd063a0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Margus Freudenthal" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <007901c3360f$ae384b00$020aff0a@tsg1> <[e-mail]> <00e401c33658$779018a0$020aff0a@tsg1> <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JCcIrb071250 for <[e-mail]>; Thu, 19 Jun 2003 05:38:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JCcIP1071249 for ietf-pkix-bks; Thu, 19 Jun 2003 05:38:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JCcDrb071244 for <[e-mail]>; Thu, 19 Jun 2003 05:38:14 -0700 (PDT) (envelope-from [e-mail])
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id h5JCcEY15126; Thu, 19 Jun 2003 15:38:14 +0300
Message-ID: <[e-mail]>
Date: Thu, 19 Jun 2003 15:38:14 +0300
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a    specific flag in the TST to represent an official TST?)
References: <[e-mail]> <007901c3360f$ae384b00$020aff0a@tsg1> <[e-mail]> <00e401c33658$779018a0$020aff0a@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-info: Headers changed by Barricade
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JBlArb069681 for <[e-mail]>; Thu, 19 Jun 2003 04:47:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5JBlA0K069680 for ietf-pkix-bks; Thu, 19 Jun 2003 04:47:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JBl7rb069674 for <[e-mail]>; Thu, 19 Jun 2003 04:47:08 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (56.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.56]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030619114650112007am5je>; Thu, 19 Jun 2003 11:46:51 +0000
Message-ID: <00e401c33658$779018a0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Margus Freudenthal" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <007901c3360f$ae384b00$020aff0a@tsg1> <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
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
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J7UHrb040884 for <[e-mail]>; Thu, 19 Jun 2003 00:30:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5J7UH9n040883 for ietf-pkix-bks; Thu, 19 Jun 2003 00:30:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J7UDrb040872 for <[e-mail]>; Thu, 19 Jun 2003 00:30:14 -0700 (PDT) (envelope-from [e-mail])
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id h5J7UDK09646; Thu, 19 Jun 2003 10:30:13 +0300
Message-ID: <[e-mail]>
Date: Thu, 19 Jun 2003 10:29:33 +0300
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a   specific flag in the TST to represent an official TST?)
References: <[e-mail]> <007901c3360f$ae384b00$020aff0a@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-info: Headers changed by Barricade
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J35rrb017867 for <[e-mail]>; Wed, 18 Jun 2003 20:05:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5J35rhT017866 for ietf-pkix-bks; Wed, 18 Jun 2003 20:05:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J35orb017857 for <[e-mail]>; Wed, 18 Jun 2003 20:05:51 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (56.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.56]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030619030546113001fikie>; Thu, 19 Jun 2003 03:05:47 +0000
Message-ID: <007901c3360f$ae384b00$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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?
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IMFYrb007831 for <[e-mail]>; Wed, 18 Jun 2003 15:15:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5IMFYkN007829 for ietf-pkix-bks; Wed, 18 Jun 2003 15:15:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IMFWrb007823 for <[e-mail]>; Wed, 18 Jun 2003 15:15:33 -0700 (PDT) (envelope-from [e-mail])
Received: from wmcooper (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.10.2/8.10.2) with ESMTP id h5IMFVW05824; Wed, 18 Jun 2003 18:15:31 -0400
From: "Matt Cooper" <[e-mail]>
To: "'Brian Hunter'" <[e-mail]>, <[e-mail]>
Subject: RE: Revocation status checking of self-issued certificates
Date: Wed, 18 Jun 2003 18:15:26 -0400
Message-ID: <00b501c335e7$220f9570$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Brian Hunter
> Sent: Wednesday, June 18, 2003 12:16 PM
> To: [e-mail]
> 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
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IHPNrb094557 for <[e-mail]>; Wed, 18 Jun 2003 10:25:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5IHPNN6094555 for ietf-pkix-bks; Wed, 18 Jun 2003 10:25:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [67.126.41.36] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IHPLrc094550 for <[e-mail]>; Wed, 18 Jun 2003 10:25:22 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210603bb164e773589@[67.126.41.36]>
In-Reply-To: <00e601c33541$87cc37c0$020aff0a@tsg1>
References: <012a01c332b3$6cd9e560$020aff0a@tsg1> <p05210614bb1286bfc2e0@[63.202.92.152]> <005e01c333ad$c48e8860$020aff0a@tsg1> <p05210605bb15643b322d@[128.89.89.5]> <00e601c33541$87cc37c0$020aff0a@tsg1>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 18 Jun 2003 10:22:45 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IH7erb093984 for <[e-mail]>; Wed, 18 Jun 2003 10:07:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5IH7exr093983 for ietf-pkix-bks; Wed, 18 Jun 2003 10:07:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IH7brb093973 for <[e-mail]>; Wed, 18 Jun 2003 10:07:38 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V5IH04CX04644 for <[e-mail]>; Wed, 18 Jun 2003 13:04:12 -0400
Received: (qmail 17578 invoked by uid 64014); 18 Jun 2003 17:03:11 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.117681 secs); 18 Jun 2003 17:03:11 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 18 Jun 2003 17:03:11 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <MX4BBNG9>; Wed, 18 Jun 2003 13:07:32 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, Matt Cooper <[e-mail]>
Cc: [e-mail]
Subject: RE: RFC 3280: same certificate in a certification path
Date: Wed, 18 Jun 2003 13:07:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

MII9jQYJKoZIhvcNAQcCoII9fjCCPXoCAQExCzAJBgUrDgMCGgUAMIIv2wYJKoZIhvcNAQcBoIIv
zASCL8hDb250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTsNCglib3VuZGFyeT0iLS09
X05leHRQYXJ0X1NUSl80NzkyNzk2OC4xMzA4MDY4MjQiDQoNCg0KLS0tLT1fTmV4dFBhcnRfU1RK
XzQ3OTI3OTY4LjEzMDgwNjgyNA0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9
IlVTLUFTQ0lJIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0K
DQpJIGp1c3Qgd2FudCB0byBjbGFyaWZ5IHRoYXQgdGhlIHRoZSBzdGF0ZW1lbnQgaW4gWC41MDkg
Y2xhdXNlPTIwDQoxMC4xIGlzIG5vdCBpbnRlbmRlZCB0byBpbXBlZGUgaW1wbGVtZW50YXRpb25z
IGZyb20gYW55IHBhdGg9MjANCmRldmVsb3BtZW50IHNjaGVtZSB0aGV5IGNob29zZS4gSXQgaXMg
aW50ZW5kZWQgdG8gYWRkcmVzcyBvbmx5PTIwDQp0aGUgdmFsaWRpdHkgb2YgYSBwYXRoIHRoYXQg
Y29udGFpbnMgdGhlIHNhbWUgY2VydGlmaWNhdGUgdHdvPTIwDQpvciBtb3JlIHRpbWVzIGFuZCB0
aGF0IGlzIG5vdCBjb25zaWRlcmVkIGEgdmFsaWQgcGF0aC4gSG93ZXZlciwNCmlmIHNvbWVvbmUn
cyBzY2hlbWUgZm9yIHBhdGggZGV2ZWxvcG1lbnQgbWVhbnQgdGhhdCB0aGV5IGNyZWF0ZWQ9MjAN
CjUgcGF0aHMgdG8gYmUgY29uc2lkZXJlZCBmb3IgcGF0aCB2YWxpZGF0aW9uIGFuZCBvbmUgb2Yg
dGhvc2U9MjANCnBhdGhzIGluY2x1ZGVkIHRoZSBzYW1lIGNlcnQgdHdpY2UsIHRoZW4gdGhlcmUg
aXMgbm8gcmVhc29uPTIwDQp0byBydW4gcGF0aCB2YWxpZGF0aW9uIGFsZ29yaXRobSBiZWNhdXNl
IHRoYXQgcGF0aCBpcyBub3QgdmFsaWQuPTIwDQoNClguNTA5IGRlbGliZXJhdGVseSBzYXlzIG5v
dGhpbmcgYWJvdXQgdGhlIHdheSBwYXRocyBhcmUgZGV2ZWxvcGVkPTIwDQphbmQgSSBkbyBhZ3Jl
ZSB0aGF0IHNvbWUgc2NoZW1lcyBtYXkgYmUgbW9yZSBlZmZpY2llbnQgdGhhbiBvdGhlcnMuDQoN
CkNoZWVycywNClNoYXJvbj0yMA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
U3RldmUgSGFubmEgPTVCbWFpbHRvOnN0ZXZlLmhhbm5hPTQwc3VuLmNvbT01RA0KU2VudDogVHVl
c2RheSwgSnVuZSAxNywgMjAwMyA0OjMyIFBNDQpUbzogTWF0dCBDb29wZXINCkNjOiBpZXRmLXBr
aXg9NDBpbWMub3JnDQpTdWJqZWN0OiBSZTogUkZDIDMyODA6IHNhbWUgY2VydGlmaWNhdGUgaW4g
YSBjZXJ0aWZpY2F0aW9uIHBhdGgNCg0KDQpNYXR0IENvb3BlciB3cm90ZToNCj4gPiBTbyBJJ20g
bm90IHRlcnJpYmx5IGNvbmNlcm5lZCBhYm91dCB0aGUgc2l6ZSBvZiB0aGUNCj4gPiBidWlsZGVy
J3MgZGVjaXNpb24gdHJlZS4NCj49MjANCj4gSSBTdHJvbmdseSBEaXNhZ3JlZS4gUmVkdWNpbmcg
dGhlIHNpemUgb2YgdGhlIGRlY2lzaW9uIHRyZWUNCj4gaXMgYWJzb2x1dGVseSBpbnN0cnVtZW50
YWwgdG8gbWFraW5nIHBhdGggZGV2ZWxvcG1lbnQgbW9yZQ0KPiBlZmZpY2llbnQuDQoNCldlIGJv
dGggYWdyZWUgdGhhdCB0aGUgZW50aXJlIGRlY2lzaW9uIHRyZWUgbWF5IGJlIHRvbyBsYXJnZQ0K
dG8gd29yayB3aXRoLiBXZSBib3RoIGFncmVlIHRoYXQgYnVpbGRlcnMgc2hvdWxkIHBydW5lIHRo
ZQ0KdHJlZSBhcyB0aGV5IGdvIGJ5IGVsaW1pbmF0aW5nIHBhdGhzIHRoYXQgY291bGQgbmV2ZXIg
YmUgdmFsaWQNCmFuZCB1c2UgaGV1cmlzdGljcyB0byBkZWNpZGUgd2hpY2ggcGF0aHMgYXJlIG1v
c3QgcHJvbWlzaW5nLg0KDQpZb3Ugd291bGQgbGlrZSB0byBoYXZlIGEgcnVsZSBhZ2FpbnN0IHJl
cGVhdGluZyBhIChuYW1lLCBrZXkpDQpwYWlyIGluIGEgcGF0aC4gSSB0aGluayB0aGlzIGNhbiBi
ZSBhIGhldXJpc3RpYywgc2luY2UgSSdtDQpub3QgeWV0IHN1cmUgdGhhdCB0aGVyZSdzIG5vIHZh
bGlkIHJlYXNvbiB0byB3YW50IHRvIGRvIHRoaXMuDQoNCkkgZG9uJ3QgdGhpbmsgd2UncmUgc28g
ZmFyIGFwYXJ0IGhlcmUuDQoNCj4gSSdtIGVudmlzaW9uaW5nIGEgZnV0dXJlIFBLSSBlbnZpcm9u
bWVudCB3aGVyZSB0cnVzdCBpcw0KPiBjb21tdW5pY2F0ZWQgYWNyb3NzIGxhcmdlIGFuZCBkaXZl
cnNlIHJlYWxtcyB0aGF0IG1ha2UNCj4gdG9kYXkncyBCcmlkZ2UgQ0EganVzdCBhIGRyb3AgaW4g
dGhlIGRlY2lzaW9uIHRyZWUgYnVja2V0Lg0KPiAuLi4NCj4gV2l0aCB0aGUgY3VycmVudCBydWxl
IHNldCwgdXNlcnMgY291bGQgd2FpdCBhbGwgZGF5IGFuZA0KPiBub3QgZXhoYXVzdCBhbGwgcG9z
c2libGUgcGF0aHMgd2hpbGUgbG9va2luZyBmb3IgYSB2YWxpZA0KPiBvbmUuDQoNCkkgYWdyZWUg
dGhpcyBpcyBhIGxpa2VseSBmdXR1cmUgYXMgbW9yZSBQS0lzIGFyZSBpbnRlcmNvbm5lY3RlZC4N
CkJ1dCBhZGRpbmcgYSBydWxlIGFnYWluc3QgcmVwZWF0aW5nIGEgKG5hbWUsIGtleSkgcGFpciBp
biBhDQpwYXRoIHdpbGwgbm90IHNvbHZlIHRoZSBwcm9ibGVtIG9mIHBhdGggYnVpbGRpbmcgaW4g
YSBodWdlDQplbnZpcm9ubWVudC4gSXQgd29uJ3QgZXZlbiBoZWxwIG11Y2guIFlvdSBjYW4gYWx3
YXlzIGhhdmUgYQ0KaGV1cmlzdGljIHRoYXQgc3RlZXJzIHlvdSBhd2F5IGZyb20gdGhlc2UgcGF0
aHMgaWYgeW91IGRvbid0DQpiZWxpZXZlIHRoZXkncmUgcHJvbWlzaW5nLg0KDQpXaGF0IHdpbGwg
aGVscCBpbiBhIGh1Z2UgYW5kIGNvbXBsZXggUEtJPw0KDQoqIFNlbmRpbmcgcGFydGlhbCBwYXRo
cyBvciwgZXZlbiBiZXR0ZXIsIGJhZ3Mgb2YgY2VydHMNCiAgKGFzIFMvTUlNRSBhbmQgU1NML1RM
UyBhbGxvdykuIElkZWFsbHksIHRoZXNlIGNlcnRzDQogIHNob3VsZCBnbyBiZXlvbmQgdGhlIEVF
J3MgdHJ1c3QgYW5jaG9yIHRvIGluY2x1ZGUNCiAgb3RoZXIgY2VydHMgbGlua2luZyBpbnRvIHJl
bGV2YW50IHRydXN0IHBvaW50cy4NCg0KKiBIYXZpbmcgZWFjaCBzaWRlIHRlbGwgdGhlIG90aGVy
IHdoYXQgaXRzIHRydXN0IGFuY2hvcnMNCiAgYXJlIChhcyBTU0wvVExTIGFsbG93cyBzZXJ2ZXJz
IHRvIGRvKS4gVGhpcyBoZWxwcw0KICBkZXRlcm1pbmUgd2hpY2ggdHJ1c3QgcG9pbnRzIGFyZSBy
ZWxldmFudC4NCg0KKiBVc2luZyBkZWxlZ2F0ZWQgcGF0aCBkaXNjb3Zlcnkgc28gdGhhdCB0aGUg
RFBEIHNlcnZlcnMgY2FuDQogIGJ1aWxkIGFuZCB1c2Uga25vd2xlZGdlIGFjcm9zcyBtYW55IHF1
ZXJpZXMuDQoNCiogQW5kLCBvZiBjb3Vyc2UsIHZhbGlkYXRpbmcgYXMgeW91IGJ1aWxkIHRvIHBy
dW5lIG91dA0KICBwYXRocyB0aGF0IGNvdWxkIG5ldmVyIGJlIHZhbGlkLiBBbmQgdXNpbmcgaGV1
cmlzdGljcw0KICB0byBzdGVlciB5b3UgdG93YXJkIHBhdGhzIHRoYXQgbG9vayBwcm9taXNpbmcu
IEluY2x1ZGluZw0KICBuYW1lIGNvbnN0cmFpbnRzIGFuZCBwb2xpY3kgY29uc3RyYWludHMgaW4g
Y2VydHMgaGVscHMNCiAgaGV1cmlzdGljcyBmaW5kIHRoZWlyIHdheS4NCg0KT3RoZXIgaWRlYXMs
IGFueW9uZT8NCg0KPiBUaGUgbnVtYmVyIG9mIG5vZGVzIGluIHRoZSBkZWNpc2lvbiB0cmVlIGEg
YnVpbGRlciB2aXNpdHMNCj4gZGVwZW5kcyBvbiB0aGUgZGVzaWduIG9mIHRoZSBidWlsZGVyLiBP
ciwgaW4gdGhlIGNhc2Ugb2Ygbm8NCj4gdmFsaWQgcGF0aCBleGlzdGluZywgaXQgdmlzaXRzIGV2
ZXJ5IHJlYWNoYWJsZSBub2RlLg0KDQpJbiBhIGxhcmdlIGVudmlyb25tZW50LCBpdCBpc24ndCBm
ZWFzaWJsZSB0byB0cnkgZXZlcnkNCnBvc3NpYmxlIHBhdGguIFRoYXQgY291bGQgdGFrZSBkYXlz
LiBBbmQgaWYgY2VydHMgYXJlDQppc3N1ZWQgcmFwaWRseSBlbm91Z2gsIGl0IGNvdWxkIHNpbXBs
eSBuZXZlciBlbmQuIEF0IGENCmNlcnRhaW4gcG9pbnQsIHlvdSAob3IgbWF5YmUgdGhlIHVzZXIp
IG11c3QganVzdCBzYXkNCj0yMkVub3VnaD0yMT0yMiBhbmQgc3RvcCBsb29raW5nLiBCdWlsZGVy
cyBuZWVkIHRvIHByb3ZpZGUNCmZvciB0aGlzLg0KDQpMZXQncyByZXR1cm4gdG8gdGhlIHF1ZXN0
aW9uIG9mIHdoZXRoZXIgdGhlIHByb3Bvc2VkIHJ1bGUNCmFnYWluc3QgcmVwZWF0aW5nIGEgKG5h
bWUsIGtleSkgcGFpciBpbiBhIHBhdGggaGFzIGEgbmV0DQpiZW5lZml0LiBUaGUgZG93bnNpZGUg
YXMgSSBzZWUgaXQgaXMgaW5jcmVhc2VkIGNvbXBsZXhpdHkNCmluIHRoZSB2YWxpZGF0aW9uIGFs
Z29yaXRobSBhbmQgbGVzcyBmbGV4aWJpbGl0eSBmb3IgdGhlDQpDQSBvcGVyYXRvci4gQW5kIHRo
ZSB1cHNpZGU/IFdlJ3JlIG5vdCBwbHVnZ2luZyBhIHNlY3VyaXR5DQpob2xlIGhlcmUuIFRoZSBt
YWluIGFkdmFudGFnZSBpcyB0aGF0IGJ1aWxkZXJzIGNhbiBrbm9jaw0Kb3V0IHRob3NlIHBhdGhz
IGFzIGludmFsaWQuIEJ1dCBidWlsZGVycyBjb3VsZCBhY2NvbXBsaXNoDQphbG1vc3QgdGhlIHNh
bWUgdGhpbmcgYnkganVzdCByYXRpbmcgdGhlbSBhcyB1bnByb21pc2luZw0KaW4gdGhlaXIgaGV1
cmlzdGljLg0KDQpJJ2Qgc2F5IHlvdSBzaG91bGQgdGFrZSB5b3VyIGNhc2UgdG8gdGhlIElTTy9J
VFUgWC41MDkgZ3JvdXAuDQpJZiB0aGV5IGFyZSBjb252aW5jZWQsIHRoZW4gdGhlIFBLSVggd29y
a2luZyBncm91cCBjYW4NCmZvbGxvdyBzdWl0LiBCdXQgSSBkb24ndCB0aGluayB0aGlzIGlzIG5v
dCBhIHN1ZmZpY2llbnRseQ0KY29udmluY2luZyBhcmd1bWVudCB0aGF0IFBLSVggc2hvdWxkIGJy
ZWFrIG5ldyBncm91bmQNCmFuZCBqdW1wIG91dCBhaGVhZCBvZiBJU08vSVRVLCBlc3BlY2lhbGx5
IHdoZW4gd2UncmUgdHJ5aW5nDQp0byB0YWtlIFJGQyAzMjgwIHRvIERyYWZ0IFN0YW5kYXJkLiBU
aGUgZmV3ZXIgY2hhbmdlcywNCnRoZSBiZXR0ZXIuDQoNClRoYW5rcywNCg0KU3RldmUNCg0KUC5T
LiBUaGFua3MgZm9yIGFuIGludGVsbGlnZW50IGRpc2N1c3Npb24uDQoNCi0tLS09X05leHRQYXJ0
X1NUSl80NzkyNzk2OC4xMzA4MDY4MjQNCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vcnRmDQpD
b250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQNCg0KZTF4eWRHWXhYR0Z1YzJsY1lXNXph
V053WnpFeU5USmNabkp2YlhSbGVIUWdYR1JsWm1Zd2UxeG1iMjUwZEdKcw0KRFFwN1hHWXdYR1p6
ZDJsemN5QkJjbWxoYkR0OURRcDdYR1l4WEdadGIyUmxjbTRnUTI5MWNtbGxjaUJPWlhjNw0KZlEw
S2UxeG1NbHhtYm1sc1hHWmphR0Z5YzJWME1pQlRlVzFpYjJ3N2ZRMEtlMXhtTTF4bWJXOWtaWEp1
WEdaag0KYUdGeWMyVjBNQ0JEYjNWeWFXVnlJRTVsZHp0OWZRMEtlMXhqYjJ4dmNuUmliRnh5WldR
d1hHZHlaV1Z1TUZ4aQ0KYkhWbE1EdGNjbVZrTUZ4bmNtVmxiakJjWW14MVpUSTFOVHQ5RFFwY2RX
TXhYSEJoY21SY2NHeGhhVzVjWkdWbQ0KZEdGaU16WXdJRnhtTUZ4bWN6SXdJRWtnYW5WemRDQjNZ
VzUwSUhSdklHTnNZWEpwWm5rZ2RHaGhkQ0IwYUdVZw0KZEdobElITjBZWFJsYldWdWRDQnBiaUJZ
TGpVd09TQmpiR0YxYzJVZ1hIQmhjZzBLTVRBdU1TQnBjeUJ1YjNRZw0KYVc1MFpXNWtaV1FnZEc4
Z2FXMXdaV1JsSUdsdGNHeGxiV1Z1ZEdGMGFXOXVjeUJtY205dElHRnVlU0J3WVhSbw0KSUZ4d1lY
SU5DbVJsZG1Wc2IzQnRaVzUwSUhOamFHVnRaU0IwYUdWNUlHTm9iMjl6WlM0Z1NYUWdhWE1nYVc1
MA0KWlc1a1pXUWdkRzhnWVdSa2NtVnpjeUJ2Ym14NUlGeHdZWElOQ25Sb1pTQjJZV3hwWkdsMGVT
QnZaaUJoSUhCaA0KZEdnZ2RHaGhkQ0JqYjI1MFlXbHVjeUIwYUdVZ2MyRnRaU0JqWlhKMGFXWnBZ
MkYwWlNCMGQyOGdYSEJoY2cwSw0KYjNJZ2JXOXlaU0IwYVcxbGN5QmhibVFnZEdoaGRDQnBjeUJ1
YjNRZ1kyOXVjMmxrWlhKbFpDQmhJSFpoYkdsaw0KSUhCaGRHZ3VJRWh2ZDJWMlpYSXNYSEJoY2cw
S2FXWWdjMjl0Wlc5dVpTZHpJSE5qYUdWdFpTQm1iM0lnY0dGMA0KYUNCa1pYWmxiRzl3YldWdWRD
QnRaV0Z1ZENCMGFHRjBJSFJvWlhrZ1kzSmxZWFJsWkNCY2NHRnlEUW8xSUhCaA0KZEdoeklIUnZJ
R0psSUdOdmJuTnBaR1Z5WldRZ1ptOXlJSEJoZEdnZ2RtRnNhV1JoZEdsdmJpQmhibVFnYjI1bA0K
SUc5bUlIUm9iM05sSUZ4d1lYSU5DbkJoZEdoeklHbHVZMngxWkdWa0lIUm9aU0J6WVcxbElHTmxj
blFnZEhkcA0KWTJVc0lIUm9aVzRnZEdobGNtVWdhWE1nYm04Z2NtVmhjMjl1SUZ4d1lYSU5DblJ2
SUhKMWJpQndZWFJvSUhaaA0KYkdsa1lYUnBiMjRnWVd4bmIzSnBkR2h0SUdKbFkyRjFjMlVnZEdo
aGRDQndZWFJvSUdseklHNXZkQ0IyWVd4cA0KWkM0Z1hIQmhjZzBLWEhCaGNnMEtXQzQxTURrZ1pH
VnNhV0psY21GMFpXeDVJSE5oZVhNZ2JtOTBhR2x1WnlCaA0KWW05MWRDQjBhR1VnZDJGNUlIQmhk
R2h6SUdGeVpTQmtaWFpsYkc5d1pXUWdYSEJoY2cwS1lXNWtJRWtnWkc4Zw0KWVdkeVpXVWdkR2ho
ZENCemIyMWxJSE5qYUdWdFpYTWdiV0Y1SUdKbElHMXZjbVVnWldabWFXTnBaVzUwSUhSbw0KWVc0
Z2IzUm9aWEp6TGx4d1lYSU5DbHh3WVhJTkNrTm9aV1Z5Y3l4Y2NHRnlEUXBUYUdGeWIyNGdYSEJo
Y2cwSw0KWEhCaGNnMEtMUzB0TFMxUGNtbG5hVzVoYkNCTlpYTnpZV2RsTFMwdExTMWNjR0Z5RFFw
R2NtOXRPaUJUZEdWMg0KWlNCSVlXNXVZU0JiYldGcGJIUnZPbk4wWlhabExtaGhibTVoUUhOMWJp
NWpiMjFkWEhCaGNnMEtVMlZ1ZERvZw0KVkhWbGMyUmhlU3dnU25WdVpTQXhOeXdnTWpBd015QTBP
ak15SUZCTlhIQmhjZzBLVkc4NklFMWhkSFFnUTI5dg0KY0dWeVhIQmhjZzBLUTJNNklHbGxkR1l0
Y0d0cGVFQnBiV011YjNKblhIQmhjZzBLVTNWaWFtVmpkRG9nVW1VNg0KSUZKR1F5QXpNamd3T2lC
ellXMWxJR05sY25ScFptbGpZWFJsSUdsdUlHRWdZMlZ5ZEdsbWFXTmhkR2x2YmlCdw0KWVhSb1hI
QmhjZzBLWEhCaGNnMEtYSEJoY2cwS1RXRjBkQ0JEYjI5d1pYSWdkM0p2ZEdVNlhIQmhjZzBLUGlB
Kw0KSUZOdklFa25iU0J1YjNRZ2RHVnljbWxpYkhrZ1kyOXVZMlZ5Ym1Wa0lHRmliM1YwSUhSb1pT
QnphWHBsSUc5bQ0KSUhSb1pWeHdZWElOQ2o0Z1BpQmlkV2xzWkdWeUozTWdaR1ZqYVhOcGIyNGdk
SEpsWlM1Y2NHRnlEUW8rSUZ4dw0KWVhJTkNqNGdTU0JUZEhKdmJtZHNlU0JFYVhOaFozSmxaUzRn
VW1Wa2RXTnBibWNnZEdobElITnBlbVVnYjJZZw0KZEdobElHUmxZMmx6YVc5dUlIUnlaV1ZjY0dG
eURRbytJR2x6SUdGaWMyOXNkWFJsYkhrZ2FXNXpkSEoxYldWdQ0KZEdGc0lIUnZJRzFoYTJsdVp5
QndZWFJvSUdSbGRtVnNiM0J0Wlc1MElHMXZjbVZjY0dGeURRbytJR1ZtWm1sag0KYVdWdWRDNWNj
R0Z5RFFwY2NHRnlEUXBYWlNCaWIzUm9JR0ZuY21WbElIUm9ZWFFnZEdobElHVnVkR2x5WlNCaw0K
WldOcGMybHZiaUIwY21WbElHMWhlU0JpWlNCMGIyOGdiR0Z5WjJWY2NHRnlEUXAwYnlCM2IzSnJJ
SGRwZEdndQ0KSUZkbElHSnZkR2dnWVdkeVpXVWdkR2hoZENCaWRXbHNaR1Z5Y3lCemFHOTFiR1Fn
Y0hKMWJtVWdkR2hsWEhCaA0KY2cwS2RISmxaU0JoY3lCMGFHVjVJR2R2SUdKNUlHVnNhVzFwYm1G
MGFXNW5JSEJoZEdoeklIUm9ZWFFnWTI5MQ0KYkdRZ2JtVjJaWElnWW1VZ2RtRnNhV1JjY0dGeURR
cGhibVFnZFhObElHaGxkWEpwYzNScFkzTWdkRzhnWkdWag0KYVdSbElIZG9hV05vSUhCaGRHaHpJ
R0Z5WlNCdGIzTjBJSEJ5YjIxcGMybHVaeTVjY0dGeURRcGNjR0Z5RFFwWg0KYjNVZ2QyOTFiR1Fn
YkdsclpTQjBieUJvWVhabElHRWdjblZzWlNCaFoyRnBibk4wSUhKbGNHVmhkR2x1WnlCaA0KSUNo
dVlXMWxMQ0JyWlhrcFhIQmhjZzBLY0dGcGNpQnBiaUJoSUhCaGRHZ3VJRWtnZEdocGJtc2dkR2hw
Y3lCag0KWVc0Z1ltVWdZU0JvWlhWeWFYTjBhV01zSUhOcGJtTmxJRWtuYlZ4d1lYSU5DbTV2ZENC
NVpYUWdjM1Z5WlNCMA0KYUdGMElIUm9aWEpsSjNNZ2JtOGdkbUZzYVdRZ2NtVmhjMjl1SUhSdklI
ZGhiblFnZEc4Z1pHOGdkR2hwY3k1Yw0KY0dGeURRcGNjR0Z5RFFwSklHUnZiaWQwSUhSb2FXNXJJ
SGRsSjNKbElITnZJR1poY2lCaGNHRnlkQ0JvWlhKbA0KTGx4d1lYSU5DbHh3WVhJTkNqNGdTU2R0
SUdWdWRtbHphVzl1YVc1bklHRWdablYwZFhKbElGQkxTU0JsYm5acA0KY205dWJXVnVkQ0IzYUdW
eVpTQjBjblZ6ZENCcGMxeHdZWElOQ2o0Z1kyOXRiWFZ1YVdOaGRHVmtJR0ZqY205eg0KY3lCc1lY
Sm5aU0JoYm1RZ1pHbDJaWEp6WlNCeVpXRnNiWE1nZEdoaGRDQnRZV3RsWEhCaGNnMEtQaUIwYjJS
aA0KZVNkeklFSnlhV1JuWlNCRFFTQnFkWE4wSUdFZ1pISnZjQ0JwYmlCMGFHVWdaR1ZqYVhOcGIy
NGdkSEpsWlNCaQ0KZFdOclpYUXVYSEJoY2cwS1BpQXVMaTVjY0dGeURRbytJRmRwZEdnZ2RHaGxJ
R04xY25KbGJuUWdjblZzWlNCeg0KWlhRc0lIVnpaWEp6SUdOdmRXeGtJSGRoYVhRZ1lXeHNJR1Jo
ZVNCaGJtUmNjR0Z5RFFvK0lHNXZkQ0JsZUdoaA0KZFhOMElHRnNiQ0J3YjNOemFXSnNaU0J3WVhS
b2N5QjNhR2xzWlNCc2IyOXJhVzVuSUdadmNpQmhJSFpoYkdsaw0KWEhCaGNnMEtQaUJ2Ym1VdVhI
QmhjZzBLWEhCaGNnMEtTU0JoWjNKbFpTQjBhR2x6SUdseklHRWdiR2xyWld4NQ0KSUdaMWRIVnla
U0JoY3lCdGIzSmxJRkJMU1hNZ1lYSmxJR2x1ZEdWeVkyOXVibVZqZEdWa0xseHdZWElOQ2tKMQ0K
ZENCaFpHUnBibWNnWVNCeWRXeGxJR0ZuWVdsdWMzUWdjbVZ3WldGMGFXNW5JR0VnS0c1aGJXVXNJ
R3RsZVNrZw0KY0dGcGNpQnBiaUJoWEhCaGNnMEtjR0YwYUNCM2FXeHNJRzV2ZENCemIyeDJaU0Iw
YUdVZ2NISnZZbXhsYlNCdg0KWmlCd1lYUm9JR0oxYVd4a2FXNW5JR2x1SUdFZ2FIVm5aVnh3WVhJ
TkNtVnVkbWx5YjI1dFpXNTBMaUJKZENCMw0KYjI0bmRDQmxkbVZ1SUdobGJIQWdiWFZqYUM0Z1dX
OTFJR05oYmlCaGJIZGhlWE1nYUdGMlpTQmhYSEJoY2cwSw0KYUdWMWNtbHpkR2xqSUhSb1lYUWdj
M1JsWlhKeklIbHZkU0JoZDJGNUlHWnliMjBnZEdobGMyVWdjR0YwYUhNZw0KYVdZZ2VXOTFJR1J2
YmlkMFhIQmhjZzBLWW1Wc2FXVjJaU0IwYUdWNUozSmxJSEJ5YjIxcGMybHVaeTVjY0dGeQ0KRFFw
Y2NHRnlEUXBYYUdGMElIZHBiR3dnYUdWc2NDQnBiaUJoSUdoMVoyVWdZVzVrSUdOdmJYQnNaWGdn
VUV0Sg0KUDF4d1lYSU5DbHh3WVhJTkNpb2dVMlZ1WkdsdVp5QndZWEowYVdGc0lIQmhkR2h6SUc5
eUxDQmxkbVZ1SUdKbA0KZEhSbGNpd2dZbUZuY3lCdlppQmpaWEowYzF4d1lYSU5DaUFnS0dGeklG
TXZUVWxOUlNCaGJtUWdVMU5NTDFSTQ0KVXlCaGJHeHZkeWt1SUVsa1pXRnNiSGtzSUhSb1pYTmxJ
R05sY25SelhIQmhjZzBLSUNCemFHOTFiR1FnWjI4Zw0KWW1WNWIyNWtJSFJvWlNCRlJTZHpJSFJ5
ZFhOMElHRnVZMmh2Y2lCMGJ5QnBibU5zZFdSbFhIQmhjZzBLSUNCdg0KZEdobGNpQmpaWEowY3lC
c2FXNXJhVzVuSUdsdWRHOGdjbVZzWlhaaGJuUWdkSEoxYzNRZ2NHOXBiblJ6TGx4dw0KWVhJTkNs
eHdZWElOQ2lvZ1NHRjJhVzVuSUdWaFkyZ2djMmxrWlNCMFpXeHNJSFJvWlNCdmRHaGxjaUIzYUdG
MA0KSUdsMGN5QjBjblZ6ZENCaGJtTm9iM0p6WEhCaGNnMEtJQ0JoY21VZ0tHRnpJRk5UVEM5VVRG
TWdZV3hzYjNkeg0KSUhObGNuWmxjbk1nZEc4Z1pHOHBMaUJVYUdseklHaGxiSEJ6WEhCaGNnMEtJ
Q0JrWlhSbGNtMXBibVVnZDJocA0KWTJnZ2RISjFjM1FnY0c5cGJuUnpJR0Z5WlNCeVpXeGxkbUZ1
ZEM1Y2NHRnlEUXBjY0dGeURRb3FJRlZ6YVc1bg0KSUdSbGJHVm5ZWFJsWkNCd1lYUm9JR1JwYzJO
dmRtVnllU0J6YnlCMGFHRjBJSFJvWlNCRVVFUWdjMlZ5ZG1WeQ0KY3lCallXNWNjR0Z5RFFvZ0lH
SjFhV3hrSUdGdVpDQjFjMlVnYTI1dmQyeGxaR2RsSUdGamNtOXpjeUJ0WVc1NQ0KSUhGMVpYSnBa
WE11WEhCaGNnMEtYSEJoY2cwS0tpQkJibVFzSUc5bUlHTnZkWEp6WlN3Z2RtRnNhV1JoZEdsdQ0K
WnlCaGN5QjViM1VnWW5WcGJHUWdkRzhnY0hKMWJtVWdiM1YwWEhCaGNnMEtJQ0J3WVhSb2N5QjBh
R0YwSUdOdg0KZFd4a0lHNWxkbVZ5SUdKbElIWmhiR2xrTGlCQmJtUWdkWE5wYm1jZ2FHVjFjbWx6
ZEdsamMxeHdZWElOQ2lBZw0KZEc4Z2MzUmxaWElnZVc5MUlIUnZkMkZ5WkNCd1lYUm9jeUIwYUdG
MElHeHZiMnNnY0hKdmJXbHphVzVuTGlCSg0KYm1Oc2RXUnBibWRjY0dGeURRb2dJRzVoYldVZ1ky
OXVjM1J5WVdsdWRITWdZVzVrSUhCdmJHbGplU0JqYjI1eg0KZEhKaGFXNTBjeUJwYmlCalpYSjBj
eUJvWld4d2MxeHdZWElOQ2lBZ2FHVjFjbWx6ZEdsamN5Qm1hVzVrSUhSbw0KWldseUlIZGhlUzVj
Y0dGeURRcGNjR0Z5RFFwUGRHaGxjaUJwWkdWaGN5d2dZVzU1YjI1bFAxeHdZWElOQ2x4dw0KWVhJ
TkNqNGdWR2hsSUc1MWJXSmxjaUJ2WmlCdWIyUmxjeUJwYmlCMGFHVWdaR1ZqYVhOcGIyNGdkSEps
WlNCaA0KSUdKMWFXeGtaWElnZG1semFYUnpYSEJoY2cwS1BpQmtaWEJsYm1SeklHOXVJSFJvWlNC
a1pYTnBaMjRnYjJZZw0KZEdobElHSjFhV3hrWlhJdUlFOXlMQ0JwYmlCMGFHVWdZMkZ6WlNCdlpp
QnViMXh3WVhJTkNqNGdkbUZzYVdRZw0KY0dGMGFDQmxlR2x6ZEdsdVp5d2dhWFFnZG1semFYUnpJ
R1YyWlhKNUlISmxZV05vWVdKc1pTQnViMlJsTGx4dw0KWVhJTkNseHdZWElOQ2tsdUlHRWdiR0Z5
WjJVZ1pXNTJhWEp2Ym0xbGJuUXNJR2wwSUdsemJpZDBJR1psWVhOcA0KWW14bElIUnZJSFJ5ZVNC
bGRtVnllVnh3WVhJTkNuQnZjM05wWW14bElIQmhkR2d1SUZSb1lYUWdZMjkxYkdRZw0KZEdGclpT
QmtZWGx6TGlCQmJtUWdhV1lnWTJWeWRITWdZWEpsWEhCaGNnMEthWE56ZFdWa0lISmhjR2xrYkhr
Zw0KWlc1dmRXZG9MQ0JwZENCamIzVnNaQ0J6YVcxd2JIa2dibVYyWlhJZ1pXNWtMaUJCZENCaFhI
QmhjZzBLWTJWeQ0KZEdGcGJpQndiMmx1ZEN3Z2VXOTFJQ2h2Y2lCdFlYbGlaU0IwYUdVZ2RYTmxj
aWtnYlhWemRDQnFkWE4wSUhOaA0KZVZ4d1lYSU5DaUpGYm05MVoyZ2hJaUJoYm1RZ2MzUnZjQ0Jz
YjI5cmFXNW5MaUJDZFdsc1pHVnljeUJ1WldWaw0KSUhSdklIQnliM1pwWkdWY2NHRnlEUXBtYjNJ
Z2RHaHBjeTVjY0dGeURRcGNjR0Z5RFFwTVpYUW5jeUJ5WlhSMQ0KY200Z2RHOGdkR2hsSUhGMVpY
TjBhVzl1SUc5bUlIZG9aWFJvWlhJZ2RHaGxJSEJ5YjNCdmMyVmtJSEoxYkdWYw0KY0dGeURRcGha
MkZwYm5OMElISmxjR1ZoZEdsdVp5QmhJQ2h1WVcxbExDQnJaWGtwSUhCaGFYSWdhVzRnWVNCdw0K
WVhSb0lHaGhjeUJoSUc1bGRGeHdZWElOQ21KbGJtVm1hWFF1SUZSb1pTQmtiM2R1YzJsa1pTQmhj
eUJKSUhObA0KWlNCcGRDQnBjeUJwYm1OeVpXRnpaV1FnWTI5dGNHeGxlR2wwZVZ4d1lYSU5DbWx1
SUhSb1pTQjJZV3hwWkdGMA0KYVc5dUlHRnNaMjl5YVhSb2JTQmhibVFnYkdWemN5Qm1iR1Y0YVdK
cGJHbDBlU0JtYjNJZ2RHaGxYSEJoY2cwSw0KUTBFZ2IzQmxjbUYwYjNJdUlFRnVaQ0IwYUdVZ2RY
QnphV1JsUHlCWFpTZHlaU0J1YjNRZ2NHeDFaMmRwYm1jZw0KWVNCelpXTjFjbWwwZVZ4d1lYSU5D
bWh2YkdVZ2FHVnlaUzRnVkdobElHMWhhVzRnWVdSMllXNTBZV2RsSUdseg0KSUhSb1lYUWdZblZw
YkdSbGNuTWdZMkZ1SUd0dWIyTnJYSEJoY2cwS2IzVjBJSFJvYjNObElIQmhkR2h6SUdGeg0KSUds
dWRtRnNhV1F1SUVKMWRDQmlkV2xzWkdWeWN5QmpiM1ZzWkNCaFkyTnZiWEJzYVhOb1hIQmhjZzBL
WVd4dA0KYjNOMElIUm9aU0J6WVcxbElIUm9hVzVuSUdKNUlHcDFjM1FnY21GMGFXNW5JSFJvWlcw
Z1lYTWdkVzV3Y205dA0KYVhOcGJtZGNjR0Z5RFFwcGJpQjBhR1ZwY2lCb1pYVnlhWE4wYVdNdVhI
QmhjZzBLWEhCaGNnMEtTU2RrSUhOaA0KZVNCNWIzVWdjMmh2ZFd4a0lIUmhhMlVnZVc5MWNpQmpZ
WE5sSUhSdklIUm9aU0JKVTA4dlNWUlZJRmd1TlRBNQ0KSUdkeWIzVndMbHh3WVhJTkNrbG1JSFJv
WlhrZ1lYSmxJR052Ym5acGJtTmxaQ3dnZEdobGJpQjBhR1VnVUV0Sg0KV0NCM2IzSnJhVzVuSUdk
eWIzVndJR05oYmx4d1lYSU5DbVp2Ykd4dmR5QnpkV2wwTGlCQ2RYUWdTU0JrYjI0bg0KZENCMGFH
bHVheUIwYUdseklHbHpJRzV2ZENCaElITjFabVpwWTJsbGJuUnNlVnh3WVhJTkNtTnZiblpwYm1O
cA0KYm1jZ1lYSm5kVzFsYm5RZ2RHaGhkQ0JRUzBsWUlITm9iM1ZzWkNCaWNtVmhheUJ1WlhjZ1oz
SnZkVzVrWEhCaA0KY2cwS1lXNWtJR3AxYlhBZ2IzVjBJR0ZvWldGa0lHOW1JRWxUVHk5SlZGVXNJ
R1Z6Y0dWamFXRnNiSGtnZDJobA0KYmlCM1pTZHlaU0IwY25scGJtZGNjR0Z5RFFwMGJ5QjBZV3Rs
SUZKR1F5QXpNamd3SUhSdklFUnlZV1owSUZOMA0KWVc1a1lYSmtMaUJVYUdVZ1ptVjNaWElnWTJo
aGJtZGxjeXhjY0dGeURRcDBhR1VnWW1WMGRHVnlMbHh3WVhJTg0KQ2x4d1lYSU5DbFJvWVc1cmN5
eGNjR0Z5RFFwY2NHRnlEUXBUZEdWMlpWeHdZWElOQ2x4d1lYSU5DbEF1VXk0Zw0KVkdoaGJtdHpJ
R1p2Y2lCaGJpQnBiblJsYkd4cFoyVnVkQ0JrYVhOamRYTnphVzl1TGx4d1lYSU5DbjA9DQotLS0t
PV9OZXh0UGFydF9TVEpfNDc5Mjc5NjguMTMwODA2ODI0LS0NCg0KoIILHjCCA6YwggKOoAMCAQIC
BD38wzEwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAO
BgNVBAsTB1IgYW5kIEQwHhcNMDMwNDI1MTIyODU2WhcNMDMxMDI1MTI1ODU2WjBZMQswCQYDVQQG
EwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEmMA4GA1UEBRMHMTYxNjY3
MTAUBgNVBAMTDVNoYXJvbiBCb2V5ZW4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALWpMajQ
C3A9ELqlE6r3+kv5Jr2dK1mB4WVFd4GL3isMtI7zgXEzmAw4Bfk9lzp4P75iyYROY2pG1T9ks8DR
qVZTbgcRVE7gevIDklDsiZp53mV5gfih14jGty67AX7noCPf6nsSqkB4iHx2a3TxYqobjH7F6i+6
0I3d/ZUCkquTAgMBAAGjggEgMIIBHDALBgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwMzA0MjUx
MjI4NTZagQ8yMDAzMDgzMTE0NTg1NlowJAYDVR0RBB0wG4EZc2hhcm9uLmJvZXllbkBlbnRydXN0
LmNvbTBUBgNVHR8ETTBLMEmgR6BFpEMwQTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3Qx
EDAOBgNVBAsTB1IgYW5kIEQxDjAMBgNVBAMTBUNSTDI0MB8GA1UdIwQYMBaAFPPwLCjmOac0Gaua
kaimZkCSnOJxMB0GA1UdDgQWBBRRDb9gl2zlGMvr6Ud8dY8lpmf0djAJBgNVHRMEAjAAMBkGCSqG
SIb2fQdBAAQMMAobBFY3LjADAgSwMA0GCSqGSIb3DQEBBQUAA4IBAQBIQEtBZnVWoWfKMhHaJxYx
tRjAAMVIAKPd4ZmZUSd2++lRAc41ZQ3fKvcX/OcEb+z1zitWtIRtxetwMWhnxjncr7Dw860AV5Ei
PSCPaxGT+wY4jm5ZVQscr2yavX7Dsln6qcSAZB4iynCgIq/tCWOKZDshE3heFVvQpChgB515/F+H
9X/jp/524GBbI1ijoT5uZayN/MKLNeiBdC0ZrJo1eSj91g6eyfil0BIZKtqhcfIB5Rv6ztVCo9Qg
MKDvo0I1Z5zfZO9BOXKQyWf1IBVtvUP5pi9w266g9hre6w/QIW8Tq1uUsSPqM2JMqkGJWDnjS0HI
SlAHoWGpT2/igcSGMIIDdzCCAl+gAwIBAgIEPfzFLzANBgkqhkiG9w0BAQUFADAxMQswCQYDVQQG
EwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDAeFw0wMzA1MTIxMjA5MzBa
Fw0wMzExMTIxMjM5MzBaMFkxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQL
EwdSIGFuZCBEMSYwDgYDVQQFEwcxNjE2NjcxMBQGA1UEAxMNU2hhcm9uIEJvZXllbjCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAo6Fl6ltnYS/22/pvoIr8lO9eRkvdCinBx4tgVO+QRZF90u+Q
Ttz4Brv9qf4I8FMTb8KSWQnjv4Dg0gwjZnxZ+lxguVFFGrJrSDyOMCYPsKIGaz8JPrUvlQqfB/8Y
u+1/4koVrHCxD4qI26vFF8D9mPGMjQVQp1HoN/XEzDS+zGcCAwEAAaOB8jCB7zALBgNVHQ8EBAMC
BSAwJAYDVR0RBB0wG4EZc2hhcm9uLmJvZXllbkBlbnRydXN0LmNvbTBUBgNVHR8ETTBLMEmgR6BF
pEMwQTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQxDjAM
BgNVBAMTBUNSTDI1MB8GA1UdIwQYMBaAFPPwLCjmOac0GauakaimZkCSnOJxMB0GA1UdDgQWBBTf
/D6k/mHuAALWEVNvhucj5Cx0xDAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgSw
MA0GCSqGSIb3DQEBBQUAA4IBAQBXXhNix13ybT60c+xhpIFCdTyqCqoa8IHzdtWdI6ltun2zxmEG
YzMnfXM8cx9vr5dEmWehIIeUt12hlLiOBfdVoakEBJ6LaoLOkveKyEVpPdR9aMvEIl5zdslQKnzC
WlFNh4HII2EjGVnnG4PY72EJ++0zwYu7PTMzTD4Hrta6wSnImddXdou6zjW1Rg/ipzzC7sZLNqVy
hEkUdO6NY04oH3lAfvSazcFHCED1DNEb5rXC8OT2i+KhSKxY04gFehD0d6gzoe40ZW5STfmnz3bv
Xk7ClE/TvmJMc6hkrQ9Az3snyeg0Ybu+xiauNDtEqbngXdeYt+LJfxIBfMN4Ver6MIID9TCCAt2g
AwIBAgIEMkiqIDANBgkqhkiG9w0BAQUFADAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz
dDEQMA4GA1UECxMHUiBhbmQgRDAeFw0wMjA0MTcwMjIwMjZaFw0yMjA0MTcwMjUwMjZaMDExCzAJ
BgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvIeIjfoD5D86sD8CehB+kVhYJTL+VuaUZiVijGevUTlnUAwy
1WpOYVpFCa8VK116TJ+o99axN1jMbsVBYfRzFk9SWl4iAH+PyJ1S6D5Yl593KjHPhBCfdD0v9KoP
qXhCwRlkvupreNlFx3FFk2Uf5jG/i9SCP925OXbz3wod2mdIu8ueNWgTmA2XAOBdHZg6HYKo50BW
UIgtRwFvzbh1J57+gNdHxMYLZmvj5saS1mDTSibkPH/AY+D+xAozRmyOYa4SY2HVfZSM2SP7MkuV
tKp17pzhwicoWAGKXrKeDRWDYeZBTJjHoNP/SXKdpSzY7rV8GPrfWFoogc4350VbowIDAQABo4IB
EzCCAQ8wEQYJYIZIAYb4QgEBBAQDAgAHMFMGA1UdHwRMMEowSKBGoESkQjBAMQswCQYDVQQGEwJD
QTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDENMAsGA1UEAxMEQ1JMMTArBgNV
HRAEJDAigA8yMDAyMDQxNzAyMjAyNlqBDzIwMjIwNDE3MDI1MDI2WjALBgNVHQ8EBAMCAQYwHwYD
VR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFPPwLCjmOac0GauakaimZkCS
nOJxMAwGA1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjYuMDo0LjADAgSQMA0GCSqGSIb3
DQEBBQUAA4IBAQCAPnm1Rpn5ya5kBLFpckRtw+XuY/G5m6uQH9hVXgechp+i6/tXlYjQ8ccnJy1H
cOmPS718LkG4drxBfrhjO9aTudv+TNIMR9izay796hsBk7raBpYtxavOEjxb8jfp+EelztgcSZo7
37mYzcrr9pDjzJldsriCzPDU/N052R+RJ4Rs/0IiuWzIVH7y99S9O+rG14PjEKNQhA39gTwg9iMB
tQoksDfKu09UCaFsE7aYUC8eE0wzki4G+Dl5RKE57MGaYAh+cccmyPR6Xw/gl8Yo3YGhOWz3qatA
hbbplACm9LSmduMSLXQybke6cq5JUb8c9VMzi9cIiv6Hbf1/xObPMYICZTCCAmECAQEwOTAxMQsw
CQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRAIEPfzDMTAJBgUr
DgMCGgUAoIIBgjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2
MTgxNzA4MDZaMCMGCSqGSIb3DQEJBDEWBBQ1YcsHiGtb3HyVezMZANvWWMnNazCCASEGCSqGSIb3
DQEJDzGCARIwggEOMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMA8GCSqG
SIb2fQdCCgICAIAwDgYIKoZIhvcNAwICAgCAMAoGCCqGSIb3DQMHMA0GCysGAQQBgTwHAQECMA4G
CSqGSIb2fQdCCgIBKDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAHBgUrDgMCGjAKBggqhkiG9w0C
BTALBgkqhkiG9w0BAQEwCwYJKoZIhvcNAQEHMAkGByqGSM44BAEwCQYHKoZIzj0CATALBgkqhkiG
9w0BAQUwCwYJKoZIhvcNAQEEMAkGByqGSM44BAMwCQYHKoZIzj0EATAMBgoqhkiG9w0BCQ8BMA0G
CSqGSIb3DQEBAQUABIGAFHXxzekixLJoB3Fkn3OYr3jR4PU3VDNv1Goh3jgbXAVC8AgTOfXwCVFw
3KHo07syWF/LV3qUDTP5xQ9iKZwezwmCz4U1MxxiQsqWh1p7OkhWGjZRjjRjDA+T6jsXs9XPcEBk
GIEX658jFysUMgMSt+ynNzuUNovKQjQtmdid/EA=


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IGEwrb088149 for <[e-mail]>; Wed, 18 Jun 2003 09:14:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5IGEwKx088148 for ietf-pkix-bks; Wed, 18 Jun 2003 09:14:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IGEurb088104 for <[e-mail]>; Wed, 18 Jun 2003 09:14:57 -0700 (PDT) (envelope-from [e-mail])
Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id SAA14378 for <[e-mail]>; Wed, 18 Jun 2003 18:14:43 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 18 Jun 2003 18:15:40 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Revocation status checking of self-issued certificates
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IFLJrb086172 for <[e-mail]>; Wed, 18 Jun 2003 08:21:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5IFLJAH086171 for ietf-pkix-bks; Wed, 18 Jun 2003 08:21:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IFLHrb086166 for <[e-mail]>; Wed, 18 Jun 2003 08:21:18 -0700 (PDT) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA08549 for <[e-mail]>; Wed, 18 Jun 2003 17:21:18 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 18 Jun 2003 17:21:18 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id RAA02956 for [e-mail]; Wed, 18 Jun 2003 17:21:17 +0200 (MET DST)
Date: Wed, 18 Jun 2003 17:21:17 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: poll for a meeting agenda  
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IErRrb085203 for <[e-mail]>; Wed, 18 Jun 2003 07:53:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5IErRLP085202 for ietf-pkix-bks; Wed, 18 Jun 2003 07:53:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IErPrb085197 for <[e-mail]>; Wed, 18 Jun 2003 07:53:26 -0700 (PDT) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA08342; Wed, 18 Jun 2003 16:53:20 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 18 Jun 2003 16:53:20 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id QAA02835; Wed, 18 Jun 2003 16:53:18 +0200 (MET DST)
Date: Wed, 18 Jun 2003 16:53:18 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a  specific flag in the TST to represent an official TST?)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IDOWrb078901 for <[e-mail]>; Wed, 18 Jun 2003 06:24:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5IDOWZg078900 for ietf-pkix-bks; Wed, 18 Jun 2003 06:24:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IDOUrb078894 for <[e-mail]>; Wed, 18 Jun 2003 06:24:30 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.12.153]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030618132424111006914re>; Wed, 18 Jun 2003 13:24:24 +0000
Message-ID: <002901c3359c$e771efc0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Margus Freudenthal" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <020001c334f8$db30ad40$020aff0a@tsg1> <[e-mail]> <00bb01c33531$d099b5f0$020aff0a@tsg1> <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks 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" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I8ZOrb056976 for <[e-mail]>; Wed, 18 Jun 2003 01:35:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5I8ZOWO056975 for ietf-pkix-bks; Wed, 18 Jun 2003 01:35:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I8ZLrb056969 for <[e-mail]>; Wed, 18 Jun 2003 01:35:22 -0700 (PDT) (envelope-from [e-mail])
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id h5I8ZrA27360; Wed, 18 Jun 2003 11:35:53 +0300
Message-ID: <[e-mail]>
Date: Wed, 18 Jun 2003 11:34:41 +0300
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a  specific flag in the TST to represent an official TST?)
References: <[e-mail]> <020001c334f8$db30ad40$020aff0a@tsg1> <[e-mail]> <00bb01c33531$d099b5f0$020aff0a@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-info: Headers changed by Barricade
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi.

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I3twrb022690 for <[e-mail]>; Tue, 17 Jun 2003 20:55:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5I3twR8022689 for ietf-pkix-bks; Tue, 17 Jun 2003 20:55:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ausyms50.ca.com ([155.35.248.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I3tvrb022684 for <[e-mail]>; Tue, 17 Jun 2003 20:55:57 -0700 (PDT) (envelope-from [e-mail])
Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Jun 2003 13:55:54 +1000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Thread-Index: AcM1Q3eY9lVUa8F9T1uhCmDCXm8hvgACf7hw
From: "Ramsay, Ron" <[e-mail]>
To: "todd glassey" <[e-mail]>, <[e-mail]>, "Stephen Kent" <[e-mail]>
X-OriginalArrivalTime: 18 Jun 2003 03:55:54.0544 (UTC) FILETIME=[84554300:01C3354D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5I3twrb022685
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So was yours!

-----Original Message-----
From: todd glassey [mailto:[e-mail]]
Sent: Wednesday, 18 June 2003 12:28
To: [e-mail]; 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" <[e-mail]>
To: "todd glassey" <[e-mail]>; <[e-mail]>;
"Paul Hoffman / IMC" <[e-mail]>
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





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I3dQrb022316 for <[e-mail]>; Tue, 17 Jun 2003 20:39:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5I3dQK5022315 for ietf-pkix-bks; Tue, 17 Jun 2003 20:39:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I3dPrb022310 for <[e-mail]>; Tue, 17 Jun 2003 20:39:25 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 26731409 for [e-mail]; Tue, 17 Jun 2003 22:39:27 -0500
Date: Tue, 17 Jun 2003 22:39:23 -0500 (CDT)
From: Eric Norman <[e-mail]>
To: PKIX list <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: MULTIPART/signed; BOUNDARY="-2140662931-1832476801-1055907567=:11026"; protocol="application/x-pkcs7-signature"; micalg=sha1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

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"

MIIHNQYJKoZIhvcNAQcCoIIHJjCCByICAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCBUswggKVMIIB/qADAgECAgICejANBgkqhkiG9w0BAQQFADCB
kTELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH
TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xIDAe
BgNVBAsTF0ludGVybmV0MiBEZW1vbnN0cmF0aW9uMRgwFgYDVQQDEw9IRVBL
SSBDbGllbnQgQ0EwHhcNMDIwODI0MTkwNjE5WhcNMDMwOTI5MTkwNjE5WjCB
vzELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH
TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xKzAp
BgNVBAsTIkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kxFDAS
BgNVBAMTC0VyaWMgTm9ybWFuMSUwIwYJKoZIhvcNAQkBFhZlam5vcm1hbkBk
b2l0Lndpc2MuZWR1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALReNRkixlpT
urV2ogd3BCWgxihjl0j6+a7EGnV+SCCBsqjWqKcVTCedD49lTbHLnmgejUd+
tfdiy5Dg+//ZpMUCAwEAAaMQMA4wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B
AQQFAAOBgQB/5AydG4TKKO6ZFiI9d/m03260pf4lBp81mlD3B9IQl0ofJ1gl
NtZlTZyC1N4x+c82eqMNBIBrcA/dcaoy0LyNWRrRtt+et+JkNXfrhLuwUWtQ
NR8Gq3i00C2th4DienwNbh9FoVo6gru6sC3i4TRxwKnDbKus6r2xvKlOQt3E
azCCAq4wggIXoAMCAQICAgG/MA0GCSqGSIb3DQEBBAUAMIGRMQswCQYDVQQG
EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw
HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50
ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD
QTAeFw0wMTA3MTcxODI0MzFaFw0yMzA2MTMxODI0MzFaMIGRMQswCQYDVQQG
EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw
HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50
ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA6xU1OJP0g+mU9srwrQLC
zWXAMlkv3DKb+lEugUQTTV8/bi+ZgcG3oan7ZcxpiN+k+3biz8vcxIbxCMcI
NZvi0u0mdDoLjaAtZtqvORMgbm3XkJhzgtGMmaxFLUBlhebSdd7YeV4/X4lJ
FAIE3hcaXWayirI+jwGkaD0UgELs3ysCAwEAAaMTMBEwDwYDVR0TAQH/BAUw
AwEB/zANBgkqhkiG9w0BAQQFAAOBgQCkRVbjdpKkibnoRNqoDGWxu1Bno4eS
pw0GlIwkveeyhURWvBA2neUzBuFlG2JinTx7/YtHYf19vwzN+GSEzv7cUl0l
p27Uc0iamMYxzCCkgSvwgOn87FrdNgVA6e1QYvjzu0XdvbVyBqr0zH5a0Cel
/kzV7l/+idyjGPeNHC1lqzGCAbIwggGuAgEBMIGYMIGRMQswCQYDVQQGEwJV
UzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAwHgYD
VQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50ZXJu
ZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBDQQIC
AnowCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0wMzA2MTgwMzM5MjdaMCMGCSqGSIb3DQEJBDEWBBSw
qOsPno1qYRUPSaYthBrIwsmN0jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3
DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN
BggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAARAP3oyDUcFvMcgOAkQ7i5m
0wjmkKUwHUYpMDtjSIN/wxPFdCXxjPviQKx9eUqrhetabYNn0jNI/gymnpbX
Au5VOQ==
---2140662931-1832476801-1055907567=:11026--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I3AArb021516 for <[e-mail]>; Tue, 17 Jun 2003 20:10:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5I3AAHL021515 for ietf-pkix-bks; Tue, 17 Jun 2003 20:10:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I3A8rb021510 for <[e-mail]>; Tue, 17 Jun 2003 20:10:08 -0700 (PDT) (envelope-from [e-mail])
Received: from cisco.com (pita.cisco.com [171.71.68.13]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5I3A3pa019568; Tue, 17 Jun 2003 20:10:04 -0700 (PDT)
Received: from lakew2k (sjc-vpn4-747.cisco.com [10.21.82.235]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id UAA29565; Tue, 17 Jun 2003 20:10:00 -0700 (PDT)
From: "George Lake" <[e-mail]>
To: "Miguel Rodriguez" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCEP newest spec
Date: Tue, 17 Jun 2003 20:10:00 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <000501c329d8$e49b3ec0$[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I2ULrb020356 for <[e-mail]>; Tue, 17 Jun 2003 19:30:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5I2UL1s020355 for ietf-pkix-bks; Tue, 17 Jun 2003 19:30:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I2UJrb020347; Tue, 17 Jun 2003 19:30:19 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.12.153]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030618023015113001c2rje>; Wed, 18 Jun 2003 02:30:16 +0000
Message-ID: <00e601c33541$87cc37c0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>, "Stephen Kent" <[e-mail]>
References: <012a01c332b3$6cd9e560$020aff0a@tsg1> <p05210614bb1286bfc2e0@[63.202.92.152]> <005e01c333ad$c48e8860$020aff0a@tsg1> <p05210605bb15643b322d@[128.89.89.5]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I 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" <[e-mail]>
To: "todd glassey" <[e-mail]>; <[e-mail]>;
"Paul Hoffman / IMC" <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I2QPrb020282 for <[e-mail]>; Tue, 17 Jun 2003 19:26:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5I2QPJa020281 for ietf-pkix-bks; Tue, 17 Jun 2003 19:26:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I2QNrb020275 for <[e-mail]>; Tue, 17 Jun 2003 19:26:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [12.159.173.182] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5I2QKD9013659; Tue, 17 Jun 2003 22:26:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210609bb157ce297f0@[12.159.173.182]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 17 Jun 2003 22:27:07 -0400
To: "Hallam-Baker, Phillip" <[e-mail]>, [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: SCEP newest spec
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I1Ilrb018320 for <[e-mail]>; Tue, 17 Jun 2003 18:18:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5I1IlPC018319 for ietf-pkix-bks; Tue, 17 Jun 2003 18:18:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I1Ijrb018311; Tue, 17 Jun 2003 18:18:45 -0700 (PDT) (envelope-from [e-mail])
Received: from [12.159.173.182] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5I1IYDH011234; Tue, 17 Jun 2003 21:18:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210605bb15643b322d@[128.89.89.5]>
In-Reply-To: <005e01c333ad$c48e8860$020aff0a@tsg1>
References: <012a01c332b3$6cd9e560$020aff0a@tsg1> <p05210614bb1286bfc2e0@[63.202.92.152]> <005e01c333ad$c48e8860$020aff0a@tsg1>
Date: Tue, 17 Jun 2003 20:44:32 -0400
To: "todd glassey" <[e-mail]>, <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I0bprb017489 for <[e-mail]>; Tue, 17 Jun 2003 17:37:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5I0bpJv017488 for ietf-pkix-bks; Tue, 17 Jun 2003 17:37:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I0bmrb017483 for <[e-mail]>; Tue, 17 Jun 2003 17:37:49 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (141.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.141]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030618003743112007e3v4e>; Wed, 18 Jun 2003 00:37:44 +0000
Message-ID: <00bb01c33531$d099b5f0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Margus Freudenthal" <[e-mail]>
Cc: "Tom Gindin" <[e-mail]>, "Cain, Patrick" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <020001c334f8$db30ad40$020aff0a@tsg1> <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The 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" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Tom Gindin" <[e-mail]>; "Cain, Patrick"
<[e-mail]>; <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HM3mrb012798 for <[e-mail]>; Tue, 17 Jun 2003 15:03:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5HM3lM8012797 for ietf-pkix-bks; Tue, 17 Jun 2003 15:03:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HM3krb012792 for <[e-mail]>; Tue, 17 Jun 2003 15:03:46 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5HM3h4Z011898; Tue, 17 Jun 2003 15:03:43 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h5HM3gs10186; Tue, 17 Jun 2003 18:03:42 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Jun 2003 18:01:41 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matt Cooper <[e-mail]>, [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
References: <00e601c3345e$7d84c810$[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4EC12D87596C44FBECB03C40"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

MIIH7QYJKoZIhvcNAQcCoIIH3jCCB9oCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcAwggKAMIIB6aADAgECAgMKB+8wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA1MjgyMTI5MjJaFw0wNDA1MjcyMTI5MjJa
MEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIjAgBgkqhkiG9w0BCQEWE3N0
ZXZlLmhhbm5hQHN1bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANof1lVV7qao
9dRjzsm6ur4Au3MV3NSZIFSRqVWOcpVs/IzxwM8YJGHkMs9hIxl112qSti+DrhGaoxNB9gNk
hK6fQ4LkjZtj2joylLxaV2pdimIzZ0o1p+aQQ1T3k2PJ4QC65wRJB3hgD3VEhFeWgrM6YOa2
RUSP+9pGXUN3G9SlAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1bi5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAnVJJECGU6OMpOee5E43ETFdohCEXc
aUUROH0CcT4+zuKJFouM/9QR6ThJs/CxL9Wf9C9EENuFqOxBa1bDXR13Y39E26q1U+aR+637
Spb8SCQrNitkaQeVy/QLRjJbWe4RCT0C+Q+wBEEZoamSvZ48/1E4TTLI48wudxv2QkF9eTCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd
MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt
YWlsIFJTQSAyMDAwLjguMzACAwoH7zAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDYxNzIyMDE0MVowIwYJKoZIhvcNAQkEMRYE
FPFGR3WddKN+P6mC19EAoRqHZIRQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAjiNls8rBMirs13hpisAwr6Y3+VBtuoBxiwAaS9f70Bm7E0dEtL+I
U4yMCtY2h6PVS5b7PbzqOfzkgBUmnVB39CniLyEpK/x2K1Zr/YR7CD7FUMW7THW/VJtDfzCF
aVmDggI/Lq7NLODadXBBJOyp+nrs624hreP0I7mIDtu95vw=
--------------ms4EC12D87596C44FBECB03C40--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HLB5rb010466 for <[e-mail]>; Tue, 17 Jun 2003 14:11:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5HLB5Bc010465 for ietf-pkix-bks; Tue, 17 Jun 2003 14:11:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HLB2rb010453 for <[e-mail]>; Tue, 17 Jun 2003 14:11:03 -0700 (PDT) (envelope-from [e-mail])
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id h5HLBWO20283; Wed, 18 Jun 2003 00:11:32 +0300
X-Authentication-Warning: kiku.itsise: margus owned process doing -bs
Date: Wed, 18 Jun 2003 00:08:13 +0300 (EEST)
From: Margus Freudenthal <[e-mail]>
X-X-Sender: [e-mail]
To: todd glassey <[e-mail]>
cc: Tom Gindin <[e-mail]>, "Cain, Patrick" <[e-mail]>, [e-mail]
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)
In-Reply-To: <020001c334f8$db30ad40$020aff0a@tsg1>
Message-ID: <[e-mail]>
References: <[e-mail]> <020001c334f8$db30ad40$020aff0a@tsg1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-info: Headers changed by Barricade
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HKXhrb009152 for <[e-mail]>; Tue, 17 Jun 2003 13:33:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5HKXgA0009150 for ietf-pkix-bks; Tue, 17 Jun 2003 13:33:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HKXfrb009142 for <[e-mail]>; Tue, 17 Jun 2003 13:33:41 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5HKXb4Z023146; Tue, 17 Jun 2003 13:33:37 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h5HKXbs00064; Tue, 17 Jun 2003 16:33:37 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Jun 2003 16:31:33 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matt Cooper <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
References: <00e601c3345e$7d84c810$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF3486CF1F706D9276DD478ED"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

MIIH7QYJKoZIhvcNAQcCoIIH3jCCB9oCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcAwggKAMIIB6aADAgECAgMKB+8wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA1MjgyMTI5MjJaFw0wNDA1MjcyMTI5MjJa
MEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIjAgBgkqhkiG9w0BCQEWE3N0
ZXZlLmhhbm5hQHN1bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANof1lVV7qao
9dRjzsm6ur4Au3MV3NSZIFSRqVWOcpVs/IzxwM8YJGHkMs9hIxl112qSti+DrhGaoxNB9gNk
hK6fQ4LkjZtj2joylLxaV2pdimIzZ0o1p+aQQ1T3k2PJ4QC65wRJB3hgD3VEhFeWgrM6YOa2
RUSP+9pGXUN3G9SlAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1bi5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAnVJJECGU6OMpOee5E43ETFdohCEXc
aUUROH0CcT4+zuKJFouM/9QR6ThJs/CxL9Wf9C9EENuFqOxBa1bDXR13Y39E26q1U+aR+637
Spb8SCQrNitkaQeVy/QLRjJbWe4RCT0C+Q+wBEEZoamSvZ48/1E4TTLI48wudxv2QkF9eTCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd
MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt
YWlsIFJTQSAyMDAwLjguMzACAwoH7zAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDYxNzIwMzEzM1owIwYJKoZIhvcNAQkEMRYE
FGzJsfsk3aog1aAtw5nlrGsbozw+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAaKuv+fs8bT3MPZY1thTiWWAzOIu83sRmG6V6hJMIOfbLUuY428m1
FFun/WRtWtnGP00FB+uG/bYem6dQ1kQ+0JVARfhH+JbtyhJilbnz94bFgm0ikb5aVsYlc9WQ
qvpP5CnHQSjN9Ch4DJz93S5Tz+wk5yLp7yZDfk1zZWLvXeM=
--------------msF3486CF1F706D9276DD478ED--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HIOprb002685 for <[e-mail]>; Tue, 17 Jun 2003 11:24:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5HIOpPH002684 for ietf-pkix-bks; Tue, 17 Jun 2003 11:24:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HIOnrb002679 for <[e-mail]>; Tue, 17 Jun 2003 11:24:50 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5HIOktd208650; Tue, 17 Jun 2003 14:24:46 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5HIOi3e026432; Tue, 17 Jun 2003 14:24:44 -0400
To: "todd glassey" <[e-mail]>
Cc: [e-mail], "Cain, Patrick" <[e-mail]>
MIME-Version: 1.0
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 17 Jun 2003 14:24:43 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPRs JHEG5JQ5CD, THTO5KLVS6, JHEG5HMLFK, JCHN5K5PG9|March 27, 2003) at 06/17/2003 14:24:44, Serialize complete at 06/17/2003 14:24:44
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        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" <[e-mail]>
06/17/2003 01:48 PM

 
        To:     Tom Gindin/Watson/IBM@IBMUS, "Cain, Patrick" <[e-mail]>
        cc:     <[e-mail]>
        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" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
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" <[e-mail]>
> Sent by: [e-mail]
> 06/15/2003 09:09 PM
>
>
>         To:     "Paul Hoffman / IMC" <[e-mail]>
>         cc:     <[e-mail]>
>         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" <[e-mail]>
> To: <[e-mail]>
> 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
>
>
>
>






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HHo7rb001592 for <[e-mail]>; Tue, 17 Jun 2003 10:50:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5HHo7nn001591 for ietf-pkix-bks; Tue, 17 Jun 2003 10:50:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HHo5rb001573 for <[e-mail]>; Tue, 17 Jun 2003 10:50:05 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (141.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.141]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030617174957112007ejq5e>; Tue, 17 Jun 2003 17:49:58 +0000
Message-ID: <020001c334f8$db30ad40$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Tom Gindin" <[e-mail]>, "Cain, Patrick" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom 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" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
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" <[e-mail]>
> Sent by: [e-mail]
> 06/15/2003 09:09 PM
>
>
>         To:     "Paul Hoffman / IMC" <[e-mail]>
>         cc:     <[e-mail]>
>         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" <[e-mail]>
> To: <[e-mail]>
> 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
>
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HE05rb087012 for <[e-mail]>; Tue, 17 Jun 2003 07:00:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5HE05qB087011 for ietf-pkix-bks; Tue, 17 Jun 2003 07:00:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HE02rb086983 for <[e-mail]>; Tue, 17 Jun 2003 07:00:03 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5HE00pS208962; Tue, 17 Jun 2003 10:00:00 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5HDxv3f036246; Tue, 17 Jun 2003 09:59:59 -0400
To: "todd glassey" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 17 Jun 2003 09:59:55 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPRs JHEG5JQ5CD, THTO5KLVS6, JHEG5HMLFK, JCHN5K5PG9|March 27, 2003) at 06/17/2003 09:59:59, Serialize complete at 06/17/2003 09:59:59
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        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" <[e-mail]>
Sent by: [e-mail]
06/15/2003 09:09 PM

 
        To:     "Paul Hoffman / IMC" <[e-mail]>
        cc:     <[e-mail]>
        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" <[e-mail]>
To: <[e-mail]>
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






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5H3KPrb032614 for <[e-mail]>; Mon, 16 Jun 2003 20:20:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5H3KPfD032612 for ietf-pkix-bks; Mon, 16 Jun 2003 20:20:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5H3KGrb032602 for <[e-mail]>; Mon, 16 Jun 2003 20:20:17 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h5H3JjHJ026268; Tue, 17 Jun 2003 15:19:45 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h5H3Jh918167; Tue, 17 Jun 2003 15:19:43 +1200
Date: Tue, 17 Jun 2003 15:19:43 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: rfc316: PKIStatus
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Al Arsenault" <[e-mail]> 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.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5H1firb030119 for <[e-mail]>; Mon, 16 Jun 2003 18:41:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5H1fiqe030118 for ietf-pkix-bks; Mon, 16 Jun 2003 18:41:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5H1fgrb030109; Mon, 16 Jun 2003 18:41:42 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (141.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.141]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003061701413111100690pde>; Tue, 17 Jun 2003 01:41:33 +0000
Message-ID: <006201c33471$9517ce60$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <00c601c33412$faa3f290$020aff0a@tsg1>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The 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" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>; <[e-mail]>;
<[e-mail]>
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" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>;
<[e-mail]>
> 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.
> >
> >
> >
> >
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GNOvrb027367 for <[e-mail]>; Mon, 16 Jun 2003 16:24:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5GNOvgG027366 for ietf-pkix-bks; Mon, 16 Jun 2003 16:24:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GNOprb027360 for <[e-mail]>; Mon, 16 Jun 2003 16:24:56 -0700 (PDT) (envelope-from [e-mail])
Received: from wmcooper (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.10.2/8.10.2) with ESMTP id h5GNOrU32345; Mon, 16 Jun 2003 19:24:53 -0400
From: "Matt Cooper" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC 3280: same certificate in a certification path
Date: Mon, 16 Jun 2003 19:24:48 -0400
Message-ID: <00e601c3345e$7d84c810$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5GNOurb027362
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Responses inline:

> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]] 
> Sent: Thursday, June 12, 2003 10:38 AM
> To: Matt Cooper
> Cc: [e-mail]
> 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 |
> >              +---+  +---+         +---+
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GEOZrb005045 for <[e-mail]>; Mon, 16 Jun 2003 07:24:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5GEOZTG005044 for ietf-pkix-bks; Mon, 16 Jun 2003 07:24:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GEOXrb005031; Mon, 16 Jun 2003 07:24:33 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (131.sanjose-11-12rs16rt.ca.dial-access.att.net[12.81.4.131]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <200306161424271110069kpfe>; Mon, 16 Jun 2003 14:24:28 +0000
Message-ID: <00c601c33412$faa3f290$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter - 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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
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.
>
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GCP8rb096029 for <[e-mail]>; Mon, 16 Jun 2003 05:25:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5GCP8ur096028 for ietf-pkix-bks; Mon, 16 Jun 2003 05:25:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GCP1rb096014 for <[e-mail]>; Mon, 16 Jun 2003 05:25:08 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id h5GCOhD8004313; Mon, 16 Jun 2003 08:24:44 -0400 (EDT)
Message-ID: <00e601c33402$255ac330$acf42180@arsenaultd2>
From: "Al Arsenault" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>, "Peter Sylvester" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: rfc316: PKIStatus
Date: Mon, 16 Jun 2003 08:23:51 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>; <[e-mail]>
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]
[e-mail]
>                                                   Tel.:   [phone]
094
> http://www.openca.org                            Fax:    +39   178  221
8225
> http://openca.sourceforge.net                    Mobile: [phone]
365
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G9obrb088236 for <[e-mail]>; Mon, 16 Jun 2003 02:50:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5G9obN8088235 for ietf-pkix-bks; Mon, 16 Jun 2003 02:50:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G9oZrb088228; Mon, 16 Jun 2003 02:50:36 -0700 (PDT) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA23138; Mon, 16 Jun 2003 11:50:28 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Mon, 16 Jun 2003 11:50:29 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id LAA20527; Mon, 16 Jun 2003 11:50:27 +0200 (MET DST)
Date: Mon, 16 Jun 2003 11:50:27 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G2KErb043064 for <[e-mail]>; Sun, 15 Jun 2003 19:20:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5G2KE7U043063 for ietf-pkix-bks; Sun, 15 Jun 2003 19:20:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G2KDrb043052; Sun, 15 Jun 2003 19:20:13 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (131.sanjose-11-12rs16rt.ca.dial-access.att.net[12.81.4.131]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030616021952112007f6q6e>; Mon, 16 Jun 2003 02:19:53 +0000
Message-ID: <005e01c333ad$c48e8860$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>
References: <012a01c332b3$6cd9e560$020aff0a@tsg1> <p05210614bb1286bfc2e0@[63.202.92.152]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G1FDrb041533 for <[e-mail]>; Sun, 15 Jun 2003 18:15:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5G1FD65041532 for ietf-pkix-bks; Sun, 15 Jun 2003 18:15:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G1FBrb041524; Sun, 15 Jun 2003 18:15:11 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (131.sanjose-11-12rs16rt.ca.dial-access.att.net[12.81.4.131]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <200306160115081110068ajne>; Mon, 16 Jun 2003 01:15:09 +0000
Message-ID: <003701c333a4$b9593430$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>
Cc: <[e-mail]>
References: <012a01c332b3$6cd9e560$020aff0a@tsg1> <p05210614bb1286bfc2e0@[63.202.92.152]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FKRPrb033728 for <[e-mail]>; Sun, 15 Jun 2003 13:27:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5FKRPV4033727 for ietf-pkix-bks; Sun, 15 Jun 2003 13:27:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FKRNrc033719 for <[e-mail]>; Sun, 15 Jun 2003 13:27:24 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210614bb1286bfc2e0@[63.202.92.152]>
In-Reply-To: <012a01c332b3$6cd9e560$020aff0a@tsg1>
References: <012a01c332b3$6cd9e560$020aff0a@tsg1>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Sun, 15 Jun 2003 13:26:44 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: gentlemen... can we set aside a specific flag in the TST to represent an official TST?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5EKSRrb053194 for <[e-mail]>; Sat, 14 Jun 2003 13:28:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5EKSRZE053193 for ietf-pkix-bks; Sat, 14 Jun 2003 13:28:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5EKSPrb053187 for <[e-mail]>; Sat, 14 Jun 2003 13:28:25 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (249.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.249]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <200306142028151110067frne>; Sat, 14 Jun 2003 20:28:15 +0000
Message-ID: <012a01c332b3$6cd9e560$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I 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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DB95rb040402 for <[e-mail]>; Fri, 13 Jun 2003 04:09:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5DB94wR040401 for ietf-pkix-bks; Fri, 13 Jun 2003 04:09:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-4.tiscali.it (mail-4.tiscali.it [195.130.225.150]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DB93rb040392 for <[e-mail]>; Fri, 13 Jun 2003 04:09:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.hackmasters.net (217.133.8.148) by mail-4.tiscali.it (6.7.016) id 3EE063B400457CD2; Fri, 13 Jun 2003 13:07:25 +0200
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id F3794F6F3; Fri, 13 Jun 2003 13:19:16 +0200 (CEST)
Received: by mail.hackmasters.net (Postfix, from userid 509) id 49D37F717; Fri, 13 Jun 2003 13:19:15 +0200 (CEST)
Received: from hackmasters.net (galadriel.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 6D2A1F6F3; Fri, 13 Jun 2003 13:19:14 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 13 Jun 2003 13:07:23 +0200
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: rfc316: PKIStatus
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010208070807000406000102"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------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]                [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC
By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j
aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u
ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG
A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR
TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh
IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl
VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm
l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K
S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB
MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo
14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi
MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF
bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg
ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0
dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg
UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v
cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku
dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku
dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt
by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0
L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu
ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD
VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w
DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex
Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr
RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S
NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL
oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI
mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB
FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm
aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls
aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n
ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs
BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT
AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG
aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4
/Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID
AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/
BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz
D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk
gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu
aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg
TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W
W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v
ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk
d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU
aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw
Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w
a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51
bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v
Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu
MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93
d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB
BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo
EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl
bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78
rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk
poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm
63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1
J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN
txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwNjEzMTEwNzIzWjAjBgkqhkiG9w0BCQQxFgQU5wdKDfqAU1TNY7JJ
LUYCNEuhiEMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB
kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe
VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk
aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ
AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV
BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN
AQEBBQAEgYBmHgkvRrPkoHvdKw52c8HSCKMsckFbL9LFQ86e+nj38LY01/0++fuwep64PeZ5
pasquw3yWwpD+Z8z8yrw8Fw/zbua8z7XWCby9N8AKev7yrVQI+GauY1nJVVHsi5Z7ASLV+He
Fu+Bj3KPdsY6pmkmBwfYUXhxD4vPJh6ygbi9IgAAAAAAAA==
--------------ms010208070807000406000102--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5D8rhrb028166 for <[e-mail]>; Fri, 13 Jun 2003 01:53:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5D8rhfr028165 for ietf-pkix-bks; Fri, 13 Jun 2003 01:53:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5D8rfrb028152 for <[e-mail]>; Fri, 13 Jun 2003 01:53:42 -0700 (PDT) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 94F7F122A56 for <[e-mail]>; Fri, 13 Jun 2003 09:53:40 +0100 (BST)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256D44.00365AEA ; Fri, 13 Jun 2003 09:53:42 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 13 Jun 2003 09:43:03 +0000
Subject: Re: Fw: PKI "not working"
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"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:     <[e-mail]>, "el-sign: electronic signatures - open     |
  |       discussion" <[e-mail]>                                     |
  |       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: <[e-mail]>
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
>
>
>






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CI7Frb073144 for <[e-mail]>; Thu, 12 Jun 2003 11:07:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CI7F3x073143 for ietf-pkix-bks; Thu, 12 Jun 2003 11:07:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CI7Erb073129 for <[e-mail]>; Thu, 12 Jun 2003 11:07:14 -0700 (PDT) (envelope-from [e-mail])
Subject: Re: Fw: PKI "not working"
To: "todd glassey" <[e-mail]>
Cc: "el-sign: electronic signatures - open discussion" <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 12 Jun 2003 12:07:44 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 06/12/2003 02:07:24 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail] 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: <[e-mail]>
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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CEesrb062500 for <[e-mail]>; Thu, 12 Jun 2003 07:40:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CEesDQ062499 for ietf-pkix-bks; Thu, 12 Jun 2003 07:40:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CEerrb062494 for <[e-mail]>; Thu, 12 Jun 2003 07:40:53 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5CEerep011163; Thu, 12 Jun 2003 08:40:53 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h5CEeqs25797; Thu, 12 Jun 2003 10:40:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 12 Jun 2003 10:38:04 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matt Cooper <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
References: <004301c33033$0757dd50$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CEWXrb062052 for <[e-mail]>; Thu, 12 Jun 2003 07:32:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CEWXmF062051 for ietf-pkix-bks; Thu, 12 Jun 2003 07:32:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CEWSrb062042 for <[e-mail]>; Thu, 12 Jun 2003 07:32:30 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (unknown[12.81.12.209]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <200306121432221110067ba5e>; Thu, 12 Jun 2003 14:32:22 +0000
Message-ID: <046d01c330ef$6ce50050$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "el-sign: electronic signatures - open discussion" <[e-mail]>
Subject: Fw: PKI "not working"
Date: Thu, 12 Jun 2003 07:28:26 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a 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: <[e-mail]>
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
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CEIIrb061526 for <[e-mail]>; Thu, 12 Jun 2003 07:18:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CEIIAx061525 for ietf-pkix-bks; Thu, 12 Jun 2003 07:18:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.telegraphspringslocal.com (va-purceville1a-238.chvlva.adelphia.net [68.71.230.238] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CEIErb061516 for <[e-mail]>; Thu, 12 Jun 2003 07:18:15 -0700 (PDT) (envelope-from [e-mail])
Received: from Quark ([]) by mail.telegraphspringslocal.com (Merak 5.8.6) with ESMTP id CNA37765 for <[e-mail]>; Thu, 12 Jun 2003 10:18:11 -0400
From: "Matt Cooper" <[e-mail]>
To: <[e-mail]>
Subject: RE: RFC 3280: same certificate in a certification path - message mangled
Date: Thu, 12 Jun 2003 10:18:11 -0400
Message-ID: <001101c330ed$74845d80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <004301c33033$0757dd50$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Matt Cooper
> Sent: Wednesday, June 11, 2003 12:04 PM
> To: 'Steve Hanna'
> Cc: [e-mail]
> 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:[e-mail]]
> > 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: [e-mail] 
> > > > [mailto:[e-mail]] On Behalf Of Matt Cooper
> > > > Sent: Friday, May 23, 2003 12:32 AM
> > > > To: [e-mail]; '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: [e-mail] 
> > > > > [mailto:[e-mail]] 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".
> > > > >
> > > > >
> > > >
> > > >
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5C7eLrb022183 for <[e-mail]>; Thu, 12 Jun 2003 00:40:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5C7eLuF022182 for ietf-pkix-bks; Thu, 12 Jun 2003 00:40:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5C7eJrb022169 for <[e-mail]>; Thu, 12 Jun 2003 00:40:20 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA05582; Thu, 12 Jun 2003 09:44:24 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA10386; Thu, 12 Jun 2003 09:39:57 +0200
Message-ID: <[e-mail]>
Date: Thu, 12 Jun 2003 09:40:15 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Last Call: Internet X.509 Public Key Infrastructure:         Logotypes in X.509 certificates to Proposed Standard
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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 
> [e-mail] or [e-mail] 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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BKwnrb087356 for <[e-mail]>; Wed, 11 Jun 2003 13:58:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BKwnrv087355 for ietf-pkix-bks; Wed, 11 Jun 2003 13:58:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BKwlrb087343 for <[e-mail]>; Wed, 11 Jun 2003 13:58:48 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 11 Jun 2003 22:56:07 +0200
Date: Wed, 11 Jun 2003 23:08:30 +0200 (CEST)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Acquire OID for CP?
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.1, Mew version 3.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Wed, 11 Jun 2003 12:02:38 -0700, Jana Nguyen <[e-mail]> 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: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BJ2hrb080721 for <[e-mail]>; Wed, 11 Jun 2003 12:02:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BJ2hKc080720 for ietf-pkix-bks; Wed, 11 Jun 2003 12:02:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sun529.nas.nasa.gov (sun529.nas.nasa.gov [129.99.33.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BJ2grb080713 for <[e-mail]>; Wed, 11 Jun 2003 12:02:42 -0700 (PDT) (envelope-from [e-mail])
Received: from nas.nasa.gov (localhost [127.0.0.1]) by sun529.nas.nasa.gov (8.11.7+Sun/8.11.7/NAS-6n) with ESMTP id h5BJ2cC19070 for <[e-mail]>; Wed, 11 Jun 2003 12:02:38 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 11 Jun 2003 12:02:38 -0700
From: Jana Nguyen <[e-mail]>
Organization: NAS - NASA Ames Research Center, Moffett Field, CA
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Acquire OID for CP?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

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

Thank you,
Jana



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BGBcrb072575 for <[e-mail]>; Wed, 11 Jun 2003 09:11:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BGBcGZ072573 for ietf-pkix-bks; Wed, 11 Jun 2003 09:11:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BGBarb072554 for <[e-mail]>; Wed, 11 Jun 2003 09:11:36 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V5BG08CX10450 for <[e-mail]>; Wed, 11 Jun 2003 12:08:12 -0400
Received: (qmail 24745 invoked by uid 64014); 11 Jun 2003 16:07:30 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.500123 secs); 11 Jun 2003 16:07:30 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 11 Jun 2003 16:07:29 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <LWS0YZJ5>; Wed, 11 Jun 2003 12:11:28 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: son-of-rfc3280 (grandson-of-rfc2459)
Date: Wed, 11 Jun 2003 12:11:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
Sent: Wednesday, June 11, 2003 9:55 AM
To: [e-mail]
Cc: [e-mail]
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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BG6Jrb071849 for <[e-mail]>; Wed, 11 Jun 2003 09:06:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BG6JTr071848 for ietf-pkix-bks; Wed, 11 Jun 2003 09:06:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BG6Irb071829 for <[e-mail]>; Wed, 11 Jun 2003 09:06:18 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (216.sanfrancisco-12rh15rt-ca.dial-access.att.net[12.81.118.216]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030611160612111006bosfe>; Wed, 11 Jun 2003 16:06:13 +0000
Message-ID: <03ac01c33033$3ded40d0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: son-of-rfc3280 (grandson-of-rfc2459)
Date: Wed, 11 Jun 2003 09:05:09 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Todd

----- Original Message ----- 
From: "Russ Housley" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BG3orb071456 for <[e-mail]>; Wed, 11 Jun 2003 09:03:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BG3obc071455 for ietf-pkix-bks; Wed, 11 Jun 2003 09:03:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.telegraphspringslocal.com (va-purceville1a-238.chvlva.adelphia.net [68.71.230.238] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BG3jrb071426 for <[e-mail]>; Wed, 11 Jun 2003 09:03:47 -0700 (PDT) (envelope-from [e-mail])
Received: from Quark ([]) by mail.telegraphspringslocal.com (Merak 5.8.6) with ESMTP id CNA37765; Wed, 11 Jun 2003 12:03:42 -0400
From: "Matt Cooper" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC 3280: same certificate in a certification path
Date: Wed, 11 Jun 2003 12:03:42 -0400
Message-ID: <004301c33033$0757dd50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5BG3nrb071449
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi 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:[e-mail]]
> 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: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Matt Cooper
> > > Sent: Friday, May 23, 2003 12:32 AM
> > > To: [e-mail]; '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: [e-mail]
> > > > [mailto:[e-mail]] 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".
> > > >
> > > >
> > >
> > >
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BFjNrb068616 for <[e-mail]>; Wed, 11 Jun 2003 08:45:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BFjNQO068615 for ietf-pkix-bks; Wed, 11 Jun 2003 08:45:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BFjLrb068596 for <[e-mail]>; Wed, 11 Jun 2003 08:45:21 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5BFjH4Z003901; Wed, 11 Jun 2003 08:45:17 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h5BFjGs04997; Wed, 11 Jun 2003 11:45:16 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 11 Jun 2003 11:43:01 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Terry Hayes <[e-mail]>
CC: [e-mail]
Subject: Re: Name Constraints Processing
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BFLOrb066380 for <[e-mail]>; Wed, 11 Jun 2003 08:21:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BFLOKM066379 for ietf-pkix-bks; Wed, 11 Jun 2003 08:21:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BFLMrb066374 for <[e-mail]>; Wed, 11 Jun 2003 08:21:22 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5BFLMep025395; Wed, 11 Jun 2003 09:21:22 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h5BFLMs01648; Wed, 11 Jun 2003 11:21:22 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 11 Jun 2003 11:19:06 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: son-of-rfc3280 (grandson-of-rfc2459)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BEMLrb063627 for <[e-mail]>; Wed, 11 Jun 2003 07:22:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BEMLgZ063626 for ietf-pkix-bks; Wed, 11 Jun 2003 07:22:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BEMJrb063619 for <[e-mail]>; Wed, 11 Jun 2003 07:22:20 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA21166; Wed, 11 Jun 2003 16:26:25 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA06740; Wed, 11 Jun 2003 16:21:57 +0200
Message-ID: <[e-mail]>
Date: Wed, 11 Jun 2003 16:22:18 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BDuJrb062281 for <[e-mail]>; Wed, 11 Jun 2003 06:56:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BDuJES062280 for ietf-pkix-bks; Wed, 11 Jun 2003 06:56:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h5BDtvrb062260 for <[e-mail]>; Wed, 11 Jun 2003 06:56:09 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 7874 invoked by uid 0); 11 Jun 2003 13:54:38 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.42.240) by woodstock.binhost.com with SMTP; 11 Jun 2003 13:54:38 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 11 Jun 2003 09:55:28 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: son-of-rfc3280 (grandson-of-rfc2459)
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BDb0rb060134 for <[e-mail]>; Wed, 11 Jun 2003 06:37:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BDb0DJ060133 for ietf-pkix-bks; Wed, 11 Jun 2003 06:37:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BDawrb060123 for <[e-mail]>; Wed, 11 Jun 2003 06:36:59 -0700 (PDT) (envelope-from [e-mail])
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h5BDaWbd018215; Wed, 11 Jun 2003 09:36:32 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 11 Jun 2003 09:36:06 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------010106060303010505050502"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------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="[e-mail]">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="[e-mail]">&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="[e-mail]"><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--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BDKfrb057427 for <[e-mail]>; Wed, 11 Jun 2003 06:20:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BDKfSh057426 for ietf-pkix-bks; Wed, 11 Jun 2003 06:20:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BDKdrb057397 for <[e-mail]>; Wed, 11 Jun 2003 06:20:40 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h5BDKX5t025991; Thu, 12 Jun 2003 01:20:33 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h5BDKXk11535; Thu, 12 Jun 2003 01:20:33 +1200
Date: Thu, 12 Jun 2003 01:20:33 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Possible deficiency in the current OCSP Standard (RFC 2560)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ryan M. Hurst" <[e-mail]> 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.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BAebrb048132 for <[e-mail]>; Wed, 11 Jun 2003 03:40:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5BAebkD048131 for ietf-pkix-bks; Wed, 11 Jun 2003 03:40:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BAeYrb048126 for <[e-mail]>; Wed, 11 Jun 2003 03:40:35 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA27380; Wed, 11 Jun 2003 12:44:39 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA05658; Wed, 11 Jun 2003 12:40:12 +0200
Message-ID: <[e-mail]>
Date: Wed, 11 Jun 2003 12:40:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5A9jbAF059072 for <[e-mail]>; Tue, 10 Jun 2003 02:45:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5A9jb3g059071 for ietf-pkix-bks; Tue, 10 Jun 2003 02:45:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5A9jYAF059064 for <[e-mail]>; Tue, 10 Jun 2003 02:45:35 -0700 (PDT) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA23808; Tue, 10 Jun 2003 11:45:18 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Tue, 10 Jun 2003 11:45:19 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id LAA27412; Tue, 10 Jun 2003 11:45:12 +0200 (MET DST)
Date: Tue, 10 Jun 2003 11:45:12 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: rfc316: PKIStatus
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59LuAAF005872 for <[e-mail]>; Mon, 9 Jun 2003 14:56:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59LuAqP005871 for ietf-pkix-bks; Mon, 9 Jun 2003 14:56:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59Lu8AF005866 for <[e-mail]>; Mon, 9 Jun 2003 14:56:08 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h59LuAep016404 for <[e-mail]>; Mon, 9 Jun 2003 15:56:10 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h59LuAQ05624; Mon, 9 Jun 2003 17:56:10 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 09 Jun 2003 17:53:31 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List <[e-mail]>
Subject: OASIS Survey on PKI Obstacles
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 [e-mail].

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.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59LfnAF005573 for <[e-mail]>; Mon, 9 Jun 2003 14:41:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59Lfnjw005572 for ietf-pkix-bks; Mon, 9 Jun 2003 14:41:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59LfmAF005567 for <[e-mail]>; Mon, 9 Jun 2003 14:41:48 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Mon, 9 Jun 2003 14:41:42 -0700
Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Jun 2003 14:41:41 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Jun 2003 14:41:41 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Jun 2003 14:41:41 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 9 Jun 2003 14:41:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Possible deficiency in the current OCSP Standard (RFC 2560)
Date: Mon, 9 Jun 2003 14:41:39 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Possible deficiency in the current OCSP Standard (RFC 2560)
Thread-Index: AcMuvTN2MEWZYITXRqqfKMItemgU5wAEL6Fw
From: "Ryan M. Hurst" <[e-mail]>
To: "Nabil Ghadiali" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 09 Jun 2003 21:41:40.0730 (UTC) FILETIME=[E98325A0:01C32ECF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h59LfmAF005568
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Nabil Ghadiali
Sent: Monday, June 09, 2003 10:14 AM
To: [e-mail]
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






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59HD9AF091835 for <[e-mail]>; Mon, 9 Jun 2003 10:13:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59HD96X091834 for ietf-pkix-bks; Mon, 9 Jun 2003 10:13:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mta5.wss.scd.yahoo.com (mta5.wss.scd.yahoo.com [66.218.85.36]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59HD8AF091828 for <[e-mail]>; Mon, 9 Jun 2003 10:13:08 -0700 (PDT) (envelope-from [e-mail])
Received: from anchor (65.88.185.3) by mta5.wss.scd.yahoo.com (7.0.016) (authenticated as [e-mail]) id 3EDCE85D0025609A for [e-mail]; Mon, 9 Jun 2003 10:13:04 -0700
From: "Nabil Ghadiali" <[e-mail]>
To: <[e-mail]>
Subject: Possible deficiency in the current OCSP Standard (RFC 2560)
Date: Mon, 9 Jun 2003 13:13:47 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h579CXAF079069 for <[e-mail]>; Sat, 7 Jun 2003 02:12:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h579CXRg079068 for ietf-pkix-bks; Sat, 7 Jun 2003 02:12:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-6.tiscali.it (mail-6.tiscali.it [195.130.225.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h579CUAF079032 for <[e-mail]>; Sat, 7 Jun 2003 02:12:31 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.hackmasters.net (217.133.8.148) by mail-6.tiscali.it (6.7.016) id 3EE06BC000083E18 for [e-mail]; Sat, 7 Jun 2003 11:12:13 +0200
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 121DAF544 for <[e-mail]>; Sat,  7 Jun 2003 11:21:18 +0200 (CEST)
Received: by mail.hackmasters.net (Postfix, from userid 509) id 59F7CF5BF; Sat,  7 Jun 2003 11:21:16 +0200 (CEST)
Received: from hackmasters.net (galadriel.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 9AAB8F544 for <[e-mail]>; Sat,  7 Jun 2003 11:21:15 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sat, 07 Jun 2003 11:12:10 +0200
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: rfc316: PKIStatus
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090407000604000905000404"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------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]                [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOZjCC
By8wggYXoAMCAQICASwwDQYJKoZIhvcNAQEEBQAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5j
aWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9u
ZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkG
A1UEBhMCSVQwHhcNMDIwNzI0MTUyNjI2WhcNMDMxMjMxMjM1OTU5WjCBqTEaMBgGA1UEAxMR
TWFzc2ltaWxpYW5vIFBhbGExNTAzBgNVBAsTLERpcGFydGltZW50byBkaSBJbmdlZ25lcmlh
IGRlbGwnSW5mb3JtYXppb25lMRcwFQYDVQQLEw5TZWRlIGRpIE1vZGVuYTEuMCwGA1UEChMl
VW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSesg80BGzryvQlplD0MJ2YWlSEUAZpiFmywpOm
l//lWMnhONmC/q0TrO7j9Bb195dNzCMuXFgvV49Sy1iyHAjDhpysFvm/xZbAS3j8prXNN23K
S3Oa7Zz2GrQpCHgupCPQL2cy+ARVwwFod2GOSCVoUACkndit964K/bfsGvyLAgMBAAGjggQB
MIID/TAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA/gw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6aSO5yTMPTf9OdcWo
14pKLqEHMDCBtwYDVR0jBIGvMIGsgBRFHaYA4ZfoyU2aaUnZYMiYf4lFA6GBkKSBjTCBijEi
MCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMeVW5pbW9yZSBF
bnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBkaSBNb2RlbmEg
ZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVIIBADBqBglghkgBhvhCAQ0EXRZbUHJvZ2V0
dG8gUG9zdGEgRWxldHRyb25pY2EgU2ljdXJhIA0KVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUg
UmVnZ2lvIEVtaWxpYSANCkMuSS5DLkEuSS5BLiANCjAiBgNVHREEGzAZgRdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDA0BgNVHRIELTArgRNwa2kuY2ljYWlhQHVuaW1vLml0hhRodHRwOi8v
cGtpLnVuaW1vLml0LzA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAKGI2h0dHA6Ly9wa2ku
dW5pbW8uaXQvY2EvaXNzdWVycy5odG1sMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9wa2ku
dW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQQEIxYhaHR0cDovL3BraS51bmlt
by5pdC9jcmwvY2FjcmwuY3JsMDAGCWCGSAGG+EIBAwQjFiFodHRwOi8vcGtpLnVuaW1vLml0
L2NybC9jYWNybC5jcmwwKgYJYIZIAYb4QgEHBB0WG2h0dHA6Ly9wa2kudW5pbW8uaXQvcmVu
ZXdhbDArBglghkgBhvhCAQgEHhYcaHR0cDovL3BraS51bmltby5pdC9jcHMvMS4xLzCB2QYD
VR0gBIHRMIHOMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYl
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBEBgorBgEEAegTAQEBMDYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly9tYWlsLnVuaW1vLml0L2Zpcm1hL2Nwc21vZGVuYS5odG0w
DQYJKoZIhvcNAQEEBQADggEBABn8ViNg4MPNRzEFFF4BsmRMP1YbUHbS+NmFvvys0D3xueex
Ie6HU+tkv9hz8++0MbLPnRY2qKpZXfWTbIOkrHLGVVHUkiZXFzfxsDMgcB4MWmSmhRVLfPqr
RZKAjIevO0JKIksq2xutAUqX5jkqZoGHpPv9JCiSI+cDRqOOW2Fh3JBGkcULKybrdwrSN6+S
NoTyTXR+ryeTBUXxu9rIbjrJdH3rKS7rz3ZkP2PKuFOb+Vbp829ALph1SJOLQrUnmJouLOSL
oVHW4zJK4zcAiNyMHua3HveLRkVINT9eDBeYBRPdn1k+LqdXqkXiEUPA+EIKeA23F5nQkqxI
mVVpaaYwggcvMIIGF6ADAgECAgEsMA0GCSqGSIb3DQEBBAUAMIGKMSIwIAYJKoZIhvcNAQkB
FhNwa2kuY2ljYWlhQHVuaW1vLml0MScwJQYDVQQDEx5Vbmltb3JlIEVudGUgZGkgQ2VydGlm
aWNhemlvbmUxLjAsBgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWls
aWExCzAJBgNVBAYTAklUMB4XDTAyMDcyNDE1MjYyNloXDTAzMTIzMTIzNTk1OVowgakxGjAY
BgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMTUwMwYDVQQLEyxEaXBhcnRpbWVudG8gZGkgSW5n
ZWduZXJpYSBkZWxsJ0luZm9ybWF6aW9uZTEXMBUGA1UECxMOU2VkZSBkaSBNb2RlbmExLjAs
BgNVBAoTJVVuaXZlcnNpdGEnIGRpIE1vZGVuYSBlIFJlZ2dpbyBFbWlsaWExCzAJBgNVBAYT
AklUMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUnrIPNARs68r0JaZQ9DCdmFpUhFAG
aYhZssKTppf/5VjJ4TjZgv6tE6zu4/QW9feXTcwjLlxYL1ePUstYshwIw4acrBb5v8WWwEt4
/Ka1zTdtyktzmu2c9hq0KQh4LqQj0C9nMvgEVcMBaHdhjkglaFAApJ3YrfeuCv237Br8iwID
AQABo4IEATCCA/0wDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/
BAQDAgP4MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+mkjuckz
D03/TnXFqNeKSi6hBzAwgbcGA1UdIwSBrzCBrIAURR2mAOGX6MlNmmlJ2WDImH+JRQOhgZCk
gY0wgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVu
aW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0YScgZGkg
TW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVSCAQAwagYJYIZIAYb4QgENBF0W
W1Byb2dldHRvIFBvc3RhIEVsZXR0cm9uaWNhIFNpY3VyYSANClVuaXZlcnNpdGEnIGRpIE1v
ZGVuYSBlIFJlZ2dpbyBFbWlsaWEgDQpDLkkuQy5BLkkuQS4gDQowIgYDVR0RBBswGYEXbWFk
d29sZkBoYWNrbWFzdGVycy5uZXQwNAYDVR0SBC0wK4ETcGtpLmNpY2FpYUB1bmltby5pdIYU
aHR0cDovL3BraS51bmltby5pdC8wPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzAChiNodHRw
Oi8vcGtpLnVuaW1vLml0L2NhL2lzc3VlcnMuaHRtbDAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vcGtpLnVuaW1vLml0L2NybC9jYWNybC5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0dHA6Ly9w
a2kudW5pbW8uaXQvY3JsL2NhY3JsLmNybDAwBglghkgBhvhCAQMEIxYhaHR0cDovL3BraS51
bmltby5pdC9jcmwvY2FjcmwuY3JsMCoGCWCGSAGG+EIBBwQdFhtodHRwOi8vcGtpLnVuaW1v
Lml0L3JlbmV3YWwwKwYJYIZIAYb4QgEIBB4WHGh0dHA6Ly9wa2kudW5pbW8uaXQvY3BzLzEu
MS8wgdkGA1UdIASB0TCBzjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93
d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYB
BQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRAYKKwYBBAHo
EwEBATA2MDQGCCsGAQUFBwIBFihodHRwOi8vbWFpbC51bmltby5pdC9maXJtYS9jcHNtb2Rl
bmEuaHRtMA0GCSqGSIb3DQEBBAUAA4IBAQAZ/FYjYODDzUcxBRReAbJkTD9WG1B20vjZhb78
rNA98bnnsSHuh1PrZL/Yc/PvtDGyz50WNqiqWV31k2yDpKxyxlVR1JImVxc38bAzIHAeDFpk
poUVS3z6q0WSgIyHrztCSiJLKtsbrQFKl+Y5KmaBh6T7/SQokiPnA0ajjlthYdyQRpHFCysm
63cK0jevkjaE8k10fq8nkwVF8bvayG46yXR96yku6892ZD9jyrhTm/lW6fNvQC6YdUiTi0K1
J5iaLizki6FR1uMySuM3AIjcjB7mtx73i0ZFSDU/XgwXmAUT3Z9ZPi6nV6pF4hFDwPhCCngN
txeZ0JKsSJlVaWmmMYIDNjCCAzICAQEwgZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNh
aWFAdW5pbW8uaXQxJzAlBgNVBAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEu
MCwGA1UEChMlVW5pdmVyc2l0YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UE
BhMCSVQCASwwCQYFKw4DAhoFAKCCAfswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwNjA3MDkxMjEwWjAjBgkqhkiG9w0BCQQxFgQUHL8GZ/NSsfogVwJc
kkjwSpEGUrowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGB
kzCBkDCBijEiMCAGCSqGSIb3DQEJARYTcGtpLmNpY2FpYUB1bmltby5pdDEnMCUGA1UEAxMe
VW5pbW9yZSBFbnRlIGRpIENlcnRpZmljYXppb25lMS4wLAYDVQQKEyVVbml2ZXJzaXRhJyBk
aSBNb2RlbmEgZSBSZWdnaW8gRW1pbGlhMQswCQYDVQQGEwJJVAIBLDCBowYLKoZIhvcNAQkQ
AgsxgZOggZAwgYoxIjAgBgkqhkiG9w0BCQEWE3BraS5jaWNhaWFAdW5pbW8uaXQxJzAlBgNV
BAMTHlVuaW1vcmUgRW50ZSBkaSBDZXJ0aWZpY2F6aW9uZTEuMCwGA1UEChMlVW5pdmVyc2l0
YScgZGkgTW9kZW5hIGUgUmVnZ2lvIEVtaWxpYTELMAkGA1UEBhMCSVQCASwwDQYJKoZIhvcN
AQEBBQAEgYA1RP1v53DsVSxC2BUaTKf3QuZVPYwWp5pldAs9sGq60FSE9vyxRIGakSMWu1e9
4/m70uZlNmfMZTu/CHwS1ip6a3ir4v24QI4Y2UUDVo856uVlvJbhsOYtmilx6WxM3jkfveAX
7ZLuMouv5HgDKVBJ6nlJo8JvpZVRWFZcV59xfgAAAAAAAA==
--------------ms090407000604000905000404--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56F99AF016077 for <[e-mail]>; Fri, 6 Jun 2003 08:09:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56F99UI016076 for ietf-pkix-bks; Fri, 6 Jun 2003 08:09:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56F98AF016068 for <[e-mail]>; Fri, 6 Jun 2003 08:09:08 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h56F99uv015385 for <[e-mail]>; Fri, 6 Jun 2003 08:09:09 -0700 (PDT)
Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <LMLG2JN3>; Fri, 6 Jun 2003 08:09:09 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: 
Cc: [e-mail]
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 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: Thursday, June 05, 2003 2:04 PM
> To: IETF-Announce; @mail.imc.org
> Cc: [e-mail]
> 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 
> [e-mail] or [e-mail] mailing lists by 2003-6-19.
> 
> Files can be obtained via 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-10.txt
> 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55I3bAF036537 for <[e-mail]>; Thu, 5 Jun 2003 11:03:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55I3bN4036536 for ietf-pkix-bks; Thu, 5 Jun 2003 11:03:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55I3aAF036531 for <[e-mail]>; Thu, 5 Jun 2003 11:03:36 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08586; Thu, 5 Jun 2003 14:03:36 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Internet X.509 Public Key Infrastructure:  Logotypes in X.509 certificates to Proposed Standard
Reply-to: [e-mail]
Date: Thu, 05 Jun 2003 14:03:36 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has 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 
[e-mail] or [e-mail] mailing lists by 2003-6-19.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-10.txt





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h553ubAF067933 for <[e-mail]>; Wed, 4 Jun 2003 20:56:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h553uaId067932 for ietf-pkix-bks; Wed, 4 Jun 2003 20:56:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h553uZAF067926 for <[e-mail]>; Wed, 4 Jun 2003 20:56:35 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (48.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.48]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030605035631113001b73be>; Thu, 5 Jun 2003 03:56:31 +0000
Message-ID: <02c101c32b16$728c2d50$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Notice of a new protocol concept.
Date: Wed, 4 Jun 2003 20:36:18 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: "'todd glassey'" <[e-mail]>; <[e-mail]>
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:[e-mail]]
> > Sent: Wednesday, June 04, 2003 6:04 PM
> > To: [e-mail]
> > 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
> >
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h550qiAF063316 for <[e-mail]>; Wed, 4 Jun 2003 17:52:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h550qhGE063315 for ietf-pkix-bks; Wed, 4 Jun 2003 17:52:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h550qgAF063310 for <[e-mail]>; Wed, 4 Jun 2003 17:52:42 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h550qjuv026481; Wed, 4 Jun 2003 17:52:45 -0700 (PDT)
Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <LMLG1NAL>; Wed, 4 Jun 2003 17:52:45 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'todd glassey'" <[e-mail]>, [e-mail]
Subject: RE: Notice of a new protocol concept.
Date: Wed, 4 Jun 2003 17:52:44 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: Wednesday, June 04, 2003 6:04 PM
> To: [e-mail]
> 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
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54M6iAF057447 for <[e-mail]>; Wed, 4 Jun 2003 15:09:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54M6hsX057446 for ietf-pkix-bks; Wed, 4 Jun 2003 15:06:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54M4CAF057276 for <[e-mail]>; Wed, 4 Jun 2003 15:06:42 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (48.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.48]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003060422040711100h4bp2e>; Wed, 4 Jun 2003 22:04:08 +0000
Message-ID: <027a01c32ae5$325a4540$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Subject: Notice of a new protocol concept.
Date: Wed, 4 Jun 2003 15:03:54 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am 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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54LWLAF056790 for <[e-mail]>; Wed, 4 Jun 2003 14:32:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54LWL2l056789 for ietf-pkix-bks; Wed, 4 Jun 2003 14:32:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54LWKAF056780 for <[e-mail]>; Wed, 4 Jun 2003 14:32:20 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h54LWG4Z007518; Wed, 4 Jun 2003 14:32:16 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h54LWFh08609; Wed, 4 Jun 2003 17:32:15 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Jun 2003 17:29:31 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matt Cooper <[e-mail]>
CC: PKIX List <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
References: <001c01c32141$3d7ae180$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Matt Cooper
> > Sent: Friday, May 23, 2003 12:32 AM
> > To: [e-mail]; '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: [e-mail]
> > > [mailto:[e-mail]] 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".
> > >
> > >
> >
> >


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54JQrAF052042 for <[e-mail]>; Wed, 4 Jun 2003 12:29:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54JQrXo052041 for ietf-pkix-bks; Wed, 4 Jun 2003 12:26:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54JOMAF051676 for <[e-mail]>; Wed, 4 Jun 2003 12:26:52 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 4 Jun 2003 12:24:17 -0700
Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Jun 2003 12:24:17 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Jun 2003 12:24:17 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Jun 2003 12:24:12 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 4 Jun 2003 12:24:12 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP Internal Error...
Date: Wed, 4 Jun 2003 12:24:09 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP Internal Error...
Thread-Index: AcMqkm8d2PQdlZ4ESD+BU741ZdPFKwAO5Pew
From: "Trevor Freeman" <[e-mail]>
To: "Faisal" <[e-mail]>, "Peter Sylvester <Peter.Sylvester" <[e-mail]>, "Frank Balluffi" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 04 Jun 2003 19:24:12.0683 (UTC) FILETIME=[E13A4DB0:01C32ACE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h54JQqAF052035
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi 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: [e-mail] [mailto:[e-mail]]
On Behalf Of Faisal
Sent: Wednesday, June 04, 2003 3:43 AM
To: Peter Sylvester <Peter.Sylvester; Frank Balluffi
Cc: [e-mail]; [e-mail]
Subject: Re: SCVP Internal Error...

Hi,

    I prefer additional status code value rather than modifying the
structure

Regards,
Faisal

----- Original Message -----
From: "Frank Balluffi" <[e-mail]>
To: "Peter Sylvester <Peter.Sylvester" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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:
[e-mail]
>                       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.
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54HVAAF045541 for <[e-mail]>; Wed, 4 Jun 2003 10:31:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54HVA7k045540 for ietf-pkix-bks; Wed, 4 Jun 2003 10:31:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54HV9AF045534 for <[e-mail]>; Wed, 4 Jun 2003 10:31:09 -0700 (PDT) (envelope-from [e-mail])
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h54HUqbd001302; Wed, 4 Jun 2003 13:30:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Jun 2003 13:30:37 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: [e-mail]
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54DRHAF030952 for <[e-mail]>; Wed, 4 Jun 2003 06:27:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54DRH4X030951 for ietf-pkix-bks; Wed, 4 Jun 2003 06:27:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54DRBAF030945 for <[e-mail]>; Wed, 4 Jun 2003 06:27:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id h54DbpL29966 for <[e-mail]>; Wed, 4 Jun 2003 15:37:51 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAAVnaOH6; Wed, 4 Jun 03 15:37:49 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h54DR4x14076 for <[e-mail]>; Wed, 4 Jun 2003 15:27:04 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 04 Jun 2003 15:27:04 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: CRL Issuer Name = Subject name from crl signer cert?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54AooAF022737 for <[e-mail]>; Wed, 4 Jun 2003 03:53:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54AooxH022735 for ietf-pkix-bks; Wed, 4 Jun 2003 03:50:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54Am4AF022261; Wed, 4 Jun 2003 03:50:35 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.193.109]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h54AhLG9002757; Wed, 4 Jun 2003 16:43:28 +0600 (PKST)
Message-ID: <003e01c32a86$28282650$1400a8c0@ascertiafm>
From: "Faisal" <[e-mail]>
To: "Peter Sylvester <Peter.Sylvester" <[e-mail]>, "Frank Balluffi" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: SCVP Internal Error...
Date: Wed, 4 Jun 2003 15:42:54 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0033_01C32AAF.F75370F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_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" <[e-mail]>
To: "Peter Sylvester <Peter.Sylvester" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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:       [e-mail]
>                       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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5TCCAzEw
ggIZoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMB4XDTAzMDMwNDA4MTI1N1oXDTEyMDczMDEw
NDIyOVowYDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAy
IENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnRehtg8oWu+jYIkNJVR1ueHs7k8fClUiqUsrjmhuaI6SGjw0eusF
FCCnDN2URjk+Un2OFHa3fn0lRFes/rIXvV0aB8pZGp8XJLO6u3pdfKJGnVeBtgBUr/YkXT/APo+z
pp6a52+VjOEA8tcsfkco+Ml4quvZRSQ6/5hvDlEnm08CAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUc/Pyi9HYduL1F1K9IjZs+KkJi3QwNQYI
KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhl3d3cuZ2xvYmFsdHJ1c3RmaW5kZXIuY29tMB8GA1Ud
IwQYMBaAFLFTcaAo/ecMU5odaxA87sgazV7OMA0GCSqGSIb3DQEBBQUAA4IBAQAWgwuPN1Kt4P+g
mBe25iHuepjjWcslDjZaC65ZxQuGjr/Aj7eKtBwpvw+01S4r9QIKQeT0DqlcFJlf3mDa6S25ZKxR
hUM74fxSYvfT1hAFd7NMZ2BYSj5bGHX5LWFQi1REDthiggjUt5QUGj+OVDfqBakynkiYMinw+NV0
gdRzMyhE3j3nWzeXrOXOmzea3o4bsLK2yCAJ6v+VjjTs+gBlCIE2aqSdctX2JOFJLQUyWlArBqZ9
CEdVW+iYS7PYRnOddXLiX3EC/7+MlbNMZSW234XzWQxrNqF8JzUXbYHm3jDMsprDdeC8RtiYAhQa
T/Ogeq21ndR7phpmrMQqYCSBMIIDajCCAlKgAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQswCQYD
VQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwHhcN
MDMwMzA0MDgwNjEyWhcNMTMwMzA0MDgwMTI3WjA7MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNj
ZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDR+NPebia/iGElNG3QI9TlQSWE+vwhh9N1p608htxwX3HG2PREDou8hP/r3pIkkJEs
flGxt3RVXK+Ut7IyKKB17rhlUSGmrqaRL2fAxyCsCbtak6uLqh7afDYesI1ozLn4sYMFeFWGCWKk
kNBzGfDvKebjXAz9yNxhFyLGbB+ZUkEsfjQA3GJ4Dza4FAbWUH/Q9jWpd8RU9Wx9Hi+QTfXOTaaW
Tn+QMRg9QWuP6pklSsGA65j9YWoBd+ONtSEUM0aX3p/iuecSqC/IjfSxa7hWCskQR+bzqg3xMJTa
R1JpCQds6Z1OqJX5R3UEh71FaxC2TTMgGhNDhwVuoxEgSPhlAgMBAAGjeTB3MA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSxU3GgKP3nDFOaHWsQPO7IGs1ezjA1Bggr
BgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20wDQYJKoZI
hvcNAQEFBQADggEBAKRrsf6/A8LzMqEFJcKl3pq41fPXH7gDLbayGYxvRJ15LRMwxy6A8A2SrY5r
V8u8PStKcMGKj/1R4q1zY/h2TH0eIHDNzIcXiAndZFNBIRPskQ1qIKIlTtO/TYC1f+qss9r7eKcw
Yk90WhdkdZ0k/r21Z7JQMtLGvgO+2Mc4LEb4f1Li/TdB3M0dBq0nRrDX5wiM3hoRbYkWn+0rNtHl
4fVqp5M0S9BeWud/jNIiPu2OSFCdiXDgYVYP56OfVYHuUQuTGfsRP8EI3uUE5RFqIPBj+Vx/Dwzt
/LnNR2CfKv6HPS5AstKZWr04k/RKserIBmJLuxohgfnUuLWJovLFPJkwggQ+MIIDp6ADAgECAgEF
MA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEmMCQGA1UE
CxMdQ2xhc3MgMiBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxFjAUBgNVBAMTDUFzY2VydGlhIENBIDIw
HhcNMDMwMzA1MDYyNDEwWhcNMDQwMzA1MDYwOTM0WjBPMQswCQYDVQQGEwJHQjERMA8GA1UEChMI
QXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRcwFQYDVQQDEw5GYWlzYWwgTWFxc29vZDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnsqY9Z9dFOdNIgrbdeM6AjpVsMferv2JSGKmLsj+
b0Yahb4NF4O7wu0f6PxQV3OehEJDc3QWWt1WwGvCgxQAcjTSeSjtZtc5pNcM5c2jByglHy3OXu+m
QuycMr7xCevqhgbxRKOAkpLSz4y/HXkvE4UnEqeZ02hofC57Q6LcVUECAwEAAaOCAhcwggITMA4G
A1UdDwEB/wQEAwID+DAMBgNVHRMBAf8EAjAAMIIBAwYDVR0gBIH7MIH4MIH1BgorBgEEAfxJAQIB
MIHmMIHjBggrBgEFBQcCAjCB1hqB01RoaXMgY2VydGlmaWNhdGUgaXMgZm9yIHRoZSBzb2xlIHVz
ZSBvZiBBc2NlcnRpYSwgYW5kIGl0cyBjdXN0b21lcnMuIEFzY2VydGlhIGFjY2VwdHMgbm8gbGlh
YmlsaXR5IGZvciBhbnkgY2xhaW0gZXhjZXB0IGFzIGV4cHJlc3NseSBwcm92aWRlZCBpbiBpdHMg
Q2VydGlmaWNhdGUgUG9saWN5LCB3aGljaCBpcyBhdmFpbGFibGUgZnJvbSBpbmZvQGFzY2VydGlh
LmNvbS4wHQYDVR0OBBYEFOtaj3aL8msQJzzETwoXrMw4lV3MME0GA1UdHwRGMEQwQqBAoD6GPGh0
dHA6Ly93d3cuYXNjZXJ0aWEuY29tL09ubGluZUNBL2NybHMvQXNjZXJ0aWFDQTIvY2xhc3MyLmNy
bDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20w
JgYDVR0RBB8wHYEbZmFpc2FsLm1hcXNvb2RAYXNjZXJ0aWEuY29tMB8GA1UdIwQYMBaAFHPz8ovR
2Hbi9RdSvSI2bPipCYt0MA0GCSqGSIb3DQEBBQUAA4GBAHVhWHsCvmtTG4Q7u8HC8ZpdWdwVHqZm
CYbxwUN+C8QzuMzrweaxE7wUE8U7TkSOBVUrJqV9FC4gfDO35VmFTbqhpugurVahb0xop0baD6LW
YoB12Fvz1BFEG3U+liNlD434TcPjFdKQYJVgwAT3cT/K9Nagp1tZJedmR3t2LinMMYIBijCCAYYC
AQEwZTBgMQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExJjAkBgNVBAsTHUNsYXNzIDIg
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1Bc2NlcnRpYSBDQSAyAgEFMAkGBSsOAwIa
BQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MDQxMDQy
NTRaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFEoKmju8
mKutknhwDkmNZjmoC1r0MA0GCSqGSIb3DQEBAQUABIGAJO5FM+Gqv5cNgYXbJ9Cu9Ia9UG9hTia6
LT2+DCxoqBEVpuHPaquUG3AcVBPQqPsZ5mX4D0VjeHGE1Fu8T2LVCnnErjvHJJpHEW/unptGGFTM
uowVqAySIqjGekZhjMRQ4of2CBedZRLzy027PrRPNNbcTUPSXuh1ypFzyV3OeIAAAAAAAAA=

------=_NextPart_000_0033_01C32AAF.F75370F0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h547XkAF099958 for <[e-mail]>; Wed, 4 Jun 2003 00:33:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h547XkNj099957 for ietf-pkix-bks; Wed, 4 Jun 2003 00:33:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h547XSAF099950 for <[e-mail]>; Wed, 4 Jun 2003 00:33:29 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.193.109]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h547TWG7020245 for <[e-mail]>; Wed, 4 Jun 2003 13:29:33 +0600 (PKST)
Message-ID: <00bc01c32a6b$0ce1d5a0$1400a8c0@ascertiafm>
From: "Faisal" <[e-mail]>
To: <[e-mail]>
Subject: CVResponse [ResponseStatus] may need to change
Date: Wed, 4 Jun 2003 12:29:32 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00B5_01C32A94.F3F2D510"; micalg=SHA1
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_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: [phone]
& Fax: [phone]
* Email: [e-mail]

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: [phone]=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: [phone]</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:[e-mail]">faisal.maqsood</A><A=20
style=3D"TEXT-DECORATION: none"=20
href=3D"mailto:[e-mail]">@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>

R0lGODlhWgA6APcAAP///yQhIjmJyWhqbGS+a8jKzAWAxKDTnqiqrejp63el2MHiv6vD5dve5/Hy
897v3haY/Hf4CBMAYPoSAGj6EgAAAAAAePgSAAACAAAw+hIA24D7dxhE+Xf/////QPoSAFCa/Hdn
mvx3CgIAAID6EgAAAAAAAAATAAC4FQAAAAAAuPgSAIgGEwBs+RIA24D7d9CY+Hd4ARMAeAETAOyc
/HeoBxMACLgVAAAAAIgABAQAfPoSAAAEBAADAAAAAAAAAAAAAAAw+RIAXVnhd8BoVgABN/l3GAAA
AAAAAAAAAAAAWPkSACQAAADTQ/l3SA0TAAAAEwAkAAAA4FQTADD5EgAAAgAA6PoSANuA+3cYRPl3
//////j6EgAWmPx3SA0TAAAAAAAAAAAAqHNIAKD5EgAAAAAAmJj4dwAAEwBQbhcAAAAAAHz5EgCI
BhMAMPoSANuA+3fQmPh3/////0D6EgDsnPx32AcTAFhuFwBsbhcAWG4XAAEAAADQmPh3AwAAAAAA
AAAAAAgCDQAAALgAugBw1hMA33f4d5DR/HfEd/h32GATALhgEwBsbhcAAAAAAAAAAAA4+hIA24D7
d4h4+Hf/////SPoSAAAAEwAHAAAAAG4XAFhuFwABAAAAAWATABDQ/Hew+RIAgPoSAID6EgDbgPt3
iK74d/////+Q+hIAsI3odwAAEwAAAAAAAQAAAG1c4XcAAAAAAQAAAADg/X+wTBcAAAAAAFhuFwAA
AAAAKAEAAFT6EgAAAAAAsP8SAP0T6nfIjeh3/////4iu+HfcTUMAWG4XAAAAEwAAAAAAIAAAAKC8
cs/FIsIBAHgAbyQAAAAAPLZwq9nAAQAAAAAZAwAAAAATAA0AAABsb2dv4FQTACABAAAZuUAA3gII
AN4CCAA0+xIA24D7d3iu+Hf/////RPsSAH9J6XcAABMACAAUABgBAABtXOF3AAAAAAAAAAAAAAAA
AAAAAMTARAA5VRMAXMQVAD1VEwAFdEgA/////+BUEwAuwUQAOVUTACH5BAAAAAAALAAAAABaADoA
AAj+AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDMuTNDAgcaPIAkyEGCgpAIGIVNeVFBSgMuS
KFXKfNiApMubLxXM3LmQJc6fBmLyHErwp1EDOokqdWC0qVKlDQw0xWngKdEEUqfetEpU60sBXId6
JSk0rEyvJROY3am1ZIO1M6NSLYnUI1yZPklKZfD27swCWff63dkgL9LBMhswYJmVpF3EH0fSpZr0
4IMFBxY8gOyQcdOglgmIHn1gM+eEeT+XFbhgtGvRC04fxIq2QEEHr3PLNphadcEDuV/H3j3QZtvK
AoO/PkC8+NjDA3ErJ91coPGp0AVKn06AeXUGjT/+9x0InLv35g5afkbOmjsB09/D34R50H11keq/
riZYfvn9goXRlZ0DBYw3UGuuDfefQQ0YCAACAQSA0AMPPLZgQxBK+BECA3Q4AAIIcRjAAA4KJOIA
thnkwAAjpqhihyAOVECEHboIQAEdqiVQAh5+iBCLEdJoUIZBMhhkhDYKBGSEMRLkQJADPEZkAAhI
GeF4DRwZoY4ELRlkklpSWZCXEY4ZJpcCHTkAQTMG2eSNET6WpZZrKsRindpt+WCZ0emZoYFIpjki
QRkeVKhBbVrIJp8J3UnQnGoduuOVewZgY6AACDmQpIQyumgAisroKaEejignpRziCcCTlt5YI0H+
TBaQoaqciqphQYnimuqoStJZkKYqBurAsL+GSSuvlR6Uq3ZT8kokkFHCemSSrCYpra+bIlurQMsK
OmKRZmroaKdHGlhtQjQioC4CNm4L562fPlYtgbwC2Wu0Too4aJ+tIoTpqgW56263CQS6rb0AjLtj
h73Cey6OJEobI7HkGooswQbXy+edj7VpG6fnZnipmAXva+LFKIM6UMkfayyuyQCU7BHIcVYKaL/A
JjtkyvJS2ubOVJ5oYboKC/ohkGimm+GbAvMs7dG8zqlmsUe+mXCYAWNdMaJOD0QmvDKSievUt6lp
7ZIoZg221yobxKKBDYh9kEfDhipQAwXYvSMcAiWuzG6oDiSAJq565z33sINfqPjijDfu+OMBAQA7

------=_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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5TCCAzEw
ggIZoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMB4XDTAzMDMwNDA4MTI1N1oXDTEyMDczMDEw
NDIyOVowYDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAy
IENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnRehtg8oWu+jYIkNJVR1ueHs7k8fClUiqUsrjmhuaI6SGjw0eusF
FCCnDN2URjk+Un2OFHa3fn0lRFes/rIXvV0aB8pZGp8XJLO6u3pdfKJGnVeBtgBUr/YkXT/APo+z
pp6a52+VjOEA8tcsfkco+Ml4quvZRSQ6/5hvDlEnm08CAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUc/Pyi9HYduL1F1K9IjZs+KkJi3QwNQYI
KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhl3d3cuZ2xvYmFsdHJ1c3RmaW5kZXIuY29tMB8GA1Ud
IwQYMBaAFLFTcaAo/ecMU5odaxA87sgazV7OMA0GCSqGSIb3DQEBBQUAA4IBAQAWgwuPN1Kt4P+g
mBe25iHuepjjWcslDjZaC65ZxQuGjr/Aj7eKtBwpvw+01S4r9QIKQeT0DqlcFJlf3mDa6S25ZKxR
hUM74fxSYvfT1hAFd7NMZ2BYSj5bGHX5LWFQi1REDthiggjUt5QUGj+OVDfqBakynkiYMinw+NV0
gdRzMyhE3j3nWzeXrOXOmzea3o4bsLK2yCAJ6v+VjjTs+gBlCIE2aqSdctX2JOFJLQUyWlArBqZ9
CEdVW+iYS7PYRnOddXLiX3EC/7+MlbNMZSW234XzWQxrNqF8JzUXbYHm3jDMsprDdeC8RtiYAhQa
T/Ogeq21ndR7phpmrMQqYCSBMIIDajCCAlKgAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQswCQYD
VQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwHhcN
MDMwMzA0MDgwNjEyWhcNMTMwMzA0MDgwMTI3WjA7MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNj
ZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDR+NPebia/iGElNG3QI9TlQSWE+vwhh9N1p608htxwX3HG2PREDou8hP/r3pIkkJEs
flGxt3RVXK+Ut7IyKKB17rhlUSGmrqaRL2fAxyCsCbtak6uLqh7afDYesI1ozLn4sYMFeFWGCWKk
kNBzGfDvKebjXAz9yNxhFyLGbB+ZUkEsfjQA3GJ4Dza4FAbWUH/Q9jWpd8RU9Wx9Hi+QTfXOTaaW
Tn+QMRg9QWuP6pklSsGA65j9YWoBd+ONtSEUM0aX3p/iuecSqC/IjfSxa7hWCskQR+bzqg3xMJTa
R1JpCQds6Z1OqJX5R3UEh71FaxC2TTMgGhNDhwVuoxEgSPhlAgMBAAGjeTB3MA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSxU3GgKP3nDFOaHWsQPO7IGs1ezjA1Bggr
BgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20wDQYJKoZI
hvcNAQEFBQADggEBAKRrsf6/A8LzMqEFJcKl3pq41fPXH7gDLbayGYxvRJ15LRMwxy6A8A2SrY5r
V8u8PStKcMGKj/1R4q1zY/h2TH0eIHDNzIcXiAndZFNBIRPskQ1qIKIlTtO/TYC1f+qss9r7eKcw
Yk90WhdkdZ0k/r21Z7JQMtLGvgO+2Mc4LEb4f1Li/TdB3M0dBq0nRrDX5wiM3hoRbYkWn+0rNtHl
4fVqp5M0S9BeWud/jNIiPu2OSFCdiXDgYVYP56OfVYHuUQuTGfsRP8EI3uUE5RFqIPBj+Vx/Dwzt
/LnNR2CfKv6HPS5AstKZWr04k/RKserIBmJLuxohgfnUuLWJovLFPJkwggQ+MIIDp6ADAgECAgEF
MA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEmMCQGA1UE
CxMdQ2xhc3MgMiBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxFjAUBgNVBAMTDUFzY2VydGlhIENBIDIw
HhcNMDMwMzA1MDYyNDEwWhcNMDQwMzA1MDYwOTM0WjBPMQswCQYDVQQGEwJHQjERMA8GA1UEChMI
QXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRcwFQYDVQQDEw5GYWlzYWwgTWFxc29vZDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnsqY9Z9dFOdNIgrbdeM6AjpVsMferv2JSGKmLsj+
b0Yahb4NF4O7wu0f6PxQV3OehEJDc3QWWt1WwGvCgxQAcjTSeSjtZtc5pNcM5c2jByglHy3OXu+m
QuycMr7xCevqhgbxRKOAkpLSz4y/HXkvE4UnEqeZ02hofC57Q6LcVUECAwEAAaOCAhcwggITMA4G
A1UdDwEB/wQEAwID+DAMBgNVHRMBAf8EAjAAMIIBAwYDVR0gBIH7MIH4MIH1BgorBgEEAfxJAQIB
MIHmMIHjBggrBgEFBQcCAjCB1hqB01RoaXMgY2VydGlmaWNhdGUgaXMgZm9yIHRoZSBzb2xlIHVz
ZSBvZiBBc2NlcnRpYSwgYW5kIGl0cyBjdXN0b21lcnMuIEFzY2VydGlhIGFjY2VwdHMgbm8gbGlh
YmlsaXR5IGZvciBhbnkgY2xhaW0gZXhjZXB0IGFzIGV4cHJlc3NseSBwcm92aWRlZCBpbiBpdHMg
Q2VydGlmaWNhdGUgUG9saWN5LCB3aGljaCBpcyBhdmFpbGFibGUgZnJvbSBpbmZvQGFzY2VydGlh
LmNvbS4wHQYDVR0OBBYEFOtaj3aL8msQJzzETwoXrMw4lV3MME0GA1UdHwRGMEQwQqBAoD6GPGh0
dHA6Ly93d3cuYXNjZXJ0aWEuY29tL09ubGluZUNBL2NybHMvQXNjZXJ0aWFDQTIvY2xhc3MyLmNy
bDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20w
JgYDVR0RBB8wHYEbZmFpc2FsLm1hcXNvb2RAYXNjZXJ0aWEuY29tMB8GA1UdIwQYMBaAFHPz8ovR
2Hbi9RdSvSI2bPipCYt0MA0GCSqGSIb3DQEBBQUAA4GBAHVhWHsCvmtTG4Q7u8HC8ZpdWdwVHqZm
CYbxwUN+C8QzuMzrweaxE7wUE8U7TkSOBVUrJqV9FC4gfDO35VmFTbqhpugurVahb0xop0baD6LW
YoB12Fvz1BFEG3U+liNlD434TcPjFdKQYJVgwAT3cT/K9Nagp1tZJedmR3t2LinMMYIBijCCAYYC
AQEwZTBgMQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExJjAkBgNVBAsTHUNsYXNzIDIg
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1Bc2NlcnRpYSBDQSAyAgEFMAkGBSsOAwIa
BQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MDQwNzI5
MzJaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFKgP5GUq
gJgrBDYQFiSv2sp/mi7hMA0GCSqGSIb3DQEBAQUABIGAI/rEvR8GENVsk6hXUW03FZN/55ZSBCFu
0VlgzuN2Pu16eBPTC3YGiyUHZ53w2YnQsK/nEKF7dQHT44AyJKI1f7G29oufUvMyEYsJNd4wu0IS
Up+FEA830+XjuI9ywfFjsMp7ct5q9hQZDBfPDYyp/H8gNW5bO7zfQXE3E8rnW/IAAAAAAAA=

------=_NextPart_000_00B5_01C32A94.F3F2D510--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5422GAF076492 for <[e-mail]>; Tue, 3 Jun 2003 19:04:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5422FgB076491 for ietf-pkix-bks; Tue, 3 Jun 2003 19:02:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h541xcAF076420 for <[e-mail]>; Tue, 3 Jun 2003 19:02:08 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h541xJ53022601; Tue, 3 Jun 2003 18:59:19 -0700 (PDT)
Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <LYL88NGS>; Tue, 3 Jun 2003 18:59:19 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: SCEP newest spec
Date: Tue, 3 Jun 2003 18:59:18 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: Tuesday, June 03, 2003 5:17 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: SCEP newest spec
> 
> 
> 
> At 3:00 AM +1200 6/4/03, Peter Gutmann wrote:
> >"Miguel Rodriguez" <[e-mail]> 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
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53LIxAF066901 for <[e-mail]>; Tue, 3 Jun 2003 14:21:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h53LIxeI066899 for ietf-pkix-bks; Tue, 3 Jun 2003 14:18:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53LGRAF066828 for <[e-mail]>; Tue, 3 Jun 2003 14:18:58 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h53LGDD9004068; Tue, 3 Jun 2003 17:16:23 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100305bb02c0225e9b@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 3 Jun 2003 17:17:15 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: SCEP newest spec
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:00 AM +1200 6/4/03, Peter Gutmann wrote:
>"Miguel Rodriguez" <[e-mail]> 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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53HFeAF055167 for <[e-mail]>; Tue, 3 Jun 2003 10:15:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h53HFeD3055166 for ietf-pkix-bks; Tue, 3 Jun 2003 10:15:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr5.us.db.com (imr5.us.db.com [160.83.65.196]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53HFcAF055157; Tue, 3 Jun 2003 10:15:39 -0700 (PDT) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr5.us.db.com  id h53HFKVq013133; Tue, 3 Jun 2003 13:15:35 -0400 (EDT)
Subject: Re: SCVP Internal Error...
To: "Peter Sylvester <Peter.Sylvester" <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Tue, 3 Jun 2003 13:15:30 -0400
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.9a |January 7, 2002) at 06/03/2003 01:15:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I 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:       [e-mail]                                                             
                      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.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53FY7AF049198 for <[e-mail]>; Tue, 3 Jun 2003 08:34:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h53FY7o3049196 for ietf-pkix-bks; Tue, 3 Jun 2003 08:34:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53FY3AF049169 for <[e-mail]>; Tue, 3 Jun 2003 08:34:05 -0700 (PDT) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA20597 for <[e-mail]>; Tue, 3 Jun 2003 17:33:59 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Tue, 3 Jun 2003 17:33:59 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id RAA01054 for [e-mail]; Tue, 3 Jun 2003 17:33:58 +0200 (MET DST)
Date: Tue, 3 Jun 2003 17:33:58 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: SCVP Internal Error...
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> I agree.  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
  }







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53F32AF046226 for <[e-mail]>; Tue, 3 Jun 2003 08:05:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h53F32FP046225 for ietf-pkix-bks; Tue, 3 Jun 2003 08:03:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53F0UAF046118 for <[e-mail]>; Tue, 3 Jun 2003 08:03:00 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h53F0PYb025590; Wed, 4 Jun 2003 03:00:25 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h53F0OJ25663; Wed, 4 Jun 2003 03:00:24 +1200
Date: Wed, 4 Jun 2003 03:00:24 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: SCEP newest spec
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Miguel Rodriguez" <[e-mail]> 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.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53EbNAF045403 for <[e-mail]>; Tue, 3 Jun 2003 07:39:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h53EbNZU045402 for ietf-pkix-bks; Tue, 3 Jun 2003 07:37:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53EYpAF045248 for <[e-mail]>; Tue, 3 Jun 2003 07:37:22 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Jun 2003 09:36:14 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: about RFC 3126
Date: Tue, 3 Jun 2003 09:36:09 -0500
Message-ID: <000d01c329dd$79b8a0c0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C329B3.90E298C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 03 Jun 2003 14:36:15.0046 (UTC) FILETIME=[7C8A5E60:01C329DD]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_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:filelist.xml@01C329B3.90940390">
<!--[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--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53EITAF043196 for <[e-mail]>; Tue, 3 Jun 2003 07:20:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h53EITl2043195 for ietf-pkix-bks; Tue, 3 Jun 2003 07:18:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h53EFvAF043133 for <[e-mail]>; Tue, 3 Jun 2003 07:18:27 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 9085 invoked by uid 0); 3 Jun 2003 14:14:52 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.34.245) by woodstock.binhost.com with SMTP; 3 Jun 2003 14:14:52 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 03 Jun 2003 09:47:34 -0400
To: "Wahaj" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: SCVP Internal Error...
In-Reply-To: <011f01c3290c$0cefe2e0$0600a8c0@IdentrusVA1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53E4aAF042601 for <[e-mail]>; Tue, 3 Jun 2003 07:07:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h53E4arT042600 for ietf-pkix-bks; Tue, 3 Jun 2003 07:04:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53E24AF042515 for <[e-mail]>; Tue, 3 Jun 2003 07:04:35 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Jun 2003 09:03:27 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: SCEP newest spec
Date: Tue, 3 Jun 2003 09:03:21 -0500
Message-ID: <000501c329d8$e49b3ec0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C329AE.FBC536C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 03 Jun 2003 14:03:27.0421 (UTC) FILETIME=[E7BE9ED0:01C329D8]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_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:[e-mail]7FA240">
<!--[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--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52DeVAF040914 for <[e-mail]>; Mon, 2 Jun 2003 06:40:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h52DeU7h040913 for ietf-pkix-bks; Mon, 2 Jun 2003 06:40:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52DeKAF040907 for <[e-mail]>; Mon, 2 Jun 2003 06:40:24 -0700 (PDT) (envelope-from [e-mail])
Received: from IdentrusVA1 ([203.81.198.106]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h52DaaG7007851 for <[e-mail]>; Mon, 2 Jun 2003 19:36:37 +0600 (PKST)
Message-ID: <011f01c3290c$0cefe2e0$0600a8c0@IdentrusVA1>
From: "Wahaj" <[e-mail]>
To: <[e-mail]>
Subject: SCVP Internal Error...
Date: Mon, 2 Jun 2003 18:37:01 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0119_01C32935.F4D2FF60"; protocol="application/x-pkcs7-signature"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK3TCCAzEw
ggIZoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMB4XDTAzMDMwNDA4MTI1N1oXDTEyMDczMDEw
NDIyOVowYDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAy
IENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnRehtg8oWu+jYIkNJVR1ueHs7k8fClUiqUsrjmhuaI6SGjw0eusF
FCCnDN2URjk+Un2OFHa3fn0lRFes/rIXvV0aB8pZGp8XJLO6u3pdfKJGnVeBtgBUr/YkXT/APo+z
pp6a52+VjOEA8tcsfkco+Ml4quvZRSQ6/5hvDlEnm08CAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUc/Pyi9HYduL1F1K9IjZs+KkJi3QwNQYI
KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhl3d3cuZ2xvYmFsdHJ1c3RmaW5kZXIuY29tMB8GA1Ud
IwQYMBaAFLFTcaAo/ecMU5odaxA87sgazV7OMA0GCSqGSIb3DQEBBQUAA4IBAQAWgwuPN1Kt4P+g
mBe25iHuepjjWcslDjZaC65ZxQuGjr/Aj7eKtBwpvw+01S4r9QIKQeT0DqlcFJlf3mDa6S25ZKxR
hUM74fxSYvfT1hAFd7NMZ2BYSj5bGHX5LWFQi1REDthiggjUt5QUGj+OVDfqBakynkiYMinw+NV0
gdRzMyhE3j3nWzeXrOXOmzea3o4bsLK2yCAJ6v+VjjTs+gBlCIE2aqSdctX2JOFJLQUyWlArBqZ9
CEdVW+iYS7PYRnOddXLiX3EC/7+MlbNMZSW234XzWQxrNqF8JzUXbYHm3jDMsprDdeC8RtiYAhQa
T/Ogeq21ndR7phpmrMQqYCSBMIIDajCCAlKgAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQswCQYD
VQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwHhcN
MDMwMzA0MDgwNjEyWhcNMTMwMzA0MDgwMTI3WjA7MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNj
ZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDR+NPebia/iGElNG3QI9TlQSWE+vwhh9N1p608htxwX3HG2PREDou8hP/r3pIkkJEs
flGxt3RVXK+Ut7IyKKB17rhlUSGmrqaRL2fAxyCsCbtak6uLqh7afDYesI1ozLn4sYMFeFWGCWKk
kNBzGfDvKebjXAz9yNxhFyLGbB+ZUkEsfjQA3GJ4Dza4FAbWUH/Q9jWpd8RU9Wx9Hi+QTfXOTaaW
Tn+QMRg9QWuP6pklSsGA65j9YWoBd+ONtSEUM0aX3p/iuecSqC/IjfSxa7hWCskQR+bzqg3xMJTa
R1JpCQds6Z1OqJX5R3UEh71FaxC2TTMgGhNDhwVuoxEgSPhlAgMBAAGjeTB3MA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSxU3GgKP3nDFOaHWsQPO7IGs1ezjA1Bggr
BgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20wDQYJKoZI
hvcNAQEFBQADggEBAKRrsf6/A8LzMqEFJcKl3pq41fPXH7gDLbayGYxvRJ15LRMwxy6A8A2SrY5r
V8u8PStKcMGKj/1R4q1zY/h2TH0eIHDNzIcXiAndZFNBIRPskQ1qIKIlTtO/TYC1f+qss9r7eKcw
Yk90WhdkdZ0k/r21Z7JQMtLGvgO+2Mc4LEb4f1Li/TdB3M0dBq0nRrDX5wiM3hoRbYkWn+0rNtHl
4fVqp5M0S9BeWud/jNIiPu2OSFCdiXDgYVYP56OfVYHuUQuTGfsRP8EI3uUE5RFqIPBj+Vx/Dwzt
/LnNR2CfKv6HPS5AstKZWr04k/RKserIBmJLuxohgfnUuLWJovLFPJkwggQ2MIIDn6ADAgECAgEG
MA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEmMCQGA1UE
CxMdQ2xhc3MgMiBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxFjAUBgNVBAMTDUFzY2VydGlhIENBIDIw
HhcNMDMwMzA1MDYyNjE4WhcNMDQwMzA1MDYwOTM0WjBLMQswCQYDVQQGEwJHQjERMA8GA1UEChMI
QXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYDVQQDEwpXYWhhaiBLaGFuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzoHFvOQce3P9dZDCpU5wwEANcxZHT+gmeTvuG4P/SsgXM
czLAPLe/0NLDxHw46Wl02V8uCimXyupFLbrg+jpzSFJdya7jV9I5ZVFttapkCtvoSJjlLa6CoHpz
BwQFoegmw8t5LYX5Kn+4S+Tk0uD0CdXU7PR7y/cXt3IcwtBQHwIDAQABo4ICEzCCAg8wDgYDVR0P
AQH/BAQDAgP4MAwGA1UdEwEB/wQCMAAwggEDBgNVHSAEgfswgfgwgfUGCisGAQQB/EkBAgEwgeYw
geMGCCsGAQUFBwICMIHWGoHTVGhpcyBjZXJ0aWZpY2F0ZSBpcyBmb3IgdGhlIHNvbGUgdXNlIG9m
IEFzY2VydGlhLCBhbmQgaXRzIGN1c3RvbWVycy4gQXNjZXJ0aWEgYWNjZXB0cyBubyBsaWFiaWxp
dHkgZm9yIGFueSBjbGFpbSBleGNlcHQgYXMgZXhwcmVzc2x5IHByb3ZpZGVkIGluIGl0cyBDZXJ0
aWZpY2F0ZSBQb2xpY3ksIHdoaWNoIGlzIGF2YWlsYWJsZSBmcm9tIGluZm9AYXNjZXJ0aWEuY29t
LjAdBgNVHQ4EFgQUkyOZfT2YC2dfQCQmwYgoCCj0LngwTQYDVR0fBEYwRDBCoECgPoY8aHR0cDov
L3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Jscy9Bc2NlcnRpYUNBMi9jbGFzczIuY3JsMDUG
CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTAiBgNV
HREEGzAZgRd3YWhhai5raGFuQGFzY2VydGlhLmNvbTAfBgNVHSMEGDAWgBRz8/KL0dh24vUXUr0i
Nmz4qQmLdDANBgkqhkiG9w0BAQUFAAOBgQBVuzxh2zNJTMqA40kC6AqtnIDrW3b5XSfmXqtCVj8P
3ecs9aoKXrUfH9nic76xOGaHs+cEklqUFPrhK1rOoBNmA54VltcDrrEpc37pQtFm64RYlGD5ClXf
BrWVz1HngqsA5kN2POp1JQWWS0VKhNxO0Ok1ZvzI907HGMGyAcU5+DGCAcgwggHEAgEBMGUwYDEL
MAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAyIENlcnRpZmlj
YXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMgIBBjAJBgUrDgMCGgUAoIG6MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDYwMjEzMzcwMVowIwYJ
KoZIhvcNAQkEMRYEFOz3v3hKDolqxTDt4GblOEgyOW64MFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABIGAhyfcUXivgAmrTxGk6smrPKjUmoqLweLOD+D0
dLWuWqx6/p3FqCEuLthPdTf4euKz3fX9L5Bj3k9VfVtIxFmcUe1GoiCNxRW0wVmUpPjE7Pu62BRt
zZmi2+fxU7GAaL4uk1zzgxcIxCDHnW3XTyP1/o5x+eAsArf/e2jD/VXp05YAAAAAAAA=

------=_NextPart_000_0119_01C32935.F4D2FF60--