Subject: TSP interoperability testing (RFC 3161)

From: Denis Pinkas <[email-masked]>
Date: Wed, 31 Jul 2002 17:07:59 +0200

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

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 1 Aug 2002 15:01:17 +1200 (NZST)

Denis Pinkas <[email-masked]> writes:

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

Date: Thu, 1 Aug 2002 15:01:17 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  TSP interoperability testing (RFC 3161)
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

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

Date: Wed, 31 Jul 2002 18:04:47 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: Tom Gindin <[email-masked]>
CC: [email-masked], "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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 <[email-masked]>@mail.imc.org on 07/23/2002
> 07:09:52 AM
> 
> Sent by:    [email-masked]
> 
> To:    [email-masked]
> cc:    "David P. Kemp" <[email-masked]>, [email-masked]
> 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: +44 161 295 5351  Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> 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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Wed, 31 Jul 2002 17:54:52 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: "Ramsay, Ron" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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:[email-masked]]
> Sent: Tuesday, 23 July 2002 21:08
> To: [email-masked]
> Cc: [email-masked]
> 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: +44 161 295 5351  Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> 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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Wed, 31 Jul 2002 17:13:20 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-ietf-pkix-warranty-ext-01
Sender: [email-masked]

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:     613-232-2350
> Cell:         613-291-0331

Date: Wed, 31 Jul 2002 17:07:59 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>
Subject: TSP interoperability testing (RFC 3161)
Sender: [email-masked]

Denis

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Delegated Path Validation and Delegated Path Discovery Protocol Requirements to Informational
Date: Tue, 30 Jul 2002 12:45:23 -0400
Sender: [email-masked]

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.

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Date: Tue, 30 Jul 2002 11:45:52 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-09.txt
Sender: [email-masked]

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.

Date: Tue, 30 Jul 2002 12:07:41 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: RFC 3281 Omission
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 30 Jul 2002 11:41:02 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: RFC 3280 has been translated to Japanese
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-wlan-extns-01.txt
Date: Tue, 30 Jul 2002 07:55:16 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-09.txt
Date: Tue, 30 Jul 2002 07:55:11 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

content-class: urn:content-classes:message
Subject: RE: OCSP follow up
Date: Tue, 30 Jul 2002 13:52:20 +0200
From: "Haaino Beljaars" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Hiroyuki CHIBA <[email-masked]>
Cc: [email-masked]
Date: Mon, 29 Jul 2002 15:58:25 -0400
Subject: Re: Wireless LAN Certificate Extensions
Sender: [email-masked]

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" <[email-masked]> 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: [email-masked] [email-masked]
>      Security Solution Promoting Division, Hitachi,Ltd.

To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Wireless LAN Certificate Extensions
From: Hiroyuki CHIBA <[email-masked]>
Date: Tue, 30 Jul 2002 04:01:12 +0900 (JST)
Lines: 28
Sender: [email-masked]

Hi Russ,

>>>>> On Mon, 29 Jul 2002 11:52:39 -0400,
	"Housley, Russ" <[email-masked]> 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: [email-masked] [email-masked]
     Security Solution Promoting Division, Hitachi,Ltd.

From: "Housley, Russ" <[email-masked]>
To: Hiroyuki CHIBA <[email-masked]>
Cc: [email-masked]
Date: Mon, 29 Jul 2002 11:52:39 -0400
Subject: Re: Wireless LAN Certificate Extensions
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-09.txt
Date: Mon, 29 Jul 2002 08:09:02 -0400
Sender: [email-masked]

--NextPart

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

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

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sun, 28 Jul 2002 22:42:42 -0700 (PDT)
From: asadi hamid <[email-masked]>
Subject: X.509 Analysis
To: [email-masked]
Sender: [email-masked]

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

Content-return: allowed
Date: Sun, 28 Jul 2002 21:54:16 -0700
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSP
To: "'Haaino Beljaars'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Haaino Beljaars [mailto:[email-masked]]
> Sent: Sunday, July 28, 2002 11:39 AM
> To: [email-masked]
> 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
> 

To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Wireless LAN Certificate Extensions
From: Hiroyuki CHIBA <[email-masked]>
Date: Mon, 29 Jul 2002 12:08:39 +0900 (JST)
Lines: 31
Sender: [email-masked]

Hi,

>>>>> On Wed, 24 Jul 2002 17:40:33 -0400,
	"Housley, Russ" <[email-masked]> 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: [email-masked] [email-masked]
     Security Solution Promoting Division, Hitachi,Ltd.

Date: Mon, 29 Jul 2002 9:8:5 +0800
From: carol <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: draft-ietf-pkix-rfc2510bis-06.txt and draft-ietf-pkix-rfc2511bis-04.txt
Sender: [email-masked]

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
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡[email-masked]
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-07-29

content-class: urn:content-classes:message
Subject: OCSP 
Date: Sun, 28 Jul 2002 20:38:56 +0200
From: "Haaino Beljaars" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Importance: Normal
Sensitivity: 
Subject: Re: LDAP ISSUE
To: David Chadwick <[email-masked]>
Cc: [email-masked], "David P. Kemp" <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Fri, 26 Jul 2002 15:58:28 -0400
Sender: [email-masked]

      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 <[email-masked]>@mail.imc.org on 07/23/2002
07:09:52 AM

Sent by:    [email-masked]

To:    [email-masked]
cc:    "David P. Kemp" <[email-masked]>, [email-masked]
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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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

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

Date: Thu, 25 Jul 2002 06:54:20 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: Rob G Weemhoff <[email-masked]>
CC: [email-masked]
Subject: Re: current edition of X.509 in the roadmap
Sender: [email-masked]

<!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;
+31(0)20 513&nbsp; 9102</font></font>
<br><font face="sans-serif"><font size=-1>Mobile: +31(0)653263269</font></font>
<p><font face="sans-serif"><font size=-1>E-mail: [email-masked]</font></font>
<br><font face="sans-serif"><font size=-1>Fax: +31(0)33 2470578</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>

Importance: Normal
Sensitivity: 
Subject: Re: interpretation of extended key usage
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Thu, 25 Jul 2002 06:50:50 -0400
Sender: [email-masked]

      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" <[email-masked]> on 07/24/2002 04:25:49 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [email-masked]
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" <[email-masked]>@mail.imc.org on 07/24/2002
>10:10:53 AM
>
>Sent by:    [email-masked]
>
>
>To:    "Heyden, Klaus" <[email-masked]>
>cc:    [email-masked]
>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
> >[email-masked]
> >+49-(0)69-263-11126
> >+49-(0)69-263-15015

To: <[email-masked]>
Subject: current edition of X.509 in the roadmap
Sensitivity: 
From: "Rob G Weemhoff" <[email-masked]>
Date: Thu, 25 Jul 2002 12:32:44 +0200
Sender: [email-masked]

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;+31(0)20 513 &nbsp;9102 &nbsp;<br>
Mobile: +31(0)653263269<br>
<br>
E-mail: [email-masked] &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
Fax: +31(0)33 2470578<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

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

From: "Ramsay, Ron" <[email-masked]>
To: David Chadwick <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: LDAP ISSUE
Date: Thu, 25 Jul 2002 19:05:57 +1000
Sender: [email-masked]

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:[email-masked]]
Sent: Tuesday, 23 July 2002 21:08
To: [email-masked]
Cc: [email-masked]
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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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

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

Date: Tue, 23 Jul 2002 12:07:50 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: [email-masked]
CC: [email-masked]
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Tue, 23 Jul 2002 12:09:52 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: [email-masked]
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Thu, 25 Jul 2002 16:54:26 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  interpretation of  extended key usage
Sender: [email-masked]

"Heyden, Klaus" <[email-masked]> 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.

Date: Wed, 24 Jul 2002 17:40:33 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Wireless LAN Certificate Extensions
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Alice Sturgeon" <[email-masked]>
To: <[email-masked]>
Subject: draft-ietf-pkix-warranty-ext-01
Date: Wed, 24 Jul 2002 17:41:07 -0400
Importance: Normal
Sender: [email-masked]

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:     613-232-2350
Cell:         613-291-0331

From: "Housley, Russ" <[email-masked]>
To: Tom Gindin <[email-masked]>
Cc: [email-masked]
Date: Wed, 24 Jul 2002 16:25:49 -0400
Subject: Re: interpretation of extended key usage
Sender: [email-masked]

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" <[email-masked]>@mail.imc.org on 07/24/2002
>10:10:53 AM
>
>Sent by:    [email-masked]
>
>
>To:    "Heyden, Klaus" <[email-masked]>
>cc:    [email-masked]
>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
> >[email-masked]
> >+49-(0)69-263-11126
> >+49-(0)69-263-15015

Importance: Normal
Sensitivity: 
Subject: Re: interpretation of extended key usage
To: "Housley, Russ" <[email-masked]>
Cc: "Heyden, Klaus" <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Wed, 24 Jul 2002 15:16:15 -0400
Sender: [email-masked]

      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" <[email-masked]>@mail.imc.org on 07/24/2002
10:10:53 AM

Sent by:    [email-masked]

To:    "Heyden, Klaus" <[email-masked]>
cc:    [email-masked]
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
>[email-masked]
>+49-(0)69-263-11126
>+49-(0)69-263-15015

From: "Housley, Russ" <[email-masked]>
To: "Heyden, Klaus" <[email-masked]>
Cc: [email-masked]
Date: Wed, 24 Jul 2002 10:10:53 -0400
Subject: Re: interpretation of  extended key usage
Sender: [email-masked]

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
>[email-masked]
>+49-(0)69-263-11126
>+49-(0)69-263-15015

From: "Heyden, Klaus" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: interpretation of  extended key usage
Date: Wed, 24 Jul 2002 13:12:22 +0200
Sender: [email-masked]

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 
[email-masked] 
+49-(0)69-263-11126 
+49-(0)69-263-15015 

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Jul 2002 17:28:43 +0-900
To: "David Chadwick" <[email-masked]>
Cc: <[email-masked]>
Reply-To: <[email-masked]>
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Jul 2002 17:23:18 +0-900
To: "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>
Reply-To: <[email-masked]>
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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

Date: Fri, 19 Jul 2002 01:41:11 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: Sharon Boeyen <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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:[email-masked]]
> 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: +44 161 295 5351  Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> 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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Fri, 19 Jul 2002 01:39:13 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: "David P. Kemp" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Fri, 19 Jul 2002 01:36:32 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: [email-masked]
CC: [email-masked]
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Thu, 18 Jul 2002 15:07:02 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Jul 2002 01:21:32 +0-900
To: <[email-masked]>
Reply-To: <[email-masked]>
Subject: Re: LDAP ISSUE
Sender: [email-masked]

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

From: Sharon Boeyen <[email-masked]>
To: "'David Chadwick'" <[email-masked]>, PKIX <[email-masked]>
Subject: RE: LDAP ISSUE
Date: Thu, 18 Jul 2002 10:43:46 -0400
Sender: [email-masked]

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:[email-masked]]
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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:[email-masked]">mailto:[email-masked]=
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: +44 161 295 5351&nbsp; Fax +44 01484 =
532930</FONT>
<BR><FONT SIZE=3D2>Mobile: +44 77 96 44 7184</FONT>
<BR><FONT SIZE=3D2>Email: [email-masked]</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--

Importance: Normal
Sensitivity: 
Subject: Re: LDAP ISSUE
To: David Chadwick <[email-masked]>
Cc: PKIX <[email-masked]>
From: "Tom Gindin" <[email-masked]>
Date: Thu, 18 Jul 2002 07:30:07 -0400
Sender: [email-masked]

      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 <[email-masked]>@mail.imc.org on 07/18/2002
02:36:20 AM

Sent by:    [email-masked]

To:    PKIX <[email-masked]>
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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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

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

From: "Vesa Suontama" <[email-masked]>
To: <[email-masked]>
Subject: Re: LDAP ISSUE
Date: Thu, 18 Jul 2002 14:05:35 +0300
Importance: Normal
Sender: [email-masked]

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" <[email-masked]> wrote in message
news:<[email-masked]>...
>
> 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: +44 161 295 5351  Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> 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:+44 77 96 44 7184
> tel;fax:+44 1484 532930
> tel;home:+44 1484 352238
> tel;work:+44 161 295 5351
> x-mozilla-html:FALSE
> url:http://www.salford.ac.uk/its024/chadwick.htm
> org:University of Salford;IS Institute
> version:2.1
> email;internet:[email-masked]
> 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--
>

Date: Thu, 18 Jul 2002 10:34:55 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: PKIX <[email-masked]>
Subject: X.509 PMI Research
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Thu, 18 Jul 2002 07:36:20 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: PKIX <[email-masked]>
Subject: LDAP ISSUE
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Wed, 17 Jul 2002 20:18:51 -0400
To: Pkix <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: draft minutes
Sender: [email-masked]

--============_-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 <[email-masked]>, Tim Polk <[email-masked]>

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;[email-masked]&gt;, Tim Polk
&lt;[email-masked]&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============--

From: "Anders Rundgren" <[email-masked]>
To: "Peter Williams" <[email-masked]>, "'Stephen Kent '" <[email-masked]>
Cc: <[email-masked]>
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
Sender: [email-masked]

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: [email-masked]
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

Date: Wed, 17 Jul 2002 13:31:37 -0400 (EDT)
From: Anne Anderson <[email-masked]>
To: <[email-masked]>
Subject: Encoding of GeneralName choice directoryName
Reply-To: [email-masked]
Sender: [email-masked]

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: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Content-return: allowed
Date: Wed, 17 Jul 2002 09:15:45 -0700
From: Peter Williams <[email-masked]>
Subject: RE: Deciding on how to proceed with DPD/DPV  Was: WG Last Call CL OSED: DPD/DPV Requirements
To: "'Stephen Kent '" <[email-masked]>, "'Anders Rundgren '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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: [email-masked]
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

Date: Wed, 17 Jul 2002 05:04:03 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Deciding on how to proceed with DPD/DPV  Was: WG Last Call CLOSED: DPD/DPV Requirements
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: "Tim Polk" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Housley, Russ" <[email-masked]>, "Denis Pinkas" <[email-masked]>, <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
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

Date: Tue, 16 Jul 2002 19:42:35 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: WG Last Call CLOSED: DPD/DPV Requirements
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: "Tim Polk" <[email-masked]>, "Stephen Kent" <[email-masked]>
Subject: Re: WG Last Call CLOSED: DPD/DPV Requirements
Date: Tue, 16 Jul 2002 12:11:58 +0200
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: "Roberto Opazo" <[email-masked]>, <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>, "Tom Gindin" <[email-masked]>
Subject: Re: PI support 
Date: Mon, 15 Jul 2002 09:10:14 +0200
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
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

Date: Fri, 12 Jul 2002 16:40:51 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: RFC 3281 ASN.1 Errata
Sender: [email-masked]

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

From: "Roberto Opazo" <[email-masked]>
To: <[email-masked]>
Subject: PI support 
Date: Fri, 12 Jul 2002 10:38:42 -0400
Importance: High
Sender: [email-masked]

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

From: "Roberto Opazo" <[email-masked]>
To: <[email-masked]>
Subject: PI support 
Date: Fri, 12 Jul 2002 10:38:42 -0400
Importance: High
Sender: [email-masked]

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

From: "Roberto Opazo" <[email-masked]>
To: <[email-masked]>
Subject: PI support 
Date: Fri, 12 Jul 2002 10:38:42 -0400
Importance: High
Sender: [email-masked]

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

Date: Thu, 11 Jul 2002 09:09:07 -0400
To: [email-masked], [email-masked]
From: Tim Polk <[email-masked]>
Subject: Request for IESG consideration: PKIX Permanent Identifier
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Wed, 10 Jul 2002 10:55:24 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: PKIX WG agenda for 54th IETF
Cc: [email-masked]
Sender: [email-masked]

--=====================_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 <[email-masked]>, Tim Polk <[email-masked]>

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

To: [email-masked]
Subject: agenda requests
Date: Tue, 09 Jul 2002 07:10:11 -0400 (EDT)
From: [email-masked]
Sender: [email-masked]

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

Date: Mon, 8 Jul 2002 20:29:16 -0700 (PDT)
From: phoffman <[email-masked]>
To: [email-masked]
Subject: A  humour game
Sender: [email-masked]

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

--HO7zst6f89q0F1wmV5K1e--

From: Oeser Thomas <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Clarifications regarding Private Internet Extensions - Authority  Information Access of RFC 3280
Date: Mon, 8 Jul 2002 16:05:57 +0200 
Sender: [email-masked]

> 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:	[email-masked]	< \
> 
> 

Date: Fri, 05 Jul 2002 12:14:13 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>, S-MIME / IETF <[email-masked]>
Subject: Attribute Certification
Sender: [email-masked]

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 [email-masked], with copy to
the editor on [email-masked] 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.

Date: Fri, 05 Jul 2002 11:53:30 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Yee, Peter" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-acmc-01.txt
Sender: [email-masked]

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

Date: Thu, 04 Jul 2002 16:16:56 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: David Hopwood <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pr-tsa-01.txt
Sender: [email-masked]

David,

> [email-masked] 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 <[email-masked]>

Date: Thu, 4 Jul 2002 22:49:09 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

"DUBUISSON Olivier" <[email-masked]> 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.

Date: Thu, 04 Jul 2002 12:14:08 +0200
From: Juergen Brauckmann <[email-masked]>
Organization: TC TrustCenter AG
To: DUBUISSON Olivier <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Sender: [email-masked]

> 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

content-class: urn:content-classes:message
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Date: Thu, 4 Jul 2002 11:55:00 +0200
From: "DUBUISSON Olivier" <[email-masked]>
To: "Housley, Russ" <[email-masked]>
Cc: "Juergen Brauckmann" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - 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: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - <A =
HREF=3D"http://asn1.elibel.tm.fr/">http://asn1.elibel.tm.fr/</A></FONT>
</P>

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 02 Jul 2002 11:04:52 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Sender: [email-masked]

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" <[email-masked]> 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.

Date: Tue, 2 Jul 2002 20:54:08 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Cc: [email-masked]
Sender: [email-masked]

"Housley, Russ" <[email-masked]> 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.

From: "Vesa Suontama" <[email-masked]>
To: <[email-masked]>
Subject: Re: about test server
Date: Tue, 2 Jul 2002 10:05:50 +0300
Importance: Normal
Sender: [email-masked]

Hi,

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

Vesa

""forward"" <[email-masked]> 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
>

Date: Mon, 01 Jul 2002 16:53:47 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: I-D ACTION:draft-ietf-pkix-scvp-09.txt
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Juergen Brauckmann <[email-masked]>
Cc: [email-masked]
Date: Mon, 01 Jul 2002 16:38:30 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Juergen Brauckmann <[email-masked]>
Cc: [email-masked]
Date: Mon, 01 Jul 2002 12:41:21 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 01 Jul 2002 13:19:17 -0400
Subject: Re: draft-ietf-pkix-warranty-extn-01
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Juergen Brauckmann <[email-masked]>
Cc: [email-masked]
Date: Mon, 01 Jul 2002 13:00:33 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Sender: [email-masked]

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

Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
To: Juergen Brauckmann <[email-masked]>
Cc: [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Mon, 1 Jul 2002 13:33:56 -0400
Sender: [email-masked]

      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 <[email-masked]>@mail.imc.org on 07/01/2002
08:17:51 AM

Sent by:    [email-masked]

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

[email-masked] 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

Date: Mon, 01 Jul 2002 14:17:51 +0200
From: Juergen Brauckmann <[email-masked]>
Organization: TC TrustCenter AG
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Sender: [email-masked]

[email-masked] 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-03.txt
Date: Mon, 01 Jul 2002 06:38:46 -0400
Sender: [email-masked]

--NextPart

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

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

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ldap-pmi-schema-00.txt
Date: Mon, 01 Jul 2002 06:38:42 -0400
Sender: [email-masked]

--NextPart

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

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

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ldap-pki-schema-00.txt
Date: Mon, 01 Jul 2002 06:38:35 -0400
Sender: [email-masked]

--NextPart

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

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

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 1 Jul 2002 16:10:44 +0800
From: =?GB2312?Q?=CD=F5=B1=FE=D1=DE?= <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Question about RootCA
Sender: [email-masked]

 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
										[email-masked]
                   ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-07-01