Re: TSA Response serialNumber Field

[Ed Gerck <[e-mail]>]

"Manger, James H" wrote:

> Michael,
>
> > How do you know when the "Time stops" and the "Order begins"?
> You never need to know - that is the beauty.

What you say below does not work.

> > Stamp from TSA_1: 20000529053138.345Z. Accuracy = 1 sec.
> > Stamp from TSA_2: 20000529053138.876Z. Accuracy = 1 sec
> > How do I do it [compare the stamps]?
> Consider T2 - T1.  The best estimate (mean) is .876 - .345 = .531.

Again, this confuses accuracy with uncertainty (which is the inverse of reliability).
If both TSA_1 and TSA_2 have accuracy of 1s (ie, spread of *one* measurement
is equal to 1 s for each) this says nothing about their uncertainty (measured by a
probability distribution over *many* measurements for each). Accuracy and
reliability (uncertainty) are independent concepts.

So, in this case to say that the best estimate of the time is the mean is the same as
saying that the best estimate between an apple and a speedboat is an orange ;-)

Now, if by "accuracy" above you mean uncertainty then I would have to
ask about their accuracies, since the time values may have very low uncertainty
and still be as far apart as apples and speedboats.

So, to the original question: "How do I do it [compare the stamps]?"
The answer must be (for what was provided): insufficient data.

> If a TSA clock returns digits down to the tenth of a second, e.g.
> "5:31:38.8", it will return the same string when the fraction of seconds is
> .800, .807, .876 and 0.887 (could use rounding instead of truncation but it
> makes no difference).  On reading "5:31:38.8" the TSA knows the time
> (according to its clock) is in the range [5:31:38.80000..,
> 5:31:38.899999...].  Any value in this range is as good a guess as any
> other.  The TSA can arbitrarily choose any value in this range.  Hence, the
> TSA can ensure its arbitrary choices always increase while its clock returns
> the same value.

As I commented a couple days ago, this is fine BUT some restrictions apply,
as given there.

Cheers,

Ed Gerck




Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03143 for <[e-mail]>; Wed, 31 May 2000 22:06:48 -0700 (PDT)
Received: from tot-tq.proxy.aol.com (tot-tq.proxy.aol.com [152.163.201.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id BAA05648 for <[e-mail]>; Thu, 1 Jun 2000 01:13:39 -0400 (EDT)
Received: from djs300y (AC9C79B2.ipt.aol.com [172.156.121.178]) by tot-tq.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e515DcJ12396 for <[e-mail]>; Thu, 1 Jun 2000 01:13:38 -0400 (EDT)
Date: Thu, 1 Jun 2000 01:13:38 -0400 (EDT)
Message-ID: <01a001bfcb88$1afad460$0100a8c0@djs300y>
From: "Dennis  Solomon" <[e-mail]>
To: <[e-mail]>
Subject: Legal Assistance
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Apparently-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA03144

EMAIL: [e-mail]

Dear Friends,

I am in need of an excellent intellectual property litigator to recover my rights and damages related to the theft of my trade secrets by the principals of Microvision, Inc., NASDAQ: MVIS.  I believe I am the first and original inventor of the virtual retinal display, and filed papers with the U.S. Patent Office over one year prior to the first filing by Microvision.

The principals I later discovered were doing business with the small electronics firm where I was conducting my experiments.  They were later paid over $200,000 by them.

The present market value of the technology in over $200,000,000.

The details may be found at my new website: www.citizenslaw.net


Thank you.


Dennis 
 [e-mail]


Dennis J. Solomon
P.O. Box 289
Yarmouth Port, MA 02675





Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26093 for <[e-mail]>; Wed, 31 May 2000 20:50:24 -0700 (PDT)
Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Wed, 31 May 2000 20:41:44 -0700 (PDT)
Date: Tue, 30 May 2000 20:42:02 -0700
From: Ed Gerck <[e-mail]>
Subject: Re: TSA Response serialNumber Field
To: "Manger, James H" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References:  <[e-mail]>

"Manger, James H" wrote:

> Michael,
>
> > How do you know when the "Time stops" and the "Order begins"?
> You never need to know - that is the beauty.

What you say below does not work.

> > Stamp from TSA_1: 20000529053138.345Z. Accuracy = 1 sec.
> > Stamp from TSA_2: 20000529053138.876Z. Accuracy = 1 sec
> > How do I do it [compare the stamps]?
> Consider T2 - T1.  The best estimate (mean) is .876 - .345 = .531.

Again, this confuses accuracy with uncertainty (which is the inverse of reliability).
If both TSA_1 and TSA_2 have accuracy of 1s (ie, spread of *one* measurement
is equal to 1 s for each) this says nothing about their uncertainty (measured by a
probability distribution over *many* measurements for each). Accuracy and
reliability (uncertainty) are independent concepts.

So, in this case to say that the best estimate of the time is the mean is the same as
saying that the best estimate between an apple and a speedboat is an orange ;-)

Now, if by "accuracy" above you mean uncertainty then I would have to
ask about their accuracies, since the time values may have very low uncertainty
and still be as far apart as apples and speedboats.

So, to the original question: "How do I do it [compare the stamps]?"
The answer must be (for what was provided): insufficient data.

> If a TSA clock returns digits down to the tenth of a second, e.g.
> "5:31:38.8", it will return the same string when the fraction of seconds is
> .800, .807, .876 and 0.887 (could use rounding instead of truncation but it
> makes no difference).  On reading "5:31:38.8" the TSA knows the time
> (according to its clock) is in the range [5:31:38.80000..,
> 5:31:38.899999...].  Any value in this range is as good a guess as any
> other.  The TSA can arbitrarily choose any value in this range.  Hence, the
> TSA can ensure its arbitrary choices always increase while its clock returns
> the same value.

As I commented a couple days ago, this is fine BUT some restrictions apply,
as given there.

Cheers,

Ed Gerck



Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA00910 for <[e-mail]>; Wed, 31 May 2000 18:32:14 -0700 (PDT)
Received: from dstc.edu.au (topaz.dstc.qut.edu.au [131.181.71.25]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id e511dko14971; Thu, 1 Jun 2000 11:39:46 +1000 (EST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 01 Jun 2000 11:39:53 +1000
From: Eddy Cheung <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Mullan <[e-mail]>
CC: [e-mail]
Subject: Re: PKIX library
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks, Sean.

I believe DSTC is already involved in Java Community Process and also in
the JCA/JCE area as well.

Cheers...
Eddy

Sean Mullan wrote:
> 
> Hi,
> 
> You may also be interested in the development of a new standard
> Java API for handling certification paths.
> 
> The Java Certification Path API is a Java API that is
> currently being specified using the Java Community Process.
> The API is targeted for the next release of J2SE (Java
> 2 Standard Edition). It will include Java classes for building
> and validating certification paths, and will be based on
> the standard Java Cryptography Architecture. A reference
> implementation of the APIs including an RFC 2459 certification
> path validation implementation is planned.
> 
> Please see http://java.sun.com/aboutJava/communityprocess/jsr/jsr_055_certp.html
> for the Java Specification Request, which includes more information
> about this API.
> 
> Thanks,
> Sean


Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19161 for <[e-mail]>; Wed, 31 May 2000 15:33:30 -0700 (PDT)
Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id AAA19469 for <[e-mail]>; Thu, 1 Jun 2000 00:41:03 +0200
From: <[e-mail]>
Sender: "denis bider" <[e-mail]>
To: <[e-mail]>
Subject: Microsoft
Date: Thu, 1 Jun 2000 00:41:44 +0200
Message-ID: <000001bfcb51$667cfd00$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hello,

I am developing a certificate-generating application that will be employed
in a Microsoft-based environment. I am looking from someone in Microsoft who
has the technical insight about how certificate verification has been
implemented in IIS, and perhaps also Microsoft Outlook.

Is there, perhaps, someone who is reading this list who would know something
about this, or someone who would have the appropriate contacts?

If so, I would be much obliged if you could send me an email.

Kind regards,

denis bider



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14162 for <[e-mail]>; Wed, 31 May 2000 10:05:06 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA09388; Wed, 31 May 2000 19:12:29 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 31 May 2000 19:12:47 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA05309; Wed, 31 May 2000 19:12:28 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA05938; Wed, 31 May 2000 19:12:28 +0200 (MET DST)
Date: Wed, 31 May 2000 19:12:28 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Time Stamp V7 Data structure
Cc: [e-mail], [e-mail], [e-mail], [e-mail]

> >
> > > I am re-opening it for two reasons: Since the first time (version 5
> > > discussion) I was expecting a change in the IETF document stating that
> > > it is optional to have a mechanism identifier (object identifier) in the
> > > time stamp request and I also expected a modified data structure
> > > allowing to use the option. None of this happened. This information is a
> > > prerequisite for developers willing to implement an IETF and ISO
> > > compatible TSA.
> > This is not quite true:
> > 
> This is a hard statement. There are at least two different ways to have
> a default value as it was proposed by Tom: either the default is
> interpreted as non-existent or as a pre-set value. And I had the
> impression that for the latter at least an indicator is needed to point
> out that this field will be used.

The 'This' in my message may be misleading: I am refering to
'None of this happened'.
 
> 
> > It has been proposed not to indicate a mechanism identifier inside
> > the information but to allow two different ways secure time
> > stamps:
> > 
> > - one is using SignedData
> > 
> > - the other one is using DigestedData to support all cases
> >   where you need a mechanism: The mechanism identifier would
> >   become the digestalgorithm.
> > 
> > Thus, you have BOTH a way to indicate a mechanism, and a modified
> > data structure.
> 
> Yes that's a solution but not a straight-forward one. And it does not
> lead to interoperability for the the ISO protocol is a superset and we
> are trying to achieve a common set. That's why I re-opened the
> discussion.

That seems the point of the dispute. There are TWO proposals.

Both the current text of the IETF standard and the ISO proposal
may be considered supersets of what we had before. 

But: The ISO protocol for the format of a time stamp token
(not just the info) is NOT a superset, since it encapsulates
the signature and data in another sequence. Thus ISO already
has another token format, and the mechanism stuff is an inner detail. 

The IETF proposal is a superset of the original IETF text that
allows to provide the SAME functionality as the ISO proposal. 

It is possible to convert both formats (four cases)

- input IETF signeddata :

  output: a sequence of the content and signeddata without the content 

- input IETF digesteddata

  output: a sequence of the messagedigest and a modified content where
          the digest algo is inserted as 'mechanism in the ISO stamp stamp info

- input ISO sequence without mechanism (thus IETF signature assumed as default)
  output a signeddata where the content is inserted

- input ISO sequence WITH mechanism
  output a digestedData where the mechanism is removed in the content, and
  used as digestalgorithm.

Indeed the last case is somewhat strange because in order to validate the
token you need to insert the algorithm into the data structure first. 


You didn't comment the statements below which are the essential ones.

- The proposed solution is using the following rule:

  1 - you have a time stamp content
  2 - you have a protecting envelope (signature, method based information)

- The method indication is assumed to be logically part of the
  protecting envelope and not of the content.

 

> > 
> > By this proposal one avoids to create another new ASN1 structures
> > and remains completely in the scope of CMS/PKCS7.
> > 
> > The top level data structure of a 'time stamp token' could
> > be either :
> > 
> > - a document conforming to a cryptographic message syntax
> > - a sequence of some data and whatever protection of that data
> > 
> > This anyway a matter of taste.
> > 
> > One could also create a mime multipart/timestamp to allow having
> > two interpreters for the different parts, etc.
> > 
> > Peter Sylvester
> > 
> > 
> Roland Mueller
 


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13756 for <[e-mail]>; Wed, 31 May 2000 09:52:53 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id TAA42836; Wed, 31 May 2000 19:00:24 +0200
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 19:00:18 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Roland Mueller <[e-mail]>
CC: IETF-PKIX <[e-mail]>, Wes Doonan <[e-mail]>, "Jose A. Ma~n" <[e-mail]>, Mike Matyas <[e-mail]>
Subject: Re: Time Stamp V7 Data structure
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Roland,

> This is a kind of re-opening the issue of aligning the actual ISO draft
> on time stamping with version 07 of the PKIX time stamping draft.
> 
> I am re-opening it for two reasons: Since the first time (version 5
> discussion) I was expecting a change in the IETF document stating that
> it is optional to have a mechanism identifier (object identifier) in the
> time stamp request and I also expected a modified data structure
> allowing to use the option. None of this happened. This information is a
> prerequisite for developers willing to implement an IETF and ISO
> compatible TSA.
> 
> The answer I received from the eeditor on the change of the data
> structure was  from my point of view sufficient for it only meant an
> endorsement to use additional elements in  the ISO data structure: "For
> the request the additional element will be in the ISO request, NOT in
> the IETF request."

The structure of the request in the (next) version of the TSP
document that I am maintaining is the following:

TimeStampReq ::= SEQUENCE  {
     version               INTEGER  { v1(1) },
     messageImprint        MessageImprint,
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
     reqPolicy             PolicyInformation        OPTIONAL,
     nonce                 INTEGER                  OPTIONAL,
     certReq               BOOLEAN                  DEFAULT FALSE,
     extensions            [0] IMPLICIT Extensions  OPTIONAL
}

The ISO document *could* use an additional default parameter
(defaulted to mean the IETF protocol where only signed TSTs exist)
to signal
that this is the ISO protocol and then *could* signal the OID of the
mechanism in the extensions field (if there are more than one). An
*example* of that case would be:

TimeStampReq ::= SEQUENCE  {
     version               INTEGER  { v1(1) },
     protocolIdentifier    ProtocolIdentifier DEFAULT v1,
     messageImprint               MessageImprint,
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
     reqPolicy             PolicyInformation        OPTIONAL,
     nonce                 INTEGER                  OPTIONAL,
     certReq               BOOLEAN                  DEFAULT FALSE,
     extensions            [0] IMPLICIT Extensions  OPTIONAL
}


   ProtocolIdentifier  ::=  INTEGER  {  v1(0), v2(1), v3(2) }
     -- v1 means the IETF protocol defined in TSP.
     -- v2 means the ISO protocol for the response 
     -- as defined in ISO XXXX-2.
     -- v3 means the ISO protocol for the response 
     -- as defined in ISO XXXX-3.

Another simpler *example* would be to use the following addition
(instead of protocolIdentifier) between the fields version and
messageImprint:

     protocolISO           BOOLEAN DEFAULT FALSE,

-- when the boolean is true, this means the ISO protocols
-- as defined in ISO XXXX-2 and ISO XXXX-3.
-- when the boolean is false, this means the IETF protocol 
-- as defined in the document TSP in RFC XXXX.

In this way, an IETF client talking to an ISO/IETF compliant server
still uses the current request (without any addition) as defined in
the TSP document. The ISO/IETF compliant server will compile the ISO
description of the request and thus can easily detect which of the
two options is being used. 

An ISO client talking to an IETF server will not get any service and
will be returned with an error.

An ISO client talking to an ISO server can obtain whatever ISO
decides.

There are many other ways. Among them, a much simpler (but not
cleaner !) solution, without the addition of any other parameter: If
ISO starts version numbers of their protocols with, let us say, 100,
then there is very little chance that IETF versions will ever reach
that number. :-)

Note: we have to make sure that there exists at least one solution,
but this is not a task of the IETF to decide which solution to pick
up for ISO. So once ISO has made a decision, it would be "nice" 
for the IETF to know about it.
 

> That means, ISO gets endorsement for its data structure. I was asking
> for a change in the IETF data structure, the mechanism Identifier
> element ALREADY exists in the ISO Time stamp request data structure.
> 
> On the other hand I have to express that the adoption of a mechanism
> identifier into the time stamp token is required to allow proper
> interpretation by the recipient of such a token. If the mechanism used
> for generating the token cannot be identified then the validity of a
> time stamp cannot be checked if it is not the IETF mechanism. If time
> stamps are generated using a mechanism different from the IETF draft and
> there is no information provided within the token what mechanism was
> used to generate the time stamp then a verifier does not know how to
> proceed. If the time stamp was generated with one of the mechanisms
> proposed in the ISO draft then information is needed to successfully
> verify the validity of the time stamp. Otherwise an ISO time stamp is
> not usable by  recipients of the time stamp for they cannot verify its
> validity.

About the structure of the response, 

On May 2, I responded privately to you with the following:

A proposal has been made to use DigestInfo, which solves your
concern, not in the way that was originally requested, but which
allows a server to send back a response that may be either IETF
conformant or ISO conformant.

On April 19, I responded privately to you with the following:

TimeStampToken is defined in the document as:

TimeStampToken ::= ContentInfo
  -- contentType is id-signedData ([CMS])
  -- content is SignedData ([CMS])

It has been proposed that ISO uses DigestInfo instead of SignedData
as defined in the CMS structure. This also means that ISO will have
to register the algorithm(s) that are needed to describe what kind
of crypto technique will be used.

When this will be done, we (i.e. the PKIX WG) might extend the
definition of the id-signatureTimeStampToken defined in the annex A
to support DigestInfo in addition to SignedData.

As the IETF process mandates to wait at least 6 months after the I-D
is issued and to have two interoperable independent implementations,
we could make the change at that time, provided that your data
structure is well defined at that time and your algorithm(s) is/are
registered.

This explains why no change to the response in the IETF document is
needed at that time and also explains that a change to the annex A
might be done 6 months from now.

Denis

Note: Do not expect another E-mail from me soon. I will only be back
in my office next monday.


> Let me explain the need for the mechanism identifier in the request also
> in an example: A client using the IETF protocol may communicate with
> either an ISO or an IETF TSA when requesting a time stamp; this will
> cause no problem for the ISO TSA will understand the request of the
> client.
> 
> The situation gets more difficult if the client uses the ISO protocol. A
> TSA only understanding IETF requests will detect general incompatibility
> and answer with an error; this leaves the client without a time stamp if
> he cannot switch to the other protocol. And this is not called
> alignement but downward compatibility. And we should try to achieve
> interoperability which means an agreed minimum level of communications.
> The accepted changes do not allow communications in both directions.
> 
> And that does not help any of the standardisation bodies, neither the
> IETF nor ISO.
> 
> That's in short why I am convinced that the discussion on the acceptance
> of these topics has to be reopened.
> 
> What is needed most urgently is a mechanism identifier in the time stamp
> request and in the time stamp response (i.e. within the time stamp
> token). And that is the only way I can imagine that allows
> interoperability between the two approaches.  Thanks again for your
> patience and support.
> 
> Roland


Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13024 for <[e-mail]>; Wed, 31 May 2000 09:12:54 -0700 (PDT)
Received: from com-and.com (lello.andxor.it [195.223.2.223]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id SAA49776; Wed, 31 May 2000 18:26:31 +0200 (CEST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 18:18:21 +0200
From: Raffaello Galli <[e-mail]>
Organization: C&A
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Timestamp: id for token
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------F032D8B75A2BD8E2AAD7C652"

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

The italian legislation requires a CA to have a TSA.
A totally independent third party TSA (i.e. using a self signed certificate)
is considered a CA (because creates its own certificates) and is
requested to be accepted, by the government, as a CA.
Because of this restriction and other (ITSEC)
for a CA is simpler to use a local owned and trusted TSA.
That is the way most of the italian CA are doing (at least the one
that are operating with our TSA).

Raffaello



[e-mail] wrote:

> Michael,
>
> Do you know if the Italian legislation mandates if these time stamps that a
> CA must obtain must come from a totally independent third party TSA (i.e.
> using a self signed certificate) or they could come from a TSA trusted by
> that CA (e.g. with a certificate issued by that CA)?
>
> Regards,
>
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]
>
> -----Original Message-----
> From: Michael Zolotarev [mailto:[e-mail]]
> Sent: Wednesday, May 31, 2000 12:43 AM
> To: Joerg Seidel; Manger, James H
> Cc: '[e-mail]'
> Subject: RE: Timestamp: id for token
>
> Case1:
>
> Italian legislation mandates that a CA obtains a time stamp for each
> published cert and CRLs. It also mandates that the TSA maintains the archive
> of all issued timestamps for the life span of the TSA key. So that the CA
> can be relieved from keeping the actual tokens.
>
> [snip]

--------------F032D8B75A2BD8E2AAD7C652
Content-Type: text/x-vcard; charset=us-ascii;
 name="r.galli.vcf"
Content-Description: Card for Raffaello Galli
Content-Disposition: attachment;
 filename="r.galli.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Galli;Raffaello
tel;cell:03482877460
tel;fax:++.39.2.24791826
tel;home:Please call me at work.
tel;work:++.39.2.24791823
x-mozilla-html:FALSE
url:www.com-and.com
org:C & A;Improve Your Security
adr:;;Viale Fulvio testi 126 ;Cinisello Balsamo   (MI);ITALY;20092;ITALY
version:2.1
email;internet:[e-mail]
title:Responsabile Tecnologie
note:Improving Your Security  ---  In God we Trust (sometimes) -- all others must submit an X.509 certificate ---
x-mozilla-cpt:;-30464
end:vcard

--------------F032D8B75A2BD8E2AAD7C652--



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12621 for <[e-mail]>; Wed, 31 May 2000 08:59:36 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA02703 for <[e-mail]>; Wed, 31 May 2000 12:00:57 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 31 May 2000 12:03:19 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: What is the meaning of the "indirectCRL" flag
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 2ri6TxKD2BcjQnGmjj/NTw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Bob Jueneman" <[e-mail]>
> 
> Presumably the relying party's Enterprise should be allowed to issue in 
internal-only CRL 
> or the equivalent, and have it be accepted by the various relying parties, so 
long as that 
> Enterprise's certificate is in the relying party's cache of trusted CA 
certificates, whether
> or not the name of that Enterprise had previously be listed in the Certificate 
Issuer Extension.



A CRL revokes the binding between identity, key, and attributes that
the CA established in the first place.

If the Enterprise wants to revoke the privileges of a now-untrusted user,
it should do something other than claim that the binding established
by the certificate is no longer valid.  (Unless the binding actually *is*
no longer valid, in which case the Enterprise should request that the CA
revoke the certificate.)



Received: from c004.sfo.cp.net (c004-h005.c004.sfo.cp.net [209.228.14.76]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA12337 for <[e-mail]>; Wed, 31 May 2000 08:55:50 -0700 (PDT)
Received: (cpmta 23850 invoked from network); 31 May 2000 09:02:56 -0700
Received: from cs9361-155.austin.rr.com (HELO tuvit.net) (24.93.61.155) by smtp.tuvit.net with SMTP; 31 May 2000 09:02:56 -0700
X-Sent: 31 May 2000 16:02:56 GMT
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 11:02:55 -0500
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: IETF-PKIX <[e-mail]>, "Manas, Jose A." <[e-mail]>, "Doonan, Wes" <[e-mail]>, "Matyas, Mike" <[e-mail]>
Subject: Re: Time Stamp V7 Data structure
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------418001B9CC70937931457ABB"

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

Hello Peter,

Peter Sylvester wrote:
> 
> >
> > This is a kind of re-opening the issue of aligning the actual ISO draft
> > on time stamping with version 07 of the PKIX time stamping draft.
> >
> > I am re-opening it for two reasons: Since the first time (version 5
> > discussion) I was expecting a change in the IETF document stating that
> > it is optional to have a mechanism identifier (object identifier) in the
> > time stamp request and I also expected a modified data structure
> > allowing to use the option. None of this happened. This information is a
> > prerequisite for developers willing to implement an IETF and ISO
> > compatible TSA.
> This is not quite true:
> 
This is a hard statement. There are at least two different ways to have
a default value as it was proposed by Tom: either the default is
interpreted as non-existent or as a pre-set value. And I had the
impression that for the latter at least an indicator is needed to point
out that this field will be used.

> It has been proposed not to indicate a mechanism identifier inside
> the information but to allow two different ways secure time
> stamps:
> 
> - one is using SignedData
> 
> - the other one is using DigestedData to support all cases
>   where you need a mechanism: The mechanism identifier would
>   become the digestalgorithm.
> 
> Thus, you have BOTH a way to indicate a mechanism, and a modified
> data structure.

Yes that's a solution but not a straight-forward one. And it does not
lead to interoperability for the the ISO protocol is a superset and we
are trying to achieve a common set. That's why I re-opened the
discussion.
> 
> By this proposal one avoids to create another new ASN1 structures
> and remains completely in the scope of CMS/PKCS7.
> 
> The top level data structure of a 'time stamp token' could
> be either :
> 
> - a document conforming to a cryptographic message syntax
> - a sequence of some data and whatever protection of that data
> 
> This anyway a matter of taste.
> 
> One could also create a mime multipart/timestamp to allow having
> two interpreters for the different parts, etc.
> 
> Peter Sylvester
> 
> 
Roland Mueller
--------------418001B9CC70937931457ABB
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------418001B9CC70937931457ABB--



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11899 for <[e-mail]>; Wed, 31 May 2000 08:42:41 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA08134; Wed, 31 May 2000 17:50:22 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 31 May 2000 17:50:22 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA04894; Wed, 31 May 2000 17:50:19 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA05917; Wed, 31 May 2000 17:50:19 +0200 (MET DST)
Date: Wed, 31 May 2000 17:50:19 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Time Stamp V7 Data structure
Cc: [e-mail], [e-mail], [e-mail], [e-mail]

The last two drafts of the text also contain serveral incompatible
changes to the asn1 syntaxes, is there some attempt to get an alignment?

> 
> as far as I understand the recent draft of the IETF there is nothing
> mentioning interoperability with the ISO draft, i.e. at least an
> optional data field (mechanism identifier). ISO has that field defined
> as an optional one and that was agreed on in January within ISO members.
> 
> ISO will be happy to specify a default value for PKIX mechanism in their
> data structure.
> 
> Roland


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11493 for <[e-mail]>; Wed, 31 May 2000 08:32:40 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA33134; Wed, 31 May 2000 17:39:49 +0200
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 17:39:47 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: AIA usage in TSA Certificate
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

François,

You are right. However the issue is progressing using some private
E-mail discusssions and I think that very soon (this week or next
week) we will be ready to post a proposal.

Just wait a few days more...  :-)

Denis

> 
> Denis,
> 
> I do not recall that the issue around the optional usage of the AIA
> extension in a TSA certificate was ever settle. If it was, what was the
> final resolution?
> 
> Regards,
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11199 for <[e-mail]>; Wed, 31 May 2000 08:27:23 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA07794; Wed, 31 May 2000 17:35:07 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 31 May 2000 17:35:07 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA04819; Wed, 31 May 2000 17:35:05 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA05909; Wed, 31 May 2000 17:35:05 +0200 (MET DST)
Date: Wed, 31 May 2000 17:35:05 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Time Stamp V7 Data structure
Cc: [e-mail], [e-mail], [e-mail]

> 
> This is a kind of re-opening the issue of aligning the actual ISO draft
> on time stamping with version 07 of the PKIX time stamping draft.
> 
> I am re-opening it for two reasons: Since the first time (version 5
> discussion) I was expecting a change in the IETF document stating that
> it is optional to have a mechanism identifier (object identifier) in the
> time stamp request and I also expected a modified data structure
> allowing to use the option. None of this happened. This information is a
> prerequisite for developers willing to implement an IETF and ISO
> compatible TSA.
This is not quite true: 

It has been proposed not to indicate a mechanism identifier inside
the information but to allow two different ways secure time
stamps:

- one is using SignedData

- the other one is using DigestedData to support all cases
  where you need a mechanism: The mechanism identifier would
  become the digestalgorithm.

Thus, you have BOTH a way to indicate a mechanism, and a modified
data structure. 

By this proposal one avoids to create another new ASN1 structures
and remains completely in the scope of CMS/PKCS7.

The top level data structure of a 'time stamp token' could
be either :

- a document conforming to a cryptographic message syntax
- a sequence of some data and whatever protection of that data

This anyway a matter of taste.

One could also create a mime multipart/timestamp to allow having
two interpreters for the different parts, etc. 

Peter Sylvester

 


Received: from europe.std.com (europe.std.com [199.172.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10801 for <[e-mail]>; Wed, 31 May 2000 08:22:32 -0700 (PDT)
Received: from world.std.com ([e-mail] [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id LAA05542; Wed, 31 May 2000 11:30:17 -0400 (EDT)
Received: from localhost (geer@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id LAA04585; Wed, 31 May 2000 11:30:16 -0400 (EDT)
Message-Id: <[e-mail]>
X-Authentication-Warning: world.std.com: geer@localhost didn't use HELO protocol
To: Rich Salz <[e-mail]>
cc: [e-mail]
Subject: Re: What is the meaning of the "indirectCRL" flag 
In-reply-to: Your message of "Wed, 31 May 2000 09:41:18 EDT." <[e-mail]> 
Date: Wed, 31 May 2000 11:30:16 -0400
From: Dan Geer <[e-mail]>

  > I believe that the more "important" or "valuable" a certificate is
  > -- and I am deliberately using vague terms since they are highly
  > context-specific -- the longer and more involved the
  > due-diligence/registration process should be.  Therefore, your
  > highly trusted, highly important CA should be off-line except for
  > those few moments when it needs to sign something.
  > 
  > Conversely (or should that be "perversely" :), in the event of a
  > compromise of one of those certificates, speed of revocation is
  > paramount.  Therefore, delegating revocation to an on-line,
  > always-up, CRL (or OCSP) server is a good thing.

downside risk due to certificate compromise:
* inversely proportional to certificate's depth in certification hierarchy

procedural costs of from-first-principles revocation testing:
* proportional to certificate's depth in certification hierarchy

because the above curves cross:
* separation of issuance and revocation is practically advantageous
* neglecting to check very distal certificates is economically rational

--dan




Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10627 for <[e-mail]>; Wed, 31 May 2000 08:21:40 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1VLQ>; Wed, 31 May 2000 11:30:11 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: AIA usage in TSA Certificate
Date: Wed, 31 May 2000 11:29:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

I do not recall that the issue around the optional usage of the AIA
extension in a TSA certificate was ever settle. If it was, what was the
final resolution?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10542 for <[e-mail]>; Wed, 31 May 2000 08:20:46 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA12639; Wed, 31 May 2000 08:27:40 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 30 May 2000 18:56:42 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-03
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

I guess that I do not object to the bulk of the rework in the Introduction 
that you propose.  This paragraph is an exception.  I do not agree at all.

>An AC may be used with various security services like:
>
>    1. access control in a client-server protocol environment,
>    2. data origin authentication in either a client-server protocol
>       or a store-and-forward environment, and
>    3. non-repudiation in a store-and-forward environment.

1.  Access control is not limited to interactive protocols.  For example, 
an AC containing clearance may determine whether e-mail should be sent to a 
particular recipient or not.

3.  Some protocols that are defined as interactive have portions of the PDU 
that persist.  For example, signed portions of the SET protocol were 
intended to provide proof that the cardholder's private key was involved in 
the transaction.  I would consider this non-repudiation, or at least 
support of non-repudiation.  I can easily imagine an AC specifying a 
short-term credit limit being included in such evidence.

In other words, I do not think the type of protocol determines which 
security services can be supported by an AC.

Russ


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10366 for <[e-mail]>; Wed, 31 May 2000 08:19:00 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1VLJ>; Wed, 31 May 2000 11:27:31 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Timestamp: id for token
Date: Wed, 31 May 2000 11:27:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Michael,

Do you know if the Italian legislation mandates if these time stamps that a
CA must obtain must come from a totally independent third party TSA (i.e.
using a self signed certificate) or they could come from a TSA trusted by
that CA (e.g. with a certificate issued by that CA)?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]



-----Original Message-----
From: Michael Zolotarev [mailto:[e-mail]]
Sent: Wednesday, May 31, 2000 12:43 AM
To: Joerg Seidel; Manger, James H
Cc: '[e-mail]'
Subject: RE: Timestamp: id for token

Case1:

Italian legislation mandates that a CA obtains a time stamp for each
published cert and CRLs. It also mandates that the TSA maintains the archive
of all issued timestamps for the life span of the TSA key. So that the CA
can be relieved from keeping the actual tokens.

[snip]


Received: from c004.sfo.cp.net (c004-h009.c004.sfo.cp.net [209.228.14.66]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA10111 for <[e-mail]>; Wed, 31 May 2000 08:14:59 -0700 (PDT)
Received: (cpmta 16469 invoked from network); 31 May 2000 08:22:09 -0700
Received: from cs9361-155.austin.rr.com (HELO tuvit.net) (24.93.61.155) by smtp.tuvit.net with SMTP; 31 May 2000 08:22:09 -0700
X-Sent: 31 May 2000 15:22:09 GMT
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 10:22:06 -0500
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
CC: IETF-PKIX <[e-mail]>, Wes Doonan <[e-mail]>, "Jose A. Ma~n" <[e-mail]>, [e-mail]
Subject: Re: Time Stamp V7 Data structure
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------5CA9DFB7CF0A79148CAB52BF"

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

Tom,

as far as I understand the recent draft of the IETF there is nothing
mentioning interoperability with the ISO draft, i.e. at least an
optional data field (mechanism identifier). ISO has that field defined
as an optional one and that was agreed on in January within ISO members.

ISO will be happy to specify a default value for PKIX mechanism in their
data structure.

Roland
--------------5CA9DFB7CF0A79148CAB52BF
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------5CA9DFB7CF0A79148CAB52BF--



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09459 for <[e-mail]>; Wed, 31 May 2000 07:56:31 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA14607 for <[e-mail]>; Wed, 31 May 2000 10:57:52 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 31 May 2000 10:59:34 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: SubjectAltName verification
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: jl7jivLNjnPGPRZ/qoFSWg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Bob,

In the case of cert field verification, there is a clear binary
distinction between explicitly endorsing placing NVI in certificates
and explicitly deprecating the practice.  That debate happened some
time ago.  It was decided at that time that NVI belongs somewhere
other than in PK certificates (such as directories, LAN management
databases, subject-signed Attribute certificates, or ...), that using PK  
certificates as a transport mechanism for such fluff simply because
it's convenient is bad practice, and that defining an NVI flag would
encourage the practice.

There may be disagreement over the decision itself, or over
the process by which it was made.  There may be a request to debate
the whole thing again and perhaps come to a different decision.
But it cannot be said that the decision was made last week, and
that a CA which was PKIX-conforming two weeks ago is not
PKIX-conforming today.  CAs which adhered to the RFC 2459 profile
two weeks ago will adhere to RFC 2459bis regardless of whether it
contains a statement of the obvious: that some communities may
choose to replace the PKIX profile with something else.

And given that CAs which choose not to conform with section
4.2.1.7 of RFC 2459 (January 1999) have a fig leaf (specifying in
the CPS some minimal gesture that could plausibly, or even
implausibly, pass for verification), the assertion that there was
some substantive change within the last week related to NVI and
PKIX conformance is pure horsewater.

- - - - - -

On the topic of non-repudiation, I admit to being disappointed that the
WG couldn't reach agreement on my point of view :-)!  (that key usage
bit 1 means "Persistent Data Origin Authentication With Third Party
Proof", that "technical non-repudiation" is an acceptable term
for PDOAWTPP, and that there are objective processing and handling
differences between PDOAWTPP keys, Entity Authentication keys, and
Key Establishment keys which make it inadvisable to deprecate the
bit entirely).  But given that PKIX could not reach agreement after
interminable months of discussion, I don't see what could be done
other than punt and let individual communities (individually and
cooperatively) profile use of the bit as they see fit.

If that is what you meant by "letting commercial practice sort
out the issue", we agree that no obviously better course of action
is apparent.

Regards,
Dave



> Date: Tue, 30 May 2000 11:43:24 -0600
> From: "Bob Jueneman" <[e-mail]>
> Cc: <[e-mail]>
> Subject: Re: SubjectAltName verification
> 
> Let me offer some comments on what I believe is a very important,
> and obviously contentious issue.
> 
> In the past, the IETF has been primarily concerned with issues of 
> over-the-wire protocol and structures, and the syntactic definitions 
> of those fields.
> 
> Other issues, and in particular issues that pertained to commercial
> business practices and/or various (potential) legal issues have generally 
> been left to the relevant experts in those fields to define.
> 
> In particular, the tradition within the IETF has been to espouse only 
> purely technical issues, regardless of their potential business impact --
> indeed, sometimes amazingly oblivious to such issues.
> 
> As a result, the PKIX WG (and X.509) is, at least in my mind, notorious 
> for failing to adequately come to grips with the precise semantic meaning 
> of many of the terms that are defined.  As a case in point, I would cite 
> the complete lack of any agreement whatsoever as to the 
> semantic meaning of the "nonrepudiation" key usage, either from a legal 
> perspective or a narrower, but still useful set of do/don't do perspectives 
that
> would apply to end user software, either the CA, the originator, or the 
relying 
> party.
> 
> As a result, the term is neither defined, nor deprecated.  Apparently the 
> consensus was to let commercial practice sort out the issue, and perhaps 
> this is in fact the best course.
> 
> The PKIX WG, has long since departed from the traditional IETF practice 
> of "rough consensus and running code".  Now we are institutionalizing 
> some of the most disliked features of ISO and we have become a 
> "design-by-committee" organization.  Unlike ISO, however, where various 
> countries explicitly take into account various national objectives, and weigh, 
> or at least try to weigh, the various commercial interests before coming to
> agreement, we generally fail to do so.
> 
> The IETF lacks any form of institutional representation of business interests 
--
> every contributor's comment or vote is treated exactly the same as every 
other,
> regardless of how small or how large the contributor's company's stake might
> be the in the outcome.
> 
> That's of course very democratic, and everyone has a more or less equal chance 
> to carry the day based on their individual fervor and ability to persuade. 
Unfortunately,
> this tends to mean that anyone can propose his own pet rock for standards 
> consideration, regardless of the commercial viability of that approach.  
> 
> I am particularly thinking of the blatant anti-intellectual property 
preferences 
> of the IESG, and their instance on including as mandatory features encryption 
> algorithms which have not been well accepted in the marketplace. The various 
> working groups then exacerbate the problem by adding more and more features 
and 
> algorithms to the list of "approved" or "standard" featured, often at the 
behest of
> a very small community of interest.  Yet every one of these additional 
features takes 
> some amount of additional coding (generally not too large) to implement, plus 
> significantly more in terms of GUIs and documentation, and an exponentially 
> increasing amount of testing, all for little or no consumer benefit.
> 
> But because of the importance of standards per se, the products are under a 
> considerable amount of pressure to be "conforming" to requirements that have 
> not been validated by the user community, and to which the user community had 
little or 
> no say so, and the cost and complexity inevitably leads to both buggy and 
> expensive software
> 
> On the other hand, existing commercial practices may suddenly be deemed to be 
> inappropriate or nonconforming, sometimes despite a considerable body of 
commercial 
> acceptance, in a rather high-handed "father knows best" attitude.  Since the 
commercial 
> entities may have only a few representatives, they may not be able to offset 
the 
> opinions offered by others with competing interests.
> 
> I believe this is an increasingly unsatisfactory state of affairs, and may 
eventually lead 
> to the IETF being regarded as more or less irrelevant to both the vendor and 
the 
> user community, particularly if existing commercial practices are suddenly, 
and perhaps 
> rather capriciously, labeled as being non-conforming.
> 
> Now, how does this apply to the current controversy?
> 
> By not adopting either an opt-out indication that certain perhaps useful
> information has not been explicitly validated by the CA, perhaps because it 
isn't 
> economically feasible to do so, the implication is that everything in the 
certificate
> is God's own BINARY truth.  And if you don't believe that, go off and read 80 
> or more pages of legalese to determine exactly what is meant. Of course 
computer
> programs can't do that, so we will resort to more and more complex schemes of
> policy OIDs, policy constraints, name constraints, etc., until we have no 
interoperability
> at all, or otherwise the relying parties will decide to limit the amount of 
trust that 
> they put in a certificate to a lowest common denominator across the entire
> industry.
> 
> I would submit that neither approach is very helpful.
> 
> We don't even seem to be able to agree as to what the problem is.
> 
> Denis Pinckas says:
> 
> >In RFC 2459, section 4.1.2.6  Subject, we currently have:
> 
> >   Where it is non-empty, the subject field MUST contain an X.500
> >   distinguished name (DN). The DN MUST be unique for each subject
> >   entity certified by the one CA as defined by the issuer name field. A
> >   CA may issue more than one certificate with the same DN to the same
> >  subject entity.
> 
> >Let us suppose that we use an *empty* distinguished name (which is
> >allowed by the standard). Should the above property also apply to
> >the alternative name ? I would think so and I understood 
> >"definitively bound" as equivalent to "unique". In other words the
> >subject Alternative name once assigned must never be re-assigned for
> >a different entity by the CA. To this respect, the other fields that
> >where mentioned are not "definitively bound". So you now understand
> >the rational of the change that was made.
> 
> I won't say that Denis' argument doesn't make any sense at all, but 
> equating "definitively bound" to "unique" seems to me to be a very great
> leap.
> 
> At least to me, "definitively bound" inherently implies the "correctness" of 
the 
> attribute that is bound to the key, and by implication to the persona who is 
> affiliated with that attribute in some fashion.
> 
> Granted, if the name is merely a e-mail address or post office box, it is very 
difficult
> and perhaps impossible to correlate that name to any particular real person, 
even if 
> (especially if) it is [e-mail]. 
> 
> On the other hand, if the DN (or any other field in the certificate) does 
presumably
> uniquely define an organizational or residential person by a globally unique 
name, 
> then a reasonable inference to be drawn from the certificate which binds both 
> the DN and subjectAltName to the same key is that they same persona is somehow
> involved.
> 
> Does that mean that the identified user has sole and exclusive access to that 
> e-mail address (i.e., his spouse and kids don't share the same mail box), or 
that he 
> even bothers to read his mail there?  Not necessarily.
> 
> Then exactly what does "validate", much less "definitively bound" mean in this 
> circumstance?  I don't like to have to say so, but the only option at this 
point is to
> say "go read the CP/CPS".
> 
> The biggest problem, I believe, is that we are attempting to apply rather 
> Procrustean binary logic to a problem that inherently involves shades of gray.
> 
> We can say "This value is either a 1 or a 0, and that's that.", but this is 
subject
> to potentially hidden provisos in the CP or CPS, "for suitably defined values 
of 1 
> and/or 0".
> 
> Trying to say that something is "right" or "not right", regardless of existing 
> commercial practice would seem to pretend to a moral and/or legal
> authority that the IETF simply doesn't command, unless the Pope has suddenly 
> become a silent co-chair.
> 
> On the other hand, saying nothing at all, and leaving it up to a completely 
laissez faire
> interpretation a la nonrepudiation isn't very helpful or useful either.
> 
> That's one reason why in the Novell Security Attributes extension we include 
in 
> all of our certificates, we define a "Certificate Class" that ranges from 0 to 
255,
> in an attempt to define some shades of gray between a completely anonymous 
user
> and a sovereign government. 
> 
> Cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm .
> 
> Regards,
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08929 for <[e-mail]>; Wed, 31 May 2000 07:44:00 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA35292; Wed, 31 May 2000 16:51:37 +0200
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 16:51:36 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

François,

> Salut Denis,
> 
> I agree with both the word change and the proposed pointer.
> 
> However, I still think that leaving the term "timeliness" in Section 2.2
> could be misinterpreted to mean that a requesting entity MUST reject a
> totally valid response because of possible delays in the intervening network
> elements and/or a drifting of this requesting entity own local time
> reference.
> 
> According to Section 2.2, what would a requesting entity be required to do
> if he/she receives a time stamp token with the right hash value and nonce,
> however the time included in the response is before or very much later than
> his/her own local trusted time reference?

The current sentence is:

 ... by verifying *either* the time included in the response against
a local trusted time reference, if one is available, *and/or* the
value of the nonce (large random number with a high probability that
it is generated by the client only once) included in the response
against the value included in the request.

Instead of "and/or", we could say "or". Would this solve your
concern ?

Denis 

 
> Regards,
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, May 31, 2000 4:19 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Rationale for Nonce in Time Stamp Protocol
> 
> François,
> 
> I have inserted your text, with one change, in the security
> considerations section of the "moving draft" I am locally
> maintening.
> 
> Instead of: If the same hash value is *generated* more than once
> within a time window,
> 
> I have inserted: If the same hash value is *present* more than once
> within a time window,
> 
> About your proposal of changing the text in section 2.2., I believe
> that the current text is fine. Deleting "timeliness" and replacing
> is by "replay" is more restrictive. We could however add a pointer
> to the security consideration section, like: "For more details,
> about replay attack detection see the security considerations
> section (item 6)".
> 
> Denis


Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08666 for <[e-mail]>; Wed, 31 May 2000 07:37:07 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA232174; Wed, 31 May 2000 10:37:23 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id KAA105808; Wed, 31 May 2000 10:39:08 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568F0.00507B37 ; Wed, 31 May 2000 10:39:04 -0400
X-Lotus-FromDomain: IBMUS
To: Roland Mueller <[e-mail]>
cc: IETF-PKIX <[e-mail]>, Wes Doonan <[e-mail]>, "Jose A. Ma~n" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 10:38:56 -0400
Subject: Re: Time Stamp V7 Data structure
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     May I ask what happened to the suggestion that mechanism identifier in
the ISO version be given a DEFAULT value which would be assigned to the
PKIX mechanism?  That would probably allow the ISO version to be used to
communicate with the current draft.

          Tom Gindin

Roland Mueller <[e-mail]> on 05/30/2000 11:34:43 PM

To:   IETF-PKIX <[e-mail]>
cc:   Wes Doonan <[e-mail]>, "Jose A. Ma~n" <[e-mail]>,
      Stephen Matyas/Poughkeepsie/IBM@IBMUS
Subject:  Time Stamp V7 Data structure



This is a kind of re-opening the issue of aligning the actual ISO draft
on time stamping with version 07 of the PKIX time stamping draft.

I am re-opening it for two reasons: Since the first time (version 5
discussion) I was expecting a change in the IETF document stating that
it is optional to have a mechanism identifier (object identifier) in the
time stamp request and I also expected a modified data structure
allowing to use the option. None of this happened. This information is a
prerequisite for developers willing to implement an IETF and ISO
compatible TSA.

The answer I received from the eeditor on the change of the data
structure was  from my point of view sufficient for it only meant an
endorsement to use additional elements in  the ISO data structure: "For
the request the additional element will be in the ISO request, NOT in
the IETF request."

That means, ISO gets endorsement for its data structure. I was asking
for a change in the IETF data structure, the mechanism Identifier
element ALREADY exists in the ISO Time stamp request data structure.

On the other hand I have to express that the adoption of a mechanism
identifier into the time stamp token is required to allow proper
interpretation by the recipient of such a token. If the mechanism used
for generating the token cannot be identified then the validity of a
time stamp cannot be checked if it is not the IETF mechanism. If time
stamps are generated using a mechanism different from the IETF draft and
there is no information provided within the token what mechanism was
used to generate the time stamp then a verifier does not know how to
proceed. If the time stamp was generated with one of the mechanisms
proposed in the ISO draft then information is needed to successfully
verify the validity of the time stamp. Otherwise an ISO time stamp is
not usable by  recipients of the time stamp for they cannot verify its
validity.

Let me explain the need for the mechanism identifier in the request also
in an example: A client using the IETF protocol may communicate with
either an ISO or an IETF TSA when requesting a time stamp; this will
cause no problem for the ISO TSA will understand the request of the
client.

The situation gets more difficult if the client uses the ISO protocol. A
TSA only understanding IETF requests will detect general incompatibility
and answer with an error; this leaves the client without a time stamp if
he cannot switch to the other protocol. And this is not called
alignement but downward compatibility. And we should try to achieve
interoperability which means an agreed minimum level of communications.
The accepted changes do not allow communications in both directions.

And that does not help any of the standardisation bodies, neither the
IETF nor ISO.

That's in short why I am convinced that the discussion on the acceptance
of these topics has to be reopened.

What is needed most urgently is a mechanism identifier in the time stamp
request and in the time stamp response (i.e. within the time stamp
token). And that is the only way I can imagine that allows
interoperability between the two approaches.  Thanks again for your
patience and support.

Roland






Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08425 for <[e-mail]>; Wed, 31 May 2000 07:30:38 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1VG5>; Wed, 31 May 2000 10:38:59 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Rationale for Nonce in Time Stamp Protocol
Date: Wed, 31 May 2000 10:38:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA08426

Salut Denis,

I agree with both the word change and the proposed pointer.

However, I still think that leaving the term "timeliness" in Section 2.2
could be misinterpreted to mean that a requesting entity MUST reject a
totally valid response because of possible delays in the intervening network
elements and/or a drifting of this requesting entity own local time
reference.

According to Section 2.2, what would a requesting entity be required to do
if he/she receives a time stamp token with the right hash value and nonce,
however the time included in the response is before or very much later than
his/her own local trusted time reference?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, May 31, 2000 4:19 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol


François,

I have inserted your text, with one change, in the security
considerations section of the "moving draft" I am locally
maintening.

Instead of: If the same hash value is *generated* more than once
within a time window, 

I have inserted: If the same hash value is *present* more than once
within a time window, 

About your proposal of changing the text in section 2.2., I believe
that the current text is fine. Deleting "timeliness" and replacing
is by "replay" is more restrictive. We could however add a pointer
to the security consideration section, like: "For more details,
about replay attack detection see the security considerations
section (item 6)". 

Denis


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07966 for <[e-mail]>; Wed, 31 May 2000 07:14:36 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiroj25964; Wed, 31 May 2000 14:22:16 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA15780; Wed, 31 May 00 10:18:46 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA09276; Wed, 31 May 2000 10:22:15 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 31 May 2000 10:22:14 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: RE: Timestamp: TSA Response serialNumber Field
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Manger," == Manger, James H <[e-mail]> writes:

 Manger,> ...We could have two uncertainties: (1) the uncertainty between
 Manger,> genTime and UTC; and (2) the uncertainty between
 Manger,> "simultaneous" measurements by the TSA.  If a TSA has many
 Manger,> clocks (e.g. one for each crypto engine) the second value is
 Manger,> the uncertainty in synchronisation between its own clocks.
 Manger,> However, I don't think this (or your BOOLEAN) is necessary.
 
I agree with that conclusion.  A clean way to solve it is to say that
the rule for comparing timestamps with their accuracy (i.e., the
partial order we've been talking about) applies to pairs of timestamps
no matter what their source.  In other words, it applies to a pair
from a "single" source just as it does for timestamps from two
independent TSAs.  That's conservative (it is probable that the
relative synchronization of multiple internal clocks is tighter than
the synchronization to UTC) but I can't see that it hurts a whole lot.

This takes care of the "large TSA" issue.  It also takes care of the
restart problem, where an "internal" clock is volatile but refreshed
from a non-volatile reference at startup.  That's of course the common
PC model, and may well fit other types of devices too.  Admittedly it
is not all that likely that a box can restart in less time than 2 *
accuracy, but it doesn't hurt to cover that case.

Hm... if you assume a large modular TSA, should you assume it has a
single global "sequence number" generator?  Of course, if that data
item is just a unique ID (e.g., hash) as has been argued, this is a
non-issue.  If it is an increasing number, though, then it has to be a
single global resource, which would also be problematic in this
scenario.  Not as much as tightly synchronized clocks, admittedly.  

	  paul


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAB07702 for <[e-mail]>; Wed, 31 May 2000 07:07:33 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiroj16158; Wed, 31 May 2000 14:15:14 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA15677; Wed, 31 May 00 10:11:44 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA09273; Wed, 31 May 2000 10:15:12 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 31 May 2000 10:15:12 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: RE: TSA Response serialNumber Field
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Manger," == Manger, James H <[e-mail]> writes:

 Manger,> Michael,
 >> How do you know when the "Time stops" and the "Order begins"?
 Manger,> You never need to know - that is the beauty.

 

 >> Stamp from TSA_1: 20000529053138.345Z. Accuracy = 1 sec.  Stamp
 >> from TSA_2: 20000529053138.876Z. Accuracy = 1 sec How do I do it
 >> [compare the stamps]?
 Manger,> Consider T2 - T1.  The best estimate (mean) is .876 - .345 =
 Manger,> .531.  When subtracting measurements the uncertainty is the
 Manger,> square root of the sum of the squares of the individual
 Manger,> uncertainties: sd = sqrt(1^2 + 1^2) = 1.414.

 Manger,> => T2 - T1 = 0.531 +/- 1.414

 Manger,> => Probability that T2 is after T1 = Pr(0 < x | x sample of
 Manger,> X = Normal-Distribution(mean=0.531, sd=1.414)) = Pr(-0.375 <
 Manger,> x | x sample of X = Standard-Normal-Distribution) = 0.65

 Manger,> So there is a 65% chance that the stamp from TSA_1 was
 Manger,> issued before the stamp from TSA_2.  Comparison done.

I would rather describe this as "order is indeterminate", but if you
are doing fuzzy logic then I guess an answer expressed as a
probability may work.

However, there are a couple of assumptions that are probably not
warranted.  

First, I would not assume that "accuracy" is the standard deviation.
I view it as guarantees on the timestamp.  So you might use six sigma,
but surely not one sigma.

Second, you're (I believe) assuming normal distribution.  That may not
be valid.  In fact, with commonly used crystal oscillators it is known
not to be anywhere close to valid.

This does indicate the need to spell out more carefully what
"accuracy" is supposed to mean.  If the consensus is that it's the
standard deviation of an assumed normal distribution, I won't be happy
about that but so long as it's written down at least I can take
corrective measures.

 >> 1. Do I assume that .345 and .876 is just ordering?
 Manger,> No.

Blame it on the fact my father is a metrologist, but I don't care at
all for the inclusion of insignificant digits.  As far as I am
concerned, and as far as I've been trained, a value given as 123.456
+/- 1 is simply an error.

    paul


Received: from mail-fwd.verio-web.com ([161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA07024 for <[e-mail]>; Wed, 31 May 2000 06:35:10 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.53) with SMTP id 0252032; Wed, 31 May 2000 09:42:28 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 09:41:18 -0400
From: Rich Salz <[e-mail]>
Organization: Caveo Systems, Inc.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: What is the meaning of the "indirectCRL" flag
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> I agree with the statement that normally, only the entity that issued
> the certificate is allowed to revoke it, or more generally to respond negatively
> to an inquiry about certificate status.

I strongly disagree.

I believe that the more "important" or "valuable" a certificate is -- and I
am deliberately using vague terms since they are highly context-specific --
the longer and more involved the due-diligence/registration process should
be.  Therefore, your highly trusted, highly important CA should be off-line
except for those few moments when it needs to sign something.

Conversely (or should that be "perversely" :), in the event of a compromise
of one of those certificates, speed of revocation is paramount.  Therefore,
delegating revocation to an on-line, always-up, CRL (or OCSP) server is a
good thing.

It is MUCH easier to recover from believing faulty revocation than from
relying on a compromised certificate.
	/r$


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06305 for <[e-mail]>; Wed, 31 May 2000 05:55:16 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07798; Wed, 31 May 2000 09:02:57 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithms to Proposed Standard
Date: Wed, 31 May 2000 09:02:57 -0400
Sender: [e-mail]

The IESG has approved the Internet-Draft 'Diffie-Hellman
Proof-of-Possession Algorithms' <draft-ietf-pkix-dhpop-02.txt> as a
Proposed Standard.  This document is the product of the Public-Key
Infrastructure (X.509) Working Group.  The IESG contact persons are
Jeffrey Schiller and Marcus Leech.


 
Technical Summary
 
  One of the important requirements in cryptographic protocols is the
  ability for an entity to prove they have possession of a particular
  key. In particular, Certifying Authorities prior to the issuance of a
  certificate, need to prove that the entity for which the certificate
  will be issued in fact does have the private key that corresponds to
  the public key which is included in the certificate.

  The traditional approach used with public key encryption systems such
  as the RSA system is to have the challenger require the entity
  holding a given private key to sign a challenge string.

  However the Diffie-Hellman (DH) algorithm does not directly lend
  itself to providing such signatures, as it is at heart a key
  agreement algorithm.  This document describes two methods for
  producing a signature from a Diffie-Hellman key pair.

Working Group Summary

  Consensus was reached on the approach used in this document.

Protocol Quality

  Jeffrey I. Schiller reviewed this document for the IESG. Furthermore
  the PKIX Working Group contains members with significant
  cryptographic experience who also have reviewed this document.

Note to RFC Editor:

There were some word-wrapping problems introduced in Appendix A of 
the document that need to be corrected:

Appendix A:

OLD:
   DH-Sign DEFINITIONS IMPLICIT TAGS ::=

   BEGIN
   --EXPORTS ALL
   -- The types and values defined in this module are exported for use
   in
   -- the other ASN.1 modules. Other applications may use them for
   their
   -- own purposes.

NEW/FIXED:
   DH-Sign DEFINITIONS IMPLICIT TAGS ::=

   BEGIN
   --EXPORTS ALL
   -- The types and values defined in this module are exported for use
   -- in the other ASN.1 modules. Other applications may use them
   -- for their own purposes.


Received: from USCOMM02.aholdusa.com (mch215.aholdusa.com [207.198.9.215] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA06132 for <[e-mail]>; Wed, 31 May 2000 05:42:10 -0700 (PDT)
Received: by USCOMM02.aholdusa.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568F0.00466DAD ; Wed, 31 May 2000 08:49:15 -0400
X-Lotus-FromDomain: AHOLD
From: "Rusty Gregg" <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 08:53:44 -0400
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04669 for <[e-mail]>; Wed, 31 May 2000 05:05:11 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA03594; Wed, 31 May 2000 14:12:48 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 31 May 2000 14:12:48 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA03992; Wed, 31 May 2000 14:12:42 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA05859; Wed, 31 May 2000 14:12:41 +0200 (MET DST)
Date: Wed, 31 May 2000 14:12:41 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol
Cc: [e-mail]

All,

You can safely forget my comments about the 'chosen plain text'
attack from yesterday. I forgot that the message signing
used in the time stamp always includes signed attributes. 

On the other hand I think one could still weaken the
requierement that the Nonce of the time stamp must be identical
to the one in the request and only require that it must
be a prefix/suffix of it.

Needless to say, that I am not sure whether a Nonce is ever
need anyway, but that's another story. 

Sorry for the irritation that my comment might not have caused.
peter


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01776 for <[e-mail]>; Wed, 31 May 2000 03:39:20 -0700 (PDT)
Received: by balinese.baltimore.ie; id LAA18650; Wed, 31 May 2000 11:47:03 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma018633; Wed, 31 May 00 11:46:38 +0100
Received: from baltimore.ie ([192.168.20.134]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA07681; Wed, 31 May 2000 11:46:26 +0100
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 11:47:13 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'Andy Dowling'" <[e-mail]>, [e-mail]
Subject: Re: Requirements for remote path processing services
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish,

Though what you suggest is possible, I think its just not
in scope for PKIX. There are lots of reasons, but one is
that there's really no point in us attempting to define 
an authorization protocol that can *only* use PKI based 
authentication. If we omit requirements to do with other 
forms of authentication (e.g. Kerberos, OTP, RADIUS,...) 
then we're just not doing a good job. I can't see 
any way to interpret the PKIX charter to incorporate such 
(real) requirements. Maybe you should look to the AAA
WG to pursue this?

Regards,
Stephen.


Ambarish Malpani wrote:
> 
> Hi Andy,
>     You could use the remote path processing server (RPPS) to verify
> ACs, or even better, you could actually use it to authorize
> certain user actions and avoid needing to deal with ACs at all!
> 
> In the case where you do trust the RPPS, the kind of query I expect
> an application to send it, would be of the form:
> "Can I trust this certificate to do the following action".
> 
> At that state, I would fully expect the RPPS to go out and figure
> out what the attributes of the certificate are, so, as an
> application, you can be completely relieved of the job of
> processing ACs at all.
> 
> Does this make sense?
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Andy Dowling [mailto:[e-mail]]
> > Sent: Monday, May 29, 2000 4:02 AM
> > To: Paul Hoffman
> > Cc: [e-mail]
> > Subject: Re: Requirements for remote path processing services
> >
> >
> > Paul + co.,
> >
> > Having read your post, I was just wondering if these remote
> > path processing
> > services could be applied to ACs for authorisation purposes? I've put
> > together a few points on the subject (see below).
> >
> > Comments would be appreciated.
> >
> > Regards,
> >
> > Andy
> >
> >
> >
> > 1) OVERVIEW
> >
> > In addition to remote path processing services:
> >
> > a) delegated path construction
> > b) delegated path verification
> > c) trust and policy centralisation
> >
> > that apply to public key certificates, there may be scope for
> > the application of these services to authorisation-related
> > certificates
> > i.e. Attribute Certificates could be verified remotely by a single
> > trusted entity, and this would bring the benefits of centralised
> > trust/policy management and simpler clients.
> >
> >
> > 2) MOTIVATION
> >
> > Firstly, let's present some arguments *against* introducing remote AC
> > validation:
> >
> > a) The current profile for AC validation is relatively simpler than
> >    that of PKC validation:
> >
> >         a) AC chains are not used
> >         b) AAControls is optional
> >         c) AC revocation checking is optional
> >
> >    Consequently, a very minimal (and conformant) AC validator can be
> >    implemented and would be "lightweight" enough to provide
> > on clients.
> >
> > b) AC validation for authorisation purposes is typically a server-side
> >    operation anyway, and clients would hardly need to validate an AC.
> >
> >
> > In response to argument (a):
> >
> >      Whilst a client may indeed conform to the simplest
> > version of the AC
> >      profile with a lightweight implementation, such an implementation
> >      would have no control over which attributes can be
> > issued by which
> >      authorities (AAControls), due to the lack of chain processing.
> >      In addition, the client cannot safely validate long-lived ACs.
> >      This is due to the lack of revocation processing.
> >
> > In response to argument (b):
> >
> >      Clients *may* need to validate ACs in the push model to
> >      ensure the integrity of the AC before passing it on to other
> >      servers. (Complications arise here when the AC is pushed to a
> >      different "trust domain" where the AC validation policy differs
> >      to that of the clients policy, so there's scope for
> > further study here)
> >
> >      A client will need to validate an AC if it is used in
> > the making of
> >      a client-side access decision. Scenarios in which a client-side
> >      access decision would need to be made are:
> >
> >             --> Checking the permissions of downloaded content:
> >                 --> Has a piece of downloaded code have
> > execute permission
> >                     from the system admin?
> >
> >             --> Client-side content filtering:
> >                  -> Checking if downloaded content has a
> > "rating" attribute
> >                     (12, 15, 18, PG-13, NC-17, R, etc.)
> >
> >
> > It is apparent that there is indeed a requirement for:
> >        (a) clients to validate ACs
> >        (b) AC validation to be performed "fully". That is, AAControls
> >            and revocation checking should be done for
> > security reasons.
> >
> > Given these requirements, it seems logical to migrate these
> > verification
> > tasks to a dedicated AC validation server.
> >
> >
> > 2) BENEFITS:
> >
> > The benefits are the same as for remote PKC processing:
> >
> > a) Centralised trust and policy for authorisation purposes
> >
> >     (i)   Administrator(s) can say what AAs are trusted by
> > the enterprise
> >     (ii)  Administrator(s) can implement complicated trust
> > management via
> >                            AAControls and/or AC Chain validation
> >     (iii) Administrator(s) can implement AC revocation checking
> >
> > b) Simplified clients
> >     (i)  No need for the client to implement any form of AC
> > verification,
> >          path processing (for AAControls), LDAP/OCSP clients, etc.
> >
> > c) Server-side caching to improve turnaround time on a
> > validation request
> >
> >
> >
> >
> >

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25606 for <[e-mail]>; Wed, 31 May 2000 02:24:36 -0700 (PDT)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01322; Wed, 31 May 2000 02:32:09 -0700 (PDT)
Received: from sun.com (boston [129.156.238.80]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id KAA19249; Wed, 31 May 2000 10:32:08 +0100 (BST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 10:32:08 +0100
From: Sean Mullan <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Eddy <[e-mail]>
CC: Gabriel =?iso-8859-1?Q?L=F3pez=20Mill=E1n?= <[e-mail]>, [e-mail]
Subject: Re: PKIX library
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

You may also be interested in the development of a new standard
Java API for handling certification paths.

The Java Certification Path API is a Java API that is
currently being specified using the Java Community Process.
The API is targeted for the next release of J2SE (Java
2 Standard Edition). It will include Java classes for building
and validating certification paths, and will be based on
the standard Java Cryptography Architecture. A reference 
implementation of the APIs including an RFC 2459 certification 
path validation implementation is planned.

Please see http://java.sun.com/aboutJava/communityprocess/jsr/jsr_055_certp.html
for the Java Specification Request, which includes more information
about this API.

Thanks,
Sean

Eddy wrote:
> 
> Hi Gabi,
> 
> I assumed that you are talking about implementation of Cert. Management
> Protocol (CMP)?
> 
> Since the last release of JCSI, we have implemented and changed a fair
> bit.  I guess more importantly for you, we have also add CMP support in
> JCSI.  At the moment, I am working on getting CMC support.
> 
> That said, however, we are still doing some QC before we will release
> the next version of JCSI (v1.0).  I am not sure even if CMP will make it
> into next release.
> 
> If you really keen on getting your hand on CMP library in Java, please
> email me separately (ie. not through email list) We can talk about how
> and if you can get your hand on those library.
> 
> Cheers...
> Eddy
> 
> Gabriel López Millán wrote:
> >
> > Gabriel López Millán wrote:
> >
> > >     Hello all.
> > >
> > >     There is any free pkix library for Java?
> > >
> > >     Thanks, Gabi.
> >
> >         OK, I am testing JCSI library. It is good, but I want a library
> > which I can construct PKIMessages, with PKIBody, PKIHeader, etc.
> >
> >     There is anything?
> >
> >     Thanks a lot, Gabi.


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22406 for <[e-mail]>; Wed, 31 May 2000 01:10:53 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA16114; Wed, 31 May 2000 10:18:30 +0200
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 10:18:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

François,

I have inserted your text, with one change, in the security
considerations section of the "moving draft" I am locally
maintening.

Instead of: If the same hash value is *generated* more than once
within a time window, 

I have inserted: If the same hash value is *present* more than once
within a time window, 

About your proposal of changing the text in section 2.2., I believe
that the current text is fine. Deleting "timeliness" and replacing
is by "replay" is more restrictive. We could however add a pointer
to the security consideration section, like: "For more details,
about replay attack detection see the security considerations
section (item 6)". 

Denis


> Salut Denis,
> 
> As requested, I have made some small changes to your proposed text about the
> nonce for the security consideration section and the amended version, with
> deletes and inserts tagged, appears below:
> 
> "Inadvertent or deliberate replays for requests incorporating the same hash
> (algorithm and) value may happen. Inadvertent replays occur when more than
> one copy of the same request message gets sent to the TSA because of
> problems in the intervening network elements. Deliberate replays occur when
> a middleman is replaying legitimate TS responses. In order to detect these
> situations, several techniques may be used. Using a nonce always allows to
> detect replays, and hence its use is RECOMMENDED. Another possibility is to
> use both a local clock and a moving time window during which the requester
> remembers all the hashes sent during that time window. When receiving a
> response, the requester <inserted>ensures</inserted> <deleted>makes sure
> that</deleted> both <inserted>that</inserted> the time of the response is
> within the time window and that there is only
> <deleted>once</deleted><inserted>one occurrence of</inserted> the hash value
> in that time window. If <deleted>there is</deleted> the same hash
> value<inserted>is generated</inserted> more than once <inserted>within a
> time window</inserted>, the requester may either use a nonce, or wait until
> the time window has moved to come back to the <deleted>previous</deleted>
> case where the same hash value appears only once during that time window."
> 
> However, you have left the second paragraph of Section 2.2 unchanged, which
> may still be open to interpretation. The way it is currently written, it
> would seem that a requesting entity would have to reject a totally valid
> response because of possible delays in the intervening network elements
> and/or drifting of the requesting entity own local time reference. In order
> to avoid this possible interpretation, an amended version, also with deletes
> and inserts tagged, appears below:
> 
> "It SHALL then verify the <deleted>timeliness of the </deleted>response
> <inserted>against replay </inserted>by verifying either the time included in
> the response against a local <deleted>trusted </deleted>time reference, if
> one is available, and/or the value of the nonce (large random number with a
> high probability that it is generated by the client only once) included in
> the response against the value included in the request. If any of the
> verifications above fails, the TimeStampToken SHALL be rejected."
> 
> Regards,
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Tuesday, May 30, 2000 6:09 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Rationale for Nonce in Time Stamp Protocol
> 
> François,
> 
> Sorry for the delay to answer, but the trafic is currently rather
> heavy on the TSP document and it takes time to prepare answers.
> 
> I do not agree to make the nonce mandatory since there exists cases
> where it is not needed. I also do not think that the case of a
> subverted TSA falls under the topic of "deliberate replay".
> 
> However, in order to address your concern, I could add the following
> text in the security consideration section :
> 
> Inadvertent or deliberate replays for requests incorporating the
> same hash (algorithm and) value may happen. Inadvertent replays
> occur when more than one copy of the same request message gets sent
> to the TSA because of problems in the intervening network elements.
> Deliberate replays occur when a middleman is replaying legitimate TS
> responses. In order to detect these situations, several techniques
> may be used. Using a nonce always allows to detect replays, and
> hence its use is RECOMMENDED. Another possibility is to use both a
> local clock and a moving time window during which the requester
> remembers all the hashes sent during that time window. When
> receiving a response, the requester makes sure that both the time of
> the response is within the time window and that there is only once
> the hash value in that time window. If there is the same hash value
> more than once, the requester may either use a nonce, or wait until
> the time window has moved to come back to the previous case where
> the same hash value appears only once during that time window.
> 
> If you prefer a different wording, please provide the amended text.
> 
> Denis
> 
> > Denis,
> >
> > We probably need to be clear on the requirement and then we can be sure
> that
> > the text in the document reflects the requirement.
> >
> > You seem quite clear that the requirement is to prevent replays - but we
> > need to be clear on whether we are trying to detect and/or prevent
> > deliberate or inadvertent replay or both.  Inadvertent replay could occur
> > when more than one copy of a request message gets sent to the TSA because
> of
> > problems in the intervening network elements.  In this case the TSA
> because
> > of its "no look" policy would just blindly generate time stamps for each
> of
> > the copies it receives.  Deliberate replay, on the other hand, assumes
> that
> > the TSA has been subverted or its signing key has been compromised, or
> that
> > a middleman is replaying legitimate TS responses.  Each of the various
> > potential replays needs to be considered to ensure that the protocol
> > protects against it.
> >
> > 1. Deliberate middleman replay.  Since each response contains a signed TS
> > Token which includes the message imprint, serial number and time, this
> type
> > of attack is easily detected within the currently proposed protocol.
> >
> > 2. Replay by subverted TSA.  A subverted TSA could generate any number of
> TS
> > Tokens containing the same message imprint at any time.  Because each
> could
> > have different serial number and/or time, each would be unique and there
> is
> > no way the client could detect a replay on the basis of the response.  The
> > only way this could be detected would be for every request to include a
> > nonce and for the client to maintain a record of all nonces generated to
> > verify against the responses.
> >
> > 3. Inadvertent replay.  Again, the only way for the client to distinguish
> > this type of replay would be through the use of a nonce. In this case,
> > however, it should not be necessary to maintain a record of all nonces
> > generated but only those generated within a time window as you suggest. If
> > the window length is set to, for example, twice the expected delay between
> > request and response, the client could be quite confident that there have
> > been no inadvertent replays if no duplicate nonce values are detected.
> >
> > To summarize, the nonce should not be an optional component of replay
> > detection (as suggested by the current wording) - it is necessary if the
> > client is trying to protect against anything other than deliberate
> middleman
> > replays.
> >
> > It is suggested that the wording in the fourth sentence of the second
> > paragraph of Section 2.2 (page 3) be changed to:
> >
> > "It SHALL then verify the value of the nonce (large random number with
> high
> > probability that is generated by the client only once) included in the
> > response against the nonce value included in the corresponding request to
> > ensure that no replay has occurred."
> >
> > In Section 2.4.1 remove the OPTIONAL qualifier from nonce in the
> definition
> > of TimeStampReq (page 4).
> >
> > Change the wording of first sentence of the nonce description in Section
> > 2.4.1 (page 5)to read:
> >
> > "The nonce allows the client to verify the response against replay."
> >
> > In Section 2.4.2 remove the OPTIONAL qualifier from nonce in the
> definition
> > of TSTInfo (page 7).
> >
> > Change the wording of the nonce description in Section 2.4.2 (page 5)to
> > read:
> >
> > "The nonce field MUST be equal to the value provided in the TimeStampReq
> > structure."
> >
> > If you agree with this approach, then I would suggest we prepare a short
> > annex to describe the two different cases - subverted TSA vice inadvertent
> > replay.
> >
> > Have a good weekend!
> >
> > Francois
> > ___________________________________
> > Francois Rousseau
> > Director of Standards and Conformance
> > Chrysalis-ITS
> > 1688 Woodward Drive
> > Ottawa, Ontario, CANADA, K2C 3R7
> > [e-mail]      Tel. [phone] ext. 419
> > http://www.chrysalis-its.com     Fax. [phone]
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, May 24, 2000 5:36 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: Rationale for Nonce in Time Stamp Protocol
> >
> > Francois,
> >
> > I realized that I ommited to reply to your E-mail.
> >
> > > Salut Denis,
> > >
> > > I do not remember if this issue was raised before, but in Section 2.2
> the
> > > following statement is made:
> > >
> > > "the requesting entity .... SHALL then verify the timeliness of the
> > response
> > > by verifying either the time included in the response against a local
> > > trusted time reference, if one is available, and/or the value of the
> nonce
> > > (large random number with a high probability that it is generated by the
> > > client only once) included in the response against the value included in
> > the
> > > request."
> > >
> > > A nonce is normally used to detect attempts at replays, which is not
> > > necessarily related to the timeliness of the response to a particular
> > > request as mentioned here.
> > >
> > > The first part of the statement talks about verifying the time included
> in
> > > the response against a locally trusted time source.  This could used to
> > > measure round trip path delay for calibration purposes,
> >
> > No. This is not the goal. The goal is to make sure that you have no
> > replay, in particular on the same hash value.
> >
> > > but unless one could
> > > be certain that the locally trusted source is as accurate as the TSA
> time
> > > source (or, at least, that the difference between them is fixed and
> > > well-known), I don't see how it would detect/prevent replays.
> >
> > Using a moving time window the caller remembers all the hashes he
> > sent during that time window.
> > If there is not the same hash value within that time window, then he
> > makes sure that the time of the response is within the time window.
> > If there is the same hash (a very rare situation), it is a little
> > bit more complicated, and there are several options. Among them:
> > using the nonce, or waiting until the time window has moved to come
> > back to the previous case: only one hash value during that time
> > window. But we are talking implementations details, which is not the
> > topic of an RFC.
> >
> > >  If one has
> > > such a trusted time source locally, what is the point in using a TTP for
> > > time stamping?
> >
> > The time is locally trusted, ... which does not mean that other
> > people will trust that time.
> >
> > >
> > > Could you please clarify the intent of this statement and if the intent
> is
> > > to prevent replays or check the timeliness of responses or both?
> >
> > Now, that you have the explanations, if you still believe that the
> > text is not clear enough, I suggest that you submit a proposal to
> > clarify the text.
> >
> > Regards,
> >
> > Denis
> >
> > >
> > > Francois
> > > ___________________________________
> > > Francois Rousseau
> > > Director of Standards and Conformance
> > > Chrysalis-ITS
> > > 1688 Woodward Drive
> > > Ottawa, Ontario, CANADA, K2C 3R7
> > > [e-mail]      Tel. [phone] ext. 419
> > > http://www.chrysalis-its.com     Fax. [phone]


Received: from thunder.dstc.qut.edu.au (thunder.dstc.qut.edu.au [131.181.71.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22074 for <[e-mail]>; Wed, 31 May 2000 01:05:57 -0700 (PDT)
Received: from dstc.edu.au (cheung.dialup.dstc.edu.au [130.102.182.233]) by thunder.dstc.qut.edu.au (8.10.1/8.10.1) with ESMTP id e4V8CsT29663; Wed, 31 May 2000 18:12:54 +1000 (EST)
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 18:12:01 +1000
From: Eddy <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Gabriel =?iso-8859-1?Q?L=F3pez=20Mill=E1n?= <[e-mail]>
CC: [e-mail]
Subject: Re: PKIX library
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi Gabi,

I assumed that you are talking about implementation of Cert. Management
Protocol (CMP)?

Since the last release of JCSI, we have implemented and changed a fair
bit.  I guess more importantly for you, we have also add CMP support in
JCSI.  At the moment, I am working on getting CMC support.

That said, however, we are still doing some QC before we will release
the next version of JCSI (v1.0).  I am not sure even if CMP will make it
into next release.

If you really keen on getting your hand on CMP library in Java, please
email me separately (ie. not through email list) We can talk about how
and if you can get your hand on those library.

Cheers...
Eddy

Gabriel López Millán wrote:
> 
> Gabriel López Millán wrote:
> 
> >     Hello all.
> >
> >     There is any free pkix library for Java?
> >
> >     Thanks, Gabi.
> 
>         OK, I am testing JCSI library. It is good, but I want a library
> which I can construct PKIMessages, with PKIBody, PKIHeader, etc.
> 
>     There is anything?
> 
>     Thanks a lot, Gabi.


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18164 for <[e-mail]>; Wed, 31 May 2000 00:22:27 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA32780; Wed, 31 May 2000 09:29:53 +0200
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 09:29:55 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamp: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James,

I will pick your message to answer.

> Denis,
> 
> > Correct, this can ALWAYS been achieved  ... if we have the following
> property:
> > | genTime 1 - GenTime 2 | > Accuracy of GenTime 1 + Accuracy of GenTime 2
> 
> You don't need this property.  Each genTime value is a measurement of UTC
> with a given uncertainty, but successive measurements are not independent.
> The measuring instrument is a clock and I assume it only increments.  

No. Your are making an assumption which is not true. You are
assuming that the TSA is using a single clock. This is not
necessarilly the case with the huge server scenario. Paul gave the
right answer:

The interpretation of a timestamp with accuracy is simple: the TSA
is
making an assertion that the time when it generated the stamp is in
the range [ts - accuracy .. ts + accuracy].  (In other words, it
promises that UTC will be contained in that interval.)

Denis

> So a
> later measurement is never less than an earlier measurement regardless of
> the uncertainty.
>     genTime1 = 6:45 +/- 8
>     genTime2 = 6:47 +/- 8
> genTime1 was issued before genTime2 because genTime1 < genTime2.
> The uncertainty, +/- 8, is important only when comparing the time to another
> clock (e.g. a timestamp from another TSA or some external event such as a
> deadline of 7:00).
> 
> 
> Your "huge server" scenario is interesting, but I don't think it changes the
> arguments.  The genTime values from a TSA can be the *definition* of order.
> With a huge server, the order requests hit the front switch may differ from
> the order they are finally processed (after being in different queues in
> different crypto engines), but which order is correct?  I am not even sure
> that "hit the front switch" is a simple concept given that a request is many
> octets, perhaps split over many IP packets with any number of TCP/IP
> interactions.
> 
> We could have two uncertainties: (1) the uncertainty between genTime and
> UTC; and (2) the uncertainty between "simultaneous" measurements by the TSA.
> If a TSA has many clocks (e.g. one for each crypto engine) the second value
> is the uncertainty in synchronisation between its own clocks.  However, I
> don't think this (or your BOOLEAN) is necessary.
> 
> 
> 
> Peter Sylvester,
> 
> > What kind of decision can you make based on that? [23h59'59'' +/- 2'']
> 
> Probability that timestamp was issued before 12h00'00''
>     = Pr(x < 12h00'00'' | x sample of X =
> Normal-Distribution(mean=23h59'59'', sd=2''))
>     = Pr(x < 0.5 | x sample of X = Standard-Normal-Distribution)
>     = 0.69
> => There is about a 70% chance that the timestamp was issued before the
> deadline.  If this is not good enough the user should have got an timestamp
> earlier or used a TSA with a lower uncertainty.
> If you want a black-and-white decision you could
> (A) pick a confidence level, say 60%, and accept any timestamp that has at
> least this probability of being before the deadline; or
> (B) get your own timestamp from the same TSA at the deadline and accept
> timestamps issued before yours (regardless of the actual time and
> uncertainty listed in your timestamp).
> 
> UTC is a continuous quantity.  Any measurement will have an uncertainty.
> Any comparison involves a confidence interval.  This is unavoidable.
>


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16884 for <[e-mail]>; Wed, 31 May 2000 00:05:11 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA18116; Wed, 31 May 2000 09:12:20 +0200
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 09:12:21 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Zolotarev <[e-mail]>
CC: Joerg Seidel <[e-mail]>, "Manger, James H" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Timestamp: id for token
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael,

Thanks for your examples that illustrate that a unique reference for
the Time Stamps issued by a given CA name MAY be useful. 

Denis

 
> Case1:
> Italian legislation mandates that a CA obtains a time stamp for each
> published cert and CRLs. It also mandates that the TSA maintains the archive
> of all issued timestamps for the life span of the TSA key. So that the CA
> can be relieved from keeping the actual tokens.
> 
> Case2:
> A document management system. Each document (e.g a purchase order) can be
> timestamped any number of times at different stages of its life cycle. It
> may be appropriate to have an archive containing just the progressing
> versions of the document, and some associated references. It is not
> necessarily possible/required to keep the document and its associated
> timestamps together. Instead, a separate archive of timestamps can be
> arranged, with the tokens referenced from other archives.
> 
> I know it all can be done in different ways -i.e. maintaining external
> referencing, so that there is nothing in the token itself. Just saying that
> there are some cases when a timestamp can be stored separately from the
> document/message it was created for.
> 
> M
> 
> > -----Original Message-----
> > From: Joerg Seidel [mailto:[e-mail]]
> > Sent: Monday, May 29, 2000 8:21 PM
> > To: Manger, James H
> > Cc: '[e-mail]'
> > Subject: Re: Timestamp: id for token
> >
> >
> > I agree on what James wrote. A unique identifier or serial
> > number is not
> > necessary.
> >
> > "Manger, James H" schrieb:
> > >
> > > Is a standardised unambiguous identifier for a timestamp
> > token really needed
> > > or wanted?
> > >
> > > Such an identifier is useful for a certificate as a
> > certificate is used in
> > > many messages (many SSL sessions, many S/MIME emails, many
> > transactions,
> > > ...).  The certificate is independent of any particular
> > use.  A timestamp,
> > > however, is only relevant to a single message - corresponding to its
> > > messageImprint field.
> > >
> > > The are no timestamp revocation lists.  There are no other
> > messages from a
> > > TSA that need to refer to a specific timestamp.
> > >
> > > It seems sensible to store a timestamp with its
> > corresponding message - so
> > > now identifier is needed.  Even if they were stored separately the
> > > implementation could its own labels to maintain the link,
> > i.e. it does not
> > > need an explicit field within the timestamp.
> >


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA16289 for <[e-mail]>; Tue, 30 May 2000 23:57:20 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA18904; Wed, 31 May 2000 09:04:51 +0200
Message-ID: <[e-mail]>
Date: Wed, 31 May 2000 09:04:52 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

> Denis:
> 
> I believe that a CA can operate in accordance with one or more
> certification policies at the same time.  The way that the CA is able to
> fulfill the requirements of more than one certification policy is
> documented in a single CPS.

OK. Let us remove the "s" from "CPS". :-)

Denis

> Russ
> 
> At 05:15 PM 05/25/2000 +0200, Denis Pinkas wrote:
> >Paul and others,
> >
> >Some major details:
> >
> >1) I would propose to add an "s" to "certificate policy" making it
> >"certificate policies".
> >
> >In RFC 2459 we have:
> >
> >4.2.1.5  Certificate Policies
> >
> >    The certificate policies extension contains a sequence of one or
> >more
> >    policy information terms, each of which consists of an object
> >    identifier (OID) and optional qualifiers.
> >
> >2) In the same way, I would add an "s" to "CPS" making it "CPSs".
> >
> >3) Finally, since the verification is not uniform, I would also add
> >an "s" to "verification".
> >
> >The final sentence would thus look like:
> >
> >"The precise nature of the verifications is detailed in the
> >certificate policies and/or the CPSs."
> >
> >4) ... and a comment on the use of "definitively":
> >
> >We were looking for text replacement related only to the subject
> >alternative name section 4.2.1.7. Now the sentence has been extended
> >to cover parameters like "all other fields in a certificate" and
> >"all certificate extensions". So "definitively" also applies to them
> >now, and this is wrong.
> >
> >I would thus propose to delete the sentence "like all other fields
> >in a certificate and all certificate extensions," and thus keep the
> >idea  from RFC 2459, where only the subject alternative name is
> >considered to be definitiviely bound to the public key, which was:
> >
> >    Because the subject alternative name is considered to be
> >    definitiviely bound to the public key, all parts of the subject
> >    alternative name MUST be verified by the CA.
> >
> >The new text would thus look like:
> >
> >   Denis> "The subject alternative name is considered to
> >   Denis> be definitively bound to the public key. Thus the CA MUST
> >   Denis> verify (directly or indirectly) all subject alternative
> >   Denis> names. The precise nature of the verifications is detailed
> >in
> >   Denis> the certificate policies and/or the CPSs."
> >
> >Denis
> >
> > > Echoing Paul Hoffman's comment...  I find Steve's text to be
> > > preferable.  For one thing, retaining "definitively" seems a good
> > > thing to do.
> >
> > >       paul
> >
> >
> >   Warwick> "The subject alternative name, like all other fields in a
> >   Warwick> certificate and all certificate extensions, is considered
> >to
> >   Warwick> be bound to the public key.  Thus the CA MUST verify (in
> >   Warwick> accordance with the applicable certificate policy and/or
> >the
> >   Warwick> CPS) all subject alternative names."
> >
> >
> >   Steve> "The subject alternative name, like all other fields in a
> >   Steve> certificate and all certificate extensions, is considered
> >to
> >   Steve> be definitively bound to the public key. Thus the CA MUST
> >   Steve> verify (directly or indirectly) all subject alternative
> >   Steve> names. The precise nature of the verification is detailed
> >in
> >   Steve> the certificate policy and/or the CPS."


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA14364 for <[e-mail]>; Tue, 30 May 2000 23:21:38 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA06615 for <[e-mail]>; Wed, 31 May 2000 16:28:48 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0Z160d; Wed May 31 16:28:13 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA17729 for <[e-mail]>; Wed, 31 May 2000 16:28:12 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd24_We_; Wed May 31 16:27:01 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA27861 for <[e-mail]>; Wed, 31 May 2000 16:27:01 +1000 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <L4KYMD3S>; Wed, 31 May 2000 16:26:30 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Wed, 31 May 2000 16:26:21 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Michael,

> How do you know when the "Time stops" and the "Order begins"?
You never need to know - that is the beauty.

 

> Stamp from TSA_1: 20000529053138.345Z. Accuracy = 1 sec.
> Stamp from TSA_2: 20000529053138.876Z. Accuracy = 1 sec
> How do I do it [compare the stamps]?
Consider T2 - T1.  The best estimate (mean) is .876 - .345 = .531.  When
subtracting measurements the uncertainty is the square root of the sum of
the squares of the individual uncertainties: sd = sqrt(1^2 + 1^2) = 1.414.

=> T2 - T1 = 0.531 +/- 1.414

=> Probability that T2 is after T1
    = Pr(0 < x | x sample of X = Normal-Distribution(mean=0.531, sd=1.414))
    = Pr(-0.375 < x | x sample of X = Standard-Normal-Distribution)
    = 0.65

So there is a 65% chance that the stamp from TSA_1 was issued before the
stamp from TSA_2.  Comparison done.

 

> 1. Do I assume that .345 and .876 is just ordering?
No.
> 2. Do I assume that both TSA_1 mad TSA_2 have a high resolution clock
No
> 3. Do I assume that 20000529053138.34 was the actual time, and the order
is 5?
No

> What we had: Time, Accuracy, [Unique referencing+Ordering].
> What we are getting to: [Time+order], Accuracy, ConditionVariable, and
derived referencing.
Not really.  We are getting to: (1) Time and (2) Uncertainty with respect to
UTC.  We are adding an assumption that a TSA's clock never gives a reading
less than a previous reading.  We are recognizing that adding extra digits
beyond the clock reading does not make the quoted time wrong.

If a TSA clock returns digits down to the tenth of a second, e.g.
"5:31:38.8", it will return the same string when the fraction of seconds is
.800, .807, .876 and 0.887 (could use rounding instead of truncation but it
makes no difference).  On reading "5:31:38.8" the TSA knows the time
(according to its clock) is in the range [5:31:38.80000..,
5:31:38.899999...].  Any value in this range is as good a guess as any
other.  The TSA can arbitrarily choose any value in this range.  Hence, the
TSA can ensure its arbitrary choices always increase while its clock returns
the same value.



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA06112 for <[e-mail]>; Tue, 30 May 2000 21:58:11 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id PAA00466; Wed, 31 May 2000 15:10:32 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <L0RK6LJ1>; Wed, 31 May 2000 15:04:21 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Andy Dowling <[e-mail]>, Paul Hoffman <[e-mail]>
Cc: [e-mail]
Subject: RE: Requirements for remote path processing services
Date: Wed, 31 May 2000 15:04:20 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Andy,

to me, the obvious way of using the RPPS to validate ACs is to validate the
signer's ACA's certificate. The rest - policy, roles, etc - really belongs
to the AC's RP (which is an access control server itself, as you have
correctly mentioned). 
Therefore, the request from the RPPS client would be "Is that *ACA* cert
valid for me?".

I'd say that this is the only way one can use a general purpose RPPS box for
ACs.

Michael

> -----Original Message-----
> From: Andy Dowling [mailto:[e-mail]]
> Sent: Monday, May 29, 2000 9:02 PM
> To: Paul Hoffman
> Cc: [e-mail]
> Subject: Re: Requirements for remote path processing services
> 
> 
> Paul + co.,
> 
> Having read your post, I was just wondering if these remote 
> path processing
> services could be applied to ACs for authorisation purposes? I've put
> together a few points on the subject (see below).
> 
> Comments would be appreciated.
> 
> Regards,
> 
> Andy
> 
> 
> 
> 1) OVERVIEW
> 
> In addition to remote path processing services:
> 
> a) delegated path construction
> b) delegated path verification
> c) trust and policy centralisation
> 
> that apply to public key certificates, there may be scope for
> the application of these services to authorisation-related 
> certificates
> i.e. Attribute Certificates could be verified remotely by a single
> trusted entity, and this would bring the benefits of centralised
> trust/policy management and simpler clients.
> 
> 
> 2) MOTIVATION
> 
> Firstly, let's present some arguments *against* introducing remote AC
> validation:
> 
> a) The current profile for AC validation is relatively simpler than
>    that of PKC validation:
> 
>         a) AC chains are not used
>         b) AAControls is optional
>         c) AC revocation checking is optional
> 
>    Consequently, a very minimal (and conformant) AC validator can be
>    implemented and would be "lightweight" enough to provide 
> on clients.
> 
> b) AC validation for authorisation purposes is typically a server-side
>    operation anyway, and clients would hardly need to validate an AC.
> 
> 
> In response to argument (a):
> 
>      Whilst a client may indeed conform to the simplest 
> version of the AC
>      profile with a lightweight implementation, such an implementation
>      would have no control over which attributes can be 
> issued by which
>      authorities (AAControls), due to the lack of chain processing.
>      In addition, the client cannot safely validate long-lived ACs.
>      This is due to the lack of revocation processing.
> 
> In response to argument (b):
> 
>      Clients *may* need to validate ACs in the push model to
>      ensure the integrity of the AC before passing it on to other
>      servers. (Complications arise here when the AC is pushed to a
>      different "trust domain" where the AC validation policy differs
>      to that of the clients policy, so there's scope for 
> further study here)
> 
>      A client will need to validate an AC if it is used in 
> the making of
>      a client-side access decision. Scenarios in which a client-side
>      access decision would need to be made are:
> 
>             --> Checking the permissions of downloaded content:
>                 --> Has a piece of downloaded code have 
> execute permission
>                     from the system admin?
> 
>             --> Client-side content filtering:
>                  -> Checking if downloaded content has a 
> "rating" attribute
>                     (12, 15, 18, PG-13, NC-17, R, etc.)
> 
> 
> It is apparent that there is indeed a requirement for:
>        (a) clients to validate ACs
>        (b) AC validation to be performed "fully". That is, AAControls
>            and revocation checking should be done for 
> security reasons.
> 
> Given these requirements, it seems logical to migrate these 
> verification
> tasks to a dedicated AC validation server.
> 
> 
> 2) BENEFITS:
> 
> The benefits are the same as for remote PKC processing:
> 
> a) Centralised trust and policy for authorisation purposes
> 
>     (i)   Administrator(s) can say what AAs are trusted by 
> the enterprise
>     (ii)  Administrator(s) can implement complicated trust 
> management via
>                            AAControls and/or AC Chain validation
>     (iii) Administrator(s) can implement AC revocation checking
> 
> b) Simplified clients
>     (i)  No need for the client to implement any form of AC 
> verification,
>          path processing (for AAControls), LDAP/OCSP clients, etc.
> 
> c) Server-side caching to improve turnaround time on a 
> validation request
> 
> 
> 
> 
> 


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA03749 for <[e-mail]>; Tue, 30 May 2000 21:37:01 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA00272; Wed, 31 May 2000 14:49:18 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <L0RK6L2H>; Wed, 31 May 2000 14:43:03 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Joerg Seidel <[e-mail]>, "Manger, James H" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Timestamp: id for token
Date: Wed, 31 May 2000 14:43:03 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Case1:
Italian legislation mandates that a CA obtains a time stamp for each
published cert and CRLs. It also mandates that the TSA maintains the archive
of all issued timestamps for the life span of the TSA key. So that the CA
can be relieved from keeping the actual tokens.

Case2:
A document management system. Each document (e.g a purchase order) can be
timestamped any number of times at different stages of its life cycle. It
may be appropriate to have an archive containing just the progressing
versions of the document, and some associated references. It is not
necessarily possible/required to keep the document and its associated
timestamps together. Instead, a separate archive of timestamps can be
arranged, with the tokens referenced from other archives.

I know it all can be done in different ways -i.e. maintaining external
referencing, so that there is nothing in the token itself. Just saying that
there are some cases when a timestamp can be stored separately from the
document/message it was created for.

M




> -----Original Message-----
> From: Joerg Seidel [mailto:[e-mail]]
> Sent: Monday, May 29, 2000 8:21 PM
> To: Manger, James H
> Cc: '[e-mail]'
> Subject: Re: Timestamp: id for token
> 
> 
> I agree on what James wrote. A unique identifier or serial 
> number is not
> necessary.
> 
> "Manger, James H" schrieb:
> > 
> > Is a standardised unambiguous identifier for a timestamp 
> token really needed
> > or wanted?
> > 
> > Such an identifier is useful for a certificate as a 
> certificate is used in
> > many messages (many SSL sessions, many S/MIME emails, many 
> transactions,
> > ...).  The certificate is independent of any particular 
> use.  A timestamp,
> > however, is only relevant to a single message - corresponding to its
> > messageImprint field.
> > 
> > The are no timestamp revocation lists.  There are no other 
> messages from a
> > TSA that need to refer to a specific timestamp.
> > 
> > It seems sensible to store a timestamp with its 
> corresponding message - so
> > now identifier is needed.  Even if they were stored separately the
> > implementation could its own labels to maintain the link, 
> i.e. it does not
> > need an explicit field within the timestamp.
> 


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29011 for <[e-mail]>; Tue, 30 May 2000 21:13:29 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA20867; Wed, 31 May 2000 14:26:13 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <L01ZXJR8>; Wed, 31 May 2000 14:20:14 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>, "Manger, James H" <[e-mail]>
Cc: [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Wed, 31 May 2000 14:20:13 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Guys,

How do you know when the "Time stops" and the "Order begins"?

If we allow two different interpretations of the fractions component - i.e.
'ordering' or 'real time' - we have to say explicitly what it is. And a lot
more, to make it unambiguous.

How do I know whether I should take the fractions as order index, or as a
real value from high resolution clock?

Imagine:

Stamp from TSA_1: 20000529053138.345Z. Accuracy = 1 sec.
Stamp from TSA_2: 20000529053138.876Z. Accuracy = 1 sec

The difference is in fractions, as you can see. I trust that the TSAs are in
synch with 'absolute time', enough for me to be able to compare the stamps.

How do I do it?

1. Do I assume that .345 and .876 is just ordering? And consequently I trim
the time down to the order of accuracy (i.e. seconds), and the time is
identical?

or

2. Do I assume that both TSA_1 mad TSA_2 have a high resolution clock,
allowing to assign finer times? And consequently there is a high probability
that Stamp1 is older than Stamp2?

or

3. Do I assume that 20000529053138.34 was the actual time, and the order is
5? And the order was 6 for the other stamp?

What I am trying to say is that imposing two different meaning for one
variable inevitable creates a mess. Then you are trying to add a separate
variable to clear up the mess. Then you end up with a bloated document
explaining how those two variables interact, trying to eliminate any
ambiguity :)

What we had: Time, Accuracy, [Unique referencing+Ordering].

What we are getting to: [Time+order], Accuracy, ConditionVariable, and
derived referencing.

This is really a matter of style, though.






> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Tuesday, May 30, 2000 7:25 PM
> To: Manger, James H
> Cc: [e-mail]
> Subject: Re: TSA Response serialNumber Field
> 
> 
> James,
> 
> Thanks for the shortest "simple and complete" message. I picked it
> to answer to all the recent messages posted on that topic. 
>  
> > TSA clients must support genTime values with 
> fraction-of-second components,
> > e.g "20000529053138.345Z".  Consequently, by using sufficient
> > fraction-of-seconds digits, it is easy for a TSA to issue 
> genTime values
> > that always increase and never repeat.
> > 
> > * The TSA does not need to maintain another never-repeating value
> > (serialNumber) and does not have to worry about maintaining 
> it when the TSA
> > server crashes.
> 
> Correct. This a very important argument. So if we maintain that
> field it is *only* to uniquely identify the TST. Now, let us answer
> to the question raised: whether that field is NECESSARY. This field
> is not *necessary*. It MAY be *useful*. Yes, it usually makes sense
> to associate the Time Stamp with the data it applies to. However, it
> MAY or MIGHT be useful to be able to reference a Time Stamp that is
> stored somewhere else.
> 
> > * The TSA does not need to issue (nor the client expect) 
> huge integer
> > values.
> 
> > * Ordering two timestamps from one TSA is simply achieved 
> by comparing their
> > genTime fields.
> 
> Correct, this can ALWAYS been achieved  ... if we have the following
> property:
> | genTime 1 - GenTime 2 | > Accuracy of GenTime 1 + Accuracy of
> GenTime 2
> 
> In the above equation > means stricly superior.
> 
> Now, when this condition does NOT apply, the BOOLEAN indicator
> "ordering" allows to say whether ordering two timestamps from one
> TSA can or cannot be achieved by comparing their genTime fields.
> 
> In the case a huge server doing parallel queuing and using parallel
> crypto engines that this property is not that easy to maintain.
> Allowing to perform an ordering in *any* case (i.e. in time frames
> less than the second) is not needed by many applications, hence the
> reason to place low contraints on the design, unless this property
> is really needed.
> 
> Now, about the last received comment from Ed Gerck, the above
> distinction gives a reliability of 100% if we have: | genTime 1 -
> GenTime 2 | > Accuracy of GenTime 1 + Accuracy of GenTime 2 and when
> that condition does not apply, either a reliability of 100% if the
> the BOOLEAN indicator "ordering" is set to TRUE and a reliability of
> 0% if the the BOOLEAN indicator "ordering" is set to FALSE.
> 
> > * Accuracy (uncertainty with respect to UTC) is not 
> affected as it is
> > conveyed in a separate field.
> > 
> > Simple.  Complete.
> > 
> > The only issue is whether the ordering works from 
> timestamps with the same
> > TSA name or same TSA signing key.
> 
> It works, as indicated above, with the same TSA name.
> 
> As a conclusion:
> 
> 1) Time Stamp Token ordering can be done in most cases (see above)
> by only using GenTime and accuracy.
> 2) serialNumber is not *necessary*, but may be *useful*. So let us
> keep it.
> 3) the BOOLEAN indicator "ordering" is useful to allow to address
> two segment needs, and does not place design constraints when no
> ordering within the second range is needed.
> 
> 
> Denis
> 


Received: from c004.sfo.cp.net (c004-h007.c004.sfo.cp.net [209.228.14.63]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA22989 for <[e-mail]>; Tue, 30 May 2000 20:27:37 -0700 (PDT)
Received: (cpmta 22953 invoked from network); 30 May 2000 20:34:47 -0700
Received: from 2Cust6.tnt4.austin2.tx.da.uu.net (HELO tuvit.net) (63.11.192.6) by smtp.tuvit.net with SMTP; 30 May 2000 20:34:47 -0700
X-Sent: 31 May 2000 03:34:47 GMT
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 22:34:43 -0500
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IETF-PKIX <[e-mail]>
CC: Wes Doonan <[e-mail]>, "Jose A. Ma~n" <[e-mail]>, Mike Matyas <[e-mail]>
Subject: Time Stamp V7 Data structure
Content-Type: multipart/mixed; boundary="------------E8FA5F4851A3EC3DB5F4346F"

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

This is a kind of re-opening the issue of aligning the actual ISO draft
on time stamping with version 07 of the PKIX time stamping draft.

I am re-opening it for two reasons: Since the first time (version 5
discussion) I was expecting a change in the IETF document stating that
it is optional to have a mechanism identifier (object identifier) in the
time stamp request and I also expected a modified data structure
allowing to use the option. None of this happened. This information is a
prerequisite for developers willing to implement an IETF and ISO
compatible TSA.

The answer I received from the eeditor on the change of the data
structure was  from my point of view sufficient for it only meant an
endorsement to use additional elements in  the ISO data structure: "For
the request the additional element will be in the ISO request, NOT in
the IETF request."

That means, ISO gets endorsement for its data structure. I was asking
for a change in the IETF data structure, the mechanism Identifier
element ALREADY exists in the ISO Time stamp request data structure.

On the other hand I have to express that the adoption of a mechanism
identifier into the time stamp token is required to allow proper
interpretation by the recipient of such a token. If the mechanism used
for generating the token cannot be identified then the validity of a
time stamp cannot be checked if it is not the IETF mechanism. If time
stamps are generated using a mechanism different from the IETF draft and
there is no information provided within the token what mechanism was
used to generate the time stamp then a verifier does not know how to
proceed. If the time stamp was generated with one of the mechanisms
proposed in the ISO draft then information is needed to successfully
verify the validity of the time stamp. Otherwise an ISO time stamp is
not usable by  recipients of the time stamp for they cannot verify its
validity.

Let me explain the need for the mechanism identifier in the request also
in an example: A client using the IETF protocol may communicate with
either an ISO or an IETF TSA when requesting a time stamp; this will
cause no problem for the ISO TSA will understand the request of the
client.

The situation gets more difficult if the client uses the ISO protocol. A
TSA only understanding IETF requests will detect general incompatibility
and answer with an error; this leaves the client without a time stamp if
he cannot switch to the other protocol. And this is not called
alignement but downward compatibility. And we should try to achieve
interoperability which means an agreed minimum level of communications.
The accepted changes do not allow communications in both directions.

And that does not help any of the standardisation bodies, neither the
IETF nor ISO.

That's in short why I am convinced that the discussion on the acceptance
of these topics has to be reopened. 

What is needed most urgently is a mechanism identifier in the time stamp
request and in the time stamp response (i.e. within the time stamp
token). And that is the only way I can imagine that allows
interoperability between the two approaches.  Thanks again for your
patience and support.

Roland
--------------E8FA5F4851A3EC3DB5F4346F
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------E8FA5F4851A3EC3DB5F4346F--



Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03678 for <[e-mail]>; Tue, 30 May 2000 18:25:21 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA26477 for <[e-mail]>; Wed, 31 May 2000 11:32:31 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0ZNymS; Wed May 31 11:32:03 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA04896 for <[e-mail]>; Wed, 31 May 2000 11:32:02 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd6rZtF_; Wed May 31 11:30:57 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA26088 for <[e-mail]>; Wed, 31 May 2000 11:30:57 +1000 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <L4KYKDWL>; Wed, 31 May 2000 11:30:26 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: Timestamp: TSA Response serialNumber Field
Date: Wed, 31 May 2000 11:30:15 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis,
 
> Correct, this can ALWAYS been achieved  ... if we have the following
property:
> | genTime 1 - GenTime 2 | > Accuracy of GenTime 1 + Accuracy of GenTime 2

You don't need this property.  Each genTime value is a measurement of UTC
with a given uncertainty, but successive measurements are not independent.
The measuring instrument is a clock and I assume it only increments.  So a
later measurement is never less than an earlier measurement regardless of
the uncertainty.
    genTime1 = 6:45 +/- 8
    genTime2 = 6:47 +/- 8
genTime1 was issued before genTime2 because genTime1 < genTime2.
The uncertainty, +/- 8, is important only when comparing the time to another
clock (e.g. a timestamp from another TSA or some external event such as a
deadline of 7:00).
 
 
Your "huge server" scenario is interesting, but I don't think it changes the
arguments.  The genTime values from a TSA can be the *definition* of order.
With a huge server, the order requests hit the front switch may differ from
the order they are finally processed (after being in different queues in
different crypto engines), but which order is correct?  I am not even sure
that "hit the front switch" is a simple concept given that a request is many
octets, perhaps split over many IP packets with any number of TCP/IP
interactions.
 
We could have two uncertainties: (1) the uncertainty between genTime and
UTC; and (2) the uncertainty between "simultaneous" measurements by the TSA.
If a TSA has many clocks (e.g. one for each crypto engine) the second value
is the uncertainty in synchronisation between its own clocks.  However, I
don't think this (or your BOOLEAN) is necessary.
 
 
 
Peter Sylvester,
 
> What kind of decision can you make based on that? [23h59'59'' +/- 2'']
 
Probability that timestamp was issued before 12h00'00''
    = Pr(x < 12h00'00'' | x sample of X =
Normal-Distribution(mean=23h59'59'', sd=2''))
    = Pr(x < 0.5 | x sample of X = Standard-Normal-Distribution)
    = 0.69
=> There is about a 70% chance that the timestamp was issued before the
deadline.  If this is not good enough the user should have got an timestamp
earlier or used a TSA with a lower uncertainty.
If you want a black-and-white decision you could
(A) pick a confidence level, say 60%, and accept any timestamp that has at
least this probability of being before the deadline; or
(B) get your own timestamp from the same TSA at the deadline and accept
timestamps issued before yours (regardless of the actual time and
uncertainty listed in your timestamp).
 
UTC is a continuous quantity.  Any measurement will have an uncertainty.
Any comparison involves a confidence interval.  This is unavoidable.
 


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21340 for <[e-mail]>; Tue, 30 May 2000 16:11:55 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA266256; Tue, 30 May 2000 19:17:51 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id TAA270770; Tue, 30 May 2000 19:19:34 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568EF.00802073 ; Tue, 30 May 2000 19:19:29 -0400
X-Lotus-FromDomain: IBMUS
To: "Bob Jueneman" <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 19:19:27 -0400
Subject: RE: SubjectAltName verification
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

"Bob Jueneman" <[e-mail]> on 05/30/2000 05:29:44 PM

To:   Tom Gindin/Watson/IBM@IBMUS, <[e-mail]>
cc:   <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject:  RE: SubjectAltName verification



Tom,

>>> <[e-mail]> 05/30/00 12:51PM >>>
>     I am not sure that VeriSign class 1's E-mail address usage is
unverified, as opposed to rather weakly verified, because the
challenge/response serves as a form of POP.  Whether this is an adequate
POP is more questionable.

E-mail distribution of the certificate tied to a PIN presumably provides a
weak proof that at least someone who has access to that mailbox also has
access to the key pair. Unfortunately neither the mailbox nor the key can
be
shown to be under the exclusive control of the putative user, whoever that
may be.

[Tom Gindin] Are we in disagreement here?  I said "rather weakly verified"
and questionably adequate.

 >    Furthermore, a number of fields which are placed in certificates are
restrictions on usage and cannot be verified by the CA.  The most obvious
such fields are the KeyUsage and ExtendedKeyUsage extensions.

Well, that isn't quite so clear.  At least some cryptographic
implementations, e.g.,
NICI and CDSA, together with most smart cards, implement strong typing
of such attributes, and hence could reasonable be relied upon to enforce
such
restrictions.

The fact that most CAs fail to check on what kind of end-user software is
in
use, or place any constraints or even education requirements on their
end-users is another problem, and one that is symptomatic of the
over-reliance
on CA policies, and a conspicuous lack of attention to the requirements for
end-user implementations.

[Tom Gindin] Actually, I'm asking whether a CA is supposed to refuse to
place such attributes in a certificate if it has no reason to believe that
the user's software package enforces them.  I know that some software does
enforce them.  In any case, if keys can be exported from their original
software packages and reimported elsewhere, the CA has no way of being sure
that they won't be differently used.

>     This does not, however, necessarily mean that the CA can avoid
responsibility for verifying identity fields and other fields that are
verifiable, such as Subject, SubjectPublicKey, SubjectAltName, and
SubjectDirectoryAttributes.

It's beginning to sound as though the CA doesn't really have to verify
anything except
those things for which it is naturally authoritative, e.g., the uniqueness
of the DN within
the CA's own domain, etc.

[Tom Gindin] Well, that definition would include not doing a POP on the
user's private key, so it's pretty extreme.  RP's certainly want more from
a CA than that.

Does it make sense to talk about "verifying" uniqueness only, without
somehow verifying
the _correctness_ (i.e., in meat-space) of the attributes?

In this regard I am in general agreement with Bruno Salgueiro.  RECOMMEND
or SHOULD
would convey the general sense of the technical community (for whatever
good
that will do with respect to legislative and regulatory authorities)
without having to
strip off the epaulets and drum the offending CA out of the corps if they
don't comply with
our infinite wisdom because of their individual business requirements.

[Tom Gindin] Now I'm going to ask what the minimum level of verification
is.  What sort of verification is implied by a true statement that "the
subject claimed X (say, that he operates http://www.random.net/~user40),
and we put X in the certificate (in this case, under subjectAltName)"?  Is
that level so low that we need a separate place to put statements like
that, or rule them out of the certificate?  I doubt that any CA puts things
in a certificate with less evidence than that.

Regards,

Bob




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA19786 for <[e-mail]>; Tue, 30 May 2000 15:04:31 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 30 May 2000 16:04:41 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 30 May 2000 16:04:38 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: What is the meaning of the "indirectCRL" flag
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA19787

Al, a belated comment on your note below.

I agree with the statement that normally, only the entity that issued
the certificate is allowed to revoke it, or more generally to respond negatively
to an inquiry about certificate status.

But there ares some exceptions, notably where the relying party, or the relying
party's Enterprise, is capable of making their own decisions about the trust implications
about the end-user's certificate.

It is not beyond the realm of possibility that a given Enterprise might want to have
their own say-so about whom they trust, regardless of what some CA thinks about the 
status of a given user.  That user may have exceeded their credit line, gone bankrupt, 
have been convicted of a felony, be under investigation in connection with various
financial irregularities, etc., none of which would necessary force a CA to revoke his 
certificate.

The relying party would no longer choose to TRUST that individual, regardless of what
the CA might think of him. 

Presumably the relying party's Enterprise should be allowed to issue in internal-only CRL 
or the equivalent, and have it be accepted by the various relying parties, so long as that 
Enterprise's certificate is in the relying party's cache of trusted CA certificates, whether
or not the name of that Enterprise had previously be listed in the Certificate Issuer Extension.

Regards,

Bob

>>> Al Arsenault <[e-mail]> 05/25/00 07:29AM >>>
Christopher:

	An "indirect CRL" is a CRL issued by an entity other than the one that
issued the certificate(s) on the CRL. The relevance of this flag is
mostly explained in section 5.3.4, namely

5.3.4  Certificate Issuer

   This CRL entry extension identifies the certificate issuer associated
   with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
   indicator set in its issuing distribution point extension. If this
   extension is not present on the first entry in an indirect CRL, the
   certificate issuer defaults to the CRL issuer. On subsequent entries
   in an indirect CRL, if this extension is not present, the certificate
   issuer for the entry is the same as that for the preceding entry.

That is, the indirectCRL flag is used in combination with the
Certificate Issuer Extension to let you know that the issuer of the
certs in a CRL was different from the issuer of the CRL, and who it was.

(Normally, only the entity that issued the certificate is allowed to
revoke it; otherwise, you open yourself up to a nice denial of service
attack.  However, if you control it properly, this can be a nice
revocation management feature.)


		Al Arsenault
		Chief Security Architect
		Diversinet Corp.


Christopher Williams wrote:
> 
> RFC2459, section 5.2.5  "Issuing Distribution Point" mentions an indirectCRL
> flag, but does not give its significance.  Does anybody know?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA19069 for <[e-mail]>; Tue, 30 May 2000 14:32:03 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 30 May 2000 15:29:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 30 May 2000 15:29:44 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: SubjectAltName verification
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA19070

Tom,

>>> <[e-mail]> 05/30/00 12:51PM >>>
>     I am not sure that VeriSign class 1's E-mail address usage is
unverified, as opposed to rather weakly verified, because the
challenge/response serves as a form of POP.  Whether this is an adequate
POP is more questionable.

E-mail distribution of the certificate tied to a PIN presumably provides a 
weak proof that at least someone who has access to that mailbox also has 
access to the key pair. Unfortunately neither the mailbox nor the key can be 
shown to be under the exclusive control of the putative user, whoever that 
may be.

 >    Furthermore, a number of fields which are placed in certificates are
restrictions on usage and cannot be verified by the CA.  The most obvious
such fields are the KeyUsage and ExtendedKeyUsage extensions.

Well, that isn't quite so clear.  At least some cryptographic implementations, e.g., 
NICI and CDSA, together with most smart cards, implement strong typing
of such attributes, and hence could reasonable be relied upon to enforce such
restrictions.

The fact that most CAs fail to check on what kind of end-user software is in 
use, or place any constraints or even education requirements on their 
end-users is another problem, and one that is symptomatic of the over-reliance 
on CA policies, and a conspicuous lack of attention to the requirements for 
end-user implementations.

>     This does not, however, necessarily mean that the CA can avoid
responsibility for verifying identity fields and other fields that are
verifiable, such as Subject, SubjectPublicKey, SubjectAltName, and
SubjectDirectoryAttributes.

It's beginning to sound as though the CA doesn't really have to verify anything except
those things for which it is naturally authoritative, e.g., the uniqueness of the DN within 
the CA's own domain, etc.

Does it make sense to talk about "verifying" uniqueness only, without somehow verifying
the _correctness_ (i.e., in meat-space) of the attributes?

In this regard I am in general agreement with Bruno Salgueiro.  RECOMMEND or SHOULD
would convey the general sense of the technical community (for whatever good 
that will do with respect to legislative and regulatory authorities) without having to 
strip off the epaulets and drum the offending CA out of the corps if they don't comply with 
our infinite wisdom because of their individual business requirements.

Regards,

Bob





Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18030 for <[e-mail]>; Tue, 30 May 2000 13:42:09 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial04.spyrus.com [207.212.34.124]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA02592; Tue, 30 May 2000 13:48:44 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 30 May 2000 16:47:28 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: SubjectAltName verification
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

I believe that a CA can operate in accordance with one or more 
certification policies at the same time.  The way that the CA is able to 
fulfill the requirements of more than one certification policy is 
documented in a single CPS.

Russ

At 05:15 PM 05/25/2000 +0200, Denis Pinkas wrote:
>Paul and others,
>
>Some major details:
>
>1) I would propose to add an "s" to "certificate policy" making it
>"certificate policies".
>
>In RFC 2459 we have:
>
>4.2.1.5  Certificate Policies
>
>    The certificate policies extension contains a sequence of one or
>more
>    policy information terms, each of which consists of an object
>    identifier (OID) and optional qualifiers.
>
>2) In the same way, I would add an "s" to "CPS" making it "CPSs".
>
>3) Finally, since the verification is not uniform, I would also add
>an "s" to "verification".
>
>The final sentence would thus look like:
>
>"The precise nature of the verifications is detailed in the
>certificate policies and/or the CPSs."
>
>4) ... and a comment on the use of "definitively":
>
>We were looking for text replacement related only to the subject
>alternative name section 4.2.1.7. Now the sentence has been extended
>to cover parameters like "all other fields in a certificate" and
>"all certificate extensions". So "definitively" also applies to them
>now, and this is wrong.
>
>I would thus propose to delete the sentence "like all other fields
>in a certificate and all certificate extensions," and thus keep the
>idea  from RFC 2459, where only the subject alternative name is
>considered to be definitiviely bound to the public key, which was:
>
>    Because the subject alternative name is considered to be
>    definitiviely bound to the public key, all parts of the subject
>    alternative name MUST be verified by the CA.
>
>The new text would thus look like:
>
>   Denis> "The subject alternative name is considered to
>   Denis> be definitively bound to the public key. Thus the CA MUST
>   Denis> verify (directly or indirectly) all subject alternative
>   Denis> names. The precise nature of the verifications is detailed
>in
>   Denis> the certificate policies and/or the CPSs."
>
>Denis
>
> > Echoing Paul Hoffman's comment...  I find Steve's text to be
> > preferable.  For one thing, retaining "definitively" seems a good
> > thing to do.
>
> >       paul
>
>
>   Warwick> "The subject alternative name, like all other fields in a
>   Warwick> certificate and all certificate extensions, is considered
>to
>   Warwick> be bound to the public key.  Thus the CA MUST verify (in
>   Warwick> accordance with the applicable certificate policy and/or
>the
>   Warwick> CPS) all subject alternative names."
>
>
>   Steve> "The subject alternative name, like all other fields in a
>   Steve> certificate and all certificate extensions, is considered
>to
>   Steve> be definitively bound to the public key. Thus the CA MUST
>   Steve> verify (directly or indirectly) all subject alternative
>   Steve> names. The precise nature of the verification is detailed
>in
>   Steve> the certificate policy and/or the CPS."



Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA15788 for <[e-mail]>; Tue, 30 May 2000 11:55:55 -0700 (PDT)
Received: (qmail 30655 invoked from network); 30 May 2000 18:58:01 -0000
Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 30 May 2000 18:58:01 -0000
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 20:08:24 +0100
From: Bruno Salgueiro <[e-mail]>
Organization: SIBS
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: pt,en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <v04220801b5594a333a29@[192.168.1.151]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms52421F465528285FF5B5AAAD"

This is a cryptographically signed message in MIME format.

--------------ms52421F465528285FF5B5AAAD
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Stephen,

  I can agree to that in the extent that the CAs MUST verify every data
in the certificate that they physically can. In case of closed user
groups
this is particularly true but on the Internet is this feasible?

  When the PKIX group addresses these "verify" and "compliance"
definitions
in a "all or nothing" way, will undoubtedly opt out, as Bob Jueneman
explained
very well, all the TTPs out there. But this of course will only happen
if we
mean by verify the same as having a written and legally binding document
that
says that a certain attribute in the certificate really
belongs/represents the
applying entity. But, on the other hand, in Peter William's email I
assumed
that the class 1 (or equivalent) Verisign policy is a PKIX conforming
policy which
is unacceptable in the view of the EU Directive! You see, until someone
really
defines what verify means and what kind of quality in certificate data
we are
aiming for, nobody will understand each other, or I won't understand
you! :)

  So, how do we solve this? I believe that there are really some issues
that 
IETF won't be able to enforce in its standards. If you want to include
TTPs
that cannot, will not verify everything which depends greatly on the
respon-
sability of RAs and end users (risk management), then the word RECOMMEND
should be used throughout the document regarding these issues and make
an
explicit reference to the CPS and CP of the certificate and the local
legislation
where the PKI is issuing certificates. Remember that in closed user
groups other
issues arise, i.e., confidentiality on the policies used.

  Is this too awkward?

Regards,

Stephen Kent wrote:
> 
> Bruno,
> 
> it is worth noting that TTPs, like you company, are not the only
> types of CAs, and thus not the only focus of these standards.
> Organizational and geopolitical CAs are of interest too.  Such CAs
> have the advantage of being authoritative for the data they put into
> certs, if they limit themselves to what they really know.  A problem
> faced by TTPs, who are generally authoritative for no data, is how to
> make the financial tradeoff you allude to.  Maybe this is another
> reason not to favor PKI models based on TTPs :-).
> 
> Steve

-- 
=======================================================
Bruno Salgueiro       (mailto:[e-mail])
                   
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

Esta mensagem foi assinada com certificado MULTIcert.
Para obter o certificado da Autoridade de Certificação
PILOTO MULTIcert dirija-se ao site
            http://www.sibs.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================
--------------ms52421F465528285FF5B5AAAD
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

MIIFCwYJKoZIhvcNAQcCoIIE/DCCBPgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A4owggOGMIIC76ADAgECAgQ3Ttp2MA0GCSqGSIb3DQEBBQUAMCgxCzAJBgNVBAYTAlBUMRkw
FwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0MB4XDTk5MDUzMTIzMzIzNFoXDTAwMDYwMTAwMDIz
NFowYTELMAkGA1UEBhMCUFQxGTAXBgNVBAoTEFBJTE9UTyBNVUxUSWNlcnQxDTALBgNVBAsT
BFNJQlMxDjAMBgNVBAsTBURTSVNUMRgwFgYDVQQDEw9CcnVubyBTYWxndWVpcm8wXDANBgkq
hkiG9w0BAQEFAANLADBIAkEAuVICquW4IcbOpM37DdyglXYa8AAdR6UWq2VFEFTUtY0colnZ
a9BQ0DvTRB8sO5XuFiTWFnVR5T94R5j5PjE0cwIDAQABo4IBxjCCAcIwCwYDVR0PBAQDAgWg
MCsGA1UdEAQkMCKADzE5OTkwNjAxMDAwMjM0WoEPMjAwMDAyMTIwNDAyMzRaMBEGCWCGSAGG
+EIBAQQEAwIFoDCBqQYJYIZIAYb4QgENBIGbFoGYQ2VydGlmaWNhZG8gUElMT1RPIE1VTFRJ
Y2VydC4gRXN0ZXMgY2VydGlmaWNhZG9zIHNhbyBlbWl0aWRvcyBhbyBhYnJpZ28gZG8gQ1BT
IHF1ZSBzZSBlbmNvbnRyYSBubyBzZWd1aW50ZSBVUkwgLSBodHRwczovL3d3dy5zaWJzLm11
bHRpY2VydC5jb20vY3BzLmh0bWwwFQYDVR0RBA4wDIEKYnNAc2licy5wdDBKBgNVHR8EQzBB
MD+gPaA7pDkwNzELMAkGA1UEBhMCUFQxGTAXBgNVBAoTEFBJTE9UTyBNVUxUSWNlcnQxDTAL
BgNVBAMTBENSTDEwHwYDVR0jBBgwFoAUuJYgbdZN8aJJDF13gU9LJAiiL+UwHQYDVR0OBBYE
FEsyR+XzLWwX2+4LDk6/lA+XyaZtMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjQu
MAMCA6gwDQYJKoZIhvcNAQEFBQADgYEAk1GfA3Mtu3ECWCz2SIxkVisgOxt9vDKdQNTevrus
an91qvmvoHAtJMAlAolegoiDpq73qdk+9JMODICE5zEXDIK9w2nCkqBheFwJs7frm/tVLnSv
H+vQ5/5EX3ARwqforMGtjf+BO8OuYoxRyydKx9xheeyhke9+xJCEnOA2wDwxggFJMIIBRQIB
ATAwMCgxCzAJBgNVBAYTAlBUMRkwFwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0AgQ3Ttp2MAkG
BSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MDAwNTMwMTkwODI0WjAjBgkqhkiG9w0BCQQxFgQUVRfj8JdKsjAPKBlxdk0cS1gK4mgwUgYJ
KoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQGGX+t86fuaAwaXs
YYDsK4f5b3/rdmZ6cgXIIQX4zAqek7nwDq5Iy6SQbn4kcgYlS9JnodUBJ8hH/ZSy1JYCHvk=
--------------ms52421F465528285FF5B5AAAD--



Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15388 for <[e-mail]>; Tue, 30 May 2000 11:43:53 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA171732; Tue, 30 May 2000 14:49:47 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id OAA207376; Tue, 30 May 2000 14:51:25 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568EF.006792F0 ; Tue, 30 May 2000 14:51:18 -0400
X-Lotus-FromDomain: IBMUS
To: Peter Williams <[e-mail]>
cc: "'Al Arsenault'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 14:51:09 -0400
Subject: RE: SubjectAltName verification
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I am not sure that VeriSign class 1's E-mail address usage is
unverified, as opposed to rather weakly verified, because the
challenge/response serves as a form of POP.  Whether this is an adequate
POP is more questionable.
     Furthermore, a number of fields which are placed in certificates are
restrictions on usage and cannot be verified by the CA.  The most obvious
such fields are the KeyUsage and ExtendedKeyUsage extensions.
     This does not, however, necessarily mean that the CA can avoid
responsibility for verifying identity fields and other fields that are
verifiable, such as Subject, SubjectPublicKey, SubjectAltName, and
SubjectDirectoryAttributes.

          Tom Gindin




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14009 for <[e-mail]>; Tue, 30 May 2000 10:53:11 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirlg12456; Tue, 30 May 2000 18:00:49 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02933; Tue, 30 May 00 13:57:19 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA00631; Tue, 30 May 2000 14:00:48 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Tue, 30 May 2000 14:00:47 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Peter" == Peter Sylvester <[e-mail]> writes:

 >>  1) Time Stamp Token ordering can be done in most cases (see
 >> above) by only using GenTime and accuracy.

 Peter> A litte flame about accuracy: A user that wants to get a time
 Peter> stamp in order not to miss a deadline goes to a TSA: The TSA
 Peter> tells, well it is 23h59'59" but maybe not, since we are not
 Peter> sure whether we have the right time, it may already be well 2
 Peter> seconds later or earlier, well, that's what we think, or
 Peter> almost.

 Peter> What kind of decision can you make based on that?  What would
 Peter> be the harm if the TSA would simply adjust the time to the
 Peter> lower end of the interval, and generate no accuracy.  If there
 Peter> is an application that requires to get the earlimost stamp
 Peter> just after midnight, and you are too early, you just repeat.

 Peter> Comparison between two time stamps of the same tsa can be done
 Peter> without using the accuracy; if the genTime is different, then
 Peter> there they are ordered by authority of the TSA.

I can't see the point of this.

The interpretation of a timestamp with accuracy is simple: the TSA is
making an assertion that the time when it generated the stamp is in
the range [ts - accuracy .. ts + accuracy].  (In other words, it
promises that UTC will be contained in that interval.)

So if you want to know the lower end of the interval, fine, you can
compute that trivially.  It is not necessary to throw away information
in the protocol to give you that option.

Other applications may want to know the upper end of the interval.
And a number will want to know the interval itself.

For example, to order timestamps from two different TSAs, you have to
have the intervals.  The order is a partial order: if the intervals
don't overlap, the answer is obvious, and if they do overlap, the
order is indeterminate.  This in fact is the reason for having the
accuracy field.


>>>>> "Michael" == Michael Zolotarev <[e-mail]> writes:

 Michael> 3. a stamp issued by another TSA (AND the precision
 Michael> diapazons of the two stamps overlap). The only purpose of
 Michael> comparing is to figure out which stamp was issued
 Michael> earlier. We have two cases to consider here:

 Michael> Case1: Precision_TSA1 is equal to Precision_TSA2.  Here the
 Michael> rule would be to treat the precision as the span of the
 Michael> probability graph, with the probability being the highest at
 Michael> the middle point (base time value), and 0 at the ends of the
 Michael> 'hill'. Therefore, the court (my court :) would simply opt
 Michael> to ignore the precision field at all, and look at just the
 Michael> base values.  I would consequtively reject any claims that
 Michael> *your* probability graph is not a 'hill-shaped' curve.

 Michael> Case2: Precision_TSA1 is smaller than Precision_TSA2.  As a
 Michael> judge I fully trust the TSA1 'cause it's time is more
 Michael> precise. So I again look at the base time value. If TSA1
 Michael> stamp says it was generated a second earlier than TSA2 stamp
 Michael> - that's the truth. If TSA1 stamp says it was generated a
 Michael> second later than TSA2 stamp - that's the truth as well.

I don't understand this reasoning at all.  Whether TSA1 has an
accuracy smaller than that of TSA2 isn't interesting, as far as I can
see.  I don't understand why you would use it to make a binary
decision of merit (i.e., trusting only the TSA that has the smaller
accuracy). 

If you ignore the accuracy and compare only midpoints, you will
definitely be making an incorrect decision when the intervals
overlap.  ("Incorrect" in the sense of "not supported by the
evidence".)   This is true whether the accuracy values are the same or
different.  (For example, in your case 2, if TSA1 says 1:00:00 +/- 1s,
and TSA2 says 1:00:01 +/- 3s, it sounds like you're saying that the
TSA1 stamp is generated a second before the TSA2 stamp.  Not so -- the
TSA2 stamp may have been generated as much as 3 seconds before the
TSA1 stamp.)

     paul


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA13921 for <[e-mail]>; Tue, 30 May 2000 10:52:41 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 30 May 2000 11:43:30 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 30 May 2000 11:43:24 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: SubjectAltName verification
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA13922

Let me offer some comments on what I believe is a very important,
and obviously contentious issue.

In the past, the IETF has been primarily concerned with issues of 
over-the-wire protocol and structures, and the syntactic definitions 
of those fields.

Other issues, and in particular issues that pertained to commercial
business practices and/or various (potential) legal issues have generally 
been left to the relevant experts in those fields to define.

In particular, the tradition within the IETF has been to espouse only 
purely technical issues, regardless of their potential business impact --
indeed, sometimes amazingly oblivious to such issues.

As a result, the PKIX WG (and X.509) is, at least in my mind, notorious 
for failing to adequately come to grips with the precise semantic meaning 
of many of the terms that are defined.  As a case in point, I would cite 
the complete lack of any agreement whatsoever as to the 
semantic meaning of the "nonrepudiation" key usage, either from a legal 
perspective or a narrower, but still useful set of do/don't do perspectives that
would apply to end user software, either the CA, the originator, or the relying 
party.

As a result, the term is neither defined, nor deprecated.  Apparently the 
consensus was to let commercial practice sort out the issue, and perhaps 
this is in fact the best course.

The PKIX WG, has long since departed from the traditional IETF practice 
of "rough consensus and running code".  Now we are institutionalizing 
some of the most disliked features of ISO and we have become a 
"design-by-committee" organization.  Unlike ISO, however, where various 
countries explicitly take into account various national objectives, and weigh, 
or at least try to weigh, the various commercial interests before coming to
agreement, we generally fail to do so.

The IETF lacks any form of institutional representation of business interests --
every contributor's comment or vote is treated exactly the same as every other,
regardless of how small or how large the contributor's company's stake might
be the in the outcome.

That's of course very democratic, and everyone has a more or less equal chance 
to carry the day based on their individual fervor and ability to persuade. Unfortunately,
this tends to mean that anyone can propose his own pet rock for standards 
consideration, regardless of the commercial viability of that approach.  

I am particularly thinking of the blatant anti-intellectual property preferences 
of the IESG, and their instance on including as mandatory features encryption 
algorithms which have not been well accepted in the marketplace. The various 
working groups then exacerbate the problem by adding more and more features and 
algorithms to the list of "approved" or "standard" featured, often at the behest of
a very small community of interest.  Yet every one of these additional features takes 
some amount of additional coding (generally not too large) to implement, plus 
significantly more in terms of GUIs and documentation, and an exponentially 
increasing amount of testing, all for little or no consumer benefit.

But because of the importance of standards per se, the products are under a 
considerable amount of pressure to be "conforming" to requirements that have 
not been validated by the user community, and to which the user community had little or 
no say so, and the cost and complexity inevitably leads to both buggy and 
expensive software

On the other hand, existing commercial practices may suddenly be deemed to be 
inappropriate or nonconforming, sometimes despite a considerable body of commercial 
acceptance, in a rather high-handed "father knows best" attitude.  Since the commercial 
entities may have only a few representatives, they may not be able to offset the 
opinions offered by others with competing interests.

I believe this is an increasingly unsatisfactory state of affairs, and may eventually lead 
to the IETF being regarded as more or less irrelevant to both the vendor and the 
user community, particularly if existing commercial practices are suddenly, and perhaps 
rather capriciously, labeled as being non-conforming.

Now, how does this apply to the current controversy?

By not adopting either an opt-out indication that certain perhaps useful
information has not been explicitly validated by the CA, perhaps because it isn't 
economically feasible to do so, the implication is that everything in the certificate
is God's own BINARY truth.  And if you don't believe that, go off and read 80 
or more pages of legalese to determine exactly what is meant. Of course computer
programs can't do that, so we will resort to more and more complex schemes of
policy OIDs, policy constraints, name constraints, etc., until we have no interoperability
at all, or otherwise the relying parties will decide to limit the amount of trust that 
they put in a certificate to a lowest common denominator across the entire
industry.

I would submit that neither approach is very helpful.

We don't even seem to be able to agree as to what the problem is.

Denis Pinckas says:

>In RFC 2459, section 4.1.2.6  Subject, we currently have:

>   Where it is non-empty, the subject field MUST contain an X.500
>   distinguished name (DN). The DN MUST be unique for each subject
>   entity certified by the one CA as defined by the issuer name field. A
>   CA may issue more than one certificate with the same DN to the same
>  subject entity.

>Let us suppose that we use an *empty* distinguished name (which is
>allowed by the standard). Should the above property also apply to
>the alternative name ? I would think so and I understood 
>"definitively bound" as equivalent to "unique". In other words the
>subject Alternative name once assigned must never be re-assigned for
>a different entity by the CA. To this respect, the other fields that
>where mentioned are not "definitively bound". So you now understand
>the rational of the change that was made.

I won't say that Denis' argument doesn't make any sense at all, but 
equating "definitively bound" to "unique" seems to me to be a very great
leap.

At least to me, "definitively bound" inherently implies the "correctness" of the 
attribute that is bound to the key, and by implication to the persona who is 
affiliated with that attribute in some fashion.

Granted, if the name is merely a e-mail address or post office box, it is very difficult
and perhaps impossible to correlate that name to any particular real person, even if 
(especially if) it is [e-mail]. 

On the other hand, if the DN (or any other field in the certificate) does presumably
uniquely define an organizational or residential person by a globally unique name, 
then a reasonable inference to be drawn from the certificate which binds both 
the DN and subjectAltName to the same key is that they same persona is somehow
involved.

Does that mean that the identified user has sole and exclusive access to that 
e-mail address (i.e., his spouse and kids don't share the same mail box), or that he 
even bothers to read his mail there?  Not necessarily.

Then exactly what does "validate", much less "definitively bound" mean in this 
circumstance?  I don't like to have to say so, but the only option at this point is to
say "go read the CP/CPS".

The biggest problem, I believe, is that we are attempting to apply rather 
Procrustean binary logic to a problem that inherently involves shades of gray.

We can say "This value is either a 1 or a 0, and that's that.", but this is subject
to potentially hidden provisos in the CP or CPS, "for suitably defined values of 1 
and/or 0".

Trying to say that something is "right" or "not right", regardless of existing 
commercial practice would seem to pretend to a moral and/or legal
authority that the IETF simply doesn't command, unless the Pope has suddenly 
become a silent co-chair.

On the other hand, saying nothing at all, and leaving it up to a completely laissez faire
interpretation a la nonrepudiation isn't very helpful or useful either.

That's one reason why in the Novell Security Attributes extension we include in 
all of our certificates, we define a "Certificate Class" that ranges from 0 to 255,
in an attempt to define some shades of gray between a completely anonymous user
and a sovereign government. 

Cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm .

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.



>>> Al Arsenault <[e-mail]> 05/28/00 07:27PM >>>
Peter,

	In a word, "No".  Details below:

Peter Williams wrote:
> 
> User includes account name in the subject DN. A Private
> organization's CA service services a closed intranet and
> extranet community. It issues a certificate including
> the account name. This circumstance is common in the Internet
> community today.
>

> CA has a policy, which is partially disclosed. The disclosed
> Policy Elements are made available only to subscribers. This
> circumstance is common in the Internet community today.
> 
> The motivations for establishing the extent
> of a field verification policy are beyond the understanding
> level of the CA's subscribers.  This  circumstance is common
> in the Internet community today.
> 

I won't argue with any of these; I'll simply state that the fact that
it's common in the Internet community today doesn't make it the right
thing to do.  

> The CA does disclose a policy element to susbcribers to
> procedurally follow a  "limited"  technical verification procedure
> concerning account names. The procedure establishes that an account
> of that name "exists" - in an account management system acceptable
> to the CA - at the time of certificate issuance.
> 

In other words:  the CA verified that there was someone named "Bill
Clinton" purporting to reside at 1600 Pennsylvania Avenue, Washington,
DC at the time of certificate issuance, so I'll put that in the
certificate.  I make no representation that the subject of this
certificate is the same "Bill Clinton" as the one you might be thinking
of, but I'll put it in the cert anyway.  All other data in the
certificate are verified as per the CP/CPS/other appropriate document.

Is this useful?  To what relying party?

> All other data in a certificate is "verified", according
> to other per-CA policy criteria and/or PKIX mandates.
> 
> Does the resulting certificate, when issued
> under the above scenario, conform with the
> proposed PKIX standards for field verification?
>

Not according to the ones I'm recommending.  :-)
 
> A fourth party undertakes a private PKIX-audit of
> the CA for the benefit of the CA.  Should it
> determine the CA is acting according to the spirit
> of the proposal concerning field verification
> when executing this scenario?
>

Again, in a word:  "NO".  The presence of an "attribute" whose value has
not been verified - either directly or indirectly - by the CA is at best
misleading, and at worst openly harmful to the relying party.
 

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13446 for <[e-mail]>; Tue, 30 May 2000 10:38:51 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirlf27544; Tue, 30 May 2000 17:46:29 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02672; Tue, 30 May 00 13:42:56 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA00623; Tue, 30 May 2000 13:46:24 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Tue, 30 May 2000 13:46:24 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Tony" == Tony Bartoletti <[e-mail]> writes:

 Tony> At 12:21 PM 5/30/00 -0400, Paul Koning wrote:
 >> >>
 Peter> 1, 1, 1, 1 ... would respect this requirement :-)
 >>  No, because the sequence 1 1 1 is NOT "increasing".  It is
 >> "non-decreasing" which is not the same thing.
 >> 
 >> "Increasing" means A(i+1) > Ai for all i.  (Non-decreasing means
 >> A(i+1) >= Ai for all i.)
 >> 
 >> "Monotonically" is a bit redundant but it doesn't hurt.

 Tony> Sorry Paul.  The sequence 1, 1, 1, ... IS monotonically
 Tony> increasing (and decreasing, for that matter.)  Perverse but
 Tony> true.

That doesn't match the math I learned, but I guess it goes to show
that you can't count on using this sort of terminology if you want to
communicate the requirements clearly.

Ok, so eliminate the words and replace by the requirement (i.e., the
required relationship is > )

	 paul



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13012 for <[e-mail]>; Tue, 30 May 2000 10:28:38 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA11982; Tue, 30 May 2000 10:35:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 30 May 2000 10:39:49 -0700
To: Paul Koning <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:21 PM 5/30/00 -0400, Paul Koning wrote:
>  >>
>  Peter> 1, 1, 1, 1 ... would respect this requirement :-)
>
>No, because the sequence 1 1 1 is NOT "increasing".  It is
>"non-decreasing" which is not the same thing.
>
>"Increasing" means  A(i+1) > Ai for all i.  (Non-decreasing means
>A(i+1) >= Ai for all i.)
>
>"Monotonically" is a bit redundant but it doesn't hurt.

Sorry Paul.  The sequence 1, 1, 1, ... IS monotonically increasing
(and decreasing, for that matter.)  Perverse but true.

That is, one has Xi <= Xj whenever i <= j.

To eliminate the "=" in the "<=" one must specify "strictly" increasing.

(I will grant that the term "monotonic" seems redundant when "strictly"
is specified.  What could be the difference between "strictly increasing"
and "strictly monotonically increasing?")

___tony___



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



Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12577 for <[e-mail]>; Tue, 30 May 2000 10:17:38 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1T6C>; Tue, 30 May 2000 13:26:04 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Rationale for Nonce in Time Stamp Protocol
Date: Tue, 30 May 2000 13:25:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA12578

Salut Denis,

As requested, I have made some small changes to your proposed text about the
nonce for the security consideration section and the amended version, with
deletes and inserts tagged, appears below:

"Inadvertent or deliberate replays for requests incorporating the same hash
(algorithm and) value may happen. Inadvertent replays occur when more than
one copy of the same request message gets sent to the TSA because of
problems in the intervening network elements. Deliberate replays occur when
a middleman is replaying legitimate TS responses. In order to detect these
situations, several techniques may be used. Using a nonce always allows to
detect replays, and hence its use is RECOMMENDED. Another possibility is to
use both a local clock and a moving time window during which the requester
remembers all the hashes sent during that time window. When receiving a
response, the requester <inserted>ensures</inserted> <deleted>makes sure
that</deleted> both <inserted>that</inserted> the time of the response is
within the time window and that there is only
<deleted>once</deleted><inserted>one occurrence of</inserted> the hash value
in that time window. If <deleted>there is</deleted> the same hash
value<inserted>is generated</inserted> more than once <inserted>within a
time window</inserted>, the requester may either use a nonce, or wait until
the time window has moved to come back to the <deleted>previous</deleted>
case where the same hash value appears only once during that time window."

However, you have left the second paragraph of Section 2.2 unchanged, which
may still be open to interpretation. The way it is currently written, it
would seem that a requesting entity would have to reject a totally valid
response because of possible delays in the intervening network elements
and/or drifting of the requesting entity own local time reference. In order
to avoid this possible interpretation, an amended version, also with deletes
and inserts tagged, appears below:

"It SHALL then verify the <deleted>timeliness of the </deleted>response
<inserted>against replay </inserted>by verifying either the time included in
the response against a local <deleted>trusted </deleted>time reference, if
one is available, and/or the value of the nonce (large random number with a
high probability that it is generated by the client only once) included in
the response against the value included in the request. If any of the
verifications above fails, the TimeStampToken SHALL be rejected."

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Tuesday, May 30, 2000 6:09 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol



François,

Sorry for the delay to answer, but the trafic is currently rather
heavy on the TSP document and it takes time to prepare answers.

I do not agree to make the nonce mandatory since there exists cases
where it is not needed. I also do not think that the case of a
subverted TSA falls under the topic of "deliberate replay". 

However, in order to address your concern, I could add the following
text in the security consideration section :

Inadvertent or deliberate replays for requests incorporating the
same hash (algorithm and) value may happen. Inadvertent replays
occur when more than one copy of the same request message gets sent
to the TSA because of problems in the intervening network elements.
Deliberate replays occur when a middleman is replaying legitimate TS
responses. In order to detect these situations, several techniques
may be used. Using a nonce always allows to detect replays, and
hence its use is RECOMMENDED. Another possibility is to use both a
local clock and a moving time window during which the requester
remembers all the hashes sent during that time window. When
receiving a response, the requester makes sure that both the time of
the response is within the time window and that there is only once
the hash value in that time window. If there is the same hash value
more than once, the requester may either use a nonce, or wait until
the time window has moved to come back to the previous case where
the same hash value appears only once during that time window.

If you prefer a different wording, please provide the amended text.

Denis

> Denis,
> 
> We probably need to be clear on the requirement and then we can be sure
that
> the text in the document reflects the requirement.
> 
> You seem quite clear that the requirement is to prevent replays - but we
> need to be clear on whether we are trying to detect and/or prevent
> deliberate or inadvertent replay or both.  Inadvertent replay could occur
> when more than one copy of a request message gets sent to the TSA because
of
> problems in the intervening network elements.  In this case the TSA
because
> of its "no look" policy would just blindly generate time stamps for each
of
> the copies it receives.  Deliberate replay, on the other hand, assumes
that
> the TSA has been subverted or its signing key has been compromised, or
that
> a middleman is replaying legitimate TS responses.  Each of the various
> potential replays needs to be considered to ensure that the protocol
> protects against it.
> 
> 1. Deliberate middleman replay.  Since each response contains a signed TS
> Token which includes the message imprint, serial number and time, this
type
> of attack is easily detected within the currently proposed protocol.
> 
> 2. Replay by subverted TSA.  A subverted TSA could generate any number of
TS
> Tokens containing the same message imprint at any time.  Because each
could
> have different serial number and/or time, each would be unique and there
is
> no way the client could detect a replay on the basis of the response.  The
> only way this could be detected would be for every request to include a
> nonce and for the client to maintain a record of all nonces generated to
> verify against the responses.
> 
> 3. Inadvertent replay.  Again, the only way for the client to distinguish
> this type of replay would be through the use of a nonce. In this case,
> however, it should not be necessary to maintain a record of all nonces
> generated but only those generated within a time window as you suggest. If
> the window length is set to, for example, twice the expected delay between
> request and response, the client could be quite confident that there have
> been no inadvertent replays if no duplicate nonce values are detected.
> 
> To summarize, the nonce should not be an optional component of replay
> detection (as suggested by the current wording) - it is necessary if the
> client is trying to protect against anything other than deliberate
middleman
> replays.
> 
> It is suggested that the wording in the fourth sentence of the second
> paragraph of Section 2.2 (page 3) be changed to:
> 
> "It SHALL then verify the value of the nonce (large random number with
high
> probability that is generated by the client only once) included in the
> response against the nonce value included in the corresponding request to
> ensure that no replay has occurred."
> 
> In Section 2.4.1 remove the OPTIONAL qualifier from nonce in the
definition
> of TimeStampReq (page 4).
> 
> Change the wording of first sentence of the nonce description in Section
> 2.4.1 (page 5)to read:
> 
> "The nonce allows the client to verify the response against replay."
> 
> In Section 2.4.2 remove the OPTIONAL qualifier from nonce in the
definition
> of TSTInfo (page 7).
> 
> Change the wording of the nonce description in Section 2.4.2 (page 5)to
> read:
> 
> "The nonce field MUST be equal to the value provided in the TimeStampReq
> structure."
> 
> If you agree with this approach, then I would suggest we prepare a short
> annex to describe the two different cases - subverted TSA vice inadvertent
> replay.
> 
> Have a good weekend!
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, May 24, 2000 5:36 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Rationale for Nonce in Time Stamp Protocol
> 
> Francois,
> 
> I realized that I ommited to reply to your E-mail.
> 
> > Salut Denis,
> >
> > I do not remember if this issue was raised before, but in Section 2.2
the
> > following statement is made:
> >
> > "the requesting entity .... SHALL then verify the timeliness of the
> response
> > by verifying either the time included in the response against a local
> > trusted time reference, if one is available, and/or the value of the
nonce
> > (large random number with a high probability that it is generated by the
> > client only once) included in the response against the value included in
> the
> > request."
> >
> > A nonce is normally used to detect attempts at replays, which is not
> > necessarily related to the timeliness of the response to a particular
> > request as mentioned here.
> >
> > The first part of the statement talks about verifying the time included
in
> > the response against a locally trusted time source.  This could used to
> > measure round trip path delay for calibration purposes,
> 
> No. This is not the goal. The goal is to make sure that you have no
> replay, in particular on the same hash value.
> 
> > but unless one could
> > be certain that the locally trusted source is as accurate as the TSA
time
> > source (or, at least, that the difference between them is fixed and
> > well-known), I don't see how it would detect/prevent replays.
> 
> Using a moving time window the caller remembers all the hashes he
> sent during that time window.
> If there is not the same hash value within that time window, then he
> makes sure that the time of the response is within the time window.
> If there is the same hash (a very rare situation), it is a little
> bit more complicated, and there are several options. Among them:
> using the nonce, or waiting until the time window has moved to come
> back to the previous case: only one hash value during that time
> window. But we are talking implementations details, which is not the
> topic of an RFC.
> 
> >  If one has
> > such a trusted time source locally, what is the point in using a TTP for
> > time stamping?
> 
> The time is locally trusted, ... which does not mean that other
> people will trust that time.
> 
> >
> > Could you please clarify the intent of this statement and if the intent
is
> > to prevent replays or check the timeliness of responses or both?
> 
> Now, that you have the explanations, if you still believe that the
> text is not clear enough, I suggest that you submit a proposal to
> clarify the text.
> 
> Regards,
> 
> Denis
> 
> >
> > Francois
> > ___________________________________
> > Francois Rousseau
> > Director of Standards and Conformance
> > Chrysalis-ITS
> > 1688 Woodward Drive
> > Ottawa, Ontario, CANADA, K2C 3R7
> > [e-mail]      Tel. [phone] ext. 419
> > http://www.chrysalis-its.com     Fax. [phone]


Received: from unimur.um.es (unimur.um.es [155.54.1.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11727 for <[e-mail]>; Tue, 30 May 2000 09:40:21 -0700 (PDT)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by unimur.um.es (8.9.1b+Sun/8.9.1) with ESMTP id SAA16895 for <[e-mail]>; Tue, 30 May 2000 18:47:52 +0200 (MET DST)
Received: from dif.um.es (labredes15.dif.um.es [155.54.210.9]) by aries.dif.um.es (Postfix) with ESMTP id C332FEC1A for <[e-mail]>; Tue, 30 May 2000 18:47:46 +0200 (MET DST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 18:47:48 +0200
From: Gabriel =?iso-8859-1?Q?L=F3pez=20Mill=E1n?= <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: PKIX library
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id JAA11730

Gabriel López Millán wrote:

>     Hello all.
>
>     There is any free pkix library for Java?
>
>     Thanks, Gabi.


        OK, I am testing JCSI library. It is good, but I want a library
which I can construct PKIMessages, with PKIBody, PKIHeader, etc.

    There is anything?

    Thanks a lot, Gabi.


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11042 for <[e-mail]>; Tue, 30 May 2000 09:13:34 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirkz14525; Tue, 30 May 2000 16:21:07 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01519; Tue, 30 May 00 12:17:37 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA00557; Tue, 30 May 2000 12:21:05 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Tue, 30 May 2000 12:21:05 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Peter" == Peter Sylvester <[e-mail]> writes:

 >> At 15:38 26.05.00 +0200, Denis Pinkas wrote: >1) for the first
 >> requirement, stick to the use of this parameter as >required for
 >> PKCs, CRLs in RFC 2459 and for ACs. This means only >require
 >> uniqueness and nothing else. We may then keep the name
 >> >"serialNumber".
 >> 
 >> Just a short remark: CRL serialnumbers (=the cRLNumber extension)
 >> are required to be monotonically increasing.  "5.2.3 CRL Number
 >> The CRL number is a non-critical CRL extension which conveys a
 >> monotonically increasing sequence number for each CRL issued by a
 >> CA.  "
 >> 
 Peter> 1, 1, 1, 1 ... would respect this requirement :-)

No, because the sequence 1 1 1 is NOT "increasing".  It is
"non-decreasing" which is not the same thing.

"Increasing" means  A(i+1) > Ai for all i.  (Non-decreasing means
A(i+1) >= Ai for all i.)

"Monotonically" is a bit redundant but it doesn't hurt.

	paul


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10554 for <[e-mail]>; Tue, 30 May 2000 08:59:37 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1TWB>; Tue, 30 May 2000 12:08:03 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Encrypting private keys - how do you achieve this in practice ?
Date: Tue, 30 May 2000 12:07:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Dave,

As you are probably aware, the PKCS#11 wrapping function should be supported
by hardware cryptographic modules that are used to generate certificate
subject private keys in order for these private keys to be extracted and
exported to end entities since these private keys should never appear in
plaintext form outside of such hardware cryptographic modules.

Our hardware cryptographic modules, which are used by many PKI vendors,
support the standard PKCS#11 v2.01 wrapping and unwrapping functions to
export and import private keys. This implies the following steps according
to Section 11.9 of PKCS#11 for an RSA private key:

1. The RSA private key must first be BER-encoded according to PKCS #1's
RSAPrivateKey ASN.1 type. This type requires values to be present for all
the attributes specific to Cryptoki's RSA private key objects. In other
words, if a Cryptoki library does not have values for an RSA private key's
CKA_MODULUS, CKA_PUBLIC_EXPONENT, CKA_PRIVATE_EXPONENT, CKA_PRIME_1,
CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT2, and CKA_COEFFICIENT values, it
cannot create an RSAPrivateKey BER-encoding of the key, and so it cannot
prepare it for wrapping;

2. The RSA private key is then BER-encoded according to PKCS #8's
PrivateKeyInfo ASN.1 type; and

3. The resulting string of bytes is encrypted with the secret key. This
encryption must be done in CBC mode with PKCS padding.

Do you mean by your response to Christopher that the PKCS#8 PrivateKeyInfo
type is what gets encrypted in the encValue field of the EncryptedValue
structure? If not, do you know what gets encrypted in the encValue field or
is it something that will need to be profiled under the upcoming CMP
testing?

Regards,

Francois

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Friday, May 26, 2000 11:48 AM
To: [e-mail]
Subject: Re: Encrypting private keys - how do you achieve this in
practice?


Christopher,

If your implementation always exports password-protected private
keys, and you don't want to (or can't, because it's in hardware)
touch the existing code, then you could just put some glue
around the module to unwrap the key with the password and
then wrap the plaintext key for the intended recipient in an
EnvelopedData structure, using
PKIArchiveOptions:encryptedPrivKey:envelopedData. Put the private key
in EnvelopedData:encryptedContentInfo:encryptedContent and set
EnvelopedData:encryptedContentInfo:contentType to id-data.

It isn't recommended (at least by me) to place a password-wrapped
private key directly in PKIArchiveOptions:encryptedPrivKey:encryptedValue.
But the straightforward approach to doing so would be to populate:

encryptedValue:symmAlg   - ???
encryptedValue:encValue  - BER of EncryptedPrivateKeyInfo

Fortunately, PKCS#8 does not define an OID for EncryptedPrivateKeyInfo,
as they obviously felt that this structure is never suitable for use
within another protocol :-).

Dave




> From: "Christopher Williams" <[e-mail]>
> To: "PKIX Mailing List" <[e-mail]>
> Subject: Encrypting private keys - how do you achieve this in practice?
> Date: Fri, 26 May 2000 11:35:06 +0100
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> 
> When you encrypt a private key to put it in the EncryptedValue structure,
it
> appears from the standard that you take the private key octets as the
plain
> text and encrypt under the symmetric algorithm / symmetric key, etc.
> 
> There's a problem here.  Our implementation of RSA / DSA / DH, etc. does
not
> give out private keys in plain text and I guess that many other
> implementations are the same.  We do support password wrapping of the
> private key (e.g. PKCS#8) but the EncryptedValue structure does not seem
to
> be designed to take a password-wrapped key.
> 
> How do you reconcile PKCS#8 with the EncryptedValue structure?  For
example,
> I guess that you could supply the password as the symmetric key and encode
> the EncryptedPrivateKeyInfo structure as a bit string, but what would then
> be the symmetric algorithm?
> 
> How have other people implemented private key encryption?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10423 for <[e-mail]>; Tue, 30 May 2000 08:59:21 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <LS0CRV2Z>; Tue, 30 May 2000 09:01:47 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, [e-mail]
Subject: RE: SubjectAltName verification
Date: Tue, 30 May 2000 09:01:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Al,

could you add a little, just a little, technical 
argument to your mails, please?
 
The matters at hand are very important
issues of conformance, and represent a major
change in policy.

You ask if ACES was referred to.

No! ACES was NOT the "national" infrastructure
referred to, in the parenthesis. Stop inventing spurious 
denials and protestation on matters that I simply have 
not introduced. It is simply not fair to the ACES people
who have no voice here to deny your assertions.

NO! VeriSign's commercial work in support of ACES was not
mentioned, implied, and should NOT be inferred. No,
ACES is not the only (major) "national" CA infrastructure
in the world, Al. But thankyou for the opportunity
to correct a US-centric view of the Internet.

Forgive me if I do not name the government; it
is for similar reasons as you feel when
you censure VeriSign. Forgive me
if I avoid responding a whole series
of erroneous assertions drawn from
your false assumption. They confuse the 
conformance issue - which is nicely framed for 
legitimate community discussion, if any.

To the valuable element of your contribution:

Nobody (at ValiCert) is writing standards to
benefit VeriSign, unelss we all win in the usual
open standards way! We are trying to ensure tha
the deployed PKI (compliant with RFC 2459) continues 
to grow, if possible. 

If we collectively decide that 
systems that were conforming with a draft standard's 
version X must now be declared non-conforming with
verison Y, then its perfectly proper to specifically
call out this for explicit endorsement by the WG. At
least it must be discussed in the next WG meeting;
of such magnitude is the change. 

Persoally I vote against: VeriSign's
PCS Class 1  contribution to the general internet should 
continue to be incorporated in PKIX, not cast out.

What we saw happen here last week was quite an
extraordinary event.


-----Original Message-----
From: Al Arsenault [mailto:[e-mail]]
Sent: Tuesday, May 30, 2000 8:33 AM
To: Peter Williams
Cc: 'Denis Pinkas'; [e-mail]
Subject: Re: SubjectAltName verification


I'll try to step lightly here, because the company is question is a
partner of my own employer.  However, I'm in complete disagreement with
one of Peter's central points:

Peter Williams wrote:
><snip>
> 
> Some or all of VeriSign's Class 1 offering
> of its Public Certification Service(s) is/are
> apparently no longer PKIX-conforming, if one applies
> the conformance principles now proposed by Steve. It
> was conforming, last week. 
> 
<snip>
> 
> This seems an excessive impact of your
> suggestion. I, as one of its co-designers, would
> like to include VeriSign PCS's current Class 1
> offering within the PKIX family of conforming CAs.

In general, writing requirements in any standard to ensure that a
particular product or implementation succeeds is a really bad idea.
(Else I'd be proposing requirements to ensure that Diversinet's products
suddenly become PKIX-conformant, even though we currently rely heavily
on an unpublished proprietary protocol for communication between RAs and
CAs.)  While we should not single out any company's product or
implementation unfairly, neither should we tailor a requirement or set
of requirements to fit a particular product or implmentation.  Thus, if
VeriSign's Class 1 service is not "PKIX-conformant", my response would
be to question why.  If it's because VeriSign has chosen not to meet a
requirement that this group deems useful, then that's too bad - VeriSign
loses.  If it's because we're imposing a requirement that's not really
important, okay, I could see deleting the requirement, but I don't
believe that that's the case.

As for

>(A "national"
> ie governmental CA service to residents also suddenly
> became non-conforming last week, also, because
> of other subtle tweaks)

okay, I'll bite.  I'll assume that you're alluding to ACES here, since
that's the only major "national" program that fits your description.  I
know how ACES policy says that information in certs is to be verified -
it's done indirectly, using existing Government databases to provide
verification of data to the approved CAs.  However, I'm confused, since
(a) VeriSign's class 1 service was never and will never be "good enough"
for ACES; and (b) I'm not sure what tweaks killed any existing PKIX
conformance for the ACES vendors.  (BTW:  did just one ACES vendor
become non-conformant, or all three of them?)

And if there's something else you're talking about here, please be less
obtuse.  Be specific, even.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10299 for <[e-mail]>; Tue, 30 May 2000 08:57:32 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <[e-mail]>; Tue, 30 May 2000 09:05:12 -0700
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 12:02:51 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Al Arsenault wrote:
> 

<snip>
>  I'll assume that you're alluding to ACES here, since
> that's the only major "national" program that fits your description.  

Geesh - working for a Canadian company, you'd think I'd know better by
now.  My apologies for that remark - ACES is the only "national" program
IN THE US that fits Peter's description, and since he now mostly resides
in the US, I jumped to the conclusion that he was referring to a US
program.  Of course, there are major national PKI-based programs in any
number of countries - if it was one of them we knocked out of PKIX
conformance last week (without a good reason for doing so), I'd be
interested in hearing about it.


>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09545 for <[e-mail]>; Tue, 30 May 2000 08:27:26 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <[e-mail]>; Tue, 30 May 2000 08:35:06 -0700
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 11:32:44 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: "'Denis Pinkas'" <[e-mail]>, [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'll try to step lightly here, because the company is question is a
partner of my own employer.  However, I'm in complete disagreement with
one of Peter's central points:

Peter Williams wrote:
><snip>
> 
> Some or all of VeriSign's Class 1 offering
> of its Public Certification Service(s) is/are
> apparently no longer PKIX-conforming, if one applies
> the conformance principles now proposed by Steve. It
> was conforming, last week. 
> 
<snip>
> 
> This seems an excessive impact of your
> suggestion. I, as one of its co-designers, would
> like to include VeriSign PCS's current Class 1
> offering within the PKIX family of conforming CAs.

In general, writing requirements in any standard to ensure that a
particular product or implementation succeeds is a really bad idea.
(Else I'd be proposing requirements to ensure that Diversinet's products
suddenly become PKIX-conformant, even though we currently rely heavily
on an unpublished proprietary protocol for communication between RAs and
CAs.)  While we should not single out any company's product or
implementation unfairly, neither should we tailor a requirement or set
of requirements to fit a particular product or implmentation.  Thus, if
VeriSign's Class 1 service is not "PKIX-conformant", my response would
be to question why.  If it's because VeriSign has chosen not to meet a
requirement that this group deems useful, then that's too bad - VeriSign
loses.  If it's because we're imposing a requirement that's not really
important, okay, I could see deleting the requirement, but I don't
believe that that's the case.

As for

>(A "national"
> ie governmental CA service to residents also suddenly
> became non-conforming last week, also, because
> of other subtle tweaks)

okay, I'll bite.  I'll assume that you're alluding to ACES here, since
that's the only major "national" program that fits your description.  I
know how ACES policy says that information in certs is to be verified -
it's done indirectly, using existing Government databases to provide
verification of data to the approved CAs.  However, I'm confused, since
(a) VeriSign's class 1 service was never and will never be "good enough"
for ACES; and (b) I'm not sure what tweaks killed any existing PKIX
conformance for the ACES vendors.  (BTW:  did just one ACES vendor
become non-conformant, or all three of them?)

And if there's something else you're talking about here, please be less
obtuse.  Be specific, even.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08851 for <[e-mail]>; Tue, 30 May 2000 08:03:39 -0700 (PDT)
Received: from [128.33.238.120] (TC120.BBN.COM [128.33.238.120]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id LAA21562; Tue, 30 May 2000 11:10:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220803b5594e23273e@[192.168.1.151]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>	 <[e-mail]> <[e-mail]> <v04220806b554462eec3e@[128.33.238.95]> <[e-mail]>
Date: Tue, 30 May 2000 11:04:53 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

I agree with your analysis of where to put which text.  In fact, I 
think an early message from me on this topic acknowledged that since 
the text in question was only present in the Subject alt name 
section, that the broader attribute verification issue might better 
be addressed elsewhere, but that got lost along the way. Sorry.

So, let's make the alt name text match the base attribute text, as 
you suggest. I am happy with your proposed rewording for this text.

Separately, I'd like to insert a comment re verification of all 
attributes contained in a certificate. Again, I am happy with your 
wording, and the suggested placement of the text in 4.1.1.1.

Thanks for the response,

Steve


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08766 for <[e-mail]>; Tue, 30 May 2000 08:03:05 -0700 (PDT)
Received: from [128.33.238.120] (TC120.BBN.COM [128.33.238.120]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id LAA21489; Tue, 30 May 2000 11:10:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220801b5594a333a29@[192.168.1.151]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 30 May 2000 11:04:53 -0400
To: Bruno Salgueiro <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bruno,

it is worth noting that TTPs, like you company, are not the only 
types of CAs, and thus not the only focus of these standards. 
Organizational and geopolitical CAs are of interest too.  Such CAs 
have the advantage of being authoritative for the data they put into 
certs, if they limit themselves to what they really know.  A problem 
faced by TTPs, who are generally authoritative for no data, is how to 
make the financial tradeoff you allude to.  Maybe this is another 
reason not to favor PKI models based on TTPs :-).

Steve


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08418 for <[e-mail]>; Tue, 30 May 2000 07:55:22 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <LS0CRVBC>; Tue, 30 May 2000 07:57:48 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Tue, 30 May 2000 07:57:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

The mandatory operational policy element 
that was advocated by one co-chair based
off of your suggestion is potentially
very damaging to the current Internet PKI,
as we who built what individual users can 
use, know it.  Please reconsider your text, given
how others may apply it, carefully.

Based on Al's and Steve's replies
to my deliberately contentious policy
scenario, we can now apply the interpretive 
principles established as community standards. That
exercise showed clearly that naming verification
policy is not only now mandatory on PKIX CAs, but
which policies are conforming is determined by PKIX.
The conformance testing procedure is unspecified 
in the text, but none the less it evidently
exists - as a subjective process. 

Lets apply 
the principles to VeriSign's branded services, to 
see the ramifications.

Some or all of VeriSign's Class 1 offering
of its Public Certification Service(s) is/are 
apparently no longer PKIX-conforming, if one applies
the conformance principles now proposed by Steve. It
was conforming, last week. (A "national"
ie governmental CA service to residents also suddenly 
became non-conforming last week, also, because
of other subtle tweaks)

Goto a formal certificate repository
https://digitalid.verisign.com/services/client/index.html
and perform the instructions. Type in
[e-mail], and see (apparently)
that a certificate is recorded, with "pending"
status. The common name is "No Such Agency"
and an unverified email address exists
in the name form selected by VeriSign.

To be fair to VeriSign, I have not completed
all procedures. To complete, someone
must send a challenge-response pin sent
to [e-mail] to VeriSign to
verify that such email account-name exists.
(This is apparently a non-conforming 
verification event.)

The resulting  certificate binds one legally 
to certain digital signatures, according
to the governing policy.

VeriSign PCS's Class 1 Service is apparently
(suddenly) no longer conforming with PKIX, under
any interpretion of the new mandatory
policy language concerning name field
verification

This seems an excessive impact of your 
suggestion. I, as one of its co-designers, would 
like to include VeriSign PCS's current Class 1 
offering within the PKIX family of conforming CAs.

Peter.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Tuesday, May 30, 2000 1:31 AM
To: Stephen Kent
Cc: [e-mail]
Subject: Re: SubjectAltName verification


Steve,

It took me longer to respond to your message because you did not
included my message in your response. :-(

Several comments to your E-mail:

The place where we intend to have the text is section 4.2.1.7. which
is only related to the subject
alternative name. Hence it is not the right place to cover other
topics.

Maybe I misread the text while reading the sentence "definitively
bound" and I guess this hides a much bigger issue here. :-(

In RFC 2459, section 4.1.2.6  Subject, we currently have:

   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN). The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name
field. A
   CA may issue more than one certificate with the same DN to the
same
   subject entity.

Let us suppose that we use an *empty* distinguished name (which is
allowed by the standard). Should the above property also apply to
the alternative name ? I would think so and I understood 
"definitively bound" as equivalent to "unique". In other words the
subject Alternative name once assigned must never be re-assigned for
a different entity by the CA. To this respect, the other fields that
where mentioned are not "definitively bound". So you now understand
the rational of the change that was made.

If we want to fix this, I propose that we do the fixing in the
appropriate sections.

For the subject alternative name (section 4.1.2.6) I would propose
the following: 

The subject alternative name MUST be unique for each subject 
entity certified by the one CA as defined by the issuer name 
field. The CA MUST verify (directly or indirectly) all subject 
alternative names. The precise nature of the verifications 
is detailed in the certificate policies and/or the CPSs."

Somewhere else we could have a general statement to cover the point
that all fields MUST be verified. This could be, for example, at the
end of section 4.1.1.1. which would look like:

4.1.1.1  tbsCertificate

 The field contains the names of the subject and issuer, a public
key
 associated with the subject, a validity period, and other
associated
 information.  The fields are described in detail in section 4.1.2;
 the tbscertificate may also include extensions which are described
in
 section 4.2. 

 The CA MUST verify (directly or indirectly) all the fields
contained
 in this field. The precise nature of the verifications is detailed 
 in the certificate policies and/or the CPSs.

Denis

Note: At the end of this E-mail, you will find my original message.
  
 
> Denis,
> 
> The latter part of your message gets at the contentious point in this
> discussion.
> 
> Some of us believe that ALL data in a certificate is definitively
> bound to the public key.  After much debate the WG rejected the
> notion of marking data in a cert as non-verified.  So, the current
> posture is that the EXTENT to which data is verified is a matter of
> CA policy, but the basic notion is that the CA has verified all of
> the data.
> 
> Warwick gave some examples that he felt supported the notion that not
> all certificate data is verified, but my response argued that these
> examples were either not a violation of the verification notion
> (e.g., OUs), or were anomalous (pseudonyms).
> 
> So, while I agree with your suggestions re pluralizing the references
> in the cited text, I don't agree with the suggestion to limit the
> scope of the comment to just the subject alternate name.
> 
> Steve


ORIGINAL MESSAGE:

Paul and others,

Some major details: 

1) I would propose to add an "s" to "certificate policy" making it
"certificate policies".

In RFC 2459 we have:

4.2.1.5  Certificate Policies

The certificate policies extension contains a sequence of one or
more policy information terms, each of which consists of an 
object identifier (OID) and optional qualifiers. 

2) In the same way, I would add an "s" to "CPS" making it "CPSs".

3) Finally, since the verification is not uniform, I would also add
an "s" to "verification".

The final sentence would thus look like:

"The precise nature of the verifications is detailed in the
certificate policies and/or the CPSs."

4) ... and a comment on the use of "definitively":

We were looking for text replacement related only to the subject
alternative name section 4.2.1.7. Now the sentence has been extended
to cover parameters like "all other fields in a certificate" and
"all certificate extensions". So "definitively" also applies to them
now, and this is wrong.

I would thus propose to delete the sentence "like all other fields
in a certificate and all certificate extensions," and thus keep the
idea  from RFC 2459, where only the subject alternative name is
considered to be definitiviely bound to the public key, which was:

   Because the subject alternative name is considered to be
   definitiviely bound to the public key, all parts of the subject
   alternative name MUST be verified by the CA.

The new text would thus look like:

Denis> "The subject alternative name is considered to
Denis> be definitively bound to the public key. Thus the CA MUST
Denis> verify (directly or indirectly) all subject alternative
Denis> names. The precise nature of the verifications is detailed
Denis> in the certificate policies and/or the CPSs."

Denis


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08099 for <[e-mail]>; Tue, 30 May 2000 07:51:42 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA18154; Tue, 30 May 2000 16:58:34 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 30 May 2000 16:58:34 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA29758; Tue, 30 May 2000 16:58:32 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA05468; Tue, 30 May 2000 16:58:32 +0200 (MET DST)
Date: Tue, 30 May 2000 16:58:32 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol
Cc: [e-mail]

> 
> François,
> 
> Sorry for the delay to answer, but the trafic is currently rather
> heavy on the TSP document and it takes time to prepare answers.
> 
> I do not agree to make the nonce mandatory since there exists cases
> where it is not needed. I also do not think that the case of a
> subverted TSA falls under the topic of "deliberate replay". 
I would even say that I rarely see a case where a client would
really need to use a nonce to avoid whatever kind of replay.

A replay of a response WITH THE SAME HASH is most likely a good
thing for the client. 

What is actually missing is an output nonce from the TSA in order
to avoid known plain text attacks in case when the results are
otherwise predictable. I would suggest to change the text
about the nonce in the following way: 

  The Nonce in the response MUST contain a possible Nonce of the
  request as a prefix. By this, the TSA can add an ouput Nonce
  in order to avoid known-plain text attacks, as well as it gives
  the possibility to front-end proxies to append data to the
  request Nonce when concentrating requests from many requesters
  in such a way that duplicates and replays can be avoided.  
  
> 
> However, in order to address your concern, I could add the following
> text in the security consideration section :
> 
> Inadvertent or deliberate replays for requests incorporating the
> same hash (algorithm and) value may happen. Inadvertent replays
> occur when more than one copy of the same request message gets sent
> to the TSA because of problems in the intervening network elements.
So, where is the problem? 

> Deliberate replays occur when a middleman is replaying legitimate TS
> responses. In order to detect these situations, several techniques
> may be used. Using a nonce always allows to detect replays, and
> hence its use is RECOMMENDED. Another possibility is to use both a
Why recommended? I would like to get a replay to have a proof of
an earlier time.

> local clock and a moving time window during which the requester
> remembers all the hashes sent during that time window. When
> receiving a response, the requester makes sure that both the time of
> the response is within the time window and that there is only once
> the hash value in that time window. If there is the same hash value
> more than once, the requester may either use a nonce, or wait until
> the time window has moved to come back to the previous case where
> the same hash value appears only once during that time window.

If there is the same hash value twice, the requester can just the
previous time stamp, why should one go to the TSA in this case? 



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07503 for <[e-mail]>; Tue, 30 May 2000 07:33:30 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA17826; Tue, 30 May 2000 16:40:39 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 30 May 2000 16:40:40 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA29639; Tue, 30 May 2000 16:40:34 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA05465; Tue, 30 May 2000 16:40:34 +0200 (MET DST)
Date: Tue, 30 May 2000 16:40:34 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]

> 
> 1) Time Stamp Token ordering can be done in most cases (see above)
> by only using GenTime and accuracy.

A litte flame about accuracy: 
  A user that wants to get a time stamp in order not to miss a deadline
  goes to a TSA: The TSA tells, well it is 23h59'59" but maybe not, since
  we are not sure whether we have the right time, it may already be well
  2 seconds later or earlier, well, that's what we think, or almost.

  What kind of decision can you make based on that?
  What would be the harm if the TSA would simply adjust the time
  to the lower end of the interval, and generate no accuracy.
  If there is an application that requires to get the earlimost
  stamp just after midnight, and you are too early, you just repeat.

  Comparison between two time stamps of the same tsa can be done
  without using the accuracy; if the genTime is different, then there
  they are ordered by authority of the TSA. 

> 2) serialNumber is not *necessary*, but may be *useful*. So let us
> keep it.
That's a strange reasoning. Just because something may be useful, doesn't
mean that it MUST be supported. But actually that's not the problem:

You did not really address the proposals about how to generate
unique numbers, or in which scope they need to be unique.

- as it is now, the number has to be unique during the whole lifetime
  of the TSA.
(1)  "the time stamp token number xxx

- it was proposed to solve this unique identification requirement by
  either
  - a combination of some serialnumber that can make round trips
    AND the genTime value. 
(2)    "The time stamp token number xxx issued at genTime" 
  - or simply by using arbitrarily trailing things at genTime 
(3)    "The time stamp issued at genTime". 

If you have any of these UNIQUE identifications, you can most likely
transform this into an order, if you you allocate the 'numbers' 
not in a completely unorderable way, unlikely, since you would need to
avoid collisions by other means than 'hierachical counting'.

Personally I have a tendancy to like the idea of the genTime+serialnumber
approach (2) for unique identification, and leave it up to the TSA how
to reuse or not the serialnumber, but I am also happy with the text
as it stands since 3 years. 

> 3) the BOOLEAN indicator "ordering" is useful to allow to address
> two segment needs, and does not place design constraints when no
> ordering within the second range is needed.

How would an application decide in advance whether it could use
a time stamping authority, if there is a requirement to compare
time stamps. 

Would a TSA always either set the indicator in all certs or never,
or could it decide from stamp to stamp. (probably it's always on or off).


Some purists may also see a need for a third service possible 
without genTime, and just an serialNumber to establish an order, but
then I wouldn't call the service 'time' stamping . 



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06957 for <[e-mail]>; Tue, 30 May 2000 07:14:30 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA28816; Tue, 30 May 2000 16:22:00 +0200
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 16:22:01 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: [e-mail]
Subject: Re: Requirements for remote path processing services
References: <p04320307b550772f168c@[165.227.249.13]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul,

Thank you for posting the requirements. In general I do not find the
document precise enough, so that we can make sure we really agree on
the goals. There are too many variants possible and I would have
prefer to have identified the various functions that would be
offered and the various parameters that would been sent and
received, of course, at a broad level.

There are several duplications of text and ideas and a more concise
document would be more appropriate. However, this is better than the
previous situation. :-)

> After the discussion in Adelaide, a group of us got together to hammer
> out what we consider requirements for remote path processing services.
> The general consensus of that group follows. The group who came to
> agreement that these are in fact a good statement of requirements
> include:
> 
> Ambarish Malpani, ValiCert
> Carlisle Adams, Entrust
> Michael Myers, VeriSign
> Michael Zolotarev, Baltimore
> Paul Hoffman, IMC & VPNC
> Peter Sylvester, EdelWeb
> Stephen Farrell, Baltimore
> Stephen Kent, BBN
> 
> 1. Requirements for remote path processing services

It would be important to say upfront against "what" a path may be
validated. I see two options :

1) against a security policy defined by an OID,
2) against multiple roots, Certification Policy constraints and
naming constraints.

> Remote path processing provides two primary services: delegated path
> construction for client-based path validation, and delegated path
> validation. Not all clients require both services in all scenarios. Many
> clients require only delegated path construction (including path
> discovery) to help them perform their own path validation, while other
> clients have requirements for offloaded path validation and have no need
> for data acquisition.
> 
> The delegated path construction features of remote path processing are
> valuable for clients that do much of the PKI processing themselves and
> simply want a server to collect information for them. 

Does this means :

1) collect all ?
2) collect only the certification chain ?
3) collect the certification chain and the associated revocation
information ?
   When revocation information is requested, does this mean:
       a) anything ?
       b) CRLs ? 
       c) OCSP responses ?  

  ... and is it for the leaf certificate only or for all the
elements of the chain ?

> The server need
> not even be trusted, because the client will ultimately perform path
> validation. Offloading path validation to a server may be required by a
> client that lacks the processing, and/or communication capabilities to
> perform path discovery and path validation. (Path discovery may not be
> required in all cases, e.g., some applications provide means for
> certification paths to be transmitted as part of the protocol.) Another
> motivation for offloading path validation is that it allows centralized
> management of validation policies in a consistent fashion across an
> enterprise.
> 
> A client that performs path validation for itself may still benefit in
> several ways from using a server to acquire certificates, CRLs, and OCSP
> responses to aid in the validation process. In this context, the client
> is relying on the server to interact with repositories to acquire the
> data that the client would otherwise have to acquire using LDAP, HTTP,
> and so on. Since these data items are digitally signed, the client need
> not trust the server to return the "right" data any more than the client
> would have to trust the repositories. There are several benefits to this
> approach; for example, a single query to a server can replace multiple
> queries to one or more directories and caching by the server can reduce
> latency. Another benefit to the client system is that it need not
> incorporate a diverse set of software to interact with various forms of
> repositories, perhaps via different protocols, nor to perform the graph
> processing necessary to discover paths, separate from making the queries
> to acquire path validation data.
> 
> A client whose networking and/or processing capabilities are limited may
> be unable to perform path validation itself. In this case, there must be
> a fully-trusted server to which the client can delegate path validation
> services. Such a server can take direction from the client about how

I would say : Such a server MUST take directions from the client
about how path validation should be done.
 
> path validation should be done (such as which roots are to be trusted),
> and the server can even provide to the client proof (e.g., certificates
> and CRLs or OCSP responses) of how the server validated the target
> certificate. 

Yes. It must be able to say whether or not the information shall be
returned.

> Even clients that are able to do their own path validation
> might instead rely on a trusted server to do path validation if the
> client is in an environment where centralized management of trusted
> roots or centralized management of non-standard policy processing is
> needed for some applications.

Good point.

> 1.1 Collecting path validation information
> 
> An untrusted server can provide a client the certificate path needed for
> path validation. It also can provide clients with revocation
> information, e.g., CRLs and OCSP responses, that the client can use to
> perform path validation. 

See the questions raised above about the granularity of the
information to be returned.

> These services can be valuable to client
> systems that do not include the protocols needed to find and download
> all of the intermediate certificates, CRLs, and OCSP responses needed
> for the client to perform complete path validation.
> 
> 1.2 Delegating path validation
> 
> A server can perform full certificate validation for the client. If a
> client uses this service, it inherently trusts the server as much as it
> would its own path validation software (if it contained such software).
> One reason that a client may want to delegate to such a server is that
> the client does not have sufficient processing or networking resources
> to perform path validation for each certificate it receives. In
> addition, because the algorithms required for path validation are
> complex, not all applications may embody high quality implementations of
> this processing. In constrained execution environments such as
> telephones and PDAs, memory and processing limitations may preclude
> implementation of complete, PKIX-compliant path validation.

Even if the validation is fully done by the server, I would still
like in that case that the information that has been used is
returned. It is not clear whether this is the case. See the
questions raised above about the granularity of the information to
be returned.
 
> In applications where minimum latency is critical, delegating validation
> to a trusted server can offer significant advantages. The time required
> to send the target certificate to the validation server, receive the
> response, and verify the signature on the response, can be considerably
> less than the time required by the client to perform path discovery and
> validation. Even if a certificate path were readily available to the
> client, the delay associated with processing the signatures for each
> certificate in the path might (under some circumstances such as very
> long paths or very limited processor speed) be greater than the delay
> associated with use of a validation server.

A basic question that is not answered is the following: Does the
client want to take advantage of the signed response and make the
server liable in case of an error ? If this is the case, then the
response MUST contain the criteria against which the validation has
been performed by the server, otherwise this is not necessary. 

 
> 1.3 Centralized trust and policy
> 
> Organizations that impose a centralized management discipline usually
> want consistent policy enforcement across all clients in particular
> scenarios. In such cases, allowing a client to manage its own set of
> trusted roots or the policies that it accepts during path validation is
> unacceptable. A trusted server can enforce particular policy decisions
> while performing path validation. Also, experience shows that it is
> difficult to manage software configuration on end systems in a corporate
> environment.

The case of a client working with a single (or a small set of)
policy is not our scope and so the protocol should be able to handle
multiple validation schemes at the same time. If a server decides to
support one and only one policy, that's fine, but this should not be
visible at the level of the protocol. So I wonder why this section
has been added, because it should not change anything in the design
of the protocol. I probably missed something. :-)

> Because path validation software is controlled by many parameters which,
> if incorrectly set, may result in insecure behavior, it is often
> important to be able to centralize path validation in a single or small
> set of servers, where system security administrators can carefully
> manage them. Both services (delegated path construction and delegated
> path validation) can be potentially used by the enterprise for enforcing
> various aspects of centralized policy.

Well, requesters might "forget" to correctly use the result of the
server, so enforcement of the policy might be a dream in some cases.
:-)

Denis

> Note that it is not clear which aspects of PKI policy can, in general,
> be usefully separated from other application specific policy using this
> approach. This is a matter for further study.
> 
> --Paul Hoffman, Director
> --VPN Consortium


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26923 for <[e-mail]>; Tue, 30 May 2000 03:01:24 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA18206; Tue, 30 May 2000 12:08:54 +0200
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 12:08:56 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

François,

Sorry for the delay to answer, but the trafic is currently rather
heavy on the TSP document and it takes time to prepare answers.

I do not agree to make the nonce mandatory since there exists cases
where it is not needed. I also do not think that the case of a
subverted TSA falls under the topic of "deliberate replay". 

However, in order to address your concern, I could add the following
text in the security consideration section :

Inadvertent or deliberate replays for requests incorporating the
same hash (algorithm and) value may happen. Inadvertent replays
occur when more than one copy of the same request message gets sent
to the TSA because of problems in the intervening network elements.
Deliberate replays occur when a middleman is replaying legitimate TS
responses. In order to detect these situations, several techniques
may be used. Using a nonce always allows to detect replays, and
hence its use is RECOMMENDED. Another possibility is to use both a
local clock and a moving time window during which the requester
remembers all the hashes sent during that time window. When
receiving a response, the requester makes sure that both the time of
the response is within the time window and that there is only once
the hash value in that time window. If there is the same hash value
more than once, the requester may either use a nonce, or wait until
the time window has moved to come back to the previous case where
the same hash value appears only once during that time window.

If you prefer a different wording, please provide the amended text.

Denis

> Denis,
> 
> We probably need to be clear on the requirement and then we can be sure that
> the text in the document reflects the requirement.
> 
> You seem quite clear that the requirement is to prevent replays - but we
> need to be clear on whether we are trying to detect and/or prevent
> deliberate or inadvertent replay or both.  Inadvertent replay could occur
> when more than one copy of a request message gets sent to the TSA because of
> problems in the intervening network elements.  In this case the TSA because
> of its "no look" policy would just blindly generate time stamps for each of
> the copies it receives.  Deliberate replay, on the other hand, assumes that
> the TSA has been subverted or its signing key has been compromised, or that
> a middleman is replaying legitimate TS responses.  Each of the various
> potential replays needs to be considered to ensure that the protocol
> protects against it.
> 
> 1. Deliberate middleman replay.  Since each response contains a signed TS
> Token which includes the message imprint, serial number and time, this type
> of attack is easily detected within the currently proposed protocol.
> 
> 2. Replay by subverted TSA.  A subverted TSA could generate any number of TS
> Tokens containing the same message imprint at any time.  Because each could
> have different serial number and/or time, each would be unique and there is
> no way the client could detect a replay on the basis of the response.  The
> only way this could be detected would be for every request to include a
> nonce and for the client to maintain a record of all nonces generated to
> verify against the responses.
> 
> 3. Inadvertent replay.  Again, the only way for the client to distinguish
> this type of replay would be through the use of a nonce. In this case,
> however, it should not be necessary to maintain a record of all nonces
> generated but only those generated within a time window as you suggest. If
> the window length is set to, for example, twice the expected delay between
> request and response, the client could be quite confident that there have
> been no inadvertent replays if no duplicate nonce values are detected.
> 
> To summarize, the nonce should not be an optional component of replay
> detection (as suggested by the current wording) - it is necessary if the
> client is trying to protect against anything other than deliberate middleman
> replays.
> 
> It is suggested that the wording in the fourth sentence of the second
> paragraph of Section 2.2 (page 3) be changed to:
> 
> "It SHALL then verify the value of the nonce (large random number with high
> probability that is generated by the client only once) included in the
> response against the nonce value included in the corresponding request to
> ensure that no replay has occurred."
> 
> In Section 2.4.1 remove the OPTIONAL qualifier from nonce in the definition
> of TimeStampReq (page 4).
> 
> Change the wording of first sentence of the nonce description in Section
> 2.4.1 (page 5)to read:
> 
> "The nonce allows the client to verify the response against replay."
> 
> In Section 2.4.2 remove the OPTIONAL qualifier from nonce in the definition
> of TSTInfo (page 7).
> 
> Change the wording of the nonce description in Section 2.4.2 (page 5)to
> read:
> 
> "The nonce field MUST be equal to the value provided in the TimeStampReq
> structure."
> 
> If you agree with this approach, then I would suggest we prepare a short
> annex to describe the two different cases - subverted TSA vice inadvertent
> replay.
> 
> Have a good weekend!
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, May 24, 2000 5:36 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Rationale for Nonce in Time Stamp Protocol
> 
> Francois,
> 
> I realized that I ommited to reply to your E-mail.
> 
> > Salut Denis,
> >
> > I do not remember if this issue was raised before, but in Section 2.2 the
> > following statement is made:
> >
> > "the requesting entity .... SHALL then verify the timeliness of the
> response
> > by verifying either the time included in the response against a local
> > trusted time reference, if one is available, and/or the value of the nonce
> > (large random number with a high probability that it is generated by the
> > client only once) included in the response against the value included in
> the
> > request."
> >
> > A nonce is normally used to detect attempts at replays, which is not
> > necessarily related to the timeliness of the response to a particular
> > request as mentioned here.
> >
> > The first part of the statement talks about verifying the time included in
> > the response against a locally trusted time source.  This could used to
> > measure round trip path delay for calibration purposes,
> 
> No. This is not the goal. The goal is to make sure that you have no
> replay, in particular on the same hash value.
> 
> > but unless one could
> > be certain that the locally trusted source is as accurate as the TSA time
> > source (or, at least, that the difference between them is fixed and
> > well-known), I don't see how it would detect/prevent replays.
> 
> Using a moving time window the caller remembers all the hashes he
> sent during that time window.
> If there is not the same hash value within that time window, then he
> makes sure that the time of the response is within the time window.
> If there is the same hash (a very rare situation), it is a little
> bit more complicated, and there are several options. Among them:
> using the nonce, or waiting until the time window has moved to come
> back to the previous case: only one hash value during that time
> window. But we are talking implementations details, which is not the
> topic of an RFC.
> 
> >  If one has
> > such a trusted time source locally, what is the point in using a TTP for
> > time stamping?
> 
> The time is locally trusted, ... which does not mean that other
> people will trust that time.
> 
> >
> > Could you please clarify the intent of this statement and if the intent is
> > to prevent replays or check the timeliness of responses or both?
> 
> Now, that you have the explanations, if you still believe that the
> text is not clear enough, I suggest that you submit a proposal to
> clarify the text.
> 
> Regards,
> 
> Denis
> 
> >
> > Francois
> > ___________________________________
> > Francois Rousseau
> > Director of Standards and Conformance
> > Chrysalis-ITS
> > 1688 Woodward Drive
> > Ottawa, Ontario, CANADA, K2C 3R7
> > [e-mail]      Tel. [phone] ext. 419
> > http://www.chrysalis-its.com     Fax. [phone]


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA23485 for <[e-mail]>; Tue, 30 May 2000 02:17:49 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA32336; Tue, 30 May 2000 11:24:53 +0200
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 11:24:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James,

Thanks for the shortest "simple and complete" message. I picked it
to answer to all the recent messages posted on that topic. 
 
> TSA clients must support genTime values with fraction-of-second components,
> e.g "20000529053138.345Z".  Consequently, by using sufficient
> fraction-of-seconds digits, it is easy for a TSA to issue genTime values
> that always increase and never repeat.
> 
> * The TSA does not need to maintain another never-repeating value
> (serialNumber) and does not have to worry about maintaining it when the TSA
> server crashes.

Correct. This a very important argument. So if we maintain that
field it is *only* to uniquely identify the TST. Now, let us answer
to the question raised: whether that field is NECESSARY. This field
is not *necessary*. It MAY be *useful*. Yes, it usually makes sense
to associate the Time Stamp with the data it applies to. However, it
MAY or MIGHT be useful to be able to reference a Time Stamp that is
stored somewhere else.

> * The TSA does not need to issue (nor the client expect) huge integer
> values.

> * Ordering two timestamps from one TSA is simply achieved by comparing their
> genTime fields.

Correct, this can ALWAYS been achieved  ... if we have the following
property:
| genTime 1 - GenTime 2 | > Accuracy of GenTime 1 + Accuracy of
GenTime 2

In the above equation > means stricly superior.

Now, when this condition does NOT apply, the BOOLEAN indicator
"ordering" allows to say whether ordering two timestamps from one
TSA can or cannot be achieved by comparing their genTime fields.

In the case a huge server doing parallel queuing and using parallel
crypto engines that this property is not that easy to maintain.
Allowing to perform an ordering in *any* case (i.e. in time frames
less than the second) is not needed by many applications, hence the
reason to place low contraints on the design, unless this property
is really needed.

Now, about the last received comment from Ed Gerck, the above
distinction gives a reliability of 100% if we have: | genTime 1 -
GenTime 2 | > Accuracy of GenTime 1 + Accuracy of GenTime 2 and when
that condition does not apply, either a reliability of 100% if the
the BOOLEAN indicator "ordering" is set to TRUE and a reliability of
0% if the the BOOLEAN indicator "ordering" is set to FALSE.

> * Accuracy (uncertainty with respect to UTC) is not affected as it is
> conveyed in a separate field.
> 
> Simple.  Complete.
> 
> The only issue is whether the ordering works from timestamps with the same
> TSA name or same TSA signing key.

It works, as indicated above, with the same TSA name.

As a conclusion:

1) Time Stamp Token ordering can be done in most cases (see above)
by only using GenTime and accuracy.
2) serialNumber is not *necessary*, but may be *useful*. So let us
keep it.
3) the BOOLEAN indicator "ordering" is useful to allow to address
two segment needs, and does not place design constraints when no
ordering within the second range is needed.


Denis


Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA22296 for <[e-mail]>; Tue, 30 May 2000 01:40:54 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Tue, 30 May 2000 09:47:48 +0100
Received: from taalap (taa-lap.sse.ie [193.120.32.86]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id JAA11173; Tue, 30 May 2000 09:47:35 +0100 (BST)
Message-ID: <006901bfca13$a6951240$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Requirements for remote path processing services
Date: Tue, 30 May 2000 09:47:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

Hi Ambarish,

thanks for the prompt reply.

I can identify two distinct stages in the use of ACs for making an access
decision:

1) Verify/validate the AC in accordance with system trust policy.
2) Extract the attributes and make an access decision based on the
     "required" attributes, versus the attributes encoded in the AC.

Whilst delegating task (1) to RPPS is fine by me, I see task (2) as more of
a "local" action that would be made at the location of the resource/action
being requested. Hence, delegating this decision to a centralised server
seems like an unnecessary offload of the access decision. Whilst I can see
this working in the specific case where the access control rules for an
entire domain are defined centrally, I can't see this working for the
general case.

Another point to note is that ACs are not limited to more than just
authorisation and access control services. By separating the access decision
process from the underlying privilege representation (i.e. ACs), we are not
limiting RPPS to verifying ACs for authorisation purposes. Instead, we can
use RPPS solely for the validation of ACs, meaning that the client can then
extract the attributes and use them in local processing (for access control
purposes or otherwise).


Regards,

Andy






Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA21845 for <[e-mail]>; Tue, 30 May 2000 01:26:09 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA05166; Tue, 30 May 2000 10:30:30 +0200
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 10:30:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <[e-mail]> <[e-mail]> <v04220806b554462eec3e@[128.33.238.95]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

It took me longer to respond to your message because you did not
included my message in your response. :-(

Several comments to your E-mail:

The place where we intend to have the text is section 4.2.1.7. which
is only related to the subject
alternative name. Hence it is not the right place to cover other
topics.

Maybe I misread the text while reading the sentence "definitively
bound" and I guess this hides a much bigger issue here. :-(

In RFC 2459, section 4.1.2.6  Subject, we currently have:

   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN). The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name
field. A
   CA may issue more than one certificate with the same DN to the
same
   subject entity.

Let us suppose that we use an *empty* distinguished name (which is
allowed by the standard). Should the above property also apply to
the alternative name ? I would think so and I understood 
"definitively bound" as equivalent to "unique". In other words the
subject Alternative name once assigned must never be re-assigned for
a different entity by the CA. To this respect, the other fields that
where mentioned are not "definitively bound". So you now understand
the rational of the change that was made.

If we want to fix this, I propose that we do the fixing in the
appropriate sections.

For the subject alternative name (section 4.1.2.6) I would propose
the following: 

The subject alternative name MUST be unique for each subject 
entity certified by the one CA as defined by the issuer name 
field. The CA MUST verify (directly or indirectly) all subject 
alternative names. The precise nature of the verifications 
is detailed in the certificate policies and/or the CPSs."

Somewhere else we could have a general statement to cover the point
that all fields MUST be verified. This could be, for example, at the
end of section 4.1.1.1. which would look like:

4.1.1.1  tbsCertificate

 The field contains the names of the subject and issuer, a public
key
 associated with the subject, a validity period, and other
associated
 information.  The fields are described in detail in section 4.1.2;
 the tbscertificate may also include extensions which are described
in
 section 4.2. 

 The CA MUST verify (directly or indirectly) all the fields
contained
 in this field. The precise nature of the verifications is detailed 
 in the certificate policies and/or the CPSs.

Denis

Note: At the end of this E-mail, you will find my original message.
  
 
> Denis,
> 
> The latter part of your message gets at the contentious point in this
> discussion.
> 
> Some of us believe that ALL data in a certificate is definitively
> bound to the public key.  After much debate the WG rejected the
> notion of marking data in a cert as non-verified.  So, the current
> posture is that the EXTENT to which data is verified is a matter of
> CA policy, but the basic notion is that the CA has verified all of
> the data.
> 
> Warwick gave some examples that he felt supported the notion that not
> all certificate data is verified, but my response argued that these
> examples were either not a violation of the verification notion
> (e.g., OUs), or were anomalous (pseudonyms).
> 
> So, while I agree with your suggestions re pluralizing the references
> in the cited text, I don't agree with the suggestion to limit the
> scope of the comment to just the subject alternate name.
> 
> Steve


ORIGINAL MESSAGE:

Paul and others,

Some major details: 

1) I would propose to add an "s" to "certificate policy" making it
"certificate policies".

In RFC 2459 we have:

4.2.1.5  Certificate Policies

The certificate policies extension contains a sequence of one or
more policy information terms, each of which consists of an 
object identifier (OID) and optional qualifiers. 

2) In the same way, I would add an "s" to "CPS" making it "CPSs".

3) Finally, since the verification is not uniform, I would also add
an "s" to "verification".

The final sentence would thus look like:

"The precise nature of the verifications is detailed in the
certificate policies and/or the CPSs."

4) ... and a comment on the use of "definitively":

We were looking for text replacement related only to the subject
alternative name section 4.2.1.7. Now the sentence has been extended
to cover parameters like "all other fields in a certificate" and
"all certificate extensions". So "definitively" also applies to them
now, and this is wrong.

I would thus propose to delete the sentence "like all other fields
in a certificate and all certificate extensions," and thus keep the
idea  from RFC 2459, where only the subject alternative name is
considered to be definitiviely bound to the public key, which was:

   Because the subject alternative name is considered to be
   definitiviely bound to the public key, all parts of the subject
   alternative name MUST be verified by the CA.

The new text would thus look like:

Denis> "The subject alternative name is considered to
Denis> be definitively bound to the public key. Thus the CA MUST
Denis> verify (directly or indirectly) all subject alternative
Denis> names. The precise nature of the verifications is detailed
Denis> in the certificate policies and/or the CPSs."

Denis


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16440 for <[e-mail]>; Tue, 30 May 2000 00:03:39 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA16066; Tue, 30 May 2000 09:11:12 +0200
Message-ID: <[e-mail]>
Date: Tue, 30 May 2000 09:11:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Use cases for digital credentials
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Marco,

Take a look at ES 201733 "Electronic Signature Formats" in
particular section 8.12.3. The document is available at:

http://www.etsi.org/SEC/el-sign.htm

Denis 

> Dear all,
> 
> I am analysing a B2B scenario where employees working for different
> enterprises (which have no previous business relationships and are not
> member of any EDI VAN or extranet) need to interact together: for trust
> reasons they need to exchange digital credentials (identity certificates and
> *expecially* attribute certificates).
> 
> I wonder if you are aware of any document/paper describing use cases for
> digital credentials in such a B2B scenario. In particular I am interested in
> use cases and examples for attribute certificates.
> 
> Any link/reference is welcome.
> 
> Marco
> 
> P.S.: Apologies if this is not the right mailing list to ask for this kind
> of information
> 
> =========================================================================
>  Marco Casassa Mont
>  Trusted E-Services Laboratory               +++++++++++++++++++++++++++
>  Hewlett-Packard Laboratories                +++++++   _/        +++++++
>  Filton Road, Stoke Gifford                  +++++    _/           +++++
>  BRISTOL, BS34 8QZ, UK.                      ++++    _/_/_/  _/_/_/ ++++
>                                              +++    _/  _/  _/  _/   +++
>  Phone:  [phone] (direct)           ++++  _/  _/  _/_/_/   ++++
>  Telnet: 312 8794                            +++++        _/       +++++
>  Fax:    [phone]                    +++++++     _/      +++++++
>  Email:  [e-mail]           +++++++++++++++++++++++++++
> 
> =========================================================================
>     'All points of view are my own and not necessarily HP's as well'


Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA05288 for <[e-mail]>; Mon, 29 May 2000 12:44:25 -0700 (PDT)
Received: (qmail 25720 invoked from network); 29 May 2000 19:46:18 -0000
Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 29 May 2000 19:46:18 -0000
Message-ID: <[e-mail]>
Date: Mon, 29 May 2000 20:56:37 +0100
From: Bruno Salgueiro <[e-mail]>
Organization: SIBS
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: pt,en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1445816AA442E7D145F663F2"

This is a cryptographically signed message in MIME format.

--------------ms1445816AA442E7D145F663F2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi to all. I'm just a reader in this mailing list but this subject is
of great concern to our organisation (which is a TTP) so here are my 2
cents. Let me start to say that Al has touched a very important point
which I didn't see quite addressed yet.

The thing here that has a great influence in business is the ratio bet-
ween the verifying effort in certificate data and the risk that a CA
wants to have in its business. This ratio has to be improved by increa-
sing the verify effort and lessening the risk factor.

The problem I see in this discussion is that you are going to the limit
of "all or nothing" and this worries me and I hope all the listeners
that
play in the same field (or please tel me why I shouldn't!).

I would like to know how this discussion fits in the EU Directive on
digi-
tal signatures and the ETSI/EESSI efforts which will really influence
how
a certificate has legal quality. I would also like to see more PKI
business
players influencing standards (because if standards are to be used they
ha-
ve to be realistic) than just vendors (not trying to flame anyone,
please).

Besides this and despite the heat of this discussion I think that "both
sides"
are presenting high quality comments.

Best regards,

Ed Gerck wrote:
> 
> Al Arsenault wrote:
> 
> [snip]
> 
> > The presence of an "attribute" whose value has not been verified
> > - either directly or indirectly - by the CA is at best misleading, and
> > at worst openly harmful to the relying party.
> 
> Al:
> 
> I agree entirely with what you wrote above. The devil is -- what do we
> mean by "verifying"?  Of course, the word "verifying" must be understood
> according to both the PKIX standard AND the CA's CPS. This means that
> such certificates are essentially statements from a CA, not fact, and that
> meaning and trust on a certificate (like beauty) is in the eyes of the beholder,
> i.e., depends on each relying-party.
> 
> And certificates also contain fields which are not very intuitively defined or
> even coherent with their names, such as the Distinguished Name field, which
> is neither always distinguished nor necessarily contains the subject's name.
> And, the SerialNumber field, etc.  So, data fields themselves are not clear in
> *their* names -- more or less like a CA making no representation that the
> subject "Bill Clinton" of a certificate is the same "Bill Clinton" as the one
> you might be thinking of, but they put it in the cert anyway ;-)
> 
> Yes,  in legal reliance terms one may trust the confirmation procedures of the
> CA during certificate reliance, but one cannot rely upon them for other than
> their value as a representation of the CA's authentication management act
> expressed in the CA's own terms and rules -- therefore, a PKIX certificate is
> neither necessarily meaningful nor valid in a r-p's reference frame or for the
> r-p's purposes. To pretend otherwise is at best misleading and at worst openly
> naive.
> 
> To see a graphical birds's eye view of my comment, with a less terse treatment,
> the reader can visit the "unabridged inside view of a typical X.509 certificate"
> in http://www.mcg.org.br/x509cert.htm
> 
> Cheers,
> 
> Ed Gerck

-- 
=======================================================
Bruno Salgueiro       (mailto:[e-mail])
                   
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

Esta mensagem foi assinada com certificado MULTIcert.
Para obter o certificado da Autoridade de Certificação
PILOTO MULTIcert dirija-se ao site
            http://www.sibs.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================
--------------ms1445816AA442E7D145F663F2
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

MIIFCwYJKoZIhvcNAQcCoIIE/DCCBPgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A4owggOGMIIC76ADAgECAgQ3Ttp2MA0GCSqGSIb3DQEBBQUAMCgxCzAJBgNVBAYTAlBUMRkw
FwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0MB4XDTk5MDUzMTIzMzIzNFoXDTAwMDYwMTAwMDIz
NFowYTELMAkGA1UEBhMCUFQxGTAXBgNVBAoTEFBJTE9UTyBNVUxUSWNlcnQxDTALBgNVBAsT
BFNJQlMxDjAMBgNVBAsTBURTSVNUMRgwFgYDVQQDEw9CcnVubyBTYWxndWVpcm8wXDANBgkq
hkiG9w0BAQEFAANLADBIAkEAuVICquW4IcbOpM37DdyglXYa8AAdR6UWq2VFEFTUtY0colnZ
a9BQ0DvTRB8sO5XuFiTWFnVR5T94R5j5PjE0cwIDAQABo4IBxjCCAcIwCwYDVR0PBAQDAgWg
MCsGA1UdEAQkMCKADzE5OTkwNjAxMDAwMjM0WoEPMjAwMDAyMTIwNDAyMzRaMBEGCWCGSAGG
+EIBAQQEAwIFoDCBqQYJYIZIAYb4QgENBIGbFoGYQ2VydGlmaWNhZG8gUElMT1RPIE1VTFRJ
Y2VydC4gRXN0ZXMgY2VydGlmaWNhZG9zIHNhbyBlbWl0aWRvcyBhbyBhYnJpZ28gZG8gQ1BT
IHF1ZSBzZSBlbmNvbnRyYSBubyBzZWd1aW50ZSBVUkwgLSBodHRwczovL3d3dy5zaWJzLm11
bHRpY2VydC5jb20vY3BzLmh0bWwwFQYDVR0RBA4wDIEKYnNAc2licy5wdDBKBgNVHR8EQzBB
MD+gPaA7pDkwNzELMAkGA1UEBhMCUFQxGTAXBgNVBAoTEFBJTE9UTyBNVUxUSWNlcnQxDTAL
BgNVBAMTBENSTDEwHwYDVR0jBBgwFoAUuJYgbdZN8aJJDF13gU9LJAiiL+UwHQYDVR0OBBYE
FEsyR+XzLWwX2+4LDk6/lA+XyaZtMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjQu
MAMCA6gwDQYJKoZIhvcNAQEFBQADgYEAk1GfA3Mtu3ECWCz2SIxkVisgOxt9vDKdQNTevrus
an91qvmvoHAtJMAlAolegoiDpq73qdk+9JMODICE5zEXDIK9w2nCkqBheFwJs7frm/tVLnSv
H+vQ5/5EX3ARwqforMGtjf+BO8OuYoxRyydKx9xheeyhke9+xJCEnOA2wDwxggFJMIIBRQIB
ATAwMCgxCzAJBgNVBAYTAlBUMRkwFwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0AgQ3Ttp2MAkG
BSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MDAwNTI5MTk1NjM3WjAjBgkqhkiG9w0BCQQxFgQU1vIpKdFu0Yov5v1jEbDzLFRZDFMwUgYJ
KoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQIunyFFJVzhB8H12
ew7RhqQm/a4ZzVdoT0wpStKKKbAR7vRZt0UTMng6dwV1HPJdAPY7w00H7glsJlpORhfao0E=
--------------ms1445816AA442E7D145F663F2--



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04049 for <[e-mail]>; Mon, 29 May 2000 11:25:14 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <LS0CRTX5>; Mon, 29 May 2000 11:27:34 -0700
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Andy Dowling'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Requirements for remote path processing services
Date: Mon, 29 May 2000 11:27:33 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Andy,
    You could use the remote path processing server (RPPS) to verify
ACs, or even better, you could actually use it to authorize
certain user actions and avoid needing to deal with ACs at all!

In the case where you do trust the RPPS, the kind of query I expect
an application to send it, would be of the form:
"Can I trust this certificate to do the following action".

At that state, I would fully expect the RPPS to go out and figure
out what the attributes of the certificate are, so, as an
application, you can be completely relieved of the job of
processing ACs at all.

Does this make sense?
Regards,
Ambarish

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


> -----Original Message-----
> From: Andy Dowling [mailto:[e-mail]]
> Sent: Monday, May 29, 2000 4:02 AM
> To: Paul Hoffman
> Cc: [e-mail]
> Subject: Re: Requirements for remote path processing services
> 
> 
> Paul + co.,
> 
> Having read your post, I was just wondering if these remote 
> path processing
> services could be applied to ACs for authorisation purposes? I've put
> together a few points on the subject (see below).
> 
> Comments would be appreciated.
> 
> Regards,
> 
> Andy
> 
> 
> 
> 1) OVERVIEW
> 
> In addition to remote path processing services:
> 
> a) delegated path construction
> b) delegated path verification
> c) trust and policy centralisation
> 
> that apply to public key certificates, there may be scope for
> the application of these services to authorisation-related 
> certificates
> i.e. Attribute Certificates could be verified remotely by a single
> trusted entity, and this would bring the benefits of centralised
> trust/policy management and simpler clients.
> 
> 
> 2) MOTIVATION
> 
> Firstly, let's present some arguments *against* introducing remote AC
> validation:
> 
> a) The current profile for AC validation is relatively simpler than
>    that of PKC validation:
> 
>         a) AC chains are not used
>         b) AAControls is optional
>         c) AC revocation checking is optional
> 
>    Consequently, a very minimal (and conformant) AC validator can be
>    implemented and would be "lightweight" enough to provide 
> on clients.
> 
> b) AC validation for authorisation purposes is typically a server-side
>    operation anyway, and clients would hardly need to validate an AC.
> 
> 
> In response to argument (a):
> 
>      Whilst a client may indeed conform to the simplest 
> version of the AC
>      profile with a lightweight implementation, such an implementation
>      would have no control over which attributes can be 
> issued by which
>      authorities (AAControls), due to the lack of chain processing.
>      In addition, the client cannot safely validate long-lived ACs.
>      This is due to the lack of revocation processing.
> 
> In response to argument (b):
> 
>      Clients *may* need to validate ACs in the push model to
>      ensure the integrity of the AC before passing it on to other
>      servers. (Complications arise here when the AC is pushed to a
>      different "trust domain" where the AC validation policy differs
>      to that of the clients policy, so there's scope for 
> further study here)
> 
>      A client will need to validate an AC if it is used in 
> the making of
>      a client-side access decision. Scenarios in which a client-side
>      access decision would need to be made are:
> 
>             --> Checking the permissions of downloaded content:
>                 --> Has a piece of downloaded code have 
> execute permission
>                     from the system admin?
> 
>             --> Client-side content filtering:
>                  -> Checking if downloaded content has a 
> "rating" attribute
>                     (12, 15, 18, PG-13, NC-17, R, etc.)
> 
> 
> It is apparent that there is indeed a requirement for:
>        (a) clients to validate ACs
>        (b) AC validation to be performed "fully". That is, AAControls
>            and revocation checking should be done for 
> security reasons.
> 
> Given these requirements, it seems logical to migrate these 
> verification
> tasks to a dedicated AC validation server.
> 
> 
> 2) BENEFITS:
> 
> The benefits are the same as for remote PKC processing:
> 
> a) Centralised trust and policy for authorisation purposes
> 
>     (i)   Administrator(s) can say what AAs are trusted by 
> the enterprise
>     (ii)  Administrator(s) can implement complicated trust 
> management via
>                            AAControls and/or AC Chain validation
>     (iii) Administrator(s) can implement AC revocation checking
> 
> b) Simplified clients
>     (i)  No need for the client to implement any form of AC 
> verification,
>          path processing (for AAControls), LDAP/OCSP clients, etc.
> 
> c) Server-side caching to improve turnaround time on a 
> validation request
> 
> 
> 
> 
> 


Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03158 for <[e-mail]>; Mon, 29 May 2000 10:37:21 -0700 (PDT)
Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 12wTay-0002cY-00; Mon, 29 May 2000 17:44:56 +0000
Received: from [209.21.28.68] (helo=nma.com) by dfw-mmp1.email.verio.net with esmtp (Exim 3.12 #7) id 12wTav-0004ag-00; Mon, 29 May 2000 17:44:54 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 May 2000 10:45:05 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: applying detection theory, was Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------66835B78283B43348B514C00"

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



"Manger, James H" wrote:

>  The accuracy (I assume this is what you mean by "precision value")
> simply conveys the uncertainty of the genTime value with
> respect to UTC.
> ...
> Quoting many more digits than the accuracy warrants does not make
> it wrong.  In some situations (e.g. a physics article) it might be
> considered bad form because the extra digits are worthless (but
> still harmless), but in our situation they do have a use - to order
> timestamps.

We need to introduce the concept of "threshhold level" as well
as to use "accuracy" in standard engineering form, together with
"reliability." This will, I believe, clarify the discussion.

Before I present some ASCII graphs that will illustrate my points,
let me cut to some of the conclusions to be gained from those graphs:

1. Accuracy is not the uncertainty of a value -- which would be
reliability and depends on *many* events on average. Accuracy is the
spread of *one* event.  The accuracy and reliability of a  measurement
depend *also* on the threshhold level of measurement.

2. In the case where the measurement is the uniqueness (or, ordering) of
an *issued* timestamp, we can consider the following correspondence for
a series of timestamps issued by a TSA:

 accuracy = formal precision value of timestamp (set by the TSA for each
            event, independently of its actual time precision)

 reliability = uncertainty of timestamp in the series (on average, for
               that TSA and based on the timestamp value)

 threshhold level = the TSA's actual time precision.

We can easily see that as a function of these three values, a timestamp
may be accurate but unreliable, accurate and reliable, etc. -- generating
four cases (depicted below). The method that Manger mentions is correct
to provide uniqueness for the issued timestamps, because it garantees
reliability of 100% for a r-p to detect ordered timestamps -- by dynamically
changing the accuracy so that no value is repeated within that accuracy.
This should NOT be confused however with reliability of 100% to detect
different time events as measured *by* the TSA, NOR confused with a
reliability of 100% for the TSA to order different time events -- because
in this case we are not talking about measurement of what is issued by a
TSA (the cert) but measurement by the TSA itself. The treshhold level
affecting the TSA may produce aliasing and re-ordering that is
undistiguishable (ie, unmeasurable) by the TSA -- and thus, wrongly
reflected in the othwerwise correct but formally ordered certs. So,
there is a finite probability that a TSA may issue two or more ordered
timestamps that can be 100% reliably ordered by a r-p, but which actually
correspond to reverse or shuffled events in time.

IN OTHER WORDS: Do not try to extract from the data more than what the
data has -- and that is why in a physics essay it IS considered bad form
to imply more accuracy than one has.  It is OK however to format the
data so as to reflect the accuracy of what you can express (here, for the
usual purpose of ordering the data issued).  In physics papers this is
also useful (e.g. to reflect the instrument's precision) and is handled
by using the form (1.000456 +- 0.3), as an example.

RECOMMENDATION: besides the above, include a declaration of the TSA's
*overall* certified error for timestamping -- which defines its treshhold
level AND its actual event ordering reliability but does NOT influence its
ordering reliability per cert (which can be 100%, as above).

Now, the technical background from detection theory.

"Accuracy" and "reliability" are standard terminology in many engineering
disciplines and can be better understood by an example in terms of a
signal that varies in time and is detected when it crosses a given
threshhold level Eo, in four cases, for each of the logical possibilities
of combination:

1. high accuracy and high reliability:

signal

^
|
|     __
|     ||
|     ||
|Eo----------------------------
|     ||
|     ||
|     ||
|     ||  __
|     ||  ||
|     ||  ||
|     ||  ||
|-----  --  ----
-------------------------> time


2. high accuracy and low reliability

signal

^
|
|     __
|     ||  __
|     ||  ||
|Eo----------------------------
|     ||  ||
|     ||  ||
|     ||  ||
|     ||  ||
|     ||  ||
|     ||  ||
|     ||  ||
|-----  --  ----
-------------------------> time


3. low accuracy and high reliability:

signal

^
|
|     _____
|     |   |
|     |   |
|Eo----------------------------
|     |   |
|     |   |
|     |   |
|     |   |  _____
|     |   |  |   |
|     |   |  |   |
|     |   |  |   |
|-----     --     ----
-------------------------> time


4. low accuracy and low reliability

signal

^
|
|     _____
|     |   |  _____
|     |   |  |   |
|Eo----------------------------
|     |   |  |   |
|     |   |  |   |
|     |   |  |   |
|     |   |  |   |
|     |   |  |   |
|     |   |  |   |
|     |   |  |   |
|-----     --     ----
-------------------------> time



Cheers,

Ed Gerck

--------------66835B78283B43348B514C00
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt></tt>&nbsp;<tt></tt>
<p><tt>"Manger, James H" wrote:</tt>
<blockquote TYPE=CITE><tt>&nbsp;The accuracy (I assume this is what you
mean by "precision value")</tt>
<br><tt>simply conveys the uncertainty of the genTime value with</tt>
<br><tt>respect to UTC.</tt>
<br><tt>...<br>
Quoting many more digits than the accuracy warrants does not make</tt>
<br><tt>it wrong.&nbsp; In some situations (e.g. a physics article) it
might be</tt>
<br><tt>considered bad form because the extra digits are worthless (but</tt>
<br><tt>still harmless), but in our situation they do have a use - to order</tt>
<br><tt>timestamps.</tt></blockquote>
<tt>We need to introduce the concept of "threshhold level" as well</tt>
<br><tt>as to use "accuracy" in standard engineering form, together with</tt>
<br><tt>"reliability." This will, I believe, clarify the discussion.</tt><tt></tt>
<p><tt>Before I present some ASCII graphs that will illustrate my points,</tt>
<br><tt>let me cut to some of the conclusions to be gained from those graphs:</tt><tt></tt>
<p><tt>1. Accuracy is not the uncertainty of a value -- which would be</tt>
<br><tt>reliability and depends on *many* events on average. Accuracy is
the</tt>
<br><tt>spread of *one* event.&nbsp; The accuracy and reliability of a&nbsp;
measurement</tt>
<br><tt>depend *also* on the threshhold level of measurement.</tt><tt></tt>
<p><tt>2. In the case where the measurement is the uniqueness (or, ordering)
of</tt>
<br><tt>an *issued* timestamp, we can consider the following correspondence
for</tt>
<br><tt>a series of timestamps issued by a TSA:</tt><tt></tt>
<p><tt>&nbsp;accuracy = formal precision value of timestamp (set by the
TSA for each</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
event, independently of its actual time precision)</tt><tt></tt>
<p><tt>&nbsp;reliability = uncertainty of timestamp in the series (on average,
for</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
that TSA and based on the timestamp value)</tt><tt></tt>
<p><tt>&nbsp;threshhold level = the TSA's actual time precision.</tt><tt></tt>
<p><tt>We can easily see that as a function of these three values, a timestamp</tt>
<br><tt>may be accurate but unreliable, accurate and reliable, etc. --
generating</tt>
<br><tt>four cases (depicted below). The method that Manger mentions is
correct</tt>
<br><tt>to provide uniqueness for the issued timestamps, because it garantees</tt>
<br><tt>reliability of 100% for a r-p to detect ordered timestamps -- by
dynamically</tt>
<br><tt>changing the accuracy so that no value is repeated within that
accuracy.</tt>
<br><tt>This should NOT be confused however with reliability of 100% to
detect</tt>
<br><tt>different time events as measured *by* the TSA, NOR confused with
a</tt>
<br><tt>reliability of 100% for the TSA to order different time events
-- because</tt>
<br><tt>in this case we are not talking about measurement of what is issued
by a</tt>
<br><tt>TSA (the cert) but measurement by the TSA itself. The treshhold
level</tt>
<br><tt>affecting the TSA may produce aliasing and re-ordering that is</tt>
<br><tt>undistiguishable (ie, <u>unmeasurable</u>) by the TSA -- and thus,
wrongly</tt>
<br><tt>reflected in the othwerwise correct but formally ordered certs.
So,</tt>
<br><tt>there is a finite probability that a TSA may issue two or more
ordered</tt>
<br><tt>timestamps that can be 100% reliably ordered by a r-p, but which
actually</tt>
<br><tt>correspond to reverse or shuffled events in time.</tt><tt></tt>
<p><tt>IN OTHER WORDS: Do not try to extract from the data more than what
the</tt>
<br><tt>data has -- and that is why in a physics essay it IS considered
bad form</tt>
<br><tt>to imply more accuracy than one has.&nbsp; It is OK however to
format the</tt>
<br><tt>data so as to reflect the accuracy of what you can express (here,
for the</tt>
<br><tt>usual purpose of ordering the data issued).&nbsp; In physics papers
this is</tt>
<br><tt>also useful (e.g. to reflect the instrument's precision) and is
handled</tt>
<br><tt>by using the form (1.000456 +- 0.3), as an example.</tt><tt></tt>
<p><tt>RECOMMENDATION: besides the above, include a declaration of the
TSA's</tt>
<br><tt>*overall* certified error for timestamping -- which defines its
treshhold</tt>
<br><tt>level AND its actual event ordering reliability but does NOT influence
its</tt>
<br><tt>ordering reliability per cert (which can be 100%, as above).</tt><tt></tt>
<p><tt>Now, the technical background from detection theory.</tt><tt></tt>
<p><tt>"Accuracy" and "reliability" are standard terminology in many engineering</tt>
<br><tt>disciplines and can be better understood by an example in terms
of a</tt>
<br><tt>signal that varies in time and is detected when it crosses a given</tt>
<br><tt>threshhold level Eo, in four cases, for each of the logical possibilities</tt>
<br><tt>of combination:</tt><tt></tt>
<p><tt>1. high accuracy and high reliability:</tt><tt></tt>
<p><tt>signal</tt><tt></tt>
<p><tt>^</tt>
<br><tt>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; __</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||</tt>
<br><tt>|Eo----------------------------</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; __</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|-----&nbsp; --&nbsp; ----</tt>
<br><tt>-------------------------> time</tt>
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>2. high accuracy and low reliability</tt>
<br><tt>&nbsp;</tt>
<br><tt>signal</tt>
<br><tt>&nbsp;</tt>
<br><tt>^</tt>
<br><tt>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; __</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; __</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|Eo----------------------------</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; ||</tt>
<br><tt>|-----&nbsp; --&nbsp; ----</tt>
<br><tt>-------------------------> time</tt>
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>3. low accuracy and high reliability:</tt>
<br><tt>&nbsp;</tt>
<br><tt>signal</tt>
<br><tt>&nbsp;</tt>
<br><tt>^</tt>
<br><tt>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; _____</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|Eo----------------------------</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; _____</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|-----&nbsp;&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp;&nbsp; ----</tt>
<br><tt>-------------------------> time</tt>
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>4. low accuracy and low reliability</tt><tt></tt>
<p><tt>signal</tt><tt></tt>
<p><tt>^</tt>
<br><tt>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; _____</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; _____</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|Eo----------------------------</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; |</tt>
<br><tt>|-----&nbsp;&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp;&nbsp; ----</tt>
<br><tt>-------------------------> time</tt>
<br><tt></tt>&nbsp;
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>Cheers,</tt><tt></tt>
<p><tt>Ed Gerck</tt></html>

--------------66835B78283B43348B514C00--



Received: from mail.siol.net (odin.siol.net [193.189.160.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25456 for <[e-mail]>; Mon, 29 May 2000 07:21:56 -0700 (PDT)
Received: from [171.78.60.30] ([213.250.20.245]) by mail.siol.net (InterMail vK.4.02.00.10 201-232-116-110 license def7f3c1ccee590d715bf25c5fe4cbb9) with ESMTP id <20000529142930.QAZV462.mail@[213.250.20.245]>; Mon, 29 May 2000 16:29:30 +0200
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220804b5581f6bed2a@[171.78.60.30]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 29 May 2000 09:30:37 -0400
To: Peter Williams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>User includes account name in the subject DN. A Private
>organization's CA service services a closed intranet and
>extranet community. It issues a certificate including
>the account name. This circumstance is common in the Internet
>community today.

As Al said, just because people do it doesn't mean it's right or 
should be condoned by our standards.  But, to continue with your 
example, let's assume that the CA finds an acceptable way to embed 
the account name in the cert somewhere.

>CA has a policy, which is partially disclosed. The disclosed
>Policy Elements are made available only to subscribers. This
>circumstance is common in the Internet community today.

partially disclosed?  partially trusted? partially useful?

>The motivations for establishing the extent
>of a field verification policy are beyond the understanding
>level of the CA's subscribers.  This  circumstance is common
>in the Internet community today.

Greed?

>The CA does disclose a policy element to susbcribers to
>procedurally follow a  "limited"  technical verification procedure
>concerning account names. The procedure establishes that an account
>of that name "exists" - in an account management system acceptable
>to the CA - at the time of certificate issuance.

I would not want to rely on this CA, and I expect most people would 
feel the same way.  I would "naturally" expect the CA to verify that 
the account name is bound to the user in question, not merely that 
the account name exists. This is the danger of adopting too liberal 
an interpretation of the "verified by whatever rules the CA wants to 
use" approach.

>All other data in a certificate is "verified", according
>to other per-CA policy criteria and/or PKIX mandates.

Based on the disclosed part of the "verification" process, I can't be 
too comfortable with what the CA may be doing for the rest of the 
data.

>
>Does the resulting certificate, when issued
>under the above scenario, conform with the
>proposed PKIX standards for field verification?

I think not.

>A fourth party undertakes a private PKIX-audit of
>the CA for the benefit of the CA.  Should it
>determine the CA is acting according to the spirit
>of the proposal concerning field verification
>when executing this scenario?

The auditor should issue a negative report.

Steve



Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [192.6.10.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18159 for <[e-mail]>; Mon, 29 May 2000 04:48:59 -0700 (PDT)
Received: from sooty.hpl.hp.com (sooty.hpl.hp.com [15.144.30.249]) by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id MAA05611 for <[e-mail]>; Mon, 29 May 2000 12:56:29 +0100 (BST)
Received: from casassamontm5 (dhcp-27-6.hpl.hp.com [15.144.27.6]) by sooty.hpl.hp.com with SMTP (8.7.6/8.7.3 SMKit7.0) id MAA02944 for <[e-mail]>; Mon, 29 May 2000 12:56:27 +0100 (BST)
Reply-To: <[e-mail]>
From: "Marco Casassa Mont" <[e-mail]>
To: <[e-mail]>
Subject: Use cases for digital credentials
Date: Mon, 29 May 2000 12:58:28 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

Dear all,

I am analysing a B2B scenario where employees working for different
enterprises (which have no previous business relationships and are not
member of any EDI VAN or extranet) need to interact together: for trust
reasons they need to exchange digital credentials (identity certificates and
*expecially* attribute certificates).

I wonder if you are aware of any document/paper describing use cases for
digital credentials in such a B2B scenario. In particular I am interested in
use cases and examples for attribute certificates.

Any link/reference is welcome.

Marco

P.S.: Apologies if this is not the right mailing list to ask for this kind
of information


=========================================================================
 Marco Casassa Mont
 Trusted E-Services Laboratory               +++++++++++++++++++++++++++
 Hewlett-Packard Laboratories                +++++++   _/        +++++++
 Filton Road, Stoke Gifford                  +++++    _/           +++++
 BRISTOL, BS34 8QZ, UK.                      ++++    _/_/_/  _/_/_/ ++++
                                             +++    _/  _/  _/  _/   +++
 Phone:  [phone] (direct)           ++++  _/  _/  _/_/_/   ++++
 Telnet: 312 8794                            +++++        _/       +++++
 Fax:    [phone]                    +++++++     _/      +++++++
 Email:  [e-mail]           +++++++++++++++++++++++++++

=========================================================================
    'All points of view are my own and not necessarily HP's as well'



Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA16508 for <[e-mail]>; Mon, 29 May 2000 03:56:51 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Mon, 29 May 2000 12:02:36 +0100
Received: from taalap (taa-lap.sse.ie [193.120.32.86]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id MAA05474; Mon, 29 May 2000 12:02:07 +0100 (BST)
Message-ID: <003801bfc95d$51c41650$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: "Paul Hoffman" <[e-mail]>
Cc: <[e-mail]>
References: <p04320307b550772f168c@[165.227.249.13]>
Subject: Re: Requirements for remote path processing services
Date: Mon, 29 May 2000 12:01:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

Paul + co.,

Having read your post, I was just wondering if these remote path processing
services could be applied to ACs for authorisation purposes? I've put
together a few points on the subject (see below).

Comments would be appreciated.

Regards,

Andy



1) OVERVIEW

In addition to remote path processing services:

a) delegated path construction
b) delegated path verification
c) trust and policy centralisation

that apply to public key certificates, there may be scope for
the application of these services to authorisation-related certificates
i.e. Attribute Certificates could be verified remotely by a single
trusted entity, and this would bring the benefits of centralised
trust/policy management and simpler clients.


2) MOTIVATION

Firstly, let's present some arguments *against* introducing remote AC
validation:

a) The current profile for AC validation is relatively simpler than
   that of PKC validation:

        a) AC chains are not used
        b) AAControls is optional
        c) AC revocation checking is optional

   Consequently, a very minimal (and conformant) AC validator can be
   implemented and would be "lightweight" enough to provide on clients.

b) AC validation for authorisation purposes is typically a server-side
   operation anyway, and clients would hardly need to validate an AC.


In response to argument (a):

     Whilst a client may indeed conform to the simplest version of the AC
     profile with a lightweight implementation, such an implementation
     would have no control over which attributes can be issued by which
     authorities (AAControls), due to the lack of chain processing.
     In addition, the client cannot safely validate long-lived ACs.
     This is due to the lack of revocation processing.

In response to argument (b):

     Clients *may* need to validate ACs in the push model to
     ensure the integrity of the AC before passing it on to other
     servers. (Complications arise here when the AC is pushed to a
     different "trust domain" where the AC validation policy differs
     to that of the clients policy, so there's scope for further study here)

     A client will need to validate an AC if it is used in the making of
     a client-side access decision. Scenarios in which a client-side
     access decision would need to be made are:

            --> Checking the permissions of downloaded content:
                --> Has a piece of downloaded code have execute permission
                    from the system admin?

            --> Client-side content filtering:
                 -> Checking if downloaded content has a "rating" attribute
                    (12, 15, 18, PG-13, NC-17, R, etc.)


It is apparent that there is indeed a requirement for:
       (a) clients to validate ACs
       (b) AC validation to be performed "fully". That is, AAControls
           and revocation checking should be done for security reasons.

Given these requirements, it seems logical to migrate these verification
tasks to a dedicated AC validation server.


2) BENEFITS:

The benefits are the same as for remote PKC processing:

a) Centralised trust and policy for authorisation purposes

    (i)   Administrator(s) can say what AAs are trusted by the enterprise
    (ii)  Administrator(s) can implement complicated trust management via
                           AAControls and/or AC Chain validation
    (iii) Administrator(s) can implement AC revocation checking

b) Simplified clients
    (i)  No need for the client to implement any form of AC verification,
         path processing (for AAControls), LDAP/OCSP clients, etc.

c) Server-side caching to improve turnaround time on a validation request







Received: from unimur.um.es (unimur.um.es [155.54.1.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15898 for <[e-mail]>; Mon, 29 May 2000 03:30:03 -0700 (PDT)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by unimur.um.es (8.9.1b+Sun/8.9.1) with ESMTP id MAA01368 for <[e-mail]>; Mon, 29 May 2000 12:37:20 +0200 (MET DST)
Received: from dif.um.es (labredes15.dif.um.es [155.54.210.9]) by aries.dif.um.es (Postfix) with ESMTP id 8AA05EC1A for <[e-mail]>; Mon, 29 May 2000 12:37:15 +0200 (MET DST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 29 May 2000 12:36:57 +0200
From: Gabriel =?iso-8859-1?Q?L=F3pez=20Mill=E1n?= <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: PKIX library 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id DAA15902

    Hello all.

    There is any free pkix library for Java?

    Thanks, Gabi.


Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA13154 for <[e-mail]>; Mon, 29 May 2000 03:03:16 -0700 (PDT)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id <MAA05083> (multiple receipients); Mon, 29 May 2000 12:10:50 +0200 (MET DST)
Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id MAA15873; Mon, 29 May 2000 12:10:20 +0200 (MEST)
Message-ID: <[e-mail]>
Date: Mon, 29 May 2000 12:20:33 +0200
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.5 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Timestamp: id for token
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree on what James wrote. A unique identifier or serial number is not
necessary.

"Manger, James H" schrieb:
> 
> Is a standardised unambiguous identifier for a timestamp token really needed
> or wanted?
> 
> Such an identifier is useful for a certificate as a certificate is used in
> many messages (many SSL sessions, many S/MIME emails, many transactions,
> ...).  The certificate is independent of any particular use.  A timestamp,
> however, is only relevant to a single message - corresponding to its
> messageImprint field.
> 
> The are no timestamp revocation lists.  There are no other messages from a
> TSA that need to refer to a specific timestamp.
> 
> It seems sensible to store a timestamp with its corresponding message - so
> now identifier is needed.  Even if they were stored separately the
> implementation could its own labels to maintain the link, i.e. it does not
> need an explicit field within the timestamp.


Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12889 for <[e-mail]>; Mon, 29 May 2000 02:56:11 -0700 (PDT)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id <MAA04774> (multiple receipients); Mon, 29 May 2000 12:03:43 +0200 (MET DST)
Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id MAA15739; Mon, 29 May 2000 12:03:09 +0200 (MEST)
Message-ID: <[e-mail]>
Date: Mon, 29 May 2000 12:13:22 +0200
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.5 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Michael Zolotarev <[e-mail]>
CC: "Manger, James H" <[e-mail]>, [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael,

Michael Zolotarev schrieb:
> 
> Not that simple to me. You'd have to go into lengths explaining how the
> precision value should be applied. For instance, what would you say about a
> token with base time ="20000529053138.345Z", and the precision of 1 second?

The precision describes the probability of the official time being inside the
intervall from "20000529053137.345Z" to "20000529053139.345Z". So if you want
to compare with a second time source you can use the presision field. If you
compare with the same time source the actual precision is much better. Actual
it is +-0, because you compare the clock with itself.

Note that the values are not randomly spread inside of the time intervall.
They are always increasing.

> Should we then trim the base value to make the precision meaningful (i.e.
> the base time is just "20000529053138Z")?

You should do this only for comparing the time stamping time with GMT.

Jörg


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09597 for <[e-mail]>; Mon, 29 May 2000 01:13:07 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA10113 for <[e-mail]>; Mon, 29 May 2000 18:20:11 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdYbqbc_; Mon May 29 18:19:57 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA28070 for <[e-mail]>; Mon, 29 May 2000 18:19:56 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdHvrn6_; Mon May 29 18:19:21 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id SAA12772 for <[e-mail]>; Mon, 29 May 2000 18:19:21 +1000 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <L4KYCQWX>; Mon, 29 May 2000 18:18:50 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 18:18:47 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> You'd have to go into lengths explaining how
> the precision value should be applied.

Why.  The accuracy (I assume this is what you mean by "precision value")
simply conveys the uncertainty of the genTime value with
respect to UTC.


> base time ="20000529053138.345Z", and the precision of 1 second?

The TSA's best estimate for UTC when this timestamp was issued was
29 May 2000 at 5:31 AM and 38.345 seconds.  The TSA's uncertainty
(1 standard deviation) in this estimate is +/- 1 second.  So UTC
may actually have been 37.8 seconds or 39 seconds or 
38.11123 for instance.


> trim the base value to make the precision meaningful

No.  Why would you?
Quoting many more digits than the accuracy warrants does not make
it wrong.  In some situations (e.g. a physics article) it might be
considered bad form because the extra digits are worthless (but
still harmless), but in our situation they do have a use - to order
timestamps.


> consistency in style with 2459

A certificate and timestamp are very different beasts.  The former
is useful independently of any particular message, the latter is
only relevant to one message.  [A more useful consistency would
have been to use a SIGNED { tbsTimestamp } ASN.1 construct,
instead of CMS]

> - e.g. having a unique reference to the token

I am not even sure that a standardised unique reference to a
timestamp is useful at all, let alone necessary in the base
standard.


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA08682 for <[e-mail]>; Mon, 29 May 2000 00:44:17 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA25008 for <[e-mail]>; Mon, 29 May 2000 17:51:20 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0vSSMm; Mon May 29 17:51:12 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA07026 for <[e-mail]>; Mon, 29 May 2000 17:51:12 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdMNGQW_; Mon May 29 17:50:39 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA29172 for <[e-mail]>; Mon, 29 May 2000 17:50:39 +1000 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <L4KYCNVH>; Mon, 29 May 2000 17:50:08 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Timestamp: id for token
Date: Mon, 29 May 2000 17:50:04 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Is a standardised unambiguous identifier for a timestamp token really needed
or wanted?

Such an identifier is useful for a certificate as a certificate is used in
many messages (many SSL sessions, many S/MIME emails, many transactions,
...).  The certificate is independent of any particular use.  A timestamp,
however, is only relevant to a single message - corresponding to its
messageImprint field.

The are no timestamp revocation lists.  There are no other messages from a
TSA that need to refer to a specific timestamp.

It seems sensible to store a timestamp with its corresponding message - so
now identifier is needed.  Even if they were stored separately the
implementation could its own labels to maintain the link, i.e. it does not
need an explicit field within the timestamp.


Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA07962 for <[e-mail]>; Mon, 29 May 2000 00:10:15 -0700 (PDT)
Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 12wJo5-0004C0-00; Mon, 29 May 2000 07:17:49 +0000
Received: from [209.21.28.126] (helo=nma.com) by dfw-mmp3.email.verio.net with esmtp (Exim 3.12 #7) id 12wJnz-0002ER-00; Mon, 29 May 2000 07:17:43 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 May 2000 00:17:52 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Al Arsenault wrote:

[snip]

> The presence of an "attribute" whose value has not been verified
> - either directly or indirectly - by the CA is at best misleading, and
> at worst openly harmful to the relying party.

Al:

I agree entirely with what you wrote above. The devil is -- what do we
mean by "verifying"?  Of course, the word "verifying" must be understood
according to both the PKIX standard AND the CA's CPS. This means that
such certificates are essentially statements from a CA, not fact, and that
meaning and trust on a certificate (like beauty) is in the eyes of the beholder,
i.e., depends on each relying-party.

And certificates also contain fields which are not very intuitively defined or
even coherent with their names, such as the Distinguished Name field, which
is neither always distinguished nor necessarily contains the subject's name.
And, the SerialNumber field, etc.  So, data fields themselves are not clear in
*their* names -- more or less like a CA making no representation that the
subject "Bill Clinton" of a certificate is the same "Bill Clinton" as the one
you might be thinking of, but they put it in the cert anyway ;-)

Yes,  in legal reliance terms one may trust the confirmation procedures of the
CA during certificate reliance, but one cannot rely upon them for other than
their value as a representation of the CA's authentication management act
expressed in the CA's own terms and rules -- therefore, a PKIX certificate is
neither necessarily meaningful nor valid in a r-p's reference frame or for the
r-p's purposes. To pretend otherwise is at best misleading and at worst openly
naive.

To see a graphical birds's eye view of my comment, with a less terse treatment,
the reader can visit the "unabridged inside view of a typical X.509 certificate"
in http://www.mcg.org.br/x509cert.htm

Cheers,

Ed Gerck




Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06329 for <[e-mail]>; Sun, 28 May 2000 23:10:05 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id QAA05460; Mon, 29 May 2000 16:23:07 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <L6FWDHJH>; Mon, 29 May 2000 16:16:59 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "Manger, James H" <[e-mail]>, [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 16:16:58 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Not that simple to me. You'd have to go into lengths explaining how the
precision value should be applied. For instance, what would you say about a
token with base time ="20000529053138.345Z", and the precision of 1 second?

Should we then trim the base value to make the precision meaningful (i.e.
the base time is just "20000529053138Z")?

And the consistency in style with 2459 - e.g. having a unique reference to
the token comprised of its SerialNumber and the issuer name, was also one of
the goals.

Michael

> -----Original Message-----
> From: Manger, James H [mailto:[e-mail]]
> Sent: Monday, May 29, 2000 3:59 PM
> To: [e-mail]
> Subject: RE: TSA Response serialNumber Field
> 
> 
> TSA clients must support genTime values with 
> fraction-of-second components,
> e.g "20000529053138.345Z".  Consequently, by using sufficient
> fraction-of-seconds digits, it is easy for a TSA to issue 
> genTime values
> that always increase and never repeat.
>  
> * The TSA does not need to maintain another never-repeating value
> (serialNumber) and does not have to worry about maintaining 
> it when the TSA
> server crashes.
> * The TSA does not need to issue (nor the client expect) huge integer
> values.
> * Ordering two timestamps from one TSA is simply achieved by 
> comparing their
> genTime fields.
> * Accuracy (uncertainty with respect to UTC) is not affected as it is
> conveyed in a separate field.
>  
> Simple.  Complete.
>  
> The only issue is whether the ordering works from timestamps 
> with the same
> TSA name or same TSA signing key.
> 
> 
> 
>  
> 


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05241 for <[e-mail]>; Sun, 28 May 2000 22:54:08 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA13540 for <[e-mail]>; Mon, 29 May 2000 16:01:06 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0F6.qW; Mon May 29 16:00:44 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA14672 for <[e-mail]>; Mon, 29 May 2000 16:00:43 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd4X5_h_; Mon May 29 15:59:48 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA27985 for <[e-mail]>; Mon, 29 May 2000 15:59:48 +1000 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <L4KYBYMK>; Mon, 29 May 2000 15:59:17 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 15:59:15 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

TSA clients must support genTime values with fraction-of-second components,
e.g "20000529053138.345Z".  Consequently, by using sufficient
fraction-of-seconds digits, it is easy for a TSA to issue genTime values
that always increase and never repeat.
 
* The TSA does not need to maintain another never-repeating value
(serialNumber) and does not have to worry about maintaining it when the TSA
server crashes.
* The TSA does not need to issue (nor the client expect) huge integer
values.
* Ordering two timestamps from one TSA is simply achieved by comparing their
genTime fields.
* Accuracy (uncertainty with respect to UTC) is not affected as it is
conveyed in a separate field.
 
Simple.  Complete.
 
The only issue is whether the ordering works from timestamps with the same
TSA name or same TSA signing key.



 



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24266 for <[e-mail]>; Sun, 28 May 2000 19:36:46 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA00998; Mon, 29 May 2000 12:49:10 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <L6FWDHCB>; Mon, 29 May 2000 12:43:01 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail]
Cc: [e-mail], xme <[e-mail]>, Peter Sylvester <[e-mail]>, [e-mail], William Lattin <[e-mail]>, [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 12:42:58 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Folks,

I'll be very short:

The most significant points raised, related to what I've proposed, are:
1. By Denis about having two requirements: a) accepting the 2459 style
interpretation for the SerialNumber, and b) preserving the order.
2. By Peter that a TSA IS(!) the authority which establishes the order. So
the natural order of timestamps as being issued by the TSA is the ONLY order
we should recognize. 

A simple way to put it all together would be to:
1) Define a SerialNumber as a strictly monotonically increasing number (1,
3,47, 543) across all tokens by the same TSA.
2) Accept the point that a TSA *always* naturally establishes the order
makes the BOOLEAN flag proposed by Denis unnecessary. The draft should not
say anything about the requirement(!) of maintaining the order at all.

And guess what: the previous two point are EXACTLY what is covered by the
very original text of the draft. Exactly that! Not a bad outcome of a good
technical discussion :)

What is missing is: 

3) a 2459-styled statement about the uniqueness of TSA_Name+SerialNumber.
4) A statement *not preventing* the crash recovery handling suggested by
Bill Lattin.
4) Long integer handling.

I've stolen a sentence from 2459, and slightly modified and shortened the
original text from the draft:
**
The serialNumber field shall include a strictly monotonically increasing
integer from one TimeStampToken to the next (e.g. 45, 236, 245, 1023, ...).
It MUST be unique for each token issued by a given TSA (i.e., the TSA name
and serial number identify a unique time stamp), providing the way to build
a unique identifier to reference the token. The serialNumber also allows to
compare the ordering of two time stamps from the same TSA, which is useful
in particular when two time stamps bear the same time. 
It should be noticed that the uniqueness of the token references must remain
valid even after a possible interruption (e.g. crash) of the service. 
The clients MUST be able to handle serialNumber longer than 4 bytes digits.
***

To what I saw, this should keep the most of us happy. Or am I dreaming?

Regards
Michael


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12392 for <[e-mail]>; Sun, 28 May 2000 18:22:06 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <[e-mail]>; Sun, 28 May 2000 18:29:38 -0700
Message-ID: <[e-mail]>
Date: Sun, 28 May 2000 21:27:15 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

	In a word, "No".  Details below:

Peter Williams wrote:
> 
> User includes account name in the subject DN. A Private
> organization's CA service services a closed intranet and
> extranet community. It issues a certificate including
> the account name. This circumstance is common in the Internet
> community today.
>

> CA has a policy, which is partially disclosed. The disclosed
> Policy Elements are made available only to subscribers. This
> circumstance is common in the Internet community today.
> 
> The motivations for establishing the extent
> of a field verification policy are beyond the understanding
> level of the CA's subscribers.  This  circumstance is common
> in the Internet community today.
> 

I won't argue with any of these; I'll simply state that the fact that
it's common in the Internet community today doesn't make it the right
thing to do.  

> The CA does disclose a policy element to susbcribers to
> procedurally follow a  "limited"  technical verification procedure
> concerning account names. The procedure establishes that an account
> of that name "exists" - in an account management system acceptable
> to the CA - at the time of certificate issuance.
> 

In other words:  the CA verified that there was someone named "Bill
Clinton" purporting to reside at 1600 Pennsylvania Avenue, Washington,
DC at the time of certificate issuance, so I'll put that in the
certificate.  I make no representation that the subject of this
certificate is the same "Bill Clinton" as the one you might be thinking
of, but I'll put it in the cert anyway.  All other data in the
certificate are verified as per the CP/CPS/other appropriate document.

Is this useful?  To what relying party?

> All other data in a certificate is "verified", according
> to other per-CA policy criteria and/or PKIX mandates.
> 
> Does the resulting certificate, when issued
> under the above scenario, conform with the
> proposed PKIX standards for field verification?
>

Not according to the ones I'm recommending.  :-)
 
> A fourth party undertakes a private PKIX-audit of
> the CA for the benefit of the CA.  Should it
> determine the CA is acting according to the spirit
> of the proposal concerning field verification
> when executing this scenario?
>

Again, in a word:  "NO".  The presence of an "attribute" whose value has
not been verified - either directly or indirectly - by the CA is at best
misleading, and at worst openly harmful to the relying party.
 

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04071 for <[e-mail]>; Sun, 28 May 2000 17:31:18 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA15125; Mon, 29 May 2000 10:43:30 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <LWX2NNCD>; Mon, 29 May 2000 10:37:44 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 10:37:35 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

> 
> Note also that the precision becomes a somewhat strange information,
> how do you compare two time stamps that just happen to to be
> a second aprt with a precision of 999 milliseconds.
>  
Peter,

You compare a time stamp with:
1. 'Real' time.
When dealing with real time, you do not compare, strictly speaking. You just
use the precision to say that "the time was somewhere around X, within +-Y
interval". This is the prime intention of the precision field.

2. a stamp issued by the same TSA.
When comparing with a stamp issued by the same TSA (2), you ignore the
precision at all.

3. a stamp issued by another TSA (AND the precision diapazons of the two
stamps overlap). The only purpose of comparing is to figure out which stamp
was issued earlier. We have two cases to consider here:

Case1: Precision_TSA1 is equal to Precision_TSA2.
Here the rule would be to treat the precision as the span of the probability
graph, with the probability being the highest at the middle point (base time
value), and 0 at the ends of the 'hill'. Therefore, the court (my court :)
would simply opt to ignore the precision field at all, and look at just the
base values.
I would consequtively reject any claims that *your* probability graph is not
a 'hill-shaped' curve.

Case2: Precision_TSA1 is smaller than Precision_TSA2. 
As a judge I fully trust the TSA1 'cause it's time is more precise. So I
again look at the base time value. If TSA1 stamp says it was generated a
second earlier than TSA2 stamp - that's the truth. If TSA1 stamp says it was
generated a second later than TSA2 stamp - that's the truth as well.


If TSA2 wants to argue that the *other* TSA's precision field is a fake,
then it is the matter for another, totaly unrelated to this one, court
hearing.

Regards
M


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24615 for <[e-mail]>; Sat, 27 May 2000 09:12:32 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA13551; Sat, 27 May 2000 18:19:54 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Sat, 27 May 2000 18:19:54 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA20201; Sat, 27 May 2000 18:19:53 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA04384; Sat, 27 May 2000 18:19:53 +0200 (MET DST)
Date: Sat, 27 May 2000 18:19:53 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: TSA Response serialNumber Field
Cc: [e-mail], [e-mail]

> Denis,
> 
> You could still achieve your objective of maintaining ISO compatibility and
> requiring global uniqueness of each TS token using only a combination of the
> TSA's name and the serialNumber provided the serialNumber field itself can
> be made up of a date/time component and a numbering counter that start over
> with every new time interval (e.g. a day, an hour, a minute, etc.). Note
> this is similar to what I had suggested in my original message on May 18,
> which started this whole thread.
> 
> For this reason I support the text proposed by Michael for the serialNumber
> field.

Ooops, I forgot to mention Francois.

> 
> I also support your rationale for the addition of the proposed BOOLEAN on
> ordering in TS tokens with a minor change as suggested below. I think if it
> is missing, or if the ordering field is present and set to false, then it
> should only indicate that the ordering of Time Stamps issued by the same TSA
> can not be guaranteed.

I don't think that this observation is worth the boolean. 
Since the serialnumber field indicates a unique value within a period of a second
or so, I do not see what a TSA cannot simply be the authority of establishing the order.


People might try to misinterprete the unique identifier as order anyway.

Thus, I would propose to say somewhere either: 

- "The TSA defines order of time stamps by a combination of the genTime
   and serialnumber value."

- "The TSA defines the order of time stamps by the serialNumber value."

Or 'the order of time stamps is defined by ...'

> 
> In section 2.4.2. Page 8.
> 
> "If the ordering field is present and set to true, Time Stamps tokens can
> always be ordered by looking only at the genTime and the serialNumber
> parameters.
> 
> If the ordering field is missing, or if the ordering field is present and
> set to false, then the genTime field only indicates the time at which the
> timestamp has been created by the TSA. In such a case, the ordering of Time
> Stamps issued by the same TSA can not be guaranteed."
Comments about DER as in my previous message.



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23892 for <[e-mail]>; Sat, 27 May 2000 08:53:59 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA13481; Sat, 27 May 2000 18:01:18 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Sat, 27 May 2000 18:01:19 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA20183; Sat, 27 May 2000 18:01:17 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA04377; Sat, 27 May 2000 18:01:17 +0200 (MET DST)
Date: Sat, 27 May 2000 18:01:17 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]

> Michael,
> 
> Thank you for this good analysis of the issue.
> 
> The problem we have is that, currently, the serialNumber is used 
> for two different purposes in order to address two different 
> requirements, hence why we have some difficulties.
> These requirements are the following:
> 
> 1) Uniquely designate a TS token using a combination of the TSA's
> name and the serialNumber. This is how serialNumber is used in RFC
> 2459 for both Public Key Certificates and CRLs, as well as how it is
> used for Attributes Certificates, at least at the time being as
> defined by ISO (and I suppose we are not going to change this). :-)
> 
> 2) Distinguish betwen two time-stamps issued with the same time
> (e.g. the same second).
These are not TWO requirements but one, since one obviously assumes
that whatever time interval is chosen, it occurs only once.

The requirement is: 'Each time stamp token has a unique identification',
and you 2 points are just two ways of adressing this.

In the current text this requirement is addressed by having a
unique serialNumber. 

Of course it could be addressed by many other things, you could even
issue a new certificate for each signature with a name component
uniqueId=nnn 

I rather see that the data retrurned respond to the following
requirements:

1 - unique identification

2 - associate a time value to an event

3 - determine an order between two events.


> 
> I would propose a simple (and new) way to solve this issue: use one
> parameter for one purpose only.

1 - is addressed by the serialNumber
2 - is addressed by the time value
3 - is currently also addressed by the serialNumber

> 
> 1) for the first requirement, stick to the use of this parameter as
> required for PKCs, CRLs in RFC 2459 and for ACs. This means only 
> require uniqueness and nothing else. We may then keep the name 
> "serialNumber".
> 
> 2) for the second requirement, let us first look at it slightly
> differently. 
> 
> Today we implicitly MANDATE TSAs to be able to indicate which one of
This is rather explicit and whether they are issued within the same
second is not important.  

> two time stamps (e.g. issued within the same second) was first. We
> could simply ALLOW TSAs to be able to indicate which one of two time
> stamps (e.g. issued within the same second) was first. In many
> cases, the ordering of the token will be artificial and even wrong,
> in particular when the TSA is handling multiple crypto-engines in
> parallel. It may be indesirable or pretty hard to try to distinguish
> between who came first in a waiting queue for a given crypto-engine
> and who came out first from a waiting queue for another given
> crypto-engine from the same TSA. In some designs shall parallel
> crypto-engines use the same clock or can they use their own clock ?
Allocating a time valiue, and SIGNING the result may not necessarily happen
in the same processor. You could just start creating the unsigned
time stamp and then hand out this to several signing engines in
parallel. See below for more.

> If the clock is different, how is it possible to still guarantee the
> ordering ? I would not like to answer to these questions and hence
> mandate designs where all TSAs MUST always guarantee the ordering.
The time stamp does not guarantee the ordering of what they recived etc.
They simply establish the order, the TSA *IS* the authority, they don't
have to justify the order. It's like asking the clock providers to
guarantee the order they generate. 

What testing device how would you create in order to test whether
a TSA hands out time stamps in a wrong order? How would you try
to establish a proof of such misbehaviour. 

In the same way as for a clock: You just send request, get an anwser,
create a new request etc. If for the new request the order is
wrong, you have an indication of misbehaviour.   

> This would prevent some implentation designs. I would rather prefer
> to ALLOW TSAs to guarantee the ordering, if they wish to do so. This
> is more flexible and also recognizes the fact that mandating this
> requirement in some environments is not at all needed.

Assume a parallel solution where the time of each of the processing
engines can have some access to a time value within let's say a
precision of n milliseconds. Each engine gets a a unique identifier
let's say 0 - 2**x-1.

Each engine maintains a local counter within this precision value, 
create time stamps of the form   time + id + counter (concatenation)
AND delay the delivery of the stamp by about 2*n.

This avoids that a client could get a time stamp, create a hash of
the time stamp, and get a time stamp of the token with a serialnumber
with is lower serial number.

> 
> Now let us look how to achieve these goals:
> 
> genTime is defined as the time at which the timestamp has been
> created by the TSA. It can include any *precision*. However the
> accuraccy (i.e. the time difference with UTC - not the precision) is
> indicated in another parameter called accuracy which represents the
> time deviation around the UTC time contained in GeneralizedTime.
genTime is the time that the TSA has allocated to that time stamp,
not more.

> 
> If a TSA wants to ALLOW users to make the difference, it may then
> use a precision much better than the second (and, for example, 
> still have an accuracy of one second). Otherwise it does what 
> it wants.
> 
> To this end the following changes are proposed:
> 
> Section 2.1. Requirements of the TSA
> 
> The TSA is REQUIRED:
> 
> (snip)
> 
>    3.  to include a unique integer for each newly 
>        generated time stamp token.
Can you tell me a method to create a unique identifier that
is substantially faster than one that you cannot easily transform
into one having the property that the integer also grows.
 
> 
> In section 2.4.2. Page 8. The serialNumber is an integer assigned by
> the TSA to each Time Stamp token. It MUST be unique for each Time
> Stamp token issued by a given TSA (i.e., the TSA name and
> serialNumber identify a unique Time Stamp token).
> 
> On page 8, just after the sentence: " However, when there is no need
> to have a precision better than the second, then GeneralizedTime
> with a precision limited to one second should be used (as in 
> [RFC 2459]).", add the following:
> 
> "When there is a need to sequence the time stamps issued from the
> same TSA at a granularity better than the second, then a greater
> precision must be used and be commensurate with the number of time
> stamps that can be generated by that TSA within the same second."
Horrible. 
>   
> There is however one major drawback with this. How can a TS user
> know if the TS token issued by a given TSA are garanteed or not to
> be ordered ? Simply looking at genTime and accuracy does not allow
> to always make the difference. So we would need another parameter
> (e.g. a BOOLEAN) :-( or use the security policy which is not
> directly machine procn application has to establish in its context whether to
accept a time stamp authority, and WHICH one; you never just say
I will accept all tokens that are signed as a TSA. 

> 
> The BOOLEAN would be "better", simple to understand, and allow more
> more flexibility than we have today. It is quite late to introduce
> another parameter at this stage, :-(  but if it is not now, it will
> never be. :-). 
> 
> If we do so, it could be after:
> 
>       policy      PolicyInformation,
> 
> add:
> 
>      ordering     BOOLEAN DEFAULT FALSE,
> 
> with the following explanations:
> 
> " If the ordering field is present and set to true, Time Stamps
> tokens
> can always be ordered by looking only at the genTime parameter,
> whatever their accuracy is.
This is USELESS: Either you have all time stamps with a different
time value, then you can compare them, or it can happen that
they have the same. Then you don't need a boolean to indicate that.

I think you will almost never be in a situation of an application
that uses one time first to determine whether a document or whatever
is conformant, i.e., a verifier would reject the time stamped data
with an indication saying: Sorry, this TIMESTAMP is not good
enough since we won't be able to establish an order between this
one and another one of the same authority. I don't believe that
a TSA would create different time stamps based on the load or
wahatever. You might consider to indicate in the request to
ask for an ordered or unordered time stamp. 

The question is there: Do we want two different types of services
or not. 

> 
> If the ordering field is missing, or if the ordering field is
> present and set to false, then the genTime field only indicates the
nit picking: when the value is THERE it is ALWAYS TRUE.
 
I thought that we had already been beyond this discussion. We already
had consensus that the genTime is not a good value to establish the order
of two time stamps. 


> time at which the timestamp has been created by the TSA. In such 
> a case, the ordering of Time Stamps issued by the same TSA is 
> only possible when the difference between their genTime is greater 
> than the accuracy of the first Time Stamp token plus the accuracy 
> of the second Time Stamp token."
Trying to compare tokens on the basis of a precision and non unique
and arbitraily injected time values, one per vaguely defined second,
doesn't seem a good solution.

One thing to retain is whether the time stamp authority does
establish an order among time stamps or not. 

Another: Would there be any possibility to use time stamps
from several authorities? In fact this latter question is much more
interesting, and probably shows that exact ordering and TIME stamping
are two different services, anyway. Note that I didn't say
'compare two time stamps'. An application would be to get a time
stamp in order to demonstrate that you have made your tax declaration
in time. There is no requirement to have an order among two time stamps. 

> 
> Now, an alternative to this proposal would be to MANDATE Time stamps
> ordering (which does not appear to be a good requirement as
> explained earlier). If so we should rename the current parameter
> differently (in order to avoid confusion), like:

Why do you say 'WOULD BE'. This is the actual definition since 3 years,
you just change the name from serialNumber to increasingNumber. 

> 
>          increasingNumber                 INTEGER,
> 
> and have the following changes:
>  
> Section 2.1. Requirements of the TSA
> 
> The TSA is REQUIRED:
> 
> (snip)
> 
>    3.  to include a strictly incrementing integer for 
>        each newly generated time stamp token.
> 
> In section 2.4.2. Page 8. The increasingNumber field shall include a
> strictly increasing integer from one TimeStampToken to the next
> (e.g. 45, 236, 245, 1023, ...). This guarantees two properties: (1)
> When used in combination with the TSA's name the increasing number
> identifies a unique Time Stamp token. (2) It is always possible to
> compare the ordering of two time stamps from the same TSA by looking
> only at that field. This may be useful in particular when two time
> stamps from the same TSA bear the same time. It should be noticed
> that the stricly increasing numbering property must remain valid
> even after a possible interruption (e.g. crash) of the service. A
> recipient of a Time Stamp token MUST be able to handle increasing
> numbers that are up to 16-bytes.

The latter mean just renaming of the actual text, but not what had
been discussed by Bill, Paul and Michael, i.e., it was questioned whether
it can be achieved in all circumstances, and whether it wouldn't be
sufficient to just have ordering property AND the unique identification
defined by the combination of the genTime and "that number".

Personally I prefer the current text, i.e., uniqueness and ordering
defined by the serialNumber. 

Peter  




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20587 for <[e-mail]>; Sat, 27 May 2000 08:00:28 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA13292; Sat, 27 May 2000 17:07:42 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Sat, 27 May 2000 17:07:43 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA20108; Sat, 27 May 2000 17:07:40 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA04368; Sat, 27 May 2000 17:07:40 +0200 (MET DST)
Date: Sat, 27 May 2000 17:07:40 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: TSA Response serialNumber Field
Cc: [e-mail], [e-mail], [e-mail]

> Folks,
> 
> As I can recall, the original idea behind the SerialNumber was simple: to
> preserve the ordering, and to arbitrate between timestamps which happen to
> have the same time value. It itself enforces that each timestamp is now
> unique (time+SerialNumber_within_time_interval is a unique combination),
> though the global uniqueness of the stamps was not the initial intent.

I cannot read brains, so I don't know what was the original idea
(not that we have drafts on the table since almost 3 years now).

>From recalling the discussions, there have been SEVERAL interpretations,
one of them was that:

- a serial number uniquely identifies a time stamp.
- a serial number ONLY is used to order time stamps. 

That is the actual text. I am not against a change as proposed:
to use the time value to take part of the global order. 
Thus, the unique identifier of a time stamp and its order is at least
defined by the indicated time and the serialNumber.

On the other hand you might note that in the actual text, the
time value may not be mononotical increasing for time stamps
ordered by serialNumber. You are able to adjust your clock. Thus
the serialnumber, and not the time defines the order. Agreed,
this might create some confusion if you detect that your clock is
two seconds ahead and you have to go back, well, in the new
rule, you would create a LOOONGG second. 

Note also that the precision becomes a somewhat strange information,
how do you compare two time stamps that just happen to to be
a second aprt with a precision of 999 milliseconds.
 
> 
> Considering that the original intention for the field is still there, let me
> put a few short points together, to straighten things up a bit:
> 
> Point 1: "SerialNumber" in TSA is not the same thing as the 2459's serial
> number. 
> 
> Point 2: a hash can NOT be used as a serialNumber - we need some sort of
> *integer sequentual etc numbering*.
> 
> Point 3: Within the same time value interval, the numbering can be "strictly
> monotonically incremental by one" (1,2,3,4) or more relaxed "strictly
> monotonically increasing" (1,34,111,112,654). Both choices are perfectly
> suitable for the purpose. But the latter is a superset of the former, so we
> can use just "scrictly monotonically increasing".
> 
> Point 4: The numbering counter can be "ever going", or start over with every
> new time interval. Both choices are perfectly suitable for the purpose. So
> that the draft should NOT dictate which one to be used. 
> 
> Point 5: Depending on which numbering scheme is used by the TSA, a
> SerialNumber can reach a big value. Therefore the recepient should be
> prepared to handle 4+ bytes integer.
> 
> Point 6: A TSA can switch from one numbering scheme to another, or reset the
> counter at its will, provided that the order (uniqueness) of timestamps with
> the same time interval is preserved (not violated). This is the only comment
> the draft should probably bear. 
> 
> Point 7: A unique Time+SerialNumber_within_that_interval combination should
> be sufficient for audits.
> 
> 
> To summarize all above, the [slightly modified] statement about the
> SerialNumber could be: 
> ***
> The serialNumber field shall include a strictly monotonically increasing
> integer (e.g. 45, 236, 245, 1023, ...), across all time stamps or at least
> across all tokens bearing the same time value. This guarantees that each
> token is unique and allows 
> to compare the ordering of two time stamps from the same TSA. This is useful
> in particular when two time stamps from the same TSA bear the same time.
> This field also provides the way to build a unique identifier to reference
> the token. It should be noticed that the ordering is defined by the
> combination of the time value and the SerialNumber of the tokens. The
> ordering MUST be maintained even after a possible interruption (e.g. crash)
> of the service. A recepient of a token MUST be able to handle serial numbers
> that are greater than 4-bytes integers.
> ***

This is a possible way.  


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16381 for <[e-mail]>; Sat, 27 May 2000 06:48:27 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA12947; Sat, 27 May 2000 15:55:52 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Sat, 27 May 2000 15:55:52 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA20029; Sat, 27 May 2000 15:55:51 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA04347; Sat, 27 May 2000 15:55:50 +0200 (MET DST)
Date: Sat, 27 May 2000 15:55:50 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field

 
> At 15:38 26.05.00 +0200, Denis Pinkas wrote:
> >1) for the first requirement, stick to the use of this parameter as
> >required for PKCs, CRLs in RFC 2459 and for ACs. This means only 
> >require uniqueness and nothing else. We may then keep the name 
> >"serialNumber".
> 
> Just a short remark: CRL serialnumbers (=the cRLNumber extension) are
> required to be monotonically increasing. 
> "5.2.3  CRL Number
>    The CRL number is a non-critical CRL extension which conveys a
>    monotonically increasing sequence number for each CRL issued by a CA.
> "
> 
1, 1, 1, 1 ... would respect this requirement :-)


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10867 for <[e-mail]>; Fri, 26 May 2000 20:15:50 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <LS0CRR33>; Fri, 26 May 2000 20:18:02 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: [e-mail]
Subject: RE: SubjectAltName verification
Date: Fri, 26 May 2000 20:17:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

User includes account name in the subject DN. A Private
organization's CA service services a closed intranet and 
extranet community. It issues a certificate including
the account name. This circumstance is common in the Internet 
community today.

CA has a policy, which is partially disclosed. The disclosed
Policy Elements are made available only to subscribers. This 
circumstance is common in the Internet community today.

The motivations for establishing the extent
of a field verification policy are beyond the understanding
level of the CA's subscribers.  This  circumstance is common 
in the Internet community today.

The CA does disclose a policy element to susbcribers to 
procedurally follow a  "limited"  technical verification procedure 
concerning account names. The procedure establishes that an account 
of that name "exists" - in an account management system acceptable 
to the CA - at the time of certificate issuance.

All other data in a certificate is "verified", according 
to other per-CA policy criteria and/or PKIX mandates.

Does the resulting certificate, when issued
under the above scenario, conform with the
proposed PKIX standards for field verification?

A fourth party undertakes a private PKIX-audit of
the CA for the benefit of the CA.  Should it
determine the CA is acting according to the spirit
of the proposal concerning field verification
when executing this scenario?


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Friday, May 26, 2000 8:29 AM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: SubjectAltName verification


Denis,

The latter part of your message gets at the contentious point in this 
discussion.

Some of us believe that ALL data in a certificate is definitively 
bound to the public key.  After much debate the WG rejected the 
notion of marking data in a cert as non-verified.  So, the current 
posture is that the EXTENT to which data is verified is a matter of 
CA policy, but the basic notion is that the CA has verified all of 
the data.

Warwick gave some examples that he felt supported the notion that not 
all certificate data is verified, but my response argued that these 
examples were either not a violation of the verification notion 
(e.g., OUs), or were anomalous (pseudonyms).

So, while I agree with your suggestions re pluralizing the references 
in the cited text, I don't agree with the suggestion to limit the 
scope of the comment to just the subject alternate name.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA02166 for <[e-mail]>; Fri, 26 May 2000 19:07:02 -0700 (PDT)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA19451; Fri, 26 May 2000 22:14:11 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220806b554462eec3e@[128.33.238.95]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 26 May 2000 11:28:44 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

The latter part of your message gets at the contentious point in this 
discussion.

Some of us believe that ALL data in a certificate is definitively 
bound to the public key.  After much debate the WG rejected the 
notion of marking data in a cert as non-verified.  So, the current 
posture is that the EXTENT to which data is verified is a matter of 
CA policy, but the basic notion is that the CA has verified all of 
the data.

Warwick gave some examples that he felt supported the notion that not 
all certificate data is verified, but my response argued that these 
examples were either not a violation of the verification notion 
(e.g., OUs), or were anomalous (pseudonyms).

So, while I agree with your suggestions re pluralizing the references 
in the cited text, I don't agree with the suggestion to limit the 
scope of the comment to just the subject alternate name.

Steve


Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13944 for <[e-mail]>; Fri, 26 May 2000 14:07:23 -0700 (PDT)
Received: from winnt (1Cust2.tnt26.sfo3.da.uu.net [63.28.72.2]) by goose.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id OAA15860; Fri, 26 May 2000 14:14:26 -0700 (PDT)
From: "William Lattin" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Michael Zolotarev" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: TSA Response serialNumber Field
Date: Fri, 26 May 2000 14:15:33 -0700
Message-ID: <000101bfc757$8779c590$ad0c173f@winnt>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <[e-mail]>
Importance: Normal

Denis,

Looks like we're converging on a better solution.

Bill

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, May 26, 2000 06:38
> To: Michael Zolotarev
> Cc: [e-mail]
> Subject: Re: TSA Response serialNumber Field
>
>
> Michael,
>
> Thank you for this good analysis of the issue.
>
> The problem we have is that, currently, the serialNumber is used
> for two different purposes in order to address two different
> requirements, hence why we have some difficulties.
> These requirements are the following:
>
> 1) Uniquely designate a TS token using a combination of the TSA's
> name and the serialNumber. This is how serialNumber is used in RFC
> 2459 for both Public Key Certificates and CRLs, as well as how it is
> used for Attributes Certificates, at least at the time being as
> defined by ISO (and I suppose we are not going to change this). :-)
>
> 2) Distinguish betwen two time-stamps issued with the same time
> (e.g. the same second).
>
> I would propose a simple (and new) way to solve this issue: use one
> parameter for one purpose only.
>
> 1) for the first requirement, stick to the use of this parameter as
> required for PKCs, CRLs in RFC 2459 and for ACs. This means only
> require uniqueness and nothing else. We may then keep the name
> "serialNumber".
>
> 2) for the second requirement, let us first look at it slightly
> differently.
>
> Today we implicitly MANDATE TSAs to be able to indicate which one of
> two time stamps (e.g. issued within the same second) was first. We
> could simply ALLOW TSAs to be able to indicate which one of two time
> stamps (e.g. issued within the same second) was first. In many
> cases, the ordering of the token will be artificial and even wrong,
> in particular when the TSA is handling multiple crypto-engines in
> parallel. It may be indesirable or pretty hard to try to distinguish
> between who came first in a waiting queue for a given crypto-engine
> and who came out first from a waiting queue for another given
> crypto-engine from the same TSA. In some designs shall parallel
> crypto-engines use the same clock or can they use their own clock ?
> If the clock is different, how is it possible to still guarantee the
> ordering ? I would not like to answer to these questions and hence
> mandate designs where all TSAs MUST always guarantee the ordering.
> This would prevent some implentation designs. I would rather prefer
> to ALLOW TSAs to guarantee the ordering, if they wish to do so. This
> is more flexible and also recognizes the fact that mandating this
> requirement in some environments is not at all needed.
>
> Now let us look how to achieve these goals:
>
> genTime is defined as the time at which the timestamp has been
> created by the TSA. It can include any *precision*. However the
> accuraccy (i.e. the time difference with UTC - not the precision) is
> indicated in another parameter called accuracy which represents the
> time deviation around the UTC time contained in GeneralizedTime.
>
> If a TSA wants to ALLOW users to make the difference, it may then
> use a precision much better than the second (and, for example,
> still have an accuracy of one second). Otherwise it does what
> it wants.
>
> To this end the following changes are proposed:
>
> Section 2.1. Requirements of the TSA
>
> The TSA is REQUIRED:
>
> (snip)
>
>    3.  to include a unique integer for each newly
>        generated time stamp token.
>
> In section 2.4.2. Page 8. The serialNumber is an integer assigned by
> the TSA to each Time Stamp token. It MUST be unique for each Time
> Stamp token issued by a given TSA (i.e., the TSA name and
> serialNumber identify a unique Time Stamp token).
>
> On page 8, just after the sentence: " However, when there is no need
> to have a precision better than the second, then GeneralizedTime
> with a precision limited to one second should be used (as in
> [RFC 2459]).", add the following:
>
> "When there is a need to sequence the time stamps issued from the
> same TSA at a granularity better than the second, then a greater
> precision must be used and be commensurate with the number of time
> stamps that can be generated by that TSA within the same second."
>
> There is however one major drawback with this. How can a TS user
> know if the TS token issued by a given TSA are garanteed or not to
> be ordered ? Simply looking at genTime and accuracy does not allow
> to always make the difference. So we would need another parameter
> (e.g. a BOOLEAN) :-( or use the security policy which is not
> directly machine processable. :-(
>
> The BOOLEAN would be "better", simple to understand, and allow more
> more flexibility than we have today. It is quite late to introduce
> another parameter at this stage, :-(  but if it is not now, it will
> never be. :-).
>
> If we do so, it could be after:
>
>       policy      PolicyInformation,
>
> add:
>
>      ordering     BOOLEAN DEFAULT FALSE,
>
> with the following explanations:
>
> " If the ordering field is present and set to true, Time Stamps
> tokens
> can always be ordered by looking only at the genTime parameter,
> whatever their accuracy is.
>
> If the ordering field is missing, or if the ordering field is
> present and set to false, then the genTime field only indicates the
> time at which the timestamp has been created by the TSA. In such
> a case, the ordering of Time Stamps issued by the same TSA is
> only possible when the difference between their genTime is greater
> than the accuracy of the first Time Stamp token plus the accuracy
> of the second Time Stamp token."
>
> Now, an alternative to this proposal would be to MANDATE Time stamps
> ordering (which does not appear to be a good requirement as
> explained earlier). If so we should rename the current parameter
> differently (in order to avoid confusion), like:
>
>          increasingNumber                 INTEGER,
>
> and have the following changes:
>
> Section 2.1. Requirements of the TSA
>
> The TSA is REQUIRED:
>
> (snip)
>
>    3.  to include a strictly incrementing integer for
>        each newly generated time stamp token.
>
> In section 2.4.2. Page 8. The increasingNumber field shall include a
> strictly increasing integer from one TimeStampToken to the next
> (e.g. 45, 236, 245, 1023, ...). This guarantees two properties: (1)
> When used in combination with the TSA's name the increasing number
> identifies a unique Time Stamp token. (2) It is always possible to
> compare the ordering of two time stamps from the same TSA by looking
> only at that field. This may be useful in particular when two time
> stamps from the same TSA bear the same time. It should be noticed
> that the stricly increasing numbering property must remain valid
> even after a possible interruption (e.g. crash) of the service. A
> recipient of a Time Stamp token MUST be able to handle increasing
> numbers that are up to 16-bytes.
>
> As a conclusion, at the time being, there are thus two choices.
>
> Denis
>
> > Folks,
> >
> > As I can recall, the original idea behind the SerialNumber was
> simple: to
> > preserve the ordering, and to arbitrate between timestamps
> which happen to
> > have the same time value. It itself enforces that each timestamp is now
> > unique (time+SerialNumber_within_time_interval is a unique combination),
> > though the global uniqueness of the stamps was not the initial intent.
> >
> > Considering that the original intention for the field is still
> there, let me
> > put a few short points together, to straighten things up a bit:
> >
> > Point 1: "SerialNumber" in TSA is not the same thing as the
> 2459's serial
> > number.
> >
> > Point 2: a hash can NOT be used as a serialNumber - we need some sort of
> > *integer sequentual etc numbering*.
> >
> > Point 3: Within the same time value interval, the numbering can
> be "strictly
> > monotonically incremental by one" (1,2,3,4) or more relaxed "strictly
> > monotonically increasing" (1,34,111,112,654). Both choices are perfectly
> > suitable for the purpose. But the latter is a superset of the
> former, so we
> > can use just "scrictly monotonically increasing".
> >
> > Point 4: The numbering counter can be "ever going", or start
> over with every
> > new time interval. Both choices are perfectly suitable for the
> purpose. So
> > that the draft should NOT dictate which one to be used.
> >
> > Point 5: Depending on which numbering scheme is used by the TSA, a
> > SerialNumber can reach a big value. Therefore the recepient should be
> > prepared to handle 4+ bytes integer.
> >
> > Point 6: A TSA can switch from one numbering scheme to another,
> or reset the
> > counter at its will, provided that the order (uniqueness) of
> timestamps with
> > the same time interval is preserved (not violated). This is the
> only comment
> > the draft should probably bear.
> >
> > Point 7: A unique Time+SerialNumber_within_that_interval
> combination should
> > be sufficient for audits.
> >
> > To summarize all above, the [slightly modified] statement about the
> > SerialNumber could be:
> > ***
> > The serialNumber field shall include a strictly monotonically increasing
> > integer (e.g. 45, 236, 245, 1023, ...), across all time stamps
> or at least
> > across all tokens bearing the same time value. This guarantees that each
> > token is unique and allows
> > to compare the ordering of two time stamps from the same TSA.
> This is useful
> > in particular when two time stamps from the same TSA bear the same time.
> > This field also provides the way to build a unique identifier
> to reference
> > the token. It should be noticed that the ordering is defined by the
> > combination of the time value and the SerialNumber of the tokens. The
> > ordering MUST be maintained even after a possible interruption
> (e.g. crash)
> > of the service. A recepient of a token MUST be able to handle
> serial numbers
> > that are greater than 4-bytes integers.
> >
> >
> > Regards
> > Michael
>



Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12742 for <[e-mail]>; Fri, 26 May 2000 12:48:03 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA15053; Fri, 26 May 2000 12:52:47 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <L4X9GKNH>; Fri, 26 May 2000 12:53:49 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: Paul Koning <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: SubjectAltName verification
Date: Fri, 26 May 2000 12:53:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

So what is the difference between "bound" and "definitively bound" (in a
standard isn't everything definitive)?  Also, what is the semantic
difference when the remaining words are simplified?  I fear you might be
reading in some meaning that is not there.

Warwick

-----Original Message-----
From: Paul Koning [mailto:[e-mail]]
Sent: Thursday, May 25, 2000 7:28 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: SubjectAltName verification


Echoing Paul Hoffman's comment...  I find Steve's text to be
preferable.  For one thing, retaining "definitively" seems a good
thing to do.

      paul

>>>>> "Warwick" == Warwick Ford <[e-mail]> writes:

 Warwick> With Steve's concurrence, I propose the following modified
 Warwick> wording to the clause of concern:

 Warwick> "The subject alternative name, like all other fields in a
 Warwick> certificate and all certificate extensions, is considered to
 Warwick> be bound to the public key.  Thus the CA MUST verify (in
 Warwick> accordance with the applicable certificate policy and/or the
 Warwick> CPS) all subject alternative names."

 Steve> I worry that we are unduly singling out this attribute, even
 Steve> though ALL the attributes have the same sort of
 Steve> requirement. How about:

 Steve> "The subject alternative name, like all other fields in a
 Steve> certificate and all certificate extensions, is considered to
 Steve> be definitively bound to the public key. Thus the CA MUST
 Steve> verify (directly or indirectly) all subject alternative
 Steve> names. The precise nature of the verification is detailed in
 Steve> the certificate policy and/or the CPS."


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11644 for <[e-mail]>; Fri, 26 May 2000 11:44:09 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1Q9V>; Fri, 26 May 2000 14:52:16 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Fri, 26 May 2000 14:51:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

You could still achieve your objective of maintaining ISO compatibility and
requiring global uniqueness of each TS token using only a combination of the
TSA's name and the serialNumber provided the serialNumber field itself can
be made up of a date/time component and a numbering counter that start over
with every new time interval (e.g. a day, an hour, a minute, etc.). Note
this is similar to what I had suggested in my original message on May 18,
which started this whole thread.

For this reason I support the text proposed by Michael for the serialNumber
field.

I also support your rationale for the addition of the proposed BOOLEAN on
ordering in TS tokens with a minor change as suggested below. I think if it
is missing, or if the ordering field is present and set to false, then it
should only indicate that the ordering of Time Stamps issued by the same TSA
can not be guaranteed.

In section 2.4.2. Page 8.

"If the ordering field is present and set to true, Time Stamps tokens can
always be ordered by looking only at the genTime and the serialNumber
parameters.

If the ordering field is missing, or if the ordering field is present and
set to false, then the genTime field only indicates the time at which the
timestamp has been created by the TSA. In such a case, the ordering of Time
Stamps issued by the same TSA can not be guaranteed."

Regards

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Friday, May 26, 2000 9:38 AM
To: Michael Zolotarev
Cc: [e-mail]
Subject: Re: TSA Response serialNumber Field


Michael,

Thank you for this good analysis of the issue.

The problem we have is that, currently, the serialNumber is used 
for two different purposes in order to address two different 
requirements, hence why we have some difficulties.
These requirements are the following:

1) Uniquely designate a TS token using a combination of the TSA's
name and the serialNumber. This is how serialNumber is used in RFC
2459 for both Public Key Certificates and CRLs, as well as how it is
used for Attributes Certificates, at least at the time being as
defined by ISO (and I suppose we are not going to change this). :-)

2) Distinguish betwen two time-stamps issued with the same time
(e.g. the same second).

I would propose a simple (and new) way to solve this issue: use one
parameter for one purpose only.

1) for the first requirement, stick to the use of this parameter as
required for PKCs, CRLs in RFC 2459 and for ACs. This means only 
require uniqueness and nothing else. We may then keep the name 
"serialNumber".

2) for the second requirement, let us first look at it slightly
differently. 

Today we implicitly MANDATE TSAs to be able to indicate which one of
two time stamps (e.g. issued within the same second) was first. We
could simply ALLOW TSAs to be able to indicate which one of two time
stamps (e.g. issued within the same second) was first. In many
cases, the ordering of the token will be artificial and even wrong,
in particular when the TSA is handling multiple crypto-engines in
parallel. It may be indesirable or pretty hard to try to distinguish
between who came first in a waiting queue for a given crypto-engine
and who came out first from a waiting queue for another given
crypto-engine from the same TSA. In some designs shall parallel
crypto-engines use the same clock or can they use their own clock ?
If the clock is different, how is it possible to still guarantee the
ordering ? I would not like to answer to these questions and hence
mandate designs where all TSAs MUST always guarantee the ordering.
This would prevent some implentation designs. I would rather prefer
to ALLOW TSAs to guarantee the ordering, if they wish to do so. This
is more flexible and also recognizes the fact that mandating this
requirement in some environments is not at all needed.

Now let us look how to achieve these goals:

genTime is defined as the time at which the timestamp has been
created by the TSA. It can include any *precision*. However the
accuraccy (i.e. the time difference with UTC - not the precision) is
indicated in another parameter called accuracy which represents the
time deviation around the UTC time contained in GeneralizedTime.

If a TSA wants to ALLOW users to make the difference, it may then
use a precision much better than the second (and, for example, 
still have an accuracy of one second). Otherwise it does what 
it wants.

To this end the following changes are proposed:

Section 2.1. Requirements of the TSA

The TSA is REQUIRED:

(snip)

   3.  to include a unique integer for each newly 
       generated time stamp token.

In section 2.4.2. Page 8. The serialNumber is an integer assigned by
the TSA to each Time Stamp token. It MUST be unique for each Time
Stamp token issued by a given TSA (i.e., the TSA name and
serialNumber identify a unique Time Stamp token).

On page 8, just after the sentence: " However, when there is no need
to have a precision better than the second, then GeneralizedTime
with a precision limited to one second should be used (as in 
[RFC 2459]).", add the following:

"When there is a need to sequence the time stamps issued from the
same TSA at a granularity better than the second, then a greater
precision must be used and be commensurate with the number of time
stamps that can be generated by that TSA within the same second."
  
There is however one major drawback with this. How can a TS user
know if the TS token issued by a given TSA are garanteed or not to
be ordered ? Simply looking at genTime and accuracy does not allow
to always make the difference. So we would need another parameter
(e.g. a BOOLEAN) :-( or use the security policy which is not
directly machine processable. :-(

The BOOLEAN would be "better", simple to understand, and allow more
more flexibility than we have today. It is quite late to introduce
another parameter at this stage, :-(  but if it is not now, it will
never be. :-). 

If we do so, it could be after:

      policy      PolicyInformation,

add:

     ordering     BOOLEAN DEFAULT FALSE,

with the following explanations:

" If the ordering field is present and set to true, Time Stamps
tokens
can always be ordered by looking only at the genTime parameter,
whatever their accuracy is.

If the ordering field is missing, or if the ordering field is
present and set to false, then the genTime field only indicates the
time at which the timestamp has been created by the TSA. In such 
a case, the ordering of Time Stamps issued by the same TSA is 
only possible when the difference between their genTime is greater 
than the accuracy of the first Time Stamp token plus the accuracy 
of the second Time Stamp token."

Now, an alternative to this proposal would be to MANDATE Time stamps
ordering (which does not appear to be a good requirement as
explained earlier). If so we should rename the current parameter
differently (in order to avoid confusion), like:

         increasingNumber                 INTEGER,

and have the following changes:
 
Section 2.1. Requirements of the TSA

The TSA is REQUIRED:

(snip)

   3.  to include a strictly incrementing integer for 
       each newly generated time stamp token.

In section 2.4.2. Page 8. The increasingNumber field shall include a
strictly increasing integer from one TimeStampToken to the next
(e.g. 45, 236, 245, 1023, ...). This guarantees two properties: (1)
When used in combination with the TSA's name the increasing number
identifies a unique Time Stamp token. (2) It is always possible to
compare the ordering of two time stamps from the same TSA by looking
only at that field. This may be useful in particular when two time
stamps from the same TSA bear the same time. It should be noticed
that the stricly increasing numbering property must remain valid
even after a possible interruption (e.g. crash) of the service. A
recipient of a Time Stamp token MUST be able to handle increasing
numbers that are up to 16-bytes.

As a conclusion, at the time being, there are thus two choices.

Denis

> Folks,
> 
> As I can recall, the original idea behind the SerialNumber was simple: to
> preserve the ordering, and to arbitrate between timestamps which happen to
> have the same time value. It itself enforces that each timestamp is now
> unique (time+SerialNumber_within_time_interval is a unique combination),
> though the global uniqueness of the stamps was not the initial intent.
> 
> Considering that the original intention for the field is still there, let
me
> put a few short points together, to straighten things up a bit:
> 
> Point 1: "SerialNumber" in TSA is not the same thing as the 2459's serial
> number.
>
> Point 2: a hash can NOT be used as a serialNumber - we need some sort of
> *integer sequentual etc numbering*.
> 
> Point 3: Within the same time value interval, the numbering can be
"strictly
> monotonically incremental by one" (1,2,3,4) or more relaxed "strictly
> monotonically increasing" (1,34,111,112,654). Both choices are perfectly
> suitable for the purpose. But the latter is a superset of the former, so
we
> can use just "scrictly monotonically increasing".
> 
> Point 4: The numbering counter can be "ever going", or start over with
every
> new time interval. Both choices are perfectly suitable for the purpose. So
> that the draft should NOT dictate which one to be used.
> 
> Point 5: Depending on which numbering scheme is used by the TSA, a
> SerialNumber can reach a big value. Therefore the recepient should be
> prepared to handle 4+ bytes integer.
> 
> Point 6: A TSA can switch from one numbering scheme to another, or reset
the
> counter at its will, provided that the order (uniqueness) of timestamps
with
> the same time interval is preserved (not violated). This is the only
comment
> the draft should probably bear.
> 
> Point 7: A unique Time+SerialNumber_within_that_interval combination
should
> be sufficient for audits.
> 
> To summarize all above, the [slightly modified] statement about the
> SerialNumber could be:
> ***
> The serialNumber field shall include a strictly monotonically increasing
> integer (e.g. 45, 236, 245, 1023, ...), across all time stamps or at least
> across all tokens bearing the same time value. This guarantees that each
> token is unique and allows
> to compare the ordering of two time stamps from the same TSA. This is
useful
> in particular when two time stamps from the same TSA bear the same time.
> This field also provides the way to build a unique identifier to reference
> the token. It should be noticed that the ordering is defined by the
> combination of the time value and the SerialNumber of the tokens. The
> ordering MUST be maintained even after a possible interruption (e.g.
crash)
> of the service. A recepient of a token MUST be able to handle serial
numbers
> that are greater than 4-bytes integers.
> 
> 
> Regards
> Michael


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10166 for <[e-mail]>; Fri, 26 May 2000 10:18:57 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1QXR>; Fri, 26 May 2000 13:27:03 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Rationale for Nonce in Time Stamp Protocol
Date: Fri, 26 May 2000 13:26:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

We probably need to be clear on the requirement and then we can be sure that
the text in the document reflects the requirement.

You seem quite clear that the requirement is to prevent replays - but we
need to be clear on whether we are trying to detect and/or prevent
deliberate or inadvertent replay or both.  Inadvertent replay could occur
when more than one copy of a request message gets sent to the TSA because of
problems in the intervening network elements.  In this case the TSA because
of its "no look" policy would just blindly generate time stamps for each of
the copies it receives.  Deliberate replay, on the other hand, assumes that
the TSA has been subverted or its signing key has been compromised, or that
a middleman is replaying legitimate TS responses.  Each of the various
potential replays needs to be considered to ensure that the protocol
protects against it.

1. Deliberate middleman replay.  Since each response contains a signed TS
Token which includes the message imprint, serial number and time, this type
of attack is easily detected within the currently proposed protocol.

2. Replay by subverted TSA.  A subverted TSA could generate any number of TS
Tokens containing the same message imprint at any time.  Because each could
have different serial number and/or time, each would be unique and there is
no way the client could detect a replay on the basis of the response.  The
only way this could be detected would be for every request to include a
nonce and for the client to maintain a record of all nonces generated to
verify against the responses.

3. Inadvertent replay.  Again, the only way for the client to distinguish
this type of replay would be through the use of a nonce. In this case,
however, it should not be necessary to maintain a record of all nonces
generated but only those generated within a time window as you suggest. If
the window length is set to, for example, twice the expected delay between
request and response, the client could be quite confident that there have
been no inadvertent replays if no duplicate nonce values are detected.

To summarize, the nonce should not be an optional component of replay
detection (as suggested by the current wording) - it is necessary if the
client is trying to protect against anything other than deliberate middleman
replays.

It is suggested that the wording in the fourth sentence of the second
paragraph of Section 2.2 (page 3) be changed to:

"It SHALL then verify the value of the nonce (large random number with high
probability that is generated by the client only once) included in the
response against the nonce value included in the corresponding request to
ensure that no replay has occurred."

In Section 2.4.1 remove the OPTIONAL qualifier from nonce in the definition
of TimeStampReq (page 4).

Change the wording of first sentence of the nonce description in Section
2.4.1 (page 5)to read:

"The nonce allows the client to verify the response against replay."

In Section 2.4.2 remove the OPTIONAL qualifier from nonce in the definition
of TSTInfo (page 7).

Change the wording of the nonce description in Section 2.4.2 (page 5)to
read:

"The nonce field MUST be equal to the value provided in the TimeStampReq
structure."

If you agree with this approach, then I would suggest we prepare a short
annex to describe the two different cases - subverted TSA vice inadvertent
replay.

Have a good weekend!

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, May 24, 2000 5:36 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol


Francois,

I realized that I ommited to reply to your E-mail.
 
> Salut Denis,
> 
> I do not remember if this issue was raised before, but in Section 2.2 the
> following statement is made:
> 
> "the requesting entity .... SHALL then verify the timeliness of the
response
> by verifying either the time included in the response against a local
> trusted time reference, if one is available, and/or the value of the nonce
> (large random number with a high probability that it is generated by the
> client only once) included in the response against the value included in
the
> request."
> 
> A nonce is normally used to detect attempts at replays, which is not
> necessarily related to the timeliness of the response to a particular
> request as mentioned here.
> 
> The first part of the statement talks about verifying the time included in
> the response against a locally trusted time source.  This could used to
> measure round trip path delay for calibration purposes, 

No. This is not the goal. The goal is to make sure that you have no
replay, in particular on the same hash value.

> but unless one could
> be certain that the locally trusted source is as accurate as the TSA time
> source (or, at least, that the difference between them is fixed and
> well-known), I don't see how it would detect/prevent replays. 

Using a moving time window the caller remembers all the hashes he
sent during that time window.
If there is not the same hash value within that time window, then he
makes sure that the time of the response is within the time window.
If there is the same hash (a very rare situation), it is a little
bit more complicated, and there are several options. Among them:
using the nonce, or waiting until the time window has moved to come
back to the previous case: only one hash value during that time
window. But we are talking implementations details, which is not the
topic of an RFC.

>  If one has
> such a trusted time source locally, what is the point in using a TTP for
> time stamping?

The time is locally trusted, ... which does not mean that other
people will trust that time.

> 
> Could you please clarify the intent of this statement and if the intent is
> to prevent replays or check the timeliness of responses or both?

Now, that you have the explanations, if you still believe that the
text is not clear enough, I suggest that you submit a proposal to
clarify the text.

Regards,

Denis

> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]


Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08038 for <[e-mail]>; Fri, 26 May 2000 08:43:42 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA25270 for <[e-mail]>; Fri, 26 May 2000 11:45:09 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 26 May 2000 11:47:41 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Encrypting private keys - how do you achieve this in practice?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ldJJVH1qPkuDwazA2ooMOQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Christopher,

If your implementation always exports password-protected private
keys, and you don't want to (or can't, because it's in hardware)
touch the existing code, then you could just put some glue
around the module to unwrap the key with the password and
then wrap the plaintext key for the intended recipient in an
EnvelopedData structure, using
PKIArchiveOptions:encryptedPrivKey:envelopedData. Put the private key
in EnvelopedData:encryptedContentInfo:encryptedContent and set
EnvelopedData:encryptedContentInfo:contentType to id-data.

It isn't recommended (at least by me) to place a password-wrapped
private key directly in PKIArchiveOptions:encryptedPrivKey:encryptedValue.
But the straightforward approach to doing so would be to populate:

encryptedValue:symmAlg   - ???
encryptedValue:encValue  - BER of EncryptedPrivateKeyInfo

Fortunately, PKCS#8 does not define an OID for EncryptedPrivateKeyInfo,
as they obviously felt that this structure is never suitable for use
within another protocol :-).

Dave




> From: "Christopher Williams" <[e-mail]>
> To: "PKIX Mailing List" <[e-mail]>
> Subject: Encrypting private keys - how do you achieve this in practice?
> Date: Fri, 26 May 2000 11:35:06 +0100
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> 
> When you encrypt a private key to put it in the EncryptedValue structure, it
> appears from the standard that you take the private key octets as the plain
> text and encrypt under the symmetric algorithm / symmetric key, etc.
> 
> There's a problem here.  Our implementation of RSA / DSA / DH, etc. does not
> give out private keys in plain text and I guess that many other
> implementations are the same.  We do support password wrapping of the
> private key (e.g. PKCS#8) but the EncryptedValue structure does not seem to
> be designed to take a password-wrapped key.
> 
> How do you reconcile PKCS#8 with the EncryptedValue structure?  For example,
> I guess that you could supply the password as the symmetric key and encode
> the EncryptedPrivateKeyInfo structure as a bit string, but what would then
> be the symmetric algorithm?
> 
> How have other people implemented private key encryption?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06301 for <[e-mail]>; Fri, 26 May 2000 07:09:18 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA42744; Fri, 26 May 2000 16:16:21 +0200
Message-ID: <[e-mail]>
Date: Fri, 26 May 2000 16:16:24 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]> <3.0.5.32.20000526155201.039ee160@callisto>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Juergen,

Good remark. However, the parameter is called cRLNumber, not
serialNumber, hence no confusion. :-)

Denis

 
> At 15:38 26.05.00 +0200, Denis Pinkas wrote:
> >1) for the first requirement, stick to the use of this parameter as
> >required for PKCs, CRLs in RFC 2459 and for ACs. This means only
> >require uniqueness and nothing else. We may then keep the name
> >"serialNumber".
> 
> Just a short remark: CRL serialnumbers (=the cRLNumber extension) are
> required to be monotonically increasing.
> "5.2.3  CRL Number
>    The CRL number is a non-critical CRL extension which conveys a
>    monotonically increasing sequence number for each CRL issued by a CA.
> "
> 
> Regards
>    Juergen
> --
> Juergen Brauckmann             Tel.:  040 / 8080 26 311
> TC TrustCenter GmbH            Fax.:  040 / 8080 26 126
> Sonninstraße 24-28          mailto:[e-mail]
> 20097 Hamburg               http://www.trustcenter.de


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06205 for <[e-mail]>; Fri, 26 May 2000 07:07:02 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1Q2H>; Fri, 26 May 2000 10:15:07 -0400
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Encrypting private keys - how do you achieve this in practice ?
Date: Fri, 26 May 2000 10:14:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Christopher,

This is why I ask a similar question to Carlisle yesterday.

I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is
being used in reality in the EncryptedValue structure since it is also what
Section 11.9 of PKCS#11 v2.01 mandates for wrapping a private key:

"Cryptoki Version 2.01 allows the use of secret keys for wrapping and
unwrapping RSA private keys, Diffie-Hellman private keys, and DSA private
keys. For wrapping, a private key is BER-encoded according to PKCS #8's
PrivateKeyInfo ASN.1 type."

This way, as mandated by Appendix B2 of RFC 2510bis, a PKCS#8 encoded
private key would be wrap using the PROT_SYM_ALG symmetric encryption
algorithm (e.g. 3-DES, 3-key-EDE, CBC mode) and not a password wrapping as
you suggested. The symmetric key is then encrypted using a previously agreed
PROT_ENC_ALG asymmetric algorithm (e.g. Diffie-Hellman, RSA).

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


-----Original Message-----
From: Christopher Williams [mailto:[e-mail]]
Sent: Friday, May 26, 2000 6:35 AM
To: PKIX Mailing List
Subject: Encrypting private keys - how do you achieve this in practice?


When you encrypt a private key to put it in the EncryptedValue structure, it
appears from the standard that you take the private key octets as the plain
text and encrypt under the symmetric algorithm / symmetric key, etc.

There's a problem here.  Our implementation of RSA / DSA / DH, etc. does not
give out private keys in plain text and I guess that many other
implementations are the same.  We do support password wrapping of the
private key (e.g. PKCS#8) but the EncryptedValue structure does not seem to
be designed to take a password-wrapped key.

How do you reconcile PKCS#8 with the EncryptedValue structure?  For example,
I guess that you could supply the password as the symmetric key and encode
the EncryptedPrivateKeyInfo structure as a bit string, but what would then
be the symmetric algorithm?

How have other people implemented private key encryption?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com


Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA05647 for <[e-mail]>; Fri, 26 May 2000 06:46:03 -0700 (PDT)
Received: by mystic1.trustcenter.de; id PAA27216; Fri, 26 May 2000 15:51:30 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma027212; Fri, 26 May 00 15:50:39 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id PAA11724 for <[e-mail]>; Fri, 26 May 2000 15:52:01 +0200 (MET DST)
Message-Id: <3.0.5.32.20000526155201.039ee160@callisto>
X-Sender: jbr@callisto
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 26 May 2000 15:52:01 +0200
To: [e-mail]
From: Juergen Brauckmann <[e-mail]>
Subject: Re: TSA Response serialNumber Field
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA05648

At 15:38 26.05.00 +0200, Denis Pinkas wrote:
>1) for the first requirement, stick to the use of this parameter as
>required for PKCs, CRLs in RFC 2459 and for ACs. This means only 
>require uniqueness and nothing else. We may then keep the name 
>"serialNumber".

Just a short remark: CRL serialnumbers (=the cRLNumber extension) are
required to be monotonically increasing. 
"5.2.3  CRL Number
   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.
"

Regards
   Juergen
-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC TrustCenter GmbH            Fax.:  040 / 8080 26 126
Sonninstraße 24-28   	    mailto:[e-mail]
20097 Hamburg 		    http://www.trustcenter.de	


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04651 for <[e-mail]>; Fri, 26 May 2000 06:31:16 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA14982; Fri, 26 May 2000 15:38:24 +0200
Message-ID: <[e-mail]>
Date: Fri, 26 May 2000 15:38:26 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Zolotarev <[e-mail]>
CC: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael,

Thank you for this good analysis of the issue.

The problem we have is that, currently, the serialNumber is used 
for two different purposes in order to address two different 
requirements, hence why we have some difficulties.
These requirements are the following:

1) Uniquely designate a TS token using a combination of the TSA's
name and the serialNumber. This is how serialNumber is used in RFC
2459 for both Public Key Certificates and CRLs, as well as how it is
used for Attributes Certificates, at least at the time being as
defined by ISO (and I suppose we are not going to change this). :-)

2) Distinguish betwen two time-stamps issued with the same time
(e.g. the same second).

I would propose a simple (and new) way to solve this issue: use one
parameter for one purpose only.

1) for the first requirement, stick to the use of this parameter as
required for PKCs, CRLs in RFC 2459 and for ACs. This means only 
require uniqueness and nothing else. We may then keep the name 
"serialNumber".

2) for the second requirement, let us first look at it slightly
differently. 

Today we implicitly MANDATE TSAs to be able to indicate which one of
two time stamps (e.g. issued within the same second) was first. We
could simply ALLOW TSAs to be able to indicate which one of two time
stamps (e.g. issued within the same second) was first. In many
cases, the ordering of the token will be artificial and even wrong,
in particular when the TSA is handling multiple crypto-engines in
parallel. It may be indesirable or pretty hard to try to distinguish
between who came first in a waiting queue for a given crypto-engine
and who came out first from a waiting queue for another given
crypto-engine from the same TSA. In some designs shall parallel
crypto-engines use the same clock or can they use their own clock ?
If the clock is different, how is it possible to still guarantee the
ordering ? I would not like to answer to these questions and hence
mandate designs where all TSAs MUST always guarantee the ordering.
This would prevent some implentation designs. I would rather prefer
to ALLOW TSAs to guarantee the ordering, if they wish to do so. This
is more flexible and also recognizes the fact that mandating this
requirement in some environments is not at all needed.

Now let us look how to achieve these goals:

genTime is defined as the time at which the timestamp has been
created by the TSA. It can include any *precision*. However the
accuraccy (i.e. the time difference with UTC - not the precision) is
indicated in another parameter called accuracy which represents the
time deviation around the UTC time contained in GeneralizedTime.

If a TSA wants to ALLOW users to make the difference, it may then
use a precision much better than the second (and, for example, 
still have an accuracy of one second). Otherwise it does what 
it wants.

To this end the following changes are proposed:

Section 2.1. Requirements of the TSA

The TSA is REQUIRED:

(snip)

   3.  to include a unique integer for each newly 
       generated time stamp token.

In section 2.4.2. Page 8. The serialNumber is an integer assigned by
the TSA to each Time Stamp token. It MUST be unique for each Time
Stamp token issued by a given TSA (i.e., the TSA name and
serialNumber identify a unique Time Stamp token).

On page 8, just after the sentence: " However, when there is no need
to have a precision better than the second, then GeneralizedTime
with a precision limited to one second should be used (as in 
[RFC 2459]).", add the following:

"When there is a need to sequence the time stamps issued from the
same TSA at a granularity better than the second, then a greater
precision must be used and be commensurate with the number of time
stamps that can be generated by that TSA within the same second."
  
There is however one major drawback with this. How can a TS user
know if the TS token issued by a given TSA are garanteed or not to
be ordered ? Simply looking at genTime and accuracy does not allow
to always make the difference. So we would need another parameter
(e.g. a BOOLEAN) :-( or use the security policy which is not
directly machine processable. :-(

The BOOLEAN would be "better", simple to understand, and allow more
more flexibility than we have today. It is quite late to introduce
another parameter at this stage, :-(  but if it is not now, it will
never be. :-). 

If we do so, it could be after:

      policy      PolicyInformation,

add:

     ordering     BOOLEAN DEFAULT FALSE,

with the following explanations:

" If the ordering field is present and set to true, Time Stamps
tokens
can always be ordered by looking only at the genTime parameter,
whatever their accuracy is.

If the ordering field is missing, or if the ordering field is
present and set to false, then the genTime field only indicates the
time at which the timestamp has been created by the TSA. In such 
a case, the ordering of Time Stamps issued by the same TSA is 
only possible when the difference between their genTime is greater 
than the accuracy of the first Time Stamp token plus the accuracy 
of the second Time Stamp token."

Now, an alternative to this proposal would be to MANDATE Time stamps
ordering (which does not appear to be a good requirement as
explained earlier). If so we should rename the current parameter
differently (in order to avoid confusion), like:

         increasingNumber                 INTEGER,

and have the following changes:
 
Section 2.1. Requirements of the TSA

The TSA is REQUIRED:

(snip)

   3.  to include a strictly incrementing integer for 
       each newly generated time stamp token.

In section 2.4.2. Page 8. The increasingNumber field shall include a
strictly increasing integer from one TimeStampToken to the next
(e.g. 45, 236, 245, 1023, ...). This guarantees two properties: (1)
When used in combination with the TSA's name the increasing number
identifies a unique Time Stamp token. (2) It is always possible to
compare the ordering of two time stamps from the same TSA by looking
only at that field. This may be useful in particular when two time
stamps from the same TSA bear the same time. It should be noticed
that the stricly increasing numbering property must remain valid
even after a possible interruption (e.g. crash) of the service. A
recipient of a Time Stamp token MUST be able to handle increasing
numbers that are up to 16-bytes.

As a conclusion, at the time being, there are thus two choices.

Denis

> Folks,
> 
> As I can recall, the original idea behind the SerialNumber was simple: to
> preserve the ordering, and to arbitrate between timestamps which happen to
> have the same time value. It itself enforces that each timestamp is now
> unique (time+SerialNumber_within_time_interval is a unique combination),
> though the global uniqueness of the stamps was not the initial intent.
> 
> Considering that the original intention for the field is still there, let me
> put a few short points together, to straighten things up a bit:
> 
> Point 1: "SerialNumber" in TSA is not the same thing as the 2459's serial
> number.
>
> Point 2: a hash can NOT be used as a serialNumber - we need some sort of
> *integer sequentual etc numbering*.
> 
> Point 3: Within the same time value interval, the numbering can be "strictly
> monotonically incremental by one" (1,2,3,4) or more relaxed "strictly
> monotonically increasing" (1,34,111,112,654). Both choices are perfectly
> suitable for the purpose. But the latter is a superset of the former, so we
> can use just "scrictly monotonically increasing".
> 
> Point 4: The numbering counter can be "ever going", or start over with every
> new time interval. Both choices are perfectly suitable for the purpose. So
> that the draft should NOT dictate which one to be used.
> 
> Point 5: Depending on which numbering scheme is used by the TSA, a
> SerialNumber can reach a big value. Therefore the recepient should be
> prepared to handle 4+ bytes integer.
> 
> Point 6: A TSA can switch from one numbering scheme to another, or reset the
> counter at its will, provided that the order (uniqueness) of timestamps with
> the same time interval is preserved (not violated). This is the only comment
> the draft should probably bear.
> 
> Point 7: A unique Time+SerialNumber_within_that_interval combination should
> be sufficient for audits.
> 
> To summarize all above, the [slightly modified] statement about the
> SerialNumber could be:
> ***
> The serialNumber field shall include a strictly monotonically increasing
> integer (e.g. 45, 236, 245, 1023, ...), across all time stamps or at least
> across all tokens bearing the same time value. This guarantees that each
> token is unique and allows
> to compare the ordering of two time stamps from the same TSA. This is useful
> in particular when two time stamps from the same TSA bear the same time.
> This field also provides the way to build a unique identifier to reference
> the token. It should be noticed that the ordering is defined by the
> combination of the time value and the SerialNumber of the tokens. The
> ordering MUST be maintained even after a possible interruption (e.g. crash)
> of the service. A recepient of a token MUST be able to handle serial numbers
> that are greater than 4-bytes integers.
> 
> 
> Regards
> Michael


Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20695 for <[e-mail]>; Fri, 26 May 2000 03:26:33 -0700 (PDT)
Received: from darxstar ([62.252.200.33]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000526103351.VTJS290.mta03-svc.ntlworld.com@darxstar> for <[e-mail]>; Fri, 26 May 2000 11:33:51 +0100
Message-ID: <002e01bfc6fe$70e8c8c0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Encrypting private keys - how do you achieve this in practice?
Date: Fri, 26 May 2000 11:35:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

When you encrypt a private key to put it in the EncryptedValue structure, it
appears from the standard that you take the private key octets as the plain
text and encrypt under the symmetric algorithm / symmetric key, etc.

There's a problem here.  Our implementation of RSA / DSA / DH, etc. does not
give out private keys in plain text and I guess that many other
implementations are the same.  We do support password wrapping of the
private key (e.g. PKCS#8) but the EncryptedValue structure does not seem to
be designed to take a password-wrapped key.

How do you reconcile PKCS#8 with the EncryptedValue structure?  For example,
I guess that you could supply the password as the symmetric key and encode
the EncryptedPrivateKeyInfo structure as a bit string, but what would then
be the symmetric algorithm?

How have other people implemented private key encryption?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from buffy.tpgi.com.au (buffy.tpgi.com.au [203.12.160.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12554 for <[e-mail]>; Fri, 26 May 2000 02:42:02 -0700 (PDT)
From: [e-mail]
Received: (from smtpd@localhost) by buffy.tpgi.com.au (8.9.3/8.9.3) id TAA01564 for <[e-mail]>; Fri, 26 May 2000 19:49:20 +1000
Date: Fri, 26 May 2000 19:49:20 +1000
Message-Id: <[e-mail]>
Received: from syd3-56k-150.tpgi.com.au(203.29.148.150), claiming to be "home" via SMTP by buffy.tpgi.com.au, id smtpdQp9Ycz; Fri May 26 19:49:11 2000
To: [e-mail]
X-Mailer: 6D559AED.5C036C2E.050f5278980406d9d1e3143a14e56baf
Subject: Open Mind
Organization: Animation Allsorts

I have discovered your webside on the Internet and find it
really interesting.I do believe that you or your clients may
benefit from the information we are offering. 

There are a lot of people trying to get rich quick, without 
any interest in another human being whatsoever. Well, I 
doubt that they will succeed. There is a law in success like 
there is a law in physics.

You may not believe in gravity or not know about it, but it still works.

The Law of Success says: 
If you help enough people to get what they want, 
You will get what You want.

Therefore, if you think, that you may gain and discover a benefit
for yourself, click on:

http://www.animationallsorts.com/00-Main-Journey.htm

or you can have a look at our Newsletter to find out if you can
benefit from it:

http://www.animationallsorts.com/NEWSLETER/April-00/NLetter-index.htm

Don't hesitate to forward a copy of this newsletter to friends
and associates, but please ask for permission before reproducing
the content in any form -- we would like to know who you are.

Pavel Kyral
Director

Animation Allsorts - Open Mind
105/3 Bruce Street, Crows Nest, NSW, 2065, Australia 
Phone: [phone] | Fax: [phone] 
Copyright © 1990-2000 All Rights Reserved

If you think, that you will not benefit from this corespondence, send

an email to:

[e-mail]	Subject:Remove gravity



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28737 for <[e-mail]>; Thu, 25 May 2000 22:34:25 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id PAA08588; Fri, 26 May 2000 15:46:03 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <L45KCZ6R>; Fri, 26 May 2000 15:40:04 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Paul Koning <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: TSA Response serialNumber Field
Date: Fri, 26 May 2000 15:40:03 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Folks,

As I can recall, the original idea behind the SerialNumber was simple: to
preserve the ordering, and to arbitrate between timestamps which happen to
have the same time value. It itself enforces that each timestamp is now
unique (time+SerialNumber_within_time_interval is a unique combination),
though the global uniqueness of the stamps was not the initial intent.

Considering that the original intention for the field is still there, let me
put a few short points together, to straighten things up a bit:

Point 1: "SerialNumber" in TSA is not the same thing as the 2459's serial
number. 

Point 2: a hash can NOT be used as a serialNumber - we need some sort of
*integer sequentual etc numbering*.

Point 3: Within the same time value interval, the numbering can be "strictly
monotonically incremental by one" (1,2,3,4) or more relaxed "strictly
monotonically increasing" (1,34,111,112,654). Both choices are perfectly
suitable for the purpose. But the latter is a superset of the former, so we
can use just "scrictly monotonically increasing".

Point 4: The numbering counter can be "ever going", or start over with every
new time interval. Both choices are perfectly suitable for the purpose. So
that the draft should NOT dictate which one to be used. 

Point 5: Depending on which numbering scheme is used by the TSA, a
SerialNumber can reach a big value. Therefore the recepient should be
prepared to handle 4+ bytes integer.

Point 6: A TSA can switch from one numbering scheme to another, or reset the
counter at its will, provided that the order (uniqueness) of timestamps with
the same time interval is preserved (not violated). This is the only comment
the draft should probably bear. 

Point 7: A unique Time+SerialNumber_within_that_interval combination should
be sufficient for audits.


To summarize all above, the [slightly modified] statement about the
SerialNumber could be: 
***
The serialNumber field shall include a strictly monotonically increasing
integer (e.g. 45, 236, 245, 1023, ...), across all time stamps or at least
across all tokens bearing the same time value. This guarantees that each
token is unique and allows 
to compare the ordering of two time stamps from the same TSA. This is useful
in particular when two time stamps from the same TSA bear the same time.
This field also provides the way to build a unique identifier to reference
the token. It should be noticed that the ordering is defined by the
combination of the time value and the SerialNumber of the tokens. The
ordering MUST be maintained even after a possible interruption (e.g. crash)
of the service. A recepient of a token MUST be able to handle serial numbers
that are greater than 4-bytes integers.
***

Regards
Michael


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21042 for <[e-mail]>; Thu, 25 May 2000 16:07:23 -0700 (PDT)
Received: from [128.33.238.70] (TC070.BBN.COM [128.33.238.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA04657; Thu, 25 May 2000 19:14:21 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220804b5534df54672@[128.33.238.61]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04220806b552fcd5851e@[171.78.30.107]> <[e-mail]>
Date: Thu, 25 May 2000 17:42:08 -0400
To: Paul Koning <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Paul,


>Better yet, perhaps we need to revisit what requirement prompted the
>inclusion of this message component.\

Agreed.

>
>If it is to distinguish one timestamp from another, the requirement
>stated should be uniqueness, no more.

no, its more than that, I think.

>
>If it is to distinguish one timestamp from another for the case where
>the time values are identical, the requirement should be just that.

still more.

>If the requirement is to let you order the timestamps that have the
>same time value, then the requirement should be that the value is
>increasing over that scope.

I think this is the requirement Denis had in mind, and that others 
did, based on the traffic from some time ago.

>
>If the requirement is a total order (regardless of time value) then
>the requirement should be "increasing".

This satisfies the previous requirement, but is more stringent.  it 
is what is required now, but maybe it's overkill, modulo the 
potential benefits I ascribed to a 1-up counter used here.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20997 for <[e-mail]>; Thu, 25 May 2000 16:07:04 -0700 (PDT)
Received: from [128.33.238.70] (TC070.BBN.COM [128.33.238.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA04652; Thu, 25 May 2000 19:14:10 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220803b5534d78293b@[128.33.238.61]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 25 May 2000 17:38:25 -0400
To: Eric Norman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Eric,

Whoops, you're right.  No requirement for the sequence to increment 
by 1 each time.  Of course, the benefits I cited for such an 
increment are lost in the more general case.

Steve


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18301 for <[e-mail]>; Thu, 25 May 2000 12:34:09 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <LQWY1PLD>; Thu, 25 May 2000 15:42:10 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Encryption of Private Keys in CRMF and CMP
Date: Thu, 25 May 2000 15:41:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Carlisle,

In Section 6.4 of RFC 2511 on CRMF, it is indicated that the EncryptedValue
field "encValue" is a BIT STRING, however I could not find any further
detail in RFC 2511 nor in RFC 2510bis, which also use this syntax, about how
to create this encrypted value (restricted, in RFC 2510bis, to be either
private keys or certificates).

Am I missing something?

I understand that RFC 2511 EncryptedValue field "symmAlg" tells me the
symmetric algorithm that was used to encrypt a private key value and that
Appendix B2 of RFC 2510bis mandates that conforming implementations MUST
support 3-DES (3-key-EDE, CBC mode) for this. However, this does not tell me
what exactly is being encrypted.

Is it a type "PrivateKeyInfo" from Section 6 of PKCS#8 or a type
"RSAPrivateKey" from Section 11.1.2 of PKCS#1 for a RSA private key since
RFC 2511 EncryptedValue field "intendedAlg" already tell me the intended
algorithm for which the private key will be used for? 

Thanks in advance for any help.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16138 for <[e-mail]>; Thu, 25 May 2000 10:37:02 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA04042; Thu, 25 May 2000 10:41:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 25 May 2000 10:45:14 -0700
To: Peter Sylvester <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:34 PM 5/25/00 +0200, Peter Sylvester wrote:
> > Peter,
> >
> > >Steve,
> > >
> > >Hm, the actual text says:
> > >
> > >     'strictly monotonical increasing'.
> > >
> > >At least the example in the text about non-consecutive
> > >number is there.
> >
> > The text I was referring to in the TSP draft states:
> >
> > 3.  to include a monotonically incrementing integer for each
> >           newly generated time stamp token.
> >
> > "Monotonically increasing" means that the counter increments by
> > exactly one each time.  If it is not an increment by one, a phrase
> > such as "strictly increasing"
> > would be appropriate.
>
>"Monotonically increasing" means that a sequence is
>monotonical, thus either always non-decreasing or non-increasing,
>and increasing selects one of the possibilities. "Strictly"
>means that you never have two numbers twice.

Precisely.

Put another way, the sequence of differences never changes sign.
(Zero excluded as a "sign change".  Where zero IS included as a
sign change, one gets the "strictly monotonic" definition.)

>I don't know what 'monotonically INCREMENTING" could mean. :-)

It would be useful to have a term for "must increase by one."
Perhaps "unitarily increasing" ;)

___tony___


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



Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15525 for <[e-mail]>; Thu, 25 May 2000 10:08:51 -0700 (PDT)
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.2.4) with ESMTP id 2067074 for [e-mail]; Thu, 25 May 2000 12:16:06 -0500
Date: Thu, 25 May 2000 12:16:06 -0500 (CDT)
From: Eric Norman <[e-mail]>
To: [e-mail]
Subject: Re: TSA Response serialNumber Field
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 25 May 2000, Peter Sylvester wrote:

> "Monotonically increasing" means that a sequence is
> monotonical, thus either always non-decreasing or non-increasing,
> and increasing selects one of the possibilities. "Strictly"
> means that you never have two numbers twice.

For what it's worth, a math major and someone who considers himself
a mathematician will chime in and point out the the above is
essentially correct.  In particular, "monotonic" DOES NOT imply
"increase by one".

And now, to tell you more than you wanted to know, the word
"monotonic" is actually an adjective that is applied to functions.
A function F is call monotonic if it is order preserving; that
means that if x <= y, then then F(x) <= F(y).

I return you now to your regular discussion about the real issues.

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".




Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15163 for <[e-mail]>; Thu, 25 May 2000 09:52:18 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA01424 for <[e-mail]>; Thu, 25 May 2000 12:53:51 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 25 May 2000 12:56:18 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: SubjectAltName verification
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: n3OxXH3zWqdc8OkFKoHPGA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Peter,

You seem intent on reaffirming the validity of the text quoted from
RFC2459.  But to what end?

> Internet CAs are free, and must be free, to operate public-key
> certification according to wholly-private practices. This includes 
> acting in PKIX-non-conforming or other PKIX opt-out manners, where
> (nationally-regulated) CAs and such CA's alone designate such practices 
> to be appropriate to meet their interworking communities security needs.

There is not much to disagree with in the above, except for the first
word.  If your interpretation of "Internet CA" is merely a private CA
which uses the Internet as a common carrier to communicate with its
customers, no problem.  But if an "Internet CA" is one which complies
with (i.e. does not opt-out from) Internet standards, it is perverse
to argue that:

  1) CA X acts in a PKIX-non-conforming manner, i.e. by performing
      no validation on some fields of its issued certificates
  2) RFC 2459 says "some communities may replace this profile ..."
  3) ergo CA X complies with RFC 2459 and is thus entitled to
     describe itself as an "Internet CA".

Surely you weren't pursuing that line of reasoning.

But in case you were, you will need to demonstrate that including
NVI in certificates meets the test of RFC 2459 to support
"additional authorization, assurance, or operational requirements".

In other words, RFC 2459 says you can do more than the basics.  But
you can't do less and still validly claim to be an Internet CA.

Dave




> From: Peter Williams <[e-mail]>
> 
> (1) You should realize that the text I quoted, repeated below from your
> reply, is from RFC 2459.
> 
> >    "Some communities will need to supplement, or possibly replace, this
> >    profile in order to meet the requirements of specialized application
> >    domains or environments with additional authorization, assurance, or
> >    operational requirements.  However, for basic applications, common
> >    representations of frequently used attributes are defined so that
> >    application developers can obtain necessary information without
> >    regard to the issuer of a particular certificate or certificate revo-
> >    cation list (CRL)." [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt]



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14589 for <[e-mail]>; Thu, 25 May 2000 09:26:56 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA14490; Thu, 25 May 2000 18:34:07 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 25 May 2000 18:34:07 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA12716; Thu, 25 May 2000 18:34:05 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA03571; Thu, 25 May 2000 18:34:05 +0200 (MET DST)
Date: Thu, 25 May 2000 18:34:05 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]

> Peter,
> 
> >Steve,
> >
> >Hm, the actual text says:
> >
> >     'strictly monotonical increasing'.
> >
> >At least the example in the text about non-consecutive
> >number is there.
> 
> The text I was referring to in the TSP draft states:
> 
> 3.  to include a monotonically incrementing integer for each
>           newly generated time stamp token.
> 
> "Monotonically increasing" means that the counter increments by 
> exactly one each time.  If it is not an increment by one, a phrase 
> such as "strictly increasing"
> would be appropriate.

"Monotonically increasing" means that a sequence is
monotonical, thus either always non-decreasing or non-increasing,
and increasing selects one of the possibilities. "Strictly"
means that you never have two numbers twice.

At least that is what I recall from initial math courses.  

I don't know what 'monotonically INCREMENTING" could mean. :-)


> 
> >
> >What you are asking for is to create consecutive time stamps.
> 
> Well, the time value will not be consecutive, which is why I though 
> Denis specified that the counter would be.  There can be legitimate 
> gaps in the time values.
Denis did not specify that. Just see the example. 

> 
> >
> >What you indicate is not mentioned in the text at all in the
> >text, maybe it was intended at some time (the usage of
> >'monotonically incrementing' may be an indication).
> >Maybe the original author's can comment on that.
> >
> >Your point is an interesting one. This is ONE method, if a TSA
> >is able and willing to increment by one, they can do that.
> 
> Yes, it's just one method. I assumed that it might have been 
> specified because its cheap to do and not patented, etc.
I guess I get your point :-)

> 
> >But that doesn't help,  a TSA can replace any stamp
> >and then claim in 30 years that the key was corrupted.
> >
> >If you imagine the possibility not to trust the TSA,*
> >then you might require that the TSA stores all stamps with
> >a notary, or whatever else third/forth/fifth tp to store
> >a complete archive of all tokens.
> 
> Elsewhere the document talks about recovery from a possible key 
> compromise and says:
> 
> . When the TSA private key has been compromised, then the
>          corresponding certificate SHALL be revoked. In this case,
>          any token signed by the TSA using that private key cannot
>          be trusted anymore.  For this reason, it is imperative that
>          the TSA's private key be guarded with proper security and
>          controls in order to minimize the possibility of compromise.
>          In case the private key does become compromised, an audit
>          trail of all tokens generated by the TSA MAY provide a means
>          to discriminate between genuine and false backdated tokens.
> 
> By sequentially numbering the TSTs, there may be some further 
> protection against back dating an audit log, but maybe this is such a 
> small added feature that it's not worth pursuing.

The problem was that this feature may be difficult to implement, and
in fact it doesn't solve anything. A TSA can easily generate random
hash numbers and time stamp them, and store them. This means they
can produce an audit trail that everything behaved in a +1 way
if you ask them. Nevertheless, since they have been the only ones
that have ever seen the radom stamps, they can still remove them
whenever you want. 

If you don't trust a TSA, you need someone else. 


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14255 for <[e-mail]>; Thu, 25 May 2000 09:13:27 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqsn04950; Thu, 25 May 2000 16:20:40 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08851; Thu, 25 May 00 12:17:12 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA11944; Thu, 25 May 2000 12:20:38 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 25 May 2000 12:20:38 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]> <v04220806b552fcd5851e@[171.78.30.107]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:

 Stephen> Peter,
 >> Steve, Hm, the actual text says: 'strictly monotonical
 >> increasing'.  At least the example in the text about
 >> non-consecutive number is there.

 Stephen> The text I was referring to in the TSP draft states:

 Stephen> 3.  to include a monotonically incrementing integer for each
 Stephen> newly generated time stamp token.

 Stephen> "Monotonically increasing" means that the counter increments
 Stephen> by exactly one each time.  If it is not an increment by one,
 Stephen> a phrase such as "strictly increasing" would be appropriate.

Well, it says "monotonically incrementing" not "increasing".

I'm not at all sure this terminology implies consecutive values must
be used.  Then again, I view "monotonically" as a rhetorical flourish,
"increasing" is sufficient.  (Note that "increasing" is not a synonym
for "non-decreasing".)

What possible value would be served by a requirement that the numbers
must be consecutive?  I can see no possible use that anyone could make
of this, given that we live in a datagram world.  That being the case,
there shouldn't be such a requirement.

Better yet, perhaps we need to revisit what requirement prompted the
inclusion of this message component.

If it is to distinguish one timestamp from another, the requirement
stated should be uniqueness, no more.

If it is to distinguish one timestamp from another for the case where
the time values are identical, the requirement should be just that.

If the requirement is to let you order the timestamps that have the
same time value, then the requirement should be that the value is
increasing over that scope.

If the requirement is a total order (regardless of time value) then
the requirement should be "increasing".

Etc...

	paul



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13959 for <[e-mail]>; Thu, 25 May 2000 09:04:54 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA13008; Thu, 25 May 2000 12:11:55 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220806b552fcd5851e@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 25 May 2000 12:11:48 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1252851303==_ma============"

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

Peter,

>Steve,
>
>Hm, the actual text says:
>
>     'strictly monotonical increasing'.
>
>At least the example in the text about non-consecutive
>number is there.

The text I was referring to in the TSP draft states:

3.  to include a monotonically incrementing integer for each
          newly generated time stamp token.

"Monotonically increasing" means that the counter increments by 
exactly one each time.  If it is not an increment by one, a phrase 
such as "strictly increasing"
would be appropriate.

>
>What you are asking for is to create consecutive time stamps.

Well, the time value will not be consecutive, which is why I though 
Denis specified that the counter would be.  There can be legitimate 
gaps in the time values.

>
>What you indicate is not mentioned in the text at all in the
>text, maybe it was intended at some time (the usage of
>'monotonically incrementing' may be an indication).
>Maybe the original author's can comment on that.
>
>Your point is an interesting one. This is ONE method, if a TSA
>is able and willing to increment by one, they can do that.

Yes, it's just one method. I assumed that it might have been 
specified because its cheap to do and not patented, etc.

>But that doesn't help,  a TSA can replace any stamp
>and then claim in 30 years that the key was corrupted.
>
>If you imagine the possibility not to trust the TSA,*
>then you might require that the TSA stores all stamps with
>a notary, or whatever else third/forth/fifth tp to store
>a complete archive of all tokens.

Elsewhere the document talks about recovery from a possible key 
compromise and says:

. When the TSA private key has been compromised, then the
         corresponding certificate SHALL be revoked. In this case,
         any token signed by the TSA using that private key cannot
         be trusted anymore.  For this reason, it is imperative that
         the TSA's private key be guarded with proper security and
         controls in order to minimize the possibility of compromise.
         In case the private key does become compromised, an audit
         trail of all tokens generated by the TSA MAY provide a means
         to discriminate between genuine and false backdated tokens.

By sequentially numbering the TSTs, there may be some further 
protection against back dating an audit log, but maybe this is such a 
small added feature that it's not worth pursuing.

Steve

--============_-1252851303==_ma============
Content-Type: text/enriched; charset="us-ascii"

Peter,


<excerpt>Steve,


Hm, the actual text says:


    'strictly monotonical increasing'. 


At least the example in the text about non-consecutive

number is there. 

</excerpt>

The text I was referring to in the TSP draft states:


<bigger>3.  to include a monotonically incrementing integer for each 

         newly generated time stamp token.


</bigger>"Monotonically increasing" means that the counter increments
by exactly one each time.  If it is not an increment by one, a phrase
such as "strictly increasing"

would be appropriate. 


<excerpt>

What you are asking for is to create consecutive time stamps.

</excerpt>

Well, the time value will not be consecutive, which is why I though
Denis specified that the counter would be.  There can be legitimate
gaps in the time values.


<excerpt>

What you indicate is not mentioned in the text at all in the

text, maybe it was intended at some time (the usage of 

'monotonically incrementing' may be an indication).

Maybe the original author's can comment on that.


Your point is an interesting one. This is ONE method, if a TSA

is able and willing to increment by one, they can do that. 

</excerpt>

Yes, it's just one method. I assumed that it might have been specified
because its cheap to do and not patented, etc.


<excerpt>But that doesn't help,  a TSA can replace any stamp

and then claim in 30 years that the key was corrupted.


If you imagine the possibility not to trust the TSA,*

then you might require that the TSA stores all stamps with

a notary, or whatever else third/forth/fifth tp to store

a complete archive of all tokens. 

</excerpt>

Elsewhere the document talks about recovery from a possible key
compromise and says:


<fontfamily><param>Courier_New</param><bigger>. When the TSA private
key has been compromised, then the 

        corresponding certificate SHALL be revoked. In this case, 

        any token signed by the TSA using that private key cannot 

        be trusted anymore.  For this reason, it is imperative that 

        the TSA's private key be guarded with proper security and 

        controls in order to minimize the possibility of compromise. 

        In case the private key does become compromised, an audit 

        trail of all tokens generated by the TSA MAY provide a means 

        to discriminate between genuine and false backdated tokens. 


</bigger></fontfamily>By sequentially numbering the TSTs, there may be
some further protection against back dating an audit log, but maybe
this is such a small added feature that it's not worth pursuing.


Steve

--============_-1252851303==_ma============--


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13031 for <[e-mail]>; Thu, 25 May 2000 08:34:31 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA12601; Thu, 25 May 2000 17:38:16 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 25 May 2000 17:38:17 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA12088; Thu, 25 May 2000 17:38:15 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA03546; Thu, 25 May 2000 17:38:15 +0200 (MET DST)
Date: Thu, 25 May 2000 17:38:15 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: ASN.1 OPTIONAL   in TSA
Cc: [e-mail]

> 
> How can we distinguish the OPTIÕNAL fields if they are not present?
> 
> TimeStampReq ::= SEQUENCE  { 
>      version                      Integer  { v1(1) }, 
>      messageImprint               MessageImprint, 
>        --a hash algorithm OID and the hash value of the data to be 
>        --time stamped 
>      reqPolicy                PolicyInformation      OPTIONAL, 
>      nonce                    Integer                OPTIONAL, 
>      certReq                  BOOLEAN                DEFAULT FALSE, 
>      extensions               [0] Extensions         OPTIONAL 
> } 
> 
> 
> If we omit reqPolicy, how do we know that the field next to 
> messageImprint is Nonce?!! We don´t have tags like in Extension.
> 
You do.
 
SEQUENCE = UNIVERSAL 16 for PolicyPnformation and
INTEGER = UNIVERSAL 2 for nonce, etc.

The CONTEXT 0 tag for extension is there in order to detect it
if none of the previous is present.


Peter

BTW: In order to avoid implementation bugs it seems useful to me
to be sure whether >

      extensions [0] Extensions OPTIONAL

actually means the same as  

      extensions [0] IMPLICIT Extensions OPTIONAL

or 
      extensions [0] EXPLICIT Extensions OPTIONAL



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12925 for <[e-mail]>; Thu, 25 May 2000 08:32:40 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA31718 for <[e-mail]>; Thu, 25 May 2000 17:39:52 +0200
Message-ID: <[e-mail]>
Date: Thu, 25 May 2000 17:39:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Comments on draft-ietf-pkix-ac509prof-03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments on document ac509prof-03

Foreword. The comments are numbered and presented in sequence,
following the page numbering of the document. However they are not
all of equal importance.

1. Page 3. Section 1. The introduction is too long and too much
access control oriented. This comment was made originally on the
first version but has not been corrected. Since the last call is now
being made (maybe to trigger reading the whole document in detail),
it is now the time to fix it.

It is important to say first what an AC is and why attributes are
not included in the certificates (before saying what it can be used
for). The proposal which follows has been using the current text
which has been re-shuffled to cover the point. It has also be
augmented to cover the fact that access control is simply one of
three security services able to take profit of the content of an AC.

The following is proposed to replace the whole section 1:

" 1.Introduction

X.509 public key certificates (PKCs) [X.509-97, X.509-DAM, PKIXPROF]
bind an identity and a public key. An AC is a structure similar to a
PKC; the main difference being that the AC contains no public key.
An AC may contain attributes that specify group membership, role,
security clearance, or other authorization information associated
with the AC holder. The syntax for the AC is defined in
Recommendation X.509, making the term "X.509 certificate" ambiguous. 

Some people constantly confuse PKCs and ACs. An analogy may make the
distinction clear. A PKC can be considered to be like a passport: it
identifies the holder, tends to last for a long time, and should not
be trivial to obtain. An AC is more like an entry visa: it is
typically issued by a different authority and does not last for as
long a time. As acquiring an entry visa typically requires
presenting a passport, getting a visa can be a simpler process.

Authorization information may be placed in a PKC extension or placed
in a separate attribute certificate (AC). The placement of
authorization information in PKCs is usually undesirable for two
reasons. First, authorization information often does not have the
same lifetime as the binding of the identity and the public key.
When authorization information is placed in a PKC extension, the
general result is the shortening of the PKC useful lifetime. Second,
the PKC issuer is not usually authoritative for the authorization
information. This results in additional steps for the PKC issuer to
obtain authorization information from the authoritative source.

For these reasons, it is often better to separate this authorization
information from the PKC. Yet, this authorization information also
needs to be protected in a fashion similar to a PKC. An AC provides
this protection; it is simply a digitally signed (or certified) set
of attributes.

An AC may be used with various security services like: 

   1. access control in a client-server protocol environment, 
   2. data origin authentication in either a client-server protocol 
      or a store-and-forward environment, and
   3. non-repudiation in a store-and-forward environment.

PKCs allow to provide an identity to access control decision
functions. However, in many contexts the identity is not the
criteria that is used for access control, but rather the role or the
group-membership of the accessor. This class of access control
functions are called role-based access control.

When making an access control decision based on an AC, an access
control decision function may need to ensure that the appropriate AC
holder is the entity that has requested access. For example, one way
in which the linkage between the request and the AC can be achieved
is if the AC has a reference to a PKC for the requester and that the
private key corresponding to the PKC has been used to authenticate
both the AC and the access request.

ACs may also be used in the context of a data origin authentication
service and of a non repudiation service. In theses contexts, the
attributes contained in the AC provide additional information about
the attributes from the signing entity. This information can be used
to make sure that the entity is authorized to sign the data. This
kind of checking depends either from the context where the data is
exchanged or from the data that has been digitally signed."


In the remaining of the document the bias towards access control
needs to be corrected. To this extend the following change relates
to this argument:


2. Page 4. Section 1.2. End of the first sentence. Delete " to
access control decision functions".


3. Page 4. Section 1.2. This section is too much oriented towards
the benefits of the "pull", whereas "push" is much better. In order
to correct this, it is proposed to add the following sentence at the
bottom of the page 4:

"The additional benefit is that only what the other party "needs to
know" is presented and thus there is no access control to be
exercised on which ACs should be made available to AC users."


4. Page 5. Section 1.2. This section is too much oriented towards
the benefits of the "pull", whereas "push" is much better. In order
to correct this, it is proposed to add the following sentence after
the second paragraph.

"A major drawback of the "pull" model is that it may require to
exercise an access control service to decide which ACs can be pulled
by access control decision functions. It is also less suitable for
some inter-domain cases where the client's right should be assigned
in the client's domain, rather than within the server's domain."


5. Page 6. Client definition. This definition should be modified to
indicate that it is specific to connection mode and access control.
Proposal: In a connection mode, the entity which is requesting the
action for which access control is being exercised.


6. Page 6. Server definition. This definition should be modified to
indicate that it is specific to connection mode and access control.
Proposal: In a connection mode, the entity which requires access
control to be enforced.


7. Page 6. Section 3. The section called "requirements" is
confusing. This seems more a list of design goals, rather than
requirements. Maybe the real question is whether this section should
be called design goals or conformance clauses, ... or even something
else ? A related question : is this section really needed ?


8. Page 6. Section 3. Time/validity requirements: If this is to be
interpreted as a conformance clause, then in many contexts, short
lived ACs are sufficient. Using CRLs or OCSP responses for attribute
certificates makes a much more complicated implementation. The
standard should thus mandate support for short-lived ACs, but not
for long-lived ACs whether it is applicable to AC issuers or AC
verifiers. Change the sentence into: Support for short-lived ACs is
required for both AC issuers and AC verifiers. If this is to be
interpreted as a design goal, then the text should read: "ACs should
be able to be used to carry short-term attributes as well as
long-term attributes.


9. Page 10. Section 4.2.2. Holder. First sentence. We should
RECOMMEND the use of the baseCertificateID and in the conformance
clause mandate its support. Proposed rewording. Instead of: "... the
holder field SHOULD use the baseCertificateID " replace with "...
the use of the baseCertificate in the holder field is RECOMMENDED."


10. Page 11. Section 4.2.2. After the third paragraph of this page,
add: "See the security consideration section which mentions some
name collision problems that may arise when using the entityName
option."


11. Page 11. Section 4.2.2. After the previous addition, add: "
Implementations conforming to this profile are not required to
support the use of the entityName field." 


12. Page 12. Section 4.2.6. Greenwich Mean Time does not exist
anymore and has been replaced by UTC. BTW, UTC and GMT mean the same
time, but standards should reference UTC.


13. Page 12. Section 4.2.6. Last sentence at the bottom, which says
:"AC users MUST be able to handle an AC which, at the time of
processing, has its entire validity period in the future (a
post-dated AC).". The sentence should be expanded to cover the case
of old ACs as well. Proposal: :"AC users MUST be able to handle an
AC which, at the time of processing, has parts of its validity
period or all its validity period in the past or in the future (a
post-dated AC)".


14. Page 12. Section 4.2.9. The first sentence says: "The extensions
field generally gives information about the AC as opposed to
information about the AC holder". The first extension on the next
page negates this statement. It is proposed to replace the sentence
by the following: "The extensions field gives information either
about the use of the AC, the AA or about the AC holder".


15. Page 15. Section 4.3.2. I could not understand the sentence :
"The targetCert CHOICE is only present ..." since in the syntax
there is no CHOICE.


16. Page 17. Section 4.3.6. No Revocation Available. I would move
this extension in a new section 4.2.10 so that we can mandate the
support of that extension for conforming implementations, since this
is what section 6 mandates. I would add: "Implementations conforming
to this profile are required to support the use of the noRevAvail
extension."


17. Page 17. Section 4.4. Attribute types. I would prefer to rename
that section "Useful Attribute types" to show better that none
needed to be supported.


18. Page 17. Section 4.4. About the IetfAttrSyntax. The use of
policyAuthority is interesting. However, there is a potential
security risk here. When using GeneralNames (without further
restrictions) there is no guarantee that the name of the policy
authority is understood in the same way by various AAs and AC users.
Also a name could be re-used creating some ambiguities. 

A name that is unique and cannot be re-used is required for secure
implementations. An OID fulfils this requirement. A URN does not
since the same name can be resold to another organization (and thus
be re-used).

When this field is present, it is thus proposed to RECOMMEND (or
mandate ?) the inclusion of an OID in GeneralNames to point to the
organization and allow the addition of a DN or a URN that may be
used as an *hint* to know the name of the organization.


19. Page 18. Section 4.4.1. Service Authentication Information .
This attribute definition should be moved in section 7.1 since it is
an encrypted attribute.


20. Page 18. Section 4.4.2. Access identity. The name is confusing.
Use "Service Identification" instead of Access Identity would be
much better. An Access Identity is an identity that is
understandable by any service, which is not the case here. Define
SvceAuthInfo here since Service Authentication Information should be
moved in section 7.1.


21. Page 19. Section 4.4.5. Role. I do not see the rational for some
limitations that are introduced here. The text states:

RoleSyntax ::= SEQUENCE {
          roleAuthority   [0] GeneralNames OPTIONAL,
          roleName        [1] GeneralName
    }

The roleAuthority field MUST NOT be used. The roleName field MUST be
present, and roleName MUST use the uniformResourceIdentifier CHOICE
of the GeneralName.

Why must the roleAuthority field NOT be used ? 
Why must the roleName use the uniformResourceIdentifier CHOICE ?
Why is the case of the roleAuthority different from the
policyAuthority ?


22. Page 22. Section 5. Typo: "timelyand"


23. Page 23. Section 6. Why making crlDistributionPoints,
authorityInformationAccess mutually exclusive ? For PKCs we allow
both. So why should we make that restriction for AC ? I would like
to get the rational.


Denis


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12455 for <[e-mail]>; Thu, 25 May 2000 08:25:34 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA12429; Thu, 25 May 2000 17:32:39 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 25 May 2000 17:32:40 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA12071; Thu, 25 May 2000 17:32:38 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA03541; Thu, 25 May 2000 17:32:38 +0200 (MET DST)
Date: Thu, 25 May 2000 17:32:38 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]

Steve,

Hm, the actual text says:

    'strictly monotonical increasing'. 

At least the example in the text about non-consecutive
number is there. 

What you are asking for is to create consecutive time stamps.

What you indicate is not mentioned in the text at all in the
text, maybe it was intended at some time (the usage of 
'monotonically incrementing' may be an indication).
Maybe the original author's can comment on that.

Your point is an interesting one. This is ONE method, if a TSA
is able and willing to increment by one, they can do that. 

But that doesn't help,  a TSA can replace any stamp
and then claim in 30 years that the key was corrupted.

If you imagine the possibility not to trust the TSA,*
then you might require that the TSA stores all stamps with
a notary, or whatever else third/forth/fifth tp to store
a complete archive of all tokens. 

> 
> >Peter,
> >
> >You are right. The name "serialNumber" in this context is
> >misleading. I forgot to look backwards to find out the additional
> >statements you mention. :-(
> >
> >The serialNumber field serves several purposes, one of them being to
> >be used in conjunction with the DN to uniquely identify a TS token.
> >
> >We have added another constraint, i.e. monotonically increasing,
> >that does not appear in other standards. This was done to save an
> >additional parameter. The main idea was to be able to compare two
> >time stamps issued during the same second.
> 
> I think that is critical and there is another possible reason for 
> wanting the counter to be monotonically increasing.  It helps detect 
> if a TSA tries to insert a late arriving hash into the time stamp 
> stream.  If there are no sequence number gaps, there are no "hole" 
> into which a later arriving hash can be inserted.  I assumed this was 
> another motivation.
> 
> Steve
> 
> 


Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12331 for <[e-mail]>; Thu, 25 May 2000 08:23:58 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA21860; Fri, 26 May 2000 03:31:10 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95926866924313>; Fri, 26 May 2000 03:31:09 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  ASN.1 OPTIONAL   in TSA
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 26 May 2000 03:31:09 (NZST)
Message-ID: <[e-mail]>

"Serafim Gomes" <[e-mail]> writes:

>If we omit reqPolicy, how do we know that the field next to messageImprint is
>Nonce?!! We donM-4t have tags like in Extension.

Yes we do, reqPolicy is tagged as a SEQUENCE, nonce is tagged as an INTEGER
(although it'd help to have the keyword capitalised to make this explicit).

Peter.



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11972 for <[e-mail]>; Thu, 25 May 2000 08:14:55 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA04276; Thu, 25 May 2000 11:22:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220801b552da7671bf@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 25 May 2000 11:14:10 -0400
To: Peter Williams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>Steve:
>
>Perhaps comment.

I'll respond to each point.

>
>(1) You should realize that the text I quoted, repeated below from your
>reply, is from RFC 2459.

Whoops, caught me on that one :-).

>
>(2) The text quoted is not some bullshit from Peter's English pen.

Didn't say it was.

>
>	(2.1) The text is the work of Ford et al., NIST/NSA, PKIX WG,
>		PKIX mailing list, IESG et al., and a PKIX WG and IETF Final
>call.

Guess I missed it the last time.  And, the fact that I missed it 
probably says something about the level of scrutiny that one ought to 
assume despite the list you cite here.  I know that the IESG members, 
other than the cognizant area director(s), do not, as a rule, read 
documents before approving them as RFCs.  And, given the large number 
of WGs that each AD must cover, they often rely primarily on WG 
chairs and the WG process to ensure that the documents are 
reasonable. So, it would be erroneous to assume that the review 
process ensures that all the cited parties have read an RFC carefully 
prior to its publication.

>
>	(2.2) The text has been present in the I-Ds leading to RFC 2459 from
>		very early moments of our mailing-list deliberations.

I'll grant that it has probably been there for a long while.

>
>(3) You do not agree that the cited paragraph (from RFC 2459) represents
>group consensus. That the same paragraph remains in son-of-2459 I-D is not
>relevant to you, presumably.

The fact that it currently is in the revised text is relevant to me, 
and I'll see if we can fix that now that you have pointed it out. 
(See the end of this message.)

>
>(4) You view the "supplement/replace" assumption stated by the authors
>of RFC 2459, as stated in the 1st quoted sentence (from RFC 2459),
>to be "out of the question".

Yes, in my opinion, and in the opinion of at least one other WG 
member who cared to respond to your message. I'll ask Tim if he 
recalls where it came from. But the point is that it is an odd 
comment that seems out of place in a standards document of this sort. 
The fact that it was present and that I didn't notice it is a failure 
on my part, but that doesn't mean we can't fix it now.  Many 
reviewers, myself included, probably focused on the technical details 
of 2459, e.g., syntax and processing rules, rather than this 
context-setting text.

X.509 and other standards have been published with errors that have 
later been fixed. That's what the defect report process is about. 
Here we're dealing with two distinct sentences, each with different 
problems.  The first, as noted above, strikes me as completely 
inappropriate for a standard. The second is confusing. Presumably it 
can be clarified, and then we can debate whether it should be in the 
RFC.

>
>(5) You view the second sentence of the same quote (from RFC 2459) as
>"confusing."


Yes, for exactly the reason I cited.

>
>(6) And...despite your repeated misdirections as chair, you will perhaps
>now agree that Peter did not write a word of the cited text that you
>criticise so severely. THIS WG wrote and reviewed the text...


You're right that I assumed you were the author, and I'll admit that 
my criticism was probably heightened by that thought :-).  However, 
if the criticism is valid, we should address it, irrespective of 
authorship.

Let's be accurate about this Peter.  WG's don't write text.  Authors 
write text.  In the case of any large document with many listed 
authors there are lots of opportunities for details to not be 
carefully reviewed.  We have uncovered a number of such details in 
2459.  I'm certain that several, perhaps most, of the long list of 
authors of 2459 have NOT reviewed MOST of the text for a long time. 
Tim is the one individual who, as the editor, has the best chance of 
keeping on top of the document.


>
>(7) The text, which was discussed in mailing list discussions, also
>passed Final Call in both PKIX WG and IETF Final Call.

See comments above.

>
>(8) IETF Final call is a conventional signal of consensus. But perhaps
>not in PKIX WG, under the rules of our chairs.

The IETF last call is the means by which the IETF notifies interested 
parties that a document is about to become a standard, unless someone 
raises objections.  To the extent that consent by abstaining is 
consensus, then you're right, since that is what happens for most 
documents and most members of the IETF. Personally, I have used the 
last call to trigger reading of documents that I was not tracking, 
and I have made suggestions to the IESG re changes to such documents. 
Sometimes my proposed changes have been adopted, sometime not.  In at 
least two cases where I did not prevail, the matter was one of 
technical accuracy and my objections were overruled despite being 
objectively correct.  So, the process is far from perfect.

>
>(9) The use of quote symbols around text is an accepted practice to
>denote a quotation.
>
>
>(10) The appendage of [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt] after
>a quoted passage represents an accepted practice to clearly identify the
>source of a quotation.


I missed that, obviously.

So, where are we now?

Well, I stand by my objections to the text.  It is inappropriate to 
have inserted the first sentence into a standard, and I now propose 
to the WG that we remove it.

The second part also strikes me as very sloppy, for exactly the 
reasons I cited.  So, I propose removing it as well, unless someone 
can clarify the meaning, and then justify why it is present.

Presumably you don't argue that just because we published this text 
before that it is perfect.  To do so would suggest that we ought not 
be making all the other changes to 2459 that we have so far.  The 
only question now is whether the WG wants to retain this text, 
expressing such a desire via a positive action (vs. silent assent) or 
if the WG is willing to strike it.

Steve



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11663 for <[e-mail]>; Thu, 25 May 2000 08:08:29 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA31576; Thu, 25 May 2000 17:15:06 +0200
Message-ID: <[e-mail]>
Date: Thu, 25 May 2000 17:15:09 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul and others,

Some major details: 

1) I would propose to add an "s" to "certificate policy" making it
"certificate policies".

In RFC 2459 we have:

4.2.1.5  Certificate Policies

   The certificate policies extension contains a sequence of one or
more
   policy information terms, each of which consists of an object
   identifier (OID) and optional qualifiers. 

2) In the same way, I would add an "s" to "CPS" making it "CPSs".

3) Finally, since the verification is not uniform, I would also add
an "s" to "verification".

The final sentence would thus look like:

"The precise nature of the verifications is detailed in the
certificate policies and/or the CPSs."

4) ... and a comment on the use of "definitively":

We were looking for text replacement related only to the subject
alternative name section 4.2.1.7. Now the sentence has been extended
to cover parameters like "all other fields in a certificate" and
"all certificate extensions". So "definitively" also applies to them
now, and this is wrong.

I would thus propose to delete the sentence "like all other fields
in a certificate and all certificate extensions," and thus keep the
idea  from RFC 2459, where only the subject alternative name is
considered to be definitiviely bound to the public key, which was:

   Because the subject alternative name is considered to be
   definitiviely bound to the public key, all parts of the subject
   alternative name MUST be verified by the CA.

The new text would thus look like:

  Denis> "The subject alternative name is considered to
  Denis> be definitively bound to the public key. Thus the CA MUST
  Denis> verify (directly or indirectly) all subject alternative
  Denis> names. The precise nature of the verifications is detailed
in
  Denis> the certificate policies and/or the CPSs."

Denis
 
> Echoing Paul Hoffman's comment...  I find Steve's text to be
> preferable.  For one thing, retaining "definitively" seems a good
> thing to do.
 
>       paul

 
  Warwick> "The subject alternative name, like all other fields in a
  Warwick> certificate and all certificate extensions, is considered
to
  Warwick> be bound to the public key.  Thus the CA MUST verify (in
  Warwick> accordance with the applicable certificate policy and/or
the
  Warwick> CPS) all subject alternative names."
 

  Steve> "The subject alternative name, like all other fields in a
  Steve> certificate and all certificate extensions, is considered
to
  Steve> be definitively bound to the public key. Thus the CA MUST
  Steve> verify (directly or indirectly) all subject alternative
  Steve> names. The precise nature of the verification is detailed
in
  Steve> the certificate policy and/or the CPS."


Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11125 for <[e-mail]>; Thu, 25 May 2000 07:54:04 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA291534; Thu, 25 May 2000 10:59:03 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id LAA139492; Thu, 25 May 2000 11:00:40 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568EA.0052751A ; Thu, 25 May 2000 11:00:39 -0400
X-Lotus-FromDomain: IBMUS
To: Peter Williams <[e-mail]>
cc: "'Stephen Kent'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 25 May 2000 11:00:31 -0400
Subject: RE: SubjectAltName verification
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I agree that the text you cite is in RFC 2459, and presumably
represents WG consensus.  However, I don't think that what it says is quite
what you seem to think it means.  First, the statement that communities may
replace the profile would appear to be a recognition that the basic
standard involved here is X.509 and a community may well find it
appropriate to build their own profile directly from X.509 without using
the PKIX profile, in which case no question of conformity to PKIX can
arise.  Second, a community may supplement the profile.  A new profile may
certainly be created from this one by adding new features using one of the
extensible mechanisms (extensions, attributes, OTHER-NAME's, etc.) or by
imposing constraints not found in this profile (such as limitations on the
range of DN attributes or the allowable types of alternate name).  Taking
one of the explicit requirements of this profile (say, that private key
usage period MUST NOT be critical) and eliminating it is not supplementing
the profile, but dispensing from specific requirements within it.  Building
a new profile by doing this might well be valid, but the resulting profile
would not be conformant to RFC 2459 or a supplement to RFC 2459, and should
not be described as such.

          Tom Gindin


Peter Williams <[e-mail]> on 05/24/2000 10:46:20 PM

To:   "'Stephen Kent'" <[e-mail]>
cc:   [e-mail]
Subject:  RE: SubjectAltName verification




Steve:

Perhaps comment.

(1) You should realize that the text I quoted, repeated below from your
reply, is from RFC 2459.

(2) The text quoted is not some bullshit from Peter's English pen.

     (2.1) The text is the work of Ford et al., NIST/NSA, PKIX WG,
          PKIX mailing list, IESG et al., and a PKIX WG and IETF Final
call.

     (2.2) The text has been present in the I-Ds leading to RFC 2459 from
          very early moments of our mailing-list deliberations.

(3) You do not agree that the cited paragraph (from RFC 2459) represents
group consensus. That the same paragraph remains in son-of-2459 I-D is not
relevant to you, presumably.

(4) You view the "supplement/replace" assumption stated by the authors
of RFC 2459, as stated in the 1st quoted sentence (from RFC 2459),
to be "out of the question".

(5) You view the second sentence of the same quote (from RFC 2459) as
"confusing."

(6) And...despite your repeated misdirections as chair, you will perhaps
now agree that Peter did not write a word of the cited text that you
criticise so severely. THIS WG wrote and reviewed the text...

(7) The text, which was discussed in mailing list discussions, also
passed Final Call in both PKIX WG and IETF Final Call.

(8) IETF Final call is a conventional signal of consensus. But perhaps
not in PKIX WG, under the rules of our chairs.

(9) The use of quote symbols around text is an accepted practice to
denote a quotation.

(10) The appendage of [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt] after
a quoted passage represents an accepted practice to clearly identify the
source of a quotation.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, May 24, 2000 8:42 AM
To: Peter Williams
Cc: [e-mail]
Subject: RE: SubjectAltName verification


Peter,

>    "Some communities will need to supplement, or possibly replace, this
>    profile in order to meet the requirements of specialized application
>    domains or environments with additional authorization, assurance, or
>    operational requirements.  However, for basic applications, common
>    representations of frequently used attributes are defined so that
>    application developers can obtain necessary information without
>    regard to the issuer of a particular certificate or certificate revo-
>    cation list (CRL)." [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt]
>
>Do you affirm the above to be group consensus?

No, I do not agree.

It seems out of place to insert text into a standard saying that "we
understand if you don't want to use this standard."  So the first
sentence is out of the question.

The second sentence confuses me.  What do you mean by "common
representations of frequently used attributes?"  The "representation"
of an attribute is its syntax, which is certainly part of the
standard, but not the focus of this discussion.

Steve





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10541 for <[e-mail]>; Thu, 25 May 2000 07:34:56 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA28076; Thu, 25 May 2000 10:42:08 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220803b552eb215c38@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 25 May 2000 10:41:28 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>Peter,
>
>You are right. The name "serialNumber" in this context is
>misleading. I forgot to look backwards to find out the additional
>statements you mention. :-(
>
>The serialNumber field serves several purposes, one of them being to
>be used in conjunction with the DN to uniquely identify a TS token.
>
>We have added another constraint, i.e. monotonically increasing,
>that does not appear in other standards. This was done to save an
>additional parameter. The main idea was to be able to compare two
>time stamps issued during the same second.

I think that is critical and there is another possible reason for 
wanting the counter to be monotonically increasing.  It helps detect 
if a TSA tries to insert a late arriving hash into the time stamp 
stream.  If there are no sequence number gaps, there are no "hole" 
into which a later arriving hash can be inserted.  I assumed this was 
another motivation.

Steve



Received: from nemesio.ci.uminho.pt (nemesio.ci.uminho.pt [193.136.16.244]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10238 for <[e-mail]>; Thu, 25 May 2000 07:27:26 -0700 (PDT)
Received: from cripto20 (shannon.di.uminho.pt [193.136.20.84] (may be forged)) by nemesio.ci.uminho.pt (8.8.7/8.8.7) with ESMTP id PAA07674 for <[e-mail]>; Thu, 25 May 2000 15:28:37 +0100
From: "Serafim Gomes" <[e-mail]>
To: [e-mail]
Date: Thu, 25 May 2000 15:30:22 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: ASN.1 OPTIONAL   in TSA
Reply-to: [e-mail]
Message-ID: <392D470E.10721.8D4D4C@localhost>
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12c)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by ns.secondary.com id HAA10241

How can we distinguish the OPTIÕNAL fields if they are not present?

TimeStampReq ::= SEQUENCE  { 
     version                      Integer  { v1(1) }, 
     messageImprint               MessageImprint, 
       --a hash algorithm OID and the hash value of the data to be 
       --time stamped 
     reqPolicy                PolicyInformation      OPTIONAL, 
     nonce                    Integer                OPTIONAL, 
     certReq                  BOOLEAN                DEFAULT FALSE, 
     extensions               [0] Extensions         OPTIONAL 
} 


If we omit reqPolicy, how do we know that the field next to 
messageImprint is Nonce?!! We don´t have tags like in Extension.



I'm working in JAVA with the IAIK package, does anyone work with this 
package?

--
Serafim Gomes
[e-mail]           telm: +351 - 938421578  telf: [phone]
http://www.pobox.com/~serafim


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09968 for <[e-mail]>; Thu, 25 May 2000 07:22:14 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqsf01703; Thu, 25 May 2000 14:28:13 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07206; Thu, 25 May 00 10:24:46 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA11837; Thu, 25 May 2000 10:28:12 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 25 May 2000 10:28:12 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: SubjectAltName verification
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

Echoing Paul Hoffman's comment...  I find Steve's text to be
preferable.  For one thing, retaining "definitively" seems a good
thing to do.

      paul

>>>>> "Warwick" == Warwick Ford <[e-mail]> writes:

 Warwick> With Steve's concurrence, I propose the following modified
 Warwick> wording to the clause of concern:

 Warwick> "The subject alternative name, like all other fields in a
 Warwick> certificate and all certificate extensions, is considered to
 Warwick> be bound to the public key.  Thus the CA MUST verify (in
 Warwick> accordance with the applicable certificate policy and/or the
 Warwick> CPS) all subject alternative names."

 Steve> I worry that we are unduly singling out this attribute, even
 Steve> though ALL the attributes have the same sort of
 Steve> requirement. How about:

 Steve> "The subject alternative name, like all other fields in a
 Steve> certificate and all certificate extensions, is considered to
 Steve> be definitively bound to the public key. Thus the CA MUST
 Steve> verify (directly or indirectly) all subject alternative
 Steve> names. The precise nature of the verification is detailed in
 Steve> the certificate policy and/or the CPS."


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09659 for <[e-mail]>; Thu, 25 May 2000 07:14:22 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqsf24291; Thu, 25 May 2000 14:21:35 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07102; Thu, 25 May 00 10:18:07 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA11798; Thu, 25 May 2000 10:21:33 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 25 May 2000 10:21:33 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Denis" == Denis Pinkas <[e-mail]> writes:

 Denis> Peter, This issue is not specific to the TSP.

 Denis> RFC 2459 does not include any text about the size of serial
 Denis> number.

 Denis> The draft draft-ietf-pkix-ac509prof-03.txt proposes an upper
 Denis> limit of 20 bytes. So you should also complain in the same way
 Denis> for that draft. :-)

 Denis> So there are two options:

 Denis> 1) Provide an upper limit, or 2) Provide a warning, without
 Denis> any limit (as you have suggested).

 Denis> I would, personally, prefer the former since, in practice,
 Denis> implementors will have to use an upper limit.

Why?  If it's just a unique ID, then the only meaningful operation on
it is memcmp() for which a tightly bounded size is not at all needed.

   paul



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09456 for <[e-mail]>; Thu, 25 May 2000 07:12:36 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqsf22238; Thu, 25 May 2000 14:19:43 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07065; Thu, 25 May 00 10:16:15 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA11796; Thu, 25 May 2000 10:19:42 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 25 May 2000 10:19:41 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Denis" == Denis Pinkas <[e-mail]> writes:

 Denis> Folks, Do not ask more than what RFC 2459 is saying about the
 Denis> serial number from a public key certificate;

 Denis> Extract from RFC 2459 page 18, section 4.1.2.2:

 Denis> The serial number is an integer assigned by the CA to each
 Denis> certificate.  It MUST be unique for each certificate issued by
 Denis> a given CA (i.e., the issuer name and serial number identify a
 Denis> unique certificate).

 Denis> The same field in a TS token serves the same purpose. There is
 Denis> no notion of sequentiality. Maybe we should have called it
 Denis> unique number. This has not been done since we wanted to
 Denis> maintain consistancy with ISO. In order to maintain
 Denis> consistancy between standards, it would not be appropriate to
 Denis> change the name and/or the concept.

Ok, if uniqueness is the requirement to be satisfied, then that is
what should be required of the number in question.  

And yes, in that case it really should be called "Unique number" or
"Unique ID".  The fact that ISO calls it something else is not
important in my view; the fact that someone uses a misleading term is
not good reason for others to copy that mistake.

But if we keep the misleading term, the least that is needed is a note
right next to its definition that says "we call it this only for
compatibility with ISO; it actually is only a unique ID.  Values are
not ordered in any way."

    paul



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09042 for <[e-mail]>; Thu, 25 May 2000 07:06:36 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqse14483; Thu, 25 May 2000 14:13:50 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA06999; Thu, 25 May 00 10:10:22 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA11794; Thu, 25 May 2000 10:13:49 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 25 May 2000 10:13:48 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: SubjectAltName verification
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Peter" == Peter Williams <[e-mail]> writes:

 Peter> Steve:

 Peter> Perhaps comment.

 Peter> (1) You should realize that the text I quoted, repeated below
 Peter> from your reply, is from RFC 2459. ...

 Peter> (6) And...despite your repeated misdirections as chair, you
 Peter> will perhaps now agree that Peter did not write a word of the
 Peter> cited text that you criticise so severely. THIS WG wrote and
 Peter> reviewed the text...

 >> "Some communities will need to supplement, or possibly replace,
 >> this profile in order to meet the requirements of specialized
 >> application domains or environments with additional authorization,
 >> assurance, or operational requirements.  However, for basic
 >> applications, common representations of frequently used attributes
 >> are defined so that application developers can obtain necessary
 >> information without regard to the issuer of a particular
 >> certificate or certificate revo- cation list (CRL)." [RFC 2459,
 >> http://www.ietf.org/rfc/rfc2459.txt]

That's all very nice, but I don't see any reason to disagree with
Steve's basic objection -- which is that it doesn't make much sense in
a standard to say "of course implementations are free not to conform
to the standard".  That's true, obvious, and irrelevant.  I wonder why
that text ever made it into this RFC.

     paul


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09017 for <[e-mail]>; Thu, 25 May 2000 07:06:06 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA31598; Thu, 25 May 2000 16:13:14 +0200
Message-ID: <[e-mail]>
Date: Thu, 25 May 2000 16:13:17 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

You are right. The name "serialNumber" in this context is
misleading. I forgot to look backwards to find out the additional
statements you mention. :-(

The serialNumber field serves several purposes, one of them being to
be used in conjunction with the DN to uniquely identify a TS token.

We have added another constraint, i.e. monotonically increasing,
that does not appear in other standards. This was done to save an
additional parameter. The main idea was to be able to compare two
time stamps issued during the same second.

An implementation could use a concatenation of a time (up to the
second granularity) and a counter.
The counter may be preset to any value when starting a new second,
then incremented using some fixed value, and make sure that the
counter cannot overflow within one second.

Since I do not know today a server recovering from a deep crash in
one second, there should be no problem. When such a recovery time
will happen, the TSA functionality could possibly wait for one
second.

Note that in that case the use of a hash function is far less
obvious than before and a limit 128 bits would probably be much more
than needed.

Denis

> Denis,
> 
> >
> > A monotonically increasing serial number for all time is not
> > REQUIRED. See my previous response to Peter Sylvester.
> 
> This is exactly the contrary of what is defined.
> 
> See below (the first X* should be like the second one).
> 
> 2.1. Requirements of the TSA
> 
> The TSA is REQUIRED:
> 
>      1.  to use a trustworthy source of time.
> 
>      2.  to include a trustworthy time value for each time stamp token.
> 
>      3.  to include a monotonically incrementing integer for each
>                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>          newly generated time stamp token.
> 
> .....
> 
> The serialNumber field shall include a strictly monotonically
>                                        XXXXXXXXXXXXXXXXXXXXXX
> 
> increasing integer from one TimeStampToken to the next (e.g. 45, 236,
> XXXXXXXXXXXXXXXXXX                                           YYYYYYYY
> 245, 1023, ...).
> YYYYYYYYYYYYYY
>                   This guarantees that each token is unique and allows
> to compare the ordering of two time stamps from the same TSA. This is
> useful in particular when two time stamps from the same TSA bear the
> same time. This field also provides the way to build a unique
> identifier to reference the token. It should be noticed that the
> monotonic property must remain valid even after a possible
> interruption (e.g. crash) of the service.
> 
> >
> > However, your concern on how to recover from a situation where the
> > serial number is lost due to equipment failure is valid. The concern
> > is to make sure to have no duplicate when re-starting the service.
> > There are several ways to solve this issue.
> Indeed.
>                                               This is implementation
> > details that should not appear in an RFC.
> Some hints about possible ways to do this can be given as examples.
> 
> >
> > As an example, you can use a concatenation of a time on 32 (or 33)
> > bits and a random number. In this way, when you recover from a
> > crash, at least one second has elapsed and there is no problem.
> How do you avoid a duplicate random number in the same interval.
> 
> >
> > You can use the result of a hash applied to a concatenation of a
> > time on 32 (or 33) bits and a random number. The risk of collisions
> > is low if keep around 2 ^64 time stamps.
> 
> How would you compare two time stamps in this case?
> 
> Regards
> 
>


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08184 for <[e-mail]>; Thu, 25 May 2000 06:24:51 -0700 (PDT)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <[e-mail]>; Thu, 25 May 2000 06:32:06 -0700
Message-ID: <[e-mail]>
Date: Thu, 25 May 2000 09:29:47 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christopher Williams <[e-mail]>
CC: PKIX Mailing List <[e-mail]>
Subject: Re: What is the meaning of the "indirectCRL" flag
References: <001f01bfc648$b29d4720$0100a8c0@darxstar>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christopher:

	An "indirect CRL" is a CRL issued by an entity other than the one that
issued the certificate(s) on the CRL. The relevance of this flag is
mostly explained in section 5.3.4, namely

5.3.4  Certificate Issuer

   This CRL entry extension identifies the certificate issuer associated
   with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
   indicator set in its issuing distribution point extension. If this
   extension is not present on the first entry in an indirect CRL, the
   certificate issuer defaults to the CRL issuer. On subsequent entries
   in an indirect CRL, if this extension is not present, the certificate
   issuer for the entry is the same as that for the preceding entry.

That is, the indirectCRL flag is used in combination with the
Certificate Issuer Extension to let you know that the issuer of the
certs in a CRL was different from the issuer of the CRL, and who it was.

(Normally, only the entity that issued the certificate is allowed to
revoke it; otherwise, you open yourself up to a nice denial of service
attack.  However, if you control it properly, this can be a nice
revocation management feature.)


		Al Arsenault
		Chief Security Architect
		Diversinet Corp.


Christopher Williams wrote:
> 
> RFC2459, section 5.2.5  "Issuing Distribution Point" mentions an indirectCRL
> flag, but does not give its significance.  Does anybody know?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com


Received: from mta01-svc.server.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07289 for <[e-mail]>; Thu, 25 May 2000 05:45:42 -0700 (PDT)
Received: from darxstar ([62.252.196.132]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000525125255.UBDK381.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Thu, 25 May 2000 13:52:55 +0100
Message-ID: <001f01bfc648$b29d4720$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: What is the meaning of the "indirectCRL" flag
Date: Thu, 25 May 2000 13:56:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

RFC2459, section 5.2.5  "Issuing Distribution Point" mentions an indirectCRL
flag, but does not give its significance.  Does anybody know?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA04882 for <[e-mail]>; Thu, 25 May 2000 04:52:32 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA07609; Thu, 25 May 2000 13:59:44 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 25 May 2000 13:59:44 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA10613; Thu, 25 May 2000 13:59:43 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA03472; Thu, 25 May 2000 13:59:42 +0200 (MET DST)
Date: Thu, 25 May 2000 13:59:42 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]

Denis, 

> 
> A monotonically increasing serial number for all time is not
> REQUIRED. See my previous response to Peter Sylvester.

This is exactly the contrary of what is defined. 

See below (the first X* should be like the second one).


2.1. Requirements of the TSA

The TSA is REQUIRED:

     1.  to use a trustworthy source of time.

     2.  to include a trustworthy time value for each time stamp token.

     3.  to include a monotonically incrementing integer for each 
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
         newly generated time stamp token.

.....

The serialNumber field shall include a strictly monotonically 
                                       XXXXXXXXXXXXXXXXXXXXXX  

increasing integer from one TimeStampToken to the next (e.g. 45, 236, 
XXXXXXXXXXXXXXXXXX                                           YYYYYYYY
245, 1023, ...). 
YYYYYYYYYYYYYY
                  This guarantees that each token is unique and allows 
to compare the ordering of two time stamps from the same TSA. This is 
useful in particular when two time stamps from the same TSA bear the 
same time. This field also provides the way to build a unique 
identifier to reference the token. It should be noticed that the 
monotonic property must remain valid even after a possible 
interruption (e.g. crash) of the service. 


> 
> However, your concern on how to recover from a situation where the
> serial number is lost due to equipment failure is valid. The concern
> is to make sure to have no duplicate when re-starting the service.
> There are several ways to solve this issue. 
Indeed.
                                              This is implementation
> details that should not appear in an RFC.
Some hints about possible ways to do this can be given as examples. 

> 
> As an example, you can use a concatenation of a time on 32 (or 33)
> bits and a random number. In this way, when you recover from a
> crash, at least one second has elapsed and there is no problem.
How do you avoid a duplicate random number in the same interval.

> 
> You can use the result of a hash applied to a concatenation of a
> time on 32 (or 33) bits and a random number. The risk of collisions
> is low if keep around 2 ^64 time stamps.

How would you compare two time stamps in this case? 

Regards

 



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23652 for <[e-mail]>; Thu, 25 May 2000 01:23:15 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA21080; Thu, 25 May 2000 10:30:18 +0200
Message-ID: <[e-mail]>
Date: Thu, 25 May 2000 10:30:19 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

This issue is not specific to the TSP. 

RFC 2459 does not include any text about the size of serial number.

The draft draft-ietf-pkix-ac509prof-03.txt proposes an upper limit
of 20 bytes. So you should also complain in the same way for that
draft. :-)

So there are two options:

1) Provide an upper limit, or
2) Provide a warning, without any limit (as you have suggested).

I would, personally, prefer the former since, in practice,
implementors will have to use an upper limit.

You should also notice that the document does not specify the use of
a hash. The hash is only one of many ways to generate serial
numbers. Since this is invisible to the outside world, TSAs can do
what they think is appropriate (and cannot be mandated to use
SHA-2).

Denis 

> >I understand that using 20 octects allows to use the result of a hash function
> >and thus does not mandate any sequentiality. It also has the further benefit
> >to hide the number of time stamps generated.
> 
> Limiting it to a current hash size may cause problems in the future, when SHA-2
> appears (accompanied by an edict that "All organisations shall transition to
> use of SHA-2 by 2005") then the 20-byte upper limit is going to be a problem.
> 
> Peter.


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA20256 for <[e-mail]>; Thu, 25 May 2000 00:44:09 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA20590; Thu, 25 May 2000 09:51:15 +0200
Message-ID: <[e-mail]>
Date: Thu, 25 May 2000 09:51:17 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: William Lattin <[e-mail]>
CC: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <000001bfc58e$594623a0$45e61b3f@winnt>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bill,

A monotonically increasing serial number for all time is not
REQUIRED. See my previous response to Peter Sylvester.

However, your concern on how to recover from a situation where the
serial number is lost due to equipment failure is valid. The concern
is to make sure to have no duplicate when re-starting the service.
There are several ways to solve this issue. This is implementation
details that should not appear in an RFC.

As an example, you can use a concatenation of a time on 32 (or 33)
bits and a random number. In this way, when you recover from a
crash, at least one second has elapsed and there is no problem.

You can use the result of a hash applied to a concatenation of a
time on 32 (or 33) bits and a random number. The risk of collisions
is low if keep around 2 ^64 time stamps.

You can use a sequential number to derive from it (using some other
stuff) the serial number. Storing that sequential number every day
may allow you to make sure to have no duplicate (by skipping some of
the numbers that would have been normaly generated). 
  
There are many other ways or variants, and we are not going to
detail them. However, if you would like some additional text in the
security considerations section to warn better implementors (without
specifying how to meet the requirement), I would be ready to
consider a proposal.


Denis

 
> Denis,
> 
> The approach I suggested does allow for unique determination of a time
> stamp, but to do so the validator must also have the certificate for the TSA
> signature key.  I don't think this is unreasonable since proper verification
> should include this information.
> 
> The issue I am attempting to address is the requirement for a monotonically
> increasing serial number for all time.  The draft does not address how to
> recover from a situation where the serial number is lost due to equipment
> failure.  Such a failure is likely to occur at least once over all time :-).
> The approach I suggest above does allow graceful recovery, since one could
> generate a new TSA signature key and certificate and start again with a
> reset counter.
> 
> I strongly suggest that we consider the ramifications of trying to assure
> seamless operation for all time.  I don't think it is practical and we
> should not design a standard requiring such.  I am open to other solutions
> if the above suggestion is perceived as too burdensome.
> 
> Cheers,
> 
> Bill
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, May 24, 2000 01:47
> > To: [e-mail]
> > Cc: '[e-mail]'; '[e-mail]';
> > '[e-mail]'
> > Subject: Re: TSA Response serialNumber Field
> >
> >
> > Bill,
> >
> > Your proposal would not allow to unambiguously distinguing two TS
> > token using the TSA mane and the serialNumber. The same issue arises
> > in other documents. For example, in draft-ietf-pkix-ac509prof-03.txt
> > there is the following text.
> >
> > Given the uniqueness and timing requirements above serial numbers
> > can be expected to contain long integers. AC users MUST be able to
> > handle serialNumber values longer than 4 octets. Conformant ACs MUST
> > NOT contain serialNumber values longer than 20 octets.
> >
> > We could take the text proposed by Peter, which is a good warning,
> > but does not include an upper limit.
> > I understand that using 20 octects allows to use the result of a
> > hash function and thus does not mandate any sequentiality. It also
> > has the further benefit to hide the number of time stamps generated.
> >
> > I would thus propose to have a text like:
> >
> > Given the uniqueness and timing requirements above serial numbers
> > can be expected to contain long integers, TSA users MUST be able to
> > handle serialNumber values longer than 4 octets. Conformant Time
> > Stamps MUST NOT contain serialNumber values longer than 20 octets.
> >
> > Can we agree on this ?
> >
> > Denis
> >
> >
> > > I think a better way to address this would be to reset the
> > counter when the
> > > TSA signature key pair is generated.  This way, we could be
> > more confident
> > > that a 64-bit counter is sufficient, plus given the real world
> > difficulties
> > > of guaranteeing a monotonic counter for all time, this gives us a way to
> > > recover from system failures.  Linkage to the TSA signature key is a
> > > natural delimiter since the counter would be unique per key and
> > the stated
> > > objective of the counter - to identify sequential time stamps containing
> > > the same time - would still be still achieved.
> > >
> > > Cheers,
> > >
> > > Bill Lattin
> > > TTFN Associates
> > >
> > > -----Original Message-----
> > > From:   Peter Gutmann [SMTP:[e-mail]]
> > > Sent:   Thursday, May 18, 2000 8:37 PM
> > > To:     [e-mail]; [e-mail]
> > > Cc:     [e-mail]
> > > Subject:        Re: TSA Response serialNumber Field
> > >
> > > [e-mail] writes:
> > >
> > > >To accomodate your issue we could add a comment in the ASN1 for the
> > > >serialNumber saying:
> > > >
> > > >-- Time Stamps users must be ready to accomodate integers up
> > to 64 bits.
> > >
> > > I think a more general way of putting this would be "...must be ready to
> > > accomodate integers larger than the machine's native word size", which
> > > warns
> > > of potential problems without implying that there's some magic
> > limit which
> > > they can expect to find.  Actually for anyone who's worked with certs on
> > > any scale, the use of 128-bit and 160-bit "serial numbers"
> > there should be
> > > enough of a warning.
> > >
> > > Peter.
> >


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA19044 for <[e-mail]>; Thu, 25 May 2000 00:30:06 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA21146; Thu, 25 May 2000 09:34:45 +0200
Message-ID: <[e-mail]>
Date: Thu, 25 May 2000 09:34:47 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks,

Do not ask more than what RFC 2459 is saying about the serial number
from a public key certificate;

Extract from RFC 2459 page 18, section 4.1.2.2:

   The serial number is an integer assigned by the CA to each
   certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a
unique
   certificate).

The same field in a TS token serves the same purpose. There is no
notion of sequentiality. Maybe we should have called it unique
number. This has not been done since we wanted to maintain
consistancy with ISO. In order to maintain consistancy between
standards, it would not be appropriate to change the name and/or the
concept.

Denis

> > I understand that using 20 octects allows to use the result of a
> > hash function and thus does not mandate any sequentiality. It also
> > has the further benefit to hide the number of time stamps generated.
> >
> 
> What do you mean by your first sentence 'sequentiality'?
> I guess you mean contiguous 'no holes in the sequence'?
> 
> Where is a hash in that scenario?
> 
> The requirement is to have unique values AND and that the numbers
> are ordered in time.
> 
> An example is to make a concatenation of a binary time value
> with some arbritrary precision, and a counter below like
> a STCK instruction on IBMs, time with 2**-20 seconds + 12 bits
> counter.
> 
> 
> 
>


Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA07961 for <[e-mail]>; Wed, 24 May 2000 20:48:53 -0700 (PDT)
Received: from winnt (1Cust145.tnt31.sfo3.da.uu.net [63.28.86.145]) by hawk.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id UAA01578; Wed, 24 May 2000 20:55:57 -0700 (PDT)
From: "William Lattin" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: TSA Response serialNumber Field
Date: Wed, 24 May 2000 20:57:03 -0700
Message-ID: <000101bfc5fd$495fb4f0$91561c3f@winnt>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Peter:

> Strictly increasing does not mean that you cannot have holes.

Agreed, but as written, one will have to pay carefull attention to ensure,
in the event of a failure, a sufficiently large jump ahead is made to ensure
a strictly increasing serial number.  My suspicion is this will require a
significant amount of work by humans.
>
> > The approach I suggested does allow for unique determination of a time
> > stamp, but to do so the validator must also have the
> certificate for the TSA
> > signature key.  I don't think this is unreasonable since proper
> verification
> > should include this information.
> In 30 years the certificate used may have no value anymore. A validation
> of the signature of the time stamp is only one method to validate it.
>
> The TSA has or should have to create logs of all time stamps, and it
> or someone else may provide a service to validate a time stamp by
> looking at the archive, in order to have at least two independant ways
> of validation.
>
> Well, that's not the point. You may need then to define a mechanism that
> compares two time stamps of *the same* authority with different
> keys. It may also happen that two key/certs are used in a roll-over
> situation with several servers in parallel.
>

There may be a variety of mechanisms to validate a time stamp. Your scenario
in which the certificate has no value and one must trust a list created by a
TSA is not a trust model to which I would subscribe.  This is an
implementation detail, however, so we don't need to resolve this here.  Key
transitions in server farms are also implementation details.  Neither
outright precludes the ability to use my suggested approach.

> >
> > The issue I am attempting to address is the requirement for a
> monotonically
> > increasing serial number for all time.  The draft does not
> address how to
> > recover from a situation where the serial number is lost due to
> equipment
> > failure.  Such a failure is likely to occur at least once over
> all time :-).
> > The approach I suggest above does allow graceful recovery,
> since one could
> > generate a new TSA signature key and certificate and start again with a
> > reset counter.
> >
> > I strongly suggest that we consider the ramifications of trying
> to assure
> > seamless operation for all time.  I don't think it is practical and we
> > should not design a standard requiring such.  I am open to
> other solutions
> > if the above suggestion is perceived as too burdensome.
>
> You can still do this if you include a time value in the number.
>
  True enough.

At the end of the day, both techniques will work.  IMHO, the approach I've
suggested would seem to provide a cleaner and more complete audit trail of
TSA time stamps.  The validation step does not require verification that the
strictly increasing hole was indeed that.

I rest here.  If others don't really view this as an issue then let the
current text stand.

Cheers,

Bill



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA00606 for <[e-mail]>; Wed, 24 May 2000 19:44:09 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <LS0CRKFX>; Wed, 24 May 2000 19:46:21 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Wed, 24 May 2000 19:46:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve:

Perhaps comment.

(1) You should realize that the text I quoted, repeated below from your
reply, is from RFC 2459.

(2) The text quoted is not some bullshit from Peter's English pen.

	(2.1) The text is the work of Ford et al., NIST/NSA, PKIX WG, 
		PKIX mailing list, IESG et al., and a PKIX WG and IETF Final
call.  

	(2.2) The text has been present in the I-Ds leading to RFC 2459 from
		very early moments of our mailing-list deliberations.

(3) You do not agree that the cited paragraph (from RFC 2459) represents
group consensus. That the same paragraph remains in son-of-2459 I-D is not 
relevant to you, presumably.

(4) You view the "supplement/replace" assumption stated by the authors
of RFC 2459, as stated in the 1st quoted sentence (from RFC 2459),
to be "out of the question". 

(5) You view the second sentence of the same quote (from RFC 2459) as 
"confusing."

(6) And...despite your repeated misdirections as chair, you will perhaps 
now agree that Peter did not write a word of the cited text that you
criticise so severely. THIS WG wrote and reviewed the text... 

(7) The text, which was discussed in mailing list discussions, also
passed Final Call in both PKIX WG and IETF Final Call.  

(8) IETF Final call is a conventional signal of consensus. But perhaps
not in PKIX WG, under the rules of our chairs.

(9) The use of quote symbols around text is an accepted practice to 
denote a quotation.

(10) The appendage of [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt] after
a quoted passage represents an accepted practice to clearly identify the
source of a quotation.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, May 24, 2000 8:42 AM
To: Peter Williams
Cc: [e-mail]
Subject: RE: SubjectAltName verification


Peter,

>    "Some communities will need to supplement, or possibly replace, this
>    profile in order to meet the requirements of specialized application
>    domains or environments with additional authorization, assurance, or
>    operational requirements.  However, for basic applications, common
>    representations of frequently used attributes are defined so that
>    application developers can obtain necessary information without
>    regard to the issuer of a particular certificate or certificate revo-
>    cation list (CRL)." [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt]
>
>Do you affirm the above to be group consensus?

No, I do not agree.

It seems out of place to insert text into a standard saying that "we 
understand if you don't want to use this standard."  So the first 
sentence is out of the question.

The second sentence confuses me.  What do you mean by "common 
representations of frequently used attributes?"  The "representation" 
of an attribute is its syntax, which is certainly part of the 
standard, but not the focus of this discussion.

Steve


Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11347 for <[e-mail]>; Wed, 24 May 2000 15:54:50 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320330b5520fa30e02@[165.227.249.13]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 24 May 2000 16:02:02 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: SubjectAltName verification
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I prefer Steve's wording to Warwick's. It is clearer and describes 
more of the limitations.

At 1:48 PM -0700 5/24/00, Warwick Ford wrote:
>With Steve's concurrence, I propose the following modified wording to the
>clause of concern:
>
>"The subject alternative name, like all other fields in a certificate and
>all certificate extensions, is considered to be bound to the public key.
>Thus the CA MUST verify (in accordance with the applicable certificate
>policy and/or the CPS) all subject alternative names."
>
>Warwick
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Wednesday, May 24, 2000 8:05 AM
>To: Denis Pinkas
>Cc: [e-mail]
>Subject: Re: SubjectAltName verification
>
>
>[snip]
>
>I worry that we are unduly singling out this attribute, even though
>ALL the attributes have the same sort of requirement. How about:
>
>"The subject alternative name, like all other fields in a certificate
>and all certificate extensions, is considered to be definitively
>bound to the public key. Thus the CA MUST verify (directly or
>indirectly) all subject alternative names. The precise nature of the
>verification is detailed in the certificate policy and/or the CPS."
>
>Steve


Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08476 for <[e-mail]>; Wed, 24 May 2000 13:42:55 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA27299; Wed, 24 May 2000 13:49:24 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <L3SVVAAM>; Wed, 24 May 2000 13:48:20 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Wed, 24 May 2000 13:48:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

With Steve's concurrence, I propose the following modified wording to the
clause of concern:

"The subject alternative name, like all other fields in a certificate and
all certificate extensions, is considered to be bound to the public key.
Thus the CA MUST verify (in accordance with the applicable certificate
policy and/or the CPS) all subject alternative names."

Warwick

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, May 24, 2000 8:05 AM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: SubjectAltName verification


[snip]

I worry that we are unduly singling out this attribute, even though 
ALL the attributes have the same sort of requirement. How about:

"The subject alternative name, like all other fields in a certificate 
and all certificate extensions, is considered to be definitively 
bound to the public key. Thus the CA MUST verify (directly or 
indirectly) all subject alternative names. The precise nature of the 
verification is detailed in the certificate policy and/or the CPS."

Steve


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02098 for <[e-mail]>; Wed, 24 May 2000 09:41:25 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA22914; Wed, 24 May 2000 18:48:30 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 24 May 2000 18:48:31 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA07186; Wed, 24 May 2000 18:48:28 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA03157; Wed, 24 May 2000 18:48:28 +0200 (MET DST)
Date: Wed, 24 May 2000 18:48:28 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: TSA Response serialNumber Field
Cc: [e-mail]

Strictly increasing does not mean that you cannot have holes. 

> The approach I suggested does allow for unique determination of a time
> stamp, but to do so the validator must also have the certificate for the TSA
> signature key.  I don't think this is unreasonable since proper verification
> should include this information.
In 30 years the certificate used may have no value anymore. A validation
of the signature of the time stamp is only one method to validate it. 

The TSA has or should have to create logs of all time stamps, and it
or someone else may provide a service to validate a time stamp by
looking at the archive, in order to have at least two independant ways
of validation. 

Well, that's not the point. You may need then to define a mechanism that
compares two time stamps of *the same* authority with different
keys. It may also happen that two key/certs are used in a roll-over
situation with several servers in parallel. 

> 
> The issue I am attempting to address is the requirement for a monotonically
> increasing serial number for all time.  The draft does not address how to
> recover from a situation where the serial number is lost due to equipment
> failure.  Such a failure is likely to occur at least once over all time :-).
> The approach I suggest above does allow graceful recovery, since one could
> generate a new TSA signature key and certificate and start again with a
> reset counter.
> 
> I strongly suggest that we consider the ramifications of trying to assure
> seamless operation for all time.  I don't think it is practical and we
> should not design a standard requiring such.  I am open to other solutions
> if the above suggestion is perceived as too burdensome.

You can still do this if you include a time value in the number. 



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01563 for <[e-mail]>; Wed, 24 May 2000 09:15:23 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA22212; Wed, 24 May 2000 18:22:03 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 24 May 2000 18:22:03 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA07063; Wed, 24 May 2000 18:22:00 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA03150; Wed, 24 May 2000 18:22:00 +0200 (MET DST)
Date: Wed, 24 May 2000 18:22:00 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail], [e-mail], [e-mail]

> I understand that using 20 octects allows to use the result of a
> hash function and thus does not mandate any sequentiality. It also
> has the further benefit to hide the number of time stamps generated.
> 

What do you mean by your first sentence 'sequentiality'? 
I guess you mean contiguous 'no holes in the sequence'?  

Where is a hash in that scenario? 

The requirement is to have unique values AND and that the numbers
are ordered in time.

An example is to make a concatenation of a binary time value
with some arbritrary precision, and a counter below like
a STCK instruction on IBMs, time with 2**-20 seconds + 12 bits
counter.

 



 



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29711 for <[e-mail]>; Wed, 24 May 2000 08:33:39 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA11740; Wed, 24 May 2000 11:40:47 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220802b551a7bc92e0@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 24 May 2000 11:41:32 -0400
To: Peter Williams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>    "Some communities will need to supplement, or possibly replace, this
>    profile in order to meet the requirements of specialized application
>    domains or environments with additional authorization, assurance, or
>    operational requirements.  However, for basic applications, common
>    representations of frequently used attributes are defined so that
>    application developers can obtain necessary information without
>    regard to the issuer of a particular certificate or certificate revo-
>    cation list (CRL)." [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt]
>
>Do you affirm the above to be group consensus?

No, I do not agree.

It seems out of place to insert text into a standard saying that "we 
understand if you don't want to use this standard."  So the first 
sentence is out of the question.

The second sentence confuses me.  What do you mean by "common 
representations of frequently used attributes?"  The "representation" 
of an attribute is its syntax, which is certainly part of the 
standard, but not the focus of this discussion.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28832 for <[e-mail]>; Wed, 24 May 2000 08:01:54 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA06968; Wed, 24 May 2000 11:08:41 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b5519f0f9dde@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>	 <v04220811b54a0fdf6fcc@[128.33.238.33]> <[e-mail]> <v0422080ab55067a93675@[171.78.30.107]> <[e-mail]>
Date: Wed, 24 May 2000 11:05:24 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>Steve,
>
>Let us try now to agree on a text replacement. I have had some
>private exchanges with Russ where I have proposed the following:
>
>The current text is as follows:
>
>    Because the subject alternative name is considered to be
>    definitiviely bound to the public key, all parts of the subject
>    alternative name MUST be verified by the CA.
>
>Using a mixture of both texts, here *was* the proposal:
>
>Because the subject alternative name is considered to be
>definitiviely bound to the public key, the CA is expected
>to perform verification (directly or indirectly) for all
>parts of the subject alternative name, leaving to the policy
>and/or CPS to refine the level of verification performed.
>
>In order to incorporate a "MUST", I would propose the following:
>
>Because the subject alternative name is considered to be
>definitiviely bound to the public key, the CA MUST
>perform verification (directly or indirectly) for all
>parts of the subject alternative name, leaving to the policy
>and/or CPS to refine the level of verification performed.
>
>Can you agree on this ?

I worry that we are unduly singling out this attribute, even though 
ALL the attributes have the same sort of requirement. How about:

"The subject alternative name, like all other fields in a certificate 
and all certificate extensions, is considered to be definitively 
bound to the public key. Thus the CA MUST verify (directly or 
indirectly) all subject alternative names. The precise nature of the 
verification is detailed in the certificate policy and/or the CPS."

Steve



Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27900 for <[e-mail]>; Wed, 24 May 2000 07:34:57 -0700 (PDT)
Received: from winnt (1Cust69.tnt22.sfo3.da.uu.net [63.27.230.69]) by scaup.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id HAA17538; Wed, 24 May 2000 07:41:50 -0700 (PDT)
From: "William Lattin" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: TSA Response serialNumber Field
Date: Wed, 24 May 2000 07:42:56 -0700
Message-ID: <000001bfc58e$594623a0$45e61b3f@winnt>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Denis,

The approach I suggested does allow for unique determination of a time
stamp, but to do so the validator must also have the certificate for the TSA
signature key.  I don't think this is unreasonable since proper verification
should include this information.

The issue I am attempting to address is the requirement for a monotonically
increasing serial number for all time.  The draft does not address how to
recover from a situation where the serial number is lost due to equipment
failure.  Such a failure is likely to occur at least once over all time :-).
The approach I suggest above does allow graceful recovery, since one could
generate a new TSA signature key and certificate and start again with a
reset counter.

I strongly suggest that we consider the ramifications of trying to assure
seamless operation for all time.  I don't think it is practical and we
should not design a standard requiring such.  I am open to other solutions
if the above suggestion is perceived as too burdensome.

Cheers,

Bill

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, May 24, 2000 01:47
> To: [e-mail]
> Cc: '[e-mail]'; '[e-mail]';
> '[e-mail]'
> Subject: Re: TSA Response serialNumber Field
>
>
> Bill,
>
> Your proposal would not allow to unambiguously distinguing two TS
> token using the TSA mane and the serialNumber. The same issue arises
> in other documents. For example, in draft-ietf-pkix-ac509prof-03.txt
> there is the following text.
>
> Given the uniqueness and timing requirements above serial numbers
> can be expected to contain long integers. AC users MUST be able to
> handle serialNumber values longer than 4 octets. Conformant ACs MUST
> NOT contain serialNumber values longer than 20 octets.
>
> We could take the text proposed by Peter, which is a good warning,
> but does not include an upper limit.
> I understand that using 20 octects allows to use the result of a
> hash function and thus does not mandate any sequentiality. It also
> has the further benefit to hide the number of time stamps generated.
>
> I would thus propose to have a text like:
>
> Given the uniqueness and timing requirements above serial numbers
> can be expected to contain long integers, TSA users MUST be able to
> handle serialNumber values longer than 4 octets. Conformant Time
> Stamps MUST NOT contain serialNumber values longer than 20 octets.
>
> Can we agree on this ?
>
> Denis
>
>
> > I think a better way to address this would be to reset the
> counter when the
> > TSA signature key pair is generated.  This way, we could be
> more confident
> > that a 64-bit counter is sufficient, plus given the real world
> difficulties
> > of guaranteeing a monotonic counter for all time, this gives us a way to
> > recover from system failures.  Linkage to the TSA signature key is a
> > natural delimiter since the counter would be unique per key and
> the stated
> > objective of the counter - to identify sequential time stamps containing
> > the same time - would still be still achieved.
> >
> > Cheers,
> >
> > Bill Lattin
> > TTFN Associates
> >
> > -----Original Message-----
> > From:   Peter Gutmann [SMTP:[e-mail]]
> > Sent:   Thursday, May 18, 2000 8:37 PM
> > To:     [e-mail]; [e-mail]
> > Cc:     [e-mail]
> > Subject:        Re: TSA Response serialNumber Field
> >
> > [e-mail] writes:
> >
> > >To accomodate your issue we could add a comment in the ASN1 for the
> > >serialNumber saying:
> > >
> > >-- Time Stamps users must be ready to accomodate integers up
> to 64 bits.
> >
> > I think a more general way of putting this would be "...must be ready to
> > accomodate integers larger than the machine's native word size", which
> > warns
> > of potential problems without implying that there's some magic
> limit which
> > they can expect to find.  Actually for anyone who's worked with certs on
> > any scale, the use of 128-bit and 160-bit "serial numbers"
> there should be
> > enough of a warning.
> >
> > Peter.
>



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27412 for <[e-mail]>; Wed, 24 May 2000 07:19:16 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id CAA05677; Thu, 25 May 2000 02:26:07 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95917836715346>; Thu, 25 May 2000 02:26:07 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 25 May 2000 02:26:07 (NZST)
Message-ID: <[e-mail]>

>I understand that using 20 octects allows to use the result of a hash function
>and thus does not mandate any sequentiality. It also has the further benefit
>to hide the number of time stamps generated.

Limiting it to a current hash size may cause problems in the future, when SHA-2
appears (accompanied by an edict that "All organisations shall transition to
use of SHA-2 by 2005") then the 20-byte upper limit is going to be a problem.

Peter.



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26950 for <[e-mail]>; Wed, 24 May 2000 06:58:25 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqom03406; Wed, 24 May 2000 14:05:30 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA21749; Wed, 24 May 00 10:02:03 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA09651; Wed, 24 May 2000 10:05:29 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 24 May 2000 10:05:28 -0400 (EDT)
To: [e-mail]
Cc: <[e-mail]>
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Denis" == Denis Pinkas <[e-mail]> writes:

 Denis> ...
 Denis> We could take the text proposed by Peter, which is a good
 Denis> warning, but does not include an upper limit.  I understand
 Denis> that using 20 octects allows to use the result of a hash
 Denis> function and thus does not mandate any sequentiality. It also
 Denis> has the further benefit to hide the number of time stamps
 Denis> generated.

 Denis> I would thus propose to have a text like:

 Denis> Given the uniqueness and timing requirements above serial
 Denis> numbers can be expected to contain long integers, TSA users
 Denis> MUST be able to handle serialNumber values longer than 4
 Denis> octets. Conformant Time Stamps MUST NOT contain serialNumber
 Denis> values longer than 20 octets.

Sounds good.

If the intent is to allow hash function outputs -- and that is a good
feature -- then I question the use of the name "serial number".  The
problem with that name is that it implies sequentiality.  If the only
property required is uniqueness, then "Unique ID" is a better name.

Incidentally, note that a 20 bytes hash function does not guarantee
2^160 unique values.  By the birthday rule, you have a good chance of
a duplicate after 2^80 values have been generated.  So in fact it
would be wise not to use such a hash for more than 2^64 or so values,
which is fine since you're not going to go that high anyway in any
plausible amount of time....

      paul


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA13095 for <[e-mail]>; Wed, 24 May 2000 02:29:16 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA15268; Wed, 24 May 2000 11:36:18 +0200
Message-ID: <[e-mail]>
Date: Wed, 24 May 2000 11:36:20 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Rationale for Nonce in Time Stamp Protocol
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Francois,

I realized that I ommited to reply to your E-mail.
 
> Salut Denis,
> 
> I do not remember if this issue was raised before, but in Section 2.2 the
> following statement is made:
> 
> "the requesting entity .... SHALL then verify the timeliness of the response
> by verifying either the time included in the response against a local
> trusted time reference, if one is available, and/or the value of the nonce
> (large random number with a high probability that it is generated by the
> client only once) included in the response against the value included in the
> request."
> 
> A nonce is normally used to detect attempts at replays, which is not
> necessarily related to the timeliness of the response to a particular
> request as mentioned here.
> 
> The first part of the statement talks about verifying the time included in
> the response against a locally trusted time source.  This could used to
> measure round trip path delay for calibration purposes, 

No. This is not the goal. The goal is to make sure that you have no
replay, in particular on the same hash value.

> but unless one could
> be certain that the locally trusted source is as accurate as the TSA time
> source (or, at least, that the difference between them is fixed and
> well-known), I don't see how it would detect/prevent replays. 

Using a moving time window the caller remembers all the hashes he
sent during that time window.
If there is not the same hash value within that time window, then he
makes sure that the time of the response is within the time window.
If there is the same hash (a very rare situation), it is a little
bit more complicated, and there are several options. Among them:
using the nonce, or waiting until the time window has moved to come
back to the previous case: only one hash value during that time
window. But we are talking implementations details, which is not the
topic of an RFC.

>  If one has
> such a trusted time source locally, what is the point in using a TTP for
> time stamping?

The time is locally trusted, ... which does not mean that other
people will trust that time.

> 
> Could you please clarify the intent of this statement and if the intent is
> to prevent replays or check the timeliness of responses or both?

Now, that you have the explanations, if you still believe that the
text is not clear enough, I suggest that you submit a proposal to
clarify the text.

Regards,

Denis

> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11360 for <[e-mail]>; Wed, 24 May 2000 01:40:35 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA20688; Wed, 24 May 2000 10:46:56 +0200
Message-ID: <[e-mail]>
Date: Wed, 24 May 2000 10:46:57 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bill,

Your proposal would not allow to unambiguously distinguing two TS
token using the TSA mane and the serialNumber. The same issue arises
in other documents. For example, in draft-ietf-pkix-ac509prof-03.txt
there is the following text.

Given the uniqueness and timing requirements above serial numbers
can be expected to contain long integers. AC users MUST be able to
handle serialNumber values longer than 4 octets. Conformant ACs MUST
NOT contain serialNumber values longer than 20 octets.

We could take the text proposed by Peter, which is a good warning,
but does not include an upper limit.
I understand that using 20 octects allows to use the result of a
hash function and thus does not mandate any sequentiality. It also
has the further benefit to hide the number of time stamps generated.

I would thus propose to have a text like:

Given the uniqueness and timing requirements above serial numbers
can be expected to contain long integers, TSA users MUST be able to
handle serialNumber values longer than 4 octets. Conformant Time 
Stamps MUST NOT contain serialNumber values longer than 20 octets.

Can we agree on this ?

Denis

 
> I think a better way to address this would be to reset the counter when the
> TSA signature key pair is generated.  This way, we could be more confident
> that a 64-bit counter is sufficient, plus given the real world difficulties
> of guaranteeing a monotonic counter for all time, this gives us a way to
> recover from system failures.  Linkage to the TSA signature key is a
> natural delimiter since the counter would be unique per key and the stated
> objective of the counter - to identify sequential time stamps containing
> the same time - would still be still achieved.
> 
> Cheers,
> 
> Bill Lattin
> TTFN Associates
> 
> -----Original Message-----
> From:   Peter Gutmann [SMTP:[e-mail]]
> Sent:   Thursday, May 18, 2000 8:37 PM
> To:     [e-mail]; [e-mail]
> Cc:     [e-mail]
> Subject:        Re: TSA Response serialNumber Field
> 
> [e-mail] writes:
> 
> >To accomodate your issue we could add a comment in the ASN1 for the
> >serialNumber saying:
> >
> >-- Time Stamps users must be ready to accomodate integers up to 64 bits.
> 
> I think a more general way of putting this would be "...must be ready to
> accomodate integers larger than the machine's native word size", which
> warns
> of potential problems without implying that there's some magic limit which
> they can expect to find.  Actually for anyone who's worked with certs on
> any scale, the use of 128-bit and 160-bit "serial numbers" there should be
> enough of a warning.
> 
> Peter.


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA10234 for <[e-mail]>; Wed, 24 May 2000 01:23:10 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA41882; Wed, 24 May 2000 10:30:09 +0200
Message-ID: <[e-mail]>
Date: Wed, 24 May 2000 10:30:11 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <v04220811b54a0fdf6fcc@[128.33.238.33]> <[e-mail]> <v0422080ab55067a93675@[171.78.30.107]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

Let us try now to agree on a text replacement. I have had some
private exchanges with Russ where I have proposed the following:

The current text is as follows:

   Because the subject alternative name is considered to be
   definitiviely bound to the public key, all parts of the subject
   alternative name MUST be verified by the CA.

Using a mixture of both texts, here *was* the proposal:

Because the subject alternative name is considered to be
definitiviely bound to the public key, the CA is expected
to perform verification (directly or indirectly) for all 
parts of the subject alternative name, leaving to the policy
and/or CPS to refine the level of verification performed.

In order to incorporate a "MUST", I would propose the following:

Because the subject alternative name is considered to be
definitiviely bound to the public key, the CA MUST
perform verification (directly or indirectly) for all 
parts of the subject alternative name, leaving to the policy
and/or CPS to refine the level of verification performed.

Can you agree on this ?

Denis

> Denis,
> 
> >Let me extract two of your statements:
> >
> >(snip)
> >
> >  > >Also, as both Denis and I pointed out,
> >  > >there are wide variations in the meaning of "verify", some of them being
> >  > >arguably very weak. Where does one draw the line between very weak
> >  > >verification and no verification?
> >
> >  > Fair point.
> >
> >  > I think its important that PKIX continue to express the
> >  > notion that a CA is expected to perform verification (directly or
> >  > indirectly) for all attributes in a cert, leaving to the policy
> >  > and/or CPS to refine the level of verification performed.
> >
> >(snip)
> >
> >  > Still, I
> >  > do believe PKIX should continue to promote the notion, through our
> >  > standards, that the contents of a certificate represent data that the
> >  > issuer has verified and thus stands behind. To do otherwise would
> >  > endorse behavior that creates confusion, a generally undesirable
> >  > security characteristic.
> >
> >The later statement is different from the former. I like the former.
> >Can we build a consensus around it ?
> >
> >If so, this should be reflected in the "son-of-RFC2459".
> 
> The former is more appropriate for inclusion in the revised RFC;  the
> latter statement was more of a rationale for my position.
> 
> Steve


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27561 for <[e-mail]>; Tue, 23 May 2000 16:38:13 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA30912; Wed, 24 May 2000 09:49:35 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <L3WNLG5W>; Wed, 24 May 2000 09:43:43 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: TSA Response serialNumber Field
Date: Wed, 24 May 2000 09:43:41 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

A very fair comment, Bill. Worth mentioning in the draft, Denis?

> -----Original Message-----
> From: Bill Lattin [mailto:[e-mail]]
> Sent: Wednesday, May 24, 2000 1:14 AM
> To: '[e-mail]'; '[e-mail]';
> '[e-mail]'
> Cc: '[e-mail]'
> Subject: RE: TSA Response serialNumber Field
> 
> 
> I think a better way to address this would be to reset the 
> counter when the 
> TSA signature key pair is generated.  This way, we could be 
> more confident 
> that a 64-bit counter is sufficient, plus given the real 
> world difficulties 
> of guaranteeing a monotonic counter for all time, this gives 
> us a way to 
> recover from system failures.  Linkage to the TSA signature key is a 
> natural delimiter since the counter would be unique per key 
> and the stated 
> objective of the counter - to identify sequential time stamps 
> containing 
> the same time - would still be still achieved.
> 
> Cheers,
> 
> Bill Lattin
> TTFN Associates
> 
> -----Original Message-----
> From:	Peter Gutmann [SMTP:[e-mail]]
> Sent:	Thursday, May 18, 2000 8:37 PM
> To:	[e-mail]; [e-mail]
> Cc:	[e-mail]
> Subject:	Re: TSA Response serialNumber Field
> 
> [e-mail] writes:
> 
> >To accomodate your issue we could add a comment in the ASN1 for the
> >serialNumber saying:
> >
> >-- Time Stamps users must be ready to accomodate integers up 
> to 64 bits.
> 
> I think a more general way of putting this would be "...must 
> be ready to
> accomodate integers larger than the machine's native word 
> size", which 
> warns
> of potential problems without implying that there's some 
> magic limit which
> they can expect to find.  Actually for anyone who's worked 
> with certs on
> any scale, the use of 128-bit and 160-bit "serial numbers" 
> there should be
> enough of a warning.
> 
> Peter.
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26688 for <[e-mail]>; Tue, 23 May 2000 15:36:15 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <LQRCL2QZ>; Tue, 23 May 2000 15:38:31 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Tue, 23 May 2000 15:38:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve:

   "Some communities will need to supplement, or possibly replace, this
   profile in order to meet the requirements of specialized application
   domains or environments with additional authorization, assurance, or
   operational requirements.  However, for basic applications, common
   representations of frequently used attributes are defined so that
   application developers can obtain necessary information without
   regard to the issuer of a particular certificate or certificate revo-
   cation list (CRL)." [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt]

Do you affirm the above to be group consensus?

Peter.


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Tuesday, May 23, 2000 1:33 PM
To: Peter Williams
Cc: [e-mail]
Subject: RE: SubjectAltName verification


Peter,

>Steve:
>
>You question me if enough is said. I demurr from the
>suggested rewriting of my contribution, in what is
>hopefully my last message on this topic.
>
>I had not assumed any need for restatement of the
>IETF-community consensus concerning the legitimacy
>of intentional non-conformity - when operating
>Internet protocols and services.
>
>There was and perhaps is a continuing need to restate
>the *additional* "PKI-specific" consensus positions
>concerning "supplementing and replacing" PKIX
>recommendations and mandates, as stated in 2459.
>
>Perhaps we can be of one mind by engaging in a joint
>action:
>
>Perhaps we can both now reaffirm our support for the position
>that the obvious meaning of, if the not the very text of, the
>"supplement/replace language" present in the
>previously-referenced element of RFC 2459
>Section 2 should continue to be expressed in all subsequent
>versions of the Internet X.509 Certificate and CRL Profile.
>
>Do we reaffirm the consensus on MY point, or not?
>
>I think this is the real question.

For a native speaker of English, your writing often seems unduly obscure.

I don't recall what your proposed rewording of 2459 is. However, if 
it differs significantly from the first of two statement by me that 
Denis cited in his message, then it is probably the case that I do 
NOT affirm (much less reaffirm) a WG consensus on YOUR point.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24317 for <[e-mail]>; Tue, 23 May 2000 13:26:47 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA00171; Tue, 23 May 2000 16:33:46 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220815b5509a9f2f8e@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 23 May 2000 16:33:00 -0400
To: Peter Williams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>Steve:
>
>You question me if enough is said. I demurr from the
>suggested rewriting of my contribution, in what is
>hopefully my last message on this topic.
>
>I had not assumed any need for restatement of the
>IETF-community consensus concerning the legitimacy
>of intentional non-conformity - when operating
>Internet protocols and services.
>
>There was and perhaps is a continuing need to restate
>the *additional* "PKI-specific" consensus positions
>concerning "supplementing and replacing" PKIX
>recommendations and mandates, as stated in 2459.
>
>Perhaps we can be of one mind by engaging in a joint
>action:
>
>Perhaps we can both now reaffirm our support for the position
>that the obvious meaning of, if the not the very text of, the
>"supplement/replace language" present in the
>previously-referenced element of RFC 2459
>Section 2 should continue to be expressed in all subsequent
>versions of the Internet X.509 Certificate and CRL Profile.
>
>Do we reaffirm the consensus on MY point, or not?
>
>I think this is the real question.

For a native speaker of English, your writing often seems unduly obscure.

I don't recall what your proposed rewording of 2459 is. However, if 
it differs significantly from the first of two statement by me that 
Denis cited in his message, then it is probably the case that I do 
NOT affirm (much less reaffirm) a WG consensus on YOUR point.

Steve



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23875 for <[e-mail]>; Tue, 23 May 2000 13:15:30 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <LQH17R0P>; Tue, 23 May 2000 13:17:44 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Tue, 23 May 2000 13:17:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve:

You question me if enough is said. I demurr from the
suggested rewriting of my contribution, in what is
hopefully my last message on this topic.

I had not assumed any need for restatement of the
IETF-community consensus concerning the legitimacy
of intentional non-conformity - when operating 
Internet protocols and services.

There was and perhaps is a continuing need to restate 
the *additional* "PKI-specific" consensus positions 
concerning "supplementing and replacing" PKIX 
recommendations and mandates, as stated in 2459.

Perhaps we can be of one mind by engaging in a joint 
action:

Perhaps we can both now reaffirm our support for the position
that the obvious meaning of, if the not the very text of, the 
"supplement/replace language" present in the 
previously-referenced element of RFC 2459 
Section 2 should continue to be expressed in all subsequent
versions of the Internet X.509 Certificate and CRL Profile.

Do we reaffirm the consensus on MY point, or not?

I think this is the real question.
 
Peter.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Tuesday, May 23, 2000 12:30 PM
To: Peter Williams
Cc: [e-mail]
Subject: RE: SubjectAltName verification


Peter,

>Internet CAs are free, and must be free, to operate public-key
>certification according to wholly-private practices. This includes
>acting in PKIX-non-conforming or other PKIX opt-out manners, where
>(nationally-regulated) CAs and such CA's alone designate such practices
>to be appropriate to meet their interworking communities security needs.

Your message seems to cover the bases, i.e., a CA can always choose 
to be non-conforming with PKIX.

So, 'nuf said, right?

Steve


Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA23364 for <[e-mail]>; Tue, 23 May 2000 13:05:20 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Tue, 23 May 2000 16:13:24 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 23 May 2000 16:12:07 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Next round of CMP testing -- jun 6 - 8
In-Reply-To: <v0422080db5508c54d3db@[171.78.30.107]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

ICSA and the PKI Forum is getting ready for the next round of CMP testing.

This is a virtual workshop for Jun 6 - 8.

So far, 8 vendors have indicated that they are ready for more testing then, 
and a few more are expecting to be ready then as well.

Please contact me at [e-mail] if you are developing a CMP 
implementation and wish to participate in this or one of the later workshops.

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22469 for <[e-mail]>; Tue, 23 May 2000 12:26:55 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA22055; Tue, 23 May 2000 15:33:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080db5508c54d3db@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 23 May 2000 15:29:38 -0400
To: Peter Williams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>Internet CAs are free, and must be free, to operate public-key
>certification according to wholly-private practices. This includes
>acting in PKIX-non-conforming or other PKIX opt-out manners, where
>(nationally-regulated) CAs and such CA's alone designate such practices
>to be appropriate to meet their interworking communities security needs.

Your message seems to cover the bases, i.e., a CA can always choose 
to be non-conforming with PKIX.

So, 'nuf said, right?

Steve



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21981 for <[e-mail]>; Tue, 23 May 2000 12:10:30 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <LQH17RRN>; Tue, 23 May 2000 12:12:40 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Tue, 23 May 2000 12:12:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Internet CAs are free, and must be free, to operate public-key
certification according to wholly-private practices. This includes 
acting in PKIX-non-conforming or other PKIX opt-out manners, where
(nationally-regulated) CAs and such CA's alone designate such practices 
to be appropriate to meet their interworking communities security needs. 

http://www.ietf.org/rfc/rfc2459.txt Section 2.

 

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Tuesday, May 23, 2000 9:53 AM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: SubjectAltName verification


Denis,

>Let me extract two of your statements:
>
>(snip)
>
>  > >Also, as both Denis and I pointed out,
>  > >there are wide variations in the meaning of "verify", some of them
being
>  > >arguably very weak. Where does one draw the line between very weak
>  > >verification and no verification?
>
>  > Fair point.
>
>  > I think its important that PKIX continue to express the
>  > notion that a CA is expected to perform verification (directly or
>  > indirectly) for all attributes in a cert, leaving to the policy
>  > and/or CPS to refine the level of verification performed.
>
>(snip)
>
>  > Still, I
>  > do believe PKIX should continue to promote the notion, through our
>  > standards, that the contents of a certificate represent data that the
>  > issuer has verified and thus stands behind. To do otherwise would
>  > endorse behavior that creates confusion, a generally undesirable
>  > security characteristic.
>
>The later statement is different from the former. I like the former.
>Can we build a consensus around it ?
>
>If so, this should be reflected in the "son-of-RFC2459".

The former is more appropriate for inclusion in the revised RFC;  the 
latter statement was more of a rationale for my position.

Steve


Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19987 for <[e-mail]>; Tue, 23 May 2000 10:52:42 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320307b550772f168c@[165.227.249.13]>
Date: Tue, 23 May 2000 10:59:45 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Requirements for remote path processing services
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

After the discussion in Adelaide, a group of us got together to hammer
out what we consider requirements for remote path processing services.
The general consensus of that group follows. The group who came to
agreement that these are in fact a good statement of requirements
include:

Ambarish Malpani, ValiCert
Carlisle Adams, Entrust
Michael Myers, VeriSign
Michael Zolotarev, Baltimore
Paul Hoffman, IMC & VPNC
Peter Sylvester, EdelWeb
Stephen Farrell, Baltimore
Stephen Kent, BBN

1. Requirements for remote path processing services

Remote path processing provides two primary services: delegated path
construction for client-based path validation, and delegated path
validation. Not all clients require both services in all scenarios. Many
clients require only delegated path construction (including path
discovery) to help them perform their own path validation, while other
clients have requirements for offloaded path validation and have no need
for data acquisition.

The delegated path construction features of remote path processing are
valuable for clients that do much of the PKI processing themselves and
simply want a server to collect information for them. The server need
not even be trusted, because the client will ultimately perform path
validation. Offloading path validation to a server may be required by a
client that lacks the processing, and/or communication capabilities to
perform path discovery and path validation. (Path discovery may not be
required in all cases, e.g., some applications provide means for
certification paths to be transmitted as part of the protocol.) Another
motivation for offloading path validation is that it allows centralized
management of validation policies in a consistent fashion across an
enterprise.

A client that performs path validation for itself may still benefit in
several ways from using a server to acquire certificates, CRLs, and OCSP
responses to aid in the validation process. In this context, the client
is relying on the server to interact with repositories to acquire the
data that the client would otherwise have to acquire using LDAP, HTTP,
and so on. Since these data items are digitally signed, the client need
not trust the server to return the "right" data any more than the client
would have to trust the repositories. There are several benefits to this
approach; for example, a single query to a server can replace multiple
queries to one or more directories and caching by the server can reduce
latency. Another benefit to the client system is that it need not
incorporate a diverse set of software to interact with various forms of
repositories, perhaps via different protocols, nor to perform the graph
processing necessary to discover paths, separate from making the queries
to acquire path validation data.

A client whose networking and/or processing capabilities are limited may
be unable to perform path validation itself. In this case, there must be
a fully-trusted server to which the client can delegate path validation
services. Such a server can take direction from the client about how
path validation should be done (such as which roots are to be trusted),
and the server can even provide to the client proof (e.g., certificates
and CRLs or OCSP responses) of how the server validated the target
certificate. Even clients that are able to do their own path validation
might instead rely on a trusted server to do path validation if the
client is in an environment where centralized management of trusted
roots or centralized management of non-standard policy processing is
needed for some applications.

1.1 Collecting path validation information

An untrusted server can provide a client the certificate path needed for
path validation. It also can provide clients with revocation
information, e.g., CRLs and OCSP responses, that the client can use to
perform path validation. These services can be valuable to client
systems that do not include the protocols needed to find and download
all of the intermediate certificates, CRLs, and OCSP responses needed
for the client to perform complete path validation.

1.2 Delegating path validation

A server can perform full certificate validation for the client. If a
client uses this service, it inherently trusts the server as much as it
would its own path validation software (if it contained such software).
One reason that a client may want to delegate to such a server is that
the client does not have sufficient processing or networking resources
to perform path validation for each certificate it receives. In
addition, because the algorithms required for path validation are
complex, not all applications may embody high quality implementations of
this processing. In constrained execution environments such as
telephones and PDAs, memory and processing limitations may preclude
implementation of complete, PKIX-compliant path validation.

In applications where minimum latency is critical, delegating validation
to a trusted server can offer significant advantages. The time required
to send the target certificate to the validation server, receive the
response, and verify the signature on the response, can be considerably
less than the time required by the client to perform path discovery and
validation. Even if a certificate path were readily available to the
client, the delay associated with processing the signatures for each
certificate in the path might (under some circumstances such as very
long paths or very limited processor speed) be greater than the delay
associated with use of a validation server.

1.3 Centralized trust and policy

Organizations that impose a centralized management discipline usually
want consistent policy enforcement across all clients in particular
scenarios. In such cases, allowing a client to manage its own set of
trusted roots or the policies that it accepts during path validation is
unacceptable. A trusted server can enforce particular policy decisions
while performing path validation. Also, experience shows that it is
difficult to manage software configuration on end systems in a corporate
environment.

Because path validation software is controlled by many parameters which,
if incorrectly set, may result in insecure behavior, it is often
important to be able to centralize path validation in a single or small
set of servers, where system security administrators can carefully
manage them. Both services (delegated path construction and delegated
path validation) can be potentially used by the enterprise for enforcing
various aspects of centralized policy.

Note that it is not clear which aspects of PKI policy can, in general,
be usefully separated from other application specific policy using this
approach. This is a matter for further study.

--Paul Hoffman, Director
--VPN Consortium


Received: from 5sigexch1.hq.5sigcmd.army.mil (5sigexch1.hq.5sigcmd.army.mil [147.40.98.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18703 for <[e-mail]>; Tue, 23 May 2000 10:04:10 -0700 (PDT)
Received: by 5sigexch1.hq.5sigcmd.army.mil with Internet Mail Service (5.5.2650.10) id <KTDMLL86>; Tue, 23 May 2000 19:11:13 +0200
Message-ID: <[e-mail]>
From: "Stringfield, Robert Mr." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: FQDN vs ALIAS
Date: Tue, 23 May 2000 19:11:06 +0200
X-Mailer: Internet Mail Service (5.5.2650.10)

Is this question acceptable to this list?  If not could you provide me with
pointers as we have no ideas :-)....
--bob

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, May 23, 2000 6:41 PM
To: [e-mail]
Subject: FQDN vs ALIAS


Mr. Stringfield,

I work with Jenny Dolak here at Ft Huachuca in PKI Server registration.   I
have recently had several questions concerning how a certificate should be
registered when an Alias is involved, and cannot seem to find an answer.
The only rule I know is that the certificate should be registered using the
FQDN, but I can't have the SA's do this if the certificate will not work
when their people are redirected.  Have you come across this problem before?
Any hints or directions to an answer would be greatly appreciated.

Thank you,

Wendy Reid
Network Administration Team
Army Network and Systems Operations Center (ANSOC)
U.S. Army Signal Command, ATTN: AFSN-NN
Fort Huachuca, AZ  85613-5000
520-538-1247 DSN 879-1247 FAX [phone]
[e-mail]


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18183 for <[e-mail]>; Tue, 23 May 2000 09:47:20 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA00531; Tue, 23 May 2000 12:54:19 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080ab55067a93675@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <v04220811b54a0fdf6fcc@[128.33.238.33]> <[e-mail]>
Date: Tue, 23 May 2000 12:52:58 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>Let me extract two of your statements:
>
>(snip)
>
>  > >Also, as both Denis and I pointed out,
>  > >there are wide variations in the meaning of "verify", some of them being
>  > >arguably very weak. Where does one draw the line between very weak
>  > >verification and no verification?
>
>  > Fair point.
>
>  > I think its important that PKIX continue to express the
>  > notion that a CA is expected to perform verification (directly or
>  > indirectly) for all attributes in a cert, leaving to the policy
>  > and/or CPS to refine the level of verification performed.
>
>(snip)
>
>  > Still, I
>  > do believe PKIX should continue to promote the notion, through our
>  > standards, that the contents of a certificate represent data that the
>  > issuer has verified and thus stands behind. To do otherwise would
>  > endorse behavior that creates confusion, a generally undesirable
>  > security characteristic.
>
>The later statement is different from the former. I like the former.
>Can we build a consensus around it ?
>
>If so, this should be reflected in the "son-of-RFC2459".

The former is more appropriate for inclusion in the revised RFC;  the 
latter statement was more of a rationale for my position.

Steve



Received: from duck.prod.itd.earthlink.net (duck.prod.itd.earthlink.net [207.217.121.117]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16272 for <[e-mail]>; Tue, 23 May 2000 08:12:05 -0700 (PDT)
Received: from william-lattin (1Cust138.tnt31.sfo3.da.uu.net [63.28.86.138]) by duck.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA21528; Tue, 23 May 2000 08:18:58 -0700 (PDT)
Received: by localhost with Microsoft MAPI; Tue, 23 May 2000 08:19:18 -0700
Message-ID: <[e-mail]>
From: Bill Lattin <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: TSA Response serialNumber Field
Date: Tue, 23 May 2000 08:13:59 -0700
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

I think a better way to address this would be to reset the counter when the 
TSA signature key pair is generated.  This way, we could be more confident 
that a 64-bit counter is sufficient, plus given the real world difficulties 
of guaranteeing a monotonic counter for all time, this gives us a way to 
recover from system failures.  Linkage to the TSA signature key is a 
natural delimiter since the counter would be unique per key and the stated 
objective of the counter - to identify sequential time stamps containing 
the same time - would still be still achieved.

Cheers,

Bill Lattin
TTFN Associates

-----Original Message-----
From:	Peter Gutmann [SMTP:[e-mail]]
Sent:	Thursday, May 18, 2000 8:37 PM
To:	[e-mail]; [e-mail]
Cc:	[e-mail]
Subject:	Re: TSA Response serialNumber Field

[e-mail] writes:

>To accomodate your issue we could add a comment in the ASN1 for the
>serialNumber saying:
>
>-- Time Stamps users must be ready to accomodate integers up to 64 bits.

I think a more general way of putting this would be "...must be ready to
accomodate integers larger than the machine's native word size", which 
warns
of potential problems without implying that there's some magic limit which
they can expect to find.  Actually for anyone who's worked with certs on
any scale, the use of 128-bit and 160-bit "serial numbers" there should be
enough of a warning.

Peter.




Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13277 for <[e-mail]>; Tue, 23 May 2000 05:17:28 -0700 (PDT)
Received: from darxstar ([62.252.196.103]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000523122427.HWBB290.mta03-svc.ntlworld.com@darxstar>; Tue, 23 May 2000 13:24:27 +0100
Message-ID: <000a01bfc4b2$611c2340$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: <[e-mail]>
Cc: "PKIX Mailing List" <[e-mail]>
References: <392A6F2C.28836.775E1F@localhost>
Subject: Re: Multiple questions
Date: Tue, 23 May 2000 13:28:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Serafim,

> Q1.1: I have look for imformation about the OID, where can I find the
repository of OIDs

Try www.alvestrand.no/objectid/top.html

> Q2: An OPTIONAL field can be NULL right?

An optional field could be zero if zero is an appropriate value but you
indicate that an optional field is not used by leaving it out entirely, so
for the structure below you would indicate that there are no extensions by
simply not setting anything at all for the extensions, rather than setting
the field to NULL.

> TimeStampReq ::= SEQUENCE {
> version Integer { v1(1) },
> messageImprint MessageImprint,
> --a hash algorithm OID and the hash value of the data to be
> --time stamped
> reqPolicy PolicyInformation OPTIONAL,
> nonce Integer OPTIONAL,
> certReq BOOLEAN DEFAULT FALSE,
> extensions [0] Extensions OPTIONAL
> }
>
> And in this case the extensions? Why the brackets? ([0]) doesn't the
brackets mean OPTIONAL?

The value 0 in the square brackets is the tag applied to the field.  Recall
that an ASN.1 object is encoded TLV (type, length, value).  In this case, 0
is the type arbitrarily assigned to the Extensions field.  Its meaning is
obtained from its context.  The brackets do not mean that the field is
optional.

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from nemesio.ci.uminho.pt (nemesio.ci.uminho.pt [193.136.16.244]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11555 for <[e-mail]>; Tue, 23 May 2000 03:42:16 -0700 (PDT)
Received: from cripto20 (shannon.di.uminho.pt [193.136.20.84] (may be forged)) by nemesio.ci.uminho.pt (8.8.7/8.8.7) with ESMTP id LAA03340 for <[e-mail]>; Tue, 23 May 2000 11:42:57 +0100
From: "Serafim Gomes" <[e-mail]>
To: [e-mail]
Date: Tue, 23 May 2000 11:44:44 +0100
MIME-Version: 1.0
Content-type: text/enriched; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: TSA: Multiple questions
Reply-to: [e-mail]
Message-ID: <392A6F2C.28836.775E1F@localhost>
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12c)

<color><param>0100,0100,0100</param>Hi,


I'm making a Tsa (client and server), and i have some questions.

Forgive my english, and my questions( if they are "stupid").


Q1: Where can I find information on Policy. Where are the OID of the 
know policy? Can I make some policy, of my own?


Q1.1: I have look for imformation about the OID, where can I find the 
repository of OIDs





Q2: An OPTIONAL field can be NULL right? 


</color><FontFamily><param>courier</param><smaller>TimeStampReq ::= SEQUENCE  {

     version                      Integer  { v1(<color><param>C200,0000,0000</param>1</color>) },

     messageImprint               MessageImprint,

       --a hash algorithm OID and the hash value of the data to be

       --time stamped

     reqPolicy                PolicyInformation      OPTIONAL,

     nonce                    Integer                OPTIONAL,

     certReq                  BOOLEAN                DEFAULT FALSE,

     extensions               [<color><param>C200,0000,0000</param>0</color>] Extensions         OPTIONAL

}


<FontFamily><param>Fixedsys</param><bigger>And in this case the extensions? Why the brackets? ([0]) doesn't the 
brackets mean OPTIONAL?



Q3: How can i test this with, some others servers? does anyone have 
one to test? test iteoperability? 

I have a beta version of a client and sever.





Best Regards,


	Serafim Gomes

	[e-mail]






Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12345 for <[e-mail]>; Mon, 22 May 2000 01:47:16 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA41792; Mon, 22 May 2000 10:53:54 +0200
Message-ID: <[e-mail]>
Date: Mon, 22 May 2000 10:53:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <v04220811b54a0fdf6fcc@[128.33.238.33]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

Let me extract two of your statements:

(snip) 

> >Also, as both Denis and I pointed out,
> >there are wide variations in the meaning of "verify", some of them being
> >arguably very weak. Where does one draw the line between very weak
> >verification and no verification?

> Fair point.  

> I think its important that PKIX continue to express the
> notion that a CA is expected to perform verification (directly or
> indirectly) for all attributes in a cert, leaving to the policy
> and/or CPS to refine the level of verification performed.
  
(snip) 

> Still, I
> do believe PKIX should continue to promote the notion, through our
> standards, that the contents of a certificate represent data that the
> issuer has verified and thus stands behind. To do otherwise would
> endorse behavior that creates confusion, a generally undesirable
> security characteristic.

The later statement is different from the former. I like the former. 
Can we build a consensus around it ?

If so, this should be reflected in the "son-of-RFC2459".

Denis
 
> Steve


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA20173 for <[e-mail]>; Fri, 19 May 2000 14:48:48 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 19 May 2000 15:47:27 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 19 May 2000 15:47:22 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: AW: SubjectAltName verification
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA20174

Not really, Peter -- at least I don't look at it that way.  The certificate class 
is just one of four elements within a field that is used to describe the
"Quality" of the certificate itself, intended to answer the question of 
"why should I believe this certificate?". The other parameters deal with 
where and how the keys were generated, where they are going to be 
used, and where they are stored in the meantime.

The other portion of the Novell Security Attributes extension is a three tiered, 
hierarchical, mandatory access control label that is intended to convey what
 _rights_  the subject of the certificate possesses, at least according to the 
issuer of the certificate.

The result is effectively a multi-dimensional policy statement, if you want
to look at it that way, that permits a very rapid calculation of the equivalent
of the name subordination rules, policy OID constraints, certificate classes, 
and something like the ESS security label supported S/MIME v3.

Take a read -- I think you'll find it interesting.

Bob

>>> "Peter Lipp" <[e-mail]> 05/19/00 10:55AM >>>

> That's why we include an explicit encoding of a certificate class
> (from 0 to 255, with a rather rich set of definitions) in the
> Novell Security Attributes in all of the certificate we create.

Honestly, isn't that a shortcut for a possible policy-Id like
Novell.sercurtityAttributes.policies.0 -
Novell.sercurtityAttributes.policies.255?

Peter





Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17067 for <[e-mail]>; Fri, 19 May 2000 11:53:10 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <KLC3N329>; Fri, 19 May 2000 15:00:41 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Rationale for Nonce in Time Stamp Protocol
Date: Fri, 19 May 2000 15:00:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Salut Denis,

I do not remember if this issue was raised before, but in Section 2.2 the
following statement is made:

"the requesting entity .... SHALL then verify the timeliness of the response
by verifying either the time included in the response against a local
trusted time reference, if one is available, and/or the value of the nonce
(large random number with a high probability that it is generated by the
client only once) included in the response against the value included in the
request."
 
A nonce is normally used to detect attempts at replays, which is not
necessarily related to the timeliness of the response to a particular
request as mentioned here.
 
The first part of the statement talks about verifying the time included in
the response against a locally trusted time source.  This could used to
measure round trip path delay for calibration purposes, but unless one could
be certain that the locally trusted source is as accurate as the TSA time
source (or, at least, that the difference between them is fixed and
well-known), I don't see how it would detect/prevent replays.  If one has
such a trusted time source locally, what is the point in using a TTP for
time stamping?
 
Could you please clarify the intent of this statement and if the intent is
to prevent replays or check the timeliness of responses or both?

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]



Received: from iaik.tu-graz.ac.at ([129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14207 for <[e-mail]>; Fri, 19 May 2000 09:48:24 -0700 (PDT)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A1D61B7010C; Fri, 19 May 2000 18:54:46 +0200
Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Fr, 19 Mai 2000 18:55:31 +0100
From: "Peter Lipp" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
Subject: AW: SubjectAltName verification
Date: Fri, 19 May 2000 18:55:30 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.92F749A7--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.92F749A7--
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


> That's why we include an explicit encoding of a certificate class
> (from 0 to 255, with a rather rich set of definitions) in the
> Novell Security Attributes in all of the certificate we create.

Honestly, isn't that a shortcut for a possible policy-Id like
Novell.sercurtityAttributes.policies.0 -
Novell.sercurtityAttributes.policies.255?

Peter



----IAIK.SMIME.MAPPER.92F749A7--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy
ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV
BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ
xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk
PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX
yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w
LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR
BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh
dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw
QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC
2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq
FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr
oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9
ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi
KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy
2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB
VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X
DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP
MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk
Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H
WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv
Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO
RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg
ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI
AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk
SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q
SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT
FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL
CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE
6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n
vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx
2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7
rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t
sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu
dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8
lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx
CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P
TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g
UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U
UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG
A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ
MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j
ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F
VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk
fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x
LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R
X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV
Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB
AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE
tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3
DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s
hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI
7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af
EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s
PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ
xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG
BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD
VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H
UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg
Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh
dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg
VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew
HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG
9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX
ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6
Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25
sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu
YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB
hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA
MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF
Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD
ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9
l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q
19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6
ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M
HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG
BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV
BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1
OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT
BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog
VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig
QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u
czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H
UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a
SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy
qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg
o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B
2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1
2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj
MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE
AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP
hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C
uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64
vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL
CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq
E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw
ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME
R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS
QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wMDA1MTkxNjU1MzFaMCMGCSqGSIb3DQEJBDEWBBQplkUW3FAAO9xJ
14Hs9L91XDFMhjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN
BgkqhkiG9w0BAQEFAASBgBr0+I9BeFcaqjBDfCIG77kCZVtgO343k8JH4ILh2AZp
erU45mZEpw9Vfi5s4j5SInvJ/71ZOcGCZUP6DiFMEgjF1aLVzdOtKahPpzT1e4KR
c08qqBwVPqMgfeYTjchrMEkouPS1n48//sGGpDanYZOYblsb8Tp0tCW0MmJj6OcP
AAAAAAAA
----IAIK.SMIME.MAPPER.92F749A7----



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01751 for <[e-mail]>; Fri, 19 May 2000 03:45:11 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02521; Fri, 19 May 2000 06:51:55 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-03.txt
Date: Fri, 19 May 2000 06:51:54 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-03.txt
	Pages		: 20
	Date		: 18-May-00
	
This document describes two methods for producing an integrity check
value from a Diffie-Hellman key pair.  This behavior is needed for
such operations as creating the signature of a PKCS #10
certification request.  These algorithms are designed to provide a
proof-of-possession rather than general purpose signing.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA05866 for <[e-mail]>; Thu, 18 May 2000 21:54:00 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 18 May 2000 23:00:10 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 18 May 2000 22:52:41 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SubjectAltName verification
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA05867

I don't believe so, Warwick, because of the difficulties inherent in referring to a CP and CPS in a non-machine readable fashion when trying to evaluate the credibility of a certificate.

That's why we include an explicit encoding of a certificate class (from 0 to 255, with a rather rich set of definitions) in the Novell Security Attributes in all of the certificate we create.

Cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm. 

Bob

>>> Warwick Ford <[e-mail]> 05/18/00 07:54AM >>>
Denis:

It seems to me that classes constitute the classic example of different
certificate policies.  Don't we have all the mechanism we need?

Warwick



Received: from fhufw.fhu.disa.mil (fhu2.fhu.disa.mil [207.132.160.62]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA00785 for <[e-mail]>; Thu, 18 May 2000 15:08:38 -0700 (PDT)
Received: from fhu2.fhu.disa.mil by fhufw.fhu.disa.mil via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 May 2000 19:16:09 UT
Received: by fhu2.fhu.disa.mil with Internet Mail Service (5.5.2650.10) id <K8QQAL2P>; Thu, 18 May 2000 15:15:18 -0700
Message-ID: <[e-mail]>
From: "Nelson, Patt" <[e-mail]>
To: [e-mail]
Subject: remove
Date: Thu, 18 May 2000 15:15:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0031_01BFC0DB.DC26E2D0"; protocol="application/x-pkcs7-signature"; micalg=SHA-1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01BFC0DB.DC26E2D0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002A_01BFC0DB.DC23D590"


------=_NextPart_000_002A_01BFC0DB.DC23D590
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

please remove soonest

------=_NextPart_000_002A_01BFC0DB.DC23D590
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2163.0">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">please remove soonest</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_002A_01BFC0DB.DC23D590--

------=_NextPart_000_0031_01BFC0DB.DC26E2D0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHljCCA58w
ggMIoAMCAQICAi/QMA0GCSqGSIb3DQEBBQUAMFwxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu
IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRcwFQYDVQQDEw5NZWQgRW1h
aWwgQ0EtMTAeFw0wMDAzMzEyMDM3MDVaFw0wMjA0MDEyMDM3MDVaMIGjMQswCQYDVQQGEwJVUzEY
MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTETMBEG
A1UECxMKQ09OVFJBQ1RPUjEkMCIGA1UEAxMbTkVMU09OLlBBVFJJQ0suRC4wNTA2MDA2MjIzMSMw
IQYJKoZIhvcNAQkBFhROZWxzb25QQGZodS5kaXNhLm1pbDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAmaUtIEs7IWmQsy/2ygsCT8xlgj2tuAPQLSW2CH/O7A5exRj0Fl/YedxnduLRFfm/zCiA
v5caS+vwj83eeNtHcd5GEyWEkusl3ScIYbu8cQVOBTWhEPvLErsAArwDtCzeG01iGTdG598AHBZf
UeVqicRzoVDUFLTSP32LPyh8ChkCAwEAAaOCASYwggEiMBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsD
MB8GA1UdIwQYMBaAFPIju1ImGhS6CXJ9cNJe5ng8aBX8MB0GA1UdDgQWBBQdqvBvCxRMqcqNAAxd
lAVWF9G0pzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADCBqQYDVR0fBIGhMIGeMIGboIGY
oIGVhoGSbGRhcDovL2RzLTEuY2hhbWIuZGlzYS5taWw6MzkwL2NuJTNkTWVkJTIwRW1haWwlMjBD
QSUyZDElMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUz
ZFVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3QlM2JiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEA
m43ImFg6CGg2n4cWF6v6lEYIwLv3nMRfb+/UghoLHncUW+uaIQBumYEvufoDtvoQ4FS8kc20Wq5p
s6Y26jiBEykDXnZxn/s/UWAYiGyhVCVE9Qw01Imp7RnJ+IN4BWPkO9xl58BN4tGY4GKsFAk0nIBL
5eUEbnu5YxrEmOJCcY4wggPvMIIDWKADAgECAgEjMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYT
AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ
MRwwGgYDVQQDExNEb0QgUEtJIE1lZCBSb290IENBMB4XDTk4MDgwNjE5NTQ1NFoXDTAzMDgwNjE5
NTQ1NFowXDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMD
RG9EMQwwCgYDVQQLEwNQS0kxFzAVBgNVBAMTDk1lZCBFbWFpbCBDQS0xMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCqTd9bbYLOvC2mMX/fpiD+4MKcPiO7bCNi+6w6jGXsyVzEysRDUkOhOR77
XJyU6PD/gRV1BgQC+tqLyVKku0u13m8hxAGLP4EXk5S2Egl6AzueBlVPQcFIpSAoeK3Q69pyE/9W
FGCf2VDWM/57IFcHmaBzUM7aWyybNw+VHo+1JwIDAQABo4IBujCCAbYwFgYDVR0gBA8wDTALBglg
hkgBZQIBCwMwHwYDVR0jBBgwFoAUxVnSzvGYlVBmqG3eMkvWYTXiRrMwDAYDVR0kBAUwA4ABADAd
BgNVHQ4EFgQU8iO7UiYaFLoJcn1w0l7meDxoFfwwDgYDVR0PAQH/BAQDAgGGMH4GA1UdEgR3MHWG
c2xkYXA6Ly9kcy0xLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwUEtJJTIwTWVkJTIwUm9vdCUy
MENBJTJjb3UlM2RQS0klMiBjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNk
VVMwDwYDVR0TAQH/BAUwAwEB/zCBrAYDVR0fBIGkMIGhMIGeoIGboIGYhoGVbGRhcDovL2RzLTEu
Y2hhbWIuZGlzYS5taWwvY24lM2REb0QlMjBQS0klMjBNZWQlMjBSb290JTIwQ0ElMmNvdSUzZFBL
SSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmljYXRl
UmV2b2NhdGlvbkxpc3QlM2JiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEAlQOnyvY3wBzBFqvQmaAJ
qUUpucy55ErAncWtLBJcNP3Q56vAk4/O4gf/0KUe+x8DovQAe5KIn3JMQUoxc98SxV2xj+/tPvUg
xPV9d59Nl2lJEGq7eufOnhwE7NNFEDJNub6V2EIpH3VMmDsPqvFJzmqTTzxzrZISXr3vJR7SdFcx
ggInMIICIwIBATBiMFwxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAK
BgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRcwFQYDVQQDEw5NZWQgRW1haWwgQ0EtMQICL9AwCQYF
Kw4DAhoFAKCCARswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAw
NTE4MjIxNTExWjAjBgkqhkiG9w0BCQQxFgQUBctkpXSKcwZb8JTjb4b3g+s+wrowSQYJKoZIhvcN
AQkPMTwwOjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwBwYFKw4DAhowCgYI
KoZIhvcNAgUwcQYJKwYBBAGCNxAEMWQwYjBcMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBH
b3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEXMBUGA1UEAxMOTWVkIEVtYWls
IENBLTECAi/QMA0GCSqGSIb3DQEBAQUABIGAio2pS7oWYATjPsV99/uN0KnQjHw6QdNVgvXbGjAk
Z9doJijhtDnb78cvL+AxkVDQYvv9tdGm27nyNubwjZCwzMRtqhB/28rXVHAEUYRTOMUKv514hBmP
F/Lg74o4f2eSPv6tyRA/ca7V4oWkvV/FFu5dYQocmoys6DdU+YdDtuoAAAAAAAA=

------=_NextPart_000_0031_01BFC0DB.DC26E2D0--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00385 for <[e-mail]>; Thu, 18 May 2000 14:57:21 -0700 (PDT)
Received: from [128.33.238.33] (TC057.BBN.COM [128.33.238.57]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA17141; Thu, 18 May 2000 18:03:16 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220811b54a0fdf6fcc@[128.33.238.33]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Thu, 18 May 2000 17:57:21 -0400
To: Warwick Ford <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Warwick,

>A common example of a nonverified name, as mentioned by Denis, is an alias
>which is deliberately not verified, sometimes because of privacy or
>annonymity requirements.

I presume you mean pseudonym here, a rare case, but even here I think 
there is a consistent interpretation of my argument. Specifically, a 
pseudonym, appearing as a subject name or subject alt name must 
clearly be identified as such, else the CA is misrepresenting the 
information in these fields. One might reasonably require that such 
names be drawn from a name space that precludes easy confusion with 
"real" names.  I recall that we did just that in RFC 1422.

>There are also examples where a part of a name is
>not verified at all. For example, when issuing a certificate to an
>organizational system (server, even intermediate CA) it is not uncommon for
>the CA to verify the organization name, but allow any name the organization
>cares to ask for in the OU fields.

An organization is authoritative for its internal naming, so it is 
fine for a CA to rely on an authorized rep for the organization to 
declare an OU in such cases. I'd say that the CA is doing its job by 
relying on an authorized RA in this case.

>Also, as both Denis and I pointed out,
>there are wide variations in the meaning of "verify", some of them being
>arguably very weak. Where does one draw the line between very weak
>verification and no verification?

Fair point.  I think its important that PKIX continue to express the 
notion that a CA is expected to perform verification (directly or 
indirectly) for all attributes in a cert, leaving to the policy 
and/or CPS to refine the level of verification performed.  As another 
WG member noted, it would seem that a major rationale for violating 
this rule is a desire to put too much into a single certificate.

The bigger security issue here is that we create new opportunities 
for vulnerabilities whenever we represent information that is not 
vouched for in a context where RPs ought to be able to rely on the 
accuracy of the information.  Anything one does that leads to easy 
confusion on the part of a user or system administrator is a 
contribution to the security failures that will inevitably result.

>I respectfully propose that, as in the past, we leave such issues as a
>matter of policy, and expressly exclude judgements on them from the PKIX
>standards.  I certainly do not believe that PKIX should be in the business
>of "censuring" CAs over their policies.

It is a pity that PKIX cannot effectively censure CAs :-).  Still, I 
do believe PKIX should continue to promote the notion, through our 
standards, that the contents of a certificate represent data that the 
issuer has verified and thus stands behind. To do otherwise would 
endorse behavior that creates confusion, a generally undesirable 
security characteristic.

Steve



Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24638 for <[e-mail]>; Thu, 18 May 2000 11:17:42 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e4IIOIj21589 for <[e-mail]>; Thu, 18 May 2000 11:24:18 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 11:53:15 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <v04220801b549227ae10c@[128.33.238.84]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> 
> Maybe it is now the right time to raise the question whether we
> should standardize the concept of classes of certificates.
> 

This whole issue of different levels of verification for the values in a
certificate stems from the misguided idea that a single certificate needs to
contain everything about a subject.  This is misguided because it expands the
scope of the CA's responsibility beyond reasonable limits.

For example, it seems to me that a domain name registrar, not a CA, is
authoritative about who owns a domain.  Similarly for email addresses, IP
addresses, and pretty much all of the other altName forms.

CAs should be authoritative for only one thing: linking a public key value to
a name.  This provides a level of indirection that allows other authorities
to attach attributes to that name.  In other words, the public-key
certificate allows relying parties to identify the owner of a name, and
attribute certs (or other attribution protocols) allow relying parties to
discern facts about the owner of that name.

Clearly separating the scope of responsibility has numerous benefits.  Each
authority's legal liabilities are vastly reduced, as each is solely
responsible for its own domain.  Attribute and key management is also greatly
simplified, as compared to using more "monolithic" certs where a cert must be
revoked and re-issued if any of its attributes changes.

Trying to define standardized classes of levels of validation is frankly a
bit naive, since no two CAs will ever operate in the same way.  It also
perpetuates the misguided notion of a single authority for several
attributes.

This notion must be abandoned if PKI is ever to reach the wide-scale
deployment we're all hoping for.  Few organizations want to take
responsibility for all the attributes in current certificate profiles. 
Giving them a way to state which bits they really take responsibility for is
just complicating the whole thing, rather than solving the problem.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+


Received: from eup2intra.euskaltel.es (mail.euskaltel.es [212.55.0.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22924 for <[e-mail]>; Thu, 18 May 2000 09:58:02 -0700 (PDT)
Received: from euskaltel.es ([212.8.127.1]) by eup2intra.euskaltel.es (Netscape Messaging Server 4.15) with ESMTP id FURM2C00.A04; Thu, 18 May 2000 19:03:48 +0200 
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 19:05:13 +0200
From: =?iso-8859-1?Q?Bego=F1a?= Canas <[e-mail]>
Organization: EUSKALTEL
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], ietf-pkix <[e-mail]>, "'Thierry Van Doninck'" <[e-mail]>
Subject: Re: Does Smime works fine with Windows 2000 PKI
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------7695007A7B1C7CFEB42E8C6C"

--------------7695007A7B1C7CFEB42E8C6C
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello,

Can anyone give me the address to subscribe to certalk list? Because this is to technical for me, I'm more interested on a list about certs, pki, ca, ... but not so
technical.

Thank you

[e-mail] wrote:

> Peter,
>
> Although I agree that such questions might better be addressed to the
> certalk list, I also agree with you that we should occasionally take the
> pulse of the industry and see who has actually rolled out commercial-grade
> products that implement that various standards.
>
> And I thank you for including the link to one of Novell's web pages, which I was
> not aware of.  I have contacted the document owner to have it updated.
>
> For the record, Novell's GroupWise 5.5 Enhancement Pack e-mail product
> supports S/MIME using EITHER the Entrust PKI solution, OR a more conventional
> PKI solution that is based on the CSP capabilities provided by MS-CAPI and Internet
> Explorer.
>
> The current version supports S/MIME version 2, and most of version 3.  Release
> schedules together with the uncertain state of CRL support by various CAs back
> in mid-1999 led us to delay the availability of CRL processing in GroupWise.
> This capability is currently scheduled for later this year.
>
> Likewise, although support for S/MIME v3's separation between encryption keys
> and digital signature keys was part of the original development, we chose not to
> feature ro recommend that usage at this time, due to the fact that Outlook Express
> seriously mishandles such dual keys, and frequently ends up sending
> an encrypted reply to the sender, using the sender's signature key.
>
> Entrust chose to try to undo that kind of mess by obligingly decrypting the message
> using the signature key, but we felt that such an approach would seriously distort
> the intent of the key usage policy, including controls over how the keys were
> generated, how they were archived, etc.  We expect to fully support dual key usage
> later this year, and we hope by that time the Outlook Express bug will have been fixed.
>
> To the best of our knowledge, GroupWise can be used to request certificates from
> any commercial CA, and our interoperability tests did not disclose any particular
> difficulties with a rather wide variety of X.509 v3 certificates.
>
> GroupWise can also consume certificates issued in bulk from Novell's own free
> Novell Certificate Server product 2.0, of course, and those certificates can also
> be used by IE for SSL mutual authentication.
>
> Sometimes it seems like it takes forever, but we have in fact come a long, long way
> from the PEM days.
>
> Regards,
>
> Bob
>
> >>> Peter Williams <[e-mail]> 05/15/00 04:46PM >>>
> http://support.microsoft.com/support/exchange/content/whitepapers/win2k_kms.
> doc
>
> Thierry,
>
> I disagree with Phil. I personally measure the state
> of open-ness of the actual PKIX industry in the US by the work
> that Microsoft does in X.509. Determining open standards adoption
> and interoperability over time is an important element of
> standards making and national infrastructure(s) planning, in my
> perhaps simplistic view.
>
> http://www.microsoft.com/Exchange/55/gen/compare.htm
> is a (Microsoft-marketing) comparison of Exchange
> and PKI with competitive products that include PKI. The
> link give a glimpse of reality of PKIX in average
> enterprise mail products.
>
> Some other URLs discussing important aspects
> of S/MIME integration into commercial-grade
> internet environments:
>
> Beyond S/MIME and onto X.400 secure stacks/networks:
> http://www.microsoft.com/exchange/55/gen/Security.htm
>
> A Lotus study of PKI and S/MIME deployment - for Identrus banks:
> http://www.lotus.com/99/session.nsf/187801dd8d07636a8525677d005a4ac8/78888aa
> 0af9ec29b8525684e0079a8d3
>
> A Study of Novell's integration with the world-class Entrust solution.
>
> http://support.novell.com/cgi-bin/search/search.pl?database_name=kb&type=HTML&docid=%03%1fF170985%3a958429713%3a%20%28%20S%2fMIME%20%29%20%20%07%01%00&byte_count=4399
>
> If you add Netscape Certificate Server and RSA Keon/VeriSign to
> the analysis, we have moved quite a long way in the US from the
> PEM days.
>
> Peter.
>
> -----Original Message-----
> From: Philip Hallam-Baker [mailto:[e-mail]]
> Sent: Monday, May 15, 2000 6:05 AM
> To: 'Thierry Van Doninck'; ietf-pkix
> Subject: RE: Does Smime works fine with Windows 2000 PKI
>
> Same answer, ask Microsoft, not an IETF development list.
>
> -----Original Message-----
> From: Thierry Van Doninck [mailto:[e-mail]]
> Sent: Thursday, May 11, 2000 7:40 AM
> To: ietf-pkix
> Subject: Does Smime works fine with Windows 2000 PKI
>
> Hi,
>
> Same message as on the smime mailing list.
> Has any of you good people any info on Windows 2000 PKI ?
>
> Thanks,
>
> Thierry
>
> ========================================================================
> ============
>
> Hi everybody,
>
> Just a question :
>
> Is there any known issues using S/MIME with Win2000PKI-certificates ?
> More generally, are Win2000 certificates usable with (and understood by
> ) the others mailers (especially Lotus Notes, Netscape, Eudora
> +plug-in?)
>
> Isn't Baltimore Unicert a "better choice" due to its greater
> compatibility ?
>
> Any advices are welcome.
>
> Regards,
>
> Laurent Deffranne

--
----------------------------------------
Begoña Canas
Sistemas Internet
Euskaltel
Tfno: 94 4011465
e-mail: [e-mail]
----------------------------------------


--------------7695007A7B1C7CFEB42E8C6C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello,
<p>Can anyone give me the address to subscribe to certalk list? Because
this is to technical for me, I'm more interested on a list about certs,
pki, ca, ... but not so technical.
<p>Thank you
<p>[e-mail] wrote:
<blockquote TYPE=CITE>Peter,
<p>Although I agree that such questions might better be addressed to the
<br>certalk list, I also agree with you that we should occasionally take
the
<br>pulse of the industry and see who has actually rolled out commercial-grade
<br>products that implement that various standards.
<p>And I thank you for including the link to one of Novell's web pages,
which I was
<br>not aware of.&nbsp; I have contacted the document owner to have it
updated.
<p>For the record, Novell's GroupWise 5.5 Enhancement Pack e-mail product
<br>supports S/MIME using EITHER the Entrust PKI solution, OR a more conventional
<br>PKI solution that is based on the CSP capabilities provided by MS-CAPI
and Internet
<br>Explorer.
<p>The current version supports S/MIME version 2, and most of version 3.&nbsp;
Release
<br>schedules together with the uncertain state of CRL support by various
CAs back
<br>in mid-1999 led us to delay the availability of CRL processing in GroupWise.
<br>This capability is currently scheduled for later this year.
<p>Likewise, although support for S/MIME v3's separation between encryption
keys
<br>and digital signature keys was part of the original development, we
chose not to
<br>feature ro recommend that usage at this time, due to the fact that
Outlook Express
<br>seriously mishandles such dual keys, and frequently ends up sending
<br>an encrypted reply to the sender, using the sender's signature key.
<p>Entrust chose to try to undo that kind of mess by obligingly decrypting
the message
<br>using the signature key, but we felt that such an approach would seriously
distort
<br>the intent of the key usage policy, including controls over how the
keys were
<br>generated, how they were archived, etc.&nbsp; We expect to fully support
dual key usage
<br>later this year, and we hope by that time the Outlook Express bug will
have been fixed.
<p>To the best of our knowledge, GroupWise can be used to request certificates
from
<br>any commercial CA, and our interoperability tests did not disclose
any particular
<br>difficulties with a rather wide variety of X.509 v3 certificates.
<p>GroupWise can also consume certificates issued in bulk from Novell's
own free
<br>Novell Certificate Server product 2.0, of course, and those certificates
can also
<br>be used by IE for SSL mutual authentication.
<p>Sometimes it seems like it takes forever, but we have in fact come a
long, long way
<br>from the PEM days.
<p>Regards,
<p>Bob
<p>>>> Peter Williams &lt;[e-mail]> 05/15/00 04:46PM >>>
<br><a href="http://support.microsoft.com/support/exchange/content/whitepapers/win2k_kms">http://support.microsoft.com/support/exchange/content/whitepapers/win2k_kms</a>.
<br>doc
<p>Thierry,
<p>I disagree with Phil. I personally measure the state
<br>of open-ness of the actual PKIX industry in the US by the work
<br>that Microsoft does in X.509. Determining open standards adoption
<br>and interoperability over time is an important element of
<br>standards making and national infrastructure(s) planning, in my
<br>perhaps simplistic view.
<p><a href="http://www.microsoft.com/Exchange/55/gen/compare.htm">http://www.microsoft.com/Exchange/55/gen/compare.htm</a>
<br>is a (Microsoft-marketing) comparison of Exchange
<br>and PKI with competitive products that include PKI. The
<br>link give a glimpse of reality of PKIX in average
<br>enterprise mail products.
<p>Some other URLs discussing important aspects
<br>of S/MIME integration into commercial-grade
<br>internet environments:
<p>Beyond S/MIME and onto X.400 secure stacks/networks:
<br><a href="http://www.microsoft.com/exchange/55/gen/Security.htm">http://www.microsoft.com/exchange/55/gen/Security.htm</a>
<p>A Lotus study of PKI and S/MIME deployment - for Identrus banks:
<br><a href="http://www.lotus.com/99/session.nsf/187801dd8d07636a8525677d005a4ac8/78888aa">http://www.lotus.com/99/session.nsf/187801dd8d07636a8525677d005a4ac8/78888aa</a>
<br>0af9ec29b8525684e0079a8d3
<p>A Study of Novell's integration with the world-class Entrust solution.
<p><a href="http://support.novell.com/cgi-bin/search/search.pl?database_name=kb&type=HTML&docid=%03%1fF170985%3a958429713%3a%20%28%20S%2fMIME%20%29%20%20%07%01%00&byte_count=4399">http://support.novell.com/cgi-bin/search/search.pl?database_name=kb&amp;type=HTML&amp;docid=%03%1fF170985%3a958429713%3a%20%28%20S%2fMIME%20%29%20%20%07%01%00&amp;byte_count=4399</a>
<p>If you add Netscape Certificate Server and RSA Keon/VeriSign to
<br>the analysis, we have moved quite a long way in the US from the
<br>PEM days.
<p>Peter.
<p>-----Original Message-----
<br>From: Philip Hallam-Baker [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]
<br>Sent: Monday, May 15, 2000 6:05 AM
<br>To: 'Thierry Van Doninck'; ietf-pkix
<br>Subject: RE: Does Smime works fine with Windows 2000 PKI
<p>Same answer, ask Microsoft, not an IETF development list.
<p>-----Original Message-----
<br>From: Thierry Van Doninck [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]
<br>Sent: Thursday, May 11, 2000 7:40 AM
<br>To: ietf-pkix
<br>Subject: Does Smime works fine with Windows 2000 PKI
<p>Hi,
<p>Same message as on the smime mailing list.
<br>Has any of you good people any info on Windows 2000 PKI ?
<p>Thanks,
<p>Thierry
<p>========================================================================
<br>============
<p>Hi everybody,
<p>Just a question :
<p>Is there any known issues using S/MIME with Win2000PKI-certificates
?
<br>More generally, are Win2000 certificates usable with (and understood
by
<br>) the others mailers (especially Lotus Notes, Netscape, Eudora
<br>+plug-in?)
<p>Isn't Baltimore Unicert a "better choice" due to its greater
<br>compatibility ?
<p>Any advices are welcome.
<p>Regards,
<p>Laurent Deffranne</blockquote>

<p>--
<br>----------------------------------------
<br>Bego&ntilde;a Canas
<br>Sistemas Internet
<br>Euskaltel
<br>Tfno: 94 4011465
<br>e-mail: [e-mail]
<br>----------------------------------------
<br>&nbsp;</html>

--------------7695007A7B1C7CFEB42E8C6C--



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21645 for <[e-mail]>; Thu, 18 May 2000 09:01:38 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA27159 for <[e-mail]>; Thu, 18 May 2000 12:03:24 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 18 May 2000 12:02:52 -0400
From: Mike Jenkins <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Standardization of certificate classes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Standardizing levels-of-assurance for broad-based certificate
application (i.e., in the Internet-wide context) gives me the
heebie-jeebies. My mantra wrt CPs and CPSs (as editor of the US DOD CP)
has always been that a CP is a statement of the minimum requirements of
the certificate-using community; a CPS is a statement of what a
certificate-issuer (CA, RA, LRA, etc.)  actually does. Some certificate
vendors publish CP/CPSs; in this case, the vendor is suggesting to what
uses you might want to put the certificate, which might be useful to the
masses who don't have a system accreditor to tell them. Standardization
within industries is inevitable; it is just as inevitable that these
standards will be wildly different from industry to industry.

In my model, if the certificate-using community wants all certificate
contents to be checked, it should say so in its CP. Any CA who checks in
the desired manner (other reqts notwithstanding) fits the bill. Note
that this does not require exposure of the CA's CPS (which some CAs seem
to want), since the relying party can find what it wants to know in the
CP (to the extent that any relying party will read anything, an issue
that has been discussed before, etc.)

I really doubt that this is a PKIX issue.

Mike Jenkins



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21364 for <[e-mail]>; Thu, 18 May 2000 08:54:30 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA27352; Thu, 18 May 2000 18:00:58 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 18:00:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <v04220801b549227ae10c@[128.33.238.84]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul,

I like your proposal in general.  ... However, I would reword it a
litlle bit differently, changing "whether" by "how" in two places. 
The other concern I have is that your proposed text mentions "THE
CPS". This is assuming ONE CP, which is the RECOMMENDATION we
presently have in RFC 2459. I raised the question whether we should
relax this a little bit, to be able to include some "well known"
OIDs which would state how the verification of the registration
information has been performed.

See below:

> >>>>> "Stephen" == Stephen Kent <[e-mail]> writes:
> 
>  Stephen> Warwick,
>  >> The meaning of "verify" (in this context) is entirely a matter of
>  >> policy, and needs to be made clear in the CP/CPS wrt all fields of
>  >> material significance.  Re our long-ago discussion on
>  >> "non-verified subscriber information", I recall us agreeing that a
>  >> certificate *may* (subject to policy) contain non-verified
>  >> subscriber information.  However, because "verification" means
>  >> different things for different fields, a binary flag was not the
>  >> answer.  The extent to which different fields are verified (or
>  >> not) by a CA is expressed in the CP/CPS.
>  >>
>  >> I believe this interpretation extends to subjectAltName since
>  >> different alternatives will unquestionably be "verified" in
>  >> different ways.
> 
>  Stephen> We disagree wrt inclusion of non-verified info, and the
>  Stephen> consensus of the WG in this regard.  I agree that a CA
>  Stephen> policy may declare that a CA has chosen to do this, but I
>  Stephen> believe that such behavior warrants censure.
> 
> I'm inclined to agree.
> 
> If Warwick's interpretation is to be adopted, then the text urgently
> needs to be repaired so it does not mislead.  The current text (i.e.,
> its intuitive meaning in plain English) supports Steve's
> interpretation and not Warwick's.  If the other interpretation is
> intended, then the text needs to say so quite explicitly.  For
> example, with words like this:
> 
>  "Whether the subjectAltName or any other field of the certificate has
>  been verified by the CA is a matter of policy and can be ascertained
>  only by examination of the CPS.  If a RP needs to know that a
>  particular attribute is definitively bound to the public key of the
>  subject, it must examine the CPS to learn whether the CA has indeed
>  verified this binding."

 "How the subjectAltName or any other field of the certificate has
 been verified by the CA is a matter of policy and can be
ascertained
 only by the knowledge of the CP(s) or by examination of the
CPS(s).  
 If a RP needs to know how a particular attribute is bound to the 
 public key of the subject, it must now have the knowledge of the 
 CP(s) or examine the CPS(s) to learn how the CA has indeed verified
 this binding."

Denis


> It would be possible to take a middle ground between the two
> positions, i.e., encouraging the definitive binding but not requiring
> it.  That of course means changing the "MUST" to a "SHOULD" and
> perhaps adding words to the effect that the CPS must indicate what is
> done.
> 
> Personally, I prefer Steve's position.  I wonder if it is necessary to
> add words to the effect that a conforming CA cannot use the CPS to get
> out of supporting mandatory items in the RFC and still be considered
> conforming.  After all, that's we're talking about right now.  It
> really shouldn't be, after all that's why we use standardized
> terminology (like "MUST").
> 
>              paul


Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20670 for <[e-mail]>; Thu, 18 May 2000 08:30:45 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA09643; Fri, 19 May 2000 03:37:07 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95866422706718>; Fri, 19 May 2000 03:37:07 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSA Response serialNumber Field
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 19 May 2000 03:37:07 (NZST)
Message-ID: <[e-mail]>

[e-mail] writes:

>To accomodate your issue we could add a comment in the ASN1 for the
>serialNumber saying:
>
>-- Time Stamps users must be ready to accomodate integers up to 64 bits.

I think a more general way of putting this would be "...must be ready to
accomodate integers larger than the machine's native word size", which warns
of potential problems without implying that there's some magic limit which
they can expect to find.  Actually for anyone who's worked with certs on
any scale, the use of 128-bit and 160-bit "serial numbers" there should be
enough of a warning.

Peter.



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18182 for <[e-mail]>; Thu, 18 May 2000 07:16:05 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA13500; Thu, 18 May 2000 16:21:14 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 16:21:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Warwick Ford <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Warwick,

Certificate policies may certainly contain information that relates
to the quality of checking of the various fields of the certificate.
However, using a single CP in the CP field (as this is RECOMMENDED
by RFC 2459) does not easily allow to compare the quality of the
checking performed by two different CAS. If we (or someone else)
were defining an OID, e.g. for "Class 32", that would come in
addition to another OID specific to the CA, this would be better.

So we might need a small text change to solve the case.

Denis

Extract from RFC 2459:

   To promote interoperability, this profile RECOMMENDS that policy
   information terms consist of only an OID.  Where an OID alone is
   insufficient, this profile strongly recommends that use of
qualifiers
   be limited to those identified in this section.
 
> Denis:
> 
> It seems to me that classes constitute the classic example of different
> certificate policies.  Don't we have all the mechanism we need?
> 
> Warwick


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17942 for <[e-mail]>; Thu, 18 May 2000 07:12:25 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA17651; Thu, 18 May 2000 16:19:03 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 18 May 2000 16:19:03 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA14490; Thu, 18 May 2000 16:19:02 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA00894; Thu, 18 May 2000 16:19:01 +0200 (MET DST)
Date: Thu, 18 May 2000 16:19:01 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: SubjectAltName verification
Cc: [e-mail]

> > > A certificate must contain a name that may be carried in the DN
> > > field or the SubjectAltName extension. That name must be unique and
> > > is assigned by the CA. The name, wherever it is placed, must be
> > > verified (well with the exception of pseudonyms that can only be
> > > verified not to collide) with some *reasonable* degree of
> > > verification.
> > >
> > 'Unique' does seem the right word to me. You can have more than one
> > 'name' for the same object, like a pseudonym and a 'real' name.
> > 
> > Are you talking about 'non-ambigous names'?
> 
> No. Unique means that a name, once given to one entity, must not be
> given to a different entity (in short not issued twice to two
> different entities).

Hm, that's unique (= the only one/sole cf Webster's dict) attribution
of a name to an object. Which makes the name unambiguous. 

X.501 (88) 8.1 d:

  (directory) name: a construct that singles out a particular object from
  all other objects. A name must be unambiguous (that is denote just one object),
  however it need not be unique (that is, be the only name which unambigously
  denotes the object);

This definition seems to be conformant the definition 1 found in Webster's dictionary
unique = the only one 'sole'. 

But rfc1439: 

   This RFC provides information that may be useful when selecting a
   method to use for assigning unique identifiers to people.

But in fact this RFC talks about the uniqueness of the assignment of
an identifier to an entity. Or, 'unique identifier' is used as a new term
but not using 'unique' as an attribute of the identifier. 

The sentence:
   'In general, these identifiers must be unique.' 

is not consistent with the rest of the text, explaining that the
attribution of an identifier to an object must be unique/sole, which is
a quality of the inverse relation.

Or, uniqueness is the opposite of unambiguous, it just
depends from which part of the relation you see it. 

Combining this all, you can still consider a term 'unique name' as a term that
describes what you say, but then you cannot necessarily say that a
'unique name' is 'unique' since the object may have several names; a very
unfortunate wording problem. 

Thus, the reason I mentioned that was not to comment the statement about the
subject of the message, rather a comment to the paragraph in 2.4 the qualified
certificate draft. 

In the context of a single DIT *the distinguished names* form a subset
of name, where each name is unique (since you can only have one distinguished
name for an object.); it is unambiguous because it is a name (X.501) and not
because it is a distinguished name. 

Or, maybe one should rename 2.4 to 'uniqueness of name assignments'. 

   In the context of qualified certificates, a distinguished name
   denotes a set of attribute values [X.501] which forms a name that is
   unambiguous within a certain domain 

Well, sorry for any misunderstanding that my comments may or may not have caused.

Peter
PS: My English has always been *very* bad, anyway.


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17554 for <[e-mail]>; Thu, 18 May 2000 07:02:26 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQipsi25566; Thu, 18 May 2000 14:09:04 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04698; Thu, 18 May 00 10:05:39 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA24758; Thu, 18 May 2000 10:09:03 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 18 May 2000 10:09:03 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "FRousseau" == FRousseau  <[e-mail]> writes:

 FRousseau> Salut Denis, I do not remember if this issue was raised
 FRousseau> before, but although I understand that there is no limit
 FRousseau> on the size of an Integer value, the "serialNumber" field
 FRousseau> of a time stamping response in Section 2.4.2 will
 FRousseau> ultimately become an enormously large number over the life
 FRousseau> of a TSA that is issuing numerous time stamps per second.

64 bits is not that large, and will last more than long enough.

In network management, 64 bit counters are often used because you can
make a byte counter on a high speed link 64 bits and never have to
worry about wrapping it.  So clearly it's good enough for this
application. 

 FRousseau> Would it not be more sensible for the serialNumber field
 FRousseau> to optionally be a monotonically increasing integer from
 FRousseau> one TimeStampToken to the next within a fixed period of
 FRousseau> time specified by the TSA's policy (e.g. a week, a day, an
 FRousseau> hour, etc.)?

 FRousseau> Such a serialNumber with the appropriate period of time
 FRousseau> would still provide a way to build a unique identifier to
 FRousseau> reference a time stamp token.

Yes, but it would be a very different thing and if such a field is
included it really should have a different name.

	 paul


Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17128 for <[e-mail]>; Thu, 18 May 2000 06:49:55 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id GAA11882; Thu, 18 May 2000 06:56:02 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK8CVL>; Thu, 18 May 2000 06:54:59 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Al Arsenault <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Thu, 18 May 2000 06:54:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis:

It seems to me that classes constitute the classic example of different
certificate policies.  Don't we have all the mechanism we need?

Warwick


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16901 for <[e-mail]>; Thu, 18 May 2000 06:45:27 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQipsh28527; Thu, 18 May 2000 13:52:05 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04418; Thu, 18 May 00 09:48:40 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA24746; Thu, 18 May 2000 09:52:03 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 18 May 2000 09:52:03 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: SubjectAltName verification
References: <[e-mail]> <v04220801b549227ae10c@[128.33.238.84]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:

 Stephen> Warwick,
 >> The meaning of "verify" (in this context) is entirely a matter of
 >> policy, and needs to be made clear in the CP/CPS wrt all fields of
 >> material significance.  Re our long-ago discussion on
 >> "non-verified subscriber information", I recall us agreeing that a
 >> certificate *may* (subject to policy) contain non-verified
 >> subscriber information.  However, because "verification" means
 >> different things for different fields, a binary flag was not the
 >> answer.  The extent to which different fields are verified (or
 >> not) by a CA is expressed in the CP/CPS.
 >> 
 >> I believe this interpretation extends to subjectAltName since
 >> different alternatives will unquestionably be "verified" in
 >> different ways.

 Stephen> We disagree wrt inclusion of non-verified info, and the
 Stephen> consensus of the WG in this regard.  I agree that a CA
 Stephen> policy may declare that a CA has chosen to do this, but I
 Stephen> believe that such behavior warrants censure.

I'm inclined to agree.

If Warwick's interpretation is to be adopted, then the text urgently
needs to be repaired so it does not mislead.  The current text (i.e.,
its intuitive meaning in plain English) supports Steve's
interpretation and not Warwick's.  If the other interpretation is
intended, then the text needs to say so quite explicitly.  For
example, with words like this:

 "Whether the subjectAltName or any other field of the certificate has
 been verified by the CA is a matter of policy and can be ascertained
 only by examination of the CPS.  If a RP needs to know that a
 particular attribute is definitively bound to the public key of the
 subject, it must examine the CPS to learn whether the CA has indeed
 verified this binding."

It would be possible to take a middle ground between the two
positions, i.e., encouraging the definitive binding but not requiring
it.  That of course means changing the "MUST" to a "SHOULD" and
perhaps adding words to the effect that the CPS must indicate what is
done. 

Personally, I prefer Steve's position.  I wonder if it is necessary to
add words to the effect that a conforming CA cannot use the CPS to get
out of supporting mandatory items in the RFC and still be considered
conforming.  After all, that's we're talking about right now.  It
really shouldn't be, after all that's why we use standardized
terminology (like "MUST").

	     paul



Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16711 for <[e-mail]>; Thu, 18 May 2000 06:44:32 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id GAA11722; Thu, 18 May 2000 06:51:23 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK8CTT>; Thu, 18 May 2000 06:50:20 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Thu, 18 May 2000 06:50:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve:

A common example of a nonverified name, as mentioned by Denis, is an alias
which is deliberately not verified, sometimes because of privacy or
annonymity requirements.  There are also examples where a part of a name is
not verified at all. For example, when issuing a certificate to an
organizational system (server, even intermediate CA) it is not uncommon for
the CA to verify the organization name, but allow any name the organization
cares to ask for in the OU fields.  Also, as both Denis and I pointed out,
there are wide variations in the meaning of "verify", some of them being
arguably very weak. Where does one draw the line between very weak
verification and no verification?

I respectfully propose that, as in the past, we leave such issues as a
matter of policy, and expressly exclude judgements on them from the PKIX
standards.  I certainly do not believe that PKIX should be in the business
of "censuring" CAs over their policies.

Warwick


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16451 for <[e-mail]>; Thu, 18 May 2000 06:40:00 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA41878; Thu, 18 May 2000 15:46:32 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 15:46:34 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <v04220801b549227ae10c@[128.33.238.84]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Al,

There was indeed two open questions (one explicit, one implicit).
You answered to the first one, and I agree that some "other" body
might be more appropriate to start the work and, maybe, when they
are done, they should present their work to us.

The second question is our concern. I said : "We would also need to
say how to express the concept of class in the certificate." 

So the question is: Should we say how/where to express the concept
of class in a certificate (in particular an end-user certificate) ?


Maybe we already have the right field and the right syntax to
accommodate the information, but we would need to extend/modify some
rules.

Denis


> Denis Pinkas wrote:
> >
> > Hum !!! Interesting discussion between the two co-chairs.  :-)
> >
> 
> I agree with Steve on this one.
> 
> > Whatever information is contained in a certificate, there are
> > various degrees of verification that can apply. The verification
> > level may even be different for each field. To this respect, Warwick
> > is right to say that a flag would not be adequate.
> >
> > A certificate must contain a name that may be carried in the DN
> > field or the SubjectAltName extension. That name must be unique and
> > is assigned by the CA. The name, wherever it is placed, must be
> > verified (well with the exception of pseudonyms that can only be
> > verified not to collide) with some *reasonable* degree of
> > verification.
> >
> > All other extra fields related to the user that we allow to be
> > present in a certificate are not mandated. If a phone number is
> > included does that means that the CA has simply accepted the phone
> > number that was included in the registration form ? or that the CA
> > has requested a proof from a telephone company that the applicant
> > was the legitimate subscriber of the phone line ? or that the CA has
> > made a phone call to that number to get the person on the phone ?
> >
> 
> In general, if the CA is not also the RA, the CA accepts the RA's
> assertion that the RA is either authoritative for all information to go
> in the certificate, or that the RA has verified the information with
> whomever is authoritative.  That is, the RA has certified that "this is
> Al's e-mail address, because I issued it", and "this is Al's phone
> number, which I ran around to his desk and verified or called the
> company phone office to verify or ..."  If the CA is also acting as the
> RA, then it is the CA's job to do this verification.
> 
> Of course, how well this job is done is a function of the CPS (or other
> policy document which serves in place of the CPS, as I was reminded at a
> meeting yesterday :-), but it needs to be done.  Giving me a certificate
> with a subjectAltName, OtherName type, of Phone_number =
> the_White_House_switchboard is somewhat irresponsible on the part of the
> CA, and should not be condoned by PKIX.
> 
> > The answer to the issue raised is not black or white. Today there
> > exists (free) certificates where no verification (except uniqueness
> > of name) is performed. There are used for testing purposes, and
> > should be recognized as such (but they are not). A next level is to
> > verify very loosely the name, in particular when it is an E-mail
> > address, by sending back an E-mail to that address. A next level is
> > to use some background check with a data base to make sure of the
> > information that is provided. A next level is to ask for one proof
> > of identity and other related information. A next level is to ask
> > for two proofs of identity and other related information. I will
> > stop here these examples.
> >
> > The industry has introduced the concept of classes of certificates.
> > The problem is that each CA issuer has made its own definition of
> > what such a class is.
> >
> > Maybe it is now the right time to raise the question whether we
> > should standardize the concept of classes of certificates.
> >
> 
> For PKIX, I would vote "NO" to this question. Maybe the PKI Forum or
> somebody else should pick it up.
> 
> > In this way we would recognize various levels of verification. We
> > would also need to say how the express the concept of class in the
> > certificate. We do not necessarily need a new extension for this.
> > Let us keep certificates slim.  :-).
> >
> > Denis
> >
> 
>                 Al Arsenault
>                 Chief Security Architect
>                 Diversinet Corp.


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15654 for <[e-mail]>; Thu, 18 May 2000 06:13:35 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA13416; Thu, 18 May 2000 15:20:02 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 15:20:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: TSA Response serialNumber Field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Salut Denis,
> 
> I do not remember if this issue was raised before, but although I understand
> that there is no limit on the size of an Integer value, the "serialNumber"
> field of a time stamping response in Section 2.4.2 will ultimately become an
> enormously large number over the life of a TSA that is issuing numerous time
> stamps per second.

I do not see a problem here. We do not have a limitation for
serialNumber in a public key certificate.
In our case, 64 bits would be quite enough, while 32 bits would be
too small.

To accomodate your issue we could add a comment in the ASN1 for the
serialNumber saying:

-- Time Stamps users must be ready to accomodate integers up to 64
bits.

> Would it not be more sensible for the serialNumber field to optionally be a
> monotonically increasing integer from one TimeStampToken to the next within
> a fixed period of time specified by the TSA's policy (e.g. a week, a day, an
> hour, etc.)?

I do not think so.

> Such a serialNumber with the appropriate period of time would still provide
> a way to build a unique identifier to reference a time stamp token.

But such an identifier would be much longer. :-(

Thanks for your comment,

Denis
 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]


Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA14064 for <[e-mail]>; Thu, 18 May 2000 05:39:54 -0700 (PDT)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id IAA20275; Thu, 18 May 2000 08:46:31 -0400 (EDT)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[e-mail]>; Thu, 18 May 2000 08:45:44 -0400 (EDT)
Received: from emss03i01.ems.lmco.com ([141.240.30.127]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[e-mail]>; Thu, 18 May 2000 08:45:41 -0400 (EDT)
Received: by emss03i01.orl.lmco.com with Internet Mail Service (5.5.2650.21)	id <KYDKMLWJ>; Thu, 18 May 2000 08:44:01 -0400
Content-return: allowed
Date: Thu, 18 May 2000 08:41:30 -0400
From: "Yutzy, Murray" <[e-mail]>
Subject: RE: SubjectAltName verification
To: "'Al Arsenault'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Denis Pinkas wrote:
> 
> Hum !!! Interesting discussion between the two co-chairs.  :-)
> 

I agree with Steve on this one.

> Whatever information is contained in a certificate, there are
> various degrees of verification that can apply. The verification
> level may even be different for each field. To this respect, Warwick
> is right to say that a flag would not be adequate.
> 
> A certificate must contain a name that may be carried in the DN
> field or the SubjectAltName extension. That name must be unique and
> is assigned by the CA. The name, wherever it is placed, must be
> verified (well with the exception of pseudonyms that can only be
> verified not to collide) with some *reasonable* degree of
> verification.
> 
> All other extra fields related to the user that we allow to be
> present in a certificate are not mandated. If a phone number is
> included does that means that the CA has simply accepted the phone
> number that was included in the registration form ? or that the CA
> has requested a proof from a telephone company that the applicant
> was the legitimate subscriber of the phone line ? or that the CA has
> made a phone call to that number to get the person on the phone ?
> 

In general, if the CA is not also the RA, the CA accepts the RA's
assertion that the RA is either authoritative for all information to go
in the certificate, or that the RA has verified the information with
whomever is authoritative.  That is, the RA has certified that "this is
Al's e-mail address, because I issued it", and "this is Al's phone
number, which I ran around to his desk and verified or called the
company phone office to verify or ..."  If the CA is also acting as the
RA, then it is the CA's job to do this verification.

Of course, how well this job is done is a function of the CPS (or other
policy document which serves in place of the CPS, as I was reminded at a
meeting yesterday :-), but it needs to be done.  Giving me a certificate
with a subjectAltName, OtherName type, of Phone_number =
the_White_House_switchboard is somewhat irresponsible on the part of the
CA, and should not be condoned by PKIX.


> The answer to the issue raised is not black or white. Today there
> exists (free) certificates where no verification (except uniqueness
> of name) is performed. There are used for testing purposes, and
> should be recognized as such (but they are not). A next level is to
> verify very loosely the name, in particular when it is an E-mail
> address, by sending back an E-mail to that address. A next level is
> to use some background check with a data base to make sure of the
> information that is provided. A next level is to ask for one proof
> of identity and other related information. A next level is to ask
> for two proofs of identity and other related information. I will
> stop here these examples.
> 
> The industry has introduced the concept of classes of certificates.
> The problem is that each CA issuer has made its own definition of
> what such a class is.
> 
> Maybe it is now the right time to raise the question whether we
> should standardize the concept of classes of certificates.
>

For PKIX, I would vote "NO" to this question. Maybe the PKI Forum or
somebody else should pick it up.

Murray> I agree with refraining from attaching a level of class to a
certificate.
We went through iterations of trying to implement levels of trust based on
CA hierarchy. Basically a root CA over n Sub CA's, each having a level of
assurance.
We moved away from it due to consuming applications not really comprehending
the
difference and that they all chain to a common root.  We are hoping that a
user will
be issued a primary identification certificate, which does exactly that
identifies who
they are not what they can or can't do, and then depend on either  policy
OID's or
attribute certificates to provide capabilities.
 
> In this way we would recognize various levels of verification. We
> would also need to say how the express the concept of class in the
> certificate. We do not necessarily need a new extension for this.
> Let us keep certificates slim.  :-).
> 
> Denis
> 


		Al Arsenault
		Chief Security Architect
		Diversinet Corp.


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13749 for <[e-mail]>; Thu, 18 May 2000 05:37:13 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <KLC3NL9W>; Thu, 18 May 2000 08:44:38 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: TSA Response serialNumber Field
Date: Thu, 18 May 2000 08:44:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Salut Denis,

I do not remember if this issue was raised before, but although I understand
that there is no limit on the size of an Integer value, the "serialNumber"
field of a time stamping response in Section 2.4.2 will ultimately become an
enormously large number over the life of a TSA that is issuing numerous time
stamps per second.

Would it not be more sensible for the serialNumber field to optionally be a
monotonically increasing integer from one TimeStampToken to the next within
a fixed period of time specified by the TSA's policy (e.g. a week, a day, an
hour, etc.)?

Such a serialNumber with the appropriate period of time would still provide
a way to build a unique identifier to reference a time stamp token.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13067 for <[e-mail]>; Thu, 18 May 2000 05:24:07 -0700 (PDT)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 18 May 2000 05:30:38 -0700
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 08:28:24 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <v04220801b549227ae10c@[128.33.238.84]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> 
> Hum !!! Interesting discussion between the two co-chairs.  :-)
> 

I agree with Steve on this one.

> Whatever information is contained in a certificate, there are
> various degrees of verification that can apply. The verification
> level may even be different for each field. To this respect, Warwick
> is right to say that a flag would not be adequate.
> 
> A certificate must contain a name that may be carried in the DN
> field or the SubjectAltName extension. That name must be unique and
> is assigned by the CA. The name, wherever it is placed, must be
> verified (well with the exception of pseudonyms that can only be
> verified not to collide) with some *reasonable* degree of
> verification.
> 
> All other extra fields related to the user that we allow to be
> present in a certificate are not mandated. If a phone number is
> included does that means that the CA has simply accepted the phone
> number that was included in the registration form ? or that the CA
> has requested a proof from a telephone company that the applicant
> was the legitimate subscriber of the phone line ? or that the CA has
> made a phone call to that number to get the person on the phone ?
> 

In general, if the CA is not also the RA, the CA accepts the RA's
assertion that the RA is either authoritative for all information to go
in the certificate, or that the RA has verified the information with
whomever is authoritative.  That is, the RA has certified that "this is
Al's e-mail address, because I issued it", and "this is Al's phone
number, which I ran around to his desk and verified or called the
company phone office to verify or ..."  If the CA is also acting as the
RA, then it is the CA's job to do this verification.

Of course, how well this job is done is a function of the CPS (or other
policy document which serves in place of the CPS, as I was reminded at a
meeting yesterday :-), but it needs to be done.  Giving me a certificate
with a subjectAltName, OtherName type, of Phone_number =
the_White_House_switchboard is somewhat irresponsible on the part of the
CA, and should not be condoned by PKIX.


> The answer to the issue raised is not black or white. Today there
> exists (free) certificates where no verification (except uniqueness
> of name) is performed. There are used for testing purposes, and
> should be recognized as such (but they are not). A next level is to
> verify very loosely the name, in particular when it is an E-mail
> address, by sending back an E-mail to that address. A next level is
> to use some background check with a data base to make sure of the
> information that is provided. A next level is to ask for one proof
> of identity and other related information. A next level is to ask
> for two proofs of identity and other related information. I will
> stop here these examples.
> 
> The industry has introduced the concept of classes of certificates.
> The problem is that each CA issuer has made its own definition of
> what such a class is.
> 
> Maybe it is now the right time to raise the question whether we
> should standardize the concept of classes of certificates.
>

For PKIX, I would vote "NO" to this question. Maybe the PKI Forum or
somebody else should pick it up.
 
> In this way we would recognize various levels of verification. We
> would also need to say how the express the concept of class in the
> certificate. We do not necessarily need a new extension for this.
> Let us keep certificates slim.  :-).
> 
> Denis
> 


		Al Arsenault
		Chief Security Architect
		Diversinet Corp.


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA27815 for <[e-mail]>; Thu, 18 May 2000 01:15:30 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA20640; Thu, 18 May 2000 10:22:02 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 10:22:05 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > A certificate must contain a name that may be carried in the DN
> > field or the SubjectAltName extension. That name must be unique and
> > is assigned by the CA. The name, wherever it is placed, must be
> > verified (well with the exception of pseudonyms that can only be
> > verified not to collide) with some *reasonable* degree of
> > verification.
> >
> 'Unique' does seem the right word to me. You can have more than one
> 'name' for the same object, like a pseudonym and a 'real' name.
> 
> Are you talking about 'non-ambigous names'?

No. Unique means that a name, once given to one entity, must not be
given to a different entity (in short not issued twice to two
different entities).

Denis


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24859 for <[e-mail]>; Thu, 18 May 2000 00:43:14 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id JAA07881; Thu, 18 May 2000 09:49:16 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 18 May 2000 09:49:16 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id JAA13365; Thu, 18 May 2000 09:49:14 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id JAA00795; Thu, 18 May 2000 09:49:14 +0200 (MET DST)
Date: Thu, 18 May 2000 09:49:14 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: SubjectAltName verification
Cc: [e-mail]

> 
> A certificate must contain a name that may be carried in the DN
> field or the SubjectAltName extension. That name must be unique and
> is assigned by the CA. The name, wherever it is placed, must be
> verified (well with the exception of pseudonyms that can only be
> verified not to collide) with some *reasonable* degree of
> verification.
> 
'Unique' does seem the right word to me. You can have more than one
'name' for the same object, like a pseudonym and a 'real' name.

Are you talking about 'non-ambigous names'?  


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA21235 for <[e-mail]>; Wed, 17 May 2000 23:47:26 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id IAA20388; Thu, 18 May 2000 08:53:06 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 May 2000 08:53:08 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>, Warwick Ford <[e-mail]>
CC: [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]> <v04220801b549227ae10c@[128.33.238.84]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hum !!! Interesting discussion between the two co-chairs.  :-)

Whatever information is contained in a certificate, there are
various degrees of verification that can apply. The verification
level may even be different for each field. To this respect, Warwick
is right to say that a flag would not be adequate.

A certificate must contain a name that may be carried in the DN
field or the SubjectAltName extension. That name must be unique and
is assigned by the CA. The name, wherever it is placed, must be
verified (well with the exception of pseudonyms that can only be
verified not to collide) with some *reasonable* degree of
verification.

All other extra fields related to the user that we allow to be
present in a certificate are not mandated. If a phone number is
included does that means that the CA has simply accepted the phone
number that was included in the registration form ? or that the CA
has requested a proof from a telephone company that the applicant
was the legitimate subscriber of the phone line ? or that the CA has
made a phone call to that number to get the person on the phone ? 

The answer to the issue raised is not black or white. Today there
exists (free) certificates where no verification (except uniqueness
of name) is performed. There are used for testing purposes, and
should be recognized as such (but they are not). A next level is to
verify very loosely the name, in particular when it is an E-mail
address, by sending back an E-mail to that address. A next level is
to use some background check with a data base to make sure of the
information that is provided. A next level is to ask for one proof
of identity and other related information. A next level is to ask
for two proofs of identity and other related information. I will
stop here these examples.

The industry has introduced the concept of classes of certificates.
The problem is that each CA issuer has made its own definition of
what such a class is. 

Maybe it is now the right time to raise the question whether we
should standardize the concept of classes of certificates. 

In this way we would recognize various levels of verification. We
would also need to say how the express the concept of class in the
certificate. We do not necessarily need a new extension for this.
Let us keep certificates slim.  :-).

Denis

 
> Warwick,
> 
> >The meaning of "verify" (in this context) is entirely a matter of policy,
> >and needs to be made clear in the CP/CPS wrt all fields of material
> >significance.  Re our long-ago discussion on "non-verified subscriber
> >information", I recall us agreeing that a certificate *may* (subject to
> >policy) contain non-verified subscriber information.  However, because
> >"verification" means different things for different fields, a binary flag
> >was not the answer.  The extent to which different fields are verified (or
> >not) by a CA is expressed in the CP/CPS.
> >
> >I believe this interpretation extends to subjectAltName since different
> >alternatives will unquestionably be "verified" in different ways.
> 
> We disagree wrt inclusion of non-verified info, and the consensus of
> the WG in this regard.  I agree that a CA policy may declare that a
> CA has chosen to do this, but I believe that such behavior warrants
> censure.
> 
> Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA12388 for <[e-mail]>; Wed, 17 May 2000 21:30:13 -0700 (PDT)
Received: from [128.33.238.32] (TC032.BBN.COM [128.33.238.32]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id AAA11661; Thu, 18 May 2000 00:35:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220801b549227ae10c@[128.33.238.84]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Thu, 18 May 2000 00:32:21 -0400
To: Warwick Ford <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Warwick,

>The meaning of "verify" (in this context) is entirely a matter of policy,
>and needs to be made clear in the CP/CPS wrt all fields of material
>significance.  Re our long-ago discussion on "non-verified subscriber
>information", I recall us agreeing that a certificate *may* (subject to
>policy) contain non-verified subscriber information.  However, because
>"verification" means different things for different fields, a binary flag
>was not the answer.  The extent to which different fields are verified (or
>not) by a CA is expressed in the CP/CPS.
>
>I believe this interpretation extends to subjectAltName since different
>alternatives will unquestionably be "verified" in different ways.

We disagree wrt inclusion of non-verified info, and the consensus of 
the WG in this regard.  I agree that a CA policy may declare that a 
CA has chosen to do this, but I believe that such behavior warrants 
censure.

Steve



Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14072 for <[e-mail]>; Wed, 17 May 2000 17:47:58 -0700 (PDT)
Received: from CC787228A ([12.78.235.241]) by mtiwmhc27.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000518005404.UKIB2120.mtiwmhc27.worldnet.att.net@CC787228A>; Thu, 18 May 2000 00:54:04 +0000
Message-ID: <000201bfc063$8e2073d0$f1eb4e0c@CC787228A>
From: "Al Arsenault" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <01bfbfa7$d76f4320$[e-mail]>
Subject: Re: SubjectAltName verification
Date: Wed, 17 May 2000 13:25:38 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

Bob,

    I think that in general Steve and Paul have addressed this issue well -
PKIX should not support the presence of an "unverified" attribute in a
certificate.  To the extent that a CPS specifies, a CA should make every
attempt to validate that a subject is entitled to claim some attribute -
such as an e-mail address - the CA puts in a certificate.  Such validation
will typically include interaction with the name authority responsible for
that particular namespace - e.g., with whomever issues e-mail accounts at
the particular mail server.

    Specific comments:

>
> -----Original Message-----
> From: Robert Moskowitz <[e-mail]>
> To: Al Arsenault <[e-mail]>; 'Paul Koning' <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail]
> <[e-mail]>
> Date: Monday, May 15, 2000 3:10 PM
> Subject: RE: SubjectAltName verification
>
>
> >At 02:50 PM 5/15/2000 -0400, Al Arsenault wrote:
> >>I have to disagree with Bob on this. To me, the words imply what they
> say -
> >>that if the CA is going to issue a certificate that says that my
> >>subjectAltName of the form rfc822Name is "[e-mail]", the CA
> >>must have taken some steps to verify that that is indeed the case.
(e.g.,
> >>the CA could have a notarized letter from the authority responsible for
> >>assigning those e-mail addresses.)  To do otherwise is false or
misleading
> >>behavior on the part of the CA.
> >
> >First question:
> >
> >What are we going to use as the SubjectAltName in your Netopia box on
your
> >DSL line in your house, Al?  Shouldn't be YOUR email address, Al.  What
> >FQDN?  Remember there is no static IP address for you, everytime you boot
> >the Netopia, it can get a new IP address from the ISP.
> >

AWA:  Let's suppose hypothetically that my cable modem provider uses DHCP,
and issues me a new IP address every time I power on my computer.  To me, it
would be foolish for any CA to issue me a certificate with an IP address in
a subjectAltName, since the certificate would become invalid every time I
powered off the computer.  On the other hand, since my e-mail address
doesn't change very often, it's perfectly OK for a CA, after checking with
the account administrator, to issue me a cert with rfc822Name =
[e-mail].

> >Taking the FQDN further, these are internal boxes, getting a third party
> >cert.  The CA cannot do a DNS query on the internal DNS server.
> >
> >This all comes down to the CP and CPS.  Here is where is stated the
method
> >use to establish the content of SubjectAltName.  Now it would be really
> >nice if there were a KEYNOTE object in the cert that would express the
> >method of validation...
> >

    Al Arsenault
    Chief Security Architect
    Diversinet Corp.






Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11082 for <[e-mail]>; Wed, 17 May 2000 15:35:22 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id PAA28438; Wed, 17 May 2000 15:38:50 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDMG3RL>; Wed, 17 May 2000 15:39:45 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Robert Moskowitz <[e-mail]>
Cc: [e-mail]
Subject: RE: SubjectAltName verification
Date: Wed, 17 May 2000 15:39:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The meaning of "verify" (in this context) is entirely a matter of policy,
and needs to be made clear in the CP/CPS wrt all fields of material
significance.  Re our long-ago discussion on "non-verified subscriber
information", I recall us agreeing that a certificate *may* (subject to
policy) contain non-verified subscriber information.  However, because
"verification" means different things for different fields, a binary flag
was not the answer.  The extent to which different fields are verified (or
not) by a CA is expressed in the CP/CPS. 

I believe this interpretation extends to subjectAltName since different
alternatives will unquestionably be "verified" in different ways.

Warwick

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Monday, May 15, 2000 9:46 PM
To: Robert Moskowitz
Cc: [e-mail]
Subject: RE: SubjectAltName verification


Bob,

The underlying assumption is that the CA is vouching for the accuracy 
of ALL data in a certificate.  A syntax check is NOT what one would 
expect. yes, the CPS may hedge on how good a check the CA does, but 
there IS a presumption that the CA has made some effort to verify the 
info.  We long ago debated this issue; some folks wanted to have a 
flag for a CA to set to indicate the presence of non-verified data. 
We rejected that approach.

Steve


Received: from ns1.point.cz (ns1.point.cz [194.212.10.45]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09360 for <[e-mail]>; Wed, 17 May 2000 14:20:31 -0700 (PDT)
Received: from redwolf (im [192.168.172.250]) by ns1.point.cz (8.9.3/8.8.7) with ESMTP id WAA01119 for <[e-mail]>; Wed, 17 May 2000 22:24:34 +0200
Message-ID: <038e01bfc046$f9c452e0$[e-mail]>
From: "Ivo MACHULDA" <[e-mail]>
To: "ietf-pkix" <[e-mail]>
Subject: Can I insert char "@" in to common name in certificate?
Date: Wed, 17 May 2000 23:29:25 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Dear sir,
Please tell me.Can I insert char "@" in to common name in certificate?

Thank you very much

Ivo MACHULDA



Received: from 5sigexch2.hq.5sigcmd.army.mil (5sigexch2.hq.5sigcmd.army.mil [147.40.98.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03754 for <[e-mail]>; Tue, 16 May 2000 23:20:14 -0700 (PDT)
Received: by 5sigexch2.hq.5sigcmd.army.mil with Internet Mail Service (5.5.2650.10) id <K4K5SCY2>; Wed, 17 May 2000 08:26:16 +0200
Message-ID: <[e-mail]>
From: "Stringfield, Robert Mr." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], ietf-pkix <[e-mail]>, "'Thierry Van Doninck'" <[e-mail]>
Subject:  Does Smime works fine with Windows 2000 PKI
Date: Wed, 17 May 2000 08:26:04 +0200
X-Mailer: Internet Mail Service (5.5.2650.10)

It was not being able to read the text that I found interesting but the fact
that the cert came intact to me over a Listserver.  Using my DOD PKI cert I
was able to trust the Novell cert and read the tact.

Think that I also am able to use it to send SMIME mail to Bob.  How for I
have been unable to send SMIME text over Lsoft's ListServ.
--bob

	Robert L. Stringfield
	DMS/PKI 5th Signal Command
	DSN: 380-5857 FAX: [phone]
	mailto:[e-mail]
	http://www.5sigcmd.army.mil/DMS/dms.htm
	http://www.5sigcmd.army.mil/pki/pki.htm
	http://144.170.207.251/archives/index.html
>     Truth:  We own the Night!!! - DeathStar Warriors
> 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]


[My apologies -- in the course of reconfiguring my NT to be C2 compliant,
the setting for digitally signed mail reverted to base64 encoding, leaving
some 
people who are not S/MIME capable (poor souls!) unable to read the text.
Sorry 'bout that.]

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<SNIP>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA22246 for <[e-mail]>; Tue, 16 May 2000 13:07:02 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 16 May 2000 14:13:02 -0600
Mime-Version: 1.0
Date: Tue, 16 May 2000 14:12:00 -0600
X-Mailer: Groupwise 5.5.3.1
Subject: RE: Does Smime works fine with Windows 2000 PKI
To: [e-mail], ietf-pkix<[e-mail]>, "'Thierry Van Doninck'"<[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____SRUSHISZHIUMINBRKRDA____"

--____SRUSHISZHIUMINBRKRDA____
Content-Type: multipart/mixed; boundary="____THGSLHIQVBYKABORKGBY____"


--____THGSLHIQVBYKABORKGBY____
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


[My apologies -- in the course of reconfiguring my NT to be C2 compliant,
the setting for digitally signed mail reverted to base64 encoding, leaving =
some=20
people who are not S/MIME capable (poor souls!) unable to read the text.
Sorry 'bout that.]

Peter,

Although I agree that such questions might better be addressed to the=20
certalk list, I also agree with you that we should occasionally take =
the=20
pulse of the industry and see who has actually rolled out commercial-grade=
=20
products that implement that various standards.

And I thank you for including the link to one of Novell's web pages, which =
I was
not aware of.  I have contacted the document owner to have it updated.

For the record, Novell's GroupWise 5.5 Enhancement Pack e-mail product =20
supports S/MIME using EITHER the Entrust PKI solution, OR a more convention=
al
PKI solution that is based on the CSP capabilities provided by MS-CAPI and =
Internet=20
Explorer.

The current version supports S/MIME version 2, and most of version 3.  =
Release
schedules together with the uncertain state of CRL support by various CAs =
back=20
in mid-1999 led us to delay the availability of CRL processing in =
GroupWise.
This capability is currently scheduled for later this year.=20

Likewise, although support for S/MIME v3's separation between encryption =
keys=20
and digital signature keys was part of the original development, we chose =
not to=20
feature ro recommend that usage at this time, due to the fact that Outlook =
Express=20
seriously mishandles such dual keys, and frequently ends up sending=20
an encrypted reply to the sender, using the sender's signature key.

Entrust chose to try to undo that kind of mess by obligingly decrypting =
the message=20
using the signature key, but we felt that such an approach would seriously =
distort
the intent of the key usage policy, including controls over how the keys =
were=20
generated, how they were archived, etc.  We expect to fully support dual =
key usage
later this year, and we hope by that time the Outlook Express bug will =
have been fixed.

To the best of our knowledge, GroupWise can be used to request certificates=
 from
any commercial CA, and our interoperability tests did not disclose any =
particular
difficulties with a rather wide variety of X.509 v3 certificates.

GroupWise can also consume certificates issued in bulk from Novell's own =
free
Novell Certificate Server product 2.0, of course, and those certificates =
can also=20
be used by IE for SSL mutual authentication.

Sometimes it seems like it takes forever, but we have in fact come a long, =
long way=20
from the PEM days.

Regards,

Bob




>>> Peter Williams <[e-mail]> 05/15/00 04:46PM >>>
http://support.microsoft.com/support/exchange/content/whitepapers/win2k_kms=


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20114 for <[e-mail]>; Tue, 16 May 2000 11:14:04 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <K828BML2>; Tue, 16 May 2000 14:20:04 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'denis bider'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: RFC 2511: PKIArchiveOptions encoding?
Date: Tue, 16 May 2000 14:20:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Denis,

Your first alternative below ("the clean one") is correct:  tagging is
EXPLICIT in a CHOICE.  If you don't have the ASN.1 specifications, there are
a number of publicly-available books and tutorials on the subject.  One such
example is the book "ASN.1:  The Tutorial and Reference" by Douglas Steedman
(1990) -- see pages 66-67 for a discussion on this particular issue.

Carlisle.

P.S., As for real-world implementations of 2511 for interoperability testing
purposes, you can join the CMP/CRMF interop trials that have been on-going
for some time now.  Contact Bob Moskowitz ([e-mail]) or the PKI Forum
(http://www.pkiforum.org) for further details.


> ----------
> From: 	denis bider[SMTP:[e-mail]]
> Sent: 	Tuesday, May 16, 2000 9:15 AM
> To: 	[e-mail]
> Subject: 	RFC 2511: PKIArchiveOptions encoding?
> 
> Hello,
> 
> I am reading RFC 2511 and trying to understand how to properly parse the
> PKIArchiveOptions choice field. For your convenience, I am attaching the
> relevant ASN.1 definitions at the end of this message.
> 
> PKIArchiveOptions is a CHOICE with three possible value types, each of
> which
> is implicitly tagged ([0], [1], [2]). Now, the problem is, the first one
> of
> these types, [0] EncryptedKey, is a CHOICE as well. Now, EncryptedKey has
> two possible value types with two possible tags among them. One
> possibility,
> EnvelopedData, has an implicit tag of [0], and the other one,
> EncryptedValue, is a SEQUENCE.
> 
> My question is - how does this fit together? I see two possibilities:
>   - The clean one: the EncryptedKey type within PKIArchiveOptions is
> actually not implicitly tagged, but rather is explicitly tagged, because
> it
> is a CHOICE within a CHOICE. However, this fact is not stated in the ASN.1
> definition because there is some clause in the ASN.1 specification that
> already says that this applies in such cases. (Unfortunately, I do not
> have
> access to such an ASN.1 specification.)
>   - The dirty one: the EncryptedKey type within PKIArchiveOptoins is
> indeed
> implicitly tagged. Therefore, it actually has two possible tags: [0] if
> the
> sub-type being used is EnvelopedData, and SEQUENCE if the sub-type being
> used is EncryptedValue.
> 
> Is there someone here who would care to point me in the right direction?
> 
> Also, I would be glad if someone could enumerate some real-world
> implementations of RFC 2511; it would be great if I could test my
> implementation against others that are already proven.
> 
> Note: I tried searching the archives, but the archive site turned out to
> be
> rather useless. The only feasible way to search the archives is to scan
> the
> subject lines, which are on 13 different pages, for keywords that one
> might
> only hope will appear in the subject of a related message. The only
> alternative is to download the entire archive file and search that file
> with
> one's favourite tools. However, at a file size of 16 MB and a throughput
> of
> 10KB per second this is not a very appealing alternative.
> 
> Kind regards,
> 
> denis bider
> 
> 
> 
> Some relevant ASN.1 definitions:
> 
> PKIArchiveOptions ::= CHOICE {
>       encryptedPrivKey     [0] EncryptedKey,
>       -- the actual value of the private key
>       keyGenParameters     [1] KeyGenParameters,
>       -- parameters which allow the private key to be re-generated
>       archiveRemGenPrivKey [2] BOOLEAN }
>       -- set to TRUE if sender wishes receiver to archive the private
>       -- key of a key pair which the receiver generates in response to
>       -- this request; set to FALSE if no archival is desired.
> 
> EncryptedKey ::= CHOICE {
>       encryptedValue        EncryptedValue,
>       envelopedData     [0] EnvelopedData }
>       -- The encrypted private key MUST be placed in the envelopedData
>       -- encryptedContentInfo encryptedContent OCTET STRING.
> 
> EncryptedValue ::= SEQUENCE {
>    ...
> }
> 
> 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA14677 for <[e-mail]>; Tue, 16 May 2000 07:42:23 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 16 May 2000 08:48:08 -0600
Mime-Version: 1.0
Date: Tue, 16 May 2000 08:47:00 -0600
X-Mailer: Groupwise 5.5.3.1
Subject: RE: Does Smime works fine with Windows 2000 PKI
To: [e-mail], ietf-pkix<[e-mail]>, "'Thierry Van Doninck'"<[e-mail]>
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"; modification-date="Tue, 16 May 2000 08:47:48 -0600"

MIIiqQYJKoZIhvcNAQcCoIIimjCCIpYCAQExCzAJBgUrDgMCGgUAMIIWGwYJKoZIhvcNAQcBoIIW
DASCFghGcm9tOiBCSlVFTkVNQU5Abm92ZWxsLmNvbQ0KU3ViamVjdDogUkU6IERvZXMgU21pbWUg
d29ya3MgZmluZSB3aXRoIFdpbmRvd3MgMjAwMCBQS0kNClRvOiBwZXRlcndAdmFsaWNlcnQuY29t
LCBpZXRmLXBraXg8aWV0Zi1wa2l4QGltYy5vcmc+LCAnVGhpZXJyeSBWYW4NCglEb25pbmNrJzxU
aGllcnJ5LlZhbkRvbmluY2tAZGV4aWEuYmU+DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNo
YXJzZXQ9aXNvLTg4NTktMQ0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50
YWJsZQ0KDQpQZXRlciwNCg0KQWx0aG91Z2ggSSBhZ3JlZSB0aGF0IHN1Y2ggcXVlc3Rpb25zIG1p
Z2h0IGJldHRlciBiZSBhZGRyZXNzZWQgdG8gdGhlPTIwDQpjZXJ0YWxrIGxpc3QsIEkgYWxzbyBh
Z3JlZSB3aXRoIHlvdSB0aGF0IHdlIHNob3VsZCBvY2Nhc2lvbmFsbHkgdGFrZSA9DQp0aGU9MjAN
CnB1bHNlIG9mIHRoZSBpbmR1c3RyeSBhbmQgc2VlIHdobyBoYXMgYWN0dWFsbHkgcm9sbGVkIG91
dCBjb21tZXJjaWFsLWdyYWRlPQ0KPTIwDQpwcm9kdWN0cyB0aGF0IGltcGxlbWVudCB0aGF0IHZh
cmlvdXMgc3RhbmRhcmRzLg0KDQpBbmQgSSB0aGFuayB5b3UgZm9yIGluY2x1ZGluZyB0aGUgbGlu
ayB0byBvbmUgb2YgTm92ZWxsJ3Mgd2ViIHBhZ2VzLCB3aGljaCA9DQpJIHdhcw0Kbm90IGF3YXJl
IG9mLiAgSSBoYXZlIGNvbnRhY3RlZCB0aGUgZG9jdW1lbnQgb3duZXIgdG8gaGF2ZSBpdCB1cGRh
dGVkLg0KDQpGb3IgdGhlIHJlY29yZCwgTm92ZWxsJ3MgR3JvdXBXaXNlIDUuNSBFbmhhbmNlbWVu
dCBQYWNrIGUtbWFpbCBwcm9kdWN0ID0yMA0Kc3VwcG9ydHMgUy9NSU1FIHVzaW5nIEVJVEhFUiB0
aGUgRW50cnVzdCBQS0kgc29sdXRpb24sIE9SIGEgbW9yZSBjb252ZW50aW9uPQ0KYWwNClBLSSBz
b2x1dGlvbiB0aGF0IGlzIGJhc2VkIG9uIHRoZSBDU1AgY2FwYWJpbGl0aWVzIHByb3ZpZGVkIGJ5
IE1TLUNBUEkgYW5kID0NCkludGVybmV0PTIwDQpFeHBsb3Jlci4NCg0KVGhlIGN1cnJlbnQgdmVy
c2lvbiBzdXBwb3J0cyBTL01JTUUgdmVyc2lvbiAyLCBhbmQgbW9zdCBvZiB2ZXJzaW9uIDMuICA9
DQpSZWxlYXNlDQpzY2hlZHVsZXMgdG9nZXRoZXIgd2l0aCB0aGUgdW5jZXJ0YWluIHN0YXRlIG9m
IENSTCBzdXBwb3J0IGJ5IHZhcmlvdXMgQ0FzID0NCmJhY2s9MjANCmluIG1pZC0xOTk5IGxlZCB1
cyB0byBkZWxheSB0aGUgYXZhaWxhYmlsaXR5IG9mIENSTCBwcm9jZXNzaW5nIGluID0NCkdyb3Vw
V2lzZS4NClRoaXMgY2FwYWJpbGl0eSBpcyBjdXJyZW50bHkgc2NoZWR1bGVkIGZvciBsYXRlciB0
aGlzIHllYXIuPTIwDQoNCkxpa2V3aXNlLCBhbHRob3VnaCBzdXBwb3J0IGZvciBTL01JTUUgdjMn
cyBzZXBhcmF0aW9uIGJldHdlZW4gZW5jcnlwdGlvbiA9DQprZXlzPTIwDQphbmQgZGlnaXRhbCBz
aWduYXR1cmUga2V5cyB3YXMgcGFydCBvZiB0aGUgb3JpZ2luYWwgZGV2ZWxvcG1lbnQsIHdlIGNo
b3NlID0NCm5vdCB0bz0yMA0KZmVhdHVyZSBybyByZWNvbW1lbmQgdGhhdCB1c2FnZSBhdCB0aGlz
IHRpbWUsIGR1ZSB0byB0aGUgZmFjdCB0aGF0IE91dGxvb2sgPQ0KRXhwcmVzcz0yMA0Kc2VyaW91
c2x5IG1pc2hhbmRsZXMgc3VjaCBkdWFsIGtleXMsIGFuZCBmcmVxdWVudGx5IGVuZHMgdXAgc2Vu
ZGluZz0yMA0KYW4gZW5jcnlwdGVkIHJlcGx5IHRvIHRoZSBzZW5kZXIsIHVzaW5nIHRoZSBzZW5k
ZXIncyBzaWduYXR1cmUga2V5Lg0KDQpFbnRydXN0IGNob3NlIHRvIHRyeSB0byB1bmRvIHRoYXQg
a2luZCBvZiBtZXNzIGJ5IG9ibGlnaW5nbHkgZGVjcnlwdGluZyA9DQp0aGUgbWVzc2FnZT0yMA0K
dXNpbmcgdGhlIHNpZ25hdHVyZSBrZXksIGJ1dCB3ZSBmZWx0IHRoYXQgc3VjaCBhbiBhcHByb2Fj
aCB3b3VsZCBzZXJpb3VzbHkgPQ0KZGlzdG9ydA0KdGhlIGludGVudCBvZiB0aGUga2V5IHVzYWdl
IHBvbGljeSwgaW5jbHVkaW5nIGNvbnRyb2xzIG92ZXIgaG93IHRoZSBrZXlzID0NCndlcmU9MjAN
CmdlbmVyYXRlZCwgaG93IHRoZXkgd2VyZSBhcmNoaXZlZCwgZXRjLiAgV2UgZXhwZWN0IHRvIGZ1
bGx5IHN1cHBvcnQgZHVhbCA9DQprZXkgdXNhZ2UNCmxhdGVyIHRoaXMgeWVhciwgYW5kIHdlIGhv
cGUgYnkgdGhhdCB0aW1lIHRoZSBPdXRsb29rIEV4cHJlc3MgYnVnIHdpbGwgPQ0KaGF2ZSBiZWVu
IGZpeGVkLg0KDQpUbyB0aGUgYmVzdCBvZiBvdXIga25vd2xlZGdlLCBHcm91cFdpc2UgY2FuIGJl
IHVzZWQgdG8gcmVxdWVzdCBjZXJ0aWZpY2F0ZXM9DQogZnJvbQ0KYW55IGNvbW1lcmNpYWwgQ0Es
IGFuZCBvdXIgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0cyBkaWQgbm90IGRpc2Nsb3NlIGFueSA9DQpw
YXJ0aWN1bGFyDQpkaWZmaWN1bHRpZXMgd2l0aCBhIHJhdGhlciB3aWRlIHZhcmlldHkgb2YgWC41
MDkgdjMgY2VydGlmaWNhdGVzLg0KDQpHcm91cFdpc2UgY2FuIGFsc28gY29uc3VtZSBjZXJ0aWZp
Y2F0ZXMgaXNzdWVkIGluIGJ1bGsgZnJvbSBOb3ZlbGwncyBvd24gPQ0KZnJlZQ0KTm92ZWxsIENl
cnRpZmljYXRlIFNlcnZlciBwcm9kdWN0IDIuMCwgb2YgY291cnNlLCBhbmQgdGhvc2UgY2VydGlm
aWNhdGVzID0NCmNhbiBhbHNvPTIwDQpiZSB1c2VkIGJ5IElFIGZvciBTU0wgbXV0dWFsIGF1dGhl
bnRpY2F0aW9uLg0KDQpTb21ldGltZXMgaXQgc2VlbXMgbGlrZSBpdCB0YWtlcyBmb3JldmVyLCBi
dXQgd2UgaGF2ZSBpbiBmYWN0IGNvbWUgYSBsb25nLCA9DQpsb25nIHdheT0yMA0KZnJvbSB0aGUg
UEVNIGRheXMuDQoNClJlZ2FyZHMsDQoNCkJvYg0KDQoNCg0KDQo+Pj4gUGV0ZXIgV2lsbGlhbXMg
PHBldGVyd0B2YWxpY2VydC5jb20+IDA1LzE1LzAwIDA0OjQ2UE0gPj4+DQpodHRwOi8vc3VwcG9y
dC5taWNyb3NvZnQuY29tL3N1cHBvcnQvZXhjaGFuZ2UvY29udGVudC93aGl0ZXBhcGVycy93aW4y
a19rbXM9DQouDQpkb2MNCg0KVGhpZXJyeSwNCg0KSSBkaXNhZ3JlZSB3aXRoIFBoaWwuIEkgcGVy
c29uYWxseSBtZWFzdXJlIHRoZSBzdGF0ZQ0Kb2Ygb3Blbi1uZXNzIG9mIHRoZSBhY3R1YWwgUEtJ
WCBpbmR1c3RyeSBpbiB0aGUgVVMgYnkgdGhlIHdvcmsNCnRoYXQgTWljcm9zb2Z0IGRvZXMgaW4g
WC41MDkuIERldGVybWluaW5nIG9wZW4gc3RhbmRhcmRzIGFkb3B0aW9uPTIwDQphbmQgaW50ZXJv
cGVyYWJpbGl0eSBvdmVyIHRpbWUgaXMgYW4gaW1wb3J0YW50IGVsZW1lbnQgb2Y9MjANCnN0YW5k
YXJkcyBtYWtpbmcgYW5kIG5hdGlvbmFsIGluZnJhc3RydWN0dXJlKHMpIHBsYW5uaW5nLCBpbiBt
eT0yMA0KcGVyaGFwcyBzaW1wbGlzdGljIHZpZXcuDQoNCmh0dHA6Ly93d3cubWljcm9zb2Z0LmNv
bS9FeGNoYW5nZS81NS9nZW4vY29tcGFyZS5odG09MjANCmlzIGEgKE1pY3Jvc29mdC1tYXJrZXRp
bmcpIGNvbXBhcmlzb24gb2YgRXhjaGFuZ2UNCmFuZCBQS0kgd2l0aCBjb21wZXRpdGl2ZSBwcm9k
dWN0cyB0aGF0IGluY2x1ZGUgUEtJLiBUaGUNCmxpbmsgZ2l2ZSBhIGdsaW1wc2Ugb2YgcmVhbGl0
eSBvZiBQS0lYIGluIGF2ZXJhZ2UNCmVudGVycHJpc2UgbWFpbCBwcm9kdWN0cy4NCg0KU29tZSBv
dGhlciBVUkxzIGRpc2N1c3NpbmcgaW1wb3J0YW50IGFzcGVjdHMNCm9mIFMvTUlNRSBpbnRlZ3Jh
dGlvbiBpbnRvIGNvbW1lcmNpYWwtZ3JhZGUNCmludGVybmV0IGVudmlyb25tZW50czoNCg0KQmV5
b25kIFMvTUlNRSBhbmQgb250byBYLjQwMCBzZWN1cmUgc3RhY2tzL25ldHdvcmtzOg0KaHR0cDov
L3d3dy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlLzU1L2dlbi9TZWN1cml0eS5odG09MjANCg0KQSBM
b3R1cyBzdHVkeSBvZiBQS0kgYW5kIFMvTUlNRSBkZXBsb3ltZW50IC0gZm9yIElkZW50cnVzIGJh
bmtzOg0KaHR0cDovL3d3dy5sb3R1cy5jb20vOTkvc2Vzc2lvbi5uc2YvMTg3ODAxZGQ4ZDA3NjM2
YTg1MjU2NzdkMDA1YTRhYzgvNzg4ODhhPQ0KYT0yMA0KMGFmOWVjMjliODUyNTY4NGUwMDc5YThk
Mw0KDQpBIFN0dWR5IG9mIE5vdmVsbCdzIGludGVncmF0aW9uIHdpdGggdGhlIHdvcmxkLWNsYXNz
IEVudHJ1c3Qgc29sdXRpb24uDQoNCmh0dHA6Ly9zdXBwb3J0Lm5vdmVsbC5jb20vY2dpLWJpbi9z
ZWFyY2gvc2VhcmNoLnBsP2RhdGFiYXNlX25hbWU9M0RrYiZ0eXBlPQ0KPTNESFRNTCZkb2NpZD0z
RCUwMyUxZkYxNzA5ODUlM2E5NTg0Mjk3MTMlM2ElMjAlMjglMjBTJTJmTUlNRSUyMCUyOSUyMCUy
MCUwPQ0KNyUwMSUwMCZieXRlX2NvdW50PTNENDM5OQ0KDQpJZiB5b3UgYWRkIE5ldHNjYXBlIENl
cnRpZmljYXRlIFNlcnZlciBhbmQgUlNBIEtlb24vVmVyaVNpZ24gdG89MjANCnRoZSBhbmFseXNp
cywgd2UgaGF2ZSBtb3ZlZCBxdWl0ZSBhIGxvbmcgd2F5IGluIHRoZSBVUyBmcm9tIHRoZT0yMA0K
UEVNIGRheXMuDQoNClBldGVyLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
UGhpbGlwIEhhbGxhbS1CYWtlciBbbWFpbHRvOnBiYWtlckB2ZXJpc2lnbi5jb21dPTIwDQpTZW50
OiBNb25kYXksIE1heSAxNSwgMjAwMCA2OjA1IEFNDQpUbzogJ1RoaWVycnkgVmFuIERvbmluY2sn
OyBpZXRmLXBraXgNClN1YmplY3Q6IFJFOiBEb2VzIFNtaW1lIHdvcmtzIGZpbmUgd2l0aCBXaW5k
b3dzIDIwMDAgUEtJDQoNCg0KU2FtZSBhbnN3ZXIsIGFzayBNaWNyb3NvZnQsIG5vdCBhbiBJRVRG
IGRldmVsb3BtZW50IGxpc3QuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IFRoaWVycnkgVmFuIERvbmluY2sgW21haWx0bzpUaGllcnJ5LlZhbkRvbmluY2tAZGV4aWEuYmVd
PTIwDQpTZW50OiBUaHVyc2RheSwgTWF5IDExLCAyMDAwIDc6NDAgQU0NClRvOiBpZXRmLXBraXgN
ClN1YmplY3Q6IERvZXMgU21pbWUgd29ya3MgZmluZSB3aXRoIFdpbmRvd3MgMjAwMCBQS0kNCg0K
DQpIaSwNCg0KU2FtZSBtZXNzYWdlIGFzIG9uIHRoZSBzbWltZSBtYWlsaW5nIGxpc3QuDQpIYXMg
YW55IG9mIHlvdSBnb29kIHBlb3BsZSBhbnkgaW5mbyBvbiBXaW5kb3dzIDIwMDAgUEtJID8NCg0K
VGhhbmtzLA0KDQpUaGllcnJ5DQoNCj0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z
RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0NCj0zRD0zRD0zRD0zRD0z
RD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z
RD0zRD0NCj0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0zRD0z
RD0zRD0zRD0zRD0zRD0zRA0KPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEPTNEDQoN
CkhpIGV2ZXJ5Ym9keSwNCg0KSnVzdCBhIHF1ZXN0aW9uIDoNCg0KSXMgdGhlcmUgYW55IGtub3du
IGlzc3VlcyB1c2luZyBTL01JTUUgd2l0aCBXaW4yMDAwUEtJLWNlcnRpZmljYXRlcyA/DQpNb3Jl
IGdlbmVyYWxseSwgYXJlIFdpbjIwMDAgY2VydGlmaWNhdGVzIHVzYWJsZSB3aXRoIChhbmQgdW5k
ZXJzdG9vZCBieQ0KKSB0aGUgb3RoZXJzIG1haWxlcnMgKGVzcGVjaWFsbHkgTG90dXMgTm90ZXMs
IE5ldHNjYXBlLCBFdWRvcmENCitwbHVnLWluPykNCg0KSXNuJ3QgQmFsdGltb3JlIFVuaWNlcnQg
YSAiYmV0dGVyIGNob2ljZSIgZHVlIHRvIGl0cyBncmVhdGVyDQpjb21wYXRpYmlsaXR5ID8NCg0K
QW55IGFkdmljZXMgYXJlIHdlbGNvbWUuDQoNClJlZ2FyZHMsDQoNCkxhdXJlbnQgRGVmZnJhbm5l
DQqgggofMIIFCDCCA/CgAwIBAgIaAhQAAAAUNP1e8mQuJK2QmnfLPCP/cgICA9owDQYJKoZIhvcN
AQEFBQAwMjEbMBkGA1UECxMSTm92ZWxsIEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5D
MB4XDTk5MTAwOTE3MjAwMFoXDTA5MTAwOTE3MjAwMFowMjEbMBkGA1UECxMSTm92ZWxsIEVtcGxv
eWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAxVzSeenZZTtL31xxaUyShV7D6ePzgxRoLsakDrf4EQfoxCC0bYfZJKOq9Q0TFbXSd72Bcbow
K1PRNXRFC5n9dr0Dh73i8ort/tkFhaFsRjEc3Xs4iZAeZZPJ6Et8oQggaBDofvFGfMW3l0YgRPU6
5+HuZqIx/PmqO5IR6XebcNjG3w4BIe54KdI4O2by1M/1FuJIvHpt+YNygt1BXVDv6vlf59jVKp6Y
FB9m5KaIm5EjI8AH1Z+dAdT6SvzCTBr7WBolbU76ulSg0fsGvFgu7lREIj2xIh/CjinfXxQQrGb3
ddn231HjSBZq5zZJOTm/6fxkSq6aRMVmxrnrpaQRMQIDAQABo4ICDjCCAgowCgYDVR0OBAMEAQEw
DAYDVR0jBAUwA4ABATAPBgNVHRMBAQAEBTADAQH/MA4GA1UdDwEBAAQEAwIBBjCCAcsGC2CGSAGG
+DcBCQQBAQEABIIBtzCCAbMEAgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZD
aHR0cDovL2RldmVsb3Blci5ub3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0
cnNfdjEwLmh0bTCCAUSgGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAwCDAGAgEBAgFG
MAgwBgIBAQIBCgIBaaIGAgEYAQH/o4IBAKBaAgECAgIA/wIBAAMNAIAAAAAAAAAAAAAAAAMJAIAA
AAAAAAAAMBgwEAIBAAIIf/////////8BAQACBAbw30gwGDAQAgEAAgh//////////wEBAAIEBvDf
SDBSoVICAQICAgD/AgEAAw0AQAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwFTAQAgEAAgh/////////
/wEBAAIBFDAVMBACAQACCH//////////AQEAAgEUok4wTAIBAgICAP8CAQADDQCA////////////
//8DCQCA/////////zASMBACAQACCH//////////AQH/MBIwEAIBAAIIf/////////8BAf8wDQYJ
KoZIhvcNAQEFBQADggEBAGohEpuwC0ipAiPOo2MnkT8zWs02OH9Bnqakz4ncDOeOoQ2SsZBXyo6K
fZ4WQxINEsY+vZC+5paqMFZVOnYKBD4KsD4JT9IwTutBMs6o6K61W56bkjVFaGPujsspsq3Ta8dg
xkwU6rCP4rqyC67dVdm/IqEwFkqfZR6+S8QDsUIE3jTDCP2+QdLE5QJcATW59itW9dRH2HcUppEG
X7EFQpnypfMtsahe19vluOWYHXr9PyUMQl5UVaBhDG7IbO1eQBAoPans5/XU8nwl9Z0vmKC5CX9J
Ib9jK3H6zdUhthBrrFdjVQ8QnVxbi4clscAMVS6COSzSDCxWuD/LwIpwsSUwggUPMIID96ADAgEC
AhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgIE6jANBgkqhkiG9w0BAQUFADAyMRswGQYDVQQLExJO
b3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkxMDA5MTgxODAwWhcN
MDExMDA5MTgxODAwWjBCMRIwEAYDVQQDEwlCSnVlbmVtYW4xDTALBgNVBAsTBE5TUkQxDDAKBgNV
BAsTA1BSVjEPMA0GA1UEChMGTm92ZWxsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
t3h7hk+uvRlsxrjGEiL3s5j3RBRdJ23ZYar9CsHmxuVh4uE4i8l+7PJevtAkEQBfaxUIRHYeyNpb
YvYYKzTo6OEmb8VND7LUHDfWnerrFzMxwWt+l499ZCVIYLihCqQmlGBplj3KunoS3LsU79J7qtUL
wBkyKowk+cv7aUsKNp16W/VFzhKWYPApi+jkyo+OHAJh8z5OnRJV8Re0o54ZDTmDb8ILPwH2vu4j
l9C7+r02CXms9XpJSjEqCX+ZmfxGXyY1JH+Yw0XSG+UaINvx1jBLAbz9r4Iga1dZ8FRRgZKX7Nas
KtAO4d1HRm5vDZc4BTLNpZbarTjWxomSuVDKAwIDAQABo4ICBTCCAgEwDAYDVR0jBAUwA4ABATAi
BgNVHREBAQAEGDAWgRRCSlVFTkVNQU5Abm92ZWxsLmNvbTCCAcsGC2CGSAGG+DcBCQQBAQEABIIB
tzCCAbMEAgEAAQH/Ex1Ob3ZlbGwgU2VjdXJpdHkgQXR0cmlidXRlKHRtKRZDaHR0cDovL2RldmVs
b3Blci5ub3ZlbGwuY29tL3JlcG9zaXRvcnkvYXR0cmlidXRlcy9jZXJ0YXR0cnNfdjEwLmh0bTCC
AUSgGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpoRoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIB
aaIGAgEUAQH/o4IBAKBaAgECAgIA/wIBAAMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBgwEAIB
AAIIf/////////8BAQACBAbw30gwGDAQAgEAAgh//////////wEBAAIEBvDfSDBSoVICAQICAgD/
AgEAAw0AQAAAAAAAAAAAAAAAAwkAQAAAAAAAAAAwFTAQAgEAAgh//////////wEBAAIBFDAVMBAC
AQACCH//////////AQEAAgEUok4wTAIBAgIBAAICAP8DDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAA
ADASMBACAQACCH//////////AQEAMBIwEAIBAAIIf/////////8BAQAwDQYJKoZIhvcNAQEFBQAD
ggEBAIhCHYqMfOAXyZc/LLjiXUxMJLibE9QG7CwcFsxKcHwUuRURoJTsisJY/BavmxZoJwV//8G1
uII7rYABLsPH1xlGkPXdqsFJ9Ok2vAvAHga+15sax3tR7OGAUH6rVaXW2Q2rIHjoSYSkgDJiG7+4
2o8CPaGfd2kucPwK5ExhZvoaXsWbEh7U43ChQEPe+zPkMG54pZpwXz2IkJPsv7hnAHiaiUZ5s236
25s5abMqoMiRDQvsw+DubavRp+d6R6RtRJ41/2Td/ozNByiHP6w7kPskOHty0Xnp60W5gKA5Q+ZK
xdrHxV6YWz/Oh1DHMrW51w4AW7SmHVbR/5AwzBwjEAUxggJAMIICPAIBATBQMDIxGzAZBgNVBAsT
Ek5vdmVsbCBFbXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQwIaAhQAAAAUNP1e8mQuJK2Q
mnfLPCP/cgICBOowCQYFKw4DAhoFAKCBxjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0wMDA1MTYwODQ3NDJaMCMGCSqGSIb3DQEJBDEWBBRVHLsLPCZqhAzmqr5BTa/b
IpHwhjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG
9w0DBDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjANBgkq
hkiG9w0BAQEFAASCAQB64+2SfezSjrKFORfzMK9/4aeGMgCKIm1onazscqCJ3aS4MLP3F8PT5NmE
9XC4/VKWOopbjl0kYewJ+TPVkYZd74yIO9lGpNBjGHav1kPh78Ue4jwEfWg4zvPIQHTVMP72+9+H
fN2Jp0mgCCD39xxQaq+kxCQ9tZUkPNKAl/gNJFZ4bdQcQxEZA9gcOGP43zuWMS2va1DoBMACOKt4
+ylKKM58kmRdH2Oh1Dj3KLZOihw96fNkAwHNwcBDsv7OoHegeK1yUmb1fs1tobY4syfEcW5AQfEz
SK5sZAqLcgkUomvnocTPHiFPlzrXIrNm8ykfsQBjbaa6jroEuGqGIuJN


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13176 for <[e-mail]>; Tue, 16 May 2000 07:00:19 -0700 (PDT)
Received: by balinese.baltimore.ie; id PAA14384; Tue, 16 May 2000 15:06:43 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma014376; Tue, 16 May 00 15:06:41 +0100
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA21395; Tue, 16 May 2000 15:06:41 +0100
Message-ID: <[e-mail]>
Date: Tue, 16 May 2000 15:07:13 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, xme <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-03
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

"Linn, John" wrote:
> 
> Stephen, re:
> 
> ...PKINIT...

So, we should keep the current text, but be ready to update the
reference? Good.

> Thanks.  Particularly for long-lived ACs, it seems to me that the same
> rationale (multiple revocation mechanisms) as contemplated for new-part1-01
> can apply here as well.  Generally, since usage practice for AC management
> is an early emerging area, I'm not sure that we've reached the best point to
> make informed restrictive judgments about which of the techniques defined
> for PKCs and ACs (in X.509) and PKCs (in new-part1-01) will be best
> applicable to ACs for the Internet.  As such, my inclination (here, as with
> some other comments) was towards flexibility.

Maybe I should ask the opposite questions: does anyone object
to including more than one AIA AccessDescription? Does anyone
object to including both AIA and CRLDP in an AC?

> > The intent is really that svceAuthInfo is usable to authenticate the
> > AC holder to some application "behind" the AC verifier, whereas,
> > accessIdentity is intended to be used for authorization purposes,
> > "by" the application that includes the AC verifier.
> 
> Is the central distinction actually (1) authentication vs. authorization, or
> (2) between the inclusion of (2a) information which is intended for
> interpretation and validation within the AC verifier vs. (2b) information
> which the AC verifier is expected to pass on for interpretation by some
> other element at the target system?  It seems more like (2) than (1) to me.
> For (2b), the AC is basically acting as a container for the attribute, with
> its contents' usage for authentication and/or authorization taking place
> outside the scope of target-side AC processing.

Fine. I've no problem adding the text below, including your mod to
the scveAuthInfo paragraph.

> > You're right that there is some potential for confusion here. Would
> > the following additional text help?
> >
> > In 4.4.1 (svceAuthInfo):
> >
> > "This attribute is intended to be used to provide
> > information, that can be used by the AC verifier (or a
> > larger system of which the AC veriifer is a component)
> > to authenticate the AC holder to another application.
> > Note that this is a different use to that intended for
> > the accessIdentity attribute in 4.4.2 below."
> 
> What about, "information, that can be presented by the AC verifier to be
> interpreted and authenticated by a separate application within the target
> system"?  If I'm understanding correctly above, it doesn't seem that the AC
> verifier is actually performing the authentication.
> 
> >
> > In 4.4.1 (accessIdentity):
> >
> > "This attribute is intended to be used to provide
> > information about the AC holder, that can be used
> > by the AC verifier (or a larger system of which the
> > AC veriifer is a component) to authorize the actions
> > of the AC holder within the AC verifier's system. Note
> > that this is a different use to that intended for
> > the svceAuthInfo attribute described in 4.4.1 above."
> 
> OK.
> 
> In the interests of conciseness here, I'll defer discussion of the role
> authority question to the separate subthread already opened on it.

Yep.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA12649 for <[e-mail]>; Tue, 16 May 2000 06:47:07 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 May 2000 13:49:16 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA28222; Tue, 16 May 2000 09:52:50 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <KVNJD1G8>; Tue, 16 May 2000 09:53:26 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-03
Date: Tue, 16 May 2000 09:53:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Stephen, re:

> > In Section 4.2, 1st paragraph, [PKINIT]'s CAT-WG Last-Call 
> is currently
> > pending on revisions to another document; it hasn't yet 
> been submitted to
> > the IESG.  Note that if AC509 reaches the RFC editor first, 
> it may find its
> > progress serialized on a normative reference.
> 
> Do you think we should wait on PKINIT or duplicate the definition
> of how to include a KerberosName into a GeneralName? The downside
> of the latter is that two specs. define the same OID 
> (krb5PrincipalName),
> which is ok so long as the OID doesn't change, but I'd rather refer
> to PKINIT so long as it won't cause a v. long hold. What's the likely
> downside of waiting on PKINIT? (i.e. what's it depend on, any idea
> of likely timing)

I agree with the merits of citing the definition if feasible, and thereby
avoiding the possibility of future divergence. PKINIT is targeted for WG
Last-Call along with Kerberos-Revisions (aka RFC1510bis).  Depending on
scheduling, this may happen either under the current CAT-WG umbrella or
under the auspices of a new WG being chartered specifically to pursue
Kerberos topics. In either case, I hope to see the pair of documents at the
WG Last-Call level in advance of the Pittsburgh meeting.

> 
> > 4.3.4, 1st paragraph: new-part1-01 allows a SEQUENCE OF 
> AccessDescription in
> > an AIA extension, which allows multiple access modes to be 
> specified for
> > revocation information and/or allows other CA-related 
> information to be
> > defined and accessed via AIA.  Why apply a tighter 
> constraint (single
> > AccessDescription only) for use of AIA in ACs?
> 
> I guess that was me trying to make the implementation easier, but I've
> no problem changing this if folks need more than one. What do others 
> think?

Thanks.  Particularly for long-lived ACs, it seems to me that the same
rationale (multiple revocation mechanisms) as contemplated for new-part1-01
can apply here as well.  Generally, since usage practice for AC management
is an early emerging area, I'm not sure that we've reached the best point to
make informed restrictive judgments about which of the techniques defined
for PKCs and ACs (in X.509) and PKCs (in new-part1-01) will be best
applicable to ACs for the Internet.  As such, my inclination (here, as with
some other comments) was towards flexibility. 

> 
> > 4.4.1 and 4.4.2: I'm confused about the relationship between Service
> > Authentication Information and Access Identity attributes.  
> Both are based
> > on the SvceAuthInfo structure, differing only in that 
> Access Identity
> > prohibits inclusion of its authInfo element.   If I'm 
> presenting only a
> > "service" and an "ident", is there any rationale for 
> deciding whether to do
> > so in a Service Authentication Information (omitting the 
> OPTIONAL authInfo)
> > or to do so in an Access Identity? As a verifier, should I 
> look equivalently
> > at both? 
> 
> The intent is really that svceAuthInfo is usable to authenticate the
> AC holder to some application "behind" the AC verifier, whereas, 
> accessIdentity is intended to be used for authorization purposes,
> "by" the application that includes the AC verifier.

Is the central distinction actually (1) authentication vs. authorization, or
(2) between the inclusion of (2a) information which is intended for
interpretation and validation within the AC verifier vs. (2b) information
which the AC verifier is expected to pass on for interpretation by some
other element at the target system?  It seems more like (2) than (1) to me.
For (2b), the AC is basically acting as a container for the attribute, with
its contents' usage for authentication and/or authorization taking place
outside the scope of target-side AC processing. 

> 
> You're right that there is some potential for confusion here. Would
> the following additional text help?
> 
> In 4.4.1 (svceAuthInfo):
> 
> "This attribute is intended to be used to provide 
> information, that can be used by the AC verifier (or a 
> larger system of which the AC veriifer is a component) 
> to authenticate the AC holder to another application.
> Note that this is a different use to that intended for
> the accessIdentity attribute in 4.4.2 below."

What about, "information, that can be presented by the AC verifier to be
interpreted and authenticated by a separate application within the target
system"?  If I'm understanding correctly above, it doesn't seem that the AC
verifier is actually performing the authentication. 

> 
> In 4.4.1 (accessIdentity):
> 
> "This attribute is intended to be used to provide
> information about the AC holder, that can be used
> by the AC verifier (or a larger system of which the 
> AC veriifer is a component) to authorize the actions 
> of the AC holder within the AC verifier's system. Note 
> that this is a different use to that intended for 
> the svceAuthInfo attribute described in 4.4.1 above."

OK. 

In the interests of conciseness here, I'll defer discussion of the role
authority question to the separate subthread already opened on it. 

--jl




Received: from shym.com (smtp.shym.com [208.247.128.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11537 for <[e-mail]>; Tue, 16 May 2000 06:10:57 -0700 (PDT)
Received: from destroyer (gatekeeper.shym.com [208.247.128.2]) by shym.com (8.9.0/8.9.0) with SMTP id JAA29990 for <[e-mail]>; Tue, 16 May 2000 09:16:56 -0400 (EDT)
From: "Scott J. Tamosunas" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Tue, 16 May 2000 09:17:21 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

unsubscribe


Received: from mail.siol.net (odin.siol.net [193.189.160.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11295 for <[e-mail]>; Tue, 16 May 2000 06:09:07 -0700 (PDT)
Received: from intergalactic ([213.250.43.61]) by mail.siol.net (InterMail vK.4.02.00.10 201-232-116-110 license def7f3c1ccee590d715bf25c5fe4cbb9) with SMTP id <20000516131535.JTQB14024.mail@intergalactic> for <[e-mail]>; Tue, 16 May 2000 15:15:35 +0200
From: "denis bider" <[e-mail]>
To: <[e-mail]>
Subject: RFC 2511: PKIArchiveOptions encoding?
Date: Tue, 16 May 2000 15:15:57 +0200
Message-ID: <000001bfbf38$dff71910$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

Hello,

I am reading RFC 2511 and trying to understand how to properly parse the
PKIArchiveOptions choice field. For your convenience, I am attaching the
relevant ASN.1 definitions at the end of this message.

PKIArchiveOptions is a CHOICE with three possible value types, each of which
is implicitly tagged ([0], [1], [2]). Now, the problem is, the first one of
these types, [0] EncryptedKey, is a CHOICE as well. Now, EncryptedKey has
two possible value types with two possible tags among them. One possibility,
EnvelopedData, has an implicit tag of [0], and the other one,
EncryptedValue, is a SEQUENCE.

My question is - how does this fit together? I see two possibilities:
  - The clean one: the EncryptedKey type within PKIArchiveOptions is
actually not implicitly tagged, but rather is explicitly tagged, because it
is a CHOICE within a CHOICE. However, this fact is not stated in the ASN.1
definition because there is some clause in the ASN.1 specification that
already says that this applies in such cases. (Unfortunately, I do not have
access to such an ASN.1 specification.)
  - The dirty one: the EncryptedKey type within PKIArchiveOptoins is indeed
implicitly tagged. Therefore, it actually has two possible tags: [0] if the
sub-type being used is EnvelopedData, and SEQUENCE if the sub-type being
used is EncryptedValue.

Is there someone here who would care to point me in the right direction?

Also, I would be glad if someone could enumerate some real-world
implementations of RFC 2511; it would be great if I could test my
implementation against others that are already proven.

Note: I tried searching the archives, but the archive site turned out to be
rather useless. The only feasible way to search the archives is to scan the
subject lines, which are on 13 different pages, for keywords that one might
only hope will appear in the subject of a related message. The only
alternative is to download the entire archive file and search that file with
one's favourite tools. However, at a file size of 16 MB and a throughput of
10KB per second this is not a very appealing alternative.

Kind regards,

denis bider



Some relevant ASN.1 definitions:

PKIArchiveOptions ::= CHOICE {
      encryptedPrivKey     [0] EncryptedKey,
      -- the actual value of the private key
      keyGenParameters     [1] KeyGenParameters,
      -- parameters which allow the private key to be re-generated
      archiveRemGenPrivKey [2] BOOLEAN }
      -- set to TRUE if sender wishes receiver to archive the private
      -- key of a key pair which the receiver generates in response to
      -- this request; set to FALSE if no archival is desired.

EncryptedKey ::= CHOICE {
      encryptedValue        EncryptedValue,
      envelopedData     [0] EnvelopedData }
      -- The encrypted private key MUST be placed in the envelopedData
      -- encryptedContentInfo encryptedContent OCTET STRING.

EncryptedValue ::= SEQUENCE {
   ...
}




Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA08135 for <[e-mail]>; Tue, 16 May 2000 05:18:01 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Tue, 16 May 2000 13:17:03 +0100
Received: from taalap (taa-lap.sse.ie [193.120.32.86]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id NAA15770; Tue, 16 May 2000 13:16:44 +0100 (BST)
Message-ID: <000f01bfbf30$9342d7b0$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: <[e-mail]>, "Linn, John" <[e-mail]>
Cc: <[e-mail]>, "RussHousley" <[e-mail]>, "xme" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-03
Date: Tue, 16 May 2000 13:16:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

Hi all,

some comments regarding the PolicyAuthority:

> Possible fixes are:
>
> 1. add back the role attribute with IetfAttrSyntax and delete
>    the role with RoleSyntax
> 2. add back the role attribute with IetfAttrSyntax and leave in
>    the role with RoleSyntax, and say that if you want
>    policyAuthority information use the one with IetfAttrSyntax
> 3. use the RoleSyntax.roleAuthority field in a way that doesn't
>    fit with X.509
> 4. define a method for including the policyAuthority in a http
>    URL in the RoleSyntax.roleName field, e.g.
>    "http://[[<host>][:<port>]]/<role>[?pa=<policy-authority>]"
>    and recommend that a (human readable) description of the
>    role be made available at that URL if a host:port are
>    present.
> 5. Like 3, but define a new uri scheme, e.g.
>    "pkixrole:///<role>[/<policy-authority>]
>
> I'd go for 4, anyone else?

If we do go for either 4 or 5, we'll need a standardised and "human
readable"
form of GeneralNames (which is what IETFAttrSyntax uses for the P.A.) in
order
to achieve the same level of flexibility with regard to naming a P.A.

For example, let's suppose that we restrict our P.A. to a *single*
GeneralName
for encoding simplicity:

The PA could be represented in the URL using the string representation
of GeneralName from the PKIX group:

http://manager?pa=directory: C=IE, O=SSE, CN=PA1   (Option 4)
pkixrole://manager/directory: C=IE, O=SSE, CN=PA1   (Option 5)

One question here would be how to handle spacing, etc.
Will we permit spaces in this, or would we have to use the %HEX encoding
scheme used on the web. If we do have to decode the hexes, this seems like
a lot of overhead for decoding a simple PA GeneralNames. :-(

Given such an encoding/decoding overhead, I'd be more inclined to go for 2.

Any comments, folks?

Andy



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA04242 for <[e-mail]>; Tue, 16 May 2000 04:05:10 -0700 (PDT)
Received: by balinese.baltimore.ie; id MAA20523; Tue, 16 May 2000 12:11:34 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma020481; Tue, 16 May 00 12:11:13 +0100
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA11699; Tue, 16 May 2000 12:11:09 +0100
Message-ID: <[e-mail]>
Date: Tue, 16 May 2000 12:11:41 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, RussHousley <[e-mail]>, xme <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-03
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi John,

> In Section 4.2, 1st paragraph, [PKINIT]'s CAT-WG Last-Call is currently
> pending on revisions to another document; it hasn't yet been submitted to
> the IESG.  Note that if AC509 reaches the RFC editor first, it may find its
> progress serialized on a normative reference.

Do you think we should wait on PKINIT or duplicate the definition
of how to include a KerberosName into a GeneralName? The downside
of the latter is that two specs. define the same OID (krb5PrincipalName),
which is ok so long as the OID doesn't change, but I'd rather refer
to PKINIT so long as it won't cause a v. long hold. What's the likely
downside of waiting on PKINIT? (i.e. what's it depend on, any idea
of likely timing)

> 4.2.6, 2nd line: suggest changing "period for which the AC issuer expects"
> to "period for which the AC issuer certifies". 

Fine.

> 4.3.4, 1st paragraph: new-part1-01 allows a SEQUENCE OF AccessDescription in
> an AIA extension, which allows multiple access modes to be specified for
> revocation information and/or allows other CA-related information to be
> defined and accessed via AIA.  Why apply a tighter constraint (single
> AccessDescription only) for use of AIA in ACs?

I guess that was me trying to make the implementation easier, but I've
no problem changing this if folks need more than one. What do others 
think?

> 4.4.1 and 4.4.2: I'm confused about the relationship between Service
> Authentication Information and Access Identity attributes.  Both are based
> on the SvceAuthInfo structure, differing only in that Access Identity
> prohibits inclusion of its authInfo element.   If I'm presenting only a
> "service" and an "ident", is there any rationale for deciding whether to do
> so in a Service Authentication Information (omitting the OPTIONAL authInfo)
> or to do so in an Access Identity? As a verifier, should I look equivalently
> at both? 

The intent is really that svceAuthInfo is usable to authenticate the
AC holder to some application "behind" the AC verifier, whereas, 
accessIdentity is intended to be used for authorization purposes,
"by" the application that includes the AC verifier.

You're right that there is some potential for confusion here. Would
the following additional text help?

In 4.4.1 (svceAuthInfo):

"This attribute is intended to be used to provide 
information, that can be used by the AC verifier (or a 
larger system of which the AC veriifer is a component) 
to authenticate the AC holder to another application.
Note that this is a different use to that intended for
the accessIdentity attribute in 4.4.2 below."

In 4.4.1 (accessIdentity):

"This attribute is intended to be used to provide
information about the AC holder, that can be used
by the AC verifier (or a larger system of which the 
AC veriifer is a component) to authorize the actions 
of the AC holder within the AC verifier's system. Note 
that this is a different use to that intended for 
the svceAuthInfo attribute described in 4.4.1 above."

> Is it valid to present both Service Authentication Information and
> Access Identity in a single AC and, if so, are their corresponding elements
> expected to match?

It is valid to hold an AC containing both attributes, and of course, each
may be multivalued, so there is no implication of any matching between
the values, even if the service field has the same value. Its really
up to the AC verifier to handle this (and the AC issuer not to issue
nonsense ACs!).

> 4.4.5: Reconsidering the list exchange about prohibiting roleAuthority
> because of its X.509 association with role specification certificates, its
> prohibition apparently implies that the authority responsible for a role
> assignment must always be the AC issuer itself.  This seems to conflict with
> requirement 4 under Attribute Types in Section 3.  Do we have a rationale
> for requiring authority qualification more strongly for groups than for
> roles, or if not do we need another means to represent roles' associated
> authorities?

You're right about this, I guess its a side-effect of using
the X.509 role attribute that slipped in:-(

Possible fixes are:

1. add back the role attribute with IetfAttrSyntax and delete 
   the role with RoleSyntax
2. add back the role attribute with IetfAttrSyntax and leave in
   the role with RoleSyntax, and say that if you want 
   policyAuthority information use the one with IetfAttrSyntax
3. use the RoleSyntax.roleAuthority field in a way that doesn't
   fit with X.509 
4. define a method for including the policyAuthority in a http
   URL in the RoleSyntax.roleName field, e.g. 
   "http://[[<host>][:<port>]]/<role>[?pa=<policy-authority>]"
   and recommend that a (human readable) description of the
   role be made available at that URL if a host:port are
   present.
5. Like 3, but define a new uri scheme, e.g. 
   "pkixrole:///<role>[/<policy-authority>]

I'd go for 4, anyone else?

> Sec. 5, first numbered list, item 6: I believe that this profile shouldn't
> preclude acceptance of ACs bearing critical extensions which are recognized
> by the verifier even if those extensions are defined in other documents.

Fine.
 
> Sec. 6, penultimate paragraph: I can see why noRevAvail wouldn't coexist
> with other revocation-related extensions, but what's the rationale for
> diverging from new-part1-01 and prohibiting use of multiple revocation
> facilities for an AC?

I guess my response is the same as to your comment on 4.3.4: simplicity
for the implementor, and as above, I'm ok with changing it if folks want
that.

BTW: As an aside, is the relying party behaviour when faced with a 
cert (PKC or AC) containing many sources of revocation status well 
defined? 

> Editorial:
> 
> 4.3.4, 5th paragraph, last line: "administrator identify" -> "administrator
> to identify".
> 
> 7.1, 5th para, 3rd line: "attribue" -> "attribute".
> 
> Sec. 8, 6th para: "issued to the AC issuer" -> "issued by the AC issuer"?
> 
> Sec. 8, 2nd para, 3rd line: "issuer's" -> "issuers".
> 
> Sec. 8, penultimate para, penultimate line: "AC verified trusts" -> "AC
> verifier trusts".

Ta,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA16768 for <[e-mail]>; Mon, 15 May 2000 23:46:22 -0700 (PDT)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A013B850152; Tue, 16 May 2000 08:52:03 +0200
Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Di, 16 Mai 2000 08:52:50 +0100
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: announce: xmlcert discussion list
Date: Tue, 16 May 2000 08:52:49 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.018ED18F--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.018ED18F--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

folks,

In a discussion on the XML-DSig mailing list, it was suggested to consider
representing (X-509?)-certificates in XML as an IETF/W3C-activity. To find
out about the general interest in and potential support for such an
activity, we set up a mailing-list to discuss this. You are invited to
subscribe to this list by sending a message to [e-mail], which
contains

subscribe xmlcert <your name>

in the body of the message.  Contributions can then be sent to
[e-mail], archives are available at
http://jcewww.iaik.at/mailarchive/xmlcert/xmlthreads.html.

Peter

______________________________________
Dr. Peter Lipp
IAIK, TU Graz
Inffeldgasse 16a, A-8010 Graz, Austria
Tel: [phone]
Fax: [phone]
Web: www.iaik.at




----IAIK.SMIME.MAPPER.018ED18F--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy
ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV
BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ
xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk
PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX
yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w
LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR
BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh
dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw
QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC
2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq
FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr
oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9
ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi
KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy
2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB
VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X
DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP
MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk
Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H
WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv
Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO
RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg
ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI
AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk
SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q
SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT
FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL
CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE
6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n
vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx
2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7
rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t
sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu
dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8
lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx
CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P
TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g
UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U
UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG
A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ
MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j
ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F
VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk
fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x
LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R
X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV
Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB
AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE
tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3
DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s
hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI
7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af
EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s
PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ
xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG
BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD
VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H
UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg
Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh
dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg
VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew
HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG
9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX
ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6
Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25
sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu
YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB
hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA
MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF
Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD
ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9
l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q
19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6
ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M
HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG
BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV
BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1
OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT
BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog
VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig
QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u
czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H
UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a
SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy
qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg
o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B
2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1
2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj
MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE
AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP
hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C
uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64
vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL
CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq
E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw
ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME
R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS
QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wMDA1MTYwNjUyNTBaMCMGCSqGSIb3DQEJBDEWBBSTlBo1IMHWIVH4
ZeDdGjKJeUOYVzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN
BgkqhkiG9w0BAQEFAASBgB+bJYR5lBq5/b+8wMhk3lyR3O0Lp7nHrRvwNYVXj+hV
pjuyyugODAycLy9s5Wj3740qHDAaJv0zTPrx7uLs3g5POobO4QtlNsq3aGteWthj
2/ywI3h8v1FVwGEOlGavsMst5w4nhefG2Ldm0By2AscLB0JcMJIP9CB0++BF0UcS
AAAAAAAA
----IAIK.SMIME.MAPPER.018ED18F----



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07505 for <[e-mail]>; Mon, 15 May 2000 21:40:10 -0700 (PDT)
Received: from [128.33.238.53] (TC084.BBN.COM [128.33.238.84]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id AAA16674; Tue, 16 May 2000 00:46:32 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220810b546822bbb03@[128.33.238.53]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 16 May 2000 00:45:40 -0400
To: Robert Moskowitz <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

The underlying assumption is that the CA is vouching for the accuracy 
of ALL data in a certificate.  A syntax check is NOT what one would 
expect. yes, the CPS may hedge on how good a check the CA does, but 
there IS a presumption that the CA has made some effort to verify the 
info.  We long ago debated this issue; some folks wanted to have a 
flag for a CA to set to indicate the presence of non-verified data. 
We rejected that approach.

Steve


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06051 for <[e-mail]>; Mon, 15 May 2000 15:44:47 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <KZ4LHBSS>; Mon, 15 May 2000 15:46:49 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Thierry Van Doninck'" <[e-mail]>, ietf-pkix <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Mon, 15 May 2000 15:46:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"

http://support.microsoft.com/support/exchange/content/whitepapers/win2k_kms.
doc

Thierry,

I disagree with Phil. I personally measure the state
of open-ness of the actual PKIX industry in the US by the work
that Microsoft does in X.509. Determining open standards adoption 
and interoperability over time is an important element of 
standards making and national infrastructure(s) planning, in my 
perhaps simplistic view.

http://www.microsoft.com/Exchange/55/gen/compare.htm
is a (Microsoft-marketing) comparison of Exchange
and PKI with competitive products that include PKI. The
link give a glimpse of reality of PKIX in average
enterprise mail products.

Some other URLs discussing important aspects
of S/MIME integration into commercial-grade
internet environments:

Beyond S/MIME and onto X.400 secure stacks/networks:
http://www.microsoft.com/exchange/55/gen/Security.htm

A Lotus study of PKI and S/MIME deployment - for Identrus banks:
http://www.lotus.com/99/session.nsf/187801dd8d07636a8525677d005a4ac8/78888aa
0af9ec29b8525684e0079a8d3

A Study of Novell's integration with the world-class Entrust solution.

http://support.novell.com/cgi-bin/search/search.pl?database_name=kb&type=HTM
L&docid=%03%1fF170985%3a958429713%3a%20%28%20S%2fMIME%20%29%20%20%07%01%00&b
yte_count=4399

If you add Netscape Certificate Server and RSA Keon/VeriSign to 
the analysis, we have moved quite a long way in the US from the 
PEM days.

Peter.

-----Original Message-----
From: Philip Hallam-Baker [mailto:[e-mail]]
Sent: Monday, May 15, 2000 6:05 AM
To: 'Thierry Van Doninck'; ietf-pkix
Subject: RE: Does Smime works fine with Windows 2000 PKI


Same answer, ask Microsoft, not an IETF development list.


-----Original Message-----
From: Thierry Van Doninck [mailto:[e-mail]]
Sent: Thursday, May 11, 2000 7:40 AM
To: ietf-pkix
Subject: Does Smime works fine with Windows 2000 PKI


Hi,

Same message as on the smime mailing list.
Has any of you good people any info on Windows 2000 PKI ?

Thanks,

Thierry

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

Hi everybody,

Just a question :

Is there any known issues using S/MIME with Win2000PKI-certificates ?
More generally, are Win2000 certificates usable with (and understood by
) the others mailers (especially Lotus Notes, Netscape, Eudora
+plug-in?)

Isn't Baltimore Unicert a "better choice" due to its greater
compatibility ?

Any advices are welcome.

Regards,

Laurent Deffranne


Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA03328 for <[e-mail]>; Mon, 15 May 2000 13:38:20 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 May 2000 20:40:26 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA29793 for <[e-mail]>; Mon, 15 May 2000 16:44:09 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <KVNJC806>; Mon, 15 May 2000 16:44:44 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Comments on draft-ietf-pkix-ac509prof-03
Date: Mon, 15 May 2000 16:44:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

I'd like to offer some Last-Call comments and questions on
draft-ietf-pkix-ac509prof-03.txt. 

Specifics:

In Section 4.2, 1st paragraph, [PKINIT]'s CAT-WG Last-Call is currently
pending on revisions to another document; it hasn't yet been submitted to
the IESG.  Note that if AC509 reaches the RFC editor first, it may find its
progress serialized on a normative reference. 

4.2.6, 2nd line: suggest changing "period for which the AC issuer expects"
to "period for which the AC issuer certifies". It's quite probable that
bindings to attributes will remain valid (and, hence, recertified) across
the lifetimes of many successive short-lived ACs, and that the AC issuer
will have no reason to expect otherwise at the point when an AC is issued.
If a change occurs within an AC's validity period, then revocation can be
applied if available; if not, the attributes' certification remains
inextricably valid until the validity period expires. 

4.3.4, 1st paragraph: new-part1-01 allows a SEQUENCE OF AccessDescription in
an AIA extension, which allows multiple access modes to be specified for
revocation information and/or allows other CA-related information to be
defined and accessed via AIA.  Why apply a tighter constraint (single
AccessDescription only) for use of AIA in ACs?

4.4.1 and 4.4.2: I'm confused about the relationship between Service
Authentication Information and Access Identity attributes.  Both are based
on the SvceAuthInfo structure, differing only in that Access Identity
prohibits inclusion of its authInfo element.   If I'm presenting only a
"service" and an "ident", is there any rationale for deciding whether to do
so in a Service Authentication Information (omitting the OPTIONAL authInfo)
or to do so in an Access Identity? As a verifier, should I look equivalently
at both? Is it valid to present both Service Authentication Information and
Access Identity in a single AC and, if so, are their corresponding elements
expected to match?

4.4.5: Reconsidering the list exchange about prohibiting roleAuthority
because of its X.509 association with role specification certificates, its
prohibition apparently implies that the authority responsible for a role
assignment must always be the AC issuer itself.  This seems to conflict with
requirement 4 under Attribute Types in Section 3.  Do we have a rationale
for requiring authority qualification more strongly for groups than for
roles, or if not do we need another means to represent roles' associated
authorities?

Sec. 5, first numbered list, item 6: I believe that this profile shouldn't
preclude acceptance of ACs bearing critical extensions which are recognized
by the verifier even if those extensions are defined in other documents. 

Sec. 6, penultimate paragraph: I can see why noRevAvail wouldn't coexist
with other revocation-related extensions, but what's the rationale for
diverging from new-part1-01 and prohibiting use of multiple revocation
facilities for an AC?  

Editorial:

4.3.4, 5th paragraph, last line: "administrator identify" -> "administrator
to identify". 

7.1, 5th para, 3rd line: "attribue" -> "attribute". 

Sec. 8, 6th para: "issued to the AC issuer" -> "issued by the AC issuer"?

Sec. 8, 2nd para, 3rd line: "issuer's" -> "issuers".

Sec. 8, penultimate para, penultimate line: "AC verified trusts" -> "AC
verifier trusts". 

--jl




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02376 for <[e-mail]>; Mon, 15 May 2000 12:49:04 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQipid15689; Mon, 15 May 2000 19:55:23 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27299; Mon, 15 May 00 15:51:59 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA24414; Mon, 15 May 2000 15:55:18 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Mon, 15 May 2000 15:55:17 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: SubjectAltName verification
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "tgindin" == tgindin  <[e-mail]> writes:

 tgindin> Existence of an IP address, DNS name or E-Mail address is
 tgindin> probably the wrong check for a CA to perform anyway.  The
 tgindin> worst problem related to this would occur if I were to get a
 tgindin> certificate with a subjectAltName containing somebody else's
 tgindin> valid E-Mail address, rather than if I got
 tgindin> "[e-mail]".

Right.

How bad that is depends on what assumptions the relying party makes.
If he interprets the RFC text in the intuitively obvious way, that
could be quite nasty, because "definitively bound" and "verified" have
intuitive meanings that are rather strong.

If he read what Robert wrote and mentally substituted "the
subjectAltName doesn't have any particular meaning and nothing
significant is guaranteed about it" then of course there probably is
no problem.

But if that's what is meant, the RFC should be corrected to say so.
Right now, it sounds like the plain meaning of the words does not even
come close to reality, which is a Bad Thing.

    paul


Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02109 for <[e-mail]>; Mon, 15 May 2000 12:42:48 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA123700; Mon, 15 May 2000 15:47:30 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id PAA27692; Mon, 15 May 2000 15:49:09 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568E0.006CDD55 ; Mon, 15 May 2000 15:49:05 -0400
X-Lotus-FromDomain: IBMUS
To: Robert Moskowitz <[e-mail]>
cc: "Martin Szotkowski" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 15 May 2000 15:48:55 -0400
Subject: Re: SubjectAltName verification
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Existence of an IP address, DNS name or E-Mail address is probably the
wrong check for a CA to perform anyway.  The worst problem related to this
would occur if I were to get a certificate with a subjectAltName containing
somebody else's valid E-Mail address, rather than if I got
"[e-mail]".

          Tom Gindin

Robert Moskowitz <[e-mail]> on 05/15/2000 02:09:10 PM

To:   "Martin Szotkowski" <[e-mail]>, <[e-mail]>
cc:
Subject:  Re: SubjectAltName verification



At 07:27 PM 5/9/2000 +0200, Martin Szotkowski wrote:
>Hi all,
>in RFC2459 (4.2.1.7) call :
> >>Because the subject alternative name is considered to be definitively
>bound to the publick key, all parts of the subject alternative name MUST
be
>verified by the CA.<<
>What exactly this means?

IMHO, this can only mean that the CA verifies that the content of
SubjectAltName follows the formatting rules of the CHOICE.  That is if
rfc822Name is used, then the rules of RFC 822 are followed.  If dNSName is
used, than RFC 1035.  etc.

These cannot be requied to be real values, that is some SMTP server respond
with an IDENT for the email and some DNS respond to a query.

WHY?

The mail or DNS server might be internal and unreachable to the CA.

IPsec looks at these as simple labeling formats.  This is particularly true
for dNSName for gateways on DSL models (ie 'mobile' gateways).


>Must be e.g. email unique in one CA? must be unique for one man?
>If yes, is there any way to determine that this man has this email? (How
>this problem is resolving for DNS, IP, URI, etc.?)
>If no, someone can stand out for some else in email communication?
>
>thanks for explanation
>Martin
>

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]






Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01572 for <[e-mail]>; Mon, 15 May 2000 12:17:36 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0432030cb545fd09e98b@[165.227.249.13]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 15 May 2000 12:24:01 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: SubjectAltName verification
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 3:05 PM -0400 5/15/00, Robert Moskowitz wrote:
>At 02:50 PM 5/15/2000 -0400, Al Arsenault wrote:
>>I have to disagree with Bob on this.

Me too. "definitively bound" seems to be very, well, definitive.

>What are we going to use as the SubjectAltName in your Netopia box 
>on your DSL line in your house, Al?

I'm not Al, but I will answer: anything the CA wants. There are a 
variety of identifiers that a CA can use for the end entity. The CA 
should obviously use an identifier that the desired relying parties 
want to use.

>   Shouldn't be YOUR email address, Al.  What FQDN?  Remember there 
>is no static IP address for you, everytime you boot the Netopia, it 
>can get a new IP address from the ISP.

That doesn't mean that there is no FQDN that will map to your router. 
Your ISP might (should?) be using DHCP with dynamic DNS that updates 
the FQDN each time the IP address changes. These have been around for 
years and have been shown to be interoperable.

>Taking the FQDN further, these are internal boxes, getting a third 
>party cert.  The CA cannot do a DNS query on the internal DNS server.

Then the CA should not issue a cert using those types of identifiers. 
There are lots of other choices for types of identifiers, some of 
which might be appropriate for relying parties. If not, well, then 
there's no way for someone to identify the box in a cert.

>This all comes down to the CP and CPS.  Here is where is stated the 
>method use to establish the content of SubjectAltName.

If the CPS says "I didn't check the binding between the ID and the 
public key" or "I checked it at the time of issuing but you probably 
won't be able to check it now", I would argue that no one should rely 
on that certificate.

>   Now it would be really nice if there were a KEYNOTE object in the 
>cert that would express the method of validation...

That won't help if there is no way to come up with a useful identity 
for the relying party.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA01011 for <[e-mail]>; Mon, 15 May 2000 11:59:06 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Mon, 15 May 2000 15:05:43 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 15 May 2000 15:05:25 -0400
To: Al Arsenault <[e-mail]>, "'Paul Koning'" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: SubjectAltName verification
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:50 PM 5/15/2000 -0400, Al Arsenault wrote:
>I have to disagree with Bob on this. To me, the words imply what they say -
>that if the CA is going to issue a certificate that says that my
>subjectAltName of the form rfc822Name is "[e-mail]", the CA
>must have taken some steps to verify that that is indeed the case.  (e.g.,
>the CA could have a notarized letter from the authority responsible for
>assigning those e-mail addresses.)  To do otherwise is false or misleading
>behavior on the part of the CA.

First question:

What are we going to use as the SubjectAltName in your Netopia box on your 
DSL line in your house, Al?  Shouldn't be YOUR email address, Al.  What 
FQDN?  Remember there is no static IP address for you, everytime you boot 
the Netopia, it can get a new IP address from the ISP.

Taking the FQDN further, these are internal boxes, getting a third party 
cert.  The CA cannot do a DNS query on the internal DNS server.

This all comes down to the CP and CPS.  Here is where is stated the method 
use to establish the content of SubjectAltName.  Now it would be really 
nice if there were a KEYNOTE object in the cert that would express the 
method of validation...



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from dvnet2.dvnet.com ([209.121.31.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00448 for <[e-mail]>; Mon, 15 May 2000 11:44:32 -0700 (PDT)
Received: from CC787228-A ([10.11.12.231]) by dvnet2.dvnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id K4M6WMC8; Mon, 15 May 2000 14:55:29 -0400
Received: by localhost with Microsoft MAPI; Mon, 15 May 2000 14:50:34 -0400
Message-ID: <[e-mail]>
From: Al Arsenault <[e-mail]>
To: "'Paul Koning'" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: SubjectAltName verification
Date: Mon, 15 May 2000 14:50:33 -0400
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Encoding: 50 TEXT

I have to disagree with Bob on this. To me, the words imply what they say - 
that if the CA is going to issue a certificate that says that my 
subjectAltName of the form rfc822Name is "[e-mail]", the CA 
must have taken some steps to verify that that is indeed the case.  (e.g., 
the CA could have a notarized letter from the authority responsible for 
assigning those e-mail addresses.)  To do otherwise is false or misleading 
behavior on the part of the CA.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.



-----Original Message-----
From:	Paul Koning [SMTP:[e-mail]]
Sent:	Monday, May 15, 2000 2:22 PM
To:	[e-mail]
Cc:	[e-mail]; [e-mail]
Subject:	Re: SubjectAltName verification

>>>>> "Robert" == Robert Moskowitz <[e-mail]> writes:

 Robert> At 07:27 PM 5/9/2000 +0200, Martin Szotkowski wrote:
 >> Hi all, in RFC2459 (4.2.1.7) call : >>Because the subject
 >> alternative name is considered to be definitively bound to the
 >> publick key, all parts of the subject alternative name MUST be
 >> verified by the CA.<< What exactly this means?

 Robert> IMHO, this can only mean that the CA verifies that the
 Robert> content of SubjectAltName follows the formatting rules of the
 Robert> CHOICE.  That is if rfc822Name is used, then the rules of RFC
 Robert> 822 are followed.  If dNSName is used, than RFC 1035.  etc.

 Robert> These cannot be requied to be real values, that is some SMTP
 Robert> server respond with an IDENT for the email and some DNS
 Robert> respond to a query.

 Robert> WHY?

 Robert> The mail or DNS server might be internal and unreachable to
 Robert> the CA.

It may well be that it's hard or impossible to do more.

But this is NOT what the words quoted would suggest, not at all.
"Definitively bound to" and "verified" does not intuitively translate
to a mere syntax check.

   paul



Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00278 for <[e-mail]>; Mon, 15 May 2000 11:43:13 -0700 (PDT)
Received: from [38.29.122.207] (ip171.phoenix11.az.pub-ip.psi.net [38.29.123.171]) by goose.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id LAA27243 for <[e-mail]>; Mon, 15 May 2000 11:49:36 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a0431010ab545f6386ac7@[38.29.122.207]>
Date: Mon, 15 May 2000 11:47:36 -0700
To: [e-mail]
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: plain text version of RE: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2459)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

i misclicked on my previous message and sent out styled text in my 
message. that has caused problems for some of you. here is the 
message in plain text

I sent out an email on this subject to this list some time ago. We 
did raise a defect, 220, on this issue and have a approved a 
Technical Corrigendum, 3. to the 3rd edition, 97, X.509 as follows

This corrects the defects reported in defect reports 9594/220.
Clause 11.2 note 3
In Note 3, in the second sentence replace "shall be absent" with "may 
be absent".

In Note 3, at the beginning of the 3rd sentence, replace "This may 
permit"  with "If version is absent, this may permit"

In Note 3, at the beginning of  the 4th sentence, replace "An 
implementation that supports version 2 (or greater) CRLs may" with 
"An implementation that supports version 2 (or greater) CRLs, in the 
absence of version, may also" 

This allows PKIX implementors to be conformant to the 97 edition

I wasn't too happy that this nuance was not understood by PKIX (it 
was first described as an X.509 error on this list) since I wrote the 
original text with a goal of interoperability. However, I understood 
that to many on this list interoperation with version 1 systems was 
not necessary. There I proposed, and the group agreed, that the shall 
be soften to a may.

This allows the PKIX group to decide what its interoperability 
requirement is. After some pondering I now believe this is the proper 
approach for the standard and have taken this approach for several 
enhancements that we added for the 4th edition.

    hoyt




>From: Warwick Ford <[e-mail]>
>To: "'Sam Schaen'" <[e-mail]>,
>         Ismo Heikkonen
>	<[e-mail]>
>Cc: [e-mail]
>Subject: RE: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2
>	459)
>Date: Mon, 15 May 2000 07:35:15 -0700
>List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
>List-ID: <ietf-pkix.imc.org>
>List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
>
>The intent was as follows. A V1 CRL interpreter should correctly process a
>CRL with extensions but with no version number -- it will ignore the
>extensions entirely, under the X.500 rules of extensibility (which is OK,
>provided no extensions are critical).  However, if a version number is
>present, a V1 CRL interpreter will break, since the version field
>contravenes the extensibility rule -- deliberately, so as to ensure critical
>extensions don't slip through unnoticed.  Therefore, there is a legitimate
>reason for permitting CRLs with noncritical extensions but no version
>number.
>
>X.509 97 probably went too far in *requiring* that configuration, and you
>will note that X.509 2000 pulled that back and made it optional. This seems
>the right thing to me, for the base standard.
>
>This opens the way for PKIX to profile the version as mandatory against the
>2000 standard, although no PKIX CRL will ever work with a V1 CRL
>interpreting product (is this important?). Also, as you point out, you
>cannot be consistent with both X.509 97 and PKIX, but that is probably not
>very important given the change in 2000.
>
>Warwick
>
>-----Original Message-----
>From: Sam Schaen [mailto:[e-mail]]
>Sent: Monday, May 15, 2000 6:02 AM
>To: Ismo Heikkonen
>Cc: [e-mail]
>Subject: Re: Inconsistency between X.509-97 and RFC 2459 (and son of RFC
>2459)
>
>
>We stumbled across this inconsistency while working on the US DOD PKI
>profile.  We elected to go with the RFC 2459 interpretation.  It seems
>to make more sense, since a version 1 CRL interpreter would not
>understand extensions at all.
>
>Sam Schaen
>MITRE
>
>Ismo Heikkonen wrote:
>>
>>  Hi,
>>  it seems to me that there is an inconsistencty between X.509-97 and RFC
>2459 (and also son of RFC2459).
>>
>>  In X.509 , in section 11.2  there is the following note just after the CRL
>definition:
>>
>>  "3 If any extensions included in a CertificateList are defined as
>critical, the version element of the CertificateList shall be present.  If
>no extensions defined as critical are included, the version element shall be
>absent. This ..."
>>
>>  But RFC 2459 requires that version shall be present always when the
>  > extensions are included:
>>  "5.1.2.1  Version
>>
>>     This optional field describes the version of the encoded CRL.  When
>>     extensions are used, as required by this profile, this field MUST be
>>     present and MUST specify version 2 (the integer value is 1)."
>>
>>  This means that I can not create CRLs which do not include any critical
>extensions so
>>  that they would be compatible with both X.509-97 and RFC 2459.
>>  Or are there any X.509 Defect reports available around this topic?
>>
>>  By the way  X.509 -2000 seems to be more flexible in this sense.
>>
>>  Ismo Heikkonen
>>  Sonera SmartTrust Ltd



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29480 for <[e-mail]>; Mon, 15 May 2000 11:15:44 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiphx07399; Mon, 15 May 2000 18:22:07 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA25712; Mon, 15 May 00 14:18:43 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA24344; Mon, 15 May 2000 14:22:06 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Mon, 15 May 2000 14:22:06 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: SubjectAltName verification
References: <061e01bfb9db$d2f7ba10$0c7011ac@SZOTKOWSKI> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Robert" == Robert Moskowitz <[e-mail]> writes:

 Robert> At 07:27 PM 5/9/2000 +0200, Martin Szotkowski wrote:
 >> Hi all, in RFC2459 (4.2.1.7) call : >>Because the subject
 >> alternative name is considered to be definitively bound to the
 >> publick key, all parts of the subject alternative name MUST be
 >> verified by the CA.<< What exactly this means?

 Robert> IMHO, this can only mean that the CA verifies that the
 Robert> content of SubjectAltName follows the formatting rules of the
 Robert> CHOICE.  That is if rfc822Name is used, then the rules of RFC
 Robert> 822 are followed.  If dNSName is used, than RFC 1035.  etc.

 Robert> These cannot be requied to be real values, that is some SMTP
 Robert> server respond with an IDENT for the email and some DNS
 Robert> respond to a query.

 Robert> WHY?

 Robert> The mail or DNS server might be internal and unreachable to
 Robert> the CA.

It may well be that it's hard or impossible to do more.

But this is NOT what the words quoted would suggest, not at all.
"Definitively bound to" and "verified" does not intuitively translate
to a mere syntax check.  

   paul



Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA29067 for <[e-mail]>; Mon, 15 May 2000 11:03:00 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Mon, 15 May 2000 14:09:36 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 15 May 2000 14:09:10 -0400
To: "Martin Szotkowski" <[e-mail]>, <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: SubjectAltName verification
In-Reply-To: <061e01bfb9db$d2f7ba10$0c7011ac@SZOTKOWSKI>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 07:27 PM 5/9/2000 +0200, Martin Szotkowski wrote:
>Hi all,
>in RFC2459 (4.2.1.7) call :
> >>Because the subject alternative name is considered to be definitively
>bound to the publick key, all parts of the subject alternative name MUST be
>verified by the CA.<<
>What exactly this means?

IMHO, this can only mean that the CA verifies that the content of 
SubjectAltName follows the formatting rules of the CHOICE.  That is if 
rfc822Name is used, then the rules of RFC 822 are followed.  If dNSName is 
used, than RFC 1035.  etc.

These cannot be requied to be real values, that is some SMTP server respond 
with an IDENT for the email and some DNS respond to a query.

WHY?

The mail or DNS server might be internal and unreachable to the CA.

IPsec looks at these as simple labeling formats.  This is particularly true 
for dNSName for gateways on DSL models (ie 'mobile' gateways).


>Must be e.g. email unique in one CA? must be unique for one man?
>If yes, is there any way to determine that this man has this email? (How
>this problem is resolving for DNS, IP, URI, etc.?)
>If no, someone can stand out for some else in email communication?
>
>thanks for explanation
>Martin
>

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28230 for <[e-mail]>; Mon, 15 May 2000 10:24:07 -0700 (PDT)
Received: from [38.29.122.207] (ip171.phoenix11.az.pub-ip.psi.net [38.29.123.171]) by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id KAA01065 for <[e-mail]>; Mon, 15 May 2000 10:30:29 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a04310107b545e06349e2@[38.29.122.207]>
Date: Mon, 15 May 2000 10:29:58 -0700
To: [e-mail]
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: Fwd: RE: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2459)
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 { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Fwd: RE: Inconsistency between X.509-97 and RFC
2459 (</title></head><body>
<div>I sent out an email on this subject to this list some time ago.
We did raise a defect, 220, on this issue and have a approved a
Technical Corrigendum, 3. to the 3rd edition, 97, X.509 as
follows</div>
<div><br></div>
<div><font face="Times New Roman" size="+3" color="#000000"><i>This
corrects the defects reported in defect reports 9594/220.<br>
</i></font><font face="Times New Roman" size="+2"
color="#000000"><b>Clause 11.2 note 3<br>
</b><i>In Note 3, in the second sentence replace
&quot;</i></font><font face="Times New Roman" size="+1"
color="#000000">shall be absent</font><font face="Times New Roman"
size="+2" color="#000000"><i>&quot; with &quot;</i></font><font
face="Times New Roman" size="+1" color="#000000">may be
absent</font><font face="Times New Roman" size="+2"
color="#000000"><i>&quot;.<br>
<br>
In Note 3, at the beginning of the 3rd sentence, replace
&quot;</i></font><font face="Times New Roman" size="+1"
color="#000000">This may permit&quot;&nbsp;</font><font size="+2"
color="#000000"><i> with</i></font><font face="Times New Roman"
size="+1" color="#000000"> &quot;If version is absent, this may
permit&quot;</font><br>
<font face="Times New Roman" size="+1" color="#000000"></font></div>
<div><font face="Times New Roman" size="+2" color="#000000"><i>In
Note 3, at the beginning of&nbsp; the 4th sentence,
replace</i></font><font face="Times New Roman" size="+1"
color="#000000"> &quot;An implementation that supports version 2 (or
greater) CRLs may&quot;</font><font face="Times New Roman" size="+2"
color="#000000"><i> with</i></font><font face="Times New Roman"
size="+1" color="#000000"> &quot;An implementation that supports
version 2 (or greater) CRLs, in the absence of version, may
also&quot;</font><font face="Times New Roman" size="+2"
color="#000000"><i>&nbsp;</i></font></div>
<div><br></div>
<div>This allows PKIX implementors to be conformant to the 97
edition</div>
<div><br></div>
<div>I wasn't too happy that this nuance was not understood by PKIX
(it was first described as an X.509 error on this list) since I wrote
the original text with a goal of interoperability. However, I
understood that to many on this list interoperation with version 1
systems was not necessary. There I proposed, and the group agreed,
that the<i> shall</i> be soften to a<i> may</i>.</div>
<div><br></div>
<div>This allows the PKIX group to decide what its interoperability
requirement is. After some pondering I now believe this is the proper
approach for the standard and have taken this approach for several
enhancements that we added for the 4th edition.</div>
<div><br></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>From: Warwick Ford
&lt;[e-mail]&gt;<br>
To: &quot;'Sam Schaen'&quot; &lt;[e-mail]&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ismo Heikkonen<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>&lt;[e-mail]&gt;<br>
Cc: [e-mail]<br>
Subject: RE: Inconsistency between X.509-97 and RFC 2459 (and son of
RFC 2<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>459)<br>
Date: Mon, 15 May 2000 07:35:15 -0700<br>
List-Archive: http://www.imc.org/ietf-pkix/mail-archiv<span
></span>e/<br>
List-ID: &lt;ietf-pkix.imc.org&gt;<br>
List-Unsubscribe: mailto:[e-mail]?body=un<span
></span>subscribe<br>
</blockquote>
<blockquote type="cite" cite>The intent was as follows. A V1 CRL
interpreter should correctly process a<br>
CRL with extensions but with no version number -- it will ignore
the<br>
extensions entirely, under the X.500 rules of extensibility (which is
OK,<br>
provided no extensions are critical).&nbsp; However, if a version
number is<br>
present, a V1 CRL interpreter will break, since the version field<br>
contravenes the extensibility rule -- deliberately, so as to ensure
critical<br>
extensions don't slip through unnoticed.&nbsp; Therefore, there is a
legitimate<br>
reason for permitting CRLs with noncritical extensions but no
version<br>
number.<br>
<br>
X.509 97 probably went too far in *requiring* that configuration, and
you<br>
will note that X.509 2000 pulled that back and made it optional. This
seems<br>
the right thing to me, for the base standard.<br>
<br>
This opens the way for PKIX to profile the version as mandatory
against the<br>
2000 standard, although no PKIX CRL will ever work with a V1 CRL<br>
interpreting product (is this important?). Also, as you point out,
you<br>
cannot be consistent with both X.509 97 and PKIX, but that is
probably not<br>
very important given the change in 2000.<br>
<br>
Warwick<br>
<br>
-----Original Message-----<br>
From: Sam Schaen [mailto:[e-mail]]<br>
Sent: Monday, May 15, 2000 6:02 AM<br>
To: Ismo Heikkonen<br>
Cc: [e-mail]<br>
Subject: Re: Inconsistency between X.509-97 and RFC 2459 (and son of
RFC<br>
2459)<br>
<br>
<br>
We stumbled across this inconsistency while working on the US DOD
PKI<br>
profile.&nbsp; We elected to go with the RFC 2459
interpretation.&nbsp; It seems<br>
to make more sense, since a version 1 CRL interpreter would not<br>
understand extensions at all.<br>
<br>
Sam Schaen<br>
MITRE<br>
<br>
Ismo Heikkonen wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt; it seems to me that there is an inconsistencty between X.509-97
and RFC<br>
2459 (and also son of RFC2459).<br>
&gt;<br>
&gt; In X.509 , in section 11.2&nbsp; there is the following note
just after the CRL<br>
definition:<br>
&gt;<br>
&gt; &quot;3 If any extensions included in a CertificateList are
defined as<br>
critical, the version element of the CertificateList shall be
present.&nbsp; If<br>
no extensions defined as critical are included, the version element
shall be<br>
absent. This ...&quot;<br>
&gt;<br>
&gt; But RFC 2459 requires that version shall be present always when
the</blockquote>
<blockquote type="cite" cite>&gt; extensions are included:<br>
&gt; &quot;5.1.2.1&nbsp; Version<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp; This optional field describes the version of
the encoded CRL.&nbsp; When<br>
&gt;&nbsp;&nbsp;&nbsp; extensions are used, as required by this
profile, this field MUST be<br>
&gt;&nbsp;&nbsp;&nbsp; present and MUST specify version 2 (the
integer value is 1).&quot;<br>
&gt;<br>
&gt; This means that I can not create CRLs which do not include any
critical<br>
extensions so<br>
&gt; that they would be compatible with both X.509-97 and RFC
2459.<br>
&gt; Or are there any X.509 Defect reports available around this
topic?<br>
&gt;<br>
&gt; By the way&nbsp; X.509 -2000 seems to be more flexible in this
sense.<br>
&gt;<br>
&gt; Ismo Heikkonen<br>
&gt; Sonera SmartTrust Ltd</blockquote>
<div><br></div>
</body>
</html>


Received: from pigeon.verisign.com ([208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22477 for <[e-mail]>; Mon, 15 May 2000 07:30:27 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA00431; Mon, 15 May 2000 07:34:24 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDMFTDD>; Mon, 15 May 2000 07:35:17 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Sam Schaen'" <[e-mail]>, Ismo Heikkonen <[e-mail]>
Cc: [e-mail]
Subject: RE: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2 459)
Date: Mon, 15 May 2000 07:35:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The intent was as follows. A V1 CRL interpreter should correctly process a
CRL with extensions but with no version number -- it will ignore the
extensions entirely, under the X.500 rules of extensibility (which is OK,
provided no extensions are critical).  However, if a version number is
present, a V1 CRL interpreter will break, since the version field
contravenes the extensibility rule -- deliberately, so as to ensure critical
extensions don't slip through unnoticed.  Therefore, there is a legitimate
reason for permitting CRLs with noncritical extensions but no version
number.

X.509 97 probably went too far in *requiring* that configuration, and you
will note that X.509 2000 pulled that back and made it optional. This seems
the right thing to me, for the base standard.

This opens the way for PKIX to profile the version as mandatory against the
2000 standard, although no PKIX CRL will ever work with a V1 CRL
interpreting product (is this important?). Also, as you point out, you
cannot be consistent with both X.509 97 and PKIX, but that is probably not
very important given the change in 2000.

Warwick

-----Original Message-----
From: Sam Schaen [mailto:[e-mail]]
Sent: Monday, May 15, 2000 6:02 AM
To: Ismo Heikkonen
Cc: [e-mail]
Subject: Re: Inconsistency between X.509-97 and RFC 2459 (and son of RFC
2459)


We stumbled across this inconsistency while working on the US DOD PKI
profile.  We elected to go with the RFC 2459 interpretation.  It seems
to make more sense, since a version 1 CRL interpreter would not
understand extensions at all.

Sam Schaen
MITRE

Ismo Heikkonen wrote:
> 
> Hi,
> it seems to me that there is an inconsistencty between X.509-97 and RFC
2459 (and also son of RFC2459).
> 
> In X.509 , in section 11.2  there is the following note just after the CRL
definition:
> 
> "3 If any extensions included in a CertificateList are defined as
critical, the version element of the CertificateList shall be present.  If
no extensions defined as critical are included, the version element shall be
absent. This ..."
> 
> But RFC 2459 requires that version shall be present always when the
> extensions are included:
> "5.1.2.1  Version
> 
>    This optional field describes the version of the encoded CRL.  When
>    extensions are used, as required by this profile, this field MUST be
>    present and MUST specify version 2 (the integer value is 1)."
> 
> This means that I can not create CRLs which do not include any critical
extensions so
> that they would be compatible with both X.509-97 and RFC 2459.
> Or are there any X.509 Defect reports available around this topic?
> 
> By the way  X.509 -2000 seems to be more flexible in this sense.
> 
> Ismo Heikkonen
> Sonera SmartTrust Ltd


Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21845 for <[e-mail]>; Mon, 15 May 2000 07:00:20 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA00024; Mon, 15 May 2000 07:06:11 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK7CJW>; Mon, 15 May 2000 07:05:10 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Sam Schaen'" <[e-mail]>, Ismo Heikkonen <[e-mail]>
Cc: [e-mail]
Subject: RE: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2 459)
Date: Mon, 15 May 2000 07:05:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01BFBE55.300EFF10"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01BFBE55.300EFF10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

When it comes to backwards compatibility I would (almost) always choose
the IETF standard over an ISO one.

In this particular case the ISO approach would appear to break legacy
implementations in unpredictable ways.

	Phill

-----Original Message-----
From: Sam Schaen [mailto:[e-mail]]
Sent: Monday, May 15, 2000 9:02 AM
To: Ismo Heikkonen
Cc: [e-mail]
Subject: Re: Inconsistency between X.509-97 and RFC 2459 (and son of RFC
2459)


We stumbled across this inconsistency while working on the US DOD PKI
profile.  We elected to go with the RFC 2459 interpretation.  It seems
to make more sense, since a version 1 CRL interpreter would not
understand extensions at all.

Sam Schaen
MITRE

Ismo Heikkonen wrote:
> 
> Hi,
> it seems to me that there is an inconsistencty between X.509-97 and
RFC 2459 (and also son of RFC2459).
> 
> In X.509 , in section 11.2  there is the following note just after the
CRL definition:
> 
> "3 If any extensions included in a CertificateList are defined as
critical, the version element of the CertificateList shall be present.
If no extensions defined as critical are included, the version element
shall be absent. This ..."
> 
> But RFC 2459 requires that version shall be present always when the
> extensions are included:
> "5.1.2.1  Version
> 
>    This optional field describes the version of the encoded CRL.  When
>    extensions are used, as required by this profile, this field MUST
be
>    present and MUST specify version 2 (the integer value is 1)."
> 
> This means that I can not create CRLs which do not include any
critical extensions so
> that they would be compatible with both X.509-97 and RFC 2459.
> Or are there any X.509 Defect reports available around this topic?
> 
> By the way  X.509 -2000 seems to be more flexible in this sense.
> 
> Ismo Heikkonen
> Sonera SmartTrust Ltd

------=_NextPart_000_0019_01BFBE55.300EFF10
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxNTE0MDYwN1owIwYJKoZI
hvcNAQkEMRYEFPyYW9cMQIDgJxWl1SPJb3Rt7D4FMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAM5hXlTlJhYzPnaOCtTSTkiQ3zolQMKG8KGVyWrVsJN7ylFgj0chhx1mWOX7kWW5s
Z3HdcVIW18FkVOboRI8zTNl62xi/vUjHl4yaJiZd+ZK2nkm+uMXg0bzir/pe1tK3NMj+K0K6n/q0
orhkST+n3PiGaY1rNr6Fk+TgTDrgrV0AAAAAAAA=

------=_NextPart_000_0019_01BFBE55.300EFF10--



Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20756 for <[e-mail]>; Mon, 15 May 2000 05:59:32 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id GAA28876; Mon, 15 May 2000 06:05:43 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <KJDK7C1X>; Mon, 15 May 2000 06:04:42 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Thierry Van Doninck'" <[e-mail]>, ietf-pkix <[e-mail]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Mon, 15 May 2000 06:04:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0011_01BFBE4C.BE742D60"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01BFBE4C.BE742D60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Same answer, ask Microsoft, not an IETF development list.


-----Original Message-----
From: Thierry Van Doninck [mailto:[e-mail]]
Sent: Thursday, May 11, 2000 7:40 AM
To: ietf-pkix
Subject: Does Smime works fine with Windows 2000 PKI


Hi,

Same message as on the smime mailing list.
Has any of you good people any info on Windows 2000 PKI ?

Thanks,

Thierry

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

Hi everybody,

Just a question :

Is there any known issues using S/MIME with Win2000PKI-certificates ?
More generally, are Win2000 certificates usable with (and understood by
) the others mailers (especially Lotus Notes, Netscape, Eudora
+plug-in?)

Isn't Baltimore Unicert a "better choice" due to its greater
compatibility ?

Any advices are welcome.

Regards,

Laurent Deffranne

------=_NextPart_000_0011_01BFBE4C.BE742D60
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxNTEzMDU0MVowIwYJKoZI
hvcNAQkEMRYEFGOnouHGy19dMtX8ZfLsOWf5lKrDMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAKkMCTpmoSwLejQNA8VS0fYUMdd3BZRg+4xEh+R0kNgWalLZbmALGwGXsmZLyB3gr
4IpRj7iltbctf/tX0ZZnu+XlPG1KJR74E2luQl3GA6tBrOfc7NRhRRDyZl+3G958OXBfdKIQ/Q/k
0Y9HFR9ni4uI5MmvOvxb5/QRSKURFhYAAAAAAAA=

------=_NextPart_000_0011_01BFBE4C.BE742D60--



Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20500 for <[e-mail]>; Mon, 15 May 2000 05:52:18 -0700 (PDT)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA24474; Mon, 15 May 2000 08:58:16 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA13116; Mon, 15 May 2000 08:57:28 -0400 (EDT)
Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub2.mitre.org with SMTP id 3435072; Mon, 15 May 2000 08:58:12 EST
Message-ID: <[e-mail]>
Date: Mon, 15 May 2000 09:01:47 -0400
From: Sam Schaen <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.72 [en]C-2000225M  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ismo Heikkonen <[e-mail]>
CC: [e-mail]
Subject: Re: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2459)
References: <007a01bfbe67$fcc08e90$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We stumbled across this inconsistency while working on the US DOD PKI
profile.  We elected to go with the RFC 2459 interpretation.  It seems
to make more sense, since a version 1 CRL interpreter would not
understand extensions at all.

Sam Schaen
MITRE

Ismo Heikkonen wrote:
> 
> Hi,
> it seems to me that there is an inconsistencty between X.509-97 and RFC 2459 (and also son of RFC2459).
> 
> In X.509 , in section 11.2  there is the following note just after the CRL definition:
> 
> "3 If any extensions included in a CertificateList are defined as critical, the version element of the CertificateList shall be present.  If no extensions defined as critical are included, the version element shall be absent. This ..."
> 
> But RFC 2459 requires that version shall be present always when the
> extensions are included:
> "5.1.2.1  Version
> 
>    This optional field describes the version of the encoded CRL.  When
>    extensions are used, as required by this profile, this field MUST be
>    present and MUST specify version 2 (the integer value is 1)."
> 
> This means that I can not create CRLs which do not include any critical extensions so
> that they would be compatible with both X.509-97 and RFC 2459.
> Or are there any X.509 Defect reports available around this topic?
> 
> By the way  X.509 -2000 seems to be more flexible in this sense.
> 
> Ismo Heikkonen
> Sonera SmartTrust Ltd



Received: from mailgate.dave.sonera.fi (mailgate.dave.sonera.fi [194.137.238.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19942 for <[e-mail]>; Mon, 15 May 2000 05:17:57 -0700 (PDT)
Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.216.195]) by mailgate.dave.sonera.fi (8.8.5/8.8.5) with ESMTP id PAA22064 for <[e-mail]>; Mon, 15 May 2000 15:23:04 +0300 (EET DST)
Received: from silverado (boreas.tkklpr.tele.fi [131.177.76.233]) by smtp.dave.sonera.fi (8.8.5/8.8.5) with SMTP id PAA17668 for <[e-mail]>; Mon, 15 May 2000 15:23:03 +0300 (EET DST)
Message-ID: <007a01bfbe67$fcc08e90$[e-mail]>
From: "Ismo Heikkonen" <[e-mail]>
To: <[e-mail]>
Subject: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2459)
Date: Mon, 15 May 2000 15:20:41 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by smtp.dave.sonera.fi id PAA17668

Hi,
it seems to me that there is an inconsistencty between X.509-97 and RFC 2459 (and also son of RFC2459). 

In X.509 , in section 11.2  there is the following note just after the CRL definition:

"3 If any extensions included in a CertificateList are defined as critical, the version element of the CertificateList shall be present.  If no extensions defined as critical are included, the version element shall be absent. This ..."

But RFC 2459 requires that version shall be present always when the 
extensions are included: 
"5.1.2.1  Version

   This optional field describes the version of the encoded CRL.  When
   extensions are used, as required by this profile, this field MUST be
   present and MUST specify version 2 (the integer value is 1)."

This means that I can not create CRLs which do not include any critical extensions so 
that they would be compatible with both X.509-97 and RFC 2459.
Or are there any X.509 Defect reports available around this topic?

By the way  X.509 -2000 seems to be more flexible in this sense. 

Ismo Heikkonen
Sonera SmartTrust Ltd



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA14223 for <[e-mail]>; Mon, 15 May 2000 01:14:26 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA42532; Mon, 15 May 2000 10:20:29 +0200
Message-ID: <[e-mail]>
Date: Mon, 15 May 2000 10:20:30 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Unmistakable identity
References: <03E49309E8F5D31183F7000629396ECCD685@TRUST>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Stefan,

My comments along your text.

> Denis and others,
> 
> I could spend my and your time by going into detailed argument with Denis,
> but I won't.

Answering to the issues that have been raised could spare much of
your time, *my* time and ... also the time of the WG. 

> Let me instead try to clear the table and state the case in few words.
> 
> There are some main functional requirements that limits the scope of the QC
> profile:
> 1) The certificate is aimed to support electronic signatures.
> 2) The certificate is issued to a human person.
> 3) The profile is based on RFC 2459
> 
> To reflect this, there are two requirements on name/identity information of
> the subject.
> 1) The DN in the subject field must be unique (at least within the issuer
> domain).
> 2) It must be possible to determine (possibly with assistance from external
> authorities) who the certificate subject is (the physical person). At least
> in case of a dispute.

I fully agree with these statements. The problem is that this is not
what the current draft reflects.

In particular the second requirement can be met, as you recognize
just above, without placing any specific/additional information in
the certificate. In the case of a dispute, the certificate serial
number which designates unambiguously the certificate allows to know
who the human person is using the identification information that
was presented at the time of registration.

> In the QC profile the first aspect is defined as a "distinguished name" and
> the second aspect is defined as an "unmistakable identity".

No. This is not what the document says.

> These functional/technical requirements are present ONLY because if they are
> not met, the profile is no longer within it's scope.
> 
> Finally.
> This concept has been in the profile, unchallenged, since the very
> beginning. It's relevant and forms the base of the scope of the profile.
> To change this now at this final state would be devastating.
> 
> I think it's more appropriate to ship this now to RFC and continue this
> "philosophic" discussion on the road from "proposed" to "draft".

This is obviously not my opinion. I have provided an example (see
the "Bob Smith" example below) and I still would like to read your
response to that example. Not responding could be interpreted that
you do have have an appropriate response.

Denis

 
> /Stefan
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 11, 2000 12:55 PM
> > To: Stefan Santesson
> > Cc: 'Russ Housley'; 'Stephen Kent'; '[e-mail]'
> > Subject: Re: Unmistakable identity
> >
> >
> > Stefan,
> >
> > Since I have been travelling quite a lot, here is my (late) answer
> > while showing very quickly in my office.
> >
> > > Denis,
> > >
> > > Some comments regarding DN and Unmistakable identity.
> > >
> > > DN is a technical requirement.
> > > Unmistakable identity is a functional requirement.
> > >
> > > The DN requirement is fullfilled if the CA assignes you a
> > unique number,
> > > e.g. "123456931", but destroys any useful information
> > regarding who is the
> > > person behind that number.
> >
> > So why the DN must be kept "user friendly". :-)
> >
> > > For this identity to also serve the purpose of being an unmistakable
> > > identity, the CA MUST provide the nessecary framework to
> > ensure that this
> > > identity also can be used to identify the person "Denis
> > Pinkas" (at least in
> > > case of a dispute).
> >
> > I would prefer to consider the case of "Bob Smith" because there are
> > probably more than 1.000 "Bob Smith" around the world but only one
> > "Denis Pinkas". :-)
> >
> >
> > > Actually the definition of unmistakable identity says it all, and is
> > > relevant.
> >
> > Sorry. The definition is not relevant and cannot not apply when you
> > consider homonyms, which is a real life case.
> >
> > > With respect to the EU directive, the PKIX document is an
> > international
> > > document, not only driven by the EU directive. Eventhough,
> > the concept of
> > > unmistakable identity applies also EU even if this term is
> > not explicitly
> > > defined in the directive.
> >
> > Besides the fact that the notion is not in the Directive, I would
> > like that you consider the following example, and, if you really
> > think that the notion is relevant, explain how you can solve the
> > case. Otherwise ...
> >
> > I will thus repost one of my previous message that has been
> > augmented with an example. Notice that I am providing a text change
> > proposal to update the draft.
> >
> > Denis
> >
> > ================================================
> >
> > The term "Unmistakable identity" is not used anywhere in the
> > Directive on Electronic Signatures, so this is not a requirement
> > from the Directive. Furthermore, the Directive explicit asks for the
> > support of pseudonyms, for which the concept of unmistakable
> > identity cannot apply.
> >
> > This term is defined under section 2.4 which is called Uniqueness of
> > Names. It should be noticed that the subject name, which is mandated
> > by the QC-03 specification, shall already be unique as this is
> > mandated by RFC 2459. It should be noticed that X.509 does not
> > mandate uniqueness of names, but that RFC 2459 does. This means that
> > once a name has been given it must never be re-used for another
> > individual within the life time of the CA. The definition of
> > unmistakable identity is thus not needed.
> >
> > Forgetting for a while, the argument of uniqueness, the concept
> > could possibly be understood as providing sufficient information so
> > that a human being may figure out without any ambiguity who the
> > person is. One problem is that the attributes for leaving out any
> > ambiguity may be scattered everywhere in the certificate, even as
> > attribute extensions, so that it is impossible for a relying party
> > to know which of them *must* be used to build the unmistakable
> > identity. In other words there is no distinction between attributes
> > that make the name unmistakable and just "useful" attributes.
> >
> > The second problem is that it is only possible to solve ambiguities
> > if the relying party is informed of such a possibility. Let us
> > illustrate this using an example: Some one knows Bob Smith working
> > in the Sales department from the Delta company. Another Bob Smith
> > later on enters the company. He will be named Bob Smith 2 also
> > working in the Sales department from the Delta company. How can a
> > relying party know make the difference between the two persons ?
> > They have different (unique) names indeed, but who is who ?
> >
> > If some one want to verify a signed message from Bob Smith 2 working
> > in the sales department from the Delta company, he will know that
> > there is/was another Bob Smith working in the sales department from
> > the Delta company. Since he does not necessarily have access to a
> > Directory to see the certificate from Bob Smith (1), he cannot make
> > the difference.
> >
> > It should also be noticed that the attributes registered in the
> > certificate from Bob Smith were perfectly unambiguous when Bob Smith
> > was registered but may not be sufficient any more when another Bob
> > Smith comes in. One way to solve the problem would be to revoke the
> > certificate from Bob Smith to include more distinctive attributes.
> > However, it does not seem adequate to perform a revocation for such
> > a case.
> >
> > If someone gets a signed messages from Bob Smith working in the
> > sales department from the Delta company, he does not even know that
> > there exists another Bob Smith 2 working in the sales department
> > from the Delta company and that the normal signatory of the message
> > should be Bob Smith 2 instead of Bob Smith.
> >
> > This problem could, in theory, be solved with an access to all the
> > certificates issued by the CA. Since there is no requirement to make
> > all these certificates accessible (in particular for privacy reasons
> > and to avoid spamming) this problem cannot be solved in such a way.
> >
> > This problem could also, possibly, be solved as indicated before by
> > identifying all the attributes that make the name unmistakable and
> > by revoking previously issued certificates in case there would be an
> > ambiguity with a formerly issued certificate. The problem is that we
> > are also dealing with long term validity of electronic signatures
> > and that expired certificates cannot be revoked anymore.
> >
> > As a conclusion:
> >
> > The concept of unmistakable identity should be dropped from the
> > QC-03 document.
> >
> >
> > Proposed rewording for section 3.1.2 of QC-03:
> >
> > 3.1.2 Subject
> >
> > The subject field MUST contain an X.500 distinguished name (DN).
> > The subject field from a public key certificate identifies the
> > entity associated with the public key stored in the subject public
> > key field. The DN MUST be unique for each subject entity certified
> > by the one CA as defined by the issuer name field.
> >
> > The subject field SHALL contain an appropriate subset of the
> > following attributes:
> >
> >       countryName;
> >       commonName;
> >       surname;
> >       givenName;
> >       pseudonym;
> >       serialNumber;
> >       organizationName;
> >       organizationalUnitName;
> >       stateOrProvinceName
> >       localityName and
> >       postalAddress.
> >
> > Of these attributes, the subject field SHALL include at least one
> > of the following:
> >
> >       Choice   I:  commonName
> >       Choice  II:  givenName
> >       Choice III:  pseudonym
> >
> > The subject field MAY contain other attributes.
> >
> > Any other attributes that MAY be present in either the subject
> > alternative name extension or the subject directory attributes
> > extension MAY help to give a better human understanding of who
> > the individual really is, but uniqueness of the name is achieved
> > singly by the subject field.
> >
> > The countryName attribute value (... then continue with the current
> > text)
> >
> >
> >
> > > /Stefan
> > >
> > > > -----Original Message-----
> > > > From: Denis Pinkas [mailto:[e-mail]]
> > > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > > To: Stefan Santesson
> > > > Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> > > > Subject: Re: Permanent identifiers in QC
> > > >
> > > >
> > > >
> > > > > Folks, I've been sort of off-line the last days.
> > > >
> > > > > So as caching up with this thread I think we need to decide
> > > > the progress of
> > > > > this issue.
> > > >
> > > > > I would just want to add an observation regarding NR and
> > > > Authentication.
> > > > > The issue is NOT whether permanent identifiers are of value for
> > > > > Authentication or NR. What IS an issue is whether it is
> > > > relevant for NR to
> > > > > be able to compare 2 names in 2 different certificates and
> > > > ensure that these
> > > > > certificates identifies the same person EVEN if some parts
> > > > of the DN is not
> > > > > matching.
> > > >
> > > > For non-repudiation, the permanent identifier may be used to link
> > > > different transactions to the same individual, even when
> > the subject
> > > > name of the individual changes. So it is relevant.
> > > >
> > > > > This particular aspect is only raised as a feature for
> > > > access control (when
> > > > > an entity changes his certificate, or possesses several
> > > > certificates with
> > > > > different DN). In the case of NR and legal signatures, the
> > > > only issue is to
> > > > > establish the relation between a certificate and the
> > > > individual key holder
> > > > > (regardless of other certificates). Here the current
> > > > profile provides the
> > > > > necessary means.
> > > >
> > > > No. See above.
> > > >
> > > > > But....
> > > >
> > > > Following the discussion on the serial Number and the Permanent
> > > > Identifier that took place on the PKIX mailing list and
> > at the last
> > > > IETF meeting in Adelaïde, I am paying more and more
> > attention to the
> > > > QC draft.
> > > >
> > > > The document is defining the concept of "unmistakable
> > identity". Now
> > > > that we have introduced the use of serialNumber, I wonder
> > why such a
> > > > concept is still needed.
> > > >
> > > > First, the wording "unmistakable identity" is not used in the
> > > > Directive, so this is the first reason why I wonder it is needed.
> > > >
> > > > Second, let us recall, what RFC 2459 says:
> > > >
> > > >    The subject field from a public key certificate identifies the
> > > >    entity associated with the public key stored in the subject
> > > > public
> > > >    key field.  The subject name may be carried in the
> > subject field
> > > >    and/or the subjectAltName extension.
> > > >
> > > >    Where it is non-empty, the subject field MUST contain an X.500
> > > >    distinguished name (DN). The DN MUST be unique for each subject
> > > >    entity certified by the one CA as defined by the issuer name
> > > > field.
> > > >
> > > > The current specification (QC-03) mandates the use of the subject
> > > > field. In such a case, as defined *in RFC 2459*, the name
> > is unique.
> > > > Moreover, it is unique not only at an instant of time, but during
> > > > the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> > > > this and I guess this is where the problem comes from. The current
> > > > QC-03 document references *X.501* while it should reference RFC
> > > > 2459. If we were *only* using the subjectAltName
> > extension then such
> > > > a concept could be useful. But at the present time, we don't.
> > > >
> > > > The chapter 2.4, called Uniqueness of names, should be deleted.
> > > >
> > > > I would also propose the following rewording for section 3.1.2:
> > > >
> > > > 3.1.2 Subject
> > > >
> > > >    The subject field MUST contain an X.500 distinguished
> > name (DN).
> > > >    The subject field from a public key certificate identifies the
> > > >    entity associated with the public key stored in the subject
> > > > public
> > > >    key field. The DN MUST be unique for each subject entity
> > > > certified
> > > >    by the one CA as defined by the issuer name field.
> > > >
> > > >    The subject field SHALL contain an appropriate subset of the
> > > >    following attributes:
> > > >
> > > >       countryName;
> > > >       commonName;
> > > >       surname;
> > > >       givenName;
> > > >       pseudonym;
> > > >       serialNumber;
> > > >       organizationName;
> > > >       organizationalUnitName;
> > > >       stateOrProvinceName
> > > >       localityName and
> > > >       postalAddress.
> > > >
> > > >    Of these attributes, the subject field SHALL include
> > at least one
> > > > of
> > > >    the following:
> > > >
> > > >       Choice   I:  commonName
> > > >       Choice  II:  givenName
> > > >       Choice III:  pseudonym
> > > >
> > > >    The subject field MAY contain other attributes.
> > > >
> > > >    Any other attributes that MAY be present in either the subject
> > > >    alternative name extension or the subject directory attributes
> > > >    extension MAY help to give a better human understanding of who
> > > >    the individual really is, but uniqueness of the name
> > is achieved
> > > >    singly by the subject field.
> > > >
> > > > The countryName attribute value (... then continue with
> > the current
> > > > text)
> > > >
> > > > As a result of this, the wording "unmistakable identity" should be
> > > > deleted from the whole document. In this way, we will be able to
> > > > suppress ambiguous sentences, like in 3.1.2 :
> > > >
> > > > "  Certificates compliant with this profile SHALL at the same time
> > > >    specify a distinguished name and an unmistakable
> > identity of the
> > > >    subject (see 2.4 for definition of distinguished name and
> > > >    unmistakable identity).
> > > >
> > > >    Attributes stored in the subject field SHALL at least form a
> > > >    distinguished name of the subject, but they MAY also specify a
> > > >    complete unmistakable identity."
> > > >
> > > >
> > > > I reproduced below an extract from Annex I from the European
> > > > Directive on Electronic Signatures:
> > > >
> > > > " Requirements for qualified certificates
> > > >
> > > > Qualified certificates must contain:
> > > >
> > > > (...)
> > > >
> > > > (c)   the name of the signatory or a pseudonym, which shall be
> > > > identified as such;"
> > > >
> > > >
> > > > > Regardless of this I agree with Steve that this issue
> > > > should be advanced on
> > > > > it's own and merged later if it's found relevant to do so.
> > > >
> > > > Anyway, I am preparing some text to describe what a permanent
> > > > identifier is and in which OID arc it should be located.
> > This should
> > > > be ready at the end of this week. In this way we will be able to
> > > > discuss whether the permanent identifier should be, for the time
> > > > being, an independent RFC that the QC draft could reference, or
> > > > whether it should be an RFC of its own.
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> > > >
> > > > > I would therefore request the QC profile to be advanced in
> > > > it's current
> > > > > shape (except for a minor noted update in the reference list).
> > > > >
> > > > > Steve:
> > > > > How do we proceed.
> > > > >
> > > > > /Stefan
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Russ Housley [mailto:[e-mail]]
> > > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > > To: Stephen Kent
> > > > > > Cc: [e-mail]; [e-mail]
> > > > > > Subject: Re: Permanent identifiers in QC
> > > > > >
> > > > > >
> > > > > > I agree with Steve.  Note that the CAT Working Group has
> > > > defined an
> > > > > > OTHER-NAME for Kerberos names.
> > > > > >
> > > > > > Russ
> > > > > >
> > > > > >
> > > > > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > > > > >Tom,
> > > > > > >
> > > > > > >I have no problems with the sorts of IDs you
> > proposed in your ASN
> > > > > > >GeneralName Other-Name examples. They seem to be
> > > > consistent with the
> > > > > > >arguments that Denis has made for such constructs. However,
> > > > > > before we add
> > > > > > >these to the updated part 1, I think we need more time to
> > > > > > explore the
> > > > > > >utility for these name forms.  The debate on the list shows
> > > > > > that there are
> > > > > > >widely diverse opinions about what such IDs are good for,
> > > > > > what scope is
> > > > > > >feasible/appropriate, etc.  I'd hesitant to hold up
> > > > progress on the
> > > > > > >revision to 2459 to add this sort of facility which has been
> > > > > > proposed only
> > > > > > >recently.  That's why several folks have suggested a
> > > > separate, small
> > > > > > >document whoch can be advanced separately, and merged into
> > > > > > 2459 if there
> > > > > > >is sufficient, consistent support.
> > > > > > >
> > > > > > >Steve
> > > > > >
> > > >
> >


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25463 for <[e-mail]>; Fri, 12 May 2000 08:39:45 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA18614 for <[e-mail]>; Fri, 12 May 2000 11:45:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220803b541c8aaf361@[171.78.30.107]>
In-Reply-To: <03E49309E8F5D31183F7000629396ECCD685@TRUST>
References: <03E49309E8F5D31183F7000629396ECCD685@TRUST>
Date: Fri, 12 May 2000 11:37:28 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: attribute certificates
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

	- The WG last call will begin on the Attribute Certificate ID 
<draft-ietf-pkix-ac509prof-03.txt> and end on May 26.

Steve


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24348 for <[e-mail]>; Fri, 12 May 2000 07:51:30 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA29308; Fri, 12 May 2000 10:55:23 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id KAA154234; Fri, 12 May 2000 10:56:26 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568DD.00521030 ; Fri, 12 May 2000 10:56:20 -0400
X-Lotus-FromDomain: IBMUS
cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 12 May 2000 10:56:09 -0400
Subject: RE: Unmistakable identity
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA24349

     In view of the wording about "unmistakable identifier" from section
3.1.2 ("Relying parties MAY however have to examine information stored in
the subject alternative name extension and the subject directory attributes
extension in order to determine a complete unmistakable identity of the
subject."), the current draft actually permits a "permanent identifier" in
the sense of Denis' and my draft to be used to render an identity
unmistakable.  The current draft details techniques for rendering an
identity unmistakable using Subject Directory Attributes, while it somewhat
neglects Subject Alternative Name.  The technique given, in my view, is
somewhat weaker than "permanent identifiers", but if all the attributes in
Subject Directory Attributes other than "title" are used the most likely
collision in those joined with a simple DN would occur when two children
are born in the same jurisdiction with the same name on the same day.
These collisions should not be neglected, but there are many fewer of them
than there collisions of CN, country, and organization alone.  Denis'
example is a collision of CN, country, organization name, and organization
unit.
     I would personally think it was sufficient to change part of the
wording quoted above to "stored in the subject alternative name extension,
using either predefined forms or OtherName forms, and the subject directory
attributes extension".  It might well be better to include a small section
on SubjectAlternativeName, both to allow for OtherName's and to rule out
the consideration of DNS names and IP addresses in forming an unmistakable
identity.

          Tom Gindin

Stefan Santesson <[e-mail]> on 05/12/2000 06:12:57 AM

To:   "'Denis Pinkas'" <[e-mail]>
cc:   "'Russ Housley'" <[e-mail]>, "'Stephen Kent'"
      <[e-mail]>, "'[e-mail]'" <[e-mail]>,
      "'[e-mail]'" <[e-mail]>
Subject:  RE: Unmistakable identity



Denis and others,

I could spend my and your time by going into detailed argument with Denis,
but I won't.
Let me instead try to clear the table and state the case in few words.

There are some main functional requirements that limits the scope of the QC
profile:
1) The certificate is aimed to support electronic signatures.
2) The certificate is issued to a human person.
3) The profile is based on RFC 2459

To reflect this, there are two requirements on name/identity information of
the subject.
1) The DN in the subject field must be unique (at least within the issuer
domain).
2) It must be possible to determine (possibly with assistance from external
authorities) who the certificate subject is (the physical person). At least
in case of a dispute.

In the QC profile the first aspect is defined as a "distinguished name" and
the second aspect is defined as an "unmistakable identity".
These functional/technical requirements are present ONLY because if they
are
not met, the profile is no longer within it's scope.


Finally.
This concept has been in the profile, unchallenged, since the very
beginning. It's relevant and forms the base of the scope of the profile.
To change this now at this final state would be devastating.

I think it's more appropriate to ship this now to RFC and continue this
"philosophic" discussion on the road from "proposed" to "draft".

/Stefan



> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 11, 2000 12:55 PM
> To: Stefan Santesson
> Cc: 'Russ Housley'; 'Stephen Kent'; '[e-mail]'
> Subject: Re: Unmistakable identity
>
>
> Stefan,
>
> Since I have been travelling quite a lot, here is my (late) answer
> while showing very quickly in my office.
>
> > Denis,
> >
> > Some comments regarding DN and Unmistakable identity.
> >
> > DN is a technical requirement.
> > Unmistakable identity is a functional requirement.
> >
> > The DN requirement is fullfilled if the CA assignes you a
> unique number,
> > e.g. "123456931", but destroys any useful information
> regarding who is the
> > person behind that number.
>
> So why the DN must be kept "user friendly". :-)
>
> > For this identity to also serve the purpose of being an unmistakable
> > identity, the CA MUST provide the nessecary framework to
> ensure that this
> > identity also can be used to identify the person "Denis
> Pinkas" (at least in
> > case of a dispute).
>
> I would prefer to consider the case of "Bob Smith" because there are
> probably more than 1.000 "Bob Smith" around the world but only one
> "Denis Pinkas". :-)
>
>
> > Actually the definition of unmistakable identity says it all, and is
> > relevant.
>
> Sorry. The definition is not relevant and cannot not apply when you
> consider homonyms, which is a real life case.
>
> > With respect to the EU directive, the PKIX document is an
> international
> > document, not only driven by the EU directive. Eventhough,
> the concept of
> > unmistakable identity applies also EU even if this term is
> not explicitly
> > defined in the directive.
>
> Besides the fact that the notion is not in the Directive, I would
> like that you consider the following example, and, if you really
> think that the notion is relevant, explain how you can solve the
> case. Otherwise ...
>
> I will thus repost one of my previous message that has been
> augmented with an example. Notice that I am providing a text change
> proposal to update the draft.
>
> Denis
>
> ================================================
>
> The term "Unmistakable identity" is not used anywhere in the
> Directive on Electronic Signatures, so this is not a requirement
> from the Directive. Furthermore, the Directive explicit asks for the
> support of pseudonyms, for which the concept of unmistakable
> identity cannot apply.
>
> This term is defined under section 2.4 which is called Uniqueness of
> Names. It should be noticed that the subject name, which is mandated
> by the QC-03 specification, shall already be unique as this is
> mandated by RFC 2459. It should be noticed that X.509 does not
> mandate uniqueness of names, but that RFC 2459 does. This means that
> once a name has been given it must never be re-used for another
> individual within the life time of the CA. The definition of
> unmistakable identity is thus not needed.
>
> Forgetting for a while, the argument of uniqueness, the concept
> could possibly be understood as providing sufficient information so
> that a human being may figure out without any ambiguity who the
> person is. One problem is that the attributes for leaving out any
> ambiguity may be scattered everywhere in the certificate, even as
> attribute extensions, so that it is impossible for a relying party
> to know which of them *must* be used to build the unmistakable
> identity. In other words there is no distinction between attributes
> that make the name unmistakable and just "useful" attributes.
>
> The second problem is that it is only possible to solve ambiguities
> if the relying party is informed of such a possibility. Let us
> illustrate this using an example: Some one knows Bob Smith working
> in the Sales department from the Delta company. Another Bob Smith
> later on enters the company. He will be named Bob Smith 2 also
> working in the Sales department from the Delta company. How can a
> relying party know make the difference between the two persons ?
> They have different (unique) names indeed, but who is who ?
>
> If some one want to verify a signed message from Bob Smith 2 working
> in the sales department from the Delta company, he will know that
> there is/was another Bob Smith working in the sales department from
> the Delta company. Since he does not necessarily have access to a
> Directory to see the certificate from Bob Smith (1), he cannot make
> the difference.
>
> It should also be noticed that the attributes registered in the
> certificate from Bob Smith were perfectly unambiguous when Bob Smith
> was registered but may not be sufficient any more when another Bob
> Smith comes in. One way to solve the problem would be to revoke the
> certificate from Bob Smith to include more distinctive attributes.
> However, it does not seem adequate to perform a revocation for such
> a case.
>
> If someone gets a signed messages from Bob Smith working in the
> sales department from the Delta company, he does not even know that
> there exists another Bob Smith 2 working in the sales department
> from the Delta company and that the normal signatory of the message
> should be Bob Smith 2 instead of Bob Smith.
>
> This problem could, in theory, be solved with an access to all the
> certificates issued by the CA. Since there is no requirement to make
> all these certificates accessible (in particular for privacy reasons
> and to avoid spamming) this problem cannot be solved in such a way.
>
> This problem could also, possibly, be solved as indicated before by
> identifying all the attributes that make the name unmistakable and
> by revoking previously issued certificates in case there would be an
> ambiguity with a formerly issued certificate. The problem is that we
> are also dealing with long term validity of electronic signatures
> and that expired certificates cannot be revoked anymore.
>
> As a conclusion:
>
> The concept of unmistakable identity should be dropped from the
> QC-03 document.
>
>
> Proposed rewording for section 3.1.2 of QC-03:
>
> 3.1.2 Subject
>
> The subject field MUST contain an X.500 distinguished name (DN).
> The subject field from a public key certificate identifies the
> entity associated with the public key stored in the subject public
> key field. The DN MUST be unique for each subject entity certified
> by the one CA as defined by the issuer name field.
>
> The subject field SHALL contain an appropriate subset of the
> following attributes:
>
>       countryName;
>       commonName;
>       surname;
>       givenName;
>       pseudonym;
>       serialNumber;
>       organizationName;
>       organizationalUnitName;
>       stateOrProvinceName
>       localityName and
>       postalAddress.
>
> Of these attributes, the subject field SHALL include at least one
> of the following:
>
>       Choice   I:  commonName
>       Choice  II:  givenName
>       Choice III:  pseudonym
>
> The subject field MAY contain other attributes.
>
> Any other attributes that MAY be present in either the subject
> alternative name extension or the subject directory attributes
> extension MAY help to give a better human understanding of who
> the individual really is, but uniqueness of the name is achieved
> singly by the subject field.
>
> The countryName attribute value (... then continue with the current
> text)
>
>
>
> > /Stefan
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > To: Stefan Santesson
> > > Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> > > Subject: Re: Permanent identifiers in QC
> > >
> > >
> > >
> > > > Folks, I've been sort of off-line the last days.
> > >
> > > > So as caching up with this thread I think we need to decide
> > > the progress of
> > > > this issue.
> > >
> > > > I would just want to add an observation regarding NR and
> > > Authentication.
> > > > The issue is NOT whether permanent identifiers are of value for
> > > > Authentication or NR. What IS an issue is whether it is
> > > relevant for NR to
> > > > be able to compare 2 names in 2 different certificates and
> > > ensure that these
> > > > certificates identifies the same person EVEN if some parts
> > > of the DN is not
> > > > matching.
> > >
> > > For non-repudiation, the permanent identifier may be used to link
> > > different transactions to the same individual, even when
> the subject
> > > name of the individual changes. So it is relevant.
> > >
> > > > This particular aspect is only raised as a feature for
> > > access control (when
> > > > an entity changes his certificate, or possesses several
> > > certificates with
> > > > different DN). In the case of NR and legal signatures, the
> > > only issue is to
> > > > establish the relation between a certificate and the
> > > individual key holder
> > > > (regardless of other certificates). Here the current
> > > profile provides the
> > > > necessary means.
> > >
> > > No. See above.
> > >
> > > > But....
> > >
> > > Following the discussion on the serial Number and the Permanent
> > > Identifier that took place on the PKIX mailing list and
> at the last
> > > IETF meeting in Adelaïde, I am paying more and more
> attention to the
> > > QC draft.
> > >
> > > The document is defining the concept of "unmistakable
> identity". Now
> > > that we have introduced the use of serialNumber, I wonder
> why such a
> > > concept is still needed.
> > >
> > > First, the wording "unmistakable identity" is not used in the
> > > Directive, so this is the first reason why I wonder it is needed.
> > >
> > > Second, let us recall, what RFC 2459 says:
> > >
> > >    The subject field from a public key certificate identifies the
> > >    entity associated with the public key stored in the subject
> > > public
> > >    key field.  The subject name may be carried in the
> subject field
> > >    and/or the subjectAltName extension.
> > >
> > >    Where it is non-empty, the subject field MUST contain an X.500
> > >    distinguished name (DN). The DN MUST be unique for each subject
> > >    entity certified by the one CA as defined by the issuer name
> > > field.
> > >
> > > The current specification (QC-03) mandates the use of the subject
> > > field. In such a case, as defined *in RFC 2459*, the name
> is unique.
> > > Moreover, it is unique not only at an instant of time, but during
> > > the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> > > this and I guess this is where the problem comes from. The current
> > > QC-03 document references *X.501* while it should reference RFC
> > > 2459. If we were *only* using the subjectAltName
> extension then such
> > > a concept could be useful. But at the present time, we don't.
> > >
> > > The chapter 2.4, called Uniqueness of names, should be deleted.
> > >
> > > I would also propose the following rewording for section 3.1.2:
> > >
> > > 3.1.2 Subject
> > >
> > >    The subject field MUST contain an X.500 distinguished
> name (DN).
> > >    The subject field from a public key certificate identifies the
> > >    entity associated with the public key stored in the subject
> > > public
> > >    key field. The DN MUST be unique for each subject entity
> > > certified
> > >    by the one CA as defined by the issuer name field.
> > >
> > >    The subject field SHALL contain an appropriate subset of the
> > >    following attributes:
> > >
> > >       countryName;
> > >       commonName;
> > >       surname;
> > >       givenName;
> > >       pseudonym;
> > >       serialNumber;
> > >       organizationName;
> > >       organizationalUnitName;
> > >       stateOrProvinceName
> > >       localityName and
> > >       postalAddress.
> > >
> > >    Of these attributes, the subject field SHALL include
> at least one
> > > of
> > >    the following:
> > >
> > >       Choice   I:  commonName
> > >       Choice  II:  givenName
> > >       Choice III:  pseudonym
> > >
> > >    The subject field MAY contain other attributes.
> > >
> > >    Any other attributes that MAY be present in either the subject
> > >    alternative name extension or the subject directory attributes
> > >    extension MAY help to give a better human understanding of who
> > >    the individual really is, but uniqueness of the name
> is achieved
> > >    singly by the subject field.
> > >
> > > The countryName attribute value (... then continue with
> the current
> > > text)
> > >
> > > As a result of this, the wording "unmistakable identity" should be
> > > deleted from the whole document. In this way, we will be able to
> > > suppress ambiguous sentences, like in 3.1.2 :
> > >
> > > "  Certificates compliant with this profile SHALL at the same time
> > >    specify a distinguished name and an unmistakable
> identity of the
> > >    subject (see 2.4 for definition of distinguished name and
> > >    unmistakable identity).
> > >
> > >    Attributes stored in the subject field SHALL at least form a
> > >    distinguished name of the subject, but they MAY also specify a
> > >    complete unmistakable identity."
> > >
> > >
> > > I reproduced below an extract from Annex I from the European
> > > Directive on Electronic Signatures:
> > >
> > > " Requirements for qualified certificates
> > >
> > > Qualified certificates must contain:
> > >
> > > (...)
> > >
> > > (c)   the name of the signatory or a pseudonym, which shall be
> > > identified as such;"
> > >
> > >
> > > > Regardless of this I agree with Steve that this issue
> > > should be advanced on
> > > > it's own and merged later if it's found relevant to do so.
> > >
> > > Anyway, I am preparing some text to describe what a permanent
> > > identifier is and in which OID arc it should be located.
> This should
> > > be ready at the end of this week. In this way we will be able to
> > > discuss whether the permanent identifier should be, for the time
> > > being, an independent RFC that the QC draft could reference, or
> > > whether it should be an RFC of its own.
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > >
> > > > I would therefore request the QC profile to be advanced in
> > > it's current
> > > > shape (except for a minor noted update in the reference list).
> > > >
> > > > Steve:
> > > > How do we proceed.
> > > >
> > > > /Stefan
> > > >
> > > > > -----Original Message-----
> > > > > From: Russ Housley [mailto:[e-mail]]
> > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > To: Stephen Kent
> > > > > Cc: [e-mail]; [e-mail]
> > > > > Subject: Re: Permanent identifiers in QC
> > > > >
> > > > >
> > > > > I agree with Steve.  Note that the CAT Working Group has
> > > defined an
> > > > > OTHER-NAME for Kerberos names.
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > > > >Tom,
> > > > > >
> > > > > >I have no problems with the sorts of IDs you
> proposed in your ASN
> > > > > >GeneralName Other-Name examples. They seem to be
> > > consistent with the
> > > > > >arguments that Denis has made for such constructs. However,
> > > > > before we add
> > > > > >these to the updated part 1, I think we need more time to
> > > > > explore the
> > > > > >utility for these name forms.  The debate on the list shows
> > > > > that there are
> > > > > >widely diverse opinions about what such IDs are good for,
> > > > > what scope is
> > > > > >feasible/appropriate, etc.  I'd hesitant to hold up
> > > progress on the
> > > > > >revision to 2459 to add this sort of facility which has been
> > > > > proposed only
> > > > > >recently.  That's why several folks have suggested a
> > > separate, small
> > > > > >document whoch can be advanced separately, and merged into
> > > > > 2459 if there
> > > > > >is sufficient, consistent support.
> > > > > >
> > > > > >Steve
> > > > >
> > >
>





Received: from trust.addtrust.com ([212.28.197.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14436 for <[e-mail]>; Fri, 12 May 2000 03:06:33 -0700 (PDT)
Received: by TRUST with Internet Mail Service (5.5.2650.21) id <KTBWSMM5>; Fri, 12 May 2000 12:13:04 +0200
Message-ID: <03E49309E8F5D31183F7000629396ECCD685@TRUST>
From: Stefan Santesson <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Unmistakable identity
Date: Fri, 12 May 2000 12:12:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis and others,

I could spend my and your time by going into detailed argument with Denis,
but I won't.
Let me instead try to clear the table and state the case in few words.

There are some main functional requirements that limits the scope of the QC
profile:
1) The certificate is aimed to support electronic signatures.
2) The certificate is issued to a human person.
3) The profile is based on RFC 2459

To reflect this, there are two requirements on name/identity information of
the subject.
1) The DN in the subject field must be unique (at least within the issuer
domain).
2) It must be possible to determine (possibly with assistance from external
authorities) who the certificate subject is (the physical person). At least
in case of a dispute.

In the QC profile the first aspect is defined as a "distinguished name" and
the second aspect is defined as an "unmistakable identity". 
These functional/technical requirements are present ONLY because if they are
not met, the profile is no longer within it's scope.


Finally. 
This concept has been in the profile, unchallenged, since the very
beginning. It's relevant and forms the base of the scope of the profile.
To change this now at this final state would be devastating.

I think it's more appropriate to ship this now to RFC and continue this
"philosophic" discussion on the road from "proposed" to "draft".

/Stefan



> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 11, 2000 12:55 PM
> To: Stefan Santesson
> Cc: 'Russ Housley'; 'Stephen Kent'; '[e-mail]'
> Subject: Re: Unmistakable identity
> 
> 
> Stefan,
> 
> Since I have been travelling quite a lot, here is my (late) answer
> while showing very quickly in my office.
> 
> > Denis,
> > 
> > Some comments regarding DN and Unmistakable identity.
> > 
> > DN is a technical requirement.
> > Unmistakable identity is a functional requirement.
> > 
> > The DN requirement is fullfilled if the CA assignes you a 
> unique number,
> > e.g. "123456931", but destroys any useful information 
> regarding who is the
> > person behind that number.
> 
> So why the DN must be kept "user friendly". :-)
> 
> > For this identity to also serve the purpose of being an unmistakable
> > identity, the CA MUST provide the nessecary framework to 
> ensure that this
> > identity also can be used to identify the person "Denis 
> Pinkas" (at least in
> > case of a dispute).
> 
> I would prefer to consider the case of "Bob Smith" because there are
> probably more than 1.000 "Bob Smith" around the world but only one
> "Denis Pinkas". :-)
> 
> 
> > Actually the definition of unmistakable identity says it all, and is
> > relevant.
> 
> Sorry. The definition is not relevant and cannot not apply when you
> consider homonyms, which is a real life case.
> 
> > With respect to the EU directive, the PKIX document is an 
> international
> > document, not only driven by the EU directive. Eventhough, 
> the concept of
> > unmistakable identity applies also EU even if this term is 
> not explicitly
> > defined in the directive.
> 
> Besides the fact that the notion is not in the Directive, I would
> like that you consider the following example, and, if you really
> think that the notion is relevant, explain how you can solve the
> case. Otherwise ...
> 
> I will thus repost one of my previous message that has been
> augmented with an example. Notice that I am providing a text change
> proposal to update the draft.
> 
> Denis
> 
> ================================================
> 
> The term "Unmistakable identity" is not used anywhere in the
> Directive on Electronic Signatures, so this is not a requirement
> from the Directive. Furthermore, the Directive explicit asks for the
> support of pseudonyms, for which the concept of unmistakable
> identity cannot apply.
> 
> This term is defined under section 2.4 which is called Uniqueness of
> Names. It should be noticed that the subject name, which is mandated
> by the QC-03 specification, shall already be unique as this is
> mandated by RFC 2459. It should be noticed that X.509 does not
> mandate uniqueness of names, but that RFC 2459 does. This means that
> once a name has been given it must never be re-used for another
> individual within the life time of the CA. The definition of
> unmistakable identity is thus not needed. 
> 
> Forgetting for a while, the argument of uniqueness, the concept
> could possibly be understood as providing sufficient information so
> that a human being may figure out without any ambiguity who the
> person is. One problem is that the attributes for leaving out any
> ambiguity may be scattered everywhere in the certificate, even as
> attribute extensions, so that it is impossible for a relying party
> to know which of them *must* be used to build the unmistakable
> identity. In other words there is no distinction between attributes
> that make the name unmistakable and just "useful" attributes.
> 
> The second problem is that it is only possible to solve ambiguities
> if the relying party is informed of such a possibility. Let us
> illustrate this using an example: Some one knows Bob Smith working
> in the Sales department from the Delta company. Another Bob Smith
> later on enters the company. He will be named Bob Smith 2 also
> working in the Sales department from the Delta company. How can a
> relying party know make the difference between the two persons ?
> They have different (unique) names indeed, but who is who ? 
> 
> If some one want to verify a signed message from Bob Smith 2 working
> in the sales department from the Delta company, he will know that
> there is/was another Bob Smith working in the sales department from
> the Delta company. Since he does not necessarily have access to a
> Directory to see the certificate from Bob Smith (1), he cannot make
> the difference.
> 
> It should also be noticed that the attributes registered in the
> certificate from Bob Smith were perfectly unambiguous when Bob Smith
> was registered but may not be sufficient any more when another Bob
> Smith comes in. One way to solve the problem would be to revoke the
> certificate from Bob Smith to include more distinctive attributes.
> However, it does not seem adequate to perform a revocation for such
> a case.
> 
> If someone gets a signed messages from Bob Smith working in the
> sales department from the Delta company, he does not even know that
> there exists another Bob Smith 2 working in the sales department
> from the Delta company and that the normal signatory of the message
> should be Bob Smith 2 instead of Bob Smith. 
> 
> This problem could, in theory, be solved with an access to all the
> certificates issued by the CA. Since there is no requirement to make
> all these certificates accessible (in particular for privacy reasons
> and to avoid spamming) this problem cannot be solved in such a way.
> 
> This problem could also, possibly, be solved as indicated before by
> identifying all the attributes that make the name unmistakable and
> by revoking previously issued certificates in case there would be an
> ambiguity with a formerly issued certificate. The problem is that we
> are also dealing with long term validity of electronic signatures
> and that expired certificates cannot be revoked anymore. 
> 
> As a conclusion:
> 
> The concept of unmistakable identity should be dropped from the
> QC-03 document.
> 
> 
> Proposed rewording for section 3.1.2 of QC-03:
> 
> 3.1.2 Subject
> 
> The subject field MUST contain an X.500 distinguished name (DN).
> The subject field from a public key certificate identifies the 
> entity associated with the public key stored in the subject public 
> key field. The DN MUST be unique for each subject entity certified 
> by the one CA as defined by the issuer name field. 
> 
> The subject field SHALL contain an appropriate subset of the
> following attributes:
> 
>       countryName;
>       commonName;
>       surname;
>       givenName;
>       pseudonym;
>       serialNumber;
>       organizationName;
>       organizationalUnitName;
>       stateOrProvinceName
>       localityName and
>       postalAddress.
> 
> Of these attributes, the subject field SHALL include at least one
> of the following:
> 
>       Choice   I:  commonName
>       Choice  II:  givenName
>       Choice III:  pseudonym
> 
> The subject field MAY contain other attributes.
> 
> Any other attributes that MAY be present in either the subject 
> alternative name extension or the subject directory attributes 
> extension MAY help to give a better human understanding of who 
> the individual really is, but uniqueness of the name is achieved 
> singly by the subject field. 
> 
> The countryName attribute value (... then continue with the current
> text)
> 
> 
>  
> > /Stefan
> > 
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > To: Stefan Santesson
> > > Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> > > Subject: Re: Permanent identifiers in QC
> > >
> > >
> > >
> > > > Folks, I've been sort of off-line the last days.
> > >
> > > > So as caching up with this thread I think we need to decide
> > > the progress of
> > > > this issue.
> > >
> > > > I would just want to add an observation regarding NR and
> > > Authentication.
> > > > The issue is NOT whether permanent identifiers are of value for
> > > > Authentication or NR. What IS an issue is whether it is
> > > relevant for NR to
> > > > be able to compare 2 names in 2 different certificates and
> > > ensure that these
> > > > certificates identifies the same person EVEN if some parts
> > > of the DN is not
> > > > matching.
> > >
> > > For non-repudiation, the permanent identifier may be used to link
> > > different transactions to the same individual, even when 
> the subject
> > > name of the individual changes. So it is relevant.
> > >
> > > > This particular aspect is only raised as a feature for
> > > access control (when
> > > > an entity changes his certificate, or possesses several
> > > certificates with
> > > > different DN). In the case of NR and legal signatures, the
> > > only issue is to
> > > > establish the relation between a certificate and the
> > > individual key holder
> > > > (regardless of other certificates). Here the current
> > > profile provides the
> > > > necessary means.
> > >
> > > No. See above.
> > >
> > > > But....
> > >
> > > Following the discussion on the serial Number and the Permanent
> > > Identifier that took place on the PKIX mailing list and 
> at the last
> > > IETF meeting in Adelaïde, I am paying more and more 
> attention to the
> > > QC draft.
> > >
> > > The document is defining the concept of "unmistakable 
> identity". Now
> > > that we have introduced the use of serialNumber, I wonder 
> why such a
> > > concept is still needed.
> > >
> > > First, the wording "unmistakable identity" is not used in the
> > > Directive, so this is the first reason why I wonder it is needed.
> > >
> > > Second, let us recall, what RFC 2459 says:
> > >
> > >    The subject field from a public key certificate identifies the
> > >    entity associated with the public key stored in the subject
> > > public
> > >    key field.  The subject name may be carried in the 
> subject field
> > >    and/or the subjectAltName extension.
> > >
> > >    Where it is non-empty, the subject field MUST contain an X.500
> > >    distinguished name (DN). The DN MUST be unique for each subject
> > >    entity certified by the one CA as defined by the issuer name
> > > field.
> > >
> > > The current specification (QC-03) mandates the use of the subject
> > > field. In such a case, as defined *in RFC 2459*, the name 
> is unique.
> > > Moreover, it is unique not only at an instant of time, but during
> > > the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> > > this and I guess this is where the problem comes from. The current
> > > QC-03 document references *X.501* while it should reference RFC
> > > 2459. If we were *only* using the subjectAltName 
> extension then such
> > > a concept could be useful. But at the present time, we don't.
> > >
> > > The chapter 2.4, called Uniqueness of names, should be deleted.
> > >
> > > I would also propose the following rewording for section 3.1.2:
> > >
> > > 3.1.2 Subject
> > >
> > >    The subject field MUST contain an X.500 distinguished 
> name (DN).
> > >    The subject field from a public key certificate identifies the
> > >    entity associated with the public key stored in the subject
> > > public
> > >    key field. The DN MUST be unique for each subject entity
> > > certified
> > >    by the one CA as defined by the issuer name field.
> > >
> > >    The subject field SHALL contain an appropriate subset of the
> > >    following attributes:
> > >
> > >       countryName;
> > >       commonName;
> > >       surname;
> > >       givenName;
> > >       pseudonym;
> > >       serialNumber;
> > >       organizationName;
> > >       organizationalUnitName;
> > >       stateOrProvinceName
> > >       localityName and
> > >       postalAddress.
> > >
> > >    Of these attributes, the subject field SHALL include 
> at least one
> > > of
> > >    the following:
> > >
> > >       Choice   I:  commonName
> > >       Choice  II:  givenName
> > >       Choice III:  pseudonym
> > >
> > >    The subject field MAY contain other attributes.
> > >
> > >    Any other attributes that MAY be present in either the subject
> > >    alternative name extension or the subject directory attributes
> > >    extension MAY help to give a better human understanding of who
> > >    the individual really is, but uniqueness of the name 
> is achieved
> > >    singly by the subject field.
> > >
> > > The countryName attribute value (... then continue with 
> the current
> > > text)
> > >
> > > As a result of this, the wording "unmistakable identity" should be
> > > deleted from the whole document. In this way, we will be able to
> > > suppress ambiguous sentences, like in 3.1.2 :
> > >
> > > "  Certificates compliant with this profile SHALL at the same time
> > >    specify a distinguished name and an unmistakable 
> identity of the
> > >    subject (see 2.4 for definition of distinguished name and
> > >    unmistakable identity).
> > >
> > >    Attributes stored in the subject field SHALL at least form a
> > >    distinguished name of the subject, but they MAY also specify a
> > >    complete unmistakable identity."
> > >
> > >
> > > I reproduced below an extract from Annex I from the European
> > > Directive on Electronic Signatures:
> > >
> > > " Requirements for qualified certificates
> > >
> > > Qualified certificates must contain:
> > >
> > > (...)
> > >
> > > (c)   the name of the signatory or a pseudonym, which shall be
> > > identified as such;"
> > >
> > >
> > > > Regardless of this I agree with Steve that this issue
> > > should be advanced on
> > > > it's own and merged later if it's found relevant to do so.
> > >
> > > Anyway, I am preparing some text to describe what a permanent
> > > identifier is and in which OID arc it should be located. 
> This should
> > > be ready at the end of this week. In this way we will be able to
> > > discuss whether the permanent identifier should be, for the time
> > > being, an independent RFC that the QC draft could reference, or
> > > whether it should be an RFC of its own.
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > >
> > > > I would therefore request the QC profile to be advanced in
> > > it's current
> > > > shape (except for a minor noted update in the reference list).
> > > >
> > > > Steve:
> > > > How do we proceed.
> > > >
> > > > /Stefan
> > > >
> > > > > -----Original Message-----
> > > > > From: Russ Housley [mailto:[e-mail]]
> > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > To: Stephen Kent
> > > > > Cc: [e-mail]; [e-mail]
> > > > > Subject: Re: Permanent identifiers in QC
> > > > >
> > > > >
> > > > > I agree with Steve.  Note that the CAT Working Group has
> > > defined an
> > > > > OTHER-NAME for Kerberos names.
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > > > >Tom,
> > > > > >
> > > > > >I have no problems with the sorts of IDs you 
> proposed in your ASN
> > > > > >GeneralName Other-Name examples. They seem to be
> > > consistent with the
> > > > > >arguments that Denis has made for such constructs. However,
> > > > > before we add
> > > > > >these to the updated part 1, I think we need more time to
> > > > > explore the
> > > > > >utility for these name forms.  The debate on the list shows
> > > > > that there are
> > > > > >widely diverse opinions about what such IDs are good for,
> > > > > what scope is
> > > > > >feasible/appropriate, etc.  I'd hesitant to hold up
> > > progress on the
> > > > > >revision to 2459 to add this sort of facility which has been
> > > > > proposed only
> > > > > >recently.  That's why several folks have suggested a
> > > separate, small
> > > > > >document whoch can be advanced separately, and merged into
> > > > > 2459 if there
> > > > > >is sufficient, consistent support.
> > > > > >
> > > > > >Steve
> > > > >
> > >
> 


Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17236 for <[e-mail]>; Thu, 11 May 2000 07:56:22 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA30692; Thu, 11 May 2000 11:00:46 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id LAA206212; Thu, 11 May 2000 11:02:09 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568DC.00529736 ; Thu, 11 May 2000 11:02:06 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: pkix list <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 11 May 2000 11:01:58 -0400
Subject: Re: DER in ac509prof-03
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I do, actually, have a constructive suggestion here along with the
various standards discussions below.  Why don't we have a 1993 module which
imports from the 1988 module, not duplicating all of the syntax
definitions, and some comments in the 1988 module about which statements
need to be commented out and replaced by imports for conformance to 1997
syntax?  There are not many of these in 2459, anyway - AlgorithmIdentifier,
AttributeTypeAndValue, PolicyQualifierInfo, OtherName and
ExtensionAttribute.
     If the reason for dumping the 1993 module was the workload of doing
simultaneous updates to two modules and ensuring that they matched, this
would reduce that substantially.

          Tom Gindin

"Phillip H. Griffin" <[e-mail]> on 05/10/2000 09:11:30 PM

Please respond to [e-mail]

To:   pkix list <[e-mail]>
cc:
Subject:  Re: DER in ac509prof-03



Tom,

Comments below.

[e-mail] wrote:
>
>      In practice, what we mean by "1988 syntax", as far as I can tell, is
> pretty much the following:
>
> 1 -  Avoiding the following three types first defined in post-1988
> versions: Instance-of, Embedded-pdv, and Unrestricted character string,
and
> adding explicit definitions for the Unicode string types which are copied
> from X.680.
> 2 -  Continuing to use "ANY DEFINED BY", as defined in X.208 section 27
and
> X.680 appendix H.3, rather than using constructs with similar meaning
first
> defined in 1993-4, such as information object classes and their fields.
> 3 -  Avoiding the use of either macros (legal in 1988) or information
> object classes (legal after 1993-4).
>
>      The only part of this which seems even questionable is point 2, but
> X.680 still contains support for ANY DEFINED BY, although it is
deprecated.
> I was not at Adelaide, which partly accounts for my suggestion of 1993
> support in AC509Prof.

No version of X.680 contains support for ANY DEFINED BY.
In the 1994 version, ANY DEFINED BY was discussed as
deprecated notation in an *informative* annex, and was
not part of any *normative* text in that standard.

[Tom Gindin] A definition of the feature appears in that version of the
standard, although explicitly deprecated.  It is a rather academic question
whether that document "contains support" for the feature.  My point was
that no reference to X.208/X.209 is strictly necessary, although we
apparently can't go beyond X.680:1994 without replacing the ANY DEFINED BY
occurrences with information object classes.

During the last revision of X.680, both of the normative
sections describing ANY DEFINED BY and the MACRO notation
were removed, and the section you refer to no longer exists
in the most recent publication of the standard, ITU-T Rec.
X.680:1997 | ISO/IEC 8824-1 (1998).

[Tom Gindin] I don't have the 1997-8 versions, and I doubt that I am the
only one who doesn't.  What positive changes other than the definition of
new string types were made to X.680 and X.681 (as opposed to X.690) between
1993-4 and 1997-8?  The removal of ANY DEFINED BY does not qualify as a
positive change, and it makes it impossible to produce definitions which
compile both in 1988-90 and 1997-8 formats.

>      I don't think that the bits on the line change for BER between
> X.209(1988) and X.690(1994) if the ASN.1 is legal 1988 syntax.  Does
> anybody know of changes specific to DER?
>

You are correct that the bits on the line did not change
for BER between the X.209:1988 and X.680:1997 publications.
However, the same can not be said for X.509:1987 DER. The
set of restrictions defined at that time were only intended
for use in the Directory specification at that time, long
before version 3 certificates.

It wasn't until the added complexity of X.509v3 extensions
came about that these 1987 rules became insufficient. They
were probably designed only to be correct at that time for
limited use within the Directory ASN.1. They were not
designed to cover all possible uses of ASN.1.

[Tom Gindin] Looking at your other posting, you cite several types whose
DER encodings were changed.  Obviously, the PKIX and X.509 communities care
about the DER encodings of BIT STRING's, UTCTime's, and GeneralizedTime's.
To the best of my knowledge, there are no occurrences of either REAL or
GeneralString in any relevant standard - I checked X.520 (1993), X.509v4
current draft, PKCS#9 current draft, the new-part1, ac509prof, and 2510bis
drafts, and RFC's 1274, 2459, 2510, 2511, 2587, and 2797.

(snip)




Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13317 for <[e-mail]>; Thu, 11 May 2000 04:37:59 -0700 (PDT)
Date: 11 May 2000 13:39:53 +0200
From: Thierry Van Doninck <[e-mail]>
To: ietf-pkix <[e-mail]>
Subject: Does Smime works fine with Windows 2000 PKI
Message-Id: <145B0391A9C090FC*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS>

Hi,

Same message as on the smime mailing list.
Has any of you good people any info on Windows 2000 PKI ?

Thanks,

Thierry

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

Hi everybody,

Just a question :

Is there any known issues using S/MIME with Win2000PKI-certificates ?
More generally, are Win2000 certificates usable with (and understood by ) the others mailers (especially Lotus Notes, Netscape, Eudora +plug-in?)

Isn't Baltimore Unicert a "better choice" due to its greater compatibility ?

Any advices are welcome.

Regards,

Laurent Deffranne



Received: from dvont01.univw.uni-sb.de (dvont01.univw.uni-sb.de [134.96.109.65]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA11959 for <[e-mail]>; Thu, 11 May 2000 04:00:56 -0700 (PDT)
Received: from univw.uni-saarland.de (unverified [134.96.108.48]) by dvont01.univw.uni-sb.de (EMWAC SMTPRS 0.83) with SMTP id <[e-mail]>; Thu, 11 May 2000 13:05:41 +0200
Message-ID: <[e-mail]>
Date: Thu, 11 May 2000 12:56:31 +0200
From: Hardo Hase <[e-mail]>
Organization: =?iso-8859-1?Q?Universit=E4t?= des Saarlandes
X-Mailer: Mozilla 4.7 [de] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: unsubscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe




Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11395 for <[e-mail]>; Thu, 11 May 2000 03:54:51 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA15220; Thu, 11 May 2000 13:00:39 +0200
Message-ID: <[e-mail]>
Date: Thu, 11 May 2000 13:00:41 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Subject: Re: Unmistakable identity
References: <03E49309E8F5D31183F7000629396ECCD663@TRUST>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Stefan,

This proposal does not solve the issue. See my longer mail on that
topic.

 
> Going through the definition in the QC profile, I would suggest this minor
> change in section 2.4
> 
> And change:
> 
>  2.4  Uniqueness of names
> 
>    Requirements on name uniqueness are described in this standard
>    through the terms "distinguished name" and "unmistakable identity",
>    having the following meaning:
> 
> To:
> 
>  2.4  Uniqueness of names
> 
>    Functional and uniqueness requirements on names are described in
>    this standard through the terms "distinguished name" and
>    "unmistakable identity", having the following meaning:
> 
> This would then clarify the concept of functional requirement related to the
> term unmistakable identity.
> 
> Since this is just a minor fix. I will see through that this is added to the
> next draft for the IESG process that will be submitted on Friday.

We need a MAJOR fix. I do not think it is appropriate to submit the
draft to the IESG at the time being. We need to solve this issue
first.
Denis

> /Stefan
> 
> > -----Original Message-----
> > From: Stefan Santesson
> > Sent: Thursday, May 04, 2000 12:04 PM
> > To: 'Denis Pinkas'
> > Cc: 'Russ Housley'; 'Stephen Kent'; '[e-mail]'
> > Subject: Unmistakable identity
> >
> >
> > Denis,
> >
> > Some comments regarding DN and Unmistakable identity.
> >
> > DN is a technical requirement.
> > Unmistakable identity is a functional requirement.
> >
> > The DN requirement is fullfilled if the CA assignes you a
> > unique number, e.g. "123456931", but destroys any useful
> > information regarding who is the person behind that number.
> >
> > For this identity to also serve the purpose of being an
> > unmistakable identity, the CA MUST provide the nessecary
> > framework to ensure that this identity also can be used to
> > identify the person "Denis Pinkas" (at least in case of a dispute).
> >
> > Actually the definition of unmistakable identity says it all,
> > and is relevant.
> >
> > With respect to the EU directive, the PKIX document is an
> > international document, not only driven by the EU directive.
> > Eventhough, the concept of unmistakable identity applies also
> > EU even if this term is not explicitly defined in the directive.
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > To: Stefan Santesson
> > > Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> > > Subject: Re: Permanent identifiers in QC
> > >
> > >
> > >
> > > > Folks, I've been sort of off-line the last days.
> > >
> > > > So as caching up with this thread I think we need to decide
> > > the progress of
> > > > this issue.
> > >
> > > > I would just want to add an observation regarding NR and
> > > Authentication.
> > > > The issue is NOT whether permanent identifiers are of value for
> > > > Authentication or NR. What IS an issue is whether it is
> > > relevant for NR to
> > > > be able to compare 2 names in 2 different certificates and
> > > ensure that these
> > > > certificates identifies the same person EVEN if some parts
> > > of the DN is not
> > > > matching.
> > >
> > > For non-repudiation, the permanent identifier may be used to link
> > > different transactions to the same individual, even when the subject
> > > name of the individual changes. So it is relevant.
> > >
> > > > This particular aspect is only raised as a feature for
> > > access control (when
> > > > an entity changes his certificate, or possesses several
> > > certificates with
> > > > different DN). In the case of NR and legal signatures, the
> > > only issue is to
> > > > establish the relation between a certificate and the
> > > individual key holder
> > > > (regardless of other certificates). Here the current
> > > profile provides the
> > > > necessary means.
> > >
> > > No. See above.
> > >
> > > > But....
> > >
> > > Following the discussion on the serial Number and the Permanent
> > > Identifier that took place on the PKIX mailing list and at the last
> > > IETF meeting in Adelaïde, I am paying more and more attention to the
> > > QC draft.
> > >
> > > The document is defining the concept of "unmistakable identity". Now
> > > that we have introduced the use of serialNumber, I wonder why such a
> > > concept is still needed.
> > >
> > > First, the wording "unmistakable identity" is not used in the
> > > Directive, so this is the first reason why I wonder it is needed.
> > >
> > > Second, let us recall, what RFC 2459 says:
> > >
> > >    The subject field from a public key certificate identifies the
> > >    entity associated with the public key stored in the subject
> > > public
> > >    key field.  The subject name may be carried in the subject field
> > >    and/or the subjectAltName extension.
> > >
> > >    Where it is non-empty, the subject field MUST contain an X.500
> > >    distinguished name (DN). The DN MUST be unique for each subject
> > >    entity certified by the one CA as defined by the issuer name
> > > field.
> > >
> > > The current specification (QC-03) mandates the use of the subject
> > > field. In such a case, as defined *in RFC 2459*, the name is unique.
> > > Moreover, it is unique not only at an instant of time, but during
> > > the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> > > this and I guess this is where the problem comes from. The current
> > > QC-03 document references *X.501* while it should reference RFC
> > > 2459. If we were *only* using the subjectAltName extension then such
> > > a concept could be useful. But at the present time, we don't.
> > >
> > > The chapter 2.4, called Uniqueness of names, should be deleted.
> > >
> > > I would also propose the following rewording for section 3.1.2:
> > >
> > > 3.1.2 Subject
> > >
> > >    The subject field MUST contain an X.500 distinguished name (DN).
> > >    The subject field from a public key certificate identifies the
> > >    entity associated with the public key stored in the subject
> > > public
> > >    key field. The DN MUST be unique for each subject entity
> > > certified
> > >    by the one CA as defined by the issuer name field.
> > >
> > >    The subject field SHALL contain an appropriate subset of the
> > >    following attributes:
> > >
> > >       countryName;
> > >       commonName;
> > >       surname;
> > >       givenName;
> > >       pseudonym;
> > >       serialNumber;
> > >       organizationName;
> > >       organizationalUnitName;
> > >       stateOrProvinceName
> > >       localityName and
> > >       postalAddress.
> > >
> > >    Of these attributes, the subject field SHALL include at least one
> > > of
> > >    the following:
> > >
> > >       Choice   I:  commonName
> > >       Choice  II:  givenName
> > >       Choice III:  pseudonym
> > >
> > >    The subject field MAY contain other attributes.
> > >
> > >    Any other attributes that MAY be present in either the subject
> > >    alternative name extension or the subject directory attributes
> > >    extension MAY help to give a better human understanding of who
> > >    the individual really is, but uniqueness of the name is achieved
> > >    singly by the subject field.
> > >
> > > The countryName attribute value (... then continue with the current
> > > text)
> > >
> > > As a result of this, the wording "unmistakable identity" should be
> > > deleted from the whole document. In this way, we will be able to
> > > suppress ambiguous sentences, like in 3.1.2 :
> > >
> > > "  Certificates compliant with this profile SHALL at the same time
> > >    specify a distinguished name and an unmistakable identity of the
> > >    subject (see 2.4 for definition of distinguished name and
> > >    unmistakable identity).
> > >
> > >    Attributes stored in the subject field SHALL at least form a
> > >    distinguished name of the subject, but they MAY also specify a
> > >    complete unmistakable identity."
> > >
> > >
> > > I reproduced below an extract from Annex I from the European
> > > Directive on Electronic Signatures:
> > >
> > > " Requirements for qualified certificates
> > >
> > > Qualified certificates must contain:
> > >
> > > (...)
> > >
> > > (c) the name of the signatory or a pseudonym, which shall be
> > > identified as such;"
> > >
> > >
> > > > Regardless of this I agree with Steve that this issue
> > > should be advanced on
> > > > it's own and merged later if it's found relevant to do so.
> > >
> > > Anyway, I am preparing some text to describe what a permanent
> > > identifier is and in which OID arc it should be located. This should
> > > be ready at the end of this week. In this way we will be able to
> > > discuss whether the permanent identifier should be, for the time
> > > being, an independent RFC that the QC draft could reference, or
> > > whether it should be an RFC of its own.
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > >
> > > > I would therefore request the QC profile to be advanced in
> > > it's current
> > > > shape (except for a minor noted update in the reference list).
> > > >
> > > > Steve:
> > > > How do we proceed.
> > > >
> > > > /Stefan
> > > >
> > > > > -----Original Message-----
> > > > > From: Russ Housley [mailto:[e-mail]]
> > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > To: Stephen Kent
> > > > > Cc: [e-mail]; [e-mail]
> > > > > Subject: Re: Permanent identifiers in QC
> > > > >
> > > > >
> > > > > I agree with Steve.  Note that the CAT Working Group has
> > > defined an
> > > > > OTHER-NAME for Kerberos names.
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > > > >Tom,
> > > > > >
> > > > > >I have no problems with the sorts of IDs you proposed
> > in your ASN
> > > > > >GeneralName Other-Name examples. They seem to be
> > > consistent with the
> > > > > >arguments that Denis has made for such constructs. However,
> > > > > before we add
> > > > > >these to the updated part 1, I think we need more time to
> > > > > explore the
> > > > > >utility for these name forms.  The debate on the list shows
> > > > > that there are
> > > > > >widely diverse opinions about what such IDs are good for,
> > > > > what scope is
> > > > > >feasible/appropriate, etc.  I'd hesitant to hold up
> > > progress on the
> > > > > >revision to 2459 to add this sort of facility which has been
> > > > > proposed only
> > > > > >recently.  That's why several folks have suggested a
> > > separate, small
> > > > > >document whoch can be advanced separately, and merged into
> > > > > 2459 if there
> > > > > >is sufficient, consistent support.
> > > > > >
> > > > > >Steve
> > > > >
> > >
> >


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11026 for <[e-mail]>; Thu, 11 May 2000 03:49:51 -0700 (PDT)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA26682; Thu, 11 May 2000 12:54:53 +0200
Message-ID: <[e-mail]>
Date: Thu, 11 May 2000 12:54:56 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Unmistakable identity
References: <03E49309E8F5D31183F7000629396ECCD661@TRUST>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Stefan,

Since I have been travelling quite a lot, here is my (late) answer
while showing very quickly in my office.

> Denis,
> 
> Some comments regarding DN and Unmistakable identity.
> 
> DN is a technical requirement.
> Unmistakable identity is a functional requirement.
> 
> The DN requirement is fullfilled if the CA assignes you a unique number,
> e.g. "123456931", but destroys any useful information regarding who is the
> person behind that number.

So why the DN must be kept "user friendly". :-)

> For this identity to also serve the purpose of being an unmistakable
> identity, the CA MUST provide the nessecary framework to ensure that this
> identity also can be used to identify the person "Denis Pinkas" (at least in
> case of a dispute).

I would prefer to consider the case of "Bob Smith" because there are
probably more than 1.000 "Bob Smith" around the world but only one
"Denis Pinkas". :-)


> Actually the definition of unmistakable identity says it all, and is
> relevant.

Sorry. The definition is not relevant and cannot not apply when you
consider homonyms, which is a real life case.

> With respect to the EU directive, the PKIX document is an international
> document, not only driven by the EU directive. Eventhough, the concept of
> unmistakable identity applies also EU even if this term is not explicitly
> defined in the directive.

Besides the fact that the notion is not in the Directive, I would
like that you consider the following example, and, if you really
think that the notion is relevant, explain how you can solve the
case. Otherwise ...

I will thus repost one of my previous message that has been
augmented with an example. Notice that I am providing a text change
proposal to update the draft.

Denis

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

The term "Unmistakable identity" is not used anywhere in the
Directive on Electronic Signatures, so this is not a requirement
from the Directive. Furthermore, the Directive explicit asks for the
support of pseudonyms, for which the concept of unmistakable
identity cannot apply.

This term is defined under section 2.4 which is called Uniqueness of
Names. It should be noticed that the subject name, which is mandated
by the QC-03 specification, shall already be unique as this is
mandated by RFC 2459. It should be noticed that X.509 does not
mandate uniqueness of names, but that RFC 2459 does. This means that
once a name has been given it must never be re-used for another
individual within the life time of the CA. The definition of
unmistakable identity is thus not needed. 

Forgetting for a while, the argument of uniqueness, the concept
could possibly be understood as providing sufficient information so
that a human being may figure out without any ambiguity who the
person is. One problem is that the attributes for leaving out any
ambiguity may be scattered everywhere in the certificate, even as
attribute extensions, so that it is impossible for a relying party
to know which of them *must* be used to build the unmistakable
identity. In other words there is no distinction between attributes
that make the name unmistakable and just "useful" attributes.

The second problem is that it is only possible to solve ambiguities
if the relying party is informed of such a possibility. Let us
illustrate this using an example: Some one knows Bob Smith working
in the Sales department from the Delta company. Another Bob Smith
later on enters the company. He will be named Bob Smith 2 also
working in the Sales department from the Delta company. How can a
relying party know make the difference between the two persons ?
They have different (unique) names indeed, but who is who ? 

If some one want to verify a signed message from Bob Smith 2 working
in the sales department from the Delta company, he will know that
there is/was another Bob Smith working in the sales department from
the Delta company. Since he does not necessarily have access to a
Directory to see the certificate from Bob Smith (1), he cannot make
the difference.

It should also be noticed that the attributes registered in the
certificate from Bob Smith were perfectly unambiguous when Bob Smith
was registered but may not be sufficient any more when another Bob
Smith comes in. One way to solve the problem would be to revoke the
certificate from Bob Smith to include more distinctive attributes.
However, it does not seem adequate to perform a revocation for such
a case.

If someone gets a signed messages from Bob Smith working in the
sales department from the Delta company, he does not even know that
there exists another Bob Smith 2 working in the sales department
from the Delta company and that the normal signatory of the message
should be Bob Smith 2 instead of Bob Smith. 

This problem could, in theory, be solved with an access to all the
certificates issued by the CA. Since there is no requirement to make
all these certificates accessible (in particular for privacy reasons
and to avoid spamming) this problem cannot be solved in such a way.

This problem could also, possibly, be solved as indicated before by
identifying all the attributes that make the name unmistakable and
by revoking previously issued certificates in case there would be an
ambiguity with a formerly issued certificate. The problem is that we
are also dealing with long term validity of electronic signatures
and that expired certificates cannot be revoked anymore. 

As a conclusion:

The concept of unmistakable identity should be dropped from the
QC-03 document.


Proposed rewording for section 3.1.2 of QC-03:

3.1.2 Subject

The subject field MUST contain an X.500 distinguished name (DN).
The subject field from a public key certificate identifies the 
entity associated with the public key stored in the subject public 
key field. The DN MUST be unique for each subject entity certified 
by the one CA as defined by the issuer name field. 

The subject field SHALL contain an appropriate subset of the
following attributes:

      countryName;
      commonName;
      surname;
      givenName;
      pseudonym;
      serialNumber;
      organizationName;
      organizationalUnitName;
      stateOrProvinceName
      localityName and
      postalAddress.

Of these attributes, the subject field SHALL include at least one
of the following:

      Choice   I:  commonName
      Choice  II:  givenName
      Choice III:  pseudonym

The subject field MAY contain other attributes.

Any other attributes that MAY be present in either the subject 
alternative name extension or the subject directory attributes 
extension MAY help to give a better human understanding of who 
the individual really is, but uniqueness of the name is achieved 
singly by the subject field. 

The countryName attribute value (... then continue with the current
text)


 
> /Stefan
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> > Subject: Re: Permanent identifiers in QC
> >
> >
> >
> > > Folks, I've been sort of off-line the last days.
> >
> > > So as caching up with this thread I think we need to decide
> > the progress of
> > > this issue.
> >
> > > I would just want to add an observation regarding NR and
> > Authentication.
> > > The issue is NOT whether permanent identifiers are of value for
> > > Authentication or NR. What IS an issue is whether it is
> > relevant for NR to
> > > be able to compare 2 names in 2 different certificates and
> > ensure that these
> > > certificates identifies the same person EVEN if some parts
> > of the DN is not
> > > matching.
> >
> > For non-repudiation, the permanent identifier may be used to link
> > different transactions to the same individual, even when the subject
> > name of the individual changes. So it is relevant.
> >
> > > This particular aspect is only raised as a feature for
> > access control (when
> > > an entity changes his certificate, or possesses several
> > certificates with
> > > different DN). In the case of NR and legal signatures, the
> > only issue is to
> > > establish the relation between a certificate and the
> > individual key holder
> > > (regardless of other certificates). Here the current
> > profile provides the
> > > necessary means.
> >
> > No. See above.
> >
> > > But....
> >
> > Following the discussion on the serial Number and the Permanent
> > Identifier that took place on the PKIX mailing list and at the last
> > IETF meeting in Adelaïde, I am paying more and more attention to the
> > QC draft.
> >
> > The document is defining the concept of "unmistakable identity". Now
> > that we have introduced the use of serialNumber, I wonder why such a
> > concept is still needed.
> >
> > First, the wording "unmistakable identity" is not used in the
> > Directive, so this is the first reason why I wonder it is needed.
> >
> > Second, let us recall, what RFC 2459 says:
> >
> >    The subject field from a public key certificate identifies the
> >    entity associated with the public key stored in the subject
> > public
> >    key field.  The subject name may be carried in the subject field
> >    and/or the subjectAltName extension.
> >
> >    Where it is non-empty, the subject field MUST contain an X.500
> >    distinguished name (DN). The DN MUST be unique for each subject
> >    entity certified by the one CA as defined by the issuer name
> > field.
> >
> > The current specification (QC-03) mandates the use of the subject
> > field. In such a case, as defined *in RFC 2459*, the name is unique.
> > Moreover, it is unique not only at an instant of time, but during
> > the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> > this and I guess this is where the problem comes from. The current
> > QC-03 document references *X.501* while it should reference RFC
> > 2459. If we were *only* using the subjectAltName extension then such
> > a concept could be useful. But at the present time, we don't.
> >
> > The chapter 2.4, called Uniqueness of names, should be deleted.
> >
> > I would also propose the following rewording for section 3.1.2:
> >
> > 3.1.2 Subject
> >
> >    The subject field MUST contain an X.500 distinguished name (DN).
> >    The subject field from a public key certificate identifies the
> >    entity associated with the public key stored in the subject
> > public
> >    key field. The DN MUST be unique for each subject entity
> > certified
> >    by the one CA as defined by the issuer name field.
> >
> >    The subject field SHALL contain an appropriate subset of the
> >    following attributes:
> >
> >       countryName;
> >       commonName;
> >       surname;
> >       givenName;
> >       pseudonym;
> >       serialNumber;
> >       organizationName;
> >       organizationalUnitName;
> >       stateOrProvinceName
> >       localityName and
> >       postalAddress.
> >
> >    Of these attributes, the subject field SHALL include at least one
> > of
> >    the following:
> >
> >       Choice   I:  commonName
> >       Choice  II:  givenName
> >       Choice III:  pseudonym
> >
> >    The subject field MAY contain other attributes.
> >
> >    Any other attributes that MAY be present in either the subject
> >    alternative name extension or the subject directory attributes
> >    extension MAY help to give a better human understanding of who
> >    the individual really is, but uniqueness of the name is achieved
> >    singly by the subject field.
> >
> > The countryName attribute value (... then continue with the current
> > text)
> >
> > As a result of this, the wording "unmistakable identity" should be
> > deleted from the whole document. In this way, we will be able to
> > suppress ambiguous sentences, like in 3.1.2 :
> >
> > "  Certificates compliant with this profile SHALL at the same time
> >    specify a distinguished name and an unmistakable identity of the
> >    subject (see 2.4 for definition of distinguished name and
> >    unmistakable identity).
> >
> >    Attributes stored in the subject field SHALL at least form a
> >    distinguished name of the subject, but they MAY also specify a
> >    complete unmistakable identity."
> >
> >
> > I reproduced below an extract from Annex I from the European
> > Directive on Electronic Signatures:
> >
> > " Requirements for qualified certificates
> >
> > Qualified certificates must contain:
> >
> > (...)
> >
> > (c)   the name of the signatory or a pseudonym, which shall be
> > identified as such;"
> >
> >
> > > Regardless of this I agree with Steve that this issue
> > should be advanced on
> > > it's own and merged later if it's found relevant to do so.
> >
> > Anyway, I am preparing some text to describe what a permanent
> > identifier is and in which OID arc it should be located. This should
> > be ready at the end of this week. In this way we will be able to
> > discuss whether the permanent identifier should be, for the time
> > being, an independent RFC that the QC draft could reference, or
> > whether it should be an RFC of its own.
> >
> > Regards,
> >
> > Denis
> >
> >
> > > I would therefore request the QC profile to be advanced in
> > it's current
> > > shape (except for a minor noted update in the reference list).
> > >
> > > Steve:
> > > How do we proceed.
> > >
> > > /Stefan
> > >
> > > > -----Original Message-----
> > > > From: Russ Housley [mailto:[e-mail]]
> > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > To: Stephen Kent
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: Permanent identifiers in QC
> > > >
> > > >
> > > > I agree with Steve.  Note that the CAT Working Group has
> > defined an
> > > > OTHER-NAME for Kerberos names.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > > >Tom,
> > > > >
> > > > >I have no problems with the sorts of IDs you proposed in your ASN
> > > > >GeneralName Other-Name examples. They seem to be
> > consistent with the
> > > > >arguments that Denis has made for such constructs. However,
> > > > before we add
> > > > >these to the updated part 1, I think we need more time to
> > > > explore the
> > > > >utility for these name forms.  The debate on the list shows
> > > > that there are
> > > > >widely diverse opinions about what such IDs are good for,
> > > > what scope is
> > > > >feasible/appropriate, etc.  I'd hesitant to hold up
> > progress on the
> > > > >revision to 2459 to add this sort of facility which has been
> > > > proposed only
> > > > >recently.  That's why several folks have suggested a
> > separate, small
> > > > >document whoch can be advanced separately, and merged into
> > > > 2459 if there
> > > > >is sufficient, consistent support.
> > > > >
> > > > >Steve
> > > >
> >


Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26635 for <[e-mail]>; Wed, 10 May 2000 18:30:50 -0700 (PDT)
Received: from asn-1.com (user-2ivf0ub.dialup.mindspring.com [165.247.131.203]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA26686 for <[e-mail]>; Wed, 10 May 2000 21:36:51 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 21:11:30 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting  
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix list <[e-mail]>
Subject: Re: DER in ac509prof-03
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,

Comments below.

[e-mail] wrote:
> 
>      In practice, what we mean by "1988 syntax", as far as I can tell, is
> pretty much the following:
> 
> 1 -  Avoiding the following three types first defined in post-1988
> versions: Instance-of, Embedded-pdv, and Unrestricted character string, and
> adding explicit definitions for the Unicode string types which are copied
> from X.680.
> 2 -  Continuing to use "ANY DEFINED BY", as defined in X.208 section 27 and
> X.680 appendix H.3, rather than using constructs with similar meaning first
> defined in 1993-4, such as information object classes and their fields.
> 3 -  Avoiding the use of either macros (legal in 1988) or information
> object classes (legal after 1993-4).
> 
>      The only part of this which seems even questionable is point 2, but
> X.680 still contains support for ANY DEFINED BY, although it is deprecated.
> I was not at Adelaide, which partly accounts for my suggestion of 1993
> support in AC509Prof.

No version of X.680 contains support for ANY DEFINED BY.
In the 1994 version, ANY DEFINED BY was discussed as 
deprecated notation in an *informative* annex, and was
not part of any *normative* text in that standard. 

During the last revision of X.680, both of the normative
sections describing ANY DEFINED BY and the MACRO notation
were removed, and the section you refer to no longer exists
in the most recent publication of the standard, ITU-T Rec. 
X.680:1997 | ISO/IEC 8824-1 (1998).

>      I don't think that the bits on the line change for BER between
> X.209(1988) and X.690(1994) if the ASN.1 is legal 1988 syntax.  Does
> anybody know of changes specific to DER?
>

You are correct that the bits on the line did not change
for BER between the X.209:1988 and X.680:1997 publications.
However, the same can not be said for X.509:1987 DER. The
set of restrictions defined at that time were only intended
for use in the Directory specification at that time, long
before version 3 certificates. 

It wasn't until the added complexity of X.509v3 extensions
came about that these 1987 rules became insufficient. They
were probably designed only to be correct at that time for
limited use within the Directory ASN.1. They were not 
designed to cover all possible uses of ASN.1.


>           Tom Gindin
> 
> Paul Koning <[e-mail]> on 05/10/2000 12:27:54 PM
> 
> To:   [e-mail]
> cc:   [e-mail], [e-mail],
>       [e-mail]
> Subject:  Re: DER in ac509prof-03
> 
> >>>>> "Russ" == Russ Housley <[e-mail]> writes:
> 
>  Russ> I disagree.  We are using the ASN.1-1988 documents, not the
>  Russ> 1997 ones.
> 
>  Russ> At 11:43 AM 05/10/2000 +0100, Stephen Farrell wrote:
> 
>  >> "DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]"
>  >> is fine by me, anyone else care?
> 
> Are the two different?  That is, are there bitstrings that conform to
> one but not the other, or whose meaning changes depending on which
> spec you use?
> 
> I think Russ's position is problematic.  It's a bit like saying that
> you continue to use an RFC that has been superseded.  Presumably it
> was superseded for a reason.  Also, while old RFCs are still
> available, 12 year old ITU specs may only exist in antique shops by
> now.   Clearly, it is not acceptable to have an RFC that points to an
> outside standard unless that outside standard is available.
> 
>      paul

Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
[phone]         1625 Glenwood Avenue, Five Points
[phone] [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------



Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26596 for <[e-mail]>; Wed, 10 May 2000 18:30:44 -0700 (PDT)
Received: from asn-1.com (user-2ivf0ub.dialup.mindspring.com [165.247.131.203]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA07416 for <[e-mail]>; Wed, 10 May 2000 21:36:43 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 21:39:09 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting  
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix list <[e-mail]>
Subject: Re: DER in ac509prof-03
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
> 
> Paul:
> 
> Both generate identical bit strings.

Russ, this is simply not true. DER as defined in X.509:1987
is not as rigorously defined as the DER in X.690. Given the 
same abstract value these two sets of rules can produce
different encodings.

You may have forgotten this discussion from August 1998
between the ASN.1 standards editor and the Directory
rapporteur on changing the reference in X.509 from their
own definition of DER to that in X.680. After detailing
differences between bit string encodings the ASN.1 editor
stated in part:

  >The reason 
  >that X.509 DER was not adopted verbatim into X.690 was 
  >that when we started looking at it closely we came across
  >deficiencies in the X.509 encoding of REAL, UTCTime, 
  >GeneralizedTime, GeneralString and BIT STRING which can 
  >result different encodings for a given value.  So we fixed
  >what was broken.  I have no doubt that X.690 DER simply 
  >closes the holes in X.509 DER and otherwise introduces
  > no incompatibility in X.509.  
  >
  >The X.690 DER spec is very short, as is the X.509 spec.
  >Take the time and review the two and you will see that 
  >X.690 DER is simply a tighter version of X.509 DER.

> This topic has been debated several times,and I do not think we should do
> it again on the list.  If you want to have a private discussion about it, I
> will be glad to do so.  The bottom line is that ASN.1-1997 does not have
> multiple implementations.

What? Russ this may have been true a few years ago but
it is not so now. While this is not a complete list I'm 
sure, and it doesn't take into account at all the many 
in house and not for sale tools that companies have, but
among the ASN.1 tools I know of that support ASN.1:1997 
are:

   http://asn1.elibel.tm.fr/en/tools/index.htm
   http://www.oss.com/products/tools.html
   http://www.computec.com/en/asn2cxx/index.html
   http://www.obj-sys.com/asn1.htm

All of these support both BER and DER. All of these also
support PER, though two of them at present only have beta
test versions of PER tools available. There are two or three
other companies currently building tools to support 
ASN.1:1997 as well, but none is complete at this time.

Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
[phone]         1625 Glenwood Avenue, Five Points
[phone] [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------
 
> Russ
> 
> At 12:27 PM 05/10/2000 -0400, Paul Koning wrote:
> > >>>>> "Russ" == Russ Housley <[e-mail]> writes:
> >
> >  Russ> I disagree.  We are using the ASN.1-1988 documents, not the
> >  Russ> 1997 ones.
> >
> >  Russ> At 11:43 AM 05/10/2000 +0100, Stephen Farrell wrote:
> >
> >  >> "DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]"
> >  >> is fine by me, anyone else care?
> >
> >Are the two different?  That is, are there bitstrings that conform to
> >one but not the other, or whose meaning changes depending on which
> >spec you use?
> >
> >I think Russ's position is problematic.  It's a bit like saying that
> >you continue to use an RFC that has been superseded.  Presumably it
> >was superseded for a reason.  Also, while old RFCs are still
> >available, 12 year old ITU specs may only exist in antique shops by
> >now.   Clearly, it is not acceptable to have an RFC that points to an
> >outside standard unless that outside standard is available.
> >
> >         paul


Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14096 for <[e-mail]>; Wed, 10 May 2000 13:07:10 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id IAA14431; Thu, 11 May 2000 08:13:07 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95798958727979>; Thu, 11 May 2000 08:13:07 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: DER in ac509prof-03
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 11 May 2000 08:13:07 (NZST)
Message-ID: <[e-mail]>

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

>>It's the same for ASN.1 books, Prof.Larmouth's book is for current versions 
>>of ASN.1 rather than the obsolete versions referenced in RFC's, so it would
>>probably do more to confuse than help.
>
>Larmouth's books certainly covers the current standards, but it is far from 
>being irrelevant to understanding any version of the ASN.1 standards. The 
>book covers such topics from antiquity as ANY DEFINED BY, ANY, and MACRO. All
>of the ASN.1 types covered in the earlier Steedman book are also covered, as 
>well as new types such as UTF8String and RELATIVE-OID that are not specified
>in X.208/209.

What I was concerned with is that since it covers features not present in the
1988 version, anyone using it as a reference could end up using features which
aren't in the older version (it's a bit like using an ANSI C manual to write
K&R code, it's backwards-compatible but you wouldn't want to rely on it as a 
reference for K&R programming).  Unless Larmouth's book is very explicit over 
which features can't be used in the 1988 version, people using it could end up 
accidentally using post-1988 ASN.1 features.

Peter.



Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13649 for <[e-mail]>; Wed, 10 May 2000 12:45:58 -0700 (PDT)
Received: from asn-1.com (user-2ivf6mc.dialup.mindspring.com [165.247.154.204]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA21436 for <[e-mail]>; Wed, 10 May 2000 15:51:58 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 15:54:27 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting 
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DER in ac509prof-03
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
> 
> Yes.  The group was asked if anyone wanted to retain the ASN.1-1993
> Appendix, and no one cared enough to speak up.
> 
> Russ

Actually the PKIX1Explicit93 module is now referenced in an
IMPORTS statement in the FDIS version of ISO 15945 (also an
ITU-T proposed standard, but I can not find the mumble number
right now) Trusted Third Parties. 

This work includes versions of CRMF and OCSP whose syntax has
been corrected where necessary and rewritten using the current
ASN.1 standards. 

Phil


> At 04:38 PM 05/10/2000 +0100, Stephen Farrell wrote:
> 
> >Tom,
> >
> > >      The definition Phil referred to ("AttributeValue ::= ANY") should be
> > > changed to
> > > "AttributeValue ::= ANY DEFINED BY AttributeType", both here and in A.1 of
> > > son-of-2459.
> >
> >No problem. 2459 does it that way in the text, but not in
> >the ASN.1 module, which I guess must be where I copied it
> >from.
> >
> > > Since only SecurityCategory, among the structures specific to
> > > AC509Prof, actually uses any old-fashioned formats, it would be better
> > > either to include documentation of the 1993 format in the draft (as in 2459
> > > and son-of-2459) or to change it to be compatible with INSTANCE OF.
> >
> >Wasn't there consensus among the folks in Adelaide to expunge the '93
> >ASN.1 from son-of-2459. I'm happy to follow whatever happens there,
> >though I can't remember if this has come up on the list.
> >
> > > Including documentation of the 1993 format would not break existing
> > > implementations (if there are any),
> >
> >There are.
> >
> >Regards,
> >Stephen.
> >
> >--
> >____________________________________________________________
> >Stephen Farrell
> >Baltimore Technologies,   tel: (direct line) [phone]
> >61 Fitzwilliam Lane,                    fax: [phone]
> >Dublin 2.                mailto:[e-mail]
> >Ireland                             http://www.baltimore.com


Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13259 for <[e-mail]>; Wed, 10 May 2000 12:34:55 -0700 (PDT)
Received: from asn-1.com (user-2ivf6mc.dialup.mindspring.com [165.247.154.204]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA32341 for <[e-mail]>; Wed, 10 May 2000 15:40:54 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 15:43:20 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting  
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: DER in ac509prof-03
References: <004d01bfbab1$55756d40$6689a4d8@rankney>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rich Ankney wrote:
> 
> -----Original Message-----
> From: Peter Gutmann <[e-mail]>
> To: [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Date: Wednesday, May 10, 2000 1:28 PM
> Subject: Re: DER in ac509prof-03
> 
> >Paul Koning <[e-mail]> writes:
> >
> >>Also, while old RFCs are still available, 12 year old ITU specs may only
> >>exist in antique shops by now.

Not sure, but I think that the 1990 version
is still available on the ITU-T web site.

> >It's the same for ASN.1 books, Prof.Larmouth's book is for current versions
> of
> >ASN.1 rather than the obsolete versions referenced in RFC's, so it would
> >probably do more to confuse than help.  The only reference for the obsolete
> >variant of ASN.1 is Douglas Steedmans "Tutorial and Reference", which is
> >useful for that version but doesn't apply to any current version.  This
> book
> >has been out of print for years, so you'd actually have to go to antique
> >shops (well, used book stores) to find it.
> >
> 
> Well, Larmouth's book does discuss these earlier artifacts (macros and
> ANY DEFINED BY), although it's certainly not very detailed.

The text on holes could give more details on
ANY and ANY DEFINED BY, but it seems to spend
more time on holes that work without the 
interoperability failures of these deprecated
types. As for MACROs, it seems rare when two
people can read one and come to the same 
conclusion. In general, they can not be 
mechanically processed in a reliable manner.
 
> >>Clearly, it is not acceptable to have an RFC that points to an outside
> >>standard unless that outside standard is available.
> >
> >It could be argued that the ASN.1 specs, being ISO standards, aren't
> usefully
> >"available" no matter whether it's an obsolete or current version which is
> >being referenced :-).
> >
> 
> I heard from a generally reliable source that ITU-T is going to cave in and
> distribute the ASN.1 specs (X.680 and X.690) for free via their website.
> I heard this about a month ago, and they are still charging, but after all
> this
> IS the ITU we're talking about.  Has anyone else heard this?
> >Peter.

At the ASN.1 meeting in Geneva in March, the ASN.1
Study Group recommended (again) that the ITU-T make
electronic copies of the standards available on their
web site for free. It has been agreed by the ITU-T to
follow this recommendation and to do so, but I am still
waiting on notice of the actual URL. 

There is other work related to this that must also be
completed. There are instructions for converting from
X.208 to the current standards that will be added to
the web site, and there is also new text to be added
that that there is no further need for retention of 
X.208 and X.209 as standards. Not sure if this actual
text has yet been approved, but the recommended text
to be displayed on the X.208 and X.209 pages was:

 "CCITT Recommendation X.208 has been superseded by 
 ITU-T Recommendations X.680-683 (1997).  All known
 defects in X.208 have been corrected in ITU-T 
 Recommendations X.680-683 (1997). Please note that 
 Rec. X.208 is scheduled for withdrawal.  If you are
 a protocol designer creating new ASN.1 notation, you
 should use the 1997 version of ASN.1 as defined in 
 ITU-T Recommendations X.680-683 (1997) instead of 
 using CCITT Recommendation X.208."

> >
> >
> Regards,
> Rich

Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
[phone]         1625 Glenwood Avenue, Five Points
[phone] [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------


Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12965 for <[e-mail]>; Wed, 10 May 2000 12:27:47 -0700 (PDT)
Received: from 216-164-137-102.s356.tnt4.lnhva.md.dialup.rcn.com ([216.164.137.102] helo=rankney) by smtp03.mrf.mail.rcn.net with smtp (Exim 2.12 #3) id 12pcEs-00060E-00; Wed, 10 May 2000 15:33:47 -0400
Message-ID: <035d01bfbab8$cb1baa80$6689a4d8@rankney>
From: "Rich Ankney" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: DER in ac509prof-03
Date: Wed, 10 May 2000 15:48:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

Simple; just update everything to ASN.1:1997 :-)

-----Original Message-----
From: Paul Koning <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, May 10, 2000 3:01 PM
Subject: Re: DER in ac509prof-03


>>>>>> "Rich" == Rich Ankney <[e-mail]> writes:
>
> Rich> I heard from a generally reliable source that ITU-T is going to
> Rich> cave in and distribute the ASN.1 specs (X.680 and X.690) for
> Rich> free via their website. 
>
>That would be cool.  But what about X.208-1988?  Given the discussion
>we just had, if *that* one isn't available (free or for money) we have
>a real problem.
>
>  paul



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12308 for <[e-mail]>; Wed, 10 May 2000 11:53:18 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiopn13464; Wed, 10 May 2000 18:59:17 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA29525; Wed, 10 May 00 14:55:54 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA28958; Wed, 10 May 2000 14:59:15 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 10 May 2000 14:59:15 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: Re: DER in ac509prof-03
References: <004d01bfbab1$55756d40$6689a4d8@rankney>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Rich" == Rich Ankney <[e-mail]> writes:

 Rich> I heard from a generally reliable source that ITU-T is going to
 Rich> cave in and distribute the ASN.1 specs (X.680 and X.690) for
 Rich> free via their website. 

That would be cool.  But what about X.208-1988?  Given the discussion
we just had, if *that* one isn't available (free or for money) we have
a real problem.

  paul


Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11766 for <[e-mail]>; Wed, 10 May 2000 11:34:24 -0700 (PDT)
Received: from 216-164-137-102.s356.tnt4.lnhva.md.dialup.rcn.com ([216.164.137.102] helo=rankney) by smtp03.mrf.mail.rcn.net with smtp (Exim 2.12 #3) id 12pbPD-000305-00; Wed, 10 May 2000 14:40:23 -0400
Message-ID: <004d01bfbab1$55756d40$6689a4d8@rankney>
From: "Rich Ankney" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: DER in ac509prof-03
Date: Wed, 10 May 2000 14:55:37 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

-----Original Message-----
From: Peter Gutmann <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, May 10, 2000 1:28 PM
Subject: Re: DER in ac509prof-03


>Paul Koning <[e-mail]> writes:
>
>>Also, while old RFCs are still available, 12 year old ITU specs may only
>>exist in antique shops by now.
>
>It's the same for ASN.1 books, Prof.Larmouth's book is for current versions
of
>ASN.1 rather than the obsolete versions referenced in RFC's, so it would
>probably do more to confuse than help.  The only reference for the obsolete
>variant of ASN.1 is Douglas Steedmans "Tutorial and Reference", which is
>useful for that version but doesn't apply to any current version.  This
book
>has been out of print for years, so you'd actually have to go to antique
>shops (well, used book stores) to find it.
>

Well, Larmouth's book does discuss these earlier artifacts (macros and
ANY DEFINED BY), although it's certainly not very detailed.

>>Clearly, it is not acceptable to have an RFC that points to an outside
>>standard unless that outside standard is available.
>
>It could be argued that the ASN.1 specs, being ISO standards, aren't
usefully
>"available" no matter whether it's an obsolete or current version which is
>being referenced :-).
>

I heard from a generally reliable source that ITU-T is going to cave in and
distribute the ASN.1 specs (X.680 and X.690) for free via their website.
I heard this about a month ago, and they are still charging, but after all
this
IS the ITU we're talking about.  Has anyone else heard this?
>Peter.
>
>
Regards,
Rich




Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05881 for <[e-mail]>; Wed, 10 May 2000 10:30:03 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA285042; Wed, 10 May 2000 13:33:53 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id NAA34140; Wed, 10 May 2000 13:35:16 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568DB.006099AB ; Wed, 10 May 2000 13:35:07 -0400
X-Lotus-FromDomain: IBMUS
To: Paul Koning <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 13:34:55 -0400
Subject: Re: DER in ac509prof-03
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     In practice, what we mean by "1988 syntax", as far as I can tell, is
pretty much the following:

1 -  Avoiding the following three types first defined in post-1988
versions: Instance-of, Embedded-pdv, and Unrestricted character string, and
adding explicit definitions for the Unicode string types which are copied
from X.680.
2 -  Continuing to use "ANY DEFINED BY", as defined in X.208 section 27 and
X.680 appendix H.3, rather than using constructs with similar meaning first
defined in 1993-4, such as information object classes and their fields.
3 -  Avoiding the use of either macros (legal in 1988) or information
object classes (legal after 1993-4).

     The only part of this which seems even questionable is point 2, but
X.680 still contains support for ANY DEFINED BY, although it is deprecated.
I was not at Adelaide, which partly accounts for my suggestion of 1993
support in AC509Prof.
     I don't think that the bits on the line change for BER between
X.209(1988) and X.690(1994) if the ASN.1 is legal 1988 syntax.  Does
anybody know of changes specific to DER?

          Tom Gindin

Paul Koning <[e-mail]> on 05/10/2000 12:27:54 PM

To:   [e-mail]
cc:   [e-mail], [e-mail],
      [e-mail]
Subject:  Re: DER in ac509prof-03



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

 Russ> I disagree.  We are using the ASN.1-1988 documents, not the
 Russ> 1997 ones.

 Russ> At 11:43 AM 05/10/2000 +0100, Stephen Farrell wrote:

 >> "DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]"
 >> is fine by me, anyone else care?

Are the two different?  That is, are there bitstrings that conform to
one but not the other, or whose meaning changes depending on which
spec you use?

I think Russ's position is problematic.  It's a bit like saying that
you continue to use an RFC that has been superseded.  Presumably it
was superseded for a reason.  Also, while old RFCs are still
available, 12 year old ITU specs may only exist in antique shops by
now.   Clearly, it is not acceptable to have an RFC that points to an
outside standard unless that outside standard is available.

     paul




Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02107 for <[e-mail]>; Wed, 10 May 2000 10:17:44 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA20492; Thu, 11 May 2000 05:23:41 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95797942127562>; Thu, 11 May 2000 05:23:41 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: DER in ac509prof-03
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 11 May 2000 05:23:41 (NZST)
Message-ID: <[e-mail]>

Paul Koning <[e-mail]> writes:

>Also, while old RFCs are still available, 12 year old ITU specs may only 
>exist in antique shops by now.   

It's the same for ASN.1 books, Prof.Larmouth's book is for current versions of
ASN.1 rather than the obsolete versions referenced in RFC's, so it would 
probably do more to confuse than help.  The only reference for the obsolete
variant of ASN.1 is Douglas Steedmans "Tutorial and Reference", which is 
useful for that version but doesn't apply to any current version.  This book
has been out of print for years, so you'd actually have to go to antique
shops (well, used book stores) to find it.

>Clearly, it is not acceptable to have an RFC that points to an outside 
>standard unless that outside standard is available.

It could be argued that the ASN.1 specs, being ISO standards, aren't usefully 
"available" no matter whether it's an obsolete or current version which is 
being referenced :-).

Peter.



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01543 for <[e-mail]>; Wed, 10 May 2000 09:56:09 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA07878; Wed, 10 May 2000 10:00:53 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 10 May 2000 12:59:22 -0400
To: Paul Koning <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: DER in ac509prof-03
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Paul:

Both generate identical bit strings.

This topic has been debated several times,and I do not think we should do 
it again on the list.  If you want to have a private discussion about it, I 
will be glad to do so.  The bottom line is that ASN.1-1997 does not have 
multiple implementations.

Russ


At 12:27 PM 05/10/2000 -0400, Paul Koning wrote:
> >>>>> "Russ" == Russ Housley <[e-mail]> writes:
>
>  Russ> I disagree.  We are using the ASN.1-1988 documents, not the
>  Russ> 1997 ones.
>
>  Russ> At 11:43 AM 05/10/2000 +0100, Stephen Farrell wrote:
>
>  >> "DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]"
>  >> is fine by me, anyone else care?
>
>Are the two different?  That is, are there bitstrings that conform to
>one but not the other, or whose meaning changes depending on which
>spec you use?
>
>I think Russ's position is problematic.  It's a bit like saying that
>you continue to use an RFC that has been superseded.  Presumably it
>was superseded for a reason.  Also, while old RFCs are still
>available, 12 year old ITU specs may only exist in antique shops by
>now.   Clearly, it is not acceptable to have an RFC that points to an
>outside standard unless that outside standard is available.
>
>         paul



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00845 for <[e-mail]>; Wed, 10 May 2000 09:25:46 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA07376; Wed, 10 May 2000 09:30:34 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 10 May 2000 12:29:20 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DER in ac509prof-03
Cc: [e-mail], [e-mail], xme <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yes.  The group was asked if anyone wanted to retain the ASN.1-1993 
Appendix, and no one cared enough to speak up.

Russ



At 04:38 PM 05/10/2000 +0100, Stephen Farrell wrote:

>Tom,
>
> >      The definition Phil referred to ("AttributeValue ::= ANY") should be
> > changed to
> > "AttributeValue ::= ANY DEFINED BY AttributeType", both here and in A.1 of
> > son-of-2459.
>
>No problem. 2459 does it that way in the text, but not in
>the ASN.1 module, which I guess must be where I copied it
>from.
>
> > Since only SecurityCategory, among the structures specific to
> > AC509Prof, actually uses any old-fashioned formats, it would be better
> > either to include documentation of the 1993 format in the draft (as in 2459
> > and son-of-2459) or to change it to be compatible with INSTANCE OF.
>
>Wasn't there consensus among the folks in Adelaide to expunge the '93
>ASN.1 from son-of-2459. I'm happy to follow whatever happens there,
>though I can't remember if this has come up on the list.
>
> > Including documentation of the 1993 format would not break existing
> > implementations (if there are any),
>
>There are.
>
>Regards,
>Stephen.
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>61 Fitzwilliam Lane,                    fax: [phone]
>Dublin 2.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00626 for <[e-mail]>; Wed, 10 May 2000 09:22:13 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiopd19020; Wed, 10 May 2000 16:27:55 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27556; Wed, 10 May 00 12:24:32 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA28769; Wed, 10 May 2000 12:27:54 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Wed, 10 May 2000 12:27:54 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: DER in ac509prof-03
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

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

 Russ> I disagree.  We are using the ASN.1-1988 documents, not the
 Russ> 1997 ones. 

 Russ> At 11:43 AM 05/10/2000 +0100, Stephen Farrell wrote:

 >> "DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]"
 >> is fine by me, anyone else care?

Are the two different?  That is, are there bitstrings that conform to
one but not the other, or whose meaning changes depending on which
spec you use?

I think Russ's position is problematic.  It's a bit like saying that
you continue to use an RFC that has been superseded.  Presumably it
was superseded for a reason.  Also, while old RFCs are still
available, 12 year old ITU specs may only exist in antique shops by
now.   Clearly, it is not acceptable to have an RFC that points to an
outside standard unless that outside standard is available.

	paul


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00273 for <[e-mail]>; Wed, 10 May 2000 09:13:49 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA07158; Wed, 10 May 2000 09:18:46 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 10 May 2000 12:17:40 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DER in ac509prof-03
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Phil:

You are correct.  In the 1988 series of documents, DER is defined as a 
short list of constraints on ASN.1, and those constraints are enumerated in 
X.509-1988.  We should Reference X.208-1988, X.209-1988, and X.509-1988 to 
provide all of the parts that people need.

I have no problem including a reference to the Larmouth book if people 
think that it will help implementors.

Russ

At 08:33 PM 05/09/2000 -0400, Phillip H. Griffin wrote:
>Hi there,
>
>In section 4.1, just after your use of the deprecated
>"ANY" notation, your profile states incorrectly that "DER
>is defined in [X.208-88]". X.208 defines Abstract Syntax
>Notation ONE (ASN.1), but it does not define any of the
>ASN.1 encoding rules.
>
>Way back in 1988, the time period to which you refer, the
>ASN.1 encoding rules were defined in X.209. Of course both
>X.208 and X.209 have been superseded and relegated along
>with their lists of unresolved defects to the maintenance
>site, at http://www.furniss.co.uk/maint/asn/index.html.
>
>In 1988, only BER existed as an ASN.1 standard, as defined
>in X.209 (though X.509:88 defined a set of restrictions on
>X.209 that they called DER). The DER, PER and CER encoding
>rules were not standardized until 1994. It could be that
>you are referring to "[X.509-88]" in your document rather
>than the current version of X.509 (which defines ACs) to
>try to include some sort of DER support for X.208/209 -
>hard to tell.
>
>The initial DER was created by Hoyt Kesterson's X.509 group.
>Out of their efforts, the ASN.1 DER rules evolved, and are
>now defined in the current ASN.1 standard, X.690. Though the
>spirit of X.509-88 and X.690:DER are the same, X.690:DER
>corrects a number of oversights present in X.509-88. These
>two rule sets differ in slight ways, particularly in how
>bit string values and a few other very small details are
>handled. These distinctions become important when digital
>signatures are involved.
>
>A good description of DER can be found in a free download
>copy of the recent ASN.1 book by John Larmouth, called ASN.1
>Complete, at http://www.nokalva.com/asn1/booksintro.html.
>Hard copy is also available from B&N (not for free I think).
>All of the wrinkles and warts are discussed. Worth a read
>if you have to deal often with such things.
>
>Phil
>----
>Phillip H. Griffin      Griffin Consulting
>http://asn-1.com        Secure ASN.1 Design & Implementation
>[phone]         1625 Glenwood Avenue, Five Points
>[phone] [fax]   Raleigh, North Carolina  27608  USA
>------------------------------------------------------------



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29900 for <[e-mail]>; Wed, 10 May 2000 09:08:55 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA07077; Wed, 10 May 2000 09:13:49 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 10 May 2000 12:12:42 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DER in ac509prof-03
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I disagree.  We are using the ASN.1-1988 documents, not the 1997 ones.

Russ


At 11:43 AM 05/10/2000 +0100, Stephen Farrell wrote:

>"DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]"
>is fine by me, anyone else care?
>
>I guess this should be the same in the son-of-2459 too.
>
>Stephen.
>
>"Phillip H. Griffin" wrote:
> >
> > Hi there,
> >
> > In section 4.1, just after your use of the deprecated
> > "ANY" notation, your profile states incorrectly that "DER
> > is defined in [X.208-88]". X.208 defines Abstract Syntax
> > Notation ONE (ASN.1), but it does not define any of the
> > ASN.1 encoding rules.
> >
> > Way back in 1988, the time period to which you refer, the
> > ASN.1 encoding rules were defined in X.209. Of course both
> > X.208 and X.209 have been superseded and relegated along
> > with their lists of unresolved defects to the maintenance
> > site, at http://www.furniss.co.uk/maint/asn/index.html.
> >
> > In 1988, only BER existed as an ASN.1 standard, as defined
> > in X.209 (though X.509:88 defined a set of restrictions on
> > X.209 that they called DER). The DER, PER and CER encoding
> > rules were not standardized until 1994. It could be that
> > you are referring to "[X.509-88]" in your document rather
> > than the current version of X.509 (which defines ACs) to
> > try to include some sort of DER support for X.208/209 -
> > hard to tell.
> >
> > The initial DER was created by Hoyt Kesterson's X.509 group.
> > Out of their efforts, the ASN.1 DER rules evolved, and are
> > now defined in the current ASN.1 standard, X.690. Though the
> > spirit of X.509-88 and X.690:DER are the same, X.690:DER
> > corrects a number of oversights present in X.509-88. These
> > two rule sets differ in slight ways, particularly in how
> > bit string values and a few other very small details are
> > handled. These distinctions become important when digital
> > signatures are involved.
> >
> > A good description of DER can be found in a free download
> > copy of the recent ASN.1 book by John Larmouth, called ASN.1
> > Complete, at http://www.nokalva.com/asn1/booksintro.html.
> > Hard copy is also available from B&N (not for free I think).
> > All of the wrinkles and warts are discussed. Worth a read
> > if you have to deal often with such things.
> >
> > Phil
> > ----
> > Phillip H. Griffin      Griffin Consulting
> > http://asn-1.com        Secure ASN.1 Design & Implementation
> > [phone]         1625 Glenwood Avenue, Five Points
> > [phone] [fax]   Raleigh, North Carolina  27608  USA
> > ------------------------------------------------------------
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>61 Fitzwilliam Lane,                    fax: [phone]
>Dublin 2.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29164 for <[e-mail]>; Wed, 10 May 2000 08:37:47 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.206]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA06606; Wed, 10 May 2000 08:43:11 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 10 May 2000 11:38:18 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: SMIME conformance specs
Cc: [e-mail]
In-Reply-To: <000601bf6340$8d7476a0$1a01a8c0@piers2k>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Piers:

Greeting old friend.

The S/MIME WG has not generated such a document.  However, RFC 2632 and RFC 
2633 do offer some advice on some of the issues.

Russ


At 12:19 PM 01/20/2000 +0000, Piers Chivers wrote:
>Hi,
>Are there any publicly available docs that describe the conformance
>requirements for a PKIX/SMIME compliant messaging client?
>
>I know that the SMIME RFCs detail the protocol requirements for a conforming
>app but I was thinking at the level of
>"A conforming client must indicate to the user when a message fails a
>signature validation" or "A user must be able to encrypt and/or sign an
>outgoing message".
>
>Thanks,
>Piers



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28862 for <[e-mail]>; Wed, 10 May 2000 08:32:22 -0700 (PDT)
Received: by balinese.baltimore.ie; id QAA23501; Wed, 10 May 2000 16:38:20 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma023453; Wed, 10 May 00 16:38:03 +0100
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA04008; Wed, 10 May 2000 16:38:01 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 16:38:25 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], xme <[e-mail]>, RussHousley <[e-mail]>
Subject: Re: DER in ac509prof-03
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,

>      The definition Phil referred to ("AttributeValue ::= ANY") should be
> changed to
> "AttributeValue ::= ANY DEFINED BY AttributeType", both here and in A.1 of
> son-of-2459.  

No problem. 2459 does it that way in the text, but not in 
the ASN.1 module, which I guess must be where I copied it
from.

> Since only SecurityCategory, among the structures specific to
> AC509Prof, actually uses any old-fashioned formats, it would be better
> either to include documentation of the 1993 format in the draft (as in 2459
> and son-of-2459) or to change it to be compatible with INSTANCE OF.

Wasn't there consensus among the folks in Adelaide to expunge the '93 
ASN.1 from son-of-2459. I'm happy to follow whatever happens there, 
though I can't remember if this has come up on the list.

> Including documentation of the 1993 format would not break existing
> implementations (if there are any), 

There are. 

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28500 for <[e-mail]>; Wed, 10 May 2000 08:22:12 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA117016; Wed, 10 May 2000 11:26:27 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id LAA165296; Wed, 10 May 2000 11:27:49 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568DB.0054EE88 ; Wed, 10 May 2000 11:27:40 -0400
X-Lotus-FromDomain: IBMUS
To: Robert Moskowitz <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 11:27:33 -0400
Subject: Re: ASN.1 Name joys
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     My own suggestions are:

1 -  Include all imported objects with dependencies other than Universal
types.
2 -  Include a table with the Universal tags for string types and times.
3 -  Include EXPLICIT or IMPLICIT on every context-specific tag.  This is
not done primarily to deter the unnecessary use of context-specific tags,
although it may well have that effect.
4 -  If it is thought that #1 and #3 involve copyright problems, require
that every import statement include a note as to whether the objects
defined by that import are implicitly or explicitly typed.  This is an
inferior alternative to #1 and #3.

     I realize that my suggestion in #3 directly contradicts X.680:94
section F.2.12.5, but since that section is not an integral part of the
standard and it is followed immediately by F.2.12.6, which appears to
believe that context-specific tags can be avoided in SET's and CHOICE's by
adding new elements to the end, I don't have to assume that the section
author's views are any more valid than my own.

          Tom Gindin

Robert Moskowitz <[e-mail]> on 05/05/2000 04:00:23 PM

To:   [e-mail]
cc:
Subject:  ASN.1 Name joys



I have just completed a 3 day CMP2000 interop workshop (email me if you
wish to participate in the next one 1st week in June).

In the days preceeding and during we yet again had vendors experiencing
ASN.1 coding problems with Name.

I have had threads as follows:

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

now I have examined the problem [with your ir] in more detail: Our Code
has problems with the field 'subject' [5] in the CertTemplate: The subject
is a NAME and the default for tagging in the CertTemplate SEQUENCE
is IMPLICIT.

Now the problem is, that the NAME  is a CHOICE and for a CHOICE
it is not allowed to use IMPLICIT tagging (see the ASN.1 specification).
So, in the case of  NAME one has to use an EXPLICIT tagging.

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

Then I get others like:

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

my interpretation of the PKIHeader->sender/recipient field was
as follows:

both sender and recipient are defined to be of type GeneralName...

      PKIHeader ::= SEQUENCE {
          pvno                INTEGER     { ietf-version2 (1) },
          sender              GeneralName,
          -- identifies the sender
          recipient           GeneralName,
          -- identifies the intended recipient
          messageTime     [0] GeneralizedTime         OPTIONAL,
          <snip>

which is defined in the IMPORTS as:  FROM PKIX1Implicit88

which is defined in RFC-2459 as:

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

therefore it should be tagged as IMPLICIT
and, it can be any number of underlying structures.

so, a Name, although a SEQUENCE by definition, would be implicitly tagged
as [4] { SET{}  SET{} ... }, not SEQUENCE { SET{}  SET{} ... }

otherwise, the underlying name type would not be so easily determined.

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

As you might imagine, it is challenging to work on CMP interoperablity when
there are questions about 2459 conformance.

Not everyone will be (or want to be) ASN.1 war heros.

What can we do with 2459bis to stop the flow of coding errors????

Do we need an informational RFC giving ASN.1 coding rules so that people do
not have to get the X. whatever???

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]





Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27994 for <[e-mail]>; Wed, 10 May 2000 08:07:22 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA125380; Wed, 10 May 2000 11:11:40 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id LAA92576; Wed, 10 May 2000 11:12:57 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568DB.005393FE ; Wed, 10 May 2000 11:12:53 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 11:12:45 -0400
Subject: Re: DER in ac509prof-03
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     The definition Phil referred to ("AttributeValue ::= ANY") should be
changed to
"AttributeValue ::= ANY DEFINED BY AttributeType", both here and in A.1 of
son-of-2459.  Since only SecurityCategory, among the structures specific to
AC509Prof, actually uses any old-fashioned formats, it would be better
either to include documentation of the 1993 format in the draft (as in 2459
and son-of-2459) or to change it to be compatible with INSTANCE OF.
Including documentation of the 1993 format would not break existing
implementations (if there are any), while changes to use INSTANCE OF would.

     Here are my suggestions (1-2 form the 1993 definition of the existing
SecurityCategory type with its own class, 3 is a 1993 definition of
SecurityCategory with the existing Attribute class, 4 is the 1988 version
of INSTANCE OF, 5 is the 1993 use of INSTANCE OF):

1)   SecurityCATEGORY               ::=     CLASS {
          &Type,
          &id  OBJECT IDENTIFIER UNIQUE }
     WITH SYNTAX { WITH SYNTAX &Type ID &id }

2)   SecurityCategory       ::=     SEQUENCE {
          type [0] IMPLICIT SecurityCATEGORY.&id,
          value     [1] EXPLICIT SecurityCATEGORY.&Type }

3)   SecurityCategory    ::=  SEQUENCE {
          type [0] IMPLICIT Attribute.&attributeId,
          value     [1] IMPLICIT Attribute.&attributeType    }

4)   SecurityCategory    ::=  [UNIVERSAL 8] IMPLICIT SEQUENCE {
          type OBJECT IDENTIFIER,
          value     [0] EXPLICIT ANY DEFINED BY type    }

5)   SecurityCategory    ::=  INSTANCE OF TYPE-IDENTIFIER

     Any corrections or suggestions are welcome.

          Tom Gindin


Stephen Farrell <[e-mail]> on 05/10/2000 06:43:04 AM

Please respond to [e-mail]

To:   [e-mail]
cc:   [e-mail]
Subject:  Re: DER in ac509prof-03




"DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]"
is fine by me, anyone else care?

I guess this should be the same in the son-of-2459 too.

Stephen.

"Phillip H. Griffin" wrote:
>
> Hi there,
>
> In section 4.1, just after your use of the deprecated
> "ANY" notation, your profile states incorrectly that "DER
> is defined in [X.208-88]". X.208 defines Abstract Syntax
> Notation ONE (ASN.1), but it does not define any of the
> ASN.1 encoding rules.
>
> Way back in 1988, the time period to which you refer, the
> ASN.1 encoding rules were defined in X.209. Of course both
> X.208 and X.209 have been superseded and relegated along
> with their lists of unresolved defects to the maintenance
> site, at http://www.furniss.co.uk/maint/asn/index.html.
>
> In 1988, only BER existed as an ASN.1 standard, as defined
> in X.209 (though X.509:88 defined a set of restrictions on
> X.209 that they called DER). The DER, PER and CER encoding
> rules were not standardized until 1994. It could be that
> you are referring to "[X.509-88]" in your document rather
> than the current version of X.509 (which defines ACs) to
> try to include some sort of DER support for X.208/209 -
> hard to tell.
>
> The initial DER was created by Hoyt Kesterson's X.509 group.
> Out of their efforts, the ASN.1 DER rules evolved, and are
> now defined in the current ASN.1 standard, X.690. Though the
> spirit of X.509-88 and X.690:DER are the same, X.690:DER
> corrects a number of oversights present in X.509-88. These
> two rule sets differ in slight ways, particularly in how
> bit string values and a few other very small details are
> handled. These distinctions become important when digital
> signatures are involved.
>
> A good description of DER can be found in a free download
> copy of the recent ASN.1 book by John Larmouth, called ASN.1
> Complete, at http://www.nokalva.com/asn1/booksintro.html.
> Hard copy is also available from B&N (not for free I think).
> All of the wrinkles and warts are discussed. Worth a read
> if you have to deal often with such things.
>
> Phil
> ----
> Phillip H. Griffin      Griffin Consulting
> http://asn-1.com        Secure ASN.1 Design & Implementation
> [phone]         1625 Glenwood Avenue, Five Points
> [phone] [fax]   Raleigh, North Carolina  27608  USA
> ------------------------------------------------------------

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22139 for <[e-mail]>; Wed, 10 May 2000 04:04:21 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA26235; Wed, 10 May 2000 13:10:13 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 10 May 2000 13:10:14 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA12235; Wed, 10 May 2000 13:10:12 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA18503; Wed, 10 May 2000 13:10:11 +0200 (MET DST)
Date: Wed, 10 May 2000 13:10:11 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Who can be a Time Stamping Authority?
Cc: [e-mail]

> 
> In the second case, the TSA certificate should contain an extension, which
> would indicate that this TSA may issue time stamping tokens within that CA
> realm.  Since RFC2459 is currently being revised and as suggested by Michael
What does mean 'issue time stamping tokens withing that CA realm'?

> Zolotarev, the Authority Information Access extension does not seem
> appropriate for this particular purpose, I would suggest that a new private
> Internet extension should probably be added in RFC2459 to achieve this
> requirement.
>
It seems to me that what is required is a kind of 'Subject Information Access'
extension as it was available in earlier drafts. The definition is similar
to the AIA by replacing 'issuer' by 'subject'.
 

Another possibility is to change in 2459:

   The authority information access extension indicates how to access CA
   information and services for the issuer of the certificate in which
   the extension appears. 

to

   The aia extension indicates how to access services related to the certificate
   in which the extension appears. 

The definition of accessMethod must describe anyway how the extension has to be
interpreted. 


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21102 for <[e-mail]>; Wed, 10 May 2000 03:37:02 -0700 (PDT)
Received: by balinese.baltimore.ie; id LAA29594; Wed, 10 May 2000 11:42:59 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma029563; Wed, 10 May 00 11:42:41 +0100
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA18292; Wed, 10 May 2000 11:42:39 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 May 2000 11:43:04 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: DER in ac509prof-03
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"DER is defined in [X.208-88]" -> "DER is defined in [X.690-97]" 
is fine by me, anyone else care? 

I guess this should be the same in the son-of-2459 too.

Stephen.

"Phillip H. Griffin" wrote:
> 
> Hi there,
> 
> In section 4.1, just after your use of the deprecated
> "ANY" notation, your profile states incorrectly that "DER
> is defined in [X.208-88]". X.208 defines Abstract Syntax
> Notation ONE (ASN.1), but it does not define any of the
> ASN.1 encoding rules.
> 
> Way back in 1988, the time period to which you refer, the
> ASN.1 encoding rules were defined in X.209. Of course both
> X.208 and X.209 have been superseded and relegated along
> with their lists of unresolved defects to the maintenance
> site, at http://www.furniss.co.uk/maint/asn/index.html.
> 
> In 1988, only BER existed as an ASN.1 standard, as defined
> in X.209 (though X.509:88 defined a set of restrictions on
> X.209 that they called DER). The DER, PER and CER encoding
> rules were not standardized until 1994. It could be that
> you are referring to "[X.509-88]" in your document rather
> than the current version of X.509 (which defines ACs) to
> try to include some sort of DER support for X.208/209 -
> hard to tell.
> 
> The initial DER was created by Hoyt Kesterson's X.509 group.
> Out of their efforts, the ASN.1 DER rules evolved, and are
> now defined in the current ASN.1 standard, X.690. Though the
> spirit of X.509-88 and X.690:DER are the same, X.690:DER
> corrects a number of oversights present in X.509-88. These
> two rule sets differ in slight ways, particularly in how
> bit string values and a few other very small details are
> handled. These distinctions become important when digital
> signatures are involved.
> 
> A good description of DER can be found in a free download
> copy of the recent ASN.1 book by John Larmouth, called ASN.1
> Complete, at http://www.nokalva.com/asn1/booksintro.html.
> Hard copy is also available from B&N (not for free I think).
> All of the wrinkles and warts are discussed. Worth a read
> if you have to deal often with such things.
> 
> Phil
> ----
> Phillip H. Griffin      Griffin Consulting
> http://asn-1.com        Secure ASN.1 Design & Implementation
> [phone]         1625 Glenwood Avenue, Five Points
> [phone] [fax]   Raleigh, North Carolina  27608  USA
> ------------------------------------------------------------

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA05468 for <[e-mail]>; Tue, 9 May 2000 23:39:00 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id QAA00716; Wed, 10 May 2000 16:49:22 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <K4L8ND56>; Wed, 10 May 2000 16:43:32 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Who can be a Time Stamping Authority?
Date: Wed, 10 May 2000 16:43:32 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

I guess a need to clarify a few points here, to avoid possible
misunderstanding about my opinion.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, May 10, 2000 4:04 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Who can be a Time Stamping Authority?
> 

> it is not clear how the requester could verify the validity of the TSA
self signed 
> certificate as part of validating the digital signature of the
TimeStampToken.  This would probably be a good reason for a
> TSA self signed certificate to contain an Authority Information Access
extension [RFC2459] as suggested 
> by Michael Zolotarev, which could indicate how to access the on-line
validation services for the TSA certificate. 
> Otherwise, the TSA self signed certificate should probably contain a CRL
distribution points extension to indicate where to
> find the status of the TSA certificate.
>
This is not what I was saying, actually. I was saying that the only reason
for AIA to be present in self-signed TSA certificates is to specify the
access mechanism to the TSA. In addition, AIA in CA-issued TSA certs CAN NOT
be used for that purpose (specifying the access mechanism to the TSA).
What you are proposing - using the AIA for checking the status of a
self-signed TSA cert - is not going to work, I'd say. This is a problem with
self-issued certificates - you can not trust its own claim about its
revocation status.

So, coming back to my original point, the only reason I can see for a
self-signed TSA cert to have the AIA extension is to specify the access
mechanism for obtaining timestamps. Leaving aside the practicality of it,
and the point that probably AIA is not the best candidate for it. In either
case, the draft should be more explicit about using AIA.

 
> In the second case, the TSA certificate should contain an extension, which
would indicate that this TSA may issue time
> stamping tokens within that CA realm.  Since RFC2459 is currently being
revised and as suggested by Michael Zolotarev, the
> Authority Information Access extension does not seem appropriate for this
particular purpose, I would suggest that a new
> private Internet extension should probably be added in RFC2459 to achieve
this requirement.
> 
It did not occur to me that a CA may want to designate a TSA as a "Domain
TSA", by placing a special mark into the TSA's certificate. My first
impression is that by doing that the CA would embark on a slippery path of
taking responsibility of TSA operations. Unless this is really the case, and
the CA fully owns/operates the TSA. 
Yet, considering that this can be a real situation, I do not see why the AIA
extension can not be used for that (which is different from your point,
Francois :). It does not contradict to the definition of AIA. The extension
is used by the CA to announce to the world: This is my OCSP. This is my
policy data. <<This is my recommended TS provider for the domain>>. Why not?


To explain all that, the only thing the current draft would have to say is 
***
"If a TSA certificate is NOT a self-signed certificate, and it contains the
AIA extension, the extension MAY be used to indicate that the TSA is closely
associated with the issuing CA's domain.  That is, the CA MAY designate the
TSA to be the 'domain TSA'. In this case, the accessMethod field in this
extension MUST contain the OID id-ad-timestamping, and the accessLocation
field defining the protocol. Note that it is different from just defining
the extKeyUsage=id-kp-timeStamping".
 

Best regards
Michael



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10865 for <[e-mail]>; Tue, 9 May 2000 18:43:09 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA16591; Wed, 10 May 2000 11:54:05 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <KT8TVRTB>; Wed, 10 May 2000 11:48:26 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail], Michael Zolotarev <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Wed, 10 May 2000 11:48:26 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Francois,

> However, the problem I see with a published TSA practice 
> statement is that
> it would not currently lend itself to automation unless XML 
> was used.  This
> is why in the first place I had suggested using the S/MIME 
> capabilities
> attribute to indicate any static information about TSA's capabilities.

I do not think, really, that a TSA client will need to be 'automated', as
opposing to been statically configured for using a particular TSA(s). You'd
never let a TSA client 'go in the wild and free hunt' for some TSA service
out there. The cost, the legal liabilities, the quality of service and a lot
of other factors contribute to the fact that a decision has to be taken to
which TSA to use. Before the TSA can be first used by the client. You
configure the client, telling it to use THAT TSA, with THAT hash algorithm,
with THAT TSA certificate or some other trust parameters. I see the
configuration of the client to be an essentual part of the whole
timestamping framework. But it is just my opinion.

I agree that having the TSA policy and capabilities structured as XML would
help automating the client configuration task.

> Checking the S/MIME capabilities attribute should not be a 
> major issue for a
> requestor since he/she must be able to use S/MIME to verify 
> the integrity of
> a TimeStampToken.
> 

timeStampToken is defined as basic CMS construct. The requestor does not
have to implement/use/understand full S/MIME in order to parse the token. 


> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] Ext. 419
> http://www.chrysalis-its.com       Fax. [phone]
> 


Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00182 for <[e-mail]>; Tue, 9 May 2000 17:25:19 -0700 (PDT)
Received: from asn-1.com (user-2ivf68s.dialup.mindspring.com [165.247.153.28]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id UAA06785 for <[e-mail]>; Tue, 9 May 2000 20:31:14 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 09 May 2000 20:33:53 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting 
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: DER in ac509prof-03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi there,

In section 4.1, just after your use of the deprecated 
"ANY" notation, your profile states incorrectly that "DER
is defined in [X.208-88]". X.208 defines Abstract Syntax
Notation ONE (ASN.1), but it does not define any of the
ASN.1 encoding rules.

Way back in 1988, the time period to which you refer, the
ASN.1 encoding rules were defined in X.209. Of course both
X.208 and X.209 have been superseded and relegated along
with their lists of unresolved defects to the maintenance
site, at http://www.furniss.co.uk/maint/asn/index.html.

In 1988, only BER existed as an ASN.1 standard, as defined
in X.209 (though X.509:88 defined a set of restrictions on
X.209 that they called DER). The DER, PER and CER encoding
rules were not standardized until 1994. It could be that
you are referring to "[X.509-88]" in your document rather
than the current version of X.509 (which defines ACs) to
try to include some sort of DER support for X.208/209 - 
hard to tell. 

The initial DER was created by Hoyt Kesterson's X.509 group. 
Out of their efforts, the ASN.1 DER rules evolved, and are
now defined in the current ASN.1 standard, X.690. Though the
spirit of X.509-88 and X.690:DER are the same, X.690:DER 
corrects a number of oversights present in X.509-88. These
two rule sets differ in slight ways, particularly in how 
bit string values and a few other very small details are 
handled. These distinctions become important when digital
signatures are involved.

A good description of DER can be found in a free download 
copy of the recent ASN.1 book by John Larmouth, called ASN.1
Complete, at http://www.nokalva.com/asn1/booksintro.html. 
Hard copy is also available from B&N (not for free I think).
All of the wrinkles and warts are discussed. Worth a read 
if you have to deal often with such things.

Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
[phone]         1625 Glenwood Avenue, Five Points
[phone] [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24961 for <[e-mail]>; Tue, 9 May 2000 11:27:00 -0700 (PDT)
Received: by balinese.baltimore.ie; id TAA21203; Tue, 9 May 2000 19:32:48 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma021196; Tue, 9 May 00 19:32:31 +0100
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id TAA22727; Tue, 9 May 2000 19:32:30 +0100
Message-ID: <[e-mail]>
Date: Tue, 09 May 2000 19:32:52 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andy Dowling <[e-mail]>
CC: [e-mail], xme <[e-mail]>
Subject: Re: AC profile - Policy Authority on the Role attribute
References: <[e-mail]> <003201bfb9c9$acf2c6a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Andy,

When I first looked at it, I thought we'd left this out simply
to make things easier, but since that didn't actually sound right,
I checked, and there is a real reason.

X.509 says: "The roleAuthority, if present, identifies the recognized 
authority that is responsible for issuing the role specification 
certificate"

And given that we have to be compatible with X.509 and don't want 
to complicate the profile by introducing "role specification 
certificates", I think we do have to mandate not using the
roleAuthority.

Regards,
Stephen.

Andy Dowling wrote:
> 
> section 4.4.5 of the ac profile document states the following:
> 
>    The roleAuthority field MUST NOT be used. The roleName field MUST be
>    present, and roleName MUST use the uniformResourceIdentifier CHOICE
>    of the GeneralName.
> 
> This means that we cannot define a policy authority for the role attribute!
> :-(
> Previously, where we used IETFAttrSyntax, we were able to qualify the
> attribute
> in this way.
> 
> Could we change the profile to allow the use of roleAuthority, i.e.:
> 
>    The roleAuthority field MAY be used to specify the issuing authority of
> the role attribute.
>    The roleName field MUST be
>    present, and roleName MUST use the uniformResourceIdentifier CHOICE
>    of the GeneralName.
> 
> Any comments?
> 
> Andy

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24185 for <[e-mail]>; Tue, 9 May 2000 10:57:34 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <KLC3NAV6>; Tue, 9 May 2000 14:04:15 -0400
Message-ID: <7E8CCF56F7F8D211894700104B9DF96DA2614B@NTSERVER2>
To: [e-mail]
Cc: [e-mail]
Subject: Who can be a Time Stamping Authority?
Date: Tue, 9 May 2000 14:04:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Salut Denis,

At paragraph 10 of Section 2.1 of the TSA Draft, it is mentioned that "a TSA
is REQUIRED to sign each time stamp token using a key generated exclusively
for this purpose and have this property of the key indicated on the
corresponding certificate".

This specific requirement explicitly excludes CAs that would want to offer a
time stamping service using the same key that they commonly used to sign
certificates and/or certificate status information (i.e. CRL or OCSP), which
is fine with me.

This then leave two cases that I think you should describe in the TSA draft:

a.  a TSA with a self signed certificate whose public key is trusted by the
requester; or

b.  a CA designated TSA who holds a specially marked certificate issued
directly by the CA, indicating that the TSA may be trusted to issue time
stamping tokens.

In the first case, each requester must obtain the TSA self signed
certificate by some (out-of-band) authenticated process, which would be
outside the scope of this TSA document.  Because it is mentioned in Section
2.2 of the TSA Draft that the requesting entity SHALL verify the validity of
the digital signature of the TimeStampToken, it is not clear how the
requester could verify the validity of the TSA self signed certificate as
part of validating the digital signature of the TimeStampToken.  This would
probably be a good reason for a TSA self signed certificate to contain an
Authority Information Access extension [RFC2459] as suggested by Michael
Zolotarev, which could indicate how to access the on-line validation
services for the TSA certificate.  Otherwise, the TSA self signed
certificate should probably contain a CRL distribution points extension to
indicate where to find the status of the TSA certificate.

In the second case, the TSA certificate should contain an extension, which
would indicate that this TSA may issue time stamping tokens within that CA
realm.  Since RFC2459 is currently being revised and as suggested by Michael
Zolotarev, the Authority Information Access extension does not seem
appropriate for this particular purpose, I would suggest that a new private
Internet extension should probably be added in RFC2459 to achieve this
requirement.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] Ext. 419
http://www.chrysalis-its.com       Fax. [phone]


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23851 for <[e-mail]>; Tue, 9 May 2000 10:49:19 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <KLC3NAVF>; Tue, 9 May 2000 13:56:00 -0400
Message-ID: <7E8CCF56F7F8D211894700104B9DF96DA2614A@NTSERVER2>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Tue, 9 May 2000 13:55:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Michael,

>The same about hash algorithms supported by the TSA for messageImprints -
>the TSA should accept all 'common' types. If it does not understand the
>algorithm's OID, the error will be returned to the client. So that the
>client will have to try a different algorithm. With makes it nothing but
>ugly, making me to believe any static information about TSA's capabilities
>should be communicated separately from the actual TSA responses. The client
>should discover the capabilities of the TSA before transacting, out-of-band
>or from some published TSA practice statement.
>
>Regards
>Michael

However, the problem I see with a published TSA practice statement is that
it would not currently lend itself to automation unless XML was used.  This
is why in the first place I had suggested using the S/MIME capabilities
attribute to indicate any static information about TSA's capabilities.
Checking the S/MIME capabilities attribute should not be a major issue for a
requestor since he/she must be able to use S/MIME to verify the integrity of
a TimeStampToken.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] Ext. 419
http://www.chrysalis-its.com       Fax. [phone]


Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23285; Tue, 9 May 2000 10:36:53 -0700 (PDT)
Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST)
Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd>
From: "Charlie Fletcher - www.ukdata.com" <[e-mail]>
To: "Finance Director" <[e-mail]>
Subject: Instant On-Line Credit Reports
Date: Tue, 9 May 2000 16:34:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

Do you need fast accurate information to assist you when appraising
potential customers, and suppliers?

The UK Data internet website www.ukdata.com contains 28 million pages of
data with full information on every UK company!

Credit Reports-Director Searches-Accounts-Annual Returns

All of these products and many more are available to you immediately, and
can be downloaded to and printed from your personal computer.

Free samples of all reports are available at www.ukdata.com.

Please also visit www.formacompany.co.uk the on-line company formation
website

Thank You

Charles Fletcher
www.ukdata.com an instant report on every UK business
www.formacompany.co.uk the on-line company formation site
www.irishdata.ie - instant reports on all Irish companies













Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22828 for <[e-mail]>; Tue, 9 May 2000 10:21:37 -0700 (PDT)
Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id TAA12179 for <[e-mail]>; Tue, 9 May 2000 19:27:17 +0200 (CEST)
Message-ID: <061e01bfb9db$d2f7ba10$0c7011ac@SZOTKOWSKI>
From: "Martin Szotkowski" <[e-mail]>
To: <[e-mail]>
Subject: SubjectAltName verification
Date: Tue, 9 May 2000 19:27:16 +0200
Organization: PVT, a.s.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Hi all,
in RFC2459 (4.2.1.7) call :
>>Because the subject alternative name is considered to be definitively
bound to the publick key, all parts of the subject alternative name MUST be
verified by the CA.<<
What exactly this means?
Must be e.g. email unique in one CA? must be unique for one man?
If yes, is there any way to determine that this man has this email? (How
this problem is resolving for DNS, IP, URI, etc.?)
If no, someone can stand out for some else in email communication?

thanks for explanation
Martin





Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA20515 for <[e-mail]>; Tue, 9 May 2000 08:14:21 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Tue, 9 May 2000 16:17:50 +0100
Received: from taalap (taa-lap.sse.ie [193.120.32.86]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id QAA08103 for <[e-mail]>; Tue, 9 May 2000 16:17:38 +0100 (BST)
Message-ID: <003201bfb9c9$acf2c6a0$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: AC profile - Policy Authority on the Role attribute
Date: Tue, 9 May 2000 16:17:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

section 4.4.5 of the ac profile document states the following:

   The roleAuthority field MUST NOT be used. The roleName field MUST be
   present, and roleName MUST use the uniformResourceIdentifier CHOICE
   of the GeneralName.

This means that we cannot define a policy authority for the role attribute!
:-(
Previously, where we used IETFAttrSyntax, we were able to qualify the
attribute
in this way.

Could we change the profile to allow the use of roleAuthority, i.e.:

   The roleAuthority field MAY be used to specify the issuing authority of
the role attribute.
   The roleName field MUST be
   present, and roleName MUST use the uniformResourceIdentifier CHOICE
   of the GeneralName.

Any comments?

Andy







Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14068 for <[e-mail]>; Tue, 9 May 2000 03:30:42 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13936; Tue, 9 May 2000 06:36:34 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ac509prof-03.txt
Date: Tue, 09 May 2000 06:36:34 -0400
Sender: [e-mail]

--NextPart

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

	Title		: An Internet Attribute Certificate Profile for 
                          Authorization
	Author(s)	: S. Farrell, R. Housley 
	Filename	: draft-ietf-pkix-ac509prof-03.txt
	Pages		: 38
	Date		: 08-May-00
	
This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements.  The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04900 for <[e-mail]>; Tue, 9 May 2000 00:44:28 -0700 (PDT)
Received: from [38.29.122.67] (ip67.phoenix10.az.pub-ip.psi.net [38.29.122.67]) by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id AAA22144; Tue, 9 May 2000 00:49:33 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a04310102b53d71357780@[38.29.122.67]>
Date: Tue, 9 May 2000 00:46:46 -0700
To: OSI Directory List <[e-mail]>, [e-mail]
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: revised 4th edition text
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

minor errors have been corrected in the x.509 text over the last 
month. the revised text has been placed on the server as

 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV3.doc

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV3.pdf

the changes have been very minor. the asn.1 errors that have been corrected -

  import the right edition of x.400

  the six places in the text where baseCertificateId occured has been 
changed to baseCertificateID

    hoyt


Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24189 for <[e-mail]>; Mon, 8 May 2000 14:56:29 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12903; Mon, 8 May 2000 15:02:08 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 2797 on Certificate Management Messages over CMS
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 08 May 2000 15:02:08 -0700
From: RFC Editor <[e-mail]>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2797

        Title:	    Certificate Management Messages over CMS
        Author(s):  M. Myers, X. Liu, J. Schaad, J. Weinstein
        Status:     Standards Track
	Date:       April 2000
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      47
        Characters: 103357
        Updates/Obsoletes/SeeAlso: None

        URL:        ftp://ftp.isi.edu/in-notes/rfc2797.txt


This document defines a Certificate Management protocol using CMS
(CMC).  This protocol addresses two immediate needs within the
Internet PKI community:

1. The need for an interface to public key certification products and
   services based on [CMS] and [PKCS10], and

2. The need in [SMIMEV3] for a certificate enrollment protocol for
   DSA-signed certificates with Diffie-Hellman public keys.

A small number of additional services are defined to supplement the
core certificate request service.
 
Throughout this specification the term CMS is used to refer to both
[CMS] and [PKCS7].  For both signedData and envelopedData, CMS is a
superset of the PKCS7. In general, the use of PKCS7 in this document
is aligned to the Cryptographic Message Syntax [CMS] that provides a
superset of the PKCS7 syntax. The term CMC refers to this
specification.

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited. 

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc2797

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2797.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from sentry.gw.tislabs.com ([e-mail] [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15510 for <[e-mail]>; Mon, 8 May 2000 06:06:41 -0700 (PDT)
Received: by sentry.gw.tislabs.com; id JAA27640; Mon, 8 May 2000 09:14:09 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma027634; Mon, 8 May 00 09:13:43 -0400
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA06984 for [e-mail]; Mon, 8 May 2000 09:07:08 -0400 (EDT)
Date: Mon, 8 May 2000 09:07:08 -0400 (EDT)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01)

            C  A  L  L       F  O  R       P  A  P  E  R  S


                          The Internet Society
         2001 Network and Distributed System Security Symposium
                               (NDSS'01)

                           February 7-9, 2001

                Catamaran Resort, San Diego, California


                            IMPORTANT DATES
          Paper Submission due:           August 2, 2000
          Author Notification:            September 27, 2000
          Camera-ready final papers due:  October 31, 2000


GOAL: 
  This symposium will foster information exchange among researchers 
  and practioners of network and distributed system security 
  services.  The intended audience includes those who are interested 
  in the practical aspects of network and distributed system security,
  focusing on actual system design and implementation, rather than
  theory.  A major goal of the symposium is to encourage and enable 
  the Internet community to apply, deploy, and advance the state of
  available security technology.  The proceedings of the symposium 
  will be published by the Internet Society.

Submissions are solicited for, but are not limited to, the following
topics:
 * Secure Electronic Commerce: e.g., payment, barter, EDI,
   notarization/timestamping, endorsement and licensing.
 * Intellectual Property Protection: protocols, schemas,
   implementations, metering, watermarking, other forms of rights
   management.
 * Implementation, deployment and management of network security
   policies.
 * Integrating Security in Internet protocols: routing, naming,
   TCP/IP, multicast, network management, and the Web.
 * Attack-resistant protocols and services.
 * Special problems and case studies: e.g., interplay and tradeoffs
   between security and efficiency, usability, reliability and cost.
 * Security for collaborative applications and services: tele- and
   video-conferencing, groupwork, etc.
 * Fundamental services: authentication, data integrity,
   confidentiality, authorization, non-repudiation, and availability.
 * Supporting mechanisms and APIs: key management and certification,
   revocation, audit trails and accountability.
 * Public Key Infrastructure.
 * Integrating security services with system and application security
   facilities and protocols: e.g., message handling, file
   transport/access, directories, time synchronization, database
   management, boot services, mobile computing.
 * Security for emerging technologies: sensor networks, specialized
   testbeds, wireless/mobile (and ad hoc) networks, personal
   communication systems, and large heterogeneous distributed systems.
 * Intrusion Avoidance, Detection, and Response: systems, experiences
   and architectures.
 * Network Perimeter Controls: firewalls, packet filters, application
   gateways.
 * Virtual Private Networks.


BEST PAPER AWARD:
  There will be a best paper award again this year. The award will
  be presented at the symposium to the authors of the best overall
  paper as selected by the Program Committee.


SUBMISSIONS:
  The Program Committee invites both technical papers and panel
  proposals. Technical papers should be at most 20 pages long. Panel
  proposals should be at most two pages and should describe the
  topic, identify the panel chair, explain the format of the panel,
  and list three to four potential panelists. Technical papers will
  appear in the proceedings. A description of each panel will appear
  in the proceedings, and may - at the discretion of the panel chair
  - include written position statements from the panelists.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify the
  contact author in case of multi-author submissions. The names of
  authors, affiliations, and other identifying information should
  appear only on the separate title page. Submissions must be
  received by August 2, 2000, and must be made via electronically
  in either PostScript or ASCII format. If the Committee is unable
  to print a PostScript submission, a hardcopy will be requested.
  Therefore, PostScript submissions must arrive well before the
  deadline.

  Submission information can be found at
  http://www.isoc.org/ndss01/cfp. Dates, final call for papers,
  advance program, and registration information will be available
  soon at http://www.isoc.org/ndss01.

  Each submission will be acknowledged by e-mail. If acknowledgment
  is not received within seven days, please contact the program
  Co-chairs as indicated below. Authors and panelists will be
  notified of acceptance by September 27, 2000. Instructions for
  preparing camera-ready copy for the proceedings will be sent at
  that time. The camera-ready copy must be received by October 31,
  2000.


GENERAL CHAIR: 
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Avi Rubin, AT&T Labs - Research
  Paul Van Oorschot, Entrust Technologies

TUTORIAL CHAIR:
  Eric Harder, National Security Agency

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  Mahesh Tripunitara, Purdue University

PUBLICITY CHAIR:
  David Balenson, NAI Labs, Network Associates

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

PROGRAM COMMITTEE:
  Bennet Yee, University of California San Diego
  Bill Cheswick, Bell Labs
  Dave Kormann, AT&T Labs - Research
  David Aucksmith, Intel Corportation
  David P. Maher, Intertrust
  David Wagner, UC Berkeley
  Edward W. Felten, Princeton University
  Fabian Monrose, Bell Labs
  Gary McGraw, Reliable Software Technologies
  James Ellis, Sun Microsystems
  Kevin McCurley, IBM Almaden Research Center
  Matt Bishop, UC Davis
  Mudge, L0pht Heavy Industries, Inc.
  Peter Gutmann, University of Auckland, New Zealand
  Radia Perlman, Sun Microsystems
  Sandra Murphy, Network Associates
  Tom Berson, Anagram Laboratories
  Virgil D. Gligor, University of Maryland



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12724 for <[e-mail]>; Sat, 6 May 2000 16:31:30 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 2C6C315531; Sat,  6 May 2000 19:37:10 -0400 (EDT)
Received: by haggis.ma.certco.com (Postfix, from userid 1079) id 96CE37C0E8; Sat,  6 May 2000 19:37:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by haggis.ma.certco.com (Postfix) with SMTP id 8A7F6744C6; Sat,  6 May 2000 19:37:10 -0400 (EDT)
Date: Sat, 6 May 2000 19:37:10 -0400 (EDT)
From: Rich Salz <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt
In-Reply-To: <"SwtlC.A.OqG.u3GF5"@glacier>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is my second response to Bruce's comments.

This covers the "style" issues.

I prefer a raw signature, not a separate S/MIME signature because
it makes sense. :)  Think of the client request and server response
as a signed entity.  Just like a cert, then, you have
	client PDU  server PDU replysig extra-data
Layed out like that, it looks like any other signature.

It makes about as much sense to use S/MIME here, as it would be to use
S/MIME to handle the CA's signature of an X509v3 cert...  You could do
it, but why?

Well, okay, style issue.
	/r$



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10795 for <[e-mail]>; Sat, 6 May 2000 12:03:52 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 38A1115531; Sat,  6 May 2000 15:09:26 -0400 (EDT)
Received: by haggis.ma.certco.com (Postfix, from userid 1079) id BCA947C0E8; Sat,  6 May 2000 15:09:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by haggis.ma.certco.com (Postfix) with SMTP id B8745744C6; Sat,  6 May 2000 15:09:26 -0400 (EDT)
Date: Sat, 6 May 2000 15:09:26 -0400 (EDT)
From: Rich Salz <[e-mail]>
To: Bruce Greenblatt <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> Boy, you're a tough customer.  Given that RFC 2649 is experimental, it's
> not surprising that you thing that changes need to be made...

Well, you did ask. :)  I understand that it's experimental.  As specified,
it's got enough problems -- for the problem I need to solve -- that it
was not a good base on which to work.

I'll write two replies.  The first (this one) talks about those items I
can address purely from a crypto/security viewpoint.  The other one will
address those issues that are style or taste.

> How does a hash of the search reply protect it?  This wasn't viewed as a
> requirement at the time.

The hash is across *all* the the replies.  So any tampering with the
reply string will be detected.  I assume you know that, so your question
leads me to think I need to add some more clarification.

> >	3. An adversary could intercept search replies undetected.
> 
> If you are concerned about this, you can protect the channel.

No, transport-level protection is NOT the same as application-level
protection.  For dispute resolution, or (contractual) proof that
proper action/due diligence was performed, I need an application-level
signature.  "See, I did search for the latest CRL and the repository
didn't give it to me.  So it's not my fault I trusted a revoked certificate."
A reply signature addresses that; saving ALL the TLS packets, key exchanges,
etc., is not practical.  And, it forces TLS in places where a simple
signature is all that's needed.

> >	4. Audit entries aren't linked; an adversary could intercept or
> >"trim off"
> >	   the end, or tamper intermediates
> An adversary would need to have sufficient access to the directory to do
> this.  If someone hacks into the directory, any number of things can happen.

I was talking about remote access, where the client/server channel can
be tampered.  Security of local log files or transaction records -- thing
necessary if/when someone hacks into the directory - are not the issue
here.  The spec defines audit entries that have remote access, and
the security thereon is insufficient.
 
> >	5. Replies aren't cryptographically tied to queries; what prevents a
> >	   man in the middle attack?
> 
> LDAP over TLS can easily prevent this.

See #3.

> >	6. For a repository that is mainly holding signed data (certs and
> >crls),
> >	   I don't see what security "sign by server" gets you, and it
> >weakens
> >	   the overall system (making some of the above attacks possible)
> 
> If this is not a requirement, don't use it.  The sign by server request
> allows the client that trusts the server to sign the operations to do the
> work.  This is an optional feature that was deemed to be useful in some
> environments.

Well 2649 isn't (directly) the topic here, but I still don't see the
point.  :)  It DOES weaken the security of the system, as I mentioned.
As a server operator, I would be *extremely* leary of being asked to
sign anything I didn't generate.  It might be possible for me to
generate a bizarre LDAP modify request that translates to an EDI
or other binary funds-transfer protocol. :)

Also, since you can have combinations of entries, and since the timestamp
is therefore coming from different places, my trust would be weakened.

But I'm not interested in audit records, I just threw in those complains
as free review.  (Worth every penny. :)

> >	7. Sequence numbers aren't required to be monotonically increasing
> >within an
> >	   object, so an adversary could intercept intermediate ones without
> >detection.
> 
> Sequence number are required to be increasing.  RFC 2649 indicates"
> "Subsequent sequence numbers indicate the sequence of changes that have
> been made to this directory object.  Note that the sequence of the changes
> can be verified due to the fact that the signed directory object will have
> a timestamp as part of the signature object, and that the sequence
> numbering as part of the change attribute should be considered to be an
> unverified aid to the LDAP client.  Sequence numbers are meaningful only
> within the context of a single directory entry..."  In any case the
> sequenceNumbers in RFC 2649 are used as an aid to the client to show the
> sequence of operations that were applied to that operation.

The ordering can be verified; the complete sequence can't be.
Can a server increment by 10's or 3's?  I might want to use a fine-grain
resolution time-of-day clock.  In any of those choices, if I remotely
query the audit trail, I have no way of knowing if something was
intercepted.  Requiring TLS is too heavyweight, it feels improper (why
require privacy for public data?), and as I tried to explain above,
isn't really a correct solution anyway.

Imagine doing an audit.

If remote access is not the issue, then I don't see how this is
appropriate to specify. :)

> >	8. On the other hand, audit trail sequence numbers aren't global, so
> >it
> >	   doesn't seem possible to step through and determine exactly when
> >something
> >	   bad happened.
> 
> Sequence numbers are global, within an entry.  Each signature has a
> timestamp as well.  So, you will know exactly when something bad happened
> to an entry.

"Global within an entry" is an uncommon use of the terms.

Is "client sign" allowed in audit records?  If so, then why can't a
client set his clock forward one day, and delete a CRL?

> I don't follow this one.  For your purposes, you just only use client
> signature mechanism. The sign by server request doesn't apply.

No.  As a CA, I want a "return receipt requested"  I want cryptographic
proof that the LDAP server got my publication request.  2649 doesn't do it.

>   I also think that it is important to have the
> ability to store the signatures stored in the directory along with the
> entry, so that other clients can retrieve the signatures... 

Sure, some folks do need that.  But it's not what the reply signatures
I-D does.
	/r$, college dropout.



Received: from ps2.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09550 for <[e-mail]>; Sat, 6 May 2000 09:57:27 -0700 (PDT)
Received: from dtasi1 (user17.sj.dialup.innetix.com [209.172.68.80]) by ps2.walltech.com (8.10.0/8.10.0/walltech-2.10) with SMTP id e46H2gU17668; Sat, 6 May 2000 10:02:43 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 06 May 2000 10:02:37 -0700
To: "Salz, Rich" <[e-mail]>
From: Bruce Greenblatt <[e-mail]>
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail] rtco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:01 AM 5/4/2000 -0400, Salz, Rich wrote:
>>Why can't you use the mechanisms defined in RFC 2649 as a basis for this?
>>Your proposal seems remarkably similar to the definitions in RFC 2649.
>
>I have a couple of issues with 2649:

Boy, you're a tough customer.  Given that RFC 2649 is experimental, it's
not surprising that you thing that changes need to be made...

>	1. Why S/MIME, why not just a raw signature?

During the process of creating RFC 2649, we discussed using raw signatures,
but it was deceided that the benefits of using a standard mechanism that
was already recognized by other applications was substantial.  S/MIME is a
standard mechanism for the interchange of signed and encrypted data.  It
allows easy transfer of the signature between Internet applications.  I
don't see this changing.  So, I'd urge you to consider paying the overhead
of using the standard interchange mechanism.

>	2. Protection of search replies is too heavyweight; no intermediate
>	   step (like "just hash")

How does a hash of the search reply protect it?  This wasn't viewed as a
requirement at the time.

>	3. An adversary could intercept search replies undetected.

If you are concerned about this, you can protect the channel.

>	4. Audit entries aren't linked; an adversary could intercept or
>"trim off"
>	   the end, or tamper intermediates

An adversary would need to have sufficient access to the directory to do
this.  If someone hacks into the directory, any number of things can happen.

>	5. Replies aren't cryptographically tied to queries; what prevents a
>	   man in the middle attack?

LDAP over TLS can easily prevent this.

>	6. For a repository that is mainly holding signed data (certs and
>crls),
>	   I don't see what security "sign by server" gets you, and it
>weakens
>	   the overall system (making some of the above attacks possible)

If this is not a requirement, don't use it.  The sign by server request
allows the client that trusts the server to sign the operations to do the
work.  This is an optional feature that was deemed to be useful in some
environments.

>	7. Sequence numbers aren't required to be monotonically increasing
>within an
>	   object, so an adversary could intercept intermediate ones without
>detection.

Sequence number are required to be increasing.  RFC 2649 indicates"
"Subsequent sequence numbers indicate the sequence of changes that have
been made to this directory object.  Note that the sequence of the changes
can be verified due to the fact that the signed directory object will have
a timestamp as part of the signature object, and that the sequence
numbering as part of the change attribute should be considered to be an
unverified aid to the LDAP client.  Sequence numbers are meaningful only
within the context of a single directory entry..."  In any case the
sequenceNumbers in RFC 2649 are used as an aid to the client to show the
sequence of operations that were applied to that operation.

>	8. On the other hand, audit trail sequence numbers aren't global, so
>it
>	   doesn't seem possible to step through and determine exactly when
>something
>	   bad happened.

Sequence numbers are global, within an entry.  Each signature has a
timestamp as well.  So, you will know exactly when something bad happened
to an entry.

>	9. Allowing both "client signs" and "sign by server" probably means
>an adversary
>	   can do bad things by messing around with his local clock.

I don't follow this one.  For your purposes, you just only use client
signature mechanism. The sign by server request doesn't apply.

>Hope this helps.

Actually, it doesn't.  I still think that you can use RFC 2649 mechanisms
for your requirements.  In your draft, you state: "In many environments the
final step of certificate issuance is publishing the certificate to a
repository. Unfortunately, there is no way for a Certification Authority
(CA) to have a secure application-level acknowledgement that the proper
repository did, in fact, receive the certificate."  In my mind, this is
exactly what RFC 2649 provides.  When the CA publishes the certificate to a
repository (presumably via an LDAP modify operation), it will receive a
signed result from the LDAP server, and the LDAP server will store the
signed operation from the CA along with the modified LDAP entry.  If there
are specific things that need to happen in the CA - LDAP Server interaction
that don't happen in the machanisms defined by RFC 2649, then maybe we
should update RFC 2649.  I also think that it is important to have the
ability to store the signatures stored in the directory along with the
entry, so that other clients can retrieve the signatures... 

Bruce

>	/r$
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi



Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA15146 for <[e-mail]>; Fri, 5 May 2000 12:56:23 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Fri, 05 May 2000 16:01:57 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 05 May 2000 16:00:23 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: ASN.1 Name joys
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I have just completed a 3 day CMP2000 interop workshop (email me if you 
wish to participate in the next one 1st week in June).

In the days preceeding and during we yet again had vendors experiencing 
ASN.1 coding problems with Name.

I have had threads as follows:

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

now I have examined the problem [with your ir] in more detail: Our Code
has problems with the field 'subject' [5] in the CertTemplate: The subject
is a NAME and the default for tagging in the CertTemplate SEQUENCE
is IMPLICIT.

Now the problem is, that the NAME  is a CHOICE and for a CHOICE
it is not allowed to use IMPLICIT tagging (see the ASN.1 specification).
So, in the case of  NAME one has to use an EXPLICIT tagging.

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

Then I get others like:

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

my interpretation of the PKIHeader->sender/recipient field was
as follows:

both sender and recipient are defined to be of type GeneralName...

      PKIHeader ::= SEQUENCE {
          pvno                INTEGER     { ietf-version2 (1) },
          sender              GeneralName,
          -- identifies the sender
          recipient           GeneralName,
          -- identifies the intended recipient
          messageTime     [0] GeneralizedTime         OPTIONAL,
          <snip>

which is defined in the IMPORTS as:  FROM PKIX1Implicit88

which is defined in RFC-2459 as:

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

therefore it should be tagged as IMPLICIT
and, it can be any number of underlying structures.

so, a Name, although a SEQUENCE by definition, would be implicitly tagged
as [4] { SET{}  SET{} ... }, not SEQUENCE { SET{}  SET{} ... }

otherwise, the underlying name type would not be so easily determined.

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

As you might imagine, it is challenging to work on CMP interoperablity when 
there are questions about 2459 conformance.

Not everyone will be (or want to be) ASN.1 war heros.

What can we do with 2459bis to stop the flow of coding errors????

Do we need an informational RFC giving ASN.1 coding rules so that people do 
not have to get the X. whatever???

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12549 for <[e-mail]>; Fri, 5 May 2000 09:28:33 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <KKZ9TLXV>; Fri, 5 May 2000 12:34:53 -0400
Message-ID: <7E8CCF56F7F8D211894700104B9DF96DA26141@NTSERVER2>
To: [e-mail]
Cc: [e-mail]
Subject: Comments on TSA Draft v7
Date: Fri, 5 May 2000 12:34:52 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Salut Denis,

Here are few other comments on this draft:

a.  Under Section 2.3 you indicate that "The TSA MUST sign all time stamp
messages with one or more keys reserved specifically for that purpose".  You
should indicate that the reason a TSA would have more than one key reserved
specifically for that purpose would be to accommodate different policies,
different algorithms and/or different private key sizes.

b.  Also under Section 2.3 you indicate that the following object identifier
identifies the KeyPurposeID having value id-kp-timeStamping:

   id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1) 
                      identified-organization(3) dod(6) 
                      internet(1) security(5) mechanisms(5) pkix(7) 
                      kp (3) timestamping (3)}

However, according to Section 4.2.1.13 of RFC 2459, its object identifier
is:

   id-kp-timeStamping    OBJECT IDENTIFIER ::= { id-kp 8 }

c.  Also under Section 2.3, must not a TSA's certificate contain the
Certificate Policies extension defined in Section 4.2.1.5 of [RFC2459]?

d.  Section 2.4.2, it is not clear what would be the circumstance under
which the error "addInfoNotAvailable (17)" for the failInfo field would be
needed since the "tdas" field was removed;

e.  Also under Section 2.4.2, should not the error "unsupportedVersion (22)"
for the failInfo field also be supported? and

f.  Also under Section 2.4.2, for the policy field of the TSTInfo, should
not the error "unacceptedPolicy (15)" be return instead of the error
"badRequest" when the TSA can not produce a response with a the same policy
as requested by the requester in the TimeStampReq?

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] Ext. 419
http://www.chrysalis-its.com       Fax. [phone]



Received: from windoze.tenebras.com (windoze.tenebras.com [216.15.43.196]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11168 for <[e-mail]>; Fri, 5 May 2000 08:05:18 -0700 (PDT)
Received: from dnai.com (localhost [127.0.0.1]) by windoze.tenebras.com (8.9.3/8.9.3) with ESMTP id IAA03801; Fri, 5 May 2000 08:10:21 -0700 (PDT) (envelope-from [e-mail])
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 05 May 2000 08:10:21 -0700
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.0-STABLE i386)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Generating Key Pair
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

chandrasekaran natarajan wrote:
> 
> hello,
> 
> How do CA's request the browser to generate the keypair.

Netscape has built-in support for generating a keypair, and the
ubiquitous 'xenroll.cab' and some supporting VBScript (ack!)
enable IE to do the same.  In the case of Netscape, an HTML
form which includes a <KEYGEN ...> tag will cause the browser
to display a pull-down box to choose RSA modulus length.

In both cases, you'll need to bake the Certificate Request
from the form elements.  IE will post what looks like a PKCS#10
cert req, but is somewhat degenerate, and Netscape will post
a SPKAC (signed public key and challenge) as the keygen value.

This has nothing to do with the CA, really -- it's all web
stuff up to the point where a cert req is presented to a CA.

The web-based enrollment could be a function of a local RA...

====================Netscape Version==========================

<FORM METHOD=POST ACTION="/enroll2">
<hr><em><b>Please enter the following data to get your personal
certificate:</b></em>
<TABLE>

<TR>
<TD> Your name </TD>
<TD><INPUT TYPE=text SIZE=40 NAME="name" VALUE="Joan Q. Public"></TD>
</TR>

<INPUT TYPE=hidden SIZE=30 NAME="unit" VALUE="JWS">
<INPUT TYPE=hidden SIZE=30 NAME="org" VALUE="Java Land">
<INPUT TYPE=hidden SIZE=30 NAME="unit" VALUE="BOZO">

<TR>
<TD> City or Locality name </TD>
<TD><INPUT TYPE=text SIZE=30 NAME="locality" VALUE="San Mateo"></TD>
</TR>

<TR>
<TD> State or Province name </TD>
<TD><INPUT TYPE=text SIZE=30 NAME="state" VALUE="California"></TD>
</TR>

<TR>
<TD> Two-letter country code (e.g. <em>US</em>).</TD>
<TD><INPUT TYPE=text SIZE=2 NAME="country" VALUE="US"></TD>
</TR>

<TR>
<TD> Your preferred key size </TD>
<TD><KEYGEN name="keygen" challenge=fixed-for-now></TD>
</TR>

</TABLE>

<INPUT TYPE="hidden" NAME="opname" VALUE="genCert">

<P>
<CENTER>
<INPUT TYPE="submit" VALUE="Request Certificate">
<INPUT TYPE="reset" VALUE="Clear Form">
</CENTER>

</FORM>


Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA09564 for <[e-mail]>; Fri, 5 May 2000 06:14:25 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri May  5 06:19:01 2000
To: [e-mail]
Date: Fri, 05 May 2000 06:19:01 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [e-mail]
X-Mailer: MailCity Service
Subject: Generating Key Pair
X-Sender-Ip: 203.197.240.87
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello,

How do CA's request the browser to generate the keypair.

with thanks,
chandar



Get your FREE Email at http://mailcity.lycos.com
Get your PERSONALIZED START PAGE at http://my.lycos.com


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05607 for <[e-mail]>; Fri, 5 May 2000 03:35:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13285; Fri, 5 May 2000 06:40:42 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pi-00.txt
Date: Fri, 05 May 2000 06:40:42 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 
                          Permanent Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-00.txt
	Pages		: 7
	Date		: 04-May-00
	
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 a physical person.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
individual even if the name of that individual has changed.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14342 for <[e-mail]>; Thu, 4 May 2000 12:17:14 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <KJF7WYK9>; Thu, 4 May 2000 15:17:33 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: PKIX Mailing List <[e-mail]>, "'Christopher Williams'" <[e-mail]>
Subject: RE: Message protection and key update
Date: Thu, 4 May 2000 13:17:31 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Chris,

> ----------
> From: 	Christopher Williams[SMTP:[e-mail]]
> Sent: 	Thursday, May 04, 2000 11:53 AM
> To: 	PKIX Mailing List
> Subject: 	Message protection and key update
> 
> Consider the following scenario:
> 
> I am enrolled in a PKI and have a signing-key pair that I wish to update.
> I
> send a key update request containing a new public key.  I sign the message
> using my old private key.  The request is granted by the CA so I send a
> certificate confirm message.
> 
> I assume that I sign this message with my NEW private key.  Is this
> correct?
 
You can sign with the new private key if you wish, but the old private key
would be fine as well (and, in fact, it may be slightly preferable to have
the consistency of a single method for all the messages in an exchange).

> Also, does this signature provide implicit POP of the private key?  After
> all, the signature is over the hash of a certificate containing the
> matching
> public key.  If it does provide implicit POP, should the POP options be
> expanded?
 
Don't think of this as providing implicit POP.  [If signing the hash of the
cert is POP, what about the hash-of-the-hash of a cert?  What about the
hash-of-the-hash-of-the-hash of the cert?  I think it's best not to go down
this route at all.]  This is simply authentication and integrity protection
on the message.

Carlisle.



Received: from firewall3.glaxowellcome.com ([e-mail] [192.58.204.207]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13768 for <[e-mail]>; Thu, 4 May 2000 11:58:43 -0700 (PDT)
Received: by firewall3.glaxowellcome.com; id OAA18213; Thu, 4 May 2000 14:57:31 -0400 (EDT)
Received: from ussun1d.glaxo.com(152.51.4.175) by firewall3.glaxowellcome.com via smap (V5.5) id xma016508; Thu, 4 May 00 14:54:44 -0400
Received: by ussun1d.glaxo.com id PAA27063; Thu, 4 May 2000 15:01:08 -0400 (EDT)
Received: from 152.51.61.114 by securemail1.glaxo.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Thu, 04 May 2000 15:00:36 -0400
X-Server-Uuid: c7fabf50-5a2e-11d2-968c-00805fc1f894
Received: from 152.51.20.99 by securemail1.glaxo.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 04 May 00 06:47:41 -0400
X-Server-Uuid: c7fabf50-5a2e-11d2-968c-00805fc1f894
Received: by ussun2m.glaxo.com id GAA27745; Thu, 4 May 2000 06:47:40 -0400 (EDT)
Received: by firewall3.glaxowellcome.com; id GAA05729; Thu, 4 May 2000 06:41:10 -0400 (EDT)
Received: from ns.secondary.com(208.184.76.39) by firewall3.glaxowellcome.com via smap (V5.5) id xma005701; Thu, 4 May 00 06:40:47 -0400
Received: from localhost (daemon@localhost) by ns.secondary.com ( 8.9.3/8.9.3) with SMTP id DAA04261; Thu, 4 May 2000 03:30:49 -0700 (PDT )
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 4 May 2000 03:29:19 -0700
Received: from trust.addtrust.com ([212.28.197.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04151 for <[e-mail]>; Thu, 4 May 2000 03:29:17 -0700 (PDT)
Received: by TRUST with Internet Mail Service (5.5.2650.21) id <JVYHA7FZ>; Thu, 4 May 2000 12:34:46 +0200
Message-ID: <03E49309E8F5D31183F7000629396ECCD663@TRUST>
From: "Stefan Santesson" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Subject: RE: Unmistakable identity
Date: Thu, 4 May 2000 12:34:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA04152
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id DAA04261
X-WSS-ID: 150F175E94634-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA13770

Going through the definition in the QC profile, I would suggest this minor
change in section 2.4

And change:

 2.4  Uniqueness of names

   Requirements on name uniqueness are described in this standard
   through the terms "distinguished name" and "unmistakable identity",
   having the following meaning:

To:

 2.4  Uniqueness of names

   Functional and uniqueness requirements on names are described in 
   this standard through the terms "distinguished name" and 
   "unmistakable identity", having the following meaning:

This would then clarify the concept of functional requirement related to the
term unmistakable identity.

Since this is just a minor fix. I will see through that this is added to the
next draft for the IESG process that will be submitted on Friday.

/Stefan





> -----Original Message-----
> From: Stefan Santesson 
> Sent: Thursday, May 04, 2000 12:04 PM
> To: 'Denis Pinkas'
> Cc: 'Russ Housley'; 'Stephen Kent'; '[e-mail]'
> Subject: Unmistakable identity
> 
> 
> Denis,
> 
> Some comments regarding DN and Unmistakable identity.
> 
> DN is a technical requirement.
> Unmistakable identity is a functional requirement.
> 
> The DN requirement is fullfilled if the CA assignes you a 
> unique number, e.g. "123456931", but destroys any useful 
> information regarding who is the person behind that number.
> 
> For this identity to also serve the purpose of being an 
> unmistakable identity, the CA MUST provide the nessecary 
> framework to ensure that this identity also can be used to 
> identify the person "Denis Pinkas" (at least in case of a dispute).
> 
> Actually the definition of unmistakable identity says it all, 
> and is relevant.
> 
> With respect to the EU directive, the PKIX document is an 
> international document, not only driven by the EU directive. 
> Eventhough, the concept of unmistakable identity applies also 
> EU even if this term is not explicitly defined in the directive.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> > Subject: Re: Permanent identifiers in QC
> > 
> > 
> >  
> > > Folks, I've been sort of off-line the last days.
> >  
> > > So as caching up with this thread I think we need to decide 
> > the progress of
> > > this issue.
> >  
> > > I would just want to add an observation regarding NR and 
> > Authentication.
> > > The issue is NOT whether permanent identifiers are of value for
> > > Authentication or NR. What IS an issue is whether it is 
> > relevant for NR to
> > > be able to compare 2 names in 2 different certificates and 
> > ensure that these
> > > certificates identifies the same person EVEN if some parts 
> > of the DN is not
> > > matching.
> > 
> > For non-repudiation, the permanent identifier may be used to link
> > different transactions to the same individual, even when the subject
> > name of the individual changes. So it is relevant.
> > 
> > > This particular aspect is only raised as a feature for 
> > access control (when
> > > an entity changes his certificate, or possesses several 
> > certificates with
> > > different DN). In the case of NR and legal signatures, the 
> > only issue is to
> > > establish the relation between a certificate and the 
> > individual key holder
> > > (regardless of other certificates). Here the current 
> > profile provides the
> > > necessary means.
> > 
> > No. See above.
> > 
> > > But....
> > 
> > Following the discussion on the serial Number and the Permanent
> > Identifier that took place on the PKIX mailing list and at the last
> > IETF meeting in Adelaïde, I am paying more and more attention to the
> > QC draft.
> > 
> > The document is defining the concept of "unmistakable identity". Now
> > that we have introduced the use of serialNumber, I wonder why such a
> > concept is still needed.
> > 
> > First, the wording "unmistakable identity" is not used in the
> > Directive, so this is the first reason why I wonder it is needed.
> > 
> > Second, let us recall, what RFC 2459 says:
> > 
> >    The subject field from a public key certificate identifies the 
> >    entity associated with the public key stored in the subject
> > public 
> >    key field.  The subject name may be carried in the subject field 
> >    and/or the subjectAltName extension.
> > 
> >    Where it is non-empty, the subject field MUST contain an X.500
> >    distinguished name (DN). The DN MUST be unique for each subject
> >    entity certified by the one CA as defined by the issuer name
> > field.
> > 
> > The current specification (QC-03) mandates the use of the subject
> > field. In such a case, as defined *in RFC 2459*, the name is unique.
> > Moreover, it is unique not only at an instant of time, but during
> > the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> > this and I guess this is where the problem comes from. The current
> > QC-03 document references *X.501* while it should reference RFC
> > 2459. If we were *only* using the subjectAltName extension then such
> > a concept could be useful. But at the present time, we don't.
> > 
> > The chapter 2.4, called Uniqueness of names, should be deleted.
> > 
> > I would also propose the following rewording for section 3.1.2:
> > 
> > 3.1.2 Subject
> > 
> >    The subject field MUST contain an X.500 distinguished name (DN).
> >    The subject field from a public key certificate identifies the 
> >    entity associated with the public key stored in the subject
> > public 
> >    key field. The DN MUST be unique for each subject entity
> > certified 
> >    by the one CA as defined by the issuer name field. 
> > 
> >    The subject field SHALL contain an appropriate subset of the
> >    following attributes:
> > 
> >       countryName;
> >       commonName;
> >       surname;
> >       givenName;
> >       pseudonym;
> >       serialNumber;
> >       organizationName;
> >       organizationalUnitName;
> >       stateOrProvinceName
> >       localityName and
> >       postalAddress.
> > 
> >    Of these attributes, the subject field SHALL include at least one
> > of
> >    the following:
> > 
> >       Choice   I:  commonName
> >       Choice  II:  givenName
> >       Choice III:  pseudonym
> > 
> >    The subject field MAY contain other attributes.
> > 
> >    Any other attributes that MAY be present in either the subject 
> >    alternative name extension or the subject directory attributes 
> >    extension MAY help to give a better human understanding of who 
> >    the individual really is, but uniqueness of the name is achieved 
> >    singly by the subject field. 
> > 
> > The countryName attribute value (... then continue with the current
> > text)
> > 
> > As a result of this, the wording "unmistakable identity" should be
> > deleted from the whole document. In this way, we will be able to
> > suppress ambiguous sentences, like in 3.1.2 :
> > 
> > "  Certificates compliant with this profile SHALL at the same time 
> >    specify a distinguished name and an unmistakable identity of the 
> >    subject (see 2.4 for definition of distinguished name and 
> >    unmistakable identity).
> > 
> >    Attributes stored in the subject field SHALL at least form a
> >    distinguished name of the subject, but they MAY also specify a
> >    complete unmistakable identity."
> > 
> > 
> > I reproduced below an extract from Annex I from the European
> > Directive on Electronic Signatures:
> > 
> > " Requirements for qualified certificates
> > 
> > Qualified certificates must contain:
> > 
> > (...)
> > 
> > (c)	the name of the signatory or a pseudonym, which shall be
> > identified as such;"
> > 
> > 
> > > Regardless of this I agree with Steve that this issue 
> > should be advanced on
> > > it's own and merged later if it's found relevant to do so.
> > 
> > Anyway, I am preparing some text to describe what a permanent
> > identifier is and in which OID arc it should be located. This should
> > be ready at the end of this week. In this way we will be able to
> > discuss whether the permanent identifier should be, for the time
> > being, an independent RFC that the QC draft could reference, or
> > whether it should be an RFC of its own.
> > 
> > Regards,
> > 
> > Denis
> > 
> >  
> > > I would therefore request the QC profile to be advanced in 
> > it's current
> > > shape (except for a minor noted update in the reference list).
> > > 
> > > Steve:
> > > How do we proceed.
> > > 
> > > /Stefan
> > > 
> > > > -----Original Message-----
> > > > From: Russ Housley [mailto:[e-mail]]
> > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > To: Stephen Kent
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: Permanent identifiers in QC
> > > >
> > > >
> > > > I agree with Steve.  Note that the CAT Working Group has 
> > defined an
> > > > OTHER-NAME for Kerberos names.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > > >Tom,
> > > > >
> > > > >I have no problems with the sorts of IDs you proposed 
> in your ASN
> > > > >GeneralName Other-Name examples. They seem to be 
> > consistent with the
> > > > >arguments that Denis has made for such constructs. However,
> > > > before we add
> > > > >these to the updated part 1, I think we need more time to
> > > > explore the
> > > > >utility for these name forms.  The debate on the list shows
> > > > that there are
> > > > >widely diverse opinions about what such IDs are good for,
> > > > what scope is
> > > > >feasible/appropriate, etc.  I'd hesitant to hold up 
> > progress on the
> > > > >revision to 2459 to add this sort of facility which has been
> > > > proposed only
> > > > >recently.  That's why several folks have suggested a 
> > separate, small
> > > > >document whoch can be advanced separately, and merged into
> > > > 2459 if there
> > > > >is sufficient, consistent support.
> > > > >
> > > > >Steve
> > > >
> > 
> 




Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12557 for <[e-mail]>; Thu, 4 May 2000 10:56:56 -0700 (PDT)
Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA00517; Thu, 4 May 2000 14:02:13 -0400 (EDT)
Received: (from root@localhost) by smtpsrv1.mitre.org (8.9.3/8.9.3) id OAA28575; Thu, 4 May 2000 14:01:39 -0400 (EDT)
Received: from smtpsrv2.mitre.org ([128.29.154.2]) by mailsrv1.mitre.org (Netscape Messaging Server 4.1) with ESMTP id FU1J4E00.13G for <[e-mail]>; Thu, 4 May 2000 11:02:38 -0400 
Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpsrv2.mitre.org (8.9.3/8.9.3) with ESMTP id LAA22277; Thu, 4 May 2000 11:01:57 -0400 (EDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by smtpproxy2.mitre.org (8.9.3/8.9.3) with ESMTP id LAA05174; Thu, 4 May 2000 11:02:19 -0400 (EDT)
Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA09531; Thu, 4 May 2000 07:56:30 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 4 May 2000 07:54:15 -0700
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09470 for <[e-mail]>; Thu, 4 May 2000 07:54:14 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 3ADBA1553C; Thu,  4 May 2000 10:59:06 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id A07617C0E8; Thu,  4 May 2000 10:59:06 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <2YFW3WG7>; Thu, 4 May 2000 11:01:20 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Bruce Greenblatt'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Date: Thu, 4 May 2000 11:01:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe

>Why can't you use the mechanisms defined in RFC 2649 as a basis for this?
>Your proposal seems remarkably similar to the definitions in RFC 2649.

I have a couple of issues with 2649:
	1. Why S/MIME, why not just a raw signature?
	2. Protection of search replies is too heavyweight; no intermediate
	   step (like "just hash")
	3. An adversary could intercept search replies undetected.
	4. Audit entries aren't linked; an adversary could intercept or
"trim off"
	   the end, or tamper intermediates
	5. Replies aren't cryptographically tied to queries; what prevents a
	   man in the middle attack?
	6. For a repository that is mainly holding signed data (certs and
crls),
	   I don't see what security "sign by server" gets you, and it
weakens
	   the overall system (making some of the above attacks possible)
	7. Sequence numbers aren't required to be monotonically increasing
within an
	   object, so an adversary could intercept intermediate ones without
detection.
	8. On the other hand, audit trail sequence numbers aren't global, so
it
	   doesn't seem possible to step through and determine exactly when
something
	   bad happened.
	9. Allowing both "client signs" and "sign by server" probably means
an adversary
	   can do bad things by messing around with his local clock.
Hope this helps.
	/r$


Received: from mta03-svc.ntlworld.com (mta3-win.server.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10494 for <[e-mail]>; Thu, 4 May 2000 08:45:16 -0700 (PDT)
Received: from darxstar ([62.252.200.208]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000504155044.ZNV290.mta03-svc.ntlworld.com@darxstar> for <[e-mail]>; Thu, 4 May 2000 16:50:44 +0100
Message-ID: <000b01bfb5e0$f3caf710$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Message protection and key update
Date: Thu, 4 May 2000 16:53:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Consider the following scenario:

I am enrolled in a PKI and have a signing-key pair that I wish to update.  I
send a key update request containing a new public key.  I sign the message
using my old private key.  The request is granted by the CA so I send a
certificate confirm message.

I assume that I sign this message with my NEW private key.  Is this correct?

Also, does this signature provide implicit POP of the private key?  After
all, the signature is over the hash of a certificate containing the matching
public key.  If it does provide implicit POP, should the POP options be
expanded?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09470 for <[e-mail]>; Thu, 4 May 2000 07:54:14 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 3ADBA1553C; Thu,  4 May 2000 10:59:06 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id A07617C0E8; Thu,  4 May 2000 10:59:06 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <2YFW3WG7>; Thu, 4 May 2000 11:01:20 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Bruce Greenblatt'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Date: Thu, 4 May 2000 11:01:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

>Why can't you use the mechanisms defined in RFC 2649 as a basis for this?
>Your proposal seems remarkably similar to the definitions in RFC 2649.

I have a couple of issues with 2649:
	1. Why S/MIME, why not just a raw signature?
	2. Protection of search replies is too heavyweight; no intermediate
	   step (like "just hash")
	3. An adversary could intercept search replies undetected.
	4. Audit entries aren't linked; an adversary could intercept or
"trim off"
	   the end, or tamper intermediates
	5. Replies aren't cryptographically tied to queries; what prevents a
	   man in the middle attack?
	6. For a repository that is mainly holding signed data (certs and
crls),
	   I don't see what security "sign by server" gets you, and it
weakens
	   the overall system (making some of the above attacks possible)
	7. Sequence numbers aren't required to be monotonically increasing
within an
	   object, so an adversary could intercept intermediate ones without
detection.
	8. On the other hand, audit trail sequence numbers aren't global, so
it
	   doesn't seem possible to step through and determine exactly when
something
	   bad happened.
	9. Allowing both "client signs" and "sign by server" probably means
an adversary
	   can do bad things by messing around with his local clock.
Hope this helps.
	/r$


Received: from trust.addtrust.com ([212.28.197.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04151 for <[e-mail]>; Thu, 4 May 2000 03:29:17 -0700 (PDT)
Received: by TRUST with Internet Mail Service (5.5.2650.21) id <JVYHA7FZ>; Thu, 4 May 2000 12:34:46 +0200
Message-ID: <03E49309E8F5D31183F7000629396ECCD663@TRUST>
From: Stefan Santesson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Subject: RE: Unmistakable identity
Date: Thu, 4 May 2000 12:34:46 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA04152

Going through the definition in the QC profile, I would suggest this minor
change in section 2.4

And change:

 2.4  Uniqueness of names

   Requirements on name uniqueness are described in this standard
   through the terms "distinguished name" and "unmistakable identity",
   having the following meaning:

To:

 2.4  Uniqueness of names

   Functional and uniqueness requirements on names are described in 
   this standard through the terms "distinguished name" and 
   "unmistakable identity", having the following meaning:

This would then clarify the concept of functional requirement related to the
term unmistakable identity.

Since this is just a minor fix. I will see through that this is added to the
next draft for the IESG process that will be submitted on Friday.

/Stefan





> -----Original Message-----
> From: Stefan Santesson 
> Sent: Thursday, May 04, 2000 12:04 PM
> To: 'Denis Pinkas'
> Cc: 'Russ Housley'; 'Stephen Kent'; '[e-mail]'
> Subject: Unmistakable identity
> 
> 
> Denis,
> 
> Some comments regarding DN and Unmistakable identity.
> 
> DN is a technical requirement.
> Unmistakable identity is a functional requirement.
> 
> The DN requirement is fullfilled if the CA assignes you a 
> unique number, e.g. "123456931", but destroys any useful 
> information regarding who is the person behind that number.
> 
> For this identity to also serve the purpose of being an 
> unmistakable identity, the CA MUST provide the nessecary 
> framework to ensure that this identity also can be used to 
> identify the person "Denis Pinkas" (at least in case of a dispute).
> 
> Actually the definition of unmistakable identity says it all, 
> and is relevant.
> 
> With respect to the EU directive, the PKIX document is an 
> international document, not only driven by the EU directive. 
> Eventhough, the concept of unmistakable identity applies also 
> EU even if this term is not explicitly defined in the directive.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> > Subject: Re: Permanent identifiers in QC
> > 
> > 
> >  
> > > Folks, I've been sort of off-line the last days.
> >  
> > > So as caching up with this thread I think we need to decide 
> > the progress of
> > > this issue.
> >  
> > > I would just want to add an observation regarding NR and 
> > Authentication.
> > > The issue is NOT whether permanent identifiers are of value for
> > > Authentication or NR. What IS an issue is whether it is 
> > relevant for NR to
> > > be able to compare 2 names in 2 different certificates and 
> > ensure that these
> > > certificates identifies the same person EVEN if some parts 
> > of the DN is not
> > > matching.
> > 
> > For non-repudiation, the permanent identifier may be used to link
> > different transactions to the same individual, even when the subject
> > name of the individual changes. So it is relevant.
> > 
> > > This particular aspect is only raised as a feature for 
> > access control (when
> > > an entity changes his certificate, or possesses several 
> > certificates with
> > > different DN). In the case of NR and legal signatures, the 
> > only issue is to
> > > establish the relation between a certificate and the 
> > individual key holder
> > > (regardless of other certificates). Here the current 
> > profile provides the
> > > necessary means.
> > 
> > No. See above.
> > 
> > > But....
> > 
> > Following the discussion on the serial Number and the Permanent
> > Identifier that took place on the PKIX mailing list and at the last
> > IETF meeting in Adelaïde, I am paying more and more attention to the
> > QC draft.
> > 
> > The document is defining the concept of "unmistakable identity". Now
> > that we have introduced the use of serialNumber, I wonder why such a
> > concept is still needed.
> > 
> > First, the wording "unmistakable identity" is not used in the
> > Directive, so this is the first reason why I wonder it is needed.
> > 
> > Second, let us recall, what RFC 2459 says:
> > 
> >    The subject field from a public key certificate identifies the 
> >    entity associated with the public key stored in the subject
> > public 
> >    key field.  The subject name may be carried in the subject field 
> >    and/or the subjectAltName extension.
> > 
> >    Where it is non-empty, the subject field MUST contain an X.500
> >    distinguished name (DN). The DN MUST be unique for each subject
> >    entity certified by the one CA as defined by the issuer name
> > field.
> > 
> > The current specification (QC-03) mandates the use of the subject
> > field. In such a case, as defined *in RFC 2459*, the name is unique.
> > Moreover, it is unique not only at an instant of time, but during
> > the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> > this and I guess this is where the problem comes from. The current
> > QC-03 document references *X.501* while it should reference RFC
> > 2459. If we were *only* using the subjectAltName extension then such
> > a concept could be useful. But at the present time, we don't.
> > 
> > The chapter 2.4, called Uniqueness of names, should be deleted.
> > 
> > I would also propose the following rewording for section 3.1.2:
> > 
> > 3.1.2 Subject
> > 
> >    The subject field MUST contain an X.500 distinguished name (DN).
> >    The subject field from a public key certificate identifies the 
> >    entity associated with the public key stored in the subject
> > public 
> >    key field. The DN MUST be unique for each subject entity
> > certified 
> >    by the one CA as defined by the issuer name field. 
> > 
> >    The subject field SHALL contain an appropriate subset of the
> >    following attributes:
> > 
> >       countryName;
> >       commonName;
> >       surname;
> >       givenName;
> >       pseudonym;
> >       serialNumber;
> >       organizationName;
> >       organizationalUnitName;
> >       stateOrProvinceName
> >       localityName and
> >       postalAddress.
> > 
> >    Of these attributes, the subject field SHALL include at least one
> > of
> >    the following:
> > 
> >       Choice   I:  commonName
> >       Choice  II:  givenName
> >       Choice III:  pseudonym
> > 
> >    The subject field MAY contain other attributes.
> > 
> >    Any other attributes that MAY be present in either the subject 
> >    alternative name extension or the subject directory attributes 
> >    extension MAY help to give a better human understanding of who 
> >    the individual really is, but uniqueness of the name is achieved 
> >    singly by the subject field. 
> > 
> > The countryName attribute value (... then continue with the current
> > text)
> > 
> > As a result of this, the wording "unmistakable identity" should be
> > deleted from the whole document. In this way, we will be able to
> > suppress ambiguous sentences, like in 3.1.2 :
> > 
> > "  Certificates compliant with this profile SHALL at the same time 
> >    specify a distinguished name and an unmistakable identity of the 
> >    subject (see 2.4 for definition of distinguished name and 
> >    unmistakable identity).
> > 
> >    Attributes stored in the subject field SHALL at least form a
> >    distinguished name of the subject, but they MAY also specify a
> >    complete unmistakable identity."
> > 
> > 
> > I reproduced below an extract from Annex I from the European
> > Directive on Electronic Signatures:
> > 
> > " Requirements for qualified certificates
> > 
> > Qualified certificates must contain:
> > 
> > (...)
> > 
> > (c)	the name of the signatory or a pseudonym, which shall be
> > identified as such;"
> > 
> > 
> > > Regardless of this I agree with Steve that this issue 
> > should be advanced on
> > > it's own and merged later if it's found relevant to do so.
> > 
> > Anyway, I am preparing some text to describe what a permanent
> > identifier is and in which OID arc it should be located. This should
> > be ready at the end of this week. In this way we will be able to
> > discuss whether the permanent identifier should be, for the time
> > being, an independent RFC that the QC draft could reference, or
> > whether it should be an RFC of its own.
> > 
> > Regards,
> > 
> > Denis
> > 
> >  
> > > I would therefore request the QC profile to be advanced in 
> > it's current
> > > shape (except for a minor noted update in the reference list).
> > > 
> > > Steve:
> > > How do we proceed.
> > > 
> > > /Stefan
> > > 
> > > > -----Original Message-----
> > > > From: Russ Housley [mailto:[e-mail]]
> > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > To: Stephen Kent
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: Permanent identifiers in QC
> > > >
> > > >
> > > > I agree with Steve.  Note that the CAT Working Group has 
> > defined an
> > > > OTHER-NAME for Kerberos names.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > > >Tom,
> > > > >
> > > > >I have no problems with the sorts of IDs you proposed 
> in your ASN
> > > > >GeneralName Other-Name examples. They seem to be 
> > consistent with the
> > > > >arguments that Denis has made for such constructs. However,
> > > > before we add
> > > > >these to the updated part 1, I think we need more time to
> > > > explore the
> > > > >utility for these name forms.  The debate on the list shows
> > > > that there are
> > > > >widely diverse opinions about what such IDs are good for,
> > > > what scope is
> > > > >feasible/appropriate, etc.  I'd hesitant to hold up 
> > progress on the
> > > > >revision to 2459 to add this sort of facility which has been
> > > > proposed only
> > > > >recently.  That's why several folks have suggested a 
> > separate, small
> > > > >document whoch can be advanced separately, and merged into
> > > > 2459 if there
> > > > >is sufficient, consistent support.
> > > > >
> > > > >Steve
> > > >
> > 
> 


Received: from trust.addtrust.com ([212.28.197.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01025 for <[e-mail]>; Thu, 4 May 2000 02:58:54 -0700 (PDT)
Received: by TRUST with Internet Mail Service (5.5.2650.21) id <JVYHA7FW>; Thu, 4 May 2000 12:04:23 +0200
Message-ID: <03E49309E8F5D31183F7000629396ECCD661@TRUST>
From: Stefan Santesson <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Unmistakable identity
Date: Thu, 4 May 2000 12:04:23 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA01026

Denis,

Some comments regarding DN and Unmistakable identity.

DN is a technical requirement.
Unmistakable identity is a functional requirement.

The DN requirement is fullfilled if the CA assignes you a unique number,
e.g. "123456931", but destroys any useful information regarding who is the
person behind that number.

For this identity to also serve the purpose of being an unmistakable
identity, the CA MUST provide the nessecary framework to ensure that this
identity also can be used to identify the person "Denis Pinkas" (at least in
case of a dispute).

Actually the definition of unmistakable identity says it all, and is
relevant.

With respect to the EU directive, the PKIX document is an international
document, not only driven by the EU directive. Eventhough, the concept of
unmistakable identity applies also EU even if this term is not explicitly
defined in the directive.

/Stefan

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, April 26, 2000 10:27 AM
> To: Stefan Santesson
> Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> Subject: Re: Permanent identifiers in QC
> 
> 
>  
> > Folks, I've been sort of off-line the last days.
>  
> > So as caching up with this thread I think we need to decide 
> the progress of
> > this issue.
>  
> > I would just want to add an observation regarding NR and 
> Authentication.
> > The issue is NOT whether permanent identifiers are of value for
> > Authentication or NR. What IS an issue is whether it is 
> relevant for NR to
> > be able to compare 2 names in 2 different certificates and 
> ensure that these
> > certificates identifies the same person EVEN if some parts 
> of the DN is not
> > matching.
> 
> For non-repudiation, the permanent identifier may be used to link
> different transactions to the same individual, even when the subject
> name of the individual changes. So it is relevant.
> 
> > This particular aspect is only raised as a feature for 
> access control (when
> > an entity changes his certificate, or possesses several 
> certificates with
> > different DN). In the case of NR and legal signatures, the 
> only issue is to
> > establish the relation between a certificate and the 
> individual key holder
> > (regardless of other certificates). Here the current 
> profile provides the
> > necessary means.
> 
> No. See above.
> 
> > But....
> 
> Following the discussion on the serial Number and the Permanent
> Identifier that took place on the PKIX mailing list and at the last
> IETF meeting in Adelaïde, I am paying more and more attention to the
> QC draft.
> 
> The document is defining the concept of "unmistakable identity". Now
> that we have introduced the use of serialNumber, I wonder why such a
> concept is still needed.
> 
> First, the wording "unmistakable identity" is not used in the
> Directive, so this is the first reason why I wonder it is needed.
> 
> Second, let us recall, what RFC 2459 says:
> 
>    The subject field from a public key certificate identifies the 
>    entity associated with the public key stored in the subject
> public 
>    key field.  The subject name may be carried in the subject field 
>    and/or the subjectAltName extension.
> 
>    Where it is non-empty, the subject field MUST contain an X.500
>    distinguished name (DN). The DN MUST be unique for each subject
>    entity certified by the one CA as defined by the issuer name
> field.
> 
> The current specification (QC-03) mandates the use of the subject
> field. In such a case, as defined *in RFC 2459*, the name is unique.
> Moreover, it is unique not only at an instant of time, but during
> the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> this and I guess this is where the problem comes from. The current
> QC-03 document references *X.501* while it should reference RFC
> 2459. If we were *only* using the subjectAltName extension then such
> a concept could be useful. But at the present time, we don't.
> 
> The chapter 2.4, called Uniqueness of names, should be deleted.
> 
> I would also propose the following rewording for section 3.1.2:
> 
> 3.1.2 Subject
> 
>    The subject field MUST contain an X.500 distinguished name (DN).
>    The subject field from a public key certificate identifies the 
>    entity associated with the public key stored in the subject
> public 
>    key field. The DN MUST be unique for each subject entity
> certified 
>    by the one CA as defined by the issuer name field. 
> 
>    The subject field SHALL contain an appropriate subset of the
>    following attributes:
> 
>       countryName;
>       commonName;
>       surname;
>       givenName;
>       pseudonym;
>       serialNumber;
>       organizationName;
>       organizationalUnitName;
>       stateOrProvinceName
>       localityName and
>       postalAddress.
> 
>    Of these attributes, the subject field SHALL include at least one
> of
>    the following:
> 
>       Choice   I:  commonName
>       Choice  II:  givenName
>       Choice III:  pseudonym
> 
>    The subject field MAY contain other attributes.
> 
>    Any other attributes that MAY be present in either the subject 
>    alternative name extension or the subject directory attributes 
>    extension MAY help to give a better human understanding of who 
>    the individual really is, but uniqueness of the name is achieved 
>    singly by the subject field. 
> 
> The countryName attribute value (... then continue with the current
> text)
> 
> As a result of this, the wording "unmistakable identity" should be
> deleted from the whole document. In this way, we will be able to
> suppress ambiguous sentences, like in 3.1.2 :
> 
> "  Certificates compliant with this profile SHALL at the same time 
>    specify a distinguished name and an unmistakable identity of the 
>    subject (see 2.4 for definition of distinguished name and 
>    unmistakable identity).
> 
>    Attributes stored in the subject field SHALL at least form a
>    distinguished name of the subject, but they MAY also specify a
>    complete unmistakable identity."
> 
> 
> I reproduced below an extract from Annex I from the European
> Directive on Electronic Signatures:
> 
> " Requirements for qualified certificates
> 
> Qualified certificates must contain:
> 
> (...)
> 
> (c)	the name of the signatory or a pseudonym, which shall be
> identified as such;"
> 
> 
> > Regardless of this I agree with Steve that this issue 
> should be advanced on
> > it's own and merged later if it's found relevant to do so.
> 
> Anyway, I am preparing some text to describe what a permanent
> identifier is and in which OID arc it should be located. This should
> be ready at the end of this week. In this way we will be able to
> discuss whether the permanent identifier should be, for the time
> being, an independent RFC that the QC draft could reference, or
> whether it should be an RFC of its own.
> 
> Regards,
> 
> Denis
> 
>  
> > I would therefore request the QC profile to be advanced in 
> it's current
> > shape (except for a minor noted update in the reference list).
> > 
> > Steve:
> > How do we proceed.
> > 
> > /Stefan
> > 
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[e-mail]]
> > > Sent: Friday, April 14, 2000 4:36 PM
> > > To: Stephen Kent
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Re: Permanent identifiers in QC
> > >
> > >
> > > I agree with Steve.  Note that the CAT Working Group has 
> defined an
> > > OTHER-NAME for Kerberos names.
> > >
> > > Russ
> > >
> > >
> > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > >Tom,
> > > >
> > > >I have no problems with the sorts of IDs you proposed in your ASN
> > > >GeneralName Other-Name examples. They seem to be 
> consistent with the
> > > >arguments that Denis has made for such constructs. However,
> > > before we add
> > > >these to the updated part 1, I think we need more time to
> > > explore the
> > > >utility for these name forms.  The debate on the list shows
> > > that there are
> > > >widely diverse opinions about what such IDs are good for,
> > > what scope is
> > > >feasible/appropriate, etc.  I'd hesitant to hold up 
> progress on the
> > > >revision to 2459 to add this sort of facility which has been
> > > proposed only
> > > >recently.  That's why several folks have suggested a 
> separate, small
> > > >document whoch can be advanced separately, and merged into
> > > 2459 if there
> > > >is sufficient, consistent support.
> > > >
> > > >Steve
> > >
> 


Received: from ps2.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14718 for <[e-mail]>; Wed, 3 May 2000 14:36:11 -0700 (PDT)
Received: from dtasi1 (goldengate-bridge.veritas.com [63.197.92.2]) by ps2.walltech.com (8.10.0/8.10.0/walltech-2.10) with SMTP id e43LfOU28516; Wed, 3 May 2000 14:41:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 03 May 2000 14:41:15 -0700
To: [e-mail]
From: Bruce Greenblatt <[e-mail]>
Subject: Re: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Rich,

Why can't you use the mechanisms defined in RFC 2649 as a basis for this?
Your proposal seems remarkably similar to the definitions in RFC 2649.

Bruce

At 06:43 AM 5/2/2000 -0400, [e-mail] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>	Title		: LDAP Controls for Reply Signatures
>	Author(s)	: R. Salz
>	Filename	: draft-salzr-ldap-repsig-00.txt
>	Pages		: 8
>	Date		: 01-May-00
>	
>In many environments the final step of certificate issuance is 
>publishing the certificate to a repository. Unfortunately, there 
>is no way for a Certification Authority (CA) to have a secure 
>application-level acknowledgement that the proper repository 
>did, in fact, receive the certificate. This issue is of greater 
>concern when considering the publication of Certificate 
>Revocation Lists (CRLs) -- if an adversary manages to interpose 
>itself between the CA and its intended repository, then clients 
>could end up relying on outdated revocation lists.
>This document defines a set of controls so that an LDAP client, 
>such as a CA, can receive a cryptographically secure 
>acknowledgement that an LDAP server has received a request, and 
>that the integrity of the server's reply has not been 
>compromised.
>  

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi



Received: from donjs (p40-max47.syd.ihug.com.au [203.109.132.168]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA06422 for <[e-mail]>; Wed, 3 May 2000 05:38:21 -0700 (PDT)
Date: Wed, 3 May 2000 05:38:21 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail]
From: "DJS" <[e-mail]>
Subject: Guilty
Content-Type: text/plain; charset=us-ascii
Reply-To: 
X-Priority: 3
X-MSMail-Priority: Normal

Hi
First of all I am a real person and not some robot sent out to annoy you.  This is not a mass marketing exercise, mailing out thousands of messages in the hope that some would be curious. 

Instead I am mailing you, a person who has had some dealings with home based businesses and would appreciate the business I have to offer. 

Let me be up front - right from the beginning. If you decide to take advantage of the idea I have come across, then it will cost you $110. That isn't a lot for a home based business wouldn't you agree? And believe it or not, the income potential for this idea is huge ... and world wide!

Your time is valuable I know. So if you want to know more about this idea you will need to send me an email asking for more details.  mailto:djs68@mailandnews or  mailto:[e-mail]

You are not on a massive list, so if you don't want to know more then I doubt very much if our paths will cross again. In the meantime I would like to leave you this quote from CS Lewis ...

Make the choice adventurous stranger, 
strike the bell and bide the danger 
or wonder 'till it drives you mad 
what would have happened if you had. 

So. Now the ball is in your court. I look forward to hearing from you ...

Peace and good wishes
Don



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01676 for <[e-mail]>; Tue, 2 May 2000 03:37:50 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26659; Tue, 2 May 2000 06:43:07 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail], [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Date: Tue, 02 May 2000 06:43:06 -0400
Sender: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: LDAP Controls for Reply Signatures
	Author(s)	: R. Salz
	Filename	: draft-salzr-ldap-repsig-00.txt
	Pages		: 8
	Date		: 01-May-00
	
In many environments the final step of certificate issuance is 
publishing the certificate to a repository. Unfortunately, there 
is no way for a Certification Authority (CA) to have a secure 
application-level acknowledgement that the proper repository 
did, in fact, receive the certificate. This issue is of greater 
concern when considering the publication of Certificate 
Revocation Lists (CRLs) -- if an adversary manages to interpose 
itself between the CA and its intended repository, then clients 
could end up relying on outdated revocation lists.
This document defines a set of controls so that an LDAP client, 
such as a CA, can receive a cryptographically secure 
acknowledgement that an LDAP server has received a request, and 
that the integrity of the server's reply has not been 
compromised.
  
    Whenever possible, the definitions here use mechanisms and 
    datatypes defined by the IETF PKIX working group. This document 
    references RFC 2459 [RFC2459]. Knowledge of the RFC is required 
    for proper implementation of this document, although it should 
    be possible to understand this document without much knowledge 
    of that RFC.
    
    It is expected that future versions of this document will 
    reference 2459's successor(s).

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-salzr-ldap-repsig-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from fsnt.future.futusoft.com ([203.197.140.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA17365 for <[e-mail]>; Mon, 1 May 2000 23:44:46 -0700 (PDT)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 02 May 2000 12:30:07 +0530
Received: from ruheenar.future.futsoft.com (ruheenar.future.futsoft.com [10.0.12.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA00685; Tue, 2 May 2000 12:08:38 +0530
Received: by localhost with Microsoft MAPI; Tue, 2 May 2000 12:15:26 +0530
Message-Id: <[e-mail]>
From: Ruheena Rashid <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Query : CA related
Date: Tue, 2 May 2000 12:15:24 +0530
Organization: future software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello

I have a query regarding the Certification Authority (CA) in IKE. RFC 2409 
mentions about the inclusion of certificate payloads, which needs to be 
verified by the CA, but does not mention as to how the information is 
conveyed to the CA for verification.

Is it that the Peer obtains the certificate and performs the verification ?
(or)
Does it send the complete payload to CA for verification ?

I would like to know whether any draft or RFC exists, which mentions about 
how the CA performs the verification of the certificates?

Also, whether any encryption needs to be performed to send the information 
to the CA (since security is a major issue) ?

I would also like to know whether any implementation exists for the same.

Regards
Ruheena Rashid.


Ruheena Rashid
Software Engineer
Future Software Pvt. Ltd.
Nandanam
Chennai




Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA13745 for <[e-mail]>; Mon, 1 May 2000 17:28:42 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA21860; Tue, 2 May 2000 10:38:25 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <KBX7M77Y>; Tue, 2 May 2000 10:33:12 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Tue, 2 May 2000 10:33:11 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

 
> Denis,
> 
> In Section 2.4.1, could there be a way for a requester to indicate what
hash and signature algorithms he/she wants on the 
> TimeStampToken in cases where a TSA would support multiple algorithms
since according to the current definition of the 
> "policy" field in Section 2.4.2, it does not seem to be within the scope
of this field to address this? How would 
> otherwise a TSA announce to the world what algorithms it uses to sign Time
Stamp Tokens and also what algorithms it 
> supports in messageImprints.  Could the S/MIME capabilities attribute be
used for this?
> 
I'd say that the client should be able to verify all 'common' types of
signatures: [RSA/DSA]:[SHA1/MD5].
The encryption algorithm for the signature is defined by the key type in the
TSA's certificate, so the client can find it out before making the first
transaction with the TSA. I do not think that the hash is really going to be
a hard bit for the client.

The same about hash algorithms supported by the TSA for messageImprints -
the TSA should accept all 'common' types. If it does not understand the
algorithm's OID, the error will be returned to the client. So that the
client will have to try a different algorithm. With makes it nothing but
ugly, making me to believe any static information about TSA's capabilities
should be communicated separately from the actual TSA responses. The client
should discover the capabilities of the TSA before transacting, out-of-band
or from some published TSA practice statement.

Regards
Michael


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10640 for <[e-mail]>; Mon, 1 May 2000 13:26:34 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <JZA34M21>; Mon, 1 May 2000 16:32:35 -0400
Message-ID: <7E8CCF56F7F8D211894700104B9DF96DA26130@NTSERVER2>
To: [e-mail]
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Mon, 1 May 2000 16:32:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis,

In Section 2.4.1, could there be a way for a requester to indicate what hash
and signature algorithms he/she wants on the TimeStampToken in cases where a
TSA would support multiple algorithms since according to the current
definition of the "policy" field in Section 2.4.2, it does not seem to be
within the scope of this field to address this? How would otherwise a TSA
announce to the world what algorithms it uses to sign Time Stamp Tokens and
also what algorithms it supports in messageImprints.  Could the S/MIME
capabilities attribute be used for this?

In Section 2.4.2, in the time stamping response when the "status" field
contains the value one (1), doesn't this mean that a token is also present,
but its format was modified from what the requester demanded? If so, some
text will need to be modified to also indicate that when the PKIStatus
contains the value one and not just zero, a Time Stamp Token is also
present.  Otherwise, it should be clear what only values for the "status"
field are allowed in a response by a TSA.

In Section 2.4.2, it is mentioned that 'The statusString field of
PKIStatusInfo MAY be used to include reason
text such as "messageImprint field is not correctly formatted"', however the
"statusString" field itself, which is defined as PKIFreeText in RFC 2510, is
missing from the definition of the PKIStatusInfo field specified in this
document.  It would be preferable if the PKIStatusInfo field was defined
consistently in both documents.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] Ext. 419
http://www.chrysalis-its.com       Fax. [phone]