Subject: RE: TSA Response serialNumber Field

From: "Manger, James H" <[email-masked]>
Date: Wed, 31 May 2000 16:26:21 +1000

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.

---

From: Paul Koning <[email-masked]>
Date: Wed, 31 May 2000 10:15:12 -0400 (EDT)

>>>>> "Manger," == Manger, James H <[email-masked]> 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

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 May 2000 20:42:02 -0700

> You never need to know - that is the beauty.

What you say below does not work.

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

> TSA can ensure its arbitrary choices always increase while its clock returns

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

Cheers,

Ed Gerck

Date: Thu, 1 Jun 2000 01:13:38 -0400 (EDT)
From: "Dennis  Solomon" <[email-masked]>
To: <[email-masked]>
Subject: Legal Assistance

EMAIL: [email-masked]

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

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

Date: Tue, 30 May 2000 20:42:02 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: TSA Response serialNumber Field
To: "Manger, James H" <[email-masked]>
Cc: [email-masked]

> You never need to know - that is the beauty.

What you say below does not work.

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

> TSA can ensure its arbitrary choices always increase while its clock returns

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

Cheers,

Ed Gerck

Sender: [email-masked]
Date: Thu, 01 Jun 2000 11:39:53 +1000
From: Eddy Cheung <[email-masked]>
To: Sean Mullan <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX library

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

From: <[email-masked]>
Sender: "denis bider" <[email-masked]>
To: <[email-masked]>
Subject: Microsoft
Date: Thu, 1 Jun 2000 00:41:44 +0200
Importance: Normal

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

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 May 2000 19:12:28 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Time Stamp V7 Data structure
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

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

Date: Wed, 31 May 2000 19:00:18 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Roland Mueller <[email-masked]>
CC: IETF-PKIX <[email-masked]>, Wes Doonan <[email-masked]>, "Jose A. Ma~n" <[email-masked]>, Mike Matyas <[email-masked]>
Subject: Re: Time Stamp V7 Data structure

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

Date: Wed, 31 May 2000 18:18:21 +0200
From: Raffaello Galli <[email-masked]>
Organization: C&A
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Timestamp: id for token

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

[email-masked] 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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078
>
> -----Original Message-----
> From: Michael Zolotarev [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2000 12:43 AM
> To: Joerg Seidel; Manger, James H
> Cc: [email-masked]'
> 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:[email-masked]
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--

Date: Wed, 31 May 2000 12:03:19 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: What is the meaning of the "indirectCRL" flag
To: [email-masked]
Content-MD5: 2ri6TxKD2BcjQnGmjj/NTw==

> From: "Bob Jueneman" <[email-masked]>
> 
> 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.)

Date: Wed, 31 May 2000 11:02:55 -0500
From: Roland Mueller <[email-masked]>
Organization: TUVIT Inc.
To: Peter Sylvester <[email-masked]>
CC: IETF-PKIX <[email-masked]>, "Manas, Jose A." <[email-masked]>, "Doonan, Wes" <[email-masked]>, "Matyas, Mike" <[email-masked]>
Subject: Re: Time Stamp V7 Data structure

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:(512) 795-0495
tel;work:(512) 795-0494
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[email-masked]
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--

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 May 2000 17:50:19 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Time Stamp V7 Data structure
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

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

Date: Wed, 31 May 2000 17:39:47 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: AIA usage in TSA Certificate

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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 May 2000 17:35:05 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Time Stamp V7 Data structure
Cc: [email-masked], [email-masked], [email-masked]

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

To: Rich Salz <[email-masked]>
cc: [email-masked]
Subject: Re: What is the meaning of the "indirectCRL" flag 
Date: Wed, 31 May 2000 11:30:16 -0400
From: Dan Geer <[email-masked]>

  > 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: AIA usage in TSA Certificate
Date: Wed, 31 May 2000 11:29:43 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Tue, 30 May 2000 18:56:42 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-03
Cc: [email-masked], [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Timestamp: id for token
Date: Wed, 31 May 2000 11:27:00 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Michael Zolotarev [mailto:[email-masked]]
Sent: Wednesday, May 31, 2000 12:43 AM
To: Joerg Seidel; Manger, James H
Cc: [email-masked]'
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]

Date: Wed, 31 May 2000 10:22:06 -0500
From: Roland Mueller <[email-masked]>
Organization: TUVIT Inc.
To: [email-masked]
CC: IETF-PKIX <[email-masked]>, Wes Doonan <[email-masked]>, "Jose A. Ma~n" <[email-masked]>, [email-masked]
Subject: Re: Time Stamp V7 Data structure

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:(512) 795-0495
tel;work:(512) 795-0494
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[email-masked]
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--

Date: Wed, 31 May 2000 10:59:34 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: SubjectAltName verification
To: [email-masked]
Content-MD5: jl7jivLNjnPGPRZ/qoFSWg==

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

Date: Wed, 31 May 2000 16:51:36 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: Rationale for Nonce in Time Stamp Protocol

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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2000 4:19 AM
> To: [email-masked]
> Cc: [email-masked]
> 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

From: [email-masked]
To: Roland Mueller <[email-masked]>
cc: IETF-PKIX <[email-masked]>, Wes Doonan <[email-masked]>, "Jose A. Ma~n" <[email-masked]>, [email-masked]
Date: Wed, 31 May 2000 10:38:56 -0400
Subject: Re: Time Stamp V7 Data structure

     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 <[email-masked]> on 05/30/2000 11:34:43 PM

To:   IETF-PKIX <[email-masked]>
cc:   Wes Doonan <[email-masked]>, "Jose A. Ma~n" <[email-masked]>,
      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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Rationale for Nonce in Time Stamp Protocol
Date: Wed, 31 May 2000 10:38:29 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, May 31, 2000 4:19 AM
To: [email-masked]
Cc: [email-masked]
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

From: Paul Koning <[email-masked]>
Date: Wed, 31 May 2000 10:22:14 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: RE: Timestamp: TSA Response serialNumber Field

>>>>> "Manger," == Manger, James H <[email-masked]> 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

From: Paul Koning <[email-masked]>
Date: Wed, 31 May 2000 10:15:12 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: RE: TSA Response serialNumber Field

 Manger,> Michael,

 Manger,> No.

    paul

Sender: rsalz
Date: Wed, 31 May 2000 09:41:18 -0400
From: Rich Salz <[email-masked]>
Organization: Caveo Systems, Inc.
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: What is the meaning of the "indirectCRL" flag

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

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithms to Proposed Standard
Date: Wed, 31 May 2000 09:02:57 -0400
Sender: [email-masked]

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.

From: "Rusty Gregg" <[email-masked]>
To: [email-masked]
Date: Wed, 31 May 2000 08:53:44 -0400

unsubscribe

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 May 2000 14:12:41 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Rationale for Nonce in Time Stamp Protocol
Cc: [email-masked]

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

Date: Wed, 31 May 2000 11:47:13 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Ambarish Malpani <[email-masked]>
CC: "'Andy Dowling'" <[email-masked]>, [email-masked]
Subject: Re: Requirements for remote path processing services

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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Andy Dowling [mailto:[email-masked]]
> > Sent: Monday, May 29, 2000 4:02 AM
> > To: Paul Hoffman
> > Cc: [email-masked]
> > 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) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Sender: [email-masked]
Date: Wed, 31 May 2000 10:32:08 +0100
From: Sean Mullan <[email-masked]>
To: Eddy <[email-masked]>
CC: Gabriel =?iso-8859-1?Q?L=F3pez=20Mill=E1n?= <[email-masked]>, [email-masked]
Subject: Re: PKIX library

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.

Date: Wed, 31 May 2000 10:18:32 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
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

> 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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2000 6:09 AM
> To: [email-masked]
> Cc: [email-masked]
> 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
> > [email-masked]      Tel. (613) 723-5076 ext. 419
> > http://www.chrysalis-its.com     Fax. (613) 723-5078
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Wednesday, May 24, 2000 5:36 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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
> > > [email-masked]      Tel. (613) 723-5076 ext. 419
> > > http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Wed, 31 May 2000 18:12:01 +1000
From: Eddy <[email-masked]>
To: Gabriel =?iso-8859-1?Q?L=F3pez=20Mill=E1n?= <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX library

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.

Date: Wed, 31 May 2000 09:29:55 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Manger, James H" <[email-masked]>
CC: [email-masked]
Subject: Re: Timestamp: TSA Response serialNumber Field

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

Date: Wed, 31 May 2000 09:12:21 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael Zolotarev <[email-masked]>
CC: Joerg Seidel <[email-masked]>, "Manger, James H" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Timestamp: id for token

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:[email-masked]]
> > Sent: Monday, May 29, 2000 8:21 PM
> > To: Manger, James H
> > Cc: [email-masked]'
> > 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.
> >

Date: Wed, 31 May 2000 09:04:52 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Wed, 31 May 2000 16:26:21 +1000

Michael,

No.
No
is 5?
No

derived referencing.

From: Michael Zolotarev <[email-masked]>
To: Andy Dowling <[email-masked]>, Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: RE: Requirements for remote path processing services
Date: Wed, 31 May 2000 15:04:20 +1000

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:[email-masked]]
> Sent: Monday, May 29, 2000 9:02 PM
> To: Paul Hoffman
> Cc: [email-masked]
> 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
> 
> 
> 
> 
> 

From: Michael Zolotarev <[email-masked]>
To: Joerg Seidel <[email-masked]>, "Manger, James H" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Timestamp: id for token
Date: Wed, 31 May 2000 14:43:03 +1000

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:[email-masked]]
> Sent: Monday, May 29, 2000 8:21 PM
> To: Manger, James H
> Cc: [email-masked]'
> 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.
> 

From: Michael Zolotarev <[email-masked]>
To: Denis Pinkas <[email-masked]>, "Manger, James H" <[email-masked]>
Cc: [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Wed, 31 May 2000 14:20:13 +1000

Guys,

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:

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

This is really a matter of style, though.

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2000 7:25 PM
> To: Manger, James H
> Cc: [email-masked]
> 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
> 

Date: Tue, 30 May 2000 22:34:43 -0500
From: Roland Mueller <[email-masked]>
Organization: TUVIT Inc.
To: IETF-PKIX <[email-masked]>
CC: Wes Doonan <[email-masked]>, "Jose A. Ma~n" <[email-masked]>, Mike Matyas <[email-masked]>
Subject: Time Stamp V7 Data structure

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:(512) 795-0495
tel;work:(512) 795-0494
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[email-masked]
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--

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: RE: Timestamp: TSA Response serialNumber Field
Date: Wed, 31 May 2000 11:30:15 +1000

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.

From: [email-masked]
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 30 May 2000 19:19:27 -0400
Subject: RE: SubjectAltName verification

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

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

Tom,

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

Date: Tue, 30 May 2000 16:04:38 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: What is the meaning of the "indirectCRL" flag

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

Date: Tue, 30 May 2000 15:29:44 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: SubjectAltName verification

Tom,

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

Date: Tue, 30 May 2000 16:47:28 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SubjectAltName verification
Cc: [email-masked]

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

Date: Tue, 30 May 2000 20:08:24 +0100
From: Bruno Salgueiro <[email-masked]>
Organization: SIBS
To: [email-masked]
Subject: Re: SubjectAltName verification

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

--------------ms52421F465528285FF5B5AAAD--

From: [email-masked]
To: Peter Williams <[email-masked]>
cc: "'Al Arsenault'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, [email-masked]
Date: Tue, 30 May 2000 14:51:09 -0400
Subject: RE: SubjectAltName verification

     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

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 14:00:47 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field

>>>>> "Peter" == Peter Sylvester <[email-masked]> 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 <[email-masked]> 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

Date: Tue, 30 May 2000 11:43:24 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
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 [email-masked]. 

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

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 13:46:24 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field

>>>>> "Tony" == Tony Bartoletti <[email-masked]> 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

Date: Tue, 30 May 2000 10:39:49 -0700
To: Paul Koning <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Rationale for Nonce in Time Stamp Protocol
Date: Tue, 30 May 2000 13:25:30 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, May 30, 2000 6:09 AM
To: [email-masked]
Cc: [email-masked]
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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2000 5:36 AM
> To: [email-masked]
> Cc: [email-masked]
> 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
> > [email-masked]      Tel. (613) 723-5076 ext. 419
> > http://www.chrysalis-its.com     Fax. (613) 723-5078

Sender: [email-masked]
Date: Tue, 30 May 2000 18:47:48 +0200
From: Gabriel =?iso-8859-1?Q?L=F3pez=20Mill=E1n?= <[email-masked]>
To: [email-masked]
Subject: Re: PKIX library

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.

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 12:21:05 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: TSA Response serialNumber Field

>>>>> "Peter" == Peter Sylvester <[email-masked]> 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Encrypting private keys - how do you achieve this in practice ?
Date: Tue, 30 May 2000 12:07:33 -0400

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:[email-masked]]
Sent: Friday, May 26, 2000 11:48 AM
To: [email-masked]
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" <[email-masked]>
> To: "PKIX Mailing List" <[email-masked]>
> 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

From: Peter Williams <[email-masked]>
To: "'Al Arsenault'" <[email-masked]>
Cc: "'Denis Pinkas'" <[email-masked]>, [email-masked]
Subject: RE: SubjectAltName verification
Date: Tue, 30 May 2000 09:01:46 -0700

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:[email-masked]]
Sent: Tuesday, May 30, 2000 8:33 AM
To: Peter Williams
Cc: 'Denis Pinkas'; [email-masked]
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.

Date: Tue, 30 May 2000 12:02:51 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Peter Williams <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, [email-masked]
Subject: Re: SubjectAltName verification

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.

Date: Tue, 30 May 2000 11:32:44 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Peter Williams <[email-masked]>
CC: "'Denis Pinkas'" <[email-masked]>, [email-masked]
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.

Date: Tue, 30 May 2000 11:04:53 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SubjectAltName verification
Cc: [email-masked]

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

Date: Tue, 30 May 2000 11:04:53 -0400
To: Bruno Salgueiro <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SubjectAltName verification
Cc: [email-masked]

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

From: Peter Williams <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Tue, 30 May 2000 07:57:48 -0700

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
[email-masked], 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 [email-masked] 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:[email-masked]]
Sent: Tuesday, May 30, 2000 1:31 AM
To: Stephen Kent
Cc: [email-masked]
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

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 May 2000 16:58:32 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Rationale for Nonce in Time Stamp Protocol
Cc: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 May 2000 16:40:34 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

Date: Tue, 30 May 2000 16:22:01 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Paul Hoffman <[email-masked]>
CC: [email-masked]
Subject: Re: Requirements for remote path processing services

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

Date: Tue, 30 May 2000 12:08:56 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2000 5:36 AM
> To: [email-masked]
> Cc: [email-masked]
> 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
> > [email-masked]      Tel. (613) 723-5076 ext. 419
> > http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Tue, 30 May 2000 11:24:54 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Manger, James H" <[email-masked]>
CC: [email-masked]
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

From: "Andy Dowling" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Requirements for remote path processing services
Date: Tue, 30 May 2000 09:47:03 +0100

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

Date: Tue, 30 May 2000 10:30:32 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stephen Kent <[email-masked]>
CC: [email-masked]
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

Date: Tue, 30 May 2000 09:11:13 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: Use cases for digital credentials

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:  +44 117 312 8794 (direct)           ++++  _/  _/  _/_/_/   ++++
>  Telnet: 312 8794                            +++++        _/       +++++
>  Fax:    +44 117 312 9250                    +++++++     _/      +++++++
>  Email:  [email-masked]           +++++++++++++++++++++++++++
> 
> =========================================================================
>     'All points of view are my own and not necessarily HP's as well'

Date: Mon, 29 May 2000 20:56:37 +0100
From: Bruno Salgueiro <[email-masked]>
Organization: SIBS
To: [email-masked]
Subject: Re: SubjectAltName verification

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

--------------ms1445816AA442E7D145F663F2--

From: Ambarish Malpani <[email-masked]>
To: "'Andy Dowling'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Requirements for remote path processing services
Date: Mon, 29 May 2000 11:27:33 -0700

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

> -----Original Message-----
> From: Andy Dowling [mailto:[email-masked]]
> Sent: Monday, May 29, 2000 4:02 AM
> To: Paul Hoffman
> Cc: [email-masked]
> 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
> 
> 
> 
> 
> 

Date: Mon, 29 May 2000 10:45:05 -0700
From: Ed Gerck <[email-masked]>
To: "Manger, James H" <[email-masked]>
CC: [email-masked]
Subject: applying detection theory, was Re: TSA Response serialNumber Field

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

Date: Mon, 29 May 2000 09:30:37 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: [email-masked]

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

Reply-To: <[email-masked]>
From: "Marco Casassa Mont" <[email-masked]>
To: <[email-masked]>
Subject: Use cases for digital credentials
Date: Mon, 29 May 2000 12:58:28 +0100
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:  +44 117 312 8794 (direct)           ++++  _/  _/  _/_/_/   ++++
 Telnet: 312 8794                            +++++        _/       +++++
 Fax:    +44 117 312 9250                    +++++++     _/      +++++++
 Email:  [email-masked]           +++++++++++++++++++++++++++

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

From: "Andy Dowling" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Requirements for remote path processing services
Date: Mon, 29 May 2000 12:01:30 +0100

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

Sender: [email-masked]
Date: Mon, 29 May 2000 12:36:57 +0200
From: Gabriel =?iso-8859-1?Q?L=F3pez=20Mill=E1n?= <[email-masked]>
To: [email-masked]
Subject: PKIX library 

    Hello all.

    There is any free pkix library for Java?

    Thanks, Gabi.

Date: Mon, 29 May 2000 12:20:33 +0200
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: "Manger, James H" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
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.

Date: Mon, 29 May 2000 12:13:22 +0200
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: Michael Zolotarev <[email-masked]>
CC: "Manger, James H" <[email-masked]>, [email-masked]
Subject: Re: TSA Response serialNumber Field

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

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 18:18:47 +1000

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

From: "Manger, James H" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Timestamp: id for token
Date: Mon, 29 May 2000 17:50:04 +1000

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.

Date: Mon, 29 May 2000 00:17:52 -0700
From: Ed Gerck <[email-masked]>
To: Al Arsenault <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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

From: Michael Zolotarev <[email-masked]>
To: "Manger, James H" <[email-masked]>, [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 16:16:58 +1000

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:[email-masked]]
> Sent: Monday, May 29, 2000 3:59 PM
> To: [email-masked]
> 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.
> 
> 
> 
>  
> 

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 15:59:15 +1000

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.

From: Michael Zolotarev <[email-masked]>
To: [email-masked]
Cc: [email-masked], xme <[email-masked]>, Peter Sylvester <[email-masked]>, [email-masked], William Lattin <[email-masked]>, [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 12:42:58 +1000

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

Date: Sun, 28 May 2000 21:27:15 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Peter Williams <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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.

From: Michael Zolotarev <[email-masked]>
To: Peter Sylvester <[email-masked]>
Cc: [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Mon, 29 May 2000 10:37:35 +1000

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

From: Peter Sylvester <[email-masked]>
Date: Sat, 27 May 2000 18:19:53 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: RE: TSA Response serialNumber Field
Cc: [email-masked], [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Sat, 27 May 2000 18:01:17 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

> 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  

From: Peter Sylvester <[email-masked]>
Date: Sat, 27 May 2000 17:07:40 +0200 (MET DST)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: TSA Response serialNumber Field
Cc: [email-masked], [email-masked], [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Sat, 27 May 2000 15:55:50 +0200 (MET DST)
To: [email-masked], [email-masked]
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 :-)

From: Peter Williams <[email-masked]>
To: [email-masked]
Subject: RE: SubjectAltName verification
Date: Fri, 26 May 2000 20:17:58 -0700

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:[email-masked]]
Sent: Friday, May 26, 2000 8:29 AM
To: Denis Pinkas
Cc: [email-masked]
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

Date: Fri, 26 May 2000 11:28:44 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SubjectAltName verification
Cc: [email-masked]

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

From: "William Lattin" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Michael Zolotarev" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: TSA Response serialNumber Field
Date: Fri, 26 May 2000 14:15:33 -0700
Importance: Normal

Denis,

Looks like we're converging on a better solution.

Bill

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, May 26, 2000 06:38
> To: Michael Zolotarev
> Cc: [email-masked]
> 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
>

From: Warwick Ford <[email-masked]>
To: Paul Koning <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: SubjectAltName verification
Date: Fri, 26 May 2000 12:53:47 -0700

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:[email-masked]]
Sent: Thursday, May 25, 2000 7:28 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]> 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."

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Fri, 26 May 2000 14:51:43 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Friday, May 26, 2000 9:38 AM
To: Michael Zolotarev
Cc: [email-masked]
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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Rationale for Nonce in Time Stamp Protocol
Date: Fri, 26 May 2000 13:26:34 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, May 24, 2000 5:36 AM
To: [email-masked]
Cc: [email-masked]
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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Fri, 26 May 2000 11:47:41 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Encrypting private keys - how do you achieve this in practice?
To: [email-masked]
Content-MD5: ldJJVH1qPkuDwazA2ooMOQ==

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

Date: Fri, 26 May 2000 16:16:24 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Juergen Brauckmann <[email-masked]>
CC: [email-masked]
Subject: Re: TSA Response serialNumber Field

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:[email-masked]
> 20097 Hamburg               http://www.trustcenter.de

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Encrypting private keys - how do you achieve this in practice ?
Date: Fri, 26 May 2000 10:14:39 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

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

Date: Fri, 26 May 2000 15:52:01 +0200
To: [email-masked]
From: Juergen Brauckmann <[email-masked]>
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.
"

Regards
   Juergen
-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC TrustCenter GmbH            Fax.:  040 / 8080 26 126
Sonninstraße 24-28   	    mailto:[email-masked]
20097 Hamburg 		    http://www.trustcenter.de	

Date: Fri, 26 May 2000 15:38:26 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael Zolotarev <[email-masked]>
CC: [email-masked]
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

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Encrypting private keys - how do you achieve this in practice?
Date: Fri, 26 May 2000 11:35:06 +0100

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

From: [email-masked]
Date: Fri, 26 May 2000 19:49:20 +1000
To: [email-masked]
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: 612 9955 7990 | Fax: 612 9955 0076 
Copyright © 1990-2000 All Rights Reserved

If you think, that you will not benefit from this corespondence, send

an email to:

[email-masked]	Subject:Remove gravity

From: Michael Zolotarev <[email-masked]>
To: Paul Koning <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Fri, 26 May 2000 15:40:03 +1000

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

Date: Thu, 25 May 2000 17:42:08 -0400
To: Paul Koning <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

Date: Thu, 25 May 2000 17:38:25 -0400
To: Eric Norman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Encryption of Private Keys in CRMF and CMP
Date: Thu, 25 May 2000 15:41:47 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Thu, 25 May 2000 10:45:14 -0700
To: Peter Sylvester <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

Date: Thu, 25 May 2000 12:16:06 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: [email-masked]
Subject: Re: TSA Response serialNumber Field

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

Date: Thu, 25 May 2000 12:56:18 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: SubjectAltName verification
To: [email-masked]
Content-MD5: n3OxXH3zWqdc8OkFKoHPGA==

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 May 2000 18:34:05 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 12:20:38 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field

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

Date: Thu, 25 May 2000 12:11:48 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 May 2000 17:38:15 +0200 (MET DST)
To: [email-masked]
Subject: Re: ASN.1 OPTIONAL   in TSA
Cc: [email-masked]

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

Date: Thu, 25 May 2000 17:39:54 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Comments on draft-ietf-pkix-ac509prof-03

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 May 2000 17:32:38 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  ASN.1 OPTIONAL   in TSA
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 26 May 2000 03:31:09 (NZST)

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

Date: Thu, 25 May 2000 11:14:10 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: [email-masked]

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

Date: Thu, 25 May 2000 17:15:09 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Paul Koning <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: SubjectAltName verification

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

From: [email-masked]
To: Peter Williams <[email-masked]>
cc: "'Stephen Kent'" <[email-masked]>, [email-masked]
Date: Thu, 25 May 2000 11:00:31 -0400
Subject: RE: SubjectAltName verification

     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 <[email-masked]> on 05/24/2000 10:46:20 PM

To:   "'Stephen Kent'" <[email-masked]>
cc:   [email-masked]
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:[email-masked]]
Sent: Wednesday, May 24, 2000 8:42 AM
To: Peter Williams
Cc: [email-masked]
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

Date: Thu, 25 May 2000 10:41:28 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

From: "Serafim Gomes" <[email-masked]>
To: [email-masked]
Date: Thu, 25 May 2000 15:30:22 +0100
Subject: ASN.1 OPTIONAL   in TSA
Reply-to: [email-masked]
Priority: normal

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
[email-masked]           telm: +351 - 938421578  telf: +351-253548100
http://www.pobox.com/~serafim

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 10:28:12 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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 <[email-masked]> 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."

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 10:21:33 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: TSA Response serialNumber Field

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

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 10:19:41 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field

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

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 10:13:48 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: SubjectAltName verification

>>>>> "Peter" == Peter Williams <[email-masked]> 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

Date: Thu, 25 May 2000 16:13:17 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: TSA Response serialNumber Field

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

Date: Thu, 25 May 2000 09:29:47 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Christopher Williams <[email-masked]>
CC: PKIX Mailing List <[email-masked]>
Subject: Re: What is the meaning of the "indirectCRL" flag

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

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: What is the meaning of the "indirectCRL" flag
Date: Thu, 25 May 2000 13:56:38 +0100

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 May 2000 13:59:42 +0200 (MET DST)
To: [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]

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

Date: Thu, 25 May 2000 10:30:19 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: TSA Response serialNumber Field

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.

Date: Thu, 25 May 2000 09:51:17 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: William Lattin <[email-masked]>
CC: [email-masked]
Subject: Re: TSA Response serialNumber Field

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:[email-masked]]
> > Sent: Wednesday, May 24, 2000 01:47
> > To: [email-masked]
> > Cc: [email-masked]'; [email-masked]';
> > [email-masked]'
> > 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:[email-masked]]
> > > Sent:   Thursday, May 18, 2000 8:37 PM
> > > To:     [email-masked]; [email-masked]
> > > Cc:     [email-masked]
> > > Subject:        Re: TSA Response serialNumber Field
> > >
> > > [email-masked] 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.
> >

Date: Thu, 25 May 2000 09:34:47 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: TSA Response serialNumber Field

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

From: "William Lattin" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: TSA Response serialNumber Field
Date: Wed, 24 May 2000 20:57:03 -0700
Importance: Normal

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

From: Peter Williams <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Wed, 24 May 2000 19:46:20 -0700

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:[email-masked]]
Sent: Wednesday, May 24, 2000 8:42 AM
To: Peter Williams
Cc: [email-masked]
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

Date: Wed, 24 May 2000 16:02:02 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: SubjectAltName verification

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:[email-masked]]
>Sent: Wednesday, May 24, 2000 8:05 AM
>To: Denis Pinkas
>Cc: [email-masked]
>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

From: Warwick Ford <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Wed, 24 May 2000 13:48:19 -0700

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:[email-masked]]
Sent: Wednesday, May 24, 2000 8:05 AM
To: Denis Pinkas
Cc: [email-masked]
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

From: Peter Sylvester <[email-masked]>
Date: Wed, 24 May 2000 18:48:28 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: RE: TSA Response serialNumber Field
Cc: [email-masked]

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. 

From: Peter Sylvester <[email-masked]>
Date: Wed, 24 May 2000 18:22:00 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked], [email-masked], [email-masked]

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

Date: Wed, 24 May 2000 11:41:32 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: [email-masked]

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

Date: Wed, 24 May 2000 11:05:24 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SubjectAltName verification
Cc: [email-masked]

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

From: "William Lattin" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: TSA Response serialNumber Field
Date: Wed, 24 May 2000 07:42:56 -0700
Importance: Normal

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:[email-masked]]
> Sent: Wednesday, May 24, 2000 01:47
> To: [email-masked]
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'
> 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:[email-masked]]
> > Sent:   Thursday, May 18, 2000 8:37 PM
> > To:     [email-masked]; [email-masked]
> > Cc:     [email-masked]
> > Subject:        Re: TSA Response serialNumber Field
> >
> > [email-masked] 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.
>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 25 May 2000 02:26:07 (NZST)

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

From: Paul Koning <[email-masked]>
Date: Wed, 24 May 2000 10:05:28 -0400 (EDT)
To: [email-masked]
Cc: <[email-masked]>
Subject: Re: TSA Response serialNumber Field

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

Date: Wed, 24 May 2000 11:36:20 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Wed, 24 May 2000 10:46:57 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "[email-masked]" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
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:[email-masked]]
> Sent:   Thursday, May 18, 2000 8:37 PM
> To:     [email-masked]; [email-masked]
> Cc:     [email-masked]
> Subject:        Re: TSA Response serialNumber Field
> 
> [email-masked] 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.

Date: Wed, 24 May 2000 10:30:11 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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

From: Michael Zolotarev <[email-masked]>
To: [email-masked], "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: TSA Response serialNumber Field
Date: Wed, 24 May 2000 09:43:41 +1000

A very fair comment, Bill. Worth mentioning in the draft, Denis?

> -----Original Message-----
> From: Bill Lattin [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2000 1:14 AM
> To: [email-masked]'; [email-masked]';
> [email-masked]'
> Cc: [email-masked]'
> 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:[email-masked]]
> Sent:	Thursday, May 18, 2000 8:37 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	Re: TSA Response serialNumber Field
> 
> [email-masked] 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.
> 

From: Peter Williams <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Tue, 23 May 2000 15:38:30 -0700

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:[email-masked]]
Sent: Tuesday, May 23, 2000 1:33 PM
To: Peter Williams
Cc: [email-masked]
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

Date: Tue, 23 May 2000 16:33:00 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: [email-masked]

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

From: Peter Williams <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Tue, 23 May 2000 13:17:34 -0700

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:[email-masked]]
Sent: Tuesday, May 23, 2000 12:30 PM
To: Peter Williams
Cc: [email-masked]
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

Date: Tue, 23 May 2000 16:12:07 -0400
To: [email-masked]
From: Robert Moskowitz <[email-masked]>
Subject: Next round of CMP testing -- jun 6 - 8

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

Date: Tue, 23 May 2000 15:29:38 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: [email-masked]

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

From: Peter Williams <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Tue, 23 May 2000 12:12:39 -0700

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:[email-masked]]
Sent: Tuesday, May 23, 2000 9:53 AM
To: Denis Pinkas
Cc: [email-masked]
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

Date: Tue, 23 May 2000 10:59:45 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Requirements for remote path processing services

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

From: "Stringfield, Robert Mr." <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: FQDN vs ALIAS
Date: Tue, 23 May 2000 19:11:06 +0200

Is this question acceptable to this list?  If not could you provide me with
pointers as we have no ideas :-)....
--bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 23, 2000 6:41 PM
To: [email-masked]
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 520-538-1232
[email-masked]

Date: Tue, 23 May 2000 12:52:58 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SubjectAltName verification
Cc: [email-masked]

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

From: Bill Lattin <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: TSA Response serialNumber Field
Date: Tue, 23 May 2000 08:13:59 -0700

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:[email-masked]]
Sent:	Thursday, May 18, 2000 8:37 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]
Subject:	Re: TSA Response serialNumber Field

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

From: "Christopher Williams" <[email-masked]>
To: <[email-masked]>
Cc: "PKIX Mailing List" <[email-masked]>
Subject: Re: Multiple questions
Date: Tue, 23 May 2000 13:28:15 +0100

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

From: "Serafim Gomes" <[email-masked]>
To: [email-masked]
Date: Tue, 23 May 2000 11:44:44 +0100
Subject: TSA: Multiple questions
Reply-to: [email-masked]
Priority: normal

<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

	[email-masked]

Date: Mon, 22 May 2000 10:53:54 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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

Date: Fri, 19 May 2000 15:47:22 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: AW: SubjectAltName verification

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Rationale for Nonce in Time Stamp Protocol
Date: Fri, 19 May 2000 15:00:21 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

From: "Peter Lipp" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
Cc: <[email-masked]>
Subject: AW: SubjectAltName verification
Date: Fri, 19 May 2000 18:55:30 +0200
Importance: Normal

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"

AAAAAAAA
----IAIK.SMIME.MAPPER.92F749A7----

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-03.txt
Date: Fri, 19 May 2000 06:51:54 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 18 May 2000 22:52:41 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: SubjectAltName verification

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

From: "Nelson, Patt" <[email-masked]>
To: [email-masked]
Subject: remove
Date: Thu, 18 May 2000 15:15:10 -0700

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"

------=_NextPart_000_0031_01BFC0DB.DC26E2D0--

Date: Thu, 18 May 2000 17:57:21 -0400
To: Warwick Ford <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: [email-masked]

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

Sender: [email-masked]
Date: Thu, 18 May 2000 11:53:15 -0700
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: SubjectAltName verification

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.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

Date: Thu, 18 May 2000 19:05:13 +0200
From: =?iso-8859-1?Q?Bego=F1a?= Canas <[email-masked]>
Organization: EUSKALTEL
To: [email-masked]
CC: [email-masked], ietf-pkix <[email-masked]>, "'Thierry Van Doninck'" <[email-masked]>
Subject: Re: Does Smime works fine with Windows 2000 PKI

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

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

--------------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>[email-masked] 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;[email-masked]> 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:[email-masked]">mailto:[email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked]
<br>----------------------------------------
<br>&nbsp;</html>

--------------7695007A7B1C7CFEB42E8C6C--

Date: Thu, 18 May 2000 12:02:52 -0400
From: Mike Jenkins <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Standardization of certificate classes

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

Date: Thu, 18 May 2000 18:00:58 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Paul Koning <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 19 May 2000 03:37:07 (NZST)

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

Date: Thu, 18 May 2000 16:21:16 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Warwick Ford <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 18 May 2000 16:19:01 +0200 (MET DST)
To: [email-masked]
Subject: Re: SubjectAltName verification
Cc: [email-masked]

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

From: Paul Koning <[email-masked]>
Date: Thu, 18 May 2000 10:09:03 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: TSA Response serialNumber Field

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

From: Warwick Ford <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, Al Arsenault <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Thu, 18 May 2000 06:54:59 -0700

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

From: Paul Koning <[email-masked]>
Date: Thu, 18 May 2000 09:52:03 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: SubjectAltName verification

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

From: Warwick Ford <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Thu, 18 May 2000 06:50:19 -0700

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

Date: Thu, 18 May 2000 15:46:34 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Al Arsenault <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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.

Date: Thu, 18 May 2000 15:20:04 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: TSA Response serialNumber Field

> 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
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078

Content-return: allowed
Date: Thu, 18 May 2000 08:41:30 -0400
From: "Yutzy, Murray" <[email-masked]>
Subject: RE: SubjectAltName verification
To: "'Al Arsenault'" <[email-masked]>, [email-masked]

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.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: TSA Response serialNumber Field
Date: Thu, 18 May 2000 08:44:20 -0400

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
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Thu, 18 May 2000 08:28:24 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: [email-masked]
Subject: Re: SubjectAltName verification

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.

Date: Thu, 18 May 2000 10:22:05 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 18 May 2000 09:49:14 +0200 (MET DST)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: SubjectAltName verification
Cc: [email-masked]

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

Date: Thu, 18 May 2000 08:53:08 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stephen Kent <[email-masked]>, Warwick Ford <[email-masked]>
CC: [email-masked]
Subject: Re: SubjectAltName verification

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

Date: Thu, 18 May 2000 00:32:21 -0400
To: Warwick Ford <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: [email-masked]

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

From: "Al Arsenault" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: SubjectAltName verification
Date: Wed, 17 May 2000 13:25:38 -0400

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 <[email-masked]>
> To: Al Arsenault <[email-masked]>; 'Paul Koning' <[email-masked]>
> Cc: [email-masked] <[email-masked]>; [email-masked]
> <[email-masked]>
> 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 "[email-masked]", 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 =
[email-masked].

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

From: Warwick Ford <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Robert Moskowitz <[email-masked]>
Cc: [email-masked]
Subject: RE: SubjectAltName verification
Date: Wed, 17 May 2000 15:39:43 -0700

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:[email-masked]]
Sent: Monday, May 15, 2000 9:46 PM
To: Robert Moskowitz
Cc: [email-masked]
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

From: "Ivo MACHULDA" <[email-masked]>
To: "ietf-pkix" <[email-masked]>
Subject: Can I insert char "@" in to common name in certificate?
Date: Wed, 17 May 2000 23:29:25 +0200

Dear sir,
Please tell me.Can I insert char "@" in to common name in certificate?

Thank you very much

Ivo MACHULDA

From: "Stringfield, Robert Mr." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], ietf-pkix <[email-masked]>, "'Thierry Van Doninck'" <[email-masked]>
Subject:  Does Smime works fine with Windows 2000 PKI
Date: Wed, 17 May 2000 08:26:04 +0200

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

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

From: [email-masked]
Date: Tue, 16 May 2000 14:12:00 -0600
Subject: RE: Does Smime works fine with Windows 2000 PKI
To: [email-masked], ietf-pkix<[email-masked]>, "'Thierry Van Doninck'"<[email-masked]>

--____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 <[email-masked]> 05/15/00 04:46PM >>>
http://support.microsoft.com/support/exchange/content/whitepapers/win2k_kms=

From: Carlisle Adams <[email-masked]>
To: "'denis bider'" <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: RFC 2511: PKIArchiveOptions encoding?
Date: Tue, 16 May 2000 14:20:03 -0400

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 ([email-masked]) or the PKI Forum
(http://www.pkiforum.org) for further details.

> ----------
> From: 	denis bider[SMTP:[email-masked]]
> Sent: 	Tuesday, May 16, 2000 9:15 AM
> To: 	[email-masked]
> 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 {
>    ...
> }
> 
> 

From: [email-masked]
Date: Tue, 16 May 2000 08:47:00 -0600
Subject: RE: Does Smime works fine with Windows 2000 PKI
To: [email-masked], ietf-pkix<[email-masked]>, "'Thierry Van Doninck'"<[email-masked]>

Date: Tue, 16 May 2000 15:07:13 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Linn, John" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, xme <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-03

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) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: "Linn, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-03
Date: Tue, 16 May 2000 09:53:23 -0400

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

From: "Scott J. Tamosunas" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Tue, 16 May 2000 09:17:21 -0400
Importance: Normal

unsubscribe

From: "denis bider" <[email-masked]>
To: <[email-masked]>
Subject: RFC 2511: PKIArchiveOptions encoding?
Date: Tue, 16 May 2000 15:15:57 +0200
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 {
   ...
}

From: "Andy Dowling" <[email-masked]>
To: <[email-masked]>, "Linn, John" <[email-masked]>
Cc: <[email-masked]>, "RussHousley" <[email-masked]>, "xme" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-03
Date: Tue, 16 May 2000 13:16:15 +0100

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

Date: Tue, 16 May 2000 12:11:41 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Linn, John" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, RussHousley <[email-masked]>, xme <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-03

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) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: announce: xmlcert discussion list
Date: Tue, 16 May 2000 08:52:49 +0200
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 [email-masked], which
contains

subscribe xmlcert <your name>

in the body of the message.  Contributions can then be sent to
[email-masked], 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: +43 316 873 5513
Fax: +43 316 873 5520
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"

AAAAAAAA
----IAIK.SMIME.MAPPER.018ED18F----

Date: Tue, 16 May 2000 00:45:40 -0400
To: Robert Moskowitz <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: "[email-masked]" <[email-masked]>

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

From: Peter Williams <[email-masked]>
To: "'Thierry Van Doninck'" <[email-masked]>, ietf-pkix <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Mon, 15 May 2000 15:46:39 -0700

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

From: "Linn, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Comments on draft-ietf-pkix-ac509prof-03
Date: Mon, 15 May 2000 16:44:42 -0400

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

From: Paul Koning <[email-masked]>
Date: Mon, 15 May 2000 15:55:17 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: SubjectAltName verification

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

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

From: [email-masked]
To: Robert Moskowitz <[email-masked]>
cc: "Martin Szotkowski" <[email-masked]>, [email-masked]
Date: Mon, 15 May 2000 15:48:55 -0400
Subject: Re: SubjectAltName verification

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

          Tom Gindin

Robert Moskowitz <[email-masked]> on 05/15/2000 02:09:10 PM

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

Date: Mon, 15 May 2000 12:24:01 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: SubjectAltName verification

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

Date: Mon, 15 May 2000 15:05:25 -0400
To: Al Arsenault <[email-masked]>, "'Paul Koning'" <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

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

From: Al Arsenault <[email-masked]>
To: "'Paul Koning'" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: SubjectAltName verification
Date: Mon, 15 May 2000 14:50:33 -0400
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 "[email-masked]", 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:[email-masked]]
Sent:	Monday, May 15, 2000 2:22 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	Re: SubjectAltName verification

>>>>> "Robert" == Robert Moskowitz <[email-masked]> 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

Date: Mon, 15 May 2000 11:47:36 -0700
To: [email-masked]
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: plain text version of RE: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2459)

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 <[email-masked]>
>To: "'Sam Schaen'" <[email-masked]>,
>         Ismo Heikkonen
>	<[email-masked]>
>Cc: [email-masked]
>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:[email-masked]?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:[email-masked]]
>Sent: Monday, May 15, 2000 6:02 AM
>To: Ismo Heikkonen
>Cc: [email-masked]
>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

From: Paul Koning <[email-masked]>
Date: Mon, 15 May 2000 14:22:06 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: SubjectAltName verification

>>>>> "Robert" == Robert Moskowitz <[email-masked]> 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

Date: Mon, 15 May 2000 14:09:10 -0400
To: "Martin Szotkowski" <[email-masked]>, <[email-masked]>
From: Robert Moskowitz <[email-masked]>
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: [email-masked]

Date: Mon, 15 May 2000 10:29:58 -0700
To: [email-masked]
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: Fwd: RE: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2459)

<!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;[email-masked]&gt;<br>
To: &quot;'Sam Schaen'&quot; &lt;[email-masked]&gt;,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ismo Heikkonen<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>&lt;[email-masked]&gt;<br>
Cc: [email-masked]<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:[email-masked]?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:[email-masked]]<br>
Sent: Monday, May 15, 2000 6:02 AM<br>
To: Ismo Heikkonen<br>
Cc: [email-masked]<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>

From: Warwick Ford <[email-masked]>
To: "'Sam Schaen'" <[email-masked]>, Ismo Heikkonen <[email-masked]>
Cc: [email-masked]
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

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:[email-masked]]
Sent: Monday, May 15, 2000 6:02 AM
To: Ismo Heikkonen
Cc: [email-masked]
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

From: Philip Hallam-Baker <[email-masked]>
To: "'Sam Schaen'" <[email-masked]>, Ismo Heikkonen <[email-masked]>
Cc: [email-masked]
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

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:[email-masked]]
Sent: Monday, May 15, 2000 9:02 AM
To: Ismo Heikkonen
Cc: [email-masked]
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"

------=_NextPart_000_0019_01BFBE55.300EFF10--

From: Philip Hallam-Baker <[email-masked]>
To: "'Thierry Van Doninck'" <[email-masked]>, ietf-pkix <[email-masked]>
Subject: RE: Does Smime works fine with Windows 2000 PKI
Date: Mon, 15 May 2000 06:04:40 -0700

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

------=_NextPart_000_0011_01BFBE4C.BE742D60--

Date: Mon, 15 May 2000 09:01:47 -0400
From: Sam Schaen <[email-masked]>
Organization: The MITRE Corporation
To: Ismo Heikkonen <[email-masked]>
CC: [email-masked]
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

From: "Ismo Heikkonen" <[email-masked]>
To: <[email-masked]>
Subject: Inconsistency between X.509-97 and RFC 2459 (and son of RFC 2459)
Date: Mon, 15 May 2000 15:20:41 +0300

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

Date: Mon, 15 May 2000 10:20:30 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stefan Santesson <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Unmistakable identity

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:[email-masked]]
> > Sent: Thursday, May 11, 2000 12:55 PM
> > To: Stefan Santesson
> > Cc: 'Russ Housley'; 'Stephen Kent'; [email-masked]'
> > 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:[email-masked]]
> > > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > > To: Stefan Santesson
> > > > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > > > 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:[email-masked]]
> > > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > > To: Stephen Kent
> > > > > > Cc: [email-masked]; [email-masked]
> > > > > > 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
> > > > > >
> > > >
> >

Date: Fri, 12 May 2000 11:37:28 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: attribute certificates

Folks,

	- The WG last call will begin on the Attribute Certificate ID 
<draft-ietf-pkix-ac509prof-03.txt> and end on May 26.

Steve

From: [email-masked]
cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Fri, 12 May 2000 10:56:09 -0400
Subject: RE: Unmistakable identity

     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 <[email-masked]> on 05/12/2000 06:12:57 AM

To:   "'Denis Pinkas'" <[email-masked]>
cc:   "'Russ Housley'" <[email-masked]>, "'Stephen Kent'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>
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:[email-masked]]
> Sent: Thursday, May 11, 2000 12:55 PM
> To: Stefan Santesson
> Cc: 'Russ Housley'; 'Stephen Kent'; [email-masked]'
> 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:[email-masked]]
> > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > To: Stefan Santesson
> > > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > > 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:[email-masked]]
> > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > To: Stephen Kent
> > > > > Cc: [email-masked]; [email-masked]
> > > > > 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
> > > > >
> > >
>

From: Stefan Santesson <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Unmistakable identity
Date: Fri, 12 May 2000 12:12:57 +0200

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:[email-masked]]
> Sent: Thursday, May 11, 2000 12:55 PM
> To: Stefan Santesson
> Cc: 'Russ Housley'; 'Stephen Kent'; [email-masked]'
> 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:[email-masked]]
> > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > To: Stefan Santesson
> > > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > > 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:[email-masked]]
> > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > To: Stephen Kent
> > > > > Cc: [email-masked]; [email-masked]
> > > > > 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
> > > > >
> > >
> 

From: [email-masked]
To: [email-masked]
cc: pkix list <[email-masked]>
Date: Thu, 11 May 2000 11:01:58 -0400
Subject: Re: DER in ac509prof-03

     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" <[email-masked]> on 05/10/2000 09:11:30 PM

Please respond to [email-masked]

To:   pkix list <[email-masked]>
cc:
Subject:  Re: DER in ac509prof-03

Tom,

Comments below.

[email-masked] 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 <[email-masked]>; Thu, 11 May 2000 04:37:59 -0700 (PDT)
Date: 11 May 2000 13:39:53 +0200
From: Thierry Van Doninck <[email-masked]>
To: ietf-pkix <[email-masked]>
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

Date: Thu, 11 May 2000 12:56:31 +0200
From: Hardo Hase <[email-masked]>
Organization: =?iso-8859-1?Q?Universit=E4t?= des Saarlandes
To: "[email-masked]'" <[email-masked]>
Subject: unsubscribe

unsubscribe

Date: Thu, 11 May 2000 13:00:41 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stefan Santesson <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>, "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Subject: Re: Unmistakable identity

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'; [email-masked]'
> > 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:[email-masked]]
> > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > To: Stefan Santesson
> > > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > > 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:[email-masked]]
> > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > To: Stephen Kent
> > > > > Cc: [email-masked]; [email-masked]
> > > > > 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
> > > > >
> > >
> >

Date: Thu, 11 May 2000 12:54:56 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stefan Santesson <[email-masked]>
CC: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "[email-masked]'" <[email-masked]>
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:[email-masked]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > 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:[email-masked]]
> > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > To: Stephen Kent
> > > > Cc: [email-masked]; [email-masked]
> > > > 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
> > > >
> >

Date: Wed, 10 May 2000 21:11:30 -0400
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting  
To: pkix list <[email-masked]>
Subject: Re: DER in ac509prof-03

Tom,

Comments below.

[email-masked] 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 <[email-masked]> on 05/10/2000 12:27:54 PM
> 
> To:   [email-masked]
> cc:   [email-masked], [email-masked],
>       [email-masked]
> Subject:  Re: DER in ac509prof-03
> 
> >>>>> "Russ" == Russ Housley <[email-masked]> 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
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------

Date: Wed, 10 May 2000 21:39:09 -0400
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting  
To: pkix list <[email-masked]>
Subject: Re: DER in ac509prof-03

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
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------
 
> Russ
> 
> At 12:27 PM 05/10/2000 -0400, Paul Koning wrote:
> > >>>>> "Russ" == Russ Housley <[email-masked]> 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

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: DER in ac509prof-03
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 11 May 2000 08:13:07 (NZST)

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

Date: Wed, 10 May 2000 15:54:27 -0400
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting 
To: [email-masked]
Subject: Re: DER in ac509prof-03

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) +353 1 647 7406
> >61 Fitzwilliam Lane,                    fax: +353 1 647 7499
> >Dublin 2.                mailto:[email-masked]
> >Ireland                             http://www.baltimore.com

Date: Wed, 10 May 2000 15:43:20 -0400
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting  
To: [email-masked]
Subject: Re: DER in ac509prof-03

Rich Ankney wrote:
> 
> -----Original Message-----
> From: Peter Gutmann <[email-masked]>
> To: [email-masked] <[email-masked]>
> Cc: [email-masked] <[email-masked]>
> Date: Wednesday, May 10, 2000 1:28 PM
> Subject: Re: DER in ac509prof-03
> 
> >Paul Koning <[email-masked]> 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
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------

From: "Rich Ankney" <[email-masked]>
To: "Paul Koning" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: DER in ac509prof-03
Date: Wed, 10 May 2000 15:48:56 -0400

Simple; just update everything to ASN.1:1997 :-)

-----Original Message-----
From: Paul Koning <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, May 10, 2000 3:01 PM
Subject: Re: DER in ac509prof-03

>>>>>> "Rich" == Rich Ankney <[email-masked]> 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

From: Paul Koning <[email-masked]>
Date: Wed, 10 May 2000 14:59:15 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: DER in ac509prof-03

>>>>> "Rich" == Rich Ankney <[email-masked]> 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

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: DER in ac509prof-03
Date: Wed, 10 May 2000 14:55:37 -0400

-----Original Message-----
From: Peter Gutmann <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, May 10, 2000 1:28 PM
Subject: Re: DER in ac509prof-03

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

From: [email-masked]
To: Paul Koning <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 10 May 2000 13:34:55 -0400
Subject: Re: DER in ac509prof-03

     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 <[email-masked]> on 05/10/2000 12:27:54 PM

To:   [email-masked]
cc:   [email-masked], [email-masked],
      [email-masked]
Subject:  Re: DER in ac509prof-03

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

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: DER in ac509prof-03
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 11 May 2000 05:23:41 (NZST)

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

Date: Wed, 10 May 2000 12:59:22 -0400
To: Paul Koning <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: DER in ac509prof-03
Cc: [email-masked], [email-masked], [email-masked]

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

Date: Wed, 10 May 2000 12:29:20 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: DER in ac509prof-03
Cc: [email-masked], [email-masked], xme <[email-masked]>

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) +353 1 647 7406
>61 Fitzwilliam Lane,                    fax: +353 1 647 7499
>Dublin 2.                mailto:[email-masked]
>Ireland                             http://www.baltimore.com

From: Paul Koning <[email-masked]>
Date: Wed, 10 May 2000 12:27:54 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: DER in ac509prof-03

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

Date: Wed, 10 May 2000 12:17:40 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: DER in ac509prof-03
Cc: [email-masked]

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
>+1-919-832-7008         1625 Glenwood Avenue, Five Points
>+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
>------------------------------------------------------------

Date: Wed, 10 May 2000 12:12:42 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: DER in ac509prof-03
Cc: [email-masked], [email-masked]

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
> > +1-919-832-7008         1625 Glenwood Avenue, Five Points
> > +1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
> > ------------------------------------------------------------
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) +353 1 647 7406
>61 Fitzwilliam Lane,                    fax: +353 1 647 7499
>Dublin 2.                mailto:[email-masked]
>Ireland                             http://www.baltimore.com

Date: Wed, 10 May 2000 11:38:18 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: SMIME conformance specs
Cc: [email-masked]

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

Date: Wed, 10 May 2000 16:38:25 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: [email-masked], xme <[email-masked]>, RussHousley <[email-masked]>
Subject: Re: DER in ac509prof-03

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) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: [email-masked]
To: Robert Moskowitz <[email-masked]>
cc: [email-masked]
Date: Wed, 10 May 2000 11:27:33 -0400
Subject: Re: ASN.1 Name joys

     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 <[email-masked]> on 05/05/2000 04:00:23 PM

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

From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked]
Date: Wed, 10 May 2000 11:12:45 -0400
Subject: Re: DER in ac509prof-03

     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 <[email-masked]> on 05/10/2000 06:43:04 AM

Please respond to [email-masked]

To:   [email-masked]
cc:   [email-masked]
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
> +1-919-832-7008         1625 Glenwood Avenue, Five Points
> +1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
> ------------------------------------------------------------

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: Peter Sylvester <[email-masked]>
Date: Wed, 10 May 2000 13:10:11 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Who can be a Time Stamping Authority?
Cc: [email-masked]

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

Date: Wed, 10 May 2000 11:43:04 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: [email-masked]
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
> +1-919-832-7008         1625 Glenwood Avenue, Five Points
> +1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
> ------------------------------------------------------------

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: Michael Zolotarev <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Who can be a Time Stamping Authority?
Date: Wed, 10 May 2000 16:43:32 +1000

I guess a need to clarify a few points here, to avoid possible
misunderstanding about my opinion.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 10, 2000 4:04 AM
> To: [email-masked]
> Cc: [email-masked]
> 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

From: Michael Zolotarev <[email-masked]>
To: [email-masked], Michael Zolotarev <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Wed, 10 May 2000 11:48:26 +1000

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
> [email-masked]      Tel. (613) 723-5077 Ext. 419
> http://www.chrysalis-its.com       Fax. (613) 723-5078
> 

Date: Tue, 09 May 2000 20:33:53 -0400
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting 
To: [email-masked]
Subject: DER in ac509prof-03

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
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------

Date: Tue, 09 May 2000 19:32:52 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Andy Dowling <[email-masked]>
CC: [email-masked], xme <[email-masked]>
Subject: Re: AC profile - Policy Authority on the Role attribute

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) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Who can be a Time Stamping Authority?
Date: Tue, 9 May 2000 14:04:14 -0400 

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
[email-masked]      Tel. (613) 723-5077 Ext. 419
http://www.chrysalis-its.com       Fax. (613) 723-5078

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Tue, 9 May 2000 13:55:59 -0400 

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
[email-masked]      Tel. (613) 723-5077 Ext. 419
http://www.chrysalis-its.com       Fax. (613) 723-5078

From: "Charlie Fletcher - www.ukdata.com" <[email-masked]>
To: "Finance Director" <[email-masked]>
Subject: Instant On-Line Credit Reports
Date: Tue, 9 May 2000 16:34:00 +0100

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

From: "Martin Szotkowski" <[email-masked]>
To: <[email-masked]>
Subject: SubjectAltName verification
Date: Tue, 9 May 2000 19:27:16 +0200
Organization: PVT, a.s.

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

From: "Andy Dowling" <[email-masked]>
To: <[email-masked]>
Subject: AC profile - Policy Authority on the Role attribute
Date: Tue, 9 May 2000 16:17:11 +0100

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ac509prof-03.txt
Date: Tue, 09 May 2000 06:36:34 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 9 May 2000 00:46:46 -0700
To: OSI Directory List <[email-masked]>, [email-masked]
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: revised 4th edition text

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

To: IETF-Announce: ;
Subject: RFC 2797 on Certificate Management Messages over CMS
Cc: [email-masked], [email-masked]
Date: Mon, 08 May 2000 15:02:08 -0700
From: RFC Editor <[email-masked]>

--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:    [email-masked], [email-masked],
                    [email-masked], [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

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

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

--OtherAccess--
--NextPart--

Date: Mon, 8 May 2000 09:07:08 -0400 (EDT)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
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

Date: Sat, 6 May 2000 19:37:10 -0400 (EDT)
From: Rich Salz <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt

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$

Date: Sat, 6 May 2000 15:09:26 -0400 (EDT)
From: Rich Salz <[email-masked]>
To: Bruce Greenblatt <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt

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

Date: Sat, 06 May 2000 10:02:37 -0700
To: "Salz, Rich" <[email-masked]>
From: Bruce Greenblatt <[email-masked]>
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Cc: [email-masked], [email-masked]

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

Date: Fri, 05 May 2000 16:00:23 -0400
To: [email-masked]
From: Robert Moskowitz <[email-masked]>
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: [email-masked]

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Comments on TSA Draft v7
Date: Fri, 5 May 2000 12:34:52 -0400 

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
[email-masked]      Tel. (613) 723-5077 Ext. 419
http://www.chrysalis-its.com       Fax. (613) 723-5078

Sender: [email-masked]
Date: Fri, 05 May 2000 08:10:21 -0700
From: Michael Sierchio <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: Generating Key Pair

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>

To: [email-masked]
Date: Fri, 05 May 2000 06:19:01 -0700
From: "chandrasekaran natarajan" <[email-masked]>
Reply-To: [email-masked]
Subject: Generating Key Pair
Organization: MailCity  (http://www.mailcity.lycos.com:80)

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-pi-00.txt
Date: Fri, 05 May 2000 06:40:42 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

From: Carlisle Adams <[email-masked]>
To: PKIX Mailing List <[email-masked]>, "'Christopher Williams'" <[email-masked]>
Subject: RE: Message protection and key update
Date: Thu, 4 May 2000 13:17:31 -0400 

Hi Chris,

> ----------
> From: 	Christopher Williams[SMTP:[email-masked]]
> 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.

From: "Stefan Santesson" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>
cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Subject: RE: Unmistakable identity
Date: Thu, 4 May 2000 12:34:46 +0200

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'; [email-masked]'
> 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:[email-masked]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > 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:[email-masked]]
> > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > To: Stephen Kent
> > > > Cc: [email-masked]; [email-masked]
> > > > 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
> > > >
> > 
> 

From: "Salz, Rich" <[email-masked]>
To: "'Bruce Greenblatt'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Date: Thu, 4 May 2000 11:01:18 -0400 

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

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Message protection and key update
Date: Thu, 4 May 2000 16:53:04 +0100

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

From: "Salz, Rich" <[email-masked]>
To: "'Bruce Greenblatt'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Date: Thu, 4 May 2000 11:01:18 -0400 

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

From: Stefan Santesson <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Subject: RE: Unmistakable identity
Date: Thu, 4 May 2000 12:34:46 +0200 

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'; [email-masked]'
> 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:[email-masked]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > 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:[email-masked]]
> > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > To: Stephen Kent
> > > > Cc: [email-masked]; [email-masked]
> > > > 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
> > > >
> > 
> 

From: Stefan Santesson <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Unmistakable identity
Date: Thu, 4 May 2000 12:04:23 +0200 

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:[email-masked]]
> Sent: Wednesday, April 26, 2000 10:27 AM
> To: Stefan Santesson
> Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> 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:[email-masked]]
> > > Sent: Friday, April 14, 2000 4:36 PM
> > > To: Stephen Kent
> > > Cc: [email-masked]; [email-masked]
> > > 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
> > >
> 

Date: Wed, 03 May 2000 14:41:15 -0700
To: [email-masked]
From: Bruce Greenblatt <[email-masked]>
Subject: Re: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Cc: [email-masked], [email-masked]

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

Date: Wed, 3 May 2000 05:38:21 -0700 (PDT)
To: [email-masked]
From: "DJS" <[email-masked]>
Subject: Guilty
Reply-To: 

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

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

To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-salzr-ldap-repsig-00.txt
Date: Tue, 02 May 2000 06:43:06 -0400
Sender: [email-masked]

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

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

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

--OtherAccess--

--NextPart--

From: Ruheena Rashid <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Query : CA related
Date: Tue, 2 May 2000 12:15:24 +0530
Organization: future software

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

From: Michael Zolotarev <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Tue, 2 May 2000 10:33:11 +1000 

> 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Mon, 1 May 2000 16:32:34 -0400 

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
[email-masked]      Tel. (613) 723-5077 Ext. 419
http://www.chrysalis-its.com       Fax. (613) 723-5078