Re: Microsoft and multi-valued RDNs (was: draft minutes)

["todd glassey" <[e-mail]>]

Stephen this is the fundamental failing of the IESG to not 'slap you silly'
for this... But you nor any other WG Chair were empowered to make your WG a
fiefdom, so it is not for you to say what is and is not a standard nor is it
appropriate for you to make any value judgments as a WG chair as to what the
IETF is all about. That is for its members to decide and as a member you get
one and only one vote... and as a WG Chair you get NO votes.

WG Chairs are there (they exist) as facilitators to make sure that fair and
open and the rest of the language about WG's and the IETF's standards
process are implemented. Which is to say you as a WG Chair were the
implementer of policy not its creator.

Oh - as to the comment you made to me about veiled threats - I don't make
them.

Todd Glassey

----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, July 31, 2003 9:01 AM
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)


>
> Peter,
>
> We fundamentally disagree about the role of standards. Your
> criticisms of the differences between PKIX RFCs and the real world,
> also applies to the differences between the base X.509 standards and
> the real world, and it is often true of other standards, vs. the real
> world. I do not believe that standards should merely codify what
> vendors have chosen to implement, especially in cases like this.  Let
> me explain.
>
> Some features in some standards are unduly complex and implementors
> may choose to not support them as a result. Oft times the desire to
> speed a product to market creates additional pressures to drop
> certain features in early releases, with the notion that support can
> be added later, if necessary.  Sometimes an implementor does not
> understand a feature and decides that the feature is unimportant, as
> a result of the lack of understanding.  Sometimes an implementor
> disagrees with the standard and choose to implement a feature
> differently.
>
> In principle, in a free market system with knowledgeable buyers, all
> of these reasons for deviating from standards can be addressed over
> time, either by fixes to the products or by changes to standards.
> However, the real world is not so neat. Buyers of PKI technology do
> not always think ahead or they may be persuaded, by folks like you,
> to work around defects in implementations, i.e., to warp requirements
> to fit the available software. Microsoft is a monopolist (as
> certified by US courts and the EU) in this space, so the free market
> argument does not apply so well either. In the case we are
> discussing, some users have expressed a need for this feature, it is
> not unduly complex, and thus it ought to remain in the standards.
>
> Steve
>
> P.S. If one applied your model to TCP, we should not have checksums
> in that protocol. I say this because in the early days or TCP/IP use
> in the academic and R&D community, BSD was THE Unix implementation.
> Bill Joy (why is it always people named "Bill" who cause these
> problems?) decided that the cost of computing the TCP checksum was
> high and resulted in diminished throughout, and besides, in the
> typical Ethernet LAN context, the CRC caught errors anyway. So, for a
> while BSD didn't bother computing the checksum, at least if it could
> detect that the peer implementation was another BSD system. DARPA,
> who was funding this work, had to bring significant pressure to bear,
> to quash this behavior. If we followed your model then during that
> window, we would have removed the TCP checksum computation from the
> standard, to reflect the reality of the dominant implementation.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7158fqt037933 for <[e-mail]>; Thu, 31 Jul 2003 22:08:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7158egQ037932 for ietf-pkix-bks; Thu, 31 Jul 2003 22:08:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7158cqt037926 for <[e-mail]>; Thu, 31 Jul 2003 22:08:39 -0700 (PDT) (envelope-from [e-mail])
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id <B00011f39f>; Fri, 01 Aug 2003 15:04:35 +1000
Received: (qmail 2535 invoked from network); 1 Aug 2003 05:04:04 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 1 Aug 2003 05:04:04 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'David Chadwick'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: LDAPv3 Profile Issue
Date: Fri, 1 Aug 2003 15:08:34 +1000
Message-ID: <002001c357ea$f60592b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

David Chadwick wrote:
> Colleagues
>
> at the Vienna meeting I stated that the only outstanding
> issue with the
> LDAPv3 profile was the use of multi-valued RDNs. However,
> there is also
> the use of the ;binary extension that still has to be addressed and
> resolved (unfortunately), since the profile needs to state what PKI
> clients should do with ;binary.

I thought this was already resolved. Tim Polk previously proposed the
following to the list:

  (1) Upon review of the PKIX-LDAP “survey” we see a critical mass of PKI
clients
  and LDAP servers that achieve interoperability using LDAPv3 with the
;binary
  option.  As these clients appear to be in the majority, we believe the
best
  approach is to maintain this option for the transfer of X.509 certificates
and
  CRLs.  Since this is the behavior documented in RFCs 2251, 2252, and 2256
(as
  well as the overarching 3377) this will require the least changes to the
LDAPv3
  specifications as well.

  (4) The lack of a defined LDAP-specific encoding for Certificate,
Certificate
  List and Certificate Pair syntaxes is a problem, as a small percentage of
  implementations transfer these attributes without the ;binary option.
Rather
  than be silent, we suggest that the PKIX syntax and schema document state
the
  LDAP-specific encoding used in transfer without the ;binary option but
  deprecate its use.  This LDAP-specific encoding has the same transfer
  representation as when the attribute is transferred with the ;binary
option.

As I recall there was no serious dissent. Consensus seems to have been
achieved.
I wrote draft-legg-ldap-binary-00.txt assuming this was the case.

Regards,
Steven

>
> The ;binary issue is holding up the final calls on the LDAPv3 profile,
> and the LDAP PKI and PMI schema documents (from Steven Legg
> and myself).
> Fortunately it does not affect the LDAP attribute extraction schema
> profiles that are due to be published as Informational RFCs, but
> nevertheless we do need closure on the ;binary issue as soon
> as possible
>
> regards
>
> David
>
> --
> *********************************************************
>
> Leaders of the world's richest nations meet in Cancun on
> September 10th
> 2003. Oxfam is presenting them with a petition to make trade fair. Be
> sure your voice is heard. Sign the 'Big Noise' petition to make trade
> fair at:
>
> http://www.maketradefair.com/go/join/?p=omf1
>
>
> *****************************************************************
>
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Web site: http://sec.isi.salford.ac.uk
> Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h714ETqt036017 for <[e-mail]>; Thu, 31 Jul 2003 21:14:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h714ET4H036016 for ietf-pkix-bks; Thu, 31 Jul 2003 21:14:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h714EQqt036006 for <[e-mail]>; Thu, 31 Jul 2003 21:14:27 -0700 (PDT) (envelope-from [e-mail])
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id <B00011f28d>; Fri, 01 Aug 2003 14:10:20 +1000
Received: (qmail 28979 invoked from network); 1 Aug 2003 04:09:49 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 1 Aug 2003 04:09:49 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'David Chadwick'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: Issues in LDAP schema IDs
Date: Fri, 1 Aug 2003 14:14:19 +1000
Message-ID: <001e01c357e3$61e70a70$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

David Chadwick wrote:
> Peter and I have resolved all the issues described at the PKIX meeting
> today, apart from one, which is what should be the attribute 
> type to be
> used to hold the X.509 DER encoded attribute. Should it be 
> the original
> attribute type name e.g. userCertificate or a new attribute 
> whose schema
> says it must be single valued. Comments please to the list to help us
> resolve this final issue.

If the original attribute type name is used in the child entry then
a client that uses the X.509 matching rules, or component matching rules,
to match certificates in situ will get each certificate twice. Once in a
subject's entry and once in a child entry of the subject. If a new
attribute type is used then the child entries will not normally be seen
by clients directly matching on certificates.

Clients not using direct matching have to be configured to search on
the extracted attributes. Configuring them to also ask for the new
attribute type shouldn't be a serious impediment.

Regards,
Steven 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h710veqt026255 for <[e-mail]>; Thu, 31 Jul 2003 17:57:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h710veOr026254 for ietf-pkix-bks; Thu, 31 Jul 2003 17:57:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h710vcqt026241 for <[e-mail]>; Thu, 31 Jul 2003 17:57:39 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (84.sanjose-05-10rs16rt.ca.dial-access.att.net[12.81.6.84]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030801005733111004l31le>; Fri, 1 Aug 2003 00:57:34 +0000
Message-ID: <00f201c357c7$dfc95d10$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <p05210604bb4eed81d497@[128.89.89.75]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 31 Jul 2003 17:56:59 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen this is the fundamental failing of the IESG to not 'slap you silly'
for this... But you nor any other WG Chair were empowered to make your WG a
fiefdom, so it is not for you to say what is and is not a standard nor is it
appropriate for you to make any value judgments as a WG chair as to what the
IETF is all about. That is for its members to decide and as a member you get
one and only one vote... and as a WG Chair you get NO votes.

WG Chairs are there (they exist) as facilitators to make sure that fair and
open and the rest of the language about WG's and the IETF's standards
process are implemented. Which is to say you as a WG Chair were the
implementer of policy not its creator.

Oh - as to the comment you made to me about veiled threats - I don't make
them.

Todd Glassey

----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, July 31, 2003 9:01 AM
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)


>
> Peter,
>
> We fundamentally disagree about the role of standards. Your
> criticisms of the differences between PKIX RFCs and the real world,
> also applies to the differences between the base X.509 standards and
> the real world, and it is often true of other standards, vs. the real
> world. I do not believe that standards should merely codify what
> vendors have chosen to implement, especially in cases like this.  Let
> me explain.
>
> Some features in some standards are unduly complex and implementors
> may choose to not support them as a result. Oft times the desire to
> speed a product to market creates additional pressures to drop
> certain features in early releases, with the notion that support can
> be added later, if necessary.  Sometimes an implementor does not
> understand a feature and decides that the feature is unimportant, as
> a result of the lack of understanding.  Sometimes an implementor
> disagrees with the standard and choose to implement a feature
> differently.
>
> In principle, in a free market system with knowledgeable buyers, all
> of these reasons for deviating from standards can be addressed over
> time, either by fixes to the products or by changes to standards.
> However, the real world is not so neat. Buyers of PKI technology do
> not always think ahead or they may be persuaded, by folks like you,
> to work around defects in implementations, i.e., to warp requirements
> to fit the available software. Microsoft is a monopolist (as
> certified by US courts and the EU) in this space, so the free market
> argument does not apply so well either. In the case we are
> discussing, some users have expressed a need for this feature, it is
> not unduly complex, and thus it ought to remain in the standards.
>
> Steve
>
> P.S. If one applied your model to TCP, we should not have checksums
> in that protocol. I say this because in the early days or TCP/IP use
> in the academic and R&D community, BSD was THE Unix implementation.
> Bill Joy (why is it always people named "Bill" who cause these
> problems?) decided that the cost of computing the TCP checksum was
> high and resulted in diminished throughout, and besides, in the
> typical Ethernet LAN context, the CRC caught errors anyway. So, for a
> while BSD didn't bother computing the checksum, at least if it could
> detect that the peer implementation was another BSD system. DARPA,
> who was funding this work, had to bring significant pressure to bear,
> to quash this behavior. If we followed your model then during that
> window, we would have removed the TCP checksum computation from the
> standard, to reflect the reality of the dominant implementation.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VJ0eqt003236 for <[e-mail]>; Thu, 31 Jul 2003 12:00:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VJ0e8I003235 for ietf-pkix-bks; Thu, 31 Jul 2003 12:00:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VJ0cqt003229 for <[e-mail]>; Thu, 31 Jul 2003 12:00:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6VJ0VD9024300; Thu, 31 Jul 2003 15:00:31 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060dbb4f16e6882b@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 31 Jul 2003 14:59:30 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

I think you are misinterpreting my position, somewhat :-)

We both agree that standards ought not embody undue complexity, 
features that nobody wants now and will never want, etc.

We disagree about where to draw the line re complexity, and about 
whether a willingness of users to distort their requirements to 
accommodate implementation limitations is a basis for changing 
standards.

Steve

P.S.  the good news is that our messages are getting shorter



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VIqrqt002912 for <[e-mail]>; Thu, 31 Jul 2003 11:52:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VIqr9R002909 for ietf-pkix-bks; Thu, 31 Jul 2003 11:52:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VIqpqt002885 for <[e-mail]>; Thu, 31 Jul 2003 11:52:52 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6VIqdak023755; Fri, 1 Aug 2003 06:52:39 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6VIqdw26194; Fri, 1 Aug 2003 06:52:39 +1200
Date: Fri, 1 Aug 2003 06:52:39 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>P.S. If one applied your model to TCP, we should not have checksums in that
>protocol. 

I think that's misrepresenting my position somewhat:

  My version of TCP would have a simple, straightforward, easy-to-get-right
  checksum (pretty much the same as what TCP does now), implementation notes
  and a rationale to guide implementors, and test vectors so people could
  check that their implementation is correct (see any RFC I've written).

  The PKIX version of TCP would have eight different checksums with two dozen
  sets of parameters.  Many checksum parameters are optional, but if you leave
  some of them out then things fail for no apparent reason.  Some are
  mandatory but have no discernable purpose, so people leave them out because
  it simplifies the implementation.  The mechanisms are identified by entries
  in an LDAP directory indexed with a multi-valued AVA in an RDN.  There are
  five different ways of applying the various checksums (one for each vendor
  that contributed to the standard), all incompatible and several mutually
  exclusive.  There's no explanation for any of the design features, so
  implementors have to guess at what they're supposed to do.  Everyone guesses
  differently.  There are no test vectors.  Nothing interoperates without
  extended, multi-iteration bakeoffs in which each side tries to match their
  guesses at what bits of the standard are supposed to mean with the other
  side's guesses at what bits of the standard are supposed to mean.  The best
  way to make sure things work is to buy everything from the same vendor, and
  even then things often only work under carefully-controlled lab conditions.

Now I'm being facetious there, but the scary thing is that I've described
fairly closely a number of PKIX RFCs (not to mention OSI before it).  I'll
omit RFC names, but anyone with any implementation experience will recognise
all of the above in various PKIX standards.  So on the one hand the scientist
part of me thinks that methodically repeating the failure of the OSI
standards-creation process in PKI is a good thing, since it's demonstrating
repeatability - OSI wasn't just a one-off thing, we can do it all again with
the same result (this is why I have a t-shirt that proclaims "PKI: The OSI of
a new generation").  On the other hand the engineering part of me, which just
wants to build something that works and is clean and elegant, is less than
thrilled with the prospect of PKI ending life as a 2-page historical footnote
in networking and security textbooks, as its predecessor for the most part
has.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VG5qqt092587 for <[e-mail]>; Thu, 31 Jul 2003 09:05:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VG5qav092586 for ietf-pkix-bks; Thu, 31 Jul 2003 09:05:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VG5oqt092567 for <[e-mail]>; Thu, 31 Jul 2003 09:05:50 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6VG5VD9012473; Thu, 31 Jul 2003 12:05:32 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210604bb4eed81d497@[128.89.89.75]>
Date: Thu, 31 Jul 2003 12:01:04 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

We fundamentally disagree about the role of standards. Your 
criticisms of the differences between PKIX RFCs and the real world, 
also applies to the differences between the base X.509 standards and 
the real world, and it is often true of other standards, vs. the real 
world. I do not believe that standards should merely codify what 
vendors have chosen to implement, especially in cases like this.  Let 
me explain.

Some features in some standards are unduly complex and implementors 
may choose to not support them as a result. Oft times the desire to 
speed a product to market creates additional pressures to drop 
certain features in early releases, with the notion that support can 
be added later, if necessary.  Sometimes an implementor does not 
understand a feature and decides that the feature is unimportant, as 
a result of the lack of understanding.  Sometimes an implementor 
disagrees with the standard and choose to implement a feature 
differently.

In principle, in a free market system with knowledgeable buyers, all 
of these reasons for deviating from standards can be addressed over 
time, either by fixes to the products or by changes to standards. 
However, the real world is not so neat. Buyers of PKI technology do 
not always think ahead or they may be persuaded, by folks like you, 
to work around defects in implementations, i.e., to warp requirements 
to fit the available software. Microsoft is a monopolist (as 
certified by US courts and the EU) in this space, so the free market 
argument does not apply so well either. In the case we are 
discussing, some users have expressed a need for this feature, it is 
not unduly complex, and thus it ought to remain in the standards.

Steve

P.S. If one applied your model to TCP, we should not have checksums 
in that protocol. I say this because in the early days or TCP/IP use 
in the academic and R&D community, BSD was THE Unix implementation. 
Bill Joy (why is it always people named "Bill" who cause these 
problems?) decided that the cost of computing the TCP checksum was 
high and resulted in diminished throughout, and besides, in the 
typical Ethernet LAN context, the CRC caught errors anyway. So, for a 
while BSD didn't bother computing the checksum, at least if it could 
detect that the peer implementation was another BSD system. DARPA, 
who was funding this work, had to bring significant pressure to bear, 
to quash this behavior. If we followed your model then during that 
window, we would have removed the TCP checksum computation from the 
standard, to reflect the reality of the dominant implementation.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VF21qt089856 for <[e-mail]>; Thu, 31 Jul 2003 08:02:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VF21st089855 for ietf-pkix-bks; Thu, 31 Jul 2003 08:02:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from netfin.mellon.com.gr (IDENT:[e-mail] [212.251.40.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VF1uqt089843 for <[e-mail]>; Thu, 31 Jul 2003 08:01:59 -0700 (PDT) (envelope-from [e-mail])
Received: from IT030 ([192.168.1.110]) by netfin.mellon.com.gr (8.11.6/8.11.6) with ESMTP id h6VE4BL25444 for <[e-mail]>; Thu, 31 Jul 2003 17:04:11 +0300
From: "Nikolas Mihalopoulos" <[e-mail]>
To: <[e-mail]>
Subject: Issuer field on Certificates
Date: Thu, 31 Jul 2003 18:01:52 +0300
Message-ID: <000001c35774$ad095a40$6e01a8c0@IT030>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I am kind of new on this list and I do not know if this has been asked
before so bear with me.
RFC 3280 discusses the Issuer field on certificate and in particular the
DirectoryString type which is defined:

The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString, UTF8String, and UniversalString. The
UTF8String encoding [RFC 2279] is the preferred encoding, and all
certificates issued after December 31, 2003 MUST use the UTF8String
encoding of DirectoryString (except as noted below). Until that
date, conforming CAs MUST choose from the following options when
creating a distinguished name, including their own: 
(a) if the character set is sufficient, the string MAY be
represented as a PrintableString;
(b) failing (a), if the BMPString character set is sufficient the
string MAY be represented as a BMPString; and
(c) failing (a) and (b), the string MUST be represented as a
UTF8String. If (a) or (b) is satisfied, the CA MAY still choose
to represent the string as a UTF8String.
...

So if you have a CA which was created using the PrintableString before
that date what exactly would happen?

Does someone (an application/implementation) have to do something?

Is this another Y2K (or Y2.003K ) issue?

Or it just depends on your specific character string?

Thanks in advance,

****************************************
Nikolas Mihalopoulos
Security Software Engineer
Mellon Technologies
59, Panepistimiou str. 105 64 Athens Greece
Tel.: [phone], Fax: [phone]
Direct:(30) 210 3727765
Email: [e-mail]
 
Disclaimer
This e-mail is confidential. If you are not the intended recipient, you
should not copy it, re-transmit it, use it or disclose its contents, but
should return it to the sender immediately and delete the copy from your
system.
 
MELLON TECHNOLOGIES SAIC cannot accept any responsibility for the
accuracy or completeness of this message as it has been transmitted over
a public network. If you suspect that the message may have been
intercepted or amended, please call the sender.
roaming signature




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VDstqt081331 for <[e-mail]>; Thu, 31 Jul 2003 06:54:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VDstn5081330 for ietf-pkix-bks; Thu, 31 Jul 2003 06:54:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VDsrqt081323 for <[e-mail]>; Thu, 31 Jul 2003 06:54:53 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6VDsFDD001373; Thu, 31 Jul 2003 09:54:16 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210602bb4ecf73ec1a@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05210605bb4d7c0019ee@[128.89.89.75]> <[e-mail]>
Date: Thu, 31 Jul 2003 09:53:56 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:30 +0200 7/31/03, Denis Pinkas wrote:
>Steve,
>
>(...)
>
>>>CAs do NOT archive CRLs today. They do not need to archive CRLs tomorrow.
>>>Relying parties (or verifiers) need to capture the CRLs when 
>>>available (as well as the OCSP responses when doing the first 
>>>validation). Archiving this information is then their concern.
>
>>>Denis
>
>>I think a better characterization here is that CAs are not required 
>>to archive CRLs based on X.509 or PKIX standards. Various national 
>>or (in the U.S.) state laws relating to digital signatures may 
>>impose this requirement, or an organization operating a CA may 
>>choose to archive CRLs.  The statement you made is just a bit too 
>>strong to be correct :-)
>
>We are both incorrect. :-)
>
>CAs usually archive CRLs in order to prove that they behaved 
>correctly in case of an audit or in case of a dispute with relying 
>parties. They may use the archives to demonstrate that they behaved 
>correctly.
>
>They are not required to provide an on-line service to these 
>archives, which are very seldomly used. For that reason, we are not 
>going to define a protocol to access that archived information.
>
>Denis
>
>>Steve

I think we are now mostly in agreement.  Whether a WG defines a 
protocol for access to these archived CRLs is probably beyond the 
scope of PKIX's charter, given the IESG's desire for us to wrap up 
our current work items, so someone else will get to decide whether 
they want to pursue the matter.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VBCIqt066327 for <[e-mail]>; Thu, 31 Jul 2003 04:12:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VBCIBo066326 for ietf-pkix-bks; Thu, 31 Jul 2003 04:12:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cmailm4.svr.pol.co.uk (cmailm4.svr.pol.co.uk [195.92.193.211]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VBCHqt066316 for <[e-mail]>; Thu, 31 Jul 2003 04:12:17 -0700 (PDT) (envelope-from [e-mail])
Received: from modem-1468.baboon.dialup.pol.co.uk ([81.78.21.188] helo=PEDIGREE) by cmailm4.svr.pol.co.uk with smtp (Exim 4.14) id 19iBLz-0004nh-Tv; Thu, 31 Jul 2003 12:12:16 +0100
From: "Dean Adams" <[e-mail]>
To: <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Thu, 31 Jul 2003 12:12:16 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis,
	Some comments if I may:
>
> CAs usually archive CRLs in order to prove that they behaved correctly in
> case of an audit or in case of a dispute with relying parties.
> They may use
> the archives to demonstrate that they behaved correctly.

So let me get this straight - The primary use of long term aaccess to
historical certificate status information is to protect the CA, not to
protect an RP ? ;-)
Some of us are also trying to provide a service to users that they actually
find useful and helpful.  I don't like to be put in the position of
effectively telling users "Look - we told you back in the year XXXX that
this certificate was revoked - you should have remembered" ;-)

>
> They are not required to provide an on-line service to these
> archives, which
> are very seldomly used. For that reason, we are not going to define a
> protocol to access that archived information.

H'mm - not required - please excuse my ignorance of how such things come
about. How do we decide on what is and what is not required?  Do we have any
market requirements input to the PKIX process?  How was it decided that
warranty extensions, permanent identifiers, logotypes for instance - were a
requirement - yet providing assistance in the long term verification of
signatures - was not.  I'm not being critical of these other efforts - I'm
genuinely curious.

	Regards
	Dean




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VAgiqt063908 for <[e-mail]>; Thu, 31 Jul 2003 03:42:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VAgioa063907 for ietf-pkix-bks; Thu, 31 Jul 2003 03:42:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cmailm5.svr.pol.co.uk (cmailm5.svr.pol.co.uk [195.92.193.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VAghqt063894 for <[e-mail]>; Thu, 31 Jul 2003 03:42:43 -0700 (PDT) (envelope-from [e-mail])
Received: from modem-1468.baboon.dialup.pol.co.uk ([81.78.21.188] helo=PEDIGREE) by cmailm5.svr.pol.co.uk with smtp (Exim 4.14) id 19iAt8-0005pb-0C; Thu, 31 Jul 2003 11:42:26 +0100
From: "Dean Adams" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Thu, 31 Jul 2003 11:42:26 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,
	Apologies for my delayed response - unfortunately I am working on multiple
PKI deployments and only have limited opportunity to keep up with these
emails.

I appreciate your comments, but I think that I didn't explain myself clearly
enough.  The "FullHistory CRL" suggestion listed as being a (2) style of
approach was meant to contain all certs that have ever been revoked under a
particular CA cert.  Therefore, no parameters would be necessary - you would
be guaranteed to be able to establish if a particular client cert had ever
been revoked, and when.  Not sure if this suggestion is a winner, since for
very large and long term deployments, this CRL could be very large.  On the
other hand, only RPs that are verifying signatures on docs or transactions
after the cert has expired, would need to pull this down.  It would never be
needed for authentication activities, or for the period when the cert is
still valid.

Your discussion of parameters being supplied is probably a better approach
from a network performance perpective, since it provides a way for the RP
client application to be able to specify more tightly what revocation
information it is interested in, by perhaps supplying a date as a parameter
(as you suggest), or by presenting the client cert being verified and
letting the CA determine (by whatever means it decides to use) if the cert
had been revoked and when - then communicating that info back to the RP.
This is the tyoe of approach I meant to hint at in the list item (1).

Unfortunately, any work in this area would seem to require a change to
client applications.

If we want PKI to be able to service the signing and long term verification
of documents and transactions, we need some way of allowing an RP to be able
to get certificate status information, for a long time after the certificate
expired.  I cannot agree with Denis that it is the obligation of each RP to
archive such material for possible future use.  This is not user friendly,
and is in any case impractical for the vast majority of simple consumer-type
users who may be required to verify signatures over an extended period and
who (even if they did archive CRLs) may not be able to so if they somehow
lose the archived CRL (unless we also wanted to impose disaster revovery
requiremts on each simple consumer-type user).  Lets remeber that the I in
PKI is infrastructure - make provide the services that people need to be
able to carry on their normal lives without becoming computer wizards.

	Regards
	Dean


>         Dean:
>
>         I don't see how a full history CRL location would work without a
> parameter for the effective date.  FreshestCRL doesn't need such a
> parameter.  If we assumed that we want an "archivedCRL" accessMethod in
> AIA, how would the accessLocation represent the effective date parameter?
> I assume that it's appropriate for such an accessMethod to use HTTP or
> HTTPS.
>         An example of the URL for the actual query (for about now) would
> be:
>         https://www.publicCA.com/archivedCRL?date=200307301530Z
>         An RP actually using this feature would be able to construct the
> query by substituting the effective time into the URL.  I also would ask
> if we need variants of this for "last CRL not later than" and "first CRL
> not before".
>
>                 Tom Gindin
>
>
>
>
>
> "Dean Adams" <[e-mail]>
> Sent by: [e-mail]
> 07/29/2003 04:37 PM
>
>
>         To:     <[e-mail]>
>         cc:
>         Subject:        RE: Why is privateKeyUsagePeriod deprecated?
>
>
>
>
> Russ,
>                  Surely, merely finding some way to ensure that a CA
> archives CRLs is not
> enough.  Some way has to be provided to allow client applications to
> discover where the appropriate CRL to be checked, can be found.
>
> Some possible options for consideration:
> 1) the first CRL that was published after the
>    expiry date of the client cert being checked
> 2) the location of a fully maintained complete CRL
>    containing all history with regard to revoked certs
>    that were issued from a particular CA certificate
>
> I'm sure there are other options too, but in any case some means of
> communicating this info to the client application needs to be defined.
> Perhaps some certificate extension similar to "Freshest CRL" that instead
> denotes "FullHistory CRL" would be appropriate?  That (or something in
> Authority Info Access) might provide a solution for (2).  Not sure how you
> might go about providing a solution for a (1) type of approach, without
> getting overly complicated.
>
> Dean Adams
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Russ Housley
> Sent: 29 July 2003 16:56
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Why is privateKeyUsagePeriod deprecated?
>
>
>
> Peter:
>
> On one hand I agree, but on another I do not.
>
> I agree that signatures need to be validated after the certificate
> expires.
>
> The algorithm in RFC 3280 allows the certificate to be validate with
> respect to a date other than today.  The date that ought to be input
> requires a trusted time that the signature was applied.  Of course, PKIX
> has developed a protocol to provide such a time stamp.
>
> An archive of the revocation information is not routinely offered by
> CAs.  How do we make that happen?
>
> Russ
>
> At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:
>
> >Stephen Kent <[e-mail]> writes:
> >
> > >I was not an author for 2459 or 3280, but my feeling is that we do not
> > >recommend use of PKUP for several reasons:
> >
> >But those are mostly just hypothetical objections.  At the moment we have
> two
> >inescapabable facts:
> >
> >1. CAs issue certs based on a 1-year billing cycle, and nothing anyone
> says
> >    will change that.  No CA will issue a cert with a 20-year lifetime,
> unless
> >    it's for its own CA certs.
> >
> >2. Users need to use certs to validate signatures at n times the
> CA-ordained
> >    lifetime.  In the abscence of any mechanism to do this, they are
> ignoring
> >    the cert expiry time.  In other words, out of necessity, they're
> > making the
> >    following change to RFC 3280:
> >
> >     The validity period for a certificate is the period of time from
> > notBefore
> >     through notAfter, inclusive.  When used with signing certificates,
> >     implementations SHOULD NOT pay any attention to the notAfter date.
> >
> >Given that this isn't going to change, it would seem that some guidance
> for
> >users would be useful here.  Since neither (1) nor (2) can be altered,
> what
> >would be needed is a simple extension, found in signing certs,
> containing
> a
> >date to which the cert can still be used for signature-checking beyond
> the
> >obvious notAfter value.  This could be written up as a short one-page
> >application note, no more (well, a bit more once you add all the usual
> >boilerplate and whatnot).
> >
> >Now CAs can still decide not to issue certs like that, but (a) they can't
> >justify it by claiming it screws up their standard cert cycle because it
> >doesn't affect validTo/validFrom, and (b) users at least have some
> guidance
> as
> >to what to do, which is better than the current situation where all they
> can
> >do is ignore parts of the standard on an ad hoc basis.
> >
> >Peter.
>
>
>
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V9VUqt058276 for <[e-mail]>; Thu, 31 Jul 2003 02:31:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6V9VUZB058273 for ietf-pkix-bks; Thu, 31 Jul 2003 02:31:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from einsteinium.btinternet.com (einsteinium.btinternet.com [194.73.73.147]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V9VTqt058266 for <[e-mail]>; Thu, 31 Jul 2003 02:31:29 -0700 (PDT) (envelope-from [e-mail])
Received: from host217-39-113-87.in-addr.btopenworld.com ([217.39.113.87] helo=deanstecra) by einsteinium.btinternet.com with esmtp (Exim 3.22 #23) id 19i9mM-0006Fr-00 for [e-mail]; Thu, 31 Jul 2003 10:31:22 +0100
Reply-To: <[e-mail]>
From: "Dean Scotson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Thu, 31 Jul 2003 10:31:16 +0100
Organization: Trustis Ltd
Message-ID: <001201c35746$80da8e40$0a00a8c0@deanstecra>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6V9VUqt058269
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

New to the discussion, but if the objective is to retrospectively verify
that a certificate was not revoked during its validity period (and having
since expired it will not be in the latest CRL created), then surely only
the last CRL issued during the validity period would need to be referenced
?. 

i.e. (and this does NOT take into account any CA products current abilities)
if I want to check that a certificate was still 'valid' up-to its 'notAfter'
date I do not need to know the date, I just send the certificate (or S/N) to
the CA as

 https://www.publicCA.com/status?certificate='serialNumber'

By return I would be given the last CRL that this certificate would have
been listed as revoked in, if in fact it was revoked during its validity
period. (Of course, there is still a window between the last CRL and
expiration of a certificate where I could revoke a certificate, but then we
are talking CRL's here and not real-time status. And I am also assuming the
CA is a good boy and retained records of certificates it has issued...).

This discussion appears to revolve around the question "This certificate has
now expired, but was it ever revoked?, and can I assume therefore that it
was valid at the time of the transaction I am now retrospectively
verifying". This seems to imply that:

A) I did not check the status at the time of transaction (bad), or
B) I have designed a system where I need real-time status but I have not
implemented real-time status (also bad).

I do not see the direct connection with PKUP, which is where the discussion
first began?. My point of view is that a certificate is something you have
whereby you can electronically 'sign/authenticate' something. This is a
facility that you (currently) have to pay for. This is Authentication.
Authorisation is up to the RP to decide, based on whatever information they
feel necessary. If the RP decides to accept an expired certificate so-be-it.
PKUP would make no difference.

Dean.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: 30 July 2003 16:37
To: Dean Adams
Cc: [e-mail]
Subject: RE: Why is privateKeyUsagePeriod deprecated?



        Dean:

        I don't see how a full history CRL location would work without a 
parameter for the effective date.  FreshestCRL doesn't need such a 
parameter.  If we assumed that we want an "archivedCRL" accessMethod in 
AIA, how would the accessLocation represent the effective date parameter? 
I assume that it's appropriate for such an accessMethod to use HTTP or 
HTTPS.
        An example of the URL for the actual query (for about now) would 
be:
        https://www.publicCA.com/archivedCRL?date=200307301530Z
        An RP actually using this feature would be able to construct the 
query by substituting the effective time into the URL.  I also would ask 
if we need variants of this for "last CRL not later than" and "first CRL 
not before".

                Tom Gindin





"Dean Adams" <[e-mail]>
Sent by: [e-mail]
07/29/2003 04:37 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Why is privateKeyUsagePeriod deprecated?




Russ,
                 Surely, merely finding some way to ensure that a CA 
archives CRLs is not
enough.  Some way has to be provided to allow client applications to
discover where the appropriate CRL to be checked, can be found.

Some possible options for consideration:
1) the first CRL that was published after the
   expiry date of the client cert being checked
2) the location of a fully maintained complete CRL
   containing all history with regard to revoked certs
   that were issued from a particular CA certificate

I'm sure there are other options too, but in any case some means of
communicating this info to the client application needs to be defined.
Perhaps some certificate extension similar to "Freshest CRL" that instead
denotes "FullHistory CRL" would be appropriate?  That (or something in
Authority Info Access) might provide a solution for (2).  Not sure how you
might go about providing a solution for a (1) type of approach, without
getting overly complicated.

Dean Adams

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Russ Housley
Sent: 29 July 2003 16:56
To: [e-mail]
Cc: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?



Peter:

On one hand I agree, but on another I do not.

I agree that signatures need to be validated after the certificate 
expires.

The algorithm in RFC 3280 allows the certificate to be validate with respect
to a date other than today.  The date that ought to be input requires a
trusted time that the signature was applied.  Of course, PKIX has developed
a protocol to provide such a time stamp.

An archive of the revocation information is not routinely offered by CAs.
How do we make that happen?

Russ

At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:

>Stephen Kent <[e-mail]> writes:
>
> >I was not an author for 2459 or 3280, but my feeling is that we do 
> >not recommend use of PKUP for several reasons:
>
>But those are mostly just hypothetical objections.  At the moment we 
>have
two
>inescapabable facts:
>
>1. CAs issue certs based on a 1-year billing cycle, and nothing anyone
says
>    will change that.  No CA will issue a cert with a 20-year lifetime,
unless
>    it's for its own CA certs.
>
>2. Users need to use certs to validate signatures at n times the
CA-ordained
>    lifetime.  In the abscence of any mechanism to do this, they are
ignoring
>    the cert expiry time.  In other words, out of necessity, they're 
> making the
>    following change to RFC 3280:
>
>     The validity period for a certificate is the period of time from 
> notBefore
>     through notAfter, inclusive.  When used with signing certificates,
>     implementations SHOULD NOT pay any attention to the notAfter date.
>
>Given that this isn't going to change, it would seem that some guidance
for
>users would be useful here.  Since neither (1) nor (2) can be altered,
what
>would be needed is a simple extension, found in signing certs, 
>containing
a
>date to which the cert can still be used for signature-checking beyond
the
>obvious notAfter value.  This could be written up as a short one-page 
>application note, no more (well, a bit more once you add all the usual 
>boilerplate and whatnot).
>
>Now CAs can still decide not to issue certs like that, but (a) they 
>can't justify it by claiming it screws up their standard cert cycle 
>because it doesn't affect validTo/validFrom, and (b) users at least 
>have some
guidance
as
>to what to do, which is better than the current situation where all 
>they
can
>do is ignore parts of the standard on an ad hoc basis.
>
>Peter.








Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V7UFqt039904 for <[e-mail]>; Thu, 31 Jul 2003 00:30:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6V7UFBM039902 for ietf-pkix-bks; Thu, 31 Jul 2003 00:30:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V7UDqt039884 for <[e-mail]>; Thu, 31 Jul 2003 00:30:14 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA13038; Thu, 31 Jul 2003 09:35:03 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA26609; Thu, 31 Jul 2003 09:30:35 +0200
Message-ID: <[e-mail]>
Date: Thu, 31 Jul 2003 09:30:09 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05210605bb4d7c0019ee@[128.89.89.75]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

(...)

>> CAs do NOT archive CRLs today. They do not need to archive CRLs tomorrow.
>> Relying parties (or verifiers) need to capture the CRLs when available 
>> (as well as the OCSP responses when doing the first validation). 
>> Archiving this information is then their concern.

>> Denis

> I think a better characterization here is that CAs are not required to 
> archive CRLs based on X.509 or PKIX standards. Various national or (in 
> the U.S.) state laws relating to digital signatures may impose this 
> requirement, or an organization operating a CA may choose to archive 
> CRLs.  The statement you made is just a bit too strong to be correct :-)

We are both incorrect. :-)

CAs usually archive CRLs in order to prove that they behaved correctly in 
case of an audit or in case of a dispute with relying parties. They may use 
the archives to demonstrate that they behaved correctly.

They are not required to provide an on-line service to these archives, which 
are very seldomly used. For that reason, we are not going to define a 
protocol to access that archived information.

Denis

> Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V4CPqt020975 for <[e-mail]>; Wed, 30 Jul 2003 21:12:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6V4CPqW020974 for ietf-pkix-bks; Wed, 30 Jul 2003 21:12:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V4COqt020969 for <[e-mail]>; Wed, 30 Jul 2003 21:12:24 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 30 Jul 2003 21:12:22 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: Clarification on XMPP log for certificate types
Date: Wed, 30 Jul 2003 21:12:22 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There are some comments that I've read out of the XMPP log for the WG
meeting that I'm trying to understand:


Thu Jul 17 09:21:52 2003 >ggm< Interop testing on 3279/3280
Thu Jul 17 09:22:14 2003 >ggm< scope is checking two impls can do cert
gen features, and CRLS
Thu Jul 17 09:22:21 2003 >ggm< and check path validation alg. features
Thu Jul 17 09:23:03 2003 >ggm< ADs happy with this approach.
Thu Jul 17 09:24:56 2003 >ggm< general testing: for certs/CRLS is 90%
complete. 
Thu Jul 17 09:25:18 2003 >ggm< Open issues: DSA param inheritence,
Diffie-Hellman, EC, and Delta CRLs. not changed much from last mtg


Is the point to find two implementations that can *generate* DSA
certificates with inherited parameters, Diffie-Hellman certificates,
Elliptic Curve certificates and Delta CRLs?  I know that the S/MIME
examples draft has DSA certificates with inherited parameters, and
Diffie Hellman certificates, but I don't know where those were generated
(if I had to guess, I would say the S/MIME Freeware Library).

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V1Beqt012047 for <[e-mail]>; Wed, 30 Jul 2003 18:11:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6V1Bees012046 for ietf-pkix-bks; Wed, 30 Jul 2003 18:11:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V1Bdqt012041 for <[e-mail]>; Wed, 30 Jul 2003 18:11:39 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 7FD756FAB5; Wed, 30 Jul 2003 18:11:41 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Comments on draft-ietf-pkix-sonof3039-01.txt
Date: Wed, 30 Jul 2003 18:12:06 -0700
Message-ID: <003f01c35700$c24da1f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

1.  Appendix A:  3280, unlike 2459 only has the 1988 ASN.1 syntax.  You
need to consider removing the 1993 syntax from you document.

2.  Appendix A.1: You need to issue and updated module of some type
refering to the ASN.1 module from RFC 3280.

ASN.1 Issues:

3.  Attribute is imported but never referenced.
4.  id-at-serialNumber is defined in RFC 3280 ASN.1 module
5.  id-at-pseudonym is defined in RFC 3280 ASN.1 module

The last two are noted only because you make the statement that you
define only those things not in RFC 3280.

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V0jGqt011466 for <[e-mail]>; Wed, 30 Jul 2003 17:45:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6V0jG92011465 for ietf-pkix-bks; Wed, 30 Jul 2003 17:45:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V0jFqt011460 for <[e-mail]>; Wed, 30 Jul 2003 17:45:15 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 73D596AB32; Wed, 30 Jul 2003 17:22:15 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>, "'Russ Housley'" <[e-mail]>, "'Steve Bellovin'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-07.txt
Date: Wed, 30 Jul 2003 17:45:41 -0700
Message-ID: <003e01c356fd$11ac6050$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I have just gone through this document and I have some comments that I
believe MUST be resolved before the IESG can accept this document.
These comments deal with the ASN.1 modules at the end of the document.

1.  The module identifer OID used in the 1988 syntax has already been
assigned to the OCSP module.
2.  You are missing a semi-colon at the end of the imports section
3.  You are importing from RFC 2459 not from RFC 3280
3.  AttributeType is imported but not referenced.
4.  UTF8String is not defined anywhere.
5.  There should be text specifing that the 1988 module is normative and
the 1993 module is informative.
6.  Similar errors exist in the 1993 module, but I don't have a compiler
for it so I don't have a complete list.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Wednesday, July 30, 2003 12:48 AM
> To: [e-mail]; Russ Housley; Steve Bellovin
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-07.txt
> 
> 
> 
> The IESG has been discussing the draft-ietf-pkix-pi document, 
> and mentioned 
> that some information was needed to bring the discussion to closure.
> 
> The document allows the naming authority to be identified in several 
> different ways. The following chunk of ASN.1 from the 
> document illustrates 
> the point:
> 
>       PermanentIdentifier ::=     SEQUENCE {
>          identifierValue              IdentifierValue,
>          identifierType               IdentifierType OPTIONAL,
>          matchingRule        [0]      IMPLICIT OBJECT 
> IDENTIFIER OPTIONAL
>       }
> 
>       IdentifierValue ::= CHOICE {
>              iA5String            IA5String,
>              uTF8String           UTF8String
>       }
> 
>       IdentifierType ::= CHOICE {
>              registeredOID                   OBJECT IDENTIFIER,
>              uri                             IA5String
>       }
> 
> The pros and cons of OIDs and URIs have been discussed in the 
> IESG. In practice, they are not used in the same manner.
> 
> Some people are uncomfortable with OIDs. For one thing, there is no 
> straightforward way of getting to know anything more about 
> them than the 
> values of their numbers, which give no hint of the context in 
> which they 
> were assigned.
> 
> Some people are uncomfortable with URIs. Their content is 
> subject to various 
> interpretations, and people sometimes make unreasonable 
> guesses based on the 
> strings embedded in the URI.
> 
> Russ, our security area Director, indicated to the PKIX 
> mailing list that an update to the Internet-Draft was needed 
> to resolve the DISCUSS votes.
> 
> After discussions between the co-editors and some other 
> people, we came to 
> the conclusion that no change was needed to the core 
> document, but that an 
> informative annex was necessary to deal with the topic of 
> permanent URIs.
> 
> The document draft-ietf-pkix-pi-07.txt is an update where an 
> annex C has 
> been added in order to address the concern.
> 
> Denis
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UNTTqt007251 for <[e-mail]>; Wed, 30 Jul 2003 16:29:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UNTTRJ007250 for ietf-pkix-bks; Wed, 30 Jul 2003 16:29:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UNTSqt007243 for <[e-mail]>; Wed, 30 Jul 2003 16:29:28 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 259DF6D79A; Wed, 30 Jul 2003 16:29:30 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>
Cc: "'pkix'" <[e-mail]>
Subject: SCVP Comment
Date: Wed, 30 Jul 2003 16:29:54 -0700
Message-ID: <003d01c356f2$7bbb4250$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

After going through the large discussions about the correct use of
smime-type in the S/MIME working group, I am wondering why you are
defining new mime times rather than use the ones from the S/MIME working
group?

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UFbWqt076996 for <[e-mail]>; Wed, 30 Jul 2003 08:37:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UFbVNx076995 for ietf-pkix-bks; Wed, 30 Jul 2003 08:37:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UFbTqt076988 for <[e-mail]>; Wed, 30 Jul 2003 08:37:30 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6UFbNpW175516; Wed, 30 Jul 2003 11:37:23 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6UFbKJs139474; Wed, 30 Jul 2003 11:37:22 -0400
To: "Dean Adams" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: RE: Why is privateKeyUsagePeriod deprecated?
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2003 11:37:04 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPRs JHEG5JQ5CD, THTO5KLVS6, JHEG5HMLFK, JCHN5K5PG9|March 27, 2003) at 07/30/2003 11:37:22, Serialize complete at 07/30/2003 11:37:22
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Dean:

        I don't see how a full history CRL location would work without a 
parameter for the effective date.  FreshestCRL doesn't need such a 
parameter.  If we assumed that we want an "archivedCRL" accessMethod in 
AIA, how would the accessLocation represent the effective date parameter? 
I assume that it's appropriate for such an accessMethod to use HTTP or 
HTTPS.
        An example of the URL for the actual query (for about now) would 
be:
        https://www.publicCA.com/archivedCRL?date=200307301530Z
        An RP actually using this feature would be able to construct the 
query by substituting the effective time into the URL.  I also would ask 
if we need variants of this for "last CRL not later than" and "first CRL 
not before".

                Tom Gindin





"Dean Adams" <[e-mail]>
Sent by: [e-mail]
07/29/2003 04:37 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Why is privateKeyUsagePeriod deprecated?




Russ,
                 Surely, merely finding some way to ensure that a CA 
archives CRLs is not
enough.  Some way has to be provided to allow client applications to
discover where the appropriate CRL to be checked, can be found.

Some possible options for consideration:
1) the first CRL that was published after the
   expiry date of the client cert being checked
2) the location of a fully maintained complete CRL
   containing all history with regard to revoked certs
   that were issued from a particular CA certificate

I'm sure there are other options too, but in any case some means of
communicating this info to the client application needs to be defined.
Perhaps some certificate extension similar to "Freshest CRL" that instead
denotes "FullHistory CRL" would be appropriate?  That (or something in
Authority Info Access) might provide a solution for (2).  Not sure how you
might go about providing a solution for a (1) type of approach, without
getting overly complicated.

Dean Adams

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Russ Housley
Sent: 29 July 2003 16:56
To: [e-mail]
Cc: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?



Peter:

On one hand I agree, but on another I do not.

I agree that signatures need to be validated after the certificate 
expires.

The algorithm in RFC 3280 allows the certificate to be validate with
respect to a date other than today.  The date that ought to be input
requires a trusted time that the signature was applied.  Of course, PKIX
has developed a protocol to provide such a time stamp.

An archive of the revocation information is not routinely offered by
CAs.  How do we make that happen?

Russ

At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:

>Stephen Kent <[e-mail]> writes:
>
> >I was not an author for 2459 or 3280, but my feeling is that we do not
> >recommend use of PKUP for several reasons:
>
>But those are mostly just hypothetical objections.  At the moment we have
two
>inescapabable facts:
>
>1. CAs issue certs based on a 1-year billing cycle, and nothing anyone 
says
>    will change that.  No CA will issue a cert with a 20-year lifetime,
unless
>    it's for its own CA certs.
>
>2. Users need to use certs to validate signatures at n times the
CA-ordained
>    lifetime.  In the abscence of any mechanism to do this, they are
ignoring
>    the cert expiry time.  In other words, out of necessity, they're
> making the
>    following change to RFC 3280:
>
>     The validity period for a certificate is the period of time from
> notBefore
>     through notAfter, inclusive.  When used with signing certificates,
>     implementations SHOULD NOT pay any attention to the notAfter date.
>
>Given that this isn't going to change, it would seem that some guidance 
for
>users would be useful here.  Since neither (1) nor (2) can be altered, 
what
>would be needed is a simple extension, found in signing certs, containing 
a
>date to which the cert can still be used for signature-checking beyond 
the
>obvious notAfter value.  This could be written up as a short one-page
>application note, no more (well, a bit more once you add all the usual
>boilerplate and whatnot).
>
>Now CAs can still decide not to issue certs like that, but (a) they can't
>justify it by claiming it screws up their standard cert cycle because it
>doesn't affect validTo/validFrom, and (b) users at least have some 
guidance
as
>to what to do, which is better than the current situation where all they
can
>do is ignore parts of the standard on an ad hoc basis.
>
>Peter.







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UE4Iqt068998 for <[e-mail]>; Wed, 30 Jul 2003 07:04:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UE4IoV068997 for ietf-pkix-bks; Wed, 30 Jul 2003 07:04:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UE4Hqt068979 for <[e-mail]>; Wed, 30 Jul 2003 07:04:17 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6UE3fD9028387; Wed, 30 Jul 2003 10:03:41 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210606bb4d7d4866e2@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References:  <[e-mail].k r> <p0521060abb471c9075b7@[128.89.89.75]> <[e-mail]>
Date: Wed, 30 Jul 2003 10:01:36 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:07 +0200 7/30/03, Denis Pinkas wrote:
>Steve,
>
>(...)
>
>>  The PKUP does operate as you note, but the cert validity period is still
>>  present, and in the presence of the PKUP extension, this field is
>>  reinterpreted to state that after the notAfter date, the cert may no
>>  longer be used to verify any signature, period.
>
>Hum ! The period is coming too early. :-)
>
>The interpretation of validity period is independant of the presence 
>or absence of the PKUP extension.
>
>After the notAfter date, the cert may no longer be used to perform a 
>new signature verification, unless such a verification has already 
>been done before and the time of that verification can be 
>demonstrated to be before the notAfter date (e.g. using 
>time-stamping) and the certification path associated to all the 
>revocation information close to that verification date has also be 
>captured (and protected against key compromission).
>
>>  That too is part of the reason for not encouraging use of PKUP,
>>  i.e., the need to reinterpret the cert validity field.
>
>This is an unrelated reason.
>
>Denis

Denis,

When one reads through the set of conditions you describe for 
interpreting the validity of the validity period, I think I am still 
comfortable with my informal characterization of the issue. In the 
absence of PKUP, anyone trying to validate a cert after the cert has 
expired has to know, by context, that the purpose of the validation 
is NR, not authentication or authorization for realtime access. This 
has to be factored into the process, else the validation will always 
fail after the cert validity period has expired.

With PKUP, I believe the intent is that the validity period really 
becomes a hard stop, i.e., a post facto validation will now fail if 
the validity period has passed, irrespective of the use of a time 
stamp. Looking at the text in X.509 and in 3280, none of this is said 
explicitly, so I admit that I am interpreting what folks who support 
use of PKUP have said, but the same is true of your description above.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UDnFqt066833 for <[e-mail]>; Wed, 30 Jul 2003 06:49:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UDnFuI066832 for ietf-pkix-bks; Wed, 30 Jul 2003 06:49:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UDnDqt066822 for <[e-mail]>; Wed, 30 Jul 2003 06:49:14 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6UDmbD9027296; Wed, 30 Jul 2003 09:48:37 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210605bb4d7c0019ee@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 30 Jul 2003 09:45:10 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: Russ Housley <[e-mail]>, Dean Adams <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:02 +0200 7/30/03, Denis Pinkas wrote:
>Russ and Dean,
>
>>Dean:
>>
>>There are many options.  A standard method for CAs to make this 
>>information available is very desirable.
>
>No new extension is necessary, nor desirable.
>
>>Russ
>>
>>At 09:37 PM 7/29/2003 +0100, Dean Adams wrote:
>>
>>>Russ,
>>>Surely, merely finding some way to ensure that a CA archives CRLs 
>>>is not enough.  Some way has to be provided to allow client
>  >> applications to discover where the appropriate CRL to be checked,
>>>  can be found.
>
>CAs do NOT archive CRLs today. They do not need to archive CRLs tomorrow.
>Relying parties (or verifiers) need to capture the CRLs when 
>available (as well as the OCSP responses when doing the first 
>validation). Archiving this information is then their concern.
>
>Denis

I think a better characterization here is that CAs are not required 
to archive CRLs based on X.509 or PKIX standards. Various national or 
(in the U.S.) state laws relating to digital signatures may impose 
this requirement, or an organization operating a CA may choose to 
archive CRLs.  The statement you made is just a bit too strong to be 
correct :-)

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UBLqqt054386 for <[e-mail]>; Wed, 30 Jul 2003 04:21:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UBLqtr054385 for ietf-pkix-bks; Wed, 30 Jul 2003 04:21:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UBLnqt054376 for <[e-mail]>; Wed, 30 Jul 2003 04:21:50 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6UBLAak018845; Wed, 30 Jul 2003 23:21:10 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6UBL8S18109; Wed, 30 Jul 2003 23:21:08 +1200
Date: Wed, 30 Jul 2003 23:21:08 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>CAs do NOT archive CRLs today. They do not need to archive CRLs tomorrow.
>Relying parties (or verifiers) need to capture the CRLs when available (as
>well as the OCSP responses when doing the first validation). Archiving this
>information is then their concern.

Hmm, are you saying that every RP will be required to repeatedly contact the
CA to obtain an arbitrarily large number of arbitrarily large CRLs and store
them for an arbitrarily long amount of time on the off chance that they need
one of them in the future?  Sounds like another one of these PKI-meets-reality
disconnections...

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U9JVqt041546 for <[e-mail]>; Wed, 30 Jul 2003 02:19:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6U9JUpk041545 for ietf-pkix-bks; Wed, 30 Jul 2003 02:19:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U9JTqt041506 for <[e-mail]>; Wed, 30 Jul 2003 02:19:29 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA12884 for <[e-mail]>; Wed, 30 Jul 2003 11:19:24 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 30 Jul 2003 11:19:24 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h6U9JMt13979 for [e-mail]; Wed, 30 Jul 2003 11:19:22 +0200 (MEST)
Date: Wed, 30 Jul 2003 11:19:22 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: Why is privateKeyUsagePeriod deprecated?
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Dean:
> 
> There are many options.  A standard method for CAs to make this information 
> available is very desirable.
> 
> Russ
> 
"Since we now have streets, everybody should use a car." 

"Since we now have a door under video surveillance, you
 need to keep the tapes forever and keep them available
 fot 100 years."

Last year at the ISSE someone said: "Digital signature protect you
in space but not in time." 

IMO the fact that you one has a time parameter as an input for a
certificate validation should not be misunderstood as a 
requirement that all values should be allowed or the
information corresponding to that date need to be available,
e.g. a CRL corresponding to that period. 

Isn't creating a digital signature which is not 
almost immediately presented to some relying or attesting party 
a profound misunderstanding of cryptographic techniques? 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U97Sqt039878 for <[e-mail]>; Wed, 30 Jul 2003 02:07:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6U97SMq039877 for ietf-pkix-bks; Wed, 30 Jul 2003 02:07:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U97Rqt039872 for <[e-mail]>; Wed, 30 Jul 2003 02:07:27 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA24094; Wed, 30 Jul 2003 11:12:19 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA17493; Wed, 30 Jul 2003 11:07:51 +0200
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2003 11:07:25 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
References: <008a01c354ea$1ee43aa0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Libor,

(...)

Yes. PKUP could be a useful extension for self-signed certificates, *if* the 
Subject Information Access extension defined in section 4.2.2.2 from RFC 
3280 is also used. In that case, the id-ad-caRepository OID SHALL be used to 
indicate in which repository the CA publishes its certificates.

Denis

> From my point of view, PKUP could be an useful extention of CA certs. 
> CA must issue its new cert long time before expiration of its own 
> certificate (this period is min of max of the time validity of issued EE
> certs).

> It means: After issuing new CA cert (new-new) the old CA cert (old-old) 
> is still valid but an appropriate old private key of the CA is not used 
> henceforth. This private key should be authoritative erased when 
> the new certificate CA is issued. Lifetime of private key is shorter
> than the validity period of the certificate. This lifetime of private 
 > key could be indicated in PKUP.

> Today, the lifetime of private key is indicated in the certificate 
> policy (CP). Unfortunately it is not possible to start procedure 
> for downloading new CA certs (old-new, new-new and new-old)
> automatically because the certificate policy (CP) is a nonstructured
 > text. In practice, the lifetime of CA private key is not even
 > published in CP yet. It is published in CPS (RFC-2527) which is not
 > in case of the majority of CAs public. Therefore it might by useful
 > to indicate this information in the PKUP.

> Libor Dostalek




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U883qt030281 for <[e-mail]>; Wed, 30 Jul 2003 01:08:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6U883NC030280 for ietf-pkix-bks; Wed, 30 Jul 2003 01:08:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U882qt030269 for <[e-mail]>; Wed, 30 Jul 2003 01:08:02 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA28440; Wed, 30 Jul 2003 10:12:53 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA17176; Wed, 30 Jul 2003 10:08:22 +0200
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2003 10:07:55 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
References: <[e-mail].k r> <p0521060abb471c9075b7@[128.89.89.75]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

(...)

 > The PKUP does operate as you note, but the cert validity period is still
 > present, and in the presence of the PKUP extension, this field is
 > reinterpreted to state that after the notAfter date, the cert may no
 > longer be used to verify any signature, period.

Hum ! The period is coming too early. :-)

The interpretation of validity period is independant of the presence or 
absence of the PKUP extension.

After the notAfter date, the cert may no longer be used to perform a new 
signature verification, unless such a verification has already been done 
before and the time of that verification can be demonstrated to be before 
the notAfter date (e.g. using time-stamping) and the certification path 
associated to all the revocation information close to that verification date 
has also be captured (and protected against key compromission).

 > That too is part of the reason for not encouraging use of PKUP,
 > i.e., the need to reinterpret the cert validity field.

This is an unrelated reason.

Denis

 > Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U87bqt030201 for <[e-mail]>; Wed, 30 Jul 2003 01:07:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6U87bB2030199 for ietf-pkix-bks; Wed, 30 Jul 2003 01:07:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U87aqt030182 for <[e-mail]>; Wed, 30 Jul 2003 01:07:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 19hlzf-0007EK-00; Wed, 30 Jul 2003 10:07:31 +0200
From: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2003 08:07:32 GMT
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: es
Subject: RE: RE: Why is privateKeyUsagePeriod deprecated?
X-Accept-Language: es
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dean,

Just one thought of mine

>
>Some possible options for consideration:
>1) the first CRL that was published after the
>  expiry date of the client cert being checked

But when a cert is revoked, it is held in the CRL 
until the cert reaches the expiry date.
Maybe it'd be better by the before CRL to the first




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U82Tqt029402 for <[e-mail]>; Wed, 30 Jul 2003 01:02:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6U82TcU029401 for ietf-pkix-bks; Wed, 30 Jul 2003 01:02:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U82Rqt029396 for <[e-mail]>; Wed, 30 Jul 2003 01:02:27 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA26306; Wed, 30 Jul 2003 10:07:18 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA17145; Wed, 30 Jul 2003 10:02:51 +0200
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2003 10:02:24 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>, Dean Adams <[e-mail]>
CC: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ and Dean,

> Dean:
> 
> There are many options.  A standard method for CAs to make this 
> information available is very desirable.

No new extension is necessary, nor desirable.

> Russ
> 
> At 09:37 PM 7/29/2003 +0100, Dean Adams wrote:
> 
>> Russ,
>> Surely, merely finding some way to ensure that a CA archives 
>> CRLs is not enough.  Some way has to be provided to allow client
 >> applications to discover where the appropriate CRL to be checked,
 >> can be found.

CAs do NOT archive CRLs today. They do not need to archive CRLs tomorrow.
Relying parties (or verifiers) need to capture the CRLs when available (as 
well as the OCSP responses when doing the first validation). Archiving this 
information is then their concern.

Denis

>> Some possible options for consideration:
>> 1) the first CRL that was published after the
>>    expiry date of the client cert being checked
>> 2) the location of a fully maintained complete CRL
>>    containing all history with regard to revoked certs
>>    that were issued from a particular CA certificate
>>
>> I'm sure there are other options too, but in any case some means of
>> communicating this info to the client application needs to be defined.
>> Perhaps some certificate extension similar to "Freshest CRL" that instead
>> denotes "FullHistory CRL" would be appropriate?  That (or something in
>> Authority Info Access) might provide a solution for (2).  Not sure how 
>> you might go about providing a solution for a (1) type of approach, 
 >> without getting overly complicated.
>>
>> Dean Adams
>>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]On Behalf Of Russ Housley
>> Sent: 29 July 2003 16:56
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: Why is privateKeyUsagePeriod deprecated?
>>
>>
>>
>> Peter:
>>
>> On one hand I agree, but on another I do not.
>>
>> I agree that signatures need to be validated after the certificate 
>> expires.
>>
>> The algorithm in RFC 3280 allows the certificate to be validate with
>> respect to a date other than today.  The date that ought to be input
>> requires a trusted time that the signature was applied.  Of course, PKIX
>> has developed a protocol to provide such a time stamp.
>>
>> An archive of the revocation information is not routinely offered by
>> CAs.  How do we make that happen?
>>
>> Russ
>>
>> At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:
>>
>> >Stephen Kent <[e-mail]> writes:
>> >
>> > >I was not an author for 2459 or 3280, but my feeling is that we do not
>> > >recommend use of PKUP for several reasons:
>> >
>> >But those are mostly just hypothetical objections.  At the moment we 
>> have
>> two
>> >inescapabable facts:
>> >
>> >1. CAs issue certs based on a 1-year billing cycle, and nothing 
>> anyone says
>> >    will change that.  No CA will issue a cert with a 20-year lifetime,
>> unless
>> >    it's for its own CA certs.
>> >
>> >2. Users need to use certs to validate signatures at n times the
>> CA-ordained
>> >    lifetime.  In the abscence of any mechanism to do this, they are
>> ignoring
>> >    the cert expiry time.  In other words, out of necessity, they're
>> > making the
>> >    following change to RFC 3280:
>> >
>> >     The validity period for a certificate is the period of time from
>> > notBefore
>> >     through notAfter, inclusive.  When used with signing certificates,
>> >     implementations SHOULD NOT pay any attention to the notAfter date.
>> >
>> >Given that this isn't going to change, it would seem that some 
>> guidance for
>> >users would be useful here.  Since neither (1) nor (2) can be 
>> altered, what
>> >would be needed is a simple extension, found in signing certs, 
>> containing a
>> >date to which the cert can still be used for signature-checking 
>> beyond the
>> >obvious notAfter value.  This could be written up as a short one-page
>> >application note, no more (well, a bit more once you add all the usual
>> >boilerplate and whatnot).
>> >
>> >Now CAs can still decide not to issue certs like that, but (a) they 
>> can't
>> >justify it by claiming it screws up their standard cert cycle because it
>> >doesn't affect validTo/validFrom, and (b) users at least have some 
>> guidance
>> as
>> >to what to do, which is better than the current situation where all they
>> can
>> >do is ignore parts of the standard on an ad hoc basis.
>> >
>> >Peter.
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U7mCqt027807 for <[e-mail]>; Wed, 30 Jul 2003 00:48:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6U7mCFe027806 for ietf-pkix-bks; Wed, 30 Jul 2003 00:48:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U7m7qt027789 for <[e-mail]>; Wed, 30 Jul 2003 00:48:09 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA22080; Wed, 30 Jul 2003 09:52:42 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA17041; Wed, 30 Jul 2003 09:48:13 +0200
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2003 09:47:47 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail], Russ Housley <[e-mail]>, Steve Bellovin <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-07.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has been discussing the draft-ietf-pkix-pi document, and mentioned 
that some information was needed to bring the discussion to closure.

The document allows the naming authority to be identified in several 
different ways. The following chunk of ASN.1 from the document illustrates 
the point:

      PermanentIdentifier ::=     SEQUENCE {
         identifierValue              IdentifierValue,
         identifierType               IdentifierType OPTIONAL,
         matchingRule        [0]      IMPLICIT OBJECT IDENTIFIER OPTIONAL
      }

      IdentifierValue ::= CHOICE {
             iA5String            IA5String,
             uTF8String           UTF8String
      }

      IdentifierType ::= CHOICE {
             registeredOID                   OBJECT IDENTIFIER,
             uri                             IA5String
      }

The pros and cons of OIDs and URIs have been discussed in the IESG.
In practice, they are not used in the same manner.

Some people are uncomfortable with OIDs. For one thing, there is no 
straightforward way of getting to know anything more about them than the 
values of their numbers, which give no hint of the context in which they 
were assigned.

Some people are uncomfortable with URIs. Their content is subject to various 
interpretations, and people sometimes make unreasonable guesses based on the 
strings embedded in the URI.

Russ, our security area Director, indicated to the PKIX mailing list that
an update to the Internet-Draft was needed to resolve the DISCUSS votes.

After discussions between the co-editors and some other people, we came to 
the conclusion that no change was needed to the core document, but that an 
informative annex was necessary to deal with the topic of permanent URIs.

The document draft-ietf-pkix-pi-07.txt is an update where an annex C has 
been added in order to address the concern.

Denis





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TNuuqt096225 for <[e-mail]>; Tue, 29 Jul 2003 16:56:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TNutNt096224 for ietf-pkix-bks; Tue, 29 Jul 2003 16:56:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6TNusqt096219 for <[e-mail]>; Tue, 29 Jul 2003 16:56:54 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 5068 invoked by uid 0); 29 Jul 2003 23:55:39 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.93.183) by woodstock.binhost.com with SMTP; 29 Jul 2003 23:55:39 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 29 Jul 2003 19:56:50 -0400
To: "Dean Adams" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dean:

There are many options.  A standard method for CAs to make this information 
available is very desirable.

Russ

At 09:37 PM 7/29/2003 +0100, Dean Adams wrote:

>Russ,
>         Surely, merely finding some way to ensure that a CA archives CRLs 
> is not
>enough.  Some way has to be provided to allow client applications to
>discover where the appropriate CRL to be checked, can be found.
>
>Some possible options for consideration:
>1) the first CRL that was published after the
>    expiry date of the client cert being checked
>2) the location of a fully maintained complete CRL
>    containing all history with regard to revoked certs
>    that were issued from a particular CA certificate
>
>I'm sure there are other options too, but in any case some means of
>communicating this info to the client application needs to be defined.
>Perhaps some certificate extension similar to "Freshest CRL" that instead
>denotes "FullHistory CRL" would be appropriate?  That (or something in
>Authority Info Access) might provide a solution for (2).  Not sure how you
>might go about providing a solution for a (1) type of approach, without
>getting overly complicated.
>
>Dean Adams
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Russ Housley
>Sent: 29 July 2003 16:56
>To: [e-mail]
>Cc: [e-mail]
>Subject: Re: Why is privateKeyUsagePeriod deprecated?
>
>
>
>Peter:
>
>On one hand I agree, but on another I do not.
>
>I agree that signatures need to be validated after the certificate expires.
>
>The algorithm in RFC 3280 allows the certificate to be validate with
>respect to a date other than today.  The date that ought to be input
>requires a trusted time that the signature was applied.  Of course, PKIX
>has developed a protocol to provide such a time stamp.
>
>An archive of the revocation information is not routinely offered by
>CAs.  How do we make that happen?
>
>Russ
>
>At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:
>
> >Stephen Kent <[e-mail]> writes:
> >
> > >I was not an author for 2459 or 3280, but my feeling is that we do not
> > >recommend use of PKUP for several reasons:
> >
> >But those are mostly just hypothetical objections.  At the moment we have
>two
> >inescapabable facts:
> >
> >1. CAs issue certs based on a 1-year billing cycle, and nothing anyone says
> >    will change that.  No CA will issue a cert with a 20-year lifetime,
>unless
> >    it's for its own CA certs.
> >
> >2. Users need to use certs to validate signatures at n times the
>CA-ordained
> >    lifetime.  In the abscence of any mechanism to do this, they are
>ignoring
> >    the cert expiry time.  In other words, out of necessity, they're
> > making the
> >    following change to RFC 3280:
> >
> >     The validity period for a certificate is the period of time from
> > notBefore
> >     through notAfter, inclusive.  When used with signing certificates,
> >     implementations SHOULD NOT pay any attention to the notAfter date.
> >
> >Given that this isn't going to change, it would seem that some guidance for
> >users would be useful here.  Since neither (1) nor (2) can be altered, what
> >would be needed is a simple extension, found in signing certs, containing a
> >date to which the cert can still be used for signature-checking beyond the
> >obvious notAfter value.  This could be written up as a short one-page
> >application note, no more (well, a bit more once you add all the usual
> >boilerplate and whatnot).
> >
> >Now CAs can still decide not to issue certs like that, but (a) they can't
> >justify it by claiming it screws up their standard cert cycle because it
> >doesn't affect validTo/validFrom, and (b) users at least have some guidance
>as
> >to what to do, which is better than the current situation where all they
>can
> >do is ignore parts of the standard on an ad hoc basis.
> >
> >Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TKb5qt084905 for <[e-mail]>; Tue, 29 Jul 2003 13:37:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TKb5PZ084904 for ietf-pkix-bks; Tue, 29 Jul 2003 13:37:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TKb4qt084896 for <[e-mail]>; Tue, 29 Jul 2003 13:37:04 -0700 (PDT) (envelope-from [e-mail])
Received: from modem-3971.lemur.dialup.pol.co.uk ([217.135.143.131] helo=PEDIGREE) by cmailg3.svr.pol.co.uk with smtp (Exim 4.14) id 19hbDS-0000sr-PC for [e-mail]; Tue, 29 Jul 2003 21:37:03 +0100
From: "Dean Adams" <[e-mail]>
To: <[e-mail]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Tue, 29 Jul 2003 21:37:02 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,
	Surely, merely finding some way to ensure that a CA archives CRLs is not
enough.  Some way has to be provided to allow client applications to
discover where the appropriate CRL to be checked, can be found.

Some possible options for consideration:
1) the first CRL that was published after the
   expiry date of the client cert being checked
2) the location of a fully maintained complete CRL
   containing all history with regard to revoked certs
   that were issued from a particular CA certificate

I'm sure there are other options too, but in any case some means of
communicating this info to the client application needs to be defined.
Perhaps some certificate extension similar to "Freshest CRL" that instead
denotes "FullHistory CRL" would be appropriate?  That (or something in
Authority Info Access) might provide a solution for (2).  Not sure how you
might go about providing a solution for a (1) type of approach, without
getting overly complicated.

Dean Adams

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Russ Housley
Sent: 29 July 2003 16:56
To: [e-mail]
Cc: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?



Peter:

On one hand I agree, but on another I do not.

I agree that signatures need to be validated after the certificate expires.

The algorithm in RFC 3280 allows the certificate to be validate with
respect to a date other than today.  The date that ought to be input
requires a trusted time that the signature was applied.  Of course, PKIX
has developed a protocol to provide such a time stamp.

An archive of the revocation information is not routinely offered by
CAs.  How do we make that happen?

Russ

At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:

>Stephen Kent <[e-mail]> writes:
>
> >I was not an author for 2459 or 3280, but my feeling is that we do not
> >recommend use of PKUP for several reasons:
>
>But those are mostly just hypothetical objections.  At the moment we have
two
>inescapabable facts:
>
>1. CAs issue certs based on a 1-year billing cycle, and nothing anyone says
>    will change that.  No CA will issue a cert with a 20-year lifetime,
unless
>    it's for its own CA certs.
>
>2. Users need to use certs to validate signatures at n times the
CA-ordained
>    lifetime.  In the abscence of any mechanism to do this, they are
ignoring
>    the cert expiry time.  In other words, out of necessity, they're
> making the
>    following change to RFC 3280:
>
>     The validity period for a certificate is the period of time from
> notBefore
>     through notAfter, inclusive.  When used with signing certificates,
>     implementations SHOULD NOT pay any attention to the notAfter date.
>
>Given that this isn't going to change, it would seem that some guidance for
>users would be useful here.  Since neither (1) nor (2) can be altered, what
>would be needed is a simple extension, found in signing certs, containing a
>date to which the cert can still be used for signature-checking beyond the
>obvious notAfter value.  This could be written up as a short one-page
>application note, no more (well, a bit more once you add all the usual
>boilerplate and whatnot).
>
>Now CAs can still decide not to issue certs like that, but (a) they can't
>justify it by claiming it screws up their standard cert cycle because it
>doesn't affect validTo/validFrom, and (b) users at least have some guidance
as
>to what to do, which is better than the current situation where all they
can
>do is ignore parts of the standard on an ad hoc basis.
>
>Peter.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TGkLqt071797 for <[e-mail]>; Tue, 29 Jul 2003 09:46:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TGkLge071796 for ietf-pkix-bks; Tue, 29 Jul 2003 09:46:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6TGkJqt071791 for <[e-mail]>; Tue, 29 Jul 2003 09:46:20 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 15574 invoked by uid 0); 29 Jul 2003 16:45:03 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.168.207) by woodstock.binhost.com with SMTP; 29 Jul 2003 16:45:03 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 29 Jul 2003 12:38:06 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Where would you want to add this?  I want to look at the flow of the section?

Russ

At 09:02 PM 7/25/2003 +1200, Peter Gutmann wrote:

>Tom Gindin <[e-mail]> writes:
>
>   The validity period for a certificate is the period of time from notBefore
>   through notAfter, inclusive.  When an RP is validating the signature on a
>   document which claims to have been signed or produced at a given past time,
>   the RP SHOULD proceed with the verification of the signature if that 
> time is
>   within the validity period even though the time of verification is outside
>   it. If the RP requires authoritative proof either of the time at which the
>   document was signed or of the certificate's not having been revoked, it MAY
>   reject the signature.
>
>That works for me.  Russ, any chance of getting this added to bride-of-3280?
>
>Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TGFIqt070755 for <[e-mail]>; Tue, 29 Jul 2003 09:15:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TGFI1H070754 for ietf-pkix-bks; Tue, 29 Jul 2003 09:15:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TGFGqt070749 for <[e-mail]>; Tue, 29 Jul 2003 09:15:17 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27763; Tue, 29 Jul 2003 12:15:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pi-07.txt
Date: Tue, 29 Jul 2003 12:15:10 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Permanent 
                          Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-07.txt
	Pages		: 15
	Date		: 2003-7-29
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
entity even if the name or the affiliation of that entity stored 
in the subject or another name form in the subjectAltName extension 
has changed.
The subject name, carried in the subject field, is only unique 
for each subject entity certified by the one CA as defined by the 
issuer name field. Also, the new name form can carry a 
name that is unique for each subject entity certified by a CA.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pi-07.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TGDoqt070659 for <[e-mail]>; Tue, 29 Jul 2003 09:13:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TGDosJ070657 for ietf-pkix-bks; Tue, 29 Jul 2003 09:13:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6TGDnqt070646 for <[e-mail]>; Tue, 29 Jul 2003 09:13:49 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 13758 invoked by uid 0); 29 Jul 2003 16:12:32 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.164.124) by woodstock.binhost.com with SMTP; 29 Jul 2003 16:12:32 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 29 Jul 2003 11:56:11 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

On one hand I agree, but on another I do not.

I agree that signatures need to be validated after the certificate expires.

The algorithm in RFC 3280 allows the certificate to be validate with 
respect to a date other than today.  The date that ought to be input 
requires a trusted time that the signature was applied.  Of course, PKIX 
has developed a protocol to provide such a time stamp.

An archive of the revocation information is not routinely offered by 
CAs.  How do we make that happen?

Russ

At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:

>Stephen Kent <[e-mail]> writes:
>
> >I was not an author for 2459 or 3280, but my feeling is that we do not
> >recommend use of PKUP for several reasons:
>
>But those are mostly just hypothetical objections.  At the moment we have two
>inescapabable facts:
>
>1. CAs issue certs based on a 1-year billing cycle, and nothing anyone says
>    will change that.  No CA will issue a cert with a 20-year lifetime, unless
>    it's for its own CA certs.
>
>2. Users need to use certs to validate signatures at n times the CA-ordained
>    lifetime.  In the abscence of any mechanism to do this, they are ignoring
>    the cert expiry time.  In other words, out of necessity, they're 
> making the
>    following change to RFC 3280:
>
>     The validity period for a certificate is the period of time from 
> notBefore
>     through notAfter, inclusive.  When used with signing certificates,
>     implementations SHOULD NOT pay any attention to the notAfter date.
>
>Given that this isn't going to change, it would seem that some guidance for
>users would be useful here.  Since neither (1) nor (2) can be altered, what
>would be needed is a simple extension, found in signing certs, containing a
>date to which the cert can still be used for signature-checking beyond the
>obvious notAfter value.  This could be written up as a short one-page
>application note, no more (well, a bit more once you add all the usual
>boilerplate and whatnot).
>
>Now CAs can still decide not to issue certs like that, but (a) they can't
>justify it by claiming it screws up their standard cert cycle because it
>doesn't affect validTo/validFrom, and (b) users at least have some guidance as
>to what to do, which is better than the current situation where all they can
>do is ignore parts of the standard on an ad hoc basis.
>
>Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TDvQqt060981 for <[e-mail]>; Tue, 29 Jul 2003 06:57:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TDvQBW060979 for ietf-pkix-bks; Tue, 29 Jul 2003 06:57:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TDvIqt060955 for <[e-mail]>; Tue, 29 Jul 2003 06:57:19 -0700 (PDT) (envelope-from [e-mail])
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.3/8.11.6/SuSE Linux 0.5) with ESMTP id h6TDvH609889; Tue, 29 Jul 2003 15:57:17 +0200
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) (authenticated (0 bits)) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h6TDv8I32171 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified OK); Tue, 29 Jul 2003 15:57:16 +0200
Message-ID: <[e-mail]>
Date: Tue, 29 Jul 2003 15:57:08 +0200
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: Antonio Lioy <[e-mail]>, Wen-Cheng Wang <[e-mail]>, =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, PKIX <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <[e-mail]> <[e-mail]> <003201c34cce$e9070070$4f85900a@wcwang> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.54
X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6TDvJqt060961
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just to make it clear and prevent misunderstandings:

Our schema specifies the storage of each certificate in a separate 
directory entry. Those entries can be stored either below a person entry 
or in a certificate only repository


1.) below Person entry:

                         cn=person name
                           (mail=emailadress, etc.)
                         /       |       \
                        /        |        \
                   cn=cert1     cn=cert2   cn=cert3


2.) below CA cert repository:

                         o=CA Name
                           |
                           |
                    cn=certificate repository
                         /       |          \
                        /        |           \
                   cn=cert1     cn=cert2 ...  cn=cert1008


Hope this helps.

Cheers,

Peter


David Chadwick wrote:

> 
> Antonio Lioy wrote:
> 
> 
>>So support for multiple certs per each user should be added to the schema.
> 
> 
> This has always been there. This is not the issue. It is whether the
> newly created per certificate entry should use a multivalued attribute
> or define a new one.
> 
> regards
> 
> David
> 
> 
>>Cheers,
>>
>>Antonio Lioy
> 
> 

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TAbqqt044805 for <[e-mail]>; Tue, 29 Jul 2003 03:37:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TAbq3b044804 for ietf-pkix-bks; Tue, 29 Jul 2003 03:37:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TAboqt044795 for <[e-mail]>; Tue, 29 Jul 2003 03:37:51 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA23542; Tue, 29 Jul 2003 12:42:41 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA08123; Tue, 29 Jul 2003 12:38:10 +0200
Message-ID: <[e-mail]>
Date: Tue, 29 Jul 2003 12:37:46 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice,

Please see my responses below.

Comments on warranty-extn-03.txt (June 2003)

1- On page 2. The text mentions: "A relying party that has a warranty from a
CA".

Does this mean that a relying party must have a contract with the CA to get
advantage of the warranty ?
[Alice] No.

Does this mean that a relying party will get a warranty without a contract
signed with the CA ?
[Alice] Yes.

Does this extension allow to make the difference between the case of a
signed contract and the case of an unsigned contract where the guarantees
could be different?

[Alice] No. If there are any differences in the T&C pertaining to a 
contractual arrangement, these differences will be outside of, beyond the 
scope, and not pertinent to, the warranty offered in the certificate.  It 
applies equally to all relying parties, whether or not a contract has been 
signed.

[Denis] Then say something like: "Whether or not relying parties have signed 
agreements with CAs, the CA will provide Terms and Conditions for this 
warranty which relates to its liability."

2 - The difference between the base warranty and the extended warranty is
not crystal clear.

How can a relying party know whether it can have the benefits of the base
warranty or of the extended warranty ?

If the extended warranty is present, then the relying party has the benefit
of the extended warranty.  In short, if it is present, then the relying
party knows that the relying party has the benefit of the extended warranty
by its presence alone.  The syntax shows that the extended warranty MAY be
present:
  Warranty ::= CHOICE  {
        none                 NULL,            -- No warranty provided
        wData                WarrantyData  }  -- Explicit warranty

    WarrantyData ::= SEQUENCE  {
        base                 WarrantyInfo,
        extended             WarrantyInfo OPTIONAL,
        tcURL                TermsAndConditionsURL OPTIONAL  }

If the tcURL is present, a human being might understand the terms and
conditions (if he can understand the local language used), but a computer
program will not be able to do so. This means that computers cannot
understand the difference.

[Alice] The computer does not need to know what is in the T&C.  If the tcURL 
is present, it is optionally for the benefit of the human reader. Perhaps 
you could suggest some text to clarify this in the I-D if you still think it 
is needed.

[Denis] Then say something like: "Warranty extensions are only aimed for 
human interpretation and contain data that is inappropriate for computer 
based verification schemes, the warranty extension MUST NOT be an active 
component in automated certification path validation."

3 - There is no security on the information placed at the tcURL parameter
since no hash of the terms and conditions is being used. These conditions
could change overtime and relying parties would not be able to demonstrate
that they have changed.

[Alice]
It seems to me that the time stamp on the certificate would suffice to place
the warranty in a point of time at which the specified terms and conditions
applied; there is no need for the extension to demonstrate that as this is
covered by the certificate itself.  This is no different from the
paper-based world in that if an insurance policy changes its terms, it
cannot do so retroactively to the detriment of clients who have paid for a
specific coverage, unless it notified the clients and compensates them
accordingly.

[Denis] The problem is that the CA could change the policy and the relying 
party will be unable to demonstrate that the policy has changed. A 
time-stamp token over the certificate would not help. A time-stamp token 
over the T&C would help, but the relying party does not necessarily have 
access to one TSU. The hash approach is much simpler.

4 - Is the "Relying party Agreement" a document to signed by the parties or
not ? This should be said.

[Alice]
Use of the term "Relying Party Agreement" is no different from its normal
usage, just as "Certificate Policy" is used in the same context without any
change to the meaning from normal usage, as per RFC 2527 and its successor.
In other words, defining the terms, either Relying Party Agreement or
Certificate Policy is not necessary to the understanding of this extension.

[Denis] The term "Relying Party Agreement" is confusing. Use a wording like 
"Terms and Conditions for Relying parties" which does not imply that there 
is an agreement signed but that unilaterally the CA provides terms and 
conditions. Relying parties may like them or not. If they disagree with 
them, then this is still "Terms and Conditions for Relying parties".

5 - The WarrantyValidityPeriod is insufficient. Usually there is a period to
claim for a compensation which must be made X months or Y days after the
date of the event which created the damage. It is thus not possible to ask
for a warranty during e.g. the whole validity period of the certificate.
Another time period parameter is missing.

[Alice]
This is exactly what the validity period is stating: that the warranty is
valid for a specified time, which is either the validity period of the
certificate, or another, specified time using the parameters as defined in
the I-D.  It is presented and offered this way, so there is no need for
another validity parameter.  If an offeror wanted to specify a time within
which claims could be made, then a shorter time period than the validity of
the certificate can be used.  This is unlike the paper-based world in the
sense that insurance policies are normally of long duration, whereas this
extension is associated with a certificate that normally has a validity of
two-three years.

[Denis] The semantics of the warranty validity period is not defined ! There 
is a need to define more precisely what "the warranty validity period" is. 
Here is a proposal along my original text. If it does not fit, please 
propose an alternative:

" The warranty validity period is a time period to claim for a compensation 
which must be made X months or Y days after the date of the event which 
created the damage. It is unrelated to the certificate validity period."

6 - The wType offers only two types of warranty: aggregated and per
transaction.

"Aggregated" means that that once the value of the fulfilled claims reaches
the maximum warranty amount, then no further claim will be fulfilled.

"Per transaction" means that each claim is handled independently but no
individual claim can exceed the maximum warranty amount.

Each type has its own problems:

"Aggregated" is like a race where late claimants will get no compensation at
all because they were not "fast enough". It is questionable whether such a
race condition will be acceptable.
It should be understood that aggregation applies to one warranty and one
claimant.  This is analogous to the paper-based world.  When you are covered
by warranty for X product or service, e.g., health insurance, there is often
an upper limit (viz. the "value") up to which claims will be met for each
claimant; i.e., one insured person.
"Per transaction" means that the CA cannot compute the maximum amount of
money that it may have to give away. Which insurance company will ever
insure a risk for which an upper limit cannot be computed ?

[Alice]
The T&C, as noted in section 1, as covered by insurance, will specify the 
maximum. The type of warranty selected depends on the nature of the 
transactions, the parties to the transactions (e.g., individuals, large 
institutions, etc.).

[Denis] What I am asking for is to allow a combination of both types, which 
is currently not possible. See below again.

None of these schemes is acceptable. Some combination should be allowed:

   - a maximum amount per transaction, and
   - a maximum amount per certificate with a maximum time period
     to claim for a compensation after the date of the event
     (no race problem implied).

7 - The content of the security consideration should be augmented to
indicate the difference between what a computer program can do and a human
being can do with this extension.

[Alice]
I would have thought this to be blindingly obvious.  We would, however, be
quite willing to consider some proposed words to address this, if you do
think it is necessary.

[Denis] If my text proposal related to comment 2 is inserted, then this is 
no more needed.

8 - The document is not mature enough and its added value is still
questionable.

[Alice]
We believe that it is mature.  Its value may be questionable to those who do
not want to use it, but given that it is (a) proposed as Informational and
(b) always non-critical, surely its availability for use is innocuous for
those that do not want to use it.  For those who do want to use it, and we
have heard from quite a number who do, it will be useful and valuable.  As
in section 1: "When a certificate contains a warranty certificate extension,
the extension MUST be non-critical, ..."

[Denis]
As you can see, we have progressed, but several issues still need to be 
addressed.


Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SNLYqt094751 for <[e-mail]>; Mon, 28 Jul 2003 16:21:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SNLYTZ094750 for ietf-pkix-bks; Mon, 28 Jul 2003 16:21:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SNLWqt094730 for <[e-mail]>; Mon, 28 Jul 2003 16:21:32 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6SNLIkh142298; Mon, 28 Jul 2003 19:21:18 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6SNLG0g066500; Mon, 28 Jul 2003 19:21:17 -0400
To: [e-mail]
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 28 Jul 2003 19:21:14 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPRs JHEG5JQ5CD, THTO5KLVS6, JHEG5HMLFK, JCHN5K5PG9|March 27, 2003) at 07/28/2003 19:21:17, Serialize complete at 07/28/2003 19:21:17
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Bonny:

        I am afraid that I don't understand your point, at all.  If the 
PKUP is present in the signer's certificate and is inside the validity 
period, the simplest rule for deciding whether the signature time is 
legitimate for that certificate is:
a)      If a time is specified in the signed object, that time must be 
within PKUP and the current time must be within the validity period.
b)      If no time is specified in the signed object, the current time 
must be within PKUP. 

        If the PKUP is not present, retrospective validation requires that 
the rules on validity time be relaxed in roughly the manner I specified in 
my earlier message.  Let me give a simple example:
1       Joe has a credit card which expires on 7/31/2003, with a 
certificate tied to it and expiring on that same date.
2       Joe buys a music CD over the Internet today (7/27), signing the 
order with the key corresponding to the certificate in step 1.
3       The CD reaches Joe on 7/31.
4       Joe dislikes several songs on the album, and decides that he 
shouldn't pay.
5       Joe claims that he didn't order the CD, when his final billing 
statement comes on 8/3.

        Now how does the credit card company get the signature and 
certificate validated on 8/4 or 8/5, or during a court case?  Even if the 
revocation evidence has been preserved in a way similar to sections 
4.4-4.6 of the "technr" draft, including time-stamping, the validation 
needs to be run after the validity period has expired.

        In this instance, using a PKUP whose end date is the expiration 
date of the credit card while putting the certificate validity end date a 
year or more after that would avoid these complexities.  In general, using 
PKUP seems to reduce the need for retrospective validation.  AFAIK, that 
is its main use.

                Tom Gindin





"bonny joy" <[e-mail]>
Sent by: [e-mail]
07/27/2003 08:20 PM

 
        To:     [e-mail], [e-mail]
        cc:     [e-mail]
        Subject:        RE: Re: Why is privateKeyUsagePeriod deprecated?




Dear Steve

The PKUP does operate as you note, but the cert validity period is still 
present, and in the presence of the PKUP extension, this field is 
reinterpreted to state that after the notAfter date, the cert may no 
longer 
be used to verify any signature, period.  That too is part of the reason 
for 
not encouraging use of PKUP, i.e., the need to reinterpret the cert 
validity 
field.



This is my view



The certificate can be used to verify the signature during the certificate 

validity period irrespective of the PKUP  , for this reason certificate 
validity period should be present



The signature should not be generated after or before  the PKUP, since the 

private key validity period is different from the certificate validity 
period , this field should be present



So why does a certificate processing part should get confused by seeing 
the 
2 fields , those 2 fields are meant for different purposes, First check 
the 
signature has been created at the valid period ,then check the validity of 

the certificate. In the case of NR the validity of the certificate is not 
having any impact ,since the thrust is on PKUP.





Regards Bonny

_________________________________________________________________
They are beautiful. They are in danger. 
http://server1.msn.co.in/Slideshow/BeautyoftheBeast/index.asp Our 
four-legged friends.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SM7bqt089283 for <[e-mail]>; Mon, 28 Jul 2003 15:07:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SM7bYH089282 for ietf-pkix-bks; Mon, 28 Jul 2003 15:07:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SM7aqt089271 for <[e-mail]>; Mon, 28 Jul 2003 15:07:36 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id E70256A8AF; Mon, 28 Jul 2003 15:07:36 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "'pkix'" <[e-mail]>
Subject: WG Last Call draft-ietf-pkix-SCVP-12.txt
Date: Mon, 28 Jul 2003 15:08:01 -0700
Message-ID: <002301c35554$b66b1230$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

ASN.1 Module:
1. CertificateList is not imported
2. UTF8String is not defined
3. OCSPResponse is not imported or defined
4. Name is imported but never referenced
5. SubjectPublicKeyInfo is imported but never referenced


Nits:

Section 1.1: "For a client uses these services" -- "that uses these"
Section 1.1: "that are performed during certification path validation"
-- "certificate path"

Other items:

1. Section 3: References to an SCVPRequest - I assume this should be a
CVRequest

2. Section 3: There is an item called a certValRequest - is this a
CVRequest?

3. Section 3.2.2:  In para 2, there is a parenthetical remark that a
server may choose to perform unrequested operations.  Is this permitted
to affect the result returned to the client?  I.e. I ask for a path
build, the server does revocation checking and the cert is revoked.  Can
it say no valid path exists?

4. Section 3.2.3:  Does AC checking include the PKC checking of the
issuer of the AC?  Can I specify a PKC as a trust point for purposes of
AC path building?

5. Section 3.2.5:  "ask for the servers default validation policy" vs "A
global default validation policy"

6. Section 3.2.5.1, last paragraph:  Yes, but does it match
[e-mail]?  This is a much more interesting question that the
ones you have listed.

7. Section 3.2.5.1:  I want to change from GeneralName to GeneralNames.
I want to be able to specify a name validation for e-mail againist both
a FROM and SENDER name.  I assume that doing two name validation
parameters would NOT get me what I want as both would need to pass
validation. (i.e. AND not OR)

8. Section 3.2.6:  Please add a (small) note dealing with clock skew
issues.

9. Section 3.2.6:  What if I put now into the validateTime field?  How
does the server make the determination on historical information?

10. Section 3.2.7:  Trust anchor only allows for self-signed
certificates?  Can I put an invalid certificate in the trust anchor
locaiton and have it correctly work (i.e. build my own self-signed
certificate to add such items as name constraints)?

11. Section 3.2.8:  I don't like the word trusted in this paragraph.  I
think a better phrase is "considred as valid"  Only items in the trust
anchor list should be considered as "trusted"

12. Section 3.2.9: Allow for references to CRL's to be placed in the
SignedData crl list?

13. Section 3.2.10:  Is it possible to change the term recognize so that
we don't have the same issues that we do with processing certificates
about the difference between recognize and process?

14. Section 3.3: I really don't like having to deal with the fact that
the requestor value must not have a zero octet.  I finally did find the
reason farther down, and would perfer that this be done in the ASN.1
rather than by special processing of the octet string.

15. Section 3.?:  Can a ref be to a extant certificate in a differet
CertRef field?

16. Section 4:  What is an SCVPResponse - no definition, I assume it's a
wrapped ContentInfo w/ a CVResponse, but not defined.

17. Section 4:  If only signed and unsigned responses, why is there an
authenticatedData example below?  [Located text that says signed
responses are either signed or authenticated, I don't like the blurring
between these items as they have different security properties.]

18. Section 4:  Why is there a restriction on the number of SignerInfos?
If a server has two, why can it not sign with both?  How would a server
know which certificate to use for signing?

19. Section 4:  If authenticated data is used, is this only in response
to an authenticated request?  How does the server determine what secret
is to be used?

20. Section 4:  You should permit the inclusion of a CounterSignature
attribute in the unsignedAttrs of a response message for later
processing after archival.

21. Section 4:  Please expand on the following text.  I don't understand
where this identifier would be used.  "   The value of the
message-digest attribute in the signedAttrs within 
   SignerInfo MAY be used as an identifier of the reponse generated by 
   the SCVP server. 
    "

22. Section 4.2: If I ask for a status of a specific time (validityTime)
does this change the value of producedAt?  If so this should be
reminded.

23. Section 4.3:  Please define which items are error vs non-error
response codes.

24. Section 4.4:  Does the connectionless statement imply that if I use
TLS I cannot have two outstanding requests in at a given time?  What
happens for server timeouts, multiple applications using a single pipe
(or impaitent users).

25. Section 4.4:  Please provide guidence on which to use requestHash vs
fullRequest.

26. Section 4.7.5:  Why is ReplyWantBack not using an ANY defined by
field rather than an OCTET STRING?.

27. Question: I put an PKC and and AC cert in a request.  I put in
status-aa-path and status-pkc-path.  What is in the result message?

28. Section B.1:  Why must the item be DER encoded?  Should the CMS
ContentInfo type surround  the CVRequest structure?

29. Section B:  What about the policy messages?


jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SLToqt087457 for <[e-mail]>; Mon, 28 Jul 2003 14:29:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SLTnjq087453 for ietf-pkix-bks; Mon, 28 Jul 2003 14:29:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from melbourne6.fhp.com.au (melbourne6.fhp.com.au [202.53.34.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SLTlqt087445 for <[e-mail]>; Mon, 28 Jul 2003 14:29:48 -0700 (PDT) (envelope-from [e-mail])
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.10  March 22, 2002
Message-ID: <[e-mail]>
From: "Adrian McCullagh" <[e-mail]>
Date: Tue, 29 Jul 2003 07:22:32 +1000
X-MIMETrack: Serialize by Router on Melbourne6/FHP/AU(Release 5.0.12  |February 13, 2003) at 29/07/2003 07:31:53 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------

Peter,

That isa really good point you make.  Maybe there could be a competition
formed that will pick some PKIX RFCs and award something to the Vendor
whose product complies the most with the selected RFCsand too what extent.

Concluding remark:

Is it worthwhile really calling it a STANDARD if so few vendors (if any at
all) are compliant.

Dr. Adrian McCullagh
Solicitor
Freehills

Direct 61 7 3258 6603
Telephone [phone]
Facsimile 61 7 3258 6444
http://www.freehills.com


                                                                                                        
                                                                                                        
                          [e-mail].  To:    [e-mail], [e-mail]      
                          ac.nz (Peter          cc:    [e-mail], [e-mail],         
                          Gutmann)                     [e-mail]                             
                          Sent by:              Subject: RE: Microsoft and multi-valued RDNs (was:      
                          owner-ietf-pkix@mail         draft minutes)                                   
                          .imc.org                                                                      
                                                                                                        
                                                                                                        
                          28/07/2003 06:25 PM                                                           
                                                                                                        
                                                                                                        





Stephen Kent <[e-mail]> writes:

>I appreciate the clarification, but I am appalled by the suggestion that
>people should construct ungainly CNs that will be hard for users to parse,
or
>that LDAP schema should be skewed to accommodate this lack of standards
>compliance.

PKIX, meet the real world.

Actually I'd like to offer a small soapbox here on the out-of-touch-with-
reality nature of many PKI-related RFCs, and the deleterious side-effects
that
this has when the RFC is applied in practice.  For example there's an EDI
messaging standard that had to do X (and also Y and Z, none of them related
to
verifying sigs after the cert has expired as per the recent thread), so
they
went to the appropriate RFCs, picked the way they wanted to do things, and
wrote it into their standard.  Since security always gets bolted on as an
afterthought, the rest of the standard was in use for a year or two before
anyone got around to looking at the security parts of it.  At that point
they
discovered that nothing in existence implemented what they required (poor
guys, they thought that MUST in the RFC implied that it'd be supported),
and
no vendor was interested in supporting it [0].

This situation is unfortunately all too common, with users (and in this
case
the WG chair) discovering that some feature discussed in an RFC as if it
were
a hard fact exists only in the imagination of the RFC author.  What's more
problematic is the case of RFC A relying on an imaginary feature of RFC B
which in turn relies on an imaginary feature of RFC C.  This is why, in
stuff
I write, I include extensive implementation notes with caveats such as "The
standard says MUST X, but in practice no-one does it that way, so be
prepared
to encounter data which doesn't do X at all".

A few years ago I started making a list of features in PKI RFCs, rated from
1-5 in terms of support in implementations, where 1 means "you can rely on
it
being present" and 5 means "don't bother", the idea being that users could
consult it to see whether the feature they wanted was going to be available
in
the real world.  I abandoned it after a while because (a) I didn't think
I'd
make many friends pointing out how little of what was in the RFCs was
actually
supported in practice and (b) there was a kind of geometric growth of
features
as you went further along the scale (i.e. from 1 to 5).

So to sum up I really wish PKIX would at least make some attempt to
approximate the real world.  SSH for example has just had a poll of
implementors/implementations to check for how to handle a new feature being
added, with the primary goal being existing support for it and
compatibility
with current implementations.  The PKIX approach in contrast seems to be to
construct cloud castles, declare the problem solved, and then wonder why
nothing does what the RFC says.

Peter.

[0] Actually I believe that there exists a single experimental/reference
    implemetation that does it, but I'm not sure who uses it in practice.







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SG64qt069682 for <[e-mail]>; Mon, 28 Jul 2003 09:06:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SG6486069681 for ietf-pkix-bks; Mon, 28 Jul 2003 09:06:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SG62qt069670 for <[e-mail]>; Mon, 28 Jul 2003 09:06:03 -0700 (PDT) (envelope-from [e-mail])
Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6SG2p107724; Mon, 28 Jul 2003 18:02:52 +0200
Message-ID: <[e-mail]>
Date: Mon, 28 Jul 2003 18:02:51 +0200
From: Leif Johansson <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <[e-mail]> <[e-mail]> <p05210600bb4ad9ed31e9@[128.89.89.75]> <[e-mail]> <p05210605bb4aec47262b@[128.89.89.75]> <[e-mail]> <p05210607bb4af6d8a021@[128.89.89.75]>
In-Reply-To: <p05210607bb4af6d8a021@[128.89.89.75]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

>
> I won't continue arguing with you about the primacy of LDAP. Either it 
> will support PKI needs, or something
>
I agree - let's not beat this particular horse anymore :-)



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SFupqt069263 for <[e-mail]>; Mon, 28 Jul 2003 08:56:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SFuoap069262 for ietf-pkix-bks; Mon, 28 Jul 2003 08:56:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SFunqt069256 for <[e-mail]>; Mon, 28 Jul 2003 08:56:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6SFuiD9009695; Mon, 28 Jul 2003 11:56:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210607bb4af6d8a021@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p05210600bb4ad9ed31e9@[128.89.89.75]> <[e-mail]> <p05210605bb4aec47262b@[128.89.89.75]> <[e-mail]>
Date: Mon, 28 Jul 2003 11:56:53 -0400
To: Leif Johansson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 17:29 +0200 7/28/03, Leif Johansson wrote:
>Stephen Kent wrote:
>
>>
>>people manage ACLs that use cert DNs as inputs for authorization. 
>>people examine DNs to make value judgements about names, e.g., in 
>>received S/MINE e-mail.  Thus it is important for DNs to be 
>>meaningful to people when they perform these functions.
>
>I know - that is one of the bad side-effects of the current pki naming scheme.

This is not a side effect, it is an essential element of any ID-based 
authorization scheme.

>>PKI gave up on ubiquitous directory availability long ago. Many 
>>apps that use PKI never need use a directory to locate a cert, 
>>because certs can be passed in the protocols (e.g., IKE & SSL/TLS). 
>>The same is true for CRLs in IKE. There are apps that benefit 
>>greatly from directory storage of certs, but if the LDAP won't 
>>support multi-valued RDNs we'll just have to use other directory 
>>models. The AIA and SIA extensions to permit this.
>
>And how many of these directores are deployed today? Are you 
>building a research project
>or are you building something which will actually be used by people 
>outside of the pkix-wg??
>The bottom line is that directores are widely deployed and pki is 
>not. If pki is to have any
>chance to get integrated with the provisioning systems which *are* 
>*already* deployed and
>used in enterprises today it must work with LDAP. No extensions. No add-ons.

I won't continue arguing with you about the primacy of LDAP. Either 
it will support PKI needs, or something else will be used to the 
extent that PKI apps require directories. So far, LDAP has not done a 
great job of supporting PKI requirements, as evidenced by the long 
running ;binary debate. Your comments are illustrative of a 
directory-centric mindset that perpetuates these sorts of problems.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SFWTqt067518 for <[e-mail]>; Mon, 28 Jul 2003 08:32:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SFWT4W067517 for ietf-pkix-bks; Mon, 28 Jul 2003 08:32:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SFWRqt067511 for <[e-mail]>; Mon, 28 Jul 2003 08:32:27 -0700 (PDT) (envelope-from [e-mail])
Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6SFTG107698; Mon, 28 Jul 2003 17:29:16 +0200
Message-ID: <[e-mail]>
Date: Mon, 28 Jul 2003 17:29:16 +0200
From: Leif Johansson <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <[e-mail]> <[e-mail]> <p05210600bb4ad9ed31e9@[128.89.89.75]> <[e-mail]> <p05210605bb4aec47262b@[128.89.89.75]>
In-Reply-To: <p05210605bb4aec47262b@[128.89.89.75]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

>
> people manage ACLs that use cert DNs as inputs for authorization. 
> people examine DNs to make value judgements about names, e.g., in 
> received S/MINE e-mail.  Thus it is important for DNs to be meaningful 
> to people when they perform these functions.

I know - that is one of the bad side-effects of the current pki naming 
scheme.

>
> PKI gave up on ubiquitous directory availability long ago. Many apps 
> that use PKI never need use a directory to locate a cert, because 
> certs can be passed in the protocols (e.g., IKE & SSL/TLS). The same 
> is true for CRLs in IKE. There are apps that benefit greatly from 
> directory storage of certs, but if the LDAP won't support multi-valued 
> RDNs we'll just have to use other directory models. The AIA and SIA 
> extensions to permit this.

And how many of these directores are deployed today? Are you building a 
research project
or are you building something which will actually be used by people 
outside of the pkix-wg??
The bottom line is that directores are widely deployed and pki is not. 
If pki is to have any
chance to get integrated with the provisioning systems which *are* 
*already* deployed and
used in enterprises today it must work with LDAP. No extensions. No 
add-ons.

>
> Steve

    MVH leifj



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SFGpqt066804 for <[e-mail]>; Mon, 28 Jul 2003 08:16:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SFGpKU066802 for ietf-pkix-bks; Mon, 28 Jul 2003 08:16:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SFGoqt066785 for <[e-mail]>; Mon, 28 Jul 2003 08:16:50 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6SFGkD9007014; Mon, 28 Jul 2003 11:16:46 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210605bb4aec47262b@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p05210600bb4ad9ed31e9@[128.89.89.75]> <[e-mail]>
Date: Mon, 28 Jul 2003 11:12:44 -0400
To: Leif Johansson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 16:57 +0200 7/28/03, Leif Johansson wrote:
>Stephen Kent wrote:
>
>>
>>I disagree with your analysis, in almost every detail.  The names 
>>are names, not addresses.  I can imagine that from an LDAP 
>>perspective you think if these names as inputs to locating database 
>>entries, but this is a rather narrow view for several reasons.Certs 
>>exist separate from directories, despite the origin of certs as an 
>>X.500 construct. Moreover, there are many ways to locate  directory 
>>entries, and the DN is but one. Yes, people get confused by names 
>>vs. addresses,  and the topic has been hotly debated for over 25 
>>years.  I refer you to John Shoc's paper form the later 70s' on 
>>this topic.
>
>That is precisely my point but I could have made it clearer. If your 
>only requirement is uniqueness
>then serial is enought. Trouble ensues when you try to use the 
>identifier for something else (readability).

people manage ACLs that use cert DNs as inputs for authorization. 
people examine DNs to make value judgements about names, e.g., in 
received S/MINE e-mail.  Thus it is important for DNs to be 
meaningful to people when they perform these functions.

>
>>
>>Speaking from the PKI perspective, LDAP is not the center of the 
>>universe. Get over it. :-)
>
>In terms of actual deployments I'd say LDAP is "slightly" more 
>wide-spread of the two. If
>a feature which is in the standard (multivalued rdn's) is not 
>implemented by leading vendors
>it is for all intents and purpouses dead. Relying on it from the 
>pkix community is clearly not
>a good idea if you are looking for interoperability with *existing* 
>deployed directories.

PKI gave up on ubiquitous directory availability long ago. Many apps 
that use PKI never need use a directory to locate a cert, because 
certs can be passed in the protocols (e.g., IKE & SSL/TLS). The same 
is true for CRLs in IKE. There are apps that benefit greatly from 
directory storage of certs, but if the LDAP won't support 
multi-valued RDNs we'll just have to use other directory models. The 
AIA and SIA extensions to permit this.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SF7nqt066258 for <[e-mail]>; Mon, 28 Jul 2003 08:07:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SF7n0r066257 for ietf-pkix-bks; Mon, 28 Jul 2003 08:07:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SF7Yqt066240 for <[e-mail]>; Mon, 28 Jul 2003 08:07:37 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04791; Mon, 28 Jul 2003 11:07:30 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-11.txt
Date: Mon, 28 Jul 2003 11:07:29 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SF7lqt066250 for <[e-mail]>; Mon, 28 Jul 2003 08:07:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SF7lEl066249 for ietf-pkix-bks; Mon, 28 Jul 2003 08:07:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SF7bqt066241 for <[e-mail]>; Mon, 28 Jul 2003 08:07:41 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04806; Mon, 28 Jul 2003 11:07:34 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sca-00.txt
Date: Mon, 28 Jul 2003 11:07:34 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Subject Certificate Access Extension
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-sca-00.txt
	Pages		: 0
	Date		: 2003-7-28
	
Currently there is nothing in a certificate to tell a relying party where this certificate, or any other certificate issued to the subject of this certificate, has been published. This document defines an extension that indicates where certificates of the subject may be published.

Please send comments on this document to the [e-mail] mailing list.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-sca-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SF1tqt066107 for <[e-mail]>; Mon, 28 Jul 2003 08:01:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SF1tDc066106 for ietf-pkix-bks; Mon, 28 Jul 2003 08:01:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SF1sqt066098 for <[e-mail]>; Mon, 28 Jul 2003 08:01:54 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6SF1oD9005970; Mon, 28 Jul 2003 11:01:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210603bb4ae9fe9d0d@[128.89.89.75]>
In-Reply-To: <006901c3550c$f61fbef0$020aff0a@tsg1>
References: <[e-mail]> <006901c3550c$f61fbef0$020aff0a@tsg1>
Date: Mon, 28 Jul 2003 10:58:11 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:33 -0700 7/28/03, todd glassey wrote:
>Peter - this is why so much of what PKIX did was not appropriate for the
>IETF but belonged by pure definition in the IRTF, but then the management
>team wouldn't of had the empire they have now to manage... PKIX is then a
>fiefdom and has never been anything else.
>
>So lets ask the management team the really big questions
>
>     1)    How many years has PKIX existed
>
>     2)    How many RFC's has it produced that have made it to Standards
>Status
>
>     3)    At what cost and to the expense of how many participants and their
>sponsors...
>
>Maybe its time to do the nasty and make PKIX a financial operations model so
>we can really see what is what here.
>
>Todd Glassey
>

PKIX, like all other IETF WGs, is a volunteer activity. Nobody is 
required to participate. Only on ToddLand would a "financial 
operations model" make any sense for any of the IETF WGs.

Talk of being out of touch with reality ...

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SF1Eqt066087 for <[e-mail]>; Mon, 28 Jul 2003 08:01:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SF1EhO066086 for ietf-pkix-bks; Mon, 28 Jul 2003 08:01:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SF1Cqt066081 for <[e-mail]>; Mon, 28 Jul 2003 08:01:12 -0700 (PDT) (envelope-from [e-mail])
Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6SEvv107675; Mon, 28 Jul 2003 16:57:58 +0200
Message-ID: <[e-mail]>
Date: Mon, 28 Jul 2003 16:57:57 +0200
From: Leif Johansson <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <[e-mail]> <[e-mail]> <p05210600bb4ad9ed31e9@[128.89.89.75]>
In-Reply-To: <p05210600bb4ad9ed31e9@[128.89.89.75]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

>
> I disagree with your analysis, in almost every detail.  The names are 
> names, not addresses.  I can imagine that from an LDAP perspective you 
> think if these names as inputs to locating database entries, but this 
> is a rather narrow view for several reasons.Certs exist separate from 
> directories, despite the origin of certs as an X.500 construct. 
> Moreover, there are many ways to locate  directory entries, and the DN 
> is but one. Yes, people get confused by names vs. addresses,  and the 
> topic has been hotly debated for over 25 years.  I refer you to John 
> Shoc's paper form the later 70s' on this topic.

That is precisely my point but I could have made it clearer. If your 
only requirement is uniqueness
then serial is enought. Trouble ensues when you try to use the 
identifier for something else (readability).

>
> Speaking from the PKI perspective, LDAP is not the center of the 
> universe. Get over it. :-)

In terms of actual deployments I'd say LDAP is "slightly" more 
wide-spread of the two. If
a feature which is in the standard (multivalued rdn's) is not 
implemented by leading vendors
it is for all intents and purpouses dead. Relying on it from the pkix 
community is clearly not
a good idea if you are looking for interoperability with *existing* 
deployed directories.

>
> Steve





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SEpqqt065894 for <[e-mail]>; Mon, 28 Jul 2003 07:51:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SEpq1T065893 for ietf-pkix-bks; Mon, 28 Jul 2003 07:51:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SEpoqt065887 for <[e-mail]>; Mon, 28 Jul 2003 07:51:51 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6SEpjD9005284; Mon, 28 Jul 2003 10:51:46 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210600bb4ad9ed31e9@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Mon, 28 Jul 2003 10:47:16 -0400
To: Leif Johansson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:31 +0200 7/27/03, Leif Johansson wrote:
>The fundamental problem (imo) is that pki confuses the address with 
>the name in
>the current use of subject and issuer DN. Using multivalued 
>"terminal" rdns for
>EE is as we all know the result of wanting to have a readable 
>component (the name)
>along with a unique component (the "address"). The corresponding 
>problem has been
>cropping up all over the ietf of late (for instance in the recent 
>discussion on ipv6
>multihoming).
>
>Speaking from the LDAP community my view is that the use of multivalued rdn's
>is as dead as the Dodo. Get over it.
>
>       Cheers Leif

I disagree with your analysis, in almost every detail.  The names are 
names, not addresses.  I can imagine that from an LDAP perspective 
you think if these names as inputs to locating database entries, but 
this is a rather narrow view for several reasons.Certs exist separate 
from directories, despite the origin of certs as an X.500 construct. 
Moreover, there are many ways to locate  directory entries, and the 
DN is but one. Yes, people get confused by names vs. addresses,  and 
the topic has been hotly debated for over 25 years.  I refer you to 
John Shoc's paper form the later 70s' on this topic.

Speaking from the PKI perspective, LDAP is not the center of the 
universe. Get over it. :-)

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SDZSqt057716 for <[e-mail]>; Mon, 28 Jul 2003 06:35:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SDZS5a057715 for ietf-pkix-bks; Mon, 28 Jul 2003 06:35:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SDZPqt057710 for <[e-mail]>; Mon, 28 Jul 2003 06:35:26 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (50.sanjose-01-02rs16rt.ca.dial-access.att.net[12.81.0.50]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030728133508111008b0rme>; Mon, 28 Jul 2003 13:35:10 +0000
Message-ID: <006901c3550c$f61fbef0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Mon, 28 Jul 2003 06:33:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter - this is why so much of what PKIX did was not appropriate for the
IETF but belonged by pure definition in the IRTF, but then the management
team wouldn't of had the empire they have now to manage... PKIX is then a
fiefdom and has never been anything else.

So lets ask the management team the really big questions

    1)    How many years has PKIX existed

    2)    How many RFC's has it produced that have made it to Standards
Status

    3)    At what cost and to the expense of how many participants and their
sponsors...

Maybe its time to do the nasty and make PKIX a financial operations model so
we can really see what is what here.

Todd Glassey

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Monday, July 28, 2003 1:25 AM
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)


>
> Stephen Kent <[e-mail]> writes:
>
> >I appreciate the clarification, but I am appalled by the suggestion that
> >people should construct ungainly CNs that will be hard for users to
parse, or
> >that LDAP schema should be skewed to accommodate this lack of standards
> >compliance.
>
> PKIX, meet the real world.
>
> Actually I'd like to offer a small soapbox here on the out-of-touch-with-
> reality nature of many PKI-related RFCs, and the deleterious side-effects
that
> this has when the RFC is applied in practice.  For example there's an EDI
> messaging standard that had to do X (and also Y and Z, none of them
related to
> verifying sigs after the cert has expired as per the recent thread), so
they
> went to the appropriate RFCs, picked the way they wanted to do things, and
> wrote it into their standard.  Since security always gets bolted on as an
> afterthought, the rest of the standard was in use for a year or two before
> anyone got around to looking at the security parts of it.  At that point
they
> discovered that nothing in existence implemented what they required (poor
> guys, they thought that MUST in the RFC implied that it'd be supported),
and
> no vendor was interested in supporting it [0].
>
> This situation is unfortunately all too common, with users (and in this
case
> the WG chair) discovering that some feature discussed in an RFC as if it
were
> a hard fact exists only in the imagination of the RFC author.  What's more
> problematic is the case of RFC A relying on an imaginary feature of RFC B
> which in turn relies on an imaginary feature of RFC C.  This is why, in
stuff
> I write, I include extensive implementation notes with caveats such as
"The
> standard says MUST X, but in practice no-one does it that way, so be
prepared
> to encounter data which doesn't do X at all".
>
> A few years ago I started making a list of features in PKI RFCs, rated
from
> 1-5 in terms of support in implementations, where 1 means "you can rely on
it
> being present" and 5 means "don't bother", the idea being that users could
> consult it to see whether the feature they wanted was going to be
available in
> the real world.  I abandoned it after a while because (a) I didn't think
I'd
> make many friends pointing out how little of what was in the RFCs was
actually
> supported in practice and (b) there was a kind of geometric growth of
features
> as you went further along the scale (i.e. from 1 to 5).
>
> So to sum up I really wish PKIX would at least make some attempt to
> approximate the real world.  SSH for example has just had a poll of
> implementors/implementations to check for how to handle a new feature
being
> added, with the primary goal being existing support for it and
compatibility
> with current implementations.  The PKIX approach in contrast seems to be
to
> construct cloud castles, declare the problem solved, and then wonder why
> nothing does what the RFC says.
>
> Peter.
>
> [0] Actually I believe that there exists a single experimental/reference
>     implemetation that does it, but I'm not sure who uses it in practice.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S9Qnqt038282 for <[e-mail]>; Mon, 28 Jul 2003 02:26:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6S9Qn7b038280 for ietf-pkix-bks; Mon, 28 Jul 2003 02:26:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nextra.cz (smtp.nextra.cz [195.70.130.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S9Qlqt038253 for <[e-mail]>; Mon, 28 Jul 2003 02:26:48 -0700 (PDT) (envelope-from [e-mail])
Received: from cbuwdostalek2 (unknown [195.47.37.200]) by smtp.nextra.cz (Postfix) with ESMTP id E12F623A67 for <[e-mail]>; Mon, 28 Jul 2003 11:26:46 +0200 (CEST)
From: <[e-mail]>
To: <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Date: Mon, 28 Jul 2003 11:25:01 +0200
Message-ID: <008a01c354ea$1ee43aa0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Dear Steve
>
> The PKUP does operate as you note, but the cert validity period is
still 
> present, and in the presence of the PKUP extension, this field is 
> reinterpreted to state that after the notAfter date, the cert may no
longer 
> be used to verify any signature, period.  That too is part of the
reason for 
> not encouraging use of PKUP, i.e., the need to reinterpret the cert
validity 
> field.
> 
> Regards Bonny

>From my point of view, PKUP could be an useful extention of CA certs. 
CA must issue its new cert long time before expiration of its own 
certificate (this period is min of max of the time validity of issued EE
certs).

It means: After issuing new CA cert (new-new) the old CA cert (old-old) 
is still valid but an appropriate old private key of the CA is not used 
henceforth. This private key should be authoritative erased when 
the new certificate CA is issued. Lifetime of private key is shorter
than 
the validity period of the certificate. This lifetime of private key 
could be indicated in PKUP.

Today, the lifetime of private key is  indicated in the certificate 
policy (CP). Unfortunately it is not possible to  start procedure 
for downloading new CA certs (old-new, new-new and new-old)
automatically
because the certificate policy (CP) is a nonstructured text. In
practice, 
the lifetime of CA private key is not even  published in CP yet. It is 
published in CPS (RFC-2527) which is not in case of the majority 
of  CAs public. Therefore it might by useful to indicate  this 
information in the PKUP.

Libor Dostalek



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S8Q3qt027897 for <[e-mail]>; Mon, 28 Jul 2003 01:26:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6S8Q3oI027896 for ietf-pkix-bks; Mon, 28 Jul 2003 01:26:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S8Q1qt027876 for <[e-mail]>; Mon, 28 Jul 2003 01:26:01 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6S8PmV8017245; Mon, 28 Jul 2003 20:25:48 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6S8Plc04015; Mon, 28 Jul 2003 20:25:47 +1200
Date: Mon, 28 Jul 2003 20:25:47 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>I appreciate the clarification, but I am appalled by the suggestion that
>people should construct ungainly CNs that will be hard for users to parse, or
>that LDAP schema should be skewed to accommodate this lack of standards
>compliance.

PKIX, meet the real world.

Actually I'd like to offer a small soapbox here on the out-of-touch-with-
reality nature of many PKI-related RFCs, and the deleterious side-effects that
this has when the RFC is applied in practice.  For example there's an EDI
messaging standard that had to do X (and also Y and Z, none of them related to
verifying sigs after the cert has expired as per the recent thread), so they
went to the appropriate RFCs, picked the way they wanted to do things, and
wrote it into their standard.  Since security always gets bolted on as an
afterthought, the rest of the standard was in use for a year or two before
anyone got around to looking at the security parts of it.  At that point they
discovered that nothing in existence implemented what they required (poor
guys, they thought that MUST in the RFC implied that it'd be supported), and
no vendor was interested in supporting it [0].

This situation is unfortunately all too common, with users (and in this case
the WG chair) discovering that some feature discussed in an RFC as if it were
a hard fact exists only in the imagination of the RFC author.  What's more
problematic is the case of RFC A relying on an imaginary feature of RFC B
which in turn relies on an imaginary feature of RFC C.  This is why, in stuff
I write, I include extensive implementation notes with caveats such as "The
standard says MUST X, but in practice no-one does it that way, so be prepared
to encounter data which doesn't do X at all".

A few years ago I started making a list of features in PKI RFCs, rated from
1-5 in terms of support in implementations, where 1 means "you can rely on it
being present" and 5 means "don't bother", the idea being that users could
consult it to see whether the feature they wanted was going to be available in
the real world.  I abandoned it after a while because (a) I didn't think I'd
make many friends pointing out how little of what was in the RFCs was actually
supported in practice and (b) there was a kind of geometric growth of features
as you went further along the scale (i.e. from 1 to 5).

So to sum up I really wish PKIX would at least make some attempt to
approximate the real world.  SSH for example has just had a poll of
implementors/implementations to check for how to handle a new feature being
added, with the primary goal being existing support for it and compatibility
with current implementations.  The PKIX approach in contrast seems to be to
construct cloud castles, declare the problem solved, and then wonder why
nothing does what the RFC says.

Peter.

[0] Actually I believe that there exists a single experimental/reference
    implemetation that does it, but I'm not sure who uses it in practice.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S7M1qt021112 for <[e-mail]>; Mon, 28 Jul 2003 00:22:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6S7M0lH021105 for ietf-pkix-bks; Mon, 28 Jul 2003 00:22:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S7Lwqt021065 for <[e-mail]>; Mon, 28 Jul 2003 00:21:59 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6S7L1V8016311; Mon, 28 Jul 2003 19:21:01 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6S7L0B03707; Mon, 28 Jul 2003 19:21:00 +1200
Date: Mon, 28 Jul 2003 19:21:00 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Al Arsenault" <[e-mail]> writes:

>This brings up what is to me an interesting question:  exactly what service
>do you think you're providing with this signature validation long after the
>fact, 

Compliance with legal/contractual requirements.  To given another example of
this, I know of applications where the PKI software reads old stored CRLs off
disk and checks the cert against them before every use because that's what the
standard requires.  It's complete bollocks, they're just going through the
motions for form's sake, but that's what the standard requires, so that's what
they do (the standard doesn't say "You must perform a sensible revocation/
validity check", it just says "You must check certs against a CRL", so that's
what happens, even if it's one issued a month ago, and the cert has already
been checked against it 873 times before).

>and why do you think it's important?

See above.

>I can only think of about three reasons why one would want to do a signature
>validation months after an order was signed:
>
>  - as part of a business audit;
>  - as part of a dispute resolution process (e.g., a non-repudiation issue)
>  - because one's business processes were REALLLLY slow, and it just takes
>    that long to process an order.

You forgot:

  - Because the standard/law/trading agreement says you need to do this in
    order to be compliant.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S2ePqt002616 for <[e-mail]>; Sun, 27 Jul 2003 19:40:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6S2ePX1002615 for ietf-pkix-bks; Sun, 27 Jul 2003 19:40:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S2eMqu002610; Sun, 27 Jul 2003 19:40:22 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210608bb4a3d8bb11b@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <000001c35329$dead74e0$[e-mail]> <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Sun, 27 Jul 2003 19:40:55 -0700
To: "Von Welch" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Draft-ietf-pkix-proxy-06.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:14 PM -0500 7/27/03, Von Welch wrote:
>  Given that this document has passed last call and been sent to the
>editor, I'm actually not sure what my ability is to make changes at
>this point.

You can always issue a new Internet Draft. Doing so is free. :-)

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S2D9qt000512 for <[e-mail]>; Sun, 27 Jul 2003 19:13:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6S2D98B000511 for ietf-pkix-bks; Sun, 27 Jul 2003 19:13:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S2D7qt000505 for <[e-mail]>; Sun, 27 Jul 2003 19:13:07 -0700 (PDT) (envelope-from [e-mail])
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h6S2Cst189756; Sun, 27 Jul 2003 21:12:55 -0500
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Sun, 27 Jul 2003 21:14:51 -0500
To: <[e-mail]>
Cc: "'pkix'" <[e-mail]>, <[e-mail]>, "'Russ Housley'" <[e-mail]>
Subject: RE: Draft-ietf-pkix-proxy-06.txt
In-Reply-To: <000001c35329$dead74e0$[e-mail]>
References: <[e-mail]> <000001c35329$dead74e0$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

 Given that this document has passed last call and been sent to the
editor, I'm actually not sure what my ability is to make changes at
this point.

 You've pointed out one objective error in 4.1.3, which I will
certainly try to correct. Your editoral suggestions I take note of and
if it is possible to make changes easily will incorporate. You also
suggestion some additions I feel we're past the point of making unless
the community really feels they are necessary.

 One response to your comments below.

Von

Jim Schaad writes (20:56 July 25, 2003):
 > >  > 7.  Section 4.2:  I have a complete lack of understanding 
 > > for the last  > three paragraphs in this section.
 > > 
 > > These paragraphs are addressing whether or not the {extended} 
 > > key usage extensions of it's issuer apply to it. It's really 
 > > ugly because these extensions are really ugly (they are in 
 > > part restrictions and in part capabilities), I'm not sure how 
 > > to clarify this.
 > 
 > Item #1.  Remove all references to key usage and just leave the extended
 > key usage.  For key usage, this text makes absolutely no sense.
 > 
 > Item #2.  I am not sure that I understand the justification for saying
 > the if you are independent, then you get to do anything you want, but if
 > otherwise you are restricted on what you can do.  

The issue that is being addressed here is that when a proxy is created
that inherits some rights from the issuer (i.e., the policyLanguage is
not independent) the {extended}keyUsage in the proxy certificate
should be constrained by the {extended}keyUsage of its issuer - a
proxy issuer shouldn't be able to grant to proxy certificate a right
they don't have.

It is an independent proxy, in which case our thinking is that it is
no longer inheriting any rights from the issuer, so it can be treated
as completely distinct. The issuer no longer matters in regards to
authorization rights for the proxy, so this means the
{extended}keyUsage constrains (which are really authorization) are now
free to be anything the issuer wants.







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S0Kpqt096077 for <[e-mail]>; Sun, 27 Jul 2003 17:20:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6S0Kp9o096076 for ietf-pkix-bks; Sun, 27 Jul 2003 17:20:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hotmail.com (law12-f97.law12.hotmail.com [64.4.19.97]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S0Koqt096069 for <[e-mail]>; Sun, 27 Jul 2003 17:20:50 -0700 (PDT) (envelope-from [e-mail])
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 27 Jul 2003 17:20:48 -0700
Received: from 165.213.1.1 by lw12fd.law12.hotmail.msn.com with HTTP; Mon, 28 Jul 2003 00:20:48 GMT
X-Originating-IP: [165.213.1.1]
X-Originating-Email: [[e-mail]]
From: "bonny joy" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
Date: Mon, 28 Jul 2003 00:20:48 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 28 Jul 2003 00:20:48.0656 (UTC) FILETIME=[18590900:01C3549E]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Steve

The PKUP does operate as you note, but the cert validity period is still 
present, and in the presence of the PKUP extension, this field is 
reinterpreted to state that after the notAfter date, the cert may no longer 
be used to verify any signature, period.  That too is part of the reason for 
not encouraging use of PKUP, i.e., the need to reinterpret the cert validity 
field.



This is my view



The certificate can be used to verify the signature during the certificate 
validity period irrespective of the PKUP  , for this reason certificate 
validity period should be present



The signature should not be generated after or before  the PKUP, since the 
private key validity period is different from the certificate validity 
period , this field should be present



So why does a certificate processing part should get confused by seeing the 
2 fields , those 2 fields are meant for different purposes, First check the 
signature has been created at the valid period ,then check the validity of 
the certificate. In the case of NR the validity of the certificate is not 
having any impact ,since the thrust is on PKUP.





Regards Bonny

_________________________________________________________________
They are beautiful. They are in danger. 
http://server1.msn.co.in/Slideshow/BeautyoftheBeast/index.asp Our 
four-legged friends.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6R8YUqt036981 for <[e-mail]>; Sun, 27 Jul 2003 01:34:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6R8YUxB036980 for ietf-pkix-bks; Sun, 27 Jul 2003 01:34:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6R8YSqt036961 for <[e-mail]>; Sun, 27 Jul 2003 01:34:29 -0700 (PDT) (envelope-from [e-mail])
Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6R8VK104134 for <[e-mail]>; Sun, 27 Jul 2003 10:31:21 +0200
Message-ID: <[e-mail]>
Date: Sun, 27 Jul 2003 10:31:20 +0200
From: Leif Johansson <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The fundamental problem (imo) is that pki confuses the address with the 
name in
the current use of subject and issuer DN. Using multivalued "terminal" 
rdns for
EE is as we all know the result of wanting to have a readable component 
(the name)
along with a unique component (the "address"). The corresponding problem 
has been
cropping up all over the ietf of late (for instance in the recent 
discussion on ipv6
multihoming).

Speaking from the LDAP community my view is that the use of multivalued 
rdn's
is as dead as the Dodo. Get over it.

       Cheers Leif



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6R1hCqt005556 for <[e-mail]>; Sat, 26 Jul 2003 18:43:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6R1hCWN005555 for ietf-pkix-bks; Sat, 26 Jul 2003 18:43:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6R1h9qt005515 for <[e-mail]>; Sat, 26 Jul 2003 18:43:10 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6R1gm4X159394; Sat, 26 Jul 2003 21:42:49 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6R1gcNb051774; Sat, 26 Jul 2003 21:42:38 -0400
To: Stephen Kent <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail] (Peter Gutmann)
MIME-Version: 1.0
Subject: Re: Why is privateKeyUsagePeriod deprecated?
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 26 Jul 2003 21:42:35 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPRs JHEG5JQ5CD, THTO5KLVS6, JHEG5HMLFK, JCHN5K5PG9|March 27, 2003) at 07/26/2003 21:42:48, Serialize complete at 07/26/2003 21:42:48
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        If this is likely to become official, I think the last sentence 
needs more work in order to let RP authors know what they should do, as 
well as what they may.
If the RP requires authoritative proof of the time at which the document 
was signed, it SHOULD reject the signature unless the signature itself is 
referenced by a time-stamped document signed by a certificate which has 
not expired, especially a time stamp created by a TSA (see RFC 3161).  If 
the RP requires authoritative proof of the certificate's not having been 
revoked, it SHOULD NOT consider the absence of an expired certificate from 
a CRL which would otherwise cover it as evidence that the certificate was 
not revoked unless the CRL was issued prior to the expiration of the 
certificate.

                Tom Gindin





Stephen Kent <[e-mail]>
07/25/2003 01:45 PM

 
        To:     [e-mail] (Peter Gutmann)
        cc:     [e-mail], Tom Gindin/Watson/IBM@IBMUS, 
[e-mail], [e-mail]
        Subject:        Re: Why is privateKeyUsagePeriod deprecated?



At 21:02 +1200 7/25/03, Peter Gutmann wrote:
>Tom Gindin <[e-mail]> writes:
>
>   The validity period for a certificate is the period of time from 
notBefore
>   through notAfter, inclusive.  When an RP is validating the signature 
on a
>   document which claims to have been signed or produced at a given past 
time,
>   the RP SHOULD proceed with the verification of the signature if that 
time is
>   within the validity period even though the time of verification is 
outside
>   it. If the RP requires authoritative proof either of the time at which 
the
>   document was signed or of the certificate's not having been revoked, 
it MAY
>   reject the signature.
>
>That works for me.  Russ, any chance of getting this added to 
bride-of-3280?
>
>Peter.

Peter,

Also, when we have SCVP in place, it make explicit provision for 
asking the "was it valid then" question, which would address this 
problem.

Steve





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6Q4flqt008280 for <[e-mail]>; Fri, 25 Jul 2003 21:41:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6Q4flKM008279 for ietf-pkix-bks; Fri, 25 Jul 2003 21:41:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6Q4fjqt008273 for <[e-mail]>; Fri, 25 Jul 2003 21:41:45 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6Q4fUs1026253; Sat, 26 Jul 2003 16:41:30 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6Q4dnk20059; Sat, 26 Jul 2003 16:39:49 +1200
Date: Sat, 26 Jul 2003 16:39:49 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>Also, when we have SCVP in place, it make explicit provision for asking the
>"was it valid then" question, which would address this problem.

Right, but as with timestamping the penetration of this is going to be minimal
enough that it won't help most people who need to do long-term signature
verification, which is why the paragraph would provide useful guidance to
those who don't have TSP/SCVP/etc.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6Q3trqt006675 for <[e-mail]>; Fri, 25 Jul 2003 20:55:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6Q3trla006674 for ietf-pkix-bks; Fri, 25 Jul 2003 20:55:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6Q3tpqt006667 for <[e-mail]>; Fri, 25 Jul 2003 20:55:51 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip197.174-173-207.eli-du.nwlink.com [207.173.174.197]) by smtp2.pacifier.net (Postfix) with ESMTP id 6E83D6B3B1; Fri, 25 Jul 2003 20:55:48 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Von Welch'" <[e-mail]>, <[e-mail]>
Cc: "'pkix'" <[e-mail]>, <[e-mail]>, "'Russ Housley'" <[e-mail]>
Subject: RE: Draft-ietf-pkix-proxy-06.txt
Date: Fri, 25 Jul 2003 20:56:13 -0700
Message-ID: <000001c35329$dead74e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Von,

Comments below.  I was working from what I downloaded before I got on
the plane to fly back, so I was a couple of days out of date, but I just
reviewed the deltas to the -07 version.  I don't see any problems with
added or removed text between -06 and -07.

> -----Original Message-----
> From: Von Welch [mailto:[e-mail]] 
> Sent: Wednesday, July 23, 2003 3:32 PM
>
> Jim,
> 
> Comments below. We released version -07 that crossed your 
> email by the way, but with one exception noted below all your 
> questions still apply.
> 
> Von
> 
> Jim Schaad writes (16:01 July 23, 2003):
>  > 
> 
>  > 3. General:  I am still not comfortable that the issuance 
> of Proxy  > Certificates cannot be restricted (or permitted) 
> by a CA when it issues  > an EEC.  One method of doing this 
> would be a non-critical ProxyCertInfo  > extension with a 
> pCPathLengthConstrant of 0 in the EEC.
> 
> I really dislike your suggested method because that would 
> make the presence of a ProxyCertInfo extension ambiguous - 
> right now it designates a certificate is a proxy certificate. 
> *IF* this is something that people think is critical, I 
> believe another extension should be defined to be placed into 
> an EEC to prohibit it from issuing proxy certificates.

I have no objections to using a different method for dealing with this.
I was just trying to come up with a method that made minimal changes to
the document as it currently stands.  

> 
>  > 4. Section 2.6:  When creating a new PC, where and how is 
> the  > negotiations on policy language and policy done?  
> Should this be  > documented as a separate step in the text 
> describing how PCs are  > obtained/issued?  Does something 
> need to be done about potentially  > asking the relying party 
> as to what policy it requires to perform some  > task?
> 
> Since it is not always possible to even know who all the 
> relying parties potentially are when a proxy certificate is 
> issued it's not really possible to negotiate this. Our view 
> is that the set of polices used in a particular environment 
> will be established out of band in the environment.

I can understand the position that the policyLanguage is going to need
to be fixed by the environment.  I think that some text could be added
here about the fact that generally the ProxyCertExtension would be
filled out by the proxy agent and needs to be checked by the PI. It
might be useful in the steps to be explicit about which entity performs
each step.

> 
>  > 5. Section 3.8.2:  I find the following text
>  > 
>  >     Note that this 
>  >     verification MUST take place regardless of whether or 
> not the PC 
>  >     itself contains a policy, as other PCs in the signing 
> chain MAY 
>  >     contain conditions that MUST be verified. 
>  > 
>  > 	to be confusing because I always get policyLanguage and policy
>  > mixed up.  I think that all PCs must have policy and so 
> the statement is  > difficult to parse.  I don't know that 
> this can be simplified without  > renaming the policy field 
> in the extension.
> 
> I think this statement is from when polices were optional and 
> impersonation was implied otherwise. If it causes real 
> heartburn I believe it can be removed at this point as it 
> doesn't add anything.

Yes, I would like this sentence removed because it is not helpful.

> 
>  >  The text in item 1) just
>  > before this refers to policy and should probably refer to
>  > policyLanguage.
> 
> I don't think this would be correct - as understanding the 
> policy implies understanding the policy language in which it 
> is written, so the change doesn't add anything, and a relying 
> party need to understand not just the language, but the policy itself.

How about changing " interpret the policy " to "interpret the proxy
policy" in item #1
> 
>  > 7.  Section 4.2:  I have a complete lack of understanding 
> for the last  > three paragraphs in this section.
> 
> These paragraphs are addressing whether or not the {extended} 
> key usage extensions of it's issuer apply to it. It's really 
> ugly because these extensions are really ugly (they are in 
> part restrictions and in part capabilities), I'm not sure how 
> to clarify this.

Item #1.  Remove all references to key usage and just leave the extended
key usage.  For key usage, this text makes absolutely no sense.

Item #2.  I am not sure that I understand the justification for saying
the if you are independent, then you get to do anything you want, but if
otherwise you are restricted on what you can do.  

> 
> 
>  > 9.  
>  > 
> 
> Is there more that should appear here?

I don't see any item #9 based on a fast scan of the document.  I think I
just missed clearing this out since I did not add a signature to the end
of the message either.

> 
> - end comments -
> 

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PNnEqt096555 for <[e-mail]>; Fri, 25 Jul 2003 16:49:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PNnELD096554 for ietf-pkix-bks; Fri, 25 Jul 2003 16:49:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com ([213.199.128.160]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PNnCqt096549 for <[e-mail]>; Fri, 25 Jul 2003 16:49:12 -0700 (PDT) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 26 Jul 2003 00:49:13 +0100
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 26 Jul 2003 00:49:13 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 26 Jul 2003 00:49:13 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-01.txt
Date: Sat, 26 Jul 2003 00:48:56 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-sonof3039-01.txt
Thread-Index: AcNS7IMBdH3O3gUAQj6LkFPIOmkr1QAF3OvA
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 25 Jul 2003 23:49:13.0159 (UTC) FILETIME=[59B7A570:01C35307]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6PNnDqt096550
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

As reminder for you who were in Vienna, and as info for those who
weren't, here is what is changed from draft 0.

1) postalAddress has been removed from the list of subject naming
attributes that must be understood as part of the subjects identity.

The reasons are mainly to align with RFC 3280 who doesn't support
postalAddress. To my knowledge there are further no use of this
attribute in the context of RFC 3039 that would motivate its presence
there despite its structure and non-support by RFC 3280.

2) Text concerning key usage has been further clarified. The old RFC
3039 requirement on having NR exclusive when set (SHOULD requirement)
was removed in draft 00. Even though that requirement may be reasonable
in many cases, there is no context in RFC 3039 where this could be
generally stated. The ongoing profiling work in ETSI aims at including
this requirement in the ETSI Qualified Certificates profile where there
IS a context for its definition.

3) text describing the scope of the qcStatements extension has been
updated with a more generic wording.

If anyone needs, I can send a comparison document, showing the exact
changes.

Open issues (except feedback on changes above):
Should the removal of postalAddress from the listed attributes (MUST
implement) in the subject filed could motivate a version number update
in the predefined compliance declaration in the qcStatements extension.

I have not done that update because a) I'm not sure it is needed, and b)
I'm not sure whether that declaration is even used by anyone.


This work is synchronized with the ongoing efforts in ETSI. In order to
keep the time table in ETSI (ready by febr 04) I would stress that the
ambition is to be ready for WG last call by Minneapolis. So please,
those who care about this work, be active now and don't wait until WG
last call :-)


/Stefan



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: den 25 juli 2003 21:29
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-01.txt

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:Qualified 
                          Certificates Profile
	Author(s)	: S. Santesson, M. Nystrom
	Filename	: draft-ietf-pkix-sonof3039-01.txt
	Pages		: 35
	Date		: 2003-7-25
	
This document forms a certificate profile, based on RFC 3280, for
dentity certificates issued to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements.  The profile is however designed to
allow further profiling in order to meet specific local needs.
The profile defines specific conventions for certificates that are
qualified within a defined legal framework, named Qualified
Certificates. The profile does however not define any legal
requirements for such Qualified Certificates.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-sonof3039-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.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PLWQqt088423 for <[e-mail]>; Fri, 25 Jul 2003 14:32:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PLWQsa088422 for ietf-pkix-bks; Fri, 25 Jul 2003 14:32:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PLWPqt088417 for <[e-mail]>; Fri, 25 Jul 2003 14:32:25 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19g9UH-0001uQ-C2; Fri, 25 Jul 2003 16:48:25 -0400
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, <[e-mail]>
Subject: Document Action: 'Internet X.509 Public Key  Infrastructure Certificate Policy and Certification Practices  Framework' to an Informational RFC 
Message-Id: <[e-mail]>
Date: Fri, 25 Jul 2003 16:48:25 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Internet X.509 Public Key 
Infrastructure Certificate Policy and Certification Practices Framework' 
<draft-ietf-pkix-ipki-new-rfc2527-02.txt> as an Informational RFC. This 
document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact person is Housley, Russ.

Thank you,

The IESG Secretary




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PJSjqt080698 for <[e-mail]>; Fri, 25 Jul 2003 12:28:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PJSjrA080697 for ietf-pkix-bks; Fri, 25 Jul 2003 12:28:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PJSiqt080689 for <[e-mail]>; Fri, 25 Jul 2003 12:28:44 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17906; Fri, 25 Jul 2003 15:28:41 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dnstrings-02.txt
Date: Fri, 25 Jul 2003 15:28:41 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: LDAPv3 DN strings for use with PKIs
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-dnstrings-02.txt
	Pages		: 0
	Date		: 2003-7-25
	
RFC 2253 [2] standardises a set of strings that can be used to 
represent attribute types in LDAP distinguished names. This list is 
does not cover the full set of attribute types used in the 
distinguished names of issuers and subjects in public key 
certificates. This document standardises the strings needed for these 
additional attribute types. It also defines the Permanent Identifier 
attribute type which may be used to identify objects.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dnstrings-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PJSgqt080684 for <[e-mail]>; Fri, 25 Jul 2003 12:28:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PJSgqw080683 for ietf-pkix-bks; Fri, 25 Jul 2003 12:28:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PJSeqt080673 for <[e-mail]>; Fri, 25 Jul 2003 12:28:41 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17890; Fri, 25 Jul 2003 15:28:37 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-01.txt
Date: Fri, 25 Jul 2003 15:28:37 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure:Qualified 
                          Certificates Profile
	Author(s)	: S. Santesson, M. Nystrom
	Filename	: draft-ietf-pkix-sonof3039-01.txt
	Pages		: 35
	Date		: 2003-7-25
	
This document forms a certificate profile, based on RFC 3280, for
dentity certificates issued to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements.  The profile is however designed to
allow further profiling in order to meet specific local needs.
The profile defines specific conventions for certificates that are
qualified within a defined legal framework, named Qualified
Certificates. The profile does however not define any legal
requirements for such Qualified Certificates.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-sonof3039-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHmuqt073701 for <[e-mail]>; Fri, 25 Jul 2003 10:48:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PHmu01073700 for ietf-pkix-bks; Fri, 25 Jul 2003 10:48:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHmtqt073694 for <[e-mail]>; Fri, 25 Jul 2003 10:48:55 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6PHmcDB004801; Fri, 25 Jul 2003 13:48:41 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060bbb471d1f9745@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 25 Jul 2003 13:45:54 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 21:02 +1200 7/25/03, Peter Gutmann wrote:
>Tom Gindin <[e-mail]> writes:
>
>   The validity period for a certificate is the period of time from notBefore
>   through notAfter, inclusive.  When an RP is validating the signature on a
>   document which claims to have been signed or produced at a given past time,
>   the RP SHOULD proceed with the verification of the signature if that time is
>   within the validity period even though the time of verification is outside
>   it. If the RP requires authoritative proof either of the time at which the
>   document was signed or of the certificate's not having been revoked, it MAY
>   reject the signature.
>
>That works for me.  Russ, any chance of getting this added to bride-of-3280?
>
>Peter.

Peter,

Also, when we have SCVP in place, it make explicit provision for 
asking the "was it valid then" question, which would address this 
problem.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHmiqt073692 for <[e-mail]>; Fri, 25 Jul 2003 10:48:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PHmiMq073691 for ietf-pkix-bks; Fri, 25 Jul 2003 10:48:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHmhqt073679 for <[e-mail]>; Fri, 25 Jul 2003 10:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6PHmcD9004801; Fri, 25 Jul 2003 13:48:39 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060abb471c9075b7@[128.89.89.75]>
In-Reply-To:  <[e-mail].k r>
References:  <[e-mail].k r>
Date: Fri, 25 Jul 2003 13:44:51 -0400
To: bonny <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1152967151==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

At 12:25 +0900 7/25/03, bonny wrote:
>Dear Steve
>
>
>
>The following are my comments for your views
>
>
>
>only in the context of post facto evaluation for NR purposes is it
>
>likely to be applicable
>
>
>
>Yeah I agreed to this
>
>
>
>
>
>
>
>it embodies the notion that we can declare that a signature
>
>generated with a private key expires at a future date, relative to 
>NR concerns. this is not a good match for many real world contexts 
>on which NR is an issue,e.g., my wet signature does not expire 
>although an agreement may have a limited lifespan.
>
>
>
>
>
>
>
>With the PKUP field we r assuring that the signatures should only be 
>created within the validity period of the private key.That doesn't 
>mean the signatures are not valid after the validity of the period.
>
>
>
>So how does PKUP creates the notion , we can declare that a signature
>
>generated with a private key expires at a future date.It only 
>suggests that no more signatures cant be generated.
>

The PKUP does operate as you note, but the cert validity period is 
still present, and in the presence of the PKUP extension, this field 
is reinterpreted to state that after the notAfter date, the cert may 
no longer be used to verify any signature, period.  That too is part 
of the reason for not encouraging use of PKUP, i.e., the need to 
reinterpret the cert validity field.

Steve
--============_-1152967151==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: Re: Why is privateKeyUsagePeriod
deprecated?</title></head><body>
<div>At 12:25 +0900 7/25/03, bonny wrote:</div>
<blockquote type="cite" cite><font face="Courier New" size="-1">Dear
Steve</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">The
following are my comments for your views</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1"><i>only</i></font><i> in the context of post facto
evaluation for NR purposes is it</i><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1"><i>likely</i></font><i> to be applicable</i><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">Yeah I
agreed to this</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1"><i>it</i></font><i> embodies the notion that we can declare
that a signature</i><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1"><i>generated</i></font><i> with a private key expires at a
future date, relative to NR concerns. this is not a good match for
many real world contexts on which NR is an issue,e.g., my wet
signature does not expire although an agreement may have a limited
lifespan.</i><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">With
the PKUP field we r assuring that the signatures should only be
created within the validity period of the private key.That doesn't
mean the signatures are not valid after the validity of the
period.</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">So how
does PKUP creates the notion , we can declare that a
signature</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">generated</font> with a private key expires at a future
date.It only suggests that no more signatures cant be generated.<br>
</blockquote>
<div><font face="Courier New" size="-1"><br></font></div>
<div>The PKUP does operate as you note, but the cert validity period
is still present, and in the presence of the PKUP extension, this
field is reinterpreted to state that after the notAfter date, the cert
may no longer be used to verify any signature, period.&nbsp; That too
is part of the reason for not encouraging use of PKUP, i.e., the need
to reinterpret the cert validity field.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1152967151==_ma============--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHYaqt073221 for <[e-mail]>; Fri, 25 Jul 2003 10:34:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PHYanQ073220 for ietf-pkix-bks; Fri, 25 Jul 2003 10:34:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr5.us.db.com (imr5.us.db.com [160.83.65.196]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHYZqt073215 for <[e-mail]>; Fri, 25 Jul 2003 10:34:36 -0700 (PDT) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr5.us.db.com  id h6PHYZ8i029432; Fri, 25 Jul 2003 13:34:36 -0400 (EDT)
Subject: draft-ietf-pkix-scvp-12.txt
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Fri, 25 Jul 2003 13:34:32 -0400
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.9a |January 7, 2002) at 07/25/2003 01:34:36 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I reviewed draft-ietf-pkix-scvp-12.txt and have the following comments, many of which are typos related to earlier draft changes. The following numbering scheme is used:

section[/paragraph[/sentence]]

general comment: scope of extensions

CVRequest's reqExtensions and CVResponse's respExtensions pertain to the entire request and response.

A CVRequest has one Query containing queryExtensions. So queryExtensions really pertain to the entire request (not to an individual queriedCerts item), yet a CVResponse may have many certReplyExtensions elements (not certReplyExtensions items), each of which pertains to a CertReply (not the entire response). [Take deep breath.] One might describe this as an impedance mismatch. BTW, this characteristic goes back to early drafts.

One possible "solution" would be to add a type named something like CertRequest and move queryExtensions from Query to CertRequest. For example:

Query ::= SEQUENCE {
    queriedCerts        SEQUENCE SIZE (1..MAX) OF CertRequest, -- Was CertReference.
    ...
    revInfos        [5] RevocationInfos OPTIONAL
    -- queryExtensions was moved to CertRequest.
}

CertRequest ::= SEQUENCE {
    certReference             CertReference,
    certRequestExtensions [1] Extensions OPTIONAL -- Was Query's queryExtensions.
}

I think I got that right.

1.3/2/3 nit: I would insert "are" before "likely".

3/1 "SCVPRequest" should be "CVRequest".

3/3/1 I think I understand the use of certValRequest, but because it is not defined, it might confuse some readers.

For me, the following ContentInfo adds confusion, not clarity:

ContentInfo {
    contentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10)
    content     CVRequest }

As page 6 shows ContentInfo containing SignedData (or AuthenticatedData) containing EncapsulatedContentInfo containing OCTET STRING containing CVRequest, which is very clear, but a little different. For reference, RFC 2630 says:

ContentInfo ::= SEQUENCE {
    contentType          ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType
}

EncapsulatedContentInfo ::= SEQUENCE {
    eContentType          ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL
}

This comment also applies to section 4.

3.2/2 nit: CertChecks and WantBack defintions (unnecessary level of indirection)

Because CertChecks and WantBack only appear one time in the ASN.1 module, why not just put SEQUENCE ... OF ... in Query. This is how Query's queriedCerts is defined.

3.2/2: The body of the document shows Query's valPolicy element as mandatory, yet the ASN.1 module (section 8) shows the element as OPTIONAL.

3.2.1 nit: lots of CHOICEs

CertReference's use of three CHOICEs is a lot of work. How about:

CertReference ::= CHOICE {
    cert     [1] Certificate,
    pkcRef   [2] ESSCertID,
    attrCert [3] AttributeCertificate,
    acRef    [4] ESSCertID
}

RevocationInfo uses this technique for two types of CLRs.

3.2.2/2 clarity

I do not understand "Revocation status checking inherently includes ..." Does this mean path validation includes path building, and revocation status checking includes path building and path validation? I believe that revocation status checking is a superset of path validation is a superset of path building. This needs to be "spelled out" very clearly.

3.2.3/1 clarity

If I understand this correctly, you might want to add that each wantBack item applies to all queriedCerts items.

3.2.5.1/1/2 typo: "use to" should be "to" or "to use to".

3.2.5.1/2 typo: KeyPurposeID should be KeyPurposeId (note case).

3.2.5.1/3/1: typo: "sting" should be "string".

3.2.5.2/2/1: typo: "Name mismatch" should be "NameMismatch".

3.2.5.2/4: typo: "KeyPurposeID" should be KeyPurposeId".

3.2.5.2/5: typo: "and empty" should be "an empty".

3.2.6/1/3: typo: "the using" should be "the checks using".

3.2.6/2: nit: "expressed Greenwich" should be "expressed in Greenwich".

This comment also applies to section 4.2.

3.2.7/3 inclusion of trust anchor in response

I am surprised that the certifiation path MUST NOT include the trust anchor. I recognize the efficiency of this, but am concerned about the ability to audit a system using this technique.

If a client sends more than one trust anchor in its request, how easy is it for an auditor to determine which trust anchor was used? I would expect the server to send the client a path which includes the trust anchor and for the client to log the "complete" path. Am I missing something?

3.2.10/1/5 typo: "and each of extension" should read "and each extension".

4.3 What is the difference between badSignature and invalidSignature?

Status code 12 is not described. The description of status code 23 includes the no-longer-used type RequestSignature.

4.4 The heading "requestReference" should be "requestRef".

4.4.1

Why define HashValue when lots of developers already have implementations of PKCS #1 DigestInfo?

4.4.2/2 typo: "PSRequest" should be "CVRequest".

4.5 typo: The heading "Requestor" should be "requestor".

4.7/2/1 nit: "for each queriedCerts item" might be clearer than "for each Query item".

4.7.5 The heading "replyWantBack" should be "replyWantBacks". This also occurs in the first paragraph.

4.7.6 confusion

If a server uses the default validation policy, how can it comply with the following:

"The valPolicy value MUST NOT be id-svp-defaultValPolicy."

CertReply's valPolicy is mandatory.

4.7.8/1/2 typo: "singleReplyExtensions" should be "certReplyExtensions".

8 The ASN.1 module needs to import CertificateList and OCSPResponse -- I validated it using a compiler.

Appendix B nit: Does not include descriptions for validation policies request and response.

Frank


--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHNtqt072908 for <[e-mail]>; Fri, 25 Jul 2003 10:23:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PHNtOl072907 for ietf-pkix-bks; Fri, 25 Jul 2003 10:23:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PHNsqt072902 for <[e-mail]>; Fri, 25 Jul 2003 10:23:54 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6PHNcD9003067; Fri, 25 Jul 2003 13:23:38 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210605bb471140cee9@[128.89.89.75]>
In-Reply-To:  <[e-mail] v.microsoft.com>
References:  <[e-mail] v.microsoft.com>
Date: Fri, 25 Jul 2003 13:20:13 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: <[e-mail]>, Michael =?iso-8859-1?Q?Str=F6der?=  <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 15:02 -0700 7/24/03, Trevor Freeman wrote:
>Hi Steve,
>First off, I am simply providing feedback as to what people do in 
>real deployments. So far the deployments I have seen are effective 
>at meeting the needs of the organisations without braking existing 
>applications. Personally I am mystified as to how adding an 
>arbitrary number to a name helps a user. Every time I have seen an 
>example of such a multi-valued RDN, they look pretty ugly to me. To 
>be widely adopted, a standard has to be a realistic solution to the 
>problem at hand.
>
>Trevor
>
We obviously have different experiences.  For example, the DoD PKI 
decided to avoid a terminal RDN SET and as a result the CN is of the 
form "John Smith 123457678901" which qualifies as ugly in my book. 
An organization typically identifies employees/students/members by 
name and ID number, which maps naturally to a terminal RDN set of CN 
+ Serial #.

I don't understand your comment: "Personally I am mystified as to how 
adding an arbitrary number to a name helps a user." The issue is that 
organizations make user names unique by assigning such numbers, and 
have for decades. Thus if we are to minimize the impact on an 
organization's existing naming practices, we need to be able to 
accommodate names that have these two components.  For users, the 
goal is to make the name presented to them as natural as possible. 
Separating the two components using the appropriate attributes 
provides an application with opportunities to do this, whereas gluing 
the two attributes together into the CN makes that very hard, since 
it may not be easy to determine where the real common name ends and 
the ID number or equivalent string, starts.

So, from my perspective, a terminal RDN SET is precisely a realistic 
solution to the problem at hand, except for the refusal of at least 
one major vendor to follow standards and support this solution.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P9kPqt029478 for <[e-mail]>; Fri, 25 Jul 2003 02:46:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6P9kPFY029477 for ietf-pkix-bks; Fri, 25 Jul 2003 02:46:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P9kMqt029430 for <[e-mail]>; Fri, 25 Jul 2003 02:46:23 -0700 (PDT) (envelope-from [e-mail])
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by fw.chttl.com.tw (8.12.9/8.11.6) with ESMTP id h6P9jOe7020340; Fri, 25 Jul 2003 17:45:24 +0800 (CST)
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h6P9kANq003283; Fri, 25 Jul 2003 17:46:10 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h6P9k8XJ003157; Fri, 25 Jul 2003 17:46:09 +0800
Message-ID: <013201c35291$7f8935a0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Masaki SHIMAOKA" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Fri, 25 Jul 2003 17:45:35 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> 1. path building over http
> 
[snip]
> IMHO, path building over http may be achieved using cAIssuers
> accessMethod in AIA extension, but it only describes single path like
> strict hierarchy.
Not exactly so, if we let caIssuers accessMethod be a HTTP URI points
to a PKCS#7 wrapped certificate list which contains all cross-certificates
issued to the issuer of the nominated certificate, there is no problem to
traverse the whole cross-certification network. However, AIA-assisted
path building only supports forward direction (I mean "from the target
certificate to a trusted root" as defined by the draft.).

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P933qt023869 for <[e-mail]>; Fri, 25 Jul 2003 02:03:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6P933HX023868 for ietf-pkix-bks; Fri, 25 Jul 2003 02:03:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P931qt023847 for <[e-mail]>; Fri, 25 Jul 2003 02:03:02 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6P92hs1010958; Fri, 25 Jul 2003 21:02:43 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6P92b815373; Fri, 25 Jul 2003 21:02:37 +1200
Date: Fri, 25 Jul 2003 21:02:37 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Gindin <[e-mail]> writes:

  The validity period for a certificate is the period of time from notBefore
  through notAfter, inclusive.  When an RP is validating the signature on a
  document which claims to have been signed or produced at a given past time,
  the RP SHOULD proceed with the verification of the signature if that time is
  within the validity period even though the time of verification is outside
  it. If the RP requires authoritative proof either of the time at which the
  document was signed or of the certificate's not having been revoked, it MAY
  reject the signature.

That works for me.  Russ, any chance of getting this added to bride-of-3280?

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P7g9qt012800 for <[e-mail]>; Fri, 25 Jul 2003 00:42:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6P7g8ad012799 for ietf-pkix-bks; Fri, 25 Jul 2003 00:42:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6P7g6qt012789 for <[e-mail]>; Fri, 25 Jul 2003 00:42:07 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6P7g0s1009528; Fri, 25 Jul 2003 19:42:00 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6P7g0014851; Fri, 25 Jul 2003 19:42:00 +1200
Date: Fri, 25 Jul 2003 19:42:00 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Trevor Freeman" <[e-mail]> writes:

>The scope for applications not doing the right thing in the presence of a
>multi-valued RDN is pretty big. Fore example, there is a large body of
>applications who extract subsets of data from the DN such as only using the
>common name in UI which will ignore subsequent values of the RDN. 

Yup, that's what I've found too, which is why I sent my earlier "Don't do
that, then" response to Michael Stroeder.  I haven't exhaustively enumerated
all the different behaviours, which app does what, and which version of which
app does what, but it ranges from ignoring everything but a small fixed set of
DN components (C, O, OU, locality, state, and obviously DN) to accepting most
components but not allowing duplicates (e.g. 2 x OU) to accepting dups but not
multi-valued AVAs.  Then the definition of "accept" varies from reading and
discarding (writing it out again removes the value), reading but ignoring
(writing retains the value), displaying or not displaying, etc etc etc.  This
is why, in writeups I've done like "PKI: Not dead just resting" I recommend
that for maximum usability people treat DNs as random blobs and don't try and
do anything fancy with them.  The further you depart from that, the more pain
you're in for.

>Therefore Microsoft's lack of support for multi-valued RDN with AD is the tip
>of the iceberg and anyone insisting on using them will have a lot of
>regression testing to perform. 

Exactly.  The range of options runs from the simplest possible DNs (C, O, OU,
etc) treated as blobs through to complex DNs, multi-AVA RDNs, etc etc, and
then relying on each component to work properly, with a corresponding increase
in pain level from 0 to infinity along the same scale.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OMvkqt080632 for <[e-mail]>; Thu, 24 Jul 2003 15:57:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OMvkPA080631 for ietf-pkix-bks; Thu, 24 Jul 2003 15:57:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OMviqt080625 for <[e-mail]>; Thu, 24 Jul 2003 15:57:44 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id h6OMvfO15724; Thu, 24 Jul 2003 16:57:41 -0600 (MDT)
From: [e-mail]
Received: from DL21064 (slip-32-102-122-152.ut.us.prserv.net [32.102.122.152]) (authenticated bits=0) by smtp.digsigtrust.com (8.12.6/8.12.6) with ESMTP id h6OMs2I4022659; Thu, 24 Jul 2003 16:54:03 -0600 (MDT)
Message-ID: <003301c35236$fb14c5a0$987a6620@DL21064>
To: "Stephen Kent" <[e-mail]>
Cc: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, <[e-mail]>
References: <p05210600bb44d06f5e06@[128.89.89.40]> <[e-mail]> <008301c35203$8f684260$9409e00a@DL21064> <[e-mail]> <00d501c35214$e1ae83c0$9409e00a@DL21064> <p05210602bb45fd229e66@[128.89.89.75]>
Subject: Re: Microsoft and multi-valued RDNs
Date: Thu, 24 Jul 2003 16:57:31 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,
I was just trying to understand things, It wasn't clear form the minute what
was the issue give that I wasn't at the meeting.
cheers
RFW

----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: <[e-mail]>
Cc: "Michael Ströder" <[e-mail]>; <[e-mail]>
Sent: Thursday, July 24, 2003 3:17 PM
Subject: Re: Microsoft and multi-valued RDNs


>
> At 12:53 -0600 7/24/03, [e-mail] wrote:
> >Ah but it is on the directory side of things when we create the directory
> >entry the 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709 is
a
> >multi name attribute.  I can either search for Russel F Weiser and get
> >multiple entries for Russel F Weiser. Or if I formulation the LDAP search
as
> >0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709+CN = Russel
F
> >Weiser
> >I will get that exact entry only.
> >I am just trying to understand what the discussion was about.
> >Several years ago when I was looking at all this I tried to get CAs to
> >create DNs that were Mutlivalued RDNs but none of the CAs would do this.
So
> >I just made the directory do it when we published the certificate into
the
> >directory.
> >This allowed me to perform name uniqueness without searching the
directory
> >prior to signing a certificate.
> >cheers
> >RFW
> >
>
> The discussion is not about multiple names for a directory entry, but
> multiple attributes within a SET within a DN, especially the terminal
> RDN.
>
> Steve
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OM2Lqt076192 for <[e-mail]>; Thu, 24 Jul 2003 15:02:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OM2L8Q076191 for ietf-pkix-bks; Thu, 24 Jul 2003 15:02:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OM2Kqt076185 for <[e-mail]>; Thu, 24 Jul 2003 15:02:20 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jul 2003 15:02:17 -0700
Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Jul 2003 15:02:17 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jul 2003 15:02:16 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 15:02:16 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 15:02:15 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 24 Jul 2003 15:02:38 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Microsoft and multi-valued RDNs (was: draft minutes)
Thread-Index: AcNSKiSynk/MZ3JPRASCF7+lIkZ47QAAtOwg
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Jul 2003 22:02:15.0421 (UTC) FILETIME=[3E08CAD0:01C3522F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6OM2Kqt076187
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Steve,
First off, I am simply providing feedback as to what people do in real deployments. So far the deployments I have seen are effective at meeting the needs of the organisations without braking existing applications. Personally I am mystified as to how adding an arbitrary number to a name helps a user. Every time I have seen an example of such a multi-valued RDN, they look pretty ugly to me. To be widely adopted, a standard has to be a realistic solution to the problem at hand.

Trevor

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Thursday, July 24, 2003 2:20 PM
To: Trevor Freeman
Cc: [e-mail]; Michael Ströder; [e-mail]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)

At 13:40 -0700 7/24/03, Trevor Freeman wrote:
>Yes there is a difference between a DN with multiple RDNs which is 
>what you depict and an individual RDN having multiple values. Most 
>commonly used applications like SSL and SMIME don't use the DN but 
>used other name types such as DNS or email so the presence of 
>multi-valued RDNs is benign.
>
>IE is a case in point where it only processes a single value (the 
>common name) from the DN and only then if there is no DNS name in 
>the subject alt name. Therefore I can readily believe in that case, 
>no problem was found when testing with multi-valued RDN's.
>
>The scope for applications not doing the right thing in the presence 
>of a multi-valued RDN is pretty big. Fore example, there is a large 
>body of applications who extract subsets of data from the DN such as 
>only using the common name in UI which will ignore subsequent values 
>of the RDN. Therefore Microsoft's lack of support for multi-valued 
>RDN with AD is the tip of the iceberg and anyone insisting on using 
>them will have a lot of regression testing to perform. This is why 
>typically the more pragmatic solution is to simply append some data 
>to the sting used for the common name to make the CN unique.
>
>Trevor
>

Trevor,

I appreciate the clarification, but I am appalled by the suggestion 
that people should construct ungainly CNs that will be hard for users 
to parse, or that LDAP schema should be skewed to accommodate this 
lack of standards compliance.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLODqt073817 for <[e-mail]>; Thu, 24 Jul 2003 14:24:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OLOCmt073816 for ietf-pkix-bks; Thu, 24 Jul 2003 14:24:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLOBqt073811 for <[e-mail]>; Thu, 24 Jul 2003 14:24:11 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6OLO8D9005737; Thu, 24 Jul 2003 17:24:08 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210603bb45fda9bde1@[128.89.89.75]>
In-Reply-To:  <[e-mail] v.microsoft.com>
References:  <[e-mail] v.microsoft.com>
Date: Thu, 24 Jul 2003 17:20:12 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: <[e-mail]>, Michael =?iso-8859-1?Q?Str=F6der?=  <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 13:40 -0700 7/24/03, Trevor Freeman wrote:
>Yes there is a difference between a DN with multiple RDNs which is 
>what you depict and an individual RDN having multiple values. Most 
>commonly used applications like SSL and SMIME don't use the DN but 
>used other name types such as DNS or email so the presence of 
>multi-valued RDNs is benign.
>
>IE is a case in point where it only processes a single value (the 
>common name) from the DN and only then if there is no DNS name in 
>the subject alt name. Therefore I can readily believe in that case, 
>no problem was found when testing with multi-valued RDN's.
>
>The scope for applications not doing the right thing in the presence 
>of a multi-valued RDN is pretty big. Fore example, there is a large 
>body of applications who extract subsets of data from the DN such as 
>only using the common name in UI which will ignore subsequent values 
>of the RDN. Therefore Microsoft's lack of support for multi-valued 
>RDN with AD is the tip of the iceberg and anyone insisting on using 
>them will have a lot of regression testing to perform. This is why 
>typically the more pragmatic solution is to simply append some data 
>to the sting used for the common name to make the CN unique.
>
>Trevor
>

Trevor,

I appreciate the clarification, but I am appalled by the suggestion 
that people should construct ungainly CNs that will be hard for users 
to parse, or that LDAP schema should be skewed to accommodate this 
lack of standards compliance.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLJbqt073697 for <[e-mail]>; Thu, 24 Jul 2003 14:19:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OLJblL073696 for ietf-pkix-bks; Thu, 24 Jul 2003 14:19:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OLJaqt073690 for <[e-mail]>; Thu, 24 Jul 2003 14:19:36 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6OLJLDB005416; Thu, 24 Jul 2003 17:19:22 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210602bb45fd229e66@[128.89.89.75]>
In-Reply-To: <00d501c35214$e1ae83c0$9409e00a@DL21064>
References: <p05210600bb44d06f5e06@[128.89.89.40]> <[e-mail]> <008301c35203$8f684260$9409e00a@DL21064> <[e-mail]> <00d501c35214$e1ae83c0$9409e00a@DL21064>
Date: Thu, 24 Jul 2003 17:17:20 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs
Cc: Michael =?iso-8859-1?Q?Str=F6der?=  <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:53 -0600 7/24/03, [e-mail] wrote:
>Ah but it is on the directory side of things when we create the directory
>entry the 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709 is a
>multi name attribute.  I can either search for Russel F Weiser and get
>multiple entries for Russel F Weiser. Or if I formulation the LDAP search as
>0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709+CN = Russel F
>Weiser
>I will get that exact entry only.
>I am just trying to understand what the discussion was about.
>Several years ago when I was looking at all this I tried to get CAs to
>create DNs that were Mutlivalued RDNs but none of the CAs would do this. So
>I just made the directory do it when we published the certificate into the
>directory.
>This allowed me to perform name uniqueness without searching the directory
>prior to signing a certificate.
>cheers
>RFW
>

The discussion is not about multiple names for a directory entry, but 
multiple attributes within a SET within a DN, especially the terminal 
RDN.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OKexqt072149 for <[e-mail]>; Thu, 24 Jul 2003 13:40:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OKex6G072148 for ietf-pkix-bks; Thu, 24 Jul 2003 13:40:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OKewqt072141 for <[e-mail]>; Thu, 24 Jul 2003 13:40:58 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jul 2003 13:40:54 -0700
Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Jul 2003 13:40:53 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jul 2003 13:40:19 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 13:40:12 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 13:40:06 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 24 Jul 2003 13:40:28 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Microsoft and multi-valued RDNs (was: draft minutes)
Thread-Index: AcNSD0pI+DlWqC6KReOcJxBURQHrkAAAUyuQ
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Jul 2003 20:40:06.0903 (UTC) FILETIME=[C468A070:01C35223]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6OKewqt072144
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes there is a difference between a DN with multiple RDNs which is what you depict and an individual RDN having multiple values. Most commonly used applications like SSL and SMIME don't use the DN but used other name types such as DNS or email so the presence of multi-valued RDNs is benign. 

IE is a case in point where it only processes a single value (the common name) from the DN and only then if there is no DNS name in the subject alt name. Therefore I can readily believe in that case, no problem was found when testing with multi-valued RDN's.

The scope for applications not doing the right thing in the presence of a multi-valued RDN is pretty big. Fore example, there is a large body of applications who extract subsets of data from the DN such as only using the common name in UI which will ignore subsequent values of the RDN. Therefore Microsoft's lack of support for multi-valued RDN with AD is the tip of the iceberg and anyone insisting on using them will have a lot of regression testing to perform. This is why typically the more pragmatic solution is to simply append some data to the sting used for the common name to make the CN unique.

Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, July 24, 2003 9:15 AM
To: Michael Ströder; [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)


Stephen Kent,
DST has been useing a multivalued RDN in EndEntity certificates for a number
of PKIs and since 1999 when we started issuing certificates.  We only do
this for End Entities not servers.  Basically the certificate SubDN looks
like the following.

0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709,E =
[e-mail], CN = Russel F Weiser,O = TrustID personal
certificate,C = US

We have used this with numerous and integrated with many applications.
So is the issue that microsoft Active Directory will not support multivalued
RDNs  or that there Applications don't ?? I'm just trying to understand the
issue more clearly.

----- Original Message ----- 
From: "Michael Ströder" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, July 24, 2003 3:47 AM
Subject: Microsoft and multi-valued RDNs (was: draft minutes)


>
> Stephen Kent wrote:
> >
> > LDAP Documents:
>  > [..]
> > Biggest issue on the table for the schema document is that
> > Microsoft says it will not support multi-valued attributes (e.g., a
> > terminal RDN that is a set consisting of a common name and a serial
> > number).
>
> Could someone please elaborate on this?
>
> One of my customers is planning to use exactly this naming scheme with
> multi-valued RDNs in a rather large PKI deployment and so we're scared
about
> interoperability issues.
>
> Ciao, Michael.
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OJCWqt066782 for <[e-mail]>; Thu, 24 Jul 2003 12:12:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OJCW4c066781 for ietf-pkix-bks; Thu, 24 Jul 2003 12:12:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from jcmwsm02.mwjc.easylink.com (jcmwsm02a.mwjc.easylink.com [165.251.41.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OJCUqt066773 for <[e-mail]>; Thu, 24 Jul 2003 12:12:31 -0700 (PDT) (envelope-from [e-mail])
Received: from mwsc0229.mw4.mailwatch.com (mwsmout-vip-1.mwjc.easylink.com [165.251.41.105]) by jcmwsm02.mwjc.easylink.com (8.12.9/8.12.9) with ESMTP id h6OJCQhI019610 for <[e-mail]>; Thu, 24 Jul 2003 15:12:26 -0400 (EDT)
Received: from mail pickup service by mwsc0229.mw4.mailwatch.com with Microsoft SMTPSVC; Thu, 24 Jul 2003 15:12:25 -0400
Received: from mail pickup service by mwsc0229.mw4.mailwatch.com with Microsoft SMTPSVC; Thu, 24 Jul 2003 13:29:42 -0400
Received: from 204.253.83.39 ([204.253.83.39]) by MWSC0229 with SMTP id 0002001daaca8761-98a4-48da-ac6a-7b868a56cfc2; Thu, 24 Jul 2003 13:29:41 -0500
Received: from above.proper.com (above.proper.com [208.184.76.39]) by dymwsm15.mailwatch.com (8.12.9/8.12.9) with ESMTP id h6OHTfVF010390; Thu, 24 Jul 2003 13:29:41 -0400
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OGnfqt058950 for <[e-mail]>; Thu, 24 Jul 2003 09:49:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OGnfL9058949 for ietf-pkix-bks; Thu, 24 Jul 2003 09:49:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OGneqt058943 for <[e-mail]>; Thu, 24 Jul 2003 09:49:40 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id h6OGnZO09351; Thu, 24 Jul 2003 10:49:35 -0600 (MDT)
From: [e-mail]
Received: from DL21064 (host192-35-174-247.digsigtrust.com [192.35.174.247]) (authenticated bits=0) by smtp.digsigtrust.com (8.12.6/8.12.6) with ESMTP id h6OGjwI4017894; Thu, 24 Jul 2003 10:45:58 -0600 (MDT)
Message-ID: <008301c35203$8f684260$9409e00a@DL21064>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, <[e-mail]>
References: <p05210600bb44d06f5e06@[128.89.89.40]> <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 24 Jul 2003 10:15:25 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MW-BTID: 090425000020032056298100022
X-MW-CTIME: 1059067781
X-MW-SENDING-MTA: 208.184.76.39
X-MIME-Autoconverted: from 8bit to quoted-printable by dymwsm15.mailwatch.com id h6OHTfVF010390
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 0102001daaca8761-98a4-48da-ac6a-7b868a56cfc2
X-OriginalArrivalTime: 24 Jul 2003 17:29:42.0137 (UTC) FILETIME=[2AB7AE90:01C35209]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6OJCVqt066775
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent,
DST has been useing a multivalued RDN in EndEntity certificates for a number
of PKIs and since 1999 when we started issuing certificates.  We only do
this for End Entities not servers.  Basically the certificate SubDN looks
like the following.

0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709,E =
[e-mail], CN = Russel F Weiser,O = TrustID personal
certificate,C = US

We have used this with numerous and integrated with many applications.
So is the issue that microsoft Active Directory will not support multivalued
RDNs  or that there Applications don't ?? I'm just trying to understand the
issue more clearly.

----- Original Message ----- 
From: "Michael Ströder" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, July 24, 2003 3:47 AM
Subject: Microsoft and multi-valued RDNs (was: draft minutes)


>
> Stephen Kent wrote:
> >
> > LDAP Documents:
>  > [..]
> > Biggest issue on the table for the schema document is that
> > Microsoft says it will not support multi-valued attributes (e.g., a
> > terminal RDN that is a set consisting of a common name and a serial
> > number).
>
> Could someone please elaborate on this?
>
> One of my customers is planning to use exactly this naming scheme with
> multi-valued RDNs in a rather large PKI deployment and so we're scared
about
> interoperability issues.
>
> Ciao, Michael.
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OIrfqt064644 for <[e-mail]>; Thu, 24 Jul 2003 11:53:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OIrfRG064643 for ietf-pkix-bks; Thu, 24 Jul 2003 11:53:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OIreqt064633 for <[e-mail]>; Thu, 24 Jul 2003 11:53:40 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id h6OIraO11663; Thu, 24 Jul 2003 12:53:36 -0600 (MDT)
From: [e-mail]
Received: from DL21064 (host192-35-174-247.digsigtrust.com [192.35.174.247]) (authenticated bits=0) by smtp.digsigtrust.com (8.12.6/8.12.6) with ESMTP id h6OInwI4019641; Thu, 24 Jul 2003 12:49:58 -0600 (MDT)
Message-ID: <00d501c35214$e1ae83c0$9409e00a@DL21064>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Cc: <[e-mail]>
References: <p05210600bb44d06f5e06@[128.89.89.40]> <[e-mail]> <008301c35203$8f684260$9409e00a@DL21064> <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs
Date: Thu, 24 Jul 2003 12:53:22 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ah but it is on the directory side of things when we create the directory
entry the 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709 is a
multi name attribute.  I can either search for Russel F Weiser and get
multiple entries for Russel F Weiser. Or if I formulation the LDAP search as
0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709+CN = Russel F
Weiser
I will get that exact entry only.
I am just trying to understand what the discussion was about.
Several years ago when I was looking at all this I tried to get CAs to
create DNs that were Mutlivalued RDNs but none of the CAs would do this. So
I just made the directory do it when we published the certificate into the
directory.
This allowed me to perform name uniqueness without searching the directory
prior to signing a certificate.
cheers
RFW

----- Original Message ----- 
From: "Michael Ströder" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, July 24, 2003 10:56 AM
Subject: Re: Microsoft and multi-valued RDNs


>
> [e-mail] wrote:
> > DST has been useing a multivalued RDN in EndEntity certificates for a
number
> > of PKIs and since 1999 when we started issuing certificates.  We only do
> > this for End Entities not servers.  Basically the certificate SubDN
looks
> > like the following.
> >
> > 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709,E =
> > [e-mail], CN = Russel F Weiser,O = TrustID personal
> > certificate,C = US
>
> Maybe I'm missing something but this is not a multi-valued RDN.
>
> An example in RFC2253 string notation would be:
>
> cn=Michael Stroeder+serialNumber=12345, ...
>
> Note the '+'.
>
> Ciao, Michael.
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OIrZqt064635 for <[e-mail]>; Thu, 24 Jul 2003 11:53:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OIrZ1h064634 for ietf-pkix-bks; Thu, 24 Jul 2003 11:53:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OIrYqt064626 for <[e-mail]>; Thu, 24 Jul 2003 11:53:34 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id h6OIrUO11653; Thu, 24 Jul 2003 12:53:30 -0600 (MDT)
From: [e-mail]
Received: from DL21064 (host192-35-174-247.digsigtrust.com [192.35.174.247]) (authenticated bits=0) by smtp.digsigtrust.com (8.12.6/8.12.6) with ESMTP id h6OInrI4019637; Thu, 24 Jul 2003 12:49:53 -0600 (MDT)
Message-ID: <00d401c35214$de6488e0$9409e00a@DL21064>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Cc: <[e-mail]>
References: <p05210600bb44d06f5e06@[128.89.89.40]> <[e-mail]> <008301c35203$8f684260$9409e00a@DL21064> <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs
Date: Thu, 24 Jul 2003 12:53:22 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ah but it is on the directory side of things when we create the directory
entry the 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709 is a
multi name attribute.  I can either search for Russel F Weiser and get
multiple entries for Russel F Weiser. Or if I formulation the LDAP search as
0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709+CN = Russel F
Weiser
I will get that exact entry only.
I am just trying to understand what the discussion was about.
Several years ago when I was looking at all this I tried to get CAs to
create DNs that were Mutlivalued RDNs but none of the CAs would do this. So
I just made the directory do it when we published the certificate into the
directory.
This allowed me to perform name uniqueness without searching the directory
prior to signing a certificate.
cheers
RFW

----- Original Message ----- 
From: "Michael Ströder" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, July 24, 2003 10:56 AM
Subject: Re: Microsoft and multi-valued RDNs


>
> [e-mail] wrote:
> > DST has been useing a multivalued RDN in EndEntity certificates for a
number
> > of PKIs and since 1999 when we started issuing certificates.  We only do
> > this for End Entities not servers.  Basically the certificate SubDN
looks
> > like the following.
> >
> > 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709,E =
> > [e-mail], CN = Russel F Weiser,O = TrustID personal
> > certificate,C = US
>
> Maybe I'm missing something but this is not a multi-valued RDN.
>
> An example in RFC2253 string notation would be:
>
> cn=Michael Stroeder+serialNumber=12345, ...
>
> Note the '+'.
>
> Ciao, Michael.
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OGuhqt059113 for <[e-mail]>; Thu, 24 Jul 2003 09:56:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OGuhXU059112 for ietf-pkix-bks; Thu, 24 Jul 2003 09:56:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4f5b.pool.mediaWays.net [217.187.79.91]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OGufqt059107 for <[e-mail]>; Thu, 24 Jul 2003 09:56:41 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id F1EBC95B99; Thu, 24 Jul 2003 18:56:31 +0200 (CEST)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id D2E0322C27; Thu, 24 Jul 2003 18:56:30 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2003 18:56:30 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030626
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: Microsoft and multi-valued RDNs
References: <p05210600bb44d06f5e06@[128.89.89.40]> <[e-mail]> <008301c35203$8f684260$9409e00a@DL21064>
In-Reply-To: <008301c35203$8f684260$9409e00a@DL21064>
X-Enigmail-Version: 0.76.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> DST has been useing a multivalued RDN in EndEntity certificates for a number
> of PKIs and since 1999 when we started issuing certificates.  We only do
> this for End Entities not servers.  Basically the certificate SubDN looks
> like the following.
> 
> 0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709,E =
> [e-mail], CN = Russel F Weiser,O = TrustID personal
> certificate,C = US

Maybe I'm missing something but this is not a multi-valued RDN.

An example in RFC2253 string notation would be:

cn=Michael Stroeder+serialNumber=12345, ...

Note the '+'.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OGnfqt058950 for <[e-mail]>; Thu, 24 Jul 2003 09:49:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OGnfL9058949 for ietf-pkix-bks; Thu, 24 Jul 2003 09:49:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OGneqt058943 for <[e-mail]>; Thu, 24 Jul 2003 09:49:40 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id h6OGnZO09351; Thu, 24 Jul 2003 10:49:35 -0600 (MDT)
From: [e-mail]
Received: from DL21064 (host192-35-174-247.digsigtrust.com [192.35.174.247]) (authenticated bits=0) by smtp.digsigtrust.com (8.12.6/8.12.6) with ESMTP id h6OGjwI4017894; Thu, 24 Jul 2003 10:45:58 -0600 (MDT)
Message-ID: <008301c35203$8f684260$9409e00a@DL21064>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, <[e-mail]>
References: <p05210600bb44d06f5e06@[128.89.89.40]> <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 24 Jul 2003 10:15:25 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent,
DST has been useing a multivalued RDN in EndEntity certificates for a number
of PKIs and since 1999 when we started issuing certificates.  We only do
this for End Entities not servers.  Basically the certificate SubDN looks
like the following.

0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709,E =
[e-mail], CN = Russel F Weiser,O = TrustID personal
certificate,C = US

We have used this with numerous and integrated with many applications.
So is the issue that microsoft Active Directory will not support multivalued
RDNs  or that there Applications don't ?? I'm just trying to understand the
issue more clearly.

----- Original Message ----- 
From: "Michael Ströder" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, July 24, 2003 3:47 AM
Subject: Microsoft and multi-valued RDNs (was: draft minutes)


>
> Stephen Kent wrote:
> >
> > LDAP Documents:
>  > [..]
> > Biggest issue on the table for the schema document is that
> > Microsoft says it will not support multi-valued attributes (e.g., a
> > terminal RDN that is a set consisting of a common name and a serial
> > number).
>
> Could someone please elaborate on this?
>
> One of my customers is planning to use exactly this naming scheme with
> multi-valued RDNs in a rather large PKI deployment and so we're scared
about
> interoperability issues.
>
> Ciao, Michael.
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ODRuqt045005 for <[e-mail]>; Thu, 24 Jul 2003 06:27:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6ODRu5U045004 for ietf-pkix-bks; Thu, 24 Jul 2003 06:27:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6ODRtqt044995 for <[e-mail]>; Thu, 24 Jul 2003 06:27:55 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4282 invoked by uid 0); 24 Jul 2003 13:26:40 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.157) by woodstock.binhost.com with SMTP; 24 Jul 2003 13:26:40 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 24 Jul 2003 09:22:13 -0400
To: "Al Arsenault" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: <[e-mail]>
In-Reply-To: <010701c3515d$6ead10b0$acf42180@arsenaultd2>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Al's conclusion.  SHOULD NOT is the right wording for RFC 3280 
(and its successor).

Russ

At 05:00 PM 7/23/2003 -0400, Al Arsenault wrote:
>I'm certainly open to explanations as to what I'm missing; that is, why it's
>important to have this information in the certificate and what you'd do
>different because of it.  But given that privateKeyUsagePeriod is permitted
>in a certificate for those who really want it (it's a SHOULD NOT, not a MUST
>NOT unless you want to mark it critical), and I personally don't see any
>benefit to it, I'm in favor of leaving the recommendation the way it is in
>3280.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ODCRqt042261 for <[e-mail]>; Thu, 24 Jul 2003 06:12:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6ODCR1X042260 for ietf-pkix-bks; Thu, 24 Jul 2003 06:12:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ODCQqt042254 for <[e-mail]>; Thu, 24 Jul 2003 06:12:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.1.70.188] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6ODCAD9020985; Thu, 24 Jul 2003 09:12:15 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210604bb458b21b802@[10.1.70.188]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 24 Jul 2003 09:12:22 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 22:43 +1200 7/24/03, Peter Gutmann wrote:
>=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:
>>Stephen Kent wrote:
>>>  LDAP Documents:
>>>  [..]
>>>  Biggest issue on the table for the schema document is that
>>>  Microsoft says it will not support multi-valued attributes (e.g., a
>>>  terminal RDN that is a set consisting of a common name and a serial
>>>  number).
>>
>>Could someone please elaborate on this?
>
>Using multi-valued RDNs is very risky because it breaks a lot of software (not
>just Microsoft's stuff).
>
>Elaborate enough?
>
>Peter.

Last year we tested IE and Netscape clients and they processed 
multi-valued, terminal RDNs with no problems.  It also was not a 
problem for Apache web servers.  I did not test IIS or other servers 
at the time. Anyway, apparently the concern is not a client side 
issue for these very (most?) widely deployed products. I think David 
indicated that he had been told it was a server issue of some sort 
for MS.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OD9Cqt042114 for <[e-mail]>; Thu, 24 Jul 2003 06:09:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OD9C8l042113 for ietf-pkix-bks; Thu, 24 Jul 2003 06:09:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OD9Bqt042103 for <[e-mail]>; Thu, 24 Jul 2003 06:09:11 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.1.70.188] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6OD8wD9020785; Thu, 24 Jul 2003 09:08:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210600bb458783df07@[10.1.70.188]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 24 Jul 2003 09:09:22 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft minutes
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:08 +0200 7/24/03, Peter Sylvester wrote:
>  >
>>
>>  PKIX WG Specifications
>>
>>	Simple Certificate Validation Protocol - Trevor Freeman (Microsoft)
>>  The current draft of SCVP is in WG Last Call, and is believed to be in
>>  full compliance with RFC 3379. This presentation discussed changes
>>  since the previous (version 11) draft. Plan is to progress to WG last
>>  call very soon. [slides]
>>
>>
>
>- Does the last sentence mean IETF last call?

No, the text says WG last call, right?

>- After having received at least one complaint (from me),
>   Tim Polk announced in the meeting that a new two weeks
>   last call period would start after the IETF meeting, the
>   reason being that both for participants of the meeting and
>   non participants either the travel time or potential discussions
>   create some time problems.

yes, Tim and I agreed to extend the last call in response to your 
observation that the overlap with the IETF meeting caused problems.

>- Since non participants of the meeting did not hear this,
>   it seems somewhat logical to me to inform the list BEFORE a new
>   period starts, so everybody know can know this. I expected
>   a mail to the list immediately after the meeting, but maybe
>   the chairmen did as me, and left Wien immediately so
>   they did not have the chance to send a mail.

I failed to mention this in the minutes because I expected we would 
send the announcement out sooner, and because I wanted to draw 
people's attention to the extended last call period, not rely on them 
to dig it out of the minutes. But, we failed to send the message.

>- Not even finding this announcement in the draft minutes is
>   more surprising.

see explanation above.

>
>- But: Even if the draft minutes would have reflected it, already
>   one week would hae ben gone.
>
>- Therefore I kindly request the chairmen to announce in a
>   mail to the list a new beginning of a last call starting
>   not less than one full working day in all areas of this
   planet, and the period not covering an IETF meeting.

WG last calls begin when we send a message top the list announcing 
them.  We don't pre-announce when a last call will begin, nor does 
any other WG with which I am familiar.

so, to address the concerns Peter noted, let's reset the clock on the 
PKIX WG last call on SCVP.  The last call will end on Friday, August 
8th, slightly more than 2 weeks from today.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OCePqt039667 for <[e-mail]>; Thu, 24 Jul 2003 05:40:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OCePJi039666 for ietf-pkix-bks; Thu, 24 Jul 2003 05:40:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OCeJqt039659 for <[e-mail]>; Thu, 24 Jul 2003 05:40:20 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA13175; Thu, 24 Jul 2003 14:40:18 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 24 Jul 2003 14:40:18 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h6OCeFG29327; Thu, 24 Jul 2003 14:40:15 +0200 (MEST)
Date: Thu, 24 Jul 2003 14:40:15 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am not sure that a relyaing party can always assume 
that a signing device is not cheating concerning the
key usage period, i.e., to determine whether the
key has be used before the PKUP end. 

The certificate validation procedures do not
imply in any case that a PKUP is checked, and
signature validation procedures are ... where are
they?

IMO, a useful PKUP is for the signing device as
Greg Chodov inidicates to inform the signer at least that

' You signature key is not to be supposed anymore, 
  if you insist signing with it, the relying parties
  may not be able to validate it before expiration of
  the cert. '

Whether the signer device allows to sign anyway or
not is another question. 

Without a PKUP, a nice user agent may indcate in
a global way: 'You cert is going to expire in n days',
but since this information is part of a policy,
the delays may be different, ...

Peter

Digital signatures are for authentication in space, not in time.

      


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OCWcqt039379 for <[e-mail]>; Thu, 24 Jul 2003 05:32:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OCWcsl039378 for ietf-pkix-bks; Thu, 24 Jul 2003 05:32:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbe4.getronics.com (mailbe4.getronics.com [158.67.5.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OCWYqt039368 for <[e-mail]>; Thu, 24 Jul 2003 05:32:34 -0700 (PDT) (envelope-from [e-mail])
Received: from MAILBE2.getronics.com ([192.58.226.24]) by mailbe4.getronics.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 13:45:12 +0200
Received: from mail pickup service by MAILBE2.getronics.com with Microsoft SMTPSVC; Thu, 24 Jul 2003 13:45:12 +0200
Received: from asgard.ietf.org ([132.151.6.40]) by MAILBE3.getronics.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 22:04:48 +0200
Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19fPCc-0004kX-80 for [e-mail]; Wed, 23 Jul 2003 15:23:06 -0400
Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19fP5V-0003eb-HX for [e-mail]; Wed, 23 Jul 2003 15:15:45 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25468; Wed, 23 Jul 2003 15:15:41 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-07.txt
Date: Wed, 23 Jul 2003 15:15:41 -0400
X-OriginalArrivalTime: 23 Jul 2003 20:04:48.0545 (UTC) FILETIME=[AB5B1910:01C35155]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-07.txt
	Pages		: 45
	Date		: 2003-7-23
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-07.txt

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

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

--OtherAccess--

--NextPart--





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OCDWqt037713 for <[e-mail]>; Thu, 24 Jul 2003 05:13:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OCDWHp037712 for ietf-pkix-bks; Thu, 24 Jul 2003 05:13:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OCDVqt037706 for <[e-mail]>; Thu, 24 Jul 2003 05:13:32 -0700 (PDT) (envelope-from [e-mail])
Received: from mail4.magma.ca (mail4.magma.ca [206.191.0.222]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id h6OCDSmR023933; Thu, 24 Jul 2003 08:13:28 -0400
Received: from hippolyta (ottawa-dial-64-26-139-254.d-ip.magma.ca [64.26.139.254]) by mail4.magma.ca (Magma's Mail Server) with SMTP id h6OCDH63003265; Thu, 24 Jul 2003 08:13:25 -0400
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Thu, 24 Jul 2003 08:23:56 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

You pose some provocative questions, as usual.  Please see my responses
below.

Thanks,


Alice Sturgeon
Chair, Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC 1/SC 27
and
System Policy Architect & Manager Standards
SPYRUS

Office:  613-232-2350
Mobile: [phone]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Denis Pinkas
Sent: Tuesday, July 08, 2003 11:19 AM
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt


>       Title           : Internet X.509 Public Key Infrastructure Warranty
Certificate Extension
>       Author(s)       : D. Linsenbardt, S. Pontius, A. Sturgeon
>       Filename        : draft-ietf-pkix-warranty-extn-03.txt
>       Pages           : 8
>       Date            : 2003-6-27

Here are my comments on this draft.
Comments on warranty-extn-03.txt (June 2003)

1- On page 2. The text mentions: "A relying party that has a warranty from a
CA".

Does this mean that a relying party must have a contract with the CA to get
advantage of the warranty ?
No.
Does this mean that a relying party will get a warranty without a contract
signed with the CA ?
Yes.
Does this extension allow to make the difference between the case of a
signed contract and the case of an unsigned contract where the guarantees
could be different?
No. If there are any differences in the T&C pertaining to a contractual
arrangement, these differences will be outside of, beyond the scope, and not
pertinent to, the warranty offered in the certificate.  It applies equally
to all relying parties, whether or not a contract has been signed.

2 - The difference between the base warranty and the extended warranty is
not crystal clear.

How can a relying party know whether it can have the benefits of the base
warranty or of the extended warranty ?
If the extended warranty is present, then the relying party has the benefit
of the extended warranty.  In short, if it is present, then the relying
party knows that the relying party has the benefit of the extended warranty
by its presence alone.  The syntax shows that the extended warranty MAY be
present:
 Warranty ::= CHOICE  {
       none                 NULL,            -- No warranty provided
       wData                WarrantyData  }  -- Explicit warranty

   WarrantyData ::= SEQUENCE  {
       base                 WarrantyInfo,
       extended             WarrantyInfo OPTIONAL,
       tcURL                TermsAndConditionsURL OPTIONAL  }

If the tcURL is present, a human being might understand the terms and
conditions (if he can understand the local language used), but a computer
program will not be able to do so. This means that computers cannot
understand the difference.
The computer does not need to know what is in the T&C.  If the tcURL is
present, it is optionally for the benefit of the human reader. Perhaps you
could suggest some text to clarify this in the I-D if you still think it is
needed.

3 - There is no security on the information placed at the tcURL parameter
since no hash of the terms and conditions is being used. These conditions
could change overtime and relying parties would not be able to demonstrate
that they have changed.
It seems to me that the time stamp on the certificate would suffice to place
the warranty in a point of time at which the specified terms and conditions
applied; there is no need for the extension to demonstrate that as this is
covered by the certificate itself.  This is no different from the
paper-based world in that if an insurance policy changes its terms, it
cannot do so retroactively to the detriment of clients who have paid for a
specific coverage, unless it notified the clients and compensates them
accordingly.

4 - Is the "Relying party Agreement" a document to signed by the parties or
not ? This should be said.
Use of the term "Relying Party Agreement" is no different from its normal
usage, just as "Certificate Policy" is used in the same context without any
change to the meaning from normal usage, as per RFC 2527 and its successor.
In other words, defining the terms, either Relying Party Agreement or
Certificate Policy is not necessary to the understanding of this extension.

5 - The WarrantyValidityPeriod is insufficient. Usually there is a period to
claim for a compensation which must be made X months or Y days after the
date of the event which created the damage. It is thus not possible to ask
for a warranty during e.g. the whole validity period of the certificate.
Another time period parameter is missing.
This is exactly what the validity period is stating: that the warranty is
valid for a specified time, which is either the validity period of the
certificate, or another, specified time using the parameters as defined in
the I-D.  It is presented and offered this way, so there is no need for
another validity parameter.  If an offeror wanted to specify a time within
which claims could be made, then a shorter time period than the validity of
the certificate can be used.  This is unlike the paper-based world in the
sense that insurance policies are normally of long duration, whereas this
extension is associated with a certificate that normally has a validity of
two-three years.

6 - The wType offers only two types of warranty: aggregated and per
transaction.

"Aggregated" means that that once the value of the fulfilled claims reaches
the maximum warranty amount, then no further claim will be fulfilled.

"Per transaction" means that each claim is handled independently but no
individual claim can exceed the maximum warranty amount.

Each type has its own problems:

"Aggregated" is like a race where late claimants will get no compensation at
all because they were not "fast enough". It is questionable whether such a
race condition will be acceptable.
It should be understood that aggregation applies to one warranty and one
claimant.  This is analogous to the paper-based world.  When you are covered
by warranty for X product or service, e.g., health insurance, there is often
an upper limit (viz. the "value") up to which claims will be met for each
claimant; i.e., one insured person.
"Per transaction" means that the CA cannot compute the maximum amount of
money that it may have to give away. Which insurance company will ever
insure a risk for which an upper limit cannot be computed ?
The T&C, as noted in section 1, as covered by insurance, will specify the
maximum.
The type of warranty selected depends on the nature of the transactions, the
parties to the transactions (e.g., individuals, large institutions, etc.).

None of these schemes is acceptable. Some combination should be allowed:

  - a maximum amount per transaction, and
  - a maximum amount per certificate with a maximum time period
    to claim for a compensation after the date of the event
    (no race problem implied).


7 - The content of the security consideration should be augmented to
indicate the difference between what a computer program can do and a human
being can do with this extension.
I would have thought this to be blindingly obvious.  We would, however, be
quite willing to consider some proposed words to address this, if you do
think it is necessary.

8 - The document is not mature enough and its added value is still
questionable.
We believe that it is mature.  Its value may be questionable to those who do
not want to use it, but given that it is (a) proposed as Informational and
(b) always non-critical, surely its availability for use is innocuous for
those that do not want to use it.  For those who do want to use it, and we
have heard from quite a number who do, it will be useful and valuable.  As
in section 1: "When a certificate contains a warranty certificate extension,
the extension MUST be non-critical, ..."

Denis





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OBgbqt035689 for <[e-mail]>; Thu, 24 Jul 2003 04:42:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OBgbXq035688 for ietf-pkix-bks; Thu, 24 Jul 2003 04:42:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OBgZqt035676 for <[e-mail]>; Thu, 24 Jul 2003 04:42:35 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6OBgUoY014530; Thu, 24 Jul 2003 23:42:30 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6OBgV106887; Thu, 24 Jul 2003 23:42:31 +1200
Date: Thu, 24 Jul 2003 23:42:31 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>Elaborate enough?
>
>Nope.

Well, what more do you want to know?  Shall I communicate it in the form of an
illuminated manuscript?

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OB2Kqt033046 for <[e-mail]>; Thu, 24 Jul 2003 04:02:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OB2KMo033045 for ietf-pkix-bks; Thu, 24 Jul 2003 04:02:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4f5b.pool.mediaWays.net [217.187.79.91]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OB2Iqt033019 for <[e-mail]>; Thu, 24 Jul 2003 04:02:18 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 5BC889D8CA; Thu, 24 Jul 2003 13:02:14 +0200 (CEST)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id A01A020F6D; Thu, 24 Jul 2003 13:02:13 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2003 13:02:13 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030626
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS 0.3.12pre8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6OB2Jqt033039
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> Michael_Ströder <[e-mail]> writes:
> 
>>Stephen Kent wrote:
>>
>>>LDAP Documents:
>>>[..]
>>>Biggest issue on the table for the schema document is that
>>>Microsoft says it will not support multi-valued attributes (e.g., a
>>>terminal RDN that is a set consisting of a common name and a serial
>>>number).
>>
>>Could someone please elaborate on this?
> 
> Using multi-valued RDNs is very risky because it breaks a lot of software (not
> just Microsoft's stuff).

I already know that.

> Elaborate enough?

Nope.

Ciao, Michael.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OAhPqt031454 for <[e-mail]>; Thu, 24 Jul 2003 03:43:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OAhPod031453 for ietf-pkix-bks; Thu, 24 Jul 2003 03:43:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OAhNqt031444 for <[e-mail]>; Thu, 24 Jul 2003 03:43:24 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6OAhJoY013553; Thu, 24 Jul 2003 22:43:19 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6OAhJk06743; Thu, 24 Jul 2003 22:43:19 +1200
Date: Thu, 24 Jul 2003 22:43:19 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:
>Stephen Kent wrote:
>> LDAP Documents:
>> [..]
>> Biggest issue on the table for the schema document is that
>> Microsoft says it will not support multi-valued attributes (e.g., a
>> terminal RDN that is a set consisting of a common name and a serial
>> number).
>
>Could someone please elaborate on this?

Using multi-valued RDNs is very risky because it breaks a lot of software (not
just Microsoft's stuff).

Elaborate enough?

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OA9Cqt029212 for <[e-mail]>; Thu, 24 Jul 2003 03:09:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OA9CI4029211 for ietf-pkix-bks; Thu, 24 Jul 2003 03:09:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OA9Aqt029206 for <[e-mail]>; Thu, 24 Jul 2003 03:09:11 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA12583; Thu, 24 Jul 2003 12:08:58 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 24 Jul 2003 12:08:59 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h6OA8vo23913; Thu, 24 Jul 2003 12:08:57 +0200 (MEST)
Date: Thu, 24 Jul 2003 12:08:57 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft minutes
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> 
> PKIX WG Specifications
> 
> 	Simple Certificate Validation Protocol - Trevor Freeman (Microsoft)
> The current draft of SCVP is in WG Last Call, and is believed to be in
> full compliance with RFC 3379. This presentation discussed changes 
> since the previous (version 11) draft. Plan is to progress to WG last 
> call very soon. [slides]
> 
> 

- Does the last sentence mean IETF last call? 

- After having received at least one complaint (from me),
  Tim Polk announced in the meeting that a new two weeks
  last call period would start after the IETF meeting, the
  reason being that both for participants of the meeting and
  non participants either the travel time or potential discussions
  create some time problems.

- Since non participants of the meeting did not hear this, 
  it seems somewhat logical to me to inform the list BEFORE a new 
  period starts, so everybody know can know this. I expected
  a mail to the list immediately after the meeting, but maybe
  the chairmen did as me, and left Wien immediately so
  they did not have the chance to send a mail. 

- Not even finding this announcement in the draft minutes is
  more surprising. 

- But: Even if the draft minutes would have reflected it, already
  one week would hae ben gone. 

- Therefore I kindly request the chairmen to announce in a
  mail to the list a new beginning of a last call starting
  not less than one full working day in all areas of this
  planet, and the period not covering an IETF meeting. 

Thanks for consideration. 
Peter




  


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O9x1qt027378 for <[e-mail]>; Thu, 24 Jul 2003 02:59:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6O9x1Cq027377 for ietf-pkix-bks; Thu, 24 Jul 2003 02:59:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O9x0qt027366 for <[e-mail]>; Thu, 24 Jul 2003 02:59:00 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 19fcs0-00016R-00; Thu, 24 Jul 2003 11:58:44 +0200
From: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Reply-To: "Diego Fernandez" <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2003 09:58:45 GMT
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: es
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
X-Accept-Language: es
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Suppose that the certificate was issued to Bob at Acme Corp.  On 30 
>November2004, Bob was fired because it was discovered that he had been
>misappropriating office supplies.  It is suspected that he has 
>initiated and
>signed a number of EDI transactions in connection with his nefarious 
>scheme.
>

But the private key can't be used beyond on 30 June 2004.
After this time, Bob will have a new cert that will be
revoked.

>My point is this:  from what I can see, usage of the extension really
>doesn't buy you anything.  In order to accurately assess whether the
>transaction was valid at the time of signing, and assess that long 
>after the
>fact, you have to archive so much extra information that I don't see 
>whatpain is caused by the fact that the certificate has expired by 
>then. It's
>not clear to me what if anything you do differently because you have
>information directly tied to the certificate - e.g., it was revoked 
>monthslater. It doesn't save much in the way of processing to have 
>any such
>information directly tied to the certificate, versus tied to some other
>piece of information you had to archive.
>

I think that  

1) The PKUP allows to extent the signature verification by the cert 
period, 
   because the reason of revocation is discovered later and have an 
affect 
   on the validity period of the private key. But:
   1.1) The reason could be discovered after the cert period
   1.2) The gap between the private key notAfter and the cert notAfter 
have
        to be related with the lifetime of the signed document.

2) An end entity cert is a signed document issued by a CA with a 
lifetime.
   It falls on the 1.2. If the CA cert has the PKUP, the end entity 
certs
   issued within the private key CA lifetime would be verified (chain 
and CRL)
   within the validity period of the CA cert.


Kind regards,

Diego Fernandez




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O9m3qt026743 for <[e-mail]>; Thu, 24 Jul 2003 02:48:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6O9m3j9026742 for ietf-pkix-bks; Thu, 24 Jul 2003 02:48:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4f5b.pool.mediaWays.net [217.187.79.91]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O9m0qt026737 for <[e-mail]>; Thu, 24 Jul 2003 02:48:01 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 1523F9D8B6 for <[e-mail]>; Thu, 24 Jul 2003 11:47:56 +0200 (CEST)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 507599D89A for <[e-mail]>; Thu, 24 Jul 2003 11:47:55 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 24 Jul 2003 11:47:54 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030626
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Microsoft and multi-valued RDNs (was: draft minutes)
References: <p05210600bb44d06f5e06@[128.89.89.40]>
In-Reply-To: <p05210600bb44d06f5e06@[128.89.89.40]>
X-Enigmail-Version: 0.76.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> 
> LDAP Documents:
 > [..]
> Biggest issue on the table for the schema document is that 
> Microsoft says it will not support multi-valued attributes (e.g., a 
> terminal RDN that is a set consisting of a common name and a serial 
> number).

Could someone please elaborate on this?

One of my customers is planning to use exactly this naming scheme with 
multi-valued RDNs in a rather large PKI deployment and so we're scared about 
interoperability issues.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O0g4qt080939 for <[e-mail]>; Wed, 23 Jul 2003 17:42:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6O0g476080938 for ietf-pkix-bks; Wed, 23 Jul 2003 17:42:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O0g3qt080926 for <[e-mail]>; Wed, 23 Jul 2003 17:42:03 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.1.70.188] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6O0fxD9021916 for <[e-mail]>; Wed, 23 Jul 2003 20:42:00 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210600bb44d06f5e06@[128.89.89.40]>
Date: Wed, 23 Jul 2003 19:56:40 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft minutes
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6O0g3qt080934
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please provide feedback by August 1st.

Steve
-------


PKIX WG Meeting 7/17/03

Edited by Steve Kent

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

The PKIX WG met once during the 57th IETF. A total of approximately 
75 individuals participated in the meeting.


Agenda review and document status - Tim Polk (NIST)
	There are about XX WG documents in various stages in the 
process, some of which fell through the cracks due to process 
glitches. [slides]

WG Focus and Direction - Russ Housley
	The working group has received direction from the IESG that 
will limit the types of new specifications accepted as PKIX work 
products. Thus the WG is not accepting new work items.  New WGs will 
be formed, as needed, to address PKI issues, or individual drafts can 
be submitted and subject to IETF-wide last call if the work described 
in them is mature and non-controversial. [no slides]

Document Status Review - Tim Polk (NIST)
	The working group has a fair number of Internet-Drafts in 
various stages of processing, but since the last meeting considerable 
progress has been made. Several IDs are in or have recently completed 
last call. [slides]


PKIX WG Specifications

	Simple Certificate Validation Protocol - Trevor Freeman (Microsoft)
The current draft of SCVP is in WG Last Call, and is believed to be in
full compliance with RFC 3379. This presentation discussed changes 
since the previous (version 11) draft. Plan is to progress to WG last 
call very soon. [slides]


RFC 3280 Progression - Tim Polk (NIST)
	NIST is currently performing the interoperability testing for RFC 3280.
This presentation updated the WG on NIST's progress, projected 
completion date, and issues identified to date. Primary focus is on 
the RFC 3280 path validation test suite developed jointly by NIST, 
DigitalNet, and NSA. Discussion of the problem of UTF-8 string 
matching, which has been addressed in the DNS context (RFC 3454), but 
is addressed only minimally in 3280. Plan is to stick with the 
current 3280 spec for progression to DRAFT, but to create a separate 
document to specify what CAs should do, to ensure that the simple, 
binary comparison will work in path building. [slides]

LDAP Documents: - David Chadwick (Univ of Salford) & Peter Gietz (DAASI)
      The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
for LDAP based PKI information distribution.  New drafts on PKC 
certificate       schema, CRL schema and on Attribute Certificate 
schema have been published      since the 56th IETF.  The authors 
presented the changes in these documents and discussed the timeline 
for document completion. Biggest issue on the table for the schema 
document is that Microsoft says it will not support multi-valued 
attributes (e.g., a terminal RDN that is a set consisting of a common 
name and a serial number). Direction from WG chairs is to maintain 
this requirement, and to discuss with MS why they believe this is not 
a necessary feature. Plan is to proceed to last call immediately 
after this IETF meeting. Still have to deal with the "; binary" issue 
for transfer of LDAP data. [slides]

Qualified Certificates  - Stefan Santesson (Microsoft)
       This presentation proposed a path for the evolution of the QC 
document. The intent is to relax some current QC profile constraints 
(e.g., re setting the NR bit), consistent with activities within 
ETSI, which uses this document as a basis for EU standards with 
regard to qualified certificates. Also need to bring this RFC into 
alignment with RFC 3280. [slides]

Certification Path Building  - Matt Cooper (Orion Security)
       This document, intended to become an informational RFC, was 
written to provide guidance and recommendations to developers 
building X.509 public-key certification paths within their 
applications, based on experience gained in several contexts. The 
document describes different PKI structures, considerations for 
forward vs. reverse path construction, tree pruning, etc. emphasis on 
value of disallowing repeated name/key combination in a path. Need to 
reword the introductory/overview text to make clear that the material 
presented is advisory, not mandatory, and to acknowledge that 
overall, we are still in early stages of gaining experience in this 
area. Also, if this is to be a PKIX document, then need to clarify 
that some of the "rules" deal with accommodation of non-complaint 
certificates. [slides]

RSA Public Key Algorithms - Jim Schaad (Soaring Hawk)
	New member of editorial team for this document. Discussed 
open questions of OID use (encryption vs. signature) and parameters 
use. New draft will be issued soon. [no slides]

Related Specifications
	The following personal drafts address topics of interest to 
the PKIX WG, and are presented to highlight the availability of the 
drafts and encourage input from the WG.

Russian Cryptographic Algorithms for PKIX - Grigory Chudov (Crypto-Pro)
	This personal draft documents the use of Russian national cryptography
standards (GOST) in the PKIX context. It was developed within the 
"Russian Cryptographic Software Compatibility Agreement", and signed 
by major Russian cryptographic software vendors. This agreement 
specifies parameters not nailed down in basic Russian Government 
standards. [slides]

Memorandum for multi-domain PKI Interoperability - Masaki SHIMAOKA (SECOM)
	This personal draft documents known issues and considerations 
for multi-domain PKI, and provides guidelines for multi-domain PKI 
interoperability as a best current practice. The scope of this 
specification is the establishment of trust relationships and 
interoperability among multiple PKI domains. This specification is a 
follow on to the JNSA Challenge PKI 2002 and Multi-Domain PKI Test 
Suite. [slides]

Liaison/Related Projects

The following specifications will update the WG on related EU activities.

European Open Standards for Electronic Signatures: the EESSI - 
Riccardo Genghini, EESSI Chair (SG&A)
	The European Electronic Signature Standardization Initiative 
(EESSI) is an industry initiative in Support of the European 
Directive on Electronic      Signatures. This presentation described 
the status of the ESESI's current and
recent work, which has just been published. This presentation was an 
update to the status report provided at the 56th IETF. [slides]

OpenEvidence Project - Peter Sylvester (EdelWeb)
	The EU IST project OpenEvidence is an Open source project 
concerning technologies for establishing the long term validity 
(integrity, time of posting, Š) of documents. The presentation 
addressed the goals and the current status of the implementations. 
Plan to update RFCs 3161 and 3029 to reflect additional experience 
gained in this project. [slides]




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NMUHqt073087 for <[e-mail]>; Wed, 23 Jul 2003 15:30:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NMUHDk073085 for ietf-pkix-bks; Wed, 23 Jul 2003 15:30:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NMUFqt073064 for <[e-mail]>; Wed, 23 Jul 2003 15:30:16 -0700 (PDT) (envelope-from [e-mail])
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h6NMUAt135632; Wed, 23 Jul 2003 17:30:10 -0500
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 23 Jul 2003 17:32:04 -0500
To: <[e-mail]>
Cc: "'pkix'" <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>
Subject: Re: Draft-ietf-pkix-proxy-06.txt
In-Reply-To: <002001c35155$4eaf7ee0$[e-mail]>
References: <002001c35155$4eaf7ee0$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

Comments below. We released version -07 that crossed your email by the
way, but with one exception noted below all your questions still
apply.

Von

Jim Schaad writes (16:01 July 23, 2003):
 > 
 > 1. Section 3.3, para 2:  I think that the MAY in this paragrah should be
 > lower case.  I do not see these as a protocal statements, but as saying
 > these are ways that reasonable uniqueness could be obtained for a serial
 > number.  I assume that other methods of doing this are perfectly
 > allowable.

(You mean both MAYs, right?) I think you are right, maybe someone else
can confirm.

 > 2. Section 3.4:  Does the subject name need to be "unique" among all
 > certificates ever issued by a proxy, or just the active certificates?

Ever, unless it's reissuance to the same bearer as described in
paragraph 3.

 > 3. General:  I am still not comfortable that the issuance of Proxy
 > Certificates cannot be restricted (or permitted) by a CA when it issues
 > an EEC.  One method of doing this would be a non-critical ProxyCertInfo
 > extension with a pCPathLengthConstrant of 0 in the EEC.

I really dislike your suggested method because that would make the
presence of a ProxyCertInfo extension ambiguous - right now it
designates a certificate is a proxy certificate. *IF* this is
something that people think is critical, I believe another extension
should be defined to be placed into an EEC to prohibit it from issuing
proxy certificates.

 > 4. Section 2.6:  When creating a new PC, where and how is the
 > negotiations on policy language and policy done?  Should this be
 > documented as a separate step in the text describing how PCs are
 > obtained/issued?  Does something need to be done about potentially
 > asking the relying party as to what policy it requires to perform some
 > task?

Since it is not always possible to even know who all the relying
parties potentially are when a proxy certificate is issued it's not
really possible to negotiate this. Our view is that the set of polices
used in a particular environment will be established out of band in
the environment.

 > 5. Section 3.8.2:  I find the following text
 > 
 >     Note that this 
 >     verification MUST take place regardless of whether or not the PC 
 >     itself contains a policy, as other PCs in the signing chain MAY 
 >     contain conditions that MUST be verified. 
 > 
 > 	to be confusing because I always get policyLanguage and policy
 > mixed up.  I think that all PCs must have policy and so the statement is
 > difficult to parse.  I don't know that this can be simplified without
 > renaming the policy field in the extension.

I think this statement is from when polices were optional and
impersonation was implied otherwise. If it causes real heartburn I
believe it can be removed at this point as it doesn't add anything.

 >  The text in item 1) just
 > before this refers to policy and should probably refer to
 > policyLanguage.

I don't think this would be correct - as understanding the policy
implies understanding the policy language in which it is written, so
the change doesn't add anything, and a relying party need to
understand not just the language, but the policy itself.

 > 6.  Section 4.1.3 next to last paragraph.  Text should be "If steps (a),
 > (b) or (d) fail,..."

Agreed.

 > 7.  Section 4.2:  I have a complete lack of understanding for the last
 > three paragraphs in this section.

These paragraphs are addressing whether or not the {extended} key
usage extensions of it's issuer apply to it. It's really ugly because
these extensions are really ugly (they are in part restrictions and in
part capabilities), I'm not sure how to clarify this.


 > 8.  Section 5.1.2:  Fix "Section Error! Reference source not found"

This was fixed in -07.

 > 9.  
 > 

Is there more that should appear here?

- end comments -



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NL2Dqt069899 for <[e-mail]>; Wed, 23 Jul 2003 14:02:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NL2D8o069898 for ietf-pkix-bks; Wed, 23 Jul 2003 14:02:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NL2Cqt069892 for <[e-mail]>; Wed, 23 Jul 2003 14:02:12 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id h6NL1WD8006094; Wed, 23 Jul 2003 17:01:34 -0400 (EDT)
Message-ID: <010701c3515d$6ead10b0$acf42180@arsenaultd2>
From: "Al Arsenault" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Date: Wed, 23 Jul 2003 17:00:19 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 23, 2003 11:24 AM
Subject: Re: Why is privateKeyUsagePeriod deprecated?


> <snip>
>
> Incidentally, one amusing/scary side-effect of using certs after they've
> expired is that the CA generally no longer bothers issuing CRLs for them
> (since they've expired), but they're still being used to validate
signatures
> beyond the 1-year billing period.  As a result, it's impossible to perform
> revocation checking on the cert.  I guess if you're ignoring the expiry
date
> you may as well ignore revocation checking as well :-).
>
> Peter.

This brings up what is to me an interesting question:  exactly what service
do you think you're providing with this signature validation long after the
fact, and why do you think it's important?

That's a big input into whether or not the privateKeyUsagePeriod extension
brings any value.

I can only think of about three reasons why one would want to do a signature
validation months after an order was signed:

    - as part of a business audit;
    - as part of a dispute resolution process (e.g., a non-repudiation
issue)
    - because one's business processes were REALLLLY slow, and it just takes
that long to process an order.

Consider two scenarios:

Scenario 1:



            A certificate is issued 1-January-2004; it's valid until
30-June-2004; there is no privateKeyUsagePeriod extension



Scenario 2:



            A certificate is issued 1-January-2004; it's valid until 31
December-2004; there is a privateKeyUsagePeriod extension allowing use of
the private key for signing from 1-January-2004 through 30-June-2004.



Now, suppose that there is an EDI transaction ostensibly signed 30 March
2004; someone attempts to validate this transaction on 30 December 2004.



In scenario 1, the certificate has expired.  That means that the CA has
stopped attesting to the validity of the owner-key mapping on 30 June 2004.
There is no  current evidence of revocation; i.e., there is no current
indication that the owner-key mapping is valid or not. There is, however, a
CRL and/or OCSP response indicating whether or not the certificate was
revoked on or shortly after 30 March 2004.



In scenario 2, the certificate is still valid.  Thus, there should be
evidence in the system that indicates not only whether the owner-key mapping
was valid on 30 March 2004, but also on 30 December 2004.



Suppose that the certificate was issued to Bob at Acme Corp.  On 30 November
2004, Bob was fired because it was discovered that he had been
misappropriating office supplies.  It is suspected that he has initiated and
signed a number of EDI transactions in connection with his nefarious scheme.



(If you want the certificate issued with Acme Corp. itself instead of Bob,
that's fine; we can just assume that the private key has somehow been
discovered and posted on a prominent web site.  In other words, it's
compromised.)



 So, what do you do?  If we're in Scenario 2, and you're just processing the
transaction on 30 December because your business processes are that slow,
then it might make a difference to you.  You know that the key is marked
compromised; the certificate is revoked. So you don't send the office
supplies.  If it's scenario 1, you MAY choose to accept the transaction and
send the supplies, even though the certificate has long ago expired.  There
may be a difference in behavior.



But in either of the other cases (audit or non-repudiation dispute), does it
really make a difference that you had the information from November?  You're
trying to determine whether accepting the transaction on 30 March was the
right thing to do.  You have to use the information that was available to
you on 30 March (or a few days thereafter) - the CRL or OCSP response from
right after that; the transaction itself; any other records.  If the key
were discovered on 30 November to be compromised, would you really say that
the behavior in March should have been different based on whether a
privateKeyUsageExtension were used or not?



Put another way:  the only potential benefit I can see to scenario 2 over
scenario 1 is that the CA is in essence stating:  "I'll keep track of the
status of Acme Corp., the cert owner, for a longer period of time.  If
evidence arises that Acme Corp. is no longer the rightful, unique holder of
the private key associated with that certificate, I'll let you know - even
though Acme Corp. has long since ceased using that private key to sign new
transactions.  What you do differently because of this information is up to
you."



My point is this:  from what I can see, usage of the extension really
doesn't buy you anything.  In order to accurately assess whether the
transaction was valid at the time of signing, and assess that long after the
fact, you have to archive so much extra information that I don't see what
pain is caused by the fact that the certificate has expired by then. It's
not clear to me what if anything you do differently because you have
information directly tied to the certificate - e.g., it was revoked months
later. It doesn't save much in the way of processing to have any such
information directly tied to the certificate, versus tied to some other
piece of information you had to archive.



I'm certainly open to explanations as to what I'm missing; that is, why it's
important to have this information in the certificate and what you'd do
different because of it.  But given that privateKeyUsagePeriod is permitted
in a certificate for those who really want it (it's a SHOULD NOT, not a MUST
NOT unless you want to mark it critical), and I personally don't see any
benefit to it, I'm in favor of leaving the recommendation the way it is in
3280.



                Al Arsenault







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NKInqt068208 for <[e-mail]>; Wed, 23 Jul 2003 13:18:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NKInN7068207 for ietf-pkix-bks; Wed, 23 Jul 2003 13:18:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-3.llnl.gov (smtp-3.llnl.gov [128.115.41.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NKImqt068194 for <[e-mail]>; Wed, 23 Jul 2003 13:18:49 -0700 (PDT) (envelope-from [e-mail])
Received: from catalyst2b.llnl.gov (localhost [127.0.0.1]) by smtp-3.llnl.gov (8.12.3/8.12.3/LLNL evision: 1.3 $) with ESMTP id h6NKIdWe017656; Wed, 23 Jul 2003 13:18:39 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 23 Jul 2003 13:18:30 -0700
To: <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
In-Reply-To: <1be301c3513c$8af27920$[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 09:04 PM 7/23/2003 +0400, Gregory S. Chudov wrote:

>What do you do with your credit card, when it expired?
>Throw it to the trash can? No, you return it to the bank.

Interesting.  But this assumes you can safely return the card ("bank" may 
be 2000 miles away) and here at least I doubt banks would accept the 
practice.  We are simply admonished to destroy the card upon its 
expiration, usually accomplished by slicing it into pieces.  I suppose the 
numbers could be retrieved, but a lot of folks toss old statements in the 
trash as well.

You really return it to the bank?

The point here, though, is that cert-lifes are relatively short precisely 
because of concerns with continued key security.  This makes the certs "act 
like" private key usage limiters, when they are properly "key-to-owner" 
binding limiters.

In the strictest usage, one might refuse to validate a signature today if 
today is beyond the cert expiration, even though the document asserts the 
signature took place earlier (how to know w/o trusted timestamp)?  But as 
Peter points out, this is a real limitation on certificate utility, 
broached by most.

Cheers!  ____tony____


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK1cqt067278 for <[e-mail]>; Wed, 23 Jul 2003 13:01:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NK1btu067277 for ietf-pkix-bks; Wed, 23 Jul 2003 13:01:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK1bqt067272 for <[e-mail]>; Wed, 23 Jul 2003 13:01:37 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (dialup-171.75.41.190.Dial1.Washington1.Level3.net [171.75.41.190]) by smtp3.pacifier.net (Postfix) with ESMTP id EB36F6DA5F; Wed, 23 Jul 2003 13:01:35 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'pkix'" <[e-mail]>, <[e-mail]>
Cc: "Russ Housley" <[e-mail]>
Subject: Draft-ietf-pkix-proxy-06.txt
Date: Wed, 23 Jul 2003 16:01:59 -0400
Message-ID: <002001c35155$4eaf7ee0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1. Section 3.3, para 2:  I think that the MAY in this paragrah should be
lower case.  I do not see these as a protocal statements, but as saying
these are ways that reasonable uniqueness could be obtained for a serial
number.  I assume that other methods of doing this are perfectly
allowable.

2. Section 3.4:  Does the subject name need to be "unique" among all
certificates ever issued by a proxy, or just the active certificates?

3. General:  I am still not comfortable that the issuance of Proxy
Certificates cannot be restricted (or permitted) by a CA when it issues
an EEC.  One method of doing this would be a non-critical ProxyCertInfo
extension with a pCPathLengthConstrant of 0 in the EEC.

4. Section 2.6:  When creating a new PC, where and how is the
negotiations on policy language and policy done?  Should this be
documented as a separate step in the text describing how PCs are
obtained/issued?  Does something need to be done about potentially
asking the relying party as to what policy it requires to perform some
task?

5. Section 3.8.2:  I find the following text

    Note that this 
    verification MUST take place regardless of whether or not the PC 
    itself contains a policy, as other PCs in the signing chain MAY 
    contain conditions that MUST be verified. 

	to be confusing because I always get policyLanguage and policy
mixed up.  I think that all PCs must have policy and so the statement is
difficult to parse.  I don't know that this can be simplified without
renaming the policy field in the extension.  The text in item 1) just
before this refers to policy and should probably refer to
policyLanguage.

6.  Section 4.1.3 next to last paragraph.  Text should be "If steps (a),
(b) or (d) fail,..."

7.  Section 4.2:  I have a complete lack of understanding for the last
three paragraphs in this section.

8.  Section 5.1.2:  Fix "Section Error! Reference source not found"

9.  



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NJQEqt065440 for <[e-mail]>; Wed, 23 Jul 2003 12:26:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NJQE7m065438 for ietf-pkix-bks; Wed, 23 Jul 2003 12:26:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NJQCqt065420 for <[e-mail]>; Wed, 23 Jul 2003 12:26:12 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jul 2003 12:26:09 -0700
Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 Jul 2003 12:26:07 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jul 2003 12:26:12 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jul 2003 12:25:49 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jul 2003 12:26:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: WG Last Call: SCVP
Date: Wed, 23 Jul 2003 12:26:05 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: SCVP
Thread-Index: AcNNLNmn+2Ggli6JSdKd9958vd1dfgCk9jSA
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Jul 2003 19:26:07.0890 (UTC) FILETIME=[44233F20:01C35150]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6NJQDqt065431
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

See below.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Friday, July 18, 2003 6:02 AM
To: Trevor Freeman
Cc: [e-mail]; [e-mail]
Subject: Re: WG Last Call: SCVP

Comments on draft-ietf-pkix-scvp-12.txt
Simple Certificate Validation Protocol (SCVP)

The following 8 issues have been suppressed since there are agreed:
9, 11, 12, 13, 16, 18, 19 and 23.

There remains 16 issues to be discussed. The original numbering has been
kept.

1. Section 1.3 Validation Policies

In this section the wording "validation policy" is used but is left
undefined: "A validation policy can be used to specify the SCVP
configuration." Please define it.

[Trevor Freeman] I have added a reference to 3379 to define validation
policy.

[Denis] Are you going to add a reference to section 7 from RFC 3379 ?

[Trevor Freeman] Actually, I now realise that a simple reference is not
going to work since the current use of validation policies in SCVP does
not cleanly map onto 3379 use of the term. I will redraft SCVP to clean
this up.

This text is copied below.

    A validation policy is a set of rules against which the validation
of
    the certificate is performed.

    A validation policy MAY include several trust anchors.  A trust
    anchor is defined as one public key, a CA name, and a validity time
    interval; a trust anchor optionally includes additional constraints.
    The use of a self-signed certificate is one way to specify the
public
    key to be used, the issuer name, and the validity period of the
    public key.

    Additional constraints for each trust anchor MAY be defined.  These
    constraints might include a set of certification policy constraints
    or a set of naming constraints.  These constraints MAY also be
    included in self-signed certificates.

    Additional conditions that apply to the certificates in the path MAY
    also be specified in the validation policy.  For example, specific
    values could be provided for the inputs to the certification path
    validation algorithm in [PKIX-1], such as user-initial-policy-set,
    initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
    any-policy-inhibit.

    Additional conditions that apply to the end-entity certificate MAY
    also be specified in the validation policy.  For example, a specific
    name form might be required.

    In order to succeed, one valid certification path (none of the
    certificates in the path are expired or revoked) MUST be found
    between an end-entity certificate and a trust anchor and all
    constraints that apply to the certification path MUST be verified.


2. Section 1.3 Validation Policies. The text says: " The validation
policy 
is determined by private agreement between the client and the server,
...".

While this may be one case this is not the single case. Please delete
and simply say: "The validation policy MUST be represented as an OBJECT
IDENTIFIER and optionally some additional parameters.

[Trevor Freeman] I have removed the word private.

[Denis] This does not solve my concern. A validation policy may also be 
determined by a policy issuer, while means that there is no agreement 
between the client and the server. The client wants to use a given 
validation policy defined by a policy issuer. If the server supports it,

then it is fine. If the server does not support it, then the client
looks 
for another server supporting it.

[Trevor Freeman]I will redraft this section and repost.

For the first of the sentence I would thus propose:

"The validation policy may be determined by the server, or any third
party."

For the second part of the sentence, we currently have:

", but it MUST be represented as an OBJECT IDENTIFIER."

I have proposed:

"The validation policy MUST be represented as an OBJECT
IDENTIFIER and optionally some additional parameters."

So the issue is whether we have or not "and optionally some additional 
parameters"

This seems to be the reason of a disagreement on many of the other
points.

The validation policy does not only include the processing algorithms
but 
also the values used by the processing algorithms to validate a
certificate.

The two possibilities, as I see them, are :

- the OID of the validation policy tells everything (i.e. both the 
processing algorithms and all the values to be used by these processing 
algorithms),

- the OID validation policy provides the processing algorithms and some
of 
the values to be used, but some other values may be defined as
additional 
parameters.

Please, reconsider my proposal.


3. In section 3, SignedData is defined with unsignedAttrs being not
used. As 
it will be explained later on, unsignedAttrs should be used to carry 
unsigned certificate values, as well as unsigned revocation information 
(CRLs in particular) while the references (much shorter) will be signed.

This has the major advantage of keeping the size of archived signed 
responses short.

[Trevor Freeman] This is not a requirement in 3379. Correct. However,
this 
is a big advantage in the following case:


The RP wants to keep an archive of "YES" answers. If the values are all 
signed, then the size of the archives will get pretty big since the same
CA 
certificates and CRLs will be duplicated many times in every "YES"
answer. 
If only the references are signed, then the values may be stored
elsewhere 
and only once: the same values will be usable for thousands of
validations.

[Trevor Freeman] This is not a requirement in 3379.

4. Section 3.2. The text currently says on page 9: " The OPTIONAL
valPolicy, trustAnchors, intermediateCerts, and revInfos items provide 
context for the client request."

This sentence should be replaced by the following:

"Either the valPolicy item or the trustAnchors item SHALL be used. The
intermediateCerts and revInfos items provide certificates or revocation
status information which MAY be useful to build the response."

[Trevor Freeman] I disagree since the validation policy alone is not
enough. 3379 does not require that the validation policy and the
parameter used with that policy are represented by a single OID.

[Denis] I do not think that you disagree on the second sentence:
" The intermediateCerts and revInfos items provide certificates or 
revocation status information which MAY be useful to build the
response."

[Trevor Freeman] Wait for the redrafted version

You probably disagree on the first sentence. It is in fact incorrect.
I would thus propose the following:

"Either the valPolicy item alone or both the valPolicy and the
trustAnchors 
items SHALL be used.

The rational is explained in issue 2.


5. Section 3.2.3  wantBack

More options should be allowed to return:

1)  only the references of both the certificates and the associated
revocation status information for the path as a signed parameter,

[Trevor Freeman] This is covered by a certificate status request.

2) both the references of both the certificates and the associated
revocation status information for the path as signed parameter, and the
certificate values together with the associated revocation status
information as an unsigned attribute (see comment 3)

[Trevor Freeman] This is covered by two requests, one for certificate
status and one DPD.

[Denis] This is not optimum, since this could be done by one request.
If this is done in two requests, this may be complicated because there
is no 
assurance that the first DPD request will return the path used by the
DPV 
request. So the client will have to test if the path that is returned is
the 
right one and re-issue a PVD request until it the right one is returned.
If 
you maintain two requests, these additional explanations would be
useful.

[Trevor Freeman] We are past optimisations. I am only considering
critical issues.

Note : certificate values or associated revocation status information as
a signed parameter are not needed when using the two alternatives above.

[Trevor Freeman] This is not a requirement in 3379. The client is at
liberty to ignore the signature.

[Denis] This relates to issue 2.

[Trevor Freeman] Wait for the redrafted version.

It is unclear why *only* the "Public key from the certificate" should be
returned. Either suppress this option, explain why it is sufficient or
return the full certificate.

[Trevor Freeman] This reduces the footprint of a simple client.

[Denis] Maybe. If we keep it, then add the full certificate as another 
possibility.

[Trevor Freeman] Please clarify. We already support returning the
certificate.

6. Section 3.2.5  valPolicy . The text says:

"  The valPolicy item, defines the validation policy to be used by the
     SCVP server during certificate validation.  The client can use this
     instead of specifying other SCVP configuration items such as
     trustAnchors.  The value of this item can be determined by private
     agreement between the client and the server, but it MUST be
     represented as an object identifier.  The server might want to
     assign identifiers that indicate that some settings are used in
     addition to others given in the request.  In this way, the
     validation policy object identifier can be a shorthand for some
SCVP
     options, but not others".

Replace the whole with:

"  The valPolicy item, defines the validation policy to be used by the
     SCVP server during certificate validation.  The client MUST either
     use it or use trustAnchors which allows to define relatively simple
     validation policies".

[Trevor Freeman] I have removed the second sentence and the word
"private" from the third sentence.

[Denis] This does not solve my concern. See issue 2.

[Trevor Freeman] I am redrafting this.

I would propose the following rephrasing:

"  The valPolicy item, defines the validation policy to be used by the
     SCVP server during certificate validation.  The client MUST either
     use it or use it in combination with trustAnchors. The second
option
     allows to define relatively simple validation policies".
[Trevor Freeman] agreed


7. Section 3.2.5  valPolicy . The text says: "All SCVP servers MUST
support 
the default policy". This is fine. However, it is important that the
client 
may know the parameters of the default policy when the default policy
has 
been used by the server. So the default policy SHALL define its
parameters.

[Trevor Freeman] the default policy has no parameters - it is a set of
rules 
as per 3379.

[Denis] As explained in issue 2, a validation policy must at least
define 
one root key, so it is not true to say that it has no parameter.

[Trevor Freeman] Not true. Both the default policy and the Name
comparison policy do not define a trust root. The trust root must be
supplied in the request or the server chooses.

In order to be able to use this protocol with Qualified Certificates (as
per 
the European Directive on Electronic Signatures) certPolicies should
further 
be subdivided in two categories: certPolicy for the end-entity
certificate 
and certPolicies for CA certificates (currently CA certificates do not
have 
certPolicies mandated as per the European Directive on Electronic
Signatures).

It is thus propose to defined three parameters for the default policy:

   - trustAnchors,
   - certPolicy for the end-entity certificate,
   - certPolicies for CA certificates.

As mentioned in the text, revocation conditions include any source of
revocation available.

[Trevor Freeman] This is not a requirement for 3379. The trust anchors
are specified in the request or the sever choose. You requirements are
accommodated by two requests, one for the end cert, and one for the CA
cert or define another algorithm.

[Denis] No. This would not solve my concern. The EESSI  standards built
upon 
the EU Directive ask for a given CP to be present in the end-entity 
certificate, but place no such constraint on the CP from the CA 
certificates. It would however be nice to be able to use the default 
validation policy in such a case.

[Trevor Freeman] My previous answer still stands. Two requests using the
default policy meets your request.

8. Section 3.2.5.1 The need and the rational for this section could not
be understood: an OID unambiguously identity a validation policy, a
"name
Validation Policy" or "Validation Policy name" (?) would not add
anything.

Please explain or delete.

[Trevor Freeman] This was asked for at IETF 56 as an example for another
validation policy.

[Denis] Adding an explanation in the document like "This was asked for
at 
IETF 56" would not be sufficient.

[Trevor Freeman] disagree. Its documented on the list along with
countless other issues not in RFCs.

:-)

I still do not understand. Please provide additional explanations in the

main body of the document (or delete).


10. Section 4 Validation Response. The text states: " An unsigned
response 
MUST only be generated for an error status". This is contradictory with
the 
preamble where it is said:

"SCVP can be used by clients that do much of the certificate processing
themselves but simply want an untrusted server to collect information
for them."

When simply collecting certification paths, responses do not need to be
signed. Thus clients should have a way to indicate whether they want
signed responses or not.

[Trevor Freeman] This is not a requirement in 3379. The client can
ignore the signature.

[Denis] I disagree. This is a DPD requirement. RFC 3379 states:

    For the client to be confident that all of the elements from the
    response originate from the expected DPD server, an authenticated
    response MAY be required.

Signing takes time and resources. Please do not mandate the signing
operation.

[Trevor Freeman] We are conformant with 3379. The server decides and may
return a signed or unsigned response.


14. Section 4.4 requestReference, page 22. The text states: "However,
the 
requestNonce provides a better mechanism for matching requests and 
responses". This is incorrect. Change into:

"While requestRef allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

[Trevor Freeman] disagree

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.

[Trevor Freeman] I don't think you assertion that the current text is
incorrect - is correct.


15. Section 4.4.1  requestHash, page 23. The text states: "However, the 
requestNonce provides a better mechanism for matching requests
andresponses."

This is incorrect. Change into:

"While requestHash allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

[Trevor Freeman] disagree

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.

[Trevor Freeman] I don't think you assertion that the current text is
incorrect - is correct.


17. Section 4.6 responder, page 23. The text states: "The OPTIONAL
responder 
item is used to identify the server." The rational for this parameter is
not 
clear. In PKIX, the subject item from a certificate allows to identify a

server. Since it is unrelated, it is very doubtful to have a value
chosen by 
the client which has only local significance to the SCVP server. Please 
explain or delete.

[Trevor Freeman] This is a requirement of 3379.

[Denis] Maybe, but where from ? I would guess that this item is only
needed 
to detect a loop when chaining is being used. If this is the case,
please 
add such explanations and what the client SHALL do with it. If this is
not 
the case, please add the appropriate explanations.

[Trevor Freeman] Since you are an author of 3379, I would expect you to
be better placed to answer why this is in 3379.


20. Section 4.7.5 page 28. The text states:

    "The octet string value for the AC issuer certification path used to
     verify the certificate in the request, { id-swb 5 }, contains the
     CertBundle type.  The syntax and semantics of the CertBundle type
     are described in section 3.2.7."

As already mentioned, since

     CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference

and

       PKCReference ::= CHOICE {
         cert              [1] Certificate,
         pkcRef            [2] ESSCertID }

The client should be able to say in his request whether he wants back
cert 
or pkcRef. If within the signed response he gets pkcRef, then he should
be 
able to say that he wants CertBundle with the option cert as an unsigned

attribute. The integrity of this unsigned parameter can easily be
checked 
using the signed pkcRef.

[Trevor Freeman] disagree

[Denis] See item 3.

[Trevor Freeman] See my response to item 3.

21. Section 4.7.6 valPolicy, page 29. The text states: "The valPolicy
value 
MUST NOT be id-svp-defaultValPolicy".

If the default policy has been used, then the client MUST be able to
know which one it was: the default policy may vary with the time.

Change into:

"When the valPolicy value is id-svp-defaultValPolicy, then all the
parameters from that policy MUST be returned."

[Trevor Freeman] Disagree. If the client wants all the parameters used
with the validation policy, then they can ask for the request to be
included in the response.

[Denis] Fine. However, it would be nice to include this explanation in
the 
document.

[Trevor Freeman] Agreed.


22. Section 6 Validation Policies Response. The text states: "The
response 
is not signed by the server". It would be nice to include a variant that

would allow the response to be signed.

[Trevor Freeman] Disagree.

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.

[Trevor Freeman] Actually I have reconsidered this and have changed my
position and now will mandate that this will be signed.


24. Addition. At present, PKCReference is defined as:

        PKCReference ::= CHOICE {
         cert              [1] Certificate,
         pkcRef            [2] ESSCertID }

In OCSPv2 a third alternative, i.e. certIdWithSignature has been
introduced. 
It would be interesting to be able to support it. It allows an
OCSPserver 
(and thus an SCVP server) to answer when it does not have access to the 
value of the certificate (in particular when it *only* uses CRLs in the 
background), whereas ESSCertID would be useless.

certIdWithSignature is a compact way to specify unambiguously a
certificate 
and to allow to verify a certification path.

     CertIdWithSignature ::= SEQUENCE {
          issuerandSerialNumber     IssuerandSerialNumber,
          tbsCertificateHash        BIT STRING,
          certSignature             CertSignature
     }

IssuerandSerialNumber is defined in [RFC3369] section 10.2.4.

tbsCertificateHash contains a hash value computed over the ASN.1 DER
encoded tbsCertificate field from the certificate using the hash
function identified in the signature algorithm from the signature.

certSignature contains the signature fields from the certificate.

     CertSignature ::= SEQUENCE {
          signatureAlgorithm        AlgorithmIdentifier,
          signatureValue            BIT STRING
     }
[Trevor Freeman] Disagree. This is not a requirement in 3379.

[Denis] Yes, this is not in RFC 3379 but this comes from an observation
made 
after RFC 3379 was done and when the OCSPv2 draft was written. Please
take a 
closer look at this issue.

[Trevor Freeman] disagree. The SCVP server MUST have the certificate to
build a response. This is a MUST in 3379.

Denis





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NJFhqt063584 for <[e-mail]>; Wed, 23 Jul 2003 12:15:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NJFhD9063583 for ietf-pkix-bks; Wed, 23 Jul 2003 12:15:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NJFgqt063575 for <[e-mail]>; Wed, 23 Jul 2003 12:15:42 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25468; Wed, 23 Jul 2003 15:15:41 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-07.txt
Date: Wed, 23 Jul 2003 15:15:41 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-07.txt
	Pages		: 45
	Date		: 2003-7-23
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-07.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NH58qt054545 for <[e-mail]>; Wed, 23 Jul 2003 10:05:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NH58Xs054544 for ietf-pkix-bks; Wed, 23 Jul 2003 10:05:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx2.cryptopro.ru (mx2.cryptopro.ru [213.59.158.218]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NH4tqt054529 for <[e-mail]>; Wed, 23 Jul 2003 10:04:57 -0700 (PDT) (envelope-from [e-mail])
Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 21:04:56 +0400
Message-ID: <1be301c3513c$8af27920$[e-mail]>
From: "Gregory S. Chudov" <[e-mail]>
To: <[e-mail]>
Cc: =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Date: Wed, 23 Jul 2003 21:04:56 +0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 23 Jul 2003 17:04:56.0939 (UTC) FILETIME=[8B0EB3B0:01C3513C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Ströder wrote:
> Personally I see no use of PKUP extension. How long signatures created
with
> a private key associated with a PKC can be validated should not be
specified
> in a public-key certificate. The more natural solution to me is to specify
> this in the policy and cryptographic protocol used for signing the
message.
It's NOT about signatures validity. It's about private key policy.
Unfortunately, this very useful extension becaume a victim
of misinterpretaion of it's purpose.

In practice, the private key does have a validity period, which is often
shorter
than the validity of a corresponding certificate.
The key, which is used for too long, has very high probability to become
lost,
forgotten, compromized in any other way, so this period is normally small -
a year or less.
While the certificate can last for many years.
Without this extension, we can only tell the person not to forget
to get a new certificate and dispose of his old private key
within given period of time.
Using this extension, we can force a person to do this,
because this policy is written right there, in his certificate.

CA can grant him a certificate with a simple condition:
he MUST destroy his public key before it expires.
If he forgot about his key, and did not notify CA
that the key was destroyed, well, that means the
key is potentialy compromised and certificate should be revoked.

What do you do with your credit card, when it expired?
Throw it to the trash can? No, you return it to the bank.

Certificate expiration time is like a bumper for a train.
Bumper makes sure the train doesn't do too much damage,
if the brakes are broken. But the normal situation
is when the train stops normally, never reaching the bumper.

PrivateKeyUsagePeriod is like those breaks, it is a normal way
to stop using a key when it's time.

Good luck,
Greg Chudov.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NGwqqt054020 for <[e-mail]>; Wed, 23 Jul 2003 09:58:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NGwqF5054019 for ietf-pkix-bks; Wed, 23 Jul 2003 09:58:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NGwoqt053998 for <[e-mail]>; Wed, 23 Jul 2003 09:58:50 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6NGwZ4X220056; Wed, 23 Jul 2003 12:58:35 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6NGwSoc159816; Wed, 23 Jul 2003 12:58:29 -0400
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Subject: Re: Why is privateKeyUsagePeriod deprecated?
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 23 Jul 2003 12:58:17 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPRs JHEG5JQ5CD, THTO5KLVS6, JHEG5HMLFK, JCHN5K5PG9|March 27, 2003) at 07/23/2003 12:58:33, Serialize complete at 07/23/2003 12:58:33
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Peter, I'd codify what they're doing as follows:

    The validity period for a certificate is the period of time from 
notBefore
    through notAfter, inclusive.  When an RP is validating the signature 
on a 
    document which claims to have been signed or produced at a given past 
time,
    the RP SHOULD proceed with the verification of the signature if that 
time
    is within the validity period even though the time of verification is 
outside
    it.  If the RP requires authoritative proof either of the time at 
which the 
    document was signed or of the certificate's not having been revoked, 
it MAY
    reject the signature.

        Note that TSP deals with only one of the two conditions in the 
MAY.
 

Tom Gindin
I/T Architect - Security
IBM Business Consulting Services - Public Sector
Phone [phone]





[e-mail] (Peter Gutmann)
Sent by: [e-mail]
07/22/2003 09:32 AM

 
        To:     [e-mail], [e-mail]
        cc:     [e-mail]
        Subject:        Re: Why is privateKeyUsagePeriod deprecated?




Stephen Kent <[e-mail]> writes:

>I was not an author for 2459 or 3280, but my feeling is that we do not
>recommend use of PKUP for several reasons:

But those are mostly just hypothetical objections.  At the moment we have 
two
inescapabable facts:

1. CAs issue certs based on a 1-year billing cycle, and nothing anyone 
says
   will change that.  No CA will issue a cert with a 20-year lifetime, 
unless
   it's for its own CA certs.

2. Users need to use certs to validate signatures at n times the 
CA-ordained
   lifetime.  In the abscence of any mechanism to do this, they are 
ignoring
   the cert expiry time.  In other words, out of necessity, they're making 
the
   following change to RFC 3280:

    The validity period for a certificate is the period of time from 
notBefore
    through notAfter, inclusive.  When used with signing certificates,
    implementations SHOULD NOT pay any attention to the notAfter date.

Given that this isn't going to change, it would seem that some guidance 
for
users would be useful here.  Since neither (1) nor (2) can be altered, 
what
would be needed is a simple extension, found in signing certs, containing 
a
date to which the cert can still be used for signature-checking beyond the
obvious notAfter value.  This could be written up as a short one-page
application note, no more (well, a bit more once you add all the usual
boilerplate and whatnot).

Now CAs can still decide not to issue certs like that, but (a) they can't
justify it by claiming it screws up their standard cert cycle because it
doesn't affect validTo/validFrom, and (b) users at least have some 
guidance as
to what to do, which is better than the current situation where all they 
can
do is ignore parts of the standard on an ad hoc basis.

Peter.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NFPcqt050548 for <[e-mail]>; Wed, 23 Jul 2003 08:25:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NFPchW050547 for ietf-pkix-bks; Wed, 23 Jul 2003 08:25:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NFPaqt050537 for <[e-mail]>; Wed, 23 Jul 2003 08:25:36 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6NFOuoY031078; Thu, 24 Jul 2003 03:24:56 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6NFOtq26969; Thu, 24 Jul 2003 03:24:55 +1200
Date: Thu, 24 Jul 2003 03:24:55 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>RFC 3126 provides some guidance :
>
>    If a recipient wants to hold a valid electronic signature he will
>    have to ensure that he has obtained a valid time stamp for it, before
>    that key (and any key involved in the validation) is revoked.  The
>    sooner the time-stamp is obtained after the signing time, the better.
>
>However, since the "sooner is the better", it is not mentioned explicitly
>that the time-stamp token MUST be obtained at latest before the end of the
>validity period of the certificate (since a CRL does not include the serial
>number of a certificate once it has expired) and the CRL (or OCSP response)
>close to that time MUST be captured.

Right, timestamping (and 3126) would definitely be the proper solution to the
problem.  Unfortunately though it's little-used (and seems unlikely to be
adopted) in the particular area where this type of long-term signature
validation needs to occur, which is in EDI transactions (I'm sure it occurs
elswhere as well, but when I hear people wanting to use expired certs to
verify sigs it's usually in this area).  Typically the requirement for these
things is that you archive copies of all messages going back to the beginning
of time, and have to verify signatures using archived certs at some arbitrary
point in the future.  This is just an updated form of the "securely archive
everything forerever" in interchange agreements. In other words they've taken
the rather vague "archive it securely" and made it more concrete as "archive
messages in signed form so they can be verified as untampered at a later
date", with variations depending on which industry group and/or set of
agreements is in effect.

So what you have is:

- Signed data that must be stored over long periods of time (possibly
  decades).

- Certs with a one-year lifetime (see my earlier posting).

- People in need of guidance as to how they can reconcile the two, within the
  framework that they already have (which unfortunately excludes adding
  additional external services, at least until the EDI standards and
  interchange agreements are all renegotiated, although I suspect the main
  change that will take place at that point is a switch to XML or whatever
  else is trendy at the time).

Let me ask some of the people (at least the ones I can remember) who've
brought this up in the past to see what they'd actually need done.

Incidentally, one amusing/scary side-effect of using certs after they've
expired is that the CA generally no longer bothers issuing CRLs for them
(since they've expired), but they're still being used to validate signatures
beyond the 1-year billing period.  As a result, it's impossible to perform
revocation checking on the cert.  I guess if you're ignoring the expiry date
you may as well ignore revocation checking as well :-).

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NEu7qt049393 for <[e-mail]>; Wed, 23 Jul 2003 07:56:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NEu7Ll049392 for ietf-pkix-bks; Wed, 23 Jul 2003 07:56:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NEu4qt049384 for <[e-mail]>; Wed, 23 Jul 2003 07:56:05 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6NEtuoY028861; Thu, 24 Jul 2003 02:55:56 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6NEtu926888; Thu, 24 Jul 2003 02:55:56 +1200
Date: Thu, 24 Jul 2003 02:55:56 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:

>Personally I see no use of PKUP extension. How long signatures created with a
>private key associated with a PKC can be validated should not be specified in
>a public-key certificate. The more natural solution to me is to specify this
>in the policy and cryptographic protocol used for signing the message.

That would make it a CMS issue, which doesn't seem right.  It's the cert
that's expired, not the CMS signature.  In other words it doesn't matter what
sort of signing attributes you stick in the signature, the problem is that as
far as the cert-checking code is concerned, the cert has expired and is
therefore no longer allowed to be used.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N9Kuqt022421 for <[e-mail]>; Wed, 23 Jul 2003 02:20:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N9Ku2j022420 for ietf-pkix-bks; Wed, 23 Jul 2003 02:20:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (cxxix.yapay.inka.de [193.197.185.3]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N9Krqt022412 for <[e-mail]>; Wed, 23 Jul 2003 02:20:54 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 51EC029AAA; Tue, 22 Jul 2003 17:49:39 +0200 (CEST)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 4610922C2F; Tue, 22 Jul 2003 17:49:38 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 22 Jul 2003 17:49:38 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030626
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> Yes, because they want to use the signing key (relatively) short-term, but be
> able to verify sigs using the public portion years after the private portion
> has been retired/destroyed/lost/whatever.

Again I'm astonished to see this discussion here. It shows like other 
discussed topic how much disagreement is here about very basic topics.

Personally I see no use of PKUP extension. How long signatures created with 
a private key associated with a PKC can be validated should not be specified 
in a public-key certificate. The more natural solution to me is to specify 
this in the policy and cryptographic protocol used for signing the message.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N3C2qt086545 for <[e-mail]>; Tue, 22 Jul 2003 20:12:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N3C2DQ086544 for ietf-pkix-bks; Tue, 22 Jul 2003 20:12:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6N3Bxqt086534 for <[e-mail]>; Tue, 22 Jul 2003 20:12:00 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 3544 invoked by alias); 23 Jul 2003 03:11:59 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 3536 invoked by alias); 23 Jul 2003 03:11:58 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 23 Jul 2003 03:11:58 -0000
Received: (qmail 6367 invoked from network); 23 Jul 2003 03:11:57 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 23 Jul 2003 03:11:57 -0000
Date: Wed, 23 Jul 2003 12:11:58 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Cooper,

> 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:       
>                           Certification Path Building
> 	Author(s)	: M. Cooper, Y. Dzambasow
> 	Filename	: draft-ietf-pkix-certpathbuild-00.txt
> 	Pages		: 59
> 	Date		: 2003-7-3

This is an excellent trial.

Sorry for my delayed comments below.

1. path building over http

This text gives an example as path building algorithm based over LDAP.
Shall we consider also about a path building algorithm over http?
# I know and agree that  basically path building is used in the
environment which have directory system.
IMHO, path building over http may be achieved using cAIssuers
accessMethod in AIA extension, but it only describes single path like
strict hierarchy.


2. forward direction vs. reverse direction

My basic opinion is shown below as hybrid path building.
=====
Path building in the forward direction is very useful for tree topology
that each node has unique parent.
However, when each node has plural parent (e.g., mesh PKI or bi-lateral
cross-certified PKI), this method is useful only a bit.
First, therefore, a builder SHOULD attempt to build a path in the
forward direction till a self-signed certificate (or maybe intermediate
certificate issued by plural CAs).
Then, the builder MAY attempt to build the remain path either way.


        2) Path building by the reverse direction
        ----------------------------------------->
   +---------+     +--------------+      +-------------+   
   | Trusted |     | Intermediate |      | Self-Signed |   
   |  Root   |---->|  Certificate |----->| Certificate |   ^
   +---------+     +--------------+      +-------------+   |
                                                |          |
                                                |          |
                                                v          |
                                        +----------------+ | 1) Path
                                        |  Intermediate  | | building
                                        | Certificate(*) | |    by
                                        +----------------+ |  forward 
                                                 |         | direction
                                                 |         |
                                                 v         |
                                         +--------------+  |
                                         |     Target   |  |
                                         |  Certificate |   
                                         +--------------+   
        (*) Not self-signed certificate.
# I know more consideration yet is required for this.
=====

And this topic has one problem.
Some subordinate CA populate their CA certificate to issuedToThisCA of
crossCertificatePair attribute in their own (CA) directory entry. On the
other hand, most cross-certified (not subordinate) CA also populates
their cross-certificate to same location.
When a path builder attempts hybrid building as above, the builder in
second step (reverse direction) does not require obtaining the
subordinate CA information.


In almost (hierarchical) PKI, path building may finish before second step.
Only in some complex PKI, path building may need second step. Anyway,
this hybrid algorithm is useful for every PKI, I think.


3. Static path vs. Dynamic path
Static certification path means that the client is given beforehand all
certificates and all revocation information required for path validation.
On the other hand, dynamic certification path means that the client at
least must obtain some certificates and revocation information required
for path validation. Dynamic certification path may use some
certificates and revocation information in certificate store or local
cache.
For a client that cannot build a certification path dynamically,
we should consider static certification path, e.g., SSL/TLS handshake.


Your I-D describes that how build a certification path, and my 'memo for
mPKI' I-D aims to support how to design a certification path.
So I hope to review our documents each other frequently.

Best Regards,
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3551)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MKP0qt069695 for <[e-mail]>; Tue, 22 Jul 2003 13:25:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MKP00I069694 for ietf-pkix-bks; Tue, 22 Jul 2003 13:25:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MKOxqt069681 for <[e-mail]>; Tue, 22 Jul 2003 13:24:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 19f3gt-000580-00; Tue, 22 Jul 2003 22:24:55 +0200
From: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Reply-To: "Diego Fernandez" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 22 Jul 2003 20:24:56 GMT
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: es
Subject: Re: Why is privateKeyUsagePeriod deprecated?
X-Accept-Language: es
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry, my latest mail was incomplete.

>From my point of view, the PKUP is a strong extension for CA certs.

The certs issued by a CA can be verified during the overall CA cert 
validity time.
The CA extensions will show when it will be necessary to renew the CA 
cert because of the private key, and which is the maximum period of 
validity time for final certs (notAfter field of a final cert will 
never be exceeding notAfter CA)

Kind regards,

Diego.  




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MJqmqt068680 for <[e-mail]>; Tue, 22 Jul 2003 12:52:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MJqmQv068679 for ietf-pkix-bks; Tue, 22 Jul 2003 12:52:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MJqgqt068674 for <[e-mail]>; Tue, 22 Jul 2003 12:52:42 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA172048; Tue, 22 Jul 2003 15:52:38 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>
Cc: "'PKIX List'" <[e-mail]>, "'Matt Cooper'" <[e-mail]>, "'Yuriy Dzambasow'" <[e-mail]>, "'Susan Joseph'" <[e-mail]>, "'Richard E. Nicholas \(Nicholas, Richard\)'" <[e-mail]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Tue, 22 Jul 2003 15:52:17 -0400
Organization: Gemini Security Solutions, Inc.
MIME-Version: 1.0
Message-ID: <00cb01c3508a$c4f47590$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C6_01C35069.39F26180"
Importance: Normal
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00C6_01C35069.39F26180
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve,

I have yet more comments inline.  I've done my best to split it up but
it's getting harder to read, I'm sure!  Sorry for not getting back to
you sooner, but I was on vacation. 

   -----Original Message-----
   From: [e-mail]
[mailto:[e-mail]] On Behalf Of Steve Hanna
   Sent: Monday, July 14, 2003 4:12 PM
   To: Peter Hesse
   Cc: 'PKIX List'; 'Matt Cooper'; 'Yuriy Dzambasow'; 'Susan Joseph';
Richard E. Nicholas (Nicholas, Richard)
   Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
   
   
   Good to hear from you, Peter! Long time no see.
   Responses inline below.
   
   > I'm glad to see more discussions of certificate path building. In a

   > non-hierarchical PKI where relying parties have different trust 
   > anchors, path building is essential. And it's not easy!
   > 
   > However, I don't think that we're ready to have an official 'best 
   > practices' document on path building yet. Very few people have 
   > implemented PKIX-compliant path building (only Sun and 
   > Cygnacom/DigitalNet, I think) and there are many areas that are
still 
   > unclear.
   > 
   > <PMH> What is PKIX-compliant path building exactly? I am not aware
of 
   > any documents that define this. This is a part of the reason why
there 
   > is a need for this document.</PMH>
   
   I don't have any objection to defining the term "PKIX-
   compliant path building". But I don't think you need 59
   pages to do that. You could do that in one sentence. 

<PMH> We can certainly work on the size of the document, although the
document is certainly shorter than some PKIX documents and longer than
others. </PMH>

   It's simply the process of building certification paths
   that are valid according to RFC 3280.

<PMH> I think the main problem we have is that the process is not
simple, else there would be more robust implementations that claimed
PKIX path building capability.  (Sun's Java CertPath, CygnaCom/Entrust
internal and external libraries, and DigitalNet CML are the only robust
implementations I know of.) </PMH>  
   
   Most of the document describes and recommends specific 
   algorithms for path building. I don't think that we have 
   anything approaching agreement on these algorithms yet.
   
<PMH> The document only discusses two basic algorithms for path
building, from the root toward the target, and from the target toward
the root.  Most of the document is spent discussing optimizations a
developer can make to support their path construction, as well as common
problems with path development implementations and how they can be
avoided.  The entirety of the document is just informational and
recommendations, it is not by any means prescribing methods.  </PMH>
   
   Fortunately, there is no need for consensus in this area.
   I can use one path building algorithm and you can use 
   an entirely different one without affecting 
   interoperability. So I see no need to rush to publish 
   an RFC on this topic.
   
<PMH> You are absolutely correct, that is why we wish to make this an
informational RFC and not a part of the standards track.  (I now see
that there is no mark in the draft of this being in the Informational
category, but that is certainly our intention.) </PMH> 
   
   Nobody has written RFCs on "how to write an OCSP server".
   As long as you comply with the protocol spec, you'll be
   able to interoperate just fine. The same should be true
   with respect to path building.

<PMH> I don't think this is a good example, because path building is not
a protocol.  It is fairly easy to get bits on a wire the way you want.
Given the size and complexity of RFC 3280, it is a bit harder to tell
someone to go forth and build an implementation that handles all the
cases RFC 3280 may throw at them. </PMH> 
   
   And I even think it may be a fine thing to have an RFC
   saying "here's how to solve the tricky problem of cert
   path building", once we have agreement on that. But I
   don't think we're close to that yet.

<PMH> Sections 3-7 of the document attempt to address 'how to solve the
tricky problem'.  Being an informational RFC, the goal here is not to
prescribe a solution but provide tools to developers.  After some amount
of time (possibly never) the PKIX community may choose to reexamine and
prescribe a particular method for path building--but I doubt it.  This
is not our intention. </PMH>  
   
   If you have a strong argument for why we *need* an RFC on
   path building *soon* (even if it's still an active research 
   area), then maybe an Experimental RFC would suffice.

<PMH> As I said before, we intend it to be Informational.  I don't think
Experimental is really the right category, in my view that is more for
protocols. </PMH>    
  
   > The I-D just published presents one early perspective on these 
   > questions, not a consensus.
   > 
   > <PMH> I disagree that the document provides one early perspective,
it 
   > describes many different scenarios and many different ways of
dealing 
   > with them.</PMH>
   
   I hope we can avoid the need to have many different ways
   of solving this problem. Otherwise, it will not be possible
   to have general-purpose mass-market software that will work
   in all sorts of PKI topologies. I expect that we can come
   up with some good general-purpose algorithms, but I think 
   it will take some time and some real data showing how 
   different algorithms perform in different environments.

<PMH> I'm a little confused by your point here, at first it seemed you
were against a prescribed method, and now it seems you're afraid of too
many methods.  Regardless, this document was intended to demonstrate a
series of general purpose optimizations that could be cobbled together
to form an algorithm.  It's like opening up a toolbox and preparing to
repair something.  Just because you have all the tools doesn't mean
you'll use them all.  I expect the end result to be many implementations
that may differ slightly but all are more robust than the current state
of things. </PMH> 
   
   > <PMH>This document was developed by five different authors from
four 
   > different companies, all of which having varied amounts of
experience 
   > building path development algorithms for many different
environments, 
   > from pure mesh style (Entrust style?) to strict hierarchy to bridge

   > ca.</PMH>
   
   Did these folks actually work on four or five separate 
   implementations of path building and pull together their 
   ideas? Or did they all work on one or two implementations
   (maybe successive versions)?

<PMH> Well, I asked for it.  There are four different implementations of
path building represented.  The first never made it as a library but was
integrated into software written by CygnaCom in the '97-'98 timeframe.
CPDL was developed from the ground up but used some of the same
optimizations.  CML integrated CPDL for a while but now implements its
own.  And developers of Entrust's internal path-building capability are
represented.  Not to mention my work with you on JSR55, although that
was more about API and less about functionality.  The authors will
gladly share other curriculum vitae points as necessary :) </PMH> 
   
   I hate to ask personal questions like that, but you raised
   the issue and maybe I'm just unaware of these many separate
   implementations of PKIX-compliant path validation. If so, 
   then I guess I'm just not very well plugged into the path 
   building community and this really does represent a community 
   consensus (although I'm still disturbed by the lack of hard 
   data). But if the authors actually worked on a single project, 
   then I don't think that represents rough consensus within IETF.

<PMH> Our experience is certainly broader than that of a single project,
not just in the development of path building algorithms but also in
their use and tuning.  Additionally, as an Informational RFC, I don't
necessarily know that this document or our experience needs to form a
rough consensus of the entire IETF.
   
   > <PMH>The document attempts to discuss many
   > of the previously encountered problems and decisions based upon
those 
   > problems, but does not make any hard and fast rules on which way 
   > future implementations should be developed.</PMH>
   
   No, but it contains many recommendations. Just search for 
   "recommend" or "should" in the document. 
   
<PMH> We say "recommend" and "should" to avoid making requirements and
"must"s.  We make clear through the document that it is a best practices
guideline.  </PMH>
   
   And I don't see or know of data to support these recommendations.

<PMH> Aside from DPD/DPV where requirements were defined, what other
RFCs required the documentation and use of real-world data in their
development?  Adding this requirement seems unfair. </PMH>     
   
   > For now, I suggest that people who have implemented path building 
   > publish their insights, results, and ideas either as individual
I-Ds 
   > without the intent to become an RFC or as research papers. Then we
can 
   > discuss these results and ideas, test them in real-world scenarios,

   > and arrive at a consensus on what Best Current Practices should be 
   > included in a BCP document on this topic. We might even want to
start 
   > an IRTF research group or an informal discussion group to
coordinate 
   > this research, sift through the results, and arrive at a solid and 
   > well-supported consensus. This effort will take some time, but I 
   > expect it will produce much better results.
   > 
   > <PMH> X.509 has existed in one form or another since 1988, and
after 
   > 15 years I think we owe the community some amount of tried and true

   > guidance toward path building.  Does this document have all the 
   > answers on what the best way is to build paths? No--but the
document 
   > states that very fact repeatedly--different environments will
always 
   > lead to different optimizations for that environment. </PMH>
   
   While X.509 has been around for many years, non-hierarchical 
   topologies are a fairly recent development. I haven't seen 
   any data comparing how different path building algorithms 
   perform in different non-hierarchical topologies. So I don't 
   think we know enough yet to say which algorithms are best.

<PMH> I couldn't agree more.  However, I can say that in the different
topologies I've worked in, (and having previously worked with/for
Entrust and so closely in the Bridge CA demonstrations you know the
majority were non-hierarchical) the things we outline in this document
are useful! </PMH> 
   
   The current I-D lists 20 different sorting techniques, but
   it doesn't provide any hard data about which work better in 
   which topologies. And I suspect there may be other 
   techniques that might be better. I'm not suggesting 
   that you publish an RFC full of graphs showing which 
   technique is best in which environments. That probably 
   belongs in a research paper. The RFC can then point to 
   the research paper.

<PMH> Again, I am not sure why there is a need for hard data before
publishing some best practices guidelines.  We did discuss taking
section 3.3 out of the document and referring to it elsewhere, but we
could not find similar examples in other RFCs.  Nor did we want to be
constantly updating that second document :) </PMH> 
   
   > If it's felt that we really need a BCP on this topic in
   > short order, then I think it should be restricted to things that we

   > are fairly sure are good practices (like advising CAs to include
name 
   > constraints and AIA in certificates to help path building and
advising 
   > path builders to ensure that they handle simple hierarchical PKIs 
   > quickly but still handle complex PKIs properly).
   > 
   > <PMH> This draft focuses on path building, not best practices for
how 
   > authorities should structure things to simplify building.  Perhaps 
   > that should be the topic of another I-D.  During drafts we
discussed 
   > prioritizing different optimizations saying "you definitely should
do 
   > A,B,C and probably do D,E,F," etc.  However we decided not to
because 
   > we wanted to make the developers free to make their own decisions 
   > based upon the environments with which they were working. </PMH>
   
   My point was that we should restrict any BCP to things
   that we (the PKIX working group) can agree (via rough
   consensus) are actually good practices. 
   
<PMH> The I-D was published to create just such a starting point.  Now
is the time for people to tell us where we're wrong! </PMH> 
   
   Maybe we should
   have two BCPs: one on path building techniques and one
   things CAs can do to make path building easier. At this
   point, I suspect you could easily distill all of our
   wisdom in each of those areas into one or two pages.
   So let's set aside the question of whether they should
   be separate documents.
   
   I'd really like to know why we need to have an RFC on 
   path building now, since it seems to be an internal matter 
   for relying parties with no interoperability implications, 
   except with respect to things that CAs can do to make 
   path building easier.

<PMH> Our document has a section on Motivation that I think accurately
shows why we need this document, and why we need it now.  (Or maybe even
a couple years ago.)  I guess you and I can argue this all day, but the
PKIX WG will have to stand up and be counted on whether there is a need
for this RFC. 

I will honestly tell you that I discussed path building with
representatives of two large PKI vendors a few years ago while
performing the Bridge CA demonstrations.  When I asked why they did not
have robust path building capability, their answer was 'because there is
no RFC for it'.  *That* is one of my prime motivations. </PMH>
   
   Thanks,
   
   Steve
   
   P.S. I'm sorry I can't make it to Vienna this week, since
   I think we could have a much more productive and relaxed 
   conversation over a few beers. Maybe we can schedule a 
   time to grab a few beers and talk on the phone. Failing 
   that, we can continue discussing this by email. But rest 
   assured that I have complete respect for your work. And 
   I'm most interested in what we can do to increase PKI 
   deployment and usage. If you can convince me that 
   publishing this document is a good way to help in that 
   area, I will be glad to help champion it. But I may 
   offer some suggestions for changes.
   
<PMH> I too was not in Austria and would have happily met up for a few
beers to continue this discussion.  (I had a good excuse, I was on
vacation with my wife and 7 week old daughter!)

We definitely want feedback and will be happy to hear any suggestions
for the document.  I look forward to continued productive conversations
on the topic, in person, on the phone, or by email.  I hope the end
result is a product that the PKIX community will be happy with, and will
help other developers to create robust path building implementations.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

------=_NextPart_000_00C6_01C35069.39F26180
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1zCCAokw
ggHyoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCVVMxKDAmBgNVBAoTH0dlbWlu
aSBTZWN1cml0eSBTb2x1dGlvbnMsIEluYy4xIjAgBgNVBAMTGUdTUyBDZXJ0aWZpY2F0ZSBBdXRo
b3JpdHkwHhcNMDIwNDI1MjE1NjI3WhcNMDUwMjEyMjE1NjI3WjBbMQswCQYDVQQGEwJVUzEoMCYG
A1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAGA1UEAxMZR1NTIENlcnRp
ZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtl3UwxhHyP05YqIF
kyfkWt8669gO/VKxC51PhJaV+hb9swwtaMVtJ9k8WjfQLt3fZpaNCNKB7V61KHxY1K1JCP67AwBy
W4TRuGRwEb+PXu5XdpNs3kxKtunlR4/WPsrrvuMx9/R/Fx9ld3TUqXCJ/JN7Zg68IappkcMy9S3w
koECAwEAAaNdMFswHQYDVR0OBBYEFJpr3UY3Hh5dngW5n9h72/GKMy7GMB8GA1UdIwQYMBaAFJpr
3UY3Hh5dngW5n9h72/GKMy7GMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBAHSd4BGG4le+QZBw/6bCq6mGpr4aJAE7UuXEW/I5YXqlQs1CkAzEHV8UnnXgDd0xONTQ
CdznbzCBNAE1EoxL14Kdp5I6omEeNulMd/tGAvxdw0qbbSaT9LolqtnPL2RbnI3j0JsQlncN1+l2
Dzx8Ka39NU4Gb/P6qo/PKa5+YRHSMIIDRjCCAq+gAwIBAgIBCzANBgkqhkiG9w0BAQUFADBbMQsw
CQYDVQQGEwJVUzEoMCYGA1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAG
A1UEAxMZR1NTIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMjA4MDUxODIxMTZaFw0wNDA4MDQx
ODIxMTZaMIGNMQswCQYDVQQGEwJVUzEnMCUGA1UEChMeR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9u
cyBJbmMuMRQwEgYDVQQLEwtEZXZlbG9wbWVudDEUMBIGA1UEAxMLUGV0ZXIgSGVzc2UxKTAnBgkq
hkiG9w0BCQEWGnBtaGVzc2VAZ2VtaW5pc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCvREu1eU1kCNW+lz+ZV9xvljBC7O6iESK10wzKPlrgnhL87+V5/joAbnwsXt25NsmP
8MIY6tuRxCbZzZn3bFTyPerhIOENWrA/HVdIP29TXfHL1YZn7bqBRHyjKcNdYS02GCw4gR4Fr5QS
SQzy62WbLcaoSG/wnhBqBesLxZMsOwIDAQABo4HmMIHjMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEB
BAQDAgSwMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUG8pDjEsHMZVS4/sJThNbtamIzEswHwYDVR0j
BBgwFoAUmmvdRjceHl2eBbmf2Hvb8YozLsYwJQYDVR0RBB4wHIEacG1oZXNzZUBnZW1pbmlzZWN1
cml0eS5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL3d3dy5nZW1pbmlzZWN1cml0eS5jb20v
cm9vdC5jcmwwFgYDVR0gBA8wDTALBgkrBgEEAe8oAQEwDQYJKoZIhvcNAQEFBQADgYEABOIVgnmX
5u4gHHRMsIG5H9WAbMqUeqjhGiFMxDjFXoS2Fkk6eVS6wLJZiS54mWrT1NLA9UOcqfvX8pdpp+pw
IpCwK9ywIco4mrqRdJ5Ja7vuxiO0e0J236mWdTQqPXWxZCOYumBtLkqoOcDFQYjuM4ZPLKSbFiMs
j1OYuQnyz6cxggK0MIICsAIBATBgMFsxCzAJBgNVBAYTAlVTMSgwJgYDVQQKEx9HZW1pbmkgU2Vj
dXJpdHkgU29sdXRpb25zLCBJbmMuMSIwIAYDVQQDExlHU1MgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
AgELMAkGBSsOAwIaBQCgggGqMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAzMDcyMjE5NTIxN1owIwYJKoZIhvcNAQkEMRYEFBcjXPUBFRba6/VrbEfwc/DS+bbYMGcG
CSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMG8GCSsGAQQBgjcQ
BDFiMGAwWzELMAkGA1UEBhMCVVMxKDAmBgNVBAoTH0dlbWluaSBTZWN1cml0eSBTb2x1dGlvbnMs
IEluYy4xIjAgBgNVBAMTGUdTUyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAQswcQYLKoZIhvcNAQkQ
AgsxYqBgMFsxCzAJBgNVBAYTAlVTMSgwJgYDVQQKEx9HZW1pbmkgU2VjdXJpdHkgU29sdXRpb25z
LCBJbmMuMSIwIAYDVQQDExlHU1MgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgELMA0GCSqGSIb3DQEB
AQUABIGAlV1EC4EAhZl9w0EprLgvqcICUFhHIIY2Y99BdX9MhfJFiHB30gioH9hCmyJp7H3JkDUw
CPh3vmmddW9DxikhSKteKpDUmfJJ+k4Ocd8GKNsA09g/YhwB9MuCjNpuOwupazbawlP7luTIpWRN
1+lg38BjIQk6ePOxgLBsZXDc/CsAAAAAAAA=

------=_NextPart_000_00C6_01C35069.39F26180--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MFMXqt053674 for <[e-mail]>; Tue, 22 Jul 2003 08:22:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MFMXTS053673 for ietf-pkix-bks; Tue, 22 Jul 2003 08:22:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cmailm2.svr.pol.co.uk (cmailm2.svr.pol.co.uk [195.92.193.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MFMWqt053667 for <[e-mail]>; Tue, 22 Jul 2003 08:22:32 -0700 (PDT) (envelope-from [e-mail])
Received: from modem-2159.llama.dialup.pol.co.uk ([217.135.184.111] helo=PEDIGREE) by cmailm2.svr.pol.co.uk with smtp (Exim 4.14) id 19eyyD-00014N-Py for [e-mail]; Tue, 22 Jul 2003 16:22:30 +0100
From: "Dean Adams" <[e-mail]>
To: <[e-mail]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Tue, 22 Jul 2003 16:22:28 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p05210600bb42d6fe2202@[12.159.173.178]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
I strongly agree with Steven's comments made above and for those reasons
would agree with deprecating privateKeyUsagePeriod.  A simpler scheme, if
one agrees with the last point that Steven made, would be to acknowledge
that the private key may be used by the subscriber up to the end of the
certificate validity for signing authenticating etc., but that Relying
Parties may continue to validate signatures for an indefinite period after
that period (whether or not that later validation can be used to support a
position or claim can only be answered by whatever governing
legal/regulatory/policy/TermsAndConditions fremework is in force.  Thus only
one validity or usage period need be specified and understood by users.

	Dean Adams

Steven Kent wrote:
--------------
I was not an author for 2459 or 3280, but my feeling is that we do
not recommend use of PKUP for several reasons:

	- it is generally confusing to folks who already have trouble
understanding PKI

	- only in the context of post facto evaluation for NR
purposes is it likely to be applicable

	- it embodies the notion that we can declare that a signature
generated with a private key expires at a future date, relative to NR
concerns. this is not a good match for many real world contexts on
which NR is an issue, e.g., my wet signature does not expire although
an agreement may have a limited lifespan.

Steve
---------------




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MF9Pqt053065 for <[e-mail]>; Tue, 22 Jul 2003 08:09:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MF9PDY053064 for ietf-pkix-bks; Tue, 22 Jul 2003 08:09:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MF9Oqt053059 for <[e-mail]>; Tue, 22 Jul 2003 08:09:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 19eylW-00072d-00 for [e-mail]; Tue, 22 Jul 2003 17:09:22 +0200
From: <[e-mail]>
To: [e-mail]
Reply-To: "Diego Fernandez" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 22 Jul 2003 15:09:24 GMT
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: es
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
X-Accept-Language: es
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Given that this isn't going to change, it would seem that some  
>guidance for 
>users would be useful here.  Since neither (1) nor (2) can be  
>altered, what 
>would be needed is a simple extension, found in signing certs,  
>containing a 
>date to which the cert can still be used for signature-checking  
>beyond the 
>obvious notAfter value.  This could be written up as a short one-page 
>application note, no more (well, a bit more once you add all the usual 
>boilerplate and whatnot). 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MEl7qt052515 for <[e-mail]>; Tue, 22 Jul 2003 07:47:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MEl7f3052514 for ietf-pkix-bks; Tue, 22 Jul 2003 07:47:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx2.cryptopro.ru (mx2.cryptopro.ru [213.59.158.218]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MEjnqt052485 for <[e-mail]>; Tue, 22 Jul 2003 07:46:56 -0700 (PDT) (envelope-from [e-mail])
Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 18:43:24 +0400
Message-ID: <1b7901c3505f$9ae2b5d0$[e-mail]>
From: "Gregory S. Chudov" <[e-mail]>
To: <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>
References: <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Date: Tue, 22 Jul 2003 18:43:24 +0400
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 22 Jul 2003 14:43:24.0593 (UTC) FILETIME=[9ACFCA10:01C3505F]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings.

David Cooper wrote
> It is my understanding that use of this extension was deprecated since,
> unless signed messages are timestamped by a trusted time stamping
> service, there is no way of determining when a message was signed.
Yes, it is true, this extension does not help validating signatures.
But it has a different meaning. It expresses the policy, under which this
key
is used.

> >The tendency with X.509 has been to record as much of the policy as
possible
> >and that is automatically checkable in the cert. So this argues for
keeping
> >and using the private key usage period
>
> Exactly.  If you've got different validity periods for the public and
private
> portions of the key, then you really need to state it in the cert, even if
> only as an expression of CA policy on the topic.
>
> Peter.
Agree. And it's not only an expression of CA policy, this also
gives clients a way to verify that CA (or any other authority)
really follows it's own policy.

For example, Russian cryptographic practice dictates that
the private key MUST be destroyed before it expires.
If it is not destroyed, than it's considered compromised,
and the corresponding certificate should be revoked.
It's sad, that PKIXCMP doesn't define a key destruction announce message.
But of course, there's that GeneralMessage, that can be used for that...

So, privateKeyUsage states:
"I promise to destroy my key before given time. If i don't, consider it
compromized."
And the peer can verify this, e.g. by fetching key destruction announces, or
using some out-of-band mechanism.

Good luck,
Greg Chudov




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MDcGqt046796 for <[e-mail]>; Tue, 22 Jul 2003 06:38:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MDcGxb046795 for ietf-pkix-bks; Tue, 22 Jul 2003 06:38:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MDcFqt046775 for <[e-mail]>; Tue, 22 Jul 2003 06:38:15 -0700 (PDT) (envelope-from [e-mail])
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <[e-mail]> for [e-mail]; Tue, 22 Jul 2003 13:35:49 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 22 Jul 2003 13:35:30 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <[e-mail]> for [e-mail]; Tue, 22 Jul 2003 13:35:29 +0000 (GMT)
Received: from SCHLUMBE-OITRVU.slb.com (vpnpool55.houston.sinet.slb.com [163.188.124.55]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 22 Jul 2003 13:35:29 +0000 (GMT)
Content-return: prohibited
Date: Tue, 22 Jul 2003 09:35:30 -0400
From: "Joel S. Kazin" <[e-mail]>
Subject: Re: Root CA key compromised
In-reply-to: <[e-mail]>
X-Sender: jkazin@163.188.150.131
To: PKIX List <[e-mail]>
Message-id: <5.1.1.1.2.20030722092937.00ae2230@163.188.150.131>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Look at RFC 2527 or the draft RFC 2527bis for an outline of how the issue 
is presented in a CP or CPS.

At 02:00 PM 7/22/2003 +0200, Lenka Kadlcakova wrote:


>Hi all,
>I would like to ask for your opinion on what to do when the Root CA key is 
>compromised. I don't see any clear instruction in RFC 3280. For the case 
>there has already been a discussion on this, could anyone please give me a 
>note?
>
>Thanks a lot for the answer,
>
>Regards,
>
>Lenka
>


Joel S. Kazin CPA, CISA, CISSP
Senior Consultant
SchlumbergerSema
Network and Infrastructure Solutions

194 Wood Avenue South
First Floor
Iselin, NJ 08830, USA

Phone  [phone]
Mobile  [phone]
email    [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MDWmqt046007 for <[e-mail]>; Tue, 22 Jul 2003 06:32:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MDWmi1046005 for ietf-pkix-bks; Tue, 22 Jul 2003 06:32:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MDWkqt045981 for <[e-mail]>; Tue, 22 Jul 2003 06:32:46 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6MDWXoY014528; Wed, 23 Jul 2003 01:32:33 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6MDWXJ01973; Wed, 23 Jul 2003 01:32:33 +1200
Date: Wed, 23 Jul 2003 01:32:33 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>I was not an author for 2459 or 3280, but my feeling is that we do not
>recommend use of PKUP for several reasons:

But those are mostly just hypothetical objections.  At the moment we have two
inescapabable facts:

1. CAs issue certs based on a 1-year billing cycle, and nothing anyone says
   will change that.  No CA will issue a cert with a 20-year lifetime, unless
   it's for its own CA certs.

2. Users need to use certs to validate signatures at n times the CA-ordained
   lifetime.  In the abscence of any mechanism to do this, they are ignoring
   the cert expiry time.  In other words, out of necessity, they're making the
   following change to RFC 3280:

    The validity period for a certificate is the period of time from notBefore
    through notAfter, inclusive.  When used with signing certificates,
    implementations SHOULD NOT pay any attention to the notAfter date.

Given that this isn't going to change, it would seem that some guidance for
users would be useful here.  Since neither (1) nor (2) can be altered, what
would be needed is a simple extension, found in signing certs, containing a
date to which the cert can still be used for signature-checking beyond the
obvious notAfter value.  This could be written up as a short one-page
application note, no more (well, a bit more once you add all the usual
boilerplate and whatnot).

Now CAs can still decide not to issue certs like that, but (a) they can't
justify it by claiming it screws up their standard cert cycle because it
doesn't affect validTo/validFrom, and (b) users at least have some guidance as
to what to do, which is better than the current situation where all they can
do is ignore parts of the standard on an ad hoc basis.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MC7eqt037352 for <[e-mail]>; Tue, 22 Jul 2003 05:07:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MC7eZu037351 for ietf-pkix-bks; Tue, 22 Jul 2003 05:07:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MC7cqt037332 for <[e-mail]>; Tue, 22 Jul 2003 05:07:38 -0700 (PDT) (envelope-from [e-mail])
Received: from [12.159.173.178] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6MC7WD9003031; Tue, 22 Jul 2003 08:07:33 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210600bb42d6fe2202@[12.159.173.178]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 22 Jul 2003 08:07:58 -0400
To: David Chadwick <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

>Peter
>
>the original idea in X.509 was to allow a certificate expiry date to be
>significantly after the private key usage period to allow for signature
>verification long after signatures could no longer be created. thus both
>times are useful.

I don't think one can say that this was the "original" idea, since v1 
and v2 certs didn't have PKUP.  Rather, PKUP is an extension that was 
created to allow certs used in support of NR to be validated after 
the period for private key use had expired.  I don't think there is 
any use for PKUP in contexts where we are dealing with certs for 
authentication, vs. NR.

>David Cooper wrote
>
>>  It is my understanding that use of this extension was deprecated since,
>>  unless signed messages are timestamped by a trusted time stamping
>>  service, there is no way of determining when a message was signed.
>
>this is obviously not true. If I recieve a signed message BEFORE the
>private key usage period has expired, I KNOW that the signature is time
>valid. I dont need a TSA to tell me that. I can read my watch. I can
>then add my own time stamp and signature and stick it in my archives, if
>I am so concerned about time.

I don't think this is a generally applicable example. In general you 
will receive the message in a time frame consistent with the notAfter 
date in the cert, and can make the value judgement you cite above 
(based on your watch) about whether the cert expired so long ago that 
the message should be regarde with suspicion, or not.

>  > Without this ability, the relying party can not verify that the
>>  signature was created before the end of the private key usage period, if
>>  the signature is being verified after the end of the private key usage
>>  period.  If relying parties can not make use of the information, then
>>  there is no reason to include it in the certificate.
>>
>
>This is a illogical leap that has been taken. Just because there is a
>very small time period during which a signer can validly use his private
>signing key, but the RP cannot receive it and validate it before the
>private key usage period expires, is no reason to state that the RP can
>not make use of the information. If 1% (or less) of the time is
>unusable, it is no reason to discard 99% of the time (or more) that is
>usuable. Anyhow, any good PKI would have replaced the user's signing key
>long before the private key usage period had expired.

I don't understand your argument at all. If we ignore PKUP for the 
moment, then I think the numbers are reversed, i.e., 99% of the time 
an RP will receive a cert and find that the current time is within 
the validity interval. I think the typical case for PKUP arises when 
we are validating a cert path to establish whether a  signature was 
valid in some past time frame that is significabtly removed from the 
current time, e.g., months or years later.


>  > Of course, there is no reason that one can not discontinue use of a
>>  private key before the expiration of the corresponding certificate even
>>  if there is no indication in the certificate of when use of the private
>>  key is supposed to end.  Is there any reason that the PKI users you
>>  mention need to include this information in the certificate?  If there
>>  is a need to verify signatures for up to 7 years after the signature was
>>  generated, why not just institute a policy that all subscribers must
>>  rekey 7 years before the expiration of their certificates?
>
>This is a good point, and a work around for not using the private key
>usage period. But like all policy, we can not record it in the cert, or
>we can record it in the cert. The tendency with X.509 has been to record
>as much of the policy as possible and that is automatically checkable in
>the cert. So this argues for keeping and using the private key usage
>period


I was not an author for 2459 or 3280, but my feeling is that we do 
not recommend use of PKUP for several reasons:

	- it is generally confusing to folks who already have trouble 
understanding PKI

	- only in the context of post facto evaluation for NR 
purposes is it likely to be applicable

	- it embodies the notion that we can declare that a signature 
generated with a private key expires at a future date, relative to NR 
concerns. this is not a good match for many real world contexts on 
which NR is an issue, e.g., my wet signature does not expire although 
an agreement may have a limited lifespan.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MC0Sqt036855 for <[e-mail]>; Tue, 22 Jul 2003 05:00:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MC0Stl036853 for ietf-pkix-bks; Tue, 22 Jul 2003 05:00:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vidle.i.cz (vidle.i.cz [193.179.36.138]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MC0Rqt036838 for <[e-mail]>; Tue, 22 Jul 2003 05:00:27 -0700 (PDT) (envelope-from [e-mail])
Received: from ns.i.cz (brana.i.cz [193.179.36.134]) by vidle.i.cz (Postfix) with ESMTP id 879B82F9EF for <[e-mail]>; Tue, 22 Jul 2003 14:00:17 +0200 (CEST)
Received: from localhost (localhost.i.cz [127.0.0.1]) by ns.i.cz (Postfix) with SMTP id E21EE5C7A for <[e-mail]>; Tue, 22 Jul 2003 14:00:16 +0200 (CEST)
X-AV-Checked: Tue Jul 22 14:00:17 2003 ns.i.cz
Received: from i.cz (kadlcakova.i.cz [192.168.18.80]) by ns.i.cz (Postfix) with ESMTP id B09D95C6C for <[e-mail]>; Tue, 22 Jul 2003 14:00:16 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 22 Jul 2003 14:00:31 +0200
From: Lenka Kadlcakova <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en, cs
MIME-Version: 1.0
To: PKIX List <[e-mail]>
Subject: Root CA key compromised
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6MC0Rqt036849
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,
I would like to ask for your opinion on what to do when the Root CA key 
is compromised. I don't see any clear instruction in RFC 3280. For the 
case there has already been a discussion on this, could anyone please 
give me a note?

Thanks a lot for the answer,

Regards,

Lenka




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MBCQqt033670 for <[e-mail]>; Tue, 22 Jul 2003 04:12:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MBCQ63033669 for ietf-pkix-bks; Tue, 22 Jul 2003 04:12:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MBCOqt033648 for <[e-mail]>; Tue, 22 Jul 2003 04:12:25 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6MBCJoY012256; Tue, 22 Jul 2003 23:12:20 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6MBCK624192; Tue, 22 Jul 2003 23:12:20 +1200
Date: Tue, 22 Jul 2003 23:12:20 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick <[e-mail]> writes:

>the original idea in X.509 was to allow a certificate expiry date to be
>significantly after the private key usage period to allow for signature
>verification long after signatures could no longer be created. thus both
>times are useful.

Right, and I think that's a most useful thing to have and have been... well,
maybe not encouraging people to use it but certainly letting them know that
it's there if they need it.  The problem is that because of the wording in
2459/3280, users are scared off using it, so if a very useful feature like
PKUP is deprecated then there should be some good reason for it.  If there's
no reason, and obviously there's user demand for having it (and the
alternative that is being used, ignoring cert expiry dates, is horrible) then
the current SHOULD NOT should really be changed to SHOULD, or at least
removed.

Could it be that the perceived problems with PKUP is that it works in reverse?
That is, the validity says the cert is valid for time X, and then PKUP comes
along and says that in some cases it isn't, when what you really need is two
validities, one which indicates the period over which the cert can be used in
general and the second which says that after the main validity expires it can
still be used in a limited manner.  Obviously for signing certs the main
validity would be "sign + verify", and then the restricted-validity would be
"verify-only", a bit like time-limited trials of software.

>The tendency with X.509 has been to record as much of the policy as possible
>and that is automatically checkable in the cert. So this argues for keeping
>and using the private key usage period

Exactly.  If you've got different validity periods for the public and private
portions of the key, then you really need to state it in the cert, even if
only as an expression of CA policy on the topic.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MAxFqt032933 for <[e-mail]>; Tue, 22 Jul 2003 03:59:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MAxFRC032932 for ietf-pkix-bks; Tue, 22 Jul 2003 03:59:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MAxDqt032925 for <[e-mail]>; Tue, 22 Jul 2003 03:59:14 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6MAx8oY012035; Tue, 22 Jul 2003 22:59:08 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6MAx7k24154; Tue, 22 Jul 2003 22:59:07 +1200
Date: Tue, 22 Jul 2003 22:59:07 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David A. Cooper" <[e-mail]> writes:

>It is my understanding that use of this extension was deprecated since,
>unless signed messages are timestamped by a trusted time stamping service,
>there is no way of determining when a message was signed. 

But the same thing applies to the overall cert validity time (as opposed to
just the PKUP) as well.  This doesn't seem like a very valid reason.

>Is there any reason that the PKI users you mention need to include this
>information in the certificate?  

Yes, because they want to use the signing key (relatively) short-term, but be
able to verify sigs using the public portion years after the private portion
has been retired/destroyed/lost/whatever.

>If there is a need to verify signatures for up to 7 years after the signature
>was generated, why not just institute a policy that all subscribers must
>rekey 7 years before the expiration of their certificates?  

Because it's unlikely that the CAs are going to modify their 1-year billing-
cycle-driven renewal process to handle long-term signing over 10- or 20-year
periods (and conversely I can't imagine users going through the hassle and
expense of re-certifying a bunch of keys year in year out just so someone else
can verify their sigs).  In any event the users don't want to keep the keys
around forever, they want to use the private keys for x amount of time but
still allow verification of the sigs generated with the keys 5x or 10x or 20x
later.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M1j1qt083472 for <[e-mail]>; Mon, 21 Jul 2003 18:45:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6M1j1np083471 for ietf-pkix-bks; Mon, 21 Jul 2003 18:45:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pmamtsi1.mtl.bceemergis.com (smtp1.emergis.com [192.139.197.95]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M1ixqt083463 for <[e-mail]>; Mon, 21 Jul 2003 18:44:59 -0700 (PDT) (envelope-from [e-mail])
Received: from MTL-GW-02.bceemergis.com by pmamtsi1.mtl.bceemergis.com (8.11.7+Sun/8.11.3) with ESMTP id h6M1iad18285; Mon, 21 Jul 2003 21:44:36 -0400 (EDT)
Received: by MTL-GW-02 with Internet Mail Service (5.5.2656.59) id <NTZQVCW8>; Mon, 21 Jul 2003 21:44:36 -0400
Message-ID: <7A423A16C9083341A1240FF22BF71D8402A645DF@MTL-MAIL-03>
From: "Montpetit, Daniel" <[e-mail]>
To: "'David Chadwick'" <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: Peter Gutmann <[e-mail]>, [e-mail]
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Mon, 21 Jul 2003 21:44:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34FF2.CE302ED0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C34FF2.CE302ED0
Content-Type: text/plain


PKIX does not disallow (strongly) the privateKeyUsagePeriod extension.
SHOULD NOT is used so the inclusion is only "not recommended" but allowed.
The strong words (MUST NOT) apply to the criticality.

I agree with David A. Cooper that a timestamp is (most of the time)
required.  

Assuming you want to include some watch reading when validating signatures
and that your relying party agreement allows it ;-).

Further assuming both a notBefore and notAfter value are present: 
You can reject signatures generated before the notBefore is reached using
your watch.
The timestamp requirement is obvious in situations where the usage period is
over and you rely on a still valid verification key. Reading your watch
won't help.
The timestamp is required DURING the usage period because the signature
might have been generated BEFORE the usage period started.  

Assuming only a notBefore value is present: The timestamp requirement
applies once the notBefore time is reached.

Assuming only a notAfter value is present: The timestamp requirement is only
essential after the private key expires  

In the book "planning for PKI" Russ Housley and/or Tim Polk state that since
TSA's are not readily available, the extension has little utility.

All of the above implies that the privateKeyUsagePeriod extension is for use
by the RP.  The extension could have some utility to (well behaved) private
key holders by specifying when they can use the key.  

RFC 3280 states:

	The private key associated with the certificate SHOULD NOT be used
to sign objects 
	before or after the times specified by the two components,
respectively.

Notwithstanding the use of SHOULD NOT instead of MUST NOT, (well behaved)
private key holders are the best placed to comply with this requirement.



Daniel Montpetit


-----Original Message-----
From: David Chadwick [mailto:[e-mail]]
Sent: Monday, July 21, 2003 13:29
To: David A. Cooper
Cc: Peter Gutmann; [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?




"David A. Cooper" wrote:
> 
> Peter Gutmann wrote:
> 
> >PKIX disallows (strongly) this extension, but without giving any reason
for
> >it:
> >
> >  This extension SHOULD NOT be used within the Internet PKI.  CAs
conforming
> >  to this profile MUST NOT generate certificates that include a critical
> >  private key usage period extension.
> >
> >I've now run into several PKI users (including fairly large ones like
> >government departments and large corporations) who resort to ignoring the
cert
> >expiry date in order to get around this restriction, since they have a
> >requirement to validate signatures long after use of the private key has
been

Peter

the original idea in X.509 was to allow a certificate expiry date to be
significantly after the private key usage period to allow for signature
verification long after signatures could no longer be created. thus both
times are useful.

David Cooper wrote

> It is my understanding that use of this extension was deprecated since,
> unless signed messages are timestamped by a trusted time stamping
> service, there is no way of determining when a message was signed.

this is obviously not true. If I recieve a signed message BEFORE the
private key usage period has expired, I KNOW that the signature is time
valid. I dont need a TSA to tell me that. I can read my watch. I can
then add my own time stamp and signature and stick it in my archives, if
I am so concerned about time.

> Without this ability, the relying party can not verify that the
> signature was created before the end of the private key usage period, if
> the signature is being verified after the end of the private key usage
> period.  If relying parties can not make use of the information, then
> there is no reason to include it in the certificate.
> 

This is a illogical leap that has been taken. Just because there is a
very small time period during which a signer can validly use his private
signing key, but the RP cannot receive it and validate it before the
private key usage period expires, is no reason to state that the RP can
not make use of the information. If 1% (or less) of the time is
unusable, it is no reason to discard 99% of the time (or more) that is
usuable. Anyhow, any good PKI would have replaced the user's signing key
long before the private key usage period had expired. 


> Of course, there is no reason that one can not discontinue use of a
> private key before the expiration of the corresponding certificate even
> if there is no indication in the certificate of when use of the private
> key is supposed to end.  Is there any reason that the PKI users you
> mention need to include this information in the certificate?  If there
> is a need to verify signatures for up to 7 years after the signature was
> generated, why not just institute a policy that all subscribers must
> rekey 7 years before the expiration of their certificates? 

This is a good point, and a work around for not using the private key
usage period. But like all policy, we can not record it in the cert, or
we can record it in the cert. The tendency with X.509 has been to record
as much of the policy as possible and that is automatically checkable in
the cert. So this argues for keeping and using the private key usage
period

David


> Why does the
> private key usage period need to be specified in the certificate (except
> perhaps indirectly by mentioning it in the certificate policy)?
> 
> Dave

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

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


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

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

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

------_=_NextPart_001_01C34FF2.CE302ED0
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTQuODkiPg0KPFRJVExFPlJFOiBXaHkg
aXMgcHJpdmF0ZUtleVVzYWdlUGVyaW9kIGRlcHJlY2F0ZWQ/PC9USVRMRT4NCjwvSEVBRD4NCjxC
T0RZPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+UEtJWCBkb2VzIG5vdCBkaXNhbGxvdyAoc3Ry
b25nbHkpIHRoZSBwcml2YXRlS2V5VXNhZ2VQZXJpb2QgZXh0ZW5zaW9uLiBTSE9VTEQgTk9UIGlz
IHVzZWQgc28gdGhlIGluY2x1c2lvbiBpcyBvbmx5ICZxdW90O25vdCByZWNvbW1lbmRlZCZxdW90
OyBidXQgYWxsb3dlZC4mbmJzcDsgVGhlIHN0cm9uZyB3b3JkcyAoTVVTVCBOT1QpIGFwcGx5IHRv
IHRoZSBjcml0aWNhbGl0eS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SSBhZ3JlZSB3
aXRoIERhdmlkIEEuIENvb3BlciB0aGF0IGEgdGltZXN0YW1wIGlzIChtb3N0IG9mIHRoZSB0aW1l
KSByZXF1aXJlZC4mbmJzcDsgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QXNzdW1p
bmcgeW91IHdhbnQgdG8gaW5jbHVkZSBzb21lIHdhdGNoIHJlYWRpbmcgd2hlbiB2YWxpZGF0aW5n
IHNpZ25hdHVyZXMgYW5kIHRoYXQgeW91ciByZWx5aW5nIHBhcnR5IGFncmVlbWVudCBhbGxvd3Mg
aXQgOy0pLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5GdXJ0aGVyIGFzc3VtaW5nIGJv
dGggYSBub3RCZWZvcmUgYW5kIG5vdEFmdGVyIHZhbHVlIGFyZSBwcmVzZW50OiA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPllvdSBjYW4gcmVqZWN0IHNpZ25hdHVyZXMgZ2VuZXJhdGVkIGJlZm9y
ZSB0aGUgbm90QmVmb3JlIGlzIHJlYWNoZWQgdXNpbmcgeW91ciB3YXRjaC48L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPlRoZSB0aW1lc3RhbXAgcmVxdWlyZW1lbnQgaXMgb2J2aW91cyBpbiBzaXR1
YXRpb25zIHdoZXJlIHRoZSB1c2FnZSBwZXJpb2QgaXMgb3ZlciBhbmQgeW91IHJlbHkgb24gYSBz
dGlsbCB2YWxpZCB2ZXJpZmljYXRpb24ga2V5LiBSZWFkaW5nIHlvdXIgd2F0Y2ggd29uJ3QgaGVs
cC48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHRpbWVzdGFtcCBpcyByZXF1aXJl
ZCBEVVJJTkcgdGhlIHVzYWdlIHBlcmlvZCBiZWNhdXNlIHRoZSBzaWduYXR1cmUgbWlnaHQgaGF2
ZSBiZWVuIGdlbmVyYXRlZCBCRUZPUkUgdGhlIHVzYWdlIHBlcmlvZCBzdGFydGVkLiZuYnNwOyA8
L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QXNzdW1pbmcgb25seSBhIG5vdEJlZm9yZSB2
YWx1ZSBpcyBwcmVzZW50OiBUaGUgdGltZXN0YW1wIHJlcXVpcmVtZW50IGFwcGxpZXMgb25jZSB0
aGUgbm90QmVmb3JlIHRpbWUgaXMgcmVhY2hlZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ
WkU9Mj5Bc3N1bWluZyBvbmx5IGEgbm90QWZ0ZXIgdmFsdWUgaXMgcHJlc2VudDogVGhlIHRpbWVz
dGFtcCByZXF1aXJlbWVudCBpcyBvbmx5IGVzc2VudGlhbCBhZnRlciB0aGUgcHJpdmF0ZSBrZXkg
ZXhwaXJlcyZuYnNwOyA8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JbiB0aGUgYm9v
ayAmcXVvdDtwbGFubmluZyBmb3IgUEtJJnF1b3Q7IFJ1c3MgSG91c2xleSBhbmQvb3IgVGltIFBv
bGsgc3RhdGUgdGhhdCBzaW5jZSBUU0EncyBhcmUgbm90IHJlYWRpbHkgYXZhaWxhYmxlLCB0aGUg
ZXh0ZW5zaW9uIGhhcyBsaXR0bGUgdXRpbGl0eS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpF
PTI+QWxsIG9mIHRoZSBhYm92ZSBpbXBsaWVzIHRoYXQgdGhlIHByaXZhdGVLZXlVc2FnZVBlcmlv
ZCBleHRlbnNpb24gaXMgZm9yIHVzZSBieSB0aGUgUlAuJm5ic3A7IFRoZSBleHRlbnNpb24gY291
bGQgaGF2ZSBzb21lIHV0aWxpdHkgdG8gKHdlbGwgYmVoYXZlZCkgcHJpdmF0ZSBrZXkgaG9sZGVy
cyBieSBzcGVjaWZ5aW5nIHdoZW4gdGhleSBjYW4gdXNlIHRoZSBrZXkuJm5ic3A7IDwvRk9OVD48
L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5SRkMgMzI4MCBzdGF0ZXM6PC9GT05UPg0KPC9QPg0KDQo8
UD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0y
PlRoZSBwcml2YXRlIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNlcnRpZmljYXRlIFNIT1VMRCBO
T1QgYmUgdXNlZCB0byBzaWduIG9iamVjdHMgPC9GT05UPg0KPEJSPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8Rk9OVCBTSVpFPTI+YmVmb3JlIG9yIGFmdGVyIHRo
ZSB0aW1lcyBzcGVjaWZpZWQgYnkgdGhlIHR3byBjb21wb25lbnRzLCByZXNwZWN0aXZlbHkuPC9G
T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Tm90d2l0aHN0YW5kaW5nIHRoZSB1c2Ugb2Yg
U0hPVUxEIE5PVCBpbnN0ZWFkIG9mIE1VU1QgTk9ULCAod2VsbCBiZWhhdmVkKSBwcml2YXRlIGtl
eSBob2xkZXJzIGFyZSB0aGUgYmVzdCBwbGFjZWQgdG8gY29tcGx5IHdpdGggdGhpcyByZXF1aXJl
bWVudC48L0ZPTlQ+PC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+RGFuaWVsIE1v
bnRwZXRpdDwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBEYXZpZCBDaGFk
d2ljayBbPEEgSFJFRj0ibWFpbHRvOmQudy5jaGFkd2lja0BzYWxmb3JkLmFjLnVrIj5tYWlsdG86
ZC53LmNoYWR3aWNrQHNhbGZvcmQuYWMudWs8L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
U2VudDogTW9uZGF5LCBKdWx5IDIxLCAyMDAzIDEzOjI5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj5UbzogRGF2aWQgQS4gQ29vcGVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYzogUGV0ZXIg
R3V0bWFubjsgaWV0Zi1wa2l4QGltYy5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlN1Ympl
Y3Q6IFJlOiBXaHkgaXMgcHJpdmF0ZUtleVVzYWdlUGVyaW9kIGRlcHJlY2F0ZWQ/PC9GT05UPg0K
PC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+JnF1b3Q7RGF2aWQgQS4g
Q29vcGVyJnF1b3Q7IHdyb3RlOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgUGV0ZXIgR3V0bWFubiB3cm90ZTo8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDtQS0lY
IGRpc2FsbG93cyAoc3Ryb25nbHkpIHRoaXMgZXh0ZW5zaW9uLCBidXQgd2l0aG91dCBnaXZpbmcg
YW55IHJlYXNvbiBmb3I8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0O2l0OjwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7ICZndDsmbmJzcDsgVGhpcyBleHRlbnNpb24gU0hPVUxEIE5PVCBiZSB1c2VkIHdpdGhpbiB0
aGUgSW50ZXJuZXQgUEtJLiZuYnNwOyBDQXMgY29uZm9ybWluZzwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+Jmd0OyAmZ3Q7Jm5ic3A7IHRvIHRoaXMgcHJvZmlsZSBNVVNUIE5PVCBnZW5lcmF0ZSBj
ZXJ0aWZpY2F0ZXMgdGhhdCBpbmNsdWRlIGEgY3JpdGljYWw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgJmd0OyZuYnNwOyBwcml2YXRlIGtleSB1c2FnZSBwZXJpb2QgZXh0ZW5zaW9uLjwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7ICZndDtJJ3ZlIG5vdyBydW4gaW50byBzZXZlcmFsIFBLSSB1c2VycyAoaW5jbHVkaW5n
IGZhaXJseSBsYXJnZSBvbmVzIGxpa2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0
O2dvdmVybm1lbnQgZGVwYXJ0bWVudHMgYW5kIGxhcmdlIGNvcnBvcmF0aW9ucykgd2hvIHJlc29y
dCB0byBpZ25vcmluZyB0aGUgY2VydDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7
ZXhwaXJ5IGRhdGUgaW4gb3JkZXIgdG8gZ2V0IGFyb3VuZCB0aGlzIHJlc3RyaWN0aW9uLCBzaW5j
ZSB0aGV5IGhhdmUgYTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7cmVxdWlyZW1l
bnQgdG8gdmFsaWRhdGUgc2lnbmF0dXJlcyBsb25nIGFmdGVyIHVzZSBvZiB0aGUgcHJpdmF0ZSBr
ZXkgaGFzIGJlZW48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5QZXRlcjwvRk9OVD4N
CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPnRoZSBvcmlnaW5hbCBpZGVhIGluIFguNTA5IHdhcyB0
byBhbGxvdyBhIGNlcnRpZmljYXRlIGV4cGlyeSBkYXRlIHRvIGJlPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj5zaWduaWZpY2FudGx5IGFmdGVyIHRoZSBwcml2YXRlIGtleSB1c2FnZSBwZXJpb2Qg
dG8gYWxsb3cgZm9yIHNpZ25hdHVyZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dmVyaWZpY2F0
aW9uIGxvbmcgYWZ0ZXIgc2lnbmF0dXJlcyBjb3VsZCBubyBsb25nZXIgYmUgY3JlYXRlZC4gdGh1
cyBib3RoPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aW1lcyBhcmUgdXNlZnVsLjwvRk9OVD4N
CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkRhdmlkIENvb3BlciB3cm90ZTwvRk9OVD4NCjwvUD4N
Cg0KPFA+PEZPTlQgU0laRT0yPiZndDsgSXQgaXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHVzZSBv
ZiB0aGlzIGV4dGVuc2lvbiB3YXMgZGVwcmVjYXRlZCBzaW5jZSw8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgdW5sZXNzIHNpZ25lZCBtZXNzYWdlcyBhcmUgdGltZXN0YW1wZWQgYnkgYSB0
cnVzdGVkIHRpbWUgc3RhbXBpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgc2Vydmlj
ZSwgdGhlcmUgaXMgbm8gd2F5IG9mIGRldGVybWluaW5nIHdoZW4gYSBtZXNzYWdlIHdhcyBzaWdu
ZWQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+dGhpcyBpcyBvYnZpb3VzbHkgbm90
IHRydWUuIElmIEkgcmVjaWV2ZSBhIHNpZ25lZCBtZXNzYWdlIEJFRk9SRSB0aGU8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPnByaXZhdGUga2V5IHVzYWdlIHBlcmlvZCBoYXMgZXhwaXJlZCwgSSBL
Tk9XIHRoYXQgdGhlIHNpZ25hdHVyZSBpcyB0aW1lPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj52
YWxpZC4gSSBkb250IG5lZWQgYSBUU0EgdG8gdGVsbCBtZSB0aGF0LiBJIGNhbiByZWFkIG15IHdh
dGNoLiBJIGNhbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlbiBhZGQgbXkgb3duIHRpbWUg
c3RhbXAgYW5kIHNpZ25hdHVyZSBhbmQgc3RpY2sgaXQgaW4gbXkgYXJjaGl2ZXMsIGlmPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj5JIGFtIHNvIGNvbmNlcm5lZCBhYm91dCB0aW1lLjwvRk9OVD4N
CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZndDsgV2l0aG91dCB0aGlzIGFiaWxpdHksIHRoZSBy
ZWx5aW5nIHBhcnR5IGNhbiBub3QgdmVyaWZ5IHRoYXQgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7IHNpZ25hdHVyZSB3YXMgY3JlYXRlZCBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgcHJp
dmF0ZSBrZXkgdXNhZ2UgcGVyaW9kLCBpZjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0
aGUgc2lnbmF0dXJlIGlzIGJlaW5nIHZlcmlmaWVkIGFmdGVyIHRoZSBlbmQgb2YgdGhlIHByaXZh
dGUga2V5IHVzYWdlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHBlcmlvZC4mbmJzcDsg
SWYgcmVseWluZyBwYXJ0aWVzIGNhbiBub3QgbWFrZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uLCB0
aGVuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoZXJlIGlzIG5vIHJlYXNvbiB0byBp
bmNsdWRlIGl0IGluIHRoZSBjZXJ0aWZpY2F0ZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhpcyBpcyBhIGlsbG9naWNhbCBs
ZWFwIHRoYXQgaGFzIGJlZW4gdGFrZW4uIEp1c3QgYmVjYXVzZSB0aGVyZSBpcyBhPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj52ZXJ5IHNtYWxsIHRpbWUgcGVyaW9kIGR1cmluZyB3aGljaCBhIHNp
Z25lciBjYW4gdmFsaWRseSB1c2UgaGlzIHByaXZhdGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PnNpZ25pbmcga2V5LCBidXQgdGhlIFJQIGNhbm5vdCByZWNlaXZlIGl0IGFuZCB2YWxpZGF0ZSBp
dCBiZWZvcmUgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5wcml2YXRlIGtleSB1c2FnZSBw
ZXJpb2QgZXhwaXJlcywgaXMgbm8gcmVhc29uIHRvIHN0YXRlIHRoYXQgdGhlIFJQIGNhbjwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+bm90IG1ha2UgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbi4gSWYg
MSUgKG9yIGxlc3MpIG9mIHRoZSB0aW1lIGlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj51bnVz
YWJsZSwgaXQgaXMgbm8gcmVhc29uIHRvIGRpc2NhcmQgOTklIG9mIHRoZSB0aW1lIChvciBtb3Jl
KSB0aGF0IGlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj51c3VhYmxlLiBBbnlob3csIGFueSBn
b29kIFBLSSB3b3VsZCBoYXZlIHJlcGxhY2VkIHRoZSB1c2VyJ3Mgc2lnbmluZyBrZXk8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPmxvbmcgYmVmb3JlIHRoZSBwcml2YXRlIGtleSB1c2FnZSBwZXJp
b2QgaGFkIGV4cGlyZWQuIDwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPiZn
dDsgT2YgY291cnNlLCB0aGVyZSBpcyBubyByZWFzb24gdGhhdCBvbmUgY2FuIG5vdCBkaXNjb250
aW51ZSB1c2Ugb2YgYTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwcml2YXRlIGtleSBi
ZWZvcmUgdGhlIGV4cGlyYXRpb24gb2YgdGhlIGNvcnJlc3BvbmRpbmcgY2VydGlmaWNhdGUgZXZl
bjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpZiB0aGVyZSBpcyBubyBpbmRpY2F0aW9u
IGluIHRoZSBjZXJ0aWZpY2F0ZSBvZiB3aGVuIHVzZSBvZiB0aGUgcHJpdmF0ZTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Jmd0OyBrZXkgaXMgc3VwcG9zZWQgdG8gZW5kLiZuYnNwOyBJcyB0aGVy
ZSBhbnkgcmVhc29uIHRoYXQgdGhlIFBLSSB1c2VycyB5b3U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgbWVudGlvbiBuZWVkIHRvIGluY2x1ZGUgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUg
Y2VydGlmaWNhdGU/Jm5ic3A7IElmIHRoZXJlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IGlzIGEgbmVlZCB0byB2ZXJpZnkgc2lnbmF0dXJlcyBmb3IgdXAgdG8gNyB5ZWFycyBhZnRlciB0
aGUgc2lnbmF0dXJlIHdhczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBnZW5lcmF0ZWQs
IHdoeSBub3QganVzdCBpbnN0aXR1dGUgYSBwb2xpY3kgdGhhdCBhbGwgc3Vic2NyaWJlcnMgbXVz
dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyByZWtleSA3IHllYXJzIGJlZm9yZSB0aGUg
ZXhwaXJhdGlvbiBvZiB0aGVpciBjZXJ0aWZpY2F0ZXM/IDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP
TlQgU0laRT0yPlRoaXMgaXMgYSBnb29kIHBvaW50LCBhbmQgYSB3b3JrIGFyb3VuZCBmb3Igbm90
IHVzaW5nIHRoZSBwcml2YXRlIGtleTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dXNhZ2UgcGVy
aW9kLiBCdXQgbGlrZSBhbGwgcG9saWN5LCB3ZSBjYW4gbm90IHJlY29yZCBpdCBpbiB0aGUgY2Vy
dCwgb3I8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPndlIGNhbiByZWNvcmQgaXQgaW4gdGhlIGNl
cnQuIFRoZSB0ZW5kZW5jeSB3aXRoIFguNTA5IGhhcyBiZWVuIHRvIHJlY29yZDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+YXMgbXVjaCBvZiB0aGUgcG9saWN5IGFzIHBvc3NpYmxlIGFuZCB0aGF0
IGlzIGF1dG9tYXRpY2FsbHkgY2hlY2thYmxlIGluPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50
aGUgY2VydC4gU28gdGhpcyBhcmd1ZXMgZm9yIGtlZXBpbmcgYW5kIHVzaW5nIHRoZSBwcml2YXRl
IGtleSB1c2FnZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+cGVyaW9kPC9GT05UPg0KPC9QPg0K
DQo8UD48Rk9OVCBTSVpFPTI+RGF2aWQ8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJ
WkU9Mj4mZ3Q7IFdoeSBkb2VzIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwcml2
YXRlIGtleSB1c2FnZSBwZXJpb2QgbmVlZCB0byBiZSBzcGVjaWZpZWQgaW4gdGhlIGNlcnRpZmlj
YXRlIChleGNlcHQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcGVyaGFwcyBpbmRpcmVj
dGx5IGJ5IG1lbnRpb25pbmcgaXQgaW4gdGhlIGNlcnRpZmljYXRlIHBvbGljeSk/PC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBEYXZl
PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+LS0gPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKio8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5MZWFkZXJzIG9mIHRoZSB3b3Js
ZCdzIHJpY2hlc3QgbmF0aW9ucyBtZWV0IGluIENhbmN1biBvbiBTZXB0ZW1iZXIgMTB0aDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+MjAwMy4gT3hmYW0gaXMgcHJlc2VudGluZyB0aGVtIHdpdGgg
YSBwZXRpdGlvbiB0byBtYWtlIHRyYWRlIGZhaXIuIEJlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj5zdXJlIHlvdXIgdm9pY2UgaXMgaGVhcmQuIFNpZ24gdGhlICdCaWcgTm9pc2UnIHBldGl0aW9u
IHRvIG1ha2UgdHJhZGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmZhaXIgYXQ6PC9GT05UPg0K
PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+PEEgSFJFRj0iaHR0cDovL3d3dy5tYWtldHJhZGVmYWly
LmNvbS9nby9qb2luLz9wPW9tZjEiIFRBUkdFVD0iX2JsYW5rIj5odHRwOi8vd3d3Lm1ha2V0cmFk
ZWZhaXIuY29tL2dvL2pvaW4vP3A9b21mMTwvQT4gPC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48
Rk9OVCBTSVpFPTI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKio8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5EYXZp
ZCBXLiBDaGFkd2ljaywgQlNjIFBoRDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UHJvZmVzc29y
IG9mIEluZm9ybWF0aW9uIFN5c3RlbXMgU2VjdXJpdHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PklTIEluc3RpdHV0ZSwgVW5pdmVyc2l0eSBvZiBTYWxmb3JkLCBTYWxmb3JkIE01IDRXVDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+VGVsOiArNDQgMTYxIDI5NSA1MzUxJm5ic3A7IEZheCArNDQg
MDE0ODQgNTMyOTMwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Nb2JpbGU6ICs0NCA3NyA5NiA0
NCA3MTg0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5FbWFpbDogRC5XLkNoYWR3aWNrQHNhbGZv
cmQuYWMudWs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkhvbWUgUGFnZTombmJzcDsgPEEgSFJF
Rj0iaHR0cDovL3d3dy5zYWxmb3JkLmFjLnVrL2l0czAyNC9jaGFkd2ljay5odG0iIFRBUkdFVD0i
X2JsYW5rIj5odHRwOi8vd3d3LnNhbGZvcmQuYWMudWsvaXRzMDI0L2NoYWR3aWNrLmh0bTwvQT48
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlJlc2VhcmNoIFdlYiBzaXRlOiA8QSBIUkVGPSJodHRw
Oi8vc2VjLmlzaS5zYWxmb3JkLmFjLnVrIiBUQVJHRVQ9Il9ibGFuayI+aHR0cDovL3NlYy5pc2ku
c2FsZm9yZC5hYy51azwvQT48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlNlbWluYXJzOiA8QSBI
UkVGPSJodHRwOi8vd3d3LnNhbGZvcmQuYWMudWsvaXRzMDI0L3NlbWluYXJzLmh0bSIgVEFSR0VU
PSJfYmxhbmsiPmh0dHA6Ly93d3cuc2FsZm9yZC5hYy51ay9pdHMwMjQvc2VtaW5hcnMuaHRtPC9B
PjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+RW50cnVzdCBrZXkgdmFsaWRhdGlvbiBzdHJpbmc6
IE1MSjktRFU1VC1IVjhKPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5QR1AgS2V5IElEIGlzIDB4
QkMyMzhERTU8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4qKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvRk9OVD4N
CjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg==

------_=_NextPart_001_01C34FF2.CE302ED0--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LIHiqt059787 for <[e-mail]>; Mon, 21 Jul 2003 11:17:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6LIHiSM059786 for ietf-pkix-bks; Mon, 21 Jul 2003 11:17:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6LIHhqt059778 for <[e-mail]>; Mon, 21 Jul 2003 11:17:43 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 56598 invoked by alias); 21 Jul 2003 18:17:44 -0000
Received: (qmail 56592 invoked from network); 21 Jul 2003 18:17:44 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.150) by rhea.salford.ac.uk with SMTP; 21 Jul 2003 18:17:44 -0000
Message-ID: <[e-mail]>
Date: Mon, 21 Jul 2003 19:17:27 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: LDAPv3 Profile Issue
Content-Type: multipart/mixed; boundary="------------840EE16934A6EEF45064928A"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Colleagues

at the Vienna meeting I stated that the only outstanding issue with the
LDAPv3 profile was the use of multi-valued RDNs. However, there is also
the use of the ;binary extension that still has to be addressed and
resolved (unfortunately), since the profile needs to state what PKI
clients should do with ;binary.

The ;binary issue is holding up the final calls on the LDAPv3 profile,
and the LDAP PKI and PMI schema documents (from Steven Legg and myself).
Fortunately it does not affect the LDAP attribute extraction schema
profiles that are due to be published as Informational RFCs, but
nevertheless we do need closure on the ;binary issue as soon as possible

regards

David

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

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


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

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

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

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

--------------840EE16934A6EEF45064928A--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LI8Zqt058509 for <[e-mail]>; Mon, 21 Jul 2003 11:08:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6LI8Z2a058508 for ietf-pkix-bks; Mon, 21 Jul 2003 11:08:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LI8Xqt058489 for <[e-mail]>; Mon, 21 Jul 2003 11:08:34 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V6LI14CN18700 for <[e-mail]>; Mon, 21 Jul 2003 14:04:48 -0400
Received: (qmail 25646 invoked by uid 64014); 21 Jul 2003 18:02:22 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.421604 secs); 21 Jul 2003 18:02:22 -0000
Received: from sottmxs01.entrust.com (10.4.61.7) by sottguard01.entrust.com with SMTP; 21 Jul 2003 18:02:22 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <PLM10AT1>; Mon, 21 Jul 2003 14:08:24 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David Chadwick'" <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: Peter Gutmann <[e-mail]>, [e-mail]
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Mon, 21 Jul 2003 14:08:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just want to voice agreement and support for David Chadwick's views on this
:-)

-----Original Message-----
From: David Chadwick [mailto:[e-mail]]
Sent: Monday, July 21, 2003 1:29 PM
To: David A. Cooper
Cc: Peter Gutmann; [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?




"David A. Cooper" wrote:
> 
> Peter Gutmann wrote:
> 
> >PKIX disallows (strongly) this extension, but without giving any reason
for
> >it:
> >
> >  This extension SHOULD NOT be used within the Internet PKI.  CAs
conforming
> >  to this profile MUST NOT generate certificates that include a critical
> >  private key usage period extension.
> >
> >I've now run into several PKI users (including fairly large ones like
> >government departments and large corporations) who resort to ignoring the
cert
> >expiry date in order to get around this restriction, since they have a
> >requirement to validate signatures long after use of the private key has
been

Peter

the original idea in X.509 was to allow a certificate expiry date to be
significantly after the private key usage period to allow for signature
verification long after signatures could no longer be created. thus both
times are useful.

David Cooper wrote

> It is my understanding that use of this extension was deprecated since,
> unless signed messages are timestamped by a trusted time stamping
> service, there is no way of determining when a message was signed.

this is obviously not true. If I recieve a signed message BEFORE the
private key usage period has expired, I KNOW that the signature is time
valid. I dont need a TSA to tell me that. I can read my watch. I can
then add my own time stamp and signature and stick it in my archives, if
I am so concerned about time.

> Without this ability, the relying party can not verify that the
> signature was created before the end of the private key usage period, if
> the signature is being verified after the end of the private key usage
> period.  If relying parties can not make use of the information, then
> there is no reason to include it in the certificate.
> 

This is a illogical leap that has been taken. Just because there is a
very small time period during which a signer can validly use his private
signing key, but the RP cannot receive it and validate it before the
private key usage period expires, is no reason to state that the RP can
not make use of the information. If 1% (or less) of the time is
unusable, it is no reason to discard 99% of the time (or more) that is
usuable. Anyhow, any good PKI would have replaced the user's signing key
long before the private key usage period had expired. 


> Of course, there is no reason that one can not discontinue use of a
> private key before the expiration of the corresponding certificate even
> if there is no indication in the certificate of when use of the private
> key is supposed to end.  Is there any reason that the PKI users you
> mention need to include this information in the certificate?  If there
> is a need to verify signatures for up to 7 years after the signature was
> generated, why not just institute a policy that all subscribers must
> rekey 7 years before the expiration of their certificates? 

This is a good point, and a work around for not using the private key
usage period. But like all policy, we can not record it in the cert, or
we can record it in the cert. The tendency with X.509 has been to record
as much of the policy as possible and that is automatically checkable in
the cert. So this argues for keeping and using the private key usage
period

David


> Why does the
> private key usage period need to be specified in the certificate (except
> perhaps indirectly by mentioning it in the certificate policy)?
> 
> Dave

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

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


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

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

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LHioqt056267 for <[e-mail]>; Mon, 21 Jul 2003 10:44:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6LHin40056266 for ietf-pkix-bks; Mon, 21 Jul 2003 10:44:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pan.salford.ac.uk (pan.salford.ac.uk [146.87.255.104]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6LHimqt056261 for <[e-mail]>; Mon, 21 Jul 2003 10:44:48 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 19116 invoked by alias); 21 Jul 2003 17:44:49 -0000
Received: (qmail 19102 invoked from network); 21 Jul 2003 17:44:49 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.150) by pan.salford.ac.uk with SMTP; 21 Jul 2003 17:44:49 -0000
Message-ID: <[e-mail]>
Date: Mon, 21 Jul 2003 18:44:32 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Internet Drafts <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Subject Certificate Access
Content-Type: multipart/mixed; boundary="------------20CF632FF8591B088C697B6D"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Colleagues

Please find attached a new ID that publishes in a cert the location of
the subject's certs. Strange as it may seem, this feature is currently
not part of SIA or AIA.

regards

David

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

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


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

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

*****************************************************************
--------------20CF632FF8591B088C697B6D
Content-Type: text/plain; charset=us-ascii;
 name="draft-ietf-pkix-chadwick-sca-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-pkix-chadwick-sca-00.txt"

PKIX Working Group                                         David Chadwick
INTERNET-DRAFT                                             University of Salford
Expires 22 January 2004                                    22 July 2003

                 Subject Certificate Access Extension
                  <draft-ietf-chadwick-pkix-sca-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright (C) The Internet Society (2002). All Rights Reserved.


Abstract

Currently there is nothing in a certificate to tell a relying party where this 
certificate, or any other certificate issued to the subject of this certificate, 
has been published. This document defines an extension that indicates where 
certificates of the subject may be published.

Please send comments on this document to the [e-mail] mailing list.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119
   [RFC2119].


1. Introduction

The PKIX Certificate and CRL profile [RFC3280] defines the Authority Information 
Access and Subject Information Access extensions that are used to indicate how 
to access information and services for the issuer and subject of the certificate 
in which these extensions appear. However they do not tell the certificate user 
where they may find this or any other certificates that have been issued to the 
subject of this certificate. Subject Information Access says where to find 
information provided BY the subject, but not information ABOUT the subject. 
Authority Information Access says where to find information about superior CAs, 
but not where to find certificates issued by this CA.

This document defines an extension that indicates the location of where 
certificates of a subject may be published. 

Subjects may typically be issued with several certificates by the same (or 
different) CAs, often with the differences being indicated in the Key Usage or 
Extended Key Usage fields. A relying party may be in possession of one 
certificate of a subject, but may need access to a different certificate. For 
example, a relying party may have been sent the digital signature certificate of 
a subject along with an S/MIME message and may now want the key encipherment 
certificate of the subject so that they can send an encrypted message back to 
the subject. The Subject Certificate Access extension defines one way for a CA 
to publish in a certificate information describing where the certificates issued 
to this subject by this CA (or any other CA) may be found.


2. Subject Certificate Access Extension

This extension lists the locations where additional certificates, belonging to 
the subject of the certificate in which this extension exists, may be found. 
Each location comprises the name of the CA issuing the certificate to the 
subject, plus the access location used by that CA. 

The formal ASN.1 definition for this extension is:

   id-pe-subjectCertAccess OBJECT IDENTIFIER ::= { id-pe tbd }

   SubjectCertAccessSyntax  ::=
           SEQUENCE SIZE (1..MAX) OF CertLocation

  
           CertLocation   ::=  SEQUENCE {
            Issuer            [0]  GeneralName OPTIONAL,
            accessLocation    [1]  GeneralName  }


The issuer component of CertLocation provides the general name of the CA issuing 
one or more certificates to the subject of the certificate in which this 
extension is present. If the issuer component is missing, then the issuer is the 
same as the issuer of the current certificate.

The accessLocation component of CertLocation provides the location at which one 
or more certificates may be found for the subject of the certificate in which 
this extension is present. 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 [URI]. Where 
information is available via ldap, the format of the URI MUST be an LDAP URL as 
specified in RFC 2255 [RFC2255]. The LDAP URL MAY specify a non-leaf node from 
which to perform a one-level or full subtree Search, or it MAY specify the LDAP 
DN of the entry holding the subject's certificates. Where the information is 
available via the Directory Access Protocol (DAP), accessLocation MUST be a 
directoryName. When the information is available via electronic mail, 
accessLocation MUST be an rfc822Name.  The semantics of other accessLocation 
name forms are not defined.

Where a CA publishes certificates in more than one location, multiple instances 
of CertLocation SHOULD be provided, one per location.

Where a subject possesses certificates issued by more than one CA, there MAY be 
values of CertLocation for each issuing CA. How this information is obtained by 
the publishing CA is not specified in this document, although one way could be 
for the subject to provide it within the CertTemplate of a Certificate Request 
Message [CRMF].


3. Security Considerations

The certificates to be retrieved from publishing servers (ftp, http, ldap, smtp, 
X.500) is digitally signed and therefore additional integrity services are NOT 
REQUIRED. 

The CPS will specify whether the information should be publicly available or 
not. If publicly available, privacy services will NOT be REQUIRED for retrieval 
requests. If not publicly available, privacy services MAY be REQUIRED and these 
can be provided by a TLS ciphersuite.

Organizations are NOT REQUIRED to provide external users with access to their 
publishing servers.


4. IANA Considerations

   Certificate extensions and attribute certificate extensions are
   identified by object identifiers (OIDs).  The OID for the extension
   defined in this document was assigned from an arc delegated by the
   IANA to the PKIX Working Group.  No further action by the IANA is
   necessary for this document or any anticipated updates


5. References

5.1 Normative References

   [RFC2119]    S. Bradner, "Key words for use in RFCs to Indicate
                Requirement Levels", RFC 2119, March 1997.

   [URI]        T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 
                Resource Identifiers (URI): Generic Syntax", RFC 2396,
                August 1998.

   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
                3", BCP 9, RFC 2026, October 1996.

   [RFC2255]    T. Howes, M. Smith. "The LDAP URL Format", RFC 2255, Dec 1997.

5.2 Informative References

   [RFC3280]    R. Housley, W. Polk, W. Ford, and D. Solo, "Internet
                X.509 Public Key Infrastructure: Certificate and
                Certificate Revocation List (CRL) Profile", RFC 3280,
                April 2002.


   [CRMF]       Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 
                Certificate Request Message Format," RFC 2511, March 1999.


6. Author's Address

David Chadwick
University of Salford
The Crescent
Salford
M5 4WT
England

Email: [e-mail]



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

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

--------------20CF632FF8591B088C697B6D--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LHTRqt055844 for <[e-mail]>; Mon, 21 Jul 2003 10:29:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6LHTRdf055843 for ietf-pkix-bks; Mon, 21 Jul 2003 10:29:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pan.salford.ac.uk (pan.salford.ac.uk [146.87.255.104]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6LHTPqt055836 for <[e-mail]>; Mon, 21 Jul 2003 10:29:26 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 12736 invoked by alias); 21 Jul 2003 17:29:26 -0000
Received: (qmail 12716 invoked from network); 21 Jul 2003 17:29:26 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.150) by pan.salford.ac.uk with SMTP; 21 Jul 2003 17:29:26 -0000
Message-ID: <[e-mail]>
Date: Mon, 21 Jul 2003 18:29:09 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------0B4261A16AFFE0AC6A81C499"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



"David A. Cooper" wrote:
> 
> Peter Gutmann wrote:
> 
> >PKIX disallows (strongly) this extension, but without giving any reason for
> >it:
> >
> >  This extension SHOULD NOT be used within the Internet PKI.  CAs conforming
> >  to this profile MUST NOT generate certificates that include a critical
> >  private key usage period extension.
> >
> >I've now run into several PKI users (including fairly large ones like
> >government departments and large corporations) who resort to ignoring the cert
> >expiry date in order to get around this restriction, since they have a
> >requirement to validate signatures long after use of the private key has been

Peter

the original idea in X.509 was to allow a certificate expiry date to be
significantly after the private key usage period to allow for signature
verification long after signatures could no longer be created. thus both
times are useful.

David Cooper wrote

> It is my understanding that use of this extension was deprecated since,
> unless signed messages are timestamped by a trusted time stamping
> service, there is no way of determining when a message was signed.

this is obviously not true. If I recieve a signed message BEFORE the
private key usage period has expired, I KNOW that the signature is time
valid. I dont need a TSA to tell me that. I can read my watch. I can
then add my own time stamp and signature and stick it in my archives, if
I am so concerned about time.

> Without this ability, the relying party can not verify that the
> signature was created before the end of the private key usage period, if
> the signature is being verified after the end of the private key usage
> period.  If relying parties can not make use of the information, then
> there is no reason to include it in the certificate.
> 

This is a illogical leap that has been taken. Just because there is a
very small time period during which a signer can validly use his private
signing key, but the RP cannot receive it and validate it before the
private key usage period expires, is no reason to state that the RP can
not make use of the information. If 1% (or less) of the time is
unusable, it is no reason to discard 99% of the time (or more) that is
usuable. Anyhow, any good PKI would have replaced the user's signing key
long before the private key usage period had expired. 


> Of course, there is no reason that one can not discontinue use of a
> private key before the expiration of the corresponding certificate even
> if there is no indication in the certificate of when use of the private
> key is supposed to end.  Is there any reason that the PKI users you
> mention need to include this information in the certificate?  If there
> is a need to verify signatures for up to 7 years after the signature was
> generated, why not just institute a policy that all subscribers must
> rekey 7 years before the expiration of their certificates? 

This is a good point, and a work around for not using the private key
usage period. But like all policy, we can not record it in the cert, or
we can record it in the cert. The tendency with X.509 has been to record
as much of the policy as possible and that is automatically checkable in
the cert. So this argues for keeping and using the private key usage
period

David


> Why does the
> private key usage period need to be specified in the certificate (except
> perhaps indirectly by mentioning it in the certificate policy)?
> 
> Dave

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

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


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

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

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

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

--------------0B4261A16AFFE0AC6A81C499--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LFKlqt049046 for <[e-mail]>; Mon, 21 Jul 2003 08:20:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6LFKlsQ049045 for ietf-pkix-bks; Mon, 21 Jul 2003 08:20:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6LFKeqt049025 for <[e-mail]>; Mon, 21 Jul 2003 08:20:41 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 80326 invoked by alias); 21 Jul 2003 15:20:25 -0000
Received: (qmail 80303 invoked from network); 21 Jul 2003 15:20:25 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.150) by rhea.salford.ac.uk with SMTP; 21 Jul 2003 15:20:25 -0000
Message-ID: <[e-mail]>
Date: Mon, 21 Jul 2003 16:20:08 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Antonio Lioy <[e-mail]>
CC: Wen-Cheng Wang <[e-mail]>, "Michael =?iso-8859-1?Q?Str=F6der?=" <[e-mail]>, PKIX <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <[e-mail]> <[e-mail]> <003201c34cce$e9070070$4f85900a@wcwang> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------0661FA61B3AD22819D10C888"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Antonio Lioy wrote:

> 
> So support for multiple certs per each user should be added to the schema.

This has always been there. This is not the issue. It is whether the
newly created per certificate entry should use a multivalued attribute
or define a new one.

regards

David

> 
> Cheers,
> 
> Antonio Lioy

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

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


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

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

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

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

--------------0661FA61B3AD22819D10C888--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LF3gqt047889 for <[e-mail]>; Mon, 21 Jul 2003 08:03:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6LF3gU5047888 for ietf-pkix-bks; Mon, 21 Jul 2003 08:03:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LF3fqt047883 for <[e-mail]>; Mon, 21 Jul 2003 08:03:41 -0700 (PDT) (envelope-from [e-mail])
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h6LF3Cw1014339; Mon, 21 Jul 2003 11:03:14 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 21 Jul 2003 11:03:02 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:

>PKIX disallows (strongly) this extension, but without giving any reason for
>it:
>
>  This extension SHOULD NOT be used within the Internet PKI.  CAs conforming
>  to this profile MUST NOT generate certificates that include a critical
>  private key usage period extension.
>
>I've now run into several PKI users (including fairly large ones like
>government departments and large corporations) who resort to ignoring the cert
>expiry date in order to get around this restriction, since they have a
>requirement to validate signatures long after use of the private key has been
>discontinued.  Is there any reason for this extension being disallowed (I'm
>sure I've asked that before, but don't remember getting a satisfactory reply)?
>What are you supposed to do in its absence?
>
Peter,

It is my understanding that use of this extension was deprecated since, 
unless signed messages are timestamped by a trusted time stamping 
service, there is no way of determining when a message was signed.  
Without this ability, the relying party can not verify that the 
signature was created before the end of the private key usage period, if 
the signature is being verified after the end of the private key usage 
period.  If relying parties can not make use of the information, then 
there is no reason to include it in the certificate.

Of course, there is no reason that one can not discontinue use of a 
private key before the expiration of the corresponding certificate even 
if there is no indication in the certificate of when use of the private 
key is supposed to end.  Is there any reason that the PKI users you 
mention need to include this information in the certificate?  If there 
is a need to verify signatures for up to 7 years after the signature was 
generated, why not just institute a policy that all subscribers must 
rekey 7 years before the expiration of their certificates?  Why does the 
private key usage period need to be specified in the certificate (except 
perhaps indirectly by mentioning it in the certificate policy)?

Dave




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J5G6qt042148 for <[e-mail]>; Fri, 18 Jul 2003 22:16:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6J5G6eZ042147 for ietf-pkix-bks; Fri, 18 Jul 2003 22:16:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J5G3qt042142 for <[e-mail]>; Fri, 18 Jul 2003 22:16:04 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6J5G1YM017771 for <[e-mail]>; Sat, 19 Jul 2003 17:16:01 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6J5G2X06190 for [e-mail]; Sat, 19 Jul 2003 17:16:02 +1200
Date: Sat, 19 Jul 2003 17:16:02 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Why is privateKeyUsagePeriod deprecated?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIX disallows (strongly) this extension, but without giving any reason for
it:

  This extension SHOULD NOT be used within the Internet PKI.  CAs conforming
  to this profile MUST NOT generate certificates that include a critical
  private key usage period extension.

I've now run into several PKI users (including fairly large ones like
government departments and large corporations) who resort to ignoring the cert
expiry date in order to get around this restriction, since they have a
requirement to validate signatures long after use of the private key has been
discontinued.  Is there any reason for this extension being disallowed (I'm
sure I've asked that before, but don't remember getting a satisfactory reply)?
What are you supposed to do in its absence?

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IG3Vqt006435 for <[e-mail]>; Fri, 18 Jul 2003 09:03:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IG3U9c006434 for ietf-pkix-bks; Fri, 18 Jul 2003 09:03:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.hackmasters.net (ppp-217-133-8-148.cust-adsl.tiscali.it [217.133.8.148]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IG3Rqt006428 for <[e-mail]>; Fri, 18 Jul 2003 09:03:28 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hackmasters.net (Postfix) with ESMTP id 2CA05F354 for <[e-mail]>; Fri, 18 Jul 2003 18:18:51 +0200 (CEST)
Received: by mail.hackmasters.net (Postfix, from userid 509) id 7AA45FEF4; Fri, 18 Jul 2003 18:18:49 +0200 (CEST)
Received: from hackmasters.net (galadriel.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 317A4F354 for <[e-mail]>; Fri, 18 Jul 2003 18:18:45 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 18 Jul 2003 18:11:27 +0200
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040808060403000809070404"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

David Chadwick wrote:
> Dear All
> 
> Peter and I have resolved all the issues described at the PKIX meeting
> today, apart from one, which is what should be the attribute type to be
> used to hold the X.509 DER encoded attribute. Should it be the original
> attribute type name e.g. userCertificate or a new attribute whose schema
> says it must be single valued. Comments please to the list to help us
> resolve this final issue.

[...]

If no issue is expected to arise from the adoption of the old name I am in
favour of the userCertificate.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [e-mail]
                                                  Tel.:   [phone]
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: [phone]

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

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IDhpqt001609 for <[e-mail]>; Fri, 18 Jul 2003 06:43:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IDhp9h001608 for ietf-pkix-bks; Fri, 18 Jul 2003 06:43:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.cht.com.tw ([202.39.162.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IDhmqt001601 for <[e-mail]>; Fri, 18 Jul 2003 06:43:48 -0700 (PDT) (envelope-from [e-mail])
Received: from linuxis.cht.com.tw ([10.1.22.33]) by fw.cht.com.tw (8.12.6/8.12.6) with ESMTP id h6IDcD9J017393; Fri, 18 Jul 2003 21:38:14 +0800 (CST) (envelope-from [e-mail])
Received: from mailgate.cht.com.tw (localhost.localdomain [127.0.0.1]) by linuxis.cht.com.tw (8.9.3/8.9.3) with ESMTP id VAA28495; Fri, 18 Jul 2003 21:49:16 +0800
Received: from linux01 (webmail.cht.com.tw [10.1.22.40]) by mailgate.cht.com.tw (8.11.6/8.10.2) with ESMTP id h6IDf2e06574; Fri, 18 Jul 2003 21:41:02 +0800
Message-ID: <24559530.1058535017301.JavaMail.root@10.1.22.7>
Date: Fri, 18 Jul 2003 21:30:17 +0800 (CST)
From: wcwang <[e-mail]>
To: =?Big5?Q?Michael_Str=3Fder?= <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
Cc: PKIX <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_151_12114599.1058535017299"
X-Mailer: WebMail/Java v0.7.10, built with JDK 1.4.1, SendMessage plugin v1.8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_151_12114599.1058535017299
Content-Type: text/plain; charset="Big5"
Content-Transfer-Encoding: quoted-printable

Michael Stroder wrote:
> Antonio Lioy wrote:
> >=20
> > Wen-Cheng Wang wrote:
> >
> >> My concern is a CA may support dual key pairs for a single EE.
> >
> > So support for multiple certs per each user should be added to the sche=
ma.
> I'd suggest to read the draft. Hint: Multi-valued attributes are not the=
=20
> only way to store multiple certificates per user.

Sorry I did not carefully read David's questio. And then when
I saw him asking for comments on restricting userCertificate
to be single-valued, I gave my concern intuitively.

Actually, I had read the three new I-Ds and I know that some
people have been working on inventing a new way to store
PKCs, ACs and CRLs in LDAP-based repository instead of
using traditional attributes such as userCertificate,
caCertificate or attributeCertificateAttribute.

Well, now I re-give my comment. I think that since it is a
new way to to store PKCs, ACs and CRLs, it is fine to define
a new single-valued attribute. Redefine the traditional
userCertificate caCertificate or attributeCertificateAttribute
attributes to be single-valued might be a bad idea.

Wen-Cheng Wang
------=_Part_151_12114599.1058535017299--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ID2Iqt094546 for <[e-mail]>; Fri, 18 Jul 2003 06:02:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6ID2Hkg094545 for ietf-pkix-bks; Fri, 18 Jul 2003 06:02:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ID2Eqt094531 for <[e-mail]>; Fri, 18 Jul 2003 06:02:14 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA23842; Fri, 18 Jul 2003 15:06:52 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA24726; Fri, 18 Jul 2003 15:02:24 +0200
Message-ID: <[e-mail]>
Date: Fri, 18 Jul 2003 15:02:10 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: WG Last Call: SCVP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments on draft-ietf-pkix-scvp-12.txt
Simple Certificate Validation Protocol (SCVP)

The following 8 issues have been suppressed since there are agreed:
9, 11, 12, 13, 16, 18, 19 and 23.

There remains 16 issues to be discussed. The original numbering has been kept.

1. Section 1.3 Validation Policies

In this section the wording "validation policy" is used but is left
undefined: "A validation policy can be used to specify the SCVP
configuration." Please define it.

[Trevor Freeman] I have added a reference to 3379 to define validation
policy.

[Denis] Are you going to add a reference to section 7 from RFC 3379 ?

This text is copied below.

    A validation policy is a set of rules against which the validation of
    the certificate is performed.

    A validation policy MAY include several trust anchors.  A trust
    anchor is defined as one public key, a CA name, and a validity time
    interval; a trust anchor optionally includes additional constraints.
    The use of a self-signed certificate is one way to specify the public
    key to be used, the issuer name, and the validity period of the
    public key.

    Additional constraints for each trust anchor MAY be defined.  These
    constraints might include a set of certification policy constraints
    or a set of naming constraints.  These constraints MAY also be
    included in self-signed certificates.

    Additional conditions that apply to the certificates in the path MAY
    also be specified in the validation policy.  For example, specific
    values could be provided for the inputs to the certification path
    validation algorithm in [PKIX-1], such as user-initial-policy-set,
    initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
    any-policy-inhibit.

    Additional conditions that apply to the end-entity certificate MAY
    also be specified in the validation policy.  For example, a specific
    name form might be required.

    In order to succeed, one valid certification path (none of the
    certificates in the path are expired or revoked) MUST be found
    between an end-entity certificate and a trust anchor and all
    constraints that apply to the certification path MUST be verified.


2. Section 1.3 Validation Policies. The text says: " The validation policy 
is determined by private agreement between the client and the server, ...".

While this may be one case this is not the single case. Please delete
and simply say: "The validation policy MUST be represented as an OBJECT
IDENTIFIER and optionally some additional parameters.

[Trevor Freeman] I have removed the word private.

[Denis] This does not solve my concern. A validation policy may also be 
determined by a policy issuer, while means that there is no agreement 
between the client and the server. The client wants to use a given 
validation policy defined by a policy issuer. If the server supports it, 
then it is fine. If the server does not support it, then the client looks 
for another server supporting it.

For the first of the sentence I would thus propose:

"The validation policy may be determined by the server, or any third party."

For the second part of the sentence, we currently have:

", but it MUST be represented as an OBJECT IDENTIFIER."

I have proposed:

"The validation policy MUST be represented as an OBJECT
IDENTIFIER and optionally some additional parameters."

So the issue is whether we have or not "and optionally some additional 
parameters"

This seems to be the reason of a disagreement on many of the other points.

The validation policy does not only include the processing algorithms but 
also the values used by the processing algorithms to validate a certificate.

The two possibilities, as I see them, are :

- the OID of the validation policy tells everything (i.e. both the 
processing algorithms and all the values to be used by these processing 
algorithms),

- the OID validation policy provides the processing algorithms and some of 
the values to be used, but some other values may be defined as additional 
parameters.

Please, reconsider my proposal.


3. In section 3, SignedData is defined with unsignedAttrs being not used. As 
it will be explained later on, unsignedAttrs should be used to carry 
unsigned certificate values, as well as unsigned revocation information 
(CRLs in particular) while the references (much shorter) will be signed.

This has the major advantage of keeping the size of archived signed 
responses short.

[Trevor Freeman] This is not a requirement in 3379. Correct. However, this 
is a big advantage in the following case:

The RP wants to keep an archive of "YES" answers. If the values are all 
signed, then the size of the archives will get pretty big since the same CA 
certificates and CRLs will be duplicated many times in every "YES" answer. 
If only the references are signed, then the values may be stored elsewhere 
and only once: the same values will be usable for thousands of validations.


4. Section 3.2. The text currently says on page 9: " The OPTIONAL
valPolicy, trustAnchors, intermediateCerts, and revInfos items provide 
context for the client request."

This sentence should be replaced by the following:

"Either the valPolicy item or the trustAnchors item SHALL be used. The
intermediateCerts and revInfos items provide certificates or revocation
status information which MAY be useful to build the response."

[Trevor Freeman] I disagree since the validation policy alone is not
enough. 3379 does not require that the validation policy and the
parameter used with that policy are represented by a single OID.

[Denis] I do not think that you disagree on the second sentence:
" The intermediateCerts and revInfos items provide certificates or 
revocation status information which MAY be useful to build the response."

You probably disagree on the first sentence. It is in fact incorrect.
I would thus propose the following:

"Either the valPolicy item alone or both the valPolicy and the trustAnchors 
items SHALL be used.

The rational is explained in issue 2.


5. Section 3.2.3  wantBack

More options should be allowed to return:

1)  only the references of both the certificates and the associated
revocation status information for the path as a signed parameter,

[Trevor Freeman] This is covered by a certificate status request.

2) both the references of both the certificates and the associated
revocation status information for the path as signed parameter, and the
certificate values together with the associated revocation status
information as an unsigned attribute (see comment 3)

[Trevor Freeman] This is covered by two requests, one for certificate
status and one DPD.

[Denis] This is not optimum, since this could be done by one request.
If this is done in two requests, this may be complicated because there is no 
assurance that the first DPD request will return the path used by the DPV 
request. So the client will have to test if the path that is returned is the 
right one and re-issue a PVD request until it the right one is returned. If 
you maintain two requests, these additional explanations would be useful.

Note : certificate values or associated revocation status information as
a signed parameter are not needed when using the two alternatives above.

[Trevor Freeman] This is not a requirement in 3379. The client is at
liberty to ignore the signature.

[Denis] This relates to issue 2.

It is unclear why *only* the "Public key from the certificate" should be
returned. Either suppress this option, explain why it is sufficient or
return the full certificate.

[Trevor Freeman] This reduces the footprint of a simple client.

[Denis] Maybe. If we keep it, then add the full certificate as another 
possibility.

6. Section 3.2.5  valPolicy . The text says:

"  The valPolicy item, defines the validation policy to be used by the
     SCVP server during certificate validation.  The client can use this
     instead of specifying other SCVP configuration items such as
     trustAnchors.  The value of this item can be determined by private
     agreement between the client and the server, but it MUST be
     represented as an object identifier.  The server might want to
     assign identifiers that indicate that some settings are used in
     addition to others given in the request.  In this way, the
     validation policy object identifier can be a shorthand for some SCVP
     options, but not others".

Replace the whole with:

"  The valPolicy item, defines the validation policy to be used by the
     SCVP server during certificate validation.  The client MUST either
     use it or use trustAnchors which allows to define relatively simple
     validation policies".

[Trevor Freeman] I have removed the second sentence and the word
"private" from the third sentence.

[Denis] This does not solve my concern. See issue 2.

I would propose the following rephrasing:

"  The valPolicy item, defines the validation policy to be used by the
     SCVP server during certificate validation.  The client MUST either
     use it or use it in combination with trustAnchors. The second option
     allows to define relatively simple validation policies".


7. Section 3.2.5  valPolicy . The text says: "All SCVP servers MUST support 
the default policy". This is fine. However, it is important that the client 
may know the parameters of the default policy when the default policy has 
been used by the server. So the default policy SHALL define its parameters.

[Trevor Freeman] the default policy has no parameters - it is a set of rules 
as per 3379.

[Denis] As explained in issue 2, a validation policy must at least define 
one root key, so it is not true to say that it has no parameter.

In order to be able to use this protocol with Qualified Certificates (as per 
the European Directive on Electronic Signatures) certPolicies should further 
be subdivided in two categories: certPolicy for the end-entity certificate 
and certPolicies for CA certificates (currently CA certificates do not have 
certPolicies mandated as per the European Directive on Electronic Signatures).

It is thus propose to defined three parameters for the default policy:

   - trustAnchors,
   - certPolicy for the end-entity certificate,
   - certPolicies for CA certificates.

As mentioned in the text, revocation conditions include any source of
revocation available.

[Trevor Freeman] This is not a requirement for 3379. The trust anchors
are specified in the request. You requirements are accommodated by two
requests, one for the end cert, and one for the CA cert.

[Denis] No. This would not solve my concern. The EESSI  standards built upon 
the EU Directive ask for a given CP to be present in the end-entity 
certificate, but place no such constraint on the CP from the CA 
certificates. It would however be nice to be able to use the default 
validation policy in such a case.

8. Section 3.2.5.1 The need and the rational for this section could not
be understood: an OID unambiguously identity a validation policy, a "name
Validation Policy" or "Validation Policy name" (?) would not add
anything.

Please explain or delete.

[Trevor Freeman] This was asked for at IETF 56 as an example for another
validation policy.

[Denis] Adding an explanation in the document like "This was asked for at 
IETF 56" would not be sufficient.

:-)

I still do not understand. Please provide additional explanations in the 
main body of the document (or delete).


10. Section 4 Validation Response. The text states: " An unsigned response 
MUST only be generated for an error status". This is contradictory with the 
preamble where it is said:

"SCVP can be used by clients that do much of the certificate processing
themselves but simply want an untrusted server to collect information
for them."

When simply collecting certification paths, responses do not need to be
signed. Thus clients should have a way to indicate whether they want
signed responses or not.

[Trevor Freeman] This is not a requirement in 3379. The client can
ignore the signature.

[Denis] I disagree. This is a DPD requirement. RFC 3379 states:

    For the client to be confident that all of the elements from the
    response originate from the expected DPD server, an authenticated
    response MAY be required.

Signing takes time and resources. Please do not mandate the signing operation.


14. Section 4.4 requestReference, page 22. The text states: "However, the 
requestNonce provides a better mechanism for matching requests and 
responses". This is incorrect. Change into:

"While requestRef allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

[Trevor Freeman] disagree

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.


15. Section 4.4.1  requestHash, page 23. The text states: "However, the 
requestNonce provides a better mechanism for matching requests andresponses."

This is incorrect. Change into:

"While requestHash allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

[Trevor Freeman] disagree

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.


17. Section 4.6 responder, page 23. The text states: "The OPTIONAL responder 
item is used to identify the server." The rational for this parameter is not 
clear. In PKIX, the subject item from a certificate allows to identify a 
server. Since it is unrelated, it is very doubtful to have a value chosen by 
the client which has only local significance to the SCVP server. Please 
explain or delete.

[Trevor Freeman] This is a requirement of 3379.

[Denis] Maybe, but where from ? I would guess that this item is only needed 
to detect a loop when chaining is being used. If this is the case, please 
add such explanations and what the client SHALL do with it. If this is not 
the case, please add the appropriate explanations.


20. Section 4.7.5 page 28. The text states:

    "The octet string value for the AC issuer certification path used to
     verify the certificate in the request, { id-swb 5 }, contains the
     CertBundle type.  The syntax and semantics of the CertBundle type
     are described in section 3.2.7."

As already mentioned, since

     CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference

and

       PKCReference ::= CHOICE {
         cert              [1] Certificate,
         pkcRef            [2] ESSCertID }

The client should be able to say in his request whether he wants back cert 
or pkcRef. If within the signed response he gets pkcRef, then he should be 
able to say that he wants CertBundle with the option cert as an unsigned 
attribute. The integrity of this unsigned parameter can easily be checked 
using the signed pkcRef.

[Trevor Freeman] disagree

[Denis] See item 3.


21. Section 4.7.6 valPolicy, page 29. The text states: "The valPolicy value 
MUST NOT be id-svp-defaultValPolicy".

If the default policy has been used, then the client MUST be able to
know which one it was: the default policy may vary with the time.

Change into:

"When the valPolicy value is id-svp-defaultValPolicy, then all the
parameters from that policy MUST be returned."

[Trevor Freeman] Disagree. If the client wants all the parameters used
with the validation policy, then they can ask for the request to be
included in the response.

[Denis] Fine. However, it would be nice to include this explanation in the 
document.


22. Section 6 Validation Policies Response. The text states: "The response 
is not signed by the server". It would be nice to include a variant that 
would allow the response to be signed.

[Trevor Freeman] Disagree.

[Denis] You disagree but you do not provide a rational for it. Please 
explain your position.


24. Addition. At present, PKCReference is defined as:

        PKCReference ::= CHOICE {
         cert              [1] Certificate,
         pkcRef            [2] ESSCertID }

In OCSPv2 a third alternative, i.e. certIdWithSignature has been introduced. 
It would be interesting to be able to support it. It allows an OCSPserver 
(and thus an SCVP server) to answer when it does not have access to the 
value of the certificate (in particular when it *only* uses CRLs in the 
background), whereas ESSCertID would be useless.

certIdWithSignature is a compact way to specify unambiguously a certificate 
and to allow to verify a certification path.

     CertIdWithSignature ::= SEQUENCE {
          issuerandSerialNumber     IssuerandSerialNumber,
          tbsCertificateHash        BIT STRING,
          certSignature             CertSignature
     }

IssuerandSerialNumber is defined in [RFC3369] section 10.2.4.

tbsCertificateHash contains a hash value computed over the ASN.1 DER
encoded tbsCertificate field from the certificate using the hash
function identified in the signature algorithm from the signature.

certSignature contains the signature fields from the certificate.

     CertSignature ::= SEQUENCE {
          signatureAlgorithm        AlgorithmIdentifier,
          signatureValue            BIT STRING
     }
[Trevor Freeman] Disagree. This is not a requirement in 3379.

[Denis] Yes, this is not in RFC 3379 but this comes from an observation made 
after RFC 3379 was done and when the OCSPv2 draft was written. Please take a 
closer look at this issue.

Denis




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I9Lsqt078416 for <[e-mail]>; Fri, 18 Jul 2003 02:21:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I9LsDX078415 for ietf-pkix-bks; Fri, 18 Jul 2003 02:21:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4d78.pool.mediaWays.net [217.187.77.120]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I9Lqqt078381 for <[e-mail]>; Fri, 18 Jul 2003 02:21:53 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 49F742B97C for <[e-mail]>; Fri, 18 Jul 2003 11:21:38 +0200 (CEST)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id A9A441E494 for <[e-mail]>; Fri, 18 Jul 2003 11:21:37 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 18 Jul 2003 11:21:37 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030626
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <[e-mail]> <[e-mail]> <003201c34cce$e9070070$4f85900a@wcwang> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Antonio Lioy wrote:
> 
> Wen-Cheng Wang wrote:
> 
>> My concern is a CA may support dual key pairs for a single EE.
 >
> So support for multiple certs per each user should be added to the schema.

I'd suggest to read the draft. Hint: Multi-valued attributes are not the 
only way to store multiple certificates per user.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I7CNqt059534 for <[e-mail]>; Fri, 18 Jul 2003 00:12:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I7CN5U059532 for ietf-pkix-bks; Fri, 18 Jul 2003 00:12:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from polito.it (terra.polito.it [130.192.3.81]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I7C9qt059486 for <[e-mail]>; Fri, 18 Jul 2003 00:12:10 -0700 (PDT) (envelope-from [e-mail])
Received: from [130.192.1.64] (HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.1b7) with ESMTP-TLS id 9492700; Fri, 18 Jul 2003 09:00:20 +0200
Message-ID: <[e-mail]>
Date: Fri, 18 Jul 2003 09:12:37 +0200
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wen-Cheng Wang <[e-mail]>
CC: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, David Chadwick <[e-mail]>, PKIX <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <[e-mail]> <[e-mail]> <003201c34cce$e9070070$4f85900a@wcwang>
In-Reply-To: <003201c34cce$e9070070$4f85900a@wcwang>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wen-Cheng Wang wrote:
 >
> My concern is a CA may support dual key pairs for a single EE. One key pair
> is for digital signature usage; the other key pair is for encipherment usage. A
> CA
> may even support triple key pairs for a single EE if non-repudiation usage is to
> be
> separated from digital signature usage. Therefore, a CA may issues two or three
> certificates to an EE at a time. If the attribute is restricted to be single
> valued, how
> do these certificates be stored in the directory?

I can confirm that this is actually happening in Italy, where many 
legal-value CAs are giving to their customers three certs:
- one for non-repudiation
- one for authentication
- one for encryption

So support for multiple certs per each user should be added to the schema.

Cheers,

Antonio Lioy



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I1osqt040214 for <[e-mail]>; Thu, 17 Jul 2003 18:50:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I1osuv040213 for ietf-pkix-bks; Thu, 17 Jul 2003 18:50:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I1ojqt040207 for <[e-mail]>; Thu, 17 Jul 2003 18:50:51 -0700 (PDT) (envelope-from [e-mail])
Received: from ms5.chttl.com.tw (ms5 [10.144.2.115]) by fw.chttl.com.tw (8.12.9/8.11.6) with ESMTP id h6I1nue7029758; Fri, 18 Jul 2003 09:49:57 +0800 (CST)
Received: (from root@localhost) by ms5.chttl.com.tw (8.11.6/8.11.6) id h6I1obX16735; Fri, 18 Jul 2003 09:50:37 +0800
Received: from wcwang ([10.144.133.79]) by ms5.chttl.com.tw (8.11.6/8.11.6) with SMTP id h6I1obS16652; Fri, 18 Jul 2003 09:50:37 +0800
Message-ID: <003201c34cce$e9070070$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>, "David Chadwick" <[e-mail]>
Cc: "PKIX" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
Date: Fri, 18 Jul 2003 09:50:03 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Ströder Wrote:
>
> David Chadwick wrote:
> >
> > Peter and I have resolved all the issues described at the PKIX meeting
> > today, apart from one, which is what should be the attribute type to be
> > used to hold the X.509 DER encoded attribute. Should it be the original
> > attribute type name e.g. userCertificate or a new attribute whose schema
> > says it must be single valued.
>
> I'd strongly argue for back-wards compability with existing clients
> => userCertificate
>
> Off course there should be a directory profiling note stating that there
> MUST NOT more than one attribute value to be compliant. The caveat is
> off-course that the directory can't enforce the SINGLE-VALUE restriction by
> schema definition.
>
My concern is a CA may support dual key pairs for a single EE. One key pair
is for digital signature usage; the other key pair is for encipherment usage. A
CA
may even support triple key pairs for a single EE if non-repudiation usage is to
be
separated from digital signature usage. Therefore, a CA may issues two or three
certificates to an EE at a time. If the attribute is restricted to be single
valued, how
do these certificates be stored in the directory?

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HEOuqt002066 for <[e-mail]>; Thu, 17 Jul 2003 07:24:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HEOu6F002065 for ietf-pkix-bks; Thu, 17 Jul 2003 07:24:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4df4.pool.mediaWays.net [217.187.77.244]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HEOrqt002052 for <[e-mail]>; Thu, 17 Jul 2003 07:24:54 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 0DC732B8C1; Thu, 17 Jul 2003 16:24:37 +0200 (CEST)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id DE7542B88E; Thu, 17 Jul 2003 16:24:35 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 17 Jul 2003 16:24:35 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030626
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
Cc: PKIX <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick wrote:
> 
> Peter and I have resolved all the issues described at the PKIX meeting
> today, apart from one, which is what should be the attribute type to be
> used to hold the X.509 DER encoded attribute. Should it be the original
> attribute type name e.g. userCertificate or a new attribute whose schema
> says it must be single valued.

I'd strongly argue for back-wards compability with existing clients
=> userCertificate

Off course there should be a directory profiling note stating that there 
MUST NOT more than one attribute value to be compliant. The caveat is 
off-course that the directory can't enforce the SINGLE-VALUE restriction by 
schema definition.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HCxoqt095372 for <[e-mail]>; Thu, 17 Jul 2003 05:59:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HCxoWT095371 for ietf-pkix-bks; Thu, 17 Jul 2003 05:59:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HCxmqt095347 for <[e-mail]>; Thu, 17 Jul 2003 05:59:48 -0700 (PDT) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Jul 2003 05:59:44 -0700
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jul 2003 05:59:43 -0700
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Jul 2003 05:59:43 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Jul 2003 05:59:42 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jul 2003 05:59:42 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Jul 2003 05:59:40 -0700
Subject: RE: WG Last Call: SCVP
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 17 Jul 2003 05:59:42 -0700
Message-ID: <[e-mail]>
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: SCVP
Thread-Index: AcNKyrBjq5FsaZUdSgiS6ZhZRS8VNwA+elog
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 17 Jul 2003 12:59:40.0183 (UTC) FILETIME=[48B57270:01C34C63]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6HCxmqt095364
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please see below.

Comments on draft-ietf-pkix-scvp-12.txt
Simple Certificate Validation Protocol (SCVP)

As an answer to the last call, please find 24 comments on this document.

1. Section 1.3 Validation Policies

In this section the wording "validation policy" is used but is left 
undefined: "A validation policy can be used to specify the SCVP 
configuration." Please define it.

[Trevor Freeman] I have added a refernce to 3379 to define validation
policy.


2. Section 1.3 Validation Policies. The text says: " The validation
policy 
is determined by private agreement between the client and the server,
...". 
While this may be one case this is not the single case. Please delete
and 
simply say: "The validation policy MUST be represented as an OBJECT 
IDENTIFIER and optionally some additional parameters.

[Trevor Freeman] I have removed the word private.

3. In section 3, SignedData is defined with unsignedAttrs being not
used. As 
it will be explained later on, unsignedAttrs should be used to carry 
unsigned certificate values, as well as unsigned revocation information 
(CRLs in particular) while the references (much shorter) will be signed.

This has the major advantage of keeping the size of archived signed 
responses short.

[Trevor Freeman] This is not a requirment in 3379.

4. Section 3.2. The text currently says on page 9: " The OPTIONAL
valPolicy, 
trustAnchors, intermediateCerts, and revInfos items provide context for
the 
client request."

This sentence should be replaced by the following:

"Either the valPolicy item or the trustAnchors item SHALL be used. The 
intermediateCerts and revInfos items provide certificates or revocation 
status information which MAY be useful to build the response."

[Trevor Freeman]I disagree since the validation policy alone is not
enough. 3379 does not require that the validation policy and the
parameter used with that policy are represented by a single OID.


5. Section 3.2.3  wantBack

More options should be allowed to return:

1)  only the references of both the certificates and the associated 
revocation status information for the path as a signed parameter,

[Trevor Freeman] This is covered by a certificate status request.

2) both the references of both the certificates and the associated 
revocation status information for the path as signed parameter, and the 
certificate values together with the associated revocation status 
information as an unsigned attribute (see comment 3)

[Trevor Freeman] This is coved by two requests, one for certificate
status and one DPD.

Note : certificate values or associated revocation status information as
a 
signed parameter are not needed when using the two alternatives above.

[Trevor Freeman] This is not a requirement in 3379. The client is at
liberty to ignore the signature.

It is unclear why *only* the "Public key from the certificate" should be

returned. Either suppress this option, explain why it is sufficient or 
return the full certificate.

[Trevor Freeman] This reduces the footprint of a simple client.


6. Section 3.2.5  valPolicy . The text says:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client can use this
    instead of specifying other SCVP configuration items such as
    trustAnchors.  The value of this item can be determined by private
    agreement between the client and the server, but it MUST be
    represented as an object identifier.  The server might want to
    assign identifiers that indicate that some settings are used in
    addition to others given in the request.  In this way, the
    validation policy object identifier can be a shorthand for some SCVP
    options, but not others".

Replace the whole with:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client MUST either
    use it or use trustAnchors which allows to define relatively simple
    validation policies".

[Trevor Freeman] I have removed the second sentence and the word
"private" from the third sentence.


7. Section 3.2.5  valPolicy . The text says: "All SCVP servers MUST
support 
the default policy". This is fine. However, it is important that the
client 
may know the parameters of the default policy when the default policy
has 
been used by the server. So the default policy SHALL define its
parameters.

[Trevor Freeman] the default policy has no parameters - it is a set of
rules as per 3379.

In order to be able to use this protocol with Qualified Certificates (as
per 
the European Directive on Electronic Signatures) certPolicies should
further 
be subdivided in two categories: certPolicy for the end-entity
certificate 
and certPolicies for CA certificates (currently CA certificates do not
have 
certPolicies mandated as per the European Directive on Electronic
Signatures).


It is thus propose to defined three parameters for the default policy:

  - trustAnchors,
  - certPolicy for the end-entity certificate,
  - certPolicies for CA certificates.

As mentioned in the text, revocation conditions include any source of 
revocation available.

[Trevor Freeman] This is not a requirement for 3379. The trust anchors
are specified in the request. You requirements are accommodated by two
requests, one for the end cert, and one for the CA cert.

8. Section 3.2.5.1 The need and the rational for this section could not
be 
understood: an OID unambiguously identity a validation policy, a "name 
Validation Policy" or "Validation Policy name" (?) would not add
anything.
Please explain or delete.

[Trevor Freeman] This was asked for at IETF 56 as an example for another
validation policy

9. Section 3.3 Requestor. the text states: "The OPTIONAL requestor item
is 
used to identify the requestor." Since there is no identification
involved, 
change into: "The OPTIONAL requestor item is a reference local to the
requestor.

[Trevor Freeman] agreed

10. Section 4 Validation Response. The text states: " An unsigned
response 
MUST only be generated for an error status". This is contradictory with
the 
preamble where it is said:

"SCVP can be used by clients that do much of the certificate processing 
themselves but simply want an untrusted server to collect information
for them."

When simply collecting certification paths, responses do not need to be 
signed. Thus clients should have a way to indicate whether they want
signed 
responses or not.

[Trevor Freeman] This is not a requirement in 3379. The client can
ignore the signature.


11. Section 4. there is an ASN.1 syntax error. Change

        signerInfos        SET OF SignerInfos } -- Only 1 in SCVP

into:

        signerInfos        SET OF SignerInfo } -- Only 1 in SCVP
[Trevor Freeman] Agreed typo


12. Section 4, page 20, states: "The inclusion of policies in the 
SigningCertificate attribute is also OPTIONAL."

    SigningCertificate ::=  SEQUENCE {
        certs        SEQUENCE OF ESSCertID,
        policies     SEQUENCE OF PolicyInformation OPTIONAL

RFC 2634 states:

    The sequence of policy information terms identifies those
certificate
    policies that the signer asserts apply to the certificate, and under
    which the certificate should be relied upon.

The added value of policies is doubtful. Replace with :
"The policies item in the SigningCertificate attribute SHALL not be
present."
[Trevor Freeman] agreed


13. Section 4.4 requestReference, page 22. The requestRef allows the
SCVP 
server to identify the request that corresponds to this response, but
the 
client has now way to specify in his request whether he wants a hash of
the 
request or the full CVRequest. This decision should not be at the
discretion 
of the server, but chosen by the client. Please add a parameter to allow
the 
client to make the choice.

[Trevor Freeman] agreed. There is now a RequestRefHash value in the
query.


14. Section 4.4 requestReference, page 22. The text states:"However, the

requestNonce provides a better mechanism for matching requests and 
responses". This is incorrect. Change into:


"While requestRef allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

[Trevor Freeman] disagree

15. Section 4.4.1  requestHash, page 23. The text states: "However, the 
requestNonce provides a better mechanism for matching requests and
responses."

This is incorrect. Change into:

"While requestHash allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

[Trevor Freeman] disagree

16. Section 4.5 Requestor, page 23. The text states: "The OPTIONAL
requestor 
item is used to identify the requestor." This is incorrect. Change into:

"The OPTIONAL requestor item is a reference local to the requestor."

[Trevor Freeman] agree

17. Section 4.6 responder, page 23. The text states: "The OPTIONAL
responder 
item is used to identify the server." The rational for this parameter is
not 
clear. In PKIX, the subject item from a certificate allows to identify a

server. Since it is unrelated, it is very doubtful to have a value
chosen by 
the client which has only local significance to the SCVP server. Please 
explain or delete.

[Trevor Freeman] This is a requirement of 3379.

18. Section 4.7.3 replyValTime, page 26. The text states: "The
replyValTime 
item tells the time at which the information in the CertReply was
correct."

This is incorrect. Change into:

"The replyValTime item tells the time at which the server processed the 
request."

[Trevor Freeman] agree

19. Section 4.7.4 replyChecks, page 26. The text states: "The
replyChecks 
item repeats the object identifier (OID) from the query and an integer".
It 
would be more precise to say:

"The replyChecks item repeats the object identifier (OID) from the
checks 
from the query and an integer".

[Trevor Freeman] agree

20. Section 4.7.5 page 28. The text states:

   "The octet string value for the AC issuer certification path used to
    verify the certificate in the request, { id-swb 5 }, contains the
    CertBundle type.  The syntax and semantics of the CertBundle type
    are described in section 3.2.7."

As already mentioned, since

    CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference

and

      PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

The client should be able to say in his request whether he wants back
cert 
or pkcRef. If within the signed response he gets pkcRef, then he should
be 
able to say that he wants CertBundle with the option cert as an unsigned

attribute. The integrity of this unsigned parameter can easily be
checked 
using the signed pkcRef.

[Trevor Freeman] disagree

21. Section 4.7.6 valPolicy, page 29. The text states: "The valPolicy
value 
MUST NOT be id-svp-defaultValPolicy".

If the default policy has been used, then the client MUST be able to
know 
which one it was: the default policy may vary with the time.

Change into:

"When the valPolicy value is id-svp-defaultValPolicy, then all the 
parameters from that policy MUST be returned."

[Trevor Freeman] Disagree. If the client wants all the parameters used
with the validation policy, then they can ask for the request to be
included in the response.

22. Section 6 Validation Policies Response. The text states: "The
response 
is not signed by the server". It would be nice to include a variant that

would allow the response to be signed.

[Trevor Freeman] Disagree.

23. Section 9. Security Considerations. This section should import more
text 
from RFC 3379 in particular:

    When no policy reference is present in the DPV request, the DPV
    client ought to verify that the policy selected by the DPV server is
    appropriate.

    The revocation status information is obtained for the validation
    time.  In case of a digital signature, it is not necessarily
    identical to the time when the private key was used.  The validation
    time ought to be adjusted by the DPV client to compensate for:

    1) time for the end-entity to realize that its private key has been
       or could possibly be compromised, and/or

    2) time for the end-entity to report the key compromise, and/or

    3) time for the revocation authority to process the revocation
       request from the end-entity, and/or

    4) time for the revocation authority to update and distribute the
       revocation status information.

[Trevor Freeman] agreed

24. Addition. At present, PKCReference is defined as:

       PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

In OCSPv2 a third alternative, i.e. certIdWithSignature has been
introduced. 
It would be interesting to be able to support it. It allows an OCSP
server 
(and thus an SCVP server) to answer when it does not have access to the 
value of the certificate (in particular when it *only* uses CRLs in the 
background), whereas ESSCertID would be useless.

certIdWithSignature is a compact way to specify unambiguously a
certificate and to allow to verify a certification path.

    CertIdWithSignature ::= SEQUENCE {
         issuerandSerialNumber     IssuerandSerialNumber,
         tbsCertificateHash        BIT STRING,
         certSignature             CertSignature
    }


IssuerandSerialNumber is defined in [RFC3369] section 10.2.4.

tbsCertificateHash contains a hash value computed over the ASN.1 DER
encoded tbsCertificate field from the certificate using the hash
function identified in the signature algorithm from the signature.

certSignature contains the signature fields from the certificate.

    CertSignature ::= SEQUENCE {
         signatureAlgorithm        AlgorithmIdentifier,
         signatureValue            BIT STRING
    }
[Trevor Freeman] Disagree. This is not a requirement in 3379.

Denis






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HCRkqt089771 for <[e-mail]>; Thu, 17 Jul 2003 05:27:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HCRkGo089770 for ietf-pkix-bks; Thu, 17 Jul 2003 05:27:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HCRiqt089754 for <[e-mail]>; Thu, 17 Jul 2003 05:27:45 -0700 (PDT) (envelope-from [e-mail])
Received: from salford.ac.uk (DC-IBM-X30.ietf57.telekom.at [81.160.187.120]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6HCRQk20485 for <[e-mail]>; Thu, 17 Jul 2003 14:27:27 +0200 (MEST)
Message-ID: <[e-mail]>
Date: Thu, 17 Jul 2003 13:27:10 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Issues in LDAP schema IDs
Content-Type: multipart/mixed; boundary="------------AF932995C5C7561C01CD9A4B"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Dear All

Peter and I have resolved all the issues described at the PKIX meeting
today, apart from one, which is what should be the attribute type to be
used to hold the X.509 DER encoded attribute. Should it be the original
attribute type name e.g. userCertificate or a new attribute whose schema
says it must be single valued. Comments please to the list to help us
resolve this final issue.

Concerning the resolved issues, the object classes of the newly created
child entries will be created with one abstract class for the
certificate/CRL (all derived from x509base) plus appropriate structural
ocs (as now) and then additional auxiliary object classes to cater for
X.509/PKIX profile defined extensions, other PKIX defined extensions
like qualified cert extensions etc. New auxiliary object classes and
attribute types can be created by people as needed. We will define in
the current IDs auxiliary classes and attributes for X.509 standard
extensions, and some from the certificate profile (RFC 3280). Other
ones, eg. for qualified certs, may make it into these IDs are may not,
depending upon our time. We now have a proper oc structure which can be
easily and intuitively extended as required.

Regards

David

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

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


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

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

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

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

--------------AF932995C5C7561C01CD9A4B--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6H6ujqt051604 for <[e-mail]>; Wed, 16 Jul 2003 23:56:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6H6ujEj051603 for ietf-pkix-bks; Wed, 16 Jul 2003 23:56:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6H6uhqt051573 for <[e-mail]>; Wed, 16 Jul 2003 23:56:43 -0700 (PDT) (envelope-from [e-mail])
Received: from [81.160.167.150] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6H6uaD9008362; Thu, 17 Jul 2003 02:56:37 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05200f05bb3bf307e40c@[81.160.167.150]>
In-Reply-To:  <[e-mail].a u>
References:  <[e-mail].a u>
Date: Thu, 17 Jul 2003 02:57:03 -0400
To: "Manger, James H" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: IP addr: 01: use NULL instead of BOOLEAN for inherit
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

>http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
>
>I had not fully not appreciated section 2.3 "IP Address Delegation 
>Extension Certification Path Validation".  The IP address delegation 
>extension acts as both a subject name and a name constraint.  It is 
>marked as CRITICAL due to the latter role.  I wonder if combining 
>these 2 functions in one extensions is the most sensible approach? 
>[RFC 2050 "Internet Registry IP Allocation Guidelines" (section 2.1) 
>makes a distinction between the allocation of IP addresses and the 
>assignment of IP addresses.]  Perhaps you can distinguish these 
>cases based on whether or not the certificate is a CA certificate.

No, the addresses are NOT subject names. The extension represents an 
authorization to use the addresses contained therein.

>Interestingly, though a name constraint would normally have to be 
>marked critical (in case someone understands a name but not a name 
>constraint) we can probably get away without this restriction in 
>this case.  A relying party either:
>* recognizes the extension and, hence, processes the constraint that 
>address ranges must be subsumed by the address ranges in the issuers 
>certificate; or
>* does not recognize the extension and, hence, does not process the 
>constraints (so the address range may be outside that of the issuer) 
>but it ignores the address range anyway.
>It should be acceptable to ignore a name constraint if you also 
>ignore any name of the type it is constraining.  Perhaps the 
>difficulty is that the output from a typical certificate path 
>processing module cannot indicate that only a subset of the subject 
>names should be considered by the application.

You are right that, in a sense, the subsetting requirement imposed on 
validation of a cert path containing these extensions is analogous to 
that imposed by name constraints. But, this is an extension designed 
to represent authorization data, not name data, and thus the name 
constraints extension is not be appropriate here.

>If a certificate includes an IP address in the subjectAltName 
>extension must it be within the ranges defined  by any IP address 
>delegation extensions in the same certificate or certificates 
>further up the chain?  Either way, this should probably be 
>explicitly mentioned in section 2.3.
>[How about e-mail address or URIs in subjectAltName that use IP addresses?]

As I noted above, the addresses here are NOT names, so they have 
nothing to do with the subject name or subject alt name fields.

>In a certificate chain (CACert1->CACert2->CACert3->EECert) does it 
>matter which certificates have the IP address delegation extension? 
>For instance, can CACert2 and EECert have the extension but not the 
>certs before and between them?

The model envisioned here requires that all CA certs on the path 
contain the extension, terminating in an EE cert containing the 
extension. We couild clarify this in a revision of the doc.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6H2ICqt023576 for <[e-mail]>; Wed, 16 Jul 2003 19:18:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6H2ICIa023575 for ietf-pkix-bks; Wed, 16 Jul 2003 19:18:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6H2I9qt023555 for <[e-mail]>; Wed, 16 Jul 2003 19:18:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA10501 for <[e-mail]>; Thu, 17 Jul 2003 12:17:52 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdehI8o_; Thu Jul 17 12:17:09 2003
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA05077 for <[e-mail]>; Thu, 17 Jul 2003 12:17:08 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd00zWRb; Thu Jul 17 12:16:40 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA19360 for <[e-mail]>; Thu, 17 Jul 2003 12:16:39 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: IP addr: 01: use NULL instead of BOOLEAN for inherit
Date: Thu, 17 Jul 2003 12:15:25 +1000
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
Thread-Index: AcNA9we0XWFLjqzlEdeWHgAIxySt0gABo0SAAr4ZAtA=
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6H2ICqt023571
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-01.txt

I had not fully not appreciated section 2.3 "IP Address Delegation Extension Certification Path Validation".  The IP address delegation extension acts as both a subject name and a name constraint.  It is marked as CRITICAL due to the latter role.  I wonder if combining these 2 functions in one extensions is the most sensible approach?  [RFC 2050 "Internet Registry IP Allocation Guidelines" (section 2.1) makes a distinction between the allocation of IP addresses and the assignment of IP addresses.]  Perhaps you can distinguish these cases based on whether or not the certificate is a CA certificate.


Interestingly, though a name constraint would normally have to be marked critical (in case someone understands a name but not a name constraint) we can probably get away without this restriction in this case.  A relying party either:
* recognizes the extension and, hence, processes the constraint that address ranges must be subsumed by the address ranges in the issuers certificate; or
* does not recognize the extension and, hence, does not process the constraints (so the address range may be outside that of the issuer) but it ignores the address range anyway.
It should be acceptable to ignore a name constraint if you also ignore any name of the type it is constraining.  Perhaps the difficulty is that the output from a typical certificate path processing module cannot indicate that only a subset of the subject names should be considered by the application.


If a certificate includes an IP address in the subjectAltName extension must it be within the ranges defined  by any IP address delegation extensions in the same certificate or certificates further up the chain?  Either way, this should probably be explicitly mentioned in section 2.3.
[How about e-mail address or URIs in subjectAltName that use IP addresses?]


In a certificate chain (CACert1->CACert2->CACert3->EECert) does it matter which certificates have the IP address delegation extension?  For instance, can CACert2 and EECert have the extension but not the certs before and between them?




> ----------
> From: 	Manger, James H  
> Sent:	Thursday, 3 July 2003 11:26 AM
> 
> 2.
> It seems unnecessary to set these extensions to CRITICAL.  A relying party is not misled by ignoring these extensions -- it simply learns nothing new about IP address and AS allocations.
> 
> Perhaps making it CRITICAL is supposed to indicate that the certificate is binding a public key to these addresses instead of any other type of name so the subject (and subjectAltName) fields should be ignored.  If this is the case, it may be better to formulate the extensions as OTHER-NAME types to be used in the subjectAltName extension (in which case no other names needs to be included).
> 
> Perhaps making it CRITICAL is supposed to indicate that the certificate should only be used in, say, Secure BGP and not for, say, secure e-mail.  If this is the case, defining a new purpose identifier for the extendedKeyUsage extension may be more appropriate.
> 
> 	----------
> 	From: 	Russ Housley [mailto:[e-mail]] 
> 	Sent:	Thursday, 17 July 2003 12:45 AM
> 	To:	Manger, James H; [e-mail]
> 
> 	Since the extension imposes constraints on the values of subordinate certificates, it is clear that it must be critical in CA certificates.  I suppose that it could be non-critical in end entity certificates, but the certificate user must be able to process the extension in the CA certificates.  Not clear there is any value in allowing it to be non-critical only in end entity certificates.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GEpLqt084970 for <[e-mail]>; Wed, 16 Jul 2003 07:51:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GEpLGV084969 for ietf-pkix-bks; Wed, 16 Jul 2003 07:51:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6GEpKqt084964 for <[e-mail]>; Wed, 16 Jul 2003 07:51:20 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 19761 invoked by uid 0); 16 Jul 2003 14:50:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (81.160.169.162) by woodstock.binhost.com with SMTP; 16 Jul 2003 14:50:08 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 16 Jul 2003 10:44:50 -0400
To: "Manger, James H" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: IP addr: 01: use NULL instead of BOOLEAN for inherit
In-Reply-To: <[e-mail] l.telstra.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since the extension imposes constraints on the values of subordinate 
certificates, it is clear that it must be critical in CA certificates.  I 
suppose that it could be non-critical in end entity certificates, but the 
certificate user must be able to process the extension in the CA 
certificates.  Not clear there is any value in allowing it to be 
non-critical only in end entity certificates.

Russ

At 11:26 AM 7/3/2003 +1000, Manger, James H wrote:
>It seems unnecessary to set these extensions to CRITICAL.  A relying party 
>is not misled by ignoring these extensions -- it simply learns nothing new 
>about IP address and AS allocations.
>
>Perhaps making it CRITICAL is supposed to indicate that the certificate is 
>binding a public key to these addresses instead of any other type of name 
>so the subject (and subjectAltName) fields should be ignored.  If this is 
>the case, it may be better to formulate the extensions as OTHER-NAME types 
>to be used in the subjectAltName extension (in which case no other names 
>needs to be included).
>
>Perhaps making it CRITICAL is supposed to indicate that the certificate 
>should only be used in, say, Secure BGP and not for, say, secure 
>e-mail.  If this is the case, defining a new purpose identifier for the 
>extendedKeyUsage extension may be more appropriate.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6G7miqt043509 for <[e-mail]>; Wed, 16 Jul 2003 00:48:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6G7migJ043508 for ietf-pkix-bks; Wed, 16 Jul 2003 00:48:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6G7mgqt043498 for <[e-mail]>; Wed, 16 Jul 2003 00:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h6G7lCw1021557; Wed, 16 Jul 2003 03:47:12 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.9/8.12.9) with ESMTP id h6G7lCKH009988; Wed, 16 Jul 2003 03:47:12 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.9/8.12.9/Submit) id h6G7l9RE009987; Wed, 16 Jul 2003 03:47:09 -0400 (EDT)
Received: from 81.160.236.34 ( [81.160.236.34]) as user [e-mail] by imp.nist.gov with HTTP; Wed, 16 Jul 2003 03:47:09 -0400
Message-ID: <[e-mail]>
Date: Wed, 16 Jul 2003 03:47:09 -0400
From: [e-mail]
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Proxy Certificates - WG Last Call Closed
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

WG Last Call for the Proxy Certificate specification is now closed.  The WG 
review has not generated any new technical issues, demonstrating that working 
group consensus has been achieved.

The editors will be submitting a new draft to resolve editorial issues raised 
by the chairs.  The new draft will identify normative and informative 
references and has a smaller editorial group.  These changes are not normative 
but will facilitate successful IESG review.

The new draft will be forwarded to the ADs when it appears in the Internet 
Draft repository.

Thanks,

Tim (and Steve)


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FIV7qt095267 for <[e-mail]>; Tue, 15 Jul 2003 11:31:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FIV77w095266 for ietf-pkix-bks; Tue, 15 Jul 2003 11:31:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FIV6qt095258 for <[e-mail]>; Tue, 15 Jul 2003 11:31:07 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h6FIUhVd030042; Tue, 15 Jul 2003 14:31:03 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Steve Hanna'" <[e-mail]>
Cc: "'PKIX List'" <[e-mail]>
Subject: RE: Question about Certificate Issuer CRL Entry Extension
Date: Tue, 15 Jul 2003 14:30:27 -0400
Message-ID: <003401c34aff$3f3e4fb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6FIV7qt095261
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

I think Steve Henna is talking about certificate issuer name in the CRL
entry extension and the need to match it to the issuer DN of the certificate
of interest. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Tuesday, July 15, 2003 8:48 AM
To: Steve Hanna
Cc: PKIX List
Subject: Re: Question about Certificate Issuer CRL Entry Extension



Steve,

> The Certificate Issuer CRL entry extension (described in section 5.3.4 
> of RFC 3280) is a GeneralNames structure that identifies the 
> certificate issuer for the CRL entry to which it is attached (and also 
> to all subsequent entries in that CRL until another Certificate Issuer 
> CRL entry extension is encountered.

> RFC 3280 doesn't say so, but I believe that within a PKIX
> (Internet) environment (where each certificate must have a non-empty 
> X.500 issuer name and issuer alternative names are generally ignored) 
> this extension MUST always contain at least one X.500 name so that the 
> relying party can match this name against the issuer name in the 
> certificate, as described in section 6.3.3 item (j) of RFC 3280. And I 
> think that text describing this requirement should be added to the
> successor to RFC 3280. Does everyone agree with this?

Matching a CRL Issuer name against a CA name is not always required, but 
having one name format would be nice. Would would be the exact phrasing ?

> I also wonder whether anyone can think of a reason why this CRL entry 
> extension should ever contain anything other than a single X.500 name 
> in a PKIX (Internet) environment. If not, then the requirement can 
> (and should) be made even more strict, specifying that this extension 
> MUST contain only a single X.500 name. Please let me know if you have 
> a reason why this would not be a good idea.

What about certificates issued after December 31, 2003 ?

RFC 3280 states:

    The UTF8String encoding [RFC 2279] is the preferred encoding,
    and all certificates issued after December 31, 2003 MUST use
    the UTF8String encoding of DirectoryString.

Isn't there a reason to have the same name encoded both using 
printableString and utf8String during some transition period ?

Denis

> Thanks,
> 
> Steve





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FD0xqt075179 for <[e-mail]>; Tue, 15 Jul 2003 06:00:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FD0xhw075176 for ietf-pkix-bks; Tue, 15 Jul 2003 06:00:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FD0vqt075145; Tue, 15 Jul 2003 06:00:58 -0700 (PDT) (envelope-from [e-mail])
Received: from [81.160.154.187] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6FCxwDD029536; Tue, 15 Jul 2003 09:00:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05200f04bb39a7534e0a@[81.160.154.187]>
In-Reply-To: <000301c34ab3$cb30a4b0$[e-mail]>
References: <000301c34ab3$cb30a4b0$[e-mail]>
Date: Tue, 15 Jul 2003 08:46:24 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Discussing RTCS
Cc: "'Denis Pinkas'" <[e-mail]>, "'Sean P. Turner'" <[e-mail]>, <[e-mail]>, "'pkix'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:30 +0200 7/15/03, Jim Schaad wrote:
>I agree with Denis, this is a certificate validation issue and as such
>belongs in the PKIX WG if to be standardized by the IETF.  I think that
>we can provide a review of the document if requested for it's usage of
>CMS, but not it's general suitablity.
>
>jim
>

Jim,

I agree with you and Denis that this is really a PKIX matter, vs. an 
S/MIME matter. However, I had several problems with Peter bringing 
this in as a WG item:
	- we already have OCSP and OCSPv2 has been worked on

	- this protocol goes beyond the OCSP semantics to provide 
delegated cert (not cert path) validation. we have just agreed to 
adopt SCVP for delegated cert path validation, and I was worried that 
this overlap would conflict with SCVP

	- PKIX has been told to not take on new work items


Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FCmAqt073051 for <[e-mail]>; Tue, 15 Jul 2003 05:48:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FCmApM073049 for ietf-pkix-bks; Tue, 15 Jul 2003 05:48:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FCm6qt073029 for <[e-mail]>; Tue, 15 Jul 2003 05:48:08 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA20026; Tue, 15 Jul 2003 14:52:42 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id OAA07561; Tue, 15 Jul 2003 14:48:15 +0200
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2003 14:48:03 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: PKIX List <[e-mail]>
Subject: Re: Question about Certificate Issuer CRL Entry Extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

> The Certificate Issuer CRL entry extension (described in
> section 5.3.4 of RFC 3280) is a GeneralNames structure
> that identifies the certificate issuer for the CRL entry
> to which it is attached (and also to all subsequent entries
> in that CRL until another Certificate Issuer CRL entry
> extension is encountered.

> RFC 3280 doesn't say so, but I believe that within a PKIX
> (Internet) environment (where each certificate must have a
> non-empty X.500 issuer name and issuer alternative names are
> generally ignored) this extension MUST always contain at
> least one X.500 name so that the relying party can match
> this name against the issuer name in the certificate, as
> described in section 6.3.3 item (j) of RFC 3280. And I think
> that text describing this requirement should be added to the
> successor to RFC 3280. Does everyone agree with this?

Matching a CRL Issuer name against a CA name is not always required, but 
having one name format would be nice. Would would be the exact phrasing ?

> I also wonder whether anyone can think of a reason why this
> CRL entry extension should ever contain anything other than
> a single X.500 name in a PKIX (Internet) environment. If not,
> then the requirement can (and should) be made even more strict,
> specifying that this extension MUST contain only a single X.500
> name. Please let me know if you have a reason why this would not
> be a good idea.

What about certificates issued after December 31, 2003 ?

RFC 3280 states:

    The UTF8String encoding [RFC 2279] is the preferred encoding,
    and all certificates issued after December 31, 2003 MUST use
    the UTF8String encoding of DirectoryString.

Isn't there a reason to have the same name encoded both using 
printableString and utf8String during some transition period ?

Denis

> Thanks,
> 
> Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FBAGqt064047 for <[e-mail]>; Tue, 15 Jul 2003 04:10:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FBAG8Q064046 for ietf-pkix-bks; Tue, 15 Jul 2003 04:10:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FBADqt064037 for <[e-mail]>; Tue, 15 Jul 2003 04:10:14 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA26484; Tue, 15 Jul 2003 13:14:52 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id NAA07065; Tue, 15 Jul 2003 13:10:24 +0200
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2003 13:10:12 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: WG Last Call: SCVP
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> This message initiates working group Last Call for the Simple Certificate
> Validation Protocol.
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not 
> close before July 22.
> 
> The URL for this Internet-Draft is:
>   http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-12.txt 
>  
> The -12 draft includes minor enhancements to bring the specification into
> full compliance with RFC 3379.
>  
> Thanks,
> 
> Tim Polk

Comments on draft-ietf-pkix-scvp-12.txt
Simple Certificate Validation Protocol (SCVP)

As an answer to the last call, please find 24 comments on this document.

1. Section 1.3 Validation Policies

In this section the wording "validation policy" is used but is left 
undefined: "A validation policy can be used to specify the SCVP 
configuration." Please define it.


2. Section 1.3 Validation Policies. The text says: " The validation policy 
is determined by private agreement between the client and the server, ...". 
While this may be one case this is not the single case. Please delete and 
simply say: "The validation policy MUST be represented as an OBJECT 
IDENTIFIER and optionally some additional parameters.


3. In section 3, SignedData is defined with unsignedAttrs being not used. As 
it will be explained later on, unsignedAttrs should be used to carry 
unsigned certificate values, as well as unsigned revocation information 
(CRLs in particular) while the references (much shorter) will be signed. 
This has the major advantage of keeping the size of archived signed 
responses short.


4. Section 3.2. The text currently says on page 9: " The OPTIONAL valPolicy, 
trustAnchors, intermediateCerts, and revInfos items provide context for the 
client request."

This sentence should be replaced by the following:

"Either the valPolicy item or the trustAnchors item SHALL be used. The 
intermediateCerts and revInfos items provide certificates or revocation 
status information which MAY be useful to build the response."


5. Section 3.2.3  wantBack

More options should be allowed to return:

1)  only the references of both the certificates and the associated 
revocation status information for the path as a signed parameter,

2) both the references of both the certificates and the associated 
revocation status information for the path as signed parameter, and the 
certificate values together with the associated revocation status 
information as an unsigned attribute (see comment 3)

Note : certificate values or associated revocation status information as a 
signed parameter are not needed when using the two alternatives above.

It is unclear why *only* the "Public key from the certificate" should be 
returned. Either suppress this option, explain why it is sufficient or 
return the full certificate.


6. Section 3.2.5  valPolicy . The text says:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client can use this
    instead of specifying other SCVP configuration items such as
    trustAnchors.  The value of this item can be determined by private
    agreement between the client and the server, but it MUST be
    represented as an object identifier.  The server might want to
    assign identifiers that indicate that some settings are used in
    addition to others given in the request.  In this way, the
    validation policy object identifier can be a shorthand for some SCVP
    options, but not others".

Replace the whole with:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client MUST either
    use it or use trustAnchors which allows to define relatively simple
    validation policies".


7. Section 3.2.5  valPolicy . The text says: "All SCVP servers MUST support 
the default policy". This is fine. However, it is important that the client 
may know the parameters of the default policy when the default policy has 
been used by the server. So the default policy SHALL define its parameters.

In order to be able to use this protocol with Qualified Certificates (as per 
the European Directive on Electronic Signatures) certPolicies should further 
be subdivided in two categories: certPolicy for the end-entity certificate 
and certPolicies for CA certificates (currently CA certificates do not have 
certPolicies mandated as per the European Directive on Electronic Signatures).

It is thus propose to defined three parameters for the default policy:

  - trustAnchors,
  - certPolicy for the end-entity certificate,
  - certPolicies for CA certificates.

As mentioned in the text, revocation conditions include any source of 
revocation available.


8. Section 3.2.5.1 The need and the rational for this section could not be 
understood: an OID unambiguously identity a validation policy, a "name 
Validation Policy" or "Validation Policy name" (?) would not add anything.
Please explain or delete.


9. Section 3.3 Requestor. the text states: "The OPTIONAL requestor item is 
used to identify the requestor." Since there is no identification involved, 
change into: "The OPTIONAL requestor item is a reference local to the requestor.


10. Section 4 Validation Response. The text states: " An unsigned response 
MUST only be generated for an error status". This is contradictory with the 
preamble where it is said:

"SCVP can be used by clients that do much of the certificate processing 
themselves but simply want an untrusted server to collect information for them."

When simply collecting certification paths, responses do not need to be 
signed. Thus clients should have a way to indicate whether they want signed 
responses or not.


11. Section 4. there is an ASN.1 syntax error. Change

        signerInfos        SET OF SignerInfos } -- Only 1 in SCVP

into:

        signerInfos        SET OF SignerInfo } -- Only 1 in SCVP


12. Section 4, page 20, states: "The inclusion of policies in the 
SigningCertificate attribute is also OPTIONAL."

    SigningCertificate ::=  SEQUENCE {
        certs        SEQUENCE OF ESSCertID,
        policies     SEQUENCE OF PolicyInformation OPTIONAL

RFC 2634 states:

    The sequence of policy information terms identifies those certificate
    policies that the signer asserts apply to the certificate, and under
    which the certificate should be relied upon.

The added value of policies is doubtful. Replace with :
"The policies item in the SigningCertificate attribute SHALL not be present."


13. Section 4.4 requestReference, page 22. The requestRef allows the SCVP 
server to identify the request that corresponds to this response, but the 
client has now way to specify in his request whether he wants a hash of the 
request or the full CVRequest. This decision should not be at the discretion 
of the server, but chosen by the client. Please add a parameter to allow the 
client to make the choice.


14. Section 4.4 requestReference, page 22. The text states:"However, the 
requestNonce provides a better mechanism for matching requests and 
responses". This is incorrect. Change into:

"While requestRef allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."


15. Section 4.4.1  requestHash, page 23. The text states: "However, the 
requestNonce provides a better mechanism for matching requests and responses."

This is incorrect. Change into:

"While requestHash allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."


16. Section 4.5 Requestor, page 23. The text states: "The OPTIONAL requestor 
item is used to identify the requestor." This is incorrect. Change into:

"The OPTIONAL requestor item is a reference local to the requestor."


17. Section 4.6 responder, page 23. The text states: "The OPTIONAL responder 
item is used to identify the server." The rational for this parameter is not 
clear. In PKIX, the subject item from a certificate allows to identify a 
server. Since it is unrelated, it is very doubtful to have a value chosen by 
the client which has only local significance to the SCVP server. Please 
explain or delete.


18. Section 4.7.3 replyValTime, page 26. The text states: "The replyValTime 
item tells the time at which the information in the CertReply was correct."

This is incorrect. Change into:

"The replyValTime item tells the time at which the server processed the 
request."


19. Section 4.7.4 replyChecks, page 26. The text states: "The replyChecks 
item repeats the object identifier (OID) from the query and an integer". It 
would be more precise to say:

"The replyChecks item repeats the object identifier (OID) from the checks 
from the query and an integer".


20. Section 4.7.5 page 28. The text states:

   "The octet string value for the AC issuer certification path used to
    verify the certificate in the request, { id-swb 5 }, contains the
    CertBundle type.  The syntax and semantics of the CertBundle type
    are described in section 3.2.7."

As already mentioned, since

    CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference

and

      PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

The client should be able to say in his request whether he wants back cert 
or pkcRef. If within the signed response he gets pkcRef, then he should be 
able to say that he wants CertBundle with the option cert as an unsigned 
attribute. The integrity of this unsigned parameter can easily be checked 
using the signed pkcRef.


21. Section 4.7.6 valPolicy, page 29. The text states: "The valPolicy value 
MUST NOT be id-svp-defaultValPolicy".

If the default policy has been used, then the client MUST be able to know 
which one it was: the default policy may vary with the time.

Change into:

"When the valPolicy value is id-svp-defaultValPolicy, then all the 
parameters from that policy MUST be returned."


22. Section 6 Validation Policies Response. The text states: "The response 
is not signed by the server". It would be nice to include a variant that 
would allow the response to be signed.


23. Section 9. Security Considerations. This section should import more text 
from RFC 3379 in particular:

    When no policy reference is present in the DPV request, the DPV
    client ought to verify that the policy selected by the DPV server is
    appropriate.

    The revocation status information is obtained for the validation
    time.  In case of a digital signature, it is not necessarily
    identical to the time when the private key was used.  The validation
    time ought to be adjusted by the DPV client to compensate for:

    1) time for the end-entity to realize that its private key has been
       or could possibly be compromised, and/or

    2) time for the end-entity to report the key compromise, and/or

    3) time for the revocation authority to process the revocation
       request from the end-entity, and/or

    4) time for the revocation authority to update and distribute the
       revocation status information.


24. Addition. At present, PKCReference is defined as:

       PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

In OCSPv2 a third alternative, i.e. certIdWithSignature has been introduced. 
It would be interesting to be able to support it. It allows an OCSP server 
(and thus an SCVP server) to answer when it does not have access to the 
value of the certificate (in particular when it *only* uses CRLs in the 
background), whereas ESSCertID would be useless.

certIdWithSignature is a compact way to specify unambiguously a
certificate and to allow to verify a certification path.

    CertIdWithSignature ::= SEQUENCE {
         issuerandSerialNumber     IssuerandSerialNumber,
         tbsCertificateHash        BIT STRING,
         certSignature             CertSignature
    }

IssuerandSerialNumber is defined in [RFC3369] section 10.2.4.

tbsCertificateHash contains a hash value computed over the ASN.1 DER
encoded tbsCertificate field from the certificate using the hash
function identified in the signature algorithm from the signature.

certSignature contains the signature fields from the certificate.

    CertSignature ::= SEQUENCE {
         signatureAlgorithm        AlgorithmIdentifier,
         signatureValue            BIT STRING
    }

Denis





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FB3Nqt063641 for <[e-mail]>; Tue, 15 Jul 2003 04:03:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FB3N0R063640 for ietf-pkix-bks; Tue, 15 Jul 2003 04:03:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FB3Lqt063633; Tue, 15 Jul 2003 04:03:22 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6FB2YYM012981; Tue, 15 Jul 2003 23:02:34 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6FB2We15157; Tue, 15 Jul 2003 23:02:32 +1200
Date: Tue, 15 Jul 2003 23:02:32 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Discussing RTCS
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>This is a topic to be addressed by the PKIX WG, not by the SMIME WG.

We already tried that, but you made sure it wouldn't work.

For those who aren't on the PKIX list, a short summary:

- Denis has some sort of rabid opposition to what RTCS does.  I had private
  mail from another PKIX member to say that RTCS' crime is that it provides a
  basic yes/no response rather than a CRL-style revoked/not revoked/maybe/
  maybe not response.  Someone else thought that it was because it made OCSP
  look bad.  I'm not sure what it really is.

- The result of this was a series of increasingly hysterical attacks by Denis
  on RTCS, using every reason he could dream up (see the PKIX list from late
  last year some time).  The highlights were him posting several messages in
  which he quoted sections of text and claimed the exact opposite of what the
  text said.  In one message I got a quote of him saying something wasn't
  possible, after which I had another quote of him saying the exact opposite
  earlier on.  You get the idea... the debate wasn't very coherent, or useful,
  except perhaps for amusement value.

- When his hissy fit on the list failed, he tried a private appeal to the WG
  chair to get it killed.

- The only (unfortunate) effect of his fit was that it drove most of the
  discussion into private mail, because no-one (apart from me apparently :-)
  wanted to become the target of his attacks.  I did, however, get some good
  feedback, which made it into the new draft.

So because of Denis it isn't really possible to have any coherent discussion
on the PKIX list.  My last message to him on that list was:

  It's obvious from your messages (and others have commented on this as well)
  that you've barely read the RTCS draft (if at all), and even then only to
  pick out bits to complain about.  The posting of obviously incorrect claims
  such as the ones cited above aren't helping your credibility much either.

As the next sentence from his current post shows:

  The advantages of this new protocol versus draft-ietf-pkix-ocspv2-ext-01.txt
  (Online Certificate Status Protocol, version 2) and the differences should
  be first explained.

he still hasen't actually read the draft.  Hint for Denis: The answer to your
question is in Section 2, right after the Abstract, which is section 1.  I'm
now pointing this out for the third (or fourth) time, but I doubt it'll make
any difference.

So to summarise: Denis has some sort of strong religious objection to RTCS.
He will engage in whatever hysterics he thinks necessary to attack it.  If
anyone wants to see the rest, see the PKIX thread on this (or wait for Denis'
next message).

Peter (sorry for the sarcasm and whatnot, but I was hoping he'd finalled given
       up after the last time... it's like listening to a broken record.  In
       the meantime, as ever, I welcome constructive feedback on RTCS).


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F9UTqt055329 for <[e-mail]>; Tue, 15 Jul 2003 02:30:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6F9UT59055327 for ietf-pkix-bks; Tue, 15 Jul 2003 02:30:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F9USqt055320; Tue, 15 Jul 2003 02:30:28 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (unknown [81.160.64.139]) by smtp4.pacifier.net (Postfix) with ESMTP id 9023D6A9C8; Tue, 15 Jul 2003 02:08:03 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Sean P. Turner'" <[e-mail]>
Cc: <[e-mail]>, "'pkix'" <[e-mail]>
Subject: RE: Discussing RTCS
Date: Tue, 15 Jul 2003 11:30:53 +0200
Message-ID: <000301c34ab3$cb30a4b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Denis, this is a certificate validation issue and as such
belongs in the PKIX WG if to be standardized by the IETF.  I think that
we can provide a review of the document if requested for it's usage of
CMS, but not it's general suitablity.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Tuesday, July 15, 2003 10:29 AM
> To: Sean P. Turner
> Cc: [e-mail]; pkix
> Subject: Re: Discussing RTCS
> 
> 
> 
> Sean,
> 
> > Does anyone have an opinion on bringing this to the working group?
> 
> This is a topic to be addressed by the PKIX WG, not by the SMIME WG.
> 
> The PKIX WG is attempting (but not always succeeding) to 
> avoid duplication 
> of protocols for the same topic.
> 
> We all know that it would have been better to use CMS for 
> building the OCSP 
>   protocol, but this was not the case.
> 
> The advantages of this new protocol versus 
> draft-ietf-pkix-ocspv2-ext-01.txt 
> (Online Certificate Status Protocol, version 2) and the 
> differences should 
> be first explained.
> 
> Denis
> 
> 
> > spt
> > 
> > Blake Ramsdell wrote:
> > 
> >>Peter Gutmann has made an individual draft submission for his 
> >>CMS-based RTCS protocol.  A URL to this draft is:
> >>
> >>http://www.ietf.org/internet-drafts/draft-gutmann-cms-rtcs-00.txt
> >>
> >>He would like to get some review of the CMS parts of this, and it 
> >>seems reasonable to discuss it here on the IETF-SMIME list 
> if there is 
> >>interest.
> >>
> >>Since this draft is CMS based and potentially adds value to CMS or 
> >>S/MIME in general, should we consider bringing it into this working 
> >>group?
> >>
> >>Comments?
> >>
> >>Blake
> >>--
> >>Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
> >>
> >>  
> >>
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F9Mfqt054268 for <[e-mail]>; Tue, 15 Jul 2003 02:22:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6F9MfZq054267 for ietf-pkix-bks; Tue, 15 Jul 2003 02:22:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F9Mdqt054262 for <[e-mail]>; Tue, 15 Jul 2003 02:22:40 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA37892; Tue, 15 Jul 2003 11:27:16 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA06554; Tue, 15 Jul 2003 11:22:47 +0200
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2003 11:22:34 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Hesse <[e-mail]>, "'Matt Cooper'" <[e-mail]>, "'Yuriy Dzambasow'" <[e-mail]>, "'Susan Joseph'" <[e-mail]>, "Richard E. Nicholas (Nicholas, Richard)" <[e-mail]>
CC: Steve Hanna <[e-mail]>, "'PKIX List'" <[e-mail]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
References: <009601c347d6$eed5ac60$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments on certpathbuild-00.txt

The title of the document was promising, but the content is not exactly what 
would have been expected.

The topic should be how to allow interoperability to find out the elements 
(i.e. both the certificates and the associated revocation status 
information) needed for to build a certification path either walking 
downwards or upwards the certification tree.

The document should explain how inserting some of the extensions defined in 
RFC 3280 will allow to build the certification path, irrespective of local 
conditions (e.g. the user does not have a XX-xxxxxxDirectory where 
everything needed is stored. :-)  )

Some interesting elements are provided starting page 54, in sections 6.2 and 
6.3. but this is far from sufficient.

There are two solutions to this problem, either walking downwards or upwards 
the certification tree.


A. Walking downwards the certification tree.

Each trust point SHOULD include in the self-signed certificate the way to 
find out where the CA has placed the CA certificates that it issues. This 
SHALL be done using the Subject Information Access extension defined in 
section 4.2.2.2 from RFC 3280.

The id-ad-caRepository OID SHALL be used to indicate in which repository the 
CA publishes its certificates and CRLs (if issued).

Each CA certificate SHOULD also include the Subject Information Access 
extension defined in section 4.2.2.2. from RFC 3280.

This is the preferred method, since anyway trust points MUST be known.


B. Walking upwards the certification tree.

Each end-entity certificate and each CA certificate SHOULD include the way 
to find out where the CA is placing the other certificates. This SHALL be 
done using the Authority Information Access extension defined in section 
4.2.2.1 from RFC 3280 :

The id-ad-caIssuers OID SHALL be used to list where the CA that has issued 
the certificate lists CA certificates issued to the CA.

This extension SHOULD be included in end-entity certificates and CA 
certificates.

This can only be a complement to the previous method, since anyway trust 
points MUST be known. When the downwards approach does not succeed (explain 
in which cases, it may not succeed), then a combination of both methods may 
succeed.

Note: The location of CRLs is not specified in this extension. That 
information is provided by the cRLDistributionPoints extension.


C. Revocation checking

For revocation checking each end-entity and CA certificate SHALL either 
include :

    a) a cRLDistributionPoints extension, or
    b) Subject Information access extension that includes the id-ad-ocsp OID
       to indicate the location of servers using the Online Certificate
       Status Protocol (OCSP) [RFC 2560].


Other comments.

1. The difference between a CA-certificate and a cross-certificate is still 
very hazy since what means a "realm" is either left undefined or is said to 
be "dependant upon local policy". It is thus impossible to have standard 
rules with such an approach.

Introducing naming constraints between subject and issuer names might be 
more appropriate; however, the real question is the following:

Is it really important to make the difference if both:

  - the pointers to CA repositories are present, and
  - these repositories entries are correctly filled-in ?


2. There is, as usual, some confusion between cross certification (which is, 
by definition, unilateral) and mutual cross certification (see section 
13.2). Figure 3 does not make sense unless the trust points are indicated.


3. The case of validating a certificate in the past after a CA key rollover 
(using the new root key) should be addressed.


4. An interesting case to discuss would be the encoding of the issuer name 
before and after December 31, 2003 since all certificates issued after 
December 31, 2003 MUST use the UTF8String encoding of DirectoryString 
(except as noted). The case of "name rollover" certificates to support an 
orderly migration to UTF8String encoding should be explained .


5. The document is far too long.


Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F8Suqt045017 for <[e-mail]>; Tue, 15 Jul 2003 01:28:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6F8SuEo045015 for ietf-pkix-bks; Tue, 15 Jul 2003 01:28:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F8Shqt044980; Tue, 15 Jul 2003 01:28:44 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA37988; Tue, 15 Jul 2003 10:33:13 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA06126; Tue, 15 Jul 2003 10:28:44 +0200
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2003 10:28:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Sean P. Turner" <[e-mail]>
CC: [e-mail], pkix <[e-mail]>
Subject: Re: Discussing RTCS
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sean,

> Does anyone have an opinion on bringing this to the working group?

This is a topic to be addressed by the PKIX WG, not by the SMIME WG.

The PKIX WG is attempting (but not always succeeding) to avoid duplication 
of protocols for the same topic.

We all know that it would have been better to use CMS for building the OCSP 
  protocol, but this was not the case.

The advantages of this new protocol versus draft-ietf-pkix-ocspv2-ext-01.txt 
(Online Certificate Status Protocol, version 2) and the differences should 
be first explained.

Denis


> spt
> 
> Blake Ramsdell wrote:
> 
>>Peter Gutmann has made an individual draft submission for his CMS-based
>>RTCS protocol.  A URL to this draft is:
>>
>>http://www.ietf.org/internet-drafts/draft-gutmann-cms-rtcs-00.txt
>>
>>He would like to get some review of the CMS parts of this, and it seems
>>reasonable to discuss it here on the IETF-SMIME list if there is
>>interest.
>>
>>Since this draft is CMS based and potentially adds value to CMS or
>>S/MIME in general, should we consider bringing it into this working
>>group?
>>
>>Comments?
>>
>>Blake
>>--
>>Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 
>>
>>  
>>
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EKUuqt000724 for <[e-mail]>; Mon, 14 Jul 2003 13:30:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EKUuJo000723 for ietf-pkix-bks; Mon, 14 Jul 2003 13:30:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EKUsqt000710 for <[e-mail]>; Mon, 14 Jul 2003 13:30:54 -0700 (PDT) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Jul 2003 13:30:51 -0700
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Jul 2003 13:30:50 -0700
Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 14 Jul 2003 13:30:50 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 14 Jul 2003 13:30:50 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 14 Jul 2003 13:30:50 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 14 Jul 2003 13:30:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Creating client certificate in IE browser using xenroll.dll
Date: Mon, 14 Jul 2003 13:30:46 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Creating client certificate in IE browser using xenroll.dll
Thread-Index: AcNJnc/6Psi5G4HsTF6leTu9eQmSGAAbuIhwAA6DjHA=
From: "Ryan M. Hurst" <[e-mail]>
To: "Sreenivasa Baddam" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 14 Jul 2003 20:30:46.0705 (UTC) FILETIME=[CE5FB210:01C34A46]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6EKUsqt000716
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Take a look at ICEnroll/ICEnroll2/ICEnroll4 on MSDN they implement the
interfaces you want.

Ryan M. Hurst
Program Manager
Windows Trusted Platform Infrastructure
Microsoft Corporation


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sreenivasa Baddam
Sent: Monday, July 14, 2003 6:36 AM
To: [e-mail]
Subject: Creating client certificate in IE browser using xenroll.dll


> Hi All,
>   I am trying to generate a public key in the client using IE browser
with the active-x control xenroll.dll using the following code got from
the link http://www.pseudonym.org/ssl/ssl_cook.html (a good one).  The
link used certenroll.dll but since new versions of IE are using
xenroll.dll, I changed in the code from certenroll to xenroll.  But
still I am not able to generate it.  The error I am getting is:'Object
doesn't support this property or method'.  The reason I judged is that
'GenerateKeyPair' method signature is not the right one.  
>   I searched in the internet as well as the microsoft dev site but
couldn't able to get the right solution.  Anyone out there faced this
kind of problem or any suggestions as to how to get the method
signatures in a dll file would be greatly appreciated.
> 
> Thanks,
> Sreeni
> 
> Here is the whole code, you can run it on your own machine too & see
it. 
> ############################
> <HTML><HEAD><TITLE>Client Certificate Request</TITLE></HEAD><BODY>
> 
> <!-- Use the Microsoft ActiveX control to generate the certificate -->
> <OBJECT CLASSID="clsid:33BEC9E0-F78F-11cf-B782-00C04FD7BF43"
CODEBASE=xenroll.dll ID=certHelper>
> </OBJECT>
> 
> <!-- JavaScript or Visual Basic will work. -->
> <SCRIPT LANGUAGE="JavaScript">
> <!---
> 
> // this is from JavaScript: The Definitive Guide, since
> // Microsoft implementation of Math.random() is broken
> //
> function random() {
>     random.seed = (random.seed*random.a + random.c) % random.m;
>     return random.seed/random.m;
> }
> random.m = 714025; random.a = 4096; random.c = 150889;
> random.seed = (new Date()).getTime()%random.m;
> 
> function GenReq ()
> {
>     var sessionId		= "a_unique_session_id";
>     var reqHardware     	= 0;
>     var szName          	= "";
>     var szPurpose       	= "ClientAuth";
>     var doAcceptanceUINow   	= 0;
>     var doAcceptanceUILater	= 0;
>     var doOnline        	= 1;
>     var keySpec = 1;
> 
>     szName = "";
>     
>     if (document.GenReqForm.commonName.value == "")
>     {
> 	alert("No Common Name");
> 	return false;
>     } 
>     else
>      szName = "CN=" + document.GenReqForm.commonName.value;
> 
>     if (document.GenReqForm.countryName.value == "")
>     {
> 	alert("No Country");
> 	return false;
>     }
>     else
> 	szName = szName + "; C=" +
document.GenReqForm.countryName.value;
> 
>     if (document.GenReqForm.stateOrProvinceName.value == "")
>     {
> 	alert("No State or Province");
> 	return false;
>     }
>     else
> 	szName = szName + "; S=" +
document.GenReqForm.stateOrProvinceName.value;
> 
>     if (document.GenReqForm.localityName.value == "")
>     {
> 	alert("No City");
> 	return false;
>     }
>     else
> 	szName = szName + "; L=" +
document.GenReqForm.localityName.value;
> 
>     if (document.GenReqForm.organizationName.value == "")
>     {
> 	alert("No Organization");
> 	return false;
>     }
>     else
> 	szName = szName + "; O=" +
document.GenReqForm.organizationName.value;
> 
>     if (document.GenReqForm.organizationalUnitName.value == "")
>     {
> 	alert("No Organizational Unit");
> 	return false;
>     }
>     else
> 	szName = szName + "; OU=" +
document.GenReqForm.organizationalUnitName.value;
> 
>     /* make session id unique */
>     sessionId = "xx" + Math.round(random() * 1000); 
>     alert('sz10='+sz10);
>     sz10 = certHelper.GenerateKeyPair(sessionId, reqHardware, szName,
>                                       0, szPurpose, doAcceptanceUINow,

>                                       doOnline, keySpec, "", "", 1);
> 
>     /*
>      *
>      * The condition sz10 being empty occurs on any condition in which
the
>      * credential was not successfully generated. In particular, it
occurs
>      * when the operation was cancelled by the user, as well as
additional
>      * errors. A cancel is distinguished from other unsuccessful
>      * generations by an empty sz10 and an error value of zero.> 
>      *
>      */
> 
>     if (sz10 != "")
>     {
> 	document.GenReqForm.reqEntry.value = sz10;
>      document.GenReqForm.sessionId.value = sessionId;
>     } else {
> 	alert("Key Pair Generation failed");
> 	return false;
>     }
> }
> 
> //--->
> </SCRIPT>
> 
> <CENTER><H3>Generate key pair and client certificate
request</H3></CENTER>
> 
> <FORM METHOD=POST ACTION="http://www.pseudonym.org/cgi-bin/ms_key.pl"
NAME="GenReqForm"  onSubmit="GenReq()">
> <TABLE>
> <TR><TD>Common Name:</TD><TD>
> <INPUT TYPE=TEXT NAME="commonName" VALUE="Client Certificate" SIZE=64>
> 
> </TD></TR><TR><TD>Country:</TD><TD>
> <INPUT TYPE=TEXT NAME="countryName"  VALUE="US" SIZE=2>
> 
> </TD></TR><TR><TD>State or Province:</TD><TD>
> <INPUT TYPE=TEXT NAME="stateOrProvinceName" VALUE="MA">
> 
> </TD></TR><TR><TD>City:</TD><TD>
> <INPUT TYPE=TEXT NAME="localityName" VALUE="Cambridge">
> 
> </TD></TR><TR><TD>Organization:</TD><TD>
> <INPUT TYPE=TEXT NAME="organizationName" VALUE="The Open Group">
> 
> </TD></TR><TR><TD>Organizational Unit:</TD><TD>
> <INPUT TYPE=TEXT NAME="organizationalUnitName" VALUE="Research
Institute">
> 
> </TD></TR></TABLE>
> 
> <INPUT TYPE=HIDDEN	NAME="sessionId">
> <INPUT TYPE=HIDDEN	NAME="reqEntry">
> 
> <INPUT TYPE="SUBMIT" name="SUBMIT">
> </FORM>
> 
> </BODY></HTML>
> 
> 
> 
> 
> 






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EKEwqt099420 for <[e-mail]>; Mon, 14 Jul 2003 13:14:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EKEwCo099419 for ietf-pkix-bks; Mon, 14 Jul 2003 13:14:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EKEuqt099414 for <[e-mail]>; Mon, 14 Jul 2003 13:14:56 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6EKEjeR023230; Mon, 14 Jul 2003 13:14:45 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h6EKEis17248; Mon, 14 Jul 2003 16:14:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 14 Jul 2003 16:11:33 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Hesse <[e-mail]>
CC: "'PKIX List'" <[e-mail]>, "'Matt Cooper'" <[e-mail]>, "'Yuriy Dzambasow'" <[e-mail]>, "'Susan Joseph'" <[e-mail]>, "Richard E. Nicholas (Nicholas, Richard)"  <[e-mail]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
References: <009601c347d6$eed5ac60$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms20BF47E1AC85BB6C8B4F4F07"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Good to hear from you, Peter! Long time no see.
Responses inline below.

> I'm glad to see more discussions of certificate path building.
> In a non-hierarchical PKI where relying parties have different
> trust anchors, path building is essential. And it's not easy!
> 
> However, I don't think that we're ready to have an official
> 'best practices' document on path building yet.
> Very few people have implemented PKIX-compliant path building
> (only Sun and Cygnacom/DigitalNet, I think) and there are many
> areas that are still unclear.
> 
> <PMH> What is PKIX-compliant path building exactly? I am not
> aware of any documents that define this. This is a part of the
> reason why there is a need for this document.</PMH>

I don't have any objection to defining the term "PKIX-compliant
path building". But I don't think you need 59 pages to
do that. You could do that in one sentence. It's simply
the process of building certification paths that are
valid according to RFC 3280.

Most of the document describes and recommends specific
algorithms for path building. I don't think that we have
anything approaching agreement on these algorithms yet.

Fortunately, there is no need for consensus in this area.
I can use one path building algorithm and you can use an
entirely different one without affecting interoperability.
So I see no need to rush to publish an RFC on this topic.

Nobody has written RFCs on "how to write an OCSP server".
As long as you comply with the protocol spec, you'll be
able to interoperate just fine. The same should be true
with respect to path building.

And I even think it may be a fine thing to have an RFC
saying "here's how to solve the tricky problem of cert
path building", once we have agreement on that. But I
don't think we're close to that yet.

If you have a strong argument for why we *need* an RFC on
path building *soon* (even if it's still an active research
area), then maybe an Experimental RFC would suffice.

> The I-D just published presents one early perspective on these
> questions, not a consensus.
> 
> <PMH> I disagree that the document provides one early perspective,
> it describes many different scenarios and many different ways of
> dealing with them.</PMH>

I hope we can avoid the need to have many different ways
of solving this problem. Otherwise, it will not be possible
to have general-purpose mass-market software that will work
in all sorts of PKI topologies. I expect that we can come
up with some good general-purpose algorithms, but I think it
will take some time and some real data showing how different
algorithms perform in different environments.

> <PMH>This document was developed by five different authors from
> four different companies, all of which having varied amounts of
> experience building path development algorithms for many different
> environments, from pure mesh style (Entrust style?) to strict
> hierarchy to bridge ca.</PMH>

Did these folks actually work on four or five separate
implementations of path building and pull together their
ideas? Or did they all work on one or two implementations
(maybe successive versions)?

I hate to ask personal questions like that, but you raised
the issue and maybe I'm just unaware of these many separate
implementations of PKIX-compliant path validation. If so,
then I guess I'm just not very well plugged into the path
building community and this really does represent a community
consensus (although I'm still disturbed by the lack of hard
data). But if the authors actually worked on a single project,
then I don't think that represents rough consensus within IETF.

> <PMH>The document attempts to discuss many
> of the previously encountered problems and decisions based upon
> those problems, but does not make any hard and fast rules on
> which way future implementations should be developed.</PMH>

No, but it contains many recommendations. Just search for
"recommend" or "should" in the document. And I don't see
or know of data to support these recommendations.

> For now, I suggest that people who have implemented path building
> publish their insights, results, and ideas either as individual I-Ds
> without the intent to become an RFC or as research papers. Then we can
> discuss these results and ideas, test them in real-world scenarios, and
> arrive at a consensus on what Best Current Practices should be included
> in a BCP document on this topic. We might even want to start an IRTF
> research group or an informal discussion group to coordinate this
> research, sift through the results, and arrive at a solid and
> well-supported consensus. This effort will take some time, but I expect
> it will produce much better results.
> 
> <PMH> X.509 has existed in one form or another since 1988, and after 15
> years I think we owe the community some amount of tried and true
> guidance toward path building.  Does this document have all the answers
> on what the best way is to build paths? No--but the document states that
> very fact repeatedly--different environments will always lead to
> different optimizations for that environment. </PMH>

While X.509 has been around for many years, non-hierarchical
topologies are a fairly recent development. I haven't seen
any data comparing how different path building algorithms
perform in different non-hierarchical topologies. So I don't
think we know enough yet to say which algorithms are best.

The current I-D lists 20 different sorting techniques, but
it doesn't provide any hard data about which work better in
which topologies. And I suspect there may be other techniques
that might be better. I'm not suggesting that you publish an
RFC full of graphs showing which technique is best in which
environments. That probably belongs in a research paper. The
RFC can then point to the research paper.

> If it's felt that we really need a BCP on this topic in
> short order, then I think it should be restricted to things that we are
> fairly sure are good practices (like advising CAs to include name
> constraints and AIA in certificates to help path building and advising
> path builders to ensure that they handle simple hierarchical PKIs
> quickly but still handle complex PKIs properly).
> 
> <PMH> This draft focuses on path building, not best practices for how
> authorities should structure things to simplify building.  Perhaps that
> should be the topic of another I-D.  During drafts we discussed
> prioritizing different optimizations saying "you definitely should do
> A,B,C and probably do D,E,F," etc.  However we decided not to because we
> wanted to make the developers free to make their own decisions based
> upon the environments with which they were working. </PMH>

My point was that we should restrict any BCP to things
that we (the PKIX working group) can agree (via rough
consensus) are actually good practices. Maybe we should
have two BCPs: one on path building techniques and one
things CAs can do to make path building easier. At this
point, I suspect you could easily distill all of our
wisdom in each of those areas into one or two pages.
So let's set aside the question of whether they should
be separate documents.

I'd really like to know why we need to have an RFC on path
building now, since it seems to be an internal matter for
relying parties with no interoperability implications,
except with respect to things that CAs can do to make path
building easier.

Thanks,

Steve

P.S. I'm sorry I can't make it to Vienna this week, since
I think we could have a much more productive and relaxed
conversation over a few beers. Maybe we can schedule a
time to grab a few beers and talk on the phone. Failing that,
we can continue discussing this by email. But rest assured
that I have complete respect for your work. And I'm most
interested in what we can do to increase PKI deployment
and usage. If you can convince me that publishing this
document is a good way to help in that area, I will be glad
to help champion it. But I may offer some suggestions for
changes.
--------------ms20BF47E1AC85BB6C8B4F4F07
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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMwNzE0MjAxMTMzWjAjBgkqhkiG9w0BCQQxFgQUT6Rqo3+BMITfUXjbWI73PwZr
+gwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAPJL+T
k+ciVgeZWXDCFuBYC/bCb9qkJdtHs++1k+uPh3c9QdptEm/qJ63yuNT24VRlGfd/AYovN7/k
UrFltg5GSo3qQXNl/uI7Ul3p9MImy72uQVMg3wkyKLYKEhNL9L0qEVPusPth3uOJr0J/Sm9u
Oo+f+rZcpQu4AGrf5FVOUA==
--------------ms20BF47E1AC85BB6C8B4F4F07--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EFTcqt082060 for <[e-mail]>; Mon, 14 Jul 2003 08:29:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EFTcs5082059 for ietf-pkix-bks; Mon, 14 Jul 2003 08:29:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hotmail.com (bay7-dav27.bay7.hotmail.com [64.4.10.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EFTaqt082049 for <[e-mail]>; Mon, 14 Jul 2003 08:29:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jul 2003 08:18:23 -0700
Received: from 192.35.232.241 by bay7-dav27.bay7.hotmail.com with DAV; Mon, 14 Jul 2003 15:18:22 +0000
X-Originating-IP: [192.35.232.241]
X-Originating-Email: [[e-mail]]
From: "cindy" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: 
Date: Mon, 14 Jul 2003 10:14:51 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 14 Jul 2003 15:18:23.0105 (UTC) FILETIME=[2A514F10:01C34A1B]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

unsubscribe


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EFF3qt081167 for <[e-mail]>; Mon, 14 Jul 2003 08:15:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EFF3eq081166 for ietf-pkix-bks; Mon, 14 Jul 2003 08:15:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EFF1qt081151 for <[e-mail]>; Mon, 14 Jul 2003 08:15:02 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V6EF0BOW03840 for <[e-mail]>; Mon, 14 Jul 2003 11:11:24 -0400
Received: (qmail 12463 invoked by uid 64014); 14 Jul 2003 15:09:17 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.364946 secs); 14 Jul 2003 15:09:17 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 14 Jul 2003 15:09:16 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <3S6Z3HS4>; Mon, 14 Jul 2003 11:14:56 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Sharon Boeyen <[e-mail]>, "Hoyt Kesterson (E-mail)" <[e-mail]>
Cc: [e-mail]
Subject: RE: What is mean by recognizing critical extensions ?
Date: Mon, 14 Jul 2003 11:14:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34A1A.AD476BD0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C34A1A.AD476BD0
Content-Type: text/plain;
	charset="iso-8859-1"

I've been looking at defect reports recently anyway, so I'll draft one to
add warning for this as well and submit it to Hoyt.
 
Sharon

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, July 14, 2003 10:50 AM
To: Sharon Boeyen; Hoyt Kesterson (E-mail)
Cc: [e-mail]
Subject: RE: What is mean by recognizing critical extensions ?


That is always the problem with quoting a few paragraphs from a document.
But, in this case, the implementors could use an extra warning.  Mishandling
this extension would be very bad!

Russ

At 10:33 AM 7/14/2003 -0400, Sharon Boeyen wrote:


I agree Russ - the text I quoted said "assume that identified certificates
are revoked" and without understanding and processing the certificateIssuer
extension one would not know what the "identified" certificates were because
you need the combination of issuer name and serial number. The text for that
extension says it can't be ignored, but I wonder if some additional text
should also be put in both places to make that clearer. What do you & others
think? 
 
Sharon


-----Original Message-----


From: Russ Housley [ mailto:[e-mail]
<mailto:[e-mail]> ]


Sent: Sunday, July 13, 2003 10:31 AM


To: Sharon Boeyen


Cc: [e-mail]


Subject: RE: What is mean by recognizing critical extensions ?



Sharon:



The Certificate Issuer CRL Entry Extension seems to be an exception, which
is the reason that I thought it had to be a critical extension.  If
certificate using software were to use the CRL issuer distinguished name and
the serial number associated with such an entry, then the software would
consider the wrong certificate to be revoked.



Russ




At 10:58 AM 7/11/2003 -0400, Sharon Boeyen wrote:



While on this topic of critical extensions and rejections - I want to be
sure everyone realizes that  the handling is different for CRLs. If the
certificate of interest is listed as revoked on a CRL it is as a minimum
considered revoked regardless of the presence of unrecognized critical
extensions. Here is the relevant text from clause 7.3 of X.509:




  

NOTE 4 - When an implementation processing a certificate revocation list
does not recognize a critical extension in the crlEntryExtensions field, it
shall assume that, at a minimum, the identified certificate has been revoked
and is no longer valid and perform additional actions concerning that
revoked certificate as dictated by local policy. When an implementation does
not recognize a critical extension in the crlExtensions field, it shall
assume that identified certificates have been revoked and are no longer
valid. However in the latter case, since the list may not be complete,
certificates that have not been identified as being revoked cannot be
assumed to be valid. In this case local policy shall dictate the action to
be taken. In any case local policy may dictate actions in addition to and/or
stronger than those stated in this Specification.


------_=_NextPart_001_01C34A1A.AD476BD0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=323591515-14072003><FONT face=Arial color=#0000ff size=2>I've 
been looking at defect reports recently anyway, so I'll draft one to add warning 
for this as well and submit it to Hoyt.</FONT></SPAN></DIV>
<DIV><SPAN class=323591515-14072003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=323591515-14072003><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Russ Housley 
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, July 14, 2003 10:50 
  AM<BR><B>To:</B> Sharon Boeyen; Hoyt Kesterson (E-mail)<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: What is mean by recognizing critical 
  extensions ?<BR><BR></FONT></DIV>That is always the problem with quoting a few 
  paragraphs from a document.&nbsp; But, in this case, the implementors could 
  use an extra warning.&nbsp; Mishandling this extension would be very 
  bad!<BR><BR>Russ<BR><BR>At 10:33 AM 7/14/2003 -0400, Sharon Boeyen wrote:<BR>
  <BLOCKQUOTE class=cite cite="" type="cite"><FONT face=arial color=#0000ff 
    size=2>I agree Russ - the text I quoted said "assume that identified 
    certificates are revoked" and without understanding and processing the 
    certificateIssuer extension one would not know what the "identified" 
    certificates were because you need the combination of issuer name and serial 
    number. The text for that extension says it can't be ignored, but I wonder 
    if some additional text should also be put in both places to make that 
    clearer. What do you &amp; others&nbsp; think? </FONT><BR>&nbsp;<BR><FONT 
    face=arial color=#0000ff size=2>Sharon</FONT><BR>
    <DL>
      <DD><FONT face=tahoma size=2>-----Original Message-----<BR>
      <DD>From:</B> Russ Housley [<A href="mailto:[e-mail]" 
      eudora="autourl">mailto:[e-mail]</A>]<BR>
      <DD>Sent:</B> Sunday, July 13, 2003 10:31 AM<BR>
      <DD>To:</B> Sharon Boeyen<BR>
      <DD>Cc:</B> [e-mail]<BR>
      <DD>Subject:</B> RE: What is mean by recognizing critical extensions 
      ?<BR><BR></FONT>
      <DD>Sharon:<BR><BR>
      <DD>The Certificate Issuer CRL Entry Extension seems to be an exception, 
      which is the reason that I thought it had to be a critical 
      extension.&nbsp; If certificate using software were to use the CRL issuer 
      distinguished name and the serial number associated with such an entry, 
      then the software would consider the wrong certificate to be 
      revoked.<BR><BR>
      <DD>Russ<BR><BR><BR>
      <DD>At 10:58 AM 7/11/2003 -0400, Sharon Boeyen wrote:<BR>
      <BLOCKQUOTE class=cite cite="" type="cite">
        <DD><FONT face=arial color=#0000ff size=2>While on this topic of 
        critical extensions and rejections - I want to be sure everyone realizes 
        that&nbsp; the handling is different for CRLs. If the certificate of 
        interest is listed as revoked on a CRL it is as a minimum considered 
        revoked regardless of the presence of unrecognized critical extensions. 
        Here is the relevant text from clause 7.3 of X.509:</FONT><BR>
        <DD><BR><FONT face=arial color=#0000ff size=2><BR></FONT>&nbsp;
        <DD><FONT face="Times New Roman, Times" size=2>NOTE 4 - When an 
        implementation processing a certificate revocation list does not 
        recognize a critical extension in the </FONT><FONT face=arial 
        size=2>crlEntryExtensions</B></FONT><FONT face="Times New Roman, Times" 
        size=2> field, it shall assume that, at a minimum, the identified 
        certificate has been revoked and is no longer valid and perform 
        additional actions concerning that revoked certificate as dictated by 
        local policy. When an implementation does not recognize a critical 
        extension in the </FONT><FONT face=arial 
        size=2>crlExtensions</B></FONT><FONT face="Times New Roman, Times" 
        size=2> field, it shall assume that identified certificates have been 
        revoked and are no longer valid. However in the latter case, since the 
        list may not be complete, certificates that have not been identified as 
        being revoked cannot be assumed to be valid. In this case local policy 
        shall dictate the action to be taken. In any case local policy may 
        dictate actions in addition to and/or stronger than those stated in this 
        Specification.</FONT></DD></BLOCKQUOTE></DD></DL></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C34A1A.AD476BD0--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEpTqt079099 for <[e-mail]>; Mon, 14 Jul 2003 07:51:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EEpTOE079098 for ietf-pkix-bks; Mon, 14 Jul 2003 07:51:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6EEpSqt079093 for <[e-mail]>; Mon, 14 Jul 2003 07:51:28 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 29824 invoked by uid 0); 14 Jul 2003 14:50:17 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (81.160.208.93) by woodstock.binhost.com with SMTP; 14 Jul 2003 14:50:17 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 14 Jul 2003 10:50:24 -0400
To: Sharon Boeyen <[e-mail]>, "Hoyt Kesterson (E-mail)" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: What is mean by recognizing critical extensions ?
Cc: [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
That is always the problem with quoting a few paragraphs from a
document.&nbsp; But, in this case, the implementors could use an extra
warning.&nbsp; Mishandling this extension would be very bad!<br><br>
Russ<br><br>
At 10:33 AM 7/14/2003 -0400, Sharon Boeyen wrote:<br>
<blockquote type=3Dcite class=3Dcite cite><font face=3D"arial" size=3D2 colo=
r=3D"#0000FF">I
agree Russ - the text I quoted said &quot;assume that identified
certificates are revoked&quot; and without understanding and processing
the certificateIssuer extension one would not know what the
&quot;identified&quot; certificates were because you need the combination
of issuer name and serial number. The text for that extension says it
can't be ignored, but I wonder if some additional text should also be put
in both places to make that clearer. What do you &amp; others&nbsp;
think? </font><br>
&nbsp;<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF">Sharon</font><br>

<dl>
<dd><font face=3D"tahoma" size=3D2>-----Original Message-----<br>

<dd>From:</b> Russ Housley
[<a href=3D"mailto:[e-mail]"=
 eudora=3D"autourl">mailto:[e-mail]</a>]<br>

<dd>Sent:</b> Sunday, July 13, 2003 10:31 AM<br>

<dd>To:</b> Sharon Boeyen<br>

<dd>Cc:</b> [e-mail]<br>

<dd>Subject:</b> RE: What is mean by recognizing critical extensions
?<br><br>
</font>
<dd>Sharon:<br><br>

<dd>The Certificate Issuer CRL Entry Extension seems to be an exception,
which is the reason that I thought it had to be a critical
extension.&nbsp; If certificate using software were to use the CRL issuer
distinguished name and the serial number associated with such an entry,
then the software would consider the wrong certificate to be
revoked.<br><br>

<dd>Russ<br><br>
<br>

<dd>At 10:58 AM 7/11/2003 -0400, Sharon Boeyen wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>
<dd><font face=3D"arial" size=3D2 color=3D"#0000FF">While on this topic of
critical extensions and rejections - I want to be sure everyone realizes
that&nbsp; the handling is different for CRLs. If the certificate of
interest is listed as revoked on a CRL it is as a minimum considered
revoked regardless of the presence of unrecognized critical extensions.
Here is the relevant text from clause 7.3 of X.509:</font><br>

<dd>&nbsp;<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF"><br>
</font>
<dd><font face=3D"Times New Roman, Times" size=3D2>NOTE 4 - When an
implementation processing a certificate revocation list does not
recognize a critical extension in the
</font><font face=3D"arial" size=3D2>crlEntryExtensions</b></font><font=
 face=3D"Times New Roman, Times" size=3D2>
field, it shall assume that, at a minimum, the identified certificate has
been revoked and is no longer valid and perform additional actions
concerning that revoked certificate as dictated by local policy. When an
implementation does not recognize a critical extension in the
</font><font face=3D"arial" size=3D2>crlExtensions</b></font><font=
 face=3D"Times New Roman, Times" size=3D2>
field, it shall assume that identified certificates have been revoked and
are no longer valid. However in the latter case, since the list may not
be complete, certificates that have not been identified as being revoked
cannot be assumed to be valid. In this case local policy shall dictate
the action to be taken. In any case local policy may dictate actions in
addition to and/or stronger than those stated in this
Specification.</font></blockquote>
</dl></blockquote></body>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEbEqt078550 for <[e-mail]>; Mon, 14 Jul 2003 07:37:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EEbE88078549 for ietf-pkix-bks; Mon, 14 Jul 2003 07:37:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEbCqt078539 for <[e-mail]>; Mon, 14 Jul 2003 07:37:12 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V6EE0XYW31298 for <[e-mail]>; Mon, 14 Jul 2003 10:33:34 -0400
Received: (qmail 5403 invoked by uid 64014); 14 Jul 2003 14:31:27 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.322577 secs); 14 Jul 2003 14:31:27 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 14 Jul 2003 14:31:27 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <3S6Z3G38>; Mon, 14 Jul 2003 10:37:07 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Steve Hanna <[e-mail]>, PKIX List <[e-mail]>
Subject: RE: Question about Certificate Issuer CRL Entry Extension 
Date: Mon, 14 Jul 2003 10:37:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with this as well.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Sunday, July 13, 2003 10:42 AM
To: Steve Hanna; PKIX List
Subject: Re: Question about Certificate Issuer CRL Entry Extension 



Steve:

>The Certificate Issuer CRL entry extension (described in
>section 5.3.4 of RFC 3280) is a GeneralNames structure
>that identifies the certificate issuer for the CRL entry
>to which it is attached (and also to all subsequent entries
>in that CRL until another Certificate Issuer CRL entry
>extension is encountered.
>
>RFC 3280 doesn't say so, but I believe that within a PKIX
>(Internet) environment (where each certificate must have a
>non-empty X.500 issuer name and issuer alternative names are
>generally ignored) this extension MUST always contain at
>least one X.500 name so that the relying party can match
>this name against the issuer name in the certificate, as
>described in section 6.3.3 item (j) of RFC 3280. And I think
>that text describing this requirement should be added to the
>successor to RFC 3280. Does everyone agree with this?

I agree.  In fact, I see no value in including any other name forms.

>I also wonder whether anyone can think of a reason why this
>CRL entry extension should ever contain anything other than
>a single X.500 name in a PKIX (Internet) environment. If not,
>then the requirement can (and should) be made even more strict,
>specifying that this extension MUST contain only a single X.500
>name. Please let me know if you have a reason why this would not
>be a good idea.

I would like to see this changed in son of RFC 3208 (Grandson of RFC 2459).

Russ


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEXpqt078439 for <[e-mail]>; Mon, 14 Jul 2003 07:33:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EEXphC078438 for ietf-pkix-bks; Mon, 14 Jul 2003 07:33:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEXoqt078427 for <[e-mail]>; Mon, 14 Jul 2003 07:33:50 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com ([10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V6EE0UBW30854 for <[e-mail]>; Mon, 14 Jul 2003 10:30:11 -0400
Received: (qmail 4781 invoked by uid 64014); 14 Jul 2003 14:27:59 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.434517 secs); 14 Jul 2003 14:27:59 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 14 Jul 2003 14:27:59 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <3S6Z3GLW>; Mon, 14 Jul 2003 10:33:39 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "Hoyt Kesterson (E-mail)" <[e-mail]>
Cc: [e-mail]
Subject: RE: What is mean by recognizing critical extensions ?
Date: Mon, 14 Jul 2003 10:33:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34A14.EA3C5650"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C34A14.EA3C5650
Content-Type: text/plain;
	charset="iso-8859-1"

I agree Russ - the text I quoted said "assume that identified certificates
are revoked" and without understanding and processing the certificateIssuer
extension one would not know what the "identified" certificates were because
you need the combination of issuer name and serial number. The text for that
extension says it can't be ignored, but I wonder if some additional text
should also be put in both places to make that clearer. What do you & others
think? 
 
Sharon

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Sunday, July 13, 2003 10:31 AM
To: Sharon Boeyen
Cc: [e-mail]
Subject: RE: What is mean by recognizing critical extensions ?


Sharon:

The Certificate Issuer CRL Entry Extension seems to be an exception, which
is the reason that I thought it had to be a critical extension.  If
certificate using software were to use the CRL issuer distinguished name and
the serial number associated with such an entry, then the software would
consider the wrong certificate to be revoked.

Russ


At 10:58 AM 7/11/2003 -0400, Sharon Boeyen wrote:


While on this topic of critical extensions and rejections - I want to be
sure everyone realizes that  the handling is different for CRLs. If the
certificate of interest is listed as revoked on a CRL it is as a minimum
considered revoked regardless of the presence of unrecognized critical
extensions. Here is the relevant text from clause 7.3 of X.509:
 

NOTE 4 - When an implementation processing a certificate revocation list
does not recognize a critical extension in the crlEntryExtensions field, it
shall assume that, at a minimum, the identified certificate has been revoked
and is no longer valid and perform additional actions concerning that
revoked certificate as dictated by local policy. When an implementation does
not recognize a critical extension in the crlExtensions field, it shall
assume that identified certificates have been revoked and are no longer
valid. However in the latter case, since the list may not be complete,
certificates that have not been identified as being revoked cannot be
assumed to be valid. In this case local policy shall dictate the action to
be taken. In any case local policy may dictate actions in addition to and/or
stronger than those stated in this Specification.


------_=_NextPart_001_01C34A14.EA3C5650
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=963303214-14072003><FONT face=Arial color=#0000ff size=2>I 
agree Russ - the text I quoted said "assume that identified certificates are 
revoked" and without understanding and processing the certificateIssuer 
extension one would not know what the "identified" certificates were because you 
need the combination of issuer name and serial number. The text for that 
extension says it can't be ignored, but I wonder if some additional text should 
also be put in both places to make that clearer. What do you &amp; others 
&nbsp;think? </FONT></SPAN></DIV>
<DIV><SPAN class=963303214-14072003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=963303214-14072003><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Russ Housley 
  [mailto:[e-mail]]<BR><B>Sent:</B> Sunday, July 13, 2003 10:31 
  AM<BR><B>To:</B> Sharon Boeyen<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: What is mean by recognizing critical 
  extensions ?<BR><BR></FONT></DIV>Sharon:<BR><BR>The Certificate Issuer CRL 
  Entry Extension seems to be an exception, which is the reason that I thought 
  it had to be a critical extension.&nbsp; If certificate using software were to 
  use the CRL issuer distinguished name and the serial number associated with 
  such an entry, then the software would consider the wrong certificate to be 
  revoked.<BR><BR>Russ<BR><BR><BR>At 10:58 AM 7/11/2003 -0400, Sharon Boeyen 
  wrote:<BR>
  <BLOCKQUOTE class=cite cite="" type="cite"><FONT face=arial color=#0000ff 
    size=2>While on this topic of critical extensions and rejections - I want to 
    be sure everyone realizes that&nbsp; the handling is different for CRLs. If 
    the certificate of interest is listed as revoked on a CRL it is as a minimum 
    considered revoked regardless of the presence of unrecognized critical 
    extensions. Here is the relevant text from clause 7.3 of 
    X.509:</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff 
    size=2><BR></FONT><FONT face="Times New Roman, Times" size=2>NOTE 4 - When 
    an implementation processing a certificate revocation list does not 
    recognize a critical extension in the </FONT><FONT face=arial 
    size=2><B>crlEntryExtensions</B></FONT><FONT face="Times New Roman, Times" 
    size=2> field, it shall assume that, at a minimum, the identified 
    certificate has been revoked and is no longer valid and perform additional 
    actions concerning that revoked certificate as dictated by local policy. 
    When an implementation does not recognize a critical extension in the 
    </FONT><FONT face=arial size=2><B>crlExtensions</B></FONT><FONT 
    face="Times New Roman, Times" size=2> field, it shall assume that identified 
    certificates have been revoked and are no longer valid. However in the 
    latter case, since the list may not be complete, certificates that have not 
    been identified as being revoked cannot be assumed to be valid. In this case 
    local policy shall dictate the action to be taken. In any case local policy 
    may dictate actions in addition to and/or stronger than those stated in this 
    Specification.</FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C34A14.EA3C5650--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EDZhqt076892 for <[e-mail]>; Mon, 14 Jul 2003 06:35:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EDZhP7076891 for ietf-pkix-bks; Mon, 14 Jul 2003 06:35:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anaheim.nestegg.net (anaheim.nestegg.net [209.249.40.9]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EDZgqt076886 for <[e-mail]>; Mon, 14 Jul 2003 06:35:42 -0700 (PDT) (envelope-from [e-mail])
Received: from viruskiller.lanlogic.net (viruskiller.lanlogic.net [209.249.40.3]) by anaheim.nestegg.net (8.12.8/8.12.8) with SMTP id h6EDZN3h003929 for <[e-mail]>; Mon, 14 Jul 2003 06:35:40 -0700
Received: from EH6.hosted.lanlogic.net ([209.249.43.7]) by viruskiller.lanlogic.net (NAVGW 2.5.2.12) with SMTP id M2003071406375525795 for <[e-mail]>; Mon, 14 Jul 2003 06:37:55 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Creating client certificate in IE browser using xenroll.dll
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 14 Jul 2003 06:35:42 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Creating client certificate in IE browser using xenroll.dll
Thread-Index: AcNJnc/6Psi5G4HsTF6leTu9eQmSGAAbuIhw
From: "Sreenivasa Baddam" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6EDZgqt076887
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi All,
>   I am trying to generate a public key in the client using IE browser with the active-x control xenroll.dll using the following code got from the link http://www.pseudonym.org/ssl/ssl_cook.html (a good one).  The link used certenroll.dll but since new versions of IE are using xenroll.dll, I changed in the code from certenroll to xenroll.  But still I am not able to generate it.  The error I am getting is:'Object doesn't support this property or method'.  The reason I judged is that 'GenerateKeyPair' method signature is not the right one.  
>   I searched in the internet as well as the microsoft dev site but couldn't able to get the right solution.  Anyone out there faced this kind of problem or any suggestions as to how to get the method signatures in a dll file would be greatly appreciated.
> 
> Thanks,
> Sreeni
> 
> Here is the whole code, you can run it on your own machine too & see it. 
> ############################
> <HTML><HEAD><TITLE>Client Certificate Request</TITLE></HEAD><BODY>
> 
> <!-- Use the Microsoft ActiveX control to generate the certificate -->
> <OBJECT CLASSID="clsid:33BEC9E0-F78F-11cf-B782-00C04FD7BF43"  CODEBASE=xenroll.dll ID=certHelper>
> </OBJECT>
> 
> <!-- JavaScript or Visual Basic will work. -->
> <SCRIPT LANGUAGE="JavaScript">
> <!---
> 
> // this is from JavaScript: The Definitive Guide, since
> // Microsoft implementation of Math.random() is broken
> //
> function random() {
>     random.seed = (random.seed*random.a + random.c) % random.m;
>     return random.seed/random.m;
> }
> random.m = 714025; random.a = 4096; random.c = 150889;
> random.seed = (new Date()).getTime()%random.m;
> 
> function GenReq ()
> {
>     var sessionId		= "a_unique_session_id";
>     var reqHardware     	= 0;
>     var szName          	= "";
>     var szPurpose       	= "ClientAuth";
>     var doAcceptanceUINow   	= 0;
>     var doAcceptanceUILater	= 0;
>     var doOnline        	= 1;
>     var keySpec = 1;
> 
>     szName = "";
>     
>     if (document.GenReqForm.commonName.value == "")
>     {
> 	alert("No Common Name");
> 	return false;
>     } 
>     else
>      szName = "CN=" + document.GenReqForm.commonName.value;
> 
>     if (document.GenReqForm.countryName.value == "")
>     {
> 	alert("No Country");
> 	return false;
>     }
>     else
> 	szName = szName + "; C=" + document.GenReqForm.countryName.value;
> 
>     if (document.GenReqForm.stateOrProvinceName.value == "")
>     {
> 	alert("No State or Province");
> 	return false;
>     }
>     else
> 	szName = szName + "; S=" + document.GenReqForm.stateOrProvinceName.value;
> 
>     if (document.GenReqForm.localityName.value == "")
>     {
> 	alert("No City");
> 	return false;
>     }
>     else
> 	szName = szName + "; L=" + document.GenReqForm.localityName.value;
> 
>     if (document.GenReqForm.organizationName.value == "")
>     {
> 	alert("No Organization");
> 	return false;
>     }
>     else
> 	szName = szName + "; O=" + document.GenReqForm.organizationName.value;
> 
>     if (document.GenReqForm.organizationalUnitName.value == "")
>     {
> 	alert("No Organizational Unit");
> 	return false;
>     }
>     else
> 	szName = szName + "; OU=" + document.GenReqForm.organizationalUnitName.value;
> 
>     /* make session id unique */
>     sessionId = "xx" + Math.round(random() * 1000); 
>     alert('sz10='+sz10);
>     sz10 = certHelper.GenerateKeyPair(sessionId, reqHardware, szName,
>                                       0, szPurpose, doAcceptanceUINow, 
>                                       doOnline, keySpec, "", "", 1);
> 
>     /*
>      *
>      * The condition sz10 being empty occurs on any condition in which the
>      * credential was not successfully generated. In particular, it occurs
>      * when the operation was cancelled by the user, as well as additional
>      * errors. A cancel is distinguished from other unsuccessful
>      * generations by an empty sz10 and an error value of zero.> 
>      *
>      */
> 
>     if (sz10 != "")
>     {
> 	document.GenReqForm.reqEntry.value = sz10;
>      document.GenReqForm.sessionId.value = sessionId;
>     } else {
> 	alert("Key Pair Generation failed");
> 	return false;
>     }
> }
> 
> //--->
> </SCRIPT>
> 
> <CENTER><H3>Generate key pair and client certificate request</H3></CENTER>
> 
> <FORM METHOD=POST ACTION="http://www.pseudonym.org/cgi-bin/ms_key.pl" NAME="GenReqForm"  onSubmit="GenReq()">
> <TABLE>
> <TR><TD>Common Name:</TD><TD>
> <INPUT TYPE=TEXT NAME="commonName" VALUE="Client Certificate" SIZE=64>
> 
> </TD></TR><TR><TD>Country:</TD><TD>
> <INPUT TYPE=TEXT NAME="countryName"  VALUE="US" SIZE=2>
> 
> </TD></TR><TR><TD>State or Province:</TD><TD>
> <INPUT TYPE=TEXT NAME="stateOrProvinceName" VALUE="MA">
> 
> </TD></TR><TR><TD>City:</TD><TD>
> <INPUT TYPE=TEXT NAME="localityName" VALUE="Cambridge">
> 
> </TD></TR><TR><TD>Organization:</TD><TD>
> <INPUT TYPE=TEXT NAME="organizationName" VALUE="The Open Group">
> 
> </TD></TR><TR><TD>Organizational Unit:</TD><TD>
> <INPUT TYPE=TEXT NAME="organizationalUnitName" VALUE="Research Institute">
> 
> </TD></TR></TABLE>
> 
> <INPUT TYPE=HIDDEN	NAME="sessionId">
> <INPUT TYPE=HIDDEN	NAME="reqEntry">
> 
> <INPUT TYPE="SUBMIT" name="SUBMIT">
> </FORM>
> 
> </BODY></HTML>
> 
> 
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E87Tqt042474 for <[e-mail]>; Mon, 14 Jul 2003 01:07:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6E87Tit042473 for ietf-pkix-bks; Mon, 14 Jul 2003 01:07:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6E87Jqt042467 for <[e-mail]>; Mon, 14 Jul 2003 01:07:20 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 15196 invoked by uid 0); 14 Jul 2003 08:06:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (81.160.208.93) by woodstock.binhost.com with SMTP; 14 Jul 2003 08:06:08 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 14 Jul 2003 04:07:15 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: SEND WG trying to make use of RFC 3281
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I thought that people on this list would like to know that the SEND WG to 
trying to make use of Attribute Certificates.

Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEfnqt086111 for <[e-mail]>; Sun, 13 Jul 2003 07:41:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6DEfnc5086110 for ietf-pkix-bks; Sun, 13 Jul 2003 07:41:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6DEfmqt086105 for <[e-mail]>; Sun, 13 Jul 2003 07:41:48 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 14850 invoked by uid 0); 13 Jul 2003 14:40:38 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (81.160.208.93) by woodstock.binhost.com with SMTP; 13 Jul 2003 14:40:38 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sun, 13 Jul 2003 10:41:42 -0400
To: Steve Hanna <[e-mail]>, PKIX List <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Question about Certificate Issuer CRL Entry Extension 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

>The Certificate Issuer CRL entry extension (described in
>section 5.3.4 of RFC 3280) is a GeneralNames structure
>that identifies the certificate issuer for the CRL entry
>to which it is attached (and also to all subsequent entries
>in that CRL until another Certificate Issuer CRL entry
>extension is encountered.
>
>RFC 3280 doesn't say so, but I believe that within a PKIX
>(Internet) environment (where each certificate must have a
>non-empty X.500 issuer name and issuer alternative names are
>generally ignored) this extension MUST always contain at
>least one X.500 name so that the relying party can match
>this name against the issuer name in the certificate, as
>described in section 6.3.3 item (j) of RFC 3280. And I think
>that text describing this requirement should be added to the
>successor to RFC 3280. Does everyone agree with this?

I agree.  In fact, I see no value in including any other name forms.

>I also wonder whether anyone can think of a reason why this
>CRL entry extension should ever contain anything other than
>a single X.500 name in a PKIX (Internet) environment. If not,
>then the requirement can (and should) be made even more strict,
>specifying that this extension MUST contain only a single X.500
>name. Please let me know if you have a reason why this would not
>be a good idea.

I would like to see this changed in son of RFC 3208 (Grandson of RFC 2459).

Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEVPqt085629 for <[e-mail]>; Sun, 13 Jul 2003 07:31:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6DEVPYl085628 for ietf-pkix-bks; Sun, 13 Jul 2003 07:31:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6DEVNqt085621 for <[e-mail]>; Sun, 13 Jul 2003 07:31:24 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 14175 invoked by uid 0); 13 Jul 2003 14:30:13 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (81.160.208.93) by woodstock.binhost.com with SMTP; 13 Jul 2003 14:30:13 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sun, 13 Jul 2003 10:31:18 -0400
To: Sharon Boeyen <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: What is mean by recognizing critical extensions ?
Cc: [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
Sharon:<br><br>
The Certificate Issuer CRL Entry Extension seems to be an exception,
which is the reason that I thought it had to be a critical
extension.&nbsp; If certificate using software were to use the CRL issuer
distinguished name and the serial number associated with such an entry,
then the software would consider the wrong certificate to be
revoked.<br><br>
Russ<br><br>
<br>
At 10:58 AM 7/11/2003 -0400, Sharon Boeyen wrote:<br>
<blockquote type=3Dcite class=3Dcite cite><font face=3D"arial" size=3D2 colo=
r=3D"#0000FF">While
on this topic of critical extensions and rejections - I want to be sure
everyone realizes that&nbsp; the handling is different for CRLs. If the
certificate of interest is listed as revoked on a CRL it is as a minimum
considered revoked regardless of the presence of unrecognized critical
extensions. Here is the relevant text from clause 7.3 of
X.509:</font><br>
&nbsp;<br>
<font face=3D"arial" size=3D2 color=3D"#0000FF"><br>
</font><font face=3D"Times New Roman, Times" size=3D2>NOTE 4 =96 When an
implementation processing a certificate revocation list does not
recognize a critical extension in the
</font><font face=3D"arial" size=3D2><b>crlEntryExtensions</b></font><font=
 face=3D"Times New Roman, Times" size=3D2>
field, it shall assume that, at a minimum, the identified certificate has
been revoked and is no longer valid and perform additional actions
concerning that revoked certificate as dictated by local policy. When an
implementation does not recognize a critical extension in the
</font><font face=3D"arial" size=3D2><b>crlExtensions</b></font><font=
 face=3D"Times New Roman, Times" size=3D2>
field, it shall assume that identified certificates have been revoked and
are no longer valid. However in the latter case, since the list may not
be complete, certificates that have not been identified as being revoked
cannot be assumed to be valid. In this case local policy shall dictate
the action to be taken. In any case local policy may dictate actions in
addition to and/or stronger than those stated in this
Specification.</font></blockquote></body>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BK0lqt017784 for <[e-mail]>; Fri, 11 Jul 2003 13:00:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BK0lsV017783 for ietf-pkix-bks; Fri, 11 Jul 2003 13:00:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mpls-qmqp-04.inet.qwest.net (mpls-qmqp-04.inet.qwest.net [63.231.195.115]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6BK0jqt017774 for <[e-mail]>; Fri, 11 Jul 2003 13:00:46 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 34932 invoked by uid 0); 11 Jul 2003 20:00:47 -0000
Received: from mpls-pop-08.inet.qwest.net (63.231.195.8) by mpls-qmqp-04.inet.qwest.net with QMQP; 11 Jul 2003 20:00:47 -0000
Received: from vdsl-130-13-127-251.phnx.uswest.net (HELO ?192.168.2.7?) (130.13.127.251) by mpls-pop-08.inet.qwest.net with SMTP; 11 Jul 2003 20:00:47 -0000
Date: Fri, 11 Jul 2003 12:44:29 -0700
Message-Id: <a0521060dbb34c0a00420@[192.168.2.7]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
X-Sender: [e-mail]@mail.earthlink.net
In-Reply-To: <00d601c347c2$21763b90$0600a8c0@IdentrusVA1>
References:  <[e-mail]> <00d601c347c2$21763b90$0600a8c0@IdentrusVA1>
Subject: Re: What is mean by recognizing critical extensions ?
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: What is mean by recognizing critical extensions
?</title></head><body>
<div>wahaj</div>
<div><br></div>
<div>if by &quot;may not process it&quot; you mean &quot;you don't
have to implement support&quot; then you are correct. if you mean
&quot;arbitrarily decide not to process it&quot; even though the
implementation supports it, then you are not in alignment with the
standard. - please reference text that i quoted from the
standard.</div>
<div><br></div>
<div>item 1 is not harsh. if one assumes that a ca has decided that
the information in the extension shall be considered to determine if
the certificate is appropriate, then one should be able to handle the
extension - by handle i mean process according to the procedures
defined in the standard and, if appropriate, constrained by a
certificate use profile such as pkix.</div>
<div><br></div>
<div>i suggest you look at the additional paragraphs i mentioned in my
email (and may be present in sharon's email). it points out that
injudicious flagging of extensions as critical may limit users.
however, if the ca has decided that the processing of an extension is
necessary for correct operation, i&nbsp; can't see why the ca would
want to widen the number of potential users to include those who will
not use the certificate as the ca intended.</div>
<div><br></div>
<div>&nbsp;&nbsp;&nbsp; hoyt</div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1">After all
the discussion, what I have understood is:</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">1) If
extension is marked as Critical,&nbsp;application MUST process it. If
an application&nbsp;can't process it, REJECT the chain
altogether</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">2) If
extension is NOT marked as Critical, you may not process
it</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Process
mean: To read the extension, its values and check it according to some
defined rules.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Don't you
think option 1 is a bit harsh. Lets consider an example, if I have
certificate from my CA, having SubjectAltName marked as critical ( why
marked as critical ? cuz I use an application from the same CA, which
process SubjectAltName). If lets say I want to use the same
certificate in a scenario e.g. Buying books from XYZ.com who have
implemented SSL with Client Side Authentication. If XYZ.com don't
process SubjectAltName and according to RFC 3280 they reject my
certificate, I can't use their service !!. This ask for another cert
may be from another CA.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Best
Regards,</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Wahaj</font></blockquote>
<blockquote type="cite" cite>&nbsp;<br>
<blockquote>----- Original Message -----</blockquote>
<blockquote><b>From:</b> <a
href="mailto:[e-mail]">Sharon Boeyen</a></blockquote>
<blockquote><b>To:</b> <a
href="mailto:[e-mail]">'Hoyt L. Kesterson II'</a> ;
<a href="mailto:[e-mail]">[e-mail]</a></blockquote>
<blockquote><b>Sent:</b> Friday, July 11, 2003 5:43 PM</blockquote>
<blockquote><b>Subject:</b> RE: What is mean by recognizing critical
extensions ?</blockquote>
<blockquote><br></blockquote>
<blockquote><font face="Arial" size="-1" color="#0000FF">I have no
objection to eliminating &quot;recognizes&quot; from the text if it is
felt necessary, but I also want to point out the text that is only a
little bit further down in clause 8</font></blockquote>
<blockquote><font face="Arial" size="-1" color="#0000FF">of
X.509:</font></blockquote>
<blockquote>&nbsp;<br>
<font size="-1"></font></blockquote>
<blockquote><font face="Arial" size="-1">A validation engine has two
possible actions to take with respect to an extension:</font><br>
<font size="-1"></font></blockquote>
<blockquote><font face="Arial" size="-1">i)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
it can ignore the extension and accept the certificate (all other
things being equal);</font><br>
<font size="-1"></font></blockquote>
<blockquote><font face="Arial" size="-1">ii)&nbsp;&nbsp;&nbsp;&nbsp;
it can process the extension and accept or reject the certificate
depending on the content of the extension and the conditions under
which processing is occuring (e.g. the current values of the path
processing variables).</font><br>
<font size="-1"></font></blockquote>
<blockquote><font face="Arial" size="-1">Some extensions can only be
marked critical. In these cases a validation engine that understands
the extension, processes it and acceptance/rejection of the
certificate is dependent (at least in part) on the content of the
extension. A validation engine that does not understand the extension
rejects the certificate.</font><br>
</blockquote>
<blockquote><font face="Arial" size="-1">Some extensions can only be
marked non-critical. In these cases a validation engine that
understands the extension processes it and acceptance/rejection of the
certificate is dependent (at least in part) on the content of the
extension. A validation engine that does not understand the extension
accepts the certificate (unless factors other than this extension
cause it to be rejected).</font><br>
</blockquote>
<blockquote><font face="Arial" size="-1">Some extensions can be marked
critical or non-critical. In these cases a validation engine that
understands the extension processes it and acceptance/rejection of the
certificate is dependent (at least in part) on the content of the
extension, regardless of the criticality flag. A validation engine
that does not understand the extension accepts the certificate if the
extension is marked non-critical (unless factors other than this
extension cause it to be rejected) and rejects the certificate if the
extension is marked critical.</font></blockquote>
<blockquote><br></blockquote>
<blockquote>&nbsp;<br>
</blockquote>
<blockquote><font face="Arial" size="-1">While I suppose it could be
argued that &quot;understands&quot; is not much better than
&quot;recognizes&quot;, I think the final paragraph is clearer about
what a validation engine is required to do.</font><br>
</blockquote>
<blockquote>&nbsp;<br>
</blockquote>
<blockquote><font face="Arial" size="-1">I think that when we changed
all this text the last time, there were some voices that opposed
eliminating &quot;recognizes&quot; from the text because that is the
only term that was used in the 3rd edition. Perhaps there is no longer
support for that position. Note that these changes were a result of
defect report 244 against the 3rd edition text (resolution published
in TC 2 for 3rd edition and integrated into 4th edition
text).</font><br>
</blockquote>
<blockquote><font face="Arial" size="-1">Sharon</font><br>
</blockquote>
<blockquote>&nbsp;<br>
</blockquote>
<blockquote>&nbsp;<br>
<blockquote><font face="Tahoma" size="-1">-----Original
Message-----<br>
<b>From:</b> Hoyt L. Kesterson II
[mailto:[e-mail]]<br>
<b>Sent:</b> Thursday, July 10, 2003 8:47 PM<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> Re: What is mean by recognizing critical extensions
?</font><br>
<font face="Tahoma" size="-1"></font></blockquote>
<blockquote>valid point. i don't see much value to considering
&quot;recognizes&quot; as meaning i've heard about the extension but
have no ability to process it. this possibly should be addressed in
two places</blockquote>
<blockquote><br></blockquote>
<blockquote>&nbsp;1) ietf agreed terminology for stating the
capabilities of an implementation</blockquote>
<blockquote><br></blockquote>
<blockquote>&nbsp; 2) a clean-up of both ietf and iso/itu standard
terminology. somewhere i had some additional text that i considered
that stated that the implementation processed the extension according
to the rules specified in the standard (old osi conformance
lingo)</blockquote>
<blockquote><br></blockquote>
<blockquote>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hoyt</blockquote>
<blockquote><br></blockquote>
<blockquote><br>
<blockquote type="cite" cite>Hoyt,<br>
<br>
I think the &quot;dispute&quot; is over the term
&quot;recognizes&quot;.&nbsp; Hypothetically, an implementation may
not have the code to &quot;process&quot; a given extension, but might
claim to have the code to &quot;recognize&quot; the extension (and
thereby hope to satisfy some extended compliance criteria, if
erroneously).<br>
<br>
If one defines &quot;recognizes&quot; IFF &quot;possesses the code to
fully process&quot;, the dispute disappears.&nbsp; But then, the
conjunction &quot;recognizes AND is able to process&quot; (highlighted
below) is indeed redundant, and plausibly misleading.<br>
<br>
Cheers!&nbsp; ____tony____<br>
<br>
<br>
At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:<br>
<blockquote type="cite" cite>I believe that this sentence<br>
<br>
<font face="Times New Roman" size="+1">&nbsp;When a certificate-using
implementation<b> recognizes and is able to process</b> an extension,
then the certificate-using implementation shall process the extension
regardless of the value of the criticality flag.</font><br>
<br>
means that if an implementation has the code to process an extension,
it must do so. if it doesn't have the code, then it will not process
an extension because it cannot process it. if, in that case, that
extension is flagged critical, then it cannot use the certificate.<br>
<br>
if anyone believe that the text says that an extension doesn't have to
be processed even though there is an ability to process the extension,
i.e. a belief that not being critical means that one can choose to
process it or not, then i will recommend additional text for the
standard to further clarify the meaning for i can see no useful result
from such potential arbitrariness.<br>
<br>
&nbsp;&nbsp; hoyt<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote>Tony Bartoletti 925-422-3881 &lt;[e-mail]&gt;<br>
Information Operations and Assurance Center<br>
Lawrence Livermore National Laboratory<br>
Livermore, CA 94551-9900<br>
</blockquote>
</blockquote>
<blockquote><br></blockquote>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
Content-Type: application/x-pkcs7-signature;<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>name=&quot;smime.p7s&quot;<br>
Content-Disposition: attachment;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>filename=&quot;smime.p7s&quot;<br>
<br>
Attachment converted: Macintosh HD:smime 2.p7s (????/----)
(00057A66)</blockquote>
<div><br></div>
</body>
</html>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BItoqt013724 for <[e-mail]>; Fri, 11 Jul 2003 11:55:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BItoOL013723 for ietf-pkix-bks; Fri, 11 Jul 2003 11:55:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BItmqt013718 for <[e-mail]>; Fri, 11 Jul 2003 11:55:48 -0700 (PDT) (envelope-from [e-mail])
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h6BItXw2018590; Fri, 11 Jul 2003 14:55:33 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 11 Jul 2003 14:58:55 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Updated agenda for PKIX, 57th IETF
Cc: peter Sylvester <[e-mail]>, [e-mail], "Riccardo.Genghini" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I have appended an updated agenda.  I think I have everyone this time...

Thanks!

Tim

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

PKIX WG (pkix-wg)


THURSDAY, July 17, 2003 0900-1130
=================================


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


AGENDA:


1. WG Status and Direction


1.1 WG Focus and Direction [ADs]


       The working group has recieved direction from the IESG that will
       limit the types of new specifications accepted as PKIX work products.
       The ADs wil present IESG's expectations for the PKIX WG along with
       the rationale. (15 min.)


1.2 Document Status Review [Tim Polk (NIST)]


       The working group has a large number of Internet-Drafts.  Many
       documents are with the ADs or in various stages of WG Last Call.
       Several others are ready for Last Call. (10 min.)


2. PKIX WG Specifications


    2.1  Simple Certificate Validation Protocol   Trevor Freeman (MicroSoft)


          http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-12.txt


       The current draft of SCVP is in WG Last Call, and is believed to be in
       full compliance with RFC 3379. This presentation will identify the
       changes since the -11 draft.  (10 min.)


    2.2 RFC 3280 Progression     Tim Polk (NIST)


       NIST is currently performing the interoperability testing for RFC 3280.
       This presentation will update the WG on NIST's progress, projected
       completion date, and issues identified to date. Primary focus will 
be the
       RFC 3280 path validation test suite developed jointly by NIST, 
DigitalNet,
       and NSA. (10 min.)


    2.3 LDAP: Schemas, String Values, and more
                                - David Chadwick (Univ of Salford)
                                  Peter Gietz (DAASI)


       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
       for LDAP based PKI information distribution.  New drafts on PKC 
certificate
       schema, CRL schema and on Attribute Certificate schema have been 
published
       since the 56th IETF.  The authors will present the changes in these 
documents
       and discuss the timeline for document completion.  (15 min.)


    2.4 Qualified Certificates          Stefan Santesson (Retrospekt AB)

       http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-00.txt

       This presentation will propose a path for the evolution of the QC 
document.
       (10 min.)

    2.5 Certification Path Building     Matt Cooper (Orion Security)


       http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-00.txt 



       This document was written to provide "best practice" guidance and
       recommendations to developers building X.509 public-key certification
       paths within their applications.    (10 min.)


3. Related Specifications


    The following personal drafts address topics of interest to the PKIX WG,
    and are presented to highlight the availability of the drafts and encourage
    input from the WG.


    3.1 Specifying Russian Cryptographic Algorithms in PKIX
                                     Gregory S. Chudov (Crypto-Pro)


       This personal draft documents the use of Russian national cryptography
       standards (GOST) in the PKIX Certificate and CRL Profile. It was
       developed within "Russian Cryptographic Software Compatibility
       Agreement", and signed by major Russian cryptographic software vendors.
       (10 min.)



    3.2 Memorandum for multi-domain PKI Interoperability
                                      Masaki SHIMAOKA (SECOM)


       This personal draft documents known issues and considerations for
       multi-domain PKI, and provides guidelines for multi-domain PKI
       interoperability as a best current practice. The scope of this
       specification is the establishment of trust relationships and
       interoperability between mulitple PKI domains.


       This specification is a follow on to the JNSA Challenge PKI 2002
       and Multi-Domain PKI Test Suite.  (10 min.)


    3.3 Object Oriented PKI (OO-PKI)  Anders Rungren (Telia)


       This personal draft introduces an Object Oriented (OO) X.509
       extension. The extension is intended to eliminate the need for
       application-level, relying party PKI software, to a priori "know"
       certificate profiles, be manually "configured", or occasionally
       require "adjustments". The primary goal with the extension is to
       enable the creation of a wide range of standard information system
       applications, having built-in relying party PKI support. (10 min.)

4. Liason/Related Projects

    The following specifications will update the WG on related activities in
    the EU.

    4.1 European Open Standards for Electronic Signatures: the EESSI
                                  - Riccardo Genghini, EESSI Chair (SG&A)


       The European Elctronic Signature Standardization Initiative (EESSI) 
is an
       industry initiative in Support of the European Directive on Electronic
       Signatures.  This presentation describes the status of the ESESI's 
current and
       recent work.  This presentation is an update to the status report
       provided at the 56th IETF. (10 min.)


    4.2 OpenEvidence Project (Peter Sylvester)

       The EU IST project OpenEvidence is an Open source project
       concerning technologies for long term validity of documents.
       The presentation will address the goals and the current status
       of the implementation. (10 min.)



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BI5Cqt012114 for <[e-mail]>; Fri, 11 Jul 2003 11:05:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BI5CjY012113 for ietf-pkix-bks; Fri, 11 Jul 2003 11:05:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BI5Aqt012108 for <[e-mail]>; Fri, 11 Jul 2003 11:05:10 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id OAA227183; Fri, 11 Jul 2003 14:05:00 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, "'PKIX List'" <[e-mail]>
Cc: "'Matt Cooper'" <[e-mail]>, "'Yuriy Dzambasow'" <[e-mail]>, "'Susan Joseph'" <[e-mail]>, "Richard E. Nicholas \(Nicholas, Richard\)" <[e-mail]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Fri, 11 Jul 2003 14:04:44 -0400
Organization: Gemini Security Solutions, Inc.
MIME-Version: 1.0
Message-ID: <009601c347d6$eed5ac60$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0091_01C347B5.6109F100"
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0091_01C347B5.6109F100
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve,

I have some responses to your message inline, marked with <PMH>...

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Steve Hanna
Sent: Thursday, July 10, 2003 3:30 PM
To: PKIX List
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt


I'm glad to see more discussions of certificate path building. In a
non-hierarchical PKI where relying parties have different trust anchors,
path building is essential. And it's not easy!

However, I don't think that we're ready to have an official 'best
practices' document on path building yet. Very few people have
implemented PKIX-compliant path building (only Sun and
Cygnacom/DigitalNet, I think) and there are many areas that are still
unclear. 

<PMH> What is PKIX-compliant path building exactly?  I am not aware of
any documents that define this.  This is a part of the reason why there
is a need for this document.</PMH>

For instance, is it better to do a Depth First Search with ranking or to
rank all candidate certificates? Which ranking heuristics work best in
which environments? Is it possible for software to dynamically adapt to
the PKI topology without requiring configuration? And what are the
performance bottlenecks and best workarounds in real-world deployments?
The I-D just published presents one early perspective on these
questions, not a consensus.

<PMH> I disagree that the document provides one early perspective, it
describes many different scenarios and many different ways of dealing
with them.  This document was developed by five different authors from
four different companies, all of which having varied amounts of
experience building path development algorithms for many different
environments, from pure mesh style (Entrust style?) to strict hierarchy
to bridge ca.  The document attempts to discuss many of the previously
encountered problems and decisions based upon those problems, but does
not make any hard and fast rules on which way future implementations
should be developed. </PMH>

For now, I suggest that people who have implemented path building
publish their insights, results, and ideas either as individual I-Ds
without the intent to become an RFC or as research papers. Then we can
discuss these results and ideas, test them in real-world scenarios, and
arrive at a consensus on what Best Current Practices should be included
in a BCP document on this topic. We might even want to start an IRTF
research group or an informal discussion group to coordinate this
research, sift through the results, and arrive at a solid and
well-supported consensus. This effort will take some time, but I expect
it will produce much better results.

<PMH> X.509 has existed in one form or another since 1988, and after 15
years I think we owe the community some amount of tried and true
guidance toward path building.  Does this document have all the answers
on what the best way is to build paths? No--but the document states that
very fact repeatedly--different environments will always lead to
different optimizations for that environment. </PMH>

If it's felt that we really need a BCP on this topic in
short order, then I think it should be restricted to things that we are
fairly sure are good practices (like advising CAs to include name
constraints and AIA in certificates to help path building and advising
path builders to ensure that they handle simple hierarchical PKIs
quickly but still handle complex PKIs properly).

<PMH> This draft focuses on path building, not best practices for how
authorities should structure things to simplify building.  Perhaps that
should be the topic of another I-D.  During drafts we discussed
prioritizing different optimizations saying "you definitely should do
A,B,C and probably do D,E,F," etc.  However we decided not to because we
wanted to make the developers free to make their own decisions based
upon the environments with which they were working. </PMH>

Thanks,

Steve

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

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

------=_NextPart_000_0091_01C347B5.6109F100
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1zCCAokw
ggHyoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCVVMxKDAmBgNVBAoTH0dlbWlu
aSBTZWN1cml0eSBTb2x1dGlvbnMsIEluYy4xIjAgBgNVBAMTGUdTUyBDZXJ0aWZpY2F0ZSBBdXRo
b3JpdHkwHhcNMDIwNDI1MjE1NjI3WhcNMDUwMjEyMjE1NjI3WjBbMQswCQYDVQQGEwJVUzEoMCYG
A1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAGA1UEAxMZR1NTIENlcnRp
ZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtl3UwxhHyP05YqIF
kyfkWt8669gO/VKxC51PhJaV+hb9swwtaMVtJ9k8WjfQLt3fZpaNCNKB7V61KHxY1K1JCP67AwBy
W4TRuGRwEb+PXu5XdpNs3kxKtunlR4/WPsrrvuMx9/R/Fx9ld3TUqXCJ/JN7Zg68IappkcMy9S3w
koECAwEAAaNdMFswHQYDVR0OBBYEFJpr3UY3Hh5dngW5n9h72/GKMy7GMB8GA1UdIwQYMBaAFJpr
3UY3Hh5dngW5n9h72/GKMy7GMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBAHSd4BGG4le+QZBw/6bCq6mGpr4aJAE7UuXEW/I5YXqlQs1CkAzEHV8UnnXgDd0xONTQ
CdznbzCBNAE1EoxL14Kdp5I6omEeNulMd/tGAvxdw0qbbSaT9LolqtnPL2RbnI3j0JsQlncN1+l2
Dzx8Ka39NU4Gb/P6qo/PKa5+YRHSMIIDRjCCAq+gAwIBAgIBCzANBgkqhkiG9w0BAQUFADBbMQsw
CQYDVQQGEwJVUzEoMCYGA1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAG
A1UEAxMZR1NTIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMjA4MDUxODIxMTZaFw0wNDA4MDQx
ODIxMTZaMIGNMQswCQYDVQQGEwJVUzEnMCUGA1UEChMeR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9u
cyBJbmMuMRQwEgYDVQQLEwtEZXZlbG9wbWVudDEUMBIGA1UEAxMLUGV0ZXIgSGVzc2UxKTAnBgkq
hkiG9w0BCQEWGnBtaGVzc2VAZ2VtaW5pc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCvREu1eU1kCNW+lz+ZV9xvljBC7O6iESK10wzKPlrgnhL87+V5/joAbnwsXt25NsmP
8MIY6tuRxCbZzZn3bFTyPerhIOENWrA/HVdIP29TXfHL1YZn7bqBRHyjKcNdYS02GCw4gR4Fr5QS
SQzy62WbLcaoSG/wnhBqBesLxZMsOwIDAQABo4HmMIHjMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEB
BAQDAgSwMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUG8pDjEsHMZVS4/sJThNbtamIzEswHwYDVR0j
BBgwFoAUmmvdRjceHl2eBbmf2Hvb8YozLsYwJQYDVR0RBB4wHIEacG1oZXNzZUBnZW1pbmlzZWN1
cml0eS5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL3d3dy5nZW1pbmlzZWN1cml0eS5jb20v
cm9vdC5jcmwwFgYDVR0gBA8wDTALBgkrBgEEAe8oAQEwDQYJKoZIhvcNAQEFBQADgYEABOIVgnmX
5u4gHHRMsIG5H9WAbMqUeqjhGiFMxDjFXoS2Fkk6eVS6wLJZiS54mWrT1NLA9UOcqfvX8pdpp+pw
IpCwK9ywIco4mrqRdJ5Ja7vuxiO0e0J236mWdTQqPXWxZCOYumBtLkqoOcDFQYjuM4ZPLKSbFiMs
j1OYuQnyz6cxggK0MIICsAIBATBgMFsxCzAJBgNVBAYTAlVTMSgwJgYDVQQKEx9HZW1pbmkgU2Vj
dXJpdHkgU29sdXRpb25zLCBJbmMuMSIwIAYDVQQDExlHU1MgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
AgELMAkGBSsOAwIaBQCgggGqMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAzMDcxMTE4MDQ0M1owIwYJKoZIhvcNAQkEMRYEFLnpydFXsAi2LNe2Gagj4CQ4nCVwMGcG
CSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMG8GCSsGAQQBgjcQ
BDFiMGAwWzELMAkGA1UEBhMCVVMxKDAmBgNVBAoTH0dlbWluaSBTZWN1cml0eSBTb2x1dGlvbnMs
IEluYy4xIjAgBgNVBAMTGUdTUyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAQswcQYLKoZIhvcNAQkQ
AgsxYqBgMFsxCzAJBgNVBAYTAlVTMSgwJgYDVQQKEx9HZW1pbmkgU2VjdXJpdHkgU29sdXRpb25z
LCBJbmMuMSIwIAYDVQQDExlHU1MgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgELMA0GCSqGSIb3DQEB
AQUABIGAQSnlHBvjfj3UoGfDqHVWzY/T0olXLoua/T/G2AP01hIvvkQSBhIVTYErlODwpZvdaUtS
hYVW5GhJihY217qA+mix+rqOWkh7JxaadrqHOEBsY2LKoiA5z97BHghK0g4dgAMTTCx6QsrIjui9
R7V0UyhLVrhtMqH05GXwd+PzAucAAAAAAAA=

------=_NextPart_000_0091_01C347B5.6109F100--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BGGWqt003654 for <[e-mail]>; Fri, 11 Jul 2003 09:16:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BGGWKo003653 for ietf-pkix-bks; Fri, 11 Jul 2003 09:16:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BGGVqt003647 for <[e-mail]>; Fri, 11 Jul 2003 09:16:31 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h6BGGWJ6030429; Fri, 11 Jul 2003 12:16:32 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, "'PKIX List'" <[e-mail]>
Subject: RE: Question about Certificate Issuer CRL Entry Extension
Date: Fri, 11 Jul 2003 12:16:27 -0400
MIME-Version: 1.0
Message-ID: <009c01c347c7$cad77e10$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0098_01C347A6.409D4DE0"
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0098_01C347A6.409D4DE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I agree with Steve Hanna on both counts.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Steve Hanna
Sent: Friday, July 11, 2003 10:20 AM
To: PKIX List
Subject: Question about Certificate Issuer CRL Entry Extension


The Certificate Issuer CRL entry extension (described in section 5.3.4 of
RFC 3280) is a GeneralNames structure that identifies the certificate
issuer for the CRL entry to which it is attached (and also to all
subsequent entries in that CRL until another Certificate Issuer CRL entry
extension is encountered.

RFC 3280 doesn't say so, but I believe that within a PKIX
(Internet) environment (where each certificate must have a non-empty X.500
issuer name and issuer alternative names are generally ignored) this
extension MUST always contain at least one X.500 name so that the relying
party can match this name against the issuer name in the certificate, as
described in section 6.3.3 item (j) of RFC 3280. And I think that text
describing this requirement should be added to the successor to RFC 3280.
Does everyone agree with this?

I also wonder whether anyone can think of a reason why this
CRL entry extension should ever contain anything other than
a single X.500 name in a PKIX (Internet) environment. If not, then the
requirement can (and should) be made even more strict, specifying that
this extension MUST contain only a single X.500 name. Please let me know
if you have a reason why this would not be a good idea.

Thanks,

Steve

------=_NextPart_000_0098_01C347A6.409D4DE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQxzCCA5sw
ggKDoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9u
IFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMTDU9yaW9uIFJvb3QgQ0Ew
HhcNMDMwNjA1MTQyODQyWhcNMTMwNjAyMTQyODQyWjBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY
T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9v
dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd3fg/nIELr3rAuxpkcxiAn7ayU
/30RPxYBMgcvn0BJbBXBXIkTHgm3jh0TwHGQk76nqTSo1fUqpkkEcSSwEtfz1jF0QCKPHoQvNxza
5ffqH2gBSTgjpwqLA34RDxFDwcdNibIG/s6Zj2PpVDDWVBYxMbLrhKluMAfufhOMT6uyYxw+XPcU
ndqy4bRo08BONIoLdoUoOsvOwHla+zPYsBnTncMEL26lnKgCQgJpcFfrQRLrM84Rlc9EmvPbU+tO
5jRfdnvJpCm8LbIcTvAwQLiM+5qr4GPTg73S+9ZMAjlaZWG/VGe5b+KtQCgDu2TPB+wtiz2csG5q
YN14mFpKMdMCAwEAAaN2MHQwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0O
BBYEFL6aKnkebaR/htm59T9Oi6Bx/TKtMB8GA1UdIwQYMBaAFL6aKnkebaR/htm59T9Oi6Bx/TKt
MBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQUFAAOCAQEAQzMteZHn/soQjPFxQxN9o2vO
NWSeql+/NniUs5ePMtuejgzB8BTstAq8co6KsafqWgs69PSKzHAZlcvwEFtixNGXaTi+uDEuLM/y
oTQQjNX1RdtzfRFtbhhxyHmfpU9XgnC/7I/xyhkNCicxBHJFN6hcq3kJFFchH/rw/uon0sf6U3NW
eEtzGtXCwqqoLpwCfH2QbAgu/vtCCNGj+K9Ej2RlCUuaEwNPrXvJEARSpe24ZEPzOCoS5PEt9LmF
atDnC5ZRw5oruM5HnfRTE2EnHoA4SK34VNqae8ieR/s1sKxHCLEOyE/XyrydnFIdT8EXnwgdStiB
W0e6HUml9I94YzCCA9owggLCoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMx
ITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMT
DU9yaW9uIFJvb3QgQ0EwHhcNMDMwNjA1MTQyODU5WhcNMDQwNjA0MTQyODU5WjBWMQswCQYDVQQG
EwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUG
A1UEAxMOT3Jpb24gRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+uWjO
SEkmdREWiIxGgQ72SflNYhBL3S6CC5JrsM6qzdAzDYQcC1DyUmIxmesZRhObEZg21HBYUV9A7af7
dJSgZdM2o6rj0Wzubd8IaoW9IeSICET9fTTmfTKP11jC9nglZg8supaiuTQvlL3YX/Eo4x/j9lgp
OvCphC36l0nx6CsvYCjBB/SBci9RKmxPA01LhZlM4N2SKUfVDF9GKK8eGHUEcm5R+HxFAzX1Ljx7
0U2ZMnwJvJ66bFgqjmNEN1ZejrHzKgWlWDjkQPXwzy2S172HOyJtyw0wF78vg05ItnEd64y6zvqd
zzh/0qB/P/Xh4TZOH1/8OBb0DL/YSKJxAgMBAAGjgbMwgbAwEgYDVR0TAQH/BAgwBgEB/wIBADAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFPjb0mg9Eoh2AfUJIKpSuJ/nxQChMB8GA1UdIwQYMBaA
FL6aKnkebaR/htm59T9Oi6Bx/TKtMBEGCWCGSAGG+EIBAQQEAwIABzA3BgNVHR8EMDAuMCygKqAo
hiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9yb290LmNybDANBgkqhkiG9w0BAQUFAAOC
AQEAsYKdLb/O41HI1vzfKfhYBZ+vrwWUPNA4bS0mH4tShgYEJ5I15NXYK+sz4gbX6MP3slwp+wtp
BKySMMF2zb/d7Ozd57aYIewzA/QOiOvcyk3jL85+CtkgkO9fLB4ZPZkynHiI+46Axuime5cNgjoh
cf6BFHoUReoutNbvYfJhyeRz6aAA/kMswR35Jjep47pS2JmOVvKJl0ZeHz2XVrt0zUT3psWPOfT6
2Yqq1Y6IKlzh+3HgbbZENT54y8WVdDyoMogIc4AcFn/nZI1sajSbcCYxi57Zvr1WKU217smOt1ON
a8xHJBjTlnTKEfM8LqUxpk9Y+XDV5HHBhMaap39qWzCCBJEwggN5oAMCAQICAQgwDQYJKoZIhvcN
AQEFBQAwVjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEL
MAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBMB4XDTAzMDYwNTIxMDE1NloXDTA0
MDYwNDIxMDE1NlowfjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0
aW9uczELMAkGA1UECxMCSFExGTAXBgNVBAMTEFNhbnRvc2ggQ2hva2hhbmkxJDAiBgkqhkiG9w0B
CQEWFWNob2toYW5pQG9yaW9uc2VjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANBGnaG75lsgtVG7RLqLPA5hCu77JO9s91EhXODBeCO9XLWrE7k+593mNEbFyuTUqxjbn8MLqe5L
HWQKP2uhj8YhjAzmkLSYvFWgAsz1Mqs2WSRCrWqJXA+H0vFejhcgXTJnTAXm3dBq3DVZmm74FSJt
4eTnt7FM2capHbrngJIzLLRpwbVFhuN9R8zN7zk85Gx85DKDUxYDBGsoR65JcnnL3hzoIqoTsqQI
ikr+WnDNr4M63oeYGxxCX6jn0uevnsUwM/zK6Xc715r9JJq8DATrUzNazmIco8NsszNO5QcbLQTE
dAyHqqX9nWTdSBzp5xlsUqqpdhnY5/W6aZVTdhECAwEAAaOCAUAwggE8MBgGA1UdIAQRMA8wDQYL
YIZIAYb4AgMCAQAwHQYDVR0OBBYEFPQLCXgNtykUjPyCwMO9MWrT0A86MB8GA1UdIwQYMBaAFPjb
0mg9Eoh2AfUJIKpSuJ/nxQChMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMu
Y29tL29yaW9uX21haWwuY3JsMAkGA1UdEwQCMAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAC
hiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBDAw
EwYDVR0lBAwwCgYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgAHMCAGA1UdEQQZMBeBFWNob2to
YW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAFy0Oc6J5qW4gzM3leQP7LBmNOsfb
cS2UMmn8YTrid5co3/z1onBXP3mEt5z/AVppjgvGVeher6xrxuyOHGjs/X0W6R61yYf2UXrr7BNn
5NXLBr18ncZ8PZech6syvHs+KLveVMjX8bymUU2GvbCfJc54aZQxhAV3bWMJE0myryLRxtiRjyAb
7i2RXG0sewLIPU5svoNIr8Uu5ect5n4VDMZ/0rrO6MZl3NJ9MXfFwN06zcNw5XSvic7sK+YHUGm5
Ntpj/blmOkcBIMqn/wwU5D9CeR0qqEAXLdjkLbJFUUPmK7zr1EWM7A7BrTliYTr5UW2c/kC3kWct
hwkIYlqApjCCBLEwggOZoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxITAf
BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9y
aW9uIEVtYWlsIENBMB4XDTAzMDYwNTIxMDEzOFoXDTA0MDYwNDIxMDEzOFowfjELMAkGA1UEBhMC
VVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExGTAXBgNV
BAMTEFNhbnRvc2ggQ2hva2hhbmkxJDAiBgkqhkiG9w0BCQEWFWNob2toYW5pQG9yaW9uc2VjLmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMLUZwZhoWYVw7zKNe5KLxQfXo0dKMKk
ph9MA+fNX9YPW/LEbsjqdofCRJ1F8VZalpBrlz61ITyJ7/y+W1My0n0oOJhwvdhqRxE2QUv+bOP8
0i7BGqIm4/wd35ZyABDG2mt5Jj2anwXUIK1KENCo1pYxhroil3qLhtd9xPiOOjUZ2wAmNEgFwxDc
QE1xsNJtJ3Ro1O3VfceF53AxomEIZM300usixqnUSKbk8D8oVwUNBnMXdj+7K/0G/YJ9EPJFF5or
wI1j9LE3tdWBVY9a7WY1+ygHDMXaeYAnM2TkAuVGtWqTHTGmdNuyxsapFY7UFLtRjItA2oFb3bs/
ho1tKrUCAwEAAaOCAWAwggFcMBgGA1UdIAQRMA8wDQYLYIZIAYb4AgMCAQAwHQYDVR0OBBYEFBKj
QVpvrGnBnkHERGgS5SKCv83bMB8GA1UdIwQYMBaAFPjb0mg9Eoh2AfUJIKpSuJ/nxQChMDcGA1Ud
HwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX21haWwuY3JsMAkGA1Ud
EwQCMAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAChiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNv
bS9vcmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBsAwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsG
AQUFBwMEBggrBgEFBQcDBwYKKwYBBAGCNxQCAjARBglghkgBhvhCAQEEBAMCAAcwIAYDVR0RBBkw
F4EVY2hva2hhbmlAb3Jpb25zZWMuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQC4JnPdbSyJu53/lKZy
AG3pkMb6jh0dZ5PUn/NR1MjqwAmb/Dy4fpg+9/SiAVAsruUDaLY4AoWwefdIvhF2XVzlHa+7eTmx
4ppKQlpyEmTfJ5BMddYAeTVhiaRO6qVfTEjCgmqGs+fHNZxROLGFA4Dz+SgtNj1vc+uV1ZVCxSGr
mcr/QZYHHERadCgATyejmcCLlxfAMQMMsmNQUKQVrsrPzcyCI/CsXEIKj4+iRmpRi+3lbflTocG0
D96cSP3wW6G9jKW45kWn8RtKiSrpzlYEyBixJkhWhJ92WV11MGIOfaJtbU5aDNppp3OueDHu8g+R
EVxkMO2TkqBj+9Kr6UetMYIDJjCCAyICAQEwWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jp
b24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwg
Q0ECAQcwCQYFKw4DAhoFAKCCAaAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMwNzExMTYxNjI3WjAjBgkqhkiG9w0BCQQxFgQUpQ9G3J6F++t+32BMfaTl4T5xaXQw
ZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC
AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwagYJKwYBBAGC
NxAEMV0wWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25z
MQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0ECAQgwbAYLKoZIhvcNAQkQAgsx
XaBbMFYxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxCzAJ
BgNVBAsTAkhRMRcwFQYDVQQDEw5PcmlvbiBFbWFpbCBDQQIBCDANBgkqhkiG9w0BAQEFAASCAQAF
wzrZe1Ic+b/iTHLywLnz4+X9TRj5GT0yIxiaXhAe4PnOrEfrGxqP7MLR0fpRTuWG1S9C/ub2g5Oy
kqKOeyVx4swGxFN4q1+cspoaSSKRT8usIBZJfpI27wCNiFhs8pABaOUYF7dtUGqo8jSt1KZeHoKm
4j0+NiO/dB3AwUoJPbPQlEgZb4v+L9JDn4xAXQcxN3k03y3h3JYqUQ1kI3rRPF8MM2NJNGogkSdQ
joXComkwqUlhaVTlFYxeu4robf0fZIlS7NuCn9HGbMlniT0nvdh+dQfcHzuN4d0gl7CnxzfQre+F
nYfp5dqcjUQYOQUSLSv3M6xTn1t5RxWbC5gdAAAAAAAA

------=_NextPart_000_0098_01C347A6.409D4DE0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BG8Dqt003386 for <[e-mail]>; Fri, 11 Jul 2003 09:08:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BG8DAs003384 for ietf-pkix-bks; Fri, 11 Jul 2003 09:08:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mpls-qmqp-02.inet.qwest.net (mpls-qmqp-02.inet.qwest.net [63.231.195.113]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6BG8Bqt003371 for <[e-mail]>; Fri, 11 Jul 2003 09:08:12 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 14300 invoked by uid 0); 11 Jul 2003 15:35:12 -0000
Received: from mpls-pop-06.inet.qwest.net (63.231.195.6) by mpls-qmqp-02.inet.qwest.net with QMQP; 11 Jul 2003 15:35:12 -0000
Received: from vdsl-130-13-127-251.phnx.uswest.net (HELO ?192.168.2.7?) (130.13.127.251) by mpls-pop-06.inet.qwest.net with SMTP; 11 Jul 2003 16:08:12 -0000
Date: Fri, 11 Jul 2003 09:03:20 -0700
Message-Id: <a0521060cbb348d6e0446@[192.168.2.7]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
X-Sender: [e-mail]@mail.earthlink.net
In-Reply-To: <01a501c347bc$2e057840$020aff0a@tsg1>
References: <[e-mail]> <[e-mail] v.microsoft.com> <[e-mail]> <[e-mail]> <a05210608bb339010a1e7@[192.168.2.7]> <01a501c347bc$2e057840$020aff0a@tsg1>
Subject: Re: What is mean by recognizing critical extensions ?
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: What is mean by recognizing critical extensions
?</title></head><body>
<div>todd, &quot;shall&quot; is considered, by the language mavens in
the standards organization, to be stronger than &quot;must&quot; (see
the 2nd meaning in webster).</div>
<div><br></div>
<div>iso and itu have agreed on a set of language rules. &quot;shall&quot;
is used when the making a statement about an action that is
compulsory. &quot;may&quot; is used to describe an action that is
optional.</div>
<div><br></div>
<div>note that laws and regulations use &quot;shall&quot;</div>
<div><br></div>
<div>i must use &quot;shall&quot;</div>
<div><br></div>
<div>&nbsp;&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1">Hoyt, this
is an instance where the would MUST is appropriate because what you
are referring to is a the compliance model for use and nothing
less.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">On a tangent
of this, one of the amazing things is that the technical world seems
to miss that most implementation's of this high-tech will be SW in
nature, and so they will require some form of internal auditing to
assure they are in compliance with the standards. In fact it probably
would be wise for the IETF to require some 'test component'
specification in the standards track to qualify a technology for
release as a standard and possibly publish these as a BCP
recommendation for validating the PKI environment.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Not that it,
the IETF,&nbsp;should build the toolkit like what OpenGroup does with
their Unix qualification suite, but at least the top level of the
functional architecture...</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Hmmmm. This
is also is probably germane to the x509 standards track
too.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">T</font><br>
<blockquote>----- Original Message -----</blockquote>
<blockquote><b>From:</b> <a
href="mailto:[e-mail]">Hoyt L. Kesterson
II</a></blockquote>
<blockquote><b>To:</b> <a
href="mailto:[e-mail]">[e-mail]</a></blockquote>
<blockquote><b>Sent:</b> Thursday, July 10, 2003 2:59 PM</blockquote>
<blockquote><b>Subject:</b> Re: What is mean by recognizing critical
extensions ?</blockquote>
<blockquote><br></blockquote>
<blockquote>I believe that this sentence</blockquote>
<blockquote><br></blockquote>
<blockquote><font face="Times New Roman" size="+1">&nbsp;When a
certificate-using implementation<b> recognizes and is able to
process</b> an extension, then the certificate-using implementation
shall process the extension regardless of the value of the criticality
flag.</font></blockquote>
<blockquote><br></blockquote>
<blockquote>means that if an implementation has the code to process an
extension, it must do so. if it doesn't have the code, then it will
not process an extension because it cannot process it. if, in that
case, that extension is flagged critical, then it cannot use the
certificate.</blockquote>
<blockquote><br></blockquote>
<blockquote>if anyone believe that the text says that an extension
doesn't have to be processed even though there is an ability to
process the extension, i.e. a belief that not being critical means
that one can choose to process it or not, then i will recommend
additional text for the standard to further clarify the meaning for i
can see no useful result from such potential
arbitrariness.</blockquote>
<blockquote><br></blockquote>
<blockquote>&nbsp;&nbsp; hoyt</blockquote>
<blockquote><br></blockquote>
<blockquote><br>
<blockquote type="cite" cite>At 10:14 PM 7/9/2003 -0700, Hoyt L.
Kesterson II wrote:<br>
<blockquote type="cite" cite>At 10:31 -0400 7/8/03, David A. Cooper
wrote:<br>
<br>
as we were finishing up the 4th edition sharon boeyen reported to our
group that some implementors were using an interesting interpretation
of &quot;recognizing an extension&quot;. apparently their recognition
essentially meant that they recognized the oid and recognized that the
extension was defined but did not process it, i.e wrote no code to
process the extension as defined in the standard. to counter this
specious argument we wrote some additional text for clause 7<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote>
<blockquote><br>
[snip]<br>
<blockquote type="cite" cite>the 4th edition has this replacement
paragraph (as well as additional paragraphs)<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote>
<blockquote><br>
[snip]<br>
<blockquote type="cite" cite><font face="Times New Roman"
size="+1">therein. When an implementation processing a certificate
does not recognize an extension, if the criticality flag
is</font><font face="Arial" size="+1"><b> FALSE</b></font><font
face="Times New Roman" size="+1">, it may ignore that extension. If
the criticality flag is</font><font face="Arial" size="+1"><b>
TRUE</b></font><font face="Times New Roman" size="+1">, unrecognized
extensions shall cause the structure to be considered invalid, i.e. in
a certificate, an unrecognized critical extension would cause
validation of a signature using that certificate to fail. When a
certificate-using implementation<b> recognizes and is able to
process</b> an extension, then the certificate-using implementation
shall process the extension regardless of the value of the criticality
flag. Note that any extension that is flagged non-critical will cause
inconsistent behaviour between certificate-using systems that will
process the extension and certificate-using systems that do not
recognize the extension and will ignore it.</font>&quot;</blockquote>
<blockquote><br>
note the penultimate sentence.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote>
<blockquote>Indeed.&nbsp; This clearly implies that non-critical
extensions &quot;may or may not&quot; be processed.<br>
<br>
Moreover, additional confusion is engendered by the phrase<br>
<br>
&nbsp;&nbsp;&nbsp; &quot;recognizes and is able to process&quot;.<br>
<br>
Perhaps this is a redundant conjunction, but logically it implies that
&quot;recognizes&quot; and &quot;is able to process&quot; are distinct
conditions (else, why the conjunction?)<br>
<br>
Thus, for non-critical extensions, one has THREE cases:<br>
<br>
1.&nbsp; Does not recognize (may or may not validate certificate, up
to implementation)<br>
<br>
2.&nbsp; &quot;Recognizes&quot;, but cannot process (same result as in
1.)<br>
<br>
3.&nbsp; Recognizes and CAN process (MUST process to determine
validity.)<br>
<br>
If the intent is to use the term &quot;recognizes&quot; to mean
&quot;can process&quot;, then the condition &quot;recognizes and can
process&quot; adds to the confusion.<br>
<br>
Cheers!&nbsp; ____tony____<br>
<br>
Tony Bartoletti 925-422-3881 &lt;[e-mail]&gt;<br>
Information Operations and Assurance Center<br>
Lawrence Livermore National Laboratory<br>
Livermore, CA 94551-9900</blockquote>
</blockquote>
</blockquote>
<div><br></div>
</body>
</html>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BFhmqt099753 for <[e-mail]>; Fri, 11 Jul 2003 08:43:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BFhmUY099752 for ietf-pkix-bks; Fri, 11 Jul 2003 08:43:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BFhkqt099742 for <[e-mail]>; Fri, 11 Jul 2003 08:43:46 -0700 (PDT) (envelope-from [e-mail])
Received: from malpani.biz (localhost [127.0.0.1]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h6BFhc9A010122; Fri, 11 Jul 2003 08:43:38 -0700
Received: from 66.224.113.194 (SquirrelMail authenticated user ambarish) by ns.malpani.biz with HTTP; Fri, 11 Jul 2003 08:43:38 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 11 Jul 2003 08:43:38 -0700 (PDT)
Subject: Re: What is mean by recognizing critical extensions ?
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Priority: 3
Importance: Normal
X-MSMail-Priority: Normal
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
X-Mailer: SquirrelMail (version 1.2.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Richard,
    Not quite. I think what most folks are saying is that you
only say you recognize an extension if you CAN process it. So, in
pseudo-C/STL code, it works something like this:

int
recognize(extension)
{
    return((know(extension.oid) && canProcess(extension.oid));
}


dealwithcert(cert)
{
    for(extension=cert.extensions.first(); extension; extension++)
    {
        if(recognize(extension))
            process(extention);
        else if(critical(extension))
            reject(cert);
    }
    return(0);
}


Wow, this pseudo-C is fun!

:-)
Ambarish
>
> Contrary to others, I don't believe the problem lies in the word
> "recognises" itself.  It's more the whole sentence that seems to be
> confusing (and I agree with those who think so).
>
> To me, the quoted language from X.509 certainly seems to say "if you
> recognise this extension, you must process it or invalidate the path,
> period", while the quote text from the other document seems to say "if
> you recognise this extension and can process it, you must process it".
>
> In pseudo-C terms, I get it like this:
>
> X.509:	if (recognise(extension)) {
> 		if (can_process(extension))
> 			process(extension);
> 		else
> 			invalidate(path);
> 	} else if (critical(extension)) {
> 		invalidate(path);
> 	}
>
> other:	if (recognise(extension) && can_process(extension)) {
> 		process(extension);
> 	} else if (critical(extension)) {
> 		invalidate(path);
> 	}
>
> Makes sense?
>
> --
> Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
> Levitte Programming | http://www.lp.se/           | S-168 36 Bromma T:
> [phone] |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"
>
>
> In message
> <[e-mail]> on Fri,
> 11 Jul 2003 08:43:16 -0400, Sharon Boeyen <[e-mail]>
> said:
>
> sharon.boeyen> I have no objection to eliminating "recognizes" from the
> text if it is felt sharon.boeyen> necessary, but I also want to point
> out the text that is only a little bit sharon.boeyen> further down in
> clause 8
> sharon.boeyen> of X.509:
> sharon.boeyen>
> sharon.boeyen> A validation engine has two possible actions to take with
> respect to an sharon.boeyen> extension:<?xml:namespace prefix = o ns =
> sharon.boeyen> "urn:schemas-microsoft-com:office:office" />
> sharon.boeyen>
> sharon.boeyen> i)      it can ignore the extension and accept the
> certificate (all other sharon.boeyen> things being equal);
> sharon.boeyen>
> sharon.boeyen> ii)     it can process the extension and accept or reject
> the certificate sharon.boeyen> depending on the content of the extension
> and the conditions under which sharon.boeyen> processing is occuring
> (e.g. the current values of the path processing sharon.boeyen>
> variables).
> sharon.boeyen>
> sharon.boeyen> Some extensions can only be marked critical. In these
> cases a validation sharon.boeyen> engine that understands the extension,
> processes it and acceptance/rejection sharon.boeyen> of the certificate
> is dependent (at least in part) on the content of the sharon.boeyen>
> extension. A validation engine that does not understand the extension
> sharon.boeyen> rejects the certificate.
> sharon.boeyen>
> sharon.boeyen> Some extensions can only be marked non-critical. In these
> cases a validation sharon.boeyen> engine that understands the extension
> processes it and acceptance/rejection sharon.boeyen> of the certificate
> is dependent (at least in part) on the content of the sharon.boeyen>
> extension. A validation engine that does not understand the extension
> sharon.boeyen> accepts the certificate (unless factors other than this
> extension cause it sharon.boeyen> to be rejected).
> sharon.boeyen>
> sharon.boeyen> Some extensions can be marked critical or non-critical.
> In these cases a sharon.boeyen> validation engine that understands the
> extension processes it and sharon.boeyen> acceptance/rejection of the
> certificate is dependent (at least in part) on sharon.boeyen> the
> content of the extension, regardless of the criticality flag. A
> sharon.boeyen> validation engine that does not understand the extension
> accepts the sharon.boeyen> certificate if the extension is marked
> non-critical (unless factors other sharon.boeyen> than this extension
> cause it to be rejected) and rejects the certificate if sharon.boeyen>
> the extension is marked critical.
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> While I suppose it could be argued that "understands" is
> not much better sharon.boeyen> than "recognizes", I think the final
> paragraph is clearer about what a sharon.boeyen> validation engine is
> required to do.
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> I think that when we changed all this text the last time,
> there were some sharon.boeyen> voices that opposed eliminating
> "recognizes" from the text because that is sharon.boeyen> the only term
> that was used in the 3rd edition. Perhaps there is no longer
> sharon.boeyen> support for that position. Note that these changes were a
> result of defect sharon.boeyen> report 244 against the 3rd edition text
> (resolution published in TC 2 for sharon.boeyen> 3rd edition and
> integrated into 4th edition text).
> sharon.boeyen>
> sharon.boeyen> Sharon
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> -----Original Message-----
> sharon.boeyen> From: Hoyt L. Kesterson II
> [mailto:[e-mail]] sharon.boeyen> Sent: Thursday, July
> 10, 2003 8:47 PM
> sharon.boeyen> To: [e-mail]
> sharon.boeyen> Subject: Re: What is mean by recognizing critical
> extensions ? sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> valid point. i don't see much value to considering
> "recognizes" as meaning sharon.boeyen> i've heard about the extension
> but have no ability to process it. this sharon.boeyen> possibly should
> be addressed in two places
> sharon.boeyen>
> sharon.boeyen>  1) ietf agreed terminology for stating the capabilities
> of an sharon.boeyen> implementation
> sharon.boeyen>
> sharon.boeyen>   2) a clean-up of both ietf and iso/itu standard
> terminology. somewhere i sharon.boeyen> had some additional text that i
> considered that stated that the sharon.boeyen> implementation processed
> the extension according to the rules specified in sharon.boeyen> the
> standard (old osi conformance lingo)
> sharon.boeyen>
> sharon.boeyen>       hoyt
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> Hoyt,
> sharon.boeyen>
> sharon.boeyen> I think the "dispute" is over the term "recognizes".
> Hypothetically, an sharon.boeyen> implementation may not have the code
> to "process" a given extension, but sharon.boeyen> might claim to have
> the code to "recognize" the extension (and thereby hope sharon.boeyen>
> to satisfy some extended compliance criteria, if erroneously).
> sharon.boeyen>
> sharon.boeyen> If one defines "recognizes" IFF "possesses the code to
> fully process", the sharon.boeyen> dispute disappears.  But then, the
> conjunction "recognizes AND is able to sharon.boeyen> process"
> (highlighted below) is indeed redundant, and plausibly misleading.
> sharon.boeyen>
> sharon.boeyen> Cheers!  ____tony____
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> I believe that this sentence
> sharon.boeyen>
> sharon.boeyen>  When a certificate-using implementation recognizes and
> is able to process sharon.boeyen> an extension, then the
> certificate-using implementation shall process the sharon.boeyen>
> extension regardless of the value of the criticality flag.
> sharon.boeyen>
> sharon.boeyen> means that if an implementation has the code to process
> an extension, it sharon.boeyen> must do so. if it doesn't have the code,
> then it will not process an sharon.boeyen> extension because it cannot
> process it. if, in that case, that extension is sharon.boeyen> flagged
> critical, then it cannot use the certificate. sharon.boeyen>
> sharon.boeyen> if anyone believe that the text says that an extension
> doesn't have to be sharon.boeyen> processed even though there is an
> ability to process the extension, i.e. a sharon.boeyen> belief that not
> being critical means that one can choose to process it or sharon.boeyen>
> not, then i will recommend additional text for the standard to further
> sharon.boeyen> clarify the meaning for i can see no useful result from
> such potential sharon.boeyen> arbitrariness.
> sharon.boeyen>
> sharon.boeyen>    hoyt
> sharon.boeyen>
> sharon.boeyen>
> sharon.boeyen> Tony Bartoletti 925-422-3881 <[e-mail]>
> sharon.boeyen> Information Operations and Assurance Center
> sharon.boeyen> Lawrence Livermore National Laboratory
> sharon.boeyen> Livermore, CA 94551-9900
> sharon.boeyen>
> sharon.boeyen>





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BFcBqt099528 for <[e-mail]>; Fri, 11 Jul 2003 08:38:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BFcAkL099527 for ietf-pkix-bks; Fri, 11 Jul 2003 08:38:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BFbrqt099511 for <[e-mail]>; Fri, 11 Jul 2003 08:38:04 -0700 (PDT) (envelope-from [e-mail])
Received: from IdentrusVA1 ([203.81.193.89]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h6BFaGRn022913; Fri, 11 Jul 2003 21:36:17 +0600 (PKST)
Message-ID: <00d601c347c2$21763b90$0600a8c0@IdentrusVA1>
From: "Wahaj" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: What is mean by recognizing critical extensions ?
Date: Fri, 11 Jul 2003 20:35:51 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_00D0_01C347EC.05196470"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00D0_01C347EC.05196470
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00D1_01C347EC.05196470"


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

Re: What is mean by recognizing critical extensions ?After all the =
discussion, what I have understood is:

1) If extension is marked as Critical, application MUST process it. If =
an application can't process it, REJECT the chain altogether
2) If extension is NOT marked as Critical, you may not process it

Process mean: To read the extension, its values and check it according =
to some defined rules.

Don't you think option 1 is a bit harsh. Lets consider an example, if I =
have certificate from my CA, having SubjectAltName marked as critical ( =
why marked as critical ? cuz I use an application from the same CA, =
which process SubjectAltName). If lets say I want to use the same =
certificate in a scenario e.g. Buying books from XYZ.com who have =
implemented SSL with Client Side Authentication. If XYZ.com don't =
process SubjectAltName and according to RFC 3280 they reject my =
certificate, I can't use their service !!. This ask for another cert may =
be from another CA.=20

Best Regards,
Wahaj

  ----- Original Message -----=20
  From: Sharon Boeyen=20
  To: 'Hoyt L. Kesterson II' ; [e-mail]=20
  Sent: Friday, July 11, 2003 5:43 PM
  Subject: RE: What is mean by recognizing critical extensions ?


  I have no objection to eliminating "recognizes" from the text if it is =
felt necessary, but I also want to point out the text that is only a =
little bit further down in clause 8
  of X.509:

  A validation engine has two possible actions to take with respect to =
an extension:

  i)      it can ignore the extension and accept the certificate (all =
other things being equal);

  ii)     it can process the extension and accept or reject the =
certificate depending on the content of the extension and the conditions =
under which processing is occuring (e.g. the current values of the path =
processing variables).

  Some extensions can only be marked critical. In these cases a =
validation engine that understands the extension, processes it and =
acceptance/rejection of the certificate is dependent (at least in part) =
on the content of the extension. A validation engine that does not =
understand the extension rejects the certificate.

  Some extensions can only be marked non-critical. In these cases a =
validation engine that understands the extension processes it and =
acceptance/rejection of the certificate is dependent (at least in part) =
on the content of the extension. A validation engine that does not =
understand the extension accepts the certificate (unless factors other =
than this extension cause it to be rejected).

  Some extensions can be marked critical or non-critical. In these cases =
a validation engine that understands the extension processes it and =
acceptance/rejection of the certificate is dependent (at least in part) =
on the content of the extension, regardless of the criticality flag. A =
validation engine that does not understand the extension accepts the =
certificate if the extension is marked non-critical (unless factors =
other than this extension cause it to be rejected) and rejects the =
certificate if the extension is marked critical.



  While I suppose it could be argued that "understands" is not much =
better than "recognizes", I think the final paragraph is clearer about =
what a validation engine is required to do.=20

  =20

  I think that when we changed all this text the last time, there were =
some voices that opposed eliminating "recognizes" from the text because =
that is the only term that was used in the 3rd edition. Perhaps there is =
no longer support for that position. Note that these changes were a =
result of defect report 244 against the 3rd edition text (resolution =
published in TC 2 for 3rd edition and integrated into 4th edition text).

  Sharon

  =20

  =20

    -----Original Message-----
    From: Hoyt L. Kesterson II [mailto:[e-mail]]
    Sent: Thursday, July 10, 2003 8:47 PM
    To: [e-mail]
    Subject: Re: What is mean by recognizing critical extensions ?


    valid point. i don't see much value to considering "recognizes" as =
meaning i've heard about the extension but have no ability to process =
it. this possibly should be addressed in two places


     1) ietf agreed terminology for stating the capabilities of an =
implementation


      2) a clean-up of both ietf and iso/itu standard terminology. =
somewhere i had some additional text that i considered that stated that =
the implementation processed the extension according to the rules =
specified in the standard (old osi conformance lingo)


          hoyt




      Hoyt,

      I think the "dispute" is over the term "recognizes".  =
Hypothetically, an implementation may not have the code to "process" a =
given extension, but might claim to have the code to "recognize" the =
extension (and thereby hope to satisfy some extended compliance =
criteria, if erroneously).

      If one defines "recognizes" IFF "possesses the code to fully =
process", the dispute disappears.  But then, the conjunction "recognizes =
AND is able to process" (highlighted below) is indeed redundant, and =
plausibly misleading.

      Cheers!  ____tony____


      At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:

        I believe that this sentence

         When a certificate-using implementation recognizes and is able =
to process an extension, then the certificate-using implementation shall =
process the extension regardless of the value of the criticality flag.

        means that if an implementation has the code to process an =
extension, it must do so. if it doesn't have the code, then it will not =
process an extension because it cannot process it. if, in that case, =
that extension is flagged critical, then it cannot use the certificate.

        if anyone believe that the text says that an extension doesn't =
have to be processed even though there is an ability to process the =
extension, i.e. a belief that not being critical means that one can =
choose to process it or not, then i will recommend additional text for =
the standard to further clarify the meaning for i can see no useful =
result from such potential arbitrariness.

           hoyt

      Tony Bartoletti 925-422-3881 <[e-mail]>
      Information Operations and Assurance Center
      Lawrence Livermore National Laboratory
      Livermore, CA 94551-9900


------=_NextPart_001_00D1_01C347EC.05196470
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D =
"urn:schemas-microsoft-com:office:office"><HEAD><TITLE>Re: What is mean =
by recognizing critical extensions ?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>After all the discussion, what I have =
understood=20
is:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) If extension is marked as=20
Critical,&nbsp;application MUST process it. If an application&nbsp;can't =
process=20
it, REJECT the chain altogether</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2) If extension is NOT marked as =
Critical, you may=20
not process it</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Process mean: To read the extension, =
its values and=20
check it according to some defined rules.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Don't you think option 1 is a bit =
harsh. Lets=20
consider an example, if I have certificate from my CA, having =
SubjectAltName=20
marked as critical ( why marked as critical ? cuz I use an application =
from the=20
same CA, which process SubjectAltName). If lets say I want to use the =
same=20
certificate in a scenario e.g. Buying books from XYZ.com who have =
implemented=20
SSL with Client Side Authentication. If XYZ.com don't process =
SubjectAltName and=20
according to RFC 3280 they reject my certificate, I can't use their =
service !!.=20
This ask for another cert may be from another CA. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Best Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Wahaj</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Sharon Boeyen</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Hoyt L. Kesterson II'</A> =
; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">[e-mail]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 11, 2003 =
5:43 PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: What is mean by =
recognizing=20
  critical extensions ?</DIV>
  <DIV><BR></DIV>
  <DIV><SPAN class=3D072031012-11072003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  have no objection to eliminating "recognizes" from the text if it is =
felt=20
  necessary, but I also want to point out the text that is only a little =
bit=20
  further down in clause 8</FONT></SPAN></DIV>
  <DIV><SPAN class=3D072031012-11072003><FONT face=3DArial =
color=3D#0000ff size=3D2>of=20
  X.509:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D072031012-11072003><FONT color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D072031012-11072003><SPAN lang=3DEN-GB><FONT =
size=3D2>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial>A validation engine has two possible actions to take with =
respect=20
  to an extension:<o:p></o:p></FONT></SPAN></P>
  <P class=3Denumlev1 style=3D"MARGIN: 4.3pt 0in 0pt 59.55pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial>i)<SPAN style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>it can ignore the extension and accept the certificate (all =
other=20
  things being equal);<o:p></o:p></FONT></SPAN></P>
  <P class=3Denumlev1 style=3D"MARGIN: 4.3pt 0in 0pt 59.55pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial>ii)<SPAN style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>it can process the extension and accept or reject the =
certificate=20
  depending on the content of the extension and the conditions under =
which=20
  processing is occuring (e.g. the current values of the path processing =

  variables).<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><FONT =
face=3DArial>Some=20
  extensions can only be marked critical. In these cases a validation =
engine=20
  that understands the extension, processes it and acceptance/rejection =
of the=20
  certificate is dependent (at least in part) on the content of the =
extension. A=20
  validation engine that does not understand the extension rejects the=20
  certificate.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
  size=3D2><FONT face=3DArial>Some extensions can only be marked =
non-critical. In=20
  these cases a validation engine that understands the extension =
processes it=20
  and acceptance/rejection of the certificate is dependent (at least in =
part) on=20
  the content of the extension. A validation engine that does not =
understand the=20
  extension accepts the certificate (unless factors other than this =
extension=20
  cause it to be rejected).<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial size=3D2>Some extensions can be marked critical or =
non-critical. In=20
  these cases a validation engine that understands the extension =
processes it=20
  and acceptance/rejection of the certificate is dependent (at least in =
part) on=20
  the content of the extension, regardless of the criticality flag. A =
validation=20
  engine that does not understand the extension accepts the certificate =
if the=20
  extension is marked non-critical (unless factors other than this =
extension=20
  cause it to be rejected) and rejects the certificate if the extension =
is=20
  marked critical.</FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial size=3D2></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial size=3D2>While I suppose =
it could be=20
  argued that "understands" is not much better than "recognizes", I =
think the=20
  final paragraph is clearer about what a validation engine is required =
to do.=20
  </FONT></SPAN></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial=20
  size=3D2></FONT></SPAN></o:p></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial size=3D2>I think that =
when we changed=20
  all this text the last time, there were some voices that opposed =
eliminating=20
  "recognizes" from the text because that is the only term that was used =
in the=20
  3rd edition. Perhaps there is no longer support for that position. =
Note that=20
  these changes were a result of defect report 244 against the 3rd =
edition text=20
  (resolution published in TC 2 for 3rd edition and integrated into 4th =
edition=20
  text).</FONT></SPAN></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial=20
  size=3D2>Sharon</FONT></SPAN></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial=20
  size=3D2></FONT></SPAN></o:p></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT=20
  size=3D2></FONT></SPAN></o:p></SPAN>&nbsp;</P></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Hoyt L. =
Kesterson II=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, July =
10, 2003=20
    8:47 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Re: What =
is mean=20
    by recognizing critical extensions ?<BR><BR></FONT></DIV>
    <DIV>valid point. i don't see much value to considering "recognizes" =
as=20
    meaning i've heard about the extension but have no ability to =
process it.=20
    this possibly should be addressed in two places</DIV>
    <DIV><BR></DIV>
    <DIV>&nbsp;1) ietf agreed terminology for stating the capabilities =
of an=20
    implementation</DIV>
    <DIV><BR></DIV>
    <DIV>&nbsp; 2) a clean-up of both ietf and iso/itu standard =
terminology.=20
    somewhere i had some additional text that i considered that stated =
that the=20
    implementation processed the extension according to the rules =
specified in=20
    the standard (old osi conformance lingo)</DIV>
    <DIV><BR></DIV>
    <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hoyt</DIV>
    <DIV><BR></DIV>
    <DIV><BR></DIV>
    <BLOCKQUOTE cite=3D"" type=3D"cite">Hoyt,<BR><BR>I think the =
"dispute" is over=20
      the term "recognizes".&nbsp; Hypothetically, an implementation may =
not=20
      have the code to "process" a given extension, but might claim to =
have the=20
      code to "recognize" the extension (and thereby hope to satisfy =
some=20
      extended compliance criteria, if erroneously).<BR><BR>If one =
defines=20
      "recognizes" IFF "possesses the code to fully process", the =
dispute=20
      disappears.&nbsp; But then, the conjunction "recognizes AND is =
able to=20
      process" (highlighted below) is indeed redundant, and plausibly=20
      misleading.<BR><BR>Cheers!&nbsp; ____tony____<BR><BR><BR>At 02:59 =
PM=20
      7/10/2003 -0700, Hoyt L. Kesterson II wrote:<BR>
      <BLOCKQUOTE cite=3D"" type=3D"cite">I believe that this=20
        sentence<BR><BR><FONT face=3D"Times New Roman" =
size=3D+1>&nbsp;When a=20
        certificate-using implementation<B> recognizes and is able to=20
        process</B> an extension, then the certificate-using =
implementation=20
        shall process the extension regardless of the value of the =
criticality=20
        flag.</FONT><BR><BR>means that if an implementation has the code =
to=20
        process an extension, it must do so. if it doesn't have the =
code, then=20
        it will not process an extension because it cannot process it. =
if, in=20
        that case, that extension is flagged critical, then it cannot =
use the=20
        certificate.<BR><BR>if anyone believe that the text says that an =

        extension doesn't have to be processed even though there is an =
ability=20
        to process the extension, i.e. a belief that not being critical =
means=20
        that one can choose to process it or not, then i will recommend=20
        additional text for the standard to further clarify the meaning =
for i=20
        can see no useful result from such potential=20
        arbitrariness.<BR><BR>&nbsp;&nbsp; =
hoyt<BR></BLOCKQUOTE></BLOCKQUOTE>
    <BLOCKQUOTE cite=3D"" type=3D"cite">Tony Bartoletti 925-422-3881=20
      &lt;[e-mail]&gt;<BR>Information Operations and Assurance=20
      Center<BR>Lawrence Livermore National Laboratory<BR>Livermore, CA=20
      94551-9900</BLOCKQUOTE>
    <DIV><BR></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_00D1_01C347EC.05196470--

------=_NextPart_000_00D0_01C347EC.05196470
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

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

------=_NextPart_000_00D0_01C347EC.05196470--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BEx6qt097641 for <[e-mail]>; Fri, 11 Jul 2003 07:59:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BEx6Kn097640 for ietf-pkix-bks; Fri, 11 Jul 2003 07:59:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BEx4qt097627 for <[e-mail]>; Fri, 11 Jul 2003 07:59:04 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V6BE2JSW18604 for <[e-mail]>; Fri, 11 Jul 2003 10:55:28 -0400
Received: (qmail 7185 invoked by uid 64014); 11 Jul 2003 14:53:28 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.756027 secs); 11 Jul 2003 14:53:28 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 11 Jul 2003 14:53:27 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <3S6ZL5TY>; Fri, 11 Jul 2003 10:58:58 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Hoyt L. Kesterson II'" <[e-mail]>, [e-mail]
Subject: RE: What is mean by recognizing critical extensions ?
Date: Fri, 11 Jul 2003 10:58:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C347BC.F44E1ED0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C347BC.F44E1ED0
Content-Type: text/plain

 Oops, Correction, the text I quoted in my earlier message is from clause 7,
not clause 8. Here is the relevant text from clause 8. Hoyt I wonder if this
is the text you were thinking about?
In a certificate or CRL, an extension is flagged as being either critical or
non-critical. If an extension is flagged critical and a certificate-using
system does not recognize the extension field type or does not implement the
semantics of the extension, then that system shall consider the certificate
invalid. If an extension is flagged non-critical, a certificate-using system
that does not recognize or implement that extension type may process the
remainder of the certificate ignoring the extension. If an extension is
flagged non-critical, a certificate-using system that does recognize the
extension, shall process the extension. Extension type definitions in this
Directory Specification indicate if the extension is always critical, always
non-critical, or if criticality can be decided by the certificate or CRL
issuer. The reason for requiring some extensions to be always non-critical
is to allow certificate-using implementations which do not need to use such
extensions to omit support for them without jeopardizing the ability to
interoperate with all certification authorities.

 
While on this topic of critical extensions and rejections - I want to be
sure everyone realizes that  the handling is different for CRLs. If the
certificate of interest is listed as revoked on a CRL it is as a minimum
considered revoked regardless of the presence of unrecognized critical
extensions. Here is the relevant text from clause 7.3 of X.509:
 
NOTE 4 - When an implementation processing a certificate revocation list
does not recognize a critical extension in the crlEntryExtensions field, it
shall assume that, at a minimum, the identified certificate has been revoked
and is no longer valid and perform additional actions concerning that
revoked certificate as dictated by local policy. When an implementation does
not recognize a critical extension in the crlExtensions field, it shall
assume that identified certificates have been revoked and are no longer
valid. However in the latter case, since the list may not be complete,
certificates that have not been identified as being revoked cannot be
assumed to be valid. In this case local policy shall dictate the action to
be taken. In any case local policy may dictate actions in addition to and/or
stronger than those stated in this Specification.



I'll stop quoting now (I guess having edited a document does come in handy
for some reasons - at least I can generally locate text when it appears in
the "not most obvious" places :-)
 
 -----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]]
Sent: Friday, July 11, 2003 8:43 AM
To: 'Hoyt L. Kesterson II'; [e-mail]
Subject: RE: What is mean by recognizing critical extensions ?


I have no objection to eliminating "recognizes" from the text if it is felt
necessary, but I also want to point out the text that is only a little bit
further down in clause 8
of X.509:
 
A validation engine has two possible actions to take with respect to an
extension:

i)      it can ignore the extension and accept the certificate (all other
things being equal);

ii)     it can process the extension and accept or reject the certificate
depending on the content of the extension and the conditions under which
processing is occuring (e.g. the current values of the path processing
variables).

Some extensions can only be marked critical. In these cases a validation
engine that understands the extension, processes it and acceptance/rejection
of the certificate is dependent (at least in part) on the content of the
extension. A validation engine that does not understand the extension
rejects the certificate.

Some extensions can only be marked non-critical. In these cases a validation
engine that understands the extension processes it and acceptance/rejection
of the certificate is dependent (at least in part) on the content of the
extension. A validation engine that does not understand the extension
accepts the certificate (unless factors other than this extension cause it
to be rejected).

Some extensions can be marked critical or non-critical. In these cases a
validation engine that understands the extension processes it and
acceptance/rejection of the certificate is dependent (at least in part) on
the content of the extension, regardless of the criticality flag. A
validation engine that does not understand the extension accepts the
certificate if the extension is marked non-critical (unless factors other
than this extension cause it to be rejected) and rejects the certificate if
the extension is marked critical.

 

While I suppose it could be argued that "understands" is not much better
than "recognizes", I think the final paragraph is clearer about what a
validation engine is required to do. 

 

I think that when we changed all this text the last time, there were some
voices that opposed eliminating "recognizes" from the text because that is
the only term that was used in the 3rd edition. Perhaps there is no longer
support for that position. Note that these changes were a result of defect
report 244 against the 3rd edition text (resolution published in TC 2 for
3rd edition and integrated into 4th edition text).

Sharon

 

 

-----Original Message-----
From: Hoyt L. Kesterson II [mailto:[e-mail]]
Sent: Thursday, July 10, 2003 8:47 PM
To: [e-mail]
Subject: Re: What is mean by recognizing critical extensions ?


valid point. i don't see much value to considering "recognizes" as meaning
i've heard about the extension but have no ability to process it. this
possibly should be addressed in two places

 1) ietf agreed terminology for stating the capabilities of an
implementation

  2) a clean-up of both ietf and iso/itu standard terminology. somewhere i
had some additional text that i considered that stated that the
implementation processed the extension according to the rules specified in
the standard (old osi conformance lingo)

      hoyt



Hoyt,

I think the "dispute" is over the term "recognizes".  Hypothetically, an
implementation may not have the code to "process" a given extension, but
might claim to have the code to "recognize" the extension (and thereby hope
to satisfy some extended compliance criteria, if erroneously).

If one defines "recognizes" IFF "possesses the code to fully process", the
dispute disappears.  But then, the conjunction "recognizes AND is able to
process" (highlighted below) is indeed redundant, and plausibly misleading.

Cheers!  ____tony____


At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:


I believe that this sentence

 When a certificate-using implementation recognizes and is able to process
an extension, then the certificate-using implementation shall process the
extension regardless of the value of the criticality flag.

means that if an implementation has the code to process an extension, it
must do so. if it doesn't have the code, then it will not process an
extension because it cannot process it. if, in that case, that extension is
flagged critical, then it cannot use the certificate.

if anyone believe that the text says that an extension doesn't have to be
processed even though there is an ability to process the extension, i.e. a
belief that not being critical means that one can choose to process it or
not, then i will recommend additional text for the standard to further
clarify the meaning for i can see no useful result from such potential
arbitrariness.

   hoyt


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



------_=_NextPart_001_01C347BC.F44E1ED0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>Re: What is mean by recognizing critical extensions ?</TITLE>

<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D998065114-11072003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;Oops, Correction, the text I quoted in my earlier =
message&nbsp;is=20
from clause 7, not clause 8. Here is the relevant text from clause 8. =
Hoyt I=20
wonder if this is the text you were thinking about?</FONT></SPAN></DIV>
<DIV><SPAN class=3D998065114-11072003>
<P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
size=3D2>In a certificate or CRL, an extension is flagged as being =
either critical=20
or non-critical. If an extension is flagged critical and a =
certificate-using=20
system does not recognize the extension field type or does not =
implement the=20
semantics of the extension, then that system shall consider the =
certificate=20
invalid. If an extension is flagged non-critical, a certificate-using =
system=20
that does not recognize or implement that extension type may process =
the=20
remainder of the certificate ignoring the extension. If an extension is =
flagged=20
non-critical, a certificate-using system that does recognize the =
extension,=20
shall process the extension. Extension type definitions in this =
Directory=20
Specification indicate if the extension is always critical, always =
non-critical,=20
or if criticality can be decided by the certificate or CRL issuer. The =
reason=20
for requiring some extensions to be always non-critical is to allow=20
certificate-using implementations which do not need to use such =
extensions to=20
omit support for them without jeopardizing the ability to interoperate =
with all=20
certification authorities.<o:p></o:p></FONT></SPAN></P></SPAN></DIV>
<DIV><SPAN class=3D998065114-11072003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D998065114-11072003><FONT face=3DArial =
color=3D#0000ff size=3D2>While=20
on this topic of critical extensions and rejections - I want to be sure =
everyone=20
realizes that&nbsp; the handling is different for CRLs. If the =
certificate of=20
interest is listed as revoked on a CRL it is as a minimum considered =
revoked=20
regardless of the presence of unrecognized critical extensions. Here is =
the=20
relevant text from clause 7.3 of X.509:</FONT></SPAN></DIV>
<DIV><SPAN class=3D998065114-11072003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D998065114-11072003><FONT face=3DArial =
color=3D#0000ff size=3D2>
<P class=3DNote1 style=3D"MARGIN: 3pt 0in 0pt 14.2pt"><FONT =
color=3D#000000><SPAN=20
lang=3DEN-GB><FONT face=3D"Times New Roman">NOTE 4 &#8211; When an =
implementation=20
processing a certificate revocation list does not recognize a critical =
extension=20
in the </FONT></SPAN><B style=3D"mso-bidi-font-weight: normal"><SPAN =
lang=3DEN-GB=20
style=3D"FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
10.0pt; mso-bidi-font-family: 'Times New =
Roman'">crlEntryExtensions</SPAN></B><SPAN=20
lang=3DEN-GB><FONT face=3D"Times New Roman"> field, it shall assume =
that, at a=20
minimum, the identified certificate has been revoked and is no longer =
valid and=20
perform additional actions concerning that revoked certificate as =
dictated by=20
local policy. When an implementation does not recognize a critical =
extension in=20
the </FONT></SPAN><B style=3D"mso-bidi-font-weight: normal"><SPAN =
lang=3DEN-GB=20
style=3D"FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
10.0pt; mso-bidi-font-family: 'Times New Roman'">crlExtensions</SPAN></B=
><SPAN=20
lang=3DEN-GB><FONT face=3D"Times New Roman"> field, it shall assume =
that identified=20
certificates have been revoked and are no longer valid. However in the =
latter=20
case, since the list may not be complete, certificates that have not =
been=20
identified as being revoked cannot be assumed to be valid. In this case =
local=20
policy shall dictate the action to be taken. In any case local policy =
may=20
dictate actions in addition to and/or stronger than those stated in =
this=20
Specification.</FONT></SPAN></FONT></P></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><FONT face=3DTahoma>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><BR><SPAN=20
  class=3D998065114-11072003><FONT face=3DArial color=3D#0000ff =
size=3D2>I'll stop=20
  quoting now (I guess having edited a document does come in handy for =
some=20
  reasons - at least I can generally locate text when it appears in the =
"not=20
  most obvious" places :-)</FONT></SPAN></DIV>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
size=3D2><SPAN=20
  class=3D998065114-11072003></SPAN></FONT>&nbsp;</DIV>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
size=3D2><SPAN=20
  class=3D998065114-11072003>&nbsp;</SPAN>-----Original=20
  Message-----<BR><B>From:</B> Sharon Boeyen=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, July 11, =
2003 8:43=20
  AM<BR><B>To:</B> 'Hoyt L. Kesterson II'; =
[e-mail]<BR><B>Subject:</B>=20
  RE: What is mean by recognizing critical extensions=20
  ?<BR><BR></DIV></FONT></FONT>
  <DIV><SPAN class=3D072031012-11072003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  have no objection to eliminating "recognizes" from the text if it is =
felt=20
  necessary, but I also want to point out the text that is only a =
little bit=20
  further down in clause 8</FONT></SPAN></DIV>
  <DIV><SPAN class=3D072031012-11072003><FONT face=3DArial =
color=3D#0000ff size=3D2>of=20
  X.509:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D072031012-11072003><FONT color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D072031012-11072003><SPAN lang=3DEN-GB><FONT =
size=3D2>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial>A validation engine has two possible actions to take =
with respect=20
  to an extension:<o:p></o:p></FONT></SPAN></P>
  <P class=3Denumlev1 style=3D"MARGIN: 4.3pt 0in 0pt 59.55pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial>i)<SPAN style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>it can ignore the extension and accept the certificate (all =
other=20
  things being equal);<o:p></o:p></FONT></SPAN></P>
  <P class=3Denumlev1 style=3D"MARGIN: 4.3pt 0in 0pt 59.55pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial>ii)<SPAN style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>it can process the extension and accept or reject the =
certificate=20
  depending on the content of the extension and the conditions under =
which=20
  processing is occuring (e.g. the current values of the path =
processing=20
  variables).<o:p></o:p></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><FONT =
face=3DArial>Some=20
  extensions can only be marked critical. In these cases a validation =
engine=20
  that understands the extension, processes it and acceptance/rejection =
of the=20
  certificate is dependent (at least in part) on the content of the =
extension. A=20
  validation engine that does not understand the extension rejects the=20
  certificate.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
  size=3D2><FONT face=3DArial>Some extensions can only be marked =
non-critical. In=20
  these cases a validation engine that understands the extension =
processes it=20
  and acceptance/rejection of the certificate is dependent (at least in =
part) on=20
  the content of the extension. A validation engine that does not =
understand the=20
  extension accepts the certificate (unless factors other than this =
extension=20
  cause it to be rejected).<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial size=3D2>Some extensions can be marked critical or =
non-critical. In=20
  these cases a validation engine that understands the extension =
processes it=20
  and acceptance/rejection of the certificate is dependent (at least in =
part) on=20
  the content of the extension, regardless of the criticality flag. A =
validation=20
  engine that does not understand the extension accepts the certificate =
if the=20
  extension is marked non-critical (unless factors other than this =
extension=20
  cause it to be rejected) and rejects the certificate if the extension =
is=20
  marked critical.</FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><FONT=20
  face=3DArial size=3D2></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial size=3D2>While I =
suppose it could be=20
  argued that "understands" is not much better than "recognizes", I =
think the=20
  final paragraph is clearer about what a validation engine is required =
to do.=20
  </FONT></SPAN></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial=20
  size=3D2></FONT></SPAN></o:p></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial size=3D2>I think that =
when we changed=20
  all this text the last time, there were some voices that opposed =
eliminating=20
  "recognizes" from the text because that is the only term that was =
used in the=20
  3rd edition. Perhaps there is no longer support for that position. =
Note that=20
  these changes were a result of defect report 244 against the 3rd =
edition text=20
  (resolution published in TC 2 for 3rd edition and integrated into 4th =
edition=20
  text).</FONT></SPAN></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial=20
  size=3D2>Sharon</FONT></SPAN></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT face=3DArial=20
  size=3D2></FONT></SPAN></o:p></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 6.8pt 0in 0pt"><SPAN =
lang=3DEN-GB><o:p><SPAN=20
  class=3D072031012-11072003><FONT=20
  size=3D2></FONT></SPAN></o:p></SPAN>&nbsp;</P></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Hoyt L. =
Kesterson II=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, July =
10, 2003=20
    8:47 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Re: What =
is mean=20
    by recognizing critical extensions ?<BR><BR></FONT></DIV>
    <DIV>valid point. i don't see much value to considering =
"recognizes" as=20
    meaning i've heard about the extension but have no ability to =
process it.=20
    this possibly should be addressed in two places</DIV>
    <DIV><BR></DIV>
    <DIV>&nbsp;1) ietf agreed terminology for stating the capabilities =
of an=20
    implementation</DIV>
    <DIV><BR></DIV>
    <DIV>&nbsp; 2) a clean-up of both ietf and iso/itu standard =
terminology.=20
    somewhere i had some additional text that i considered that stated =
that the=20
    implementation processed the extension according to the rules =
specified in=20
    the standard (old osi conformance lingo)</DIV>
    <DIV><BR></DIV>
    <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hoyt</DIV>
    <DIV><BR></DIV>
    <DIV><BR></DIV>
    <BLOCKQUOTE cite=3D"" type=3D"cite">Hoyt,<BR><BR>I think the =
"dispute" is over=20
      the term "recognizes".&nbsp; Hypothetically, an implementation =
may not=20
      have the code to "process" a given extension, but might claim to =
have the=20
      code to "recognize" the extension (and thereby hope to satisfy =
some=20
      extended compliance criteria, if erroneously).<BR><BR>If one =
defines=20
      "recognizes" IFF "possesses the code to fully process", the =
dispute=20
      disappears.&nbsp; But then, the conjunction "recognizes AND is =
able to=20
      process" (highlighted below) is indeed redundant, and plausibly=20
      misleading.<BR><BR>Cheers!&nbsp; ____tony____<BR><BR><BR>At 02:59 =
PM=20
      7/10/2003 -0700, Hoyt L. Kesterson II wrote:<BR>
      <BLOCKQUOTE cite=3D"" type=3D"cite">I believe that this=20
        sentence<BR><BR><FONT face=3D"Times New Roman" =
size=3D+1>&nbsp;When a=20
        certificate-using implementation<B> recognizes and is able to=20
        process</B> an extension, then the certificate-using =
implementation=20
        shall process the extension regardless of the value of the =
criticality=20
        flag.</FONT><BR><BR>means that if an implementation has the =
code to=20
        process an extension, it must do so. if it doesn't have the =
code, then=20
        it will not process an extension because it cannot process it. =
if, in=20
        that case, that extension is flagged critical, then it cannot =
use the=20
        certificate.<BR><BR>if anyone believe that the text says that =
an=20
        extension doesn't have to be processed even though there is an =
ability=20
        to process the extension, i.e. a belief that not being critical =
means=20
        that one can choose to process it or not, then i will recommend =

        additional text for the standard to further clarify the meaning =
for i=20
        can see no useful result from such potential=20
        arbitrariness.<BR><BR>&nbsp;&nbsp; =
hoyt<BR></BLOCKQUOTE></BLOCKQUOTE>
    <BLOCKQUOTE cite=3D"" type=3D"cite">Tony Bartoletti 925-422-3881=20
      &lt;[e-mail]&gt;<BR>Information Operations and Assurance=20
      Center<BR>Lawrence Livermore National Laboratory<BR>Livermore, CA =

      94551-9900</BLOCKQUOTE>
    <DIV><BR></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C347BC.F44E1ED0--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BErlqt097487 for <[e-mail]>; Fri, 11 Jul 2003 07:53:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BErl0h097486 for ietf-pkix-bks; Fri, 11 Jul 2003 07:53:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BErjqt097479 for <[e-mail]>; Fri, 11 Jul 2003 07:53:45 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (105.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.105]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003071114533811100qg9che>; Fri, 11 Jul 2003 14:53:38 +0000
Message-ID: <01a501c347bc$2e057840$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Hoyt L. Kesterson II" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail] v.microsoft.com> <[e-mail]> <[e-mail]> <a05210608bb339010a1e7@[192.168.2.7]>
Subject: Re: What is mean by recognizing critical extensions ?
Date: Fri, 11 Jul 2003 07:53:17 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A2_01C34781.7D0356F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_01A2_01C34781.7D0356F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: What is mean by recognizing critical extensions ?Hoyt, this is an =
instance where the would MUST is appropriate because what you are =
referring to is a the compliance model for use and nothing less.=20

On a tangent of this, one of the amazing things is that the technical =
world seems to miss that most implementation's of this high-tech will be =
SW in nature, and so they will require some form of internal auditing to =
assure they are in compliance with the standards. In fact it probably =
would be wise for the IETF to require some 'test component' =
specification in the standards track to qualify a technology for release =
as a standard and possibly publish these as a BCP recommendation for =
validating the PKI environment.=20

Not that it, the IETF, should build the toolkit like what OpenGroup does =
with their Unix qualification suite, but at least the top level of the =
functional architecture...

Hmmmm. This is also is probably germane to the x509 standards track too.

T
  ----- Original Message -----=20
  From: Hoyt L. Kesterson II=20
  To: [e-mail]=20
  Sent: Thursday, July 10, 2003 2:59 PM
  Subject: Re: What is mean by recognizing critical extensions ?


  I believe that this sentence


   When a certificate-using implementation recognizes and is able to =
process an extension, then the certificate-using implementation shall =
process the extension regardless of the value of the criticality flag.


  means that if an implementation has the code to process an extension, =
it must do so. if it doesn't have the code, then it will not process an =
extension because it cannot process it. if, in that case, that extension =
is flagged critical, then it cannot use the certificate.


  if anyone believe that the text says that an extension doesn't have to =
be processed even though there is an ability to process the extension, =
i.e. a belief that not being critical means that one can choose to =
process it or not, then i will recommend additional text for the =
standard to further clarify the meaning for i can see no useful result =
from such potential arbitrariness.


     hoyt




    At 10:14 PM 7/9/2003 -0700, Hoyt L. Kesterson II wrote:

      At 10:31 -0400 7/8/03, David A. Cooper wrote:

      as we were finishing up the 4th edition sharon boeyen reported to =
our group that some implementors were using an interesting =
interpretation of "recognizing an extension". apparently their =
recognition essentially meant that they recognized the oid and =
recognized that the extension was defined but did not process it, i.e =
wrote no code to process the extension as defined in the standard. to =
counter this specious argument we wrote some additional text for clause =
7


    [snip]

      the 4th edition has this replacement paragraph (as well as =
additional paragraphs)


    [snip]

      therein. When an implementation processing a certificate does not =
recognize an extension, if the criticality flag is FALSE, it may ignore =
that extension. If the criticality flag is TRUE, unrecognized extensions =
shall cause the structure to be considered invalid, i.e. in a =
certificate, an unrecognized critical extension would cause validation =
of a signature using that certificate to fail. When a certificate-using =
implementation recognizes and is able to process an extension, then the =
certificate-using implementation shall process the extension regardless =
of the value of the criticality flag. Note that any extension that is =
flagged non-critical will cause inconsistent behaviour between =
certificate-using systems that will process the extension and =
certificate-using systems that do not recognize the extension and will =
ignore it."

      note the penultimate sentence.

    Indeed.  This clearly implies that non-critical extensions "may or =
may not" be processed.

    Moreover, additional confusion is engendered by the phrase

        "recognizes and is able to process".

    Perhaps this is a redundant conjunction, but logically it implies =
that "recognizes" and "is able to process" are distinct conditions =
(else, why the conjunction?)

    Thus, for non-critical extensions, one has THREE cases:

    1.  Does not recognize (may or may not validate certificate, up to =
implementation)

    2.  "Recognizes", but cannot process (same result as in 1.)

    3.  Recognizes and CAN process (MUST process to determine validity.)

    If the intent is to use the term "recognizes" to mean "can process", =
then the condition "recognizes and can process" adds to the confusion.

    Cheers!  ____tony____

    Tony Bartoletti 925-422-3881 <[e-mail]>
    Information Operations and Assurance Center
    Lawrence Livermore National Laboratory
    Livermore, CA 94551-9900


------=_NextPart_000_01A2_01C34781.7D0356F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: What is mean by recognizing critical extensions =
?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hoyt, this is an instance where the =
would MUST is=20
appropriate because what you are referring to is a the compliance model =
for use=20
and nothing less. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>On a tangent of this, one of the =
amazing things is=20
that the technical world seems to miss that most implementation's of =
this=20
high-tech will be SW in nature, and so they will require some form of =
internal=20
auditing to assure they are in compliance with the standards. In fact it =

probably would be wise for the IETF to require some 'test component'=20
specification in the standards track to qualify a technology for release =
as a=20
standard and possibly publish these as a BCP recommendation for =
validating the=20
PKI environment. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Not that it, the IETF,&nbsp;should =
build the=20
toolkit like what OpenGroup does with their Unix qualification suite, =
but at=20
least the top level of the functional architecture...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Hmmmm. This is also is probably germane =
to the x509=20
standards track too.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>T</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Hoyt L. Kesterson II</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, July 10, 2003 =
2:59=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: What is mean by =
recognizing=20
  critical extensions ?</DIV>
  <DIV><BR></DIV>
  <DIV>I believe that this sentence</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3D"Times New Roman" size=3D+1>&nbsp;When a =
certificate-using=20
  implementation<B> recognizes and is able to process</B> an extension, =
then the=20
  certificate-using implementation shall process the extension =
regardless of the=20
  value of the criticality flag.</FONT></DIV>
  <DIV><BR></DIV>
  <DIV>means that if an implementation has the code to process an =
extension, it=20
  must do so. if it doesn't have the code, then it will not process an =
extension=20
  because it cannot process it. if, in that case, that extension is =
flagged=20
  critical, then it cannot use the certificate.</DIV>
  <DIV><BR></DIV>
  <DIV>if anyone believe that the text says that an extension doesn't =
have to be=20
  processed even though there is an ability to process the extension, =
i.e. a=20
  belief that not being critical means that one can choose to process it =
or not,=20
  then i will recommend additional text for the standard to further =
clarify the=20
  meaning for i can see no useful result from such potential=20
arbitrariness.</DIV>
  <DIV><BR></DIV>
  <DIV>&nbsp;&nbsp; hoyt</DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite">At 10:14 PM 7/9/2003 -0700, Hoyt =
L.=20
    Kesterson II wrote:<BR>
    <BLOCKQUOTE cite=3D"" type=3D"cite">At 10:31 -0400 7/8/03, David A. =
Cooper=20
      wrote:<BR><BR>as we were finishing up the 4th edition sharon =
boeyen=20
      reported to our group that some implementors were using an =
interesting=20
      interpretation of "recognizing an extension". apparently their =
recognition=20
      essentially meant that they recognized the oid and recognized that =
the=20
      extension was defined but did not process it, i.e wrote no code to =
process=20
      the extension as defined in the standard. to counter this specious =

      argument we wrote some additional text for clause=20
  7<BR></BLOCKQUOTE></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><BR>[snip]<BR>
    <BLOCKQUOTE cite=3D"" type=3D"cite">the 4th edition has this =
replacement=20
      paragraph (as well as additional =
paragraphs)<BR></BLOCKQUOTE></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><BR>[snip]<BR>
    <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3D"Times New Roman"=20
      size=3D+1>therein. When an implementation processing a certificate =
does not=20
      recognize an extension, if the criticality flag is</FONT><FONT =
face=3DArial=20
      size=3D+1><B> FALSE</B></FONT><FONT face=3D"Times New Roman" =
size=3D+1>, it may=20
      ignore that extension. If the criticality flag is</FONT><FONT =
face=3DArial=20
      size=3D+1><B> TRUE</B></FONT><FONT face=3D"Times New Roman" =
size=3D+1>,=20
      unrecognized extensions shall cause the structure to be considered =

      invalid, i.e. in a certificate, an unrecognized critical extension =
would=20
      cause validation of a signature using that certificate to fail. =
When a=20
      certificate-using implementation<B> recognizes and is able to =
process</B>=20
      an extension, then the certificate-using implementation shall =
process the=20
      extension regardless of the value of the criticality flag. Note =
that any=20
      extension that is flagged non-critical will cause inconsistent =
behaviour=20
      between certificate-using systems that will process the extension =
and=20
      certificate-using systems that do not recognize the extension and =
will=20
      ignore it.</FONT>"<BR><BR>note the penultimate=20
  sentence.<BR></BLOCKQUOTE></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">Indeed.&nbsp; This clearly implies =
that=20
    non-critical extensions "may or may not" be =
processed.<BR><BR>Moreover,=20
    additional confusion is engendered by the =
phrase<BR><BR>&nbsp;&nbsp;&nbsp;=20
    "recognizes and is able to process".<BR><BR>Perhaps this is a =
redundant=20
    conjunction, but logically it implies that "recognizes" and "is able =
to=20
    process" are distinct conditions (else, why the =
conjunction?)<BR><BR>Thus,=20
    for non-critical extensions, one has THREE cases:<BR><BR>1.&nbsp; =
Does not=20
    recognize (may or may not validate certificate, up to=20
    implementation)<BR><BR>2.&nbsp; "Recognizes", but cannot process =
(same=20
    result as in 1.)<BR><BR>3.&nbsp; Recognizes and CAN process (MUST =
process to=20
    determine validity.)<BR><BR>If the intent is to use the term =
"recognizes" to=20
    mean "can process", then the condition "recognizes and can process" =
adds to=20
    the confusion.<BR><BR>Cheers!&nbsp; ____tony____<BR><BR>Tony =
Bartoletti=20
    925-422-3881 &lt;[e-mail]&gt;<BR>Information Operations and =
Assurance=20
    Center<BR>Lawrence Livermore National Laboratory<BR>Livermore, CA=20
  94551-9900</BLOCKQUOTE>
  <DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_01A2_01C34781.7D0356F0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BEXBqt096890 for <[e-mail]>; Fri, 11 Jul 2003 07:33:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BEXBeP096889 for ietf-pkix-bks; Fri, 11 Jul 2003 07:33:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BEX9qt096883 for <[e-mail]>; Fri, 11 Jul 2003 07:33:09 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 11 Jul 2003 16:31:26 +0200
Date: Fri, 11 Jul 2003 16:31:23 +0200 (CEST)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: What is mean by recognizing critical extensions ?
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.1, Mew version 3.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Contrary to others, I don't believe the problem lies in the word
"recognises" itself.  It's more the whole sentence that seems to be
confusing (and I agree with those who think so).

To me, the quoted language from X.509 certainly seems to say "if you
recognise this extension, you must process it or invalidate the path,
period", while the quote text from the other document seems to say "if
you recognise this extension and can process it, you must process it".

In pseudo-C terms, I get it like this:

X.509:	if (recognise(extension)) {
		if (can_process(extension))
			process(extension);	
		else
			invalidate(path);
	} else if (critical(extension)) {
		invalidate(path);
	}

other:	if (recognise(extension) && can_process(extension)) {
		process(extension);
	} else if (critical(extension)) {
		invalidate(path);
	}

Makes sense?

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


In message <[e-mail]> on Fri, 11 Jul 2003 08:43:16 -0400, Sharon Boeyen <[e-mail]> said:

sharon.boeyen> I have no objection to eliminating "recognizes" from the text if it is felt
sharon.boeyen> necessary, but I also want to point out the text that is only a little bit
sharon.boeyen> further down in clause 8
sharon.boeyen> of X.509:
sharon.boeyen>  
sharon.boeyen> A validation engine has two possible actions to take with respect to an
sharon.boeyen> extension:<?xml:namespace prefix = o ns =
sharon.boeyen> "urn:schemas-microsoft-com:office:office" />
sharon.boeyen> 
sharon.boeyen> i)      it can ignore the extension and accept the certificate (all other
sharon.boeyen> things being equal);
sharon.boeyen> 
sharon.boeyen> ii)     it can process the extension and accept or reject the certificate
sharon.boeyen> depending on the content of the extension and the conditions under which
sharon.boeyen> processing is occuring (e.g. the current values of the path processing
sharon.boeyen> variables).
sharon.boeyen> 
sharon.boeyen> Some extensions can only be marked critical. In these cases a validation
sharon.boeyen> engine that understands the extension, processes it and acceptance/rejection
sharon.boeyen> of the certificate is dependent (at least in part) on the content of the
sharon.boeyen> extension. A validation engine that does not understand the extension
sharon.boeyen> rejects the certificate.
sharon.boeyen> 
sharon.boeyen> Some extensions can only be marked non-critical. In these cases a validation
sharon.boeyen> engine that understands the extension processes it and acceptance/rejection
sharon.boeyen> of the certificate is dependent (at least in part) on the content of the
sharon.boeyen> extension. A validation engine that does not understand the extension
sharon.boeyen> accepts the certificate (unless factors other than this extension cause it
sharon.boeyen> to be rejected).
sharon.boeyen> 
sharon.boeyen> Some extensions can be marked critical or non-critical. In these cases a
sharon.boeyen> validation engine that understands the extension processes it and
sharon.boeyen> acceptance/rejection of the certificate is dependent (at least in part) on
sharon.boeyen> the content of the extension, regardless of the criticality flag. A
sharon.boeyen> validation engine that does not understand the extension accepts the
sharon.boeyen> certificate if the extension is marked non-critical (unless factors other
sharon.boeyen> than this extension cause it to be rejected) and rejects the certificate if
sharon.boeyen> the extension is marked critical.
sharon.boeyen> 
sharon.boeyen>  
sharon.boeyen> 
sharon.boeyen> While I suppose it could be argued that "understands" is not much better
sharon.boeyen> than "recognizes", I think the final paragraph is clearer about what a
sharon.boeyen> validation engine is required to do. 
sharon.boeyen> 
sharon.boeyen>  
sharon.boeyen> 
sharon.boeyen> I think that when we changed all this text the last time, there were some
sharon.boeyen> voices that opposed eliminating "recognizes" from the text because that is
sharon.boeyen> the only term that was used in the 3rd edition. Perhaps there is no longer
sharon.boeyen> support for that position. Note that these changes were a result of defect
sharon.boeyen> report 244 against the 3rd edition text (resolution published in TC 2 for
sharon.boeyen> 3rd edition and integrated into 4th edition text).
sharon.boeyen> 
sharon.boeyen> Sharon
sharon.boeyen> 
sharon.boeyen>  
sharon.boeyen> 
sharon.boeyen>  
sharon.boeyen> 
sharon.boeyen> -----Original Message-----
sharon.boeyen> From: Hoyt L. Kesterson II [mailto:[e-mail]]
sharon.boeyen> Sent: Thursday, July 10, 2003 8:47 PM
sharon.boeyen> To: [e-mail]
sharon.boeyen> Subject: Re: What is mean by recognizing critical extensions ?
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> valid point. i don't see much value to considering "recognizes" as meaning
sharon.boeyen> i've heard about the extension but have no ability to process it. this
sharon.boeyen> possibly should be addressed in two places
sharon.boeyen> 
sharon.boeyen>  1) ietf agreed terminology for stating the capabilities of an
sharon.boeyen> implementation
sharon.boeyen> 
sharon.boeyen>   2) a clean-up of both ietf and iso/itu standard terminology. somewhere i
sharon.boeyen> had some additional text that i considered that stated that the
sharon.boeyen> implementation processed the extension according to the rules specified in
sharon.boeyen> the standard (old osi conformance lingo)
sharon.boeyen> 
sharon.boeyen>       hoyt
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> Hoyt,
sharon.boeyen> 
sharon.boeyen> I think the "dispute" is over the term "recognizes".  Hypothetically, an
sharon.boeyen> implementation may not have the code to "process" a given extension, but
sharon.boeyen> might claim to have the code to "recognize" the extension (and thereby hope
sharon.boeyen> to satisfy some extended compliance criteria, if erroneously).
sharon.boeyen> 
sharon.boeyen> If one defines "recognizes" IFF "possesses the code to fully process", the
sharon.boeyen> dispute disappears.  But then, the conjunction "recognizes AND is able to
sharon.boeyen> process" (highlighted below) is indeed redundant, and plausibly misleading.
sharon.boeyen> 
sharon.boeyen> Cheers!  ____tony____
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> I believe that this sentence
sharon.boeyen> 
sharon.boeyen>  When a certificate-using implementation recognizes and is able to process
sharon.boeyen> an extension, then the certificate-using implementation shall process the
sharon.boeyen> extension regardless of the value of the criticality flag.
sharon.boeyen> 
sharon.boeyen> means that if an implementation has the code to process an extension, it
sharon.boeyen> must do so. if it doesn't have the code, then it will not process an
sharon.boeyen> extension because it cannot process it. if, in that case, that extension is
sharon.boeyen> flagged critical, then it cannot use the certificate.
sharon.boeyen> 
sharon.boeyen> if anyone believe that the text says that an extension doesn't have to be
sharon.boeyen> processed even though there is an ability to process the extension, i.e. a
sharon.boeyen> belief that not being critical means that one can choose to process it or
sharon.boeyen> not, then i will recommend additional text for the standard to further
sharon.boeyen> clarify the meaning for i can see no useful result from such potential
sharon.boeyen> arbitrariness.
sharon.boeyen> 
sharon.boeyen>    hoyt
sharon.boeyen> 
sharon.boeyen> 
sharon.boeyen> Tony Bartoletti 925-422-3881 <[e-mail]>
sharon.boeyen> Information Operations and Assurance Center
sharon.boeyen> Lawrence Livermore National Laboratory
sharon.boeyen> Livermore, CA 94551-9900
sharon.boeyen> 
sharon.boeyen> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BENeqt096403 for <[e-mail]>; Fri, 11 Jul 2003 07:23:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BENekw096402 for ietf-pkix-bks; Fri, 11 Jul 2003 07:23:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BENcqt096392 for <[e-mail]>; Fri, 11 Jul 2003 07:23:38 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6BENYpi004115 for <[e-mail]>; Fri, 11 Jul 2003 07:23:34 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h6BENXs08975; Fri, 11 Jul 2003 10:23:33 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 11 Jul 2003 10:20:24 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List <[e-mail]>
Subject: Question about Certificate Issuer CRL Entry Extension
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD3C01BF60385FA55104EDA8B"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

The Certificate Issuer CRL entry extension (described in
section 5.3.4 of RFC 3280) is a GeneralNames structure
that identifies the certificate issuer for the CRL entry
to which it is attached (and also to all subsequent entries
in that CRL until another Certificate Issuer CRL entry
extension is encountered.

RFC 3280 doesn't say so, but I believe that within a PKIX
(Internet) environment (where each certificate must have a
non-empty X.500 issuer name and issuer alternative names are
generally ignored) this extension MUST always contain at
least one X.500 name so that the relying party can match
this name against the issuer name in the certificate, as
described in section 6.3.3 item (j) of RFC 3280. And I think
that text describing this requirement should be added to the
successor to RFC 3280. Does everyone agree with this?

I also wonder whether anyone can think of a reason why this
CRL entry extension should ever contain anything other than
a single X.500 name in a PKIX (Internet) environment. If not,
then the requirement can (and should) be made even more strict,
specifying that this extension MUST contain only a single X.500
name. Please let me know if you have a reason why this would not
be a good idea.

Thanks,

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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMwNzExMTQyMDI0WjAjBgkqhkiG9w0BCQQxFgQUThor5nQvEbMKYdaQ05zFZt5Q
iZQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAmiwkH
8DngxosvLqxW2NAeNn83ENeV9y7uo29ZwAKVHgtZynt1+lMBsKmUm/YJ6I8oOPu+/qtqZiIJ
3oFaVBY27rh2isiJXyVZpYeelmn/7X27YZ+Id3VyGG+98gouqAqOw/zJMHA42elpgtdR3QXn
AXxJvkpcM6rJBSgnehJCcQ==
--------------msD3C01BF60385FA55104EDA8B--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BChPqt092490 for <[e-mail]>; Fri, 11 Jul 2003 05:43:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BChPJb092489 for ietf-pkix-bks; Fri, 11 Jul 2003 05:43:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BChNqt092484 for <[e-mail]>; Fri, 11 Jul 2003 05:43:23 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V6BC33AW00120 for <[e-mail]>; Fri, 11 Jul 2003 08:39:46 -0400
Received: (qmail 13043 invoked by uid 64014); 11 Jul 2003 12:37:47 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.429505 secs); 11 Jul 2003 12:37:47 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 11 Jul 2003 12:37:46 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <3S6ZLWQB>; Fri, 11 Jul 2003 08:43:17 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Hoyt L. Kesterson II'" <[e-mail]>, [e-mail]
Subject: RE: What is mean by recognizing critical extensions ?
Date: Fri, 11 Jul 2003 08:43:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C347A9.FFC39A00"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C347A9.FFC39A00
Content-Type: text/plain

I have no objection to eliminating "recognizes" from the text if it is felt
necessary, but I also want to point out the text that is only a little bit
further down in clause 8
of X.509:
 
A validation engine has two possible actions to take with respect to an
extension:<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />

i)      it can ignore the extension and accept the certificate (all other
things being equal);

ii)     it can process the extension and accept or reject the certificate
depending on the content of the extension and the conditions under which
processing is occuring (e.g. the current values of the path processing
variables).

Some extensions can only be marked critical. In these cases a validation
engine that understands the extension, processes it and acceptance/rejection
of the certificate is dependent (at least in part) on the content of the
extension. A validation engine that does not understand the extension
rejects the certificate.

Some extensions can only be marked non-critical. In these cases a validation
engine that understands the extension processes it and acceptance/rejection
of the certificate is dependent (at least in part) on the content of the
extension. A validation engine that does not understand the extension
accepts the certificate (unless factors other than this extension cause it
to be rejected).

Some extensions can be marked critical or non-critical. In these cases a
validation engine that understands the extension processes it and
acceptance/rejection of the certificate is dependent (at least in part) on
the content of the extension, regardless of the criticality flag. A
validation engine that does not understand the extension accepts the
certificate if the extension is marked non-critical (unless factors other
than this extension cause it to be rejected) and rejects the certificate if
the extension is marked critical.

 

While I suppose it could be argued that "understands" is not much better
than "recognizes", I think the final paragraph is clearer about what a
validation engine is required to do. 

 

I think that when we changed all this text the last time, there were some
voices that opposed eliminating "recognizes" from the text because that is
the only term that was used in the 3rd edition. Perhaps there is no longer
support for that position. Note that these changes were a result of defect
report 244 against the 3rd edition text (resolution published in TC 2 for
3rd edition and integrated into 4th edition text).

Sharon

 

 

-----Original Message-----
From: Hoyt L. Kesterson II [mailto:[e-mail]]
Sent: Thursday, July 10, 2003 8:47 PM
To: [e-mail]
Subject: Re: What is mean by recognizing critical extensions ?


valid point. i don't see much value to considering "recognizes" as meaning
i've heard about the extension but have no ability to process it. this
possibly should be addressed in two places

 1) ietf agreed terminology for stating the capabilities of an
implementation

  2) a clean-up of both ietf and iso/itu standard terminology. somewhere i
had some additional text that i considered that stated that the
implementation processed the extension according to the rules specified in
the standard (old osi conformance lingo)

      hoyt



Hoyt,

I think the "dispute" is over the term "recognizes".  Hypothetically, an
implementation may not have the code to "process" a given extension, but
might claim to have the code to "recognize" the extension (and thereby hope
to satisfy some extended compliance criteria, if erroneously).

If one defines "recognizes" IFF "possesses the code to fully process", the
dispute disappears.  But then, the conjunction "recognizes AND is able to
process" (highlighted below) is indeed redundant, and plausibly misleading.

Cheers!  ____tony____


At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:


I believe that this sentence

 When a certificate-using implementation recognizes and is able to process
an extension, then the certificate-using implementation shall process the
extension regardless of the value of the criticality flag.

means that if an implementation has the code to process an extension, it
must do so. if it doesn't have the code, then it will not process an
extension because it cannot process it. if, in that case, that extension is
flagged critical, then it cannot use the certificate.

if anyone believe that the text says that an extension doesn't have to be
processed even though there is an ability to process the extension, i.e. a
belief that not being critical means that one can choose to process it or
not, then i will recommend additional text for the standard to further
clarify the meaning for i can see no useful result from such potential
arbitrariness.

   hoyt


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



------_=_NextPart_001_01C347A9.FFC39A00
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Re: What is mean by recognizing critical extensions ?</TITLE>

<STYLE type=text/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content="MSHTML 6.00.2800.1170" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=072031012-11072003><FONT face=Arial color=#0000ff size=2>I have 
no objection to eliminating "recognizes" from the text if it is felt necessary, 
but I also want to point out the text that is only a little bit further down in 
clause 8</FONT></SPAN></DIV>
<DIV><SPAN class=072031012-11072003><FONT face=Arial color=#0000ff size=2>of 
X.509:</FONT></SPAN></DIV>
<DIV><SPAN class=072031012-11072003><FONT color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=072031012-11072003><SPAN lang=EN-GB><FONT size=2>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><FONT 
face=Arial>A validation engine has two possible actions to take with respect to 
an extension:<?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></SPAN></P>
<P class=enumlev1 style="MARGIN: 4.3pt 0in 0pt 59.55pt"><SPAN lang=EN-GB><FONT 
face=Arial>i)<SPAN style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN>it can ignore the extension and accept the certificate (all other things 
being equal);<o:p></o:p></FONT></SPAN></P>
<P class=enumlev1 style="MARGIN: 4.3pt 0in 0pt 59.55pt"><SPAN lang=EN-GB><FONT 
face=Arial>ii)<SPAN style="mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>it 
can process the extension and accept or reject the certificate depending on the 
content of the extension and the conditions under which processing is occuring 
(e.g. the current values of the path processing 
variables).<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><FONT face=Arial>Some 
extensions can only be marked critical. In these cases a validation engine that 
understands the extension, processes it and acceptance/rejection of the 
certificate is dependent (at least in part) on the content of the extension. A 
validation engine that does not understand the extension rejects the 
certificate.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><FONT 
size=2><FONT face=Arial>Some extensions can only be marked non-critical. In 
these cases a validation engine that understands the extension processes it and 
acceptance/rejection of the certificate is dependent (at least in part) on the 
content of the extension. A validation engine that does not understand the 
extension accepts the certificate (unless factors other than this extension 
cause it to be rejected).<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><FONT 
face=Arial size=2>Some extensions can be marked critical or non-critical. In 
these cases a validation engine that understands the extension processes it and 
acceptance/rejection of the certificate is dependent (at least in part) on the 
content of the extension, regardless of the criticality flag. A validation 
engine that does not understand the extension accepts the certificate if the 
extension is marked non-critical (unless factors other than this extension cause 
it to be rejected) and rejects the certificate if the extension is marked 
critical.</FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><FONT 
face=Arial size=2></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><o:p><SPAN 
class=072031012-11072003><FONT face=Arial size=2>While I suppose it could be 
argued that "understands" is not much better than "recognizes", I think the 
final paragraph is clearer about what a validation engine is required to do. 
</FONT></SPAN></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><o:p><SPAN 
class=072031012-11072003><FONT face=Arial 
size=2></FONT></SPAN></o:p></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><o:p><SPAN 
class=072031012-11072003><FONT face=Arial size=2>I think that when we changed 
all this text the last time, there were some voices that opposed eliminating 
"recognizes" from the text because that is the only term that was used in the 
3rd edition. Perhaps there is no longer support for that position. Note that 
these changes were a result of defect report 244 against the 3rd edition text 
(resolution published in TC 2 for 3rd edition and integrated into 4th edition 
text).</FONT></SPAN></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><o:p><SPAN 
class=072031012-11072003><FONT face=Arial 
size=2>Sharon</FONT></SPAN></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><o:p><SPAN 
class=072031012-11072003><FONT face=Arial 
size=2></FONT></SPAN></o:p></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 6.8pt 0in 0pt"><SPAN lang=EN-GB><o:p><SPAN 
class=072031012-11072003><FONT 
size=2></FONT></SPAN></o:p></SPAN>&nbsp;</P></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hoyt L. Kesterson II 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, July 10, 2003 
  8:47 PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Re: What is mean by 
  recognizing critical extensions ?<BR><BR></FONT></DIV>
  <DIV>valid point. i don't see much value to considering "recognizes" as 
  meaning i've heard about the extension but have no ability to process it. this 
  possibly should be addressed in two places</DIV>
  <DIV><BR></DIV>
  <DIV>&nbsp;1) ietf agreed terminology for stating the capabilities of an 
  implementation</DIV>
  <DIV><BR></DIV>
  <DIV>&nbsp; 2) a clean-up of both ietf and iso/itu standard terminology. 
  somewhere i had some additional text that i considered that stated that the 
  implementation processed the extension according to the rules specified in the 
  standard (old osi conformance lingo)</DIV>
  <DIV><BR></DIV>
  <DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hoyt</DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite="" type="cite">Hoyt,<BR><BR>I think the "dispute" is over 
    the term "recognizes".&nbsp; Hypothetically, an implementation may not have 
    the code to "process" a given extension, but might claim to have the code to 
    "recognize" the extension (and thereby hope to satisfy some extended 
    compliance criteria, if erroneously).<BR><BR>If one defines "recognizes" IFF 
    "possesses the code to fully process", the dispute disappears.&nbsp; But 
    then, the conjunction "recognizes AND is able to process" (highlighted 
    below) is indeed redundant, and plausibly misleading.<BR><BR>Cheers!&nbsp; 
    ____tony____<BR><BR><BR>At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II 
    wrote:<BR>
    <BLOCKQUOTE cite="" type="cite">I believe that this sentence<BR><BR><FONT 
      face="Times New Roman" size=+1>&nbsp;When a certificate-using 
      implementation<B> recognizes and is able to process</B> an extension, then 
      the certificate-using implementation shall process the extension 
      regardless of the value of the criticality flag.</FONT><BR><BR>means that 
      if an implementation has the code to process an extension, it must do so. 
      if it doesn't have the code, then it will not process an extension because 
      it cannot process it. if, in that case, that extension is flagged 
      critical, then it cannot use the certificate.<BR><BR>if anyone believe 
      that the text says that an extension doesn't have to be processed even 
      though there is an ability to process the extension, i.e. a belief that 
      not being critical means that one can choose to process it or not, then i 
      will recommend additional text for the standard to further clarify the 
      meaning for i can see no useful result from such potential 
      arbitrariness.<BR><BR>&nbsp;&nbsp; hoyt<BR></BLOCKQUOTE></BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">Tony Bartoletti 925-422-3881 
    &lt;[e-mail]&gt;<BR>Information Operations and Assurance 
    Center<BR>Lawrence Livermore National Laboratory<BR>Livermore, CA 
  94551-9900</BLOCKQUOTE>
  <DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C347A9.FFC39A00--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BC39qt089160 for <[e-mail]>; Fri, 11 Jul 2003 05:03:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6BC39Ft089159 for ietf-pkix-bks; Fri, 11 Jul 2003 05:03:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6BC38qt089151 for <[e-mail]>; Fri, 11 Jul 2003 05:03:08 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6BC380C029686; Fri, 11 Jul 2003 06:03:08 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h6BC37s13061; Fri, 11 Jul 2003 08:03:07 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 11 Jul 2003 07:59:57 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'PKIX List'" <[e-mail]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
References: <006d01c34740$17fde4a0$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms036ECB52D38380147F10C852"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Santosh Chokhani wrote:
> Would some empirical statistics of real-world cross certified
> PKI against what the RFC says and what other ways Steve has
> in mind help?

Yes, real-world statistics will definitely be useful.
They will help us determine which path building techniques
are most effective. We should also test path builders
against real-world PKIs (cross-certified and not).

However, I suspect that cross-certified PKIs are still
in their infancy. We may need to test against some
hypothetical PKIs that represent what future PKIs may
look like.

I'll note also that while I agree that real-world testing
and statistics are essential, I don't think they will
result in an instantaneous maturation of our understanding
of path building. That will take time and experience.

Thanks,

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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMwNzExMTE1OTU3WjAjBgkqhkiG9w0BCQQxFgQUnC5EkddaMoOq88KfsbmE6cm1
0CAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCaOuMR
QK+Q0Mg7fBlywC6McoRZhBnvQ+4el5fb/+3BdtCtRKb+pdJgXRHEa8ociy9SoRXvIPaUoYVz
eoIoH8rGJeqUbEiHPDStmhhNWCEdrH8G/SuxfKHjfIBK8RmLDIAKT+JrjRoTSZeFCAt7pjPS
XYo44UIqKV4f4jCsr7Oa/g==
--------------ms036ECB52D38380147F10C852--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6B10lqt026500 for <[e-mail]>; Thu, 10 Jul 2003 18:00:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6B10leG026499 for ietf-pkix-bks; Thu, 10 Jul 2003 18:00:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mpls-qmqp-01.inet.qwest.net (mpls-qmqp-01.inet.qwest.net [63.231.195.112]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6B10kqt026493 for <[e-mail]>; Thu, 10 Jul 2003 18:00:46 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 51759 invoked by uid 0); 11 Jul 2003 01:00:48 -0000
Received: from unknown (63.231.195.1) by mpls-qmqp-01.inet.qwest.net with QMQP; 11 Jul 2003 01:00:48 -0000
Received: from vdsl-130-13-127-251.phnx.uswest.net (HELO ?192.168.2.7?) (130.13.127.251) by mpls-pop-01.inet.qwest.net with SMTP; 11 Jul 2003 01:00:48 -0000
Date: Thu, 10 Jul 2003 17:46:38 -0700
Message-Id: <a0521060bbb33b6e4bba1@[192.168.2.7]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
X-Sender: [e-mail]@mail.earthlink.net
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail] v.microsoft.com> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: What is mean by recognizing critical extensions ?
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: What is mean by recognizing critical extensions
?</title></head><body>
<div>valid point. i don't see much value to considering
&quot;recognizes&quot; as meaning i've heard about the extension but
have no ability to process it. this possibly should be addressed in
two places</div>
<div><br></div>
<div>&nbsp;1) ietf agreed terminology for stating the capabilities of
an implementation</div>
<div><br></div>
<div>&nbsp; 2) a clean-up of both ietf and iso/itu standard
terminology. somewhere i had some additional text that i considered
that stated that the implementation processed the extension according
to the rules specified in the standard (old osi conformance
lingo)</div>
<div><br></div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>Hoyt,<br>
<br>
I think the &quot;dispute&quot; is over the term
&quot;recognizes&quot;.&nbsp; Hypothetically, an implementation may
not have the code to &quot;process&quot; a given extension, but might
claim to have the code to &quot;recognize&quot; the extension (and
thereby hope to satisfy some extended compliance criteria, if
erroneously).<br>
<br>
If one defines &quot;recognizes&quot; IFF &quot;possesses the code to
fully process&quot;, the dispute disappears.&nbsp; But then, the
conjunction &quot;recognizes AND is able to process&quot; (highlighted
below) is indeed redundant, and plausibly misleading.<br>
<br>
Cheers!&nbsp; ____tony____<br>
<br>
<br>
At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:<br>
<blockquote type="cite" cite>I believe that this sentence<br>
<br>
<font face="Times New Roman" size="+1">&nbsp;When a certificate-using
implementation<b> recognizes and is able to process</b> an extension,
then the certificate-using implementation shall process the extension
regardless of the value of the criticality flag.</font><br>
<br>
means that if an implementation has the code to process an extension,
it must do so. if it doesn't have the code, then it will not process
an extension because it cannot process it. if, in that case, that
extension is flagged critical, then it cannot use the certificate.<br>
<br>
if anyone believe that the text says that an extension doesn't have to
be processed even though there is an ability to process the extension,
i.e. a belief that not being critical means that one can choose to
process it or not, then i will recommend additional text for the
standard to further clarify the meaning for i can see no useful result
from such potential arbitrariness.<br>
<br>
&nbsp;&nbsp; hoyt<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>Tony Bartoletti 925-422-3881
&lt;[e-mail]&gt;<br>
Information Operations and Assurance Center<br>
Lawrence Livermore National Laboratory<br>
Livermore, CA 94551-9900</blockquote>
<div><br></div>
</body>
</html>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6B0IJqt025515 for <[e-mail]>; Thu, 10 Jul 2003 17:18:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6B0IJDq025514 for ietf-pkix-bks; Thu, 10 Jul 2003 17:18:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6B0IIqt025508 for <[e-mail]>; Thu, 10 Jul 2003 17:18:18 -0700 (PDT) (envelope-from [e-mail])
Received: from catalyst2b.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.12.3/8.12.3/LLNL evision: 1.3 $) with ESMTP id h6B0IBl3013183; Thu, 10 Jul 2003 17:18:12 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 10 Jul 2003 17:18:33 -0700
To: "Hoyt L. Kesterson II" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: What is mean by recognizing critical extensions ?
In-Reply-To: <a05210608bb339010a1e7@[192.168.2.7]>
References: <[e-mail]> <[e-mail]> <[e-mail] v.microsoft.com> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
Hoyt,<br>
<br>
I think the &quot;dispute&quot; is over the term
&quot;recognizes&quot;.&nbsp; Hypothetically, an implementation may not
have the code to &quot;process&quot; a given extension, but might claim
to have the code to &quot;recognize&quot; the extension (and thereby hope
to satisfy some extended compliance criteria, if erroneously).<br>
<br>
If one defines &quot;recognizes&quot; IFF &quot;possesses the code to
fully process&quot;, the dispute disappears.&nbsp; But then, the
conjunction &quot;recognizes AND is able to process&quot; (highlighted
below) is indeed redundant, and plausibly misleading.<br>
<br>
Cheers!&nbsp; ____tony____<br>
<br>
<br>
At 02:59 PM 7/10/2003 -0700, Hoyt L. Kesterson II wrote:<br>
<blockquote type=cite class=cite cite>I believe that this sentence<br>
<br>
<font face="Times New Roman, Times" size=4>&nbsp;When a certificate-using
implementation<b> recognizes and is able to process</b> an extension,
then the certificate-using implementation shall process the extension
regardless of the value of the criticality flag.</font><br>
<br>
means that if an implementation has the code to process an extension, it
must do so. if it doesn't have the code, then it will not process an
extension because it cannot process it. if, in that case, that extension
is flagged critical, then it cannot use the certificate.<br>
<br>
if anyone believe that the text says that an extension doesn't have to be
processed even though there is an ability to process the extension, i.e.
a belief that not being critical means that one can choose to process it
or not, then i will recommend additional text for the standard to further
clarify the meaning for i can see no useful result from such potential
arbitrariness.<br>
<br>
&nbsp;&nbsp; hoyt</blockquote>
<x-sigsep><p></x-sigsep>
Tony Bartoletti 925-422-3881 &lt;[e-mail]&gt; <br>
Information Operations and Assurance Center <br>
Lawrence Livermore National Laboratory <br>
Livermore, CA 94551-9900<br>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6B059qt025109 for <[e-mail]>; Thu, 10 Jul 2003 17:05:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6B059Ac025108 for ietf-pkix-bks; Thu, 10 Jul 2003 17:05:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6B058qt025103 for <[e-mail]>; Thu, 10 Jul 2003 17:05:08 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h6B059J6028771; Thu, 10 Jul 2003 20:05:09 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, "'PKIX List'" <[e-mail]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 10 Jul 2003 20:05:04 -0400
MIME-Version: 1.0
Message-ID: <006d01c34740$17fde4a0$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0069_01C3471E.8D1D3B40"
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0069_01C3471E.8D1D3B40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve and Matt:

Would some empirical statistics of real-world cross certified PKI against
what the RFC says and what other ways Steve has in mind help?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Steve Hanna
Sent: Thursday, July 10, 2003 3:30 PM
To: PKIX List
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt


I'm glad to see more discussions of certificate path
building. In a non-hierarchical PKI where relying parties
have different trust anchors, path building is essential.
And it's not easy!

However, I don't think that we're ready to have an
official 'best practices' document on path building yet.
Very few people have implemented PKIX-compliant path
building (only Sun and Cygnacom/DigitalNet, I think) and
there are many areas that are still unclear. For instance,
is it better to do a Depth First Search with ranking or
to rank all candidate certificates? Which ranking
heuristics work best in which environments? Is it possible
for software to dynamically adapt to the PKI topology
without requiring configuration? And what are the
performance bottlenecks and best workarounds in
real-world deployments? The I-D just published presents
one early perspective on these questions, not a consensus.

For now, I suggest that people who have implemented path building publish
their insights, results, and ideas either as individual I-Ds without the
intent to become an RFC or as research papers. Then we can discuss these
results and ideas, test them in real-world scenarios, and arrive at a
consensus on what Best Current Practices should be included in a BCP
document on this topic. We might even want to start an IRTF research group
or an informal discussion group to coordinate this research, sift through
the results, and arrive at a solid and well-supported consensus. This
effort will take some time, but I expect it will produce much better
results.

If it's felt that we really need a BCP on this topic in
short order, then I think it should be restricted to things that we are
fairly sure are good practices (like advising CAs to include name
constraints and AIA in certificates to help path building and advising
path builders to ensure that they handle simple hierarchical PKIs quickly
but still handle complex PKIs properly).

Thanks,

Steve

-------- Original Message --------
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 03 Jul 2003 11:32:03 -0400
From: [e-mail]
Reply-To: [e-mail]
To: IETF-Announce:;
CC: [e-mail]

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:
                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow
	Filename	: draft-ietf-pkix-certpathbuild-00.txt
	Pages		: 59
	Date		: 2003-7-3

This document was written to provide 'best practice' guidance and
recommendations to developers building X.509 public-key certification
paths within their applications.  By following the guidance and
recommendations defined in this document, an application developer is
more likely to develop a robust X.509 certificate enabled application
that can build valid certification paths across a wide range of PKI
environments.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certpathbuild-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_000_0069_01C3471E.8D1D3B40
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQxzCCA5sw
ggKDoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9u
IFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMTDU9yaW9uIFJvb3QgQ0Ew
HhcNMDMwNjA1MTQyODQyWhcNMTMwNjAyMTQyODQyWjBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY
T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9v
dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd3fg/nIELr3rAuxpkcxiAn7ayU
/30RPxYBMgcvn0BJbBXBXIkTHgm3jh0TwHGQk76nqTSo1fUqpkkEcSSwEtfz1jF0QCKPHoQvNxza
5ffqH2gBSTgjpwqLA34RDxFDwcdNibIG/s6Zj2PpVDDWVBYxMbLrhKluMAfufhOMT6uyYxw+XPcU
ndqy4bRo08BONIoLdoUoOsvOwHla+zPYsBnTncMEL26lnKgCQgJpcFfrQRLrM84Rlc9EmvPbU+tO
5jRfdnvJpCm8LbIcTvAwQLiM+5qr4GPTg73S+9ZMAjlaZWG/VGe5b+KtQCgDu2TPB+wtiz2csG5q
YN14mFpKMdMCAwEAAaN2MHQwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0O
BBYEFL6aKnkebaR/htm59T9Oi6Bx/TKtMB8GA1UdIwQYMBaAFL6aKnkebaR/htm59T9Oi6Bx/TKt
MBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQUFAAOCAQEAQzMteZHn/soQjPFxQxN9o2vO
NWSeql+/NniUs5ePMtuejgzB8BTstAq8co6KsafqWgs69PSKzHAZlcvwEFtixNGXaTi+uDEuLM/y
oTQQjNX1RdtzfRFtbhhxyHmfpU9XgnC/7I/xyhkNCicxBHJFN6hcq3kJFFchH/rw/uon0sf6U3NW
eEtzGtXCwqqoLpwCfH2QbAgu/vtCCNGj+K9Ej2RlCUuaEwNPrXvJEARSpe24ZEPzOCoS5PEt9LmF
atDnC5ZRw5oruM5HnfRTE2EnHoA4SK34VNqae8ieR/s1sKxHCLEOyE/XyrydnFIdT8EXnwgdStiB
W0e6HUml9I94YzCCA9owggLCoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMx
ITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMT
DU9yaW9uIFJvb3QgQ0EwHhcNMDMwNjA1MTQyODU5WhcNMDQwNjA0MTQyODU5WjBWMQswCQYDVQQG
EwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUG
A1UEAxMOT3Jpb24gRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+uWjO
SEkmdREWiIxGgQ72SflNYhBL3S6CC5JrsM6qzdAzDYQcC1DyUmIxmesZRhObEZg21HBYUV9A7af7
dJSgZdM2o6rj0Wzubd8IaoW9IeSICET9fTTmfTKP11jC9nglZg8supaiuTQvlL3YX/Eo4x/j9lgp
OvCphC36l0nx6CsvYCjBB/SBci9RKmxPA01LhZlM4N2SKUfVDF9GKK8eGHUEcm5R+HxFAzX1Ljx7
0U2ZMnwJvJ66bFgqjmNEN1ZejrHzKgWlWDjkQPXwzy2S172HOyJtyw0wF78vg05ItnEd64y6zvqd
zzh/0qB/P/Xh4TZOH1/8OBb0DL/YSKJxAgMBAAGjgbMwgbAwEgYDVR0TAQH/BAgwBgEB/wIBADAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFPjb0mg9Eoh2AfUJIKpSuJ/nxQChMB8GA1UdIwQYMBaA
FL6aKnkebaR/htm59T9Oi6Bx/TKtMBEGCWCGSAGG+EIBAQQEAwIABzA3BgNVHR8EMDAuMCygKqAo
hiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9yb290LmNybDANBgkqhkiG9w0BAQUFAAOC
AQEAsYKdLb/O41HI1vzfKfhYBZ+vrwWUPNA4bS0mH4tShgYEJ5I15NXYK+sz4gbX6MP3slwp+wtp
BKySMMF2zb/d7Ozd57aYIewzA/QOiOvcyk3jL85+CtkgkO9fLB4ZPZkynHiI+46Axuime5cNgjoh
cf6BFHoUReoutNbvYfJhyeRz6aAA/kMswR35Jjep47pS2JmOVvKJl0ZeHz2XVrt0zUT3psWPOfT6
2Yqq1Y6IKlzh+3HgbbZENT54y8WVdDyoMogIc4AcFn/nZI1sajSbcCYxi57Zvr1WKU217smOt1ON
a8xHJBjTlnTKEfM8LqUxpk9Y+XDV5HHBhMaap39qWzCCBJEwggN5oAMCAQICAQgwDQYJKoZIhvcN
AQEFBQAwVjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEL
MAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBMB4XDTAzMDYwNTIxMDE1NloXDTA0
MDYwNDIxMDE1NlowfjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0
aW9uczELMAkGA1UECxMCSFExGTAXBgNVBAMTEFNhbnRvc2ggQ2hva2hhbmkxJDAiBgkqhkiG9w0B
CQEWFWNob2toYW5pQG9yaW9uc2VjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANBGnaG75lsgtVG7RLqLPA5hCu77JO9s91EhXODBeCO9XLWrE7k+593mNEbFyuTUqxjbn8MLqe5L
HWQKP2uhj8YhjAzmkLSYvFWgAsz1Mqs2WSRCrWqJXA+H0vFejhcgXTJnTAXm3dBq3DVZmm74FSJt
4eTnt7FM2capHbrngJIzLLRpwbVFhuN9R8zN7zk85Gx85DKDUxYDBGsoR65JcnnL3hzoIqoTsqQI
ikr+WnDNr4M63oeYGxxCX6jn0uevnsUwM/zK6Xc715r9JJq8DATrUzNazmIco8NsszNO5QcbLQTE
dAyHqqX9nWTdSBzp5xlsUqqpdhnY5/W6aZVTdhECAwEAAaOCAUAwggE8MBgGA1UdIAQRMA8wDQYL
YIZIAYb4AgMCAQAwHQYDVR0OBBYEFPQLCXgNtykUjPyCwMO9MWrT0A86MB8GA1UdIwQYMBaAFPjb
0mg9Eoh2AfUJIKpSuJ/nxQChMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMu
Y29tL29yaW9uX21haWwuY3JsMAkGA1UdEwQCMAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAC
hiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBDAw
EwYDVR0lBAwwCgYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgAHMCAGA1UdEQQZMBeBFWNob2to
YW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAFy0Oc6J5qW4gzM3leQP7LBmNOsfb
cS2UMmn8YTrid5co3/z1onBXP3mEt5z/AVppjgvGVeher6xrxuyOHGjs/X0W6R61yYf2UXrr7BNn
5NXLBr18ncZ8PZech6syvHs+KLveVMjX8bymUU2GvbCfJc54aZQxhAV3bWMJE0myryLRxtiRjyAb
7i2RXG0sewLIPU5svoNIr8Uu5ect5n4VDMZ/0rrO6MZl3NJ9MXfFwN06zcNw5XSvic7sK+YHUGm5
Ntpj/blmOkcBIMqn/wwU5D9CeR0qqEAXLdjkLbJFUUPmK7zr1EWM7A7BrTliYTr5UW2c/kC3kWct
hwkIYlqApjCCBLEwggOZoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxITAf
BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9y
aW9uIEVtYWlsIENBMB4XDTAzMDYwNTIxMDEzOFoXDTA0MDYwNDIxMDEzOFowfjELMAkGA1UEBhMC
VVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExGTAXBgNV
BAMTEFNhbnRvc2ggQ2hva2hhbmkxJDAiBgkqhkiG9w0BCQEWFWNob2toYW5pQG9yaW9uc2VjLmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMLUZwZhoWYVw7zKNe5KLxQfXo0dKMKk
ph9MA+fNX9YPW/LEbsjqdofCRJ1F8VZalpBrlz61ITyJ7/y+W1My0n0oOJhwvdhqRxE2QUv+bOP8
0i7BGqIm4/wd35ZyABDG2mt5Jj2anwXUIK1KENCo1pYxhroil3qLhtd9xPiOOjUZ2wAmNEgFwxDc
QE1xsNJtJ3Ro1O3VfceF53AxomEIZM300usixqnUSKbk8D8oVwUNBnMXdj+7K/0G/YJ9EPJFF5or
wI1j9LE3tdWBVY9a7WY1+ygHDMXaeYAnM2TkAuVGtWqTHTGmdNuyxsapFY7UFLtRjItA2oFb3bs/
ho1tKrUCAwEAAaOCAWAwggFcMBgGA1UdIAQRMA8wDQYLYIZIAYb4AgMCAQAwHQYDVR0OBBYEFBKj
QVpvrGnBnkHERGgS5SKCv83bMB8GA1UdIwQYMBaAFPjb0mg9Eoh2AfUJIKpSuJ/nxQChMDcGA1Ud
HwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX21haWwuY3JsMAkGA1Ud
EwQCMAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAChiZodHRwOi8vd3d3Lm9yaW9uc2VjLmNv
bS9vcmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBsAwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsG
AQUFBwMEBggrBgEFBQcDBwYKKwYBBAGCNxQCAjARBglghkgBhvhCAQEEBAMCAAcwIAYDVR0RBBkw
F4EVY2hva2hhbmlAb3Jpb25zZWMuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQC4JnPdbSyJu53/lKZy
AG3pkMb6jh0dZ5PUn/NR1MjqwAmb/Dy4fpg+9/SiAVAsruUDaLY4AoWwefdIvhF2XVzlHa+7eTmx
4ppKQlpyEmTfJ5BMddYAeTVhiaRO6qVfTEjCgmqGs+fHNZxROLGFA4Dz+SgtNj1vc+uV1ZVCxSGr
mcr/QZYHHERadCgATyejmcCLlxfAMQMMsmNQUKQVrsrPzcyCI/CsXEIKj4+iRmpRi+3lbflTocG0
D96cSP3wW6G9jKW45kWn8RtKiSrpzlYEyBixJkhWhJ92WV11MGIOfaJtbU5aDNppp3OueDHu8g+R
EVxkMO2TkqBj+9Kr6UetMYIDJjCCAyICAQEwWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jp
b24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwg
Q0ECAQcwCQYFKw4DAhoFAKCCAaAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMwNzExMDAwNTAzWjAjBgkqhkiG9w0BCQQxFgQUQ3yAIBCllynN1MdGRlrufnnz3K0w
ZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC
AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwagYJKwYBBAGC
NxAEMV0wWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25z
MQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0ECAQgwbAYLKoZIhvcNAQkQAgsx
XaBbMFYxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxCzAJ
BgNVBAsTAkhRMRcwFQYDVQQDEw5PcmlvbiBFbWFpbCBDQQIBCDANBgkqhkiG9w0BAQEFAASCAQB5
wXcjCxbdMbBWVYVZlvZAW7nR4MRGvK9xbgI5LaKYtufYojuFSWEmQO+1PVw1ox0m0bFwTizfsEO3
04Zc6d5V1c4OUlgEIDFvVz9TzVIRHEbClwEKzPpw2xZAVpRUACG1j4sMRhP7gMuuwS8jREeBz7KK
OWVtLB2FS/oSOhEDHXzKigpT2+ym5qH7w6PAzL/tHM+dhSvTUcDnHKxeQ80fnBoADYESmekN+OOq
YjNt7rGBY7h71niTdUH3/N/rzMCFCMyzkox73GjjLLZGU5NiLFLPC/tyvqIazXyoIM73W7LbrvL2
IRjGd+Z7EiEBpQGaqz9d8mUaNK7MWWX+xfKvAAAAAAAA

------=_NextPart_000_0069_01C3471E.8D1D3B40--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6AM0qqt019772 for <[e-mail]>; Thu, 10 Jul 2003 15:00:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6AM0qAe019771 for ietf-pkix-bks; Thu, 10 Jul 2003 15:00:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mpls-qmqp-02.inet.qwest.net (mpls-qmqp-02.inet.qwest.net [63.231.195.113]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6AM0oqt019763 for <[e-mail]>; Thu, 10 Jul 2003 15:00:51 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 20929 invoked by uid 0); 10 Jul 2003 21:27:56 -0000
Received: from mpls-pop-10.inet.qwest.net (63.231.195.10) by mpls-qmqp-02.inet.qwest.net with QMQP; 10 Jul 2003 21:27:56 -0000
Received: from vdsl-130-13-127-251.phnx.uswest.net (HELO ?192.168.2.7?) (130.13.127.251) by mpls-pop-10.inet.qwest.net with SMTP; 10 Jul 2003 22:00:52 -0000
Date: Thu, 10 Jul 2003 14:59:26 -0700
Message-Id: <a05210608bb339010a1e7@[192.168.2.7]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
X-Sender: [e-mail]@mail.earthlink.net
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail] v.microsoft.com> <[e-mail]> <[e-mail]>
Subject: Re: What is mean by recognizing critical extensions ?
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: What is mean by recognizing critical extensions
?</title></head><body>
<div>I believe that this sentence</div>
<div><br></div>
<div><font face="Times New Roman" size="+1">&nbsp;When a
certificate-using implementation<b> recognizes and is able to
process</b> an extension, then the certificate-using implementation
shall process the extension regardless of the value of the criticality
flag.</font></div>
<div><br></div>
<div>means that if an implementation has the code to process an
extension, it must do so. if it doesn't have the code, then it will
not process an extension because it cannot process it. if, in that
case, that extension is flagged critical, then it cannot use the
certificate.</div>
<div><br></div>
<div>if anyone believe that the text says that an extension doesn't
have to be processed even though there is an ability to process the
extension, i.e. a belief that not being critical means that one can
choose to process it or not, then i will recommend additional text for
the standard to further clarify the meaning for i can see no useful
result from such potential arbitrariness.</div>
<div><br></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>At 10:14 PM 7/9/2003 -0700, Hoyt L.
Kesterson II wrote:<br>
<blockquote type="cite" cite>At 10:31 -0400 7/8/03, David A. Cooper
wrote:<br>
<br>
as we were finishing up the 4th edition sharon boeyen reported to our
group that some implementors were using an interesting interpretation
of &quot;recognizing an extension&quot;. apparently their recognition
essentially meant that they recognized the oid and recognized that the
extension was defined but did not process it, i.e wrote no code to
process the extension as defined in the standard. to counter this
specious argument we wrote some additional text for clause 7<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
[snip]<br>
<blockquote type="cite" cite>the 4th edition has this replacement
paragraph (as well as additional paragraphs)<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
[snip]<br>
<blockquote type="cite" cite><font face="Times New Roman"
size="+1">therein. When an implementation processing a certificate
does not recognize an extension, if the criticality flag
is</font><font face="Arial" size="+1"><b> FALSE</b></font><font
face="Times New Roman" size="+1">, it may ignore that extension. If
the criticality flag is</font><font face="Arial" size="+1"><b>
TRUE</b></font><font face="Times New Roman" size="+1">, unrecognized
extensions shall cause the structure to be considered invalid, i.e. in
a certificate, an unrecognized critical extension would cause
validation of a signature using that certificate to fail. When a
certificate-using implementation<b> recognizes and is able to
process</b> an extension, then the certificate-using implementation
shall process the extension regardless of the value of the criticality
flag. Note that any extension that is flagged non-critical will cause
inconsistent behaviour between certificate-using systems that will
process the extension and certificate-using systems that do not
recognize the extension and will ignore it.</font>&quot;<br>
<br>
note the penultimate sentence.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>Indeed.&nbsp; This clearly implies that
non-critical extensions &quot;may or may not&quot; be processed.<br>
<br>
Moreover, additional confusion is engendered by the phrase<br>
<br>
&nbsp;&nbsp;&nbsp; &quot;recognizes and is able to process&quot;.<br>
<br>
Perhaps this is a redundant conjunction, but logically it implies that
&quot;recognizes&quot; and &quot;is able to process&quot; are distinct
conditions (else, why the conjunction?)<br>
<br>
Thus, for non-critical extensions, one has THREE cases:<br>
<br>
1.&nbsp; Does not recognize (may or may not validate certificate, up
to implementation)<br>
<br>
2.&nbsp; &quot;Recognizes&quot;, but cannot process (same result as in
1.)<br>
<br>
3.&nbsp; Recognizes and CAN process (MUST process to determine
validity.)<br>
<br>
If the intent is to use the term &quot;recognizes&quot; to mean
&quot;can process&quot;, then the condition &quot;recognizes and can
process&quot; adds to the confusion.<br>
<br>
Cheers!&nbsp; ____tony____<br>
<br>
Tony Bartoletti 925-422-3881 &lt;[e-mail]&gt;<br>
Information Operations and Assurance Center<br>
Lawrence Livermore National Laboratory<br>
Livermore, CA 94551-9900</blockquote>
<div><br></div>
</body>
</html>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6AKt6qt016305 for <[e-mail]>; Thu, 10 Jul 2003 13:55:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6AKt5OC016304 for ietf-pkix-bks; Thu, 10 Jul 2003 13:55:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6AKt5qt016292 for <[e-mail]>; Thu, 10 Jul 2003 13:55:05 -0700 (PDT) (envelope-from [e-mail])
Received: from catalyst2b.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.12.3/8.12.3/LLNL evision: 1.6 $) with ESMTP id h6AKt0eQ001605 for <[e-mail]>; Thu, 10 Jul 2003 13:55:01 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 10 Jul 2003 13:55:22 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: What is mean by recognizing critical extensions ?
In-Reply-To: <a05210601bb329cb000b2@[192.168.2.7]>
References: <[e-mail]> <[e-mail] v.microsoft.com> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
At 10:14 PM 7/9/2003 -0700, Hoyt L. Kesterson II wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>At 10:31 -0400 7/8/03, David A.
Cooper wrote:<br>
<br>
as we were finishing up the 4th edition sharon boeyen reported to our
group that some implementors were using an interesting interpretation of
&quot;recognizing an extension&quot;. apparently their recognition
essentially meant that they recognized the oid and recognized that the
extension was defined but did not process it, i.e wrote no code to
process the extension as defined in the standard. to counter this
specious argument we wrote some additional text for clause 7<br>
</blockquote><br>
[snip]<br>
<br>
<blockquote type=3Dcite class=3Dcite cite>the 4th edition has this
replacement paragraph (as well as additional
paragraphs)</blockquote><br>
[snip]<br>
<br>
<blockquote type=3Dcite class=3Dcite cite><font face=3D"Times New Roman,=
 Times" size=3D4>therein.
When an implementation processing a certificate does not recognize an
extension, if the criticality flag
is</font><font face=3D"Arial, Helvetica" size=3D4><b>
FALSE</b></font><font face=3D"Times New Roman, Times" size=3D4>, it may
ignore that extension. If the criticality flag
is</font><font face=3D"Arial, Helvetica" size=3D4><b>
TRUE</b></font><font face=3D"Times New Roman, Times" size=3D4>, unrecognized
extensions shall cause the structure to be considered invalid, i.e. in a
certificate, an unrecognized critical extension would cause validation of
a signature using that certificate to fail. When a certificate-using
implementation <b>recognizes and is able to process</b> an extension,
then the certificate-using implementation shall process the extension
regardless of the value of the criticality flag. Note that any extension
that is flagged non-critical will cause inconsistent behaviour between
certificate-using systems that will process the extension and
certificate-using systems that do not recognize the extension and will
ignore it.</font>&quot;<br>
<br>
note the penultimate sentence.</blockquote>
<x-sigsep><p></x-sigsep>
Indeed.&nbsp; This clearly implies that non-critical extensions &quot;may
or may not&quot; be processed.<br>
<br>
Moreover, additional confusion is engendered by the phrase<br>
<br>
&nbsp;&nbsp;&nbsp; &quot;recognizes and is able to process&quot;.<br>
<br>
Perhaps this is a redundant conjunction, but logically it implies that
&quot;recognizes&quot; and &quot;is able to process&quot; are distinct
conditions (else, why the conjunction?)<br>
<br>
Thus, for non-critical extensions, one has THREE cases:<br>
<br>
1.&nbsp; Does not recognize (may or may not validate certificate, up to
implementation)<br>
<br>
2.&nbsp; &quot;Recognizes&quot;, but cannot process (same result as in
1.)<br>
<br>
3.&nbsp; Recognizes and CAN process (MUST process to determine
validity.)<br>
<br>
If the intent is to use the term &quot;recognizes&quot; to mean &quot;can
process&quot;, then the condition &quot;recognizes and can process&quot;
adds to the confusion.<br>
<br>
Cheers!&nbsp; ____tony____<br>
<br>
Tony Bartoletti 925-422-3881 &lt;[e-mail]&gt; <br>
Information Operations and Assurance Center <br>
Lawrence Livermore National Laboratory <br>
Livermore, CA 94551-9900<br>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6AJX8qt013275 for <[e-mail]>; Thu, 10 Jul 2003 12:33:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6AJX8JH013274 for ietf-pkix-bks; Thu, 10 Jul 2003 12:33:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6AJX6qt013269 for <[e-mail]>; Thu, 10 Jul 2003 12:33:07 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6AJX8c8029343 for <[e-mail]>; Thu, 10 Jul 2003 13:33:08 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h6AJX7s00398; Thu, 10 Jul 2003 15:33:07 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 10 Jul 2003 15:29:58 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List <[e-mail]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4B7902436081545849902AA0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms4B7902436081545849902AA0
Content-Type: multipart/mixed;
 boundary="------------3EB6208E1C918044D629D703"

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

I'm glad to see more discussions of certificate path
building. In a non-hierarchical PKI where relying parties
have different trust anchors, path building is essential.
And it's not easy!

However, I don't think that we're ready to have an
official 'best practices' document on path building yet.
Very few people have implemented PKIX-compliant path
building (only Sun and Cygnacom/DigitalNet, I think) and
there are many areas that are still unclear. For instance,
is it better to do a Depth First Search with ranking or
to rank all candidate certificates? Which ranking
heuristics work best in which environments? Is it possible
for software to dynamically adapt to the PKI topology
without requiring configuration? And what are the
performance bottlenecks and best workarounds in
real-world deployments? The I-D just published presents
one early perspective on these questions, not a consensus.

For now, I suggest that people who have implemented path
building publish their insights, results, and ideas either
as individual I-Ds without the intent to become an RFC or
as research papers. Then we can discuss these results and
ideas, test them in real-world scenarios, and arrive at a
consensus on what Best Current Practices should be included
in a BCP document on this topic. We might even want to
start an IRTF research group or an informal discussion group
to coordinate this research, sift through the results, and
arrive at a solid and well-supported consensus. This effort
will take some time, but I expect it will produce much better
results.

If it's felt that we really need a BCP on this topic in
short order, then I think it should be restricted to things
that we are fairly sure are good practices (like advising
CAs to include name constraints and AIA in certificates to
help path building and advising path builders to ensure
that they handle simple hierarchical PKIs quickly but still
handle complex PKIs properly).

Thanks,

Steve

-------- Original Message --------
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 03 Jul 2003 11:32:03 -0400
From: [e-mail]
Reply-To: [e-mail]
To: IETF-Announce:;
CC: [e-mail]

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:       
                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow
	Filename	: draft-ietf-pkix-certpathbuild-00.txt
	Pages		: 59
	Date		: 2003-7-3
	
This document was written to provide 'best practice' guidance and 
recommendations to developers building X.509 public-key certification 
paths within their applications.  By following the guidance and 
recommendations defined in this document, an application developer is 
more likely to develop a robust X.509 certificate enabled application 
that can build valid certification paths across a wide range of PKI 
environments.

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certpathbuild-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.
--------------3EB6208E1C918044D629D703
Content-Type: Message/External-body;
 name="draft-ietf-pkix-certpathbuild-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-pkix-certpathbuild-00.txt"

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


--------------3EB6208E1C918044D629D703--

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

MIIH7QYJKoZIhvcNAQcCoIIH3jCCB9oCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcAwggKAMIIB6aADAgECAgMKB+8wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA1MjgyMTI5MjJaFw0wNDA1MjcyMTI5MjJa
MEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIjAgBgkqhkiG9w0BCQEWE3N0
ZXZlLmhhbm5hQHN1bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANof1lVV7qao
9dRjzsm6ur4Au3MV3NSZIFSRqVWOcpVs/IzxwM8YJGHkMs9hIxl112qSti+DrhGaoxNB9gNk
hK6fQ4LkjZtj2joylLxaV2pdimIzZ0o1p+aQQ1T3k2PJ4QC65wRJB3hgD3VEhFeWgrM6YOa2
RUSP+9pGXUN3G9SlAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1bi5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAnVJJECGU6OMpOee5E43ETFdohCEXc
aUUROH0CcT4+zuKJFouM/9QR6ThJs/CxL9Wf9C9EENuFqOxBa1bDXR13Y39E26q1U+aR+637
Spb8SCQrNitkaQeVy/QLRjJbWe4RCT0C+Q+wBEEZoamSvZ48/1E4TTLI48wudxv2QkF9eTCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd
MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt
YWlsIFJTQSAyMDAwLjguMzACAwoH7zAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDcxMDE5Mjk1OFowIwYJKoZIhvcNAQkEMRYE
FMz32jUqApkWwotdsXBROjLqp4B4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAfJW/9KMNci16TWS8owhRGFm9HVO7AV8iN/tYJA4uZZkUtq1fiZBE
VgFQuDLKN0ZAADSi5lRQa0xs4NJ7CGiPqPPjlGkfVu/RsAyOv0mk5dK3ynngxM3aC7KFz30T
hWzwRdNHnbmP1sLOoTYZlNAivkyDYfeCq6aYa2O9unBM9e0=
--------------ms4B7902436081545849902AA0--



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

Denis,

I believe that there is some confusion in the meaning of "CRL issuer".  
A CRL issuer is any entity, including CAs, that issues CRLs.

Perhaps the confusion comes from section 3, where the following text 
appears:

   CRL issuer: an optional system to which a CA delegates the
               publication of certificate revocation lists;

This is not a definition, however.  It is describing the components in 
Figure 1.  CRL issuer is defined as optional because the CRL issuer 
would not appear as a separate component in the figure if the CA issued 
its own CRLs.  Elsewhere in RFC 3280, it is clear that any entity that 
issues CRLs is a CRL issuer.

Paragraph 3 of section 5 states: "CRL issuers issue CRLs.  In general, 
the CRL issuer is the CA.... Whenever the CRL issuer is not the CA that 
issued the certificates, the CRL is referred to as an indirect CRL."

Denis Pinkas wrote:

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6A5Xrqt036192 for <[e-mail]>; Wed, 9 Jul 2003 22:33:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6A5XrBv036191 for ietf-pkix-bks; Wed, 9 Jul 2003 22:33:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mpls-qmqp-03.inet.qwest.net (mpls-qmqp-03.inet.qwest.net [63.231.195.114]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6A5Xqqt036186 for <[e-mail]>; Wed, 9 Jul 2003 22:33:52 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 89155 invoked by uid 0); 10 Jul 2003 05:26:28 -0000
Received: from mpls-pop-07.inet.qwest.net (63.231.195.7) by mpls-qmqp-03.inet.qwest.net with QMQP; 10 Jul 2003 05:26:28 -0000
Received: from vdsl-130-13-127-251.phnx.uswest.net (HELO ?192.168.2.7?) (130.13.127.251) by mpls-pop-07.inet.qwest.net with SMTP; 10 Jul 2003 05:33:55 -0000
Date: Wed, 9 Jul 2003 22:14:15 -0700
Message-Id: <a05210601bb329cb000b2@[192.168.2.7]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
X-Sender: [e-mail]@mail.earthlink.net
In-Reply-To: <[e-mail]>
References:  <[e-mail] v.microsoft.com> <[e-mail]>
Subject: Re: What is mean by recognizing critical extensions ?
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: What is mean by recognizing critical extensions
?</title></head><body>
<div>At 10:31 -0400 7/8/03, David A. Cooper wrote:</div>
<div><br></div>
<div>as we were finishing up the 4th edition sharon boeyen reported to
our group that some implementors were using an interesting
interpretation of &quot;recognizing an extension&quot;. apparently
their recognition essentially meant that they recognized the oid and
recognized that the extension was defined but did not process it, i.e
wrote no code to process the extension as defined in the standard. to
counter this specious argument we wrote some additional text for
clause 7</div>
<div><br></div>
<div>the 3rd edition contains this paragraph</div>
<div><br></div>
<div><font size="+1">&quot;<font face="Times"
color="#000000">The</font><font face="Helvetica" color="#000000"><b>
extensions</b></font><font face="Times" color="#000000"> field allows
addition of new fields to the structure without modification to the
ASN.1 definition. An extension field consists of an extension
identifier, a criticality flag, and a canonical encoding of a data
value of an ASN.1 type associated with the identified extension. For
those extensions where ordering of individual extensions within the
SEQUENCE is significant, the specification of those individual
extensions shall include the rules for the significance of the order
therein. When an implementation processing a certificate does not
recognize an extension, if the criticality flag is FALSE, it may
ignore that extension. If the criticality flag is TRUE, unrecognized
extensions shall cause the structure to be considered invalid, i.e. in
a certificate, an unrecognized critical extension would cause
validation of a signature using that certificate to
fail.</font></font><font size="+1">&quot;</font></div>
<div><br></div>
<div>the 4th edition has this replacement paragraph (as well as
additional paragraphs)</div>
<div><br></div>
<div><font size="+1">&quot;<font face="Times New Roman"
color="#000000">The</font><font face="Arial" color="#000000"><b>
extensions</b></font><font face="Times New Roman" color="#000000">
field allows addition of new fields to the structure without
modification to the ASN.1 definition. An extension field consists of
an extension identifier, a criticality flag, and an encoding of a data
value of an ASN.1 type associated with the identified extension. For
those extensions where ordering of individual extensions within
the</font><font face="Arial" color="#000000"><b>
SEQUENCE</b></font><font face="Times New Roman" color="#000000"> is
significant, the specification of those individual extensions shall
include the rules for the significance of the order therein. When an
implementation processing a certificate does not recognize an
extension, if the criticality flag is</font><font face="Arial"
color="#000000"><b> FALSE</b></font><font face="Times New Roman"
color="#000000">, it may ignore that extension. If the criticality
flag is</font><font face="Arial" color="#000000"><b>
TRUE</b></font><font face="Times New Roman" color="#000000">,
unrecognized extensions shall cause the structure to be considered
invalid, i.e. in a certificate, an unrecognized critical extension
would cause validation of a signature using that certificate to fail.
When a certificate-using implementation recognizes and is able to
process an extension, then the certificate-using implementation shall
process the extension regardless of the value of the criticality flag.
Note that any extension that is flagged non-critical will cause
inconsistent behaviour between certificate-using systems that will
process the extension and certificate-using systems that do not
recognize the extension and will ignore it.</font></font><font
size="+1">&quot;</font></div>
<div><br></div>
<div>note the penultimate sentence.</div>
<div><br></div>
<div>one of the advantages of implementation conformance statements is
that they can be used to determined what a product implemented and
what it did not. i believe it would be useful for the ietf to define
implementation conformance statement pro formas for their
standards</div>
<div><br></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
<blockquote type="cite" cite>Trevor,<br>
<br>
It was not intention to imply that the criticality flag should be used
in deciding whether to process an extension.&nbsp; I agree that if you
can process an extension, then you must do so, whether the extension
is critical or non-critical.<br>
<br>
For most extensions (e.g., BasicConstraints, nameConstraints,
policyConstraints, keyUsage), the processing requirements are very
clearly stated.&nbsp; Processing rules tend to be more vague for
extensions in which the processing can only be performed by the user
application and not by the path validation library.&nbsp;
SubjectAltName is one such example.&nbsp; certificatePolicies is
another.&nbsp; The rules for determining the set of policies under
which a certificate is valid are well specified, but processing the
extension also means ensuring that the certificate is used in
accordance with the rules implied by one of the specified
policies.&nbsp;&nbsp; For the most part, this can only be accomplished
through out-of-band means.</blockquote>
<blockquote type="cite" cite><br>
In general, I think that the SubjectAltName extension is only relevant
in an end certificate.&nbsp; In an intermediate certificate, the
subject field must contain a non-null name and so the SubjectAltName
extension, if present, can (and probably should) be non-critical.&nbsp;
I think processing subject names means ensuring that one has the right
certificate.&nbsp; For intermediate certificates, this is done by
comparing the subject field to the issuer field in the next
certificate.&nbsp; For the end certificate, this means either
determining that the subject name or one of the SubjectAltNames
matches the name the application is &quot;expecting&quot; (e.g.,
finding the sender's e-mail address in the certificate when verifying
a signed e-mail message) or using one or more of the subject names to
inform the application's user of the certified name so that the user
can determine if the identity is correct.&nbsp; If the end certificate
contains a null subject name and the application can not process any
of the names in the SubjectAltName extension, then there is no way to
determine if the identity is correct.<br>
<br>
I wouldn't know how to process a registeredID either.&nbsp; But, if I
received a signed message in which the signer's certificate had a null
subject name and a SubjectAltName extension that only included a
registeredID, should I accept the certificate?&nbsp; Is it of any use
to know that the message was properly signed if the signer's identity
has no meaning to me?<br>
<br>
Dave<br>
<br>
Trevor Freeman wrote:<br>
<blockquote type="cite" cite>David,<br>
I think you are giving the impression that the criticality flag is
an<br>
input into the decision on whether to process an extension - which is
it<br>
not. If an application understands an extension, it must process
the<br>
contents of the extension, regardless of criticality. Applications
which<br>
do not understand the extension may skip processing of an
extension<br>
marked as non-critical. That said; the definition of what constitutes
to<br>
process the contents is typically vague. Even in you example - I have
no<br>
clue what it means to process a registeredID.<br>
<br>
&nbsp;</blockquote>
</blockquote>
<div><br></div>
</body>
</html>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69ENkqt098842 for <[e-mail]>; Wed, 9 Jul 2003 07:23:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h69ENk16098841 for ietf-pkix-bks; Wed, 9 Jul 2003 07:23:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69ENiqt098836; Wed, 9 Jul 2003 07:23:45 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA33082; Wed, 9 Jul 2003 16:28:17 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA07578; Wed, 9 Jul 2003 16:23:47 +0200
Message-ID: <[e-mail]>
Date: Wed, 09 Jul 2003 16:23:41 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>, S-MIME / IETF <[e-mail]>
Subject: Policy Requirements for Attribute Authorities
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h69ENkqu098837
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

ETSI is making available a draft document for public comments called:
"Policy requirements for certification service providers issuing Attribute 
Certificates".

The document is available at the following URL:
http://docbox.etsi.org/ESI/Open/ETSI%20TS%20102_158%20v01.zip

This document has been approved by ETSI Technical Committee - Electronic 
Signatures and Infrastructures for public review.  Comments are invited on 
it, to be submitted to the editor and/or the task leader by 2003.08.24.

Editor: Denis Pinkas <[e-mail]>
Task leader: Franco Ruggieri <[e-mail]>

Do not send your comments to the PKIX or to the SMIME mailing list.

This will allow the consolidation by 2003.09.07 of a final draft to be 
approved for publication at TC ESI # 05 in Sophia Antipolis, 23 – 24 
September 2003 as ETSI Technical Specification (TS) 102 158.

If you choose to place your comments in-line in the text of the document 
please return them under the same file name with the addition "&your initials".

If you are aware of other public lists whose members might benefit from 
awareness of this document and have their own views to offer, please feel 
free to forward the document to them with copy of this message.

Regards,

Denis Pinkas. Document editor.
Franco Ruggieri. Task leader.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h697DFqt055160 for <[e-mail]>; Wed, 9 Jul 2003 00:13:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h697DFvt055159 for ietf-pkix-bks; Wed, 9 Jul 2003 00:13:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-pro.vtx.ch (smtp-pro.vtx.ch [212.147.0.65]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h697DAqt055111 for <[e-mail]>; Wed, 9 Jul 2003 00:13:12 -0700 (PDT) (envelope-from [e-mail])
Received: from DRGS8HR4Y6Q4IY (unknown [212.147.70.133]) by smtp-pro.vtx.ch (VTX Services) with SMTP id 0440966FD1; Wed,  9 Jul 2003 09:12:46 +0200 (CEST)
From: "Otto Mueller" <[e-mail]>
To: <[e-mail]>
Cc: "Man-Sze Li" <[e-mail]>, "Mueller, Adrian, M-C" <[e-mail]>
Subject: draft-ietf-pkix-pi-06
Date: Wed, 9 Jul 2003 09:07:32 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear PKIX WG:
Please note that Cyber Identity has now emerged as a very hot topic.
Permanent Identifiers in X.509 certificates are an important link in the
Cyber Identity system. The Internet draft-ietf-pkix-pi-06 defines very
clearly the syntax how to incorporate a unique identifier of some entity
into a X.509 certificate.

Now, we state that the discussion about this very useful prospective RFC has
come into a deadlock. The issues are:
- an URI is easily workable but is not considered "permanent enough";
- an OID is really permanent but is not easily workable in applications;

We think the assessment
- if a specific URI is "permanent enough" and
- if an OID is workable in applications
should be left
- to the certification authority issuing a certificate according to its
certificate policy and
- to the relying party using some application to extract the permanent
identifier.

The certification authority is responsible for the content of the
certificate i.e. the permanent identifier and the relying party has to
decide if they accept the certificate policy related to the certificate.
However, they need a clear syntax which is given by the
draft-ietf-pkix-pi-06.

Therefore, we suggest that the draft should be left as is and be updated by
some explanation as outlined above.

Regards,
Otto and Adrian Mueller


Otto Mueller
c/o Zurich chamber of commerce
phone [phone]
fax   [phone]




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

David,

Since you just sent a message on the PKIX mailing list, I take advantage of 
this opportunity to forward you an e-mail that I sent on June 11 where 
apparently I did not received a response.

There is a minor comment at the very end of that e-mail.

Denis

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

David,

Thank you for this very prompt response.

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

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

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

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

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

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

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

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

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

Is the following a more correct statement ?

      The CRL issuer MUST assert the indirectCRL boolean, if the scope of
      the CRL includes certificates issued by authorities for which the
      CRL issuer has not received from a CA the right to revoke.

Denis

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





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68FIhqt082621 for <[e-mail]>; Tue, 8 Jul 2003 08:18:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h68FIhxh082620 for ietf-pkix-bks; Tue, 8 Jul 2003 08:18:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68FIfqt082615 for <[e-mail]>; Tue, 8 Jul 2003 08:18:42 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA05684 for <[e-mail]>; Tue, 8 Jul 2003 17:23:13 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA02289 for <[e-mail]>; Tue, 8 Jul 2003 17:18:42 +0200
Message-ID: <[e-mail]>
Date: Tue, 08 Jul 2003 17:18:36 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

> 	Title		: Internet X.509 Public Key Infrastructure Warranty 
>                           Certificate Extension
> 	Author(s)	: D. Linsenbardt, S. Pontius, A. Sturgeon
> 	Filename	: draft-ietf-pkix-warranty-extn-03.txt
> 	Pages		: 8
> 	Date		: 2003-6-27

Here are my comments on this draft.

Comments on warranty-extn-03.txt (June 2003)

1- On page 2. The text mentions: "A relying party that has a warranty from a 
CA".

Does this mean that a relying party must have a contract with the CA to get 
advantage of the warranty ?

Does this mean that a relying party will get a warranty without a contract 
signed with the CA ?

Does this extension allow to make the difference between the case of a 
signed contract and the case of an unsigned contract where the guarantees 
could be different ?


2 - The difference between the base warranty and the extended warranty is 
not crystal clear.

How can a relying party know whether it can have the benefits of the base 
warranty or of the extended warranty ?

If the tcURL is present, a human being might understand the terms and 
conditions (if he can understand the local language used), but a computer 
program will not be able to do so. This means that computers cannot 
understand the difference.


3 - There is no security on the information placed at the tcURL parameter 
since no hash of the terms and conditions is being used. These conditions 
could change overtime and relying parties would not be able to demonstrate 
that they have changed.


4 - Is the "Relying party Agreement" a document to signed by the parties or 
not ? This should be said.


5 - The WarrantyValidityPeriod is insufficient. Usually there is a period to 
claim for a compensation which must be made X months or Y days after the 
date of the event which created the damage. It is thus not possible to ask 
for a warranty during e.g. the whole validity period of the certificate. 
Another time period parameter is missing.


6 - The wType offers only two types of warranty: aggregated and per transaction.

"Aggregated" means that that once the value of the fulfilled claims reaches 
the maximum warranty amount, then no further claim will be fulfilled.

"Per transaction" means that each claim is handled independently but no 
individual claim can exceed the maximum warranty amount.

Each type has its own problems:

"Aggregated" is like a race where late claimants will get no compensation at 
all because they were not "fast enough". It is questionable whether such a 
race condition will be acceptable.

"Per transaction" means that the CA cannot compute the maximum amount of 
money that it may have to give away. Which insurance company will ever 
insure a risk for which an upper limit cannot be computed ?

None of these schemes is acceptable. Some combination should be allowed:

  - a maximum amount per transaction, and
  - a maximum amount per certificate with a maximum time period
    to claim for a compensation after the date of the event
    (no race problem implied).


7 - The content of the security consideration should be augmented to 
indicate the difference between what a computer program can do and a human 
being can do with this extension.


8 - The document is not mature enough and its added value is still questionable.


Denis




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68EWGqt078443 for <[e-mail]>; Tue, 8 Jul 2003 07:32:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h68EWGAT078442 for ietf-pkix-bks; Tue, 8 Jul 2003 07:32:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68EWEqt078436 for <[e-mail]>; Tue, 8 Jul 2003 07:32:14 -0700 (PDT) (envelope-from [e-mail])
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h68EVUPg022899; Tue, 8 Jul 2003 10:31:32 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 08 Jul 2003 10:31:01 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: Wahaj <[e-mail]>, [e-mail]
Subject: Re: What is mean by recognizing critical extensions ?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

It was not intention to imply that the criticality flag should be used 
in deciding whether to process an extension.  I agree that if you can 
process an extension, then you must do so, whether the extension is 
critical or non-critical.

For most extensions (e.g., BasicConstraints, nameConstraints, 
policyConstraints, keyUsage), the processing requirements are very 
clearly stated.  Processing rules tend to be more vague for extensions 
in which the processing can only be performed by the user application 
and not by the path validation library.  SubjectAltName is one such 
example.  certificatePolicies is another.  The rules for determining the 
set of policies under which a certificate is valid are well specified, 
but processing the extension also means ensuring that the certificate is 
used in accordance with the rules implied by one of the specified 
policies.   For the most part, this can only be accomplished through 
out-of-band means.

In general, I think that the SubjectAltName extension is only relevant 
in an end certificate.  In an intermediate certificate, the subject 
field must contain a non-null name and so the SubjectAltName extension, 
if present, can (and probably should) be non-critical.  I think 
processing subject names means ensuring that one has the right 
certificate.  For intermediate certificates, this is done by comparing 
the subject field to the issuer field in the next certificate.  For the 
end certificate, this means either determining that the subject name or 
one of the SubjectAltNames matches the name the application is 
"expecting" (e.g., finding the sender's e-mail address in the 
certificate when verifying a signed e-mail message) or using one or more 
of the subject names to inform the application's user of the certified 
name so that the user can determine if the identity is correct.  If the 
end certificate contains a null subject name and the application can not 
process any of the names in the SubjectAltName extension, then there is 
no way to determine if the identity is correct.

I wouldn't know how to process a registeredID either.  But, if I 
received a signed message in which the signer's certificate had a null 
subject name and a SubjectAltName extension that only included a 
registeredID, should I accept the certificate?  Is it of any use to know 
that the message was properly signed if the signer's identity has no 
meaning to me?

Dave

Trevor Freeman wrote:

>David,
>I think you are giving the impression that the criticality flag is an
>input into the decision on whether to process an extension - which is it
>not. If an application understands an extension, it must process the
>contents of the extension, regardless of criticality. Applications which
>do not understand the extension may skip processing of an extension
>marked as non-critical. That said; the definition of what constitutes to
>process the contents is typically vague. Even in you example - I have no
>clue what it means to process a registeredID.
>
>  
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68CEVqt070626 for <[e-mail]>; Tue, 8 Jul 2003 05:14:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h68CEVcJ070625 for ietf-pkix-bks; Tue, 8 Jul 2003 05:14:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gghqex1.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68CEUqt070620 for <[e-mail]>; Tue, 8 Jul 2003 05:14:30 -0700 (PDT) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: What is mean by recognizing critical extensions ?
Date: Tue, 8 Jul 2003 08:14:27 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What is mean by recognizing critical extensions ?
Thread-Index: AcNEwirWXOhBe3UVSx+6utCa+dHwSwAhEnkQ
From: "Oshman, Dave" <[e-mail]>
To: "Wahaj" <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h68CEUqt070621
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wahaj--
Not sure if anyone has answered this part of your question so here's my
attempt.

Wahaj wrote:

>  
> In RFC 3280 in certificate extension section it is stated " A
> certificate using system MUST reject the certificate if it encounters 
> a critical extension it does not recognize". Now what recognize mean ?

> is it to use it (in other words process it) or merely read it and 
> not processing. I came across three different terms used. Ability to 
> Recognize, Process or Support. What is exactly meant by them. Are they

> same or different ?
>  

Regarding this question which leans toward asking if critical extensions
need to be "processed" or only "recognized" along with definitions of
the terms. In section 6.1.4 in 3280, it states:
(o)  Recognize and process any other critical extension present in
      the certificate.  Process any other recognized non-critical
      extension present in the certificate.
So, you do need to "process" all critical extensions. If you recognize
any non-critical extensions, you must "process" them as well. 

Now, the more difficult question is what is meant by "process". I'd say
that "processing" is more or less described in sections 4 & 5 where each
extension is described. For example, the Key Usage extension defined in
4.2.1.3, if recognized, should be processed to verify that the
certificate is being used for the purpose(s) described. E.g. Is the
application attempting to provide a non-repudiation service which
"protects against the signing entity falsely denying some action,
excluding certificate or CRL signing." such as signing off on a purchase
order. If so, the non-repudiation bit in the key usage extension must be
set or else the usage is invalid.

I'd then say that "recognize" means "include processing logic for the
extension". 

I think "support" means a combination of both.

Regards,
Dave Oshman




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68C2bqt070170 for <[e-mail]>; Tue, 8 Jul 2003 05:02:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h68C2b1i070169 for ietf-pkix-bks; Tue, 8 Jul 2003 05:02:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68C2Zqt070164 for <[e-mail]>; Tue, 8 Jul 2003 05:02:35 -0700 (PDT) (envelope-from [e-mail])
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h68C2HPg000455 for <[e-mail]>; Tue, 8 Jul 2003 08:02:17 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.9/8.12.9) with ESMTP id h68C2GKH000674 for <[e-mail]>; Tue, 8 Jul 2003 08:02:17 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.9/8.12.9/Submit) id h68C2G7g000673 for [e-mail]; Tue, 8 Jul 2003 08:02:16 -0400 (EDT)
Received: from 138.88.233.179 ( [138.88.233.179]) as user [e-mail] by imp.nist.gov with HTTP; Tue,  8 Jul 2003 08:02:16 -0400
Message-ID: <[e-mail]>
Date: Tue,  8 Jul 2003 08:02:16 -0400
From: [e-mail]
To: [e-mail]
Subject: draft agenda - 57th IETF
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Here is the draft agenda for next week's meeting.  Please let me know ASAP if 
you wanted to be on the agenda but were overlooked.

Thanks,

Tim Polk

------------------ draft agenda --------------------------------

 
PKIX WG (pkix-wg) 

THURSDAY, July 17, 2003 0900-1130 
================================= 

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

AGENDA: 

1. WG Status and Direction

1.1 WG Focus and Direction [ADs]

      The working group has recieved direction from the IESG that will
      limit the types of new specifications accepted as PKIX work products.
      The ADs wil present IESG's expectations for the PKIX WG along with
      the rationale. (15 min.)

1.2 Document Status Review [Tim Polk (NIST)]

      The working group has a large number of Internet-Drafts.  Many 
      documents are with the ADs or in various stages of WG Last Call. 
      Several others are ready for Last Call. (15 min.)

2. PKIX WG Specifications

   2.1  Simple Certificate Validation Protocol   Trevor Freeman (MicroSoft) 

         http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-12.txt 

      The current draft of SCVP is in WG Last Call, and is believed to be in 
      full compliance with RFC 3379. This presentation will identify the 
changes
      since the -11 draft.  (15 min.)

   2.2 RFC 3280 Progression	Tim Polk (NIST)

      NIST is currently performing the interoperability testing for RFC 3280. 
      This presentation will update the WG on NIST's progress, projected 
      completion date, and issues identified to date. Primary focus will be the
      RFC 3280 path validation test suite developed jointly by NIST, 
DigitalNet,
      and NSA. (10 min.) 

   2.3 LDAP: Schemas, String Values, and more - David Chadwick (Univ of 
Salford) 
                                 Peter Gietz (DAASI) 

      The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
      for LDAP based PKI information distribution.  New drafts on PKC 
certificate
      schema, CRL schema and on Attribute Certificate schema have been 
published
      since the 56th IETF.  The authors will present the changes in these 
documents
      and discuss the timeline for document completion.  (15 min.)

   2.4 Certification Path Building     Matt Cooper (Orion Security)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-00.txt 

      This document was written to provide "best practice" guidance and 
      recommendations to developers building X.509 public-key certification 
      paths within their applications.    (10 min.) 

3. Related Specifications

   The following personal drafts address topics of interest to the PKIX WG,
   and are presented to highlight the availability of the drafts and encourage
   input from the WG.  

   3.1 Specifying Russian Cryptographic Algorithms in PKIX
                                    Gregory S. Chudov (Crypto-Pro)

      This personal draft documents the use of Russian national cryptography
      standards (GOST) in the PKIX Certificate and CRL Profile. It was 
developed
      within "Russian Cryptographic Software Compatibility Agreement", 
      and signed by major Russian cryptographic software vendors. (10 min.)


   3.2 Memorandum for multi-domain PKI Interoperability
                                     Masaki SHIMAOKA (SECOM)

      This personal draft documents known issues and considerations for
      multi-domain PKI, and provides guidelines for multi-domain PKI
      interoperability as a best current practice. The scope of this 
      specification is the establishment of trust relationships and
      interoperability between mulitple PKI domains.  

      This specification is a follow on to the JNSA Challenge PKI 2002 
      and Multi-Domain PKI Test Suite.  (10 min.)

   3.2 Object Oriented PKI (OO-PKI)  Anders Rungren (Telia)

      This personal draft introduces an Object Oriented (OO) X.509
      extension. The extension is intended to eliminate the need for
      application-level, relying party PKI software, to a priori "know"
      certificate profiles, be manually "configured", or occasionally
      require "adjustments". The primary goal with the extension is to
      enable the creation of a wide range of standard information system
      applications, having built-in relying party PKI support. (10 min.)






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68Bwwqt070023 for <[e-mail]>; Tue, 8 Jul 2003 04:58:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h68BwwQS070022 for ietf-pkix-bks; Tue, 8 Jul 2003 04:58:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68Bwuqt070017 for <[e-mail]>; Tue, 8 Jul 2003 04:58:56 -0700 (PDT) (envelope-from [e-mail])
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h68BwePg028690 for <[e-mail]>; Tue, 8 Jul 2003 07:58:40 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.9/8.12.9) with ESMTP id h68BweKH000557 for <[e-mail]>; Tue, 8 Jul 2003 07:58:40 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.9/8.12.9/Submit) id h68Bwegk000556 for [e-mail]; Tue, 8 Jul 2003 07:58:40 -0400 (EDT)
Received: from 138.88.233.179 ( [138.88.233.179]) as user [e-mail] by imp.nist.gov with HTTP; Tue,  8 Jul 2003 07:58:39 -0400
Message-ID: <[e-mail]>
Date: Tue,  8 Jul 2003 07:58:39 -0400
From: [e-mail]
To: [e-mail]
Subject: WG Last Call: SCVP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates working group Last Call for the Simple Certificate
Validation Protocol.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before July 22.

The URL for this Internet-Draft is:
  http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-12.txt 
 
The -12 draft includes minor enhancements to bring the specification into
full compliance with RFC 3379.
 
Thanks,

Tim Polk

 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67LgTqt093977 for <[e-mail]>; Mon, 7 Jul 2003 14:42:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67LgTMF093976 for ietf-pkix-bks; Mon, 7 Jul 2003 14:42:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67LgSqt093968 for <[e-mail]>; Mon, 7 Jul 2003 14:42:28 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Mon, 7 Jul 2003 14:42:25 -0700
Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Jul 2003 14:42:25 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jul 2003 14:41:58 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jul 2003 14:41:57 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 7 Jul 2003 14:41:56 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: What is mean by recognizing critical extensions ?
Date: Mon, 7 Jul 2003 14:41:37 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What is mean by recognizing critical extensions ?
Thread-Index: AcNEyennKgJjLK7dS6mn9JPziYowzgABFpKA
From: "Trevor Freeman" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "Wahaj" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 07 Jul 2003 21:41:56.0908 (UTC) FILETIME=[96B8B6C0:01C344D0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h67LgSqt093970
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,
I think you are giving the impression that the criticality flag is an
input into the decision on whether to process an extension - which is it
not. If an application understands an extension, it must process the
contents of the extension, regardless of criticality. Applications which
do not understand the extension may skip processing of an extension
marked as non-critical. That said; the definition of what constitutes to
process the contents is typically vague. Even in you example - I have no
clue what it means to process a registeredID.

Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of David A. Cooper
Sent: Monday, July 07, 2003 12:03 PM
To: Wahaj
Cc: [e-mail]
Subject: Re: What is mean by recognizing critical extensions ?


Wahaj wrote:

> Hi All,
>  
> I need to know if a Certificate has got an extension marked as 
> critical, should the application process it ( By process I mean 
> perform some action & not merely recognizing it). So if an application

> receives a user certificate having SubjectAltName marked as critical 
> and that application don't use or process SubjectAltName then should 
> the application discard or reject the user certificate based on the 
> fact it won't process it and only recognize it OR should it carry on 
> with it because it can recognize this extension.

If an extension is marked critical, the application must process the 
extension or reject the certificate.  For the SubjectAltName extension, 
X.509 states: "If the [SubjectAltName] extension is flagged critical, at

least one of the name forms that is present shall be recognized and 
processed, otherwise the certificate shall be considered invalid."

> As far as CRL extensions are concerned, it is clearly stated that if 
> they are marked as Critical they should be processed, if not the CRL 
> is not valid and is rejected.
>  
> In RFC 3280 in certificate extension section it is stated " A 
> certificate using system MUST reject the certificate if it encounters 
> a critical extension it does not recognize". Now what recognize mean ?

> is it to use it (in other words process it) or merely read it and 
> not processing. I came across three different terms used. Ability to 
> Recognize, Process or Support. What is exactly meant by them. Are they

> same or different ?
>  
> Also it is stated in RFC 3280 that Basic Constaint MUST be set set as 
> critical. So should an application reject such CA certificate if Basic

> Constraint is present but is not set as critical. Same for other 
> extensions ?

No.  This statement is indicating that CAs conforming to RFC 3280 must 
set the BasicConstraints extension to critical.  There is no requirement

for clients to only accept certificates issued by RFC 3280 compliant
CAs.






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67J48qt084608 for <[e-mail]>; Mon, 7 Jul 2003 12:04:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67J48Sc084607 for ietf-pkix-bks; Mon, 7 Jul 2003 12:04:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67J45qt084593 for <[e-mail]>; Mon, 7 Jul 2003 12:04:05 -0700 (PDT) (envelope-from [e-mail])
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h67J3QPg013484; Mon, 7 Jul 2003 15:03:27 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 07 Jul 2003 15:02:59 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wahaj <[e-mail]>
CC: [e-mail]
Subject: Re: What is mean by recognizing critical extensions ?
References: <0ccd01c3423d$89338880$0600a8c0@IdentrusVA1>
In-Reply-To: <0ccd01c3423d$89338880$0600a8c0@IdentrusVA1>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wahaj wrote:

> Hi All,
>  
> I need to know if a Certificate has got an extension marked as 
> critical, should the application process it ( By process I mean 
> perform some action & not merely recognizing it). So if an application 
> receives a user certificate having SubjectAltName marked as critical 
> and that application don't use or process SubjectAltName then should 
> the application discard or reject the user certificate based on the 
> fact it won't process it and only recognize it OR should it carry on 
> with it because it can recognize this extension.

If an extension is marked critical, the application must process the 
extension or reject the certificate.  For the SubjectAltName extension, 
X.509 states: "If the [SubjectAltName] extension is flagged critical, at 
least one of the name forms that is present shall be recognized and 
processed, otherwise the certificate shall be considered invalid."

> As far as CRL extensions are concerned, it is clearly stated that if 
> they are marked as Critical they should be processed, if not the CRL 
> is not valid and is rejected.
>  
> In RFC 3280 in certificate extension section it is stated " A 
> certificate using system MUST reject the certificate if it encounters 
> a critical extension it does not recognize". Now what recognize mean ? 
> is it to use it (in other words process it) or merely read it and 
> not processing. I came across three different terms used. Ability to 
> Recognize, Process or Support. What is exactly meant by them. Are they 
> same or different ?
>  
> Also it is stated in RFC 3280 that Basic Constaint MUST be set set as 
> critical. So should an application reject such CA certificate if Basic 
> Constraint is present but is not set as critical. Same for other 
> extensions ?

No.  This statement is indicating that CAs conforming to RFC 3280 must 
set the BasicConstraints extension to critical.  There is no requirement 
for clients to only accept certificates issued by RFC 3280 compliant CAs.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64F5cqt093559 for <[e-mail]>; Fri, 4 Jul 2003 08:05:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64F5cDY093558 for ietf-pkix-bks; Fri, 4 Jul 2003 08:05:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64F5Tqt093552 for <[e-mail]>; Fri, 4 Jul 2003 08:05:34 -0700 (PDT) (envelope-from [e-mail])
Received: from IdentrusVA1 ([203.81.196.29]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h64F4bJG000042 for <[e-mail]>; Fri, 4 Jul 2003 21:04:38 +0600 (PKST)
Message-ID: <0ccd01c3423d$89338880$0600a8c0@IdentrusVA1>
From: "Wahaj" <[e-mail]>
To: <[e-mail]>
Subject: What is mean by recognizing critical extensions ?
Date: Fri, 4 Jul 2003 20:04:13 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0CC7_01C34267.70A28670"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0CC7_01C34267.70A28670
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0CC8_01C34267.70A28670"


------=_NextPart_001_0CC8_01C34267.70A28670
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi All,

I need to know if a Certificate has got an extension marked as critical, =
should the application process it ( By process I mean perform some =
action & not merely recognizing it). So if an application receives a =
user certificate having SubjectAltName marked as critical and that =
application don't use or process SubjectAltName then should the =
application discard or reject the user certificate based on the fact it =
won't process it and only recognize it OR should it carry on with it =
because it can recognize this extension.

As far as CRL extensions are concerned, it is clearly stated that if =
they are marked as Critical they should be processed, if not the CRL is =
not valid and is rejected.=20

In RFC 3280 in certificate extension section it is stated " A =
certificate using system MUST reject the certificate if it encounters a =
critical extension it does not recognize". Now what recognize mean ? is =
it to use it (in other words process it) or merely read it and not =
processing. I came across three different terms used. Ability to =
Recognize, Process or Support. What is exactly meant by them. Are they =
same or different ?

Also it is stated in RFC 3280 that Basic Constaint MUST be set set as =
critical. So should an application reject such CA certificate if Basic =
Constraint is present but is not set as critical. Same for other =
extensions ?

Best Regards,
Wahaj

------=_NextPart_001_0CC8_01C34267.70A28670
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3D"file://F:\Data\Document\General\Ascertia\Ascertia Email =
signature\">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi All,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I need to know if a Certificate has got an extension marked as =
critical,=20
should the application process it ( By process I mean perform some =
action &amp;=20
not merely recognizing it). So if an application receives a user =
certificate=20
having SubjectAltName marked as critical and that application don't use =
or=20
process SubjectAltName then should the application discard or reject the =
user=20
certificate&nbsp;based on the fact&nbsp;it won't process it and only =
recognize=20
it OR should it carry on with it because it can recognize this =
extension.</DIV>
<DIV>&nbsp;</DIV>
<DIV>As far as CRL extensions are concerned, it is clearly stated that =
if they=20
are marked as Critical they should be processed, if not the CRL is not =
valid and=20
is rejected. </DIV>
<DIV>&nbsp;</DIV>
<DIV>In RFC 3280 in certificate extension section it is stated " A =
certificate=20
using system MUST reject the certificate if it encounters a critical =
extension=20
it does not recognize". Now what recognize mean ? is it to use it (in =
other=20
words process it) or merely read it and not&nbsp;processing. I came =
across three=20
different terms used. Ability to Recognize, Process or Support. What is =
exactly=20
meant by them. Are they same or different ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Also it is stated in RFC 3280 that Basic Constaint MUST be set set =
as=20
critical. So should an application reject&nbsp;such CA certificate if =
Basic=20
Constraint is present but is not set as critical. Same for other =
extensions=20
?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Best Regards,</DIV>
<DIV>
<DIV class=3DSection1>
<DIV>Wahaj</DIV>
<DIV>&nbsp;</DIV></DIV></DIV></BODY></HTML>

------=_NextPart_001_0CC8_01C34267.70A28670--

------=_NextPart_000_0CC7_01C34267.70A28670
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

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

------=_NextPart_000_0CC7_01C34267.70A28670--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FWJFK065837 for <[e-mail]>; Thu, 3 Jul 2003 08:32:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FWJMb065836 for ietf-pkix-bks; Thu, 3 Jul 2003 08:32:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FW6FK065820 for <[e-mail]>; Thu, 3 Jul 2003 08:32:15 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16656; Thu, 3 Jul 2003 11:31:59 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-crl-schema-01.txt
Date: Thu, 03 Jul 2003 11:31:58 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure LDAP Schema 
                          for X.509 CRLs
	Author(s)	: D. Chadwick, M. Sahalayev
	Filename	: draft-ietf-pkix-ldap-crl-schema-01.txt
	Pages		: 0
	Date		: 2003-7-3
	
This document describes an LDAP schema for X.509 CRLs. Each CRL is broken down into a set of attribute types. These attributes can then be stored in a CRL entry, or set of entries. Object classes are defined for these CRL entries. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63G3Oqt003018 for <[e-mail]>; Thu, 3 Jul 2003 09:03:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63G3Oix003017 for ietf-pkix-bks; Thu, 3 Jul 2003 09:03:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63G3Kqt002981 for <[e-mail]>; Thu, 3 Jul 2003 09:03:20 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h63G339A028559; Thu, 3 Jul 2003 09:03:04 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Yasir Khan" <[e-mail]>, <[e-mail]>
Subject: RE: A question about RFC-2560 (OCSP)
Date: Thu, 3 Jul 2003 09:04:06 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C34142.0E7966B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <004a01c33fb8$2e6e9fc0$[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C34142.0E7966B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


Hi Yasir,
    The client needs to "know" that it can trust the signer. This trust can
happen
in one of 3 ways:

1. The CA signs the response
2. The CA delegates signing authority to a VA to sign the response
3. The client has a separate signing relationship with a VA who does
validation for it. In this case the signer is authorized to sign because
of a private relationship between the client and the VA.

Regards,
Ambarish


---------------------------------------------------------------------
Ambarish Malpani                                          650.759.9045
Malpani Consulting Services
[e-mail]                         http://www.malpani.biz



  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On
Behalf Of Yasir Khan
  Sent: Tuesday, July 01, 2003 3:00 AM
  To: [e-mail]
  Subject: A question about RFC-2560 (OCSP)


  Hi,

  I have a question about 'Signed Response Acceptance Requirements' in
RFC-2560 (OCSP), I am quoting the part of the document related to my
question.

  3.2  Signed Response Acceptance Requirements

     Prior to accepting a signed response as valid, OCSP clients SHALL
confirm that:

     1. The certificate identified in a received response corresponds to
that which was identified in the corresponding request;
     2. The signature on the response is valid;
     3. The identity of the signer matches the intended recipient of the
request.
     4. The signer is currently authorized to sign the response.
     5. The time at which the status being indicated is known to be correct
(thisUpdate) is sufficiently recent.
     6. When available, the time at or before which newer information will
be available about the status of the certificate (nextUpdate) is greater
than the current time.

  Requirement 4 is very ambiguous, there comes many possibilities to satisfy
this requirement e.g.

  a) EKU in signer certificate must contain OCSPSigning
  b) Signer certificate is not revoked
  c) Signer certificate is issued by the same CA that issed the target
certificate to be checked for revocation
  d) Issuer of the signer certificate is explicitly trusted

  I want to know the exact check(s) to satisfy the requiremtent 4.

  Thanx,

  Regards,
  Yasir Khan
  www.ascertia.com

------=_NextPart_000_0022_01C34142.0E7966B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Yasir,</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; The client needs to "know" that it can trust =
the=20
signer. This trust can happen</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =
size=3D2>in one=20
of 3 ways:</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =
size=3D2>1. The=20
CA signs the response</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =
size=3D2>2. The=20
CA delegates signing authority to a VA to sign the =
response</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =
size=3D2>3. The=20
client has a separate signing relationship with a VA who=20
does</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =

size=3D2>validation for it. In this case the signer is authorized to =
sign=20
because</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =
size=3D2>of a=20
private relationship between the client and the VA.</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =

size=3D2>Ambarish</FONT></SPAN></DIV>
<DIV><SPAN class=3D614340016-03072003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<P><FONT=20
size=3D2>----------------------------------------------------------------=
-----<BR>Ambarish=20
Malpani&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
650.759.9045<BR>Malpani Consulting=20
Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
<A href=3D"http://www.malpani.biz/"=20
target=3D_blank>http://www.malpani.biz</A><BR><BR></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Yasir=20
  Khan<BR><B>Sent:</B> Tuesday, July 01, 2003 3:00 AM<BR><B>To:</B>=20
  [e-mail]<BR><B>Subject:</B> A question about RFC-2560=20
  (OCSP)<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I have a question about <EM>'Signed =
Response=20
  Acceptance Requirements' </EM>in RFC-2560 (OCSP), I am quoting the =
part of the=20
  document related to my question. </FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2>3.2&nbsp; Signed =
Response=20
  Acceptance Requirements</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><BR><FONT =
color=3D#0000ff>&nbsp;&nbsp; Prior to=20
  accepting a signed response as valid, OCSP clients SHALL confirm=20
  that:</FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><BR><FONT =
color=3D#0000ff>&nbsp;&nbsp; 1. The=20
  certificate identified in a received response corresponds to that =
which was=20
  identified in the corresponding request;<BR>&nbsp;&nbsp; 2. The =
signature on=20
  the response is valid;<BR>&nbsp;&nbsp; 3. The identity of the signer =
matches=20
  the intended recipient of the request.<BR>&nbsp;&nbsp;<FONT =
color=3D#ff0000> 4.=20
  The signer is currently authorized to sign the=20
  response.<BR></FONT>&nbsp;&nbsp; 5. The time at which the status being =

  indicated is known to be correct (thisUpdate) is sufficiently=20
  recent.<BR>&nbsp;&nbsp; 6. When available, the time at or before which =
newer=20
  information will be available about the status of the certificate =
(nextUpdate)=20
  is greater than the current time.<BR></FONT></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Requirement 4 is very ambiguous, =
there comes many=20
  possibilities to satisfy this requirement e.g.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>a) EKU in signer certificate must =
contain=20
  OCSPSigning</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>b) Signer certificate is not =
revoked</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>c) Signer certificate is issued by =
the&nbsp;same=20
  CA that issed the target certificate to be checked for =
revocation</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>d) Issuer of the signer certificate =
is explicitly=20
  trusted&nbsp;</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I want to know the exact check(s) to =
satisfy the=20
  requiremtent 4.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Thanx,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Yasir Khan</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://www.ascertia.com">www.ascertia.com</A>&nbsp;</DIV></BLOCKQ=
UOTE></FONT></BODY></HTML>

------=_NextPart_000_0022_01C34142.0E7966B0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FWMFK065850 for <[e-mail]>; Thu, 3 Jul 2003 08:32:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FWMJF065849 for ietf-pkix-bks; Thu, 3 Jul 2003 08:32:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FWFFK065824 for <[e-mail]>; Thu, 3 Jul 2003 08:32:16 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16698; Thu, 3 Jul 2003 11:32:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dnstrings-01.txt
Date: Thu, 03 Jul 2003 11:32:08 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: LDAPv3 DN strings for use with PKIs
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-dnstrings-01.txt
	Pages		: 0
	Date		: 2003-7-3
	
RFC 2253 [2] standardises a set of strings that can be used to 
represent attribute types in LDAP distinguished names. This list is 
does not cover the full set of attribute types used in the 
distinguished names of issuers and subjects in public key 
certificates. This document standardises the strings needed for these 
additional attribute types. It also defines the Permanent Identifier 
attribute type which may be used to identify objects.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dnstrings-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FWFFK065830 for <[e-mail]>; Thu, 3 Jul 2003 08:32:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63FWFBF065829 for ietf-pkix-bks; Thu, 3 Jul 2003 08:32:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FWAFK065819 for <[e-mail]>; Thu, 3 Jul 2003 08:32:10 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16682; Thu, 3 Jul 2003 11:32:03 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 03 Jul 2003 11:32:03 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure:       
                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow
	Filename	: draft-ietf-pkix-certpathbuild-00.txt
	Pages		: 59
	Date		: 2003-7-3
	
This document was written to provide 'best practice' guidance and 
recommendations to developers building X.509 public-key certification 
paths within their applications.  By following the guidance and 
recommendations defined in this document, an application developer is 
more likely to develop a robust X.509 certificate enabled application 
that can build valid certification paths across a wide range of PKI 
environments.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-certpathbuild-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631RKFK096303 for <[e-mail]>; Wed, 2 Jul 2003 18:27:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h631RKov096302 for ietf-pkix-bks; Wed, 2 Jul 2003 18:27:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h631RIFK096294 for <[e-mail]>; Wed, 2 Jul 2003 18:27:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA07559 for <[e-mail]>; Thu, 3 Jul 2003 11:27:12 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0pLj5A; Thu Jul  3 11:26:46 2003
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA12164 for <[e-mail]>; Thu, 3 Jul 2003 11:26:46 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0Zlxdk; Thu Jul  3 11:26:29 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA00557 for <[e-mail]>; Thu, 3 Jul 2003 11:26:29 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: IP addr: 01: use NULL instead of BOOLEAN for inherit
Date: Thu, 3 Jul 2003 11:26:07 +1000
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
Thread-Index: AcNA9we0XWFLjqzlEdeWHgAIxySt0gABo0SA
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h631RJFK096297
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1.
Instead of a BOOLEAN type for which TRUE is required and FALSE is forbidden, simply use a NULL type.

Change the type of the inherit fields in IPAddressChoice (2.2.3) and ASIdentifierChoice (3.2.3) to the following:

   IPAddressChoice     ::= CHOICE {
      inherit              NULL, -- Inherit from Issuer
      addressesOrRanges    SEQUENCE OF IPAddressOrRange }

   ASIdentifierChoice ::= CHOICE {
      inherit             NULL, -- Inherit from Issuer
      asIdsOrRanges       SEQUENCE OF ASIdOrRange }

The associated text describing the inherit fields (2.2.3.5 & 3.2.3.3) can be simplified accordingly.


2.
It seems unnecessary to set these extensions to CRITICAL.  A relying party is not misled by ignoring these extensions -- it simply learns nothing new about IP address and AS allocations.

Perhaps making it CRITICAL is supposed to indicate that the certificate is binding a public key to these addresses instead of any other type of name so the subject (and subjectAltName) fields should be ignored.  If this is the case, it may be better to formulate the extensions as OTHER-NAME types to be used in the subjectAltName extension (in which case no other names needs to be included).

Perhaps making it CRITICAL is supposed to indicate that the certificate should only be used in, say, Secure BGP and not for, say, secure e-mail.  If this is the case, defining a new purpose identifier for the extendedKeyUsage extension may be more appropriate.


3.
Why does everything have to be sorted?  Does it really make it easy or faster for CAs and relying parties?



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, 3 July 2003 8:10 AM
Cc: [e-mail]
Subject: IP addr: 01: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt


	Title		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
	Pages		: 24
	Date		: 2003-7-2
	
This document defines two private X.509 v3 certificate extensions.  The first binds a list of IP address blocks, or prefixes, to the subject of a certificate.  The second binds a list of Autonomous System Identifiers to the subject of a certificate.  These extensions may be used to convey the authorization of the subject to use the IP addresses and Autonomous System identifiers contained in the extensions.

http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-01.txt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62MAMFK088186 for <[e-mail]>; Wed, 2 Jul 2003 15:10:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62MAMMo088185 for ietf-pkix-bks; Wed, 2 Jul 2003 15:10:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62MALFK088179 for <[e-mail]>; Wed, 2 Jul 2003 15:10:21 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23610; Wed, 2 Jul 2003 18:10:19 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
Date: Wed, 02 Jul 2003 18:10:18 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
	Pages		: 24
	Date		: 2003-7-2
	
This document defines two private X.509 v3 certificate extensions.
The first binds a list of IP address blocks, or prefixes, to the
subject of a certificate.  The second binds a list of Autonomous
System Identifiers to the subject of a certificate.  These extensions
may be used to convey the authorization of the subject to use the IP
addresses and Autonomous System identifiers contained in the
extensions.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62E7IFK058019 for <[e-mail]>; Wed, 2 Jul 2003 07:07:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62E7Ic3058017 for ietf-pkix-bks; Wed, 2 Jul 2003 07:07:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.9/8.12.8) with SMTP id h62E7FFK058002 for <[e-mail]>; Wed, 2 Jul 2003 07:07:16 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 8555 invoked by alias); 2 Jul 2003 14:07:14 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 8547 invoked by alias); 2 Jul 2003 14:07:14 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 2 Jul 2003 14:07:14 -0000
Received: (qmail 14317 invoked from network); 2 Jul 2003 14:07:13 -0000
Received: from unknown (HELO ?192.168.1.3?) (172.30.253.111) by mail with SMTP; 2 Jul 2003 14:07:13 -0000
Date: Wed, 02 Jul 2003 23:07:13 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: [e-mail]
Subject: I-D: multi-domain PKI Interoperability
Cc: [e-mail]
Reply-To: [e-mail], [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

As Ryu said in last IETF meeting, I am writing a Inetenet-Draft for
multi-domain PKI interoperability as a best current practice. This fruit is based on several multi-domain PKI interoperability experiments and documents.
# This is an individual submission.

Here is an abstract of this I-D.

	Title		: Memorandum for multi-domain PKI Interoperability
	Author(s)	: M. Shimaoka
	Filename	: draft-shimaoka-multidomain-pki-00.txt
	Pages		: 16
	Date		: June 2003

===== Abstract =====
This memo is used to share the awareness necessary to deployment of
multi-domain PKI. Scope of this memo is to establish trust
relationship and interoperability between plural PKI domains.  Both
single-domain PKI and multi-domain PKI are established by the trust
relationships between Certification Authorities (CAs).  Typical and
primitive PKI models are specified as single-domain PKI.  Multi-
domain PKI established by plural single-domain PKI is categorized as
multi-trust point model and single-trust point model. Multi-trust
point model is based on trust list model, and single-trust point
model is based on cross-certification.
===== Abstract =====

The I-D has already published on IETF repository, but I revised several parts after that.
So, please refer the following URLs:
    http://www.jnsa.org/mpki/
    http://www.jnsa.org/mpki/draft-shimaoka-multidomain-pki-00.txt

URL above invites you to our activity for multi-domain PKI
interoperability framework, as you know as what reported in past IETF
meetings.

If you are interested in this, please let me know.
Thanks in advance for any comments.

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3551)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61JLXFK079828 for <[e-mail]>; Tue, 1 Jul 2003 12:21:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61JLXrZ079827 for ietf-pkix-bks; Tue, 1 Jul 2003 12:21:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61JLWFK079816 for <[e-mail]>; Tue, 1 Jul 2003 12:21:32 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 1 Jul 2003 12:21:28 -0700
Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 Jul 2003 12:21:28 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Jul 2003 12:21:29 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Jul 2003 12:21:28 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 1 Jul 2003 12:21:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: SCVP Questions
Date: Tue, 1 Jul 2003 12:20:46 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP Questions
Thread-Index: AcM/2rutNpncH9htQaKCnpEUCWz+bwAJLrZQ
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 01 Jul 2003 19:21:27.0971 (UTC) FILETIME=[F8347F30:01C34005]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C34005.F98F9F29"

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

See below

=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Faisal
Sent: Tuesday, July 01, 2003 5:36 AM
To: [e-mail]
Subject: SCVP Questions

=20

Hi,

=20

    Following things are not clear to me, can any one please do clear
these:

1.     If SCVPServer goes for revocation checking of QuriedCertificate
and did not find valid revocation information about certificate from
local repository and problem to connect ldap with reason that ldap is
not responding or temperaly off and same with ocsp too. In this case
this should not called as Internal Error, so revocation status should be
Unknown for the certificate.

[Trevor Freeman] If the ldap connection failed - unknown, if it
succeeded but unavailable.


In this case SCVPServer has not any valid OCSPResponse or CRL related
QuriedCertificate and in WantBack revocation information is required, so
how we can handle this case?

2.     If SCVPServer recieves a request with one certificate for query
and found a CRL in which issuer of the certificate is revoked but query
certificate is not revoked in that CRL, what would be the response of
the quried certificate, either Revoked or Good or ?

[Trevor Freeman] Revoked. The chain you describe would fail the
algorithm described in RFC3280 section 6.

3.     If queried certificate is expired then what would be the response
either Revoked or SCVPServer should process for revocation checking of
the certificate?

[Trevor Freeman] certPathNotValid

Also if on expired certificate SCVPServer should send back status as
revoked then what would be the revocation information about Revoked
status? because we have not checked any OCSPResponse or CRL for this
condition.

There are more things but related above, may be your kind replies will
do fix those automatically.

=20

Thanks in advance for replies.

Regards,

Faisal Maqsood

www.ascertia.com

=20


------_=_NextPart_001_01C34005.F98F9F29
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<base href=3D"file:///F:\_BackUp-FM\Email%20Signature\">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:navy;}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>See below</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Faisal<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> </span></font><font =
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Tuesday, July
 01, 2003</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'> </span></font><font size=3D2 face=3DTahoma><span
 style=3D'font-size:10.0pt;font-family:Tahoma'>5:36 =
AM</span></font><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> SCVP =
Questions</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Hi,</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;
Following things are not clear to me, can any one please do clear =
these:</span></font></p>

</div>

<p class=3DMsoNormal =
style=3D'margin-left:72.0pt;text-indent:-18.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>1.</span></font><font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font>If SCVPServer
goes for revocation checking of QuriedCertificate and did not find valid
revocation information about certificate from local repository =
and&nbsp;problem
to connect&nbsp;ldap with reason that ldap is not responding or =
temperaly
off&nbsp;and&nbsp;same with&nbsp;ocsp too. In this case this should not =
called
as Internal Error, so&nbsp;revocation status&nbsp;should be Unknown for =
the
certificate.</p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Trevor Freeman] If the ldap connection failed =
&#8211;
unknown, if it succeeded but unavailable.</span></font></i></b></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><br>
In this case SCVPServer has not any valid OCSPResponse or CRL related =
QuriedCertificate
and in WantBack revocation information is required, so how we can handle =
this
case?</span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:72.0pt;text-indent:-18.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>2.</span></font><font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font>If SCVPServer
recieves a request with one certificate for query and found a CRL in =
which
issuer of the certificate is revoked but query certificate is not =
revoked in
that CRL, what would be the response of the quried certificate, either =
Revoked
or Good or ?</p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Trevor Freeman] Revoked. The chain you describe =
would fail
the algorithm described in RFC3280 section 6.</span></font></i></b></p>

<p class=3DMsoNormal =
style=3D'margin-left:72.0pt;text-indent:-18.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>3.</span></font><font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font>If
queried certificate is expired then what would be the response either =
Revoked
or SCVPServer should process for revocation checking of the =
certificate?</p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Trevor Freeman] </span></font></i></b><b><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold'>certPathNotValid</span></font></b></p>

<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Also if on =
expired
certificate SCVPServer should send back status as revoked then what =
would be
the revocation information about Revoked status? because we have not =
checked
any OCSPResponse or CRL for this condition.</span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>There are more =
things but
related above, may be your kind replies will do fix those =
automatically.</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Thanks in =
advance for
replies.</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Regards,</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Faisal =
Maqsood</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><a
href=3D"http://www.ascertia.com">www.ascertia.com</a></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C34005.F98F9F29--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FNUFK060043 for <[e-mail]>; Tue, 1 Jul 2003 08:23:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61FNUPm060042 for ietf-pkix-bks; Tue, 1 Jul 2003 08:23:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FNRFK060034 for <[e-mail]>; Tue, 1 Jul 2003 08:23:28 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Jul 2003 10:24:45 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: FW: A question about RFC-2560 (OCSP)
Date: Tue, 1 Jul 2003 10:26:35 -0500
Message-ID: <002701c33fe5$28dbf3f0$[e-mail]>
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 01 Jul 2003 15:24:45.0546 (UTC) FILETIME=[E6E66CA0:01C33FE4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggqCQ29u
dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ
YXJ0XzAwMF8wMDIzXzAxQzMzRkJCLjNGQTRFMDMwIg0KDQpUaGlzIGlzIGEgbXVsdGktcGFydCBt
ZXNzYWdlIGluIE1JTUUgZm9ybWF0Lg0KDQotLS0tLS09X05leHRQYXJ0XzAwMF8wMDIzXzAxQzMz
RkJCLjNGQTRFMDMwDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47DQoJY2hhcnNldD0iVVMtQVND
SUkiDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQoNCiANCkhpDQogDQpBbiBPQ1NQ
IHJlc3BvbmRlciBpcyBhdXRob3JpemVkIHRvIHNpZ24gYSByZXNwb25zZSBieSBtZWFucyBvZiB0
cnVzdA0KZGVsZWdhdGlvbi4gVGhpcyBjYW4gb2NjdXIgaW4gMyB3YXlzIGFzIHByZXNjcmliZWQg
YnkgUkZDLTI1NjA6DQogDQoxLglOTyBkZWxlZ2F0aW9uLCB0aGUgQ0EgaXRzZWxmIHNpZ25zIHRo
ZSBPQ1NQIHJlc3BvbnNlDQoyLglFeHBsaWNpdCBkZWxlZ2F0aW9uLCB0aGUgQ0EgaXNzdWVzIGEg
c3BlY2lhbCBjZXJ0aWZpY2F0ZSB0byB0aGUNCk9DU1AgcmVzcG9uZGVyICh3aXRoIHRoZSBFS1Ug
T0NTUFNpZ25pbmcpDQozLglMb2NhbCBjbGllbnQgY29uZmlndXJhdGlvbjogaW4gdGhpcyBjYXNl
IHRoZSBjbGllbnQgaXMNCmluc3RydWN0ZWQgKGJ5IG1lYW5zIG9mIGEgbG9jYWwgY29uZmlndXJh
dGlvbikgdG8gdHJ1c3QgYSBwYXJ0aWN1bGFyDQpyZXNwb25kZXIuIA0KIA0KU28sIHdoZW4gcmVj
ZWl2aW5nIGEgcmVzcG9uc2UsIHRoZSBjbGllbnQgaGFzIHRvIGNoZWNrIHdoaWNoIG9mIHRoZSAz
DQpwb3NzaWJsZSBzY2VuYXJpb3MgaXMgdG8gYmUgYXBwbGllZC4gICANCiANCkhvcGUgdGhpcyBo
ZWxwcywNCiANCk1pZ3VlbCBBIFJvZHJpZ3Vleg0KU2VndXJpREFUQQ0KTWV4aWNvDQogDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9y
ZyBbbWFpbHRvOm93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmddDQpPbiBCZWhhbGYgT2YgWWFz
aXIgS2hhbg0KU2VudDogTWFydGVzLCAwMSBkZSBKdWxpbyBkZSAyMDAzIDA1OjAwIGEubS4NClRv
OiBpZXRmLXBraXhAaW1jLm9yZw0KU3ViamVjdDogQSBxdWVzdGlvbiBhYm91dCBSRkMtMjU2MCAo
T0NTUCkNCiANCkhpLA0KIA0KSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgJ1NpZ25lZCBSZXNwb25z
ZSBBY2NlcHRhbmNlIFJlcXVpcmVtZW50cycgaW4NClJGQy0yNTYwIChPQ1NQKSwgSSBhbSBxdW90
aW5nIHRoZSBwYXJ0IG9mIHRoZSBkb2N1bWVudCByZWxhdGVkIHRvIG15DQpxdWVzdGlvbi4gDQog
DQozLjIgIFNpZ25lZCBSZXNwb25zZSBBY2NlcHRhbmNlIFJlcXVpcmVtZW50cw0KDQogICBQcmlv
ciB0byBhY2NlcHRpbmcgYSBzaWduZWQgcmVzcG9uc2UgYXMgdmFsaWQsIE9DU1AgY2xpZW50cyBT
SEFMTA0KY29uZmlybSB0aGF0Og0KDQogICAxLiBUaGUgY2VydGlmaWNhdGUgaWRlbnRpZmllZCBp
biBhIHJlY2VpdmVkIHJlc3BvbnNlIGNvcnJlc3BvbmRzIHRvDQp0aGF0IHdoaWNoIHdhcyBpZGVu
dGlmaWVkIGluIHRoZSBjb3JyZXNwb25kaW5nIHJlcXVlc3Q7DQogICAyLiBUaGUgc2lnbmF0dXJl
IG9uIHRoZSByZXNwb25zZSBpcyB2YWxpZDsNCiAgIDMuIFRoZSBpZGVudGl0eSBvZiB0aGUgc2ln
bmVyIG1hdGNoZXMgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGUNCnJlcXVlc3QuDQogICA0
LiBUaGUgc2lnbmVyIGlzIGN1cnJlbnRseSBhdXRob3JpemVkIHRvIHNpZ24gdGhlIHJlc3BvbnNl
Lg0KICAgNS4gVGhlIHRpbWUgYXQgd2hpY2ggdGhlIHN0YXR1cyBiZWluZyBpbmRpY2F0ZWQgaXMg
a25vd24gdG8gYmUNCmNvcnJlY3QgKHRoaXNVcGRhdGUpIGlzIHN1ZmZpY2llbnRseSByZWNlbnQu
DQogICA2LiBXaGVuIGF2YWlsYWJsZSwgdGhlIHRpbWUgYXQgb3IgYmVmb3JlIHdoaWNoIG5ld2Vy
IGluZm9ybWF0aW9uIHdpbGwNCmJlIGF2YWlsYWJsZSBhYm91dCB0aGUgc3RhdHVzIG9mIHRoZSBj
ZXJ0aWZpY2F0ZSAobmV4dFVwZGF0ZSkgaXMgZ3JlYXRlcg0KdGhhbiB0aGUgY3VycmVudCB0aW1l
Lg0KUmVxdWlyZW1lbnQgNCBpcyB2ZXJ5IGFtYmlndW91cywgdGhlcmUgY29tZXMgbWFueSBwb3Nz
aWJpbGl0aWVzIHRvDQpzYXRpc2Z5IHRoaXMgcmVxdWlyZW1lbnQgZS5nLg0KIA0KYSkgRUtVIGlu
IHNpZ25lciBjZXJ0aWZpY2F0ZSBtdXN0IGNvbnRhaW4gT0NTUFNpZ25pbmcNCmIpIFNpZ25lciBj
ZXJ0aWZpY2F0ZSBpcyBub3QgcmV2b2tlZA0KYykgU2lnbmVyIGNlcnRpZmljYXRlIGlzIGlzc3Vl
ZCBieSB0aGUgc2FtZSBDQSB0aGF0IGlzc2VkIHRoZSB0YXJnZXQNCmNlcnRpZmljYXRlIHRvIGJl
IGNoZWNrZWQgZm9yIHJldm9jYXRpb24NCmQpIElzc3VlciBvZiB0aGUgc2lnbmVyIGNlcnRpZmlj
YXRlIGlzIGV4cGxpY2l0bHkgdHJ1c3RlZCANCiANCkkgd2FudCB0byBrbm93IHRoZSBleGFjdCBj
aGVjayhzKSB0byBzYXRpc2Z5IHRoZSByZXF1aXJlbXRlbnQgNC4NCiANClRoYW54LA0KIA0KUmVn
YXJkcywNCllhc2lyIEtoYW4NCnd3dy5hc2NlcnRpYS5jb20gDQoNCi0tLS0tLT1fTmV4dFBhcnRf
MDAwXzAwMjNfMDFDMzNGQkIuM0ZBNEUwMzANCkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOw0KCWNo
YXJzZXQ9IlVTLUFTQ0lJIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50
YWJsZQ0KDQoEghAAPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBU
cmFuc2l0aW9uYWwvL0VOIj4NCjxodG1sIHhtbG5zOnY9M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0
LWNvbTp2bWwiID0NCnhtbG5zOm89M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6
b2ZmaWNlIiA9DQp4bWxuczp3PTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndv
cmQiID0NCnhtbG5zOnN0MT0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy
dHRhZ3MiID0NCnhtbG5zPTNEImh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8
aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9M0QiQ29udGVudC1UeXBlIiBDT05URU5UPTNEInRleHQv
aHRtbDsgPQ0KY2hhcnNldD0zRHVzLWFzY2lpIj4NCg0KDQo8bWV0YSBuYW1lPTNEUHJvZ0lkIGNv
bnRlbnQ9M0RXb3JkLkRvY3VtZW50Pg0KPG1ldGEgbmFtZT0zREdlbmVyYXRvciBjb250ZW50PTNE
Ik1pY3Jvc29mdCBXb3JkIDEwIj4NCjxtZXRhIG5hbWU9M0RPcmlnaW5hdG9yIGNvbnRlbnQ9M0Qi
TWljcm9zb2Z0IFdvcmQgMTAiPg0KPGxpbmsgcmVsPTNERmlsZS1MaXN0IGhyZWY9M0QiY2lkOmZp
bGVsaXN0LnhtbEAwMUMzM0ZCQi4zRjc5MTU0MCI+DQo8bzpTbWFydFRhZ1R5cGUgPQ0KbmFtZXNw
YWNldXJpPTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBu
YW1lPTNEInRpbWUiLz4NCjxvOlNtYXJ0VGFnVHlwZSA9DQpuYW1lc3BhY2V1cmk9M0QidXJuOnNj
aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9M0QiY291bnRyeS1y
ZWdpb24iLz4NCjxvOlNtYXJ0VGFnVHlwZSA9DQpuYW1lc3BhY2V1cmk9M0QidXJuOnNjaGVtYXMt
bWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9M0QicGxhY2UiLz4NCjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQogIDxvOkRv
Tm90UmVseU9uQ1NTLz4NCiA8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDx3OldvcmREb2N1bWVudD4NCiAgPHc6
U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0KICA8dzpHcmFtbWFyU3RhdGU+
Q2xlYW48L3c6R3JhbW1hclN0YXRlPg0KICA8dzpEb2N1bWVudEtpbmQ+RG9jdW1lbnRFbWFpbDwv
dzpEb2N1bWVudEtpbmQ+DQogIDx3OkVudmVsb3BlVmlzLz4NCiAgPHc6QnJvd3NlckxldmVsPk1p
Y3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERvY3Vt
ZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6Knti
ZWhhdmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8
c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0Ow0KCW1zby1m
b250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9u
dC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MTYyNzQyMTMxOSAtMjE0NzQ4
MzY0OCA4IDAgNjYwNDcgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h
bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ
bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk
b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpBcmlhbDsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWhhbnNpLWZvbnQt
ZmFtaWx5OkFyaWFsOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOm5hdnk7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ
bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28t
YmlkaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1hc2NpaS1m
b250LWZhbWlseTpBcmlhbDsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJp
ZGktZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtz
aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0
Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM1LjRwdDsNCgltc28tZm9vdGVyLW1hcmdpbjozNS40cHQ7
DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30N
CiAvKiBMaXN0IERlZmluaXRpb25zICovDQogQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzY0Njk0
MDUzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTQzODE0NjY0O30NCkBsaXN0IGwxDQoJe21z
by1saXN0LWlkOjEzNjU2Njc1MzE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt
dGVtcGxhdGUtaWRzOjQ2NTA5NjA2MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw
MyA9DQo2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlz
dCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZl
bDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNv
LWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10
YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6
MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0
IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZl
bDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbgSCEAA6bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0
b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1b
aWYgZ3RlIG1zbyAxMF0+DQo8c3R5bGU+DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi89MjANCiB0
YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCglt
c28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJ
bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGlu
Zy1hbHQ6MGNtIDUuNHB0IDBjbSA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGNtOw0KCW1zby1w
YXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47
DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8
L3N0eWxlPg0KPCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0zRCJlZGl0IiBzcGlkbWF4PTNEIjEwMjYiIC8+DQo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0zRCJl
ZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9M0QiZWRpdCIgZGF0YT0zRCIxIiAvPg0KIDwvbzpzaGFw
ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0zRHdo
aXRlIGxhbmc9M0RFTi1VUyBsaW5rPTNEYmx1ZSB2bGluaz0zRGJsdWUgPQ0Kc3R5bGU9M0QndGFi
LWludGVydmFsOjM2LjBwdCc+DQoNCjxkaXYgY2xhc3M9M0RTZWN0aW9uMT4NCg0KPHAgY2xhc3M9
M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgY29sb3I9M0RuYXZ5IGZhY2U9M0RBcmlhbD48c3Bh
biA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6
bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RN
c29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgY29sb3I9M0RuYXZ5IGZhY2U9M0RBcmlhbD48c3BhbiA9
DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2
eSc+SGk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1h
bD48Zm9udCBzaXplPTNEMiBjb2xvcj0zRG5hdnkgZmFjZT0zREFyaWFsPjxzcGFuID0NCnN0eWxl
PTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48
Zm9udCBzaXplPTNEMiBjb2xvcj0zRG5hdnkgZmFjZT0zREFyaWFsPjxzcGFuID0NCnN0eWxlPTNE
J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5BbiBPQ1NQ
IHJlc3BvbmRlciBpcyBhdXRob3JpemVkIHRvID0NCnNpZ24gYQ0KcmVzcG9uc2UgYnkgbWVhbnMg
b2YgdHJ1c3QgZGVsZWdhdGlvbi4gVGhpcyBjYW4gb2NjdXIgaW4gMyB3YXlzIGFzID0NCnByZXNj
cmliZWQNCmJ5IFJGQy0yNTYwOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs
YXNzPTNETXNvTm9ybWFsPjxmb250IHNpemU9M0QyIGNvbG9yPTNEbmF2eSBmYWNlPTNEQXJpYWw+
PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv
bG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxvbCBzdHls
ZT0zRCdtc28tbWFyZ2luLXRvcC1hbHQ6MGNtJyBzdGFydD0zRDEgdHlwZT0zRDE+DQogPGxpIGNs
YXNzPTNETXNvTm9ybWFsIHN0eWxlPTNEJ2NvbG9yOm5hdnk7bXNvLWxpc3Q6bDEgbGV2ZWwxID0N
CmxmbzM7dGFiLXN0b3BzOmxpc3QgMzYuMHB0Jz48Zm9udA0KICAgICBzaXplPTNEMiBjb2xvcj0z
RG5hdnkgZmFjZT0zREFyaWFsPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6DQogICAgIEFyaWFsJz5OTyBkZWxlZ2F0aW9uLCB0aGUgQ0EgaXRzZWxmIHNpZ25z
IHRoZSBPQ1NQID0NCnJlc3BvbnNlPG86cD48L286cD48L3NwYW4+PC9mb250PjwvbGk+DQogPGxp
IGNsYXNzPTNETXNvTm9ybWFsIHN0eWxlPTNEJ2NvbG9yOm5hdnk7bXNvLWxpc3Q6bDEgbGV2ZWwx
ID0NCmxmbzM7dGFiLXN0b3BzOmxpc3QgMzYuMHB0Jz48Zm9udA0KICAgICBzaXplPTNEMiBjb2xv
cj0zRG5hdnkgZmFjZT0zREFyaWFsPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6DQogICAgIEFyaWFsJz5FeHBsaWNpdCBkZWxlZ2F0aW9uLCB0aGUgQ0EgaXNz
dWVzIGEgc3BlY2lhbCBjZXJ0aWZpY2F0ZSB0byA9DQp0aGUNCiAgICAgT0NTUCByZXNwb25kZXIg
KHdpdGggdGhlIEVLVSA9DQpPQ1NQU2lnbmluZyk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9s
aT4NCiA8bGkgY2xhc3M9M0RNc29Ob3JtYWwgc3R5bGU9M0QnY29sb3I6bmF2eTttc28tbGlzdDps
MSBsZXZlbDEgPQ0KbGZvMzt0YWItc3RvcHM6bGlzdCAzNi4wcHQnPjxmb250DQogICAgIHNpemU9
M0QyIGNvbG9yPTNEbmF2eSBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseToNCiAgICAgQXJpYWwnPkxvY2FsIGNsaWVudCBjb25maWd1cmF0
aW9uOiBpbiB0aGlzIGNhc2UgdGhlIGNsaWVudCBpcyA9DQppbnN0cnVjdGVkDQogICAgIChieSBt
ZWFucyBvZiBhIGxvY2FsIGNvbmZpZ3VyYXRpb24pIHRvIHRydXN0IGEgcGFydGljdWxhciA9DQpy
ZXNwb25kZXIuIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2xpPg0KPC9vbD4NCg0KPHAgY2xh
c3M9M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgY29sb3I9M0RuYXZ5IGZhY2U9M0RBcmlhbD48
c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29s
b3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9
M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgY29sb3I9M0RuYXZ5IGZhY2U9M0RBcmlhbD48c3Bh
biA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6
bmF2eSc+U28sIHdoZW4gcmVjZWl2aW5nIGEgcmVzcG9uc2UsIHRoZSA9DQpjbGllbnQNCmhhcyB0
byBjaGVjayB3aGljaCBvZiB0aGUgMyBwb3NzaWJsZSBzY2VuYXJpb3MgaXMgdG8gYmUgYXBwbGll
ZC48c3Bhbg0Kc3R5bGU9M0QnbXNvLXNwYWNlcnVuOnllcyc+Jm5ic3A7Jm5ic3A7ID0NCjwvc3Bh
bj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48
Zm9udCBzaXplPTNEMiBjb2xvcj0zRG5hdnkgZmFjZT0zREFyaWFsPjxzcGFuID0NCnN0eWxlPTNE
J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48Zm9u
dCBzaXplPTNEMiBjb2xvcj0zRG5hdnkgZmFjZT0zREFyaWFsPjxzcGFuID0NCnN0eWxlPTNEJ2Zv
bnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5Ib3BlIHRoaXMg
PQ0KaGVscHMsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29O
b3JtYWw+PGZvbnQgc2l6ZT0zRDIgY29sb3I9M0RuYXZ5IGZhY2U9M0RBcmlhbD48c3BhbiA9DQpz
dHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3Jt
YWw+PGZvbnQgc2l6ZT0zRDIgY29sb3I9M0RuYXZ5IGZhY2U9M0RBcmlhbD48c3BhbiA9DQpzdHls
ZT0zRCdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+TWln
BIIQAHVlbCBBID0NClJvZHJpZ3VlejxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw
IGNsYXNzPTNETXNvTm9ybWFsPjxmb250IHNpemU9M0QyIGNvbG9yPTNEbmF2eSBmYWNlPTNEQXJp
YWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs
O2NvbG9yOm5hdnknPlNlZ3VyaURBVEE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PD0NCi9wPg0K
DQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3QxOmNvdW50cnktcmVnaW9uPjxzdDE6cGxhY2U+PGZv
bnQgc2l6ZT0zRDIgPQ0KY29sb3I9M0RuYXZ5DQogIGZhY2U9M0RBcmlhbD48c3BhbiA9DQpzdHls
ZT0zRCdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPk1leGlj
bzwvc3Bhbj48L2ZvPQ0KbnQ+PC9zdDE6cGxhY2U+PC9zdDE6Y291bnRyeS1yZWdpb24+PGZvbnQN
CnNpemU9M0QyIGNvbG9yPTNEbmF2eSBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOm5hdnknPjxvOnA+PC9vOnA+
PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxmb250IHNpemU9M0Qy
IGNvbG9yPTNEbmF2eSBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0K
MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvZm9udD48L3A+DQoNCjxkaXYgc3R5bGU9M0QnYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gPQ0KMGNtIDQuMHB0Jz4NCg0KPHAgY2xh
c3M9M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRFRhaG9tYT48c3BhbiA9DQpzdHls
ZT0zRCdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hJz4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLTxicj4NCjxiPjxzcGFuIHN0eWxlPTNEJ2ZvbnQtd2VpZ2h0OmJvbGQnPkZy
b206PC9zcGFuPjwvYj4gPQ0Kb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZw0KW21haWx0bzpv
d25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnXSA8Yj48c3BhbiA9DQpzdHlsZT0zRCdmb250LXdl
aWdodDpib2xkJz5Pbg0KQmVoYWxmIE9mIDwvc3Bhbj48L2I+WWFzaXIgS2hhbjxicj4NCjxiPjxz
cGFuIHN0eWxlPTNEJ2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gTWFydGVzLCAw
MSBkZSBKdWxpbyA9DQpkZSAyMDAzIDwvc3Bhbj48L2ZvbnQ+PHN0MTp0aW1lDQpIb3VyPTNEIjUi
IE1pbnV0ZT0zRCIwIj48Zm9udCBzaXplPTNEMiBmYWNlPTNEVGFob21hPjxzcGFuID0NCnN0eWxl
PTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7DQogZm9udC1mYW1pbHk6VGFob21hJz4wNTowMCBhLm0uPC9z
cGFuPjwvZm9udD48L3N0MTp0aW1lPjxmb250IHNpemU9M0QyDQpmYWNlPTNEVGFob21hPjxzcGFu
IHN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz48YnI+DQo8Yj48
c3BhbiBzdHlsZT0zRCdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiBpZXRmLXBraXhA
aW1jLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPTNEJ2ZvbnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6
PC9zcGFuPjwvYj4gQSBxdWVzdGlvbiBhYm91dCA9DQpSRkMtMjU2MA0KKE9DU1ApPC9zcGFuPjwv
Zm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0z
RDMgZmFjZT0zRCJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToN
CjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0K
PHAgY2xhc3M9M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zREFyaWFsPjxzcGFuID0N
CnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+SGksPC9zcGFu
PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPTNE
TXNvTm9ybWFsPjxmb250IHNpemU9M0QzIGZhY2U9M0QiVGltZXMgTmV3IFJvbWFuIj48c3BhbiA9
DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48Zm9u
dCBzaXplPTNEMiBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOjEwLjBw
dDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5JIGhhdmUgYSBxdWVzdGlvbiBhYm91dCA8ZW0+PGk+PGZv
bnQgPQ0KZmFjZT0zREFyaWFsPjxzcGFuDQpzdHlsZT0zRCdmb250LWZhbWlseTpBcmlhbCc+J1Np
Z25lZCBSZXNwb25zZSBBY2NlcHRhbmNlIFJlcXVpcmVtZW50cycgPQ0KPC9zcGFuPjwvZm9udD48
L2k+PC9lbT5pbg0KUkZDLTI1NjAgKE9DU1ApLCBJIGFtIHF1b3RpbmcgdGhlIHBhcnQgb2YgdGhl
IGRvY3VtZW50IHJlbGF0ZWQgdG8gbXkgPQ0KcXVlc3Rpb24uIDwvc3Bhbj48L2ZvbnQ+PG86cD48
L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48Zm9u
dCBzaXplPTNEMyBmYWNlPTNEIlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9u
dC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8
L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgY29s
b3I9M0RibHVlIGZhY2U9M0RBcmlhbD48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4w
cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+My4yJm5ic3A7IFNpZ25lZCBSZXNwb25z
ZSA9DQpBY2NlcHRhbmNlDQpSZXF1aXJlbWVudHM8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w
Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0z
RDIgZmFjZT0zREFyaWFsPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250
LWZhbWlseTpBcmlhbCc+PGJyPg0KPGZvbnQgY29sb3I9M0RibHVlPjxzcGFuIHN0eWxlPTNEJ2Nv
bG9yOmJsdWUnPiZuYnNwOyZuYnNwOyBQcmlvciB0byA9DQphY2NlcHRpbmcgYQ0Kc2lnbmVkIHJl
c3BvbnNlIGFzIHZhbGlkLCBPQ1NQIGNsaWVudHMgU0hBTEwgY29uZmlybSA9DQp0aGF0Ojwvc3Bh
bj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+
DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxmb250IHNpemU9M0QyIGZhY2U9M0RBcmlhbD48c3Bh
biA9DQpzdHlsZT0zRCdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxicj4N
Cjxmb250IGNvbG9yPTNEYmx1ZT48c3BhbiBzdHlsZT0zRCdjb2xvcjpibHVlJz4mbmJzcDsmbmJz
cDsgMS4gVGhlID0NCmNlcnRpZmljYXRlDQppZGVudGlmaWVkIGluIGEgcmVjZWl2ZWQgcmVzcG9u
c2UgY29ycmVzcG9uZHMgdG8gdGhhdCB3aGljaCB3YXMgPQ0KaWRlbnRpZmllZCBpbg0KdGhlIGNv
cnJlc3BvbmRpbmcgcmVxdWVzdDs8YnI+DQombmJzcDsmbmJzcDsgMi4gVGhlIHNpZ25hdHVyZSBv
biB0aGUgcmVzcG9uc2UgaXMgdmFsaWQ7PGJyPg0KJm5ic3A7Jm5ic3A7IDMuIFRoZSBpZGVudGl0
eSBvZiB0aGUgc2lnbmVyIG1hdGNoZXMgdGhlIGludGVuZGVkID0NCnJlY2lwaWVudCBvZg0KdGhl
IHJlcXVlc3QuPGJyPg0KJm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj0zRHJl
ZD48c3BhbiBzdHlsZT0zRCdjb2xvcjpyZWQnPiA9DQo0LiBUaGUNCnNpZ25lciBpcyBjdXJyZW50
bHkgYXV0aG9yaXplZCB0byBzaWduIHRoZSByZXNwb25zZS48YnI+DQo8L3NwYW4+PC9mb250Pjxm
b250IGNvbG9yPTNEYmx1ZT48c3BhbiBzdHlsZT0zRCdjb2xvcjpibHVlJz4mbmJzcDsmbmJzcDsg
PQ0KNS4gVGhlDQp0aW1lIGF0IHdoaWNoIHRoZSBzdGF0dXMgYmVpbmcgaW5kaWNhdGVkIGlzIGtu
b3duIHRvIGJlIGNvcnJlY3QgPQ0KKHRoaXNVcGRhdGUpIGlzDQpzdWZmaWNpZW50bHkgcmUEggwG
Y2VudC48YnI+DQombmJzcDsmbmJzcDsgNi4gV2hlbiBhdmFpbGFibGUsIHRoZSB0aW1lIGF0IG9y
IGJlZm9yZSB3aGljaCBuZXdlciA9DQppbmZvcm1hdGlvbg0Kd2lsbCBiZSBhdmFpbGFibGUgYWJv
dXQgdGhlIHN0YXR1cyBvZiB0aGUgY2VydGlmaWNhdGUgKG5leHRVcGRhdGUpIGlzID0NCmdyZWF0
ZXINCnRoYW4gdGhlIGN1cnJlbnQgdGltZS48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PG86
cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48
Zm9udCBzaXplPTNEMiBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOjEw
LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5SZXF1aXJlbWVudCA0IGlzIHZlcnkgYW1iaWd1b3Vz
LCB0aGVyZSBjb21lcyBtYW55DQpwb3NzaWJpbGl0aWVzIHRvIHNhdGlzZnkgdGhpcyByZXF1aXJl
bWVudCA9DQplLmcuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxk
aXY+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxmb250IHNpemU9M0QzIGZhY2U9M0QiVGltZXMg
TmV3IFJvbWFuIj48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz
cz0zRE1zb05vcm1hbD48Zm9udCBzaXplPTNEMiBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9
M0QnZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5hKSBFS1UgaW4gc2lnbmVy
IGNlcnRpZmljYXRlIG11c3QgY29udGFpbiA9DQpPQ1NQU2lnbmluZzwvc3Bhbj48L2ZvbnQ+PG86
cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48
Zm9udCBzaXplPTNEMiBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOjEw
LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5iKSBTaWduZXIgY2VydGlmaWNhdGUgaXMgbm90ID0N
CnJldm9rZWQ8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N
Cg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zREFyaWFsPjxzcGFu
ID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+YykgU2ln
bmVyIGNlcnRpZmljYXRlIGlzIGlzc3VlZCBieSB0aGUmbmJzcDtzYW1lIENBID0NCnRoYXQNCmlz
c2VkIHRoZSB0YXJnZXQgY2VydGlmaWNhdGUgdG8gYmUgY2hlY2tlZCBmb3IgPQ0KcmV2b2NhdGlv
bjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj
bGFzcz0zRE1zb05vcm1hbD48Zm9udCBzaXplPTNEMiBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5
bGU9M0QnZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5kKSBJc3N1ZXIgb2Yg
dGhlIHNpZ25lciBjZXJ0aWZpY2F0ZSBpcyBleHBsaWNpdGx5DQp0cnVzdGVkJm5ic3A7PC9zcGFu
PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPTNE
TXNvTm9ybWFsPjxmb250IHNpemU9M0QzIGZhY2U9M0QiVGltZXMgTmV3IFJvbWFuIj48c3BhbiA9
DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48Zm9u
dCBzaXplPTNEMiBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOjEwLjBw
dDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5JIHdhbnQgdG8ga25vdyB0aGUgZXhhY3QgY2hlY2socykg
dG8gc2F0aXNmeSB0aGUNCnJlcXVpcmVtdGVudCA0Ljwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48
L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48Zm9udCBzaXpl
PTNEMyBmYWNlPTNEIlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXpl
Og0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4N
Cg0KPGRpdj4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zREFy
aWFsPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlh
bCc+VGhhbngsPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+
DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxmb250IHNpemU9M0QzIGZhY2U9M0QiVGltZXMgTmV3
IFJvbWFuIj48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0z
RE1zb05vcm1hbD48Zm9udCBzaXplPTNEMiBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0Qn
Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5SZWdhcmRzLDwvc3Bhbj48L2Zv
bnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz0zRE1zb05v
cm1hbD48Zm9udCBzaXplPTNEMiBmYWNlPTNEQXJpYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1z
aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5ZYXNpciBLaGFuPC9zcGFuPjwvZm9udD48
bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFs
Pjxmb250IHNpemU9M0QyIGZhY2U9M0RBcmlhbD48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6
MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxhID0NCmhyZWY9M0QiaHR0cDovL3d3dy5hc2Nl
cnRpYS5jb20iPnd3dy5hc2NlcnRpYS5jb208L2E+Jm5ic3A7PG86cD48L286cD48L3M9DQpwYW4+
PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8
L2h0bWw+DQoNCi0tLS0tLT1fTmV4dFBhcnRfMDAwXzAwMjNfMDFDMzNGQkIuM0ZBNEUwMzAtLQ0K
AAAAAAAAoIIDJjCCAyIwggKLoAMCAQICFTAwMDAwMTAwMDAwMTUwMDAwMDAxMDANBgkqhkiG9w0B
AQUFADCBvjEhMB8GA1UEAxMYQW50b25pbyAgUmVzZW5kaXogIExpbWFzMTEwLwYDVQQJEyhQcml2
LiBTdGEgTHVjaWEgNzMgIDczICAzMDQgIE9saXZhciAgMTIzMQ4wDAYDVQQREwUwMTQwMDELMAkG
A1UEBhMCTVgxDzANBgNVBAgTBk1leGljbzEfMB0GA1UEBxMWQWx2YXJvIE9icmVnb24gIE1leGlj
bzEXMBUGA1UELQMOAFJFTEE3MjExMTQzTDcwHhcNMDMwNTI2MDAwMDAwWhcNMDQwNTI1MDAwMDAw
WjBXMRMwEQYDVQQKEwpTZWd1cmlEQVRBMQ8wDQYDVQQDEwZNYXJzIDMxCzAJBgNVBAYTAk1YMSIw
IAYJKoZIhvcNAQkBFhNtYXJzQHNlZ3VyaWRhdGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQClwcnY08nLbFRVuON9OA51xc4SDcwE9U9m90a/bSsIOtUItopDfaGas3fGadu1ZBBB7S0B
VT/bHkdal+kgjg8SuR4SivRzfR2qUSiwu4hGpXp9r6gqC4lv2pjq4XhW52XWGqm+YKhk4shm8E76
5ZRLmQ6XtZenSvnb+tDULkCQ+QIDAQABo4GBMH8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovLzE5
Mi4xNjguMC4xNzMvY3JsL2xhc3QuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAJ
BgNVHRMEAjAAMAwGA1UdDwQFAwMH6AAwEQYJYIZIAYb4QgEBBAQDAgCgMA0GCSqGSIb3DQEBBQUA
A4GBAJlGHtozmKSKVJRbY6M6ZR+cYWTzS4m+qRsO7uKtmG0obRULSE/H5X4NqZH4PjEuzdq5RZFa
STYX/Gzz1IwIbudpo41EmC1mDyhiUe3QqMO6fQkRI1a/tKG/Ni/RJCYzsUIj2KIA5g6Pe+iHkMuQ
2MUmjhbr1Rj4k1f69PLzG6crMYIEIzCCBB8CAQEwgdgwgb4xITAfBgNVBAMTGEFudG9uaW8gIFJl
c2VuZGl6ICBMaW1hczExMC8GA1UECRMoUHJpdi4gU3RhIEx1Y2lhIDczICA3MyAgMzA0ICBPbGl2
YXIgIDEyMzEOMAwGA1UEERMFMDE0MDAxCzAJBgNVBAYTAk1YMQ8wDQYDVQQIEwZNZXhpY28xHzAd
BgNVBAcTFkFsdmFybyBPYnJlZ29uICBNZXhpY28xFzAVBgNVBC0DDgBSRUxBNzIxMTE0M0w3AhUw
MDAwMDEwMDAwMDE1MDAwMDAwMTAwCQYFKw4DAhoFAKCCAqAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwNzAxMTUyNjM1WjAjBgkqhkiG9w0BCQQxFgQUsVSa8/L8
rCu28j8Q5Ck1pCoeUwAwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggq
hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZI
hvcNAgUwgekGCSsGAQQBgjcQBDGB2zCB2DCBvjEhMB8GA1UEAxMYQW50b25pbyAgUmVzZW5kaXog
IExpbWFzMTEwLwYDVQQJEyhQcml2LiBTdGEgTHVjaWEgNzMgIDczICAzMDQgIE9saXZhciAgMTIz
MQ4wDAYDVQQREwUwMTQwMDELMAkGA1UEBhMCTVgxDzANBgNVBAgTBk1leGljbzEfMB0GA1UEBxMW
QWx2YXJvIE9icmVnb24gIE1leGljbzEXMBUGA1UELQMOAFJFTEE3MjExMTQzTDcCFTAwMDAwMTAw
MDAwMTUwMDAwMDAxMDCB6wYLKoZIhvcNAQkQAgsxgduggdgwgb4xITAfBgNVBAMTGEFudG9uaW8g
IFJlc2VuZGl6ICBMaW1hczExMC8GA1UECRMoUHJpdi4gU3RhIEx1Y2lhIDczICA3MyAgMzA0ICBP
bGl2YXIgIDEyMzEOMAwGA1UEERMFMDE0MDAxCzAJBgNVBAYTAk1YMQ8wDQYDVQQIEwZNZXhpY28x
HzAdBgNVBAcTFkFsdmFybyBPYnJlZ29uICBNZXhpY28xFzAVBgNVBC0DDgBSRUxBNzIxMTE0M0w3
AhUwMDAwMDEwMDAwMDE1MDAwMDAwMTAwDQYJKoZIhvcNAQEBBQAEgYCa0A2pOB3Oz0vJ8XySYK42
alnNN2S8dw01RnqypOzS6zNbDgUAAKIdCBy6fW3HjddZa3dnDwgHukFlDa2+/Wxq+1X9sAkaZY4c
e0iALEuOzPpCHAvtN0s/BZ03g2jAEH26Jn2uOmdYKY4oNHTN9JW2Yw0ZVIaUAUdhw+Mi8aOIxgAA
AAAAAA==



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61CcoFK051498 for <[e-mail]>; Tue, 1 Jul 2003 05:38:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61CcoOk051497 for ietf-pkix-bks; Tue, 1 Jul 2003 05:38:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61CccFK051490 for <[e-mail]>; Tue, 1 Jul 2003 05:38:43 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.193.60]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h61CbsJG026793 for <[e-mail]>; Tue, 1 Jul 2003 18:37:55 +0600 (PKST)
Message-ID: <007f01c33fcd$4e232ec0$1400a8c0@ascertiafm>
From: "Faisal" <[e-mail]>
To: <[e-mail]>
Subject: SCVP Questions
Date: Tue, 1 Jul 2003 17:35:50 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0079_01C33FF7.3692ACC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0079_01C33FF7.3692ACC0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_007A_01C33FF7.3692ACC0"


------=_NextPart_001_007A_01C33FF7.3692ACC0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

    Following things are not clear to me, can any one please do clear =
these:
  1.. If SCVPServer goes for revocation checking of QuriedCertificate =
and did not find valid revocation information about certificate from =
local repository and problem to connect ldap with reason that ldap is =
not responding or temperaly off and same with ocsp too. In this case =
this should not called as Internal Error, so revocation status should be =
Unknown for the certificate.
  In this case SCVPServer has not any valid OCSPResponse or CRL related =
QuriedCertificate and in WantBack revocation information is required, so =
how we can handle this case?
  2.. If SCVPServer recieves a request with one certificate for query =
and found a CRL in which issuer of the certificate is revoked but query =
certificate is not revoked in that CRL, what would be the response of =
the quried certificate, either Revoked or Good or ?
  3.. If queried certificate is expired then what would be the response =
either Revoked or SCVPServer should process for revocation checking of =
the certificate?
  Also if on expired certificate SCVPServer should send back status as =
revoked then what would be the revocation information about Revoked =
status? because we have not checked any OCSPResponse or CRL for this =
condition.
There are more things but related above, may be your kind replies will =
do fix those automatically.

Thanks in advance for replies.
Regards,
Faisal Maqsood
www.ascertia.com


------=_NextPart_001_007A_01C33FF7.3692ACC0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3D"file://F:\_BackUp-FM\Email Signature\">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Following things are not clear to me, can any =
one please=20
do clear these:</DIV>
<OL>
  <LI>If SCVPServer goes for revocation checking of QuriedCertificate =
and did=20
  not find valid revocation information about certificate from local =
repository=20
  and&nbsp;problem to connect&nbsp;ldap with reason that ldap is not =
responding=20
  or temperaly off&nbsp;and&nbsp;same with&nbsp;ocsp too. In this case =
this=20
  should not called as Internal Error, so&nbsp;revocation =
status&nbsp;should be=20
  Unknown for the certificate.<BR>In this case SCVPServer has not any =
valid=20
  OCSPResponse or CRL related QuriedCertificate and in WantBack =
revocation=20
  information is required, so how we can handle this case?</LI>
  <LI>If SCVPServer recieves a request with one certificate for query =
and found=20
  a CRL in which issuer of the certificate is revoked but query =
certificate is=20
  not revoked in that CRL, what would be the response of the quried =
certificate,=20
  either Revoked or Good or ?</LI>
  <LI>If queried certificate is expired then what would be the response =
either=20
  Revoked or SCVPServer should process for revocation checking of the=20
  certificate?<BR>Also if on expired certificate SCVPServer should send =
back=20
  status as revoked then what would be the revocation information about =
Revoked=20
  status? because we have not checked any OCSPResponse or CRL for this=20
  condition.</LI></OL>
<DIV>There are more things but related above, may be your kind replies =
will do=20
fix those automatically.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advance for replies.</DIV>
<DIV>Regards,</DIV>
<DIV>Faisal Maqsood</DIV>
<DIV><A href=3D"http://www.ascertia.com">www.ascertia.com</A></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_007A_01C33FF7.3692ACC0--

------=_NextPart_000_0079_01C33FF7.3692ACC0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

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

------=_NextPart_000_0079_01C33FF7.3692ACC0--



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

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-12.txt
	Pages		: 44
	Date		: 2003-6-30
	
SCVP allows a client to offload certificate handling to a server.  
The server can provide 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 revocation 
status.  SCVP has many purposes, including simplifying client 
implementations and allowing companies to centralize trust and 
policy management.

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61A4QFK034796 for <[e-mail]>; Tue, 1 Jul 2003 03:04:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61A4QBC034795 for ietf-pkix-bks; Tue, 1 Jul 2003 03:04:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61A4AFK034675 for <[e-mail]>; Tue, 1 Jul 2003 03:04:11 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertia3 (host136.worldcall.net.pk [203.81.195.136] (may be forged)) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h61A3BJG016319 for <[e-mail]>; Tue, 1 Jul 2003 16:03:12 +0600 (PKST)
Message-ID: <004a01c33fb8$2e6e9fc0$[e-mail]>
Reply-To: "Yasir Khan" <[e-mail]>
From: "Yasir Khan" <[e-mail]>
To: <[e-mail]>
Subject: A question about RFC-2560 (OCSP)
Date: Tue, 1 Jul 2003 14:59:34 +0500
Organization: Ascertia Limited.
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0040_01C33FE1.6261E480"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0040_01C33FE1.6261E480
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0041_01C33FE1.6261E480"


------=_NextPart_001_0041_01C33FE1.6261E480
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I have a question about 'Signed Response Acceptance Requirements' in =
RFC-2560 (OCSP), I am quoting the part of the document related to my =
question.=20

3.2  Signed Response Acceptance Requirements

   Prior to accepting a signed response as valid, OCSP clients SHALL =
confirm that:

   1. The certificate identified in a received response corresponds to =
that which was identified in the corresponding request;
   2. The signature on the response is valid;
   3. The identity of the signer matches the intended recipient of the =
request.
   4. The signer is currently authorized to sign the response.
   5. The time at which the status being indicated is known to be =
correct (thisUpdate) is sufficiently recent.
   6. When available, the time at or before which newer information will =
be available about the status of the certificate (nextUpdate) is greater =
than the current time.

Requirement 4 is very ambiguous, there comes many possibilities to =
satisfy this requirement e.g.

a) EKU in signer certificate must contain OCSPSigning
b) Signer certificate is not revoked
c) Signer certificate is issued by the same CA that issed the target =
certificate to be checked for revocation
d) Issuer of the signer certificate is explicitly trusted=20

I want to know the exact check(s) to satisfy the requiremtent 4.

Thanx,

Regards,
Yasir Khan
www.ascertia.com=20

------=_NextPart_001_0041_01C33FE1.6261E480
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3502.5390" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have a question about <EM>'Signed =
Response=20
Acceptance Requirements' </EM>in RFC-2560 (OCSP), I am quoting the part =
of the=20
document related to my question. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2>3.2&nbsp; Signed =
Response Acceptance=20
Requirements</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR><FONT color=3D#0000ff>&nbsp;&nbsp; =
Prior to=20
accepting a signed response as valid, OCSP clients SHALL confirm=20
that:</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR><FONT color=3D#0000ff>&nbsp;&nbsp; =
1. The=20
certificate identified in a received response corresponds to that which =
was=20
identified in the corresponding request;<BR>&nbsp;&nbsp; 2. The =
signature on the=20
response is valid;<BR>&nbsp;&nbsp; 3. The identity of the signer matches =
the=20
intended recipient of the request.<BR>&nbsp;&nbsp;<FONT color=3D#ff0000> =
4. The=20
signer is currently authorized to sign the =
response.<BR></FONT>&nbsp;&nbsp; 5.=20
The time at which the status being indicated is known to be correct =
(thisUpdate)=20
is sufficiently recent.<BR>&nbsp;&nbsp; 6. When available, the time at =
or before=20
which newer information will be available about the status of the =
certificate=20
(nextUpdate) is greater than the current time.<BR></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Requirement 4 is very ambiguous, there =
comes many=20
possibilities to satisfy this requirement e.g.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>a) EKU in signer certificate must =
contain=20
OCSPSigning</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>b) Signer certificate is not =
revoked</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>c) Signer certificate is issued by =
the&nbsp;same CA=20
that issed the target certificate to be checked for =
revocation</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>d) Issuer of the signer certificate is =
explicitly=20
trusted&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I want to know the exact check(s) to =
satisfy the=20
requiremtent 4.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanx,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Yasir Khan</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ascertia.com">www.ascertia.com</A>&nbsp;</DIV></FONT><=
/BODY></HTML>

------=_NextPart_001_0041_01C33FE1.6261E480--

------=_NextPart_000_0040_01C33FE1.6261E480
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK3TCCAzEw
ggIZoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMB4XDTAzMDMwNDA4MTI1N1oXDTEyMDczMDEw
NDIyOVowYDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAy
IENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnRehtg8oWu+jYIkNJVR1ueHs7k8fClUiqUsrjmhuaI6SGjw0eusF
FCCnDN2URjk+Un2OFHa3fn0lRFes/rIXvV0aB8pZGp8XJLO6u3pdfKJGnVeBtgBUr/YkXT/APo+z
pp6a52+VjOEA8tcsfkco+Ml4quvZRSQ6/5hvDlEnm08CAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUc/Pyi9HYduL1F1K9IjZs+KkJi3QwNQYI
KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhl3d3cuZ2xvYmFsdHJ1c3RmaW5kZXIuY29tMB8GA1Ud
IwQYMBaAFLFTcaAo/ecMU5odaxA87sgazV7OMA0GCSqGSIb3DQEBBQUAA4IBAQAWgwuPN1Kt4P+g
mBe25iHuepjjWcslDjZaC65ZxQuGjr/Aj7eKtBwpvw+01S4r9QIKQeT0DqlcFJlf3mDa6S25ZKxR
hUM74fxSYvfT1hAFd7NMZ2BYSj5bGHX5LWFQi1REDthiggjUt5QUGj+OVDfqBakynkiYMinw+NV0
gdRzMyhE3j3nWzeXrOXOmzea3o4bsLK2yCAJ6v+VjjTs+gBlCIE2aqSdctX2JOFJLQUyWlArBqZ9
CEdVW+iYS7PYRnOddXLiX3EC/7+MlbNMZSW234XzWQxrNqF8JzUXbYHm3jDMsprDdeC8RtiYAhQa
T/Ogeq21ndR7phpmrMQqYCSBMIIDajCCAlKgAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQswCQYD
VQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwHhcN
MDMwMzA0MDgwNjEyWhcNMTMwMzA0MDgwMTI3WjA7MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNj
ZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDR+NPebia/iGElNG3QI9TlQSWE+vwhh9N1p608htxwX3HG2PREDou8hP/r3pIkkJEs
flGxt3RVXK+Ut7IyKKB17rhlUSGmrqaRL2fAxyCsCbtak6uLqh7afDYesI1ozLn4sYMFeFWGCWKk
kNBzGfDvKebjXAz9yNxhFyLGbB+ZUkEsfjQA3GJ4Dza4FAbWUH/Q9jWpd8RU9Wx9Hi+QTfXOTaaW
Tn+QMRg9QWuP6pklSsGA65j9YWoBd+ONtSEUM0aX3p/iuecSqC/IjfSxa7hWCskQR+bzqg3xMJTa
R1JpCQds6Z1OqJX5R3UEh71FaxC2TTMgGhNDhwVuoxEgSPhlAgMBAAGjeTB3MA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSxU3GgKP3nDFOaHWsQPO7IGs1ezjA1Bggr
BgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20wDQYJKoZI
hvcNAQEFBQADggEBAKRrsf6/A8LzMqEFJcKl3pq41fPXH7gDLbayGYxvRJ15LRMwxy6A8A2SrY5r
V8u8PStKcMGKj/1R4q1zY/h2TH0eIHDNzIcXiAndZFNBIRPskQ1qIKIlTtO/TYC1f+qss9r7eKcw
Yk90WhdkdZ0k/r21Z7JQMtLGvgO+2Mc4LEb4f1Li/TdB3M0dBq0nRrDX5wiM3hoRbYkWn+0rNtHl
4fVqp5M0S9BeWud/jNIiPu2OSFCdiXDgYVYP56OfVYHuUQuTGfsRP8EI3uUE5RFqIPBj+Vx/Dwzt
/LnNR2CfKv6HPS5AstKZWr04k/RKserIBmJLuxohgfnUuLWJovLFPJkwggQ2MIIDn6ADAgECAgEH
MA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEmMCQGA1UE
CxMdQ2xhc3MgMiBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxFjAUBgNVBAMTDUFzY2VydGlhIENBIDIw
HhcNMDMwMzA1MDYyOTE1WhcNMDQwMzA1MDYwOTM0WjBLMQswCQYDVQQGEwJHQjERMA8GA1UEChMI
QXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYDVQQDEwpZYXNpciBLaGFuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+lV3AAYAfCQ6zjrenn1zqmT2Zm/7hFEA50MI3LEIFLX73
OW7/Kt6hovwHNM4E/AKd0XkCjQnhGcrR7aNS9MWRXm1z/v8T0tpzXlZ0N9OGzrg3Ls8+M2DRnYPP
e2hxhwVF3NcG1Sm8PusSuZ/f17lhyt7Bvo1yyRfxjDP0fdOf1wIDAQABo4ICEzCCAg8wDgYDVR0P
AQH/BAQDAgP4MAwGA1UdEwEB/wQCMAAwggEDBgNVHSAEgfswgfgwgfUGCisGAQQB/EkBAgEwgeYw
geMGCCsGAQUFBwICMIHWGoHTVGhpcyBjZXJ0aWZpY2F0ZSBpcyBmb3IgdGhlIHNvbGUgdXNlIG9m
IEFzY2VydGlhLCBhbmQgaXRzIGN1c3RvbWVycy4gQXNjZXJ0aWEgYWNjZXB0cyBubyBsaWFiaWxp
dHkgZm9yIGFueSBjbGFpbSBleGNlcHQgYXMgZXhwcmVzc2x5IHByb3ZpZGVkIGluIGl0cyBDZXJ0
aWZpY2F0ZSBQb2xpY3ksIHdoaWNoIGlzIGF2YWlsYWJsZSBmcm9tIGluZm9AYXNjZXJ0aWEuY29t
LjAdBgNVHQ4EFgQUR/NebTQ3/3TBMPcGT2VoVG2rfEgwTQYDVR0fBEYwRDBCoECgPoY8aHR0cDov
L3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Jscy9Bc2NlcnRpYUNBMi9jbGFzczIuY3JsMDUG
CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTAiBgNV
HREEGzAZgRd5YXNpci5raGFuQGFzY2VydGlhLmNvbTAfBgNVHSMEGDAWgBRz8/KL0dh24vUXUr0i
Nmz4qQmLdDANBgkqhkiG9w0BAQUFAAOBgQA2fBKsHdZaYDQdZrGUK5nSpXm80r/lpXL7mWOiFTZV
CcNzi0lgyQnTsH++/HGgIVULy8kx4/2znthI378S+XKwRBitAStvx05cNUJlyyyi/Ff/Ogtncgls
+9xFgWm8dluXMFUstp0pdzMr7EnNwT2a8h0i3aoHKSs5hpFg0p/REDGCAcgwggHEAgEBMGUwYDEL
MAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAyIENlcnRpZmlj
YXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMgIBBzAJBgUrDgMCGgUAoIG6MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDcwMTA5NTkzNFowIwYJ
KoZIhvcNAQkEMRYEFPD0tI2q5CFTaf881/o3NNXDvtt8MFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABIGAe6AtWyJadeThw+AQ8MPGHPtTtqAXYQ/2jTjT
yfLXo0lSWN9M/c68HcMY+GHhoo4Pt2veAyy5oLC4IfoW4xqgZvzZx4Q0Y5nO6bZtnUz+80ljU39w
2kn9OTdN7eJCiUk4KX/nnkYVxtmk8wxo/kypb1weyrxub32xRo/YHqi84Z4AAAAAAAA=

------=_NextPart_000_0040_01C33FE1.6261E480--