Re: TSP interoperability testing (RFC 3161)

[[e-mail] (Peter Gutmann)]

Denis Pinkas <[e-mail]> writes:

>At the Yokohama meeting, during my presentation on RFC3161bis, I advertised
>that despite the existence of about 10 different implementations of RFC 3161,
>interoperability testing of TSP had not yet been done.

Actually Peter Sylvester has done a fair bit of this with his TSA and assorted
clients... in fact I think there's been quite a bit of informal testing, just
no big grand unified test.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71329G23160 for ietf-pkix-bks; Wed, 31 Jul 2002 20:02:09 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g71326w23156 for <[e-mail]>; Wed, 31 Jul 2002 20:02:07 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g7131Lq9012966; Thu, 1 Aug 2002 15:01:21 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA409714; Thu, 1 Aug 2002 15:01:17 +1200 (NZST) (sender [e-mail])
Date: Thu, 1 Aug 2002 15:01:17 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  TSP interoperability testing (RFC 3161)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>At the Yokohama meeting, during my presentation on RFC3161bis, I advertised
>that despite the existence of about 10 different implementations of RFC 3161,
>interoperability testing of TSP had not yet been done.

Actually Peter Sylvester has done a fair bit of this with his TSA and assorted
clients... in fact I think there's been quite a bit of informal testing, just
no big grand unified test.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6VH33e09838 for ietf-pkix-bks; Wed, 31 Jul 2002 10:03:03 -0700 (PDT)
Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VH32w09831 for <[e-mail]>; Wed, 31 Jul 2002 10:03:02 -0700 (PDT)
Received: from rse23.kings.cam.ac.uk ([131.111.251.35] helo=salford.ac.uk) by purple.csi.cam.ac.uk with esmtp (Exim 4.10) id 17ZwsH-0001IJ-00; Wed, 31 Jul 2002 18:03:01 +0100
Message-ID: <[e-mail]>
Date: Wed, 31 Jul 2002 18:04:47 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail], "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: LDAP ISSUE
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------03EC9918723EA1BA6238830B"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Tom Gindin wrote:
> 
>       One of the problems with keywords is the state of the registry.
> First, section 2.3 of RFC 2253 does permit new keywords (the table which
> appears there says "As an example, strings for a few of the attribute types
> frequently seen ...").  Second, the assignment table in IANA (
> http://www.iana.org/assignments/directory-system-names) is further behind
> than RFC 2253, because it's missing DC and UID.
>       I would like to ask a few questions.  First, is there any reason why
> the two attributes added to RFC 2253 after RFC 1779 should not be added to
> IANA's keyword registry? 

In my opinion none. The only reason they have not been is that LDAPBIS
had decided not to use the registry again and to keep the keywords as a
fixed short list (which is why the topic has been reopened again). Since
the LDAPBIS group had decided to close down the registry, I issued the
PKIX ID as an alternative way of publishing the DN strings. But the
registry is a better way, provided we have an agreed mechanism for
deciding who can add new entries to it.

> Second, should not any new registrations be made
> there? 

Yes, once the registry is functional again. (I think IANA may think it
is no longer being used)


> Third, if PKIX is going to suggest new entries for DN attributes,
> shouldn't we be also adding the RFC 2587 attributes, which are PKIX
> specific?  

Yes

>Last, and outside the scope of PKIX, why should not attributes
> defined in X.520, RFC 1274, and PKCS#9 have keywords added to this
> registry, as those in X.520 and RFC 1274 currently can be found at
> ldap.akbkhome.com?

Thanks for pointing me to this useful LDAP resource. I personnally see
no reason why all of the above should not have their friendly strings
usuable in RDNs instead of OIDs.


David

> 
>             Tom Gindin
> 
> David Chadwick <[e-mail]>@mail.imc.org on 07/23/2002
> 07:09:52 AM
> 
> Sent by:    [e-mail]
> 
> To:    [e-mail]
> cc:    "David P. Kemp" <[e-mail]>, [e-mail]
> Subject:    Re: LDAP ISSUE
> 
> Dave
> 
> the current LDAP model is that the server does the mapping, and that the
> client does not need to be bothered with the OIDs. Simple clients will
> not map between keywords and the user interface (the user will see the
> keywords). More sophisticated clients will do some presentation mapping
> e.g. serialNumber into Serial Number.
> 
> David
> 
> Steve Hanna wrote:
> >
> > Yes, this is a presentation issue. OIDs work fine on the wire
> > (in the LDAP protocol). Keywords are only important when
> > users need to understand the DN. I agree with your suggestion
> > completely. Use OIDs on the wire for maximum compatibility
> > and simplicity in implementation. Clients can translate these
> > to and from user-friendly keywords, if they want.
> >
> > -Steve
> >
> > >
> > >Steve,
> > >
> > >That sounds like a presentation issue, and perhaps that's what
> > >you meant to imply by emphasizing "on the wire".
> > >
> > >Would it not be reasonable for new DN attribute keywords to
> > >be registered with IANA, and permit newly developed clients
> > >to translate between keywords (for human consumption)
> > >and OIDs (on the wire)?
> > >
> > >Dave
> > >
> > >
> > >
> > >
> > >Steve Hanna wrote:
> > >>
> > >> Actually, there is a good reason for the position of the LDAP
> > >> group on this issue.
> > >>
> > >> The reason that new keywords for attribute types in X.500 DNs
> > >> cannot be sent on the wire in LDAP protocol messages is that
> > >> old LDAP servers won't know what the new keywords mean. For
> > >> user input and output, new keywords can be added. But you
> > >> can't expect existing LDAP servers to automagically understand
> > >> what a new keyword means when they see it on the wire. OIDs
> > >> are the best way to handle this.
> > >>
> > >> Also, this is not a new position. RFC 1779 (for LDAPv2)
> > >> allowed new keywords and defined an IANA registry. But no
> > >> new keywords were ever defined. I suspect that people
> > >> realized the problems that would ensue. RFC 2253 (for LDAPv3)
> > >> does not allow new keywords. And the revised version of 2253
> > >> (draft-ietf-ldapbis-dn-07.txt) also does not.
> > >>
> > >> Steve
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------03EC9918723EA1BA6238830B
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------03EC9918723EA1BA6238830B--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6VGrBx08915 for ietf-pkix-bks; Wed, 31 Jul 2002 09:53:11 -0700 (PDT)
Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VGr9w08894 for <[e-mail]>; Wed, 31 Jul 2002 09:53:09 -0700 (PDT)
Received: from rse23.kings.cam.ac.uk ([131.111.251.35] helo=salford.ac.uk) by purple.csi.cam.ac.uk with esmtp (Exim 4.10) id 17Zwig-0000ct-00; Wed, 31 Jul 2002 17:53:06 +0100
Message-ID: <[e-mail]>
Date: Wed, 31 Jul 2002 17:54:52 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ramsay, Ron" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: LDAP ISSUE
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------B2934F3CE3D6CC454E93CBE8"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



"Ramsay, Ron" wrote:
> 
> How can you display an unknown keyword?
> 
> The keyword comes out just fine, but the value? The assumption in LDAPv2 was
> that all values are encoded as printable (ASCII) strings, so your idea would
> work fine here. Now that we are in the modern world, though, some care must
> be taken with values. It would seem more appropriate to ignore unrecognised
> attributes, rather than displaying them.
> 

Ron

good point. But is it worse to throw something away or to display what
youve got to the user, in the offchance that it might be useful. I think
the latter is more preferrable. As a case in point, a well known Windows
LDAP client that retrieves information but times out before everything
is recieved, throws it all away and displays a time out error to the
user, whereas another competing LDAP client displays what its got as
well as the time out message.

David

> Ron.
> 
> -----Original Message-----
> From: David Chadwick [mailto:[e-mail]]
> Sent: Tuesday, 23 July 2002 21:08
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: LDAP ISSUE
> 
> Steve Hanna wrote:
> >
> > David Chadwick wrote:
> > >we have two cases here.
> >
> 
> Steve
> 
> sorry for the late reply, but I was travelling in Japan all the week
> after the IETF meeting.
> 
> > What about the case where a server returns a keyword to a
> > client that doesn't understand it?
> 
> This is exactly why LDAP invented the use of keywords. The argument is
> that clients who dont understand the new attribute type, if it is
> identified by an object identifiers then displaying these OIDs to the
> users is pointless. However, if an unknown attribute is identified by an
> unknown keyword e.g. Pseudonymn is returned to the client, it simply
> displays it to the human user as is, in anticipation that it will make
> sense to the user. Certainly the keyword will make more sense to the
> human than the OID. Thus your third case above is one that actually
> supports the use of keywords rather than OIDs.
> 
> >I agree that you can define
> > new keywords if all the software is updated or reconfigured
> > whenever a new keyword is defined. But this isn't realistic.
> >
> 
> Its just as realistic as reconfiguring the software when a new attribute
> OID is defined. The whole point of LDAP using keywords was that unknown
> keywords were easier for dumb clients to handle than unknown OIDs.
> 
> >
> > We agree that OIDs are the best solution for the on-the-wire
> > protocol.
> 
> Actually I just gave an example when they werent!. But if we had a clean
> sheet for defining the LDAP protocol I would never have suggested
> inventing keywords and would have stuck with OIDs to be compatible with
> X.500. But there are many folk who think that keywords in protocol are
> far preferrable all the time to OIDs, since it makes debugging much
> easier (e.g. would you prefer to see 1.2.986.2345.26.3.4.67 or ssNumber
> when it occurs in protocol).
> 
> >The best way forward seems clear to me. Don't define
> > new keywords to be used on the wire. Can you provide any reason
> > why it would be good to define more keywords?
> >
> 
> Yes I just have done above. Could you also answer my point that already
> more than 50 keywords exist, and servers know how to map these into
> attribute types (and OIDs) when they exist in requests for attributes,
> but not when they exist in DNs. Can  you explain why this situation is
> tenable?
> 
> > >But now PKIX has defined some new attributes for use
> > >in DNs, and therefore the keywords for these should also be supported.
> >
> > Following that logic, we'll have to add new keywords whenever
> > anyone comes up with another attribute. Each keyword will
> > introduce another potential compatibility issue. That sounds
> > pretty undesirable to me.
> >
> 
> No so, if the keyword is registered when the new attribute OID is
> registered, then both will appear at the same time.
> 
> David
> 
> > Thanks,
> >
> > Steve
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------B2934F3CE3D6CC454E93CBE8
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------B2934F3CE3D6CC454E93CBE8--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6VFEG403737 for ietf-pkix-bks; Wed, 31 Jul 2002 08:14:16 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VFEEw03733 for <[e-mail]>; Wed, 31 Jul 2002 08:14:14 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA19158; Wed, 31 Jul 2002 17:18:19 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002073117132284:910 ; Wed, 31 Jul 2002 17:13:22 +0200 
Message-ID: <[e-mail]>
Date: Wed, 31 Jul 2002 17:13:20 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: draft-ietf-pkix-warranty-ext-01
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 31/07/2002 17:13:23, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 31/07/2002 17:13:54, Serialize complete at 31/07/2002 17:13:54
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 g6VFEFw03734
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice,
 
> Hi folks,
> Several issues were raised at the IETF meeting on the proposed warranty
> extension I-D that may warrant some discussion on this list.
> 
> Issue # 1:  Should the warranty be an aspect of certification policy?  If
> so, policy qualifiers would indicate the amount of coverage.
> The reason for a warranty program is that a CA is not an insurance company
> and therefore cannot issue a policy of insurance in favor of the subscriber.

Whether or not the insurance is direct or subcontracted is not the main
point. The insurance is provided by the CA because the CA pays for it.

> The CA will take out a certificate insurance policy with a licensed
> insurance company.  Different certificates will have different certificate
> policies and therefore will have a different risk profile.  

Since the certificate policy describes ALL aspects of the policy, if two
certificates have the same CP then then have the same insurance and warranty
limits.

As RFC 3280 states: "Optional qualifiers, which MAY be present, are not
expected to change the definition of the policy".

> The insurance
> company will cover each certificate and type of certificate issued.  Hence
> the insurance company will sit behind the operations of the CA to cover the
> extended warranty program.  There will be a contractual relationship between
> the CA and  the subscriber, likely through the use of a Subscriber
> Agreement.  With respect to the relying party, the subscriber, if the
> subscriber opts for the extended warranty, has the opportunity to extend the
> financial trust relationship between them.  A relying party in encountering
> a certificate warranty program will know that an insurance company is
> covering the CA for any claims that fit within the warranty program.

"any claims that fit within the warranty program". This is not
understandable or machine processable. This is not visible in the warranty
amount but this is even more important than the amount. So it is very
questionable why the amount should be made visible and machine processable
whereas the conditions of the warranty are not. I am not saying that it
should be done visible as well, but this is more an argument to say that the
amount only is quite insufficient. 

So my conclusion would be: we could have a direct pointer to the terms and
conditions of the warranty. These terms and conditions can be subcontracted.
The single adantage is a direct pointer so that a human being can read the
terms and conditions and *not* to automate the processing of that
information. If some processing is needed, it has only to be done against
the OID of the CP.

The support of the warranty concept could be limited to a Certificate
Warranty qualifier. It could be defined as follows:

   The Certificate Warranty qualifier contains a direct pointer to a subpart 
   of the Certification Practice Statement (CPS) published by the CA.  The 
   pointer is in the form of a URI.  Processing requirements for this
   qualifier are a local matter.  

Thus, we do not need an extension for the warranty.

> Consequently certain warranties will be dealt with in the CP but it will not
> deal with the extended warranty.  For example, the amount of compensation
> available would likely not be covered as the same CP for different types of
> certificates (e.g., usages) could have different extended warranty amounts.
> It is up to the subscriber to select the program.

> Warranty may be an aspect of certification policy, just as liability and
> disclaimers of liability and/or warranty.  It is not necessary or
> appropriate to define a new policy qualifier (nor would it covered in the
> two policy qualifiers specified in RFC 3280 (s.4.2.1.5), the CPS URI pointer
> and User Notice), because it is defined in the proposed extension.  The
> warranty extension may include the amount of coverage, or it may point to a
> specific document in which coverage is specified.  That could be a narrowly
> focused Terms and Conditions, it could be Subscriber/Relying Party
> Agreements, or it could be a CP.  The revision of RFC 2527 covers issues of
> warranty, and allows the statement of warranty in the CP and/or in
> subscriber/relying party agreements.  Note: 'The degree to which a relying
> party can trust the binding embodied in a certificate depends on several
> factors. These factors include the practices followed by CA in
> authenticating the subject; the CA's operating policy, procedures, and
> security controls; the scope of the subscriber's obligations (for example,
> in protecting the private key); and the stated responsibilities and
> liability terms and conditions of the CA (for example, warranties,
> disclaimers of warranties, and limitations of liability).' [s.1.1]
> Note also: section 4.9.6:  Representations and Warranties - 'This
> subcomponent can include representations and warranties of various entities
> that are being made pursuant to the CP or CPS...'
> 
> Issue # 2:  There has been concern expressed that IETF standardization of
> this proposed certificate extension could lead to proposals to standardize
> on other extensions, possibly many extensions.  If proposals come forward,
> then they should be considered on a case-by-case basis.  We should not
> arbitrarily or gratuitously prohibit, or even discourage, proposals for
> standardization on any aspect of certificates and PKI in general.  Where one
> person does not see a need for standardization, another might; if the case
> for standardization is sufficient, then it should be allowed.  We saw a
> strong need for standardizing in the area of warranty, and so proposed this
> standard for an extension.

ETSI TS 101 862 defines in section  4.2.2 "Statement regarding limits on the
value of transactions" the following:

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

The limits on the value of transactions, for which the certificate can be
used, if applicable, may be indicated using the statement defined in this
clause. The codes are defined in ISO 4217 [9].

This optional statement contains:

· an identifier of this statement (represented by an OID);
· a monetary value expressing the limit on the value of transactions.

   esi4-qcStatement-2 QC-STATEMENT ::= { SYNTAX QcEuLimitValue IDENTIFIED
   BY id-etsi-qcs-QcLimitValue }

   --  This statement is a statement by the issuer which impose a
   --  limitation on the value of transaction for which this certificate
   --  can be used to the specified amount (MonetaryValue), according to 
   --  the Directive 1999/93/EC of the European Parliament and of the 
   --  Council of 13 December 1999 on a Community framework for
   --  electronic signatures, as implemented in the law of the country
   --  specified in the issuer field of this certificate.

   QcEuLimitValue ::= MonetaryValue

   MonetaryValue::= SEQUENCE {
       currency        Iso4217CurrencyCode,
       amount          INTEGER,
       exponent        INTEGER}
      -- value = amount * 10^exponent

	Iso4217CurrencyCode ::= CHOICE {
		alphabetic 	PrintableString (SIZE 3), -- Recommended
		numeric		INTEGER (1..999) }
		-- Alphabetic or numeric currency code as defined in ISO 4217
		-- It is recommended that the Alphabetic form is used

id-etsi-qcs-QcLimitValue      OBJECT IDENTIFIER ::= { id-etsi-qcs 2 }
 
=============================================================================

This extension does not say that a warranty exists under a given amount but
instead that no warranty applies above a given amount. This makes a *big*
difference.

> Issue # 3: ETSI tried to specify warranty information, and ETSI was never
> able to reach consensus.

 ??? Quite a strange statement. ETSI TS 101 862 has been endorsed by ETSI
members unanimously.

> While awaiting background on the discussions in ETSI, it is worthwhile
> noting that the ETSI standard that is being/has been discussed on this issue
> (ETSI 101 862 - Qualified Certificate Profile) says nothing about warranty,
> insurance, liability or disclaimers of such.  The only related aspect is the
> inclusion of an optional statement on the monetary limit for which a
> certificate may be used (pursuant to 1999/93/EC).  It has been noted that
> this optional statement is virtually the same as an explicit warranty
> disclaimer, but we would argue that it is insufficient to give adequate
> confidence to a relying party, by being implicit.

As indicated, the intent is to say: no waranty applies *above* that amount.
For the details of the waranty that *may* apply below that amount see the
details of the CP or CPS.
 
> Issue # 4: Would any CA be willing to make warranty cover the subscriber
> actions as well as the CA actions?  If so, the relying party would be better
> served.

Not sure I understand the issue here.

> Whether a CA would make a warranty that covers subscriber actions is outside
> the scope of this proposed I-D. This proposed extension covers a CA's
> warranty provision. It is, of course, possible that a CA would insure
> against subscriber folly, but it is considered unlikely.  Think about it:
> the only case in which a CA might be willing to cover the actions of its
> subscribers would be in a closed, high-assurance infrastructure; in that
> case, however, subscribers will also be the relying parties (and vice
> versa), so the matter is academic.  In an open infrastructure, even a
> high-assurance one with user hardware security modules (tokens), the CA
> cannot control all the actions of subscribers nor ensure that subscribers
> will do everything right (i.e., protect their private keys).  Other parts of
> the certificate, obviously, constrain the actions of all parties, in terms
> of certificate usage, applications, etc. etc.  The warranty extension need
> not address all concerns; that is not its purpose.  Its purpose is to give
> the relying party (a) confidence in the backing of the certificate (as well
> as confidence in the CA, in that the CA specifies in warranty coverage its
> own confidence in the system), and (b) an avenue for compensation in the
> event that the CA causes harm through failure to conform to its own
> specifications.

If this document is going to progress (in the direction of a policy
qualifier rather than an extension), it should be clearly indicated that the
warranty that is provided only covers errors committed by the CA when
issuing or revoking certificates, but by no means indicates the monetary
amount on some account related to the certificate subject. This is however
what relying parties are really interested in ! This insurance cannot be
provided by the CA but rather by party independent from the CA, e.g. a bank
or an insurance company. This warranty would need to be obtained on-line
using some protocol.
 
What is even more important is the format of the warranty rather than the
details of the protocol, so that relying parties can "understand" not only
the amount of the insurance but also all the terms and conditions that are
related to that amount. PKIX WG is likely not the right WG to define such a
protocol. 

Any idea about which IETF WG would be able to "host" such a work item ? 

Denis

> Alice Sturgeon
> Chair
> Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect
> SPYRUS
> Phone:     [phone]
> Cell:         613-291-0331


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6VF82k03466 for ietf-pkix-bks; Wed, 31 Jul 2002 08:08:02 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VF80w03461 for <[e-mail]>; Wed, 31 Jul 2002 08:08:01 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA28550 for <[e-mail]>; Wed, 31 Jul 2002 17:12:27 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002073117080073:909 ; Wed, 31 Jul 2002 17:08:00 +0200 
Message-ID: <[e-mail]>
Date: Wed, 31 Jul 2002 17:07:59 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: TSP interoperability testing (RFC 3161)
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 31/07/2002 17:08:00, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 31/07/2002 17:08:02, Serialize complete at 31/07/2002 17:08:02
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At the Yokohama meeting, during my presentation on RFC3161bis, I advertised
that despite the existence of about 10 different implementations of 
RFC 3161, interoperability testing of TSP had not yet been done.

This is needed to progress to Draft Standard. Of course, we all know that 
RFC 3280 also needs to be at Draft Standard level, but this is not an 
argument for just waiting for it. :-)

Tim Polk requested me to send the "matrix" to help people to know what to do
for the testing. I have prepared such a document in the March time frame and
already send it to the "TSP community". There may be some errors in that
document, so I do not claim it is perfect. This is just an help. Correct the
document as you wish.

I would be pleased to know which companies are willing to undertake the
effort to do the testing.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6UGkY501952 for ietf-pkix-bks; Tue, 30 Jul 2002 09:46:34 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UGkWw01948 for <[e-mail]>; Tue, 30 Jul 2002 09:46:33 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27692; Tue, 30 Jul 2002 12:45:23 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Delegated Path Validation and Delegated Path Discovery Protocol Requirements to Informational
Date: Tue, 30 Jul 2002 12:45:23 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved publication of 'Delegated Path Validation and
Delegated Path Discovery Protocol Requirements'
<draft-ietf-pkix-dpv-dpd-req-05.txt> as an Informational RFC.  This
document is the product of the Public-Key Infrastructure (X.509)
Working Group.  The IESG contact persons are Jeffrey Schiller and Steve
Bellovin.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6UG8KQ29290 for ietf-pkix-bks; Tue, 30 Jul 2002 09:08:20 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6UG8Iw29279 for <[e-mail]>; Tue, 30 Jul 2002 09:08:18 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Jul 2002 16:07:16 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA23891 for <[e-mail]>; Tue, 30 Jul 2002 12:08:19 -0400 (EDT)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6UG6Ah12836 for <[e-mail]>; Tue, 30 Jul 2002 12:06:10 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <NGM1D7G9>; Tue, 30 Jul 2002 09:08:16 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVBSTG; Tue, 30 Jul 2002 12:07:50 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 30 Jul 2002 11:45:52 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-09.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIX WG:

This is the same document that was made available via the RSA Labs FTP site 
prior to the meeting in Yokohama.  Since the repository is now accepting 
postings, I have simply posted the same document in the usual location.

Russ

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working 
>Group of the IETF.
>
>         Title           : Simple Certificate Validation Protocol (SCVP)
>         Author(s)       : A. Malpani, R. Housley, T. Freeman
>         Filename        : draft-ietf-pkix-scvp-09.txt
>         Pages           : 31
>         Date            : 29-Jul-02
>
>The SCVP protocol allows a client to offload certificate handling to a
>server. The server can give a variety of valuable information about
>the certificate, such as whether or not the certificate is valid, a
>certification path to a trust anchor, and so on. SCVP has many
>purposes, including simplifying client implementations and allowing
>companies to centralize their trust and policy management.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6UG81629269 for ietf-pkix-bks; Tue, 30 Jul 2002 09:08:01 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6UG7xw29262 for <[e-mail]>; Tue, 30 Jul 2002 09:07:59 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Jul 2002 16:06:57 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA23843 for <[e-mail]>; Tue, 30 Jul 2002 12:08:01 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6UG5q712790 for <[e-mail]>; Tue, 30 Jul 2002 12:05:52 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <P68R51TB>; Tue, 30 Jul 2002 17:11:11 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVBST2; Tue, 30 Jul 2002 12:07:52 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 30 Jul 2002 12:07:41 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RFC 3281 Omission
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear PKIX WG:

Jim Schaad discovered that an OID necessary for implementation of encrypted 
attributes as described in section 7.1 of RFC 3281 was not included in the 
document.  To fix this problem, I have assigned the missing OID.

The document says:

    The AC then contains the ciphertext inside its signed data.  The
    EnvelopedData (id-envelopedData) ContentType is used, and the content
    field will contain the EnvelopedData type.

It should also say:

    Within EnvelopedData, the encapuslatedContentInfo identifies the content
    type carried withing the ciphertext.  In this case, the contentType 
field of
    encapuslatedContentInfo MUST contain id-ct-attrCertEncAttrs, which
    has the following value:

       attrCertEncAttrs OBJECT IDENTIFIER ::=
             { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
               id-smime(16) id-ct(1) 14 }

Enjoy,
    Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6UG7wI29260 for ietf-pkix-bks; Tue, 30 Jul 2002 09:07:58 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6UG7uw29256 for <[e-mail]>; Tue, 30 Jul 2002 09:07:56 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Jul 2002 16:06:54 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA23839 for <[e-mail]>; Tue, 30 Jul 2002 12:07:57 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6UG5nu12786 for <[e-mail]>; Tue, 30 Jul 2002 12:05:49 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <P68R51TA>; Tue, 30 Jul 2002 17:11:08 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVBSTF; Tue, 30 Jul 2002 12:07:50 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 30 Jul 2002 11:41:02 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RFC 3280 has been translated to Japanese
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Seiji Kobayashi from Japan Certification Services, Inc. has published the 
Japanese document translated  from RFC 3280 at 
http://www2.jcsinc.co.jp/tutorial/doc/rfc3280-j.pdf.

Many thanks to Seiji.  PKI is getting much attention in Japan.  This 
translation should make the Internet certificate and CRL profile readily 
available to the Japanese audience.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6UBuOG17824 for ietf-pkix-bks; Tue, 30 Jul 2002 04:56:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UBuNw17819 for <[e-mail]>; Tue, 30 Jul 2002 04:56:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13475; Tue, 30 Jul 2002 07:55:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-wlan-extns-01.txt
Date: Tue, 30 Jul 2002 07:55:16 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Wireless LAN Certificate Extensions
	Author(s)	: R. Housley, T. Moore
	Filename	: draft-ietf-pkix-wlan-extns-01.txt
	Pages		: 7
	Date		: 29-Jul-02
	
This document defines two EAP extended key usage values and a
certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-wlan-extns-01.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-wlan-extns-01.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-wlan-extns-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6UBuJa17815 for ietf-pkix-bks; Tue, 30 Jul 2002 04:56:19 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UBuIw17809 for <[e-mail]>; Tue, 30 Jul 2002 04:56:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13457; Tue, 30 Jul 2002 07:55:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-09.txt
Date: Tue, 30 Jul 2002 07:55:11 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-09.txt
	Pages		: 31
	Date		: 29-Jul-02
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about
the certificate, such as whether or not the certificate is valid, a
certification path to a trust anchor, and so on. SCVP has many
purposes, including simplifying client implementations and allowing
companies to centralize their trust and policy management.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-09.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6UBpWM17175 for ietf-pkix-bks; Tue, 30 Jul 2002 04:51:32 -0700 (PDT)
Received: from ms01.dh02.ictu.nl ([193.173.47.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UBpUw17171 for <[e-mail]>; Tue, 30 Jul 2002 04:51:31 -0700 (PDT)
Received: from gw01.dh01.ictu.nl (unverified) by ms01.dh02.ictu.nl (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Tue, 30 Jul 2002 13:33:48 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: RE: OCSP follow up
Date: Tue, 30 Jul 2002 13:52:20 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP
Thread-Index: AcI2yoK3l98xYL1VR7aLcy0HrmZVWAA81f71
From: "Haaino Beljaars" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g6UBpVw17172
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi everybody,
 
I have a follow-up question about OCSP.
 
I send a seigned message to person A, person A checks the status of my certificate on time I by an OCSP responder, and the status of my certificate is 'good'. At time II, time after I, my certificate is revoked. Person A checks my message again at time III, time III is after time II. 
 
Question: what is the response of the OCSP responder at time III ? 
If the OCSP responder gives back 'revoked' at time III, isn't this incorrect? If the OCSP responder gives back 'good', this implies that the OCSP keeps some sort of a history?
If person A check your message against a CRL it would indicate at time III that the certificate was good at the moment of signing.
 
A general question in this all: why doens't the OCSP RFC have any angles with signed time? Or am I mistaken? Or have any 'history' possibilities? Keeping al this in mind, is it possible to only use OCSP and not CRL? Is it wise only to use OCSP and not CRL?
 
From: Ambarish Malpani:
 
>    There is nothing that says a responder must get all its
>information from a CRL.

>Other ways for a responder to get its information (for example) are:
>- direct access to a CA's database which could contain up-to-date
>        information about the status of all certificates
>- special notifications provided to the responder (e.g. by the RA/
>        other authorized parties) to give it up to date information
>        (while a CA might be down/unavailable).

>There is nothing in the spec that requires you to be able to verify
>the responses from a responder against a CRL. So there is no
>guarantee that you can verify a responder's responses in an
>independent way.

>> I'm just wondering where, according to the RCF, the OCSP
>> responder may get his information besides a CRL? May an OCSP
>> responder get his information from a list of
>> to-be-published-certificates-on-the-crl? If so, how can an
>> entity check the validity of an OCSP respondes if the source
>> of the OCSP responder is a system he/she cannot check?
>> Which ways are open to an OCSP responder to retrieve
>> information about certificates? May those 'ways' also contain
>> proprietary means?
>> Should a responds by an OCSP responder always be in such a
>> way that it can be validated without the use of an OCSP
>> responder, this implies that an OCSP responder can only use a
>> CRL as a basis of his response or any other public way?

Best regards,
Haaino


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6TJwXk14968 for ietf-pkix-bks; Mon, 29 Jul 2002 12:58:33 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6TJwVw14964 for <[e-mail]>; Mon, 29 Jul 2002 12:58:31 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 29 Jul 2002 19:57:31 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA22031 for <[e-mail]>; Mon, 29 Jul 2002 15:58:33 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6TJuPF18858 for <[e-mail]>; Mon, 29 Jul 2002 15:56:26 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVBHQX>; Mon, 29 Jul 2002 15:58:31 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.40]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVBHQV; Mon, 29 Jul 2002 15:58:28 -0400
From: "Housley, Russ" <[e-mail]>
To: Hiroyuki CHIBA <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 29 Jul 2002 15:58:25 -0400
Subject: Re: Wireless LAN Certificate Extensions
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hiroyuki:

Okay, so we agree that the SSID is the appropriate value.

I understand your desire to link the SSID to a certificate after it is 
issued.  This will complicate the application.  First, it would locate the 
AC that contains the desired SSID.  Next, the AC holder field is used to 
locate the PKC.

Russ


>Hi Russ,
>
> >>>>> On Mon, 29 Jul 2002 11:52:39 -0400,
>         "Housley, Russ" <[e-mail]> said
>         about: Re: Wireless LAN Certificate Extensions:
>
>rhousley> >rhousley> I propose that we stick with SSID as described in the 
>document.
>
>rhousley> >If this extension can be included in either PKC or AC, we can 
>select
>rhousley> >the alternative for a volatile SSID with reduced revocation 
>cost, I think.
>rhousley> >Any comments?
>
>rhousley> I only envision these extensions being included in PKCs.
>rhousley> What do you propose instead of the SSID?   Tim Moore (my 
>co-author) could
>rhousley> not find an appropriate value that was more stable than the SSID.
>
>I assume that SSIDs will be assigned by wireless-network service
>providers or corporate network administrators, and the assignment will
>NOT be depend on issuing PKC of the network client.
>In other words, a lifecycle of PKC should be different from each SSIDs' .
>
>My proposal is to allow including WLAN SSID EXT. into AC.
>
>Thanks,
>
>----
>Hiroyuki CHIBA: [e-mail] [e-mail]
>      Security Solution Promoting Division, Hitachi,Ltd.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6TJ2ot12783 for ietf-pkix-bks; Mon, 29 Jul 2002 12:02:50 -0700 (PDT)
Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TJ2nw12779 for <[e-mail]>; Mon, 29 Jul 2002 12:02:49 -0700 (PDT)
Received: from navsg3.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id EAA15337; Tue, 30 Jul 2002 04:02:51 +0900 (JST)
Received: from navsg3.hitachi.co.jp by navsg3.hitachi.co.jp (8.9.3/3.7W-navsg3) id EAA20478; Tue, 30 Jul 2002 04:02:51 +0900 (JST)
Received: from navgw3.itg.hitachi.co.jp ([158.213.165.14]) by navsg3.hitachi.co.jp (NAVGW 2.5.1.16) with SMTP id M2002073004025000490 for <[e-mail]>; Tue, 30 Jul 2002 04:02:50 +0900
Received: from bisdgw.bisd.hitachi.co.jp ([133.144.87.253]) by navgw3.itg.hitachi.co.jp (NAVGW 2.5.2.9) with SMTP id M2002073004025008393 ; Tue, 30 Jul 2002 04:02:50 +0900
Received: from bisdmlvg1.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with SMTP id EAA03642; Tue, 30 Jul 2002 04:02:50 +0900 (JST) (envelope-from [e-mail])
Received: by bisdmail.bisd.hitachi.co.jp (8.11.3/3.7W-bisdmail) id g6TJ2nL06561; Tue, 30 Jul 2002 04:02:49 +0900 (JST) (envelope-from hiro)
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: Wireless LAN Certificate Extensions
From: Hiroyuki CHIBA <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?=
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Tue, 30 Jul 2002 04:01:12 +0900 (JST)
X-Dispatcher: imput version 20000228(IM140)
Lines: 28
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Russ,

>>>>> On Mon, 29 Jul 2002 11:52:39 -0400,
	"Housley, Russ" <[e-mail]> said
	 about: Re: Wireless LAN Certificate Extensions:

rhousley> >rhousley> I propose that we stick with SSID as described in the document.

rhousley> >If this extension can be included in either PKC or AC, we can select
rhousley> >the alternative for a volatile SSID with reduced revocation cost, I think.
rhousley> >Any comments?

rhousley> I only envision these extensions being included in PKCs.
rhousley> What do you propose instead of the SSID?   Tim Moore (my co-author) could 
rhousley> not find an appropriate value that was more stable than the SSID.

I assume that SSIDs will be assigned by wireless-network service
providers or corporate network administrators, and the assignment will
NOT be depend on issuing PKC of the network client.
In other words, a lifecycle of PKC should be different from each SSIDs' .

My proposal is to allow including WLAN SSID EXT. into AC.

Thanks,

----
Hiroyuki CHIBA: [e-mail] [e-mail]
     Security Solution Promoting Division, Hitachi,Ltd.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6TFqpP27541 for ietf-pkix-bks; Mon, 29 Jul 2002 08:52:51 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6TFqmw27531 for <[e-mail]>; Mon, 29 Jul 2002 08:52:49 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 29 Jul 2002 15:51:48 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA26250 for <[e-mail]>; Mon, 29 Jul 2002 11:52:49 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6TFogo18688 for <[e-mail]>; Mon, 29 Jul 2002 11:50:42 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVBDGM>; Mon, 29 Jul 2002 11:52:47 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.40]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVBDG2; Mon, 29 Jul 2002 11:52:43 -0400
From: "Housley, Russ" <[e-mail]>
To: Hiroyuki CHIBA <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 29 Jul 2002 11:52:39 -0400
Subject: Re: Wireless LAN Certificate Extensions
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hiroyuki:

>rhousley> The question was: Can the SSID change?  And if so, is there a 
>more stable
>rhousley> alternative that we could include in the certificate instead.
>
>rhousley> Yes the SSID can change, but it does not change often.  For 
>example when
>rhousley> Mobilestar was bought, the SSID was changed to TMOBILE from 
>Mobilestar.
>rhousley> There isn't a good replacement. One that the authors considered 
>is the
>rhousley> network name of the RADIUS server/proxy (not the final RADIUS 
>server) which
>rhousley> would be mobilestar.com in the previous example.  However, this 
>name would
>rhousley> also change under then same circumstances that cause the SSID to 
>change.
>
>rhousley> I propose that we stick with SSID as described in the document.
>
>If this extension can be included in either PKC or AC, we can select
>the alternative for a volatile SSID with reduced revocation cost, I think.
>Any comments?

I only envision these extensions being included in PKCs.

What do you propose instead of the SSID?   Tim Moore (my co-author) could 
not find an appropriate value that was more stable than the SSID.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6TCAAq17489 for ietf-pkix-bks; Mon, 29 Jul 2002 05:10:10 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TCA9w17485 for <[e-mail]>; Mon, 29 Jul 2002 05:10:09 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25537; Mon, 29 Jul 2002 08:09:02 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-09.txt
Date: Mon, 29 Jul 2002 08:09:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure:Roadmap
	Author(s)	: A. Arsenault, S. Turner
	Filename	: draft-ietf-pkix-roadmap-09.txt
	Pages		: 55
	Date		: 26-Jul-02
	
This document provides an overview or 'roadmap' of the work done by 
the IETF PKIX working group. It describes some of the terminology 
used in the working group's documents, and the theory behind an 
X.509-based Public Key Infrastructure, Privilege Management 
Infrastructure (PMI), and Time Stamping and Data Certification 
Infrastructures. It identifies each document developed by the PKIX 
working group, and describes the relationships among the various 
documents. It also provides advice to would-be PKIX implementors 
about some of the issues discussed at length during PKIX development, 
in hopes of making it easier to build implementations that will 
actually interoperate.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-roadmap-09.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g6T5gcY04511 for ietf-pkix-bks; Sun, 28 Jul 2002 22:42:38 -0700 (PDT)
Received: from web21409.mail.yahoo.com (web21409.mail.yahoo.com [216.136.232.79]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6T5gbw04507 for <[e-mail]>; Sun, 28 Jul 2002 22:42:37 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [213.19.173.247] by web21409.mail.yahoo.com via HTTP; Sun, 28 Jul 2002 22:42:42 PDT
Date: Sun, 28 Jul 2002 22:42:42 -0700 (PDT)
From: asadi hamid <[e-mail]>
Subject: X.509 Analysis
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1181255889-1027921362=:54804"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0-1181255889-1027921362=:54804
Content-Type: text/plain; charset=us-ascii


Hi dear

     I searched for a document about X.509 analysis in INTERNET but i could not find any document.Are there any about this topic?

With best regard

Hamid Asadi

Master Student from Isfahan University of Technology(IUT)

 

 



---------------------------------
Do You Yahoo!?
Yahoo! Health - Feel better, live better
--0-1181255889-1027921362=:54804
Content-Type: text/html; charset=us-ascii

<P>Hi dear</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; I searched for a document about X.509 analysis in INTERNET but i could not find any document.Are there any about this topic?</P>
<P>With best regard</P>
<P>Hamid Asadi</P>
<P>Master Student from Isfahan University of Technology(IUT)</P>
<P>&nbsp;</P>
<P>&nbsp;</P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://health.yahoo.com/">Yahoo! Health</a> - Feel better, live better
--0-1181255889-1027921362=:54804--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6T4sme03861 for ietf-pkix-bks; Sun, 28 Jul 2002 21:54:48 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6T4smw03857 for <[e-mail]>; Sun, 28 Jul 2002 21:54:48 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Sun, 28 Jul 2002 21:46:29 -0700 (PDT)
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, 28 Jul 2002 21:46:29 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <MV9MKQN7>; Sun, 28 Jul 2002 21:54:17 -0700
Content-return: allowed
Date: Sun, 28 Jul 2002 21:54:16 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP
To: "'Haaino Beljaars'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="windows-1252"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Haaino,
    There is nothing that says a responder must get all its
information from a CRL.

Other ways for a responder to get its information (for example) are:
- direct access to a CA's database which could contain up-to-date
	information about the status of all certificates
- special notifications provided to the responder (e.g. by the RA/
	other authorized parties) to give it up to date information
	(while a CA might be down/unavailable).

There is nothing in the spec that requires you to be able to verify
the responses from a responder against a CRL. So there is no
guarantee that you can verify a responder's responses in an
independent way.

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Haaino Beljaars [mailto:[e-mail]]
> Sent: Sunday, July 28, 2002 11:39 AM
> To: [e-mail]
> Subject: OCSP
> 
> 
> 
> Hi,
> 
> I'm just wondering where, according to the RCF, the OCSP 
> responder may get his information besides a CRL? May an OCSP 
> responder get his information from a list of 
> to-be-published-certificates-on-the-crl? If so, how can an 
> entity check the validity of an OCSP respondes if the source 
> of the OCSP responder is a system he/she cannot check? 
> Which ways are open to an OCSP responder to retrieve 
> information about certificates? May those 'ways' also contain 
> proprietary means?
> Should a responds by an OCSP responder always be in such a 
> way that it can be validated without the use of an OCSP 
> responder, this implies that an OCSP responder can only use a 
> CRL as a basis of his response or any other public way?
> 
> Best regards,
> Haaino
> 


Received: by above.proper.com (8.11.6/8.11.3) id g6T3BPf02311 for ietf-pkix-bks; Sun, 28 Jul 2002 20:11:25 -0700 (PDT)
Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6T3BNw02306 for <[e-mail]>; Sun, 28 Jul 2002 20:11:23 -0700 (PDT)
Received: from navsg2.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id MAA16087; Mon, 29 Jul 2002 12:10:26 +0900 (JST)
Received: from navsg2.hitachi.co.jp by navsg2.hitachi.co.jp (8.9.3/3.7W-navsg2) id MAA09434; Mon, 29 Jul 2002 12:10:25 +0900 (JST)
Received: from navgw4.itg.hitachi.co.jp ([158.213.165.15]) by navsg2.hitachi.co.jp (NAVGW 2.5.1.16) with SMTP id M2002072912102527537 for <[e-mail]>; Mon, 29 Jul 2002 12:10:25 +0900
Received: from bisdgw.bisd.hitachi.co.jp ([133.144.87.253]) by navgw4.itg.hitachi.co.jp (NAVGW 2.5.2.9) with SMTP id M2002072912102521498 ; Mon, 29 Jul 2002 12:10:25 +0900
Received: from bisdmlvg1.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with SMTP id MAA12394; Mon, 29 Jul 2002 12:10:25 +0900 (JST) (envelope-from [e-mail])
Received: by bisdmail.bisd.hitachi.co.jp (8.11.3/3.7W-bisdmail) id g6T3AND46797; Mon, 29 Jul 2002 12:10:23 +0900 (JST) (envelope-from hiro)
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: Wireless LAN Certificate Extensions
From: Hiroyuki CHIBA <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?=
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Mon, 29 Jul 2002 12:08:39 +0900 (JST)
X-Dispatcher: imput version 20000228(IM140)
Lines: 31
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

>>>>> On Wed, 24 Jul 2002 17:40:33 -0400,
	"Housley, Russ" <[e-mail]> said
	 about: Wireless LAN Certificate Extensions:

rhousley> At the IETF meeting in Japan last week, I gave a presentation on 
rhousley> draft-ietf-pkix-wlan-extns-00.txt. I got one question that deserves 
rhousley> discussion on the list.

It's my question.

rhousley> The question was: Can the SSID change?  And if so, is there a more stable 
rhousley> alternative that we could include in the certificate instead.

rhousley> Yes the SSID can change, but it does not change often.  For example when 
rhousley> Mobilestar was bought, the SSID was changed to TMOBILE from Mobilestar. 
rhousley> There isn't a good replacement. One that the authors considered is the 
rhousley> network name of the RADIUS server/proxy (not the final RADIUS server) which 
rhousley> would be mobilestar.com in the previous example.  However, this name would 
rhousley> also change under then same circumstances that cause the SSID to change.

rhousley> I propose that we stick with SSID as described in the document.

If this extension can be included in either PKC or AC, we can select
the alternative for a volatile SSID with reduced revocation cost, I think.
Any comments?

----
Hiroyuki CHIBA: [e-mail] [e-mail]
     Security Solution Promoting Division, Hitachi,Ltd.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6T17DG00296 for ietf-pkix-bks; Sun, 28 Jul 2002 18:07:13 -0700 (PDT)
Received: from usermail.chinacomm.com.cn ([211.157.102.9]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6T17Bw00292 for <[e-mail]>; Sun, 28 Jul 2002 18:07:11 -0700 (PDT)
Message-Id: <[e-mail]>
Received: (qmail 12739 invoked from network); 29 Jul 2002 01:18:29 -0000
Received: from unknown (HELO ccit-carol) (61.48.8.77) by 0 with SMTP; 29 Jul 2002 01:18:29 -0000
Date: Mon, 29 Jul 2002 9:8:5 +0800
From: carol <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: draft-ietf-pkix-rfc2510bis-06.txt and draft-ietf-pkix-rfc2511bis-04.txt
X-mailer: FoxMail 4.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g6T17Cw00293
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

  According to the draft themselves, they have expired in June , 2002.

But I couldn't find any new version draft or RFC about rfc2510 and rfc2511.

What's the current status of draft-ietf-pkix-rfc2510bis-06.txt and draft-ietf-pkix-rfc2511bis-04.txt?


Best regards,

 				
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡carol
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡[e-mail]
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-07-29


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6SImcP15609 for ietf-pkix-bks; Sun, 28 Jul 2002 11:48:38 -0700 (PDT)
Received: from ms01.dh02.ictu.nl ([193.173.47.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SImRw15600 for <[e-mail]>; Sun, 28 Jul 2002 11:48:36 -0700 (PDT)
Received: from gw01.dh01.ictu.nl (unverified) by ms01.dh02.ictu.nl (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Sun, 28 Jul 2002 20:20:23 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Subject: OCSP 
Date: Sun, 28 Jul 2002 20:38:56 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP 
Thread-Index: AcI2Zge96aFw+xjpQBCRzMh8FCa/wg==
From: "Haaino Beljaars" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g6SImbw15605
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I'm just wondering where, according to the RCF, the OCSP responder may get his information besides a CRL? May an OCSP responder get his information from a list of to-be-published-certificates-on-the-crl? If so, how can an entity check the validity of an OCSP respondes if the source of the OCSP responder is a system he/she cannot check? 
Which ways are open to an OCSP responder to retrieve information about certificates? May those 'ways' also contain proprietary means?
Should a responds by an OCSP responder always be in such a way that it can be validated without the use of an OCSP responder, this implies that an OCSP responder can only use a CRL as a basis of his response or any other public way?

Best regards,
Haaino


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6QJx4F17292 for ietf-pkix-bks; Fri, 26 Jul 2002 12:59:04 -0700 (PDT)
Received: from e1.ny.us.ibm.com. (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QJx2w17285 for <[e-mail]>; Fri, 26 Jul 2002 12:59:02 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com. (8.12.2/8.12.2) with ESMTP id g6QJwRbW056116; Fri, 26 Jul 2002 15:58:28 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6QJwNNK139626; Fri, 26 Jul 2002 15:58:24 -0400
Importance: Normal
Sensitivity: 
Subject: Re: LDAP ISSUE
To: David Chadwick <[e-mail]>
Cc: [e-mail], "David P. Kemp" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 26 Jul 2002 15:58:28 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 07/26/2002 03:58:26 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      One of the problems with keywords is the state of the registry.
First, section 2.3 of RFC 2253 does permit new keywords (the table which
appears there says "As an example, strings for a few of the attribute types
frequently seen ...").  Second, the assignment table in IANA (
http://www.iana.org/assignments/directory-system-names) is further behind
than RFC 2253, because it's missing DC and UID.
      I would like to ask a few questions.  First, is there any reason why
the two attributes added to RFC 2253 after RFC 1779 should not be added to
IANA's keyword registry?  Second, should not any new registrations be made
there?  Third, if PKIX is going to suggest new entries for DN attributes,
shouldn't we be also adding the RFC 2587 attributes, which are PKIX
specific?  Last, and outside the scope of PKIX, why should not attributes
defined in X.520, RFC 1274, and PKCS#9 have keywords added to this
registry, as those in X.520 and RFC 1274 currently can be found at
ldap.akbkhome.com?

            Tom Gindin


David Chadwick <[e-mail]>@mail.imc.org on 07/23/2002
07:09:52 AM

Sent by:    [e-mail]


To:    [e-mail]
cc:    "David P. Kemp" <[e-mail]>, [e-mail]
Subject:    Re: LDAP ISSUE



Dave

the current LDAP model is that the server does the mapping, and that the
client does not need to be bothered with the OIDs. Simple clients will
not map between keywords and the user interface (the user will see the
keywords). More sophisticated clients will do some presentation mapping
e.g. serialNumber into Serial Number.

David


Steve Hanna wrote:
>
> Yes, this is a presentation issue. OIDs work fine on the wire
> (in the LDAP protocol). Keywords are only important when
> users need to understand the DN. I agree with your suggestion
> completely. Use OIDs on the wire for maximum compatibility
> and simplicity in implementation. Clients can translate these
> to and from user-friendly keywords, if they want.
>
> -Steve
>
> >
> >Steve,
> >
> >That sounds like a presentation issue, and perhaps that's what
> >you meant to imply by emphasizing "on the wire".
> >
> >Would it not be reasonable for new DN attribute keywords to
> >be registered with IANA, and permit newly developed clients
> >to translate between keywords (for human consumption)
> >and OIDs (on the wire)?
> >
> >Dave
> >
> >
> >
> >
> >Steve Hanna wrote:
> >>
> >> Actually, there is a good reason for the position of the LDAP
> >> group on this issue.
> >>
> >> The reason that new keywords for attribute types in X.500 DNs
> >> cannot be sent on the wire in LDAP protocol messages is that
> >> old LDAP servers won't know what the new keywords mean. For
> >> user input and output, new keywords can be added. But you
> >> can't expect existing LDAP servers to automagically understand
> >> what a new keyword means when they see it on the wire. OIDs
> >> are the best way to handle this.
> >>
> >> Also, this is not a new position. RFC 1779 (for LDAPv2)
> >> allowed new keywords and defined an IANA registry. But no
> >> new keywords were ever defined. I suspect that people
> >> realized the problems that would ensue. RFC 2253 (for LDAPv3)
> >> does not allow new keywords. And the revised version of 2253
> >> (draft-ietf-ldapbis-dn-07.txt) also does not.
> >>
> >> Steve

--
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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







Received: by above.proper.com (8.11.6/8.11.3) id g6PBBv823103 for ietf-pkix-bks; Thu, 25 Jul 2002 04:11:57 -0700 (PDT)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PBBqw23096 for <[e-mail]>; Thu, 25 Jul 2002 04:11:52 -0700 (PDT)
Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 25 Jul 2002 06:54:25 -0400
Message-ID: <[e-mail]>
Date: Thu, 25 Jul 2002 06:54:20 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rob G Weemhoff <[e-mail]>
CC: [e-mail]
Subject: Re: current edition of X.509 in the roadmap
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Rob,
<p>The reason is that PKIX profiles the 3rd edition and not the fourth
- hence the reference to the 3rd edition vice the 4th.
<p>spt
<p>Rob G Weemhoff wrote:
<blockquote TYPE=CITE>&nbsp;
<br><font face="sans-serif"><font size=-1>Why does the PKIX roadmap ignore
the current edition 4 of X.509 (03/2000) with the - changed - title: IT
- OSI - The Directory: Public-key and attribute certificate frameworks
(was Authentication framework)?</font></font>
<br>&nbsp;
<p><font face="sans-serif"><font size=-1>----</font></font>
<br><font face="sans-serif"><font size=-1>Regards,</font></font>
<br><font face="sans-serif"><font size=-1>Ing. Rob G. WEEMHOFF</font></font>
<br><font face="sans-serif"><font size=-1>Senior Consulting IT-Architect</font></font>
<br><font face="sans-serif"><font size=-1>IBM Smart Card Solutions</font></font>
<br><font face="sans-serif"><font size=-1>Tel:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[phone]&nbsp; 9102</font></font>
<br><font face="sans-serif"><font size=-1>Mobile: [phone]</font></font>
<p><font face="sans-serif"><font size=-1>E-mail: [e-mail]</font></font>
<br><font face="sans-serif"><font size=-1>Fax: [phone]</font></font>
<br><font face="sans-serif"><font size=-1>Computerweg 8</font></font>
<br><font face="sans-serif"><font size=-1>3821 AB&nbsp; Amersfoort</font></font>
<br><font face="sans-serif"><font size=-1>The Netherlands</font></font>
<p><font face="sans-serif"><font size=-1><A HREF="http://www.ibm.com/security">http://www.ibm.com/security</A></font></font>
<br><font face="sans-serif"><font size=-1>Instant Messaging: robgweemhoff</font></font></blockquote>
</html>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6PAp5221125 for ietf-pkix-bks; Thu, 25 Jul 2002 03:51:05 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PAp3w21120 for <[e-mail]>; Thu, 25 Jul 2002 03:51:03 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6PAove8044946; Thu, 25 Jul 2002 06:50:57 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6PAots4063896; Thu, 25 Jul 2002 06:50:55 -0400
Importance: Normal
Sensitivity: 
Subject: Re: interpretation of extended key usage
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 25 Jul 2002 06:50:50 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 07/25/2002 06:50:55 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      You're right, there is no key purpose for CMP.  My question is
whether this is a good thing or not, especially if an intermediate CA wants
to publish a certificate for CMP use.  How does a remote client recognize
such a certificate?  Remember, this issue applies to all CA's, not just
root ones.

            Tom Gindin

"Housley, Russ" <[e-mail]> on 07/24/2002 04:25:49 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail]
Subject:    Re: interpretation of extended key usage


Tom:

I am unaware of any extended key usage OIDs for CMP.

It is quite reasonable for a CA certificate to indicate that the key can be

used to validate OCSP or SCVP responses (if the CA handles these with the
same signing key).

I tend to think of a root CA as being primarily off-line.  This
architecture provides for physical protection of the root CA's signing
key.  I guess this bias spilled into my response.

Russ



At 03:16 PM 7/24/2002 -0400, Tom Gindin wrote:

>       Russ:
>
>       Would it be reasonable for a CA certificate to contain extended key
>usage values for CMP usage (or perhaps OCSP)?  It would be better practice
>for the CA to issue a certificate to its own DN with such values but no
>certificate signing ability, of course.  It is clear that the extended key
>usage extension in a CA certificate is not an analogue to name or policy
>constraints.
>
>             Tom Gindin
>
>
>"Housley, Russ" <[e-mail]>@mail.imc.org on 07/24/2002
>10:10:53 AM
>
>Sent by:    [e-mail]
>
>
>To:    "Heyden, Klaus" <[e-mail]>
>cc:    [e-mail]
>Subject:    Re: interpretation of  extended key usage
>
>
>
>I think that RFC 3280 is pretty clear.  It says:
>
>     If a certificate contains both a key usage extension and an extended
>     key usage extension, then both extensions MUST be processed
>     independently and the certificate MUST only be used for a purpose
>     consistent with both extensions.  If there is no purpose consistent
>     with both extensions, then the certificate MUST NOT be used for any
>     purpose.
>
>I would not expect a root certificate to contain an extended key usage
>extension.
>
>Russ
>
>
>At 01:12 PM 7/24/2002 +0200, Heyden, Klaus wrote:
>
> >Hello,
> >
> >i have a question about the meaning of extended key usage extensions in
a
> >certificate, specialy in a root certificate.
> >
> >How is the understanding of extended Key Usages in Root or CA
>certificates.
> >Specialy under the circumstance of certificate path validation. Therefor
i
> >think two opinions are possible:
> >
> >(1) the extended key usage is only usable for the use of the public key
> >itself and his direct usage i.e. signing of certificates etc. (view RFC
>2469
> >4.2.1.13 first sentence). So a root certificate dont need an extended
key
> >usage, because the public key will only be needed for path validation
and
> >signing of certificates and CRLs.
> >
> >(2) the public key is also needed for path validation, so an extended
key
> >usage can be used to restrict the use of sub and end entity
certificates.
> >
> >I have looked a bit around and found some CA certificates with extended
>key
> >usages, so its a bit confusing. Both way's are imagineable.
> >
> >Best Regards
> >Klaus Heyden
> >
> >
> >Dresdner Bank AG
> >D-60301 Frankfurt/Main
> >[e-mail]
> >[phone]
> >[phone]







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6PAWv619279 for ietf-pkix-bks; Thu, 25 Jul 2002 03:32:57 -0700 (PDT)
Received: from d06lmsgate-5.uk.ibm.com (d06lmsgate-5.uk.ibm.com [195.212.29.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PAWsw19274 for <[e-mail]>; Thu, 25 Jul 2002 03:32:55 -0700 (PDT)
Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-5.uk.ibm.com (1.0.0) with ESMTP id LAA98664 for <[e-mail]>; Thu, 25 Jul 2002 11:34:39 +0100
Received: from d15ml007.benelux.ibm.com (d15ml008.nl.ibm.com [9.132.41.68]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6PAWlH55480 for <[e-mail]>; Thu, 25 Jul 2002 11:32:47 +0100
To: <[e-mail]>
Subject: current edition of X.509 in the roadmap
MIME-Version: 1.0
Sensitivity: 
X-Mailer: Lotus Notes Build M13TT_06062002 Pre-release 2 June 06, 2002
From: "Rob G Weemhoff" <[e-mail]>
X-MIMETrack: S/MIME Sign by Notes Client on Rob G Weemhoff/Netherlands/IBM(Build M13TT_06062002 Pre-release 2|June 06, 2002) at 25-07-2002 12:32:17, Serialize by Notes Client on Rob G Weemhoff/Netherlands/IBM(Build M13TT_06062002 Pre-release 2|June 06, 2002) at 25-07-2002 12:32:17, Serialize complete at 25-07-2002 12:32:17, Itemize by Notes Client on Rob G Weemhoff/Netherlands/IBM(Build M13TT_06062002 Pre-release 2|June 06, 2002) at 25-07-2002 12:32:17, S/MIME Sign complete at 25-07-2002 12:32:17, S/MIME Sign by Notes Client on Rob G Weemhoff/Netherlands/IBM(Build M13TT_06062002 Pre-release 2|June 06, 2002) at 25-07-2002 12:32:19, S/MIME Sign complete at 25-07-2002 12:32:19, Serialize by Router on D15ML008/15/M/IBM(Release 5.0.9a |January 7, 2002) at 25/07/2002 12:32:47, Serialize complete at 25/07/2002 12:32:47
Message-ID: <[e-mail]>
Date: Thu, 25 Jul 2002 12:32:44 +0200
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z3173_boundary_sign
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is an S/MIME signed message.

---------z3173_boundary_sign
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Why does the PKIX roadmap ignore the current edition 4 of X.509 (03/2000) with the - changed - title: IT - OSI - The Directory: Public-key and attribute certificate frameworks (was Authentication framework)?<br>
<br>
<br>
----<br>
Regards,<br>
Ing. Rob G. WEEMHOFF &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
Senior Consulting IT-Architect &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
IBM Smart Card Solutions<br>
Tel: &nbsp; &nbsp; &nbsp; &nbsp;[phone] &nbsp;9102 &nbsp;<br>
Mobile: [phone]<br>
<br>
E-mail: [e-mail] &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
Fax: [phone]<br>
Computerweg 8<br>
3821 AB &nbsp;Amersfoort<br>
The Netherlands<br>
<br>
http://www.ibm.com/security<br>
Instant Messaging: robgweemhoff<br>
</font>

---------z3173_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIIUDgIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISTDCCAsYw
ggIvoAMCAQICEBMjUVlih6h6pQ7i2OzJ8/MwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh
d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDExMDEwMDAwMDBaFw0wMzA2MDkyMzU5NTla
MEwxCzAJBgNVBAYTAlVTMRswGQYDVQQKExJFcXVpZmF4IFNlY3VyZSBJbmMxIDAeBgNVBAMTF0Vx
dWlmYXggU2VjdXJlIEVtYWlsIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCeZ/4bODoB
R+BTlesm8Dd2kqhtIbeGxvBuclR+bDX02mNwpoPV3HeLmFT+q8mllJ5R3x6IJgHZWUwz7stb4+zD
NAjwd5jf3LEskadCZ+O6REJhpz7PRobxYhfdr9puYVpbBqOLUnmGwOt36fgPdXu1iq3jeu8C+F3+
e6ka7hle0wIDAQABoyMwITASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG
9w0BAQQFAAOBgQBlqVclsMirnoq1hzPZqBbIkUqfyvNcOdo7aXv1fYZfx1e4u37OSPbfXpfHbFM7
0ODTHmtqHrS7Z2KVPtjRH/vW0YaRcNOgcjghlJFKyNryHTD3FMwvzefhjQ2zfEdz6OFWZARDY1uE
V5SW6zZJwdgbvtLhltkDEJkA26tHcktEdDCCAsYwggIvoAMCAQICEBMjUVlih6h6pQ7i2OzJ8/Mw
DQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl
cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe
Fw0wMDExMDEwMDAwMDBaFw0wMzA2MDkyMzU5NTlaMEwxCzAJBgNVBAYTAlVTMRswGQYDVQQKExJF
cXVpZmF4IFNlY3VyZSBJbmMxIDAeBgNVBAMTF0VxdWlmYXggU2VjdXJlIEVtYWlsIENBMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCeZ/4bODoBR+BTlesm8Dd2kqhtIbeGxvBuclR+bDX02mNw
poPV3HeLmFT+q8mllJ5R3x6IJgHZWUwz7stb4+zDNAjwd5jf3LEskadCZ+O6REJhpz7PRobxYhfd
r9puYVpbBqOLUnmGwOt36fgPdXu1iq3jeu8C+F3+e6ka7hle0wIDAQABoyMwITASBgNVHRMBAf8E
CDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQBlqVclsMirnoq1hzPZqBbI
kUqfyvNcOdo7aXv1fYZfx1e4u37OSPbfXpfHbFM70ODTHmtqHrS7Z2KVPtjRH/vW0YaRcNOgcjgh
lJFKyNryHTD3FMwvzefhjQ2zfEdz6OFWZARDY1uEV5SW6zZJwdgbvtLhltkDEJkA26tHcktEdDCC
AycwggKQoAMCAQICAgwbMA0GCSqGSIb3DQEBBAUAMEwxCzAJBgNVBAYTAlVTMRswGQYDVQQKExJF
cXVpZmF4IFNlY3VyZSBJbmMxIDAeBgNVBAMTF0VxdWlmYXggU2VjdXJlIEVtYWlsIENBMB4XDTAx
MTAyNTIwNTE1NloXDTAyMTEwODIxNTE1NlowgYsxCzAJBgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0x
ETAPBgNVBAsTCEVNUExPWUVFMRgwFgYDVQQDEw9Sb2IgRy4gV2VlbWhvZmYxGTAXBgoJkiaJk/Is
ZAEBEwkwOTMyNTI3ODgxJjAkBgkqhkiG9w0BCQEWF3JvYl93ZWVtaG9mZkBubC5pYm0uY29tMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCmqkWR/YMN7tn0JJYjUYNbpD9A4/AJcGYvyRiJjgw0
PD7SfMK5DkhqQk7Uo/DLX6AOyUQwaLqBBdygWXhGeU14LacpvWICa/VATMK1sDDLdmK7/6Gd8HBU
RX+aQVJWb4pvmMMBfg+OfZcdl5AoUEyyCw4nMIQJ0am0j0uatym6UwIDAQABo4HXMIHUMA4GA1Ud
DwEB/wQEAwIE8DBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vd3d3LmVxdWlmYXhzZWN1cmUuY29t
L2VidXNpbmVzc2lkL2NybC9zbWltZTY0Yi5jcmwwdgYDVR0gBG8wbTBrBglghkgBhvpMAQEwXjAX
BggrBgEFBQcCAjALMAcWADADAgEBGgAwQwYIKwYBBQUHAgEWN2h0dHA6Ly93d3cuZXF1aWZheHNl
Y3VyZS5jb20vZWJ1c2luZXNzaWQvc21pbWVfY3BzLmh0bWwwDQYJKoZIhvcNAQEEBQADgYEADxvV
1SPCvkYYMDoU6zyrl+OWQdWg6Szw/oY5tUkNYRD6/flrIe9BUU6XIOZ3/wQf7AdXIbZO7A7LVOhE
Vv0fgiFksy55gnoDYB7ir+NGnpl2LE3XKito6p6u8cabNFjFzCxr036IsmysF/K6Jw0yqdADq6hS
Z67UmdUeQsCxRggwggMnMIICkKADAgECAgIMGzANBgkqhkiG9w0BAQQFADBMMQswCQYDVQQGEwJV
UzEbMBkGA1UEChMSRXF1aWZheCBTZWN1cmUgSW5jMSAwHgYDVQQDExdFcXVpZmF4IFNlY3VyZSBF
bWFpbCBDQTAeFw0wMTEwMjUyMDUxNTZaFw0wMjExMDgyMTUxNTZaMIGLMQswCQYDVQQGEwJVUzEM
MAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEYMBYGA1UEAxMPUm9iIEcuIFdlZW1ob2Zm
MRkwFwYKCZImiZPyLGQBARMJMDkzMjUyNzg4MSYwJAYJKoZIhvcNAQkBFhdyb2Jfd2VlbWhvZmZA
bmwuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApqpFkf2DDe7Z9CSWI1GDW6Q/
QOPwCXBmL8kYiY4MNDw+0nzCuQ5IakJO1KPwy1+gDslEMGi6gQXcoFl4RnlNeC2nKb1iAmv1QEzC
tbAwy3Ziu/+hnfBwVEV/mkFSVm+Kb5jDAX4Pjn2XHZeQKFBMsgsOJzCECdGptI9LmrcpulMCAwEA
AaOB1zCB1DAOBgNVHQ8BAf8EBAMCBPAwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3d3dy5lcXVp
ZmF4c2VjdXJlLmNvbS9lYnVzaW5lc3NpZC9jcmwvc21pbWU2NGIuY3JsMHYGA1UdIARvMG0wawYJ
YIZIAYb6TAEBMF4wFwYIKwYBBQUHAgIwCzAHFgAwAwIBARoAMEMGCCsGAQUFBwIBFjdodHRwOi8v
d3d3LmVxdWlmYXhzZWN1cmUuY29tL2VidXNpbmVzc2lkL3NtaW1lX2Nwcy5odG1sMA0GCSqGSIb3
DQEBBAUAA4GBAA8b1dUjwr5GGDA6FOs8q5fjlkHVoOks8P6GObVJDWEQ+v35ayHvQVFOlyDmd/8E
H+wHVyG2TuwOy1ToRFb9H4IhZLMueYJ6A2Ae4q/jRp6ZdixN1yoraOqervHGmzRYxcwsa9N+iLJs
rBfyuicNMqnQA6uoUmeu1JnVHkLAsUYIMIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB
0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2
aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ
KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoX
DTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl
cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34Ul
dSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr
2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0T
AQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1
XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8
sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAy0wggKWoAMCAQIC
AQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT
H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv
bTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z
dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQD
ExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy
ZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH
2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9x
H0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+Va
xBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749Zal
Z2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj
524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T4
0c53ooExggGdMIIBmQIBATBSMEwxCzAJBgNVBAYTAlVTMRswGQYDVQQKExJFcXVpZmF4IFNlY3Vy
ZSBJbmMxIDAeBgNVBAMTF0VxdWlmYXggU2VjdXJlIEVtYWlsIENBAgIMGzAJBgUrDgMCGgUAoIGi
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDcyNTEwMzIxN1ow
IwYJKoZIhvcNAQkEMRYEFOc+aoc+nDTZWqafhNJ6bKysyocGMEMGCSqGSIb3DQEJDzE2MDQwBwYF
Kw4DAh0wDgYIKoZIhvcNAwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3
DQEBAQUABIGAYpCDSemSeaxpAZkscu5pjps7FsxbDGM/6hh35FwWClJ0iQk/Jf9GUPIWVXr4MvYD
HXrLG4UsRJdZe2MVK8VSwort+SGKyHtND7bW2GMXgGiEAqqoIEUPuVMqLInPWox/jxIP5gBXye5M
wcXSXkbiv8Bi7thG2ckqWJeHXuoVm2AAAAAA

---------z3173_boundary_sign--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6P95jP12939 for ietf-pkix-bks; Thu, 25 Jul 2002 02:05:45 -0700 (PDT)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6P95iw12935 for <[e-mail]>; Thu, 25 Jul 2002 02:05:44 -0700 (PDT)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id <3YMK893W>; Thu, 25 Jul 2002 19:05:36 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: David Chadwick <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: LDAP ISSUE
Date: Thu, 25 Jul 2002 19:05:57 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

How can you display an unknown keyword?

The keyword comes out just fine, but the value? The assumption in LDAPv2 was
that all values are encoded as printable (ASCII) strings, so your idea would
work fine here. Now that we are in the modern world, though, some care must
be taken with values. It would seem more appropriate to ignore unrecognised
attributes, rather than displaying them.

Ron.

-----Original Message-----
From: David Chadwick [mailto:[e-mail]]
Sent: Tuesday, 23 July 2002 21:08
To: [e-mail]
Cc: [e-mail]
Subject: Re: LDAP ISSUE




Steve Hanna wrote:
> 
> David Chadwick wrote:
> >we have two cases here.
> 

Steve

sorry for the late reply, but I was travelling in Japan all the week
after the IETF meeting.

> What about the case where a server returns a keyword to a
> client that doesn't understand it? 

This is exactly why LDAP invented the use of keywords. The argument is
that clients who dont understand the new attribute type, if it is
identified by an object identifiers then displaying these OIDs to the
users is pointless. However, if an unknown attribute is identified by an
unknown keyword e.g. Pseudonymn is returned to the client, it simply
displays it to the human user as is, in anticipation that it will make
sense to the user. Certainly the keyword will make more sense to the
human than the OID. Thus your third case above is one that actually
supports the use of keywords rather than OIDs.


>I agree that you can define
> new keywords if all the software is updated or reconfigured
> whenever a new keyword is defined. But this isn't realistic.
> 

Its just as realistic as reconfiguring the software when a new attribute
OID is defined. The whole point of LDAP using keywords was that unknown
keywords were easier for dumb clients to handle than unknown OIDs.

> 
> We agree that OIDs are the best solution for the on-the-wire
> protocol. 

Actually I just gave an example when they werent!. But if we had a clean
sheet for defining the LDAP protocol I would never have suggested
inventing keywords and would have stuck with OIDs to be compatible with
X.500. But there are many folk who think that keywords in protocol are
far preferrable all the time to OIDs, since it makes debugging much
easier (e.g. would you prefer to see 1.2.986.2345.26.3.4.67 or ssNumber
when it occurs in protocol).

>The best way forward seems clear to me. Don't define
> new keywords to be used on the wire. Can you provide any reason
> why it would be good to define more keywords?
>

Yes I just have done above. Could you also answer my point that already
more than 50 keywords exist, and servers know how to map these into
attribute types (and OIDs) when they exist in requests for attributes,
but not when they exist in DNs. Can  you explain why this situation is
tenable?


> >But now PKIX has defined some new attributes for use
> >in DNs, and therefore the keywords for these should also be supported.
> 
> Following that logic, we'll have to add new keywords whenever
> anyone comes up with another attribute. Each keyword will
> introduce another potential compatibility issue. That sounds
> pretty undesirable to me.
> 

No so, if the keyword is registered when the new attribute OID is
registered, then both will appear at the same time.

David

> Thanks,
> 
> Steve

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6P7VlA01228 for ietf-pkix-bks; Thu, 25 Jul 2002 00:31:47 -0700 (PDT)
Received: from imfep03.kcom.ne.jp (imfep03.kcom.ne.jp [210.174.120.149]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6P7Vkw01218 for <[e-mail]>; Thu, 25 Jul 2002 00:31:46 -0700 (PDT)
Received: from salford.ac.uk ([203.141.162.38]) by imfep03.kcom.ne.jp (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Thu, 25 Jul 2002 16:31:34 +0900
Message-ID: <[e-mail]>
Date: Tue, 23 Jul 2002 12:07:50 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: LDAP ISSUE
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------3B49C2D188B8CF5B66D9AB87"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Steve Hanna wrote:
> 
> David Chadwick wrote:
> >we have two cases here.
> 

Steve

sorry for the late reply, but I was travelling in Japan all the week
after the IETF meeting.

> What about the case where a server returns a keyword to a
> client that doesn't understand it? 

This is exactly why LDAP invented the use of keywords. The argument is
that clients who dont understand the new attribute type, if it is
identified by an object identifiers then displaying these OIDs to the
users is pointless. However, if an unknown attribute is identified by an
unknown keyword e.g. Pseudonymn is returned to the client, it simply
displays it to the human user as is, in anticipation that it will make
sense to the user. Certainly the keyword will make more sense to the
human than the OID. Thus your third case above is one that actually
supports the use of keywords rather than OIDs.


>I agree that you can define
> new keywords if all the software is updated or reconfigured
> whenever a new keyword is defined. But this isn't realistic.
> 

Its just as realistic as reconfiguring the software when a new attribute
OID is defined. The whole point of LDAP using keywords was that unknown
keywords were easier for dumb clients to handle than unknown OIDs.

> 
> We agree that OIDs are the best solution for the on-the-wire
> protocol. 

Actually I just gave an example when they werent!. But if we had a clean
sheet for defining the LDAP protocol I would never have suggested
inventing keywords and would have stuck with OIDs to be compatible with
X.500. But there are many folk who think that keywords in protocol are
far preferrable all the time to OIDs, since it makes debugging much
easier (e.g. would you prefer to see 1.2.986.2345.26.3.4.67 or ssNumber
when it occurs in protocol).

>The best way forward seems clear to me. Don't define
> new keywords to be used on the wire. Can you provide any reason
> why it would be good to define more keywords?
>

Yes I just have done above. Could you also answer my point that already
more than 50 keywords exist, and servers know how to map these into
attribute types (and OIDs) when they exist in requests for attributes,
but not when they exist in DNs. Can  you explain why this situation is
tenable?


> >But now PKIX has defined some new attributes for use
> >in DNs, and therefore the keywords for these should also be supported.
> 
> Following that logic, we'll have to add new keywords whenever
> anyone comes up with another attribute. Each keyword will
> introduce another potential compatibility issue. That sounds
> pretty undesirable to me.
> 

No so, if the keyword is registered when the new attribute OID is
registered, then both will appear at the same time.

David

> Thanks,
> 
> Steve

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------3B49C2D188B8CF5B66D9AB87
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------3B49C2D188B8CF5B66D9AB87--





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6P7VkK01217 for ietf-pkix-bks; Thu, 25 Jul 2002 00:31:46 -0700 (PDT)
Received: from imfep03.kcom.ne.jp (imfep03.kcom.ne.jp [210.174.120.149]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6P7Viw01205 for <[e-mail]>; Thu, 25 Jul 2002 00:31:44 -0700 (PDT)
Received: from salford.ac.uk ([203.141.162.38]) by imfep03.kcom.ne.jp (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Thu, 25 Jul 2002 16:31:42 +0900
Message-ID: <[e-mail]>
Date: Tue, 23 Jul 2002 12:09:52 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: LDAP ISSUE
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------91605E42822B1613F7BC98B6"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Dave

the current LDAP model is that the server does the mapping, and that the
client does not need to be bothered with the OIDs. Simple clients will
not map between keywords and the user interface (the user will see the
keywords). More sophisticated clients will do some presentation mapping
e.g. serialNumber into Serial Number.

David


Steve Hanna wrote:
> 
> Yes, this is a presentation issue. OIDs work fine on the wire
> (in the LDAP protocol). Keywords are only important when
> users need to understand the DN. I agree with your suggestion
> completely. Use OIDs on the wire for maximum compatibility
> and simplicity in implementation. Clients can translate these
> to and from user-friendly keywords, if they want.
> 
> -Steve
> 
> >
> >Steve,
> >
> >That sounds like a presentation issue, and perhaps that's what
> >you meant to imply by emphasizing "on the wire".
> >
> >Would it not be reasonable for new DN attribute keywords to
> >be registered with IANA, and permit newly developed clients
> >to translate between keywords (for human consumption)
> >and OIDs (on the wire)?
> >
> >Dave
> >
> >
> >
> >
> >Steve Hanna wrote:
> >>
> >> Actually, there is a good reason for the position of the LDAP
> >> group on this issue.
> >>
> >> The reason that new keywords for attribute types in X.500 DNs
> >> cannot be sent on the wire in LDAP protocol messages is that
> >> old LDAP servers won't know what the new keywords mean. For
> >> user input and output, new keywords can be added. But you
> >> can't expect existing LDAP servers to automagically understand
> >> what a new keyword means when they see it on the wire. OIDs
> >> are the best way to handle this.
> >>
> >> Also, this is not a new position. RFC 1779 (for LDAPv2)
> >> allowed new keywords and defined an IANA registry. But no
> >> new keywords were ever defined. I suspect that people
> >> realized the problems that would ensue. RFC 2253 (for LDAPv3)
> >> does not allow new keywords. And the revised version of 2253
> >> (draft-ietf-ldapbis-dn-07.txt) also does not.
> >>
> >> Steve

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------91605E42822B1613F7BC98B6
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------91605E42822B1613F7BC98B6--





Received: by above.proper.com (8.11.6/8.11.3) id g6P4sZx08724 for ietf-pkix-bks; Wed, 24 Jul 2002 21:54:35 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6P4sWw08719 for <[e-mail]>; Wed, 24 Jul 2002 21:54:33 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g6P4sSq9032285; Thu, 25 Jul 2002 16:54:28 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA157451; Thu, 25 Jul 2002 16:54:26 +1200 (NZST) (sender [e-mail])
Date: Thu, 25 Jul 2002 16:54:26 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  interpretation of  extended key usage
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Heyden, Klaus" <[e-mail]> writes:

>(1) the extended key usage is only usable for the use of the public key itself
>and his direct usage i.e. signing of certificates etc. (view RFC 2469 4.2.1.13
>first sentence). So a root certificate dont need an extended key usage, because
>the public key will only be needed for path validation and signing of
>certificates and CRLs.
>
>(2) the public key is also needed for path validation, so an extended key
>usage can be used to restrict the use of sub and end entity certificates.
>
>I have looked a bit around and found some CA certificates with extended key
>usages, so its a bit confusing. Both way's are imagineable.

Both are used (see e.g. the X.509 style guide for comments).  If you need to
use one or the other, just find the appropriate standard which specifies the
one you want.  Alternatively, if you have to comply with a certain standard,
make sure that the software you're using does actually apply the same
interpretation as the standard.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6OLenO29842 for ietf-pkix-bks; Wed, 24 Jul 2002 14:40:49 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6OLelw29836 for <[e-mail]>; Wed, 24 Jul 2002 14:40:47 -0700 (PDT)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Jul 2002 21:41:33 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g6OLk8q05950 for <[e-mail]>; Thu, 25 Jul 2002 07:46:08 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <NVT7GT81>; Thu, 25 Jul 2002 07:40:38 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.32]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TP40V41; Wed, 24 Jul 2002 17:40:36 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 24 Jul 2002 17:40:33 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Wireless LAN Certificate Extensions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At the IETF meeting in Japan last week, I gave a presentation on 
draft-ietf-pkix-wlan-extns-00.txt. I got one question that deserves 
discussion on the list.

The question was: Can the SSID change?  And if so, is there a more stable 
alternative that we could include in the certificate instead.

Yes the SSID can change, but it does not change often.  For example when 
Mobilestar was bought, the SSID was changed to TMOBILE from Mobilestar. 
There isn't a good replacement. One that the authors considered is the 
network name of the RADIUS server/proxy (not the final RADIUS server) which 
would be mobilestar.com in the previous example.  However, this name would 
also change under then same circumstances that cause the SSID to change.

I propose that we stick with SSID as described in the document.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6OLb1m29790 for ietf-pkix-bks; Wed, 24 Jul 2002 14:37:01 -0700 (PDT)
Received: from mx4.magma.ca (mx4.magma.ca [206.191.0.253]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OLb0w29786 for <[e-mail]>; Wed, 24 Jul 2002 14:37:00 -0700 (PDT)
Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221]) by mx4.magma.ca (Magma's Mail Server) with ESMTP id g6OLavmA016710 for <[e-mail]>; Wed, 24 Jul 2002 17:36:58 -0400
Received: from asturgeonpc (ottawa-dial-64-26-139-104.d-ip.magma.ca [64.26.139.104]) by mail3.magma.ca (Magma's Mail Server) with SMTP id g6OLascG010971 for <[e-mail]>; Wed, 24 Jul 2002 17:36:55 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: <[e-mail]>
Subject: draft-ietf-pkix-warranty-ext-01
Date: Wed, 24 Jul 2002 17:41:07 -0400
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: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Several issues were raised at the IETF meeting on the proposed warranty
extension I-D that may warrant some discussion on this list.

Issue # 1:  Should the warranty be an aspect of certification policy?  If
so, policy qualifiers would indicate the amount of coverage.
The reason for a warranty program is that a CA is not an insurance company
and therefore cannot issue a policy of insurance in favor of the subscriber.
The CA will take out a certificate insurance policy with a licensed
insurance company.  Different certificates will have different certificate
policies and therefore will have a different risk profile.  The insurance
company will cover each certificate and type of certificate issued.  Hence
the insurance company will sit behind the operations of the CA to cover the
extended warranty program.  There will be a contractual relationship between
the CA and  the subscriber, likely through the use of a Subscriber
Agreement.  With respect to the relying party, the subscriber, if the
subscriber opts for the extended warranty, has the opportunity to extend the
financial trust relationship between them.  A relying party in encountering
a certificate warranty program will know that an insurance company is
covering the CA for any claims that fit within the warranty program.
Consequently certain warranties will be dealt with in the CP but it will not
deal with the extended warranty.  For example, the amount of compensation
available would likely not be covered as the same CP for different types of
certificates (e.g., usages) could have different extended warranty amounts.
It is up to the subscriber to select the program.
Warranty may be an aspect of certification policy, just as liability and
disclaimers of liability and/or warranty.  It is not necessary or
appropriate to define a new policy qualifier (nor would it covered in the
two policy qualifiers specified in RFC 3280 (s.4.2.1.5), the CPS URI pointer
and User Notice), because it is defined in the proposed extension.  The
warranty extension may include the amount of coverage, or it may point to a
specific document in which coverage is specified.  That could be a narrowly
focused Terms and Conditions, it could be Subscriber/Relying Party
Agreements, or it could be a CP.  The revision of RFC 2527 covers issues of
warranty, and allows the statement of warranty in the CP and/or in
subscriber/relying party agreements.  Note: 'The degree to which a relying
party can trust the binding embodied in a certificate depends on several
factors. These factors include the practices followed by CA in
authenticating the subject; the CA's operating policy, procedures, and
security controls; the scope of the subscriber's obligations (for example,
in protecting the private key); and the stated responsibilities and
liability terms and conditions of the CA (for example, warranties,
disclaimers of warranties, and limitations of liability).' [s.1.1]
Note also: section 4.9.6:  Representations and Warranties - 'This
subcomponent can include representations and warranties of various entities
that are being made pursuant to the CP or CPS...'

Issue # 2:  There has been concern expressed that IETF standardization of
this proposed certificate extension could lead to proposals to standardize
on other extensions, possibly many extensions.  If proposals come forward,
then they should be considered on a case-by-case basis.  We should not
arbitrarily or gratuitously prohibit, or even discourage, proposals for
standardization on any aspect of certificates and PKI in general.  Where one
person does not see a need for standardization, another might; if the case
for standardization is sufficient, then it should be allowed.  We saw a
strong need for standardizing in the area of warranty, and so proposed this
standard for an extension.

Issue # 3: ETSI tried to specify warranty information, and ETSI was never
able to reach consensus.
While awaiting background on the discussions in ETSI, it is worthwhile
noting that the ETSI standard that is being/has been discussed on this issue
(ETSI 101 862 - Qualified Certificate Profile) says nothing about warranty,
insurance, liability or disclaimers of such.  The only related aspect is the
inclusion of an optional statement on the monetary limit for which a
certificate may be used (pursuant to 1999/93/EC).  It has been noted that
this optional statement is virtually the same as an explicit warranty
disclaimer, but we would argue that it is insufficient to give adequate
confidence to a relying party, by being implicit.

Issue # 4: Would any CA be willing to make warranty cover the subscriber
actions as well as the CA actions?  If so, the relying party would be better
served.
Whether a CA would make a warranty that covers subscriber actions is outside
the scope of this proposed I-D. This proposed extension covers a CA's
warranty provision. It is, of course, possible that a CA would insure
against subscriber folly, but it is considered unlikely.  Think about it:
the only case in which a CA might be willing to cover the actions of its
subscribers would be in a closed, high-assurance infrastructure; in that
case, however, subscribers will also be the relying parties (and vice
versa), so the matter is academic.  In an open infrastructure, even a
high-assurance one with user hardware security modules (tokens), the CA
cannot control all the actions of subscribers nor ensure that subscribers
will do everything right (i.e., protect their private keys).  Other parts of
the certificate, obviously, constrain the actions of all parties, in terms
of certificate usage, applications, etc. etc.  The warranty extension need
not address all concerns; that is not its purpose.  Its purpose is to give
the relying party (a) confidence in the backing of the certificate (as well
as confidence in the CA, in that the CA specifies in warranty coverage its
own confidence in the system), and (b) an avenue for compensation in the
event that the CA causes harm through failure to conform to its own
specifications.



Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6OKPuB28391 for ietf-pkix-bks; Wed, 24 Jul 2002 13:25:56 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6OKPsw28387 for <[e-mail]>; Wed, 24 Jul 2002 13:25:54 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Jul 2002 20:25:00 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA14051 for <[e-mail]>; Wed, 24 Jul 2002 16:25:56 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6OKNn003627 for <[e-mail]>; Wed, 24 Jul 2002 16:23:49 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TP4043B>; Wed, 24 Jul 2002 16:25:54 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.32]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TP4043A; Wed, 24 Jul 2002 16:25:52 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 24 Jul 2002 16:25:49 -0400
Subject: Re: interpretation of extended key usage
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

I am unaware of any extended key usage OIDs for CMP.

It is quite reasonable for a CA certificate to indicate that the key can be 
used to validate OCSP or SCVP responses (if the CA handles these with the 
same signing key).

I tend to think of a root CA as being primarily off-line.  This 
architecture provides for physical protection of the root CA's signing 
key.  I guess this bias spilled into my response.

Russ



At 03:16 PM 7/24/2002 -0400, Tom Gindin wrote:

>       Russ:
>
>       Would it be reasonable for a CA certificate to contain extended key
>usage values for CMP usage (or perhaps OCSP)?  It would be better practice
>for the CA to issue a certificate to its own DN with such values but no
>certificate signing ability, of course.  It is clear that the extended key
>usage extension in a CA certificate is not an analogue to name or policy
>constraints.
>
>             Tom Gindin
>
>
>"Housley, Russ" <[e-mail]>@mail.imc.org on 07/24/2002
>10:10:53 AM
>
>Sent by:    [e-mail]
>
>
>To:    "Heyden, Klaus" <[e-mail]>
>cc:    [e-mail]
>Subject:    Re: interpretation of  extended key usage
>
>
>
>I think that RFC 3280 is pretty clear.  It says:
>
>     If a certificate contains both a key usage extension and an extended
>     key usage extension, then both extensions MUST be processed
>     independently and the certificate MUST only be used for a purpose
>     consistent with both extensions.  If there is no purpose consistent
>     with both extensions, then the certificate MUST NOT be used for any
>     purpose.
>
>I would not expect a root certificate to contain an extended key usage
>extension.
>
>Russ
>
>
>At 01:12 PM 7/24/2002 +0200, Heyden, Klaus wrote:
>
> >Hello,
> >
> >i have a question about the meaning of extended key usage extensions in a
> >certificate, specialy in a root certificate.
> >
> >How is the understanding of extended Key Usages in Root or CA
>certificates.
> >Specialy under the circumstance of certificate path validation. Therefor i
> >think two opinions are possible:
> >
> >(1) the extended key usage is only usable for the use of the public key
> >itself and his direct usage i.e. signing of certificates etc. (view RFC
>2469
> >4.2.1.13 first sentence). So a root certificate dont need an extended key
> >usage, because the public key will only be needed for path validation and
> >signing of certificates and CRLs.
> >
> >(2) the public key is also needed for path validation, so an extended key
> >usage can be used to restrict the use of sub and end entity certificates.
> >
> >I have looked a bit around and found some CA certificates with extended
>key
> >usages, so its a bit confusing. Both way's are imagineable.
> >
> >Best Regards
> >Klaus Heyden
> >
> >
> >Dresdner Bank AG
> >D-60301 Frankfurt/Main
> >[e-mail]
> >[phone]
> >[phone]


Received: by above.proper.com (8.11.6/8.11.3) id g6OJGKk23782 for ietf-pkix-bks; Wed, 24 Jul 2002 12:16:20 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OJGIw23775 for <[e-mail]>; Wed, 24 Jul 2002 12:16:18 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6OJGCg5201004; Wed, 24 Jul 2002 15:16:12 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6OJG9s4087384; Wed, 24 Jul 2002 15:16:10 -0400
Importance: Normal
Sensitivity: 
Subject: Re: interpretation of extended key usage
To: "Housley, Russ" <[e-mail]>
Cc: "Heyden, Klaus" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 24 Jul 2002 15:16:15 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 07/24/2002 03:16:10 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Russ:

      Would it be reasonable for a CA certificate to contain extended key
usage values for CMP usage (or perhaps OCSP)?  It would be better practice
for the CA to issue a certificate to its own DN with such values but no
certificate signing ability, of course.  It is clear that the extended key
usage extension in a CA certificate is not an analogue to name or policy
constraints.

            Tom Gindin


"Housley, Russ" <[e-mail]>@mail.imc.org on 07/24/2002
10:10:53 AM

Sent by:    [e-mail]


To:    "Heyden, Klaus" <[e-mail]>
cc:    [e-mail]
Subject:    Re: interpretation of  extended key usage



I think that RFC 3280 is pretty clear.  It says:

    If a certificate contains both a key usage extension and an extended
    key usage extension, then both extensions MUST be processed
    independently and the certificate MUST only be used for a purpose
    consistent with both extensions.  If there is no purpose consistent
    with both extensions, then the certificate MUST NOT be used for any
    purpose.

I would not expect a root certificate to contain an extended key usage
extension.

Russ


At 01:12 PM 7/24/2002 +0200, Heyden, Klaus wrote:

>Hello,
>
>i have a question about the meaning of extended key usage extensions in a
>certificate, specialy in a root certificate.
>
>How is the understanding of extended Key Usages in Root or CA
certificates.
>Specialy under the circumstance of certificate path validation. Therefor i
>think two opinions are possible:
>
>(1) the extended key usage is only usable for the use of the public key
>itself and his direct usage i.e. signing of certificates etc. (view RFC
2469
>4.2.1.13 first sentence). So a root certificate dont need an extended key
>usage, because the public key will only be needed for path validation and
>signing of certificates and CRLs.
>
>(2) the public key is also needed for path validation, so an extended key
>usage can be used to restrict the use of sub and end entity certificates.
>
>I have looked a bit around and found some CA certificates with extended
key
>usages, so its a bit confusing. Both way's are imagineable.
>
>Best Regards
>Klaus Heyden
>
>
>Dresdner Bank AG
>D-60301 Frankfurt/Main
>[e-mail]
>[phone]
>[phone]







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6OEB4V07881 for ietf-pkix-bks; Wed, 24 Jul 2002 07:11:04 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6OEB3w07876 for <[e-mail]>; Wed, 24 Jul 2002 07:11:03 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Jul 2002 14:10:07 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA05170 for <[e-mail]>; Wed, 24 Jul 2002 10:11:03 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6OE8v416997 for <[e-mail]>; Wed, 24 Jul 2002 10:08:57 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TP40NXB>; Wed, 24 Jul 2002 10:11:02 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.16]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TP40NW0; Wed, 24 Jul 2002 10:10:57 -0400
From: "Housley, Russ" <[e-mail]>
To: "Heyden, Klaus" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 24 Jul 2002 10:10:53 -0400
Subject: Re: interpretation of  extended key usage
In-Reply-To: <[e-mail] l.dresdner.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think that RFC 3280 is pretty clear.  It says:

    If a certificate contains both a key usage extension and an extended
    key usage extension, then both extensions MUST be processed
    independently and the certificate MUST only be used for a purpose
    consistent with both extensions.  If there is no purpose consistent
    with both extensions, then the certificate MUST NOT be used for any
    purpose.

I would not expect a root certificate to contain an extended key usage 
extension.

Russ


At 01:12 PM 7/24/2002 +0200, Heyden, Klaus wrote:

>Hello,
>
>i have a question about the meaning of extended key usage extensions in a
>certificate, specialy in a root certificate.
>
>How is the understanding of extended Key Usages in Root or CA certificates.
>Specialy under the circumstance of certificate path validation. Therefor i
>think two opinions are possible:
>
>(1) the extended key usage is only usable for the use of the public key
>itself and his direct usage i.e. signing of certificates etc. (view RFC 2469
>4.2.1.13 first sentence). So a root certificate dont need an extended key
>usage, because the public key will only be needed for path validation and
>signing of certificates and CRLs.
>
>(2) the public key is also needed for path validation, so an extended key
>usage can be used to restrict the use of sub and end entity certificates.
>
>I have looked a bit around and found some CA certificates with extended key
>usages, so its a bit confusing. Both way's are imagineable.
>
>Best Regards
>Klaus Heyden
>
>
>Dresdner Bank AG
>D-60301 Frankfurt/Main
>[e-mail]
>[phone]
>[phone]


Received: by above.proper.com (8.11.6/8.11.3) id g6OBI8D29892 for ietf-pkix-bks; Wed, 24 Jul 2002 04:18:08 -0700 (PDT)
Received: from purveyor6.dresdnerbank.de (purveyor6.dresdnerbank.de [193.194.7.52]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OBI7w29888 for <[e-mail]>; Wed, 24 Jul 2002 04:18:07 -0700 (PDT)
Received: from ffz00egn.wwz0me.mail.dresdner.net (unverified) by purveyor6.dresdnerbank.de (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 24 Jul 2002 13:12:26 +0200
Received: by ffz00egn.wwz0me.mail.dresdner.net with Internet Mail Service (5.5.2655.55) id <PG64NQ5N>; Wed, 24 Jul 2002 13:12:26 +0200
Message-ID: <[e-mail]>
From: "Heyden, Klaus" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: interpretation of  extended key usage
Date: Wed, 24 Jul 2002 13:12:22 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

i have a question about the meaning of extended key usage extensions in a
certificate, specialy in a root certificate.

How is the understanding of extended Key Usages in Root or CA certificates.
Specialy under the circumstance of certificate path validation. Therefor i
think two opinions are possible:

(1) the extended key usage is only usable for the use of the public key
itself and his direct usage i.e. signing of certificates etc. (view RFC 2469
4.2.1.13 first sentence). So a root certificate dont need an extended key
usage, because the public key will only be needed for path validation and
signing of certificates and CRLs.

(2) the public key is also needed for path validation, so an extended key
usage can be used to restrict the use of sub and end entity certificates. 

I have looked a bit around and found some CA certificates with extended key
usages, so its a bit confusing. Both way's are imagineable.  

Best Regards 
Klaus Heyden 


Dresdner Bank AG 
D-60301 Frankfurt/Main 
[e-mail] 
[phone] 
[phone] 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6J8Rm509440 for ietf-pkix-bks; Fri, 19 Jul 2002 01:27:48 -0700 (PDT)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J8Rlw09426 for <[e-mail]>; Fri, 19 Jul 2002 01:27:47 -0700 (PDT)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07258; Fri, 19 Jul 2002 01:27:41 -0700 (PDT)
Received: from sydney.East.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g6J8RXL25582; Fri, 19 Jul 2002 04:27:35 -0400 (EDT)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 19 Jul 2002 17:28:43 +0-900
To: "David Chadwick" <[e-mail]>
Cc: <[e-mail]>
Reply-To: <[e-mail]>
Subject: Re: LDAP ISSUE
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick wrote:
>we have two cases here.

What about the case where a server returns a keyword to a
client that doesn't understand it? I agree that you can define
new keywords if all the software is updated or reconfigured
whenever a new keyword is defined. But this isn't realistic.

>> For
>> user input and output, new keywords can be added. But you
>> can't expect existing LDAP servers to automagically understand
>> what a new keyword means when they see it on the wire. OIDs
>> are the best way to handle this.
>
>Actually OIDs are the best alround, and keywords should never have been
>defined! But given that they are, we should be consistent in their
>application, and not require keywords for some things and OIDs for
>others, within the same protocol item (a DN)

We agree that OIDs are the best solution for the on-the-wire
protocol. The best way forward seems clear to me. Don't define
new keywords to be used on the wire. Can you provide any reason
why it would be good to define more keywords?

>But now PKIX has defined some new attributes for use
>in DNs, and therefore the keywords for these should also be supported.

Following that logic, we'll have to add new keywords whenever
anyone comes up with another attribute. Each keyword will
introduce another potential compatibility issue. That sounds
pretty undesirable to me.

Thanks,

Steve



Received: by above.proper.com (8.11.6/8.11.3) id g6J8MJ208208 for ietf-pkix-bks; Fri, 19 Jul 2002 01:22:19 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J8MHw08200 for <[e-mail]>; Fri, 19 Jul 2002 01:22:17 -0700 (PDT)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04599; Fri, 19 Jul 2002 02:22:17 -0600 (MDT)
Received: from sydney.East.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g6J8M9L25389; Fri, 19 Jul 2002 04:22:10 -0400 (EDT)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 19 Jul 2002 17:23:18 +0-900
To: "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
Reply-To: <[e-mail]>
Subject: Re: LDAP ISSUE
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, this is a presentation issue. OIDs work fine on the wire
(in the LDAP protocol). Keywords are only important when
users need to understand the DN. I agree with your suggestion
completely. Use OIDs on the wire for maximum compatibility
and simplicity in implementation. Clients can translate these
to and from user-friendly keywords, if they want.

-Steve

>
>Steve,
>
>That sounds like a presentation issue, and perhaps that's what
>you meant to imply by emphasizing "on the wire".
>
>Would it not be reasonable for new DN attribute keywords to
>be registered with IANA, and permit newly developed clients
>to translate between keywords (for human consumption)
>and OIDs (on the wire)?
>
>Dave
>
>
>
>
>Steve Hanna wrote:
>> 
>> Actually, there is a good reason for the position of the LDAP
>> group on this issue.
>> 
>> The reason that new keywords for attribute types in X.500 DNs
>> cannot be sent on the wire in LDAP protocol messages is that
>> old LDAP servers won't know what the new keywords mean. For
>> user input and output, new keywords can be added. But you
>> can't expect existing LDAP servers to automagically understand
>> what a new keyword means when they see it on the wire. OIDs
>> are the best way to handle this.
>> 
>> Also, this is not a new position. RFC 1779 (for LDAPv2)
>> allowed new keywords and defined an IANA registry. But no
>> new keywords were ever defined. I suspect that people
>> realized the problems that would ensue. RFC 2253 (for LDAPv3)
>> does not allow new keywords. And the revised version of 2253
>> (draft-ietf-ldapbis-dn-07.txt) also does not.
>> 
>> Steve




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6J0dmP06047 for ietf-pkix-bks; Thu, 18 Jul 2002 17:39:48 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J0dlw06041 for <[e-mail]>; Thu, 18 Jul 2002 17:39:47 -0700 (PDT)
Received: from salford.ac.uk (dwclaptop.dyn.ietf54.wide.ad.jp [133.93.19.189]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6J0dmJ02049; Fri, 19 Jul 2002 09:39:48 +0900 (JST)
Message-ID: <[e-mail]>
Date: Fri, 19 Jul 2002 01:41:11 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: LDAP ISSUE
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------C8C21A0F0F26FEC8F39DC392"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Sharon

I agree. Servers already know how to map between OIDs and 50 or more
attributes all defined in the X.500 User Schema RFC. But they are only
allowed to map 11 of them in DNs. This is surely silly. All 50+
attribute names should be allowed in DNs

David


> Sharon Boeyen wrote:
> 
> I'd like to see strings for all the attributes PKIX allows for DNs. I
> think the draft currently defines strings for those that are in RFC
> 3280 as "MUST" support but that are not in RFC 2253. It should also
> define strings for the attributes that RFC 3280 says SHOULD be
> supported for DNs that don't appear in RFC 2253 (e.g. title, surname,
> given name, initials, generational qualifier).
> 
> Sharon
> 
> -----Original Message-----
> From: David Chadwick [mailto:[e-mail]]
> Sent: Thursday, July 18, 2002 2:36 AM
> To: PKIX
> Subject: LDAP ISSUE
> 
> There was one LDAP item missed out of the agenda yesterday due to lack
> 
> of time. This concerns the use of user friendly strings in LDAP DNs.
> It
> is not an issue of how DNs are encoded in certificates (as these are
> ASN.1 DER), but rather how DNs are encoded in the LDAP protocol when
> asking to retrieve or store a certificate. LDAP uses user friendly
> strings to refer to attribute types, but can use OIDs if no user
> friendly strings are known. In the case of DNs, a list of 9 attribute
> type user friendly strings are published in RFC 2253 (e.g. C, O, OU
> etc.). The revision of LDAPv3 is currently stating that no further
> strings can be defined for Internet use (earlier versions allowed for
> other strings to be defined e.g. registered with IANA, but no one had
> ever bothered to register any further strings). The PKIX group has
> specified a larger set of attribute types in its Qualified
> Certificates
> profile RFC 3039. In practical terms this means that the applications
> using LDAP APIs will be able to pass user friendly strings for some of
> 
> the attributes but not for others e.g. CN=David Chadwick +
> SerialNumber=12345 would need to be passed to the LDAP API as CN=David
> 
> Chadwick + 2.5.4.5=12345.
> 
> The PKIX draft <draft-ietf-pkix-dnstrings-00.txt> defines strings for
> PKIX used attribute types so that a consistent call can be made to the
> 
> LDAP API. This might be useful for example where users type in DNs at
> the user interface level, or they are read in from configuration
> files.
> Without this change the application will need
> to have a table of which attributes can be sent to LDAP as strings and
> 
> which will need to be sent as OIDs. (You clearly cannot expect user's
> to
> type in OIDs). Some in the LDAP group are opposed to the PKIX group
> publishing
> this ID, as they dont want to possibly open the floodgates to lots of
> other strings being registered.
> 
> So the question that the PKIX group needs to answer is "Do we care or
> not". Silence on the list implies that PKI application providers dont
> really care, as they are happy to pass either a mixture of OIDs and
> user
> friendly strings, or all OIDs (the latter is not ruled out), to their
> LDAP APIs.
> If you think it is important to be able to pass all user friendly
> strings to
> the LDAP API, then please respond now.
> 
> thankyou
> 
> David
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------C8C21A0F0F26FEC8F39DC392
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------C8C21A0F0F26FEC8F39DC392--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6J0bs305983 for ietf-pkix-bks; Thu, 18 Jul 2002 17:37:54 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J0brw05978 for <[e-mail]>; Thu, 18 Jul 2002 17:37:53 -0700 (PDT)
Received: from salford.ac.uk (dwclaptop.dyn.ietf54.wide.ad.jp [133.93.19.189]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6J0bnJ02041; Fri, 19 Jul 2002 09:37:49 +0900 (JST)
Message-ID: <[e-mail]>
Date: Fri, 19 Jul 2002 01:39:13 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: LDAP ISSUE
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------4F9552E2B4626B31E6CE899B"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Dave

Once the keywords are reggistered with IANA, the client wont need to do
the mapping. It can send the keywords in the protocol. It has to do the
mapping now for some of the keywords, and not for others, since only
some of the mappings are known to the server. This is an odd situation
to be in, and burdens the client. Once the keywords are registered, the
clients wont need to know about or use any of the OIDs.

David


"David P. Kemp" wrote:
> 
> Steve,
> 
> That sounds like a presentation issue, and perhaps that's what
> you meant to imply by emphasizing "on the wire".
> 
> Would it not be reasonable for new DN attribute keywords to
> be registered with IANA, and permit newly developed clients
> to translate between keywords (for human consumption)
> and OIDs (on the wire)?
> 
> Dave
> 
> Steve Hanna wrote:
> >
> > Actually, there is a good reason for the position of the LDAP
> > group on this issue.
> >
> > The reason that new keywords for attribute types in X.500 DNs
> > cannot be sent on the wire in LDAP protocol messages is that
> > old LDAP servers won't know what the new keywords mean. For
> > user input and output, new keywords can be added. But you
> > can't expect existing LDAP servers to automagically understand
> > what a new keyword means when they see it on the wire. OIDs
> > are the best way to handle this.
> >
> > Also, this is not a new position. RFC 1779 (for LDAPv2)
> > allowed new keywords and defined an IANA registry. But no
> > new keywords were ever defined. I suspect that people
> > realized the problems that would ensue. RFC 2253 (for LDAPv3)
> > does not allow new keywords. And the revised version of 2253
> > (draft-ietf-ldapbis-dn-07.txt) also does not.
> >
> > Steve

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------4F9552E2B4626B31E6CE899B
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------4F9552E2B4626B31E6CE899B--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6J0Z9b05902 for ietf-pkix-bks; Thu, 18 Jul 2002 17:35:09 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J0Z8w05898 for <[e-mail]>; Thu, 18 Jul 2002 17:35:08 -0700 (PDT)
Received: from salford.ac.uk (dwclaptop.dyn.ietf54.wide.ad.jp [133.93.19.189]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6J0Z8J02036; Fri, 19 Jul 2002 09:35:08 +0900 (JST)
Message-ID: <[e-mail]>
Date: Fri, 19 Jul 2002 01:36:32 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: LDAP ISSUE
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------E7334057200E84EE8B2822B2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Steve Hanna wrote:
> 
> Actually, there is a good reason for the position of the LDAP
> group on this issue.
> 
> The reason that new keywords for attribute types in X.500 DNs
> cannot be sent on the wire in LDAP protocol messages is that
> old LDAP servers won't know what the new keywords mean.

Steve

we have two cases here.
i) a new attribute is defined along with a new string keyword. 
-- this wont cause a problem because the old server wont have any
entries with that name and will return an error message to the client

ii) an old server does have entries with that name but is used to seeing
OIDs in the request, and the clients that go with it also send the OIDs
(they cant do otherwise). Then the string name (which is already defined
anyway and known about, because the client can use it when asking for
the attribute) is defined for use in DNs as well. There will be a
migration problem only if the clients start to use the string keyword
before the server. Therefore once the keyword is defined in an Internet
draft, servers should be configured to start to expect it.


> For
> user input and output, new keywords can be added. But you
> can't expect existing LDAP servers to automagically understand
> what a new keyword means when they see it on the wire. OIDs
> are the best way to handle this.

Actually OIDs are the best alround, and keywords should never have been
defined! But given that they are, we should be consistent in their
application, and not require keywords for some things and OIDs for
others, within the same protocol item (a DN)

> 
> Also, this is not a new position. RFC 1779 (for LDAPv2)
> allowed new keywords and defined an IANA registry. But no
> new keywords were ever defined. I suspect that people
> realized the problems that would ensue. 

No, I think it was because everyone built their DITs using only the
keywords defined. But now PKIX has defined some new attributes for use
in DNs, and therefore the keywords for these should also be supported.

David

>RFC 2253 (for LDAPv3)
> does not allow new keywords. And the revised version of 2253
> (draft-ietf-ldapbis-dn-07.txt) also does not.
> 
> Steve

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------E7334057200E84EE8B2822B2
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------E7334057200E84EE8B2822B2--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6IJ9Y420765 for ietf-pkix-bks; Thu, 18 Jul 2002 12:09:34 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJ9Xw20760 for <[e-mail]>; Thu, 18 Jul 2002 12:09:33 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g6IJ6iN23359; Thu, 18 Jul 2002 15:06:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 18 Jul 2002 15:07:02 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: LDAP ISSUE
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

That sounds like a presentation issue, and perhaps that's what
you meant to imply by emphasizing "on the wire".

Would it not be reasonable for new DN attribute keywords to
be registered with IANA, and permit newly developed clients
to translate between keywords (for human consumption)
and OIDs (on the wire)?

Dave




Steve Hanna wrote:
> 
> Actually, there is a good reason for the position of the LDAP
> group on this issue.
> 
> The reason that new keywords for attribute types in X.500 DNs
> cannot be sent on the wire in LDAP protocol messages is that
> old LDAP servers won't know what the new keywords mean. For
> user input and output, new keywords can be added. But you
> can't expect existing LDAP servers to automagically understand
> what a new keyword means when they see it on the wire. OIDs
> are the best way to handle this.
> 
> Also, this is not a new position. RFC 1779 (for LDAPv2)
> allowed new keywords and defined an IANA registry. But no
> new keywords were ever defined. I suspect that people
> realized the problems that would ensue. RFC 2253 (for LDAPv3)
> does not allow new keywords. And the revised version of 2253
> (draft-ietf-ldapbis-dn-07.txt) also does not.
> 
> Steve


Received: by above.proper.com (8.11.6/8.11.3) id g6IGKa111460 for ietf-pkix-bks; Thu, 18 Jul 2002 09:20:36 -0700 (PDT)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IGKYw11454 for <[e-mail]>; Thu, 18 Jul 2002 09:20:34 -0700 (PDT)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21534 for <[e-mail]>; Thu, 18 Jul 2002 10:20:36 -0600 (MDT)
Received: from sydney.East.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g6IGK3L27689 for <[e-mail]>; Thu, 18 Jul 2002 12:20:26 -0400 (EDT)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 19 Jul 2002 01:21:32 +0-900
To: <[e-mail]>
Reply-To: <[e-mail]>
Subject: Re: LDAP ISSUE
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually, there is a good reason for the position of the LDAP
group on this issue.

The reason that new keywords for attribute types in X.500 DNs
cannot be sent on the wire in LDAP protocol messages is that
old LDAP servers won't know what the new keywords mean. For
user input and output, new keywords can be added. But you
can't expect existing LDAP servers to automagically understand
what a new keyword means when they see it on the wire. OIDs
are the best way to handle this.

Also, this is not a new position. RFC 1779 (for LDAPv2)
allowed new keywords and defined an IANA registry. But no
new keywords were ever defined. I suspect that people
realized the problems that would ensue. RFC 2253 (for LDAPv3)
does not allow new keywords. And the revised version of 2253
(draft-ietf-ldapbis-dn-07.txt) also does not.

Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6IEiAk06145 for ietf-pkix-bks; Thu, 18 Jul 2002 07:44:10 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IEi8w06138 for <[e-mail]>; Thu, 18 Jul 2002 07:44:08 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <38JSLYYQ>; Thu, 18 Jul 2002 10:43:53 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David Chadwick'" <[e-mail]>, PKIX <[e-mail]>
Subject: RE: LDAP ISSUE
Date: Thu, 18 Jul 2002 10:43:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E69.85650870"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C22E69.85650870
Content-Type: text/plain

I'd like to see strings for all the attributes PKIX allows for DNs. I think
the draft currently defines strings for those that are in RFC 3280 as "MUST"
support but that are not in RFC 2253. It should also define strings for the
attributes that RFC 3280 says SHOULD be supported for DNs that don't appear
in RFC 2253 (e.g. title, surname, given name, initials, generational
qualifier). 

Sharon

-----Original Message-----
From: David Chadwick [mailto:[e-mail]]
Sent: Thursday, July 18, 2002 2:36 AM
To: PKIX
Subject: LDAP ISSUE


There was one LDAP item missed out of the agenda yesterday due to lack
of time. This concerns the use of user friendly strings in LDAP DNs. It
is not an issue of how DNs are encoded in certificates (as these are
ASN.1 DER), but rather how DNs are encoded in the LDAP protocol when
asking to retrieve or store a certificate. LDAP uses user friendly
strings to refer to attribute types, but can use OIDs if no user
friendly strings are known. In the case of DNs, a list of 9 attribute
type user friendly strings are published in RFC 2253 (e.g. C, O, OU
etc.). The revision of LDAPv3 is currently stating that no further
strings can be defined for Internet use (earlier versions allowed for
other strings to be defined e.g. registered with IANA, but no one had
ever bothered to register any further strings). The PKIX group has
specified a larger set of attribute types in its Qualified Certificates
profile RFC 3039. In practical terms this means that the applications
using LDAP APIs will be able to pass user friendly strings for some of
the attributes but not for others e.g. CN=David Chadwick +
SerialNumber=12345 would need to be passed to the LDAP API as CN=David
Chadwick + 2.5.4.5=12345.

The PKIX draft <draft-ietf-pkix-dnstrings-00.txt> defines strings for
PKIX used attribute types so that a consistent call can be made to the
LDAP API. This might be useful for example where users type in DNs at
the user interface level, or they are read in from configuration files.
Without this change the application will need
to have a table of which attributes can be sent to LDAP as strings and
which will need to be sent as OIDs. (You clearly cannot expect user's to
type in OIDs). Some in the LDAP group are opposed to the PKIX group
publishing
this ID, as they dont want to possibly open the floodgates to lots of
other strings being registered.

So the question that the PKIX group needs to answer is "Do we care or
not". Silence on the list implies that PKI application providers dont
really care, as they are happy to pass either a mixture of OIDs and user
friendly strings, or all OIDs (the latter is not ruled out), to their
LDAP APIs. 
If you think it is important to be able to pass all user friendly
strings to
the LDAP API, then please respond now.

thankyou

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

------_=_NextPart_001_01C22E69.85650870
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.2653.12">
<TITLE>RE: LDAP ISSUE</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I'd like to see strings for all the attributes PKIX =
allows for DNs. I think the draft currently defines strings for those =
that are in RFC 3280 as &quot;MUST&quot; support but that are not in =
RFC 2253. It should also define strings for the attributes that RFC =
3280 says SHOULD be supported for DNs that don't appear in RFC 2253 =
(e.g. title, surname, given name, initials, generational qualifier). =
</FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David Chadwick [<A =
HREF=3D"mailto:[e-mail]">mailto:d.w.chadwick@salford.a=
c.uk</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, July 18, 2002 2:36 AM</FONT>
<BR><FONT SIZE=3D2>To: PKIX</FONT>
<BR><FONT SIZE=3D2>Subject: LDAP ISSUE</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>There was one LDAP item missed out of the agenda =
yesterday due to lack</FONT>
<BR><FONT SIZE=3D2>of time. This concerns the use of user friendly =
strings in LDAP DNs. It</FONT>
<BR><FONT SIZE=3D2>is not an issue of how DNs are encoded in =
certificates (as these are</FONT>
<BR><FONT SIZE=3D2>ASN.1 DER), but rather how DNs are encoded in the =
LDAP protocol when</FONT>
<BR><FONT SIZE=3D2>asking to retrieve or store a certificate. LDAP uses =
user friendly</FONT>
<BR><FONT SIZE=3D2>strings to refer to attribute types, but can use =
OIDs if no user</FONT>
<BR><FONT SIZE=3D2>friendly strings are known. In the case of DNs, a =
list of 9 attribute</FONT>
<BR><FONT SIZE=3D2>type user friendly strings are published in RFC 2253 =
(e.g. C, O, OU</FONT>
<BR><FONT SIZE=3D2>etc.). The revision of LDAPv3 is currently stating =
that no further</FONT>
<BR><FONT SIZE=3D2>strings can be defined for Internet use (earlier =
versions allowed for</FONT>
<BR><FONT SIZE=3D2>other strings to be defined e.g. registered with =
IANA, but no one had</FONT>
<BR><FONT SIZE=3D2>ever bothered to register any further strings). The =
PKIX group has</FONT>
<BR><FONT SIZE=3D2>specified a larger set of attribute types in its =
Qualified Certificates</FONT>
<BR><FONT SIZE=3D2>profile RFC 3039. In practical terms this means that =
the applications</FONT>
<BR><FONT SIZE=3D2>using LDAP APIs will be able to pass user friendly =
strings for some of</FONT>
<BR><FONT SIZE=3D2>the attributes but not for others e.g. CN=3DDavid =
Chadwick +</FONT>
<BR><FONT SIZE=3D2>SerialNumber=3D12345 would need to be passed to the =
LDAP API as CN=3DDavid</FONT>
<BR><FONT SIZE=3D2>Chadwick + 2.5.4.5=3D12345.</FONT>
</P>

<P><FONT SIZE=3D2>The PKIX draft =
&lt;draft-ietf-pkix-dnstrings-00.txt&gt; defines strings for</FONT>
<BR><FONT SIZE=3D2>PKIX used attribute types so that a consistent call =
can be made to the</FONT>
<BR><FONT SIZE=3D2>LDAP API. This might be useful for example where =
users type in DNs at</FONT>
<BR><FONT SIZE=3D2>the user interface level, or they are read in from =
configuration files.</FONT>
<BR><FONT SIZE=3D2>Without this change the application will need</FONT>
<BR><FONT SIZE=3D2>to have a table of which attributes can be sent to =
LDAP as strings and</FONT>
<BR><FONT SIZE=3D2>which will need to be sent as OIDs. (You clearly =
cannot expect user's to</FONT>
<BR><FONT SIZE=3D2>type in OIDs). Some in the LDAP group are opposed to =
the PKIX group</FONT>
<BR><FONT SIZE=3D2>publishing</FONT>
<BR><FONT SIZE=3D2>this ID, as they dont want to possibly open the =
floodgates to lots of</FONT>
<BR><FONT SIZE=3D2>other strings being registered.</FONT>
</P>

<P><FONT SIZE=3D2>So the question that the PKIX group needs to answer =
is &quot;Do we care or</FONT>
<BR><FONT SIZE=3D2>not&quot;. Silence on the list implies that PKI =
application providers dont</FONT>
<BR><FONT SIZE=3D2>really care, as they are happy to pass either a =
mixture of OIDs and user</FONT>
<BR><FONT SIZE=3D2>friendly strings, or all OIDs (the latter is not =
ruled out), to their</FONT>
<BR><FONT SIZE=3D2>LDAP APIs. </FONT>
<BR><FONT SIZE=3D2>If you think it is important to be able to pass all =
user friendly</FONT>
<BR><FONT SIZE=3D2>strings to</FONT>
<BR><FONT SIZE=3D2>the LDAP API, then please respond now.</FONT>
</P>

<P><FONT SIZE=3D2>thankyou</FONT>
</P>

<P><FONT SIZE=3D2>David</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT =
SIZE=3D2>***************************************************************=
**</FONT>
</P>

<P><FONT SIZE=3D2>David W. Chadwick, BSc PhD</FONT>
<BR><FONT SIZE=3D2>Professor of Information Systems Security</FONT>
<BR><FONT SIZE=3D2>IS Institute, University of Salford, Salford M5 =
4WT</FONT>
<BR><FONT SIZE=3D2>Tel: [phone]&nbsp; Fax [phone] =
532930</FONT>
<BR><FONT SIZE=3D2>Mobile: [phone]</FONT>
<BR><FONT SIZE=3D2>Email: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Home Page:&nbsp; <A =
HREF=3D"http://www.salford.ac.uk/its024/chadwick.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/chadwick.htm</A></FONT=
>
<BR><FONT SIZE=3D2>Research Projects: <A =
HREF=3D"http://sec.isi.salford.ac.uk" =
TARGET=3D"_blank">http://sec.isi.salford.ac.uk</A></FONT>
<BR><FONT SIZE=3D2>Understanding X.500:&nbsp; <A =
HREF=3D"http://www.salford.ac.uk/its024/X500.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/X500.htm</A></FONT>
<BR><FONT SIZE=3D2>X.500/LDAP Seminars: <A =
HREF=3D"http://www.salford.ac.uk/its024/seminars.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/seminars.htm</A></FONT=
>
<BR><FONT SIZE=3D2>Entrust key validation string: MLJ9-DU5T-HV8J</FONT>
<BR><FONT SIZE=3D2>PGP Key ID is 0xBC238DE5</FONT>
</P>

<P><FONT =
SIZE=3D2>***************************************************************=
**</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C22E69.85650870--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6IBUNN26616 for ietf-pkix-bks; Thu, 18 Jul 2002 04:30:23 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IBULw26611 for <[e-mail]>; Thu, 18 Jul 2002 04:30:21 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6IBUGg5165356; Thu, 18 Jul 2002 07:30:16 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g6IBUEx55902; Thu, 18 Jul 2002 07:30:14 -0400
Importance: Normal
Sensitivity: 
Subject: Re: LDAP ISSUE
To: David Chadwick <[e-mail]>
Cc: PKIX <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 18 Jul 2002 07:30:07 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 07/18/2002 07:30:15 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      IMHO this is fairly important.  I think that both the standardization
of names for further attributes beyond those mentioned in RFC 2253 section
2.3, both ITU terms such as serialNumber and attributes from other
standards groups such as rfc822Mailbox, is important and has no real
disadvantages.  I also believe that permitting installations to define
their own user-friendly attribute names and have them mapped at the server
rather  than in each client is desirable, but this opinion is less strongly
held because of the possible confusion which could result if different
servers defined the same abbreviation for attributes with different syntax
or semantics.  The use of the abbreviation MAIL for rfc822Mailbox, BTW, is
an example of the mapping at the server.

            Tom Gindin

David Chadwick <[e-mail]>@mail.imc.org on 07/18/2002
02:36:20 AM

Sent by:    [e-mail]


To:    PKIX <[e-mail]>
cc:
Subject:    LDAP ISSUE



There was one LDAP item missed out of the agenda yesterday due to lack
of time. This concerns the use of user friendly strings in LDAP DNs. It
is not an issue of how DNs are encoded in certificates (as these are
ASN.1 DER), but rather how DNs are encoded in the LDAP protocol when
asking to retrieve or store a certificate. LDAP uses user friendly
strings to refer to attribute types, but can use OIDs if no user
friendly strings are known. In the case of DNs, a list of 9 attribute
type user friendly strings are published in RFC 2253 (e.g. C, O, OU
etc.). The revision of LDAPv3 is currently stating that no further
strings can be defined for Internet use (earlier versions allowed for
other strings to be defined e.g. registered with IANA, but no one had
ever bothered to register any further strings). The PKIX group has
specified a larger set of attribute types in its Qualified Certificates
profile RFC 3039. In practical terms this means that the applications
using LDAP APIs will be able to pass user friendly strings for some of
the attributes but not for others e.g. CN=David Chadwick +
SerialNumber=12345 would need to be passed to the LDAP API as CN=David
Chadwick + 2.5.4.5=12345.

The PKIX draft <draft-ietf-pkix-dnstrings-00.txt> defines strings for
PKIX used attribute types so that a consistent call can be made to the
LDAP API. This might be useful for example where users type in DNs at
the user interface level, or they are read in from configuration files.
Without this change the application will need
to have a table of which attributes can be sent to LDAP as strings and
which will need to be sent as OIDs. (You clearly cannot expect user's to
type in OIDs). Some in the LDAP group are opposed to the PKIX group
publishing
this ID, as they dont want to possibly open the floodgates to lots of
other strings being registered.

So the question that the PKIX group needs to answer is "Do we care or
not". Silence on the list implies that PKI application providers dont
really care, as they are happy to pass either a mixture of OIDs and user
friendly strings, or all OIDs (the latter is not ruled out), to their
LDAP APIs.
If you think it is important to be able to pass all user friendly
strings to
the LDAP API, then please respond now.

thankyou

David

--
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6IB3qo24321 for ietf-pkix-bks; Thu, 18 Jul 2002 04:03:52 -0700 (PDT)
Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IB3iw24295 for <[e-mail]>; Thu, 18 Jul 2002 04:03:50 -0700 (PDT)
Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.2) with SMTP id g6IB3cM17004 for <[e-mail]>; Thu, 18 Jul 2002 14:03:38 +0300 (EEST)
Received: (qmail 25575 invoked from network); 18 Jul 2002 11:03:38 -0000
Received: from unknown (HELO schubert) ([10.1.0.48]) (envelope-sender <[e-mail]>) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 18 Jul 2002 11:03:38 -0000
From: "Vesa Suontama" <[e-mail]>
To: <[e-mail]>
Subject: Re: LDAP ISSUE
Date: Thu, 18 Jul 2002 14:05:35 +0300
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 V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Good point!

I think we SHOLD assign each attribute a well defined friendly name.

If we do not have well defined names for OIDs, some directory vendors will
(and have already) come up with the friendly names of their own. E.g. is
email address in DN "E" or "EMAIL"?

I would love to see a simpe rfc (rfc2253bis?) with more oids associated with
friendly names.

Vesa

"David Chadwick" <[e-mail]> wrote in message
news:<[e-mail]>...
>
> This is a multi-part message in MIME format.
> --------------EA72FAF40C88E4BE16EA66C8
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> There was one LDAP item missed out of the agenda yesterday due to lack
> of time. This concerns the use of user friendly strings in LDAP DNs. It
> is not an issue of how DNs are encoded in certificates (as these are
> ASN.1 DER), but rather how DNs are encoded in the LDAP protocol when
> asking to retrieve or store a certificate. LDAP uses user friendly
> strings to refer to attribute types, but can use OIDs if no user
> friendly strings are known. In the case of DNs, a list of 9 attribute
> type user friendly strings are published in RFC 2253 (e.g. C, O, OU
> etc.). The revision of LDAPv3 is currently stating that no further
> strings can be defined for Internet use (earlier versions allowed for
> other strings to be defined e.g. registered with IANA, but no one had
> ever bothered to register any further strings). The PKIX group has
> specified a larger set of attribute types in its Qualified Certificates
> profile RFC 3039. In practical terms this means that the applications
> using LDAP APIs will be able to pass user friendly strings for some of
> the attributes but not for others e.g. CN=David Chadwick +
> SerialNumber=12345 would need to be passed to the LDAP API as CN=David
> Chadwick + 2.5.4.5=12345.
>
> The PKIX draft <draft-ietf-pkix-dnstrings-00.txt> defines strings for
> PKIX used attribute types so that a consistent call can be made to the
> LDAP API. This might be useful for example where users type in DNs at
> the user interface level, or they are read in from configuration files.
> Without this change the application will need
> to have a table of which attributes can be sent to LDAP as strings and
> which will need to be sent as OIDs. (You clearly cannot expect user's to
> type in OIDs). Some in the LDAP group are opposed to the PKIX group
> publishing
> this ID, as they dont want to possibly open the floodgates to lots of
> other strings being registered.
>
> So the question that the PKIX group needs to answer is "Do we care or
> not". Silence on the list implies that PKI application providers dont
> really care, as they are happy to pass either a mixture of OIDs and user
> friendly strings, or all OIDs (the latter is not ruled out), to their
> LDAP APIs.
> If you think it is important to be able to pass all user friendly
> strings to
> the LDAP API, then please respond now.
>
> thankyou
>
> David
>
> --
> *****************************************************************
>
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************
> --------------EA72FAF40C88E4BE16EA66C8
> Content-Type: text/x-vcard; charset=us-ascii;
>  name="d.w.chadwick.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for David Chadwick
> Content-Disposition: attachment;
>  filename="d.w.chadwick.vcf"
>
> begin:vcard
> n:Chadwick;David
> tel;cell:[phone]
> tel;fax:[phone]
> tel;home:[phone]
> tel;work:[phone]
> x-mozilla-html:FALSE
> url:http://www.salford.ac.uk/its024/chadwick.htm
> org:University of Salford;IS Institute
> version:2.1
> email;internet:[e-mail]
> title:Professor of Information Security
> adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5
4WT;England
> note;quoted-printable:Research Projects:
http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding
X.500:  http://www.salford.ac.uk/its024/X500.htm
.......................=0D=0A=0D=0AX.500/LDAP Seminars:
http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AE
ntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key
ID is 0xBC238DE5
> x-mozilla-cpt:;-4856
> fn:David Chadwick
> end:vcard
>
> --------------EA72FAF40C88E4BE16EA66C8--
>



Received: by above.proper.com (8.11.6/8.11.3) id g6I9XXl16778 for ietf-pkix-bks; Thu, 18 Jul 2002 02:33:33 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I9XWw16774 for <[e-mail]>; Thu, 18 Jul 2002 02:33:32 -0700 (PDT)
Received: from salford.ac.uk (dwclaptop.dyn.ietf54.wide.ad.jp [133.93.19.189]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6I9XWu17326 for <[e-mail]>; Thu, 18 Jul 2002 18:33:32 +0900 (JST)
Message-ID: <[e-mail]>
Date: Thu, 18 Jul 2002 10:34:55 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: X.509 PMI Research
Content-Type: multipart/mixed; boundary="------------319C28251EA8F03A9E110D25"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Sorry to send this semi-spam to the list.

I have a fully funded 3 year PhD studentship to work with me on
Delegation of Authority in X.509 PMIs.  One restriction with the grant
is that it is only available to an EC national, but if anyone who
qualifies is interested, or knows anyone who is interested, can they
please contact me directly so as to not take up any further list time
with this topic

thankyou

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------319C28251EA8F03A9E110D25
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------319C28251EA8F03A9E110D25--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6I6Z1o21046 for ietf-pkix-bks; Wed, 17 Jul 2002 23:35:01 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I6Yxw21035 for <[e-mail]>; Wed, 17 Jul 2002 23:34:59 -0700 (PDT)
Received: from salford.ac.uk (dwclaptop.dyn.ietf54.wide.ad.jp [133.93.19.189]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6I6Ywu16869 for <[e-mail]>; Thu, 18 Jul 2002 15:34:58 +0900 (JST)
Message-ID: <[e-mail]>
Date: Thu, 18 Jul 2002 07:36:20 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: LDAP ISSUE
Content-Type: multipart/mixed; boundary="------------EA72FAF40C88E4BE16EA66C8"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

There was one LDAP item missed out of the agenda yesterday due to lack
of time. This concerns the use of user friendly strings in LDAP DNs. It
is not an issue of how DNs are encoded in certificates (as these are
ASN.1 DER), but rather how DNs are encoded in the LDAP protocol when
asking to retrieve or store a certificate. LDAP uses user friendly
strings to refer to attribute types, but can use OIDs if no user
friendly strings are known. In the case of DNs, a list of 9 attribute
type user friendly strings are published in RFC 2253 (e.g. C, O, OU
etc.). The revision of LDAPv3 is currently stating that no further
strings can be defined for Internet use (earlier versions allowed for
other strings to be defined e.g. registered with IANA, but no one had
ever bothered to register any further strings). The PKIX group has
specified a larger set of attribute types in its Qualified Certificates
profile RFC 3039. In practical terms this means that the applications
using LDAP APIs will be able to pass user friendly strings for some of
the attributes but not for others e.g. CN=David Chadwick +
SerialNumber=12345 would need to be passed to the LDAP API as CN=David
Chadwick + 2.5.4.5=12345.

The PKIX draft <draft-ietf-pkix-dnstrings-00.txt> defines strings for
PKIX used attribute types so that a consistent call can be made to the
LDAP API. This might be useful for example where users type in DNs at
the user interface level, or they are read in from configuration files.
Without this change the application will need
to have a table of which attributes can be sent to LDAP as strings and
which will need to be sent as OIDs. (You clearly cannot expect user's to
type in OIDs). Some in the LDAP group are opposed to the PKIX group
publishing
this ID, as they dont want to possibly open the floodgates to lots of
other strings being registered.

So the question that the PKIX group needs to answer is "Do we care or
not". Silence on the list implies that PKI application providers dont
really care, as they are happy to pass either a mixture of OIDs and user
friendly strings, or all OIDs (the latter is not ruled out), to their
LDAP APIs. 
If you think it is important to be able to pass all user friendly
strings to
the LDAP API, then please respond now.

thankyou

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------EA72FAF40C88E4BE16EA66C8
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------EA72FAF40C88E4BE16EA66C8--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6I0udL06555 for ietf-pkix-bks; Wed, 17 Jul 2002 17:56:39 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I0uMw06544 for <[e-mail]>; Wed, 17 Jul 2002 17:56:37 -0700 (PDT)
Received: from [133.93.73.143] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15855 for <[e-mail]>; Wed, 17 Jul 2002 20:57:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1 (Unverified)
Message-Id: <p05100302b95bb9455978@[128.89.89.100]>
Date: Wed, 17 Jul 2002 20:18:51 -0400
To: Pkix <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: draft minutes
Content-Type: multipart/alternative; boundary="============_-1185168705==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1185168705==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

=46olks,

Below is the draft version of the meeting minutes for yesterday's PKIX meeti=
ng.

Please respond with comments and corrections, by 8/3.

Thanks,

Steve
------

PKIX WG Meeting 7/17/02

Edited by Steve Kent

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

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


Tim Polk began with a review of the agenda and document status.
	NIST will develop an interoperability test plan for RFC 3279 
&b 3280, and submit to WG for review. Note 3 documents have now 
achieved RFC status. DPV/DPD requirements document in IESG last call. 
Roadmap, OCSP(v1)bis and PI documents in IESG queue. 2527bis ready 
now. CMP and CRMF have been awaiting documentation of test results 
for progression to Draft, but we will publish and cycle at Proposed. 
We still have 19 active IDs, which is a lot, but an improvement! [see 
slides]

Certificate Validation Protocol - Denis Pinkas (Bull)
	A candidate for meeting the DPV (but not DPD) requirements. 
User specifies validation policy to control path validation by a 
serverf if no policy specified, server employs local default, and 
notifies user of the policy (by OID). Allows user control over type 
of revocation checking to be done, time stamping of returned data, 
etc. Option for user to provide additional certificates and 
revocation status data. Optional requestor ID. Extensions permitted, 
e.g., to support inter-server use as well as client/server support. 
=46acilities are included to support NR use, but do not burden non-NR 
use. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-00.txt

SCVP Protocol - Ambarish Malpani (ValiCert)
Update on SCVP, changes to meet newly adopted requirements document. 
Uses CMS as basis. SCVP supports both DPD and DPV. Changes include 
references to policy by OID, references to certificates as 
alternative to sending certificates, client identifier added, query 
for client to discover policies supported by server, etc. [see 
slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-08.txt

Tim urges WG to begin examining protocols in detail. Other candidates 
(e.g., OCSPv2) should republish with any changes needed to meet 
requirements we have adopted. Hope is to make a decision before 
Atlanta IETF meeting, this fall.

Wireless LAN Certificate Extensions - Russ Housley (RSA Security)
IEEE 802.1X is looking at use of EAP-TLS for authentication in 
wireless LANs. Need extensions to support this application, when a 
user accesses different WLANs, e.g., home vs. work vs. airport, =8A. 
Proposal defines EKU values for EAP/PPP and EAP/WLAN applications. 
Want to automate selection of the right certificate for different 
access points. Each WLAN has one or more service set identifiers 
(SSIDs). Put a list of SSIDs into a certificate as an extension, to 
identify the WLAN. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

Certificate Warranty Extension - Russ Housley (RSA Security) for Spyrus
	Extension provides explicit data about warranties provided by 
the CA, including an explicit declaration of no warranty. It's a 
non-critical extension; NULL used to express no warranty, and there 
are provisions for extended warranty data too. Option to point to 
warranty data via URL. All of this can be gleaned from CP or CPS, but 
goal here is to make it easy for a machine to process. Subtle issues 
need to be discussed about why it is appropriate to use this 
extension, vs. using a policy extension with a specific policy and 
policy qualifiers to express monetary values. We have to be careful 
to not start a trend in creating a separate extension for each type 
of data that might appear in a CP/CPS and which might benefit from 
automated processing. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

Attribute Certificate Policies Extension - Denis Pinkas (Bull)
Two extensions, one provides policy info re an attribute certificate 
and one for locating the AA certificate. First extension copies 
policy extension from PK certificates (but gets new OID because of 
wording issues), uses policy qualifiers to express freshness of the 
attribute certificate. Second extension is a URL, and is marked to 
indicate whether the repository is public or private. Discussion 
about need for freshness info, possible separation of second 
extension as it is more general than this AC context, and the need to 
include policy info explicitly in the AC. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt

RFC 3161bis - Denis Pinkas (Bull)
  	Want to move to Draft, but need real interoperability tests 
to move forward. Will publish a matrix of tests to guide testers. 
Various minor changes to the document reviewed. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-00.txt

Policy requirements for TSAs - Denis Pinkas (Bull)
	This document is derived from work in ETSI. Changes to 
terminology to align with 3161bis. This is targeted as an 
Informational RFC, with ETSI maintaining change control. Question is 
raised about whether we need a more generic policy requirements 
document for a wide range of PKI servers, e.g., CAs, AAs, TSAs, OCSP 
servers, DPD/DPV servers, etc. Hope is to reuse text in future policy 
documents. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-01.txt

PKIX Permanent Identifiers - Denis Pinkas (Bull)
	Document is with the IESG. Discussion of matching rule 
features. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt

Logotypes in X.509 Certificates - Stefan Santesson (AddTrust)
	Document now in third draft, and a fourth draft will be 
issued soon. Now can display logos at different resolutions, B+W vs. 
color, audio for vision impaired, language-specific logo selection, 
direct inclusion and indirect reference, etc. Three basic types of 
logos (community, issuer, client), plus loyalty, =8A. [see slides] 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-03.txt

LDAPv3 Issues Relevant to PKIX - David Chadwick (Univ. of Salford)
	There was a change from LDAPv2 to LDAPv3 which affects how 
certificates and related PKI data structures are stored. LDAPv3 added 
";binary" as a means of specifying transfer syntax for these objects, 
which should be transferred in BER form. Now, however, the LDAPv3 WG 
has decided to remove support for ;binary (which was optional), in an 
effort to progress to Draft, avoiding other problems associated with 
generic use of this feature. Plan is to reintroduce ;binary as an 
extension in the future, once the problems that caused it to be 
removed is resolved. PKIX WG members are requested to respond on the 
list, noting whether clients and servers make use of ;binary when 
interacting with LDAPv3 directories. An LDAPv3 schema has been 
defined for data items relevant to PKIX, to address this issue in the 
long run, and OpenLDAP supports this schema.

"Specification Problem around Multi PKI domain Experience in 
Challenge PKI 2001"
  - Ryu Inada (Japan Network Security Association)
	This is a report on the interoperability testing activities 
in Japan, not a PKIX activity. Test environment involved root CAs and 
9 subordinate CAs, a cross-certification model, and a bridge CA model 
representative of the Japanese government PKI. Applications included 
SSL, TLS, and S/MIME. Testing uncovered several areas that required 
clarification, in path validation and policy mapping. Also uncovered 
a number of CA non-compliance problems, e.g., mis-encoding of key 
usage, basic constraints in EE certificates, bad combinations of 
flags in key usage, etc. They hope to feedback results of tests in 
multi-domain PKIs to clarify the RFC 3280 issues. [see slides]
--============_-1185168705==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>draft minutes</title></head><body>
<div>Folks,</div>
<div><br></div>
<div>Below is the draft version of the meeting minutes for yesterday's
PKIX meeting.</div>
<div><br></div>
<div>Please respond with comments and corrections, by 8/3.</div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Steve</div>
<div>------</div>
<div><br></div>
<div><font face=3D"Courier" size=3D"+2" color=3D"#000000">PKIX WG Meeting
7/17/02<br>
<br>
Edited by Steve Kent<br>
<br>
Chairs: Stephen Kent &lt;[e-mail]&gt;, Tim Polk
&lt;[e-mail]&gt;</font><br>
<font face=3D"Courier" size=3D"+2" color=3D"#000000"></font></div>
<div><font face=3D"Courier" size=3D"+2" color=3D"#000000">The PKIX WG met
once during the 53rd IETF. A total of approximately 185 individuals
participated in the meeting.<br>
<br>
<br>
Tim Polk began with a review of the agenda and document status.<br>
<x-tab> </x-tab>NIST will develop an interoperability test plan for
RFC 3279 &amp;b 3280, and submit to WG for review. Note 3 documents
have now achieved RFC status. DPV/DPD requirements document in IESG
last call. Roadmap, OCSP(v1)bis and PI documents in IESG queue.
2527bis ready now. CMP and CRMF have been awaiting documentation of
test results for progression to Draft, but we will publish and cycle
at Proposed. We still have 19 active IDs, which is a lot, but an
improvement! [see slides]<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab><br>
Certificate Validation Protocol - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp; </x-tab>A candidate for meeting the DPV (but not
DPD) requirements. User specifies validation policy to control path
validation by a serverf if no policy specified, server employs local
default, and notifies user of the policy (by OID). Allows user control
over type of revocation checking to be done, time stamping of returned
data, etc. Option for user to provide additional certificates and
revocation status data. Optional requestor ID. Extensions permitted,
e.g., to support inter-server use as well as client/server support.
=46acilities are included to support NR use, but do not burden non-NR
use. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-00.txt<br>
<br>
SCVP Protocol - Ambarish Malpani (ValiCert)<br>
Update on SCVP, changes to meet newly adopted requirements document.
Uses CMS as basis. SCVP supports both DPD and DPV. Changes include
references to policy by OID, references to certificates as alternative
to sending certificates, client identifier added, query for client to
discover policies supported by server, etc. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-08.txt<br>
<br>
Tim urges WG to begin examining protocols in detail. Other candidates
(e.g., OCSPv2) should republish with any changes needed to meet
requirements we have adopted. Hope is to make a decision before
Atlanta IETF meeting, this fall.<br>
<br>
Wireless LAN Certificate Extensions - Russ Housley (RSA Security)<br>
IEEE 802.1X is looking at use of EAP-TLS for authentication in
wireless LANs. Need extensions to support this application, when a
user accesses different WLANs, e.g., home vs. work vs. airport, =8A.
Proposal defines EKU values for EAP/PPP and EAP/WLAN applications.
Want to automate selection of the right certificate for different
access points. Each WLAN has one or more service set identifiers
(SSIDs). Put a list of SSIDs into a certificate as an extension, to
identify the WLAN. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt<br
>
<br>
Certificate Warranty Extension - Russ Housley (RSA Security) for
Spyrus<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Extension provides
explicit data about warranties provided by the CA, including an
explicit declaration of no warranty. It's a non-critical extension;
NULL used to express no warranty, and there are provisions for
extended warranty data too. Option to point to warranty data via URL.
All of this can be gleaned from CP or CPS, but goal here is to make it
easy for a machine to process. Subtle issues need to be discussed
about why it is appropriate to use this extension, vs. using a policy
extension with a specific policy and policy qualifiers to express
monetary values. We have to be careful to not start a trend in
creating a separate extension for each type of data that might appear
in a CP/CPS and which might benefit from automated processing. [see
slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt<br
>
<br>
Attribute Certificate Policies Extension - Denis Pinkas (Bull)<br>
Two extensions, one provides policy info re an attribute certificate
and one for locating the AA certificate. First extension copies policy
extension from PK certificates (but gets new OID because of wording
issues), uses policy qualifiers to express freshness of the attribute
certificate. Second extension is a URL, and is marked to indicate
whether the repository is public or private. Discussion about need for
freshness info, possible separation of second extension as it is more
general than this AC context, and the need to include policy info
explicitly in the AC. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-0<span
></span>0.txt</font></div>
<div><font face=3D"Courier" size=3D"+2" color=3D"#000000"><br>
RFC 3161bis - Denis Pinkas (Bull)<br>
&nbsp;<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Want to move to
Draft, but need real interoperability tests to move forward. Will
publish a matrix of tests to guide testers. Various minor changes to
the document reviewed. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-00.txt<br
>
<br>
Policy requirements for TSAs - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>This document is derived
from work in ETSI. Changes to terminology to align with 3161bis. This
is targeted as an Informational RFC, with ETSI maintaining change
control. Question is raised about whether we need a more generic
policy requirements document for a wide range of PKI servers, e.g.,
CAs, AAs, TSAs, OCSP servers, DPD/DPV servers, etc. Hope is to reuse
text in future policy documents. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-01.txt<br>
<br>
PKIX Permanent Identifiers - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Document is with the
IESG. Discussion of matching rule features. [see slides]
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt<x-tab
>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab><br>
<br>
Logotypes in X.509 Certificates - Stefan Santesson (AddTrust)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Document now in third draft, and a fourth
draft will be issued soon. Now can display logos at different
resolutions, B+W vs. color, audio for vision impaired,
language-specific logo selection, direct inclusion and indirect
reference, etc. Three basic types of logos (community, issuer,
client), plus loyalty, =8A. [see slides]<u>
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-03.txt<br
>
<br>
</u>LDAPv3 Issues Relevant to PKIX - David Chadwick (Univ. of
Salford)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>There was a change from LDAPv2
to LDAPv3 which affects how certificates and related PKI data
structures are stored. LDAPv3 added ";binary" as a means of
specifying transfer syntax for these objects, which should be
transferred in BER form. Now, however, the LDAPv3 WG has decided to
remove support for ;binary (which was optional), in an effort to
progress to Draft, avoiding other problems associated with generic use
of this feature. Plan is to reintroduce ;binary as an extension in the
future, once the problems that caused it to be removed is resolved.
PKIX WG members are requested to respond on the list, noting whether
clients and servers make use of ;binary when interacting with LDAPv3
directories. An LDAPv3 schema has been defined for data items relevant
to PKIX, to address this issue in the long run, and OpenLDAP supports
this schema.<br>
<br>
&quot;Specification Problem around Multi PKI domain Experience in
Challenge PKI 2001&quot;<br>
&nbsp;- Ryu Inada (Japan Network Security Association)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>This is a report on the
interoperability testing activities in Japan, not a PKIX activity.
Test environment involved root CAs and 9 subordinate CAs, a
cross-certification model, and a bridge CA model representative of the
Japanese government PKI. Applications included SSL, TLS, and S/MIME.
Testing uncovered several areas that required clarification, in path
validation and policy mapping. Also uncovered a number of CA
non-compliance problems, e.g., mis-encoding of key usage, basic
constraints in EE certificates, bad combinations of flags in key
usage, etc. They hope to feedback results of tests in multi-domain
PKIs to clarify the RFC 3280 issues. [see slides]</font></div>
</body>
</html>
--============_-1185168705==_ma============--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6HLTqx00149 for ietf-pkix-bks; Wed, 17 Jul 2002 14:29:52 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6HLTow00144 for <[e-mail]>; Wed, 17 Jul 2002 14:29:50 -0700 (PDT)
Received: from arport (h133n2fls31o1122.telia.com [212.181.142.133]) by maila.telia.com (8.12.5/8.12.5) with SMTP id g6HLTage003832; Wed, 17 Jul 2002 23:29:36 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <015c01c22de0$c9f05410$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Williams" <[e-mail]>, "'Stephen Kent '" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Deciding on how to proceed with DPD/DPV  Was: WG Last Call CL OSED: DPD/DPV Requirements
Date: Thu, 18 Jul 2002 00:24:54 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

>We have to be balanced.

I don't exactly know how to interpret this statement but let
me rephrase the issues.  I have neither said that DPD/DPV
is a bad design, nor that it does not address valid issues.
On the contrary I think such systems will popularize PKI.

So which are the current problems?

- OCSP is out there and so is XKMS

- Due to the "Web Services" craze, the need for DP* is *now*,
  not 24 months ahead, as a friendly off-list supporter of my
  request-for-action just wrote. XKMS may fill that purpose.

- Being a member/spy of competing standards-bodies, I feel that
  the presumed need for a particular IETF-flavored DP* is not
  justified, particularly not if there already is a working solution,
  sanctioned by major players, that you can  without cost get the
  specification for, like: http://www.w3.org/TR/xkms
  In the case of XML, there is an ocean of free Java-software as
  well, so you could be running XKMS in hours if you really want.

Maybe my suggestion to take a bold decision in some direction
is asking for a little bit too much.  OTOH I think that just "forgetting"
a "draft in despair" and let it silently disappear in obscurity, mainly
to avoid tricky decisions, is a rather inefficient way of moving things
forward.

But insisting that the DPD/DPV-promoters should clarify the need
for DPD/DPV in the light of XKMS, is though not asking for too much,
as this question will pop-up anyway when DPD/DPV is to be supported
by a vendor, or deployed by a customer.  We'd better come up with
some good answers now!

BTW, shutting down projects is unfortunately something most
people have experienced in some way, and why should standards-
efforts be different from other projects, if something unexpected
happens on the way?

I believe that I'd better cease my part in this issue for now, and can
only hope that others, including the authors take the opportunity to offer
their views on this matter in concrete, pragmatic, project-like terms. 

Regards
Anders Rundgren

>DPV/DPD will not suddenly break through a notional barrier
>that holds back adoption of digital signatures: we have
>PEM+ out there in practice, in the midst of Microsoft 2000
>and Microsoft Office XP, and despite the excellence of
>that offering, subscriber reaction is luke warm.

>I'm personally at the crux of my own Phd work, which asserts 
>that what we lack is, actually, a means of limiting certain effects
>that our signature mechanisms now provide - for the lack of
>such limiting function is a major cause of user failure to 
>now adopt our abundant technology.

>I dont happen to focus in my research work on DPV, but I do recognise
>that DPV represents within IETF the best means to accomplishing
>a more refined notion of trust (via certs), as a DPV service will 
>enable a highly subjective evaluation of cert paths - a feature that 
>may overcome user reluctance to actually go out, multiply,
>and even use digital signatures.

>Peter.


-----Original Message-----
From: Stephen Kent
To: Anders Rundgren
Cc: [e-mail]
Sent: 7/17/02 2:04 AM
Subject: Re: Deciding on how to proceed with DPD/DPV  Was: WG Last Call
CLOSED: DPD/DPV Requirements


At 11:20 AM +0200 7/17/02, Anders Rundgren wrote:
>Thanx Steve,
>
>Your phrase "the rest of us" indicates that I am the only PKIX'er who
have
>doubts regarding the validity of the DPD/DPV-effort.  I won't argue
with that
>as I have no proofs for the opposite, but rather base my view on
information
>gathered from other communities, drafts etc.   But please continue
reading...
>
>Long-term suggestion
>------------------------
>A problem with the e-mail-list approach including "rough consensus",
>is that most people are rather timid, and do not particularly enjoy
getting
>publicly bashed.  Due to this fact, I believe it could be of some value
to
>add a voting-system to the IETF-mailing lists, where a list-member
could
>send a vote on a certain topic without being exposed on the list.  Then
an
>admittedly sensitive topic like "Should we continue the DPD/DPV
effort",
>could be voted on, and you would not only get a ratio of Yes and Noes,
>but also a clear indication on how many who cares about a subject at
all.
>The suggested purpose of this would in no way be changing anything in
the
>IETF-process rules, but to gather additional input to critical
decisions.
>

Again, thanks for your suggestions on how to improve IETF processes. 
They will certainly receive due consideration.

Since we have at least 3, and maybe 4, proposals for protocols to 
satisfy the DPV/DPD requirements, I have complete confidence that 
there is a sufficient support for continuing the work in PKIX. If it 
were of no interest, we would have one proposed protocol, at best. As 
before, if you or others, feel that this is not a good use of your 
time, then you are free to ignore the activity.

Steve



Received: by above.proper.com (8.11.6/8.11.3) id g6HHVeX16128 for ietf-pkix-bks; Wed, 17 Jul 2002 10:31:40 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6HHVdw16124 for <[e-mail]>; Wed, 17 Jul 2002 10:31:39 -0700 (PDT)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10137 for <[e-mail]>; Wed, 17 Jul 2002 11:31:41 -0600 (MDT)
Received: from sunlabs.east.sun.com (sunlabs [129.148.75.250]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id g6HHVeL00167 for <[e-mail]>; Wed, 17 Jul 2002 13:31:40 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 17 Jul 2002 13:31:37 -0400 (EDT)
From: Anne Anderson <[e-mail]>
To: <[e-mail]>
Subject: Encoding of GeneralName choice directoryName
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid
Reply-To: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

None of the examples in RFC3280 includes a "directoryName" choice
from a GeneralName.  This particular type is of interest because
it is the only type in the GeneralName CHOICE that is itself a
CHOICE.  This means that a special clause in X.680 Section 30.6
applies: explicit tagging is used to encode a choice type, even
if the TagDefault is IMPLICIT TAGS.

Is the following correct:

A Name of "cn=Anne" has the following encoded form:
            
        [SEQUENCE] <length>
            [SET] <length>
                [SEQUENCE] <length>
                   [OBJECT IDENTIFIER] <length>
                       2.5.4.3
                   [PrintableString] <length>
                       'Anne'

so the encoding of directoryName with a value of that Name has
the following form:

      [4] <length>
        [SEQUENCE] <length>
            [SET] <length>
                [SEQUENCE] <length>
                   [OBJECT IDENTIFIER] <length>
                       2.5.4.3
                   [PrintableString] <length>
                       'Anne'

The examples in RFC3280 include GeneralName choices for URLs and
RFC822 e-mail names, and those encodings indeed are done with
IMPLICIT encoding.

Anne Anderson
-- 
Anne H. Anderson             Email: [e-mail]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6HGFs912433 for ietf-pkix-bks; Wed, 17 Jul 2002 09:15:54 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6HGFqw12425 for <[e-mail]>; Wed, 17 Jul 2002 09:15:52 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 17 Jul 2002 09:08:22 -0700 (PDT)
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, 17 Jul 2002 09:08:22 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <MV9MJFPR>; Wed, 17 Jul 2002 09:15:47 -0700
Content-return: allowed
Date: Wed, 17 Jul 2002 09:15:45 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Deciding on how to proceed with DPD/DPV  Was: WG Last Call CL OSED: DPD/DPV Requirements
To: "'Stephen Kent '" <[e-mail]>, "'Anders Rundgren '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We have to be balanced.

DPV/DPD will not suddenly break through a notional barrier
that holds back adoption of digital signatures: we have
PEM+ out there in practice, in the midst of Microsoft 2000
and Microsoft Office XP, and despite the excellence of
that offering, subscriber reaction is luke warm.

I'm personally at the crux of my own Phd work, which asserts 
that what we lack is, actually, a means of limiting certain effects
that our signature mechanisms now provide - for the lack of
such limiting function is a major cause of user failure to 
now adopt our abundant technology.

I dont happen to focus in my research work on DPV, but I do recognise
that DPV represents within IETF the best means to accomplishing
a more refined notion of trust (via certs), as a DPV service will 
enable a highly subjective evaluation of cert paths - a feature that 
may overcome user reluctance to actually go out, multiply,
and even use digital signatures.

Peter.


-----Original Message-----
From: Stephen Kent
To: Anders Rundgren
Cc: [e-mail]
Sent: 7/17/02 2:04 AM
Subject: Re: Deciding on how to proceed with DPD/DPV  Was: WG Last Call
CLOSED: DPD/DPV Requirements


At 11:20 AM +0200 7/17/02, Anders Rundgren wrote:
>Thanx Steve,
>
>Your phrase "the rest of us" indicates that I am the only PKIX'er who
have
>doubts regarding the validity of the DPD/DPV-effort.  I won't argue
with that
>as I have no proofs for the opposite, but rather base my view on
information
>gathered from other communities, drafts etc.   But please continue
reading...
>
>Long-term suggestion
>------------------------
>A problem with the e-mail-list approach including "rough consensus",
>is that most people are rather timid, and do not particularly enjoy
getting
>publicly bashed.  Due to this fact, I believe it could be of some value
to
>add a voting-system to the IETF-mailing lists, where a list-member
could
>send a vote on a certain topic without being exposed on the list.  Then
an
>admittedly sensitive topic like "Should we continue the DPD/DPV
effort",
>could be voted on, and you would not only get a ratio of Yes and Noes,
>but also a clear indication on how many who cares about a subject at
all.
>The suggested purpose of this would in no way be changing anything in
the
>IETF-process rules, but to gather additional input to critical
decisions.
>

Again, thanks for your suggestions on how to improve IETF processes. 
They will certainly receive due consideration.

Since we have at least 3, and maybe 4, proposals for protocols to 
satisfy the DPV/DPD requirements, I have complete confidence that 
there is a sufficient support for continuing the work in PKIX. If it 
were of no interest, we would have one proposed protocol, at best. As 
before, if you or others, feel that this is not a good use of your 
time, then you are free to ignore the activity.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H952r16945 for ietf-pkix-bks; Wed, 17 Jul 2002 02:05:02 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H950w16941 for <[e-mail]>; Wed, 17 Jul 2002 02:05:00 -0700 (PDT)
Received: from [133.93.73.143] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21927; Wed, 17 Jul 2002 05:05:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100304b95ae282c83c@[133.93.73.143]>
In-Reply-To: <005a01c22d73$369d6990$0500a8c0@arport>
References: <005101c22cb1$39231830$0500a8c0@arport> <p05100302b95a5ea8957a@[133.93.73.143]> <005a01c22d73$369d6990$0500a8c0@arport>
Date: Wed, 17 Jul 2002 05:04:03 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Deciding on how to proceed with DPD/DPV  Was: WG Last Call CLOSED: DPD/DPV Requirements
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:20 AM +0200 7/17/02, Anders Rundgren wrote:
>Thanx Steve,
>
>Your phrase "the rest of us" indicates that I am the only PKIX'er who have
>doubts regarding the validity of the DPD/DPV-effort.  I won't argue with that
>as I have no proofs for the opposite, but rather base my view on information
>gathered from other communities, drafts etc.   But please continue reading...
>
>Long-term suggestion
>------------------------
>A problem with the e-mail-list approach including "rough consensus",
>is that most people are rather timid, and do not particularly enjoy getting
>publicly bashed.  Due to this fact, I believe it could be of some value to
>add a voting-system to the IETF-mailing lists, where a list-member could
>send a vote on a certain topic without being exposed on the list.  Then an
>admittedly sensitive topic like "Should we continue the DPD/DPV effort",
>could be voted on, and you would not only get a ratio of Yes and Noes,
>but also a clear indication on how many who cares about a subject at all.
>The suggested purpose of this would in no way be changing anything in the
>IETF-process rules, but to gather additional input to critical decisions.
>

Again, thanks for your suggestions on how to improve IETF processes. 
They will certainly receive due consideration.

Since we have at least 3, and maybe 4, proposals for protocols to 
satisfy the DPV/DPD requirements, I have complete confidence that 
there is a sufficient support for continuing the work in PKIX. If it 
were of no interest, we would have one proposed protocol, at best. As 
before, if you or others, feel that this is not a good use of your 
time, then you are free to ignore the activity.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g6H8PoD11399 for ietf-pkix-bks; Wed, 17 Jul 2002 01:25:50 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H8Pnw11392; Wed, 17 Jul 2002 01:25:49 -0700 (PDT)
Received: from arport (h133n2fls31o1122.telia.com [212.181.142.133]) by maila.telia.com (8.11.6/8.11.6) with SMTP id g6H8PKa16712; Wed, 17 Jul 2002 10:25:20 +0200 (CEST)
Message-ID: <005a01c22d73$369d6990$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Tim Polk" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <005101c22cb1$39231830$0500a8c0@arport> <p05100302b95a5ea8957a@[133.93.73.143]>
Subject: Deciding on how to proceed with DPD/DPV  Was: WG Last Call CLOSED: DPD/DPV Requirements
Date: Wed, 17 Jul 2002 11:20:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx Steve,

Your phrase "the rest of us" indicates that I am the only PKIX'er who have
doubts regarding the validity of the DPD/DPV-effort.  I won't argue with that
as I have no proofs for the opposite, but rather base my view on information
gathered from other communities, drafts etc.   But please continue reading...

Long-term suggestion
------------------------
A problem with the e-mail-list approach including "rough consensus",
is that most people are rather timid, and do not particularly enjoy getting
publicly bashed.  Due to this fact, I believe it could be of some value to
add a voting-system to the IETF-mailing lists, where a list-member could
send a vote on a certain topic without being exposed on the list.  Then an
admittedly sensitive topic like "Should we continue the DPD/DPV effort",
could be voted on, and you would not only get a ratio of Yes and Noes,
but also a clear indication on how many who cares about a subject at all.
The suggested purpose of this would in no way be changing anything in the
IETF-process rules, but to gather additional input to critical decisions.

Short-term DPD/DPV-action
--------------------------------
Anyway, I believe it would be most appropriate and in everybody's
interest if the authors created a short rationale showing why the
DPV/DPD-effort should be continued in the light of recent advances
by competing efforts like XKMS.

Even in the security area there is a huge "cemetery" of technically
wonderful(?) standards-efforts that the market rejected, several
due to the existence of another system. PCT/SSL, S-HTTP/HTTPS,
and SPA/3D Secure belong to this latter category.

regards
Anders Rundgren

----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 17, 2002 01:42
Subject: Re: WG Last Call CLOSED: DPD/DPV Requirements


Anders,

I'm sure we all appreciate your efforts to save the rest of us from 
wasting our time on DPV/DPD. Your message seems to indicate that you 
don't object to the rest of us continuing to work on this if we see 
fit.

Thanks,

Steve



Received: by above.proper.com (8.11.6/8.11.3) id g6GNwPv08192 for ietf-pkix-bks; Tue, 16 Jul 2002 16:58:25 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GNwJw08187 for <[e-mail]>; Tue, 16 Jul 2002 16:58:20 -0700 (PDT)
Received: from [133.93.73.143] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04376; Tue, 16 Jul 2002 19:59:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100302b95a5ea8957a@[133.93.73.143]>
In-Reply-To: <005101c22cb1$39231830$0500a8c0@arport>
References: <005101c22cb1$39231830$0500a8c0@arport>
Date: Tue, 16 Jul 2002 19:42:35 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: WG Last Call CLOSED: DPD/DPV Requirements
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

I'm sure we all appreciate your efforts to save the rest of us from 
wasting our time on DPV/DPD. Your message seems to indicate that you 
don't object to the rest of us continuing to work on this if we see 
fit.

Thanks,

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6G9Ghm21160 for ietf-pkix-bks; Tue, 16 Jul 2002 02:16:43 -0700 (PDT)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6G9Gfw21152 for <[e-mail]>; Tue, 16 Jul 2002 02:16:42 -0700 (PDT)
Received: from arport (h133n2fls31o1122.telia.com [212.181.142.133]) by mailc.telia.com (8.11.6/8.11.6) with SMTP id g6G9Geq10359; Tue, 16 Jul 2002 11:16:40 +0200 (CEST)
Message-ID: <005101c22cb1$39231830$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: "Tim Polk" <[e-mail]>, "Stephen Kent" <[e-mail]>
Subject: Re: WG Last Call CLOSED: DPD/DPV Requirements
Date: Tue, 16 Jul 2002 12:11:58 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Polk wrote:

    "As there has been no discussion on the list regarding the DPD/DPV 
    requirements document I have forwarded it to Jeff and Steve.    We have 
    obsessed long enough, and there will be lots of opportunities to grind your 
    favorite axe on the protocol specs."

May I start swinging my "favorite axe", before people begin wrestling
another 24 months over this subject?

The market-leaders in the form of VeriSign (including esteemed
PKIX'er Phillip Hallam-Baker), Microsoft, IBM, as well as the
Open Source community have clearly shown that they are focusing
their efforts on XML-based schemes including PKI-based such.
XML-Dsig is really a huge success if you look at recent "design-ins".

And XKMS, which is already shipping, is AFAIK a "DP*"-solution.

IMO, it does not matter much if DPV/DPD will be "better" than
XKMS, as the market does not have this "granularity" in general.
That XKMS has a head start is considerably more important.

Note that this is not one of those dreary "XML is better than ASN.1"-
discussions, but a serious attempt to save energy, talent, time, and
money for other, hopefully more fruitful design-activities.

Naturally the IETF-PKIX chairs are free to ignore that the landscape
has changed since the DPD/DPV-effort was initiated, but I believe
that individual participants should not.

As similar situation occurred in 1995, when Microsoft pulled the plug
on their proprietary MSN-system the day before launch(!), when they
reluctantly realized that "The Internet has won".

That was in my opinion a very bold, and vigorous move that certainly
paid-off in the long-run.

Anders Rundgren
 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6F6F0A28362 for ietf-pkix-bks; Sun, 14 Jul 2002 23:15:00 -0700 (PDT)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6F6Eww28351 for <[e-mail]>; Sun, 14 Jul 2002 23:14:58 -0700 (PDT)
Received: from arport (h133n2fls31o1122.telia.com [212.181.142.133]) by mailf.telia.com (8.12.5/8.12.5) with SMTP id g6F6EsTM014240; Mon, 15 Jul 2002 08:14:54 +0200 (CEST)
X-Original-Recipient: [e-mail]
Message-ID: <003101c22bce$abd05610$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Roberto Opazo" <[e-mail]>, <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>, "Tom Gindin" <[e-mail]>
References: <[e-mail]>
Subject: Re: PI support 
Date: Mon, 15 Jul 2002 09:10:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Roberto,

Due to the fact that the coming PI RFC neither supports [1], nor
exploits [2], current well-established practices of commercial
CAs and SW, there is an obvious risk that it will not get proper
attention in spite of good intentions by the authors.

1] Using DNs as the primary place-holder for identity elements.

This practice is already in extensive use since years back (including
holding permanent identifiers), and it is probably a bit too late to
change this now.  Mostly people are comfortable with this system
as well, and certificate mapping software like Microsoft's IIS only
supports DN-based operations.  As the PI-extension does not
support DN-based PI-data at all, it effectively requires such data to
be _duplicated_ to support current mapping techniques.


2] For reasons like simplicity, fear of getting sued due to customer err,
   and technical support concerns, practically all serious CAs limit
   their issuance of certificates to one entity-type per CA-cert/key.

This fact rather make _CA-certs_ the prime candidate for holding
PI-declarations, which associated entity-certificates using path-
validation-like syntax-checking algorithms would have to obey.
Such schemes would in many cases also allow CA-certs to be re-
generated using existing keys, to support _migration_ to explicit
PI-usage without recalling existing entity-certificates (typically
using serialnumber etc. for storing IDs), which would subsequently
become fully PI-compliant by the "reborn" CA.

As an example of how [badly] an entity-cert.-only scheme works,
I can mention that VeriSign have defined a private DUNS-extension
in their web-server certificates.  Now assume that an RP is building
support for that in their applications.   As the DUNS-extension in
similarity to the PI-extension is optional, the RP software must

- look for the extension and if available extract DUNS-data

- fail gracefully or fail hard if a received certificate does not have
  the wanted extension, in spite of coming from an accepted CA,
  and vouching for the requested entity type (implicit in the case
  of VeriSign)

- using PIs you would also have to look for matching identifierType
  so you don't end-up accepting an invalid entity type (what an
  unspecified identifierType as allowed by the PI-draft means in
  terms of entity-type, you cannot have really _any_ idea about).

By using a single, CA-specified PI-declarator, you limit hassles
to an absolute minimum as you at the moment of CA-acceptance
know _exactly_, and _in_advance_, what to expect and have
decided to "digest" or not, and all the gory stuff can be handled
automatically by an enhanced standard certificate processing
subsystem (at least if assuming that a specific RP is unlikely to
support more than a single PI-scheme).  This is particularly
desirable in non-programmatic situations like in the afore-
mentioned IIS mapping setup.

Robustness and rigidity, the cornerstones of real interoperability. :-)

Using the PI-draft extension OTOH, you know essentially nothing
what to expect in terms of entity-certificates.

The reason I am a bit concerned is that I can hardly find a _single_
entity-certificate-type that would not benefit from PI-support, ranging
from e-mail certificates (as an e-mail address may be used as a PI
belonging to the Internet naming domain), to web-server certificates
containing DUNS, and to national and organization-wide ID-schemes
using citizen- and employee-codes.
Can you?

The "rough consensus" that has been achieved for the PI draft, is
IMHO mainly based on a general lack of interest in the subject.

cheers,
Anders

----- Original Message ----- 
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Sent: Friday, July 12, 2002 16:38
Subject: PI support 




Hello:

I am trying to get some support to promote the use of Permanent Identifiers
in my country. In particular, it would be very useful if you send me the
following information:

1.- Who is working on that. I mean witch providers are going to support PI
codifying?

2.- If someone has emitted a certificate with a PI I would be pleased to
have a copy of that. In fact I would like to have a set of certificates with
PI.

3.- Does anyone know about the browser support. Microsoft, Netscape or Opera
are going to support that?

Thanks a lot,

Roberto Opazo








Received: by above.proper.com (8.11.6/8.11.3) id g6E1cXA20453 for ietf-pkix-bks; Sat, 13 Jul 2002 18:38:33 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6E1cVw20449 for <[e-mail]>; Sat, 13 Jul 2002 18:38:31 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Jul 2002 01:37:51 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id VAA14772 for <[e-mail]>; Sat, 13 Jul 2002 21:38:34 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6E1aTd11956 for <[e-mail]>; Sat, 13 Jul 2002 21:36:30 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <3XCQSKG0>; Sun, 14 Jul 2002 02:41:36 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TP46XLG; Sat, 13 Jul 2002 21:38:20 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 12 Jul 2002 16:40:51 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RFC 3281 ASN.1 Errata
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi.

I just want to make everyone aware of a typo in the ASN.1 module in RFC 
3281.  There is a comma in the wrong place, and it it quite simple to fix.

INCORRECT LINE:

                 version        AttCertVersion  -- version is v2,

CORRECT LINE:

                 version        AttCertVersion,  -- version is v2

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6CHv0B28782 for ietf-pkix-bks; Fri, 12 Jul 2002 10:57:00 -0700 (PDT)
Received: from onrims.onr.navy.mil (onrims.onr.navy.mil [131.250.16.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CHuxw28775 for <[e-mail]>; Fri, 12 Jul 2002 10:56:59 -0700 (PDT)
Received: from onrex3.onr.navy.mil ([131.250.16.107]) by onrims.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Jul 2002 13:45:20 -0400
Received: from mail pickup service by onrex3.onr.navy.mil with Microsoft SMTPSVC; Fri, 12 Jul 2002 13:45:03 -0400
Received: from onrims.onr.navy.mil ([131.250.16.88]) by onrex3.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966);	 Fri, 12 Jul 2002 13:37:09 -0400
Received: from above.proper.com ([208.184.76.45]) by onrims.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966);	 Fri, 12 Jul 2002 13:13:33 -0400
Received: from localhost (localhost [[UNIX: localhost]])	by above.proper.com (8.11.6/8.11.3) id g6CGb4V20439	for ietf-pkix-bks; Fri, 12 Jul 2002 09:37:04 -0700 (PDT)
Received: from onrims.onr.navy.mil (onrims.onr.navy.mil [131.250.16.88])	by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CGb2w20434	for <[e-mail]>; Fri, 12 Jul 2002 09:37:02 -0700 (PDT)
Received: from onrex3.onr.navy.mil ([131.250.16.107]) by onrims.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966);	 Fri, 12 Jul 2002 12:36:44 -0400
Received: from mail pickup service by onrex3.onr.navy.mil with Microsoft SMTPSVC;	 Fri, 12 Jul 2002 12:36:39 -0400
Received: from onrims.onr.navy.mil ([131.250.16.88]) by onrex3.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966);	 Fri, 12 Jul 2002 12:22:57 -0400
Received: from above.proper.com ([208.184.76.45]) by onrims.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966);	 Fri, 12 Jul 2002 11:31:55 -0400
Received: from localhost (localhost [[UNIX: localhost]])	by above.proper.com (8.11.6/8.11.3) id g6CEddG07970	for ietf-pkix-bks; Fri, 12 Jul 2002 07:39:39 -0700 (PDT)
Received: from slx_cus_mai02.custodium.com ([216.241.20.228])	by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CEdWw07959	for <[e-mail]>; Fri, 12 Jul 2002 07:39:37 -0700 (PDT)
Received: from ww2kropazo ([192.168.4.100])	by slx_cus_mai02.custodium.com (8.12.2/8.12.2) with SMTP id g6CEbfre005323	for <[e-mail]>; Fri, 12 Jul 2002 10:37:56 -0400
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Subject: PI support 
Date: Fri, 12 Jul 2002 10:38:42 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
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.4807.1700
Importance: High
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 12 Jul 2002 15:31:55.0561 (UTC) FILETIME=[40FA0190:01C229B9]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello:

I am trying to get some support to promote the use of Permanent Identifiers
in my country. In particular, it would be very useful if you send me the
following information:

1.- Who is working on that. I mean witch providers are going to support PI
codifying?

2.- If someone has emitted a certificate with a PI I would be pleased to
have a copy of that. In fact I would like to have a set of certificates with
PI.

3.- Does anyone know about the browser support. Microsoft, Netscape or Opera
are going to support that?

Thanks a lot,

Roberto Opazo



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6CGb4V20439 for ietf-pkix-bks; Fri, 12 Jul 2002 09:37:04 -0700 (PDT)
Received: from onrims.onr.navy.mil (onrims.onr.navy.mil [131.250.16.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CGb2w20434 for <[e-mail]>; Fri, 12 Jul 2002 09:37:02 -0700 (PDT)
Received: from onrex3.onr.navy.mil ([131.250.16.107]) by onrims.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Jul 2002 12:36:44 -0400
Received: from mail pickup service by onrex3.onr.navy.mil with Microsoft SMTPSVC; Fri, 12 Jul 2002 12:36:39 -0400
Received: from onrims.onr.navy.mil ([131.250.16.88]) by onrex3.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966);	 Fri, 12 Jul 2002 12:22:57 -0400
Received: from above.proper.com ([208.184.76.45]) by onrims.onr.navy.mil with Microsoft SMTPSVC(5.0.2195.2966);	 Fri, 12 Jul 2002 11:31:55 -0400
Received: from localhost (localhost [[UNIX: localhost]])	by above.proper.com (8.11.6/8.11.3) id g6CEddG07970	for ietf-pkix-bks; Fri, 12 Jul 2002 07:39:39 -0700 (PDT)
Received: from slx_cus_mai02.custodium.com ([216.241.20.228])	by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CEdWw07959	for <[e-mail]>; Fri, 12 Jul 2002 07:39:37 -0700 (PDT)
Received: from ww2kropazo ([192.168.4.100])	by slx_cus_mai02.custodium.com (8.12.2/8.12.2) with SMTP id g6CEbfre005323	for <[e-mail]>; Fri, 12 Jul 2002 10:37:56 -0400
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Subject: PI support 
Date: Fri, 12 Jul 2002 10:38:42 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
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.4807.1700
Importance: High
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 12 Jul 2002 15:31:55.0561 (UTC) FILETIME=[40FA0190:01C229B9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello:

I am trying to get some support to promote the use of Permanent Identifiers
in my country. In particular, it would be very useful if you send me the
following information:

1.- Who is working on that. I mean witch providers are going to support PI
codifying?

2.- If someone has emitted a certificate with a PI I would be pleased to
have a copy of that. In fact I would like to have a set of certificates with
PI.

3.- Does anyone know about the browser support. Microsoft, Netscape or Opera
are going to support that?

Thanks a lot,

Roberto Opazo



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6CEddG07970 for ietf-pkix-bks; Fri, 12 Jul 2002 07:39:39 -0700 (PDT)
Received: from slx_cus_mai02.custodium.com ([216.241.20.228]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CEdWw07959 for <[e-mail]>; Fri, 12 Jul 2002 07:39:37 -0700 (PDT)
Received: from ww2kropazo ([192.168.4.100]) by slx_cus_mai02.custodium.com (8.12.2/8.12.2) with SMTP id g6CEbfre005323 for <[e-mail]>; Fri, 12 Jul 2002 10:37:56 -0400
From: "Roberto Opazo" <[e-mail]>
To: <[e-mail]>
Subject: PI support 
Date: Fri, 12 Jul 2002 10:38:42 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
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.4807.1700
Importance: High
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello:

I am trying to get some support to promote the use of Permanent Identifiers
in my country. In particular, it would be very useful if you send me the
following information:

1.- Who is working on that. I mean witch providers are going to support PI
codifying?

2.- If someone has emitted a certificate with a PI I would be pleased to
have a copy of that. In fact I would like to have a set of certificates with
PI.

3.- Does anyone know about the browser support. Microsoft, Netscape or Opera
are going to support that?

Thanks a lot,

Roberto Opazo



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6BDCCi20895 for ietf-pkix-bks; Thu, 11 Jul 2002 06:12:12 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BDC8w20875 for <[e-mail]>; Thu, 11 Jul 2002 06:12:08 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g6BDC2hZ024518; Thu, 11 Jul 2002 09:12:02 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 11 Jul 2002 09:09:07 -0400
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Request for IESG consideration: PKIX Permanent Identifier
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Steve,

The PKIX working group has achieved rough consensus and completed WG Last 
Call for  http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt, 
"Internet X.509 Public Key Infrastructure: Permanent Identifier".  Please 
consider this specification for submission to the IESG for advancement to 
RFC status.

We believe this specification would be most appropriate as an standards 
track RFC.

Thanks,

Tim Polk






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6AEwRd16634 for ietf-pkix-bks; Wed, 10 Jul 2002 07:58:27 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6AEwPw16629 for <[e-mail]>; Wed, 10 Jul 2002 07:58:25 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g6AEwHjP018770; Wed, 10 Jul 2002 10:58:18 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 10 Jul 2002 10:55:24 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: PKIX WG agenda for 54th IETF
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_98177095==_"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_98177095==_
Content-Type: text/plain; charset="us-ascii"; format=flowed


The current agenda for the PKIX WG at the 54th IETF meeting is attached.

Thanks,

Tim Polk
--=====================_98177095==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="PKIX agenda 54.txt"

PKIX WG (pkix-wg)

WEDNESDAY, July 17 1300-1500
=================================

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

AGENDA:

I. Document Status Review (10 min.)             Tim Polk (NIST)

II. Interoperability Testing for RFC 3279       Tim Polk (NIST)
        and RFC 3280 (5 min.)

III. DPD/DPV Requirements and Protocol

    a. DPV Requirements Status (5 min.)         Denis Pinkas (Bull)
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-05.txt

    b. Certificate Validation Protocol (5)      Denis Pinkas (Bull)
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-00.txt

    c. SCVP Protocol (5 min.)                   Ambarish Malpani (ValiCert)
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-08.txt

IV. Wireless LAN Certificate Extensions (10)    Russ Housley (RSA Security)
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

V. Attribute Certificate Policies Extension (5) Denis Pinkas (Bull)
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt

VI. RFC 3161bis (5 Min.)                        Denis Pinkas (Bull)	
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161bis-00.txt

VII. Policy requirements for TSAs (5 min.)      Denis Pinkas (Bull)		
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-01.txt

VIII. PKIX Permanent Identifiers (5 min.)       Denis Pinkas (Bull)	
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt	

IX.  Logotypes in X.509 Certificates (5 min.)   Stefan Santesson (AddTrust)
    http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-03.txt

X.  "Specification Problem around Multi PKI (15 min.)   Ryu Inada (Japan Network 
       domain Experience in Challenge PKI 2001"              Security Association)

--=====================_98177095==_--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g69BAEQ26115 for ietf-pkix-bks; Tue, 9 Jul 2002 04:10:14 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g69BACw26110 for <[e-mail]>; Tue, 9 Jul 2002 04:10:12 -0700 (PDT)
Received: from email.nist.gov (localhost [127.0.0.1]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g69BACPp016703 for <[e-mail]>; Tue, 9 Jul 2002 07:10:12 -0400 (EDT)
Received: (from nobody@localhost) by email.nist.gov (8.12.2/8.12.2/Submit) id g69BABnI016702 for [e-mail]; Tue, 9 Jul 2002 07:10:11 -0400 (EDT)
X-Authentication-Warning: email.nist.gov: nobody set sender to [e-mail] using -f
To: [e-mail]
Subject: agenda requests
Message-ID: <[e-mail]>
Date: Tue, 09 Jul 2002 07:10:11 -0400 (EDT)
From: [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.6
X-Originating-IP: 141.156.172.8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Denis has reminded me that the PKIX agenda is due tomorrow.  (Thanks for the 
reminder.)  If you would like time on the agenda please send the request to me 
today.  I will submit the agenda tomorrow morning. 

Thanks,

Tim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g693TJM03842 for ietf-pkix-bks; Mon, 8 Jul 2002 20:29:19 -0700 (PDT)
Received: from xinhuanet.com ([202.84.17.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g693TCw03831 for <[e-mail]>; Mon, 8 Jul 2002 20:29:16 -0700 (PDT)
Date: Mon, 8 Jul 2002 20:29:16 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from Qks([210.22.128.77]) by xinhuanet.com(JetMail 2.5.3.0) with SMTP id jm3e3d2a83d4; Tue,  9 Jul 2002 03:33:46 -0000
From: phoffman <[e-mail]>
To: [e-mail]
Subject: A  humour game
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=HO7zst6f89q0F1wmV5K1e
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--HO7zst6f89q0F1wmV5K1e
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>

<FONT>This is a special  humour game<br>
This game is my first work.<br>
You're the first player.<br>
I hope you would enjoy it.</FONT></BODY></HTML>

--HO7zst6f89q0F1wmV5K1e
Content-Type: application/octet-stream;
	name=picacu.exe
Content-Transfer-Encoding: base64
Content-ID: <C04gw3Uai0wjcyq23>


--HO7zst6f89q0F1wmV5K1e
--HO7zst6f89q0F1wmV5K1e
Content-Type: application/octet-stream;
	name=05T2_1.HTM
Content-Transfer-Encoding: base64
Content-ID: <C04gw3Uai0wjcyq23>

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMiBGaW5hbC8vRU4i
Pg0KPEhUTUw+DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ29u
dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVdpbmRvd3MtMTI1MiI+DQo8VElUTEU+TWljcm9z
b2Z0IE9mZmljZSAyMDAwIFJlc291cmNlIEtpdDwvVElUTEU+DQo8U0NSSVBUIExBTkdVQUdF
PSJKYXZhU2NyaXB0Ij4NCjwhLS0NCglpZiAobmF2aWdhdG9yLnVzZXJBZ2VudC5pbmRleE9m
KCJNU0lFIDQiKSAhPSAtMSkNCgkJCXsNCgkJZG9jdW1lbnQud3JpdGUoIjxMSU5LIFJFTD1T
VFlMRVNIRUVUIEhSRUY9XCIuLi9vcmsuY3NzXCIgVFlQRT1cInRleHQvY3NzXCI+Iik7DQoJ
CWRvY3VtZW50LndyaXRlKCI8U1RZTEU+Iik7DQoJCWRvY3VtZW50LndyaXRlKCI8PCEtLT4i
KTsNCgkJZG9jdW1lbnQud3JpdGUoIjxBOmhvdmVyCXtjb2xvcjogMDAzMzk5fT4iKTsNCgkJ
ZG9jdW1lbnQud3JpdGUoIjwvLy0tPj4iKTsNCgkJZG9jdW1lbnQud3JpdGUoIjwvU1RZTEU+
Iik7DQoJCQl9DQoJZWxzZQ0KCQkJew0KCWlmIChuYXZpZ2F0b3IuYXBwTmFtZSA9PSAiTmV0
c2NhcGUiKQ0KCQkJew0KCQlkb2N1bWVudC53cml0ZSgiPExJTksgUkVMPVNUWUxFU0hFRVQg
SFJFRj1cIi4uL29ya25zLmNzc1wiIFRZUEU9XCJ0ZXh0L2Nzc1wiPiIpOw0KCQkJfQ0KCWVs
c2UNCgkJCXsNCgkJZG9jdW1lbnQud3JpdGUoIjxMSU5LIFJFTD1TVFlMRVNIRUVUIEhSRUY9
XCIuLi9vcmsuY3NzXCIgVFlQRT1cInRleHQvY3NzXCI+Iik7DQoJfQ0KCQkJfQ0KLy8tLT4N
CjwvU0NSSVBUPjwvSEVBRD4NCg0KPEJPRFkgQkdDT0xPUj0iI0ZGRkZGRiIgVEVYVD0iIzAw
MDAwMCI+DQoNCg0KPCEtLSBTdGFydDogVG9vbEJhciBmb3IgZG93bi1sZXZlbCBicm93c2Vy
cy0tPg0KDQo8VEFCTEUgV0lEVEg9JzEwMCUnIENFTExQQURESU5HPTAgQ0VMTFNQQUNJTkc9
MCBCT1JERVI9MCBCR0NPTE9SPScjRkZGRkZGJz4NCjxUUj4NCgk8VEQgVkFMSUdOPSdtaWRk
bGUnIEhFSUdIVD02MCBST1dTUEFOPTI+PElNRyBTUkM9Ii4uL2ltYWdlcy9vZmZsb2dvLkdJ
RiIgQUxJR049bGVmdCBib3JkZXI9MD48L1REPg0KCTxURCBWQUxJR049J21pZGRsZScgSEVJ
R0hUPTIwIEFMSUdOPSdSSUdIVCc+PElNRyBTUkM9Jy4uL2ltYWdlcy9jdXJ2ZS5naWYnIFdJ
RFRIPTE4IEhFSUdIVD0yMCBBTFQ9JycgQk9SREVSPTA+PC9URD4NCgk8VEQgQkdDT0xPUj0n
IzAwMDAwMCcgSEVJR0hUPTIwIFZBTElHTj0nbWlkZGxlJyBBTElHTj0nUklHSFQnIE5PV1JB
UCBDT0xTUEFOPTI+DQoJCTxGT05UIENPTE9SPScjRkZGRkZGJyBGQUNFPSdWZXJkYW5hLCBB
cmlhbCcgU0laRT0xPg0KCQk8Qj4NCgkJCTxJTUcgU1JDPScuLi9pbWFnZXMvMXB0cmFucy5n
aWYnIFdJRFRIPTIyMCBIRUlHSFQ9MTUgQUxUPScnIEJPUkRFUj0wPjxBIFNUWUxFPSdjb2xv
cjojRkZGRkZGO3RleHQtZGVjb3JhdGlvbjpub25lOycgSFJFRj0iaHR0cDovL3d3dy5taWNy
b3NvZnQuY29tIiBUQVJHRVQ9J190b3AnPjxGT05UIENPTE9SPScjRkZGRkZGJz5taWNyb3Nv
ZnQuY29tIEhvbWU8L0ZPTlQ+PC9BPiZuYnNwOyZuYnNwOw0KCQk8L0I+DQoJCTwvRk9OVD48
L1REPg0KPC9UUj4NCjxUUj4NCgk8VEQgVkFMSUdOPSdUT1AnIEhFSUdIVD00MCBXSURUSD0x
OT48SU1HIFNSQz0nLi4vaW1hZ2VzLzFwdHJhbnMuZ2lmJyBXSURUSD0xOSBIRUlHSFQ9NDAg
QUxUPScnIEJPUkRFUj0wPjwvVEQ+DQoJPFREIFZBTElHTj0nVE9QJyBIRUlHSFQ9NDAgQUxJ
R049J1JJR0hUJyBOT1dSQVAgQ09MU1BBTj0yPjxBIEhSRUY9Imh0dHA6Ly93d3cubWljcm9z
b2Z0LmNvbSIgVEFSR0VUPSdfdG9wJz48SU1HIFNSQz0nLi4vaW1hZ2VzL21zbG9nby5naWYn
IFdJRFRIPTExMiBIRUlHSFQ9NDAgQUxUPSdNaWNyb3NvZnQnIEJPUkRFUj0wPjwvQT48L1RE
Pg0KPC9UUj4NCjxUUj4NCgk8IS0tIFN0YXJ0OiBMb2NhbCBtZW51cyAtLT4NCgk8VEQgQkdD
T0xPUj0nIzAwMDAwMCcgSEVJR0hUPTIwIE5PV1JBUCBWQUxJR049J01JRERMRScgQ09MU1BB
Tj00IGFsaWduPXJpZ2h0Pg0KCQk8SU1HIFNSQz0nLi4vaW1hZ2VzLzFwdHJhbnMuZ2lmJyBX
SURUSD0xOSBIRUlHSFQ9NyBBTFQ9JycgQk9SREVSPTA+DQoJCTxBIEhSRUY9Imh0dHA6Ly93
d3cubWljcm9zb2Z0LmNvbS9vZmZpY2Uvb3JrIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiBu
b25lOyI+PEZPTlQgQ09MT1I9JyNGRkZGRkYnIEZBQ0U9J1ZlcmRhbmEsIEFyaWFsJyBTSVpF
PTE+PEI+DQpodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vb2ZmaWNlL29yazwvRk9OVD48L0I+
PC9BPiZuYnNwOyZuYnNwOzwvVEQ+DQoJPCEtLSBFbmQ6IExvY2FsIG1lbnVzIC0tPg0KPC9U
Uj4NCjwvVEFCTEU+DQoNCg0KDQo8IS0tIEVuZDogVG9vbEJhciBWMi4wLS0+DQoNCg0KPCEt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBCRUdJTiBPUksgTkFWSUdBVElPTiBC
QVIgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+DQoNCjxUQUJMRSBXSURUSD0x
MDAlIENFTExQQURESU5HPTAgQ0VMTFNQQUNJTkc9MCBCT1JERVI9MD4NCgk8VFI+DQoJPFRE
IFZBTElHTj1UT1AgV0lEVEg9MiU+DQoNCgk8VEFCTEUgd2lkdGg9MTY1IENFTExQQURESU5H
PTAgQ0VMTFNQQUNJTkc9MCBCT1JERVI9MCBoZWlnaHQ9IjEwMCUiPg0KCQk8VFI+DQoJCTxU
RCBWQUxJR049VE9QIGJnY29sb3I9IiM2NjY2OTkiIGFsaWduPXJpZ2h0Pg0KDQoJPFRBQkxF
IENFTExQQURESU5HPTAgQ0VMTFNQQUNJTkc9MCBCT1JERVI9MD4NCgkJPFRSPg0KCQk8VEQg
Ymdjb2xvcj0iIzY2NjY5OSI+PEZPTlQgRkFDRT0idmVyZGFuYSwgaGVsdmV0aWNhLCBhcmlh
bCIgU0laRT0iMiI+PEEgSHJlZj0iLi4vZGVmYXVsdC5odG0iPjxESVYgQ0xBU1M9dGllcjF3
aGl0ZSBJRD1pbWcxIG9uTW91c2VPdmVyPSJ0aGlzLmNsYXNzTmFtZT0ndGllcjFvdmVyJyIg
b25Nb3VzZU91dD0idGhpcy5jbGFzc05hbWU9J3RpZXIxd2hpdGUnIj48SU1HIFNSQz0iLi4v
aW1hZ2VzL3NwYWNlci5naWYiIFdJRFRIPTkgSEVJR0hUPTM1IEJPUkRFUj0iMCIgYWxpZ249
ImxlZnQiPk1pY3Jvc29mdCBPZmZpY2UgMjAwMCBSZXNvdXJjZSBLaXQgSG9tZTwvRElWPjwv
YT48L0ZPTlQ+PC9URD4NCgkJPC9UUj4NCgkJDQoJCTxUUj4NCgkJPFREIGJnY29sb3I9IiM2
NjY2OTkiPjxkaXYgY2xhc3M9dGllcjE+PGltZyBzcmM9Ii4uL2ltYWdlcy9zdHJpcGUuanBn
IiB3aWR0aD0xNTUgaGVpZ2h0PTEgYWxpZ249Y2VudGVyPjwvZGl2PjwvVEQ+DQoJCTwvVFI+
DQoJCQ0KCQkNCgkJDQoJCTxUUj4NCgkJPFREIGJnY29sb3I9IiM2NjY2OTkiPjxGT05UIEZB
Q0U9InZlcmRhbmEsIGhlbHZldGljYSwgYXJpYWwiIFNJWkU9Mj48QSBIcmVmPSIuLi9kZWZh
dWx0Lmh0bSI+PERJViBDTEFTUz10aWVyMXllbGxvdyBJRD1pbWcxIG9uTW91c2VPdmVyPSJ0
aGlzLmNsYXNzTmFtZT0ndGllcjFvdmVyJyIgb25Nb3VzZU91dD0idGhpcy5jbGFzc05hbWU9
J3RpZXIxeWVsbG93JyI+PGltZyBzcmM9Ii4uL2ltYWdlcy9taW51cy5naWYiIGJvcmRlcj0w
PjxJTUcgU1JDPSIuLi9pbWFnZXMvc3BhY2VyLmdpZiIgV0lEVEg9OCBIRUlHSFQ9MjAgQk9S
REVSPSIwIiBhbGlnbj0ibGVmdCI+PGI+Jm5ic3A7VGhlIE9mZmljZSAyMDAwIEVudmlyb25t
ZW50PC9iPjwvRElWPjwvQT48L0ZPTlQ+DQo8L1REPjwvVFI+DQoJCQ0KCQk8VFI+DQoJCTxU
RCBiZ2NvbG9yPSIjQ0NDQ0NDIj48Rk9OVCBGQUNFPSJ2ZXJkYW5hLCBoZWx2ZXRpY2EsIGFy
aWFsIiBTSVpFPTI+PGEgaHJlZj0iLi4vb25lLzA1Y3QuaHRtIj48RElWIENMQVNTPXRpZXIx
IElEPWltZzEgb25Nb3VzZU92ZXI9InRoaXMuY2xhc3NOYW1lPSd0aWVyMW92ZXInIiBvbk1v
dXNlT3V0PSJ0aGlzLmNsYXNzTmFtZT0ndGllcjEnIj48aW1nIHNyYz0iLi4vaW1hZ2VzL2Js
a21pbnVzLmdpZiIgYm9yZGVyPTA+PElNRyBTUkM9Ii4uL2ltYWdlcy9zcGFjZXIuZ2lmIiBX
SURUSD04IEhFSUdIVD0xMCBCT1JERVI9IjAiIGFsaWduPSJsZWZ0Ij48Yj4mbmJzcDtPZmZp
Y2UgMjAwMCAtIFdoYXQgWW91IE5lZWQgdG8gS25vdzwvYj48L0RJVj48L2E+PC9mb250Pg0K
DQoNCgkJCTxUQUJMRSBXSURUSD0xNTUgQ0VMTFBBRERJTkc9MCBDRUxMU1BBQ0lORz0wIEJP
UkRFUj0wIGJnY29sb3I9IiNDQ0NDQ0MiIHN0eWxlPSJtYXJnaW4tbGVmdDogMWVtOyI+DQoJ
CQkNCgkJCTxUUj4NCgkJCTxURD48SU1HIFNSQz0iLi4vaW1hZ2VzL3NwYWNlci5naWYiIFdJ
RFRIPTUgSEVJR0hUPTUgQk9SREVSPSIwIiBhbGlnbj1sZWZ0PjwvVEQ+DQoJCQk8L1RSPg0K
DQoJCQkJPFRSPg0KCQkJCTxURCBDT0xTUEFOPTI+PEZPTlQgRkFDRT0idmVyZGFuYSwgaGVs
dmV0aWNhLCBhcmlhbCIgU0laRT0yPjxBIEhSRUY9Ii4uL29uZS8wNWN0XzEuaHRtIj48RElW
IENMQVNTPXRpZXIyIG9uTW91c2VPdmVyPSJ0aGlzLmNsYXNzTmFtZT0ndGllcjJvdmVyJyIg
b25Nb3VzZU91dD0idGhpcy5jbGFzc05hbWU9J3RpZXIyJyI+VGhlIE9mZmljZSAyMDAwIFJl
c291cmNlIEtpdDwvRElWPjwvQT48L0ZPTlQ+PC9URD4NCgkJCQk8L1RSPg0KCQkJCQ0KCQkJ
PFRSPg0KCQkJPFREPjxJTUcgU1JDPSIuLi9pbWFnZXMvc3BhY2VyLmdpZiIgV0lEVEg9NSBI
RUlHSFQ9NSBCT1JERVI9IjAiIGFsaWduPWxlZnQ+PC9URD4NCgkJCTwvVFI+DQoNCgkJCQk8
VFI+DQoJCQkJPFREIENPTFNQQU49Mj48Rk9OVCBGQUNFPSJ2ZXJkYW5hLCBoZWx2ZXRpY2Es
IGFyaWFsIiBTSVpFPTI+PEEgSFJFRj0iLi4vb25lLzA1dDIuaHRtIj48RElWIGNsYXNzPXRp
ZXIyaG90PlRoZSBPZmZpY2UgMjAwMCBDbGllbnQgUGxhdGZvcm08L0RJVj48L0I+PC9GT05U
PjwvVEQ+DQoJCQkJPC9UUj4NCgkJCQkNCgkJCQkJCQk8VFI+DQoJCQk8VEQ+PElNRyBTUkM9
Ii4uL2ltYWdlcy9zcGFjZXIuZ2lmIiBXSURUSD01IEhFSUdIVD01IEJPUkRFUj0iMCIgYWxp
Z249bGVmdD48L1REPg0KCQkJPC9UUj4NCgkJCQ0KCQkJCQkJCTxUUj4NCgkJCQk8VEQgQ09M
U1BBTj0yPjxGT05UIEZBQ0U9InZlcmRhbmEsIGhlbHZldGljYSwgYXJpYWwiIFNJWkU9Mj48
QSBIUkVGPSIuLi9vbmUvMDV0My5odG0iPjxESVYgQ0xBU1M9dGllcjIgb25Nb3VzZU92ZXI9
InRoaXMuY2xhc3NOYW1lPSd0aWVyMm92ZXInIiBvbk1vdXNlT3V0PSJ0aGlzLmNsYXNzTmFt
ZT0ndGllcjInIj5UaGUgT2ZmaWNlIDIwMDAgTmV0d29yayBQbGF0Zm9ybTwvRElWPjwvQj48
L0ZPTlQ+PC9URD4NCgkJCQk8L1RSPg0KCQkJCQ0KCQkJCQkJCTxUUj4NCgkJCTxURD48SU1H
IFNSQz0iLi4vaW1hZ2VzL3NwYWNlci5naWYiIFdJRFRIPTUgSEVJR0hUPTUgQk9SREVSPSIw
IiBhbGlnbj1sZWZ0PjwvVEQ+DQoJCQk8L1RSPg0KDQoJCQk8L1RBQkxFPg0KDQoJCTwvVEQ+
PC9UUj4NCgkJDQoJCQkJPFRSPg0KCQk8VEQgYmdjb2xvcj0iI0NDQ0NDQyI+PEZPTlQgRkFD
RT0idmVyZGFuYSwgaGVsdmV0aWNhLCBhcmlhbCIgU0laRT0yIENPTE9SPSIjMDAwMDAwIj48
QSBocmVmPSIuLi9vbmUvMTBjdC5odG0iPjxESVYgQ0xBU1M9dGllcjEgSUQ9aW1nMSBvbk1v
dXNlT3Zlcj0idGhpcy5jbGFzc05hbWU9J3RpZXIxb3ZlciciIG9uTW91c2VPdXQ9InRoaXMu
Y2xhc3NOYW1lPSd0aWVyMSciPjxpbWcgc3JjPSIuLi9pbWFnZXMvYmxrcGx1cy5naWYiIGJv
cmRlcj0wPjxJTUcgU1JDPSIuLi9pbWFnZXMvc3BhY2VyLmdpZiIgV0lEVEg9OCBIRUlHSFQ9
MjAgQk9SREVSPSIwIiBhbGlnbj0ibGVmdCI+Jm5ic3A7VG9vbHMgYW5kIFRlY2hub2xvZ2ll
cyBUaGF0IFdvcmsgd2l0aCBPZmZpY2U8L0RJVj48L2E+PC9GT05UPg0KCQk8L3RkPg0KCQk8
L3RyPg0KCQkNCgkJDQoJCQ0KCQkNCgkJDQoJCQ0KCQkNCgkJDQoJCTxUUj4NCgkJPFREIGJn
Y29sb3I9IiM2NjY2OTkiPjxGT05UIEZBQ0U9InZlcmRhbmEsIGhlbHZldGljYSwgYXJpYWwi
IFNJWkU9Mj48YSBocmVmPSIuLi9hcHBuZHgvOTVjdC5odG0iPjxESVYgQ0xBU1M9dGllcjF3
aGl0ZSBJRD0iaW1nNiIgb25Nb3VzZU92ZXI9InRoaXMuY2xhc3NOYW1lPSd0aWVyMW92ZXIn
IiBvbk1vdXNlT3V0PSJ0aGlzLmNsYXNzTmFtZT0ndGllcjF3aGl0ZSciPjxpbWcgc3JjPSIu
Li9pbWFnZXMvcGx1cy5naWYiIGJvcmRlcj0wPjxJTUcgU1JDPSIuLi9pbWFnZXMvc3BhY2Vy
LmdpZiIgV0lEVEg9OCBIRUlHSFQ9MjAgQk9SREVSPSIwIiBhbGlnbj0ibGVmdCI+Jm5ic3A7
T3ZlcnZpZXcgb2YgVG9vbHMgYW5kIFV0aWxpdGllczwvRElWPjwvYT48L0ZPTlQ+DQo8L1RE
PjwvVFI+DQoNCgkNCgkJDQoJCQ0KCQkNCg0KCQkNCgk8VFI+DQoJCTxURCBiZ2NvbG9yPSIj
NjY2Njk5Ij48Rk9OVCBGQUNFPSJ2ZXJkYW5hLCBoZWx2ZXRpY2EsIGFyaWFsIiBTSVpFPSIy
Ij48QSBIUkVGPSIuLi9hcHBuZHgvZ2xvc3NhcnkuaHRtIj48RElWIENMQVNTPXRpZXIxd2hp
dGUgb25Nb3VzZU92ZXI9InRoaXMuY2xhc3NOYW1lPSd0aWVyMW92ZXInIiBvbk1vdXNlT3V0
PSJ0aGlzLmNsYXNzTmFtZT0ndGllcjF3aGl0ZSciPjxJTUcgU1JDPSIuLi9pbWFnZXMvc3Bh
Y2VyLmdpZiIgV0lEVEg9MTMgSEVJR0hUPTEwIEJPUkRFUj0iMCI+R2xvc3Nhcnk8L0RJVj48
L0E+PC9GT05UPjwvVEQ+DQoJCTwvVFI+DQoJCQ0KCQk8VFI+DQoJCTxURCBiZ2NvbG9yPSIj
NjY2Njk5Ij48SU1HIFNSQz0iLi4vaW1hZ2VzL3NwYWNlci5naWYiIFdJRFRIPTEgSEVJR0hU
PTUgQk9SREVSPSIwIj48Rk9OVCBGQUNFPSJ2ZXJkYW5hLCBoZWx2ZXRpY2EsIGFyaWFsIiBT
SVpFPSIyIj48QSBIUkVGPSIuLi9hcHBuZHgvaW5kZXguaHRtIj48RElWIENMQVNTPXRpZXIx
d2hpdGUgb25Nb3VzZU92ZXI9InRoaXMuY2xhc3NOYW1lPSd0aWVyMW92ZXInIiBvbk1vdXNl
T3V0PSJ0aGlzLmNsYXNzTmFtZT0ndGllcjF3aGl0ZSciPjxJTUcgU1JDPSIuLi9pbWFnZXMv
c3BhY2VyLmdpZiIgV0lEVEg9MTMgSEVJR0hUPTEwIEJPUkRFUj0iMCI+SW5kZXg8L0RJVj48
L0E+PC9GT05UPjwvVEQ+DQoJCTwvVFI+DQoNCgkJPFRSPg0KCQk8VEQgYmdjb2xvcj0iIzY2
NjY5OSI+PElNRyBTUkM9Ii4uL2ltYWdlcy9zcGFjZXIuZ2lmIiBXSURUSD0xNDcgSEVJR0hU
PTIwMD48L1REPg0KCQk8L1RSPg0KDQoJCTwvVEFCTEU+DQoNCgk8L1REPg0KCTwvVFI+DQoJ
PC9UQUJMRT4NCgk8L1REPg0KDQo8IS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
IEVORCBOQVZJR0FUSU9OIEJBUiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4N
Cg0KDQoJPFREPjxJTUcgU1JDPSIuLi9pbWFnZXMvc3BhY2VyLmdpZiIgV0lEVEg9MSBIRUlH
SFQ9MTAgQk9SREVSPSIwIj48L1REPg0KCTxURCBWQUxJR049VE9QIFdJRFRIPTk5JT4NCiAg
ICANCg0KDQoNCg0KDQoNCg0KPCEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBC
RUdJTiBQQUdFIENPTlRFTlQgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+DQoN
CjxhIG5hbWU9InRvcCI+PC9hPg0KPEg1IGNsYXNzPXRvcGljPlRoZSBPZmZpY2UmbmJzcDsy
MDAwIENsaWVudCBQbGF0Zm9ybTwvSDU+DQo8SDEgY2xhc3M9cGFnZT4NCk9mZmljZSZuYnNw
OzIwMDAgU3lzdGVtcyBSZXF1aXJlbWVudHM8L0gxPg0KPGEgbmFtZT0iZGV4MiI+PC9hPg0K
DQo8UCBjbGFzcz1UPk1pY3Jvc29mdCBPZmZpY2UmbmJzcDsyMDAwIGlzIGF2YWlsYWJsZSBp
biBmaXZlIGVkaXRpb25zLiBFYWNoIGVkaXRpb24gaW5zdGFsbHMgYSBkaWZmZXJlbnQgc2V0
IG9mIE9mZmljZSBhcHBsaWNhdGlvbnMsIGFuZCBlYWNoIHJlcXVpcmVzIGEgZGlmZmVyZW50
IHNldCBvZiBzeXN0ZW0gcmVxdWlyZW1lbnRzIG9uIHVzZXJzkiBjb21wdXRlcnMuPC9QPg0K
DQoNCg0KPEg0Pk1pY3Jvc29mdCBPZmZpY2UmbmJzcDsyMDAwIFN0YW5kYXJkPC9IND4NCjxh
IG5hbWU9ImRleDMiPjwvYT4NCg0KDQoNCg0KDQoNCg0KPFAgY2xhc3M9VD5NaWNyb3NvZnQg
T2ZmaWNlJm5ic3A7MjAwMCBTdGFuZGFyZCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIGFwcGxp
Y2F0aW9uczo8L1A+DQo8YSBuYW1lPSJkZXg0Ij48L2E+DQoNCjxVTD4NCgk8TEkgY2xhc3M9
TEIxPk1pY3Jvc29mdCBFeGNlbCAyMDAwPC9saT4NCg0KPGEgbmFtZT0iZGV4NSI+PC9hPg0K
DQoNCgk8TEkgY2xhc3M9TEIxPk1pY3Jvc29mdCBPdXRsb29rIDIwMDA8L2xpPg0KDQo8YSBu
YW1lPSJkZXg2Ij48L2E+DQoNCg0KCTxMSSBjbGFzcz1MQjE+TWljcm9zb2Z0IFBvd2VyUG9p
bnQgMjAwMCA8L2xpPg0KDQo8YSBuYW1lPSJkZXg3Ij48L2E+DQoNCg0KCTxMSSBjbGFzcz1M
QjE+TWljcm9zb2Z0IFdvcmQgMjAwMDwvbGk+DQo8L3VsPg0KDQoNCjxhIG5hbWU9ImRleDgi
PjwvYT4NCg0KPFAgY2xhc3M9VD5UbyB1c2UgTWljcm9zb2Z0IE9mZmljZSZuYnNwOzIwMDAg
U3RhbmRhcmQsIHVzZXJzkiBjb21wdXRlcnMgbXVzdCBtZWV0IHRoZSBmb2xsb3dpbmcgcmVx
dWlyZW1lbnRzOjwvUD4NCjxhIG5hbWU9ImRleDkiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5Q
cm9jZXNzb3I8L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7UGVudGl1bSA3NSBNSHogb3IgaGlnaGVy
IHByb2Nlc3NvciA8L1A+DQo8YSBuYW1lPSJkZXgxMCI+PC9hPg0KDQo8UCBjbGFzcz1UPjxC
Pk9wZXJhdGluZyBzeXN0ZW08L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7TWljcm9zb2Z0IFdpbmRv
d3MgOTUvOTgsIE1pY3Jvc29mdCBXaW5kb3dzIE5UIHZlcnNpb24gNC4wLCBvciBNaWNyb3Nv
ZnQgV2luZG93cyAyMDAwPC9QPg0KPGEgbmFtZT0iZGV4MTEiPjwvYT4NCg0KPFAgY2xhc3M9
VD48Qj5NZW1vcnk8L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIFdpbmRvd3MgOTUvOTgsIDE2
IE1CIG9mIFJBTSBmb3IgdGhlIG9wZXJhdGluZyBzeXN0ZW0sIHBsdXMgYW4gYWRkaXRpb25h
bCA0IE1CIG9mIFJBTSBmb3IgZWFjaCBhcHBsaWNhdGlvbiBydW5uaW5nIHNpbXVsdGFuZW91
c2x5ICg4IE1CIGZvciBNaWNyb3NvZnQgT3V0bG9vaykuIDwvUD4NCjxhIG5hbWU9ImRleDEy
Ij48L2E+DQoNCjxQIGNsYXNzPVQ+Rm9yIFdpbmRvd3MgTlQgV29ya3N0YXRpb24gdmVyc2lv
biA0LjAgb3IgbGF0ZXIsIDMyIE1CIG9mIFJBTSBmb3IgdGhlIG9wZXJhdGluZyBzeXN0ZW0s
IHBsdXMgYW4gYWRkaXRpb25hbCA0IE1CIG9mIFJBTSBmb3IgZWFjaCBhcHBsaWNhdGlvbiBy
dW5uaW5nIHNpbXVsdGFuZW91c2x5ICg4IE1CIGZvciBPdXRsb29rKTwvUD4NCjxhIG5hbWU9
ImRleDEzIj48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+QXZhaWxhYmxlIGhhcmQtZGlzayBzcGFj
ZTwvQj4mbmJzcDsmbmJzcDsmbmJzcDsxODkgTUIgZm9yIE1pY3Jvc29mdCBPZmZpY2UmbmJz
cDsyMDAwIERpc2MmbmJzcDsxIChFeGNlbCwgT3V0bG9vaywgUG93ZXJQb2ludCwgYW5kIFdv
cmQpLiA8L1A+DQo8YSBuYW1lPSJkZXgxNCI+PC9hPg0KDQo8UCBjbGFzcz1UPlRoaXMgZmln
dXJlIGluZGljYXRlcyBhIGRlZmF1bHQgaW5zdGFsbGF0aW9uOyB5b3VyIGhhcmQtZGlzayB1
c2FnZSB2YXJpZXMgZGVwZW5kaW5nIG9uIHlvdXIgY29uZmlndXJhdGlvbiBhbmQgdGhlIG9w
dGlvbnMgeW91IGNob29zZSB0byBpbnN0YWxsLjwvUD4NCjxhIG5hbWU9ImRleDE1Ij48L2E+
DQoNCjxQIGNsYXNzPVQ+PEI+RGlzayBkcml2ZXMmbmJzcDsmbmJzcDsmbmJzcDs8L0I+Q0Qt
Uk9NIGRyaXZlPC9QPg0KPGEgbmFtZT0iZGV4MTYiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5N
b25pdG9yPC9CPiZuYnNwOyZuYnNwOyZuYnNwO1ZHQSBvciBoaWdoZXItcmVzb2x1dGlvbiBt
b25pdG9yOyBTdXBlciBWR0EgcmVjb21tZW5kZWQ8L1A+DQo8YSBuYW1lPSJkZXgxNyI+PC9h
Pg0KDQo8UCBjbGFzcz1UPjxCPlBvaW50aW5nIGRldmljZSZuYnNwOyZuYnNwOyZuYnNwOzwv
Qj5NaWNyb3NvZnQgTW91c2UsIE1pY3Jvc29mdCBJbnRlbGxpTW91c2WuLCBvciBjb21wYXRp
YmxlIHBvaW50aW5nIGRldmljZTwvUD4NCjxhIG5hbWU9ImRleDE4Ij48L2E+DQoNCjxQIGNs
YXNzPVQ+U29tZSBPZmZpY2UmbmJzcDsyMDAwIGZlYXR1cmVzIGhhdmUgYWRkaXRpb25hbCBy
ZXF1aXJlbWVudHM6PC9QPg0KPGEgbmFtZT0iZGV4MTkiPjwvYT4NCg0KPFAgY2xhc3M9VD48
Qj5Nb2RlbSZuYnNwOyZuYnNwOyZuYnNwOzwvQj45NjAwIG9yIGhpZ2hlci1iYXVkIG1vZGVt
OyAxNCw0MDAgYmF1ZCByZWNvbW1lbmRlZDwvUD4NCjxhIG5hbWU9ImRleDIwIj48L2E+DQoN
CjxQIGNsYXNzPVQ+PEI+TXVsdGltZWRpYTwvQj4mbmJzcDsmbmJzcDsmbmJzcDtNdWx0aW1l
ZGlhIGNvbXB1dGVyIHJlcXVpcmVkIGZvciBzb3VuZCBhbmQgb3RoZXIgbXVsdGltZWRpYSBl
ZmZlY3RzPC9QPg0KPGEgbmFtZT0iZGV4MjEiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5FLW1h
aWw8L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7TWljcm9zb2Z0IE1haWwsIE1pY3Jvc29mdCBFeGNo
YW5nZSwgSW50ZXJuZXQgU01UUC9QT1AzLCBJTUFQNCwgb3Igb3RoZXIgTUFQSS1jb21wbGlh
bnQgbWVzc2FnaW5nIHNvZnR3YXJlIDwvUD4NCjxhIG5hbWU9ImRleDIyIj48L2E+DQoNCjxQ
IGNsYXNzPVQ+PEI+Q29sbGFib3JhdGlvbjwvQj4mbmJzcDsmbmJzcDsmbmJzcDtNaWNyb3Nv
ZnQgRXhjaGFuZ2UgU2VydmVyIHJlcXVpcmVkIGZvciBjZXJ0YWluIGFkdmFuY2VkIGNvbGxh
Ym9yYXRpb24gZnVuY3Rpb25hbGl0eSBpbiBPdXRsb29rPC9QPg0KPGEgbmFtZT0iZGV4MjMi
PjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5JbnRlcm5ldDwvQj4mbmJzcDsmbmJzcDsmbmJzcDtT
b21lIEludGVybmV0IGZ1bmN0aW9uYWxpdHkgbWF5IHJlcXVpcmUgSW50ZXJuZXQgYWNjZXNz
IGFuZCBwYXltZW50IG9mIGEgc2VwYXJhdGUgZmVlIHRvIGEgc2VydmljZSBwcm92aWRlciwg
YW5kIGxvY2FsIGNoYXJnZXMgbWF5IGFwcGx5LjwvUD4NCg0KPHAgY2xhc3M9dCBhbGlnbj1y
aWdodD48Yj48YSBocmVmPSIjdG9wIj5Ub3A8L2E+PC9iPjwvcD4NCg0KPEg0Pk1pY3Jvc29m
dCBPZmZpY2UmbmJzcDsyMDAwIFNtYWxsIEJ1c2luZXNzPC9IND4NCjxhIG5hbWU9ImRleDI0
Ij48L2E+DQoNCg0KDQoNCg0KDQoNCjxQIGNsYXNzPVQ+TWljcm9zb2Z0IE9mZmljZSZuYnNw
OzIwMDAgU21hbGwgQnVzaW5lc3MgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBhcHBsaWNhdGlv
bnM6PC9QPg0KPGEgbmFtZT0iZGV4MjUiPjwvYT4NCg0KPFVMPg0KCTxMSSBjbGFzcz1MQjE+
TWljcm9zb2Z0IEV4Y2VsIDIwMDA8L2xpPg0KDQo8YSBuYW1lPSJkZXgyNiI+PC9hPg0KDQoN
Cgk8TEkgY2xhc3M9TEIxPk1pY3Jvc29mdCBPdXRsb29rIDIwMDA8L2xpPg0KDQo8YSBuYW1l
PSJkZXgyNyI+PC9hPg0KDQoNCgk8TEkgY2xhc3M9TEIxPk1pY3Jvc29mdCBQdWJsaXNoZXIg
MjAwMDwvbGk+DQoNCjxhIG5hbWU9ImRleDI4Ij48L2E+DQoNCg0KCTxMSSBjbGFzcz1MQjE+
TWljcm9zb2Z0IFdvcmQgMjAwMDwvbGk+DQoNCjxhIG5hbWU9ImRleDI5Ij48L2E+DQoNCg0K
CTxMSSBjbGFzcz1MQjE+TWljcm9zb2Z0IFNtYWxsIEJ1c2luZXNzIFRvb2xzPC9saT4NCjwv
VUw+DQoNCg0KPGEgbmFtZT0iZGV4MzAiPjwvYT4NCg0KPFAgY2xhc3M9VD5UbyB1c2UgTWlj
cm9zb2Z0IE9mZmljZSZuYnNwOzIwMDAgU21hbGwgQnVzaW5lc3MsIHVzZXJzkiBjb21wdXRl
cnMgbXVzdCBtZWV0IHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnRzOjwvUD4NCjxhIG5hbWU9
ImRleDMxIj48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+UHJvY2Vzc29yPC9CPiZuYnNwOyZuYnNw
OyZuYnNwO1BlbnRpdW0gNzUgTUh6IG9yIGhpZ2hlciBwcm9jZXNzb3IgPC9QPg0KPGEgbmFt
ZT0iZGV4MzIiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5PcGVyYXRpbmcgc3lzdGVtPC9CPiZu
YnNwOyZuYnNwOyZuYnNwO01pY3Jvc29mdCBXaW5kb3dzIDk1Lzk4LCBNaWNyb3NvZnQgV2lu
ZG93cyBOVCB2ZXJzaW9uIDQuMCwgb3IgTWljcm9zb2Z0IFdpbmRvd3MgMjAwMDwvUD4NCjxh
IG5hbWU9ImRleDMzIj48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+TWVtb3J5PC9CPiZuYnNwOyZu
YnNwOyZuYnNwO0ZvciBXaW5kb3dzIDk1Lzk4LCAxNiBNQiBvZiBSQU0gZm9yIHRoZSBvcGVy
YXRpbmcgc3lzdGVtLCBwbHVzIGFuIGFkZGl0aW9uYWwgNCBNQiBvZiBSQU0gZm9yIGVhY2gg
YXBwbGljYXRpb24gcnVubmluZyBzaW11bHRhbmVvdXNseSAoOCBNQiBmb3IgT3V0bG9vayku
IDwvUD4NCjxhIG5hbWU9ImRleDM0Ij48L2E+DQoNCjxQIGNsYXNzPVQ+Rm9yIFdpbmRvd3Mg
TlQgV29ya3N0YXRpb24gdmVyc2lvbiA0LjAgb3IgbGF0ZXIsIDMyIE1CIG9mIFJBTSBmb3Ig
dGhlIG9wZXJhdGluZyBzeXN0ZW0sIHBsdXMgYW4gYWRkaXRpb25hbCA0IE1CIG9mIFJBTSBm
b3IgZWFjaCBhcHBsaWNhdGlvbiBydW5uaW5nIHNpbXVsdGFuZW91c2x5ICg4IE1CIGZvciBP
dXRsb29rKTwvUD4NCjxhIG5hbWU9ImRleDM1Ij48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+QXZh
aWxhYmxlIGhhcmQtZGlzayBzcGFjZTwvQj4mbmJzcDsmbmJzcDsmbmJzcDsxNzggTUIgZm9y
IE9mZmljZSBEaXNjJm5ic3A7MSAoRXhjZWwsIE91dGxvb2ssIGFuZCBXb3JkKTsgMTgyIE1C
IGZvciBPZmZpY2UgRGlzYyZuYnNwOzIgKFB1Ymxpc2hlciBhbmQgU21hbGwgQnVzaW5lc3Mg
VG9vbHMpLiA8L1A+DQo8YSBuYW1lPSJkZXgzNiI+PC9hPg0KDQo8UCBjbGFzcz1UPlRoZXNl
IGZpZ3VyZXMgaW5kaWNhdGUgYSBkZWZhdWx0IGluc3RhbGxhdGlvbjsgeW91ciBoYXJkLWRp
c2sgdXNhZ2UgdmFyaWVzIGRlcGVuZGluZyBvbiB5b3VyIGNvbmZpZ3VyYXRpb24gYW5kIHRo
ZSBvcHRpb25zIHlvdSBjaG9vc2UgdG8gaW5zdGFsbC48L1A+DQo8YSBuYW1lPSJkZXgzNyI+
PC9hPg0KDQo8UCBjbGFzcz1UPjxCPkRpc2sgZHJpdmVzJm5ic3A7Jm5ic3A7Jm5ic3A7PC9C
PkNELVJPTSBkcml2ZTwvUD4NCjxhIG5hbWU9ImRleDM4Ij48L2E+DQoNCjxQIGNsYXNzPVQ+
PEI+TW9uaXRvcjwvQj4mbmJzcDsmbmJzcDsmbmJzcDtWR0Egb3IgaGlnaGVyLXJlc29sdXRp
b24gbW9uaXRvcjsgU3VwZXIgVkdBIHJlY29tbWVuZGVkPC9QPg0KPGEgbmFtZT0iZGV4Mzki
PjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5Qb2ludGluZyBkZXZpY2UmbmJzcDsmbmJzcDsmbmJz
cDs8L0I+TWljcm9zb2Z0IE1vdXNlLCBNaWNyb3NvZnQgSW50ZWxsaU1vdXNlLCBvciBjb21w
YXRpYmxlIHBvaW50aW5nIGRldmljZTwvUD4NCjxhIG5hbWU9ImRleDQwIj48L2E+DQoNCjxQ
IGNsYXNzPVQ+U29tZSBPZmZpY2UmbmJzcDsyMDAwIGZlYXR1cmVzIGhhdmUgYWRkaXRpb25h
bCByZXF1aXJlbWVudHM6PC9QPg0KPGEgbmFtZT0iZGV4NDEiPjwvYT4NCg0KPFAgY2xhc3M9
VD48Qj5Nb2RlbSZuYnNwOyZuYnNwOyZuYnNwOzwvQj45NjAwIG9yIGhpZ2hlci1iYXVkIG1v
ZGVtOyAxNCw0MDAgYmF1ZCByZWNvbW1lbmRlZDwvUD4NCjxhIG5hbWU9ImRleDQyIj48L2E+
DQoNCjxQIGNsYXNzPVQ+PEI+TXVsdGltZWRpYTwvQj4mbmJzcDsmbmJzcDsmbmJzcDtNdWx0
aW1lZGlhIGNvbXB1dGVyIHJlcXVpcmVkIGZvciBzb3VuZCBhbmQgb3RoZXIgbXVsdGltZWRp
YSBlZmZlY3RzPC9QPg0KPGEgbmFtZT0iZGV4NDMiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5F
LW1haWw8L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7TWljcm9zb2Z0IE1haWwsIE1pY3Jvc29mdCBF
eGNoYW5nZSwgSW50ZXJuZXQgU01UUC9QT1AzLCBJTUFQNCwgb3Igb3RoZXIgTUFQSS1jb21w
bGlhbnQgbWVzc2FnaW5nIHNvZnR3YXJlIDwvUD4NCjxhIG5hbWU9ImRleDQ0Ij48L2E+DQoN
CjxQIGNsYXNzPVQ+PEI+Q29sbGFib3JhdGlvbjwvQj4mbmJzcDsmbmJzcDsmbmJzcDtNaWNy
b3NvZnQgRXhjaGFuZ2UgU2VydmVyIHJlcXVpcmVkIGZvciBjZXJ0YWluIGFkdmFuY2VkIGNv
bGxhYm9yYXRpb24gZnVuY3Rpb25hbGl0eSBpbiBPdXRsb29rPC9QPg0KPGEgbmFtZT0iZGV4
NDUiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5JbnRlcm5ldDwvQj4mbmJzcDsmbmJzcDsmbmJz
cDtTb21lIEludGVybmV0IGZ1bmN0aW9uYWxpdHkgbWF5IHJlcXVpcmUgSW50ZXJuZXQgYWNj
ZXNzIGFuZCBwYXltZW50IG9mIGEgc2VwYXJhdGUgZmVlIHRvIGEgc2VydmljZSBwcm92aWRl
ciwgYW5kIGxvY2FsIGNoYXJnZXMgbWF5IGFwcGx5LjwvUD4NCg0KPHAgY2xhc3M9dCBhbGln
bj1yaWdodD48Yj48YSBocmVmPSIjdG9wIj5Ub3A8L2E+PC9iPjwvcD4NCg0KPEg0Pk1pY3Jv
c29mdCBPZmZpY2UmbmJzcDsyMDAwIFByb2Zlc3Npb25hbDwvSDQ+DQo8YSBuYW1lPSJkZXg0
NiI+PC9hPg0KDQoNCg0KDQoNCg0KDQo8UCBjbGFzcz1UPk1pY3Jvc29mdCBPZmZpY2UmbmJz
cDsyMDAwIFByb2Zlc3Npb25hbCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIGFwcGxpY2F0aW9u
czo8L1A+DQo8YSBuYW1lPSJkZXg0NyI+PC9hPg0KDQo8VUw+DQoJPExJIGNsYXNzPUxCMT5N
aWNyb3NvZnQgQWNjZXNzIDIwMDA8L2xpPg0KDQo8YSBuYW1lPSJkZXg0OCI+PC9hPg0KDQoN
Cgk8TEkgY2xhc3M9TEIxPk1pY3Jvc29mdCBFeGNlbCAyMDAwPC9saT4NCg0KPGEgbmFtZT0i
ZGV4NDkiPjwvYT4NCg0KDQoJPExJIGNsYXNzPUxCMT5NaWNyb3NvZnQgT3V0bG9vayAyMDAw
PC9saT4NCg0KPGEgbmFtZT0iZGV4NTAiPjwvYT4NCg0KDQoJPExJIGNsYXNzPUxCMT5NaWNy
b3NvZnQgUG93ZXJQb2ludCAyMDAwPC9saT4NCg0KPGEgbmFtZT0iZGV4NTEiPjwvYT4NCg0K
DQoJPExJIGNsYXNzPUxCMT5NaWNyb3NvZnQgUHVibGlzaGVyIDIwMDA8L2xpPg0KDQo8YSBu
YW1lPSJkZXg1MiI+PC9hPg0KDQoNCgk8TEkgY2xhc3M9TEIxPk1pY3Jvc29mdCBXb3JkIDIw
MDA8L2xpPg0KDQo8YSBuYW1lPSJkZXg1MyI+PC9hPg0KDQoNCgk8TEkgY2xhc3M9TEIxPk1p
Y3Jvc29mdCBTbWFsbCBCdXNpbmVzcyBUb29sczwvbGk+DQo8L1VMPg0KDQoNCjxhIG5hbWU9
ImRleDU0Ij48L2E+DQoNCjxQIGNsYXNzPVQ+VG8gdXNlIE1pY3Jvc29mdCBPZmZpY2UmbmJz
cDsyMDAwIFByb2Zlc3Npb25hbCwgdXNlcnOSIGNvbXB1dGVycyBtdXN0IG1lZXQgdGhlIGZv
bGxvd2luZyByZXF1aXJlbWVudHM6PC9QPg0KPGEgbmFtZT0iZGV4NTUiPjwvYT4NCg0KPFAg
Y2xhc3M9VD48Qj5Qcm9jZXNzb3I8L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7UGVudGl1bSA3NSBN
SHogb3IgaGlnaGVyIHByb2Nlc3NvciA8L1A+DQo8YSBuYW1lPSJkZXg1NiI+PC9hPg0KDQo8
UCBjbGFzcz1UPjxCPk9wZXJhdGluZyBzeXN0ZW08L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7TWlj
cm9zb2Z0IFdpbmRvd3MgOTUvOTgsIE1pY3Jvc29mdCBXaW5kb3dzIE5UIHZlcnNpb24gNC4w
LCBvciBNaWNyb3NvZnQgV2luZG93cyAyMDAwPC9QPg0KPGEgbmFtZT0iZGV4NTciPjwvYT4N
Cg0KPFAgY2xhc3M9VD48Qj5NZW1vcnk8L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIFdpbmRv
d3MgOTUvOTgsIDE2IE1CIG9mIFJBTSBmb3IgdGhlIG9wZXJhdGluZyBzeXN0ZW0sIHBsdXMg
YW4gYWRkaXRpb25hbCA0IE1CIG9mIFJBTSBmb3IgZWFjaCBhcHBsaWNhdGlvbiBydW5uaW5n
IHNpbXVsdGFuZW91c2x5ICg4IE1CIGZvciBBY2Nlc3Mgb3IgT3V0bG9vaykuIDwvUD4NCjxh
IG5hbWU9ImRleDU4Ij48L2E+DQoNCjxQIGNsYXNzPVQ+Rm9yIFdpbmRvd3MgTlQgV29ya3N0
YXRpb24gdmVyc2lvbiA0LjAgb3IgbGF0ZXIsIDMyIE1CIG9mIFJBTSBmb3IgdGhlIG9wZXJh
dGluZyBzeXN0ZW0sIHBsdXMgYW4gYWRkaXRpb25hbCA0IE1CIG9mIFJBTSBmb3IgZWFjaCBh
cHBsaWNhdGlvbiBydW5uaW5nIHNpbXVsdGFuZW91c2x5ICg4IE1CIGZvciBBY2Nlc3Mgb3Ig
T3V0bG9vayk8L1A+DQo8YSBuYW1lPSJkZXg1OSI+PC9hPg0KDQo8UCBjbGFzcz1UPjxCPkF2
YWlsYWJsZSBoYXJkLWRpc2sgc3BhY2U8L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7MjE3IE1CIGZv
ciBPZmZpY2UgRGlzYyZuYnNwOzEgKEFjY2VzcywgRXhjZWwsIE91dGxvb2ssIFBvd2VyUG9p
bnQsIGFuZCBXb3JkKTsgMTc0IE1CIGZvciBPZmZpY2UgRGlzYyZuYnNwOzIgKFB1Ymxpc2hl
ciBhbmQgU21hbGwgQnVzaW5lc3MgVG9vbHMpLiA8L1A+DQo8YSBuYW1lPSJkZXg2MCI+PC9h
Pg0KDQo8UCBjbGFzcz1UPlRoZXNlIGZpZ3VyZXMgaW5kaWNhdGUgYSBkZWZhdWx0IGluc3Rh
bGxhdGlvbjsgeW91ciBoYXJkLWRpc2sgdXNhZ2UgdmFyaWVzIGRlcGVuZGluZyBvbiB5b3Vy
IGNvbmZpZ3VyYXRpb24gYW5kIHRoZSBvcHRpb25zIHlvdSBjaG9vc2UgdG8gaW5zdGFsbC48
L1A+DQo8YSBuYW1lPSJkZXg2MSI+PC9hPg0KDQo8UCBjbGFzcz1UPjxCPkRpc2sgZHJpdmVz
Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9CPkNELVJPTSBkcml2ZTwvUD4NCjxhIG5hbWU9ImRleDYy
Ij48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+TW9uaXRvcjwvQj4mbmJzcDsmbmJzcDsmbmJzcDtW
R0Egb3IgaGlnaGVyLXJlc29sdXRpb24gbW9uaXRvcjsgU3VwZXIgVkdBIHJlY29tbWVuZGVk
PC9QPg0KPGEgbmFtZT0iZGV4NjMiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5Qb2ludGluZyBk
ZXZpY2UmbmJzcDsmbmJzcDsmbmJzcDs8L0I+TWljcm9zb2Z0IE1vdXNlLCBNaWNyb3NvZnQg
SW50ZWxsaU1vdXNlLCBvciBjb21wYXRpYmxlIHBvaW50aW5nIGRldmljZTwvUD4NCjxhIG5h
bWU9ImRleDY0Ij48L2E+DQoNCjxQIGNsYXNzPVQ+U29tZSBPZmZpY2UmbmJzcDsyMDAwIGZl
YXR1cmVzIGhhdmUgYWRkaXRpb25hbCByZXF1aXJlbWVudHM6PC9QPg0KPGEgbmFtZT0iZGV4
NjUiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5Nb2RlbSZuYnNwOyZuYnNwOyZuYnNwOzwvQj45
NjAwIG9yIGhpZ2hlci1iYXVkIG1vZGVtOyAxNCw0MDAgYmF1ZCByZWNvbW1lbmRlZDwvUD4N
CjxhIG5hbWU9ImRleDY2Ij48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+TXVsdGltZWRpYTwvQj4m
bmJzcDsmbmJzcDsmbmJzcDtNdWx0aW1lZGlhIGNvbXB1dGVyIHJlcXVpcmVkIGZvciBzb3Vu
ZCBhbmQgb3RoZXIgbXVsdGltZWRpYSBlZmZlY3RzPC9QPg0KPGEgbmFtZT0iZGV4NjciPjwv
YT4NCg0KPFAgY2xhc3M9VD48Qj5FLW1haWw8L0I+Jm5ic3A7Jm5ic3A7Jm5ic3A7TWljcm9z
b2Z0IE1haWwsIE1pY3Jvc29mdCBFeGNoYW5nZSwgSW50ZXJuZXQgU01UUC9QT1AzLCBJTUFQ
NCwgb3Igb3RoZXIgTUFQSS1jb21wbGlhbnQgbWVzc2FnaW5nIHNvZnR3YXJlIDwvUD4NCjxh
IG5hbWU9ImRleDY4Ij48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+Q29sbGFib3JhdGlvbjwvQj4m
bmJzcDsmbmJzcDsmbmJzcDtNaWNyb3NvZnQgRXhjaGFuZ2UgU2VydmVyIHJlcXVpcmVkIGZv
ciBjZXJ0YWluIGFkdmFuY2VkIGNvbGxhYm9yYXRpb24gZnVuY3Rpb25hbGl0eSBpbiBPdXRs
b29rPC9QPg0KPGEgbmFtZT0iZGV4NjkiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5JbnRlcm5l
dDwvQj4mbmJzcDsmbmJzcDsmbmJzcDtTb21lIEludGVybmV0IGZ1bmN0aW9uYWxpdHkgbWF5
IHJlcXVpcmUgSW50ZXJuZXQgYWNjZXNzIGFuZCBwYXltZW50IG9mIGEgc2VwYXJhdGUgZmVl
IHRvIGEgc2VydmljZSBwcm92aWRlciwgYW5kIGxvY2FsIGNoYXJnZXMgbWF5IGFwcGx5Ljwv
UD4NCg0KPHAgY2xhc3M9dCBhbGlnbj1yaWdodD48Yj48YSBocmVmPSIjdG9wIj5Ub3A8L2E+
PC9iPjwvcD4NCg0KPEg0Pk1pY3Jvc29mdCBPZmZpY2UmbmJzcDsyMDAwIFByZW1pdW08L0g0
Pg0KPGEgbmFtZT0iZGV4NzAiPjwvYT4NCg0KDQoNCg0KDQoNCg0KPFAgY2xhc3M9VD5NaWNy
b3NvZnQgT2ZmaWNlJm5ic3A7MjAwMCBQcmVtaXVtIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcg
YXBwbGljYXRpb25zOjwvUD4NCjxhIG5hbWU9ImRleDcxIj48L2E+DQoNCjxVTD4NCgk8TEkg
Y2xhc3M9TEIxPk1pY3Jvc29mdCBBY2Nlc3MgMjAwMDwvbGk+DQoNCjxhIG5hbWU9ImRleDcy
Ij48L2E+DQoNCg0KCTxMSSBjbGFzcz1MQjE+TWljcm9zb2Z0IEV4Y2VsIDIwMDA8L2xpPg0K
DQo8YSBuYW1lPSJkZXg3MyI+PC9hPg0KDQoNCgk8TEkgY2xhc3M9TEIxPk1pY3Jvc29mdCBG
cm9udFBhZ2UgMjAwMDwvbGk+DQoNCjxhIG5hbWU9ImRleDc0Ij48L2E+DQoNCg0KCTxMSSBj
bGFzcz1MQjE+TWljcm9zb2Z0IE91dGxvb2sgMjAwMDwvbGk+DQoNCjxhIG5hbWU9ImRleDc1
Ij48L2E+DQoNCg0KCTxMSSBjbGFzcz1MQjE+TWljcm9zb2Z0IFBob3RvRHJhdyAyMDAwPC9s
aT4NCg0KPGEgbmFtZT0iZGV4NzYiPjwvYT4NCg0KDQoJPExJIGNsYXNzPUxCMT5NaWNyb3Nv
ZnQgUG93ZXJQb2ludCAyMDAwPC9saT4NCg0KPGEgbmFtZT0iZGV4NzciPjwvYT4NCg0KDQoJ
PExJIGNsYXNzPUxCMT5NaWNyb3NvZnQgUHVibGlzaGVyIDIwMDA8L2xpPg0KDQo8YSBuYW1l
PSJkZXg3OCI+PC9hPg0KDQoNCgk8TEkgY2xhc3M9TEIxPk1pY3Jvc29mdCBXb3JkIDIwMDA8
L2xpPg0KDQo8YSBuYW1lPSJkZXg3OSI+PC9hPg0KDQoNCgk8TEkgY2xhc3M9TEIxPk1pY3Jv
c29mdCBTbWFsbCBCdXNpbmVzcyBUb29sczwvbGk+DQo8L3VsPg0KDQoNCjxhIG5hbWU9ImRl
eDgwIj48L2E+DQoNCjxQIGNsYXNzPVQ+VG8gdXNlIE1pY3Jvc29mdCBPZmZpY2UmbmJzcDsy
MDAwIFByZW1pdW0sIHVzZXJzkiBjb21wdXRlcnMgbXVzdCBtZWV0IHRoZSBmb2xsb3dpbmcg
cmVxdWlyZW1lbnRzOjwvUD4NCjxhIG5hbWU9ImRleDgxIj48L2E+DQoNCjxQIGNsYXNzPVQ+
PEI+UHJvY2Vzc29yPC9CPiZuYnNwOyZuYnNwOyZuYnNwO1BlbnRpdW0gNzUgTUh6IG9yIGhp
Z2hlciBwcm9jZXNzb3I7IFBlbnRpdW0gMTY2IG9yIGhpZ2hlciByZXF1aXJlZCBmb3IgUGhv
dG9EcmF3PC9QPg0KPGEgbmFtZT0iZGV4ODIiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5PcGVy
YXRpbmcgc3lzdGVtPC9CPiZuYnNwOyZuYnNwOyZuYnNwO01pY3Jvc29mdCBXaW5kb3dzIDk1
Lzk4LCBNaWNyb3NvZnQgV2luZG93cyBOVCB2ZXJzaW9uIDQuMCwgb3IgTWljcm9zb2Z0IFdp
bmRvd3MgMjAwMDwvUD4NCjxhIG5hbWU9ImRleDgzIj48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+
TWVtb3J5PC9CPiZuYnNwOyZuYnNwOyZuYnNwO0ZvciBXaW5kb3dzIDk1Lzk4LCAxNiBNQiBv
ZiBSQU0gZm9yIHRoZSBvcGVyYXRpbmcgc3lzdGVtLCBwbHVzIGFuIGFkZGl0aW9uYWwgNCBN
QiBvZiBSQU0gZm9yIGVhY2ggYXBwbGljYXRpb24gcnVubmluZyBzaW11bHRhbmVvdXNseSAo
OCBNQiBmb3IgQWNjZXNzLCBGcm9udFBhZ2UsIG9yIE91dGxvb2s7IDE2IE1CIGZvciBQaG90
b0RyYXcpLiA8L1A+DQo8YSBuYW1lPSJkZXg4NCI+PC9hPg0KDQo8UCBjbGFzcz1UPkZvciBX
aW5kb3dzIE5UIFdvcmtzdGF0aW9uIHZlcnNpb24gNC4wIG9yIGxhdGVyLCAzMiBNQiBvZiBS
QU0gZm9yIHRoZSBvcGVyYXRpbmcgc3lzdGVtLCBwbHVzIGFuIGFkZGl0aW9uYWwgNCBNQiBv
ZiBSQU0gZm9yIGVhY2ggYXBwbGljYXRpb24gcnVubmluZyBzaW11bHRhbmVvdXNseSAoOCBN
QiBmb3IsIEFjY2VzcywgRnJvbnRQYWdlLCBvciBPdXRsb29rOyAxNiBNQiBmb3IgUGhvdG9E
cmF3KTwvUD4NCjxhIG5hbWU9ImRleDg1Ij48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+QXZhaWxh
YmxlIGhhcmQtZGlzayBzcGFjZTwvQj4mbmJzcDsmbmJzcDsmbmJzcDsyNTIgTUIgZm9yIE9m
ZmljZSBEaXNjJm5ic3A7MSAoQWNjZXNzLCBFeGNlbCwgRnJvbnRQYWdlLCBPdXRsb29rLCBQ
b3dlclBvaW50LCBhbmQgV29yZCk7IDE3NCBNQiBmb3IgT2ZmaWNlIERpc2MmbmJzcDsyIChQ
dWJsaXNoZXIgYW5kIFNtYWxsIEJ1c2luZXNzIFRvb2xzKTsgMTAwIE1CIGZvciBPZmZpY2Ug
RGlzYyZuYnNwOzMgKFBob3RvRHJhdykuIDwvUD4NCjxhIG5hbWU9ImRleDg2Ij48L2E+DQoN
CjxQIGNsYXNzPVQ+Rm9yIG9wdGltYWwgcGVyZm9ybWFuY2UsIGFuIGFkZGl0aW9uYWwgMTAw
IE1CIG9mIGF2YWlsYWJsZSBoYXJkLWRpc2sgc3BhY2UgaXMgcmVjb21tZW5kZWQgZm9yIHVz
ZSBieSB0aGUgV2luZG93cyBzd2FwIGZpbGUuIDwvUD4NCjxhIG5hbWU9ImRleDg3Ij48L2E+
DQoNCjxQIGNsYXNzPVQ+VGhlc2UgZmlndXJlcyBpbmRpY2F0ZSBhIGRlZmF1bHQgaW5zdGFs
bGF0aW9uOyB5b3VyIGhhcmQtZGlzayB1c2FnZSB2YXJpZXMgZGVwZW5kaW5nIG9uIHlvdXIg
Y29uZmlndXJhdGlvbiBhbmQgdGhlIG9wdGlvbnMgeW91IGNob29zZSB0byBpbnN0YWxsLjwv
UD4NCjxhIG5hbWU9ImRleDg4Ij48L2E+DQoNCjxQIGNsYXNzPVQ+PEI+RGlzayBkcml2ZXMm
bmJzcDsmbmJzcDsmbmJzcDs8L0I+Q0QtUk9NIGRyaXZlPC9QPg0KPGEgbmFtZT0iZGV4ODki
PjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5Nb25pdG9yPC9CPiZuYnNwOyZuYnNwOyZuYnNwO1ZH
QSBvciBoaWdoZXItcmVzb2x1dGlvbiBtb25pdG9yOyBTdXBlciBWR0EgcmVjb21tZW5kZWQ8
L1A+DQo8YSBuYW1lPSJkZXg5MCI+PC9hPg0KDQo8UCBjbGFzcz1UPjxCPlBvaW50aW5nIGRl
dmljZSZuYnNwOyZuYnNwOyZuYnNwOzwvQj5NaWNyb3NvZnQgTW91c2UsIE1pY3Jvc29mdCBJ
bnRlbGxpTW91c2UsIG9yIGNvbXBhdGlibGUgcG9pbnRpbmcgZGV2aWNlPC9QPg0KPGEgbmFt
ZT0iZGV4OTEiPjwvYT4NCg0KPFAgY2xhc3M9VD5Tb21lIE9mZmljZSZuYnNwOzIwMDAgZmVh
dHVyZXMgaGF2ZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50czo8L1A+DQo8YSBuYW1lPSJkZXg5
MiI+PC9hPg0KDQo8UCBjbGFzcz1UPjxCPk1vZGVtJm5ic3A7Jm5ic3A7Jm5ic3A7PC9CPjk2
MDAgb3IgaGlnaGVyLWJhdWQgbW9kZW07IDE0LDQwMCBiYXVkIHJlY29tbWVuZGVkPC9QPg0K
PGEgbmFtZT0iZGV4OTMiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5NdWx0aW1lZGlhPC9CPiZu
YnNwOyZuYnNwOyZuYnNwO011bHRpbWVkaWEgY29tcHV0ZXIgcmVxdWlyZWQgZm9yIHNvdW5k
IGFuZCBvdGhlciBtdWx0aW1lZGlhIGVmZmVjdHM8L1A+DQo8YSBuYW1lPSJkZXg5NCI+PC9h
Pg0KDQo8UCBjbGFzcz1UPjxCPkUtbWFpbDwvQj4mbmJzcDsmbmJzcDsmbmJzcDtNaWNyb3Nv
ZnQgTWFpbCwgTWljcm9zb2Z0IEV4Y2hhbmdlLCBJbnRlcm5ldCBTTVRQL1BPUDMsIElNQVA0
LCBvciBvdGhlciBNQVBJLWNvbXBsaWFudCBtZXNzYWdpbmcgc29mdHdhcmUgPC9QPg0KPGEg
bmFtZT0iZGV4OTUiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5Db2xsYWJvcmF0aW9uPC9CPiZu
YnNwOyZuYnNwOyZuYnNwO01pY3Jvc29mdCBFeGNoYW5nZSBTZXJ2ZXIgcmVxdWlyZWQgZm9y
IGNlcnRhaW4gYWR2YW5jZWQgY29sbGFib3JhdGlvbiBmdW5jdGlvbmFsaXR5IGluIE91dGxv
b2s8L1A+DQo8YSBuYW1lPSJkZXg5NiI+PC9hPg0KDQo8UCBjbGFzcz1UPjxCPkludGVybmV0
PC9CPiZuYnNwOyZuYnNwOyZuYnNwO1NvbWUgSW50ZXJuZXQgZnVuY3Rpb25hbGl0eSBtYXkg
cmVxdWlyZSBJbnRlcm5ldCBhY2Nlc3MgYW5kIHBheW1lbnQgb2YgYSBzZXBhcmF0ZSBmZWUg
dG8gYSBzZXJ2aWNlIHByb3ZpZGVyLCBhbmQgbG9jYWwgY2hhcmdlcyBtYXkgYXBwbHkuPC9Q
Pg0KDQo8cCBjbGFzcz10IGFsaWduPXJpZ2h0PjxiPjxhIGhyZWY9IiN0b3AiPlRvcDwvYT48
L2I+PC9wPg0KDQo8SDQ+TWljcm9zb2Z0IE9mZmljZSZuYnNwOzIwMDAgRGV2ZWxvcGVyPC9I
ND4NCjxhIG5hbWU9ImRleDk3Ij48L2E+DQoNCg0KDQoNCg0KDQoNCjxQIGNsYXNzPVQ+TWlj
cm9zb2Z0IE9mZmljZSZuYnNwOzIwMDAgRGV2ZWxvcGVyIGluY2x1ZGVzIHRoZSBzYW1lIGFw
cGxpY2F0aW9ucyBhcyBNaWNyb3NvZnQgT2ZmaWNlJm5ic3A7MjAwMCBQcmVtaXVtLCBwbHVz
IHRoZSBmb2xsb3dpbmcgYXBwbGljYXRpb25zIGFuZCB0b29sczo8L1A+DQo8YSBuYW1lPSJk
ZXg5OCI+PC9hPg0KDQo8VUw+DQoJPExJIGNsYXNzPUxCMT5PZmZpY2UmbmJzcDsyMDAwIERl
dmVsb3BlciBUb29sczwvbGk+DQoNCjxhIG5hbWU9ImRleDk5Ij48L2E+DQoNCg0KCTxMSSBj
bGFzcz1MQjE+TVNETiBMaWJyYXJ5PC9saT4NCg0KPGEgbmFtZT0iZGV4MTAwIj48L2E+DQoN
Cg0KCTxMSSBjbGFzcz1MQjE+VmlzdWFsIFNvdXJjZVNhZmUgNi4wPC9saT4NCg0KPGEgbmFt
ZT0iZGV4MTAxIj48L2E+DQoNCg0KCTxMSSBjbGFzcz1MQjE+TWljcm9zb2Z0IEFjY2VzcyAy
MDAwIFJ1bnRpbWUgU2V0dXA8L2xpPg0KDQo8YSBuYW1lPSJkZXgxMDIiPjwvYT4NCg0KDQoJ
PExJIGNsYXNzPUxCMT5NaWNyb3NvZnQgQW5zd2VyIFdpemFyZCBCdWlsZGVyPC9saT4NCg0K
PGEgbmFtZT0iZGV4MTAzIj48L2E+DQoNCg0KCTxMSSBjbGFzcz1MQjE+TWljcm9zb2Z0IEFn
ZW50IENoYXJhY3RlciBFZGl0b3I8L2xpPg0KDQo8YSBuYW1lPSJkZXgxMDQiPjwvYT4NCg0K
DQoJPExJIGNsYXNzPUxCMT5IVE1MIEhlbHAgV29ya3Nob3A8L2xpPg0KPC9VTD4NCg0KDQo8
YSBuYW1lPSJkZXgxMDUiPjwvYT4NCg0KPFAgY2xhc3M9VD5NaWNyb3NvZnQgT2ZmaWNlJm5i
c3A7MjAwMCBEZXZlbG9wZXIgaGFzIHRoZSBzYW1lIHN5c3RlbSByZXF1aXJlbWVudHMgYXMg
TWljcm9zb2Z0IE9mZmljZSZuYnNwOzIwMDAgUHJlbWl1bSwgd2l0aCB0aGUgZXhjZXB0aW9u
IG9mIGFkZGl0aW9uYWwgaGFyZCBkaXNrIHNwYWNlIHJlcXVpcmVtZW50cy4gUmVxdWlyZWQg
aGFyZCBkaXNrIHNwYWNlIHZhcmllcywgZGVwZW5kaW5nIG9uIHdoaWNoIHRvb2xzIGFuZCBk
b2N1bWVudGF0aW9uIGZpbGVzIGFyZSBpbnN0YWxsZWQ8L1A+DQoNCjxINT5NaW5pbXVtIGlu
c3RhbGxhdGlvbjwvSDU+DQo8YSBuYW1lPSJkZXgxMDYiPjwvYT4NCg0KPFAgY2xhc3M9VD5B
IG1pbmltdW0gaW5zdGFsbGF0aW9uIGNvbnNpc3RzIG9mIE9mZmljZSZuYnNwOzIwMDAgRGV2
ZWxvcGVyIFRvb2xzIChNU0ROIExpYnJhcnkgbm90IGluc3RhbGxlZCkgaGFzIHRoZSBmb2xs
b3dpbmcgaGFyZCBkaXNrIHNwYWNlIHJlcXVpcmVtZW50cy48L1A+DQo8YSBuYW1lPSJkZXgx
MDciPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5TeXN0ZW0gZmlsZXM8L0I+Jm5ic3A7Jm5ic3A7
Jm5ic3A7MzAgTUIgPC9QPg0KPGEgbmFtZT0iZGV4MTA4Ij48L2E+DQoNCjxQIGNsYXNzPVQ+
PEI+UHJvZ3JhbSBmaWxlczwvQj4mbmJzcDsmbmJzcDsmbmJzcDszMCBNQiA8L1A+DQoNCjxI
NT5NU0ROIExpYnJhcnk8L0g1Pg0KPGEgbmFtZT0iZGV4MTA5Ij48L2E+DQoNCjxQIGNsYXNz
PVQ+QSBtaW5pbXVtIGluc3RhbGxhdGlvbiBwbHVzIE1TRE4gTGlicmFyeSBoYXMgdGhlIGZv
bGxvd2luZyBoYXJkIGRpc2sgc3BhY2UgcmVxdWlyZW1lbnRzLjwvUD4NCjxhIG5hbWU9ImRl
eDExMCI+PC9hPg0KDQo8UCBjbGFzcz1UPjxCPlN5c3RlbSBmaWxlcyZuYnNwOyZuYnNwOyZu
YnNwOzwvQj4zNSBNQiA8L1A+DQo8YSBuYW1lPSJkZXgxMTEiPjwvYT4NCg0KPFAgY2xhc3M9
VD48Qj5Qcm9ncmFtIGZpbGVzPC9CPiZuYnNwOyZuYnNwOyZuYnNwOzkwIE1CIDwvUD4NCg0K
PEg1Pk1heGltdW0gaW5zdGFsbGF0aW9uPC9INT4NCjxhIG5hbWU9ImRleDExMiI+PC9hPg0K
DQo8UCBjbGFzcz1UPkEgbWF4aW11bSBpbnN0YWxsYXRpb24sIHdoaWNoIGluY2x1ZGVzIGFs
bCBvZiB0aGUgT2ZmaWNlJm5ic3A7MjAwMCBEZXZlbG9wZXIgYXBwbGljYXRpb25zIGFuZCB0
b29scywgaGFzIHRoZSBmb2xsb3dpbmcgaGFyZCBkaXNrIHNwYWNlIHJlcXVpcmVtZW50cy48
L1A+DQo8YSBuYW1lPSJkZXgxMTMiPjwvYT4NCg0KPFAgY2xhc3M9VD48Qj5TeXN0ZW0gZmls
ZXMmbmJzcDsmbmJzcDsmbmJzcDs8L0I+NDUgTUIgPC9QPg0KPGEgbmFtZT0iZGV4MTE0Ij48
L2E+DQoNCjxQIGNsYXNzPVQ+PEI+UHJvZ3JhbSBmaWxlczwvQj4mbmJzcDsmbmJzcDsmbmJz
cDszMDAgTUIgPC9QPg0KDQo8UCBjbGFzcz1UQlQ+PEI+VG9vbGJveDwvQj4mbmJzcDsmbmJz
cDsmbmJzcDtZb3UgY2FuIHZpZXcgYSBsaXN0IG9mIGFsbCB0aGUgZmlsZXMgaW5zdGFsbGVk
IGZvciBlYWNoIE9mZmljZSZuYnNwOzIwMDAgZmVhdHVyZSBpbiBhbiBFeGNlbCB3b3JrYm9v
ayBuYW1lZCBGaWxlbGlzdC54bHMuIEZpbGVsaXN0LnhscyBhbHNvIGluY2x1ZGVzIGluZm9y
bWF0aW9uIGFib3V0IGZpbGUgc2l6ZXMsIGluc3RhbGxhdGlvbiBmb2xkZXJzLCBhbmQgc3Vw
cG9ydGVkIHZlcnNpb25zIG9mIFdpbmRvd3MuIEZvciBpbmZvcm1hdGlvbiBhYm91dCBpbnN0
YWxsaW5nIHRoaXMgd29ya2Jvb2ssIHNlZSA8YSBIUkVGPSIuLi9hcHBuZHgvOTV0Ml80Lmh0
bSI+T2ZmaWNlIEluZm9ybWF0aW9uPC9hPi48L1A+DQoNCg0KDQo8cCBjbGFzcz10IGFsaWdu
PXJpZ2h0PjxiPjxhIGhyZWY9IiN0b3AiPlRvcDwvYT48L2I+PC9wPg0KDQo8SDQ+U2VlIGFs
c288L0g0Pg0KPGEgbmFtZT0iZGV4MTE1Ij48L2E+DQoNCjxQIGNsYXNzPVQ+U29tZSBvZiB0
aGUgZmVhdHVyZXMgYXZhaWxhYmxlIHRvIE1pY3Jvc29mdCBPZmZpY2UmbmJzcDsyMDAwIHVz
ZXJzIGRlcGVuZCBvbiB3aGljaCBXZWIgYnJvd3NlciBpcyBpbnN0YWxsZWQgb24gdXNlcnOS
IGNvbXB1dGVycywgYW5kIG9uIHdoaWNoIFdlYiBzZXJ2ZXIgY29tcG9uZW50cyBhcmUgaW5z
dGFsbGVkIG9uIHRoZSBvcmdhbml6YXRpb26ScyBzZXJ2ZXJzLiBGb3IgaW5mb3JtYXRpb24g
YWJvdXQgV2ViIGJyb3dzZXIgYW5kIFdlYiBzZXJ2ZXIgcmVxdWlyZW1lbnRzLCBzZWUgPGEg
SFJFRj0iLi4vb25lLzEwdDIuaHRtIj5JbnRlcm5ldCBhbmQgSW50cmFuZXQgVGVjaG5vbG9n
aWVzPC9hPi48L1A+DQo8YSBuYW1lPSJkZXgxMTYiPjwvYT4NCg0KPFAgY2xhc3M9VD5Tb21l
IG9mIHRoZSBmZWF0dXJlcyBhdmFpbGFibGUgdG8gTWljcm9zb2Z0IE9mZmljZSZuYnNwOzIw
MDAgdXNlcnMgZGVwZW5kIG9uIHdoaWNoIG1lc3NhZ2luZyBzZXJ2aWNlcyBhcmUgYXZhaWxh
YmxlIG9uIHVzZXJzkiBjb21wdXRlcnMuIEZvciBpbmZvcm1hdGlvbiBhYm91dCBlLW1haWwg
c2VydmVycyBhbmQgbWVzc2FnaW5nIHNlcnZpY2VzIHN1cHBvcnRlZCBieSBPZmZpY2UmbmJz
cDsyMDAwIGFwcGxpY2F0aW9ucywgc2VlIDxhIEhSRUY9Ii4uL29uZS8xMGN0XzMuaHRtIj5P
ZmZpY2UmbmJzcDsyMDAwIGFuZCBFLW1haWwgU2VydmVyczwvYT4uPC9QPg0KPGEgbmFtZT0i
ZGV4MTE3Ij48L2E+DQoNCjxQIGNsYXNzPVQ+U29tZSBkYXRhIGFjY2VzcyBmZWF0dXJlcyBh
dmFpbGFibGUgdG8gT2ZmaWNlJm5ic3A7MjAwMCB1c2VycyBkZXBlbmQgb24gdGhlIGRhdGEg
YWNjZXNzIGNvbXBvbmVudHMgdGhhdCBhcmUgaW5zdGFsbGVkIG9uIHVzZXJzkiBjb21wdXRl
cnMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGRhdGEgYWNjZXNzIHRlY2hub2xvZ2ll
cywgc2VlIDxhIEhSRUY9Ii4uL29uZS8xMHQzXzMuaHRtIj5PZmZpY2UmbmJzcDsyMDAwIGFu
ZCBEYXRhIENvbm5lY3Rpdml0eSBUZWNobm9sb2dpZXM8L2E+LjwvUD4NCjxhIG5hbWU9ImRl
eDExOCI+PC9hPg0KDQo8UCBjbGFzcz1UPlNvbWUgZGF0YSBhY2Nlc3MgZmVhdHVyZXMgYXZh
aWxhYmxlIHRvIE9mZmljZSZuYnNwOzIwMDAgdXNlcnMgYWxzbyBkZXBlbmQgb24gdGhlIGRh
dGFiYXNlIHNlcnZlcnMgdGhhdCBhcmUgYXZhaWxhYmxlIG9uIGFuIG9yZ2FuaXphdGlvbpJz
IG5ldHdvcmsuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBzZWUgPGEgSFJFRj0iLi4vb25lLzEw
Y3RfNC5odG0iPk9mZmljZSZuYnNwOzIwMDAgYW5kIERhdGFiYXNlIFNlcnZlcnM8L2E+Ljwv
UD4NCjxhIG5hbWU9ImRleDExOSI+PC9hPg0KDQo8UCBjbGFzcz1UPk1pY3Jvc29mdCBPZmZp
Y2UmbmJzcDsyMDAwIHByb3ZpZGVzIHlvdSB3aXRoIHRoZSBmbGV4aWJpbGl0eSB0byBjdXN0
b21pemUgYW5kIGluc3RhbGwgT2ZmaWNlIGluIGEgbnVtYmVyIG9mIGRpZmZlcmVudCB3YXlz
LiBGb3IgaW5mb3JtYXRpb24gYWJvdXQgaW5zdGFsbGF0aW9uIG9wdGlvbnMsIHNlZSA8YSBI
UkVGPSIuLi90d28vMzB0Mi5odG0iPkJhc2ljIEluc3RhbGxhdGlvbiBNZXRob2RzPC9hPi48
L1A+DQo8QlI+DQoNCg0KPC9URD4NCg0KDQoNCjwhLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0gRU5EIFBBR0UgQ09OVEVOVCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLT4NCg0KDQoNCjwhLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gU1RBUlQg
UFJFVi9ORVhUIE5BVklHQVRJT04gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+
DQoNCg0KPHRkIGFsaWduPXJpZ2h0IHdpZHRoPTgwPg0KDQoNCg0KCTx0YWJsZSBhbGlnbj0i
cmlnaHQiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9Im1hcmdpbi10
b3A6IDVweDsiIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij4NCjx0cj4NCiAgICA8dGQ+
PEEgSFJFRj0iMDV0Mi5odG0iPjxpbWcgc3JjPSIuLi9pbWFnZXMvY29udGVudHMuZ2lmIiBi
b3JkZXI9MCBhbHQ9IlRvcGljIENvbnRlbnRzIiB2c3BhY2U9MT48L0E+PC90ZD4NCjwvdHI+
DQo8dHI+DQogICAgPHRkPjxhIGhyZWY9IjA1dDJfMi5odG0iPjxpbWcgc3JjPSIuLi9pbWFn
ZXMvbmV4dC5naWYiIGJvcmRlcj0wIGFsdD0iTmV4dCI+PC9hPjwvdGQ+DQo8L3RyPg0KDQoN
CjwvdGFibGU+DQoNCg0KPCEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBFTkQg
UFJFVi9ORVhUIE5BVklHQVRJT04gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+
DQoNCjwvdGQ+DQo8L3RyPg0KPC90YWJsZT4NCg0KPCEtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSBCRUdJTiBQQUdFIEZPT1RFUiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLT4NCjxjZW50ZXI+DQo8dGFibGUgd2lkdGg9NDUwIHN0eWxlPSJtYXJnaW4tbGVm
dDogODBweDsiPg0KPFRSPjxURCBDT0xTUEFOPTMgYWxpZ249Y2VudGVyPjxIUiB3aWR0aD01
MDA+DQo8Rk9OVCBGQUNFPSJ2ZXJkYW5hLCBoZWx2ZXRpY2EsIGFyaWFsIiBTSVpFPTIgY29s
b3I9IzAwMzM5OT48Yj48YSBocmVmPSIwNXQyLmh0bSI+VG9waWMgQ29udGVudHM8L2E+PC9i
PiZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDs8Yj48QSBIUkVGPSIwNXQy
XzIuaHRtIj5OZXh0PC9hPjwvYj4mbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5i
c3A7PGI+PGEgaHJlZj0iI3RvcCI+VG9wPC9hPjwvYj48L2ZvbnQ+DQo8QlI+PEJSPiZuYnNw
Ow0KPEZPTlQgRkFDRT0idmVyZGFuYSwgaGVsdmV0aWNhLCBhcmlhbCIgU0laRT0xIENMQVNT
PWRldGFpbD4NCkZyaWRheSwgTWFyY2ggNSwgMTk5OTxCUj4NCiZjb3B5OyA8QSBIUkVGPSIu
Li9hcHBuZHgvY3B5cmlnaHQuaHRtIj4gMTk5OSBNaWNyb3NvZnQgQ29ycG9yYXRpb24uIEFs
bCByaWdodHMgcmVzZXJ2ZWQuIFRlcm1zIG9mIHVzZTwvQT4uDQo8L0ZPTlQ+PEJSPjxJTUcg
U1JDPSIuLi9pbWFnZXMvc3BhY2VyLmdpZiIgV0lEVEg9MzQwIEhFSUdIVD0xPjwvVEQ+PC9U
Uj4NCg0KPFRSPjxURCBDT0xTUEFOPTMgYWxpZ249Y2VudGVyPg0KPEZPTlQgRkFDRT0idmVy
ZGFuYSwgaGVsdmV0aWNhLCBhcmlhbCIgU0laRT0xIENMQVNTPWRldGFpbD4NCjxBIEhSRUY9
Ii4uL2FwcG5keC9ldWxhLmh0bSI+TGljZW5zZTwvQT4NCjwvRk9OVD48QlI+PElNRyBTUkM9
Ii4uL2ltYWdlcy9zcGFjZXIuZ2lmIiBXSURUSD0zNDAgSEVJR0hUPTE+PC9URD48L1RSPjwv
VEFCTEU+DQo8L2NlbnRlcj4NCjwhLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g
RU5EIFBBR0UgRk9PVEVSIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPg0KPC9C
T0RZPg0KPC9IVE1MPg0K
--HO7zst6f89q0F1wmV5K1e--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68E6FH29257 for ietf-pkix-bks; Mon, 8 Jul 2002 07:06:15 -0700 (PDT)
Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g68E6Ew29252 for <[e-mail]>; Mon, 8 Jul 2002 07:06:14 -0700 (PDT)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g68E6DO00573 for <[e-mail]>; Mon, 8 Jul 2002 16:06:13 +0200 (MEST)
Received: from mchx0a2w.mchm.siemens.de (mchx0a2w.mchm.siemens.de [139.23.227.157]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g68E6DV18060 for <[e-mail]>; Mon, 8 Jul 2002 16:06:13 +0200 (MEST)
Received: by mchx0a2w.mchm.siemens.de with Internet Mail Service (5.5.2653.19) id <N5Y0APWK>; Mon, 8 Jul 2002 16:06:12 +0200
Message-ID: <[e-mail]>
From: Oeser Thomas <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Clarifications regarding Private Internet Extensions - Authority  Information Access of RFC 3280
Date: Mon, 8 Jul 2002 16:05:57 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Community,
> 
> can anyone please help me with my questions?
> 
> In section 4.2.2.1 "Private Internet Extensions - Authority Information
> Access" of RFC 3280 it reads:
> 
> 	....
> 	The id-ad-caIssuers OID is used when the additional information
> 	lists CAs that have issued certificates superior to the CA that 
> 	issued the certificate containing this extension.  The referenced 
> 	CA issuers description is intended to aid certificate users in the 
> 	selection of a certification path that terminates at a point trusted
> 
> 	by the certificate user.
> 	....
> 
> If I understand this right, here *NOT* the CA immediately issung the
> certificate is listed but CAs *superior* to this CA; i.e., if we have a
> chain RootCA-->SubCA-->SubSubCA-->IssuingCA-->EndEntityCert, SubSubCA,
> SubCA and potentially RootCA is expected to be listed, when we find this
> extension in the end entity certificate. 
> Is there any reason to leave out the CA immediately issuing the end entity
> certificate?
> Also is it expected that the end entity certificate points to a list that
> more or less represents the chain leading to a trusted Root CA, or that
> each certificate points only to its immediate issuing CA?
> 
> 	...   
> 	When id-ad-caIssuers appears as accessMethod, the accessLocation
> 	field describes the referenced description server and the access 
> 	protocol to obtain the referenced description.  The accessLocation
> field 
> 	is defined as a GeneralName, which can take several forms. Where the
> 
> 	information is available via http, ftp, or ldap, accessLocation MUST
> be 
> 	a uniformResourceIdentifier.  Where the information is available via
> the 
> 	Directory Access Protocol (DAP), accessLocation MUST be a 
> 	directoryName.  The entry for that directoryName contains CA 
> 	certificates in the crossCertificatePair attribute.  When the
> information 
> 	is available via electronic mail, accessLocation MUST be an
> rfc822Name.  
> 	The semantics of other id-ad-caIssuers accessLocation name forms 
> 	are not defined.
> 	...
> 
> My problem here is, that unfortunately only for the case DAP the exact
> syntax for how constructing this list of superior CAs is defined (by the
> attribute crossCertificatePair). There is no syntax specified of how to
> store this list when the access method is e.g. HTTP, FTP or LDAP. The URI
> can point to everything, e.g. a ZIP-File containg CA certs in DER format,
> a directory containing files of CA certs in whatever format, a DER file
> representing the ASN.1 equivalent of SET OF or SEQUENCE OF X.509
> certificates, ...;
> Have I missed a format specification anywhere?
> 
> 
> -- Thomas Oeser
> 
> Siemens AG, CIO - Information Security
> D-85356 Munich-Airport, Suedallee 1, Germany
> Tel.:	+ 49 (89) 636-36356		_0/
> FAX:	+ 49 (89) 636-7-18593		  |
> mailto:	[e-mail]	< \
> 
> 


Received: by above.proper.com (8.11.6/8.11.3) id g65AM1S29114 for ietf-pkix-bks; Fri, 5 Jul 2002 03:22:01 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65AHOw28906; Fri, 5 Jul 2002 03:17:24 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA20354; Fri, 5 Jul 2002 12:21:26 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002070512165338:175 ; Fri, 5 Jul 2002 12:16:53 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Jul 2002 12:14:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>, S-MIME / IETF <[e-mail]>
Subject: Attribute Certification
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/07/2002 12:16:53, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/07/2002 12:17:24, Serialize complete at 05/07/2002 12:17:24
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Request for public comments on Draft ETSI TR 102 044 V0.0.7 (2002-07):

"Identification of requirements for attribute certification"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
technical report to identify a set of requirements that will provide a basis
on which a subsequent standard can build policy requirements for attributes
certified by Attribute Authorities or Certification Authorities either in a
subject's PKCs (Public Key Certificates) or in ACs (Attribute Certificates).

The scope of this document is to extensively investigate on the attribute
certification related topics in order to cover the general use of certified
attributes in the context of electronic signatures, but attributes that can
be used in such a context can also be used for other reasons, e.g.: for
authorisation.

COMMENTS ARE REQUESTED BY 8 TH SEPTEMBER 2002. Details of how to obtain
a copy of this document and submit comments are given towards the end of
this message.

BACKGROUND

The development of policy documents is one of the tasks the ETSI Electronic
Signature and Infrastructure Working Group is progressing within the
European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.

Please send your comments and suggestions not later than 8 th September
either to the ETSI El Sign e-mail list [e-mail], with copy to
the editor on [e-mail] or only to the editor, as you wish.
Please put "Attribute Certification" at the front of the Subject field of
all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(draft_TR_102044_v007.pdf) see:

http://portal.etsi.org/sec/el-sign.asp

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.

With regards,

Denis Pinkas. Bull.
Editor - Identification of requirements for attribute certification.

Franco Ruggieri. FIR DIG Consultants.
Task leader - Identification of requirements for attribute certification.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g659uOT26801 for ietf-pkix-bks; Fri, 5 Jul 2002 02:56:24 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g659uMw26796 for <[e-mail]>; Fri, 5 Jul 2002 02:56:22 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA17848; Fri, 5 Jul 2002 12:00:21 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002070511560479:168 ; Fri, 5 Jul 2002 11:56:04 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Jul 2002 11:53:30 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Yee, Peter" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-acmc-01.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/07/2002 11:56:04, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/07/2002 11:56:20, Serialize complete at 05/07/2002 11:56:20
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

WARNING: This is a very loooong e-mail in response to Peter.

Since you are coming to Yokohama, I believe that a face to face 
meeting would help. Nevertheless, in the mean time, you will find 
my comments below.

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

Denis,

    I've just gotten around to writing up my responses to your input
    on ACRMF and ACMC.  Thank you for taking the time to read both
    documents. Your input is valued.

 >Comments on drafts "Attribute Certificate Request Message Format" and
 >"Attribute Certificate Management Messages over CMS" (March 2002)

 >The two drafts are very technical, hard to read, inter-related and do
 >not have sufficient explanations to allow a rapid and easy 
 >understanding for everyone. It can be observed that no comment has 
 >been sent up to now on acmc.

    I'll grant you that they are very technical and perhaps hard to 
    read. I'll see what I can do to include more explanatory text in the 
    next draft.

    As for the number of comments that have come up regards ACMC, I fail 
    to see a direct correlation.  And in truth, I have received 
    supportive correspondence on ACMC from several parties who simply 
    didn't post to the list.

[DP] Discussions are supposed to be taken on the list. Off-list 
discussions are usually used to solve issues that would take too long on 
the list. Maybe we should now go off the list. :-)

 >It is assumed that managing ACs is as simple as managing PKCs and thus
 >that protocols able to manage PKCs, with a few modifications, will be 
 >able to manage ACs. This assumption is incorrect.

    I respectfully disagree.  While the combination of ACMC/ACRMF may 
    not be sufficient for all management aspects of ACs, I think that 
    they and the paradigm they espouse have their places.

[DP] Without explanations, this is still a free assertion. This is not as 
simple since you only have *one* version for a PKC and *many* possible 
versions for an AC that can include many or few attributes, associated 
with different validity periods, target constraints and so on.

    I think that there will be situations where PKCs and ACs are issued 
    together as part of an overall enrollment process.  

[DP] This is one possibility. Do you mean that the document only covers 
that possibility ? If this is the case, then it should be made clear. In 
such a case do we really need a protocol to retrieve ACs ? I do not think 
so, since LDPA would do it. We would only need a protocol to revoke 
attributes in ACs (I did NOT said "we would only need a protocol to 
revoke ACs".

    I think that there are other situations where the PKCs and the ACs 
    will be managed independently by different authorities. The 
    architecture needs the flexibility to support both situations.

[DP] Which both situations ? The document only covers X.509 attribute 
certificates from Attribute Authorities.

 >The way ACs are managed is very different from the way PKCs are 
 >managed and for that reason it is not believed that extending CRMF 
 >and CMC is the right way. Whether some extension to CMP would be 
 >able to do the job better will not be discussed either. The problem 
 >is that is that we have a solution without requirements, so it is hard 
 >to say whether or not the solution fits the requirements.

 >It would be appropriate to write of the requirements first, so 
 >we can all understand how a proposal would fit these requirements.

    Sometimes you think the requirements are clear -- as you did with 
    the attribute certificate policy work.  It's also true that when 
    extending an existing framework, one assumes that the underlying 
    requirements that built the framework still hold true.

[DP] The major problem is that the existing framework does not fit.

 >Before looking into some of these requirements, it is important to
 >understand the major differences with a PKC.

 >When a PKC is requested, a template of the PKC is provided together 
 >with registration information. From that request, a *single 
 >*certificate will be created later on, and will be given back to the 
 >requester and/or placed in a repository.

 >When an attribute (beware, *not* an AC) is registered, that attribute 
 >is provided together with registration information. No AC is created 
 >from that request. The registration information consists of two main 
 >components:

 >   - the definition of the attribute itself, together with some
 >     constraints that apply to it (see later) and the revocation
 >     conditions for that attribute.

 >   - the way to link the "to-be-created-ACs" with an entity, most of
 >     the time by linking it to a PKC. In that case providing the PKC is
 >     not always sufficient since the subject DN may not be explicit
 >     enough and thus information (or some link) from the CA that has
 >     created the PKC may be necessary.

    In your discussion, I don't see a mechanism for revoking an 
    attribute.

[DP]. Before raising the problem of revoking an AC, the first goal is to 
get the AC ! Revocation is not a mandatory requirement, since some ACs 
are never revoked because their validity period is small (e.g. one day). 

    Are you proposing another form of revocation list or status protocol 
    that is related to single attributes?  I would rather avoid such 
    creating of a new mechanism, as I see no indication that the current 
    ones are inadequate.

[DP] Revocation status information may be obtained using CRLs. In the 
future, maybe using the equivalent of an OCSP server. 

    Both linkages are supported in ACRMF -- either the IssuerSerial pair 
    is used or a DN (GeneralNames, really) is given.

[DP] This information may be ambiguous and is not usable in large PKIs.

 >Attribute registration is usually not done by the end user that will
 >become ultimately the AC holder. Various attributes can be registered.
 >Some attributes may be registered with some constraints like, the 
 >validity period of ACs that may be issued later on; how revocation 
 >will be handled, if handled for that attribute; restrictions that 
 >will apply to that attribute like target controls. Note that this 
 >operation is not necessary done remotely using a protocol, so it is 
 >not mandatory to support a protocol for it.

    I do not think that the means by which the AA determines the 
    appropriate values for each of the attributes should not be part of 
    this protocol.  In my view this would be analogous to bundling PKC 
    enrollment with identity vetting.  We recognize that identity 
    vetting has many components, potentially including face-to-face 
    interaction with an RA.  The AA (or the RA working with the AA) 
    faces a similar situation.  Some attribute values may be readily at 
    hand (perhaps in a local account management database). Some 
    attribute values may involve coordination or information gathering 
    (perhaps a credit check).  Other attribute values may require time 
    (perhaps waiting for a check to clear).  The latency between the AC 
    request and the AC issuance will depend on these factors (and other 
    ones too). Breaking the process into separate attribute registration 
    steps followed by a AC issuance step does not seem to be a general 
    model.

[DP] This is a core difference between the two approaches. The process 
has to be broken between attribute registration and AC issuance. Suppose 
that an entity has ten attributes registered by an Attribute Authority. 
That entity will not necessarily wish to disclose and/or exercise all the 
ten attributes that it has. There is a principle of "least privileges" 
that is always applicable. Even with the same subset, some target 
controls or different validity periods may need to be applied. The AA is 
simply unaware of the users needs.

 >Most users will be unable to specify the details of an AC and this will
 >either be done locally at the level of the AA or remotely by using
 >protocols dedicated to managers only. The job of these managers is to 
 >make life easy for certificate holders. They will define AC templates 
 >so that ACs can later on be created upon request from the AC holders 
 >by using these templates.

 >Some grouping of attributes will need to be done to fulfill a job or to
 >perform a set of operations. The AC holder will thus only need to know
 >the references of these various templates that will be tailored to 
 >match their jobs. In some cases, end-users will make the definition 
 >themselves and then will use the reference of these definitions to get 
 > an AC.

    ACMC and ACRMF work fine for either managers, knowledgeable users 
    (often called ARAs), or certain 3rd parties that are requesting ACs.

 >This means that AC will be obtained by providing a reference whose
 >details are already known to the AA.

    We support this -- the ACMC Attribute Modification Handling Control
    Attribute allows attribute certificates to be issued against a 
    specified policy or profile.  Conceptually, this usage can be mapped 
    to your templates.

[DP] Since the policy or the profile has no name nor reference, this 
feature is not supported. The text also says: Currently, getCert only 
supports retrieval based upon the issuerName and serialNumber 
combination. Quite hard to understand how all this will work together. 
Once again the document is very difficult to read, since it is not a 
standalone document. An introduction and preliminary information would be 
most useful instead of diving directly in the ASN.1 details.

 >As a summary, the following three basic functions are identified:

 >   1) Attribute registration (no AC is produced). This can be invoked
 >      several times. This function is optional since it can be done
 >      locally.

 >   2) AC template definition (a reference for a template is produced,
 >      but no AC is produced). This function can be done locally or
 >      remotely.

 >   3) AC acquisition (an AC is produced based on a template reference).

    ACMC and ACRMF are designed to handle #3.

[DP] No. In ACMC and ACRMF, an AC is produced based on a template, not 
based on a template reference. I wonder whether we have all the 
flexibility, in particular, how can the AC validity period be selected ?
A good exercise would be to use RFC 3281 and to explain in an annex how 
each of the fields of the AC can be selected to fit the requester's 
needs.

    #1 and #2 are outside of the scope of what I'm trying to do.
    Others are welcome to "fill in the blanks" for those situations 
    where they are needed. I argue that there are situations where 
    ACMC/ACRMF is sufficient.

[DP] It would be possible to return a template reference instead of an 
AC. Then #2 would be supported and would allow thin clients to use this 
protocol which is far too complicated for thin clients. #3 using a 
reference would be used by "thin" clients, while #2 would be used by 
managers or "fat" clients.

 >Additional functions are needed since the second function may be 
 >performed by managers while the third one will be performed by AC 
 >holders:

 >  - list the AC templates for a given entity (for an AC holder or
 >    a manager),

    Again, this isn't the realm of ACMC and ACRMF.  Another protocol is 
    welcome to step up to the plate on this.  In any case, I'm not sure 
    how AC templates are bound against a given entity.  If you're 
    referring to attribute certificates already issued, then some sort 
    of directory search may suffice (depends on the latitude of use of 
    these templates, joined directories, etc.).

    If you mean prior to AC issuance (which is what I suspect), well, 
    that's definitely beyond the scope of what I'm looking to do.  As 
    noted, these may be handled as a local function.

[DP] Template registration can be a local function but requesting an 
attribute certificate based on an already registered template cannot be 
done with the current proposal.

 >  - list the AC templates for a set of entities (for a manager only).

    Again, out of scope for ACMC/ACRMF.

 >Note: This assumes that the AA already "know" the attribute type.
 >If not, a registration function to register new attributes would be
 >needed.

    Sure.  And that's another local or remote function.

 >Once an AC has been obtained, it may be necessary to revoke it 
 >(if this is allowed). However, the revocation requests is not for 
 >an AC, but either for an attribute or an AC template. This means that 
 >all ACs containing this attribute or produced using that template 
 >have to be revoked. This may be for one entity or for all entities 
 >using that attribute or that AC template.

 >Since the requester (which may not be the AC holder) does not
 >necessarily know all the AC s that have been issued, it cannot 
 >indicate the serial numbers of these ACs and thus let the AA find 
 >out how many and which ACs need to be revoked. This is fairly 
 >different from the ways PKCs are requested to be revoked.

    I have to disagree with you on this one.  Let's take an example. 
    I have an AC that permits me to make purchases on behalf of the 
    company up to the $10,000 level.  Now, because of a change in 
    responsibilities, my level is being reduced to $5,000.  At that 
    point, the AC I have allowing me to make $10,000 purchases is going 
    to revoked.  Period.  I have no idea why the AC template would be 
    revoked -- what does my loss of authority have to do with anyone 
    else using a similar type of AC?  And since I'm not really concerned 
    about attribute registration, the revocation (deregistration?) of 
    attributes is outside of the scope of ACMC/ACRMF.

[DP] I fear you failed to catch the point. In your case, the capability 
to purchases up to the $10,000 level will be revoked, All certificates 
that contain that capability must be revoked (if revocation is handled 
for them). This is the revocation issue. Now in addition, this means that 
if you then request that capability (e.g. using an AC template), no AC 
with that capability in it will be granted. If you had a template 
reference that included that capability, either then no AC would be 
granted based on that template or you would get everything else except 
that capability.

    Re-reading your paragraph above, I think we're looking at attributes 
    in a fundamentally different way.  You seem to think that an 
    attribute is registered, and then can be issued in attribute 
    certificates to multiple users.

[DP] This is not what I said.

    And that an attribute may need to be revoked, causing the revocation 
    of all certificates incorporating that attribute.

[DP] Certainly, I first mean all certificates that contains that 
attribute for a given user: a user may be given many attribute 
certificates that include that attribute. In addition suppose that you 
want to stop at once all the "project team 23" members to access a 
server. You can simply revoke the attribute "Project team 23". All 
certificates already issued and still valid, that contain that attribute 
type and value will be revoked.

    That's not at all what I was thinking. There may be many attribute 
    certificates with a specific attribute type, but the need to revoke 
    is tied to a specific attribute certificate and its attributes, not 
    to the set of all attributes certificates containing a specific 
    attribute (either type or type/value/conditions).

[DP] See again the example above.

    Finally, I'll note that even if you do use an attribute revocation 
    scheme instead of an attribute certificate revocation scheme, you 
    still have to revoke an affected AC and (potentially) issue a new 
    one minus the stricken attribute.  ACMC/ACRMF can be used to do 
    this.

[DP] Re-issuing a new attribute certificate minus the stricken attribute 
finally allows me to understand which model you have in mind.

The model you seem to be advocating is indeed pretty different from the 
one I have in mind. Maybe it is so self-evident to you that you have not 
mentioned it.

Model 1: Attributes certificates are issued automatically by the AA and 
placed in a repository. The grouping of attributes, the validity period 
of the AC is fully left at the entire discretion of the AA.

Model 2: Attributes certificates are issued upon request from requestors. 
They are not necessarily placed in a repository, but *may* be placed in 
it, upon request from the requestor. The grouping of attributes, the 
validity period of the AC, the publication is fully at the discretion of
the requestor, provided that it does not violate the policy under which 
the AC is being requested to be issued.

Would you confirm if this is one of the main difference ?

 >This description provides an hint on how an attribute revocation 
 >request should be handled. This is fairly different from the current 
 >proposal which is only able to revoke an AC by providing an AA name 
 >and a serial number.

 >While useful in some cases, this is certainly insufficient.

    The mechanism you offered can be used with in conjunction with other
    mechanisms to work on pretty much any need for revocation.  I think 
    that I see where you're going, but I believe that in only providing 
    AA name/serial number, I haven't changed the problem; I've only 
    changed where the list of certificates to be revoked is assembled.  
    You seem to propose that the AA could do this. I've pushed list 
    assembly to an entity that could be logically outside of the AA (the 
    ARA or some other management entity).

[DP] In only providing AA name/serial number, you have not solved the 
problem which is different from the PKC case.

 >Since an AC is created for an AC holder and upon request from an AC
 >holder, it is given back to the requester. In most protocols ACs are 
 >"pushed" towards an application or are provided attached to some 
 >signed data.

 >Otherwise, the reference of the certificate is "pushed" by the AC 
 >holder and the AA may then provide the AC upon request. When that 
 >function is useful, it would be interesting to use an LDAP schema so 
 >that LDAP can be used for ACs, rather than a new dedicated protocol.

 >Hereafter are a few comments on the two proposals.

 >ACRMF is an "Attribute Certificate Request Message Format". 
 >It combines two functions mentioned earlier: 
 >the AC template definition function and the AC acquisition function. 
 >However, as indicated above, these functions should be separated.

    I'm not a believer in the AC template school.  If you wish to argue 
    that ACRMF contains a template, I'll agree that it contains one, 
    generic template that can be used to generate any attribute 
    certificate (given a set of attributes, etc.). I view ACRMF as part 
    of the AC acquisition function.  Period.  If you insist on an AC 
    template function, I think that it belongs in a separate protocol.  
    Again, many situations are handled by ACMC/ACRMF.

[DP] The problem has to do with thin clients that will be unable to ask 
for "complicated" AC contents.

 >"Attribute Certificate Management Messages over CMS" - ACMC - fails to
 >clearly present the functions that are supported. It is necessary to
 >maintain open at the same time three other documents to be able to
 >understand that document: [CMCbis], [ACRMF] and [CRMF]. Before going 
 >into the details, it would be most useful to express the functions that
 > are supported.

    Fair enough.  I will endeavor to make it clear functions ACMC 
    supports.

 >In section 3.6, GetCert is mentioned to be sufficient for attribute
 >certificates while it only supports AC retrieval based upon the issuer
 >name and the AC serial number. This function is insufficient and should 
 >be supported using LDAP.

    I did not say that Get Cert was sufficient.  I said that the issuer 
    name and serial number combination was sufficient to retrieve an 
    attribute certificate.  I didn't say that it was the only way or 
    what everyone might desire.  The second paragraph suggests that 
    there are other needs.  I'm simply saying that if you do have the 
    issuer name/AC serial number, the existing Get Cert is available.  I 
    don't want to replicate LDAP within ACMC.

[DP] Since then David has issue a new draft: LDAP schema and syntaxes for 
PMIs. It would now be certainly interesting to compare what can be done 
with each of the two drafts, i.e. what is common and what is specific.

 >In section 3.8. the revoke request control attribute allows to revoke 
 >an attribute certificate, while it has been mentioned that this is
 >insufficient.

    I suppose we just disagree on this point.

 >In section 4.1. attributes can be added but this is again insufficient:
 >attributes with restrictions may need to be added. As an example,
 >extensions like target Controls may be appropriate.

    I'm not sure I follow you -- are you saying we need extensions 
    (using the AC extension mechanism) that control attributes?  Or that 
    the attributes need to specify controls (generically? or attribute-
    specifically?)  If the former case, I think you've got a mess 
    brewing if you want to try to tie extensions to specific attributes.  
    If the latter case, and attribute-specifically, I would say that's a 
    question of attribute definition.  If generically, then you're 
    talking about something that needs to be handled at the X.509 AC 
    syntax and semantics; these would then percolate into ACMC/ACRMF.

[DP] The restrictions apply to the whole set of attributes contained in 
the AC.

 >CONCLUSION

 >We first need to agree on a set of requirements before discussing the
 >details of any proposal. It might be appropriate to write an
 >Informational RFC to specify these requirements.

    I see no need to write a requirements document at this point.  The 
    PKIX chairs will let us all know if they think otherwise.
    The mechanisms provided by ACMC/ACRMF are needed, 

(DP] But the main question is are there sufficient or insufficient. This 
cannot be debated in a vacuum but only wen compared with requirements.

    but I will try to add more explanation about the scope.  I will try 
    to make it clear what is covered and what is not covered.  

[DP] This will certainly help, but will not close the debate.

    This should leave plenty of room for a companion document addressing 
    some of your concerns.  The need for that companion document is 
    breaking much more new ground.  Maybe a requirements document is 
    appropriate for that effort. Again, the PKIX chairs will let us 
    know....

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64EHJG22628 for ietf-pkix-bks; Thu, 4 Jul 2002 07:17:19 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64EHHw22609 for <[e-mail]>; Thu, 4 Jul 2002 07:17:17 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA13956; Thu, 4 Jul 2002 16:21:16 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002070416165709:78 ; Thu, 4 Jul 2002 16:16:57 +0200 
Message-ID: <[e-mail]>
Date: Thu, 04 Jul 2002 16:16:56 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: David Hopwood <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pr-tsa-01.txt
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/07/2002 16:16:57, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/07/2002 16:17:16, Serialize complete at 04/07/2002 16:17:16
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

> [e-mail] wrote:
> > 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           : Policy Requirements for Time-Stamping Authorities
> >         Author(s)       : D. Pinkas, N. Pope, J. Ross
> >         Filename        : draft-ietf-pkix-pr-tsa-01.txt
> >         Pages           : 39
> >         Date            : 26-Jun-02

> > This document specifies policy requirements relating to the
> > operation of Time-stamping Authorities (TSAs). It defines policy
> > requirements on the operation and management practices of TSAs such
> > that subscribers and relying parties may have confidence in the
> > operation of the time-stamping services.
> > The contents of this Informational RFC is technically equivalent to
> > ETSI TS 102 023 V1.2.1 (2002-06) [TS 102023]. The ETSI TS is under
> > the ETSI Copyright (C). Individual copies of this ETSI deliverable
> > can be downloaded from http://www.etsi.org
> > This document is an Internet-Draft and is NOT offered in accordance
> > with Section 10 of RFC 2026, and the authors do not provide the IETF
> > with any rights other than to publish as an Internet-Draft.
 
> Since this draft concerns policy requirements for an Internet Standards
> Track protocol (TSP, i.e. RFC 3161), it should be part of the Internet
> Standards Process. RFC 2026 is clear about that meaning that it MUST be
> subject to Section 10.

You will find below, some text copied from RFC 2026, explaining why this
document is progressed on the Informational Track:

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.

Note also that RFC 2529 (Certificate Policy and Certification Practices
Framework) which applies to CAs is not issued on the Standards Tracks but as
an Informational Standard (This RFC is being updated. A separate mailing
list has been formed for the discussion of the update). 

Now, reading again the current abstract, some confusion is possible. 
So I am proposing to re-use some text from the inner content of the 
document and duplicate it in the abstract to form a new abstract as follows:

   This document defines requirements for a baseline time-stamp policy 
   for TSAs issuing time-stamp tokens, supported by public key 
   certificates, with an accuracy of 1 second or better. A TSA may 
   define its own policy which enhances the policy defined in the 
   current document. Such a policy shall incorporate or further 
   constrain the requirements identified in the current document. 

We certainly do not expect that all implementations of RFC 3161 will
implement this baseline policy.  It is put forward for information as a
baseline policy that has been defined. Other policies are expected to
exist.

I hope that this should solve your concern.

Regards,

Denis
 
> (It is possible for documents that are not part of the Internet Standards
> Process to be published as Informational RFCs without being subject to
> Section 10, as described in RFC 2026 Section 4.2.2, but that should be
> reserved for documents that have no direct relation to any Standards Track
> protocols.)
> 
> - --
> David Hopwood <[e-mail]>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64AnYO03554 for ietf-pkix-bks; Thu, 4 Jul 2002 03:49:34 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64AnWw03548 for <[e-mail]>; Thu, 4 Jul 2002 03:49:32 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g64AnD42032037; Thu, 4 Jul 2002 22:49:13 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id WAA206537; Thu, 4 Jul 2002 22:49:09 +1200 (NZST) (sender [e-mail])
Date: Thu, 4 Jul 2002 22:49:09 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"DUBUISSON Olivier" <[e-mail]> writes:

>Implementors do not have to bother with tagging when they use an ASN.1
>compiler!

Unfortunately experience shows that quite a number of implementers don't do
this.  Designing around the problem in the RFC is an easy fix for this.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64AEJn29708 for ietf-pkix-bks; Thu, 4 Jul 2002 03:14:19 -0700 (PDT)
Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64AEHw29704 for <[e-mail]>; Thu, 4 Jul 2002 03:14:18 -0700 (PDT)
Received: (from root@localhost) by mystic1.trustcenter.de (8.10.2+Sun/8.10.2) id g64ADhb26890; Thu, 4 Jul 2002 12:13:43 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.200.233) by mystic1.trustcenter.de via csmap (V6.0) id srcAAACMaiH0; Thu, 4 Jul 02 12:13:41 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g64AE8Q16141; Thu, 4 Jul 2002 12:14:08 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 04 Jul 2002 12:14:08 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: DUBUISSON Olivier <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> DUBUISSON Olivier wrote:
> > > In my opinion the
> 
> > >module would be better readable for implementors if you would
> declare
> > it
> > >as EXPLICIT.
> 
> Implementors do not have to bother with tagging when they use an
> ASN.1 compiler!

Sure. But obviously too many people don't use one and produce invalid
encodings, and other people than have to deal with this defect stuff.

I had to discuss the "IMPLICIT, that turns implicitely in an
EXPLICIT"-thing several times with partners of our company; and I know
of at least one implementation in the wild that does it wrong.

It's my hope that a little hint in standard documents may help to
prevent this mess.

> And what about sticking "AUTOMATIC TAGS" in the module header (if it's
> 
> a new ASN.1 module that you're producing), and not bother with tags
> any more?

Of course that does not work with old compilers... .

Regards,
   Juergen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g649u7f27504 for ietf-pkix-bks; Thu, 4 Jul 2002 02:56:07 -0700 (PDT)
Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g649u5w27497 for <[e-mail]>; Thu, 4 Jul 2002 02:56:05 -0700 (PDT)
Received:  from francetelecom.com (L-AT5639.rd.francetelecom.fr [10.193.13.119]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3GJGJ4J9; Thu, 4 Jul 2002 11:54:41 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22340.D0EF0680"
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Date: Thu, 4 Jul 2002 11:55:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Thread-Index: AcIjQNGYEjWXK48IEdaOfgCAXzHsRg==
From: "DUBUISSON Olivier" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: "Juergen Brauckmann" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

"Housley, Russ" wrote:
>=20
> Juergen:
>=20
> Right after sending my last reply, I realized that I was much too
hasty
> in
> my reply to this comment.  Please disregard my previous response.
>=20
> In general, I do not like EXPLICIT tagging.  But you are correct that
> there
> is a problem here.  I want to consider alternative solutions and get
> advice
> from others about how this has been handled in other protocols.  I
will
> post a proposed fix soon.
>=20
> Russ
>=20
> >**** ASN.1:
> >You declare the Module as IMPLICIT TAGS. But the only use of tags is
> >LogotypeExtn ::=3D SEQUENCE {
> >          communityLogo  [0] LogotypeInfo OPTIONAL,
> >          issuerLogo     [1] LogotypeInfo OPTIONAL,
> >          subjectLogo    [2] LogotypeInfo OPTIONAL,
> >          otherLogos     [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }
> >
> >       LogotypeInfo ::=3D CHOICE {
> >          direct          LogotypeData,
> >          indirect        LogotypeReference }
> >
> >Here, the tags are converted silently by clause 30.6 c) of X.680 into
> >EXPLICIT tags because LogotypeInfo is a CHOICE (IMPLICIT tags on
> CHOICEs
> >are implicitely EXPLICIT or something like that). In my opinion the
> >module would be better readable for implementors if you would declare
> it
> >as EXPLICIT.

Implementors do not have to bother with tagging when they use an
ASN.1 compiler!

> >The LogotypeInfo CHOICE misses a tag when you use module-wide
IMPLICIT
> >or EXPLICIT tagging. LogotypeData and LogotypeReference are both
> >SEQUENCEs, and for the CHOICE to be parseable, you have to tag the
> >elements (Clause 28.2. of X.680).
>=20
> How about:
>=20
>     LogotypeInfo ::=3D CHOICE {
>        direct          [0] LogotypeData,
>        indirect        [1] LogotypeReference }

And what about sticking "AUTOMATIC TAGS" in the module header (if it's
a new ASN.1 module that you're producing), and not bother with tags
any more?
--=20
Olivier DUBUISSON
france telecom R&D

DTL/TAL - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/

------_=_NextPart_001_01C22340.D0EF0680
Content-Type: text/html;
	charset="us-ascii"
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 =
6.0.5770.91">
<TITLE>Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>&quot;Housley, Russ&quot; wrote:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Juergen:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Right after sending my last reply, I realized =
that I was much too hasty</FONT>

<BR><FONT SIZE=3D2>&gt; in</FONT>

<BR><FONT SIZE=3D2>&gt; my reply to this comment.&nbsp; Please disregard =
my previous response.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; In general, I do not like EXPLICIT =
tagging.&nbsp; But you are correct that</FONT>

<BR><FONT SIZE=3D2>&gt; there</FONT>

<BR><FONT SIZE=3D2>&gt; is a problem here.&nbsp; I want to consider =
alternative solutions and get</FONT>

<BR><FONT SIZE=3D2>&gt; advice</FONT>

<BR><FONT SIZE=3D2>&gt; from others about how this has been handled in =
other protocols.&nbsp; I will</FONT>

<BR><FONT SIZE=3D2>&gt; post a proposed fix soon.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Russ</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt;**** ASN.1:</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;You declare the Module as IMPLICIT TAGS. But =
the only use of tags is</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;LogotypeExtn ::=3D SEQUENCE {</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
communityLogo&nbsp; [0] LogotypeInfo OPTIONAL,</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
issuerLogo&nbsp;&nbsp;&nbsp;&nbsp; [1] LogotypeInfo OPTIONAL,</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
subjectLogo&nbsp;&nbsp;&nbsp; [2] LogotypeInfo OPTIONAL,</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
otherLogos&nbsp;&nbsp;&nbsp;&nbsp; [3] SEQUENCE OF OtherLogotypeInfo =
OPTIONAL }</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
LogotypeInfo ::=3D CHOICE {</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
direct&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
LogotypeData,</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
indirect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LogotypeReference =
}</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;Here, the tags are converted silently by =
clause 30.6 c) of X.680 into</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;EXPLICIT tags because LogotypeInfo is a =
CHOICE (IMPLICIT tags on</FONT>

<BR><FONT SIZE=3D2>&gt; CHOICEs</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;are implicitely EXPLICIT or something like =
that). In my opinion the</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;module would be better readable for =
implementors if you would declare</FONT>

<BR><FONT SIZE=3D2>&gt; it</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;as EXPLICIT.</FONT>
</P>

<P><FONT SIZE=3D2>Implementors do not have to bother with tagging when =
they use an</FONT>

<BR><FONT SIZE=3D2>ASN.1 compiler!</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt;The LogotypeInfo CHOICE misses a tag when you =
use module-wide IMPLICIT</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;or EXPLICIT tagging. LogotypeData and =
LogotypeReference are both</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;SEQUENCEs, and for the CHOICE to be =
parseable, you have to tag the</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;elements (Clause 28.2. of X.680).</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; How about:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; LogotypeInfo ::=3D =
CHOICE {</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
direct&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [0] =
LogotypeData,</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
indirect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1] LogotypeReference =
}</FONT>
</P>

<P><FONT SIZE=3D2>And what about sticking &quot;AUTOMATIC TAGS&quot; in =
the module header (if it's</FONT>

<BR><FONT SIZE=3D2>a new ASN.1 module that you're producing), and not =
bother with tags</FONT>

<BR><FONT SIZE=3D2>any more?</FONT>

<BR><FONT SIZE=3D2>-- </FONT>

<BR><FONT SIZE=3D2>Olivier DUBUISSON</FONT>

<BR><FONT SIZE=3D2>france telecom R&amp;D</FONT>
</P>

<P><FONT SIZE=3D2>DTL/TAL - 22307 Lannion Cedex - France</FONT>

<BR><FONT SIZE=3D2>t: [phone] - f: [phone] - <A =
HREF=3D"http://asn1.elibel.tm.fr/">http://asn1.elibel.tm.fr/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C22340.D0EF0680--


Received: by above.proper.com (8.11.6/8.11.3) id g62F6Hj20222 for ietf-pkix-bks; Tue, 2 Jul 2002 08:06:17 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g62F6Fw20212 for <[e-mail]>; Tue, 2 Jul 2002 08:06:15 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Jul 2002 15:05:46 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA09739 for <[e-mail]>; Tue, 2 Jul 2002 11:06:15 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g62F4Fm13074 for <[e-mail]>; Tue, 2 Jul 2002 11:04:15 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZVDJT>; Tue, 2 Jul 2002 11:06:14 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.21]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZVDJQ; Tue, 2 Jul 2002 11:06:12 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 02 Jul 2002 11:04:52 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

The accessability people at Microsoft think that sounds are the only 
alternative to logo images for blind people.

Your ASN.1 suggestion just removes one tag.  While it is a matter of style, 
I think it is a good idea.

Russ


At 08:54 PM 7/2/2002 +1200, Peter Gutmann wrote:
>"Housley, Russ" <[e-mail]> writes:
>
> >Third, the optional elements within LogotypeData are tagged.
>
>You could clean it up a bit and get rid of a lot of tagging by leaving the 
>most
>common cases untagged.  For example for LogotypeData I would imagine 99.9% of
>uses would be for a graphic logo, so by leaving the image option untagged you
>get rid of tagging in most cases (are people really going to associate
>digitised sounds with a cert?  When I suggested that a while back it was only
>as a joke).
>
>Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g628sI521390 for ietf-pkix-bks; Tue, 2 Jul 2002 01:54:18 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g628sFw21384 for <[e-mail]>; Tue, 2 Jul 2002 01:54:16 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g628s942012185; Tue, 2 Jul 2002 20:54:09 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA489463; Tue, 2 Jul 2002 20:54:08 +1200 (NZST) (sender [e-mail])
Date: Tue, 2 Jul 2002 20:54:08 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>Third, the optional elements within LogotypeData are tagged.

You could clean it up a bit and get rid of a lot of tagging by leaving the most
common cases untagged.  For example for LogotypeData I would imagine 99.9% of
uses would be for a graphic logo, so by leaving the image option untagged you
get rid of tagging in most cases (are people really going to associate
digitised sounds with a cert?  When I suggested that a while back it was only
as a joke).

Peter.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6275cO11621 for ietf-pkix-bks; Tue, 2 Jul 2002 00:05:38 -0700 (PDT)
Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6275Zw11615 for <[e-mail]>; Tue, 2 Jul 2002 00:05:35 -0700 (PDT)
Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.2) with SMTP id g6275YM08180 for <[e-mail]>; Tue, 2 Jul 2002 10:05:34 +0300 (EEST)
Received: (qmail 10508 invoked from network); 2 Jul 2002 07:05:33 -0000
Received: from unknown (HELO schubert) ([10.1.0.48]) (envelope-sender <[e-mail]>) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 2 Jul 2002 07:05:33 -0000
From: "Vesa Suontama" <[e-mail]>
To: <[e-mail]>
Subject: Re: about test server
Date: Tue, 2 Jul 2002 10:05:50 +0300
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

pki.ssh.com has a SCEP interoperability site. See http://pki.ssh.com for
more information.

Vesa

""forward"" <[e-mail]> wrote in message
news:<005901c220a6$4cf59ca0$b400a8c0@liyunfeng>...
>
> Hi all:
> I know this email list is not about SCEP. But I want to know where can I
> find a test SCEP CA server.
> Thanks very much!
>
> Forward.li
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61KvQi14693 for ietf-pkix-bks; Mon, 1 Jul 2002 13:57:26 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g61KvOw14689 for <[e-mail]>; Mon, 1 Jul 2002 13:57:24 -0700 (PDT)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Jul 2002 20:58:03 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g61L2aq01812 for <[e-mail]>; Tue, 2 Jul 2002 07:02:37 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <NVT7F6GX>; Tue, 2 Jul 2002 06:57:51 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28Z457G; Mon, 1 Jul 2002 16:57:12 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 01 Jul 2002 16:53:47 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: I-D ACTION:draft-ietf-pkix-scvp-09.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A New Internet-Draft is available, but it is not in the usual location.  I 
missed the deadline.
I thought that I had beat the deadline by five hours, but I actually missed 
it by four hours.
Anyway, we have made it available for everyone to download from a different 
server.

This draft is a work item of the Public-Key Infrastructure (X.509) Working 
Group of the IETF.

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, and T. Freeman
	Filename	: draft-ietf-pkix-scvp-09.txt
	Pages		: 31
	Date		: 1-Jul-02
	
SCVP allows a client to offload certificate handling to a server. The 
server can prove the client with a variety of valuable information about 
the certificate, such as whether the certificate is valid, a certification 
path to a trust anchor, and so on. SCVP has many purposes, including 
simplifying client implementations and allowing companies to centralize 
trust and policy management.

A URL for this Internet-Draft is:
ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-scvp-09.txt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61Kclx14212 for ietf-pkix-bks; Mon, 1 Jul 2002 13:38:47 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g61Kckw14207 for <[e-mail]>; Mon, 1 Jul 2002 13:38:46 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Jul 2002 20:38:19 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA16120 for <[e-mail]>; Mon, 1 Jul 2002 16:38:48 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g61KamQ03254 for <[e-mail]>; Mon, 1 Jul 2002 16:36:48 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28Z45CG>; Mon, 1 Jul 2002 16:38:46 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28Z45B4; Mon, 1 Jul 2002 16:38:38 -0400
From: "Housley, Russ" <[e-mail]>
To: Juergen Brauckmann <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 01 Jul 2002 16:38:30 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen:

Thanks for pointing out the ASN.1 issues.  I believe that the following 
corrects the problem that you found and one other.  First, the implicit 
EXPLICITs are made EXPLICIT to aid the reader (and implementor).  Second, 
the alternatives within LogotypeInfo are tagged as I proposed in my earlier 
message. Third, the optional elements within LogotypeData are tagged.

    LogotypeExtn ::= SEQUENCE {
       communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
       issuerLogo      [1] EXPLICIT LogotypeInfo OPTIONAL,
       subjectLogo     [2] EXPLICIT LogotypeInfo OPTIONAL,
       otherLogos      [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }

    LogotypeInfo ::= CHOICE {
       direct          [0] LogotypeData,
       indirect        [1] LogotypeReference }

    LogotypeData ::= SEQUENCE {
       image           [0] SEQUENCE OF LogotypeImage OPTIONAL,
       audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

Russ


>**** ASN.1:
>You declare the Module as IMPLICIT TAGS. But the only use of tags is
>LogotypeExtn ::= SEQUENCE {
>          communityLogo  [0] LogotypeInfo OPTIONAL,
>          issuerLogo     [1] LogotypeInfo OPTIONAL,
>          subjectLogo    [2] LogotypeInfo OPTIONAL,
>          otherLogos     [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }
>
>       LogotypeInfo ::= CHOICE {
>          direct          LogotypeData,
>          indirect        LogotypeReference }
>
>Here, the tags are converted silently by clause 30.6 c) of X.680 into
>EXPLICIT tags because LogotypeInfo is a CHOICE (IMPLICIT tags on CHOICEs
>are implicitely EXPLICIT or something like that). In my opinion the
>module would be better readable for implementors if you would declare it
>as EXPLICIT.
>
>The LogotypeInfo CHOICE misses a tag when you use module-wide IMPLICIT
>or EXPLICIT tagging. LogotypeData and LogotypeReference are both
>SEQUENCEs, and for the CHOICE to be parseable, you have to tag the
>elements (Clause 28.2. of X.680).


How about:

    LogotypeInfo ::= CHOICE {
       direct          [0] LogotypeData,
       indirect        [1] LogotypeReference }


Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61JiBC10526 for ietf-pkix-bks; Mon, 1 Jul 2002 12:44:11 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g61Ji9w10518 for <[e-mail]>; Mon, 1 Jul 2002 12:44:09 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Jul 2002 19:43:42 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA20523 for <[e-mail]>; Mon, 1 Jul 2002 15:44:11 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g61GfMM09201 for <[e-mail]>; Mon, 1 Jul 2002 12:41:22 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28Z4V2X>; Mon, 1 Jul 2002 12:43:21 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.14]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28Z4V2W; Mon, 1 Jul 2002 12:43:15 -0400
From: "Housley, Russ" <[e-mail]>
To: Juergen Brauckmann <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 01 Jul 2002 12:41:21 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen:

>**** Page 6, at the end of chapter 3:
>    Applications SHOULD enhance processing and off-line functionality by
>    cashing logotype data.
>    ^^^^^
>Funny typo:-) Who cashes whom?;-)

Obviously, this is a typo.  It will be fixed in draft -04.

>**** LogotypeImageInfo and LogotypeAudioInfo:
>In my opinion these data structures lack something like "descriptiveText
>UTF8String OPTIONAL" that could be displayed if the source of the images
>or audio data is currently unavailable or the data cannot be retrieved.
>
>I can imagine many situations where retrieval of data is not possible,
>but nevertheless the functionality of community branding is desired. And
>in such situations it would be helpful if the application could present
>a simple string to the user.

This is an interesting idea.  I would like to hear what others think before 
a change is made.

>**** ASN.1:
>You declare the Module as IMPLICIT TAGS. But the only use of tags is
>LogotypeExtn ::= SEQUENCE {
>          communityLogo  [0] LogotypeInfo OPTIONAL,
>          issuerLogo     [1] LogotypeInfo OPTIONAL,
>          subjectLogo    [2] LogotypeInfo OPTIONAL,
>          otherLogos     [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }
>
>       LogotypeInfo ::= CHOICE {
>          direct          LogotypeData,
>          indirect        LogotypeReference }
>
>Here, the tags are converted silently by clause 30.6 c) of X.680 into
>EXPLICIT tags because LogotypeInfo is a CHOICE (IMPLICIT tags on CHOICEs
>are implicitely EXPLICIT or something like that). In my opinion the
>module would be better readable for implementors if you would declare it
>as EXPLICIT.
>
>The LogotypeInfo CHOICE misses a tag when you use module-wide IMPLICIT
>or EXPLICIT tagging. LogotypeData and LogotypeReference are both
>SEQUENCEs, and for the CHOICE to be parseable, you have to tag the
>elements (Clause 28.2. of X.680).


How about:

    LogotypeInfo ::= CHOICE {
       direct          [0] LogotypeData,
       indirect        [1] LogotypeReference }


Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61JXoG09435 for ietf-pkix-bks; Mon, 1 Jul 2002 12:33:50 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g61JXmw09430 for <[e-mail]>; Mon, 1 Jul 2002 12:33:48 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Jul 2002 19:33:21 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA18054; Mon, 1 Jul 2002 15:33:50 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g61HHTk11693; Mon, 1 Jul 2002 13:17:29 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28Z4VL6>; Mon, 1 Jul 2002 13:19:28 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.14]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28Z4VL5; Mon, 1 Jul 2002 13:19:19 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 01 Jul 2002 13:19:17 -0400
Subject: Re: draft-ietf-pkix-warranty-extn-01
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

> > > > [REVISED TEXT:]  A relying party may obtain compensation from a CA 
> depending
> > > > on the conditions for such compensation expressed in either the CA's
> > > > Certificate Policy or the CA's insurance policy, or both.
> > >
> > >I believe that Russ said that the CA's insurance policy was included 
> in the
> > >CA's Certificate Policy. The "or" is not appropriate.
> >
> > That depends on the structure of the policy.  The CA might self-insure for
> > small claims, and have an insurance policy for larger ones.
>
>I disagree: what is important is what is visible for the relying parties.
>Self-insurance or back up insurance is a level of detail that is internal to
>the CA. This does not have to be visible to the relying party. The "or" is
>still not appropriate.

I think we are saying the same thing.  The CA might self-insure, get a 
policy from an insurance company, or a combination of the two.  This is of 
no interest to the relying party.  The replying party only cares that 
compensation is available.  If there is a problem, the relying party will 
contact the CA to make her claim.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61JTDB08898 for ietf-pkix-bks; Mon, 1 Jul 2002 12:29:13 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g61JTBw08891 for <[e-mail]>; Mon, 1 Jul 2002 12:29:11 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Jul 2002 19:28:44 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA16378 for <[e-mail]>; Mon, 1 Jul 2002 15:29:13 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g61Gwjd10497 for <[e-mail]>; Mon, 1 Jul 2002 12:58:45 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28Z4VKL>; Mon, 1 Jul 2002 13:00:44 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.14]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28Z4VK2; Mon, 1 Jul 2002 13:00:35 -0400
From: "Housley, Russ" <[e-mail]>
To: Juergen Brauckmann <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 01 Jul 2002 13:00:33 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen:

Right after sending my last reply, I realized that I was much too hasty in 
my reply to this comment.  Please disregard my previous response.

In general, I do not like EXPLICIT tagging.  But you are correct that there 
is a problem here.  I want to consider alternative solutions and get advice 
from others about how this has been handled in other protocols.  I will 
post a proposed fix soon.

Russ


>**** ASN.1:
>You declare the Module as IMPLICIT TAGS. But the only use of tags is
>LogotypeExtn ::= SEQUENCE {
>          communityLogo  [0] LogotypeInfo OPTIONAL,
>          issuerLogo     [1] LogotypeInfo OPTIONAL,
>          subjectLogo    [2] LogotypeInfo OPTIONAL,
>          otherLogos     [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }
>
>       LogotypeInfo ::= CHOICE {
>          direct          LogotypeData,
>          indirect        LogotypeReference }
>
>Here, the tags are converted silently by clause 30.6 c) of X.680 into
>EXPLICIT tags because LogotypeInfo is a CHOICE (IMPLICIT tags on CHOICEs
>are implicitely EXPLICIT or something like that). In my opinion the
>module would be better readable for implementors if you would declare it
>as EXPLICIT.
>
>The LogotypeInfo CHOICE misses a tag when you use module-wide IMPLICIT
>or EXPLICIT tagging. LogotypeData and LogotypeReference are both
>SEQUENCEs, and for the CHOICE to be parseable, you have to tag the
>elements (Clause 28.2. of X.680).


How about:

    LogotypeInfo ::= CHOICE {
       direct          [0] LogotypeData,
       indirect        [1] LogotypeReference }


Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61HXuA03108 for ietf-pkix-bks; Mon, 1 Jul 2002 10:33:56 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61HXsw03102 for <[e-mail]>; Mon, 1 Jul 2002 10:33:54 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g61HXpe8121440; Mon, 1 Jul 2002 13:33:51 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g61HXnc42250; Mon, 1 Jul 2002 13:33:49 -0400
Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
To: Juergen Brauckmann <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 1 Jul 2002 13:33:56 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 07/01/2002 01:33:50 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Actually, Juergen, only 3 of the 4 fields get converted to EXPLICIT.
Of course, with only a single IMPLICIT left it would be simpler just to
make that one (otherLogos) IMPLICIT SEQUENCE OF.  I would also suggest that
LogotypeInfo be changed as follows:

      LogotypeInfo ::= CHOICE {
         direct          LogotypeData,
         indirect  [30]  IMPLICIT LogotypeReference }

            Tom Gindin

Juergen Brauckmann <[e-mail]>@mail.imc.org on 07/01/2002
08:17:51 AM

Sent by:    [e-mail]


To:    [e-mail]
cc:
Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt



[e-mail] wrote:
>
> 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
Logotypes in
>                           X.509 certificates
>         Author(s)       : S. Santesson, R. Housley, T. Freeman
>         Filename        : draft-ietf-pkix-logotypes-03.txt
>         Pages           : 18
>         Date            : 28-Jun-02


Hi.


**** Page 6, at the end of chapter 3:
   Applications SHOULD enhance processing and off-line functionality by
   cashing logotype data.
   ^^^^^
Funny typo:-) Who cashes whom?;-)


**** LogotypeImageInfo and LogotypeAudioInfo:
In my opinion these data structures lack something like "descriptiveText
UTF8String OPTIONAL" that could be displayed if the source of the images
or audio data is currently unavailable or the data cannot be retrieved.

I can imagine many situations where retrieval of data is not possible,
but nevertheless the functionality of community branding is desired. And
in such situations it would be helpful if the application could present
a simple string to the user.



**** ASN.1:
You declare the Module as IMPLICIT TAGS. But the only use of tags is
LogotypeExtn ::= SEQUENCE {
         communityLogo  [0] LogotypeInfo OPTIONAL,
         issuerLogo     [1] LogotypeInfo OPTIONAL,
         subjectLogo    [2] LogotypeInfo OPTIONAL,
         otherLogos     [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }

      LogotypeInfo ::= CHOICE {
         direct          LogotypeData,
         indirect        LogotypeReference }

Here, the tags are converted silently by clause 30.6 c) of X.680 into
EXPLICIT tags because LogotypeInfo is a CHOICE (IMPLICIT tags on CHOICEs
are implicitely EXPLICIT or something like that). In my opinion the
module would be better readable for implementors if you would declare it
as EXPLICIT.

The LogotypeInfo CHOICE misses a tag when you use module-wide IMPLICIT
or EXPLICIT tagging. LogotypeData and LogotypeReference are both
SEQUENCEs, and for the CHOICE to be parseable, you have to tag the
elements (Clause 28.2. of X.680).


Regards,
    Juergen







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61CHxJ12685 for ietf-pkix-bks; Mon, 1 Jul 2002 05:17:59 -0700 (PDT)
Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61CHww12679 for <[e-mail]>; Mon, 1 Jul 2002 05:17:58 -0700 (PDT)
Received: (from root@localhost) by mystic1.trustcenter.de (8.10.2+Sun/8.10.2) id g61CHOt02557 for <[e-mail]>; Mon, 1 Jul 2002 14:17:24 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.200.233) by mystic1.trustcenter.de via csmap (V6.0) id srcAAA1EaG_e; Mon, 1 Jul 02 14:17:23 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g61CHpQ01055 for <[e-mail]>; Mon, 1 Jul 2002 14:17:51 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 01 Jul 2002 14:17:51 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> 
> 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 Logotypes in
>                           X.509 certificates
>         Author(s)       : S. Santesson, R. Housley, T. Freeman
>         Filename        : draft-ietf-pkix-logotypes-03.txt
>         Pages           : 18
>         Date            : 28-Jun-02


Hi.


**** Page 6, at the end of chapter 3:
   Applications SHOULD enhance processing and off-line functionality by
   cashing logotype data.
   ^^^^^
Funny typo:-) Who cashes whom?;-)


**** LogotypeImageInfo and LogotypeAudioInfo:
In my opinion these data structures lack something like "descriptiveText
UTF8String OPTIONAL" that could be displayed if the source of the images
or audio data is currently unavailable or the data cannot be retrieved. 

I can imagine many situations where retrieval of data is not possible,
but nevertheless the functionality of community branding is desired. And
in such situations it would be helpful if the application could present
a simple string to the user.



**** ASN.1: 
You declare the Module as IMPLICIT TAGS. But the only use of tags is 
LogotypeExtn ::= SEQUENCE {
         communityLogo  [0] LogotypeInfo OPTIONAL,
         issuerLogo     [1] LogotypeInfo OPTIONAL,
         subjectLogo    [2] LogotypeInfo OPTIONAL,
         otherLogos     [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }

      LogotypeInfo ::= CHOICE {
         direct          LogotypeData,
         indirect        LogotypeReference }

Here, the tags are converted silently by clause 30.6 c) of X.680 into
EXPLICIT tags because LogotypeInfo is a CHOICE (IMPLICIT tags on CHOICEs
are implicitely EXPLICIT or something like that). In my opinion the
module would be better readable for implementors if you would declare it
as EXPLICIT.

The LogotypeInfo CHOICE misses a tag when you use module-wide IMPLICIT
or EXPLICIT tagging. LogotypeData and LogotypeReference are both
SEQUENCEs, and for the CHOICE to be parseable, you have to tag the
elements (Clause 28.2. of X.680).


Regards,
    Juergen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61AdZ004626 for ietf-pkix-bks; Mon, 1 Jul 2002 03:39:35 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61AdYw04619 for <[e-mail]>; Mon, 1 Jul 2002 03:39:34 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22400; Mon, 1 Jul 2002 06:38:47 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Date: Mon, 01 Jul 2002 06:38:46 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-03.txt
	Pages		: 18
	Date		: 28-Jun-02
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61AdVU04614 for ietf-pkix-bks; Mon, 1 Jul 2002 03:39:31 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61AdUw04610 for <[e-mail]>; Mon, 1 Jul 2002 03:39:30 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22369; Mon, 1 Jul 2002 06:38:42 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-pmi-schema-00.txt
Date: Mon, 01 Jul 2002 06:38:42 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure LDAP Schema 
                          and Syntaxes for PMIs
	Author(s)	: D. Chadwick, S. Legg
	Filename	: draft-ietf-pkix-ldap-pmi-schema-00.txt
	Pages		: 
	Date		: 28-Jun-02
	
This document describes LDAP schema features that are needed to support 
X.509 Privilege Management Infrastructures. Specifically, X.509 
attribute types, object classes, matching rules, attribute value 
syntaxes and attribute value assertion syntaxes needed for PMIs are 
defined.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-pmi-schema-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-ldap-pmi-schema-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-ldap-pmi-schema-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g61AdPa04596 for ietf-pkix-bks; Mon, 1 Jul 2002 03:39:25 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61AdNw04591 for <[e-mail]>; Mon, 1 Jul 2002 03:39:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22349; Mon, 1 Jul 2002 06:38:36 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-pki-schema-00.txt
Date: Mon, 01 Jul 2002 06:38:35 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure LDAP Schema 
                          and Syntaxes for PKIs
	Author(s)	: D. Chadwick, S. Legg
	Filename	: draft-ietf-pkix-ldap-pki-schema-00.txt
	Pages		: 
	Date		: 28-Jun-02
	
This document describes LDAP schema features that are needed to support 
X.509 Public Key Infrastructures. Specifically, X.509 attribute types, 
object classes, matching rules, attribute value syntaxes and attribute 
value assertion syntaxes needed for PKIs are defined.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-pki-schema-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-ldap-pki-schema-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-ldap-pki-schema-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g618CvY23968 for ietf-pkix-bks; Mon, 1 Jul 2002 01:12:57 -0700 (PDT)
Received: from usermail.chinacomm.com.cn ([211.157.102.9]) by above.proper.com (8.11.6/8.11.3) with SMTP id g618Csw23955 for <[e-mail]>; Mon, 1 Jul 2002 01:12:54 -0700 (PDT)
Message-Id: <[e-mail]>
Received: (qmail 9557 invoked from network); 1 Jul 2002 08:24:04 -0000
Received: from unknown (HELO wangbingyan) (61.48.8.92) by 0 with SMTP; 1 Jul 2002 08:24:04 -0000
Date: Mon, 1 Jul 2002 16:10:44 +0800
From: =?GB2312?Q?=CD=F5=B1=FE=D1=DE?= <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Question about RootCA
X-mailer: FoxMail 4.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g618Ctw23960
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 I was puzzled by the term "root CA" in rfc2510 (CMP).

 The below paragraph is from 1.2.2. 
    We use the term "root CA" to indicate a CA that is directly trusted
    by an end entity; that is, securely acquiring the value of a root CA
    public key requires some out-of-band step(s). This term is not meant
                                                  ----------------------
    to imply that a root CA is necessarily at the top of any hierarchy,
    ------------------------------------------------------------------
    simply that the CA in question is trusted directly.
    --------------------------------------------------
 If there are two CA certificates,
                cert a                       cert b(signed by cert a)
    Issuer    C=US,OU=TSA,CN=a            C=US,OU=TSA,CN=a
    
    subject   C=US,OU=TSA,CN=a            C=US,OU=TSA,CN=b
 
 According to the above statement, certificate b is a "root CA" if there is an 
 end entity trust it.

 Then comes the question about Root CA Key update in Section 2.4.    
    The basis of the procedure described here is that the CA protects its
    new public key using its previous private key and vice versa. Thus
    when a CA updates its key pair it must generate two extra cACertificate 
    attribute values if certificates are made available using an X.500 directory 
    (for a total of four:  OldWithOld; OldWithNew; NewWithOld; and NewWithNew).
                           --------------------------------------------------
 If the CA operator want to update key for cert b, what does the four certificate mean?
                OldWithOld        OldWithNew        NewWithOld         NewWithNew
  Issuer   C=US,OU=TSA,CN=a          ?                 ?                   ?
    
  subject  C=US,OU=TSA,CN=b          ?                 ?                   ?

  signer       cert a                ?                 ?                   ?


Thanks for any answer.
wang bing yan
										[e-mail]
                   ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-07-01