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

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2003 12:01:04 -0400

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.

---

From: "todd glassey" <[email-masked]>
Date: Thu, 31 Jul 2003 17:56:59 -0700

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" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 31, 2003 9:01 AM
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)

> standard, to reflect the reality of the dominant implementation.

Reply-To: <[email-masked]>
From: "Steven Legg" <[email-masked]>
To: "'David Chadwick'" <[email-masked]>, "'PKIX'" <[email-masked]>
Subject: RE: LDAPv3 Profile Issue
Date: Fri, 1 Aug 2003 15:08:34 +1000
Importance: Normal
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research 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
>
> *****************************************************************

Reply-To: <[email-masked]>
From: "Steven Legg" <[email-masked]>
To: "'David Chadwick'" <[email-masked]>, "'PKIX'" <[email-masked]>
Subject: RE: Issues in LDAP schema IDs
Date: Fri, 1 Aug 2003 14:14:19 +1000
Importance: Normal
Sender: [email-masked]

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 

From: "todd glassey" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 31 Jul 2003 17:56:59 -0700
Sender: [email-masked]

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" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 31, 2003 9:01 AM
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)

> standard, to reflect the reality of the dominant implementation.

Date: Thu, 31 Jul 2003 14:59:30 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 1 Aug 2003 06:52:39 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 31 Jul 2003 12:01:04 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked]
Sender: [email-masked]

Peter,

Steve

From: "Nikolas Mihalopoulos" <[email-masked]>
To: <[email-masked]>
Subject: Issuer field on Certificates
Date: Thu, 31 Jul 2003 18:01:52 +0300
Importance: Normal
Sender: [email-masked]

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.: (30) 210 3727700, Fax: (30) 210 3223694
Direct:(30) 210 3727765
Email: [email-masked]
 
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

Date: Thu, 31 Jul 2003 09:53:56 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

From: "Dean Adams" <[email-masked]>
To: <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Thu, 31 Jul 2003 12:12:16 +0100
Importance: Normal
Sender: [email-masked]

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

From: "Dean Adams" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Thu, 31 Jul 2003 11:42:26 +0100
Importance: Normal
Sender: [email-masked]

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" <[email-masked]>
> Sent by: [email-masked]
> 07/29/2003 04:37 PM
>
>
>         To:     <[email-masked]>
>         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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Russ Housley
> Sent: 29 July 2003 16:56
> To: [email-masked]
> Cc: [email-masked]
> 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 <[email-masked]> 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.
>
>
>
>
>
>

Reply-To: <[email-masked]>
From: "Dean Scotson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Thu, 31 Jul 2003 10:31:16 +0100
Organization: Trustis Ltd
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: 30 July 2003 16:37
To: Dean Adams
Cc: [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
07/29/2003 04:37 PM

        To:     <[email-masked]>
        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: [email-masked] [mailto:[email-masked]]On
Behalf Of Russ Housley
Sent: 29 July 2003 16:56
To: [email-masked]
Cc: [email-masked]
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 <[email-masked]> 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.

Date: Thu, 31 Jul 2003 09:30:09 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: Clarification on XMPP log for certificate types
Date: Wed, 30 Jul 2003 21:12:22 -0700
Importance: Normal
Sender: [email-masked]

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 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Comments on draft-ietf-pkix-sonof3039-01.txt
Date: Wed, 30 Jul 2003 18:12:06 -0700
Importance: Normal
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: <[email-masked]>, "'Russ Housley'" <[email-masked]>, "'Steve Bellovin'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-07.txt
Date: Wed, 30 Jul 2003 17:45:41 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Wednesday, July 30, 2003 12:48 AM
> To: [email-masked]; 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
> 
> 
> 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>
Cc: "'pkix'" <[email-masked]>
Subject: SCVP Comment
Date: Wed, 30 Jul 2003 16:29:54 -0700
Importance: Normal
Sender: [email-masked]

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

To: "Dean Adams" <[email-masked]>
Cc: [email-masked]
Subject: RE: Why is privateKeyUsagePeriod deprecated?
From: Tom Gindin <[email-masked]>
Date: Wed, 30 Jul 2003 11:37:04 -0400
Sender: [email-masked]

        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" <[email-masked]>
Sent by: [email-masked]
07/29/2003 04:37 PM

        To:     <[email-masked]>
        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: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: 29 July 2003 16:56
To: [email-masked]
Cc: [email-masked]
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 <[email-masked]> 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.

Date: Wed, 30 Jul 2003 10:01:36 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 30 Jul 2003 09:45:10 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: Russ Housley <[email-masked]>, Dean Adams <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Wed, 30 Jul 2003 23:21:08 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 30 Jul 2003 11:19:22 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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

Date: Wed, 30 Jul 2003 11:07:25 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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

Date: Wed, 30 Jul 2003 10:07:55 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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

From: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 30 Jul 2003 08:07:32 GMT
Subject: RE: RE: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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

Date: Wed, 30 Jul 2003 10:02:24 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>, Dean Adams <[email-masked]>
CC: [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Russ Housley
>> Sent: 29 July 2003 16:56
>> To: [email-masked]
>> Cc: [email-masked]
>> 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 <[email-masked]> 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.
> 
> 
> 

Date: Wed, 30 Jul 2003 09:47:47 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked], Russ Housley <[email-masked]>, Steve Bellovin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-07.txt
Sender: [email-masked]

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

Date: Tue, 29 Jul 2003 19:56:50 -0400
To: "Dean Adams" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Russ Housley
>Sent: 29 July 2003 16:56
>To: [email-masked]
>Cc: [email-masked]
>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 <[email-masked]> 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.

From: "Dean Adams" <[email-masked]>
To: <[email-masked]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Tue, 29 Jul 2003 21:37:02 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: 29 July 2003 16:56
To: [email-masked]
Cc: [email-masked]
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 <[email-masked]> 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.

Date: Tue, 29 Jul 2003 12:38:06 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-pi-07.txt
Date: Tue, 29 Jul 2003 12:15:10 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 29 Jul 2003 11:56:11 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 29 Jul 2003 15:57:08 +0200
From: Peter Gietz <[email-masked]>
Organization: DAASI International GmbH
To: David Chadwick <[email-masked]>
CC: Antonio Lioy <[email-masked]>, Wen-Cheng Wang <[email-masked]>, =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, PKIX <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

Date: Tue, 29 Jul 2003 12:37:46 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
From: Tom Gindin <[email-masked]>
Date: Mon, 28 Jul 2003 19:21:14 -0400
Sender: [email-masked]

        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" <[email-masked]>
Sent by: [email-masked]
07/27/2003 08:20 PM

        To:     [email-masked], [email-masked]
        cc:     [email-masked]
        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.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "'pkix'" <[email-masked]>
Subject: WG Last Call draft-ietf-pkix-SCVP-12.txt
Date: Mon, 28 Jul 2003 15:08:01 -0700
Importance: Normal
Sender: [email-masked]

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

Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: "Adrian McCullagh" <[email-masked]>
Date: Tue, 29 Jul 2003 07:22:32 +1000
Sender: [email-masked]

--------------------------------------------------------------------
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 61 7 3258 6666
Facsimile 61 7 3258 6444
http://www.freehills.com

                                                                                                        
                          [email-masked].  To:    [email-masked], [email-masked]      
                          ac.nz (Peter          cc:    [email-masked], [email-masked],         
                          Gutmann)                     [email-masked]                             
                          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 <[email-masked]> 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.

Date: Mon, 28 Jul 2003 18:02:51 +0200
From: Leif Johansson <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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

Date: Mon, 28 Jul 2003 11:56:53 -0400
To: Leif Johansson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked]
Sender: [email-masked]

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

Date: Mon, 28 Jul 2003 17:29:16 +0200
From: Leif Johansson <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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

Date: Mon, 28 Jul 2003 11:12:44 -0400
To: Leif Johansson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked]
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-11.txt
Date: Mon, 28 Jul 2003 11:07:29 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure: Logotypes in
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-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 [email-masked]
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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sca-00.txt
Date: Mon, 28 Jul 2003 11:07:34 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 28 Jul 2003 10:58:11 -0400
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 28 Jul 2003 16:57:57 +0200
From: Leif Johansson <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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

Date: Mon, 28 Jul 2003 10:47:16 -0400
To: Leif Johansson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked]
Sender: [email-masked]

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

From: "todd glassey" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Mon, 28 Jul 2003 06:33:57 -0700
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, July 28, 2003 1:25 AM
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)

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

From: <[email-masked]>
To: <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Date: Mon, 28 Jul 2003 11:25:01 +0200
Importance: Normal
Sender: [email-masked]

> 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

Date: Mon, 28 Jul 2003 20:25:47 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Mon, 28 Jul 2003 19:21:00 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Sun, 27 Jul 2003 19:40:55 -0700
To: "Von Welch" <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Draft-ietf-pkix-proxy-06.txt
Sender: [email-masked]

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

From: "Von Welch" <[email-masked]>
Date: Sun, 27 Jul 2003 21:14:51 -0500
To: <[email-masked]>
Cc: "'pkix'" <[email-masked]>, <[email-masked]>, "'Russ Housley'" <[email-masked]>
Subject: RE: Draft-ietf-pkix-proxy-06.txt
Sender: [email-masked]

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.

From: "bonny joy" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
Date: Mon, 28 Jul 2003 00:20:48 +0000
Sender: [email-masked]

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.

Date: Sun, 27 Jul 2003 10:31:20 +0200
From: Leif Johansson <[email-masked]>
CC: [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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

To: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked] (Peter Gutmann)
Subject: Re: Why is privateKeyUsagePeriod deprecated?
From: Tom Gindin <[email-masked]>
Date: Sat, 26 Jul 2003 21:42:35 -0400
Sender: [email-masked]

        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 <[email-masked]>
07/25/2003 01:45 PM

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

At 21:02 +1200 7/25/03, Peter Gutmann wrote:
>Tom Gindin <[email-masked]> 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

Date: Sat, 26 Jul 2003 16:39:49 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Von Welch'" <[email-masked]>, <[email-masked]>
Cc: "'pkix'" <[email-masked]>, <[email-masked]>, "'Russ Housley'" <[email-masked]>
Subject: RE: Draft-ietf-pkix-proxy-06.txt
Date: Fri, 25 Jul 2003 20:56:13 -0700
Importance: Normal
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-01.txt
Date: Sat, 26 Jul 2003 00:48:56 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: den 25 juli 2003 21:29
Cc: [email-masked]
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:
	[email-masked].
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.

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Document Action: 'Internet X.509 Public Key  Infrastructure Certificate Policy and Certification Practices  Framework' to an Informational RFC 
Date: Fri, 25 Jul 2003 16:48:25 -0400
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dnstrings-02.txt
Date: Fri, 25 Jul 2003 15:28:41 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-01.txt
Date: Fri, 25 Jul 2003 15:28:37 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

Date: Fri, 25 Jul 2003 13:45:54 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 21:02 +1200 7/25/03, Peter Gutmann wrote:
>Tom Gindin <[email-masked]> 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

Date: Fri, 25 Jul 2003 13:44:51 -0400
To: bonny <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

Subject: draft-ietf-pkix-scvp-12.txt
To: [email-masked]
From: "Frank Balluffi" <[email-masked]>
Date: Fri, 25 Jul 2003 13:34:32 -0400
Sender: [email-masked]

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.

Date: Fri, 25 Jul 2003 13:20:13 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: <[email-masked]>, Michael =?iso-8859-1?Q?Str=F6der?=  <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

From: "Wen-Cheng Wang" <[email-masked]>
To: "Masaki SHIMAOKA" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Fri, 25 Jul 2003 17:45:35 +0800
Sender: [email-masked]

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

Date: Fri, 25 Jul 2003 21:02:37 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Fri, 25 Jul 2003 19:42:00 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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

From: [email-masked]
To: "Stephen Kent" <[email-masked]>
Cc: =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs
Date: Thu, 24 Jul 2003 16:57:31 -0600
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
Cc: "Michael Ströder" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 24, 2003 3:17 PM
Subject: Re: Microsoft and multi-valued RDNs

>
> At 12:53 -0600 7/24/03, [email-masked] 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
>

Content-class: urn:content-classes:message
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 24 Jul 2003 15:02:38 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, July 24, 2003 2:20 PM
To: Trevor Freeman
Cc: [email-masked]; Michael Ströder; [email-masked]
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

Date: Thu, 24 Jul 2003 17:20:12 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: <[email-masked]>, Michael =?iso-8859-1?Q?Str=F6der?=  <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 24 Jul 2003 17:17:20 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs
Cc: Michael =?iso-8859-1?Q?Str=F6der?=  <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 12:53 -0600 7/24/03, [email-masked] 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

Content-class: urn:content-classes:message
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 24 Jul 2003 13:40:28 -0700
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 24, 2003 9:15 AM
To: Michael Ströder; [email-masked]
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 =
[email-masked], 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" <[email-masked]>
To: <[email-masked]>
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.

From: [email-masked]
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 24 Jul 2003 10:15:25 -0600
HOP-COUNT: 1
Sender: [email-masked]

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

From: [email-masked]
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs
Date: Thu, 24 Jul 2003 12:53:22 -0600
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 24, 2003 10:56 AM
Subject: Re: Microsoft and multi-valued RDNs

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

From: [email-masked]
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs
Date: Thu, 24 Jul 2003 12:53:22 -0600
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 24, 2003 10:56 AM
Subject: Re: Microsoft and multi-valued RDNs

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

Date: Thu, 24 Jul 2003 18:56:30 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Microsoft and multi-valued RDNs
Sender: [email-masked]

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

From: [email-masked]
To: =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Thu, 24 Jul 2003 10:15:25 -0600
Sender: [email-masked]

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

Date: Thu, 24 Jul 2003 09:22:13 -0400
To: "Al Arsenault" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: <[email-masked]>
Sender: [email-masked]

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.

Date: Thu, 24 Jul 2003 09:12:22 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked]
Sender: [email-masked]

At 22:43 +1200 7/24/03, Peter Gutmann wrote:
>=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> 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

Date: Thu, 24 Jul 2003 09:09:22 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: draft minutes
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 24 Jul 2003 14:40:15 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-07.txt
Date: Wed, 23 Jul 2003 15:15:41 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Alice Sturgeon" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Thu, 24 Jul 2003 08:23:56 -0400
Importance: Normal
Sender: [email-masked]

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Denis Pinkas
Sent: Tuesday, July 08, 2003 11:19 AM
Cc: [email-masked]
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

Date: Thu, 24 Jul 2003 23:42:31 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: [email-masked]
Sender: [email-masked]

>>Elaborate enough?
>Nope.

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

Peter.

Date: Thu, 24 Jul 2003 13:02:13 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

Peter Gutmann wrote:
> Michael_Ströder <[email-masked]> 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.

Date: Thu, 24 Jul 2003 22:43:19 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> 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.

Date: Thu, 24 Jul 2003 12:08:57 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft minutes
Sender: [email-masked]

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

From: <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: "Diego Fernandez" <[email-masked]>
Date: Thu, 24 Jul 2003 09:58:45 GMT
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

>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

Date: Thu, 24 Jul 2003 11:47:54 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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.

Date: Wed, 23 Jul 2003 19:56:40 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft minutes
Sender: [email-masked]

Please provide feedback by August 1st.

Steve
-------

PKIX WG Meeting 7/17/03

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

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]

From: "Von Welch" <[email-masked]>
Date: Wed, 23 Jul 2003 17:32:04 -0500
To: <[email-masked]>
Cc: "'pkix'" <[email-masked]>, <[email-masked]>, "Russ Housley" <[email-masked]>
Subject: Re: Draft-ietf-pkix-proxy-06.txt
Sender: [email-masked]

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 -

From: "Al Arsenault" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Date: Wed, 23 Jul 2003 17:00:19 -0400
Sender: [email-masked]

----- Original Message -----
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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

Date: Wed, 23 Jul 2003 13:18:30 -0700
To: <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Sender: [email-masked]

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 <[email-masked]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'pkix'" <[email-masked]>, <[email-masked]>
Cc: "Russ Housley" <[email-masked]>
Subject: Draft-ietf-pkix-proxy-06.txt
Date: Wed, 23 Jul 2003 16:01:59 -0400
Importance: Normal
Sender: [email-masked]

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.  

Content-class: urn:content-classes:message
Subject: RE: WG Last Call: SCVP
Date: Wed, 23 Jul 2003 12:26:05 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

See below.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Friday, July 18, 2003 6:02 AM
To: Trevor Freeman
Cc: [email-masked]; [email-masked]
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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-07.txt
Date: Wed, 23 Jul 2003 15:15:41 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

From: "Gregory S. Chudov" <[email-masked]>
To: <[email-masked]>
Cc: =?iso-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Date: Wed, 23 Jul 2003 21:04:56 +0400
Sender: [email-masked]

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.

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
From: Tom Gindin <[email-masked]>
Date: Wed, 23 Jul 2003 12:58:17 -0400
Sender: [email-masked]

        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 (301) 803-3460

[email-masked] (Peter Gutmann)
Sent by: [email-masked]
07/22/2003 09:32 AM

        To:     [email-masked], [email-masked]
        cc:     [email-masked]
        Subject:        Re: Why is privateKeyUsagePeriod deprecated?

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

Date: Thu, 24 Jul 2003 03:24:55 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 24 Jul 2003 02:55:56 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> 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.

Date: Tue, 22 Jul 2003 17:49:38 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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.

Date: Wed, 23 Jul 2003 12:11:58 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Sender: [email-masked]

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: +81 422 91 8493 (ext.3551)
Fax: +81 422 45 0536
e-mail: [email-masked]

From: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: "Diego Fernandez" <[email-masked]>
Date: Tue, 22 Jul 2003 20:24:56 GMT
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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.  

From: "Peter Hesse" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>
Cc: "'PKIX List'" <[email-masked]>, "'Matt Cooper'" <[email-masked]>, "'Yuriy Dzambasow'" <[email-masked]>, "'Susan Joseph'" <[email-masked]>, "'Richard E. Nicholas \(Nicholas, Richard\)'" <[email-masked]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Tue, 22 Jul 2003 15:52:17 -0400
Organization: Gemini Security Solutions, Inc.
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]] 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                    [email-masked]     |
| Phone: (703)934-2031         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"

------=_NextPart_000_00C6_01C35069.39F26180--

From: "Dean Adams" <[email-masked]>
To: <[email-masked]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Tue, 22 Jul 2003 16:22:28 +0100
Importance: Normal
Sender: [email-masked]

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

From: <[email-masked]>
To: [email-masked]
Reply-To: "Diego Fernandez" <[email-masked]>
Date: Tue, 22 Jul 2003 15:09:24 GMT
Subject: RE: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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

From: "Gregory S. Chudov" <[email-masked]>
To: <[email-masked]>
Cc: "Peter Gutmann" <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Date: Tue, 22 Jul 2003 18:43:24 +0400
Sender: [email-masked]

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

Content-return: prohibited
Date: Tue, 22 Jul 2003 09:35:30 -0400
From: "Joel S. Kazin" <[email-masked]>
Subject: Re: Root CA key compromised
To: PKIX List <[email-masked]>
Sender: [email-masked]

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  +1 914-769-8780
Mobile  +1 914-645-5598
email    [email-masked]

Date: Wed, 23 Jul 2003 01:32:33 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 22 Jul 2003 08:07:58 -0400
To: David Chadwick <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 22 Jul 2003 14:00:31 +0200
From: Lenka Kadlcakova <[email-masked]>
To: PKIX List <[email-masked]>
Subject: Root CA key compromised
Sender: [email-masked]

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

Date: Tue, 22 Jul 2003 23:12:20 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Tue, 22 Jul 2003 22:59:07 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Cc: [email-masked]
Sender: [email-masked]

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

From: "Montpetit, Daniel" <[email-masked]>
To: "'David Chadwick'" <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: Peter Gutmann <[email-masked]>, [email-masked]
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Mon, 21 Jul 2003 21:44:35 -0400
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Monday, July 21, 2003 13:29
To: David A. Cooper
Cc: Peter Gutmann; [email-masked]
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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research 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

------_=_NextPart_001_01C34FF2.CE302ED0--

Date: Mon, 21 Jul 2003 19:17:27 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: PKIX <[email-masked]>
Subject: LDAPv3 Profile Issue
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research 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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------840EE16934A6EEF45064928A--

From: Sharon Boeyen <[email-masked]>
To: "'David Chadwick'" <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: Peter Gutmann <[email-masked]>, [email-masked]
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Mon, 21 Jul 2003 14:08:21 -0400
Sender: [email-masked]

Just want to voice agreement and support for David Chadwick's views on this
:-)

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Monday, July 21, 2003 1:29 PM
To: David A. Cooper
Cc: Peter Gutmann; [email-masked]
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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research 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

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

Date: Mon, 21 Jul 2003 18:44:32 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: Internet Drafts <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Subject Certificate Access
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research 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 [email-masked] 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: [email-masked]

--------------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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------20CF632FF8591B088C697B6D--

Date: Mon, 21 Jul 2003 18:29:09 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: "David A. Cooper" <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research 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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------0B4261A16AFFE0AC6A81C499--

Date: Mon, 21 Jul 2003 16:20:08 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: Antonio Lioy <[email-masked]>
CC: Wen-Cheng Wang <[email-masked]>, "Michael =?iso-8859-1?Q?Str=F6der?=" <[email-masked]>, PKIX <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research 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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------0661FA61B3AD22819D10C888--

Date: Mon, 21 Jul 2003 11:03:02 -0400
From: "David A. Cooper" <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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

Date: Sat, 19 Jul 2003 17:16:02 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Why is privateKeyUsagePeriod deprecated?
Sender: [email-masked]

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.

Date: Fri, 18 Jul 2003 18:11:27 +0200
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
To: PKIX <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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]                [email-masked]
                                                  Tel.:   +39 (0)59  270  094
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

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

--------------ms040808060403000809070404--

Date: Fri, 18 Jul 2003 21:30:17 +0800 (CST)
From: wcwang <[email-masked]>
To: =?Big5?Q?Michael_Str=3Fder?= <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Cc: PKIX <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 18 Jul 2003 15:02:10 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: WG Last Call: SCVP
Sender: [email-masked]

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

Date: Fri, 18 Jul 2003 11:21:37 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: PKIX <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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.

Date: Fri, 18 Jul 2003 09:12:37 +0200
From: Antonio Lioy <[email-masked]>
Organization: Politecnico di Torino
To: Wen-Cheng Wang <[email-masked]>
CC: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, David Chadwick <[email-masked]>, PKIX <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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

From: "Wen-Cheng Wang" <[email-masked]>
To: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>, "David Chadwick" <[email-masked]>
Cc: "PKIX" <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Date: Fri, 18 Jul 2003 09:50:03 +0800
Sender: [email-masked]

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

Date: Thu, 17 Jul 2003 16:24:35 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: David Chadwick <[email-masked]>
Cc: PKIX <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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.

Subject: RE: WG Last Call: SCVP
Date: Thu, 17 Jul 2003 05:59:42 -0700
Content-class: urn:content-classes:message
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 17 Jul 2003 13:27:10 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: PKIX <[email-masked]>
Subject: Issues in LDAP schema IDs
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research 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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------AF932995C5C7561C01CD9A4B--

Date: Thu, 17 Jul 2003 02:57:03 -0400
To: "Manger, James H" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: IP addr: 01: use NULL instead of BOOLEAN for inherit
Cc: <[email-masked]>
Sender: [email-masked]

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.

content-class: urn:content-classes:message
Subject: RE: IP addr: 01: use NULL instead of BOOLEAN for inherit
Date: Thu, 17 Jul 2003 12:15:25 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
> 	Sent:	Thursday, 17 July 2003 12:45 AM
> 	To:	Manger, James H; [email-masked]
> 
> 	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.
> 

Date: Wed, 16 Jul 2003 10:44:50 -0400
To: "Manger, James H" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: IP addr: 01: use NULL instead of BOOLEAN for inherit
Sender: [email-masked]

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.

Date: Wed, 16 Jul 2003 03:47:09 -0400
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Proxy Certificates - WG Last Call Closed
Sender: [email-masked]

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)

From: "Santosh Chokhani" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Steve Hanna'" <[email-masked]>
Cc: "'PKIX List'" <[email-masked]>
Subject: RE: Question about Certificate Issuer CRL Entry Extension
Date: Tue, 15 Jul 2003 14:30:27 -0400
Importance: Normal
Sender: [email-masked]

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

Date: Tue, 15 Jul 2003 08:46:24 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Discussing RTCS
Cc: "'Denis Pinkas'" <[email-masked]>, "'Sean P. Turner'" <[email-masked]>, <[email-masked]>, "'pkix'" <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 15 Jul 2003 14:48:03 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Steve Hanna <[email-masked]>
CC: PKIX List <[email-masked]>
Subject: Re: Question about Certificate Issuer CRL Entry Extension
Sender: [email-masked]

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,

Date: Tue, 15 Jul 2003 13:10:12 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked]
Subject: Re: WG Last Call: SCVP
Sender: [email-masked]

> 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

Date: Tue, 15 Jul 2003 23:02:32 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Discussing RTCS
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Denis Pinkas <[email-masked]> 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).

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Sean P. Turner'" <[email-masked]>
Cc: <[email-masked]>, "'pkix'" <[email-masked]>
Subject: RE: Discussing RTCS
Date: Tue, 15 Jul 2003 11:30:53 +0200
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Tuesday, July 15, 2003 10:29 AM
> To: Sean P. Turner
> Cc: [email-masked]; 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
> >>
> >>  
> >>
> > 
> 
> 

Date: Tue, 15 Jul 2003 11:22:34 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Hesse <[email-masked]>, "'Matt Cooper'" <[email-masked]>, "'Yuriy Dzambasow'" <[email-masked]>, "'Susan Joseph'" <[email-masked]>, "Richard E. Nicholas (Nicholas, Richard)" <[email-masked]>
CC: Steve Hanna <[email-masked]>, "'PKIX List'" <[email-masked]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
Sender: [email-masked]

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

Date: Tue, 15 Jul 2003 10:28:32 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Sean P. Turner" <[email-masked]>
CC: [email-masked], pkix <[email-masked]>
Subject: Re: Discussing RTCS
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: Creating client certificate in IE browser using xenroll.dll
Date: Mon, 14 Jul 2003 13:30:46 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Sreenivasa Baddam" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Sreenivasa Baddam
Sent: Monday, July 14, 2003 6:36 AM
To: [email-masked]
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>
> 
> 
> 
> 
> 

Date: Mon, 14 Jul 2003 16:11:33 -0400
From: Steve Hanna <[email-masked]>
To: Peter Hesse <[email-masked]>
CC: "'PKIX List'" <[email-masked]>, "'Matt Cooper'" <[email-masked]>, "'Yuriy Dzambasow'" <[email-masked]>, "'Susan Joseph'" <[email-masked]>, "Richard E. Nicholas (Nicholas, Richard)"  <[email-masked]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
Sender: [email-masked]

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

--------------ms20BF47E1AC85BB6C8B4F4F07--

From: "cindy" <[email-masked]>
To: <[email-masked]>
Subject: 
Date: Mon, 14 Jul 2003 10:14:51 -0500
Sender: [email-masked]

unsubscribe

From: Sharon Boeyen <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Sharon Boeyen <[email-masked]>, "Hoyt Kesterson (E-mail)" <[email-masked]>
Cc: [email-masked]
Subject: RE: What is mean by recognizing critical extensions ?
Date: Mon, 14 Jul 2003 11:14:53 -0400
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Monday, July 14, 2003 10:50 AM
To: Sharon Boeyen; Hoyt Kesterson (E-mail)
Cc: [email-masked]
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:[email-masked]
<mailto:[email-masked]> ]

Sent: Sunday, July 13, 2003 10:31 AM

To: Sharon Boeyen

Cc: [email-masked]

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:[email-masked]]<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> 
  [email-masked]<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:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>]<BR>
      <DD>Sent:</B> Sunday, July 13, 2003 10:31 AM<BR>
      <DD>To:</B> Sharon Boeyen<BR>
      <DD>Cc:</B> [email-masked]<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--

Date: Mon, 14 Jul 2003 10:50:24 -0400
To: Sharon Boeyen <[email-masked]>, "Hoyt Kesterson (E-mail)" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: What is mean by recognizing critical extensions ?
Cc: [email-masked]
Sender: [email-masked]

<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:[email-masked]"=
 eudora=3D"autourl">mailto:[email-masked]</a>]<br>

<dd>Sent:</b> Sunday, July 13, 2003 10:31 AM<br>

<dd>To:</b> Sharon Boeyen<br>

<dd>Cc:</b> [email-masked]<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>

From: Sharon Boeyen <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Steve Hanna <[email-masked]>, PKIX List <[email-masked]>
Subject: RE: Question about Certificate Issuer CRL Entry Extension 
Date: Mon, 14 Jul 2003 10:37:06 -0400
Sender: [email-masked]

I agree with this as well.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
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

From: Sharon Boeyen <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "Hoyt Kesterson (E-mail)" <[email-masked]>
Cc: [email-masked]
Subject: RE: What is mean by recognizing critical extensions ?
Date: Mon, 14 Jul 2003 10:33:38 -0400
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Sunday, July 13, 2003 10:31 AM
To: Sharon Boeyen
Cc: [email-masked]
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:[email-masked]]<BR><B>Sent:</B> Sunday, July 13, 2003 10:31 
  AM<BR><B>To:</B> Sharon Boeyen<BR><B>Cc:</B> 
  [email-masked]<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--

content-class: urn:content-classes:message
Subject: Creating client certificate in IE browser using xenroll.dll
Date: Mon, 14 Jul 2003 06:35:42 -0700
From: "Sreenivasa Baddam" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 14 Jul 2003 04:07:15 -0400
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: SEND WG trying to make use of RFC 3281
Sender: [email-masked]

I thought that people on this list would like to know that the SEND WG to 
trying to make use of Attribute Certificates.

Russ

Date: Sun, 13 Jul 2003 10:41:42 -0400
To: Steve Hanna <[email-masked]>, PKIX List <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Question about Certificate Issuer CRL Entry Extension 
Sender: [email-masked]

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

Date: Sun, 13 Jul 2003 10:31:18 -0400
To: Sharon Boeyen <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: What is mean by recognizing critical extensions ?
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 11 Jul 2003 12:44:29 -0700
From: "Hoyt L. Kesterson II" <[email-masked]>
To: [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

<!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:[email-masked]">Sharon Boeyen</a></blockquote>
<blockquote><b>To:</b> <a
href="mailto:[email-masked]">'Hoyt L. Kesterson II'</a> ;
<a href="mailto:[email-masked]">[email-masked]</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:[email-masked]]<br>
<b>Sent:</b> Thursday, July 10, 2003 8:47 PM<br>
<b>To:</b> [email-masked]<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;[email-masked]&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>

Date: Fri, 11 Jul 2003 14:58:55 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Updated agenda for PKIX, 57th IETF
Cc: peter Sylvester <[email-masked]>, [email-masked], "Riccardo.Genghini" <[email-masked]>
Sender: [email-masked]

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

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

From: "Peter Hesse" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, "'PKIX List'" <[email-masked]>
Cc: "'Matt Cooper'" <[email-masked]>, "'Yuriy Dzambasow'" <[email-masked]>, "'Susan Joseph'" <[email-masked]>, "Richard E. Nicholas \(Nicholas, Richard\)" <[email-masked]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Fri, 11 Jul 2003 14:04:44 -0400
Organization: Gemini Security Solutions, Inc.
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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                    [email-masked]     |
| Phone: (703)934-2031         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"

------=_NextPart_000_0091_01C347B5.6109F100--

From: "Santosh Chokhani" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, "'PKIX List'" <[email-masked]>
Subject: RE: Question about Certificate Issuer CRL Entry Extension
Date: Fri, 11 Jul 2003 12:16:27 -0400
Importance: Normal
Sender: [email-masked]

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

------=_NextPart_000_0098_01C347A6.409D4DE0--

Date: Fri, 11 Jul 2003 09:03:20 -0700
From: "Hoyt L. Kesterson II" <[email-masked]>
To: [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

<!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:[email-masked]">Hoyt L. Kesterson
II</a></blockquote>
<blockquote><b>To:</b> <a
href="mailto:[email-masked]">[email-masked]</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;[email-masked]&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>

Date: Fri, 11 Jul 2003 08:43:38 -0700 (PDT)
Subject: Re: What is mean by recognizing critical extensions ?
From: "Ambarish Malpani" <[email-masked]>
To: <[email-masked]>
Importance: Normal
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:
> +46-708-26 53 44 |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"
>
>
> In message
> <[email-masked]> on Fri,
> 11 Jul 2003 08:43:16 -0400, Sharon Boeyen <[email-masked]>
> 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:[email-masked]] sharon.boeyen> Sent: Thursday, July
> 10, 2003 8:47 PM
> sharon.boeyen> To: [email-masked]
> 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 <[email-masked]>
> sharon.boeyen> Information Operations and Assurance Center
> sharon.boeyen> Lawrence Livermore National Laboratory
> sharon.boeyen> Livermore, CA 94551-9900
> sharon.boeyen>
> sharon.boeyen>

From: "Wahaj" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, <[email-masked]>
Subject: Re: What is mean by recognizing critical extensions ?
Date: Fri, 11 Jul 2003 20:35:51 +0500
Sender: [email-masked]

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' ; [email-masked]=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:[email-masked]]
    Sent: Thursday, July 10, 2003 8:47 PM
    To: [email-masked]
    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 <[email-masked]>
      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=[email-masked]=20
  href=3D"mailto:[email-masked]">Sharon Boeyen</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">'Hoyt L. Kesterson II'</A> =
; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]]<BR><B>Sent:</B> Thursday, July =
10, 2003=20
    8:47 PM<BR><B>To:</B> [email-masked]<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;[email-masked]&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"

------=_NextPart_000_00D0_01C347EC.05196470--

From: Sharon Boeyen <[email-masked]>
To: "'Hoyt L. Kesterson II'" <[email-masked]>, [email-masked]
Subject: RE: What is mean by recognizing critical extensions ?
Date: Fri, 11 Jul 2003 10:58:57 -0400
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Friday, July 11, 2003 8:43 AM
To: 'Hoyt L. Kesterson II'; [email-masked]
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:[email-masked]]
Sent: Thursday, July 10, 2003 8:47 PM
To: [email-masked]
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 <[email-masked]>
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:[email-masked]]<BR><B>Sent:</B> Friday, July 11, =
2003 8:43=20
  AM<BR><B>To:</B> 'Hoyt L. Kesterson II'; =
[email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, July =
10, 2003=20
    8:47 PM<BR><B>To:</B> [email-masked]<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;[email-masked]&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--

From: "todd glassey" <[email-masked]>
To: "Hoyt L. Kesterson II" <[email-masked]>, <[email-masked]>
Subject: Re: What is mean by recognizing critical extensions ?
Date: Fri, 11 Jul 2003 07:53:17 -0700
Sender: [email-masked]

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: [email-masked]=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 <[email-masked]>
    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=[email-masked]=20
  href=3D"mailto:[email-masked]">Hoyt L. Kesterson II</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</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;[email-masked]&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--

Date: Fri, 11 Jul 2003 16:31:23 +0200 (CEST)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

In message <[email-masked]> on Fri, 11 Jul 2003 08:43:16 -0400, Sharon Boeyen <[email-masked]> 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:[email-masked]]
sharon.boeyen> Sent: Thursday, July 10, 2003 8:47 PM
sharon.boeyen> To: [email-masked]
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 <[email-masked]>
sharon.boeyen> Information Operations and Assurance Center
sharon.boeyen> Lawrence Livermore National Laboratory
sharon.boeyen> Livermore, CA 94551-9900
sharon.boeyen> 
sharon.boeyen> 

Date: Fri, 11 Jul 2003 10:20:24 -0400
From: Steve Hanna <[email-masked]>
To: PKIX List <[email-masked]>
Subject: Question about Certificate Issuer CRL Entry Extension
Sender: [email-masked]

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

--------------msD3C01BF60385FA55104EDA8B--

From: Sharon Boeyen <[email-masked]>
To: "'Hoyt L. Kesterson II'" <[email-masked]>, [email-masked]
Subject: RE: What is mean by recognizing critical extensions ?
Date: Fri, 11 Jul 2003 08:43:16 -0400
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Thursday, July 10, 2003 8:47 PM
To: [email-masked]
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 <[email-masked]>
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:[email-masked]]<BR><B>Sent:</B> Thursday, July 10, 2003 
  8:47 PM<BR><B>To:</B> [email-masked]<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;[email-masked]&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--

Date: Fri, 11 Jul 2003 07:59:57 -0400
From: Steve Hanna <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: "'PKIX List'" <[email-masked]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
Sender: [email-masked]

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

--------------ms036ECB52D38380147F10C852--

Date: Thu, 10 Jul 2003 17:46:38 -0700
From: "Hoyt L. Kesterson II" <[email-masked]>
To: [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

<!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;[email-masked]&gt;<br>
Information Operations and Assurance Center<br>
Lawrence Livermore National Laboratory<br>
Livermore, CA 94551-9900</blockquote>
<div><br></div>
</body>
</html>

Date: Thu, 10 Jul 2003 17:18:33 -0700
To: "Hoyt L. Kesterson II" <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

<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;[email-masked]&gt; <br>
Information Operations and Assurance Center <br>
Lawrence Livermore National Laboratory <br>
Livermore, CA 94551-9900<br>
</html>

From: "Santosh Chokhani" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, "'PKIX List'" <[email-masked]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 10 Jul 2003 20:05:04 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce:;
CC: [email-masked]

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

------=_NextPart_000_0069_01C3471E.8D1D3B40--

Date: Thu, 10 Jul 2003 14:59:26 -0700
From: "Hoyt L. Kesterson II" <[email-masked]>
To: [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

<!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;[email-masked]&gt;<br>
Information Operations and Assurance Center<br>
Lawrence Livermore National Laboratory<br>
Livermore, CA 94551-9900</blockquote>
<div><br></div>
</body>
</html>

Date: Thu, 10 Jul 2003 13:55:22 -0700
To: [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

<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;[email-masked]&gt; <br>
Information Operations and Assurance Center <br>
Lawrence Livermore National Laboratory <br>
Livermore, CA 94551-9900<br>
</html>

Date: Thu, 10 Jul 2003 15:29:58 -0400
From: Steve Hanna <[email-masked]>
To: PKIX List <[email-masked]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
Sender: [email-masked]

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: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce:;
CC: [email-masked]

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

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

--------------ms4B7902436081545849902AA0--

Date: Thu, 10 Jul 2003 14:36:42 -0400
From: "David A. Cooper" <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: CRL Issuer Name = Subject name from crl signer cert?
Sender: [email-masked]

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

Date: Wed, 9 Jul 2003 22:14:15 -0700
From: "Hoyt L. Kesterson II" <[email-masked]>
To: [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

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

Date: Wed, 09 Jul 2003 16:23:41 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>, S-MIME / IETF <[email-masked]>
Subject: Policy Requirements for Attribute Authorities
Sender: [email-masked]

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 <[email-masked]>
Task leader: Franco Ruggieri <[email-masked]>

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.

From: "Otto Mueller" <[email-masked]>
To: <[email-masked]>
Cc: "Man-Sze Li" <[email-masked]>, "Mueller, Adrian, M-C" <[email-masked]>
Subject: draft-ietf-pkix-pi-06
Date: Wed, 9 Jul 2003 09:07:32 +0200
Importance: Normal
Sender: [email-masked]

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 +41 1 217 40 50
fax   +41 1 217 40 51

Date: Tue, 08 Jul 2003 18:21:29 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: [Fwd: Re: CRL Issuer Name = Subject name from crl signer cert?]
Sender: [email-masked]

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 <[email-masked]>
Organization: Bull SA.
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
References: <[email-masked]> <[email-masked]> 
<[email-masked]> <[email-masked]>

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

Date: Tue, 08 Jul 2003 17:18:36 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Sender: [email-masked]

> 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

Date: Tue, 08 Jul 2003 10:31:01 -0400
From: "David A. Cooper" <[email-masked]>
To: Trevor Freeman <[email-masked]>
CC: Wahaj <[email-masked]>, [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: What is mean by recognizing critical extensions ?
Date: Tue, 8 Jul 2003 08:14:27 -0400
From: "Oshman, Dave" <[email-masked]>
To: "Wahaj" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Tue,  8 Jul 2003 08:02:16 -0400
From: [email-masked]
To: [email-masked]
Subject: draft agenda - 57th IETF
Sender: [email-masked]

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

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

Date: Tue,  8 Jul 2003 07:58:39 -0400
From: [email-masked]
To: [email-masked]
Subject: WG Last Call: SCVP
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: What is mean by recognizing critical extensions ?
Date: Mon, 7 Jul 2003 14:41:37 -0700
From: "Trevor Freeman" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "Wahaj" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Monday, July 07, 2003 12:03 PM
To: Wahaj
Cc: [email-masked]
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.

Date: Mon, 07 Jul 2003 15:02:59 -0400
From: "David A. Cooper" <[email-masked]>
To: Wahaj <[email-masked]>
CC: [email-masked]
Subject: Re: What is mean by recognizing critical extensions ?
Sender: [email-masked]

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.

From: "Wahaj" <[email-masked]>
To: <[email-masked]>
Subject: What is mean by recognizing critical extensions ?
Date: Fri, 4 Jul 2003 20:04:13 +0500
Sender: [email-masked]

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"

------=_NextPart_000_0CC7_01C34267.70A28670--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ldap-crl-schema-01.txt
Date: Thu, 03 Jul 2003 11:31:58 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

From: "Ambarish Malpani" <[email-masked]>
To: "Yasir Khan" <[email-masked]>, <[email-masked]>
Subject: RE: A question about RFC-2560 (OCSP)
Date: Thu, 3 Jul 2003 09:04:06 -0700
Importance: Normal
Sender: [email-masked]

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
[email-masked]                         http://www.malpani.biz

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Yasir Khan
  Sent: Tuesday, July 01, 2003 3:00 AM
  To: [email-masked]
  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
[email-masked]&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> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Yasir=20
  Khan<BR><B>Sent:</B> Tuesday, July 01, 2003 3:00 AM<BR><B>To:</B>=20
  [email-masked]<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--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dnstrings-01.txt
Date: Thu, 03 Jul 2003 11:32:08 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 03 Jul 2003 11:32:03 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

content-class: urn:content-classes:message
Subject: IP addr: 01: use NULL instead of BOOLEAN for inherit
Date: Thu, 3 Jul 2003 11:26:07 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 3 July 2003 8:10 AM
Cc: [email-masked]
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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
Date: Wed, 02 Jul 2003 18:10:18 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 02 Jul 2003 23:07:13 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: [email-masked]
Subject: I-D: multi-domain PKI Interoperability
Cc: [email-masked]
Reply-To: [email-masked], [email-masked]
Sender: [email-masked]

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: +81 422 91 8493 (ext.3551)
Fax: +81 422 45 0536
e-mail: [email-masked]

Content-class: urn:content-classes:message
Subject: RE: SCVP Questions
Date: Tue, 1 Jul 2003 12:20:46 -0700
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Faisal
Sent: Tuesday, July 01, 2003 5:36 AM
To: [email-masked]
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> =
[email-masked]
[mailto:[email-masked]] <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> [email-masked]<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--

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: FW: A question about RFC-2560 (OCSP)
Date: Tue, 1 Jul 2003 10:26:35 -0500
Importance: Normal
Sender: [email-masked]

From: "Faisal" <[email-masked]>
To: <[email-masked]>
Subject: SCVP Questions
Date: Tue, 1 Jul 2003 17:35:50 +0500
Sender: [email-masked]

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"

------=_NextPart_000_0079_01C33FF7.3692ACC0--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-12.txt
Date: Tue, 01 Jul 2003 07:23:33 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Reply-To: "Yasir Khan" <[email-masked]>
From: "Yasir Khan" <[email-masked]>
To: <[email-masked]>
Subject: A question about RFC-2560 (OCSP)
Date: Tue, 1 Jul 2003 14:59:34 +0500
Organization: Ascertia Limited.
Sender: [email-masked]

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"

------=_NextPart_000_0040_01C33FE1.6261E480--