Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

From: "Manger, James H" <[email-masked]>
Date: Fri, 30 Jun 2000 16:40:55 +1000

Denis

Paul Koning provided sensible arguments for removing the unnecessary checks
by the TSA on the messageImprint field.  Michael Zolotarev agreed, as did
Terry Hayes.  No one disagreed.  However, the latest timestamp draft does
not reflect this agreement.  Why not?

If more voices are needed I add my agreement.

If details of specific text changes are required here goes (apply to draft
09):

1. In section 2.1. "Requirements of the TSA", delete item 7 ("to examine the
OID of the one-way..") and renumber the subsequent items.

2. In section 2.1. "Requirements of the TSA", delete the bracketed text in
item 8, i.e. the text that refers to item 7.

3. In section 2.4.1 "Request Format", page 4, delete the following sentence:
	"Its length MUST match the length of the hash value for that
algorithm (e.g. 20 bytes for SHA-1 or 16 bytes for MD5)"

4. In section 2.4.1 "Request Format", page 5, delete the following
paragraph:
	"The hash algorithm indicated in the hashAlgorithm field MUST be a
known hash algorithm (one-way and collision resistant)."

5. In section 2.4.2 "Response Format", page 8, delete the following text:
	", provided that the size of the hash value matches the expected
size of the hash algorithm identified in hashAlgorithm"

P.S. The changes do not prevent a TSA rejecting a timestamp request if it
knows the hash algorithm is bad.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Jun 2000 14:50:09 -0400

Jim,

I support Denis in his desire to have the TSA check everything it can 
(syntactically) in a request.  Not checking allows the TSA to sign 
tokens that are just broken.  We have seen many examples of broken 
certs signed by CAs, so I think it worthwhile that we put language in 
RFCs to require, where possible, that appropriate consistency checks 
be performed.  RFC 2459 has a few statement about relationships among 
extensions, which gets to the same concerns.  We could put in more, 
or collect them in one place, and make for a better document.

I may have lost track of the counter argument here.  Why would one 
not want to have a TSA do the best possible job when it comes to 
ensuring syntactic consistency re its inputs?

Steve

Date: Fri, 30 Jun 2000 14:50:09 -0400
To: "Manger, James H" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Cc: "'PKIX'" <[email-masked]>

Jim,

I support Denis in his desire to have the TSA check everything it can 
(syntactically) in a request.  Not checking allows the TSA to sign 
tokens that are just broken.  We have seen many examples of broken 
certs signed by CAs, so I think it worthwhile that we put language in 
RFCs to require, where possible, that appropriate consistency checks 
be performed.  RFC 2459 has a few statement about relationships among 
extensions, which gets to the same concerns.  We could put in more, 
or collect them in one place, and make for a better document.

I may have lost track of the counter argument here.  Why would one 
not want to have a TSA do the best possible job when it comes to 
ensuring syntactic consistency re its inputs?

Steve

Date: Fri, 30 Jun 2000 11:26:08 -0700
To: PKIX <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

At 08:34 AM 6/30/00 -0700, Aram Perez wrote:
>Hi Michael,
> >
> > I envisage you saying that an average client is a no-brain moron (NBM) with
> > a tendency to trust anybody, and it is our sacred mission to protect them.
>
>Yes, I do believe that we, as non-NBM and security experts, do have some
>moral responsibility to the NBM to make their use of our systems as easy and
>safe as possible.

>I am trying to be consistent with respect to PKIX. In PKIX, by definition
>and whether we like it or not, only CAs issue certificates, not any new
>service that comes along and wants to issue a self-signed cert for itself.
>
>The OOB validation issue applies to any PKI, whether it is PKIX, SPKI, PGP
>or whatever.

Aram,

I do appreciate the sentiment that standards should avoid making it
default for people to ignore safety (though there may be a limiting
tradeoff between "easy" and "safe".)

At the very real risk of appearing ignorant, I must ask "What does it
take to be a PKIX CA?"  Not a big CA, or for-profit CA, or even a
trusted CA, but simply a (minimally) PKIX-compliant CA.  Does the
PKIX standard mandate social compliance in addition to protocol?

If, as you describe, the current tack taken by most folks regarding
the validation of root-certs is the "Null Option", then it cannot be
worse to allow individuals to create their own self-signed anchor,
and "certify" these foreign root-certs as they please.  The software
should comply (that "easy" goal) and I cannot see where safety is
reduced in the process.  Functionally, it is not far from simply
encrypting your browser's root-certs, and having it prompt you for
a pass-key at each root-cert usage.  It provides both tamper-detection
AND control over the otherwise "automatic" trust assumption.  The
self-signed anchor approach has the advantage of not bothering you
when you choose not to be bothered.

I recognize that by allowing individuals to create self-certs, and
then to "personally certify" (say) Verisign's public key, there is
nothing to stop them from performing other mechanical CA functions.

They can certify other keys.  And other parties can rely upon that
certification at their benefit or at their peril.

The alternative is to make the very "existence" of a root-cert
become the evidence of its trustworthiness.  That is, "Only Real
CAs can issue certs, and this is a cert, thus it is trustworthy."
Building such associations into the (expected) protocol mechanics
of PKIX compliance does not serve the cause of safety.

IMNSHO, ALL trust calculation should occur over the *nature*
of the content, none over the mere existence of the content.

Only CAs can issue certificates? Fine. Let there be a billion CAs.

Let "trust imply useful-CA", not "CA imply useful-trust".

( shades of Ed Gerck there :)

Bitwise, OOB appears hopelessly problematic.  It demands prerequisite
trust in a channel that cannot be secured computationally.  (Even the
promise of an inviolably tamperproof quantum cryptographic channel
will not serve to establish the identity of the party at the far-end
without a previous agreement on a uniquely produceable signature.)

Perhaps OOB security can be approached only "statistically", akin to
those web sites where each visitor "ranks" the postings they read,
and the most popular posts rise to the top.  (In retrospect, we have
something "like" that already.  The "popularity" of IE and Netscape
largely dictate the population of extant root-certs.  Unfortunately,
it is a peculiar sort of trust association, subject to "revocation"
at the next software release, and not reflective of daily utility.)

___tony___

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

Date: Fri, 30 Jun 2000 08:34:55 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Hi Michael,

> God knows I was trying hard to stay away from it :)

You can't keep a good man away for long ;-)

>>> 
>>> Inescapably, there must be a good OOB procedure somewhere, but
>>> each customer would need only the one of their choosing, and it
>>> must be of their own choosing, of course, unless someone else
>>> is willing to accept the liability of making that decision for
>>> them (show of hands?)
>> 
>> If you find that one OOB procedure, let me know. I far as I
>> can tell, you
>> need a separate OOB procedure for every self-signed
>> certificate. I raised
>> this issue quite a while back: try to find out the root certificate
>> fingerprints for Verisign, Thawte or any public CA and try to
>> validate your
>> browser root certificates.
> 
> So you are saying that we must prohibit self-signed TSA certs for the lack
> of practical and reliable OOB mechanism? That seems to be the root of the
> problem to me.

That's partially true, but more to the point, this is PKIX, where, by
definition (whether we like it or not), CA issue certificates.

> 
> Well, the same argument would have to apply to the most of self-signed PKI
> then, as your experience with Verisign and Co rightly shows.
> Following the same logic - should we temporary freeze everything, 'till
> there is an OOB that we all agree to trust?
> And consequently shut those authorities that do not seem to provide adequate
> OOB (or so we reckon)? Who should we start with? any suggestions?

As I stated to Tony B., the issue of trusting anchor certificates is largely
being ignored, by choice or ignorance. That does not mean that you must
freeze everything. Right now the obvious OOB mechanism seems to be the NULL
one: don't do an OOB validation. Most folks obviously trust Microsoft and
Netscape. If you are satisfied with not doing an OOB validation or trusting
in Microsoft and Netscape, then continue with the status quo.

> 
> Out of the bitchy mood now.
> 
> If my clients community decides that my OOB is adequate - why should you
> stop my clients from exercising their trust? On the other hand, if a client
> decides that my OOB is NOT adequate - it is his/her right not to use my
> services.

You are right that the clients (and/or relying parties) have the right to
trust or not to trust any particular service. But should be make it harder
for them to make that decision?

> 
> I just don't see why is it of any concern for us.

I would hope that one of the purposes of defining standards is to make it
easier and safer to implement and use, and hence our concern.

> 
> I envisage you saying that an average client is a no-brain moron (NBM) with
> a tendency to trust anybody, and it is our sacred mission to protect them.

Yes, I do believe that we, as non-NBM and security experts, do have some
moral responsibility to the NBM to make their use of our systems as easy and
safe as possible.

> Well - doesn't the same argument apply to a NBM using "any public CA", which
> did not happen to be pre-loaded into IE5?

Yes it does, and look at the problems that were caused when all those
pre-loaded certs expired on December 31, 1999.

> Please, be consistent - once you
> start talking about NBMs, there is no difference between self-signed CA cert
> and self-signed TSA cert. As for non-NBM, we should have some kind of
> reliance into OOB and general intellegence of the clients (not a very
> technical argument though, I admit :)

I am trying to be consistent with respect to PKIX. In PKIX, by definition
and whether we like it or not, only CAs issue certificates, not any new
service that comes along and wants to issue a self-signed cert for itself.

The OOB validation issue applies to any PKI, whether it is PKIX, SPKI, PGP
or whatever.

Regards,
Aram Perez

Date: Fri, 30 Jun 2000 07:59:09 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Hi Tony,

> At 03:03 PM 6/29/00 -0700, Aram Perez wrote:
>> Hi Tony,
>>> Inescapably, there must be a good OOB procedure somewhere, but
>>> each customer would need only the one of their choosing, and it
>>> must be of their own choosing, of course, unless someone else
>>> is willing to accept the liability of making that decision for
>>> them (show of hands?)
>> 
>> If you find that one OOB procedure, let me know. I far as I can tell, you
>> need a separate OOB procedure for every self-signed certificate. I raised
>> this issue quite a while back: try to find out the root certificate
>> fingerprints for Verisign, Thawte or any public CA and try to validate your
>> browser root certificates.
> 
> You are right there.  In general, our browser (or its distributor)
> is the effective root of our trust.  What a thought.
> 
> Classic regress problem.  You want a secure channel in order to convey
> the items that establish the security of another channel.  The only
> channel that you can trust a priori is the channel that you have with
> yourself, (hence the SPKI approach.)
> 
> Hypothetically, (assuming I just give up and assume that my browser's
> root certs are "currently" valid,) I could create a self-signed root
> cert, use it to certify all of the root-keys in the browser, and thus
> establish myself as my (personal) root-over-them-all (solely to prevent
> their tampering or replacement).  Beyond this, when I felt (for whatever
> reason) that CA XYZ was no longer to be trusted, I would simply revoke
> MY certification of their public key.  But what would be required to
> make such processing occur (for what little comfort it might bring?)
> 
> How might I force all chains to reach for my root-cert as endpoint?

The issue of how to trust anchor certificates (using my previously stated
definition of anchor certificates) is largely being ignored, either by
choice or by ignorance. There is no one OOB mechanism to solve this issue,
whether you are using PKIX, SPKI, PGP or any other PKI.

Regards,
Aram Perez

Date: Fri, 30 Jun 2000 12:33:47 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: [email-masked]
Subject: Re: CRMF encValue Field

Hi Francois,

As I said yesterday, I'll check what the folks on Bob's ca-talk list
have implemented. I do agree that handling pkcs#11 tokens is desirable,
but I would guess is lower priority than not breaking current
implementations. So pkcs#11 support (if different from what's 
implemented already), could either be added to 2510bis as an
implenmentation note, or, if it gets complicated, in a separate 
"pkcs#11 key wrapping in CMP" draft.

Let's wait & see what the developers have done.

Regards,
Stephen.

> [email-masked] wrote:
> 
> Steve,
> 
> As agreed yesterday at the PKI Forum meeting in Dublin, could you please check and add some
> clarification in the next version of RFC2510bis about what exactly must be encoded in the
> "encValue" field of the EncryptedValue structure, which is described in Section 6.4 of CRMF
> [RFC2511]. This clarification will become necessary in order to ensure interoperability between
> components using hardware or software from different vendors (i.e. clients, RAs and CAs) that
> might use this CRMF "encValue" field.
> 
> As discussed, please note that hardware cryptographic module vendors that implement PKCS#11 would
> normally use the Cryptoki wrapping mechanism to encrypt any private key that has to be extracted
> from their module to go in this "encValue" field. Since Section 11.9 of PKCS#11 v2.01 mandates for
> wrapping a private key that:
> 
> "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."
> 
> I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is currently being
> encrypted within this CRMF "encValue" field of the EncryptedValue structure for today CMP
> implementations.
> 
> 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: Francois Rousseau
> Sent: Thursday, May 25, 2000 3:42 PM
> To: 'Carlisle Adams'
> Cc: [email-masked]
> Subject: Encryption of Private Keys in CRMF and CMP
> 
> 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

-- 
____________________________________________________________
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: Fri, 30 Jun 2000 17:06:30 +0900
From: Kong QiuYan <[email-masked]>
To: [email-masked]
Subject: certificate chain validation(policy extension)

Suppose I have a certificate chain consisting of a Root, a CA and a User
certificate.

The policy extension in the Root certificate contains one oid of 1.1.1(critical)
The policy extension in the CA certificate does not exist.
The policy extension in the User certificate contains one oid of 1.1.1(critical)

Assuming all other data is valid, is this a valid certificate chain?

It appears to me that the algorithm defined in RFC2459 would determine that
this certificate path is valid.  

-----------
RFC2459 6.1 says:
 
      (e)  Verify that policy information is consistent with the
      acceptable policy set:

         (1) if the certificate policies extension is marked critical,
         the intersection of the policies extension and the acceptable
         policy set shall be non-null;

         (2) the acceptable policy set is assigned the resulting
         intersection as its new value.

      (g) Verify that the intersection of the acceptable policy set and
      the initial policy set is non-null.
---------

Personally, I think that all of the certificates in a valid path must have
policy extension(critical or non-critical). Am I wrong? 

QiuYan Kong,
Fujitsu Ltd

From: Peter Sylvester <[email-masked]>
Date: Fri, 30 Jun 2000 09:51:15 +0200 (MET DST)
To: [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]

Currently a CA can have several key usages indicated in its
cert (or in some cert given to it) EXCEPT you can newer use
a CA key for time stamping. 
 
Why is it that a TSA needs a more restrictive handling than a CA?

> 
> I envisage you saying that an average client is a no-brain moron (NBM) with
> a tendency to trust anybody, and it is our sacred mission to protect them.
> Well - doesn't the same argument apply to a NBM using "any public CA", which
> did not happen to be pre-loaded into IE5? Please, be consistent - once you
> start talking about NBMs, there is no difference between self-signed CA cert
> and self-signed TSA cert. As for non-NBM, we should have some kind of
> reliance into OOB and general intellegence of the clients (not a very
> technical argument though, I admit :)
> 
> Michael

From: Michael Zolotarev <[email-masked]>
To: Aram Perez <[email-masked]>, PKIX <[email-masked]>
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Fri, 30 Jun 2000 16:57:31 +1000

God knows I was trying hard to stay away from it :)
> > 
> > Inescapably, there must be a good OOB procedure somewhere, but
> > each customer would need only the one of their choosing, and it
> > must be of their own choosing, of course, unless someone else
> > is willing to accept the liability of making that decision for
> > them (show of hands?)
> 
> If you find that one OOB procedure, let me know. I far as I 
> can tell, you
> need a separate OOB procedure for every self-signed 
> certificate. I raised
> this issue quite a while back: try to find out the root certificate
> fingerprints for Verisign, Thawte or any public CA and try to 
> validate your
> browser root certificates.

So you are saying that we must prohibit self-signed TSA certs for the lack
of practical and reliable OOB mechanism? That seems to be the root of the
problem to me.

Well, the same argument would have to apply to the most of self-signed PKI
then, as your experience with Verisign and Co rightly shows.
Following the same logic - should we temporary freeze everything, 'till
there is an OOB that we all agree to trust?
And consequently shut those authorities that do not seem to provide adequate
OOB (or so we reckon)? Who should we start with? any suggestions?

Out of the bitchy mood now.

If my clients community decides that my OOB is adequate - why should you
stop my clients from exercising their trust? On the other hand, if a client
decides that my OOB is NOT adequate - it is his/her right not to use my
services.

I just don't see why is it of any concern for us.

I envisage you saying that an average client is a no-brain moron (NBM) with
a tendency to trust anybody, and it is our sacred mission to protect them.
Well - doesn't the same argument apply to a NBM using "any public CA", which
did not happen to be pre-loaded into IE5? Please, be consistent - once you
start talking about NBMs, there is no difference between self-signed CA cert
and self-signed TSA cert. As for non-NBM, we should have some kind of
reliance into OOB and general intellegence of the clients (not a very
technical argument though, I admit :)

Michael

From: "Manger, James H" <[email-masked]>
To: "'PKIX'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Date: Fri, 30 Jun 2000 16:40:55 +1000

Denis

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: algorithm OID esoterica
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 30 Jun 2000 14:27:47 (NZST)

Ari Kermaier <[email-masked]> writes:

>This may not be of interest to many people, but are there any
>legitimate/official/semi-real OIDs defined for the Blowfish symmetric
>cipher algorithm and the Null cipher (for completeness' sake)?

draft-schneier-blowfish-00.txt has:

5. ASN.1 structures and Object Identifiers

Blowfish has the following ASN.1 definitions:

  blowfishECB ALGORITHM PARAMETER NULL ::=
    {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1)
     dds(3029) algorithm(1) symmetric-encryption(1) 1}
  blowfishCBC ALGORITHM PARAMETER CBCParameter ::=
    {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1)
     dds(3029) algorithm(1) symmetric-encryption(1) 2}
  blowfishCFB ALGORITHM PARAMETER FBParameter ::=
    {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1)
     dds(3029) algorithm(1) symmetric-encryption(1) 3}
  blowfishOFB ALGORITHM PARAMETER FBParameter ::=
    {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1)
     dds(3029) algorithm(1) symmetric-encryption(1) 4}

The parameters are the standard OIW parameters for block cipher
chaining modes [OIW] and are reproduced below:

    CBCParameter ::= IV

    FBParameter ::= SEQUENCE {
        iv IV,
        numberOfBits NumberOfBits
        }

    IV ::= OCTET STRING  -- 8 octets

    NumberOfBits ::= INTEGER

When used with Blowfish, NumberOfBits should always be 64.

Peter.

Date: Thu, 29 Jun 2000 22:21:53 -0400
To: [email-masked]
From: Ari Kermaier <[email-masked]>
Subject: algorithm OID esoterica

This may not be of interest to many people, but are there any 
legitimate/official/semi-real OIDs defined for the Blowfish symmetric 
cipher algorithm and the Null cipher (for completeness' sake)?

Ari Kermaier

Date: Thu, 29 Jun 2000 17:32:53 -0700
To: Aram Perez <[email-masked]>, PKIX <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

At 03:03 PM 6/29/00 -0700, Aram Perez wrote:
>Hi Tony,
> > Inescapably, there must be a good OOB procedure somewhere, but
> > each customer would need only the one of their choosing, and it
> > must be of their own choosing, of course, unless someone else
> > is willing to accept the liability of making that decision for
> > them (show of hands?)
>
>If you find that one OOB procedure, let me know. I far as I can tell, you
>need a separate OOB procedure for every self-signed certificate. I raised
>this issue quite a while back: try to find out the root certificate
>fingerprints for Verisign, Thawte or any public CA and try to validate your
>browser root certificates.

You are right there.  In general, our browser (or its distributor)
is the effective root of our trust.  What a thought.

Classic regress problem.  You want a secure channel in order to convey
the items that establish the security of another channel.  The only
channel that you can trust a priori is the channel that you have with
yourself, (hence the SPKI approach.)

Hypothetically, (assuming I just give up and assume that my browser's
root certs are "currently" valid,) I could create a self-signed root
cert, use it to certify all of the root-keys in the browser, and thus
establish myself as my (personal) root-over-them-all (solely to prevent
their tampering or replacement).  Beyond this, when I felt (for whatever
reason) that CA XYZ was no longer to be trusted, I would simply revoke
MY certification of their public key.  But what would be required to
make such processing occur (for what little comfort it might bring?)

How might I force all chains to reach for my root-cert as endpoint?

___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: CRMF encValue Field
Date: Thu, 29 Jun 2000 19:27:41 -0400

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

------_=_NextPart_001_01BFE221.AB1BCDEC
Content-Type: text/plain;
	charset="iso-8859-1"

Steve,

As agreed yesterday at the PKI Forum meeting in Dublin, could you please
check and add some clarification in the next version of RFC2510bis about
what exactly must be encoded in the "encValue" field of the EncryptedValue
structure, which is described in Section 6.4 of CRMF [RFC2511]. This
clarification will become necessary in order to ensure interoperability
between components using hardware or software from different vendors (i.e.
clients, RAs and CAs) that might use this CRMF "encValue" field.

As discussed, please note that hardware cryptographic module vendors that
implement PKCS#11 would normally use the Cryptoki wrapping mechanism to
encrypt any private key that has to be extracted from their module to go in
this "encValue" field. Since Section 11.9 of PKCS#11 v2.01 mandates for
wrapping a private key that:

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

I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is
currently being encrypted within this CRMF "encValue" field of the
EncryptedValue structure for today CMP implementations.

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: Francois Rousseau 
Sent: Thursday, May 25, 2000 3:42 PM
To: 'Carlisle Adams'
Cc: [email-masked]
Subject: Encryption of Private Keys in CRMF and CMP

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

------_=_NextPart_001_01BFE221.AB1BCDEC
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.2650.12">
<TITLE>CRMF encValue Field</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Steve,</FONT>
</P>

<P><FONT SIZE=3D2>As agreed yesterday at the PKI Forum meeting in =
Dublin, could you please check and add some clarification in the next =
version of RFC2510bis about what exactly must be encoded in the =
&quot;encValue&quot; field of the EncryptedValue structure, which is =
described in Section 6.4 of CRMF [RFC2511]. This clarification will =
become necessary in order to ensure interoperability between components =
using hardware or software from different vendors (i.e. clients, RAs =
and CAs) that might use this CRMF &quot;encValue&quot; =
field.</FONT></P>

<P><FONT SIZE=3D2>As discussed, please note that hardware cryptographic =
module vendors that implement PKCS#11 would normally use the Cryptoki =
wrapping mechanism to encrypt any private key that has to be extracted =
from their module to go in this &quot;encValue&quot; field. Since =
Section 11.9 of PKCS#11 v2.01 mandates for wrapping a private key =
that:</FONT></P>

<P><FONT SIZE=3D2>&quot;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.&quot;</FONT></P>

<P><FONT SIZE=3D2>I hope that the type &quot;PrivateKeyInfo&quot; from =
Section 6 of PKCS#8 is what is currently being encrypted within this =
CRMF &quot;encValue&quot; field of the EncryptedValue structure for =
today CMP implementations.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Francois Rousseau </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 25, 2000 3:42 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Carlisle Adams'</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Encryption of Private Keys in CRMF and =
CMP</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2>In Section 6.4 of RFC 2511 on CRMF, it is indicated =
that the EncryptedValue field &quot;encValue&quot; 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).</FONT></P>

<P><FONT SIZE=3D2>Am I missing something?</FONT>
</P>

<P><FONT SIZE=3D2>I understand that RFC 2511 EncryptedValue field =
&quot;symmAlg&quot; 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.</FONT></P>

<P><FONT SIZE=3D2>Is it a type &quot;PrivateKeyInfo&quot; from Section =
6 of PKCS#8 or a type &quot;RSAPrivateKey&quot; from Section 11.1.2 of =
PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field =
&quot;intendedAlg&quot; already tell me the intended algorithm for =
which the private key will be used for? </FONT></P>

<P><FONT SIZE=3D2>Thanks in advance for any help.</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFE221.AB1BCDEC--

Date: Thu, 29 Jun 2000 15:03:36 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Hi Tony,

> At 12:40 PM 6/29/00 -0700, Aram Perez wrote:
>> Hi Rich,
>>> 3    Repeat step 2 with "every" CA a potential customer might know.
>> 
>> I doubt your potential customers will want many CAs. Again, for every CA
>> they want, they have to have an OOB mechanism to validate the root
>> certificate.
> 
> I don't think Rich meant that "a" potential customer may want to
> employ many different CAs, but rather that he must deal with the
> union of the set of CAs trusted by his set of customers, right?

Yes that is correct. But that is the PKIX model.

> 
> Inescapably, there must be a good OOB procedure somewhere, but
> each customer would need only the one of their choosing, and it
> must be of their own choosing, of course, unless someone else
> is willing to accept the liability of making that decision for
> them (show of hands?)

If you find that one OOB procedure, let me know. I far as I can tell, you
need a separate OOB procedure for every self-signed certificate. I raised
this issue quite a while back: try to find out the root certificate
fingerprints for Verisign, Thawte or any public CA and try to validate your
browser root certificates.

Regards,
Aram Perez

Date: Thu, 29 Jun 2000 15:31:06 -0700
To: Aram Perez <[email-masked]>, PKIX <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

At 12:40 PM 6/29/00 -0700, Aram Perez wrote:
>Hi Rich,
>
> >> Why do you want to force me to figure out the OOB mechanism for every new
> >> PKIX service?
> >
> > I don't.  I want it to be possible.  Surely you see the difference.
>
>Yes I see the difference. But the more possibilities you have, the more
>potential for security breakdown there is, i.e. someone doesn't do their due
>diligence with the OOB mechanism.

On Aram's side, I envision a large enterprise dealing routinely
with signature verifications of all manner.  In such a case, it
would certainly make sense to have the TSA key be similarly
certified, rather than invoking an additional OOB mechanism.

On Rich's side, I envision a dedicated operation that had purely
a need for a secured timestamp.  In any case, some TSA must be
independently trusted for this operation.  If the TS-client has
to form a secure OOB conveyance, and could do so directly with
the TSA, it does seem "unnatural" to require that they instead
seek a CA to trust, and require this TSA to have their key
certified by this particular choice of CA.

(Otherwise, their choice of TSA becomes restricted to those
whose keys have been certified by the "trusted" CAs, if any.)

Granted, for future RPs who need to make verifications, it is
a question of whether the TSA went out of business first, and
the CA second, or the TSA outlived the CA.  Are we betting on
relative longevity here?

___tony___

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

Date: Thu, 29 Jun 2000 15:07:36 -0700
To: Aram Perez <[email-masked]>, PKIX <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

At 12:40 PM 6/29/00 -0700, Aram Perez wrote:
>Hi Rich,
> > 3    Repeat step 2 with "every" CA a potential customer might know.
>
>I doubt your potential customers will want many CAs. Again, for every CA
>they want, they have to have an OOB mechanism to validate the root
>certificate.

I don't think Rich meant that "a" potential customer may want to
employ many different CAs, but rather that he must deal with the
union of the set of CAs trusted by his set of customers, right?

Inescapably, there must be a good OOB procedure somewhere, but
each customer would need only the one of their choosing, and it
must be of their own choosing, of course, unless someone else
is willing to accept the liability of making that decision for
them (show of hands?)

___tony___

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

Date: Thu, 29 Jun 2000 14:44:03 -0700
To: Rich Salz <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
Cc: [email-masked]

At 02:37 PM 6/29/00 -0400, Rich Salz wrote:
> > If the CP under which the CA operates says that it certifies identity and
> > binding of that to a public key, then that is all it does.
>
>And that's pretty much indistinguishable from self-signed, no?
>Actually, it's "less secure."  Self-signed is proof-of-possesion,
>while the CA you describe means "I trust that you saw
>proof-of-possesion."
>         /r$

Even a (supposed) CA that attests to POP is of no value if you
do not first (1) trust that CA, and (2) trust that you actually
have a certificate issued by that CA.

Both sides of this argument make good points in their isolation.
I must apply a (naive, dumb) usage example to clarify the issues
in my own mind.

I imagine some poor soul who discovers they must rely critically
upon a particular timestamped piece of data, the timestamp itself
a critical value.  While simultaneously demonstrating my ignorance
of the protocols and procedures that might be in place, I think I
am not too far off in recognizing that the following "logical"
operations must occur, in one or another order:

1.  Obtain a public key value for which the TS signature verifies.
     (Call this key the TS-Public).

     (This establishes that the signer, whoever in the world they
     might be), possessed the corresponding private key, and (we
     must assume) effected the TS signature.

2.  Obtain a certificate (self-signed or otherwise) that hopes
     to represent a binding of the TS-Public with a set of name-
     like attributes.  In our case, the name is "TS-R-US".

     (My boss TOLD me that TS-R-US is the TSA to trust.)
     So far, so good...

Now, what are the possible avenues of attack, for which either
"self-signed" or "CA-signed" is intended to be a better remedy?

In order for a fraud to be perpetrated, we assume it is the
fraudster who must have possessed and signed the timestamp.

An attacker, knowing our penchant to trust "TS-R-US", would
need to

a.  Create a TS-signing key pair (easy)

b.  Formulate a certificate attesting to the binding of this
     keypair with the name "TS-R-US", EITHER in self-signed
     fashion, or else by another ersatz key-pair/cert appearing
     as the (well-known;) CA "AnyCerts.com".

     (Yes, my boss SAID to trust "AnyCerts.com")

c.  Then (How?) circulate/distribute this/these certificates in
     such a fashion that the poor soul verifying the timestamp
     in question is sure to run across them first.

Of course, in the case of "AnyCerts.com", that certificate
is itself either self-signed, or invokes a further chain of
verification.  But eventually the buck stops.

Beyond the mere mechanics of verification, there must be an
established place where the buck is to stop.  That place
SHOULD be anywhere the RP chooses it to be, I would think.
After all, they are the Relying Party.  Similarly, each RP
will need to apply the "discovery procedures" that they feel
serve to satisfy their own operational and security needs.

In light of this, I am not convinced that any one "solution"
has a hands-down advantage for all reasonable use-cases.

Comments?

___tony___

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

Date: Thu, 29 Jun 2000 12:58:11 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Hi Peter,

While I mostly agree with you, this is the PKIX (where the X is for X.509)
with is by definition hierarchical (or "parochial" as you put it). I'm not
sure where this notion of "delegation of authority via certificates" comes
from or the concept of "trust me, I have a certificate from XYZ (a CA)", but
I certain am not a believer or practitioner of it. In a PKIX world, I only
want a CA to bind some identity and a public key. I will establish authority
and trust via other mechanisms that are not necessarily tied to a CA and/or
certificates.

Regards,
Aram Perez

> Rich/Aram,
> 
> The OCSP model got it - the control constructs - about right, I
> suggest. There, a key management model was embedded in the RFC that
> leveraged both hierarchical control systems theory (2459) and
> non-control-oriented constructs for authenticating the public
> keys of the responder to the service user.
> 
> OCSP used a specific set of concepts for orchestrating
> the control relationships between the parties. These went
> beyond the notion of "delegation of authority via
> certificates" - a parochial construct from the proprietary system
> security designs of the late 70s and 80s - a reflection of a certain
> era of designed-in integrity for distributed systems.
> 
> TSA should do the same as OCSP, I suggest.  The simplistic military
> security model in which TSAs are "granted authority to act" by
> a CA is doubtfully sufficient for the Internet environment
> that we profile here. The commercial, political and
> practical realities make such a simple model as impractical
> as the same model was for OCSP.
> 
> I doubt we would now have the various validation networks that
> we see popping up if the OCSP standard had not had
> the flexibility to adapt to various ideas of control, as
> decided by the deployment community. OCSP
> enabled us (a significant OCSP vendor/user community now) to
> deploy switched, proxied, cached, pushed, pulled and delegated
> forms of validation  authorities (OCSP responders) as the
> risk management culture demanded.
> 
> To engender a successful, commercially-driven, multi-vendor,
> value-adding, open TSA industry, we  should perhaps follow the
> OCSP lead. We should again use interworking-standards consensus to
> help form another round  of open, Internet infrastructure. Ensuring
> that there are various models of control - that relying parties apply
> under their own models of risk management - seems vital: only
> those Internet security standards with the required degree of openness
> in the control area seem to get adopted in practice.
> 
> Peter.
> 
> -----Original Message-----
> From: Rich Salz [mailto:[email-masked]]
> Sent: Thursday, June 29, 2000 8:41 AM
> To: Aram Perez
> Cc: PKIX
> Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
>> Why do you want to force me to figure out the OOB mechanism for every new
>> PKIX service?
> 
> I don't.  I want it to be possible.  Surely you see the difference.
> 
> Without a self-signed cert, my service has to either
> 1    Run a CA, doubling the amount of private key material I maintain; or
> 2    Go to someone else's CA, who might be a competitor, and convince
> them to perform the due diligence necessary to certify me as a TSA;
> or
> 3    Repeat step 2 with "every" CA a potential customer might know.
> 
> I don't believe it's reasonable claim that just because it's a CA, it is
> qualified to certify TSA usage.  "Trusted to sign end-entitities without
> these eKU values" is not a feasible trust model.
> /r$

Date: Thu, 29 Jun 2000 12:49:50 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: [email-masked], [email-masked]
Cc: [email-masked]

GHilborn wrote:

> If the CP under which the CA operates says that it certifies identity and
> binding of that to a public key, then that is all it does.   The validity or
> security or accuracy, etc. of whatever service a business operates under that
> identity (e.g., time sever, ocsp responder, web information server, etc.)  is
> NOT what a CA "certifies."  So isn't the only "due-diligence" required of the
> CA
> that of certifing the valid business identity and private key possession of
> the
> public key bound into the certificate of the TSA?  The accuracy, availability,
> etc. of TSA service is expressed in their own policy/contract with their
> customers, just as is the privacy policy for a web server to which a CA issues
> a certificate.

Well stated! I'm sure there are a number of web-based stores that Verisign
issued certificates to that are no longer in business. The same will happen
with TSAs, not all of them will exist after a few years (whether or not they
issued self-signed certificates).

Aram Perez

> -GH
> 
> 
> 
> 
> [email-masked] on 06/29/2000 11:40:43 AM
> 
> To:   [email-masked]
> cc:   [email-masked] (bcc: Gene Hilborn/DEF/CSC)
> Subject:  Re: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> 
>> Why do you want to force me to figure out the OOB mechanism for every new
>> PKIX service?
> 
> I don't.  I want it to be possible.  Surely you see the difference.
> 
> Without a self-signed cert, my service has to either
> 1   Run a CA, doubling the amount of private key material I maintain; or
> 2   Go to someone else's CA, who might be a competitor, and convince
> them to perform the due diligence necessary to certify me as a TSA; or
> 3   Repeat step 2 with "every" CA a potential customer might know.
> 
> I don't believe it's reasonable claim that just because it's a CA, it is
> qualified to certify TSA usage.  "Trusted to sign end-entitities without
> these eKU values" is not a feasible trust model.
> /r$
> 
> 
> 
> 

Date: Thu, 29 Jun 2000 12:40:31 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Hi Rich,

>> Why do you want to force me to figure out the OOB mechanism for every new
>> PKIX service?
> 
> I don't.  I want it to be possible.  Surely you see the difference.

Yes I see the difference. But the more possibilities you have, the more
potential for security breakdown there is, i.e. someone doesn't do their due
diligence with the OOB mechanism.

> 
> Without a self-signed cert, my service has to either
> 1    Run a CA, doubling the amount of private key material I maintain; or

In my opinion, this should NOT be an option.

> 2    Go to someone else's CA, who might be a competitor, and convince
> them to perform the due diligence necessary to certify me as a TSA; or

This is the correct option. That is why they are in business: to certify
public keys. And any CA, whether or not it signs your TSA key and whether or
not a TSA can issue self-signed roots, is a potential competitor. Look at
all the non-CA things Verisign is doing now days. Besides, a CA should not
certify you as a TSA, it should certify your TSA public key. If I want to
use your service, I will not go to the CA that signed your key to determine
whether or not your TSA service is valid.

> 3    Repeat step 2 with "every" CA a potential customer might know.

I doubt your potential customers will want many CAs. Again, for every CA
they want, they have to have an OOB mechanism to validate the root
certificate.

> 
> I don't believe it's reasonable claim that just because it's a CA, it is
> qualified to certify TSA usage.  "Trusted to sign end-entitities without
> these eKU values" is not a feasible trust model.

See my comment under option 2.

Regards,
Aram Perez

Sender: rsalz
Date: Thu, 29 Jun 2000 14:37:34 -0400
From: Rich Salz <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> If the CP under which the CA operates says that it certifies identity and
> binding of that to a public key, then that is all it does.

And that's pretty much indistinguishable from self-signed, no?
Actually, it's "less secure."  Self-signed is proof-of-possesion,
while the CA you describe means "I trust that you saw
proof-of-possesion."
	/r$

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Thu, 29 Jun 2000 13:11:27 -0400
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

If the CP under which the CA operates says that it certifies identity and
binding of that to a public key, then that is all it does.   The validity or
security or accuracy, etc. of whatever service a business operates under that
identity (e.g., time sever, ocsp responder, web information server, etc.)  is
NOT what a CA "certifies."  So isn't the only "due-diligence" required of the CA
that of certifing the valid business identity and private key possession of the
public key bound into the certificate of the TSA?  The accuracy, availability,
etc. of TSA service is expressed in their own policy/contract with their
customers, just as is the privacy policy for a web server to which a CA issues a
certificate.
-GH

[email-masked] on 06/29/2000 11:40:43 AM

To:   [email-masked]
cc:   [email-masked] (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> Why do you want to force me to figure out the OOB mechanism for every new
> PKIX service?

I don't.  I want it to be possible.  Surely you see the difference.

Without a self-signed cert, my service has to either
 1   Run a CA, doubling the amount of private key material I maintain; or
 2   Go to someone else's CA, who might be a competitor, and convince
     them to perform the due diligence necessary to certify me as a TSA; or
 3   Repeat step 2 with "every" CA a potential customer might know.

I don't believe it's reasonable claim that just because it's a CA, it is
qualified to certify TSA usage.  "Trusted to sign end-entitities without
these eKU values" is not a feasible trust model.
     /r$

Content-return: allowed
Date: Thu, 29 Jun 2000 09:54:54 -0700
From: Peter Williams <[email-masked]>
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
To: "'Rich Salz'" <[email-masked]>, Aram Perez <[email-masked]>
Cc: PKIX <[email-masked]>

Rich/Aram,

The OCSP model got it - the control constructs - about right, I 
suggest. There, a key management model was embedded in the RFC that 
leveraged both hierarchical control systems theory (2459) and 
non-control-oriented constructs for authenticating the public 
keys of the responder to the service user.
 
OCSP used a specific set of concepts for orchestrating
the control relationships between the parties. These went
beyond the notion of "delegation of authority via
certificates" - a parochial construct from the proprietary system 
security designs of the late 70s and 80s - a reflection of a certain 
era of designed-in integrity for distributed systems.

TSA should do the same as OCSP, I suggest.  The simplistic military
security model in which TSAs are "granted authority to act" by
a CA is doubtfully sufficient for the Internet environment
that we profile here. The commercial, political and
practical realities make such a simple model as impractical
as the same model was for OCSP.  

I doubt we would now have the various validation networks that
we see popping up if the OCSP standard had not had
the flexibility to adapt to various ideas of control, as
decided by the deployment community. OCSP
enabled us (a significant OCSP vendor/user community now) to 
deploy switched, proxied, cached, pushed, pulled and delegated 
forms of validation  authorities (OCSP responders) as the 
risk management culture demanded.

To engender a successful, commercially-driven, multi-vendor,
value-adding, open TSA industry, we  should perhaps follow the 
OCSP lead. We should again use interworking-standards consensus to 
help form another round  of open, Internet infrastructure. Ensuring 
that there are various models of control - that relying parties apply
under their own models of risk management - seems vital: only 
those Internet security standards with the required degree of openness
in the control area seem to get adopted in practice.

Peter.
 
-----Original Message-----
From: Rich Salz [mailto:[email-masked]]
Sent: Thursday, June 29, 2000 8:41 AM
To: Aram Perez
Cc: PKIX
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> Why do you want to force me to figure out the OOB mechanism for every new
> PKIX service?

I don't.  I want it to be possible.  Surely you see the difference.

Without a self-signed cert, my service has to either
 1	Run a CA, doubling the amount of private key material I maintain; or
 2	Go to someone else's CA, who might be a competitor, and convince
	them to perform the due diligence necessary to certify me as a TSA;
or
 3	Repeat step 2 with "every" CA a potential customer might know.

I don't believe it's reasonable claim that just because it's a CA, it is
qualified to certify TSA usage.  "Trusted to sign end-entitities without
these eKU values" is not a feasible trust model.
	/r$

Sender: rsalz
Date: Thu, 29 Jun 2000 11:40:43 -0400
From: Rich Salz <[email-masked]>
To: Aram Perez <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> Why do you want to force me to figure out the OOB mechanism for every new
> PKIX service?

I don't.  I want it to be possible.  Surely you see the difference.

Without a self-signed cert, my service has to either
 1	Run a CA, doubling the amount of private key material I maintain; or
 2	Go to someone else's CA, who might be a competitor, and convince
	them to perform the due diligence necessary to certify me as a TSA; or
 3	Repeat step 2 with "every" CA a potential customer might know.

I don't believe it's reasonable claim that just because it's a CA, it is
qualified to certify TSA usage.  "Trusted to sign end-entitities without
these eKU values" is not a feasible trust model.
	/r$

To: [email-masked]
Date: Wed, 28 Jun 2000 21:05:44 -0700
From: "chandrasekaran natarajan" <[email-masked]>
Reply-To: [email-masked]
Subject: hello world !
Organization: MailCity  (http://www.mailcity.lycos.com:80)

Hello all,
These days I am not getting any mails from this forum ..
Is this forum On ?

chandar

Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct

From: Peter Sylvester <[email-masked]>
Date: Wed, 28 Jun 2000 15:07:16 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSP-09

I forgot :

The text says: 

  When the accuracy optional field is not present, then the accuracy 
  may be available through other means, e.g. the PolicyInformation.

The text does not indicate the default value for accuracy.

Appendix C says:

   Security considerations: Carries a request for a timestamp and the 
   response. The response will be cryptographically signed.

Actually only a part of the response is signed.

From: Peter Sylvester <[email-masked]>
Date: Wed, 28 Jun 2000 14:37:27 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSP-09

> 
> Modifications to say that a modified Token may be returned when the
> status is one (grantedWithMods), e.g. when some extensions have been
> incorporated in a way that is slightly different from the request.
Note that the status is not part of the token, and it is not signed.
It should be made clear that grantedWithMods can only be seen as a
hint in order to indicate to the client, that the token may not be what
had been asked for.
Anyway, a client has to verify all the fields in the token,
thus this status doesn't really give additional information.   

It is not specified in what situation a TSA would set

         revocationWarning      (4),
          -- this message contains a warning that a revocation is 
          -- imminent 
         revocationNotification (5),
          -- notification that a revocation has occurred 

and 

         addInfoNotAvailable (17)
         -- the additional information requested could not be understood
         -- or is not available

That latter I imagine to see in case of extensions, for example. 

> It is now time to send this document to the IESG. There are still
> opportunities to make minor changes to the document when it becomes
> a Standard, at least six months after it becomes Proposed Standard.
Hm.

The text references a non existing specification:

  A TSA's certificate MAY contain a Subject Information Access (SIA)
  extension [son of RFC2459] in order to convey the method of contacting 
  the TSA.  The accessMethod field in this extension MUST contain the 
  OID id-ad-timestamping:

At least, I propose the following change:  

  A TSA's certificate MAY contain a Subject Information Access (SIA)
  extension [son of RFC2459].  In order to convey the method of contacting 
  the TSA, the accessMethod field in this extension MUST contain the 
  OID id-ad-timestamping:

The following comment should be changed if one uses a SIA:

-- Authority Information Access for TSA

Besides that, I do not think that a SIA is necessary, it is sufficient
to slightly modify the AIA definition by saying that the exact
meaning is defined by the definition of the access method, i.e.,
whether and how it is related to the subject or the issuer.

/P

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-00.txt
Date: Tue, 27 Jun 2000 06:44:06 -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		: Transport Protocols for CMP
	Author(s)	: A. Kapoor, R. Tschalar
	Filename	: draft-ietf-pkix-cmp-transport-protocols-00.txt
	Pages		: 10
	Date		: 26-Jun-00
	
This document describes how to layer Certificate Management
Protocols [CMP] over various transport protocols.
The key words 'MUST','MUST NOT', 'REQUIRED', 'SHOULD', 'SHOULD
NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document (in
uppercase, as shown) are to be interpreted as described in
[RFC2119].
This document version corresponds to the draft-ietf-pkix-cmp-transports-03.txt
published and discussed in the PKI Forum interoperability mailing list.

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 26 Jun 2000 11:42:07 -0700
To: Philip Hallam-Baker <[email-masked]>, "'Ben Laurie'" <[email-masked]>, Bob Jueneman <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: Do people have something against RSA?
Cc: [email-masked], [email-masked]

I have to agree with Phillip and Ben as well.

The USPTO seems way-behind the times when it comes to "software"
and "web" inventions.  If you were the lucky one to first think of
the idea of coordinating web auctions (eBay) you just about have
the market sewn up.  Just try to start your own such service if
you want to know what an army of lawyers looks like.  They (PTO)
seem to think anything transferred to "the web" = "new invention".

At minimum, I would like to see such "patents" awarded for at most
a one-year period (i.e., adjusted to "cyber-time".)  With an adequate
review, that should give patent-holders time to leverage their IP
into a market advantage.  But if all they can produce with their
one-year head start are lawsuits, "times up".

___tony___

At 10:17 AM 6/26/00 -0700, Philip Hallam-Baker wrote:
>I agree with Ben, burn down the PTO. Patents are in any case a sixteenth
>century method of supporting innovation. To equate them with
>'capitalism' is ridiculous.
>
>Since when was appealing to the government to grant you a twenty year
>monopoly an intrinsic part of free market competition?
>
>
>The problem is that the US PTO is systematically incompetent. The lack
>of prior public review utterly compromises the patents issued. No other
>country has such a ridiculous scheme.
>
>The lack of public review is doubly iniquitous. It should be possible
>for me to determine through due dilligence what IP claims might impinge
>upon a proposed product. The closed review permits the 'submarine
>patent' strategy. Keep the patent in process for ten years and rewrite
>it after the standards have been set.
>
>The poor standard of review at the US PTO hurts genuine applicants too.
>Hold up a US PTO patent and you don't have half the credibility you have
>with a UK, French or German one.
>
>Anyone here believe Unisys deserve a patent royalty on Compuserve's Gif
>format? Compuserve were entirely unaware that their standard might
>infringe. Had they known that Unisys had a patent they could easily have
>avoided the specific inventions claimed.
>
>
>Has anyone considered that a person making a bogus patent application
>might be held liable under a private suit for conversion in fraud?
>
>         Phill

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

From: Philip Hallam-Baker <[email-masked]>
To: "'Ben Laurie'" <[email-masked]>, Bob Jueneman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Do people have something against RSA?
Date: Mon, 26 Jun 2000 10:17:47 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01BFDF71.12D65C80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I agree with Ben, burn down the PTO. Patents are in any case a sixteenth
century method of supporting innovation. To equate them with
'capitalism' is ridiculous.

Since when was appealing to the government to grant you a twenty year
monopoly an intrinsic part of free market competition?

The problem is that the US PTO is systematically incompetent. The lack
of prior public review utterly compromises the patents issued. No other
country has such a ridiculous scheme.

The lack of public review is doubly iniquitous. It should be possible
for me to determine through due dilligence what IP claims might impinge
upon a proposed product. The closed review permits the 'submarine
patent' strategy. Keep the patent in process for ten years and rewrite
it after the standards have been set.

The poor standard of review at the US PTO hurts genuine applicants too.
Hold up a US PTO patent and you don't have half the credibility you have
with a UK, French or German one. 

Anyone here believe Unisys deserve a patent royalty on Compuserve's Gif
format? Compuserve were entirely unaware that their standard might
infringe. Had they known that Unisys had a patent they could easily have
avoided the specific inventions claimed.

Has anyone considered that a person making a bogus patent application
might be held liable under a private suit for conversion in fraud?

	Phill

------=_NextPart_000_0019_01BFDF71.12D65C80
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0019_01BFDF71.12D65C80--

From: "Lutz, Lisa" <[email-masked]>
To: [email-masked]
Subject: unsubsribe
Date: Mon, 26 Jun 2000 11:03:02 -0400

From: "Mason, Shane" <[email-masked]>
To: [email-masked]
Subject: unsubscribe
Date: Mon, 26 Jun 2000 10:36:49 -0400

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

------_=_NextPart_001_01BFDF7B.F61DCEF0
Content-Type: text/plain;
	charset="iso-8859-1"

unsubscribe

------_=_NextPart_001_01BFDF7B.F61DCEF0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial><SPAN 
class=161403514-26062000>unsubscribe</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01BFDF7B.F61DCEF0--

Date: Mon, 26 Jun 2000 06:43:50 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Hi Rich,

>> So you want any user of a PKIX service to have to figure out a OOB mechanism
>> for each provider of the service to verify the self-signed certificate?
> 
> Not at all.
> 
> I want it to be *possible* to start an independant PKIX service.
> 
> Let me turn the question around:  why do you feel it necessary to force me
> to run a CA?

I've never stated that I want you to run a CA for each PKIX service. I think
the issuance of certificates should be handled by a CA, not every PKIX
service that pops up.

Why do you want to force me to figure out the OOB mechanism for every new
PKIX service? You, most of the folks on this list and I may know how to do
that, but I doubt my mother or grandmother would know how to.

Regards,
Aram Perez

Date: Mon, 26 Jun 2000 14:44:50 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: TSP-09

I took advantage of a pause on the mailing list about TSP, to post a
new draft now available at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-09.txt

The main reason to issue a new draft was to correct the syntax of
PKIStatus which was missing one line, i.e. statusString 
PKIFreeText  OPTIONAL, :-(

At the same time, the following changes have been made:

Turn some "shall" into "SHALL".

Modifications to say that a modified Token may be returned when the
status is one (grantedWithMods), e.g. when some extensions have been
incorporated in a way that is slightly different from the request.
The status 6 (KeyUpdateWarning) has been deleted since it bears a
different meaning in CMP and cannot be returned in our case.

Modification of the sentence about multiple private signature keys
in section 2.3. to get the following:

"A TSA MAY have distinct private keys, e.g. to accommodate different
policies, different algorithms, different private key sizes or to
increase the performance."

As supported by Steve Kent and some others, the current text to
specify that the private key MUST not be used for any other purpose
has been maintained. 

Peter Sylvester noticed that (in version 8) I changed in the module, 
extensions            [0] Extensions  OPTIONAL
with 
extensions            [0] IMPLICIT Extensions  OPTIONAL
but I forgot do do it as well in the text. I will fix it.

It is now time to send this document to the IESG. There are still
opportunities to make minor changes to the document when it becomes
a Standard, at least six months after it becomes Proposed Standard.

Denis

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-09.txt
Date: Mon, 26 Jun 2000 06:46:31 -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 Time Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams,  P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-09.txt
	Pages		: 22
	Date		: 23-Jun-00
	
A time stamping service allows to prove that a datum existed before 
a particular time and can be used by a Trusted Third Party (TTP) as 
one component in building reliable non-repudiation services (see 
[ISONR]). This document describes the format of a request sent to a 
Time Stamping Authority (TSA) and of the response that is returned.
An example of how to prove that a digital signature was generated 
during the validity period of a public key certificate is given 
in an annex.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-09.txt

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

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

--OtherAccess--

--NextPart--

From: "Peter Lipp" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>
Cc: "PKIX" <[email-masked]>
Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Mon, 26 Jun 2000 10:09:19 +0200
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.A287CEE0--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> It is not a PGP-model. I register my direct trust a self-signed CA
> certificate - is it PGP? Of course not. So why are you saying
> that trusting to a self-signed TSA certificate is PGP?

Because if every PKI-service (TSA, OCSP, SCVP, ...) signs their own
certificate, and if I have to verify trust into each and every one of them
separately, and that smells PGPish and not PKIXish. Strictly speaking it is
not PGP, but if I extrapolate and allow you to register your direct trust
into my personal self signed CA certificate, we are very close to PGP,
aren't we? And I don't care about the data formats here...

Peter

----IAIK.SMIME.MAPPER.A287CEE0--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAAA
----IAIK.SMIME.MAPPER.A287CEE0----

Date: Mon, 26 Jun 2000 07:14:23 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Group plc
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Do people have something against RSA?

Bob Jueneman wrote:
> Sounds great, at least to the young and naive (as most of us were at one time).
> Unfortunately, although the Soviets tried this system for 80 years, and the Cubans,
> North Koreans, and some other societies are still trying it, the jury has come back with
> a verdict.  Except in some closed societies, normally religious orders, this system
> simply does not work, and can only be sustained through a very harsh and cruel
> dictatorship.  Those who have talent either opt out or become the bosses, leaving
> those who cannot to fend for themselves.
> 
> If inventors cannot be rewarded for the fruits of their labors, then the entire structure
> of capitalism is without a foundation, and all of the IPOs and stock market gains
> are merely the Tulip Bulb mania repeating itself all over again.
> 
> Unfortunately, it has gotten to the point that filing for an invention has become
> the kiss of death within the IETF.  No matter how good the idea is, if you patent it
> the IETF will go out of their way to make sure that it isn't standardized.

a) Are you aware of the IETF rules regarding patented stuff in
standards?

b) Why do you think that patents are the only way to be rewarded for
inventing things?

> The inevitable result of this is that either (1) companies will stop inventing things,
> since they won't be rewarded for them, or (2) companies will drop out of the IETF
> process, and ignore the standards as either irrelevant or explicitly contrary to their
> business interests.  Is that what we want to have happen?

The problem with this "prediction" is that although its premise is
demonstrably correct, the consequence hasn't occurred.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

To: [email-masked]
Cc: [email-masked]
Subject: Unique identifiers for certificate.
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 26 Jun 2000 15:02:11 +0900 (JST)
Lines: 17

Hello,
I have a question of unique identifiers for certificate.

Is there any general guideline which describes which unambiguous
identifiers for certificate should be used?

For example, a combination of Issuer Name and Certificate Serial
Number is used as the identifier for the actual public key to verify
the signature in PKCS#7.  Additinally, a combination of issuer name,
subject name and subject key identifier is also used (this is
described in draft-ietf-pkix-technr-00.txt.)

Thanks,
----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business Solution Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

From: Michael Zolotarev <[email-masked]>
To: Peter Lipp <[email-masked]>, Rich Salz <[email-masked]>, Aram Perez <[email-masked]>
Cc: PKIX <[email-masked]>
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Mon, 26 Jun 2000 09:44:19 +1000

It is not a PGP-model. I register my direct trust a self-signed CA
certificate - is it PGP? Of course not. So why are you saying that trusting
to a self-signed TSA certificate is PGP?

Are we trying to limit issuing self-signed certificates to CA only,
PKI-wide? The same arguments apply to any non-CA service, such as Attribute
Authority, don't they?

> -----Original Message-----
> From: Peter Lipp [mailto:[email-masked]]
> Sent: Saturday, June 24, 2000 9:41 PM
> To: Rich Salz; Aram Perez
> Cc: PKIX
> Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> > > If I take your statements/conclusions below to their extreme,
> > then anytime
> > > PKIX comes up with a new service that uses digital signatures,
> > that service
> > > would have to issue its own self-signed certificates. I don't
> > see the OCSP
> > > folks requesting their own self-signed certificates.
> >
> > Not HAVE TO issue, but COULD issue.  Most definitely.
> 
> Yes. And I could also issue my self-signed certificate, and 
> you would have
> less problems trusting me because you would not need to 
> bother with the
> obscure cert I might have from some CA service. Welcome to 
> the PGP-model!
> 
> Peter
> 
> 
> 

Date: Sun, 25 Jun 2000 14:57:10 -0400
From: Rich Salz <[email-masked]>
To: Aram Perez <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> So you want any user of a PKIX service to have to figure out a OOB mechanism
> for each provider of the service to verify the self-signed certificate?

Not at all.

I want it to be *possible* to start an independant PKIX service.

Let me turn the question around:  why do you feel it necessary to force me
to run a CA?
	/r$

Date: Sat, 24 Jun 2000 22:34:32 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Rish Salz wrote:

>> If I take your statements/conclusions below to their extreme, then anytime
>> PKIX comes up with a new service that uses digital signatures, that service
>> would have to issue its own self-signed certificates. I don't see the OCSP
>> folks requesting their own self-signed certificates.
> 
> Not HAVE TO issue, but COULD issue.  Most definitely.

So you want any user of a PKIX service to have to figure out a OOB mechanism
for each provider of the service to verify the self-signed certificate?

Regards,
Aram Perez

From: [email-masked]
Date: Sat, 24 Jun 2000 17:37:11 EDT
Subject: Re: certification for pki
To: [email-masked], [email-masked]
CC: [email-masked]

Jean,

There is a process called WebTrust that is endorsed by the American Institute 
of Certified Public Accountants (AICPA) and the Canadian Institute of 
Chartered Accountants (CICA).  WebTrust offers several models of audit and 
certification guidance including one for Certificate Authorities (WebTrust 
Principles and Criteria for Certificate Authorities).  While this process 
does not currently have "international" acceptance, many past AICPA standards 
have gained that stature.  If you would like additional information, please 
go to: http://www.cpawebtrust.org.

Charlie

<[email-masked]>

From: "Peter Lipp" <[email-masked]>
To: "Rich Salz" <[email-masked]>, "Aram Perez" <[email-masked]>
Cc: "PKIX" <[email-masked]>
Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Sat, 24 Jun 2000 13:41:11 +0200
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.261C1BF8--
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> > If I take your statements/conclusions below to their extreme,
> then anytime
> > PKIX comes up with a new service that uses digital signatures,
> that service
> > would have to issue its own self-signed certificates. I don't
> see the OCSP
> > folks requesting their own self-signed certificates.
>
> Not HAVE TO issue, but COULD issue.  Most definitely.

Yes. And I could also issue my self-signed certificate, and you would have
less problems trusting me because you would not need to bother with the
obscure cert I might have from some CA service. Welcome to the PGP-model!

Peter

----IAIK.SMIME.MAPPER.261C1BF8--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAAA
----IAIK.SMIME.MAPPER.261C1BF8----

Date: Sat, 24 Jun 2000 06:41:01 -0400
From: Rich Salz <[email-masked]>
To: Aram Perez <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> If I take your statements/conclusions below to their extreme, then anytime
> PKIX comes up with a new service that uses digital signatures, that service
> would have to issue its own self-signed certificates. I don't see the OCSP
> folks requesting their own self-signed certificates.

Not HAVE TO issue, but COULD issue.  Most definitely.

From: "Jean Abraham" <[email-masked]>
To: <[email-masked]>
Subject: digital certificate supports?
Date: Sat, 24 Jun 2000 13:11:51 +0300
Importance: Normal

Hi,

What are the applications that does or does not support more than 4
hierachies in a digital certificate.

Jean

Date: Fri, 23 Jun 2000 21:12:33 -0700
From: Aram Perez <[email-masked]>
Subject: Re: Allow RSA mandatory after September 20, 2000 ?
To: IETF-PXIX <[email-masked]>

Hi Denis,

> Up to now, the IETF WGs and the IESG have mandated the DSA and
> Diffie-Hellman algorithms only, since the RSA algorithm was
> patented. On September 20, 2000 the RSA patent will expire, so this
> allows the IESG to reconsider the issue.
> 
> I would like the co-chairs to raise this issue to the IESG, so that
> for any Standard (not Proposed Standard) issued after September 20,
> 2000, we can, if this is a WG decision, mandate the RSA algorithm.

Great suggestion! I fully support this request.

Regards,
Aram Perez

Date: Fri, 23 Jun 2000 21:12:36 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Hi Michael,

If I take your statements/conclusions below to their extreme, then anytime
PKIX comes up with a new service that uses digital signatures, that service
would have to issue its own self-signed certificates. I don't see the OCSP
folks requesting their own self-signed certificates.

Regards,
Aram Perez

>> 
>> I don't agree.  As the service provider, why do I *have* to deal with
>> the management of two private keys.  It's way more than syntax.
>> 
>> We don't need to "push" anything.  We need to not prohibit it.
>> /r$
>> 
> 
> I fully agree with that.
> 
> Guys,
> 
> << I feel that I've said all I had to say on the subject. In this mail I'll
> try to put together a little summary of my position, which I know is
> supported by a number of the list members. It was taking too much and too
> long - this message will be the last from me on self-signed TSA certs (do I
> see happy smiles :)? Denis, it is really up to you now - put it on vote, or
> forget. >>
> 
> I (quite frankly) fail to understand the rational for the draft to introduce
> limitations which necessitate extra entities and potentially more complex
> environment for all involved parties. All for a sake of extra purity of a
> concept, which is already pure enough. Probably my position is too much
> 'engineering', but this is what I am, sorry.
> 
> An example first:
> Imagine some Business_Domain_Managing_Authority (BDMA) that wants to deploy
> a TSA service for its members. Would it be Ok that the members express their
> trust directly to the TSA? I guess so.
> 
> With the client's trust expressed directly to the TSA cert, it is irrelevant
> if the TSA cert was self-signed or CA-signed. Referring to the arguments in
> favor of signing by CA - yes, I agree that there are benefits, thank you. It
> is all perfect with the assumption that there IS a CA around, or at least a
> business has a need for a CA.
> 
> Now, can anybody explain the BDMA's manager (a stubborn and slow guy he is
> indeed :) why the organisation has to buy/setup/employ a CA, if everything
> that they will ever need is just a TSA?
> 
> << I know that the previous sentence may get me sacked from Baltimore, which
> main business is selling CAs. :) So the standard disclaimer is right here.
>>> 
> 
> Mind you, out-of-band TSA cert delivery is as complex, or as simple, as the
> one for distributing a CA's cert, should it exist.
> 
> As a conclusion:
> Using self-signed TSA certs should be an internal matter for each domain,
> each TSA, subject to specific policy and national regulations. And a hell
> lot more. Therefore, the draft should not encourage self-signed TSA certs,
> neither it should prohibit them. It should be neutral and stay away from
> that slippery subject.
> 
> And it is not far from what the current draft is about, as it seems.
> 
> A minor fix- a sentence for the security considerations section would be
> something like:
> "The TSA private key must be generated and used ONLY for signing timestamps,
> and possibly for internal key/certificate management operations such as
> P-O-P or self-signing."
> 
> Best regards
> Michael
> 

From: "Peter Lipp" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, <[email-masked]>
Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Fri, 23 Jun 2000 23:34:22 +0200
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.8A03CDEB--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I guess the problem is a common misconception that a TSA is always a
> subsidiary/sub-service of a CA. Not necessary. TSA is/can_be a service on
> its own, with no inherited relationship to any CA at all.
Sure it can. But I bet it still will have certificates from some CA (more
than one maybe) that trust the TSA for doing their service properly. Do you
really believe the average user will and can go and check for each and every
service provider if it should be trusted? If he at some point really
consiously decided to trust a certain CA, it will be close to a miracle.
Most will accept somebody elses decisions, maybe preconfigured by the
vendor, and if the SW asks: should I trust, he will hit the "never ask me
that question again" button....

Peter

----IAIK.SMIME.MAPPER.8A03CDEB--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAAA
----IAIK.SMIME.MAPPER.8A03CDEB----

Date: Fri, 23 Jun 2000 17:04:53 -0400
To: Rich Salz <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
Cc: PKIX <[email-masked]>

Rich,

><snip>
>
>Stephen Kent:
>  > I've always asserted that self-signed certs are just a syntactic
>  > convenience, not a generally useful way of ensuring security for
>  > transmitted public keys.  If we agree on that point, then I don't see
>  > a lot of reason to push for self-signed TSA certs.
>
>I don't agree.  As the service provider, why do I *have* to deal with
>the management of two private keys.  It's way more than syntax.
>
>We don't need to "push" anything.  We need to not prohibit it.

You don't agree with what, the assertion about syntactic convenience? 
I don't think it's much easier to manage one private key vs. two when 
you have to distribute one key visa OOB means in either case. It is a 
lot cleaner, and it provides a straightforward revocation mechanism 
for the TSA key, even allowing delegation to an OCSP server without 
further violating the notion of what a TSA should be used to sign.

Steve

From: Philip Hallam-Baker <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, Bob Jueneman <[email-masked]>, [email-masked]
Subject: RE: Do people have something against RSA?
Date: Fri, 23 Jun 2000 13:25:09 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0032_01BFDD2F.C163D550
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>OpenPGP *is* and IETF standard. It has the same standards level as 
>S/MIME and PKIX does. You may not use it, and your company may not 
>sell it, but please stop pretending it is not an IETF standard.

Paul as a matter of FACT, PGP is NOT an IETF standard. There are in 
fact practically no IETF standards. IP and TCP being some of the few
exceptions. SMTP is a standard but HTTP still is not.

PGP is currently a proposed standard. Recognition as an actual standard
is far from certain and depends in part upon market acceptance.

The status of market acceptance of PGP and PKIX is NOT equivalent in
any degree.

In addition X.509v3 of which PKIX is a profile IS a standard recognised
by the International Standards Organization.

It is thus not a 'pretense' to claim PGP is not an IETF standard.
X.509v3
is however a longstanding ISO standard that the IETF has already
incorporated into widely deployed standards proposals.

		Phill

------=_NextPart_000_0032_01BFDD2F.C163D550
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0032_01BFDD2F.C163D550--

Content-return: allowed
Date: Fri, 23 Jun 2000 13:18:53 -0700
From: Frank Balluffi <[email-masked]>
Subject: RFC 2459: Use of Key Identifiers During Path Validation
To: "[email-masked]'" <[email-masked]>

Based on my reading of section 6.1 of RFC 2459 there is no need to check
that key identifiers chain properly during path validation. Is this true?

Frank

From: Philip Hallam-Baker <[email-masked]>
To: PKIX Mailing List <[email-masked]>
Subject: RE: Do people have something against RSA? 
Date: Fri, 23 Jun 2000 13:18:37 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_002D_01BFDD2E.D7428C00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Summary:

Unless we modify the drafts to rip out the mandatory DH but optional
RSA the PKIX and SMIME specs will inevitably end up being recycled
at DRAFT stage since otherwise our spec will not correspond to 
reality.

While we are at it a good purge of all lossage related to 40bit
ciphers is needed.

On the patent issue, yes I do begrudge folk a return on their IP. I
have yet to see anyone go out and hand me (or CERN) a cheque for the 
IP we put in the public domain. The fact is that in most cases a
patent is the kiss of death as far as I am concerned. If you patent
something it means that I have to talk to our lawyers if I want to
use it in a design. It is usually easier to work out another way 
to do the same thing - as some folk on this list have discovered.

I don't have a problem in the case that someone genuinely invented
something worthwhile. In most cases however I'm reading claims written
by some weasel that developed a better mousetrap and is claiming
the idea of catching all forms of vermin for purposes of disposal
(excluding weasels).

When I was at MIT one of the Profs made certain patent claims which
had they been made in an academic paper would have been considered
plagarism. I have noted a distinct decline in said profs patent 
prolixity since I made my position clear (and no it isn't anyone the
folk in this group is likely to know - unless they spend time reading
bogus patent claims).

The fact that DH expired two years ago and will not expire till the
end of the month after the next IETF does not appear to me to be 
a sufficient reason to absolutely reject RSA until the second hand
reaches the top of the hour ushering in October 1.

When the argument is that we all need one default algorithm to permit
interoperation it aoccurs to me that ignoring the 100 odd million
installations already shipped is ridiculous. They do RSA, they don't
do DH, it will be five years at least before that installed base will
cease to be a constraint - end of story.

		Phill

------=_NextPart_000_002D_01BFDD2E.D7428C00
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_002D_01BFDD2E.D7428C00--

Date: Fri, 23 Jun 2000 15:58:35 -0400
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Cc: <[email-masked]>

Bob,

>Steve/Clark :-),

(hey, don't blow my cover ...)

>
>  >>But presumably there would only be one
>  >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="[email-masked]"
>
>  >True.  If the intent were to create multiple leaf entries below the
>single entry of this form then  the justification would be better,
>but I don't that's what people have been suggesting.

>It's not that I particularly like compound attributes, but that's what
>I was suggesting, rather than having the rfc822 be a leaf under the user name
>DN.  That's what I mean to imply by the plus sign -- exactly like most
>people have been suggesting for name+serial.  At least the rfc822 name
>component has a great semantic content than a serial number.

Yes. But, what people were suggesting was a DN with ONLY a given name 
and surname, plus an e-mail address.  That's a bit odd from a 
directory structure perspective. Obviously we would not use the first 
two components as RDNs under a root, since there would be no good way 
to separate the database base for people on a large geographic basis 
using those attributes. If we used the e-mail address as the first 
RDN it would allow for meaningful partitioning, but because the 
address is a composite value, it seems wrong too.  It would be more 
appropriate to use the DC attribute to mimic the DNS structure, then 
put the user name as the leaf RDN.  In that case, though, the given 
name and surname are redundant, right?

Steve

From: Philip Hallam-Baker <[email-masked]>
To: "'Frederik Loeckx'" <[email-masked]>, [email-masked]
Subject: RE: Allow RSA mandatory after September 20, 2000 ?
Date: Fri, 23 Jun 2000 12:29:52 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0025_01BFDD28.07BA6670
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Even further, why wait till September 30? The patent sunset is
sufficiently
close and the deployment of RSA sufficiently widespread that the IESG is
not likely to influence the situation much.

I strongly suspect that MOST implementations of S/MIME will ignore the
mandatory support for D-H. The IESG can issue Canute like demands but
the tide of deployed clients will not head them any more than the sea
did the King.

We all know that after Sept 30 the IESG won't have any rational argument
for not recognising that support for RSA is necessary for S/MIME
interoperability and support for DH is not. It does not take a game
theorist to determine that the IESG has no negotiating strength in
such a situation.

Coupled with the various pieces of mud bubbling to the surface of the 
swamp with various obscure D-H related claims emerging, the IP story on 
D-H is likely to be worse than that on RSA after Sept 30.

		Phill

-----Original Message-----
From: Frederik Loeckx [mailto:[email-masked]]
Sent: Friday, June 23, 2000 7:46 AM
To: [email-masked]
Subject: Re: Allow RSA mandatory after September 20, 2000 ?

Even further, the question could be raised if DSA and  Diffie Hellman
need
to be marked as mandatory if RSA is already marked as mandatory.  When
RSA
is already present as a common algorithm, there is not need for DSA, DH
to
be mandated.   The standards will more reflect the actual marketplace,
when
DSA and Diffie Hellman are considered as optional.

Frederik

Denis Pinkas <[email-masked]> on 23/06/2000 10:09:14

To:   IETF-PXIX <[email-masked]>
cc:    (bcc: Frederik Loeckx/Utimaco/BE)

Subject:  Allow RSA mandatory after September 20, 2000 ?

Up to now, the IETF WGs and the IESG have mandated the DSA and
Diffie-Hellman algorithms only, since the RSA algorithm was
patented. On September 20, 2000 the RSA patent will expire, so this
allows the IESG to reconsider the issue.

I would like the co-chairs to raise this issue to the IESG, so that
for any Standard (not Proposed Standard) issued after September 20,
2000, we can, if this is a WG decision, mandate the RSA algorithm.

Denis

------=_NextPart_000_0025_01BFDD28.07BA6670
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0025_01BFDD28.07BA6670--

Date: Fri, 23 Jun 2000 11:30:21 -0700
From: "Doug M Williscroft" <[email-masked]>
To: [email-masked]
Subject: Trading Partner Web Certificates

This note is to elicit feedback on a PKI model that my organization has
implemented for web delivery/collection of information. We call it the
"trading partner certificate" model.

The trading partner certificate model does not attempt to provide the
full benefits of the grand PKI vision but limits itself to browser-based
extranets. The solution we have adopted is rather simple but - due to
limitations of existing technology - not especially elegant. Even so, we
believe it to provide significant authentication benefit at at
significantly lower cost than other alternatives. 

At the end of this note I describe a desirable new function for
certificate management (at the browser and/or OS) that would provide
broad benefit for extranet applications under this model.  I believe
this additional functionality would be relatively easy to develop, and
would quite possibly find a large market. 

Our model:
1) Establish a trading agreement with an organization through standard
business processes which include contractual definition of obligaitions.

2) Issue a trading partner certificate to the organization. (In our
current case the certificates are "anonymous"; they make no statement
about the trading partner. This is not a necessary component of the
model. Neither is it necessary that we be the certificate issuer.)

3) The trading partner installs the certificate and private key on all
browsers that will be used to access our services. (Most of our trading
partners use the IE5 browser which allows the private key to be flagged
as "not exportable" from the computer - a highly desirable feature in
our from our perspective.)

4) The trading partner registers its users in our extranet directory -
and assumes responsibility for managing those users - including
assignment of access permissions within the bounds of the trading
partner agreement. (At this point user administration requires some
intervention on our part - we anticipate fully externalized user
management in the future.)

5) Users connecting to our web servers are challenged (via SSL) to
provide a client certificate. 

6) Users presenting a valid trading partner certificate are challenged
for UserID and Password.

7) Users presenting a valid password and the correct trading partner
certificate for that user's organization are granted access to the
appropriate services.

To impersonate a user an attacker must gain direct access to a computer
in the trading partner organization, and gain knowledge of a valid
userID and password pair. We see this 2-factor mechanism as offering
protection against password discovery (by attackers external to the
trading partner organization), and against man-in-the-middle attacks
based on URL hijacking or DNS poisoning.

Desirable new certificate management functionality: 
It would be helpful to our trading partners if certificates/private keys
could be centrally distributed en-masse to all computers/user profiles
in a trading partner organization. Currently, our trading partners must
manually install the private key to each user login account that will
use our services - a tedious activity. This task must be repeated prior
to certificate expiry. Fortunately our trading partners are willing to
accept this administrative burden because they consider the services we
offer sufficiently valuable. 

Comments?

-- 
Doug Williscroft
HealthNet/BC Architecture and Standards Branch
Ministry of Health Information Management Group

Telephone: (250) 952-2497
_______________________________________________

Content-return: allowed
Date: Fri, 23 Jun 2000 10:30:30 -0700
From: Ambarish Malpani <[email-masked]>
Subject: RE: Generalizing the concept of id-pkix-ocsp-nocheck
To: "'Russ Housley'" <[email-masked]>
Cc: [email-masked]

I am suggesting that a CA does not require you to do a revocation
check on that certificate.

The reason a CA might want to do this is:

a. The CA has rules which say that the guarantees associated with
such certificates are more limited (e.g. utility certs in Identrus).

b. The CA "knows" that the cert will never be revoked [because
the CA controls that key with exactly the same care with which its
root key is protected].

c. The CA is trying to protect from infinite recursion [e.g. the
OCSP responder cert or maybe its indirect CRL signing cert].

Do we need to distinguish between a and b? Or should the CA do that
in its policies?

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: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, June 22, 2000 1:45 PM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: Re: Generalizing the concept of id-pkix-ocsp-nocheck
> 
> 
> Ambrish:
> 
> Are you suggesting that the replying party should blindly accept any 
> certificate that contains this flag?  Or, are you suggesting 
> that the flag 
> indicates that no revocation information is available for the 
> certificate?
> 
> Russ
> 
> 
> At 09:26 PM 06/20/2000 -0700, Ambarish Malpani wrote:
> 
> >I was recently having a conversation with a collegue and he
> >asked a question. Here goes:
> >
> >In OCSP, we have support the concept of a CA issuing a special
> >certificate to an OCSP responder, allowing it to respond on its
> >[the CA's] behalf with a special extended key usage flag.
> >
> >We also allow the CA to indicate that the responder's cert does
> >not need to be validated by having it include the
> >id-pkix-ocsp-nocheck extension in the responder's certificate.
> >
> >Why can't the concept of including an id-pkix-ocsp-nocheck
> >extension in a certificate be extended to any arbitrary certificate
> >to indicate that it doesn't need to be validated?
> >
> >If this makes sense, should this capability be specified in
> >son-of-rfc2459?
> >
> >Comments?
> >
> >Ambarish
> >
> >
> >---------------------------------------------------------------------
> >Ambarish Malpani
> >Architect                                                650.567.5457
> >ValiCert, Inc.                                  [email-masked]
> >339 N. Bernardo Ave.                          http://www.valicert.com
> >Mountain View, CA 94043
> 

Date: Thu, 22 Jun 2000 16:44:46 -0400
To: Ambarish Malpani <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Generalizing the concept of id-pkix-ocsp-nocheck
Cc: [email-masked]

Ambrish:

Are you suggesting that the replying party should blindly accept any 
certificate that contains this flag?  Or, are you suggesting that the flag 
indicates that no revocation information is available for the certificate?

Russ

At 09:26 PM 06/20/2000 -0700, Ambarish Malpani wrote:

>I was recently having a conversation with a collegue and he
>asked a question. Here goes:
>
>In OCSP, we have support the concept of a CA issuing a special
>certificate to an OCSP responder, allowing it to respond on its
>[the CA's] behalf with a special extended key usage flag.
>
>We also allow the CA to indicate that the responder's cert does
>not need to be validated by having it include the
>id-pkix-ocsp-nocheck extension in the responder's certificate.
>
>Why can't the concept of including an id-pkix-ocsp-nocheck
>extension in a certificate be extended to any arbitrary certificate
>to indicate that it doesn't need to be validated?
>
>If this makes sense, should this capability be specified in
>son-of-rfc2459?
>
>Comments?
>
>Ambarish
>
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                                650.567.5457
>ValiCert, Inc.                                  [email-masked]
>339 N. Bernardo Ave.                          http://www.valicert.com
>Mountain View, CA 94043

Content-return: allowed
Date: Fri, 23 Jun 2000 06:20:05 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
To: "'Michael Zolotarev'" <[email-masked]>, Peter Lipp <[email-masked]>, [email-masked]

According to RFC 2459 and draft-ietf-pkix-time-stamp-08.txt, the decision of
how to terminate the most-significant end of a certificate path and obtain
the most-trusted public key is up to you (i.e., is a matter of policy).

I recommend that section 2.4.1 of draft-ietf-pkix-time-stamp-08.txt point to
section 6.1 of RFC 2459 with something like:

For more information about validating the certificates in the certificates
field of the SignedData structure and obtaining the most-trusted public key,
see RFC 2459, section 6.1.

The relevant text follows.

Frank

<relevant-text>
RFC 2459, section 6:

This text assumes that all valid paths begin with certificates issued by a
single "most-trusted CA". ... The "most-trusted CA" is a matter of policy:
it could be a root CA in a hierarchical PKI; the CA that issued the
verifier's own certificate(s); or any other CA in a network PKI.

RFC 2459, section 6.1:

The text assumes that the trusted public key (and related information) is
contained in a "self-signed" certificate. This simplifies the description of
the path processing procedure.  Note that the signature on the self-signed
certificate does not provide any security services.  The trusted public key
(and related information) may be obtained in other formats; the information
is trusted because of other procedures used to obtain and protect it.

draft-ietf-pkix-time-stamp-08.txt, section 2.4.1

If the certReq field is present and set to true, the TSA's public key
certificate that is referenced by the ESSCertID attribute in the response
must be provided by the TSA in the certificates field from the SignedData
structure in that response. That field may also contain other certificates.
</relevant-text>

> -----Original Message-----
> From: Michael Zolotarev [mailto:[email-masked]]
> Sent: Thursday, June 22, 2000 10:02 PM
> To: Peter Lipp; [email-masked]
> Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> I guess the problem is a common misconception that a TSA is always a
> subsidiary/sub-service of a CA. Not necessary. TSA is/can_be 
> a service on
> its own, with no inherited relationship to any CA at all.
> 
> So when NIST starts offering TSA services, it would have to get a
> certificate from some CA? Why? Why wouldn't you trust their 
> TSA certificate
> directly?
> 
> 
> > -----Original Message-----
> > From: Peter Lipp [mailto:[email-masked]]
> > Sent: Thursday, June 22, 2000 7:24 PM
> > To: [email-masked]
> > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
> > 
> > 
> > > I'm not convinced it's bad to issue self-signed TSA certificate.
> > > I'm just saying it might not be a great idea.
> > Agree. I don't see the big advantage. For one, if I want to 
> > trust a CA I
> > need to go through whatever steps are appropriate. If the CA
> > offers/recommends/uses a TSA, it can give me a certificate 
> > for the TSA and -
> > having already decided to trust the CA - it is simple to verify the
> > certificate and decide to trust the TSA too. So what does the 
> > self-signed
> > TSA cert buy me besides the need to go through the trust 
> > decisions again?
> > Now consider revocation - do you really suggest to set up a separate
> > revocation-scheme for the TSA? I simply don't see any 
> > advantage here...
> > 
> > Peter
> > 
> 

Date: Fri, 23 Jun 2000 21:11:21 +0900
From: "Youjin, Eun" <[email-masked]>
Organization: SECUVE
To: "[email-masked]" <[email-masked]>
Subject: subscribe

--
=============================================================
-------------------------------------------------------------
Name : Eun, You Jin
-------------------------------------------------------------
Technical Director.
SECUVE CO., Ltd.
-------------------------------------------------------------
Phone   : +82-342-726-0830
Fax     : +82-342-726-0821
Cellular : +82-11-9968-0287
Address : D-217 SIGMA II 18, Koomi-Dong, Bundang-Gu,
          Sungnam-City, Kyunggi-Do, Korea
E-mail  : [email-masked]
URL     : http://www.secuve.com
=============================================================

From: "Frederik Loeckx" <[email-masked]>
To: [email-masked]
Date: Fri, 23 Jun 2000 13:45:47 +0200
Subject: Re: Allow RSA mandatory after September 20, 2000 ?

Even further, the question could be raised if DSA and  Diffie Hellman need
to be marked as mandatory if RSA is already marked as mandatory.  When  RSA
is already present as a common algorithm, there is not need for DSA, DH to
be mandated.   The standards will more reflect the actual marketplace, when
DSA and Diffie Hellman are considered as optional.

Frederik

Denis Pinkas <[email-masked]> on 23/06/2000 10:09:14

To:   IETF-PXIX <[email-masked]>
cc:    (bcc: Frederik Loeckx/Utimaco/BE)

Subject:  Allow RSA mandatory after September 20, 2000 ?

Up to now, the IETF WGs and the IESG have mandated the DSA and
Diffie-Hellman algorithms only, since the RSA algorithm was
patented. On September 20, 2000 the RSA patent will expire, so this
allows the IESG to reconsider the issue.

I would like the co-chairs to raise this issue to the IESG, so that
for any Standard (not Proposed Standard) issued after September 20,
2000, we can, if this is a WG decision, mandate the RSA algorithm.

Denis

From: Paul Halliden <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Paul Koning'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
Date: Fri, 23 Jun 2000 09:27:18 +0100

Terry Hayes wrote:
>A TSA MAY choose enforce restrictions on the imprint, but the 
>standard should not REQUIRE it.

Agreed. The question I was answering was "Why should people avoid using MD5
- other than because the German Digital Signature Law says so?".

Paul Halliden

Date: Fri, 23 Jun 2000 10:17:27 +0200
To: <[email-masked]>, <[email-masked]>
From: Juergen Brauckmann <[email-masked]>
Subject: RE: Private Key Cloning

At 18:24 22.06.00 -0700, Les Nightingill wrote:
>I suppose I should check, but perhaps someone knows, too, whether an M-of-N
>secret sharing scheme for disaster recovery of a root key is also
>non-compliant with the German Digital Signature laws?

Well, this is untested yet, I guess... . Private key cloning is explicitely
prohibited in the text of the law, but whether copying with secret sharing
is the same is not sure to me. 

As this is a law and legal stuff, you probably cannot check this issue
yourself, but you have to test against the authorities:-)  

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, 23 Jun 2000 10:09:14 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Allow RSA mandatory after September 20, 2000 ?

Up to now, the IETF WGs and the IESG have mandated the DSA and
Diffie-Hellman algorithms only, since the RSA algorithm was
patented. On September 20, 2000 the RSA patent will expire, so this
allows the IESG to reconsider the issue. 

I would like the co-chairs to raise this issue to the IESG, so that
for any Standard (not Proposed Standard) issued after September 20,
2000, we can, if this is a WG decision, mandate the RSA algorithm.

Denis

From: "Simon McMahon" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Fri, 23 Jun 2000 15:36:22 +1000

> > > From: Michael Zolotarev <[email-masked]>
> > >
> > > 1. Self-signed TSA cert. You have to evaluate your secure signing
> > > environment. Which is the same for generating timestamps
> > and for generation
> > > a self-signed cert.
> >
> > What security-relevant information are you expecting clients to derive
> > from validating the signature of a self-signed cert?
> >
> A client would not validate a self-signed cert - it would have to be
trusted
> directly, as an anchor. Distributed and cjecked out-of-bands. Why the
> question?
>
>
Why should the TSA self-sign this cert if no client will ever check the
signature ? This cert could be signed by any private key and the client
would not know since it trusts it directly and does not verify the sig.
Would you really abuse the usage constraints on a timestamping key to make a
signature that nobody needs to verify ?

The TSA may as well use another key-pair that it generates to sign this
cert. It can then make a normal self-signed cert with this new key pair that
will not sign timestamps.

Then clients who will not check the TSA cert's signature can just install
and trust the TSA cert (not self-signed). Clients that insist on checking
signatures on trusted and/or self-signed certs can install both certs then
trust the self-signed cert (not the TSA cert) as if it was from a real CA.

The TSA is effectively has its own mini CA and will only certify its own
time-stamping key pair. Its hardly a full blown CA with all the costs that
go with them. You could leave out the possibility of revocation etc. and you
would be no worse off than the self-signed TSA cert scenario.

>
> I don't agree.  As the service provider, why do I *have* to deal with
> the management of two private keys.  It's way more than syntax.
>
Because you are trying to do two things with one key. Producing timestamps,
and trusting them. You are still *having* to deal with these two seperate
processes the difference is with one key or with two.

If your clients dont check the trusted TSA cert's signature then you fall
back to only needing one key.

Simon.

From: Michael Zolotarev <[email-masked]>
To: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Fri, 23 Jun 2000 14:28:26 +1000

> 
> > From: Michael Zolotarev <[email-masked]>
> >
> > 1. Self-signed TSA cert. You have to evaluate your secure signing
> > environment. Which is the same for generating timestamps 
> and for generation
> > a self-signed cert.
> 
> What security-relevant information are you expecting clients to derive
> from validating the signature of a self-signed cert?
> 
A client would not validate a self-signed cert - it would have to be trusted
directly, as an anchor. Distributed and cjecked out-of-bands. Why the
question?

> Do you expect clients to have trusted storage which could 
> hold a bare TSA
> public key, but which could not hold the entire self-signed 
> TSA cert???
> 

No, I do not. The clients would store the entire self-signed cert.

Aha, I see it now: phrasing in (1) could be misleading. The signing of the
self-signed certificate is not critical, as the cert must be validated
out-of-band anyway. You only need to evaluate your secure key generation
environment, and the security of key storage and the crypto engine used for
signing timestamps.

But the argument still stays: using self-signed certificate does not
necessarily make the formal security evaluation process of a TSA any more
difficult, compared to having the TSA cert signed by a CA.

Regards
Michael

From: Michael Zolotarev <[email-masked]>
To: Rich Salz <[email-masked]>, PKIX <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Fri, 23 Jun 2000 13:39:15 +1000

> 
> I don't agree.  As the service provider, why do I *have* to deal with
> the management of two private keys.  It's way more than syntax.
> 
> We don't need to "push" anything.  We need to not prohibit it.
> 	/r$
> 

I fully agree with that. 

Guys,

<< I feel that I've said all I had to say on the subject. In this mail I'll
try to put together a little summary of my position, which I know is
supported by a number of the list members. It was taking too much and too
long - this message will be the last from me on self-signed TSA certs (do I
see happy smiles :)? Denis, it is really up to you now - put it on vote, or
forget. >>

I (quite frankly) fail to understand the rational for the draft to introduce
limitations which necessitate extra entities and potentially more complex
environment for all involved parties. All for a sake of extra purity of a
concept, which is already pure enough. Probably my position is too much
'engineering', but this is what I am, sorry.

An example first:
Imagine some Business_Domain_Managing_Authority (BDMA) that wants to deploy
a TSA service for its members. Would it be Ok that the members express their
trust directly to the TSA? I guess so.

With the client's trust expressed directly to the TSA cert, it is irrelevant
if the TSA cert was self-signed or CA-signed. Referring to the arguments in
favor of signing by CA - yes, I agree that there are benefits, thank you. It
is all perfect with the assumption that there IS a CA around, or at least a
business has a need for a CA. 

Now, can anybody explain the BDMA's manager (a stubborn and slow guy he is
indeed :) why the organisation has to buy/setup/employ a CA, if everything
that they will ever need is just a TSA?

<< I know that the previous sentence may get me sacked from Baltimore, which
main business is selling CAs. :) So the standard disclaimer is right here.

Mind you, out-of-band TSA cert delivery is as complex, or as simple, as the
one for distributing a CA's cert, should it exist. 

As a conclusion:
Using self-signed TSA certs should be an internal matter for each domain,
each TSA, subject to specific policy and national regulations. And a hell
lot more. Therefore, the draft should not encourage self-signed TSA certs,
neither it should prohibit them. It should be neutral and stay away from
that slippery subject.

And it is not far from what the current draft is about, as it seems. 

A minor fix- a sentence for the security considerations section would be
something like:
"The TSA private key must be generated and used ONLY for signing timestamps,
and possibly for internal key/certificate management operations such as
P-O-P or self-signing."

Best regards
Michael

From: Michael Zolotarev <[email-masked]>
To: Peter Lipp <[email-masked]>, [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Fri, 23 Jun 2000 12:02:16 +1000

I guess the problem is a common misconception that a TSA is always a
subsidiary/sub-service of a CA. Not necessary. TSA is/can_be a service on
its own, with no inherited relationship to any CA at all.

So when NIST starts offering TSA services, it would have to get a
certificate from some CA? Why? Why wouldn't you trust their TSA certificate
directly?

> -----Original Message-----
> From: Peter Lipp [mailto:[email-masked]]
> Sent: Thursday, June 22, 2000 7:24 PM
> To: [email-masked]
> Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> > I'm not convinced it's bad to issue self-signed TSA certificate.
> > I'm just saying it might not be a great idea.
> Agree. I don't see the big advantage. For one, if I want to 
> trust a CA I
> need to go through whatever steps are appropriate. If the CA
> offers/recommends/uses a TSA, it can give me a certificate 
> for the TSA and -
> having already decided to trust the CA - it is simple to verify the
> certificate and decide to trust the TSA too. So what does the 
> self-signed
> TSA cert buy me besides the need to go through the trust 
> decisions again?
> Now consider revocation - do you really suggest to set up a separate
> revocation-scheme for the TSA? I simply don't see any 
> advantage here...
> 
> Peter
> 

Reply-To: <[email-masked]>
From: [email-masked] (Les Nightingill)
To: <[email-masked]>
Subject: RE: Private Key Cloning
Date: Thu, 22 Jun 2000 18:24:47 -0700
Importance: Normal

I'm curious on the views of the "key cloning detractors" on the notable
disaster-recovery mitigation benefits of cloning. While the indirection
solution helps with load-sharing, it still leaves the root unrecoverable
under a no-clone policy.

I suppose I should check, but perhaps someone knows, too, whether an M-of-N
secret sharing scheme for disaster recovery of a root key is also
non-compliant with the German Digital Signature laws?

Les Nightingill
Cylink

-----Original Message-----
From: Michael Zolotarev [mailto:[email-masked]]
Sent: Wednesday, June 21, 2000 5:19 PM
To: Jeff Davis; [email-masked]
Subject: RE: Private Key Cloning

Jeff wrote:
> The whole idea of having a private key is just that, it is
> private to a
> single entity and not shared across many other "clones" of
> that entity.
>
> IMHO, and it is very "H" in this case, cloning a private key, of any
> nature, is opening yourselves up to all sorts of repudiation
> claims.  If
> you clone once what stops you cloning "n" times without
> anyone knowing
> ( regardless of what procedures you have in place ).  Part of
> the basis
> of "trust" is that a private key only exists in one place under the
> strict control of the owner of that key.

The cloning procedure becomes a critical part, I agree. So the authority
would have to certify both the security/procedures of its operational
environment, and the security/procedures of key cloning. The same scale of
precautions that currently applies to keeping the [only and single] key
secure would apply to the cloning process. If you suspect that the cloning
may allow a criminal-minded high-privileged insider to perpetrate a fraud,
then for the same reason your should similarly suspect any other security
aspects of the authority operations.

We must always consider every particular case of key cloning, instead of
dismissing the whole concept. If a particular cloning procedure, executed by
a particular authority, using given hardware, in a particular secure
environment etc etc can be formally certified as being sufficiently secure,
at least not less(!) secure than the rest of the solution - what is wrong
with it?

If you can prove that your solution is secure - that would be just fine. Why
reject the approach on the basis that it MAY present a security hole.
Following that logic, whole PKI would be extinct by now.

>
> I support the views put forward that maybe the TSA root should sign
> certificates  for level 1 TSA Agents, of which there could be
> as many as
> required, but all of whom have a different DN ( very closely
> associated
> with the parent TSA ).  The trust of the Time Stamp would then be
> through a normal certificate chain and that only being 1 level.  Maybe
> the TSA root could then go offline leaving the "work horses"
> to perform
> the stamping.  Re-issuing of new TSA signing keys would then be quite
> easy for each Agent, with only 1 out of "n" Agents being
> offline at any
> one time, update the hardware signing module and get back online
> a.s.a.p.
>
> I may be well off the mark here, if so, just tell me to shut
> up and get
> back in the cupboard.  However, as I am trying to learn this stuff, a
> little help with my waywardness would go a long way.
>
I'm also new to the house. But I've learned that there are two words missing
in the group's dictionary - "beautiful" and "shut up". Three words, actually
:)

M

Date: Thu, 22 Jun 2000 21:24:04 -0400
From: Rich Salz <[email-masked]>
To: PKIX <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

Aram:
> You shouldn't have to, although this is the model that most public CAs seem
> to push and/or encourage. As I mentioned, a possible solution is the the use
> of "anchor certificates".

Seems a little complicated.

I don't see why I have to introduce an extra entity involved, or extra certs
involved.

Stephen Kent:
> I've always asserted that self-signed certs are just a syntactic
> convenience, not a generally useful way of ensuring security for
> transmitted public keys.  If we agree on that point, then I don't see
> a lot of reason to push for self-signed TSA certs.

I don't agree.  As the service provider, why do I *have* to deal with
the management of two private keys.  It's way more than syntax.

We don't need to "push" anything.  We need to not prohibit it.
	/r$

Date: Thu, 22 Jun 2000 17:42:06 -0700
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Do people have something against RSA?

At 6:07 PM -0600 6/22/00, Bob Jueneman wrote:
>I don't disagree that PGP can use DSA.  And if I were building and giving away
>a product primarily to advance my own notions of social justice, 
>freedom, and privacy
>for all, laudable as that might be, instead of trying to make a 
>reasonable living, I
>would certainly pick a free algorithm also.  But we were talking about IETF
>standards, not freeware.

OpenPGP *is* and IETF standard. It has the same standards level as 
S/MIME and PKIX does. You may not use it, and your company may not 
sell it, but please stop pretending it is not an IETF standard.

>I don't think that the issue is one of large companies vs. small 
>companies, or even
>individuals or nonprofit institutitions.

We fully disagree here. Small companies cannot get reasonably-priced 
licenses for RSA today. Even large companies who have business models 
where they want to give away free software (have you ever heard of 
Microsoft, IBM, and AOL?) that happens to have good security in it 
cannot get reasonably-priced licenses from RSA. That is a business 
decision that RSA has had in place for many, many years.

>Instead, the issue cuts to the very heart of t
>he value of intellectual property, and whether someone, including 
>you, has a right
>to make a profit from their creative endeavors.

That's absolutely right. And, because there are freely-usable 
alternatives, we can ignore it. When the RSA patent expires, we can 
decide what to do about RSA vs. DSA.

[ insulting assumptions about other people's motivations snipped ]

>Unfortunately, it has gotten to the point that filing for an 
>invention has become
>the kiss of death within the IETF.  No matter how good the idea is, 
>if you patent it
>the IETF will go out of their way to make sure that it isn't standardized.

Bob, you need to get out into the rest of the IETF more. There are 
many IETF standards that use patented technologies. The patent 
holders have granted reasonable licenses to their competitors to use 
the technology in IETF standards.

>The inevitable result of this is that either (1) companies will stop 
>inventing things,
>since they won't be rewarded for them, or (2) companies will drop 
>out of the IETF
>process, and ignore the standards as either irrelevant or explicitly 
>contrary to their
>business interests.  Is that what we want to have happen?

The same argument has been heard here for many years, and it has 
never become true. I won't predict why that is, because my prediction 
mechanism is probably as badly flawed as yours is. If you (as an 
individual) want to drop out of the IETF, and/or if you want to try 
to convince Novell to drop out of the IETF, you are welcome to.

What we want to have happen is that useful, freely-implementable 
standards can be created. There are many other standards bodies that 
have different agendas. Spend your time in them as you wish.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 22 Jun 2000 18:07:43 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Do people have something against RSA?

I don't disagree that PGP can use DSA.  And if I were building and giving away
a product primarily to advance my own notions of social justice, freedom, and privacy
for all, laudable as that might be, instead of trying to make a reasonable living, I 
would certainly pick a free algorithm also.  But we were talking about IETF
standards, not freeware.

I don't think that the issue is one of large companies vs. small companies, or even
individuals or nonprofit institutitions.  Instead, the issue cuts to the very heart of t
he value of intellectual property, and whether someone, including you, has a right 
to make a profit from their creative endeavors.

Because the Internet was originally paid for by the US government and member
institutions, individuals never received a bill for service, and hence they tended 
to develop a sense of entitlement.

"From each, according to their abilities, and to each, according to their needs" 
was the credo of the Communists, and to a degree that mantra seems to have 
been adopted by a segment of the Internet community.

Since I "need" free movies, free MP3, free crypto, free computer games, etc., 
etc., and don't have the artistic or technical ability to generate them myself, 
I should be entitled to casually reach in and take whatever I want, without
paying for anything.  Minor details such as copyrights, patents, licensing fees,
attorneys -- these are just impediments created by the "suits" to prevent my
instant self-gratification.  After all, these things are just bits, right?  It isn't as though
I was stealing a car, right?

Sounds great, at least to the young and naive (as most of us were at one time).
Unfortunately, although the Soviets tried this system for 80 years, and the Cubans,
North Koreans, and some other societies are still trying it, the jury has come back with
a verdict.  Except in some closed societies, normally religious orders, this system 
simply does not work, and can only be sustained through a very harsh and cruel
dictatorship.  Those who have talent either opt out or become the bosses, leaving 
those who cannot to fend for themselves. 

If inventors cannot be rewarded for the fruits of their labors, then the entire structure
of capitalism is without a foundation, and all of the IPOs and stock market gains
are merely the Tulip Bulb mania repeating itself all over again.

Unfortunately, it has gotten to the point that filing for an invention has become 
the kiss of death within the IETF.  No matter how good the idea is, if you patent it
the IETF will go out of their way to make sure that it isn't standardized.

The inevitable result of this is that either (1) companies will stop inventing things,
since they won't be rewarded for them, or (2) companies will drop out of the IETF
process, and ignore the standards as either irrelevant or explicitly contrary to their 
business interests.  Is that what we want to have happen?

Bob

>>> Paul Hoffman / IMC <[email-masked]> 06/22/00 04:27PM >>>
At 2:55 PM -0600 6/22/00, Bob Jueneman wrote:
>I'm still waiting to see piece of e-mail that was signed using DSA and
>validated by a signature that also uses DSA.

Start using PGP.

>I'm glad that patents don't last forever, but we shouldn't begrudge them a
>reasonable return on their hard work.

It's funny how we never hear things like this from anyone who doesn't 
work for a large company.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 22 Jun 2000 17:11:18 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address

Steve/Clark :-),

>>But presumably there would only be one
>{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="[email-masked]"

>True.  If the intent were to create multiple leaf entries below the 
single entry of this form then  the justification would be better, 
but I don't that's what people have been suggesting.

It's not that I particularly like compound attributes, but that's what
I was suggesting, rather than having the rfc822 be a leaf under the user name
DN.  That's what I mean to imply by the plus sign -- exactly like most
people have been suggesting for name+serial.  At least the rfc822 name
component has a great semantic content than a serial number.

On the other hand, I guess we could always revert to the imfamous MPEG 
of me and my cat. But instead of putting it in the DN, I guess we would have 
to make it a directory attribute now.  (Just joking, of course.)

Bob

>>> Stephen Kent <[email-masked]> 06/22/00 04:28PM >>>
Bob,

>Steve,
>
>  >"Since e-mail addresses are
>already globally unique, what does the given name and surname do for
>you, from a tree structure standpoint?"
>
>Well, e-mail addresses are presumably globally unique, but they are 
>not necessarily
>one to one with an identifiable person.  Two or more people may share an
>e-mail mailbox, and very often do.  And one person may have more than one
>mailbox, and many do.

OK. But that does not justify constructing the schema we're debating, 
nor does the schema in question match your examples below.

>
>Likewise, there may be multiple Steve Kent's, and there might or might not
>be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent".

Yes, we need to have a DN that distinguishes among multiple Steve 
Kents. In your example above, a postal address would typically be 
employed to identify me as a specific residential person, or a 
binding to my employer would be used for me as an organizational 
person.

>But presumably there would only be one
>{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="[email-masked]"

True.  If the intent were to create multiple leaf entries below the 
single entry of this form then  the justification would be better, 
but I don't that's what people have been suggesting.

>Even so, that DN might be globally unambiguous, but not globally unique.
>{c=US, l=Gotham, cN="Clark Kent"}+rfc822="[email-masked]"
>may in fact refer to the same individual.

No argument there.  Multiple entries in the DIT may correspond to the 
same physical entity, ad would usually be true for residential and 
organizational persons, for example.

>And both e-mail postal boxes and DNS components can have aliases,
>so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding 
>Bullet"@DailyPlanet.com
>may also refer to the same person.

Sure.

Steve

Date: Thu, 22 Jun 2000 16:58:24 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: certification for pki

I attended the recent International Common Criteria conference in Baltimore,
mostly to learn the answers to these kinds of questions.

My assessment would be as follows:

1.  The Common Criteria, and the fact that 13 or so countries have agreed to
it, is not really a criteria at all, from the usual perspective, but rather a 
meta-criteria or specification language for laying out in some (excruciating) detail
what the requirements are, and how you have met them.  As a process for
convincing yourself, or your industry, that you have thought hard about the 
problem you are trying to solve, it is excellent.

2.  The real "guts" of the issue, however, is not how you specify the requirements,
but what the requirements really are.  And this is done through the Protection Profile.

3.  Unfortunately, there are as yet very few Protection Profiles that have been 
published, and even fewer, if any that have been widely vetted and accepted by a 
broad segment of the user community.

4.  One of the best examples of a good Protection Profile is being hammered out 
by the smart card industry, with the clout of the banks and credit card companies behind
it.  That will almost surely emerge as a almost universally accept PP.

5.  Some of the worst (from the standpoint of universality) Protection Profiles may
be in the area of PKI.  It should be obvious, but if there is substantial disagreement
as to the fundamentals of the digital signature law of the jurisdiction, there is not 
likely going to be any commonality regarding the Protection Profile.

As a result, I would expect that if say Siemens expects to sell a PKI for use in Germany,
they will eventually have to get it certified against the German Protection Profile.
But having done so, that may or may not carry any weight at all with respect to 
say the State of Utah's PKI requirement. And vice versa, for someone like 
Digital Signature Trust if they try to sell into Germany.

In other words, I wouldn't bet a whole lot of money on the Common Criteria being 
a roaring success, and especially in the PKI space.  And I say that, even though I'm 
a firm believer in the value of an independent evaluation of important software 
components.  Time will tell

bob

>>> <[email-masked]> 06/21/00 09:47AM >>>

It is not a choice of CC vs. FIPS.  The FIPS 140-1 testing pertains narrowly to
crypto modules.  The CC evaluation/"torture" process is about the
system/components for certificate issuance and management meeting its security
specification (security target and claimed PP(s)).  A crypto module is just an
embedded "engine" in the larger vehicle.   To continue with the automotive
metaphor, it is not a choice between auto emission testing vs. crash testing vs.
fuel economy vs. performance testing, etc.  All of these tests may be required
for the consumer to understand and compare what they are buying.  It may be
"torture" for the manufacturer, but when the market (or laws, regulations, etc.)
demand it, manufacturers do it.
-GH

[email-masked] on 06/21/2000 11:11:43 PM

Please respond to [email-masked] 

To:   [email-masked] 
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: certification for pki

[email-masked] writes:

>One internationally recognized avenue is an evaluation under the Common
>Criteria/ISO 15408.  Such an evaluation up to EAL4 is automatically recognized
>by the (currently) nine mutual recognition arrangement countries.  Two current
>problems are (1) that the CC itself does not contain a crypto module
>evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus
>and evaluated Protection Profile for PKI components.   Some product vendors
>have undertanen evaluations without PPs.  FIPS 140-1 is officially US/Canada,
>but also widely recognized.

A third problem with the CC, for those who haven't experienced it before, is
that it acts as a form of torture for companies to determine how badly they
need government (or whatever) contracts - the more pain you can stand, the
better you've demonstrated that you need the contract.  I'm not just saying
this for $generic_CC_bashing, from talking to people who have gone through it
it really sounds like an incredibly unpleasant experience (when I used the term
"torture" to describe it above this doesn't originate with me but with the
people I talked to).  In terms of achieving more or less the same effect (the
certification that is, not the torture :-) it looks like FIPS 140 is the easier
path, and it does constitute a de facto PP which the CC doesn't have yet.  I'd
go with FIPS 140.

Peter.

Date: Thu, 22 Jun 2000 18:28:43 -0400
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Cc: <[email-masked]>

Bob,

>Steve,
>
>  >"Since e-mail addresses are
>already globally unique, what does the given name and surname do for
>you, from a tree structure standpoint?"
>
>Well, e-mail addresses are presumably globally unique, but they are 
>not necessarily
>one to one with an identifiable person.  Two or more people may share an
>e-mail mailbox, and very often do.  And one person may have more than one
>mailbox, and many do.

OK. But that does not justify constructing the schema we're debating, 
nor does the schema in question match your examples below.

>
>Likewise, there may be multiple Steve Kent's, and there might or might not
>be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent".

Yes, we need to have a DN that distinguishes among multiple Steve 
Kents. In your example above, a postal address would typically be 
employed to identify me as a specific residential person, or a 
binding to my employer would be used for me as an organizational 
person.

>But presumably there would only be one
>{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="[email-masked]"

True.  If the intent were to create multiple leaf entries below the 
single entry of this form then  the justification would be better, 
but I don't that's what people have been suggesting.

>Even so, that DN might be globally unambiguous, but not globally unique.
>{c=US, l=Gotham, cN="Clark Kent"}+rfc822="[email-masked]"
>may in fact refer to the same individual.

No argument there.  Multiple entries in the DIT may correspond to the 
same physical entity, ad would usually be true for residential and 
organizational persons, for example.

>And both e-mail postal boxes and DNS components can have aliases,
>so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding 
>Bullet"@DailyPlanet.com
>may also refer to the same person.

Sure.

Steve

Date: Thu, 22 Jun 2000 15:27:16 -0700
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Do people have something against RSA?

At 2:55 PM -0600 6/22/00, Bob Jueneman wrote:
>I'm still waiting to see piece of e-mail that was signed using DSA and
>validated by a signature that also uses DSA.

Start using PGP.

>I'm glad that patents don't last forever, but we shouldn't begrudge them a
>reasonable return on their hard work.

It's funny how we never hear things like this from anyone who doesn't 
work for a large company.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 22 Jun 2000 15:46:24 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address

Steve,

>"Since e-mail addresses are 
already globally unique, what does the given name and surname do for 
you, from a tree structure standpoint?"

Well, e-mail addresses are presumably globally unique, but they are not necessarily
one to one with an identifiable person.  Two or more people may share an
e-mail mailbox, and very often do.  And one person may have more than one 
mailbox, and many do.

Likewise, there may be multiple Steve Kent's, and there might or might not
be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent".

But presumably there would only be one 
{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="[email-masked]" 

Even so, that DN might be globally unambiguous, but not globally unique.
{c=US, l=Gotham, cN="Clark Kent"}+rfc822="[email-masked]" 
may in fact refer to the same individual.

And both e-mail postal boxes and DNS components can have aliases,
so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding Bullet"@DailyPlanet.com
may also refer to the same person.

Signed,

"Leaps Tall Buildings with a Bound and a Half"@novell.com  :-)

>>> Stephen Kent <[email-masked]> 06/20/00 09:13AM >>>
Stefan,

>Steve,
>
>Thank's for useful input. Just to round this up, can you confirm the 
>conclusion that issuing certificates where subjects are represented 
>by just e-mail address + givenName + surname (and maybe also 
>country) is simply not possible.
>
>The name must simply be combined with a serialNumber attribute or 
>some other information that makes the name (with e-mail address 
>excluded) a reasonable DN.
>
>Right?

Well, its possible to issue certs with any sort of DN.  The question 
is what makes sense given the semantics of a DN, not just viewing it 
as a string of AVAs irrespective of context. The question I would ask 
is what would the directory tree look like given a proposed DN.  How 
would the tree be distributed and managed?  Think about the schema 
with those considerations in mind.

For example, if one uses a geopolitical and organizational structure, 
which is the common model for DNs, we see lots of reasonable options 
for dividing the tree and determining who is responsible for 
maintainign what portions of it.  On the other hand, if a DN consists 
of an e-mail address plus givenname and surname, this seems rather 
odd.  The e-mail address, as a single attribute, results in a very 
broad fan out under the root. (in contrast, if one used DC 
attributes, as mentioned recently, one could mimic the structure of 
the DNS, which is well suited for separation and distributed 
maintenance, as the DNS has shown.)  Since e-mail addresses are 
already globally unique, what does the given name and surname do for 
you, from a tree structure standpoint?

Steve

From: "Peter Lipp" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
Subject: AW: Do people have something against RSA?
Date: Thu, 22 Jun 2000 23:13:31 +0200
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.D38462D0--
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bob,

> I'm still waiting to see piece of e-mail that was signed using DSA
> and  validated by a signature that also uses DSA.  It isn't that it
> couldn't necessarily
> be done, it's just that it would be such a curiosity that I would=20
> be inclined to=20
> frame it.
You did not insist on S/Mime, did you? :-)

Peter

----IAIK.SMIME.MAPPER.D38462D0--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAAA
----IAIK.SMIME.MAPPER.D38462D0----

Date: Thu, 22 Jun 2000 14:55:21 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Do people have something against RSA?

Amen, brother!

I'm still waiting to see piece of e-mail that was signed using DSA and 
validated by a signature that also uses DSA.  It isn't that it couldn't necessarily
be done, it's just that it would be such a curiosity that I would be inclined to 
frame it.

It's exactly like when all of the coin machine vendors were forced to change their 
machines to handle the Susan B. Anthony dollar, only to have that coin sink 
like a rock.  The Post Office (and only the Post Office) issued them as change
if you bought a book of stamps, and anyone who received one got rid of it at the first
opportunity.

In the meantime, mandating particular algorithms that no one uses adds very 
significantly to the cost of development, testing, and documentation, not to mention 
bloated code. And piling on additional, "standardized" optional algorithms
just makes things worse.

"The nice thing about standards is that there are so many different ones to 
choose from."

Fortunately, the various vendors are quite free to say "Nuts to that" and ignore
the political correctness nonsense, and many of them are doing so.

RSA may very well be the Lavoris of cryptography -- the mouthwash you 
love to hate, twice a day -- but their standards, including the PKCS suite 
and S/MIME (along with Netscape's SSL, for all of its warts) have been 
commercial successes, while the adoption of IETF standards in this space 
have been lukewarm at best.  And they (along with Phil Zimmerman) were the ones 
who were standing up to NSA and refusing to back down when the 
government wanted desperately to put the crypto genie back in the bottle.

I'm glad that patents don't last forever, but we shouldn't begrudge them a 
reasonable return on their hard work.

Bob

>>> "Christopher Williams" <[email-masked]> 06/16/00 11:35AM >>>
OK, maybe RSADSI are litigious and awkward to deal with.  I don't know, I've
never dealt with them.  However, let's say that I implemented a standard,
say TLS, and only included the mandatory cipher suite, DSA with ephemeral
Diffie-Hellman, SHA-1 and 3-DES encryption.  You know what?  It wouldn't
work with anything!  Everybody else's implementation uses RSA so mine has to
as well, whether I like it or not.  The reality is that RSA is mandatory and
DSA the nice optional extra which adds spice and competitive advantage.

As to whether the future belongs to RSA or maybe some recent innovation like
ECC or some as-yet uninvented scheme, as Microsoft shows, it's not being the
best that makes you the winner, it's being the most widespread.

So, given that:
 - RSA's patent is due to expire (news to me, but welcome news)
 - DSA has patent issues in Europe
 - Everybody uses RSA anyway; very few use DSA

Can we please start mandating RSA in future?  It will make implementing
standards much easier and remove the FUD because I haven't incorporated
support for Diffie-Hellman!

Christopher Williams

Software engineer, NetLexis Ltd.
http://www.netlexis.com "Intelligent Trust"

Date: Thu, 22 Jun 2000 16:34:01 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
To: [email-masked]
Content-MD5: OgKp0bhJ2vWpkO0jtilCTg==

> From: Michael Zolotarev <[email-masked]>
>
> 1. Self-signed TSA cert. You have to evaluate your secure signing
> environment. Which is the same for generating timestamps and for generation
> a self-signed cert.

What security-relevant information are you expecting clients to derive
from validating the signature of a self-signed cert?

Do you expect clients to have trusted storage which could hold a bare TSA
public key, but which could not hold the entire self-signed TSA cert???

Date: Thu, 22 Jun 2000 13:31:00 -0700
From: [email-masked] (Terry Hayes)
To: Paul Halliden <[email-masked]>
CC: "'Paul Koning'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

Paul Halliden wrote:

> Certainly, as Terry argues, collisions in the TSA's own process will always
> be a concern. Whether or not end entity collisions are a concern to the TSA
> is application dependent.  As a minimum, collisions deliberately created by
> the end entity would be an embarrassment to the TSA and affect the
> perception of it in a public dispute.  Again, I would argue that it is
> safest not to make assumptions about the application.

Embarrassment to the TSA should result from failure to provide a correct and
secure timestamp, not from the content that is being stamped.  If you are
worried about embarrassment, perhaps you should insist on seeing the entire
message, rather than just an imprint.  After all, the imprint may be referring
to racist material, or plans for terrorist attacks.

While I'll grant that the imprint algorithm used (and the appropriateness of the
value given for that algorithm) are important for the functioning of the
process, I don't see any need to have the TSA enforce restrictions on them at
the time the timestamp is created.  If the primary goal is achieved (correct and
secure timestamping of the imprint), then a dispute resolution process can
determine whether a reasonable imprint algorithm (for the time) was used.

A TSA MAY choose enforce restrictions on the imprint, but the standard should
not REQUIRE it.

Terry Hayes

From: Paul Halliden <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Paul Koning'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
Date: Thu, 22 Jun 2000 20:36:58 +0100

Terry, Michael

I agree that finding "meaningful" collisions *can* be substantially harder
than simply finding two arbitrary strings with the same hash.  How much
harder, depends on the application.  For instance, if a strictly formatted
message has provision for a 64-bit randomly allocated nonce, the task is no
more difficult.  The point is that, as security system designers, we should
not make any assumptions about the message and it is therefore safest to
assume that creating a set of meaningful messages is not significantly more
difficult than creating un-meaningful ones. Ok, there are many cases where
that will not be valid, but...

Certainly, as Terry argues, collisions in the TSA's own process will always
be a concern. Whether or not end entity collisions are a concern to the TSA
is application dependent.  As a minimum, collisions deliberately created by
the end entity would be an embarrassment to the TSA and affect the
perception of it in a public dispute.  Again, I would argue that it is
safest not to make assumptions about the application.

As regards the possibility of actually mounting a "brute force" attack on
MD5 today, I originally said that "this task is far from trivial".  That is
British understatement for "very difficult".  As far as I am aware,  the
largest exhaustive search was for 56-bits in 1997 - and that required
massive distributed processing.  Searching for a collision would also
require large amount of memory / storage (one has to store the variable part
of 2^64 [meaningful] messages and their hash in order to have about 50%
probability of having two identical hashes).  So I do not expect to read of
a successful brute force attack on MD5 this year - but I would not express
great surprise if it happened.

Regards
Paul Halliden

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: 22 June 2000 19:13
>To: Paul Halliden
>Cc: 'Paul Koning'; [email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
>
>
>Paul,
>
>Addressing the first point in your message (a client 
>submitting a "cooked" MD5
>hash for timestamping), there are two points to make:
>
>1.  Finding collisions in MD5 is still hard, and finding 
>meaningful ones much
>harder.
>2.  It is not the concern of the TSA whether the client has 
>chosen a form of
>message imprint that will hold up under a challenge.  The 
>TSA's function is to
>associate a timestamp with the message imprint, no more.  
>Whether that message
>imprint can be used later to convince a third party that a 
>particular document
>was reference is more important to the client.  The client 
>should choose an
>imprint algorithm that will meet their requirements.
>
>Addressing the second point (getting the TSA to generate a 
>colliding time stamp
>token):
>
>1.  Again, it is difficult to find meaningful collisions.
>2.  The TSA is concern in this case, since a collision could 
>result it a token
>that indicates a different timestamp (probably an earlier one).
>3.  The TSA should choose a strong signature algorithm that 
>will provide the
>appropriate level of assurance for the required time period.  
>I suspect that
>many TSAs will choose a signature based on SHA for this 
>reason.  They will also
>choose key lengths depending on the desired security level.
>4.  Since a large part of the timestamp token is fixed or 
>guessable, t is
>probably worth including a "nonce" value in the generated 
>signature to make it
>difficult to force the TSA into generating a colliding 
>signature.  This value
>can easily be incorporated into the CMS SignedData object as a 
>signed attribute.
>
>Terry Hayes
>Netscape Communications Corp.
>
>Paul Halliden wrote:
>
>> There were two potential issues with MD5.  The first one was 
>an indication
>> that, at the time MD4 was "broken", MD5 was expected to fall 
>to a similar
>> attack "in the near future".  That has not happened so far.  
>We do not know
>> if that is because the task was too hard or if it was simply 
>that no-one has
>> got round to trying.  But it was the reason that many 
>stopped using MD5 at
>> that time.
>>
>> The second potential issue concerns the size of an MD5 hash, which is
>> shorter than an SHA-1 hash.  If an end entity is able to 
>create two messages
>> that have the same value of hash, he can submit the hash to 
>the TSA and then
>> subsequently claim that either of the messages existed. When 
>challenged, the
>> end entity presents whichever version of the message best 
>suits his argument
>> - an adjudicator would not be able to tell which was the 
>genuine one. Whilst
>> this task is far from trivial for a 128-bit hash such as 
>MD5, I believe it
>> is the same order of magnitude as finding a 64-bit symmetric key by
>> exhaustive search. (IANAC - so any cryptographer / 
>mathematician please feel
>> free to correct me).
>>
>> This potential attack is, IMHO, more significant for a TSA 
>where one entity
>> chooses the message and generates the hash and a second 
>entity signs it (as
>> part of the timestamp).
>>
>> Regards
>> Paul Halliden
>>
>> >-----Original Message-----
>> >From: Paul Koning [mailto:[email-masked]]
>> >Sent: 19 June 2000 16:00
>> >To: [email-masked]
>> >Cc: [email-masked]; [email-masked];
>> >[email-masked]
>> >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
>> >
>> >
>> >>>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:
>> >
>> > Joerg> Comments inline.
>> > >> TSA implementations MUST support SHA-1.  TSA implementations
>> > >> SHOULD support MD5.
>> >
>> > Joerg> I think there are good reasons not to use MD5 in time
>> > Joerg> stamps. They should use a strong hash function in order to
>> > Joerg> achive long validity periods. MD5 is likely to be 
>unsafe (=not
>> > Joerg> collision free) soon and is already discuraged by german
>> > Joerg> authorities.
>> >
>> > Joerg> IF we add a section about algorithms, it should maybe read:
>> > Joerg> "TSA implementations MUST support SHA-1.  TSA 
>implementations
>> > Joerg> SHOULD NOT support MD5.". But I think such a section is not
>> > Joerg> very necessary.
>> >
>> >IANAC, but from what I understand the currently known attacks on MD5
>> >are nowhere near strong enough to justify that.
>> >
>> >I don't have a problem with the current text (SHA-1 required, MD5
>> >recommended).  I do have a problem with text that implies 
>that MD5 is
>> >bad, because I don't know of data that supports such an assertion.
>> >
>> >Also, it doesn't seem like a good idea for the timestamp 
>spec to give
>> >very different signals from the other security specs.  If 
>there really
>> >is good reason to say these kinds of things about MD5, 
>let's have them
>> >identified.  (German authorities are not a good reason.  
>Cryptanalysis
>> >that shows weaknesses of interesting size would be.)  If the issues
>> >are real, changes to MD5 text should be applied across the board.
>> >
>> >      paul
>> >
>

Date: Thu, 22 Jun 2000 14:27:22 -0500
From: Roland Mueller <[email-masked]>
To: Paul Halliden <[email-masked]>
CC: "'Paul Koning'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

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

Just take a look at CryptoBytes Volume 2, Number 2 which I'll attach. As far as
I recall, MD5 was considered broken at Eurocrypt 96

Roland

Paul Halliden wrote:

> There were two potential issues with MD5.  The first one was an indication
> that, at the time MD4 was "broken", MD5 was expected to fall to a similar
> attack "in the near future".  That has not happened so far.  We do not know
> if that is because the task was too hard or if it was simply that no-one has
> got round to trying.  But it was the reason that many stopped using MD5 at
> that time.
>
> The second potential issue concerns the size of an MD5 hash, which is
> shorter than an SHA-1 hash.  If an end entity is able to create two messages
> that have the same value of hash, he can submit the hash to the TSA and then
> subsequently claim that either of the messages existed. When challenged, the
> end entity presents whichever version of the message best suits his argument
> - an adjudicator would not be able to tell which was the genuine one. Whilst
> this task is far from trivial for a 128-bit hash such as MD5, I believe it
> is the same order of magnitude as finding a 64-bit symmetric key by
> exhaustive search. (IANAC - so any cryptographer / mathematician please feel
> free to correct me).
>
> This potential attack is, IMHO, more significant for a TSA where one entity
> chooses the message and generates the hash and a second entity signs it (as
> part of the timestamp).
>
> Regards
> Paul Halliden
>
> >-----Original Message-----
> >From: Paul Koning [mailto:[email-masked]]
> >Sent: 19 June 2000 16:00
> >To: [email-masked]
> >Cc: [email-masked]; [email-masked];
> >[email-masked]
> >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
> >
> >
> >>>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:
> >
> > Joerg> Comments inline.
> > >> TSA implementations MUST support SHA-1.  TSA implementations
> > >> SHOULD support MD5.
> >
> > Joerg> I think there are good reasons not to use MD5 in time
> > Joerg> stamps. They should use a strong hash function in order to
> > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not
> > Joerg> collision free) soon and is already discuraged by german
> > Joerg> authorities.
> >
> > Joerg> IF we add a section about algorithms, it should maybe read:
> > Joerg> "TSA implementations MUST support SHA-1.  TSA implementations
> > Joerg> SHOULD NOT support MD5.". But I think such a section is not
> > Joerg> very necessary.
> >
> >IANAC, but from what I understand the currently known attacks on MD5
> >are nowhere near strong enough to justify that.
> >
> >I don't have a problem with the current text (SHA-1 required, MD5
> >recommended).  I do have a problem with text that implies that MD5 is
> >bad, because I don't know of data that supports such an assertion.
> >
> >Also, it doesn't seem like a good idea for the timestamp spec to give
> >very different signals from the other security specs.  If there really
> >is good reason to say these kinds of things about MD5, let's have them
> >identified.  (German authorities are not a good reason.  Cryptanalysis
> >that shows weaknesses of interesting size would be.)  If the issues
> >are real, changes to MD5 text should be applied across the board.
> >
> >      paul
> >

--------------C8515E6EAC751FF5702124B6
Content-Type: application/pdf;
 name="crypto2n2.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="crypto2n2.pdf"

--------------C8515E6EAC751FF5702124B6--

Date: Thu, 22 Jun 2000 11:12:54 -0700
From: [email-masked] (Terry Hayes)
To: Paul Halliden <[email-masked]>
CC: "'Paul Koning'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

Paul,

Addressing the first point in your message (a client submitting a "cooked" MD5
hash for timestamping), there are two points to make:

1.  Finding collisions in MD5 is still hard, and finding meaningful ones much
harder.
2.  It is not the concern of the TSA whether the client has chosen a form of
message imprint that will hold up under a challenge.  The TSA's function is to
associate a timestamp with the message imprint, no more.  Whether that message
imprint can be used later to convince a third party that a particular document
was reference is more important to the client.  The client should choose an
imprint algorithm that will meet their requirements.

Addressing the second point (getting the TSA to generate a colliding time stamp
token):

1.  Again, it is difficult to find meaningful collisions.
2.  The TSA is concern in this case, since a collision could result it a token
that indicates a different timestamp (probably an earlier one).
3.  The TSA should choose a strong signature algorithm that will provide the
appropriate level of assurance for the required time period.  I suspect that
many TSAs will choose a signature based on SHA for this reason.  They will also
choose key lengths depending on the desired security level.
4.  Since a large part of the timestamp token is fixed or guessable, t is
probably worth including a "nonce" value in the generated signature to make it
difficult to force the TSA into generating a colliding signature.  This value
can easily be incorporated into the CMS SignedData object as a signed attribute.

Terry Hayes
Netscape Communications Corp.

Paul Halliden wrote:

> There were two potential issues with MD5.  The first one was an indication
> that, at the time MD4 was "broken", MD5 was expected to fall to a similar
> attack "in the near future".  That has not happened so far.  We do not know
> if that is because the task was too hard or if it was simply that no-one has
> got round to trying.  But it was the reason that many stopped using MD5 at
> that time.
>
> The second potential issue concerns the size of an MD5 hash, which is
> shorter than an SHA-1 hash.  If an end entity is able to create two messages
> that have the same value of hash, he can submit the hash to the TSA and then
> subsequently claim that either of the messages existed. When challenged, the
> end entity presents whichever version of the message best suits his argument
> - an adjudicator would not be able to tell which was the genuine one. Whilst
> this task is far from trivial for a 128-bit hash such as MD5, I believe it
> is the same order of magnitude as finding a 64-bit symmetric key by
> exhaustive search. (IANAC - so any cryptographer / mathematician please feel
> free to correct me).
>
> This potential attack is, IMHO, more significant for a TSA where one entity
> chooses the message and generates the hash and a second entity signs it (as
> part of the timestamp).
>
> Regards
> Paul Halliden
>
> >-----Original Message-----
> >From: Paul Koning [mailto:[email-masked]]
> >Sent: 19 June 2000 16:00
> >To: [email-masked]
> >Cc: [email-masked]; [email-masked];
> >[email-masked]
> >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
> >
> >
> >>>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:
> >
> > Joerg> Comments inline.
> > >> TSA implementations MUST support SHA-1.  TSA implementations
> > >> SHOULD support MD5.
> >
> > Joerg> I think there are good reasons not to use MD5 in time
> > Joerg> stamps. They should use a strong hash function in order to
> > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not
> > Joerg> collision free) soon and is already discuraged by german
> > Joerg> authorities.
> >
> > Joerg> IF we add a section about algorithms, it should maybe read:
> > Joerg> "TSA implementations MUST support SHA-1.  TSA implementations
> > Joerg> SHOULD NOT support MD5.". But I think such a section is not
> > Joerg> very necessary.
> >
> >IANAC, but from what I understand the currently known attacks on MD5
> >are nowhere near strong enough to justify that.
> >
> >I don't have a problem with the current text (SHA-1 required, MD5
> >recommended).  I do have a problem with text that implies that MD5 is
> >bad, because I don't know of data that supports such an assertion.
> >
> >Also, it doesn't seem like a good idea for the timestamp spec to give
> >very different signals from the other security specs.  If there really
> >is good reason to say these kinds of things about MD5, let's have them
> >identified.  (German authorities are not a good reason.  Cryptanalysis
> >that shows weaknesses of interesting size would be.)  If the issues
> >are real, changes to MD5 text should be applied across the board.
> >
> >      paul
> >

Sender: [email-masked]
Date: Thu, 22 Jun 2000 10:43:18 -0700
From: Michael Sierchio <[email-masked]>
To: Paul Halliden <[email-masked]>
CC: "'Paul Koning'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

Paul Halliden wrote:
> 
> There were two potential issues with MD5. 

A potential issue is not an issue...

> ...If an end entity is able to create two messages
> that have the same value of hash, he can submit the hash to the TSA and then
> subsequently claim that either of the messages existed. 
> ...(IANAC - so any cryptographer / mathematician please feel
> free to correct me).

The difficulty of finding any two messages that have the same MD5
hash is enormous.  But consider that if both such messages are to
be meaningful it is quite another order of difficulty (greater,
if it isn't obvious).  

There is still no mechanism for creating a message which has
a given MD5 hash value...

From: Paul Halliden <[email-masked]>
To: "'Paul Koning'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
Date: Thu, 22 Jun 2000 18:16:18 +0100

There were two potential issues with MD5.  The first one was an indication
that, at the time MD4 was "broken", MD5 was expected to fall to a similar
attack "in the near future".  That has not happened so far.  We do not know
if that is because the task was too hard or if it was simply that no-one has
got round to trying.  But it was the reason that many stopped using MD5 at
that time.

The second potential issue concerns the size of an MD5 hash, which is
shorter than an SHA-1 hash.  If an end entity is able to create two messages
that have the same value of hash, he can submit the hash to the TSA and then
subsequently claim that either of the messages existed. When challenged, the
end entity presents whichever version of the message best suits his argument
- an adjudicator would not be able to tell which was the genuine one. Whilst
this task is far from trivial for a 128-bit hash such as MD5, I believe it
is the same order of magnitude as finding a 64-bit symmetric key by
exhaustive search. (IANAC - so any cryptographer / mathematician please feel
free to correct me).

This potential attack is, IMHO, more significant for a TSA where one entity
chooses the message and generates the hash and a second entity signs it (as
part of the timestamp).  

Regards
Paul Halliden

>-----Original Message-----
>From: Paul Koning [mailto:[email-masked]]
>Sent: 19 June 2000 16:00
>To: [email-masked]
>Cc: [email-masked]; [email-masked];
>[email-masked]
>Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
>
>
>>>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:
>
> Joerg> Comments inline.
> >> TSA implementations MUST support SHA-1.  TSA implementations
> >> SHOULD support MD5.
>
> Joerg> I think there are good reasons not to use MD5 in time
> Joerg> stamps. They should use a strong hash function in order to
> Joerg> achive long validity periods. MD5 is likely to be unsafe (=not
> Joerg> collision free) soon and is already discuraged by german
> Joerg> authorities.
>
> Joerg> IF we add a section about algorithms, it should maybe read:
> Joerg> "TSA implementations MUST support SHA-1.  TSA implementations
> Joerg> SHOULD NOT support MD5.". But I think such a section is not
> Joerg> very necessary.
>
>IANAC, but from what I understand the currently known attacks on MD5
>are nowhere near strong enough to justify that.  
>
>I don't have a problem with the current text (SHA-1 required, MD5
>recommended).  I do have a problem with text that implies that MD5 is
>bad, because I don't know of data that supports such an assertion.
>
>Also, it doesn't seem like a good idea for the timestamp spec to give
>very different signals from the other security specs.  If there really
>is good reason to say these kinds of things about MD5, let's have them
>identified.  (German authorities are not a good reason.  Cryptanalysis
>that shows weaknesses of interesting size would be.)  If the issues
>are real, changes to MD5 text should be applied across the board.
>
>      paul
>

Date: Thu, 22 Jun 2000 10:09:12 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Rich Salz wrote:

>> I'm not sure I understand your statement of having "*less* to trust".
> 
> Sorry, poorly worded.
> 
> If I trust the CA that certifies a TSA, then aren't I (by default, and
> certainly by philosophy) trusting EVERY certificate that CA issues?
> Why should I have to?

You shouldn't have to, although this is the model that most public CAs seem
to push and/or encourage. As I mentioned, a possible solution is the the use
of "anchor certificates".

Regards,
Aram Perez

Date: Thu, 22 Jun 2000 10:05:12 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Stephen Kent wrote:

> Folks,
> 
> I support Denis's original restriction on the uses of a TSA private
> key.  It is desirable to constrain the use of a private key to avoid
> possible errors in its use.  It seems that we have gone down a thread
> that focuses on certificates for a TSA, more than on the original key
> usage restriction.
> 
> I've always asserted that self-signed certs are just a syntactic
> convenience, not a generally useful way of ensuring security for
> transmitted public keys.  If we agree on that point, then I don't see
> a lot of reason to push for self-signed TSA certs.  A TSA is not a
> CA.  Even if the same organization happens to operate both a CA
> function and a TSA function, it seems appropriate to separate these
> functions. That's part of why we have the proposed constraint for
> using the TSA private key only for signing TSA responses. It was
> suggested that this is not consistent with the use of POP.  True, but
> only in so far as the POP in question is the one defined in our
> automated registration protocols.  Thus is not the only game in town,
> and for a TSA it is reasonable to anticipate other mechanisms that
> provide POP, but not via those protocols.  So, I don't think that the
> POP argument is a good basis for rejecting the key usage restriction.
> 
> The "less to trust" argument that Michael makes does have some merit,
> but as Aram points out, a self-signed cert required some
> integrity/authenticity secure, OOB means for its delivery, which is
> why we try to minimize the use of such certs.  It seems hard enough
> to do this for CAs, without adding TSAs to the list. Let's assume
> that TSAs are certified like other entities, by CAs, and work from
> there.

Well put Steve, I fully support this position.

Regards,
Aram Perez

Sender: rsalz
Date: Thu, 22 Jun 2000 11:45:52 -0400
From: Rich Salz <[email-masked]>
Organization: Caveo Systems, LLC
To: Aram Perez <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> I'm not sure I understand your statement of having "*less* to trust".

Sorry, poorly worded.

If I trust the CA that certifies a TSA, then aren't I (by default, and
certainly by philosophy) trusting EVERY certificate that CA issues?
Why should I have to?
	/r$

Date: Thu, 22 Jun 2000 10:39:16 -0400
To: Rich Salz <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
Cc: [email-masked]

Folks,

I support Denis's original restriction on the uses of a TSA private 
key.  It is desirable to constrain the use of a private key to avoid 
possible errors in its use.  It seems that we have gone down a thread 
that focuses on certificates for a TSA, more than on the original key 
usage restriction.

I've always asserted that self-signed certs are just a syntactic 
convenience, not a generally useful way of ensuring security for 
transmitted public keys.  If we agree on that point, then I don't see 
a lot of reason to push for self-signed TSA certs.  A TSA is not a 
CA.  Even if the same organization happens to operate both a CA 
function and a TSA function, it seems appropriate to separate these 
functions. That's part of why we have the proposed constraint for 
using the TSA private key only for signing TSA responses. It was 
suggested that this is not consistent with the use of POP.  True, but 
only in so far as the POP in question is the one defined in our 
automated registration protocols.  Thus is not the only game in town, 
and for a TSA it is reasonable to anticipate other mechanisms that 
provide POP, but not via those protocols.  So, I don't think that the 
POP argument is a good basis for rejecting the key usage restriction.

The "less to trust" argument that Michael makes does have some merit, 
but as Aram points out, a self-signed cert required some 
integrity/authenticity secure, OOB means for its delivery, which is 
why we try to minimize the use of such certs.  It seems hard enough 
to do this for CAs, without adding TSAs to the list. Let's assume 
that TSAs are certified like other entities, by CAs, and work from 
there.

Steve

Date: Thu, 22 Jun 2000 07:20:44 -0700
From: Aram Perez <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
To: PKIX <[email-masked]>

Rich Salz wrote:

>> So what does the self-signed
>> TSA cert buy me besides the need to go through the trust decisions again?
> 
> You actually have *less* to trust if you have a self-signed TSA. Trusting
> the CA means you trust all it signs.  Trusting the TSA means just and only
> that.

I'm not sure I understand your statement of having "*less* to trust". To
trust a self-signed certificate (no matter if it is from a CA or TSA), you
have to have an out-of-band mechanism to verify that the self-signed
certificate is valid. One of the nice features of a hierarchical PKI is that
I can limit the number of times I need the out-of-band mechanisms to verify
self-signed certificates.

If I don't want to trust the self-signed certificate of a CA that signs a
TSA, then I can use the out-of-band mechanism to verify the TSA's
certificate (that was signed by a CA) and treat it as an "anchor
certificate". My definition of an anchor certificate is a certificate I
implicitly trust because I have used an out-of-band mechanism to verify it.
When I'm validating the certificate chain, I stop whenever I reach an anchor
certificate (whether or not it is self-signed).

Regards,
Aram Perez

From: [email-masked]
To: [email-masked]
Subject: RE: certification for pki
Date: Thu, 22 Jun 2000 10:04:10 -0400

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

------_=_NextPart_001_01BFDC52.C59A3F34
Content-Type: text/plain;
	charset="iso-8859-1"

Russ,

Thanks for the link. I had a quick look at them and I have noted that
contrary to the NIST CIMC PP, which as indicated in my previous Email
created new security functional requirements even for key management, the
SPYRUS CIMS PPs contain no security functional requirements whatsoever about
cryptographic functionality. Each SPYRUS's PP contains the same statement,
"I haven't got a clue" when addressing Common Criteria requirement
statements about cryptographic support. Does SPYRUS plan to add some
security functional requirements from the Class FCS on cryptographic support
in a future version of its PPs?

Reagards,

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: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, June 21, 2000 10:48 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: certification for pki

Please take a look at the protection profiles being proposed by SPYRUS.  You
can find them at http://www.spyrus.com/documents/cims.  We have released the
Level 3 profile to ANSI X9 as a strawman for a financial industry protection
profile.

Russ

[snip]

------_=_NextPart_001_01BFDC52.C59A3F34
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.2650.12">
<TITLE>RE: certification for pki</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the link. I had a quick look at them and I =
have noted that contrary to the NIST CIMC PP, which as indicated in my =
previous Email created new security functional requirements even for =
key management, the SPYRUS CIMS PPs contain no security functional =
requirements whatsoever about cryptographic functionality. Each =
SPYRUS's PP contains the same statement, &quot;I haven't got a =
clue&quot; when addressing Common Criteria requirement statements about =
cryptographic support. Does SPYRUS plan to add some security functional =
requirements from the Class FCS on cryptographic support in a future =
version of its PPs?</FONT></P>

<P><FONT SIZE=3D2>Reagards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ Housley [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Wednesday, June 21, 2000 10:48 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: certification for pki</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Please take a look at the protection profiles being =
proposed by SPYRUS.&nbsp; You can find them at <A =
HREF=3D"http://www.spyrus.com/documents/cims" =
TARGET=3D"_blank">http://www.spyrus.com/documents/cims</A>.&nbsp; We =
have released the Level 3 profile to ANSI X9 as a strawman for a =
financial industry protection profile.</FONT></P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

<P><FONT SIZE=3D2>[snip]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFDC52.C59A3F34--

Sender: rsalz
Date: Thu, 22 Jun 2000 09:48:59 -0400
From: Rich Salz <[email-masked]>
Organization: Caveo Systems, LLC
To: Peter Lipp <[email-masked]>
CC: [email-masked]
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> So what does the self-signed
> TSA cert buy me besides the need to go through the trust decisions again?

You actually have *less* to trust if you have a self-signed TSA. Trusting
the CA means you trust all it signs.  Trusting the TSA means just and only
that.

	/r$

From: "Meggison, Tim" <[email-masked]>
To: "'Simon McMahon'" <[email-masked]>, Michael Zolotarev <[email-masked]>, Jean-Marc Desperrier <[email-masked]>, [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 08:24:54 -0400

I believe the key word in Simon's email is policy.  
What is good policy for one situation is overkill for another.
I suggest the spec should be limited to technical and interop requirements,
and leave policy decisions to actual implementations.

> -----Original Message-----
> From: Simon McMahon [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2000 10:51 PM
> To: Michael Zolotarev; Jean-Marc Desperrier; [email-masked]
> Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> Michael wrote:
> >
> > If we forget for a moment about what the draft says 
> (please): what is
> wrong
> > with using a TSA key for signing 'something that is not a 
> time-stamp'? I
> do
> > not see anything criminal about that. Especially if the case is
> well-defined
> > and justified.
> >
> The draft obviously said it for a reason but to answer "what is wrong
> with using a TSA key for signing 'something that is not a 
> time-stamp'?"
> 
> 1.    Its good security policy to restrict usage of 
> particularly sensitive
> keys.
> 
> The ultimate restriction is one exclusive use which is the 
> state of the
> draft now.
> You should show a very good reason to weaken that or show that the new
> usage has negligable impact. If you do this then an attack on 
> certificate
> signing keys will be useful as an attack on time-stamp 
> signing keys since
> time-stamp signing keys can also sign certificates.
> 
> 2.    It couples the primary TSA service (making timestamps) with a CA
>         service (making certificates).
> 
> I'm not sure that the intention is for TSAs to always be CAs 
> or vice versa.
> If CAs and TSAs will be operated, managed and owned seperately then it
> is good that their services are not too coupled or intertwined.
> 
> Also, if TSAs will be subject to formal evaluation "torture" 
> then the less
> services and complications they include the less the torture 
> will be. Both
> uses of the private key, time-stamp signing and certificate 
> signing, will
> need to be evaluated.
> 
> 
> Regards,
> 
> Simon.
> 
> 

Reply-To: "Farrukh Ahmad" <[email-masked]>
From: "Farrukh Ahmad" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: certification for pki
Date: Thu, 22 Jun 2000 12:34:54 +0100
Organization: Baltimore Technology (UK) Ltd

FYI, under the CEN/ETSI standards work currently being carried out for use
with the European Directive on Digital Signatures, trustworthy system
standards are being written which include in their annex CC PPs for CAs and
RAs. These may be used by a Certification Service Provider (CSP) issuing
Qualified Certificates for compliance assessment. A public draft will be
available sometime in September and a complete standard by the end of the
year.

Regards
Farrukh Ahmad
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 22, 2000 5:47 AM
Subject: Re: certification for pki

> [email-masked] writes:
>
> >It is not a choice of CC vs. FIPS.  The FIPS 140-1 testing pertains
> narrowly
> >to crypto modules.  The CC evaluation/"torture" process is about the
> >system/components for certificate issuance and management meeting its
> security
> >specification (security target and claimed PP(s)).
>
> Oh, so the interest is in certifying the PKI process rather than
> machinery
> which makes it possible?  In that case there's a whole host of standards
> to
> choose from, from ISO there's ISO 15782-1, Banking - Certificate
> Management,
> from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI
> Practices and
> Framework, and from vendors there's both VISA and MC's SET PKI
> requirements
> (which, while in some cases SET-specific), are well thought out.  Would
> any of
> those be usable as a PP?
>
> Peter.
>

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 11:24:15 +0200
Importance: Normal

> I'm not convinced it's bad to issue self-signed TSA certificate.
> I'm just saying it might not be a great idea.
Agree. I don't see the big advantage. For one, if I want to trust a CA I
need to go through whatever steps are appropriate. If the CA
offers/recommends/uses a TSA, it can give me a certificate for the TSA and -
having already decided to trust the CA - it is simple to verify the
certificate and decide to trust the TSA too. So what does the self-signed
TSA cert buy me besides the need to go through the trust decisions again?
Now consider revocation - do you really suggest to set up a separate
revocation-scheme for the TSA? I simply don't see any advantage here...

Peter

From: Michael Zolotarev <[email-masked]>
To: Simon McMahon <[email-masked]>, [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 18:52:47 +1000

> For an evaluated TSA I would push the self-signed 
> cert-request (or cert)
> into the Key generation operation. That way signing the 
> cert-request could
> not be classed as a form of run-time usage of the key and should not
> conflict with the intended exclusive usage (signing 
> timestamps) of the key.
> If thats what you've been saying all along then I apolagise. 
> You would not
> be able to re-generate another self-signed cert later on 
> though. Does that
> matter ?

Well, that would probably matter when a current certificate expires and you
need to issue another certificate.
Do you mean that logical(!) definition of Key Generation operation can not
embrace re-issuing a certificate with the same value of the key? Why not? I
think we'd be able to defend it for the evaluation. It is not part of the
run-time usage (a tick box here), the key was not compromised (a tick box
here), a new certificate is issued following the same (already evaluated)
procedure as the very first one (a tick box here).
Do not think it would be a problem, in general.

> 
> BTW The steps now become :
> 
> a.    Key generation - output self-signed cert-request (or 
> cert) and private
> key pair.
> b.    Secure private key storage.
> c.    Cert-request (or cert) distribution.
> d.    Private key usage - input validation & signing.
> 
> Regards,
> 
> Simon.
> 
> 

From: "Simon McMahon" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 18:28:08 +1000

>
> Ok, lets go for it:
> 1. Self-signed TSA cert. You have to evaluate your secure signing
> environment. Which is the same for generating timestamps and for
generation
> a self-signed cert.
> 2. Not self-signed TSA cert. You have to evaluate your secure timestamp
> signing environment AND whatever mechanism you (or whoever else) employed
to
> issue TSA a certificate.

In both cases you will have to evaluate.
a.    Key generation - Output public key and private key pair.
b.    Secure private key storage.
c.    Public key distribution.
d.    Private key usage - input validation & signing.

a & b are the same for TSA types 1 & 2.

c1 - Public key goes into a cert encoding and is signed by the private key
(uses d1).
d1 - Sign timestamps, and sign encoded cert (from c1).

c2 - Public key goes to evaluated CA for cert encoding and distribution.
d2 - Sign timestamps.

I would suspect that type 1 TSAs will also have to support having their
public key certified by a CA which means that c2 applies to them also. A
type 2 TSA would not need c1.

just received :
> And yet another argument (as shyly suggested by Stephen Farrell) - in
order
> to get a TSA certificate from a CA, you may have to (as an obedient PKIX
> follower) sign the request (P-O-P stuff). Which means that the key, which
is
> otherwise 100% pure timestamping, will be still used for non-timestamping
> purpose. We are not going to prohibit the mechanism of POP, are we?

You are right. That means c2 includes generating a cert request and d2
includes self-signing the encoded cert request. The only difference now is
that type 2 TSAs includes self-signed certificate request encodings and type
1 includes them and self-signed certificate encodings also.

For an evaluated TSA I would push the self-signed cert-request (or cert)
into the Key generation operation. That way signing the cert-request could
not be classed as a form of run-time usage of the key and should not
conflict with the intended exclusive usage (signing timestamps) of the key.
If thats what you've been saying all along then I apolagise. You would not
be able to re-generate another self-signed cert later on though. Does that
matter ?

BTW The steps now become :

a.    Key generation - output self-signed cert-request (or cert) and private
key pair.
b.    Secure private key storage.
c.    Cert-request (or cert) distribution.
d.    Private key usage - input validation & signing.

Regards,

Simon.

Date: Thu, 22 Jun 2000 10:12:00 +0200
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

Michael Zolotarev wrote:

> > That there has been at least one point of time where your TSA hardware
> > crypto module has been able to sign something that is not a
> > time-stamp.
>
> If we forget for a moment about what the draft says (please): what is wrong
> with using a TSA key for signing 'something that is not a time-stamp'? I do
> not see anything criminal about that. Especially if the case is well-defined
> and justified.

Maybe I did not express myself clearly enough.

I'm not convinced it's bad to issue self-signed TSA certificate.
I'm just saying it might not be a great idea.

I sure did not analyse the implication of that in every detail, and especially
the inconvenience not being able to issue self-signed certificate.

>From what you say, it looks like it should be allowed, and then up to every TSA
operator to design his own policy with regard to using this possibility or not.

From: Michael Zolotarev <[email-masked]>
To: Simon McMahon <[email-masked]>, Jean-Marc Desperrier <[email-masked]>, [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 17:03:46 +1000

And yet another argument (as shyly suggested by Stephen Farrell) - in order
to get a TSA certificate from a CA, you may have to (as an obedient PKIX
follower) sign the request (P-O-P stuff). Which means that the key, which is
otherwise 100% pure timestamping, will be still used for non-timestamping
purpose. We are not going to prohibit the mechanism of POP, are we?

M

> -----Original Message-----
> From: Simon McMahon [mailto:[email-masked]]
> Sent: Thursday, June 22, 2000 12:51 PM
> To: Michael Zolotarev; Jean-Marc Desperrier; [email-masked]
> Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> Michael wrote:
> >
> > If we forget for a moment about what the draft says 
> (please): what is
> wrong
> > with using a TSA key for signing 'something that is not a 
> time-stamp'? I
> do
> > not see anything criminal about that. Especially if the case is
> well-defined
> > and justified.
> >
> The draft obviously said it for a reason but to answer "what is wrong
> with using a TSA key for signing 'something that is not a 
> time-stamp'?"
> 
> 1.    Its good security policy to restrict usage of 
> particularly sensitive
> keys.
> 
> The ultimate restriction is one exclusive use which is the 
> state of the
> draft now.
> You should show a very good reason to weaken that or show that the new
> usage has negligable impact. If you do this then an attack on 
> certificate
> signing keys will be useful as an attack on time-stamp 
> signing keys since
> time-stamp signing keys can also sign certificates.
> 
> 2.    It couples the primary TSA service (making timestamps) with a CA
>         service (making certificates).
> 
> I'm not sure that the intention is for TSAs to always be CAs 
> or vice versa.
> If CAs and TSAs will be operated, managed and owned seperately then it
> is good that their services are not too coupled or intertwined.
> 
> Also, if TSAs will be subject to formal evaluation "torture" 
> then the less
> services and complications they include the less the torture 
> will be. Both
> uses of the private key, time-stamp signing and certificate 
> signing, will
> need to be evaluated.
> 
> 
> Regards,
> 
> Simon.
> 
> 

From: Michael Zolotarev <[email-masked]>
To: Simon McMahon <[email-masked]>, Jean-Marc Desperrier <[email-masked]>, [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 14:06:28 +1000

> 
> Michael wrote:
> >
> > If we forget for a moment about what the draft says 
> (please): what is
> wrong
> > with using a TSA key for signing 'something that is not a 
> time-stamp'? I
> do
> > not see anything criminal about that. Especially if the case is
> well-defined
> > and justified.
> >
> The draft obviously said it for a reason but to answer "what is wrong
> with using a TSA key for signing 'something that is not a 
> time-stamp'?"
> 
> 1.    Its good security policy to restrict usage of 
> particularly sensitive
> keys.
> 
Use a TSA key for signing timestamps and for signing a TSA's own certificate
is still within well-defined and restricted scope of use. The use of the key
IS STILL WELL RESTRICTED.

> The ultimate restriction is one exclusive use which is the 
> state of the
> draft now.
> You should show a very good reason to weaken that

Self-signed TSA cert is a very good reason to me.

> or show that the new usage has negligable impact. If you do this then an
attack on 
> certificate signing keys will be useful as an attack on time-stamp 
> signing keys since time-stamp signing keys can also sign certificates.

Do you mean that using a particular key to produce N signatures (timestamps)
as compared to producing N+1 signatures (timestamps and a self-signed TSA
cert) makes an attack any easier? I doubt it.

> 
> 2.    It couples the primary TSA service (making timestamps) with a CA
>         service (making certificates).
> 

Do not agree here. Issuing a self-signed cert by no means makes an entity a
CA. TSA does not become a CA, and it does not need to become one, simply for
the fact that it has a self-signed cert. No no no :).

> I'm not sure that the intention is for TSAs to always be CAs 
> or vice versa.
> If CAs and TSAs will be operated, managed and owned seperately then it
> is good that their services are not too coupled or intertwined.
> 
> Also, if TSAs will be subject to formal evaluation "torture" 
> then the less
> services and complications they include the less the torture 
> will be. Both
> uses of the private key, time-stamp signing and certificate 
> signing, will
> need to be evaluated.

Ok, lets go for it:
1. Self-signed TSA cert. You have to evaluate your secure signing
environment. Which is the same for generating timestamps and for generation
a self-signed cert.
2. Not self-signed TSA cert. You have to evaluate your secure timestamp
signing environment AND whatever mechanism you (or whoever else) employed to
issue TSA a certificate.

What is easier? (1) is sure looks simpler to me.

Regards
Michael

> Regards,
> Simon.

Date: Wed, 21 Jun 2000 22:48:08 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: certification for pki
Cc: [email-masked], [email-masked], [email-masked]

<html>
Please take a look at the protection profiles being proposed by
SPYRUS.&nbsp; You can find them at
<a href="http://www.spyrus.com/documents/cims" eudora="autourl">http://www.spyrus.com/documents/</a><a href="http://www.spyrus.com/documents/cims" eudora="autourl">cims</a>.&nbsp;
We have released the Level 3 profile to ANSI X9 as a strawman for a
financial industry protection profile.<br>
<br>
Russ<br>
<br>
At 12:09 PM 06/21/2000 -0400, [email-masked] wrote:<br>
<br>
<font size=2><blockquote type=cite cite>Gene,</font> <br>
<br>
<font size=2>However, the major drawback with the Certificate Issuing and
Management Component (CIMC) Protection Profile (PP) sponsored/created by
the (US) National Institute of Science and Technology (NIST) is that the
current version still specifies about 25 new security functional
requirements (SFRs) that are NOT included in the Common Criteria (CC)/ISO
15408 instead of using the refinement and/or the iteration operations on
existing CC security functional requirements.<br>
</font><br>
In addition, all these additional security functional requirements from
the NIST CIMC PP would probably not be recognised through the mutual
recognition arrangement (MRA).<br>
<br>
Francois <br>
<font size=2>___________________________________</font> <br>
<font size=2>Francois Rousseau</font> <br>
<font size=2>Director of Standards and Conformance</font> <br>
<font size=2>Chrysalis-ITS</font> <br>
<font size=2>1688 Woodward Drive</font> <br>
<font size=2>Ottawa, Ontario, CANADA, K2C 3R7</font> <br>
<font size=2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Tel. (613) 723-5076 ext. 419</font> <br>
<font size=2><a href="http://www.chrysalis-its.com">http://www.chrysalis-its.com</a>&nbsp;&nbsp;&nbsp;&nbsp;
Fax. (613) 723-5078</font> <br>
<br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: [email-masked]
[<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</font>
<br>
<font size=2>Sent: Wednesday, June 21, 2000 10:23 AM</font> <br>
<font size=2>To: [email-masked]</font> <br>
<font size=2>Cc: [email-masked]</font> <br>
<font size=2>Subject: Re: certification for pki</font> <br>
<br>
<font size=2>One internationally recognized avenue is an evaluation under
the Common</font> <br>
<font size=2>Criteria/ISO 15408.&nbsp; Such an evaluation up to EAL4 is
automatically recognized</font> <br>
<font size=2>by the (currently) nine mutual recognition arrangement
countries.&nbsp; Two current</font> <br>
<font size=2>problems are (1) that the CC itself does not contain a
crypto module evaluation</font> <br>
<font size=2>standard such as FIPS 140-1/2, and (2) there is not yet a
consensus and</font> <br>
<font size=2>evaluated Protection Profile for PKI components.&nbsp;&nbsp;
Some product vendors have</font> <br>
<font size=2>undertanen evaluations without PPs.&nbsp; FIPS 140-1 is
officially US/Canada, but</font> <br>
<font size=2>also widely recognized.</font> <br>
<br>
<font size=2>There is a maturing draft PP sponsored/created by the (US)
National Institute of</font> <br>
<font size=2>Science and Technology,&nbsp; which offers a selection of
four levels of assurance</font> <br>
<font size=2>for certificate issuing and management components
(CIMC).&nbsp; See</font> <br>
<font size=2><a href="http://csrc.nist.gov/pki/documents/">http://csrc.nist.gov/pki/documents/</a>.&nbsp;
For specific crypto module validation, it</font> <br>
<font size=2>references FIPS 140-1, but also includes all the other
system security funcional</font> <br>
<font size=2>and assurance requirements appropriate to CIMC.</font> 
<br>
<br>
<font size=2>-Gene Hilborn</font> <br>
<br>
<font size=2>[email-masked] on 06/21/2000 06:00:06 AM</font> <br>
<br>
<font size=2>To:&nbsp;&nbsp; [email-masked]</font> <br>
<font size=2>cc:&nbsp;&nbsp;&nbsp; (bcc: Gene Hilborn/DEF/CSC)</font> <br>
<font size=2>Subject:&nbsp; certification for pki</font> <br>
<br>
<font size=2>Hi,</font> <br>
<br>
<font size=2>Is there any internationally accredited certification for PKI</font> <br>
<br>
<font size=2>Jean</font> </blockquote></html>

From: "Simon McMahon" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 12:51:06 +1000

Michael wrote:
>
> If we forget for a moment about what the draft says (please): what is
wrong
> with using a TSA key for signing 'something that is not a time-stamp'? I
do
> not see anything criminal about that. Especially if the case is
well-defined
> and justified.
The draft obviously said it for a reason but to answer "what is wrong
with using a TSA key for signing 'something that is not a time-stamp'?"

1.    Its good security policy to restrict usage of particularly sensitive
keys.

The ultimate restriction is one exclusive use which is the state of the
draft now.
You should show a very good reason to weaken that or show that the new
usage has negligable impact. If you do this then an attack on certificate
signing keys will be useful as an attack on time-stamp signing keys since
time-stamp signing keys can also sign certificates.

2.    It couples the primary TSA service (making timestamps) with a CA
        service (making certificates).

I'm not sure that the intention is for TSAs to always be CAs or vice versa.
If CAs and TSAs will be operated, managed and owned seperately then it
is good that their services are not too coupled or intertwined.

Also, if TSAs will be subject to formal evaluation "torture" then the less
services and complications they include the less the torture will be. Both
uses of the private key, time-stamp signing and certificate signing, will
need to be evaluated.

Regards,

Simon.

From: Michael Zolotarev <[email-masked]>
To: Jeff Davis <[email-masked]>, [email-masked]
Subject: RE: Private Key Cloning
Date: Thu, 22 Jun 2000 10:18:30 +1000

Jeff wrote:
> The whole idea of having a private key is just that, it is 
> private to a
> single entity and not shared across many other "clones" of 
> that entity.
> 
> IMHO, and it is very "H" in this case, cloning a private key, of any
> nature, is opening yourselves up to all sorts of repudiation 
> claims.  If
> you clone once what stops you cloning "n" times without  
> anyone knowing
> ( regardless of what procedures you have in place ).  Part of 
> the basis
> of "trust" is that a private key only exists in one place under the
> strict control of the owner of that key.

The cloning procedure becomes a critical part, I agree. So the authority
would have to certify both the security/procedures of its operational
environment, and the security/procedures of key cloning. The same scale of
precautions that currently applies to keeping the [only and single] key
secure would apply to the cloning process. If you suspect that the cloning
may allow a criminal-minded high-privileged insider to perpetrate a fraud,
then for the same reason your should similarly suspect any other security
aspects of the authority operations.

We must always consider every particular case of key cloning, instead of
dismissing the whole concept. If a particular cloning procedure, executed by
a particular authority, using given hardware, in a particular secure
environment etc etc can be formally certified as being sufficiently secure,
at least not less(!) secure than the rest of the solution - what is wrong
with it?

If you can prove that your solution is secure - that would be just fine. Why
reject the approach on the basis that it MAY present a security hole.
Following that logic, whole PKI would be extinct by now.

> 
> I support the views put forward that maybe the TSA root should sign
> certificates  for level 1 TSA Agents, of which there could be 
> as many as
> required, but all of whom have a different DN ( very closely 
> associated
> with the parent TSA ).  The trust of the Time Stamp would then be
> through a normal certificate chain and that only being 1 level.  Maybe
> the TSA root could then go offline leaving the "work horses" 
> to perform
> the stamping.  Re-issuing of new TSA signing keys would then be quite
> easy for each Agent, with only 1 out of "n" Agents being 
> offline at any
> one time, update the hardware signing module and get back online
> a.s.a.p.
> 
> I may be well off the mark here, if so, just tell me to shut 
> up and get
> back in the cupboard.  However, as I am trying to learn this stuff, a
> little help with my waywardness would go a long way.
> 
I'm also new to the house. But I've learned that there are two words missing
in the group's dictionary - "beautiful" and "shut up". Three words, actually
:)

M

From: Michael Zolotarev <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>, [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 09:45:26 +1000

> 
> But from a practical point of view what does self-signed TSA 
> cert means?
> That there has been at least one point of time where your TSA hardware
> crypto module has been able to sign something that is not a 
> time-stamp.

If we forget for a moment about what the draft says (please): what is wrong
with using a TSA key for signing 'something that is not a time-stamp'? I do
not see anything criminal about that. Especially if the case is well-defined
and justified.
Please do not mistake this with signing a timestamp with a 'wrong' key. That
would be just too bad.

> I think that if a TSA is under a formal evaluation process, 
> it will have to prove it's "impossible" to get it to sign something that
is not a
> valid time stamp.

Considering what I said above, we won't have to prove it at all.

> 
> Of course, the signing of this certificate would be done in an initial
> step, before the hardware crypto module is inserted inside the actual
> TSA operation process, but it does not sound that great.
> Also couldn't there be circonstances, where we would have to 
> generate a
> new certificate, if the policy changes, etc... ?
> 
Under those circumstances a new key would need to be generated, most likely.

Michael

From: Michael Zolotarev <[email-masked]>
To: Peter Lipp <[email-masked]>, Jean-Marc Desperrier <[email-masked]>, [email-masked]
Subject: RE: self-signed TSA [Was Re: Private Key Cloning]
Date: Thu, 22 Jun 2000 09:21:13 +1000

I see. But do you think that the requirement should be loosen up a bit, in
order to accommodate self-signed certificates?

> -----Original Message-----
> From: Peter Lipp [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2000 10:24 PM
> To: Michael Zolotarev; Jean-Marc Desperrier; [email-masked]
> Subject: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> > However, it does NOT necessarily say that the same
> > 'timestamping' key can not be used for signing whatever else, for
> > example a certificate.
> 
> Looking at the current draft it sais:
> 
> A TSA is REQUIRED ...
> 10. 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.
> 
> I read "exclusively for this purpose" as "not allowed for signing
> certificates".
> 
> Peter
> 
> 
> 

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Wed, 21 Jun 2000 14:42:12 -0400
Subject: RE: certification for pki

--0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I apologize to the pkix list if the following is getting to be too off-topic,
and would be happy to take it off list if anyone wishes.

Francois,

I agree generally with your critique of NIST's draft CIMC PP, in the sense that
its authors probably made over-liberal use of creating new security functional
requirements that are not in the CC, rather than using the SFRs available.  They
probably could have done a much better job of using the existing SFRs with
creative use of legitimate operations (selection, assignment, iteration, and
refinement).

However, I disagree with the statement that "all these additional requirements
would probably not be recognized through the mutual recognition."  The MRA
http://niap.nist.gov/cc-scheme/DownloadCCMRA.html  does not recognize
"requirements;" it does recognize CC evaluation certificates for PPs and IT
products evaluated under the member national schemes.

A proper use of custom or "explicit" SFRs and/or security assurance requirements
(SARs) is most definitely provided for in the CC.  For example, in CC part 1
paragraph 5.2 we have:

"The CC recognizes the possibility that functional and assurance requirements
not
included in the provided catalogues may be required in order to represent the
complete set of IT security requirements. The following shall apply to the
inclusion
of these extended functional or assurance requirements: ..."

The exact CC requirements for SFR/SAR extension in a PP are further elaborated
in the Annex B Specification of Protection Profiles.

If done properly and justified in the PP/ST rationale, the use of
explicit/extended SFRs in no way invalidates a PP or product evaluation.  The
PP/ST author does have the burden of justifying the use of any explicit
(extended) requirements (which IMO the CIMC PP authors have failed to do in the
current draft).  Once a PP (even with explicit SFRs) has been successfully
evaluated under one of the national schemes it's evaluation will be mutually
recognized.  Once a product with an ST claiming compliance to such a PP has been
successfully evaluated under one of the national schemes it's evaluation will be
mutually recognized.
-GH

[email-masked] on 06/21/2000 12:09:18 PM

To:   Gene Hilborn/DEF/CSC@CSC
cc:   [email-masked], [email-masked]
Subject:  RE: certification for pki

Gene,

However, the major drawback with the Certificate Issuing and Management
Component (CIMC) Protection Profile (PP) sponsored/created by the (US)
National Institute of Science and Technology (NIST) is that the current
version still specifies about 25 new security functional requirements (SFRs)
that are NOT included in the Common Criteria (CC)/ISO 15408 instead of using
the refinement and/or the iteration operations on existing CC security
functional requirements.

In addition, all these additional security functional requirements from the
NIST CIMC PP would probably not be recognised through the mutual recognition
arrangement (MRA).

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 21, 2000 10:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: certification for pki

One internationally recognized avenue is an evaluation under the Common
Criteria/ISO 15408.  Such an evaluation up to EAL4 is automatically
recognized
by the (currently) nine mutual recognition arrangement countries.  Two
current
problems are (1) that the CC itself does not contain a crypto module
evaluation
standard such as FIPS 140-1/2, and (2) there is not yet a consensus and
evaluated Protection Profile for PKI components.   Some product vendors have
undertanen evaluations without PPs.  FIPS 140-1 is officially US/Canada, but
also widely recognized.

There is a maturing draft PP sponsored/created by the (US) National
Institute of
Science and Technology,  which offers a selection of four levels of
assurance
for certificate issuing and management components (CIMC).  See
http://csrc.nist.gov/pki/documents/.  For specific crypto module validation,
it
references FIPS 140-1, but also includes all the other system security
funcional
and assurance requirements appropriate to CIMC.

-Gene Hilborn

[email-masked] on 06/21/2000 06:00:06 AM

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  certification for pki

Hi,

Is there any internationally accredited certification for PKI

Jean

--0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-transfer-encoding: base64
Content-Description: Internet HTML

--0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs--

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Wed, 21 Jun 2000 14:27:10 -0400
Subject: Re: certification for pki

Peter,
I said nothing about "certifying the PKI process."  Rather I spoke of the
process of certifying the products  (CC and FIPS).
-Gene

[email-masked] on 06/22/2000 12:47:52 AM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: certification for pki

[email-masked] writes:

>It is not a choice of CC vs. FIPS.  The FIPS 140-1 testing pertains narrowly
>to crypto modules.  The CC evaluation/"torture" process is about the
>system/components for certificate issuance and management meeting its security
>specification (security target and claimed PP(s)).

Oh, so the interest is in certifying the PKI process rather than machinery
which makes it possible?  In that case there's a whole host of standards to
choose from, from ISO there's ISO 15782-1, Banking - Certificate Management,
from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices and
Framework, and from vendors there's both VISA and MC's SET PKI requirements
(which, while in some cases SET-specific), are well thought out.  Would any of
those be usable as a PP?

Peter.

From: "Morrill, Dan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: certification for pki
Date: Wed, 21 Jun 2000 10:04:13 -0700

I don't suppose that out there on the net or in committee, there is one
unifying document to take care of both the PKI process and the machinery
that it is stored on as a mutually agreed upon set of standards? If not,
maybe it would be good for this panel to make one?

Just a thought.
r/
Dan Morrill
CSC

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 21, 2000 09:48 PM
To: [email-masked]
Subject: Re: certification for pki

[email-masked] writes:

>It is not a choice of CC vs. FIPS.  The FIPS 140-1 testing pertains
narrowly
>to crypto modules.  The CC evaluation/"torture" process is about the
>system/components for certificate issuance and management meeting its
security
>specification (security target and claimed PP(s)).

Oh, so the interest is in certifying the PKI process rather than machinery
which makes it possible?  In that case there's a whole host of standards to
choose from, from ISO there's ISO 15782-1, Banking - Certificate Management,
from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices
and
Framework, and from vendors there's both VISA and MC's SET PKI requirements
(which, while in some cases SET-specific), are well thought out.  Would any
of
those be usable as a PP?

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: certification for pki
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 22 Jun 2000 04:47:52 (NZST)

[email-masked] writes:

>It is not a choice of CC vs. FIPS.  The FIPS 140-1 testing pertains narrowly
>to crypto modules.  The CC evaluation/"torture" process is about the
>system/components for certificate issuance and management meeting its security
>specification (security target and claimed PP(s)).

Oh, so the interest is in certifying the PKI process rather than machinery
which makes it possible?  In that case there's a whole host of standards to
choose from, from ISO there's ISO 15782-1, Banking - Certificate Management,
from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices and
Framework, and from vendors there's both VISA and MC's SET PKI requirements
(which, while in some cases SET-specific), are well thought out.  Would any of
those be usable as a PP?

Peter.

Date: Wed, 21 Jun 2000 09:31:04 -0700
From: Mack Hicks <[email-masked]>
Subject: Re: certification for pki
To: [email-masked]
Cc: [email-masked]

GH,

As a "consumer", a banking business, of these products and services -- and as one
who is also deploying into the marketplace, I do demand some testing and review. I
also ask how much all this security is costing, and what risks are being minimized
or eliminated.

What I do NOT demand is the use of a "military threat" model in a commercial
context. I define "military threat" as "a fault in security could ultimately lead to
nuclear war - so no faults are allowed".  What I mean is that most of the
evaluations and criteria I have seen, like the AICPA draft and the ANSI X9.79 draft,
are regarding risks as if they cannot be commercially controlled.  To this end, Bank
of America has voted "NO" on the first round of balloting for ANSI X9.79, and I
encourage all other ANSI members to do the same.

I mention this in the context of the mailing list discussion on private key cloning
for commercial servers. Given budget constraints and the cost of the cryptographic
hardware - not to mention the operational costs and customer (client) impact - there
is no choice but to have some cloning and/or key backup of server signing keys.
These keys are just too important to business flow to leave to a single location or
piece of hardware.

Admittedly, when one is acting in a position of trust for other organizations, care
must be exercised - but it must be compatible and commensurate with the risk
involved - not just to the risk to the keys but much more importantly - to the
on-going operation of our customer's business.

Further, when key management hardware is deployed to commercial servers that are not
under bank security guidelines (like we do with credit card merchants today), there
is an even greater need for resilience and key backup. The cost of hardware
replication or the cost of business interruption (for rekeying and certification) is
too high for the associated risk and perceived security benefit.

[email-masked] wrote:

> ... It may be
> "torture" for the manufacturer, but when the market (or laws, regulations, etc.)
> demand it, manufacturers do it.
> -GH

-------------------------------------------------
Mack Hicks, SVP     [email-masked]
Bank of America  +1-415-436-5809

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: certification for pki
Date: Wed, 21 Jun 2000 12:09:18 -0400

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

------_=_NextPart_001_01BFDB9B.166638B8
Content-Type: text/plain;
	charset="iso-8859-1"

Gene,

However, the major drawback with the Certificate Issuing and Management
Component (CIMC) Protection Profile (PP) sponsored/created by the (US)
National Institute of Science and Technology (NIST) is that the current
version still specifies about 25 new security functional requirements (SFRs)
that are NOT included in the Common Criteria (CC)/ISO 15408 instead of using
the refinement and/or the iteration operations on existing CC security
functional requirements.

In addition, all these additional security functional requirements from the
NIST CIMC PP would probably not be recognised through the mutual recognition
arrangement (MRA).

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 21, 2000 10:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: certification for pki

One internationally recognized avenue is an evaluation under the Common
Criteria/ISO 15408.  Such an evaluation up to EAL4 is automatically
recognized
by the (currently) nine mutual recognition arrangement countries.  Two
current
problems are (1) that the CC itself does not contain a crypto module
evaluation
standard such as FIPS 140-1/2, and (2) there is not yet a consensus and
evaluated Protection Profile for PKI components.   Some product vendors have
undertanen evaluations without PPs.  FIPS 140-1 is officially US/Canada, but
also widely recognized.

There is a maturing draft PP sponsored/created by the (US) National
Institute of
Science and Technology,  which offers a selection of four levels of
assurance
for certificate issuing and management components (CIMC).  See
http://csrc.nist.gov/pki/documents/.  For specific crypto module validation,
it
references FIPS 140-1, but also includes all the other system security
funcional
and assurance requirements appropriate to CIMC.

-Gene Hilborn

[email-masked] on 06/21/2000 06:00:06 AM

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  certification for pki

Hi,

Is there any internationally accredited certification for PKI

Jean

------_=_NextPart_001_01BFDB9B.166638B8
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.2650.12">
<TITLE>RE: certification for pki</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Gene,</FONT>
</P>

<P><FONT SIZE=3D2>However, the major drawback with the Certificate =
Issuing and Management Component (CIMC) Protection Profile (PP) =
sponsored/created by the (US) National Institute of Science and =
Technology (NIST) is that the current version still specifies about 25 =
new security functional requirements (SFRs) that are NOT included in =
the Common Criteria (CC)/ISO 15408 instead of using the refinement =
and/or the iteration operations on existing CC security functional =
requirements.</FONT></P>

<P><FONT SIZE=3D2>In addition, all these additional security functional =
requirements from the NIST CIMC PP would probably not be recognised =
through the mutual recognition arrangement (MRA).</FONT></P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, June 21, 2000 10:23 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: certification for pki</FONT>
</P>

<P><FONT SIZE=3D2>One internationally recognized avenue is an =
evaluation under the Common</FONT>
<BR><FONT SIZE=3D2>Criteria/ISO 15408.&nbsp; Such an evaluation up to =
EAL4 is automatically recognized</FONT>
<BR><FONT SIZE=3D2>by the (currently) nine mutual recognition =
arrangement countries.&nbsp; Two current</FONT>
<BR><FONT SIZE=3D2>problems are (1) that the CC itself does not contain =
a crypto module evaluation</FONT>
<BR><FONT SIZE=3D2>standard such as FIPS 140-1/2, and (2) there is not =
yet a consensus and</FONT>
<BR><FONT SIZE=3D2>evaluated Protection Profile for PKI =
components.&nbsp;&nbsp; Some product vendors have</FONT>
<BR><FONT SIZE=3D2>undertanen evaluations without PPs.&nbsp; FIPS 140-1 =
is officially US/Canada, but</FONT>
<BR><FONT SIZE=3D2>also widely recognized.</FONT>
</P>

<P><FONT SIZE=3D2>There is a maturing draft PP sponsored/created by the =
(US) National Institute of</FONT>
<BR><FONT SIZE=3D2>Science and Technology,&nbsp; which offers a =
selection of four levels of assurance</FONT>
<BR><FONT SIZE=3D2>for certificate issuing and management components =
(CIMC).&nbsp; See</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://csrc.nist.gov/pki/documents/" =
TARGET=3D"_blank">http://csrc.nist.gov/pki/documents/</A>.&nbsp; For =
specific crypto module validation, it</FONT>
<BR><FONT SIZE=3D2>references FIPS 140-1, but also includes all the =
other system security funcional</FONT>
<BR><FONT SIZE=3D2>and assurance requirements appropriate to =
CIMC.</FONT>
</P>

<P><FONT SIZE=3D2>-Gene Hilborn</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>[email-masked] on 06/21/2000 06:00:06 =
AM</FONT>
</P>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; [email-masked]</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp;&nbsp; (bcc: Gene =
Hilborn/DEF/CSC)</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; certification for pki</FONT>
</P>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Is there any internationally accredited certification =
for PKI</FONT>
</P>

<P><FONT SIZE=3D2>Jean</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFDB9B.166638B8--

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Wed, 21 Jun 2000 11:47:39 -0400
Subject: Re: certification for pki

It is not a choice of CC vs. FIPS.  The FIPS 140-1 testing pertains narrowly to
crypto modules.  The CC evaluation/"torture" process is about the
system/components for certificate issuance and management meeting its security
specification (security target and claimed PP(s)).  A crypto module is just an
embedded "engine" in the larger vehicle.   To continue with the automotive
metaphor, it is not a choice between auto emission testing vs. crash testing vs.
fuel economy vs. performance testing, etc.  All of these tests may be required
for the consumer to understand and compare what they are buying.  It may be
"torture" for the manufacturer, but when the market (or laws, regulations, etc.)
demand it, manufacturers do it.
-GH

[email-masked] on 06/21/2000 11:11:43 PM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: certification for pki

[email-masked] writes:

>One internationally recognized avenue is an evaluation under the Common
>Criteria/ISO 15408.  Such an evaluation up to EAL4 is automatically recognized
>by the (currently) nine mutual recognition arrangement countries.  Two current
>problems are (1) that the CC itself does not contain a crypto module
>evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus
>and evaluated Protection Profile for PKI components.   Some product vendors
>have undertanen evaluations without PPs.  FIPS 140-1 is officially US/Canada,
>but also widely recognized.

A third problem with the CC, for those who haven't experienced it before, is
that it acts as a form of torture for companies to determine how badly they
need government (or whatever) contracts - the more pain you can stand, the
better you've demonstrated that you need the contract.  I'm not just saying
this for $generic_CC_bashing, from talking to people who have gone through it
it really sounds like an incredibly unpleasant experience (when I used the term
"torture" to describe it above this doesn't originate with me but with the
people I talked to).  In terms of achieving more or less the same effect (the
certification that is, not the torture :-) it looks like FIPS 140 is the easier
path, and it does constitute a de facto PP which the CC doesn't have yet.  I'd
go with FIPS 140.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: certification for pki
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 22 Jun 2000 03:11:43 (NZST)

[email-masked] writes:

>One internationally recognized avenue is an evaluation under the Common
>Criteria/ISO 15408.  Such an evaluation up to EAL4 is automatically recognized
>by the (currently) nine mutual recognition arrangement countries.  Two current
>problems are (1) that the CC itself does not contain a crypto module
>evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus
>and evaluated Protection Profile for PKI components.   Some product vendors
>have undertanen evaluations without PPs.  FIPS 140-1 is officially US/Canada,
>but also widely recognized.

A third problem with the CC, for those who haven't experienced it before, is
that it acts as a form of torture for companies to determine how badly they
need government (or whatever) contracts - the more pain you can stand, the
better you've demonstrated that you need the contract.  I'm not just saying
this for $generic_CC_bashing, from talking to people who have gone through it
it really sounds like an incredibly unpleasant experience (when I used the term
"torture" to describe it above this doesn't originate with me but with the
people I talked to).  In terms of achieving more or less the same effect (the
certification that is, not the torture :-) it looks like FIPS 140 is the easier
path, and it does constitute a de facto PP which the CC doesn't have yet.  I'd
go with FIPS 140.

Peter.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Wed, 21 Jun 2000 10:37:13 -0400

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

------_=_NextPart_001_01BFDB8E.391CBF4C
Content-Type: text/plain;
	charset="iso-8859-1"

Jean-Marc Desperrier wrote:

[snip]
>
> Also couldn't there be circonstances, where we would have to
> generate a new certificate, if the policy changes, etc... ?

In addition, a TSA private key would eventually expire.

When a TSA using a self-signed certificate has to update its key pair, would
it also have to generate three (3) certificates (i.e. the OldWithNew,
NewWithOld and NewWithNew TSA certificates) as per Section 2.4 of RFC 2510?

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

------_=_NextPart_001_01BFDB8E.391CBF4C
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.2650.12">
<TITLE>RE: AW: self-signed TSA [Was Re: Private Key Cloning]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jean-Marc Desperrier wrote:</FONT>
</P>

<P><FONT SIZE=3D2>[snip]</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Also couldn't there be circonstances, where we =
would have to</FONT>
<BR><FONT SIZE=3D2>&gt; generate a new certificate, if the policy =
changes, etc... ?</FONT>
</P>

<P><FONT SIZE=3D2>In addition, a TSA private key would eventually =
expire.</FONT>
</P>

<P><FONT SIZE=3D2>When a TSA using a self-signed certificate has to =
update its key pair, would it also have to generate three (3) =
certificates (i.e. the OldWithNew, NewWithOld and NewWithNew TSA =
certificates) as per Section 2.4 of RFC 2510?</FONT></P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFDB8E.391CBF4C--

From: "Jeff Davis" <[email-masked]>
To: <[email-masked]>
Subject: Re: Private Key Cloning
Date: Wed, 21 Jun 2000 15:25:29 +0100

Hi,

Being new to this group I would just like to add my 0.00001c ( or
pennies in my case ) worth to this discussion.

The whole idea of having a private key is just that, it is private to a
single entity and not shared across many other "clones" of that entity.

IMHO, and it is very "H" in this case, cloning a private key, of any
nature, is opening yourselves up to all sorts of repudiation claims.  If
you clone once what stops you cloning "n" times without  anyone knowing
( regardless of what procedures you have in place ).  Part of the basis
of "trust" is that a private key only exists in one place under the
strict control of the owner of that key.

I support the views put forward that maybe the TSA root should sign
certificates  for level 1 TSA Agents, of which there could be as many as
required, but all of whom have a different DN ( very closely associated
with the parent TSA ).  The trust of the Time Stamp would then be
through a normal certificate chain and that only being 1 level.  Maybe
the TSA root could then go offline leaving the "work horses" to perform
the stamping.  Re-issuing of new TSA signing keys would then be quite
easy for each Agent, with only 1 out of "n" Agents being offline at any
one time, update the hardware signing module and get back online
a.s.a.p.

I may be well off the mark here, if so, just tell me to shut up and get
back in the cupboard.  However, as I am trying to learn this stuff, a
little help with my waywardness would go a long way.

Jeff

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Wed, 21 Jun 2000 10:23:09 -0400
Subject: Re: certification for pki

One internationally recognized avenue is an evaluation under the Common
Criteria/ISO 15408.  Such an evaluation up to EAL4 is automatically recognized
by the (currently) nine mutual recognition arrangement countries.  Two current
problems are (1) that the CC itself does not contain a crypto module evaluation
standard such as FIPS 140-1/2, and (2) there is not yet a consensus and
evaluated Protection Profile for PKI components.   Some product vendors have
undertanen evaluations without PPs.  FIPS 140-1 is officially US/Canada, but
also widely recognized.

There is a maturing draft PP sponsored/created by the (US) National Institute of
Science and Technology,  which offers a selection of four levels of assurance
for certificate issuing and management components (CIMC).  See
http://csrc.nist.gov/pki/documents/.  For specific crypto module validation, it
references FIPS 140-1, but also includes all the other system security funcional
and assurance requirements appropriate to CIMC.
-Gene Hilborn

[email-masked] on 06/21/2000 06:00:06 AM

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  certification for pki

Hi,

Is there any internationally accredited certification for PKI

Jean

Content-return: allowed
Date: Wed, 21 Jun 2000 07:09:26 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: Using certificates as trust anchors
To: "'Yassir Elley'" <[email-masked]>, [email-masked]

Yassir asked:

> If the trust anchor information is trusted because it
> was delivered "out-of-band", can we use non-self-signed
> certificates to provide the trust anchor information?

draft-ietf-pkix-new-part1-01.txt, section 6, paragraph 4 states:

   The "most-trusted CA" is a matter of policy: it could be a root CA in
   a hierarchical PKI; the CA that issued the verifier's own
   certificate(s); or any other CA in a network PKI.  The path valida-
   tion procedure is the same regardless of the choice of "most-trusted
   CA."

My interpretation of the above paragraph is yes, the trust anchor need not
be a self-signed root certificate, which leads me to ...

I have a difficult time comprehending section 6 of RFC 2459 and
draft-ietf-pkix-new-part1-01.txt. I believe the reason is that many terms
are used without first being clearly defined. For example, the term root CA,
in the above paragraph, appears once without being defined. The term root
certificate does not appear in draft-ietf-pkix-new-part1-01.txt. As an
aside, I would love to know how many times the terms root CA or root
certificate appear in PKIX-related implementations, either in comments or
variable names.

Is there interest in formally defining the terms used in section 6? If yes,
I would be more than willing to take a stab at defining the terms I deem
relevant, including:

certificate [Is currently defined in section 3.1.]
certificate hierarchy
root certificate
superior (or parent) certificate
subordinate (or child) certificate
self-signed certificate
trusted certificate
certificate (or certification) path [Is currently defined in section 3.2.]

Perhaps this would make it easier to for developers (such as myself) to
convert the narrative into code.

Frank

> -----Original Message-----
> From: Yassir Elley [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2000 2:45 PM
> To: [email-masked]
> Subject: Using certificates as trust anchors
> 
> 
> In looking over draft-ietf-pkix-new-part1-01.txt, a question
> arises as to how to process trust anchors provided in the
> form of a self-signed certificate. Since many applications 
> use such certificates
> as trust anchors, I think it is important for PKIX to 
> explicitly spell out how
> to process these certificates.
> 
> Section 6.1.1 describes the five pieces of trust anchor 
> information and
> mentions that the trust anchor information may be provided in the form
> of a self-signed certificate.
> 
> "(d) trust anchor information, describing a CA that serves as a
>       trust anchor for the certification path.  The trust 
> anchor infor-
>       mation includes:
>          (1) the trusted issuer name,
>          (2) optionally, the trusted issuer unique identifier,
>          (3) the trusted public key algorithm,
>          (4) the trusted public key, and
>          (5) optionally, the trusted public key parameters associated
>          with the public key.
> 
>       The trust anchor information may be provided to the 
> path process-
>       ing procedure in the form of a self-signed certificate. The
>       trusted anchor information is trusted because it was 
> delivered to
>       the path processing procedure by some trustworthy "out-of-band"
>       procedure.  If the trusted public key algorithm requires parame-
>       ters, then the parameters are provided along with the 
> trusted pub-
>       lic key."
> 
> However, in other parts of Section 6, we find that the algorithm
> also requires the validity period of the public key, as well
> as other constraints (presumably this refers to initial
> name constraints, policy constraints, basic 
> constraints[pathLenConstraint]?).
> 
> For example:
> "In section 6.1, the text describes basic path validation. This text
>    assumes that all valid paths begin with certificates 
> issued by a sin-
>    gle "most-trusted CA". The algorithm requires the public key of the
>    CA, the CA's name, the validity period of the public key, and any
>    constraints upon the set of paths which may be validated using this
>    key."
> 
> Section 6.2 also refers to making use of the certificate's extensions
> to limit the path.
>  "Limitations in the trust paths for any particular key may
>    be incorporated into the self-signed certificate's extensions. In
>    this way, the self-signed certificates permit the path validation
>    module to automatically incorporate local security policy and
>    requirements."
> 
> If the trust anchor information is provided in the form of a 
> self-signed
> certificate, we can certainly extract the five pieces of trust anchor
> information mentioned in Section 6.1.1.
> 
> Should we also be extracting other information from the certificate,
> such as policy constraints, policy mappings, name constraints, and
> basic constraints, and using these to initialize the relevant state
> variables? What about the validity period of the public key?
> Do we need to verify that the self-signed certificates's 
> validity period
> includes time T?
> 
> Do we need to validate the self-signed certificate itself?
> (i.e. do we have to verify the self-signed certificate's signature,
> revocation status, name chaining, uid chaining, that any
> certificate policies and policy mappings are processed,
> that it is a CA cert, that it has a keyCertSign key usage asserted,
> that all critical extensions are processed?)
> 
> If the trust anchor information is trusted because it
> was delivered "out-of-band", can we use non-self-signed
> certificates to provide the trust anchor information?
> Perhaps I have a certificate that is not self-signed that I
> trust for some "out-of-band" reason. I would think
> that I should be able to use this certificate as a trust anchor
> since I have designated it as trusted. If this is allowed,
> it should be noted that we will not be able to
> validate the signature, revocation status, name chaining,
> and uid chaining checks because these checks rely
> on a "previous" certificate's values which we don't have.
> 
> One approach would be to not validate any part of
> the trust anchor certificate and simply accept it
> (whether or not it is self-signed)
> because the user has designated it as "trusted", but
> to extract any relevant information. In other words,
> we wouldn't perform any of the steps in
> 6.1.3 (Basic Certificate Processing) but we would
> perform all the steps in 6.1.4 (Preparation for
> Certificate i+1).
> 
> All of these questions need to be answered explicitly
> so that we can all process trust anchor certificates in
> a standard way.
> 
> -Yassir.
> 
> 
> 
> 

Date: Wed, 21 Jun 2000 15:49:03 +0200
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

Peter Lipp wrote:

> > However, it does NOT necessarily say that the same
> > 'timestamping' key can not be used for signing whatever else, for
> > example a certificate.
>
> Looking at the current draft it says:
>
> A TSA is REQUIRED ...
> 10. 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.
>
> I read "exclusively for this purpose" as "not allowed for signing
> certificates".

I wrote another answer before, but it seems I have sent it to Michael
Zolotarev instead of to the list.

It seems that the beginning of 2.3 and point 10 of 2.2 are a rewording
of each other.

After rereading, paragraph 2.3 does not explicitely forbid keyCertSign
to be asserted, as this is a key usage bit, and not an extended
keyusage.
This said, if we take into account point 10, it sounds like this key
usage bit should not be asserted.

It would more explicit to have a list in the draft of the key usage bits
that must/musn't be asserted.

The message about the use of "certificates as trust anchor" suggests
that it should not be necessary that the key usage bitfield of a
self-signed certificate has the keyCertSign set for it to be accepted as
a trust anchor.
This seems to me to make sense.

But from a practical point of view what does self-signed TSA cert means
?
That there has been at least one point of time where your TSA hardware
crypto module has been able to sign something that is not a time-stamp.
I think that if a TSA is under a formal evaluation process, it will have
to prove it's "impossible" to get it to sign something that is not a
valid time stamp.

Of course, the signing of this certificate would be done in an initial
step, before the hardware crypto module is inserted inside the actual
TSA operation process, but it does not sound that great.
Also couldn't there be circonstances, where we would have to generate a
new certificate, if the policy changes, etc... ?

From: "Peter Lipp" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: AW: self-signed TSA [Was Re: Private Key Cloning]
Date: Wed, 21 Jun 2000 14:24:06 +0200
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.776CFB97--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> However, it does NOT necessarily say that the same
> 'timestamping' key can not be used for signing whatever else, for
> example a certificate.

Looking at the current draft it sais:

A TSA is REQUIRED ...
10. 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.

I read "exclusively for this purpose" as "not allowed for signing
certificates".

Peter

----IAIK.SMIME.MAPPER.776CFB97--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAAA
----IAIK.SMIME.MAPPER.776CFB97----

From: "Frederik Loeckx" <[email-masked]>
To: [email-masked]
Date: Wed, 21 Jun 2000 12:24:45 +0200
Subject: PKIStatusInfo inside draft-ietf-pkix-time-stamp-08.txt

Hello,

A somewhat less philosophical question as cloning keys:

Inside RFC2510bis, PKIStatusInfo is defined as
PKIStatusInfo ::= SEQUENCE {
      status        PKIStatus,
      statusString  PKIFreeText     OPTIONAL,
      failInfo      PKIFailureInfo  OPTIONAL
  }

In  draft-ietf-pkix-time-stamp-08.txt, the second field, statusString,
disappeared resulting in
PKIStatusInfo ::= SEQUENCE {
      status        PKIStatus,
      failInfo      PKIFailureInfo  OPTIONAL
  }

So I think this is a little mistake inside the time stamping draft,
especially because the statusString field is explicitly mentioned inside
the corresponding text of the draft.

Kind regards,

Frederik Loeckx

From: "Jean Abraham" <[email-masked]>
To: <[email-masked]>
Subject: certification for pki
Date: Wed, 21 Jun 2000 13:00:06 +0300
Importance: Normal

Hi,

Is there any internationally accredited certification for PKI

Jean

From: "Simon McMahon" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, <[email-masked]>, "Paul Koning" <[email-masked]>, "Juergen Brauckmann" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Private Key Cloning (TSA keys)
Date: Wed, 21 Jun 2000 19:12:10 +1000

Juergen wrote :
> As all servers that want to operate according to the German Digital
> Signature Law must issue signatures that comply with this law, it is
> relevant.
>
> We hope that a revision of the law will contain a notion of "server
> keys/certificates", so that all the things that are not appliable for
> CAs/TSAs will disappear... .
>
So perhaps SigG/SigV compliant TSAs should not attempt load balancing until
the revision to the law is released. If the revision is really likely then
wont this problem just go away ?

> ... With some tricks (mostly not technical) we can get
> around entering a PIN for every timestamp issued, but the "no copying a
> private key" issue still applies.
>
Surely this is a better approach, to use tricks to get around the
deficiencies in the law, rather than trying to accomidate it in the standard
when it gets too messy. Especially if the law is likely to be changed to
accomidate CA/TSA servers anyway.

I guess the analogy with an accelerater with controlled private key copies
within the secure perimeter was not tricky enough to convince you :-).

I know of an ITSEC evaluation with SigG/SigV compiance which argued that
copies of private keys was OK because they were made in order to move the
private key from one module to another within the secure perimieter. It
wasn't a TSA, of course, and the existance of two copies was only for an
instant before the previous copy was destroyed. We are talking about long
term persistance of multiple copies of the private key and doing signatures
with them, but as long as they stay within the target of evaluation's secure
perimeter ...

Regards,

Simon.

Date: Wed, 21 Jun 2000 09:20:12 +0200
To: "Simon McMahon" <[email-masked]>, "Michael Zolotarev" <[email-masked]>, <[email-masked]>, "Paul Koning" <[email-masked]>
From: Juergen Brauckmann <[email-masked]>
Subject: Re: Private Key Cloning (TSA keys)
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>, <[email-masked]>

At 16:08 21.06.00 +1000, Simon McMahon wrote:
>> ... But the argument has started as a result of the fact
>> that some legislations, namely German Digital Signature Law, prohibit key
>> cloning. So we've been discussing just one of the possible solutions to
>get
>> around the restrictions of the law.
>>
>Is that the SigG / SigV German signature law ?
>I thought that was more for personal private keys where authentication data
>(e.g. the PIN) is provided for EVERY signature generated by the private key
>as well as "no copying the private key". Surely that is not relevant to TSA
>servers where no one is there to enter a PIN.

Funnily it is relevant. CAs that want to operate according to SigG/SigV
have to offer a timestamping service. This is a requirement of the law.
They have to sign the timestamps with signatures that comply with that law.
The current SigG does not recognize the necessity to have server
keys/certificate, and so all restrictions to personal private keys apply to
CA/TSA operating keys. With some tricks (mostly not technical) we can get
around entering a PIN for every timestamp issued, but the "no copying a
private key" issue still applies.

>Yes, its a question of whether it is within the law, and within which
>relevant law. The german signature law that I have indirectly worked with
>was very specific but in my opinion not relevant to private keys used by
>unattended servers.

As all servers that want to operate according to the German Digital
Signature Law must issue signatures that comply with this law, it is
relevant. 

We hope that a revision of the law will contain a notion of "server
keys/certificates", so that all the things that are not appliable for
CAs/TSAs will disappear... .

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: "Simon McMahon" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, <[email-masked]>, "Paul Koning" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Private Key Cloning (TSA keys)
Date: Wed, 21 Jun 2000 16:08:45 +1000

> ... But the argument has started as a result of the fact
> that some legislations, namely German Digital Signature Law, prohibit key
> cloning. So we've been discussing just one of the possible solutions to
get
> around the restrictions of the law.
>
Is that the SigG / SigV German signature law ?
I thought that was more for personal private keys where authentication data
(e.g. the PIN) is provided for EVERY signature generated by the private key
as well as "no copying the private key". Surely that is not relevant to TSA
servers where no one is there to enter a PIN.

> I'm still not convinced, though, that the interpretation of the law is
> correct. Taking your example with accelerator - would it be regarded as a
> breach of the law? If not, and the accelerator is all right, what makes it
> dramatically different from cloning the key in the environment which can
be
> formally certified as a security-equivalent to the accelerator's?
>
Yes, its a question of whether it is within the law, and within which
relevant law. The german signature law that I have indirectly worked with
was very specific but in my opinion not relevant to private keys used by
unattended servers.

> The law is written for general use, and each particular scenario requires
> specific peruse. I'm wondering if we are trying to scare ourselves away
even
> before the law has a chance to "speak out". Would really like to hear from
> anybody who has legal expertise and can provide an interpretation of the
> German Law for that specific case.
>
That would be good but I'll be surprised if you get any. What good is legal
advice that is not based on actual case law anyway ? There are no TSA's yet
(are there ?) let alone cases regarding them ?

Using a time-stamping key to self sign TSA certificates looks a bit like a
kludge to me to fix a problem that TSA's may not even have. Surely well
defined key usage, particularly single key usage, is a good security goal to
achieve that this approach undermines.

Simon McMahon
ERACOM Pty. Ltd.

From: "Jean Abraham" <[email-masked]>
To: <[email-masked]>
Subject: 
Date: Wed, 21 Jun 2000 08:56:27 +0300
Importance: Normal

Hi,

What are the applications that does or does not support more than 4
hierachies in a digital certificate.

Jean

From: Michael Zolotarev <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>, [email-masked]
Subject: RE: self-signed TSA [Was Re: Private Key Cloning]
Date: Wed, 21 Jun 2000 15:23:49 +1000

Jean,

My interpretation of the current text is:
The text mandates that a timestamp token can be only signed with a specific
'timestamping' key, as indicated by the ExtKeyUsage. A timestamp token
signed by a key which does not contain that ExtKeyUsage field must be
considered invalid. However, it does NOT necessarily say that the same
'timestamping' key can not be used for signing whatever else, for example a
certificate. 

So, I can not see anything in the current text that would prohibit issuing a
self-signed TSA certificate.

However, I'd suggest that the draft makes it clearer, by adding a comment
(in a security section?) about possibility of generating and using
self-signed TSA certificates.

Regards
M

> -----Original Message-----
> From: Jean-Marc Desperrier [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2000 8:37 PM
> To: [email-masked]
> Subject: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> Michael Zolotarev wrote:
> 
> > I can see a problem with it with self-signed TSA 
> certificates. Normally, a
> > client would be configured to directly trust THAT 
> [self-signed] TSA cert.
> > Having a set of self-signed TSA certificates would be a 
> configuration
> > nightmare for the clients. And then you add another crypto 
> box to your load
> > balancing array on TSS, and then another one...
> 
> It is my understanding of the current draft that a TSA 
> certificate can not be
> self-signed :
> 
> 2.3 :
> The TSA MUST sign all time stamp messages with one or more keys
> reserved specifically for that purpose.  The corresponding certificate
> MUST contain only one instance of the extended key usage field
> extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID
> having value id-kp-timeStamping. This extension MUST be critical.
> 
> If the TSA is self-signed then the private key has been used 
> for something else
> than signing time stamp, and something it does not have the 
> correct key usage
> field for.
> 
> So if self-signed TSA certificate should be enabled, I think 
> the wording of the
> draft should be changed to specify this.
> 

From: Michael Zolotarev <[email-masked]>
To: Simon McMahon <[email-masked]>, Michael Zolotarev <[email-masked]>, [email-masked], Paul Koning <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Private Key Cloning (TSA keys)
Date: Wed, 21 Jun 2000 14:53:14 +1000

Simon,
(I'm taking luxury of being in the same time zone with you, so I can answer
the first :)

What you are saying is absolutely right, and technically I believe we all
know that it is more practical to clone the keys, than to come up with the
solution around it. But the argument has started as a result of the fact
that some legislations, namely German Digital Signature Law, prohibit key
cloning. So we've been discussing just one of the possible solutions to get
around the restrictions of the law.

I'm still not convinced, though, that the interpretation of the law is
correct. Taking your example with accelerator - would it be regarded as a
breach of the law? If not, and the accelerator is all right, what makes it
dramatically different from cloning the key in the environment which can be
formally certified as a security-equivalent to the accelerator's?

The law is written for general use, and each particular scenario requires
specific peruse. I'm wondering if we are trying to scare ourselves away even
before the law has a chance to "speak out". Would really like to hear from
anybody who has legal expertise and can provide an interpretation of the
German Law for that specific case.

Regards
Michael

> -----Original Message-----
> From: Simon McMahon [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2000 2:39 PM
> To: Michael Zolotarev; [email-masked]; Paul Koning
> Cc: David P. Kemp; [email-masked]; [email-masked]
> Subject: Re: Private Key Cloning (TSA keys)
> 
> 
> Hi All,
> 
> I've been considering load balancing and Private Key cloning 
> for another
> project (not TSA) but a lot of the issues are the same. I 
> think the problems
> of messing with the client software to fix what looks to me 
> like a server
> problem is a bad idea. Anyway, here is my 2c worth.
> 
> Performance / availablilty is a problem that the TSA server 
> has and load
> balancing is one solution to address that problem. In my 
> opinion any load
> balancing scheme that impacts on the clients will not be very 
> scalable or
> interoperable and should be avoided. In other words cloning 
> the private key
> is necessary to do load balancing transparently to the client base.
> 
> The problem is legislation which boils down to "dont copy 
> that private key".
> 
> However, if the cloned private keys were controlled in such a 
> way that they
> could not be seperated and used independantly outside a well defined
> boundary, e.g. the TSA, couldn't they still be considered as 
> one instance of
> the private key since externally (to the TSA) there would be no way of
> knowing that more than one copy exists within the TSA. The 
> TSA would also
> have to show that any loss or theft of any copy of the 
> private key, for any
> amount of time, is detectable and would result in revocation 
> of that key.
> 
> As an extreme example - consider a hardware accelerator with 
> two modular
> exponentiation processors on board. The TSA application loads 
> up one private
> key but the accelerator splits it into two copies one loaded 
> into each of
> the processors. The TSA application then pumps signature 
> requests at the
> accelerator and has no control over which processor inside 
> the device does
> the operation. The accelerator offers no other services which 
> would allow
> either copy of the private key to be messed around with. If 
> the accelerator
> was evaluated to Fips 140, ITSEC, CC or whatever, then surely 
> there would be
> no problem with the legislation here.
> 
> Scaling that example up to physically seperate devices within 
> a TSA might
> require a security evaluation of the TSA, or at least that 
> physical part tha
> t includes the devices and management processes for them but 
> wont TSAs need
> to be evaluated anyway ?
> 
> Simon McMahon
> ERACOM Pty. Ltd.
> 
> ----- Original Message -----
> From: Michael Zolotarev <[email-masked]>
> To: <[email-masked]>; Paul Koning <[email-masked]>
> Cc: Michael Zolotarev <[email-masked]>; David P. Kemp
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Sent: Wednesday, 21 June 2000 13:21
> Subject: RE: Private Key Cloning (TSA keys)
> 
> 
> > Guys,
> >
> > Let's talk about one issue at a time.
> >
> > 1. Using self-signed TSA certs.
> > The specifics of timestamping framework, in my opinion, 
> make it perfectly
> > normal and acceptable that a client would trust a TSA 
> directly. A TSA can
> be
> > generally considered a TTP, with no pressing need to have a TSA cert
> issued
> > by other TTP (a CA). Consequently, there should be nothing  wrong in
> having
> > a self-signed TSA certificate. If the current draft 
> precludes from doing
> it,
> > or makes the possibility of it confusing, I believe it 
> should be fixed.
> > (This is why I cc-ed Denis on this).
> >
> > 2. Assuming that using self-signed TSA certs is Ok, then we 
> do have an
> issue
> > of handling an array of crypto boxes. The solutions for simplifying
> client's
> > side trust configuration proposed in the recent traffic 
> were all about the
> > same: making the TSA to allocate a dedicated "signing key", 
> and to sign
> the
> > 'real operational' TSA certs with that key.
> > I agree that this 'redirection' would simplify the client's 
> side. The rule
> > of trust for the client would be something like "Trust any TSA
> certificate,
> > signed by THAT key-signing cert".
> >
> > Note that this makes a TSA operating more like a mini-CA, 
> signing the
> certs
> > for the keys it generates itself with yet another key it has [just]
> > generated. This creates extra inconvenience for the TSA 
> management - they
> > would have to maintain a separate [and potentially secure]
> > procedure/facility. Probably even having to allocate a 
> different DN for
> each
> > of the 'operational' certificate as well? But this is not a 
> huge issue -
> who
> > cares about poor system administrators :)?
> >
> > As a conclusion, I personally do not see any problems with 
> that approach,
> > and tend to agree that the problem of key cloning for TSA 
> can be solved
> with
> > the 'redirection'.
> >
> > Regards
> > Michael
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, June 21, 2000 3:07 AM
> > > To: Paul Koning
> > > Cc: [email-masked]; David P. Kemp; [email-masked]
> > > Subject: Re: Private Key Cloning
> > >
> > >
> > > Paul Koning wrote:
> > >
> > > >
> > > >  Michael> I can see a problem with it with self-signed TSA
> > > >  Michael> certificates. Normally, a client would be 
> configured to
> > > >  Michael> directly trust THAT [self-signed] TSA cert.
> > > Having a set of
> > > >  Michael> self-signed TSA certificates would be a configuration
> > > >  Michael> nightmare for the clients. And then you add 
> another crypto
> > > >  Michael> box to your load balancing array on TSS, and 
> then another
> > > >  Michael> one...
> > > >
> > > > So have one of the copies self-sign its own key and in 
> addition sign
> > > > each of the other keys.  Is there a problem with that?
> > > >
> > >
> > > I suspect that this would not be acceptable.  The draft
> > > indicates that TSA
> > > keys should only be used for signing timestamps.  Your 
> proposal allows
> > > signing other keys (creating certificates) as well.
> > >
> > > The best solution is to create a separate key that is trusted
> > > to create TSA
> > > certificates and is used only for that purpose, or to get
> > > another (trusted)
> > > CA to sign each of the TSA keys.
> > >
> > > Terry
> > >
> > >
> >
> 

Content-return: allowed
Date: Tue, 20 Jun 2000 21:26:55 -0700
From: Ambarish Malpani <[email-masked]>
Subject: Generalizing the concept of id-pkix-ocsp-nocheck
To: [email-masked]

I was recently having a conversation with a collegue and he
asked a question. Here goes:

In OCSP, we have support the concept of a CA issuing a special
certificate to an OCSP responder, allowing it to respond on its
[the CA's] behalf with a special extended key usage flag.

We also allow the CA to indicate that the responder's cert does
not need to be validated by having it include the
id-pkix-ocsp-nocheck extension in the responder's certificate.

Why can't the concept of including an id-pkix-ocsp-nocheck
extension in a certificate be extended to any arbitrary certificate
to indicate that it doesn't need to be validated?

If this makes sense, should this capability be specified in
son-of-rfc2459?

Comments?

Ambarish

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

From: "Simon McMahon" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, <[email-masked]>, "Paul Koning" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Private Key Cloning (TSA keys)
Date: Wed, 21 Jun 2000 14:38:34 +1000

Hi All,

I've been considering load balancing and Private Key cloning for another
project (not TSA) but a lot of the issues are the same. I think the problems
of messing with the client software to fix what looks to me like a server
problem is a bad idea. Anyway, here is my 2c worth.

Performance / availablilty is a problem that the TSA server has and load
balancing is one solution to address that problem. In my opinion any load
balancing scheme that impacts on the clients will not be very scalable or
interoperable and should be avoided. In other words cloning the private key
is necessary to do load balancing transparently to the client base.

The problem is legislation which boils down to "dont copy that private key".

However, if the cloned private keys were controlled in such a way that they
could not be seperated and used independantly outside a well defined
boundary, e.g. the TSA, couldn't they still be considered as one instance of
the private key since externally (to the TSA) there would be no way of
knowing that more than one copy exists within the TSA. The TSA would also
have to show that any loss or theft of any copy of the private key, for any
amount of time, is detectable and would result in revocation of that key.

As an extreme example - consider a hardware accelerator with two modular
exponentiation processors on board. The TSA application loads up one private
key but the accelerator splits it into two copies one loaded into each of
the processors. The TSA application then pumps signature requests at the
accelerator and has no control over which processor inside the device does
the operation. The accelerator offers no other services which would allow
either copy of the private key to be messed around with. If the accelerator
was evaluated to Fips 140, ITSEC, CC or whatever, then surely there would be
no problem with the legislation here.

Scaling that example up to physically seperate devices within a TSA might
require a security evaluation of the TSA, or at least that physical part tha
t includes the devices and management processes for them but wont TSAs need
to be evaluated anyway ?

Simon McMahon
ERACOM Pty. Ltd.

----- Original Message -----
From: Michael Zolotarev <[email-masked]>
To: <[email-masked]>; Paul Koning <[email-masked]>
Cc: Michael Zolotarev <[email-masked]>; David P. Kemp
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, 21 June 2000 13:21
Subject: RE: Private Key Cloning (TSA keys)

> Guys,
>
> Let's talk about one issue at a time.
>
> 1. Using self-signed TSA certs.
> The specifics of timestamping framework, in my opinion, make it perfectly
> normal and acceptable that a client would trust a TSA directly. A TSA can
be
> generally considered a TTP, with no pressing need to have a TSA cert
issued
> by other TTP (a CA). Consequently, there should be nothing  wrong in
having
> a self-signed TSA certificate. If the current draft precludes from doing
it,
> or makes the possibility of it confusing, I believe it should be fixed.
> (This is why I cc-ed Denis on this).
>
> 2. Assuming that using self-signed TSA certs is Ok, then we do have an
issue
> of handling an array of crypto boxes. The solutions for simplifying
client's
> side trust configuration proposed in the recent traffic were all about the
> same: making the TSA to allocate a dedicated "signing key", and to sign
the
> 'real operational' TSA certs with that key.
> I agree that this 'redirection' would simplify the client's side. The rule
> of trust for the client would be something like "Trust any TSA
certificate,
> signed by THAT key-signing cert".
>
> Note that this makes a TSA operating more like a mini-CA, signing the
certs
> for the keys it generates itself with yet another key it has [just]
> generated. This creates extra inconvenience for the TSA management - they
> would have to maintain a separate [and potentially secure]
> procedure/facility. Probably even having to allocate a different DN for
each
> of the 'operational' certificate as well? But this is not a huge issue -
who
> cares about poor system administrators :)?
>
> As a conclusion, I personally do not see any problems with that approach,
> and tend to agree that the problem of key cloning for TSA can be solved
with
> the 'redirection'.
>
> Regards
> Michael
>
>
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, June 21, 2000 3:07 AM
> > To: Paul Koning
> > Cc: [email-masked]; David P. Kemp; [email-masked]
> > Subject: Re: Private Key Cloning
> >
> >
> > Paul Koning wrote:
> >
> > >
> > >  Michael> I can see a problem with it with self-signed TSA
> > >  Michael> certificates. Normally, a client would be configured to
> > >  Michael> directly trust THAT [self-signed] TSA cert.
> > Having a set of
> > >  Michael> self-signed TSA certificates would be a configuration
> > >  Michael> nightmare for the clients. And then you add another crypto
> > >  Michael> box to your load balancing array on TSS, and then another
> > >  Michael> one...
> > >
> > > So have one of the copies self-sign its own key and in addition sign
> > > each of the other keys.  Is there a problem with that?
> > >
> >
> > I suspect that this would not be acceptable.  The draft
> > indicates that TSA
> > keys should only be used for signing timestamps.  Your proposal allows
> > signing other keys (creating certificates) as well.
> >
> > The best solution is to create a separate key that is trusted
> > to create TSA
> > certificates and is used only for that purpose, or to get
> > another (trusted)
> > CA to sign each of the TSA keys.
> >
> > Terry
> >
> >
>

From: Michael Zolotarev <[email-masked]>
To: [email-masked], Paul Koning <[email-masked]>
Cc: Michael Zolotarev <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Private Key Cloning (TSA keys)
Date: Wed, 21 Jun 2000 13:21:21 +1000

Guys,

Let's talk about one issue at a time.

1. Using self-signed TSA certs.
The specifics of timestamping framework, in my opinion, make it perfectly
normal and acceptable that a client would trust a TSA directly. A TSA can be
generally considered a TTP, with no pressing need to have a TSA cert issued
by other TTP (a CA). Consequently, there should be nothing  wrong in having
a self-signed TSA certificate. If the current draft precludes from doing it,
or makes the possibility of it confusing, I believe it should be fixed.
(This is why I cc-ed Denis on this).

2. Assuming that using self-signed TSA certs is Ok, then we do have an issue
of handling an array of crypto boxes. The solutions for simplifying client's
side trust configuration proposed in the recent traffic were all about the
same: making the TSA to allocate a dedicated "signing key", and to sign the
'real operational' TSA certs with that key.
I agree that this 'redirection' would simplify the client's side. The rule
of trust for the client would be something like "Trust any TSA certificate,
signed by THAT key-signing cert".

Note that this makes a TSA operating more like a mini-CA, signing the certs
for the keys it generates itself with yet another key it has [just]
generated. This creates extra inconvenience for the TSA management - they
would have to maintain a separate [and potentially secure]
procedure/facility. Probably even having to allocate a different DN for each
of the 'operational' certificate as well? But this is not a huge issue - who
cares about poor system administrators :)?

As a conclusion, I personally do not see any problems with that approach,
and tend to agree that the problem of key cloning for TSA can be solved with
the 'redirection'.

Regards
Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2000 3:07 AM
> To: Paul Koning
> Cc: [email-masked]; David P. Kemp; [email-masked]
> Subject: Re: Private Key Cloning
> 
> 
> Paul Koning wrote:
> 
> >
> >  Michael> I can see a problem with it with self-signed TSA
> >  Michael> certificates. Normally, a client would be configured to
> >  Michael> directly trust THAT [self-signed] TSA cert.  
> Having a set of
> >  Michael> self-signed TSA certificates would be a configuration
> >  Michael> nightmare for the clients. And then you add another crypto
> >  Michael> box to your load balancing array on TSS, and then another
> >  Michael> one...
> >
> > So have one of the copies self-sign its own key and in addition sign
> > each of the other keys.  Is there a problem with that?
> >
> 
> I suspect that this would not be acceptable.  The draft 
> indicates that TSA
> keys should only be used for signing timestamps.  Your proposal allows
> signing other keys (creating certificates) as well.
> 
> The best solution is to create a separate key that is trusted 
> to create TSA
> certificates and is used only for that purpose, or to get 
> another (trusted)
> CA to sign each of the TSA keys.
> 
> Terry
> 
> 

Date: Tue, 20 Jun 2000 18:18:29 -0700
From: [email-masked] (Terry Hayes)
To: Michael Zolotarev <[email-masked]>
CC: Paul Koning <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

I agree as well.  There is no need for the TSA to check anything about the
imprint. This requirement should be removed from the draft.

Terry Hayes
[email-masked]

Michael Zolotarev wrote:

> > If I were to generate my imprint with hash algorithm FRED that has a
> > 37 byte digest, does it matter to the TSA?  No, it does not.  So why
> > are we saying that the TSA needs to know the OID for FRED, and the
> > associated digest length?
> >
> > The spec says that it's done to consistency-check the length of the
> > imprint.  Sure, but to what end?  If I send a digest generated by FRED
> > but truncate it to 31 bytes, what purpose is served by the TSA saying
> > "naughty boy you threw away 6 bytes"?  I may in fact have a legitimate
> > reason for doing this -- just as IPsec has a legitimate reason for
> > throwing away some of the hash bytes in the HMAC construct.  If it
> > actually mattered to the TSA algorithms, that would be one thing.  But
> > since the only purpose of the check is to do the check, let's get rid
> > of it, simplify the spec, make the TSA implementations more reliable,
> > and eliminate the need to ECO the spec every time a new hash appears.
> >
> >         paul
>
> I agree (expecting a public outcry here :). I always felt pretty
> uncomfortable with the TSA having to recognise the hash OID and checking the
> length. And on top of if, this would now allow a client tp send a NO-HASH
> imprint, a clear text, if they want to.
>
> Michael
> >

From: Michael Zolotarev <[email-masked]>
To: Paul Koning <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Date: Wed, 21 Jun 2000 10:48:58 +1000

> If I were to generate my imprint with hash algorithm FRED that has a
> 37 byte digest, does it matter to the TSA?  No, it does not.  So why
> are we saying that the TSA needs to know the OID for FRED, and the
> associated digest length?
> 
> The spec says that it's done to consistency-check the length of the
> imprint.  Sure, but to what end?  If I send a digest generated by FRED
> but truncate it to 31 bytes, what purpose is served by the TSA saying
> "naughty boy you threw away 6 bytes"?  I may in fact have a legitimate
> reason for doing this -- just as IPsec has a legitimate reason for
> throwing away some of the hash bytes in the HMAC construct.  If it
> actually mattered to the TSA algorithms, that would be one thing.  But
> since the only purpose of the check is to do the check, let's get rid
> of it, simplify the spec, make the TSA implementations more reliable,
> and eliminate the need to ECO the spec every time a new hash appears.
> 
> 	  paul

I agree (expecting a public outcry here :). I always felt pretty
uncomfortable with the TSA having to recognise the hash OID and checking the
length. And on top of if, this would now allow a client tp send a NO-HASH
imprint, a clear text, if they want to.

Michael

Date: Tue, 20 Jun 2000 14:44:58 -0400
From: Yassir Elley <[email-masked]>
To: [email-masked]
Subject: Using certificates as trust anchors

In looking over draft-ietf-pkix-new-part1-01.txt, a question
arises as to how to process trust anchors provided in the
form of a self-signed certificate. Since many applications use such certificates
as trust anchors, I think it is important for PKIX to explicitly spell out how
to process these certificates.

Section 6.1.1 describes the five pieces of trust anchor information and
mentions that the trust anchor information may be provided in the form
of a self-signed certificate.

"(d) trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor infor-
      mation includes:
         (1) the trusted issuer name,
         (2) optionally, the trusted issuer unique identifier,
         (3) the trusted public key algorithm,
         (4) the trusted public key, and
         (5) optionally, the trusted public key parameters associated
         with the public key.

      The trust anchor information may be provided to the path process-
      ing procedure in the form of a self-signed certificate. The
      trusted anchor information is trusted because it was delivered to
      the path processing procedure by some trustworthy "out-of-band"
      procedure.  If the trusted public key algorithm requires parame-
      ters, then the parameters are provided along with the trusted pub-
      lic key."

However, in other parts of Section 6, we find that the algorithm
also requires the validity period of the public key, as well
as other constraints (presumably this refers to initial
name constraints, policy constraints, basic constraints[pathLenConstraint]?).

For example:
"In section 6.1, the text describes basic path validation. This text
   assumes that all valid paths begin with certificates issued by a sin-
   gle "most-trusted CA". The algorithm requires the public key of the
   CA, the CA's name, the validity period of the public key, and any
   constraints upon the set of paths which may be validated using this
   key."

Section 6.2 also refers to making use of the certificate's extensions
to limit the path.
 "Limitations in the trust paths for any particular key may
   be incorporated into the self-signed certificate's extensions. In
   this way, the self-signed certificates permit the path validation
   module to automatically incorporate local security policy and
   requirements."

If the trust anchor information is provided in the form of a self-signed
certificate, we can certainly extract the five pieces of trust anchor
information mentioned in Section 6.1.1.

Should we also be extracting other information from the certificate,
such as policy constraints, policy mappings, name constraints, and
basic constraints, and using these to initialize the relevant state
variables? What about the validity period of the public key?
Do we need to verify that the self-signed certificates's validity period
includes time T?

Do we need to validate the self-signed certificate itself?
(i.e. do we have to verify the self-signed certificate's signature,
revocation status, name chaining, uid chaining, that any
certificate policies and policy mappings are processed,
that it is a CA cert, that it has a keyCertSign key usage asserted,
that all critical extensions are processed?)

If the trust anchor information is trusted because it
was delivered "out-of-band", can we use non-self-signed
certificates to provide the trust anchor information?
Perhaps I have a certificate that is not self-signed that I
trust for some "out-of-band" reason. I would think
that I should be able to use this certificate as a trust anchor
since I have designated it as trusted. If this is allowed,
it should be noted that we will not be able to
validate the signature, revocation status, name chaining,
and uid chaining checks because these checks rely
on a "previous" certificate's values which we don't have.

One approach would be to not validate any part of
the trust anchor certificate and simply accept it
(whether or not it is self-signed)
because the user has designated it as "trusted", but
to extract any relevant information. In other words,
we wouldn't perform any of the steps in
6.1.3 (Basic Certificate Processing) but we would
perform all the steps in 6.1.4 (Preparation for
Certificate i+1).

All of these questions need to be answered explicitly
so that we can all process trust anchor certificates in
a standard way.

-Yassir.

Date: Tue, 20 Jun 2000 10:22:19 -0700
To: "David P. Kemp" <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: RE: Private Key Cloning

At 12:33 PM 6/20/00 -0400, David P. Kemp wrote:

>But I remember an old quote (can't remember the source) --
>
>   "I never met a problem that couldn't be solved with another layer
>    of indirection."

That would have to be Bill Gates ... :)

___tony___

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

Date: Tue, 20 Jun 2000 10:06:51 -0700
From: [email-masked] (Terry Hayes)
To: Paul Koning <[email-masked]>
CC: [email-masked], "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Private Key Cloning

Paul Koning wrote:

>
>  Michael> I can see a problem with it with self-signed TSA
>  Michael> certificates. Normally, a client would be configured to
>  Michael> directly trust THAT [self-signed] TSA cert.  Having a set of
>  Michael> self-signed TSA certificates would be a configuration
>  Michael> nightmare for the clients. And then you add another crypto
>  Michael> box to your load balancing array on TSS, and then another
>  Michael> one...
>
> So have one of the copies self-sign its own key and in addition sign
> each of the other keys.  Is there a problem with that?
>

I suspect that this would not be acceptable.  The draft indicates that TSA
keys should only be used for signing timestamps.  Your proposal allows
signing other keys (creating certificates) as well.

The best solution is to create a separate key that is trusted to create TSA
certificates and is used only for that purpose, or to get another (trusted)
CA to sign each of the TSA keys.

Terry

Date: Tue, 20 Jun 2000 12:33:41 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Private Key Cloning
To: [email-masked]
Content-MD5: Zy2YnAfwx0TZodRsz2lfzg==

Agree that it is a problem with the architecture you and Gene describe.

But I remember an old quote (can't remember the source) -- 

  "I never met a problem that couldn't be solved with another layer
   of indirection."

You could add that layer (a self-signed TSA trust point that signs the
server keys), or you could use static load balancing - assign the first
100,000 clients to one server, then stand up another server and assign
the next 100,000 clients to it, etc.  Not pretty, but not a "nightmare"
either.

Or you could use server accelerators which allow you to import and
export private signature keys.  I'm sure there is a market for both
tokens which prevent signature key cloning and tokens which allow it,
allowing system architects to trade off technical controls with
procedural controls.  Personally, I prefer technical -- never offer
a human the opportunity to be the man-in-the-middle (or the man-at-one-end,
since spoofing a token-to-token protocol doesn't require two tokens).

> From: Michael Zolotarev <[email-masked]>
> To: "David P. Kemp" <[email-masked]>, [email-masked]
> Subject: RE: Private Key Cloning
> Date: Tue, 20 Jun 2000 10:38:35 +1000
> 
> > 
> > And it doesn't seem to present insurmountable obstacles to load
> > balancing ... why shouldn't each server have its own signature key?
> > Is there a reason not to use N certificates with identical
> > distinguished names and different public keys?
> > 
> 
> I can see a problem with it with self-signed TSA certificates. Normally, a
> client would be configured to directly trust THAT [self-signed] TSA cert.
> Having a set of self-signed TSA certificates would be a configuration
> nightmare for the clients. And then you add another crypto box to your load
> balancing array on TSS, and then another one...
> 
> M
> 
> 
> *****************************************************************************
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> ******************************************************************************

From: Peter Sylvester <[email-masked]>
Date: Tue, 20 Jun 2000 17:55:18 +0200 (MET DST)
To: [email-masked]
Subject: Re: Can we form certificates with just name and e-mail address
Cc: [email-masked]

Why not using an alternature subject with an
email and the x.509 extension for the name parts. 

Subject directory attributes extension

This field conveyes and desired Directory attribute values for
the subject of the certificate. This field is defined as follows:

 subjectDirectoryAttributes EXTENSION ::= {
     SYNTAX AttributesSyntax
     IDENTIFIED BY id-ce-subjectDirectoryAttributes }

 AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute 

id-ce-subjectDirectoryAttributes :: OBJECT IDENTIFIER ::= {id-ce 9}

Date: Tue, 20 Jun 2000 11:13:52 -0400
To: Stefan Santesson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Cc: "PKIX Mailing List" <[email-masked]>

Stefan,

>Steve,
>
>Thank's for useful input. Just to round this up, can you confirm the 
>conclusion that issuing certificates where subjects are represented 
>by just e-mail address + givenName + surname (and maybe also 
>country) is simply not possible.
>
>The name must simply be combined with a serialNumber attribute or 
>some other information that makes the name (with e-mail address 
>excluded) a reasonable DN.
>
>Right?

Well, its possible to issue certs with any sort of DN.  The question 
is what makes sense given the semantics of a DN, not just viewing it 
as a string of AVAs irrespective of context. The question I would ask 
is what would the directory tree look like given a proposed DN.  How 
would the tree be distributed and managed?  Think about the schema 
with those considerations in mind.

For example, if one uses a geopolitical and organizational structure, 
which is the common model for DNs, we see lots of reasonable options 
for dividing the tree and determining who is responsible for 
maintainign what portions of it.  On the other hand, if a DN consists 
of an e-mail address plus givenname and surname, this seems rather 
odd.  The e-mail address, as a single attribute, results in a very 
broad fan out under the root. (in contrast, if one used DC 
attributes, as mentioned recently, one could mimic the structure of 
the DNS, which is well suited for separation and distributed 
maintenance, as the DNS has shown.)  Since e-mail addresses are 
already globally unique, what does the given name and surname do for 
you, from a tree structure standpoint?

Steve

From: Paul Koning <[email-masked]>
Date: Tue, 20 Jun 2000 11:04:42 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

>>>>> "Michael" == Michael Zolotarev <[email-masked]> writes:

 Michael> Folks, Haven't we already had a discussion about hash
 Michael> algorithm for messageImprint?

 Michael> I believe that the consensus was (and it is 100% reflected
 Michael> in the current draft) to allow a user to use whatever digest
 Michael> he/she wants. It is NOT a TSA concern if a user used 'weak'
 Michael> hash. The TSA does not inspect, modify, store or analyse the
 Michael> content of messageImprint - it only checks that the length
 Michael> of the hash corresponds to the hash algorithm. If so, then
 Michael> why should the draft imply any limitations on type of digest
 Michael> algorithms, except saying that they must be known?

 Michael> The position of the draft is, if I interpret it correctly:
 Michael> 1) The TSA does not care about hash algorithm used in
 Michael> messageImprint. But the algorithm must be known, to allow
 Michael> TSA to sanity-check the length of digested data.  2) The
 Michael> user is ADVICED to use strong hash, such as SHA-1 or MD5.

 Michael> This position of the draft with regards to hash is general,
 Michael> and provides enough space to grow, instead of being
 Michael> unnecessary restrictive. Can we leave it in peace :)?

Can we remove this unnecessary restrictions instead?

A rule of thumb of protocol design is that requirements are put in
because they are necessary for interoperability.  In the case we have
here, that rule of thumb doesn't apply.

If I were to generate my imprint with hash algorithm FRED that has a
37 byte digest, does it matter to the TSA?  No, it does not.  So why
are we saying that the TSA needs to know the OID for FRED, and the
associated digest length?

The spec says that it's done to consistency-check the length of the
imprint.  Sure, but to what end?  If I send a digest generated by FRED
but truncate it to 31 bytes, what purpose is served by the TSA saying
"naughty boy you threw away 6 bytes"?  I may in fact have a legitimate
reason for doing this -- just as IPsec has a legitimate reason for
throwing away some of the hash bytes in the HMAC construct.  If it
actually mattered to the TSA algorithms, that would be one thing.  But
since the only purpose of the check is to do the check, let's get rid
of it, simplify the spec, make the TSA implementations more reliable,
and eliminate the need to ECO the spec every time a new hash appears.

	  paul

From: Paul Koning <[email-masked]>
Date: Tue, 20 Jun 2000 10:51:01 -0400 (EDT)
To: [email-masked]
Cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: Private Key Cloning

>>>>> "Michael" == Michael Zolotarev <[email-masked]> writes:

 >>  And it doesn't seem to present insurmountable obstacles to load
 >> balancing ... why shouldn't each server have its own signature
 >> key?  Is there a reason not to use N certificates with identical
 >> distinguished names and different public keys?
 >> 

 Michael> I can see a problem with it with self-signed TSA
 Michael> certificates. Normally, a client would be configured to
 Michael> directly trust THAT [self-signed] TSA cert.  Having a set of
 Michael> self-signed TSA certificates would be a configuration
 Michael> nightmare for the clients. And then you add another crypto
 Michael> box to your load balancing array on TSS, and then another
 Michael> one...

So have one of the copies self-sign its own key and in addition sign
each of the other keys.  Is there a problem with that?

     paul

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Tue, 20 Jun 2000 10:24:54 -0400
Subject: Re: Private Key Cloning

I agree on what you said.  We had done it different for the load balance, the
design is to us sub-CAs for the load balance, this may be more complex.  The
result should be cleaner and for better management for long term, since the
serial number and the DN will need special care after service for a while.

And as the sub-CA method do no need to clone the CA key at all.

Mcken Mak

[email-masked] on 06/19/2000 03:24:05 PM

To:   [email-masked]
cc:    (bcc: Mcken Mak/Technology/Equifax)

Subject:  Re: Private Key Cloning

The issue is relevant only for for a very basic PKI.  The wish is to have a
single trust anchor of one public key, no sub-CAs, yet assure availability and
load balance the CA service by cloned copies of the CA server (and its key).
This scenario pre-empts by definition each server having its own key.  However,
it also conflicts with the no-copy rule.
-Gene Hilborn

[email-masked] on 06/19/2000 02:21:34 PM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: Private Key Cloning

> From: Paul Koning <[email-masked]>
> Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT)
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: Re: Private Key Cloning
>
> >>>>> "FRousseau" == FRousseau  <[email-masked]> writes:
>
>  FRousseau> Juergen, If a private key generated within a hardware
>  FRousseau> cryptographic module is securely wrapped within that same
>  FRousseau> module, is then exported to another similar hardware
>  FRousseau> cryptographic module through an authenticated key exchange
>  FRousseau> where it is unwrapped and both of these private keys are
>  FRousseau> then used to perform electronic signatures in a load
>  FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean
>  FRousseau> this would not be legal in Germany?
>
> How would you guarantee that there's no man in the middle?  The only
> way would be to have a prior out of band secure setup of
> authenticating data, such as a shared secret or public keys used for
> this key exchange process.  While the user of such a device can ensure
> that this is done right, the manufacturer of the devices cannot.
>
> It doesn't surprise me at all to see devices that don't allow this.
> It makes good security sense to omit such a capability.
>
>    paul

And it doesn't seem to present insurmountable obstacles to load
balancing ... why shouldn't each server have its own signature key?
Is there a reason not to use N certificates with identical
distinguished names and different public keys?

Date: Tue, 20 Jun 2000 12:36:42 +0200
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: self-signed TSA [Was Re: Private Key Cloning]

Michael Zolotarev wrote:

> I can see a problem with it with self-signed TSA certificates. Normally, a
> client would be configured to directly trust THAT [self-signed] TSA cert.
> Having a set of self-signed TSA certificates would be a configuration
> nightmare for the clients. And then you add another crypto box to your load
> balancing array on TSS, and then another one...

It is my understanding of the current draft that a TSA certificate can not be
self-signed :

2.3 :
The TSA MUST sign all time stamp messages with one or more keys
reserved specifically for that purpose.  The corresponding certificate
MUST contain only one instance of the extended key usage field
extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID
having value id-kp-timeStamping. This extension MUST be critical.

If the TSA is self-signed then the private key has been used for something else
than signing time stamp, and something it does not have the correct key usage
field for.

So if self-signed TSA certificate should be enabled, I think the wording of the
draft should be changed to specify this.

Date: Tue, 20 Jun 2000 12:06:31 +0200
From: Hans Schupp <[email-masked]>
Organization: SECUDE GmbH
To: Aram Perez <[email-masked]>
CC: PKIX Mailing List <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address

Dies ist eine kryptographisch unterzeichnete Nachricht im MIME-Format.

--------------ms0E2F3B897E84257584775E83
Content-Type: multipart/mixed;
 boundary="------------9E538EACC218188EF5083E6D"

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------9E538EACC218188EF5083E6D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram Perez schrieb:

> I haven't seen any provide this answer so here I go: Someone can
> correct my ASN.1, but a reason you shouldn't use "e=[email-masked]"
> in a/or as a DN is that it does not meet the ASN.1 rules for a DN
> (the '@' symbol is not in one of the valid character sets for DNs).
> There are a number of "public CAs" that do put the '@' in a DN, but
> technically they are incorrect.

There is no single valid character set for "DName", only one for each
defined "AttributeValueAssertion" (i.e. every pair XX=YY).
The email-Attribute (OID 1.2.840.113549.1.9.1) has IA5String as defined
character set, which contains the '@' character.

So there is no problem.

best regards,
Hans Schupp
--------------9E538EACC218188EF5083E6D
Content-Type: text/x-vcard; charset=us-ascii;
 name="schupp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Hans Schupp
Content-Disposition: attachment;
 filename="schupp.vcf"

begin:vcard 
n:Schupp;Hans
tel;cell:(+49) 177 / 2452088 (private)
tel;fax:(+49) 6151 / 82897 - 26
tel;work:(+49) 6151 / 82897 - 37
x-mozilla-html:FALSE
url:http://www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH<br><font color=green>e-security for e-business</font></i>
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;NEW ADDRESS:=0D=0ADolivostr. 11=0D=0A;Darmstadt;;D-64293;Germany
fn:Hans Schupp
end:vcard

--------------9E538EACC218188EF5083E6D--

--------------ms0E2F3B897E84257584775E83
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Kryptographische Unterschrift mit S/MIME

--------------ms0E2F3B897E84257584775E83--

From: "Joerg Voelker" <[email-masked]>
To: "Jean Abraham" <[email-masked]>, <[email-masked]>
Subject: AW: 
Date: Tue, 20 Jun 2000 09:42:14 +0200
Importance: Normal

Jean,

TSA : Time Stamping Authority
OCSP: Online Certificate Status Protocol

For further information see: http://www.ietf.org/ID.html

regards,
Joerg
>-----Ursprüngliche Nachricht-----
>Von: Jean Abraham [mailto:[email-masked]]
>Gesendet: Dienstag, 20. Juni 2000 09:27
>An: [email-masked]
>Betreff:
>
>
>hi,
>
>What is TSA, OSCP?
>
>Jean
>

From: "Jean Abraham" <[email-masked]>
To: <[email-masked]>
Subject: 
Date: Tue, 20 Jun 2000 10:26:51 +0300
Importance: Normal

hi,

What is TSA, OSCP?

Jean

From: Michael Zolotarev <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Date: Tue, 20 Jun 2000 13:21:12 +1000

Folks,

Haven't we already had a discussion about hash algorithm for messageImprint?

I believe that the consensus was (and it is 100% reflected in the current
draft) to allow a user to use whatever digest he/she wants. It is NOT a TSA
concern if a user used 'weak' hash. The TSA does not inspect, modify, store
or analyse the content of messageImprint - it only checks that the length of
the hash corresponds to the hash algorithm. If so, then why should the draft
imply any limitations on type of digest algorithms, except saying that they
must be known?

The position of the draft is, if I interpret it correctly:
1) The TSA does not care about hash algorithm used in messageImprint. But
the algorithm must be known, to allow TSA to sanity-check the length of
digested data.
2) The user is ADVICED to use strong hash, such as SHA-1 or MD5. 

This position of the draft with regards to hash is general, and provides
enough space to grow, instead of being unnecessary restrictive. Can we leave
it in peace :)?

Michael

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2000 1:00 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
> 
> 
> >>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:
> 
>  Joerg> Comments inline.
>  >> TSA implementations MUST support SHA-1.  TSA implementations
>  >> SHOULD support MD5.
> 
>  Joerg> I think there are good reasons not to use MD5 in time
>  Joerg> stamps. They should use a strong hash function in order to
>  Joerg> achive long validity periods. MD5 is likely to be unsafe (=not
>  Joerg> collision free) soon and is already discuraged by german
>  Joerg> authorities.
> 
>  Joerg> IF we add a section about algorithms, it should maybe read:
>  Joerg> "TSA implementations MUST support SHA-1.  TSA implementations
>  Joerg> SHOULD NOT support MD5.". But I think such a section is not
>  Joerg> very necessary.
> 
> IANAC, but from what I understand the currently known attacks on MD5
> are nowhere near strong enough to justify that.  
> 
> I don't have a problem with the current text (SHA-1 required, MD5
> recommended).  I do have a problem with text that implies that MD5 is
> bad, because I don't know of data that supports such an assertion.
> 
> Also, it doesn't seem like a good idea for the timestamp spec to give
> very different signals from the other security specs.  If there really
> is good reason to say these kinds of things about MD5, let's have them
> identified.  (German authorities are not a good reason.  Cryptanalysis
> that shows weaknesses of interesting size would be.)  If the issues
> are real, changes to MD5 text should be applied across the board.
> 
>       paul
> 

Date: Mon, 19 Jun 2000 18:54:22 -0700
From: Aram Perez <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
To: PKIX Mailing List <[email-masked]>

Hi Terry,

> From: [email-masked] (Terry Hayes)
> Date: Mon, 19 Jun 2000 10:16:34 -0700
> To: Stefan Santesson <[email-masked]>
> Cc: Stephen Kent <[email-masked]>, PKIX Mailing List <[email-masked]>
> Subject: Re: Can we form certificates with just name and e-mail address
> 
> Stefan Santesson wrote:
> 
>> ....
>> 
>> Why can't an e-mail address be part of a reasonable DN? (I guess that's
>> what the current text implies)
>> 
> 
> There is no reason that it can't be.  In fact, I believe that e=[email-masked]
> is a
> perfectly good DN.  It's probably not a good DN in the X.509 world, since it
> isn't
> very helpful in locating the portion of the "global" directory that actually
> contains the entry.  It is a unique name and probably will work in many LDAP
> or
> other directory environments.

I haven't seen any provide this answer so here I go: Someone can correct my
ASN.1, but a reason you shouldn't use "e=[email-masked]" in a/or as a DN is
that it does not meet the ASN.1 rules for a DN (the '@' symbol is not in one
of the valid character sets for DNs). There are a number of "public CAs"
that do put the '@' in a DN, but technically they are incorrect.

Regards,
Aram Perez

[snip]

From: Michael Zolotarev <[email-masked]>
To: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: Private Key Cloning
Date: Tue, 20 Jun 2000 10:38:35 +1000

> 
> And it doesn't seem to present insurmountable obstacles to load
> balancing ... why shouldn't each server have its own signature key?
> Is there a reason not to use N certificates with identical
> distinguished names and different public keys?
> 

I can see a problem with it with self-signed TSA certificates. Normally, a
client would be configured to directly trust THAT [self-signed] TSA cert.
Having a set of self-signed TSA certificates would be a configuration
nightmare for the clients. And then you add another crypto box to your load
balancing array on TSS, and then another one...

M

Date: Tue, 20 Jun 2000 00:50:22 +0200
To: Stephen Kent <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Cc: "PKIX Mailing List" <[email-masked]>

Steve,

Thank's for useful input. Just to round this up, can you confirm the 
conclusion that issuing certificates where subjects are represented by just 
e-mail address + givenName + surname (and maybe also country) is simply not 
possible.

The name must simply be combined with a serialNumber attribute or some 
other information that makes the name (with e-mail address excluded) a 
reasonable DN.

Right?

/Stefan

At 15:12 2000-06-19 -0400, Stephen Kent wrote:
>Stefan,
>
>>Steve,
>>
>><snip>
>>At 14:13 2000-06-16 -0400, you wrote:
>>>Christopher,
>>>
>>>>You put your common name (or given name + surname) in the SubjectName field
>>>>and your e-mail address in the rfc822Name field in a SubjectAlternativeName
>>>>field extension.  I don't think that it is too important if the SubjectName
>>>>is not unique; the combination of SubjectName and SerialNo has to be 
>>>>unique.
>>>
>>>We have had this discussion in this list.  The decision was that if 
>>>you're going to use a DN field (subject name or a directory name as an 
>>>alt name) then the contents should be "reasonable" in a directory 
>>>context.  That's why, when Denis Pinkas proposed a name form built from 
>>>DN attributes but not consistent with real directory use, he agreed to 
>>>define a new data type for it.  The bottom line is that just because a 
>>>name is constructed from directory attributes, that does not make it a 
>>>reasonable DN.
>>Rest deleted ....
>>
>>So I guess you confirm my conclusion that givenName + surname in the 
>>subject field, or as a directory name in alt name, does NOT by itself 
>>form a reasonable DN. Especially since there will be duplicate names.
>
>Right.
>
>>
>>So the only thing left seams to be putting the names in 
>>SubjectDirectoryAttributes but I have problems/thoughts with that:
>>
>>1) What will the current installed base of products say about that?
>
>I don't know.  Many would probably ignore attributes in that extension.
>
>>2) The latest X.509 version implies that attributes stored in the 
>>SubjectDirectoryAttributes are primary for authorization and not part of 
>>the subjects name.
>
>Right again.
>
>>It seams that we have no where to go.
>>
>>Why can't an e-mail address be part of a reasonable DN? (I guess that's 
>>what the current text implies)
>
>The argument is that a DN is the name of an entry in the DIT. One would 
>not create a schema where a e-mail address was tacked onto the end of an 
>otherwise good DN. It would create an additional layer of the tree that 
>served no purpose, as it dangles under the real user entry.  An e-mail 
>address is an alternative way of identifying an entity. Thus it is a 
>perfectly fine attribute for a directory entry, but it makes no sense as 
>an added attribute in a DN.
>
>Steve

From: "Eissa, Mohamed" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Certificate Retrieval from LDAP/CA
Date: Mon, 19 Jun 2000 13:12:00 -0700

Hi,

In general, after a user submits a certificate request, is it better to
retrieve issued certificates from LDAP server? or from CA server? and why? 

Also, is PKIX capable of retrieving certificates from LDAP and CA servers or
CAs only?

Thanks,
Mohamed

Date: Mon, 19 Jun 2000 16:11:24 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: A Heretic's view of Certificates
Cc: "PKIX-List" <[email-masked]>

Anders,

Part of this material, like the Schneier and Ellison article, makes 
the mistake of equating X.509 with the trusted third party model of 
VeriSign, CyberTrust, etc.  The figure in Section 4 illustrates this 
bias. The author acts as thought the 10 point list from that article 
is some sort of holy grail, rather than what is really was, i.e., a 
list of points of a length inspired by David Letterman.

The discussion of revocation is a bit naive. It seems to assume a 
push model, whereas traditional X.509 is pull, as is OCSP.  The 
argument about the implied net traffic associated with maintaining 
CRLs for a very large population is just  hand waving, with no good 
analysis.

The author places way too much emphasis on the browser model of a 
PKI, which is not a very good one, especially for the B2B 
transactions that are the focus of the article.  Again, a strawman.

The author's most significant criticisms of current PKI models are 
contained in Section 5, and there are several seriously flawed 
arguments. For example, he claims that some of the conditions that he 
sets as requirements cannot be met because existing (already issued) 
certs do not meet these requirements.  This is an interesting 
criticism, since the suggestion is that one can develop and deploy a 
new, different system (of the author's design) but cannot reissue 
certs to meet his declared requirements!  He misunderstands options 
for retention of certs and CRLs in support of NR, and argues that 
anything that LDAP does not do now will not change.  (Anyone who has 
followed the progress of LDAP would know better!) More errors arise 
in this discussion, but one ought not be surprised since the goal of 
this section is as a strawman to motivate the author's proposal.

Most, if not all, of what the author proposes, in Section 7, can be 
effected with X.509 certificates, based on PKI models that are 
organizational and/or geopolitical in scope, rather than TTP-based 
PKIs.  Some details of his proposals require changes (or usage 
restrictions) to current e-mail and web protocols. (For example, the 
function assigned to a secure e-mail proxy could be effected using 
the S/MIME triple-wrapping feature. The author alludes to signing an 
"SMTP envelope," which causes me to question the depth of his 
protocol knowledge.)  If these functions were deemed important, they 
could be supported just as well with X.509 as with his newly minted 
"credentials."  Other aspects of this model merely reflect 
implementation choices for such PKI elements as certification policy 
statements.  Some aspects of model also appears to be consistent with 
the ongoing PKIX work on delegated cert path validation, for those 
who desire to adopt this approach. The model is thus a mix of new 
data types, implementation options, and a few assurance mandates.

Finally, when one gets to the end of this text, it appears to be 
promotional (marketing) material for some products/services that the 
author is hoping to sell.

So, Anders, what exactly was your point?

Steve

From: Peter Sylvester <[email-masked]>
Date: Mon, 19 Jun 2000 21:36:16 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: RE: TSP Draft 08
Cc: [email-masked]

> 
> Peter,
> 
> I disagree that the addition of the ordering flag is creating any
> incompatibility issue since the TSA document is still only an Internet Draft
> that should not have been used to develop any commercial product until it
> becomes an RFC. In addition, I think it is much more meaningful to require
> the flag to be present to indicate that ordering is supported as currently
> mandated by the latest TSA document.

I did not say that the changings had created any incompatibility in
commercial products. 

I have said the spec is incompatible with the previous texts
Some parts of the text had been 'stable' since two years or so, and
get suddenly changed. Well, the token format is so small, that 
modifications of the actual syntax do not really influence product
designers to prepare all the other stuff. 

An implementation that used draft 7 spec and did not
set accuracy and by used a serialnumber that contains some encoded value
can easily retransform the serialnumber into genTime with the need
of using ordering for comparisions. 
Thje only problem is that when you receive such a time stamp, 
it doesn't tell that there is ordering.   

Since the very beginning the ordering was defined solely by the order
of the serialnumber. There was no even mention about the order of the genTime
values. Thus you could have all kinds of equal genTime values and 
even genTimes in different order than the serialnumber. 

In version 8 the serialnumber of the timestamp has no real purpose anymore
inside this protocol; it is not used at all in any
other protocol elements like in crls or esscertid etc. 

To resume (somewhat flame) : I disagree with Ed Gerck; the model is not broken,
there is simply no service model.   

> 
> I agree however that there must be a way for a TSA to publish which of the
> ordering services it supports. As a minimum this should be done through the
> TSA's policy and it could possibly be done through the Subject Information
> Access (SIA) extension from the son of RFC 2459 if it contained a similar
> ordering flag. By using the reqPolicy field a requester could then request
> the appropriate service if a TSA offers different ordering services.
I would like to repeat a question that I had already asked several times
on that list: An equivalent of SIA was in drafts of X.509 and 2459. 
When did this disappear and why? There were two extensions, the other
one was telling something about a CA subject. 

> 
> I also agree that the document should indicate if a TSA has to set the
> ordering in a identical way in ALL of its time stamps. I would think that if
> a TSA explicitly indicate that it will not support ordering (e.g. through
> the TSA's policy or the SIA extension), Time Stamp tokens issued from this
> TSA MUST NEVER have the ordering field set to true. However, if a TSA
> explicitly indicate that it will support ordering, all Time Stamp tokens
> issued from this TSA SHOULD have the ordering field set to true unless the
> TSA can not longer do this because of some technical problems. This would
> then be a good reason to use the value of one (1) in the structure
> "PKIStatus" (i.e. grantedWithMods).

You suggest that a TSA that provides an ordered set may want to switch 
to a reduced service. 

Why not just giving an error? An application that really need an order
would have to loop and reask until a orderable stamp is returned. 
If the order is not necessary then I would use the other type of service. 

Or, if grantedWithMods is done, one can simply add a failurebit indicating
that 'order not guaranteed contrary of what is indicated in the TSA's cert.'

/P

From: [email-masked]
To: [email-masked]
Date: Mon, 19 Jun 2000 15:24:05 -0400
Subject: Re: Private Key Cloning

The issue is relevant only for for a very basic PKI.  The wish is to have a
single trust anchor of one public key, no sub-CAs, yet assure availability and
load balance the CA service by cloned copies of the CA server (and its key).
This scenario pre-empts by definition each server having its own key.  However,
it also conflicts with the no-copy rule.
-Gene Hilborn

[email-masked] on 06/19/2000 02:21:34 PM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: Private Key Cloning

> From: Paul Koning <[email-masked]>
> Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT)
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: Re: Private Key Cloning
>
> >>>>> "FRousseau" == FRousseau  <[email-masked]> writes:
>
>  FRousseau> Juergen, If a private key generated within a hardware
>  FRousseau> cryptographic module is securely wrapped within that same
>  FRousseau> module, is then exported to another similar hardware
>  FRousseau> cryptographic module through an authenticated key exchange
>  FRousseau> where it is unwrapped and both of these private keys are
>  FRousseau> then used to perform electronic signatures in a load
>  FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean
>  FRousseau> this would not be legal in Germany?
>
> How would you guarantee that there's no man in the middle?  The only
> way would be to have a prior out of band secure setup of
> authenticating data, such as a shared secret or public keys used for
> this key exchange process.  While the user of such a device can ensure
> that this is done right, the manufacturer of the devices cannot.
>
> It doesn't surprise me at all to see devices that don't allow this.
> It makes good security sense to omit such a capability.
>
>    paul

And it doesn't seem to present insurmountable obstacles to load
balancing ... why shouldn't each server have its own signature key?
Is there a reason not to use N certificates with identical
distinguished names and different public keys?

Date: Mon, 19 Jun 2000 15:15:47 -0400
To: Michael Zolotarev <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Can we form certificates with just name and e-mail address
Cc: Stefan Santesson <[email-masked]>, PKIX Mailing List <[email-masked]>

Zolotarev,

>Sorry, but I'm not quite getting what is so problematic with what
>Christopher and Oscar proposed:
>
>What really stops me from leaving Subject field empty, and including BOTH my
>e-mail address (as RFC822name) and my name/surname as a proper(!)
>DirectoryName into SubjectAltName field?
>
>I believe that the root of the problem is in [mis]interpretation of the
>"uniqueness of the name" requirement. The document says in (4.1.2.6
>Subject):
>-------------
>    Where it is non-empty, the subject field MUST contain an X.500 dis-
>    tinguished 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.
>--------------
>This is what Stefan was referring to, right?
>
>However, there is NO such uniqueness requirement for the DN included into
>the SubjectAltName. Or I've missed one. So I do not see a problem with
>having a SubjectAltName containing non_unique DN, as long as the rest of the
>information in the extension makes it unique.

We're in the process of revising the alt subject name text, and one 
of the proposed changes is to treat it as stringently as the subject 
name.  I believe text citing the uniqueness check, as well as CA 
verification, has been circulated. Irrespective of this, other 
traffic I've just sent discusses the question of whether/how an email 
address fits into a DN.

Steve

Date: Mon, 19 Jun 2000 15:12:51 -0400
To: Stefan Santesson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Cc: "PKIX Mailing List" <[email-masked]>

Stefan,

>Steve,
>
><snip>
>At 14:13 2000-06-16 -0400, you wrote:
>>Christopher,
>>
>>>You put your common name (or given name + surname) in the SubjectName field
>>>and your e-mail address in the rfc822Name field in a SubjectAlternativeName
>>>field extension.  I don't think that it is too important if the SubjectName
>>>is not unique; the combination of SubjectName and SerialNo has to be unique.
>>
>>We have had this discussion in this list.  The decision was that if 
>>you're going to use a DN field (subject name or a directory name as 
>>an alt name) then the contents should be "reasonable" in a 
>>directory context.  That's why, when Denis Pinkas proposed a name 
>>form built from DN attributes but not consistent with real 
>>directory use, he agreed to define a new data type for it.  The 
>>bottom line is that just because a name is constructed from 
>>directory attributes, that does not make it a reasonable DN.
>Rest deleted ....
>
>So I guess you confirm my conclusion that givenName + surname in the 
>subject field, or as a directory name in alt name, does NOT by 
>itself form a reasonable DN. Especially since there will be 
>duplicate names.

Right.

>
>So the only thing left seams to be putting the names in 
>SubjectDirectoryAttributes but I have problems/thoughts with that:
>
>1) What will the current installed base of products say about that?

I don't know.  Many would probably ignore attributes in that extension.

>2) The latest X.509 version implies that attributes stored in the 
>SubjectDirectoryAttributes are primary for authorization and not 
>part of the subjects name.

Right again.

>It seams that we have no where to go.
>
>Why can't an e-mail address be part of a reasonable DN? (I guess 
>that's what the current text implies)

The argument is that a DN is the name of an entry in the DIT. One 
would not create a schema where a e-mail address was tacked onto the 
end of an otherwise good DN. It would create an additional layer of 
the tree that served no purpose, as it dangles under the real user 
entry.  An e-mail address is an alternative way of identifying an 
entity. Thus it is a perfectly fine attribute for a directory entry, 
but it makes no sense as an added attribute in a DN.

Steve

Date: Mon, 19 Jun 2000 14:52:56 -0400
To: [email-masked] (Terry Hayes)
From: Stephen Kent <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Cc: Stefan Santesson <[email-masked]>, PKIX Mailing List <[email-masked]>

Terry,

>Stefan Santesson wrote:
>
>  > ....
>  >
>  > Why can't an e-mail address be part of a reasonable DN? (I guess that's
>  > what the current text implies)
>  >
>
>There is no reason that it can't be.  In fact, I believe that 
>e=[email-masked] is a
>perfectly good DN.  It's probably not a good DN in the X.509 world, 
>since it isn't
>very helpful in locating the portion of the "global" directory that actually
>contains the entry.  It is a unique name and probably will work in 
>many LDAP or
>other directory environments.

I think you mean in the "X.500 world" not "the X.509 world."  X.509 
deals with certs and CRLs, whereas X.500 is the broader directory 
environment.  DNs are X.500 constructs, not X.509 constructs, so it 
is in the directory context that one ought to evaluate the 
appropriateness of a candidate DN.  In that context, the example you 
provide is not a good one, e.g., for the searching reasons you cite, 
as well as others.

David Kemp's suggestion is an example of what one could reasonably do 
to map a DNS name into the DIT.  However, I disagree with David in 
that a real DN, if it does not begin with a country code attribute, 
should begin with an international organization attribute (e.g., for 
the OCRC, NATO, UN, etc.).  The DNS, for legacy reasons, has a 
handful of TLDs that are not country names, which has been the source 
of numerous name battles, scaling problems, etc.

>The RFC deprecates using an email component of the DN as the RFC822 name for
>delivering email.  This means that you need to put the email address in the
>Subject Alternate Name extension as well, to allow S/MIME (and 
>other) applications
>to find it there.  It does not mean that it is disallowed as a 
>component in the
>DN.

I don't think I would characterize the 2459 discussion of e-mail 
addresses in names in quite this way.  What section 4.1.2.6 says is 
that newly generated certs should not contain an EmailAddress 
attribute in the Subject name field. Instead, the preferred approach 
is to place the e-mail address in a subject alt name of the type 
rfc822name.  If a non-null subject name is present, it may include an 
EmailAddress attribute, but such inclusion is permitted for backwards 
compatibility, and it is deprecated.

The overall message from this text is that EmailAddress is a 
directory attribute that has no place in a DN, but we allow it, with 
prejudice, to avoid breaking existing (S/MIME) systems.  Going 
forward, the right approach is to put an e-mail address into the 
subject alt name using the name type designed to carry it.

Steve

Date: Mon, 19 Jun 2000 17:44:17 +0200
To: [email-masked], [email-masked]
From: Volker Hammer <[email-masked]>
Subject: Re: Private Key Cloning
Cc: [email-masked]

Hi,

>Juergen, 
>
>If a private key generated within a hardware cryptographic module is securely wrapped within that same module, is then exported to another similar hardware cryptographic module through an authenticated key exchange where it is unwrapped and both of these private keys are then used to perform electronic signatures in a load balancing situation (e.g. OCSP or TSA server), do you mean this would not be legal in Germany?

why you don't want to use two (or more) different key-pairs for different / fallback servers? For every key a similar certificate can be issued. This should not be a problem except for root certificates.  For TSA or OCSP servers key cloning seems not to be necessary from my point of view.

Regards
Volker Hammer.
--------------------------------------------------------
Dr.-Ing. Volker Hammer
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-458, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
--------------------------------------------------------
PGP-Fingerprint    3C9C AD64 AC6B 64CC  FA6B AE8D 2A5D 462D

Date: Mon, 19 Jun 2000 14:21:34 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Private Key Cloning
To: [email-masked]
Content-MD5: NG2ebhAazn8tGK/TbEmeFA==

> From: Paul Koning <[email-masked]>
> Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT)
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: Re: Private Key Cloning
> 
> >>>>> "FRousseau" == FRousseau  <[email-masked]> writes:
> 
>  FRousseau> Juergen, If a private key generated within a hardware
>  FRousseau> cryptographic module is securely wrapped within that same
>  FRousseau> module, is then exported to another similar hardware
>  FRousseau> cryptographic module through an authenticated key exchange
>  FRousseau> where it is unwrapped and both of these private keys are
>  FRousseau> then used to perform electronic signatures in a load
>  FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean
>  FRousseau> this would not be legal in Germany?
> 
> How would you guarantee that there's no man in the middle?  The only
> way would be to have a prior out of band secure setup of
> authenticating data, such as a shared secret or public keys used for
> this key exchange process.  While the user of such a device can ensure
> that this is done right, the manufacturer of the devices cannot.
> 
> It doesn't surprise me at all to see devices that don't allow this.
> It makes good security sense to omit such a capability.
> 
>    paul

And it doesn't seem to present insurmountable obstacles to load
balancing ... why shouldn't each server have its own signature key?
Is there a reason not to use N certificates with identical
distinguished names and different public keys?

Date: Mon, 19 Jun 2000 13:42:52 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
To: [email-masked]
Content-MD5: 4WQznHPMAzrZebsnHHg4Cw==

> From: Stefan Santesson <[email-masked]>
>
>   ...
>
> Why can't an e-mail address be part of a reasonable DN? (I guess that's 
> what the current text implies)
> 
> /Stefan

DNS is a (the only?) universal-coverage name registration system, and
although one would never know it by examining current X.509
certificates, "reasonable" does not have to mean "beginning with a
Country= RDN".  So one reasonable DN might be:

  "DC=se, DC=accurata, SN=stefan + CN=Stefan Santesson"

This is semantically identical to a null DN and an rfc822Name in the
subjectAltName extension, and if there were an RFC spelling out some
equivalence rules, applications might someday be able to translate
between the rfc822Name format and the RDNSequence format as required.

Date: Mon, 19 Jun 2000 10:16:34 -0700
From: [email-masked] (Terry Hayes)
To: Stefan Santesson <[email-masked]>
CC: Stephen Kent <[email-masked]>, PKIX Mailing List <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address

Stefan Santesson wrote:

> ....
>
> Why can't an e-mail address be part of a reasonable DN? (I guess that's
> what the current text implies)
>

There is no reason that it can't be.  In fact, I believe that e=[email-masked] is a
perfectly good DN.  It's probably not a good DN in the X.509 world, since it isn't
very helpful in locating the portion of the "global" directory that actually
contains the entry.  It is a unique name and probably will work in many LDAP or
other directory environments.

The RFC deprecates using an email component of the DN as the RFC822 name for
delivering email.  This means that you need to put the email address in the
Subject Alternate Name extension as well, to allow S/MIME (and other) applications
to find it there.  It does not mean that it is disallowed as a component in the
DN.

Terry

Date: Mon, 19 Jun 2000 10:09:53 -0700 (PDT)
From: Sharon Liu <[email-masked]>
Reply-To: Sharon Liu <[email-masked]>
Subject: Re: Why is Java still crypto-crippled?
To: [email-masked]
Cc: [email-masked]
Content-MD5: UN12bPu1ZTtFMm8JP9ZvOw==

Anders,

There are on-going works to make strong crypto into JDK.

Sun's JCE (Java Cryptography Extension) 1.2.1 is exportable.
It is currently in Beta, and its global distribution has
restrictions on available crypto strength.

Sun has filed a new JCE export application to remove the
crypto restrictions in JCE global distribution. Once that
application gets approved by the U.S. government, we'll have 
a single JCE distribution for both domestic and global users.

Then we plan to move JCE into JDK (note: JCE was initially
introduced as a Java 2 extension due to the U.S export
regulations). This is depend on the Java Community Process.

Hope this helps a bit.

Thanks,
Sharon 

------------- Begin Forwarded Message ------------- 
From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>
Subject: Why is Java still crypto-crippled?
Date: Sat, 17 Jun 2000 14:44:25 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id 
EAA13351
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[email-masked]?body=unsubscribe

I have since quite a while been using W2K (Bill, it IS great!)  using strong 
crypto
although I live in Europe.   But why can't I get that for JDK?  Without special 
permissions.

This is a *serious* threat to Java to be dependent on third-party tools when
the "other guy" has it all built-in!

Anders

Not religious about Java but likes it anyway.

------------- End Forwarded Message -------------

From: Paul Koning <[email-masked]>
Date: Mon, 19 Jun 2000 10:59:53 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

>>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:

 Joerg> Comments inline.
 >> TSA implementations MUST support SHA-1.  TSA implementations
 >> SHOULD support MD5.

 Joerg> I think there are good reasons not to use MD5 in time
 Joerg> stamps. They should use a strong hash function in order to
 Joerg> achive long validity periods. MD5 is likely to be unsafe (=not
 Joerg> collision free) soon and is already discuraged by german
 Joerg> authorities.

 Joerg> IF we add a section about algorithms, it should maybe read:
 Joerg> "TSA implementations MUST support SHA-1.  TSA implementations
 Joerg> SHOULD NOT support MD5.". But I think such a section is not
 Joerg> very necessary.

IANAC, but from what I understand the currently known attacks on MD5
are nowhere near strong enough to justify that.  

I don't have a problem with the current text (SHA-1 required, MD5
recommended).  I do have a problem with text that implies that MD5 is
bad, because I don't know of data that supports such an assertion.

Also, it doesn't seem like a good idea for the timestamp spec to give
very different signals from the other security specs.  If there really
is good reason to say these kinds of things about MD5, let's have them
identified.  (German authorities are not a good reason.  Cryptanalysis
that shows weaknesses of interesting size would be.)  If the issues
are real, changes to MD5 text should be applied across the board.

      paul

From: Paul Koning <[email-masked]>
Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Private Key Cloning

>>>>> "FRousseau" == FRousseau  <[email-masked]> writes:

 FRousseau> Juergen, If a private key generated within a hardware
 FRousseau> cryptographic module is securely wrapped within that same
 FRousseau> module, is then exported to another similar hardware
 FRousseau> cryptographic module through an authenticated key exchange
 FRousseau> where it is unwrapped and both of these private keys are
 FRousseau> then used to perform electronic signatures in a load
 FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean
 FRousseau> this would not be legal in Germany?

How would you guarantee that there's no man in the middle?  The only
way would be to have a prior out of band secure setup of
authenticating data, such as a shared secret or public keys used for
this key exchange process.  While the user of such a device can ensure
that this is done right, the manufacturer of the devices cannot.

It doesn't surprise me at all to see devices that don't allow this.
It makes good security sense to omit such a capability.

   paul

Date: Mon, 19 Jun 2000 16:37:39 +0200
To: [email-masked]
From: Juergen Brauckmann <[email-masked]>
Subject: Re: Private Key Cloning
Cc: [email-masked]

At 10:11 19.06.00 -0400, you wrote:=20

<flushright>><smaller>If a private key generated within a hardware
cryptographic module is securely wrapped within that=20

>same module, is then exported to another similar hardware cryptographic
module through an=20

>authenticated key exchange where it is unwrapped and both of these
private keys are then used to=20

>perform electronic signatures in a load balancing situation (e.g. OCSP
or TSA server), do you mean=20

>this would not be legal in Germany?

</smaller>It is of course legal if you don't want to conform to the
German Digital Signature Act.

It is not legal if you operate according to that Act. In fact it's a
requirement to the equipment that it's not possible to duplicate the
key.

It makes some sense to forbid a single user to duplicate it's key if that
key is to be used for "valuable" signatures (this minimizes the risk that
the key may be stolen or lost unnoticed). The problem is that the current
German Signature Act does not take into account that the scenario you
described above is necessary for servers.

Regards,

  Juergen 

--=20

Juergen Brauckmann             Tel.:  040 / 8080 26 311

TC TrustCenter GmbH            Fax.:  040 / 8080 26 126

Sonninstra=DFe 24-28   	    mailto:[email-masked]

20097 Hamburg 		    http://www.trustcenter.de=09

Date: Mon, 19 Jun 2000 11:24:37 +0200
To: [email-masked]
From: "Juergen Brauckmann" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

At 11:24 19.06.00 +0200, Joerg Seidel wrote:
>> If a TSA has more than one key for performance purposes, I would assume
they
>> are just copies of the same private key cloned in different cryptographic
>> modules for performance and load balancing reasons.
>
>Since it is not possible with some cryptograpic modules to make copies of the
>private key...

And sometimes not legal... .

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]
Cc: [email-masked]
Subject: Private Key Cloning
Date: Mon, 19 Jun 2000 10:11:05 -0400

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

------_=_NextPart_001_01BFD9F8.4134A830
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Juergen,

If a private key generated within a hardware cryptographic module is
securely wrapped within that same module, is then exported to another
similar hardware cryptographic module through an authenticated key =
exchange
where it is unwrapped and both of these private keys are then used to
perform electronic signatures in a load balancing situation (e.g. OCSP =
or
TSA server), do you mean this would not be legal in Germany?

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: Juergen Brauckmann [mailto:[email-masked]]
Sent: Monday, June 19, 2000 5:25 AM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

At 11:24 19.06.00 +0200, Joerg Seidel wrote:
>> If a TSA has more than one key for performance purposes, I would =
assume
they
>> are just copies of the same private key cloned in different =
cryptographic
>> modules for performance and load balancing reasons.
>
>Since it is not possible with some cryptograpic modules to make copies =
of
the
>private key...

And sometimes not legal... .

Regards,
   Juergen

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

------_=_NextPart_001_01BFD9F8.4134A830
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.2650.12">
<TITLE>Private Key Cloning</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Juergen,</FONT>
</P>

<P><FONT SIZE=3D2>If a private key generated within a hardware =
cryptographic module is securely wrapped within that same module, is =
then exported to another similar hardware cryptographic module through =
an authenticated key exchange where it is unwrapped and both of these =
private keys are then used to perform electronic signatures in a load =
balancing situation (e.g. OCSP or TSA server), do you mean this would =
not be legal in Germany?</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Juergen Brauckmann [<A =
HREF=3D"mailto:[email-masked]">mailto:brauckmann@trustcenter.=
de</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, June 19, 2000 5:25 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: I-D =
ACTION:draft-ietf-pkix-time-stamp-08.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 11:24 19.06.00 +0200, Joerg Seidel wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; If a TSA has more than one key for =
performance purposes, I would assume</FONT>
<BR><FONT SIZE=3D2>they</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; are just copies of the same private key =
cloned in different cryptographic</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; modules for performance and load balancing =
reasons.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Since it is not possible with some cryptograpic =
modules to make copies of the</FONT>
<BR><FONT SIZE=3D2>&gt;private key...</FONT>
</P>

<P><FONT SIZE=3D2>And sometimes not legal... .</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Juergen</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Juergen =
Brauckmann&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; Tel.:&nbsp; 040 / 8080 26 311</FONT>
<BR><FONT SIZE=3D2>TC TrustCenter =
GmbH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax.:&nbsp; 040 / 8080 26 126</FONT>
<BR><FONT SIZE=3D2>Sonninstra=DFe 24-28&nbsp;&nbsp; &nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:[email-masked]">mailto:brauckmann@trustcenter.=
de</A></FONT>
<BR><FONT SIZE=3D2>20097 Hamburg &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.trustcenter.de" =
TARGET=3D"_blank">http://www.trustcenter.de</A>&nbsp;&nbsp; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD9F8.4134A830--

Date: Mon, 19 Jun 2000 11:24:37 +0200
To: [email-masked]
From: Juergen Brauckmann <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

At 11:24 19.06.00 +0200, Joerg Seidel wrote:
>> If a TSA has more than one key for performance purposes, I would assume
they
>> are just copies of the same private key cloned in different cryptographic
>> modules for performance and load balancing reasons.
>
>Since it is not possible with some cryptograpic modules to make copies of the
>private key...

And sometimes not legal... .

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: Mon, 19 Jun 2000 11:24:22 +0200
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: [email-masked]
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

Francois,

comments inline.

> If a TSA has more than one key for performance purposes, I would assume they
> are just copies of the same private key cloned in different cryptographic
> modules for performance and load balancing reasons.

Since it is not possible with some cryptograpic modules to make copies of the
private key...

> "The TSA MUST sign all time stamp messages with one or more keys reserved
> specifically for that purpose. A TSA MAY have distinct private keys to
> accommodate different policies, different algorithms and/or different key
> sizes."

... I suggest:
"The TSA MUST sign all time stamp messages with one or more keys reserved
specifically for that purpose. A TSA MAY have distinct private keys to
accommodate different policies, different algorithms, different key
sizes and/or to increase the performance."

> I agree that TSAs should not use MD5 in their time stamps and MUST only use
> strong hash functions (e.g. SHA-1, RIPEMD-160). However, there is nothing
> wrong
> for a requester to submit a message imprint containing a MD5 hash, which
> means
> that TSAs should be able accept request with MD5.

You are right. If a requester insists on using MD5 it is not up to the TSA to
explain him he shouldn't.

Joerg

-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

From: [email-masked]
To: "Christopher Williams" <[email-masked]>
Cc: "PKIX Mailing List" <[email-masked]>
Subject: Re: Do people have something against RSA? 
Date: Mon, 19 Jun 2000 09:43:19 +0200
Sender: [email-masked]

[email-masked] said:
> However, let's say that I implemented a standard, say TLS, and only
> included the mandatory cipher suite, DSA with ephemeral
> Diffie-Hellman, SHA-1 and 3-DES encryption.  You know what?  It
> wouldn't work with anything!  Everybody else's implementation uses RSA
> so mine has to as well, whether I like it or not. 

Is seems to me that your reasonoing is flawed in that you assume that
"everone else" will *not* include the *mandatory* cipher suite.
The whole idea of having mandatory cipher suites in the first place
is to assure at least one common fall back algorithm.

Best regards,
//Mats

From: Michael Zolotarev <[email-masked]>
To: Stefan Santesson <[email-masked]>, Stephen Kent <[email-masked]>
Cc: PKIX Mailing List <[email-masked]>
Subject: RE: Can we form certificates with just name and e-mail address
Date: Mon, 19 Jun 2000 14:44:12 +1000

Sorry, but I'm not quite getting what is so problematic with what
Christopher and Oscar proposed:

What really stops me from leaving Subject field empty, and including BOTH my
e-mail address (as RFC822name) and my name/surname as a proper(!)
DirectoryName into SubjectAltName field?
 
I believe that the root of the problem is in [mis]interpretation of the
"uniqueness of the name" requirement. The document says in (4.1.2.6
Subject):
-------------
   Where it is non-empty, the subject field MUST contain an X.500 dis-
   tinguished 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.
--------------
This is what Stefan was referring to, right?

However, there is NO such uniqueness requirement for the DN included into
the SubjectAltName. Or I've missed one. So I do not see a problem with
having a SubjectAltName containing non_unique DN, as long as the rest of the
information in the extension makes it unique.

Regards
Michael

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Monday, June 19, 2000 8:44 AM
> To: Stephen Kent
> Cc: PKIX Mailing List
> Subject: Re: Can we form certificates with just name and 
> e-mail address
> 
> 
> Steve,
> 
> <snip>
> At 14:13 2000-06-16 -0400, you wrote:
> >Christopher,
> >
> >>You put your common name (or given name + surname) in the 
> SubjectName field
> >>and your e-mail address in the rfc822Name field in a 
> SubjectAlternativeName
> >>field extension.  I don't think that it is too important if 
> the SubjectName
> >>is not unique; the combination of SubjectName and SerialNo 
> has to be unique.
> >
> >We have had this discussion in this list.  The decision was 
> that if you're 
> >going to use a DN field (subject name or a directory name as 
> an alt name) 
> >then the contents should be "reasonable" in a directory 
> context.  That's 
> >why, when Denis Pinkas proposed a name form built from DN 
> attributes but 
> >not consistent with real directory use, he agreed to define 
> a new data 
> >type for it.  The bottom line is that just because a name is 
> constructed 
> >from directory attributes, that does not make it a reasonable DN.
> Rest deleted ....
> 
> So I guess you confirm my conclusion that givenName + surname in the 
> subject field, or as a directory name in alt name, does NOT 
> by itself form 
> a reasonable DN. Especially since there will be duplicate names.
> 
> So the only thing left seams to be putting the names in 
> SubjectDirectoryAttributes but I have problems/thoughts with that:
> 
> 1) What will the current installed base of products say about that?
> 2) The latest X.509 version implies that attributes stored in the 
> SubjectDirectoryAttributes are primary for authorization and 
> not part of 
> the subjects name.
> 
> It seams that we have no where to go.
> 
> Why can't an e-mail address be part of a reasonable DN? (I 
> guess that's 
> what the current text implies)
> 
> /Stefan
> 

Date: Mon, 19 Jun 2000 00:43:48 +0200
To: Stephen Kent <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Cc: "PKIX Mailing List" <[email-masked]>

Steve,

<snip>
At 14:13 2000-06-16 -0400, you wrote:
>Christopher,
>
>>You put your common name (or given name + surname) in the SubjectName field
>>and your e-mail address in the rfc822Name field in a SubjectAlternativeName
>>field extension.  I don't think that it is too important if the SubjectName
>>is not unique; the combination of SubjectName and SerialNo has to be unique.
>
>We have had this discussion in this list.  The decision was that if you're 
>going to use a DN field (subject name or a directory name as an alt name) 
>then the contents should be "reasonable" in a directory context.  That's 
>why, when Denis Pinkas proposed a name form built from DN attributes but 
>not consistent with real directory use, he agreed to define a new data 
>type for it.  The bottom line is that just because a name is constructed 
>from directory attributes, that does not make it a reasonable DN.
Rest deleted ....

So I guess you confirm my conclusion that givenName + surname in the 
subject field, or as a directory name in alt name, does NOT by itself form 
a reasonable DN. Especially since there will be duplicate names.

So the only thing left seams to be putting the names in 
SubjectDirectoryAttributes but I have problems/thoughts with that:

1) What will the current installed base of products say about that?
2) The latest X.509 version implies that attributes stored in the 
SubjectDirectoryAttributes are primary for authorization and not part of 
the subjects name.

It seams that we have no where to go.

Why can't an e-mail address be part of a reasonable DN? (I guess that's 
what the current text implies)

/Stefan

Reply-To: <[email-masked]>
From: "denis bider" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, <[email-masked]>
Subject: Off-topic: crypto crippling
Date: Sat, 17 Jun 2000 15:40:58 +0200
Importance: Low

[I would have posted this to the sci.crypt newsgroup, but I dislike doing
that for several reasons - among them, slow message propagation, spam and
last but not the least, I do not have Usenet configured and it takes a while
to find a server that carries sci.crypt. Does anyone know of a regular
mailing list equivalent to the sci.crypt newsgroup?]

Actually,

I have heard a rumour that the '128-bit encryption' that Microsoft is
shipping with Windows 2000 has actually been tweaked in such a way that it
is only 128-bit when observed by a non-clued-in person, but is rather 40-bit
for the people who know how it has been designed.

In effect, rumour therefore has it that 88 bits out of the 128 are set in
such a way that it is extremely easy to find them for someone who knows how.
The French are supposed to have found this out, and they are supposed to
have been a little bit upset because of this fact.

I am not sure how much of this is actually the truth. The person I received
this information from might have confused this with the silent "3DES -> DES"
fallback in Windows that has been demonstrated lately.

Can anyone confirm or deny the above rumour?

Anyway. The bottom line is - I think people today are a little bit crazy to
use, and even buy, security software as executables without any kind of
access to the source code. It is plain stupid, and it gives the country
which supplied you with the binaries a perfect weapon for the information
wars that are due to ensue sooner or later. The world is not all roses all
the time. Remember the several-billion-dollar deal which was lost by the
European airplane manufacturer to Boeing because the USA was eavesdropping
on their conversations with the purchaser?

Iraq, Vatican and several others have learned this lesson when they bought
black-box crypto machines from Crypto AG, only to find out that the machine
transmits the encryption key almost in plaintext along with the encrypted
message. Which, hence, was easily recoverable by folks from the NSA and from
the German intelligence agency.

denis

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: 17. junij 2000 14:44
To: PKIX-List
Subject: Why is Java still crypto-crippled?

I have since quite a while been using W2K (Bill, it IS great!)  using strong
crypto
although I live in Europe.   But why can't I get that for JDK?  Without
special permissions.

This is a *serious* threat to Java to be dependent on third-party tools when
the "other guy" has it all built-in!

Anders

Not religious about Java but likes it anyway.

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>
Subject: Why is Java still crypto-crippled?
Date: Sat, 17 Jun 2000 14:44:25 +0200

I have since quite a while been using W2K (Bill, it IS great!)  using strong crypto
although I live in Europe.   But why can't I get that for JDK?  Without special permissions.

This is a *serious* threat to Java to be dependent on third-party tools when
the "other guy" has it all built-in!

Anders

Not religious about Java but likes it anyway.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, "PKIX-List" <[email-masked]>
Subject: A Heretic's view of Certificates
Date: Sat, 17 Jun 2000 10:34:36 +0200

Interesting reading.  Particularly for PKI "fundamentalists"....

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, June 16, 2000 22:14
Subject: another view of certificates

>
>
>for another view of certificates
>
>http://www.DGA.co.uk/customer/publicdo.nsf/public/WP-HERESY
>
>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Do people have something against RSA?
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 17 Jun 2000 07:41:24 (NZST)

"Christopher Williams" <[email-masked]>

>Can we please start mandating RSA in future?  It will make implementing
>standards much easier and remove the FUD because I haven't incorporated
>support for Diffie-Hellman!

Calm down, calm down, it's not that bad.  The way it works is that everyone
pretends to do DSA+DH until September, then stops pretending on the 20th.  The
"shall DSA, may RSA" wording of the standards is a bit confusing at first, but
it all works out in the long run.

(You're new to this, right? :-).

Peter.

Date: Fri, 16 Jun 2000 14:13:47 -0400
To: "Christopher Williams" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Cc: "PKIX Mailing List" <[email-masked]>

Christopher,

>You put your common name (or given name + surname) in the SubjectName field
>and your e-mail address in the rfc822Name field in a SubjectAlternativeName
>field extension.  I don't think that it is too important if the SubjectName
>is not unique; the combination of SubjectName and SerialNo has to be unique.

We have had this discussion in this list.  The decision was that if 
you're going to use a DN field (subject name or a directory name as 
an alt name) then the contents should be "reasonable" in a directory 
context.  That's why, when Denis Pinkas proposed a name form built 
from DN attributes but not consistent with real directory use, he 
agreed to define a new data type for it.  The bottom line is that 
just because a name is constructed from directory attributes, that 
does not make it a reasonable DN.

>Alternatively, you can leave the SubjectName field blank (unusual but the
>standard permits it) and put your common name in a directoryName field in
>your alternative name and your e-mail address in an rfc822Name.  While
>you're at it, why not include the URL of your homepage in a uRI field!
>Remember that a SubjectAlternativeName is type GeneralNames, which means it
>can have any number of elements.

But, it is still of type DirectoryName and thus should be a name 
suitable for use in a directory, as noted above.

>On the subject of alternative names, what exactly is an ediPartyName,
>anybody?  I know that EDI stands for "Electronic Data Interchange" but I
>don't know anything more.

I always assumed the EDI folks have really exclusive parties and 
never invite the rest of us.

>
>Also, I have to say that I think it's crazy that your e-mail address has to
>go into an extension, or can only be placed in the name field by means of a
>(deprecated) kludge.  In a world context, your e-mail address is as
>important (at least) as your X-500 characteristics.  If I get a personal
>certificate, I don't have an "organization" or an "organizational unit"  -
>it's just me.

I agree that having a cert with an alt subject name that is JUST an 
RFC822 name would be fine.  Your comments re O and OU are correct, 
but perhaps you are missing some context here.  The directory 
distinguishes between organizational persons and residential persons. 
The latter don't contain an O or OU attribute.

Steve

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Re: Do people have something against RSA?
Date: Fri, 16 Jun 2000 18:35:18 +0100

OK, maybe RSADSI are litigious and awkward to deal with.  I don't know, I've
never dealt with them.  However, let's say that I implemented a standard,
say TLS, and only included the mandatory cipher suite, DSA with ephemeral
Diffie-Hellman, SHA-1 and 3-DES encryption.  You know what?  It wouldn't
work with anything!  Everybody else's implementation uses RSA so mine has to
as well, whether I like it or not.  The reality is that RSA is mandatory and
DSA the nice optional extra which adds spice and competitive advantage.

As to whether the future belongs to RSA or maybe some recent innovation like
ECC or some as-yet uninvented scheme, as Microsoft shows, it's not being the
best that makes you the winner, it's being the most widespread.

So, given that:
 - RSA's patent is due to expire (news to me, but welcome news)
 - DSA has patent issues in Europe
 - Everybody uses RSA anyway; very few use DSA

Can we please start mandating RSA in future?  It will make implementing
standards much easier and remove the FUD because I haven't incorporated
support for Diffie-Hellman!

Christopher Williams

Software engineer, NetLexis Ltd.
http://www.netlexis.com "Intelligent Trust"

From: "Christopher Williams" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: "PKIX Mailing List" <[email-masked]>
Subject: Re: Can we form certificates with just name and e-mail address
Date: Fri, 16 Jun 2000 18:07:47 +0100

You put your common name (or given name + surname) in the SubjectName field
and your e-mail address in the rfc822Name field in a SubjectAlternativeName
field extension.  I don't think that it is too important if the SubjectName
is not unique; the combination of SubjectName and SerialNo has to be unique.

Alternatively, you can leave the SubjectName field blank (unusual but the
standard permits it) and put your common name in a directoryName field in
your alternative name and your e-mail address in an rfc822Name.  While
you're at it, why not include the URL of your homepage in a uRI field!
Remember that a SubjectAlternativeName is type GeneralNames, which means it
can have any number of elements.

On the subject of alternative names, what exactly is an ediPartyName,
anybody?  I know that EDI stands for "Electronic Data Interchange" but I
don't know anything more.

Also, I have to say that I think it's crazy that your e-mail address has to
go into an extension, or can only be placed in the name field by means of a
(deprecated) kludge.  In a world context, your e-mail address is as
important (at least) as your X-500 characteristics.  If I get a personal
certificate, I don't have an "organization" or an "organizational unit"  -
it's just me.

Christopher Williams

Software engineer, NetLexis Ltd.
http://www.netlexis.com "Intelligent Trust"

From: "Jacoby, Jeffrey" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: CRMF (RFC 2511) and password-based MAC question
Date: Fri, 16 Jun 2000 09:31:33 -0700

Hi,

In section 4.4.1 of RFC 2511, on generating a
password-based MAC value, there is no recommended
minimum (or maximum) length for the salt value.

Does anyone have a recommendation for salt length?
What's typically used in practice or existing applications?

Thanks,

Jeff Jacoby

phone: (650) 295-7569         
email: [email-masked]        

RSA Security, SMDC
2755 Campus Drive
San Mateo, CA 94403

From: Hal Lockhart <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: "'PKIX Mailing List'" <[email-masked]>
Subject: RE: Do people have something against RSA?
Date: Fri, 16 Jun 2000 12:14:29 -0400

> The TSP draft is well along and I don't envision holding it up, 
> waiting for the RSA patent to expire.  The document adopted an 
> algorithm approach consistent with IESG policy, and with other 
> crypto-based RFCs.  Let's just stick with that.

I agree and predict that algorithm support will be a frequent type of
modification. For example, all the specs that deal with symmetric algorithms
will upgrade to AES, most likely as the required choice, once that selection
occurs.

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [email-masked]
F: 1-508-229-0338             www.entegrity.com
=======================================================

Date: Fri, 16 Jun 2000 18:07:35 +0200
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: Can we form certificates with just name and e-mail address

This is a cryptographically signed message in MIME format.

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

Stefan Santesson wrote:
> How do you form a certificate according to PKIX where the subjects name
> only consists of a name (commonName or GivenName + surname) and an e-mail
> address ?? It seams to be virtually impossible to do this.
>
> [...]
>
> What has historic debates concluded in?

I don't actually know the history here, but I would wager a suggestion:

Could you not leave the subject name empty and include both a rfc822Name
and a directoryName (which would then contain your given name and
surname attributes) in the subject alternate name extension?

//oscar
--------------ms5659E2AFB7538B3B3AFF4A69
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

--------------ms5659E2AFB7538B3B3AFF4A69--

Date: Fri, 16 Jun 2000 11:55:55 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Do people have something against RSA?
Cc: "'PKIX Mailing List'" <[email-masked]>

Denis,

The TSP draft is well along and I don't envision holding it up, 
waiting for the RSA patent to expire.  The document adopted an 
algorithm approach consistent with IESG policy, and with other 
crypto-based RFCs.  Let's just stick with that.

Steve

Sender: [email-masked]
Date: Fri, 16 Jun 2000 08:20:48 -0700
From: Michael Sierchio <[email-masked]>
To: Christopher Williams <[email-masked]>
CC: PKIX Mailing List <[email-masked]>
Subject: Re: Do people have something against RSA?

Christopher Williams wrote:
> 
> Do people in the PKI world have something RSA Data Corporation?  It's just
> that every document mandates DSA as a signature algorithm and indicates that
> RSA "MAY" also be supported.  Another example is that PKIX does not support
> PKCS#8 for securing private keys, even though PKCS#8 is a well-established
> standard (eight years old now?).  Then I read as a suggested amendment to
> the TSP document:
> 
> "TSA implementations MUST support DSA.  TSA implementations MAY include RSA."

I'm afraid that I don't see why a mandate for private key storage is
relevant to this discussion -- other than the obvious requirement
that private keys be kept private,  whether by embedding in tamper-resistant
hardware,  password based encryption, etc.,  and that there be a revocation
mechanism in the event of compromise.

And the answer to your query -- as a former employee of RSADSI (now
RSA Security) -- is: yes.  There is antipathy for RSA, perhaps because
they have always spent more on lawyers than on R&D.  I have the greatest
respect for the folks at RSA Labs,  but slight regard for the rest of
the company that was RSADSI and SDTI.

> Get real!  The whole world uses RSA.  The future worldwide PKI will run on
> RSA.

One might easily surmise that the future of PKI is ECC, or something
yet to be invented.  However,  choosing technology that is unecumbered
by patents is an IETF requirement.

>  I have never seen a certificate signed with an algorithm other than
> RSA and containing anything other than an RSA public key. 

That is a self-referential statement -- the plural of anecdote is not
data, IIRC.

> Insisting upon DSA and Diffie-Hellman is like railing against the
> universality of Microsoft: pointless and missing the point.

There are distinct advantages to the use of long-term DH values
tied to identity, esp. when it comes to stateless protocols, IPSec,
and other uses for key agreement.

Date: Fri, 16 Jun 2000 16:50:58 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "'PKIX Mailing List'" <[email-masked]>
Subject: Re: Do people have something against RSA?

denis,

I will use your E-mail to comment.
 
> > > Get real!  The whole world uses RSA. [...]
> > > Insisting upon DSA and Diffie-Hellman is like railing against the
> > > universality of Microsoft: pointless and missing the point.
> > IETF standards are required to use non-proprietary technologies wherever
> > possible.
> 
> Yes, but - the RSA patent is going to expire in September this year, is it
> not?
> 
> There are not going to be any serious commercial employments of, say, a TSA,
> before September, are they?

I do not buy the arguments from Christopher, but I thank him for
being the first one daring to raise the issue. The question raised
by denis makes sense: we only have a little bit more than 3 months
left before the expiration of the RSA patent.

There are two related questions:

1) Should we mandate the use of the RSA algorithm for signing TS
token ? This seems reasonable in this new context.
2) Should the chairs wait until September 21 rst, 2000 to send the
TSP draft to the IESG (and mandate the use of the RSA algorithm for
signing) or should they do it now (i.e. as soon as they consider
that we have reached a WG consensus) taking into account that the
next step is Proposed Standard, i.e. not Standard, which means that
in any case, the Standard will be published three months AFTER the
expiration of the RSA patent. 

The later seems reasonable ... but would mean to publish a version 9
of the TSP draft before sending it to the IESG.

Anyway the question is much broader than the TSP draft and applies
to all other drafts, in particular Attibute Certificates.

Denis

> So why not put in RSA, since the patent is going to expire soon enough
> anyway? As far as I know, the validity of the patent cannot be extended,
> thus RSA becomes public domain.
> 
> Regards,
> 
> denis

Date: Fri, 16 Jun 2000 16:29:17 +0200
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Can we form certificates with just name and e-mail address

Just a seemingly easy question!

How do you form a certificate according to PKIX where the subjects name 
only consists of a name (commonName or GivenName + surname) and an e-mail 
address ?? It seams to be virtually impossible to do this.

I'm almost certain that this must have been up before, so I would 
appreciate some hints here.
The problem is that son of RFC 2459 in "4.1.2.6  Subject" says

    Conforming implementations generating new certificates with elec-
    tronic mail addresses MUST use the rfc822Name in the subject alterna-
    tive name field (see sec. 4.2.1.7) to describe such identities.
    Simultaneous inclusion of the EmailAddress attribute in the subject
    distinguished name to support legacy implementations is deprecated
    but permitted.

My problem with this is that the name (given name + surname) is not unique. 
I.e. it can't be stored in the subject field nor as a name form in the 
subjectAltName ext, unless combined with some disambiguating data (such as 
an e-mail address), which is deprecated according to the current text.

This means that inclusion of a name in the subject field must be combined 
with some disambiguating data other than an e-mail address (if the name is 
not unique enough). This seams like a pragmatic view that hardly meets the 
requirements of a practical world.

What has historic debates concluded in?

/Stefan

Date: Fri, 16 Jun 2000 10:18:55 -0400
From: Timothy Fisher <[email-masked]>
To: Ben Laurie <[email-masked]>
CC: Christopher Williams <[email-masked]>, PKIX Mailing List <[email-masked]>
Subject: Re: Do people have something against RSA?

Chris,

I also think that the simple fact is that YES, quite a few people do have
something against RSA
Security Inc.   Have you ever tryed negotiating with them?   I have...   Its not a
fun process....
Many people share this opinion of RSA.

Tim

Ben Laurie wrote:

> Christopher Williams wrote:
> >
> > Do people in the PKI world have something RSA Data Corporation?  It's just
> > that every document mandates DSA as a signature algorithm and indicates that
> > RSA "MAY" also be supported.  Another example is that PKIX does not support
> > PKCS#8 for securing private keys, even though PKCS#8 is a well-established
> > standard (eight years old now?).  Then I read as a suggested amendment to
> > the TSP document:
> >
> > "TSA implementations MUST support DSA.  TSA implementations MAY include RSA.
> > "
> >
> > Get real!  The whole world uses RSA.  The future worldwide PKI will run on
> > RSA.  I have never seen a certificate signed with an algorithm other than
> > RSA and containing anything other than an RSA public key.  Sure, RSA is
> > patented, so factor licensing it as part of your software development costs
> > and pay them their fee - they deserve it.
> >
> > Insisting upon DSA and Diffie-Hellman is like railing against the
> > universality of Microsoft: pointless and missing the point.
>
> IETF standards are required to use non-proprietary technologies wherever
> possible.
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> Coming to ApacheCon Europe 2000? http://apachecon.com/

Date: Fri, 16 Jun 2000 10:17:05 -0400
From: Timothy Fisher <[email-masked]>
To: Christopher Williams <[email-masked]>
CC: PKIX Mailing List <[email-masked]>
Subject: Re: Do people have something against RSA?

Fortunately, the patent will expire at the end of September of this year.  After
that, you will
no longer have to pay RSA data corp. any fees to use RSA.

The reason that DSA is mandated in most standards is simply because it is free
to use.
A standard should never mandate an algorithm which must be licensed from a
specific provider.
This would be a mistake.

Timothy Fisher

Christopher Williams wrote:

> Do people in the PKI world have something RSA Data Corporation?  It's just
> that every document mandates DSA as a signature algorithm and indicates that
> RSA "MAY" also be supported.  Another example is that PKIX does not support
> PKCS#8 for securing private keys, even though PKCS#8 is a well-established
> standard (eight years old now?).  Then I read as a suggested amendment to
> the TSP document:
>
> "TSA implementations MUST support DSA.  TSA implementations MAY include RSA.
> "
>
> Get real!  The whole world uses RSA.  The future worldwide PKI will run on
> RSA.  I have never seen a certificate signed with an algorithm other than
> RSA and containing anything other than an RSA public key.  Sure, RSA is
> patented, so factor licensing it as part of your software development costs
> and pay them their fee - they deserve it.
>
> Insisting upon DSA and Diffie-Hellman is like railing against the
> universality of Microsoft: pointless and missing the point.
>
> Christopher Williams
>
> Software engineer, NetLexis Ltd.
> http://www.netlexis.com "Intelligent Trust"

Date: Fri, 16 Jun 2000 15:20:45 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Group plc
To: [email-masked]
CC: "'Christopher Williams'" <[email-masked]>, "'PKIX Mailing List'" <[email-masked]>
Subject: Re: Do people have something against RSA?

[email-masked] wrote:
> 
> > > Get real!  The whole world uses RSA. [...]
> > > Insisting upon DSA and Diffie-Hellman is like railing against the
> > > universality of Microsoft: pointless and missing the point.
> > IETF standards are required to use non-proprietary technologies wherever
> > possible.
> 
> Yes, but - the RSA patent is going to expire in September this year, is it
> not?
> 
> There are not going to be any serious commercial employments of, say, a TSA,
> before September, are they?

Rules are rules! In September, you'll be right.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

Date: Fri, 16 Jun 2000 15:20:11 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Group plc
To: Xenitellis S <[email-masked]>
CC: "'PKIX Mailing List'" <[email-masked]>
Subject: Re: Do people have something against RSA?

Xenitellis S wrote:
> 
> I am not an expert on this, however I have heard two reasons that
> may make RSA still difficult to use.
> 
> 1. The RSA patent expires this September, but there are several related
> to RSA patents that do not expire yet. It depends on the course that
> these additional patents will be fought for.
> 
> 2. In other countries (like in the UK), I think that RSA is patented. What
> is
> the case in those countries? When do patents expire?

RSA is not patented in the UK (or the rest of Europe).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

From: Paul Halliden <[email-masked]>
To: "'Xenitellis S'" <[email-masked]>, "'PKIX Mailing List'" <[email-masked]>
Subject: RE: Do people have something against RSA?
Date: Fri, 16 Jun 2000 14:32:12 +0100

>2. In other countries (like in the UK), I think that RSA is 
>patented. What is the case in those countries? 

RSA is not patented in the UK or, to the best of my knowledge, in any other
European country.  However, I understand that there is a claim that DSA may
covered by a European patent.  In the US, I believe that the Federal
authorities provide indemnity to vendors using DSA in products supplied to
the government - but I have not heard of that happening elsewhere. 

Regards
Paul Halliden

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
Date: Fri, 16 Jun 2000 08:53:56 -0400

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

------_=_NextPart_001_01BFD791.F4FB4180
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

J=F6rg,

See comments inline.

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: Joerg Seidel [mailto:[email-masked]]
>Sent: Thursday, June 15, 2000 3:31 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
>
>Comments inline.
>
>> [email-masked] schrieb:
>>=20
>> a.  Under Section 2.3, the first sentence indicates that "The TSA =
MUST
sign
>> all time stamp messages with one or more keys reserved specifically =
for
that
>> purpose". As suggested before, I would recommend that you add the
following
>> sentence after the first sentence to explain the reason(s) why a TSA
could
>> have more than one key reserved specifically for that purpose: "A =
TSA MAY
>> have more than one key to accommodate different policies, different
>> algorithms and/or different private key sizes".
>
>Or just for performance purposes.

If a TSA has more than one key for performance purposes, I would assume =
they
are just copies of the same private key cloned in different =
cryptographic
modules for performance and load balancing reasons. I think that the
document meant "distinct" private keys, but I would agree with you that =
it
is not obvious. Instead it could read this way:

"The TSA MUST sign all time stamp messages with one or more keys =
reserved
specifically for that purpose. A TSA MAY have distinct private keys to
accommodate different policies, different algorithms and/or different =
key
sizes."

>> I would then suggest that a new Section be
>> added between the current Sections 3 and 4, which would define the
minimum
>> set of algorithm that MUST and SHOULD be supported by requesters and
TSAs.
>> Based on Section 12 of RFC 2630 [CMS], it could read as follows:
>>=20
>> 4  Supported Algorithms
>>=20
>>    This section lists the algorithms that must be supported.
>>    Additional algorithms that should be supported are also included.
>>=20
>> 4.1  Hash Algorithms
>>=20
>>    TSA implementations MUST support SHA-1.  TSA implementations =
SHOULD
>>    support MD5.
>
>I think there are good reasons not to use MD5 in time stamps. They =
should
use
>a strong hash function in order to achive long validity periods. MD5 =
is
likely
>to be unsafe (=3Dnot collision free) soon and is already discuraged by =
german
>authorities.

I agree that TSAs should not use MD5 in their time stamps and MUST only =
use
strong hash functions (e.g. SHA-1, RIPEMD-160). However, there is =
nothing
wrong
for a requester to submit a message imprint containing a MD5 hash, =
which
means
that TSAs should be able accept request with MD5.

>IF we add a section about algorithms, it should maybe read: "TSA
>implementations MUST support SHA-1.  TSA implementations SHOULD NOT =
support
>MD5.". But I think such a section is not very necessary.

See comment above, however I agree that the text will have to be =
modified to
distinguish between the hash supported by TSAs in requests versus the =
hash
used by TSAs in time stamp tokens.

>> 4.2  Signature Algorithms
>>=20
>>    TSA implementations MUST support DSA.  TSA implementations MAY
>>    include RSA.
>
>Again I would do it the other way round: "TSA MUST support RSA. MAY =
support
>DSA".

This came directly from RFC 2630 [CMS], however this document could =
mandate
different algorithms for TSA if this is what everyone agree.

>J=F6rg
>--=20
>__________________________________________________________________
>
>J=F6rg Seidel                             phone  +49-40-76629-1911
>Director Technology                     fax    +49-40-76629-551
>timeproof GmbH                         =20
>Harburger Schlo=DFstra=DFe 6-12             mailto:[email-masked]
>DE 21079 Hamburg                        http://www.timeproof.de
>__________________________________________________________________
>

------_=_NextPart_001_01BFD791.F4FB4180
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.2650.12">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>J=F6rg,</FONT>
</P>

<P><FONT SIZE=3D2>See comments inline.</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Joerg Seidel [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt;Sent: Thursday, June 15, 2000 3:31 PM</FONT>
<BR><FONT SIZE=3D2>&gt;To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: Re: I-D =
ACTION:draft-ietf-pkix-time-stamp-08.txt</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Comments inline.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; [email-masked] schrieb:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; a.&nbsp; Under Section 2.3, the first =
sentence indicates that &quot;The TSA MUST sign</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; all time stamp messages with one or more =
keys reserved specifically for that</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; purpose&quot;. As suggested before, I would =
recommend that you add the following</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; sentence after the first sentence to =
explain the reason(s) why a TSA could</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; have more than one key reserved =
specifically for that purpose: &quot;A TSA MAY</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; have more than one key to accommodate =
different policies, different</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; algorithms and/or different private key =
sizes&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Or just for performance purposes.</FONT>
</P>

<P><FONT SIZE=3D2>If a TSA has more than one key for performance =
purposes, I would assume they are just copies of the same private key =
cloned in different cryptographic modules for performance and load =
balancing reasons. I think that the document meant &quot;distinct&quot; =
private keys, but I would agree with you that it is not obvious. =
Instead it could read this way:</FONT></P>

<P><FONT SIZE=3D2>&quot;The TSA MUST sign all time stamp messages with =
one or more keys reserved specifically for that purpose. A TSA MAY have =
distinct private keys to accommodate different policies, different =
algorithms and/or different key sizes.&quot;</FONT></P>

<P><FONT SIZE=3D2>&gt;&gt; I would then suggest that a new Section =
be</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; added between the current Sections 3 and 4, =
which would define the minimum</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; set of algorithm that MUST and SHOULD be =
supported by requesters and TSAs.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Based on Section 12 of RFC 2630 [CMS], it =
could read as follows:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; 4&nbsp; Supported Algorithms</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp; This section lists the =
algorithms that must be supported.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp; Additional algorithms =
that should be supported are also included.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; 4.1&nbsp; Hash Algorithms</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp; TSA implementations MUST =
support SHA-1.&nbsp; TSA implementations SHOULD</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp; support MD5.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I think there are good reasons not to use MD5 in =
time stamps. They should use</FONT>
<BR><FONT SIZE=3D2>&gt;a strong hash function in order to achive long =
validity periods. MD5 is likely</FONT>
<BR><FONT SIZE=3D2>&gt;to be unsafe (=3Dnot collision free) soon and is =
already discuraged by german</FONT>
<BR><FONT SIZE=3D2>&gt;authorities.</FONT>
</P>

<P><FONT SIZE=3D2>I agree that TSAs should not use MD5 in their time =
stamps and MUST only use</FONT>
<BR><FONT SIZE=3D2>strong hash functions (e.g. SHA-1, RIPEMD-160). =
However, there is nothing wrong</FONT>
<BR><FONT SIZE=3D2>for a requester to submit a message imprint =
containing a MD5 hash, which means</FONT>
<BR><FONT SIZE=3D2>that TSAs should be able accept request with =
MD5.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;IF we add a section about algorithms, it should =
maybe read: &quot;TSA</FONT>
<BR><FONT SIZE=3D2>&gt;implementations MUST support SHA-1.&nbsp; TSA =
implementations SHOULD NOT support</FONT>
<BR><FONT SIZE=3D2>&gt;MD5.&quot;. But I think such a section is not =
very necessary.</FONT>
</P>

<P><FONT SIZE=3D2>See comment above, however I agree that the text will =
have to be modified to distinguish between the hash supported by TSAs =
in requests versus the hash used by TSAs in time stamp =
tokens.</FONT></P>

<P><FONT SIZE=3D2>&gt;&gt; 4.2&nbsp; Signature Algorithms</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp; TSA implementations MUST =
support DSA.&nbsp; TSA implementations MAY</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp; include RSA.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Again I would do it the other way round: =
&quot;TSA MUST support RSA. MAY support</FONT>
<BR><FONT SIZE=3D2>&gt;DSA&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>This came directly from RFC 2630 [CMS], however this =
document could mandate different algorithms for TSA if this is what =
everyone agree.</FONT></P>

<P><FONT SIZE=3D2>&gt;J=F6rg</FONT>
<BR><FONT SIZE=3D2>&gt;-- </FONT>
<BR><FONT =
SIZE=3D2>&gt;___________________________________________________________=
_______</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;J=F6rg =
Seidel&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; phone&nbsp; +49-40-76629-1911</FONT>
<BR><FONT SIZE=3D2>&gt;Director =
Technology&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
fax&nbsp;&nbsp;&nbsp; +49-40-76629-551</FONT>
<BR><FONT SIZE=3D2>&gt;timeproof =
GmbH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;Harburger Schlo=DFstra=DFe =
6-12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; <A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></FONT=
<BR><FONT SIZE=3D2>&gt;DE 21079 =
Hamburg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; <A HREF=3D"http://www.timeproof.de" =
TARGET=3D"_blank">http://www.timeproof.de</A></FONT>
<BR><FONT =
SIZE=3D2>&gt;___________________________________________________________=
_______</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD791.F4FB4180--

From: Xenitellis S <[email-masked]>
To: "'PKIX Mailing List'" <[email-masked]>
Subject: RE: Do people have something against RSA?
Date: Fri, 16 Jun 2000 13:41:23 +0100

I am not an expert on this, however I have heard two reasons that
may make RSA still difficult to use.

1. The RSA patent expires this September, but there are several related
to RSA patents that do not expire yet. It depends on the course that 
these additional patents will be fought for.

2. In other countries (like in the UK), I think that RSA is patented. What
is
the case in those countries? When do patents expire? 

My 2 drx,
Simos Xenitellis

> ----------
> From: 	denis.bider[SMTP:[email-masked]]
> Sent: 	16 June 2000 13:24
> To: 	'Ben Laurie'; 'Christopher Williams'
> Cc: 	'PKIX Mailing List'
> Subject: 	RE: Do people have something against RSA?
> 
> > > Get real!  The whole world uses RSA. [...]
> > > Insisting upon DSA and Diffie-Hellman is like railing against the
> > > universality of Microsoft: pointless and missing the point.
> > IETF standards are required to use non-proprietary technologies wherever
> > possible.
> 
> Yes, but - the RSA patent is going to expire in September this year, is it
> not?
> 
> There are not going to be any serious commercial employments of, say, a
> TSA,
> before September, are they?
> 
> So why not put in RSA, since the patent is going to expire soon enough
> anyway? As far as I know, the validity of the patent cannot be extended,
> thus RSA becomes public domain.
> 
> Regards,
> 
> denis
> 

From: <[email-masked]>
Sender: "denis bider" <[email-masked]>
To: "'Ben Laurie'" <[email-masked]>, "'Christopher Williams'" <[email-masked]>
Cc: "'PKIX Mailing List'" <[email-masked]>
Subject: RE: Do people have something against RSA?
Date: Fri, 16 Jun 2000 14:24:04 +0200
Importance: Normal

> > Get real!  The whole world uses RSA. [...]
> > Insisting upon DSA and Diffie-Hellman is like railing against the
> > universality of Microsoft: pointless and missing the point.
> IETF standards are required to use non-proprietary technologies wherever
> possible.

Yes, but - the RSA patent is going to expire in September this year, is it
not?

There are not going to be any serious commercial employments of, say, a TSA,
before September, are they?

So why not put in RSA, since the patent is going to expire soon enough
anyway? As far as I know, the validity of the patent cannot be extended,
thus RSA becomes public domain.

Regards,

denis

Date: Fri, 16 Jun 2000 12:51:14 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Group plc
To: Christopher Williams <[email-masked]>
CC: PKIX Mailing List <[email-masked]>
Subject: Re: Do people have something against RSA?

Christopher Williams wrote:
> 
> Do people in the PKI world have something RSA Data Corporation?  It's just
> that every document mandates DSA as a signature algorithm and indicates that
> RSA "MAY" also be supported.  Another example is that PKIX does not support
> PKCS#8 for securing private keys, even though PKCS#8 is a well-established
> standard (eight years old now?).  Then I read as a suggested amendment to
> the TSP document:
> 
> "TSA implementations MUST support DSA.  TSA implementations MAY include RSA.
> "
> 
> Get real!  The whole world uses RSA.  The future worldwide PKI will run on
> RSA.  I have never seen a certificate signed with an algorithm other than
> RSA and containing anything other than an RSA public key.  Sure, RSA is
> patented, so factor licensing it as part of your software development costs
> and pay them their fee - they deserve it.
> 
> Insisting upon DSA and Diffie-Hellman is like railing against the
> universality of Microsoft: pointless and missing the point.

IETF standards are required to use non-proprietary technologies wherever
possible.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

From: Michael Zolotarev <[email-masked]>
To: Christopher Williams <[email-masked]>, PKIX Mailing List <[email-masked]>
Subject: RE: Do people have something against RSA?
Date: Fri, 16 Jun 2000 21:38:51 +1000

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

------_=_NextPart_000_01BFD787.718D6774
Content-Type: text/plain;
	charset="iso-8859-1"

> Get real!  The whole world uses RSA.  The future worldwide 
> PKI will run on
> RSA.  I have never seen a certificate signed with an 
> algorithm other than
> RSA and containing anything other than an RSA public key.  

Here is one for you, Christopher. It contains a DSA key. If you insist, I
can generate a *real* certificate for you. And I can sign it with a DSA key.

Having fun?

Michael :)

------_=_NextPart_000_01BFD787.718D6774
Content-Type: application/octet-stream;
	name="DEMO_DSA.crt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="DEMO_DSA.crt"

------_=_NextPart_000_01BFD787.718D6774--

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Do people have something against RSA?
Date: Fri, 16 Jun 2000 12:22:59 +0100

Do people in the PKI world have something RSA Data Corporation?  It's just
that every document mandates DSA as a signature algorithm and indicates that
RSA "MAY" also be supported.  Another example is that PKIX does not support
PKCS#8 for securing private keys, even though PKCS#8 is a well-established
standard (eight years old now?).  Then I read as a suggested amendment to
the TSP document:

"TSA implementations MUST support DSA.  TSA implementations MAY include RSA.
"

Get real!  The whole world uses RSA.  The future worldwide PKI will run on
RSA.  I have never seen a certificate signed with an algorithm other than
RSA and containing anything other than an RSA public key.  Sure, RSA is
patented, so factor licensing it as part of your software development costs
and pay them their fee - they deserve it.

Insisting upon DSA and Diffie-Hellman is like railing against the
universality of Microsoft: pointless and missing the point.

Christopher Williams

Software engineer, NetLexis Ltd.
http://www.netlexis.com "Intelligent Trust"

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: TSP Draft 08
Date: Thu, 15 Jun 2000 19:57:06 -0400

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

------_=_NextPart_001_01BFD725.6F087410
Content-Type: text/plain;
	charset="iso-8859-1"

Peter,

I disagree that the addition of the ordering flag is creating any
incompatibility issue since the TSA document is still only an Internet Draft
that should not have been used to develop any commercial product until it
becomes an RFC. In addition, I think it is much more meaningful to require
the flag to be present to indicate that ordering is supported as currently
mandated by the latest TSA document.

I agree however that there must be a way for a TSA to publish which of the
ordering services it supports. As a minimum this should be done through the
TSA's policy and it could possibly be done through the Subject Information
Access (SIA) extension from the son of RFC 2459 if it contained a similar
ordering flag. By using the reqPolicy field a requester could then request
the appropriate service if a TSA offers different ordering services.

I also agree that the document should indicate if a TSA has to set the
ordering in a identical way in ALL of its time stamps. I would think that if
a TSA explicitly indicate that it will not support ordering (e.g. through
the TSA's policy or the SIA extension), Time Stamp tokens issued from this
TSA MUST NEVER have the ordering field set to true. However, if a TSA
explicitly indicate that it will support ordering, all Time Stamp tokens
issued from this TSA SHOULD have the ordering field set to true unless the
TSA can not longer do this because of some technical problems. This would
then be a good reason to use the value of one (1) in the structure
"PKIStatus" (i.e. grantedWithMods).

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: Peter Sylvester [mailto:[email-masked]]
Sent: Thursday, June 15, 2000 2:45 PM
To: [email-masked]
Subject: Re: TSP Draft 08

I find it somewhat unelegant to change the functionality of
ordering is such an incompatible way. I think it
would have been wiser to at least inverse the meaning
or BOOLEAN ordering. 

It is not said anywhere whether a TSA has to set the ordering
in a identical way in ALL of its time stamps.

The ordering bit defines two different services; there is
no way fore a TSA to publish which of the services it supports,
there is also no way for the client to indicate whether
ordering or not is desired when requesting a time stamp?

The text says: 'Using a nonce always allows to detect replays'
This should be 'using a nonce reduces the possibility of replay attacks.'.

P

------_=_NextPart_001_01BFD725.6F087410
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.2650.12">
<TITLE>RE: TSP Draft 08</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Peter,</FONT>
</P>

<P><FONT SIZE=3D2>I disagree that the addition of the ordering flag is =
creating any incompatibility issue since the TSA document is still only =
an Internet Draft that should not have been used to develop any =
commercial product until it becomes an RFC. In addition, I think it is =
much more meaningful to require the flag to be present to indicate that =
ordering is supported as currently mandated by the latest TSA =
document.</FONT></P>

<P><FONT SIZE=3D2>I agree however that there must be a way for a TSA to =
publish which of the ordering services it supports. As a minimum this =
should be done through the TSA's policy and it could possibly be done =
through the Subject Information Access (SIA) extension from the son of =
RFC 2459 if it contained a similar ordering flag. By using the =
reqPolicy field a requester could then request the appropriate service =
if a TSA offers different ordering services.</FONT></P>

<P><FONT SIZE=3D2>I also agree that the document should indicate if a =
TSA has to set the ordering in a identical way in ALL of its time =
stamps. I would think that if a TSA explicitly indicate that it will =
not support ordering (e.g. through the TSA's policy or the SIA =
extension), Time Stamp tokens issued from this TSA MUST NEVER have the =
ordering field set to true. However, if a TSA explicitly indicate that =
it will support ordering, all Time Stamp tokens issued from this TSA =
SHOULD have the ordering field set to true unless the TSA can not =
longer do this because of some technical problems. This would then be a =
good reason to use the value of one (1) in the structure =
&quot;PKIStatus&quot; (i.e. grantedWithMods).</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Peter Sylvester [<A =
HREF=3D"mailto:[email-masked]">mailto:Peter.Sylvester@EdelWe=
b.fr</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, June 15, 2000 2:45 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: TSP Draft 08</FONT>
</P>

<P><FONT SIZE=3D2>I find it somewhat unelegant to change the =
functionality of</FONT>
<BR><FONT SIZE=3D2>ordering is such an incompatible way. I think =
it</FONT>
<BR><FONT SIZE=3D2>would have been wiser to at least inverse the =
meaning</FONT>
<BR><FONT SIZE=3D2>or BOOLEAN ordering. </FONT>
</P>

<P><FONT SIZE=3D2>It is not said anywhere whether a TSA has to set the =
ordering</FONT>
<BR><FONT SIZE=3D2>in a identical way in ALL of its time stamps.</FONT>
</P>

<P><FONT SIZE=3D2>The ordering bit defines two different services; =
there is</FONT>
<BR><FONT SIZE=3D2>no way fore a TSA to publish which of the services =
it supports,</FONT>
<BR><FONT SIZE=3D2>there is also no way for the client to indicate =
whether</FONT>
<BR><FONT SIZE=3D2>ordering or not is desired when requesting a time =
stamp?</FONT>
</P>

<P><FONT SIZE=3D2>The text says: 'Using a nonce always allows to detect =
replays'</FONT>
<BR><FONT SIZE=3D2>This should be 'using a nonce reduces the =
possibility of replay attacks.'.</FONT>
</P>

<P><FONT SIZE=3D2>P</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD725.6F087410--

Date: Thu, 15 Jun 2000 21:31:00 +0200
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

Comments inline.

> [email-masked] schrieb:
> 
> a.  Under Section 2.3, the first sentence indicates that "The TSA MUST sign
> all time stamp messages with one or more keys reserved specifically for that
> purpose". As suggested before, I would recommend that you add the following
> sentence after the first sentence to explain the reason(s) why a TSA could
> have more than one key reserved specifically for that purpose: "A TSA MAY
> have more than one key to accommodate different policies, different
> algorithms and/or different private key sizes".
Or just for performance purposes.

> I would then suggest that a new Section be
> added between the current Sections 3 and 4, which would define the minimum
> set of algorithm that MUST and SHOULD be supported by requesters and TSAs.
> Based on Section 12 of RFC 2630 [CMS], it could read as follows:
> 
> 4  Supported Algorithms
> 
>    This section lists the algorithms that must be supported.
>    Additional algorithms that should be supported are also included.
> 
> 4.1  Hash Algorithms
> 
>    TSA implementations MUST support SHA-1.  TSA implementations SHOULD
>    support MD5.

I think there are good reasons not to use MD5 in time stamps. They should use
a strong hash function in order to achive long validity periods. MD5 is likely
to be unsafe (=not collision free) soon and is already discuraged by german
authorities.

IF we add a section about algorithms, it should maybe read: "TSA
implementations MUST support SHA-1.  TSA implementations SHOULD NOT support
MD5.". But I think such a section is not very necessary.

> 4.2  Signature Algorithms
> 
>    TSA implementations MUST support DSA.  TSA implementations MAY
>    include RSA.

Again I would do it the other way round: "TSA MUST support RSA. MAY support
DSA".

Jörg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

From: Peter Sylvester <[email-masked]>
Date: Thu, 15 Jun 2000 20:44:33 +0200 (MET DST)
To: [email-masked]
Subject: Re: TSP Draft 08

I find it somewhat unelegant to change the functionality of
ordering is such an incompatible way. I think it
would have been wiser to at least inverse the meaning
or BOOLEAN ordering. 

It is not said anywhere whether a TSA has to set the ordering
in a identical way in ALL of its time stamps.

The ordering bit defines two different services; there is
no way fore a TSA to publish which of the services it supports,
there is also no way for the client to indicate whether
ordering or not is desired when requesting a time stamp?

The text says: 'Using a nonce always allows to detect replays'
This should be 'using a nonce reduces the possibility of replay attacks.'.

P

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
Date: Thu, 15 Jun 2000 13:08:14 -0400

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

------_=_NextPart_001_01BFD6EC.50BA7A8C
Content-Type: text/plain;
	charset="iso-8859-1"

Salut Denis,

Here are few comments on version 8, some a which are a repeat of previous
comments:

a.  Under Section 2.3, the first sentence indicates that "The TSA MUST sign
all time stamp messages with one or more keys reserved specifically for that
purpose". As suggested before, I would recommend that you add the following
sentence after the first sentence to explain the reason(s) why a TSA could
have more than one key reserved specifically for that purpose: "A TSA MAY
have more than one key to accommodate different policies, different
algorithms and/or different private key sizes".

b.  In Section 2.4.2, the structure "PKIStatusInfo" is missing the OPTIONAL
"statusString" field, which is defined in RFC 2510 as PKIFreeText. Because
later 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'", it would be preferable if the structure
"PKIStatusInfo" in this document was made consistent with the one in RFC
2510.

c.  Under Section 2.4.2, the structure "PKIStatus" can take the value of one
(1) (i.e. grantedWithMods), which is defined in RFC 2510 as:

         grantedWithMods        (1),
         -- you got something like what you asked for; the
         -- requester is responsible for ascertaining the differences

However, base on this definition from RFC 2510, it is not clear in the
context of a TSA if this means that a Time Stamp Token can be 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 (1) and not just zero (0), a Time Stamp Token can also be
present. Otherwise, it should be clear what values for are allowed in the
structure "PKIStatus" of a response by a TSA. In this case, I would suggest
that you then indicate that the value of one (1) MUST not be used in a time
stamping response.

d.  Under Section 2.4.2, in the definition for the TSTInfo "policy" field,
it would be more meaningful to the requester if the document mandated that
the error "unacceptedPolicy (15)" be returned instead of the error
"badRequest (5)" when the TSA can not produce a response with a the same
policy as requested by the requester in the TimeStampReq.

e.  Since there is no "automated" way for a TSA announce to the world what
algorithms it supports to sign Time Stamp Tokens and also what algorithms it
supports in messageImprints although I had previously suggested using the
S/MIME
capabilities attribute for this, I would then suggest that a new Section be
added between the current Sections 3 and 4, which would define the minimum
set of algorithm that MUST and SHOULD be supported by requesters and TSAs.
Based on Section 12 of RFC 2630 [CMS], it could read as follows:

4  Supported Algorithms

   This section lists the algorithms that must be supported.
   Additional algorithms that should be supported are also included.

4.1  Hash Algorithms

   TSA implementations MUST support SHA-1.  TSA implementations SHOULD
   support MD5.

   Hash algorithm identifiers are located in the MessageImprint
   hashAlgorithm field, the [CMS] SignedData digestAlgorithms field and
   the [CMS] SignerInfo digestAlgorithm field.

   Hash values are located in the MessageImprint and the [CMS] Message
   Digest authenticated attribute.  In addition, hash values are input
   to signature algorithms.

4.1.1  SHA-1

   The SHA-1 hash algorithm is defined in FIPS Pub 180-1 [SHA1]. The
   algorithm identifier for SHA-1 is:

      sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
          oiw(14) secsig(3) algorithm(2) 26 }

   The AlgorithmIdentifier parameters field is optional.  If present,
   the parameters field must contain an ASN.1 NULL.  Implementations
   should accept SHA-1 AlgorithmIdentifiers with absent parameters as
   well as NULL parameters.  Implementations should generate SHA-1
   AlgorithmIdentifiers with NULL parameters.

4.1.2  MD5

   The MD5 hash algorithm is defined in RFC 1321 [MD5].  The algorithm
   identifier for MD5 is:

      md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
          rsadsi(113549) digestAlgorithm(2) 5 }

   The AlgorithmIdentifier parameters field must be present, and the
   parameters field must contain NULL.  Implementations may accept the
   MD5 AlgorithmIdentifiers with absent parameters as well as NULL
   parameters.

4.2  Signature Algorithms

   TSA implementations MUST support DSA.  TSA implementations MAY
   include RSA.

   Signature algorithm identifiers are located in the [CMS] SignerInfo
   signatureAlgorithm field.

   Signature values are located in the [CMS] SignerInfo signature
   field.

4.2.1  DSA

   The DSA signature algorithm is defined in FIPS Pub 186 [DSS].  DSA
   is always used with the SHA-1 message digest algorithm.  The
   algorithm identifier for DSA is:

      id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
          us(840) x9-57 (10040) x9cm(4) 3 }

   The AlgorithmIdentifier parameters field must not be present.

4.2.2  RSA

   The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC
   2347 specifies the use of the RSA signature algorithm with the SHA-1
   and MD5 message digest algorithms.  The algorithm identifier for RSA
   is:

      rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

f.  Under Section 6, you will have to add the [son of RFC 2459], which you
are now referring under Section 2.3 for the Subject Information Access
(SIA). You will also have to add all the references for the supported
algorithms (i.e. [SHA1], [MD5], [DSS] and [NEWPKCS#1]) if you agree to add
the new Section 4 above on Supported Algorithms.

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

------_=_NextPart_001_01BFD6EC.50BA7A8C
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.2650.12">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Salut Denis,</FONT>
</P>

<P><FONT SIZE=3D2>Here are few comments on version 8, some a which are =
a repeat of previous comments:</FONT>
</P>

<P><FONT SIZE=3D2>a.&nbsp; Under Section 2.3, the first sentence =
indicates that &quot;The TSA MUST sign all time stamp messages with one =
or more keys reserved specifically for that purpose&quot;. As suggested =
before, I would recommend that you add the following sentence after the =
first sentence to explain the reason(s) why a TSA could have more than =
one key reserved specifically for that purpose: &quot;A TSA MAY have =
more than one key to accommodate different policies, different =
algorithms and/or different private key sizes&quot;.</FONT></P>

<P><FONT SIZE=3D2>b.&nbsp; In Section 2.4.2, the structure =
&quot;PKIStatusInfo&quot; is missing the OPTIONAL =
&quot;statusString&quot; field, which is defined in RFC 2510 as =
PKIFreeText. Because later in Section 2.4.2 it is mentioned that =
&quot;The statusString field of PKIStatusInfo MAY be used to include =
reason text such as 'messageImprint field is not correctly =
formatted'&quot;, it would be preferable if the structure =
&quot;PKIStatusInfo&quot; in this document was made consistent with the =
one in RFC 2510.</FONT></P>

<P><FONT SIZE=3D2>c.&nbsp; Under Section 2.4.2, the structure =
&quot;PKIStatus&quot; can take the value of one (1) (i.e. =
grantedWithMods), which is defined in RFC 2510 as:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
grantedWithMods&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1),</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- =
you got something like what you asked for; the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- =
requester is responsible for ascertaining the differences</FONT>
</P>

<P><FONT SIZE=3D2>However, base on this definition from RFC 2510, it is =
not clear in the context of a TSA if this means that a Time Stamp Token =
can be 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 (1) and not just zero =
(0), a Time Stamp Token can also be present. Otherwise, it should be =
clear what values for are allowed in the structure =
&quot;PKIStatus&quot; of a response by a TSA. In this case, I would =
suggest that you then indicate that the value of one (1) MUST not be =
used in a time stamping response.</FONT></P>

<P><FONT SIZE=3D2>d.&nbsp; Under Section 2.4.2, in the definition for =
the TSTInfo &quot;policy&quot; field, it would be more meaningful to =
the requester if the document mandated that the error =
&quot;unacceptedPolicy (15)&quot; be returned instead of the error =
&quot;badRequest (5)&quot; when the TSA can not produce a response with =
a the same policy as requested by the requester in the =
TimeStampReq.</FONT></P>

<P><FONT SIZE=3D2>e.&nbsp; Since there is no &quot;automated&quot; way =
for a TSA announce to the world what algorithms it supports to sign =
Time Stamp Tokens and also what algorithms it supports in =
messageImprints although I had previously suggested using the =
S/MIME</FONT></P>

<P><FONT SIZE=3D2>capabilities attribute for this, I would then suggest =
that a new Section be added between the current Sections 3 and 4, which =
would define the minimum set of algorithm that MUST and SHOULD be =
supported by requesters and TSAs. Based on Section 12 of RFC 2630 =
[CMS], it could read as follows:</FONT></P>

<P><FONT SIZE=3D2>4&nbsp; Supported Algorithms</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; This section lists the algorithms that =
must be supported.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Additional algorithms that should be =
supported are also included.</FONT>
</P>

<P><FONT SIZE=3D2>4.1&nbsp; Hash Algorithms</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; TSA implementations MUST support =
SHA-1.&nbsp; TSA implementations SHOULD</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; support MD5.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Hash algorithm identifiers are located =
in the MessageImprint</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; hashAlgorithm field, the [CMS] =
SignedData digestAlgorithms field and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the [CMS] SignerInfo digestAlgorithm =
field.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Hash values are located in the =
MessageImprint and the [CMS] Message</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Digest authenticated attribute.&nbsp; =
In addition, hash values are input</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; to signature algorithms.</FONT>
</P>

<P><FONT SIZE=3D2>4.1.1&nbsp; SHA-1</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The SHA-1 hash algorithm is defined in =
FIPS Pub 180-1 [SHA1]. The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; algorithm identifier for SHA-1 =
is:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sha-1 OBJECT =
IDENTIFIER ::=3D { iso(1) identified-organization(3)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; oiw(14) =
secsig(3) algorithm(2) 26 }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The AlgorithmIdentifier parameters field =
is optional.&nbsp; If present,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the parameters field must contain an =
ASN.1 NULL.&nbsp; Implementations</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; should accept SHA-1 =
AlgorithmIdentifiers with absent parameters as</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; well as NULL parameters.&nbsp; =
Implementations should generate SHA-1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; AlgorithmIdentifiers with NULL =
parameters.</FONT>
</P>

<P><FONT SIZE=3D2>4.1.2&nbsp; MD5</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The MD5 hash algorithm is defined in RFC =
1321 [MD5].&nbsp; The algorithm</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; identifier for MD5 is:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; md5 OBJECT IDENTIFIER =
::=3D { iso(1) member-body(2) us(840)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
rsadsi(113549) digestAlgorithm(2) 5 }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The AlgorithmIdentifier parameters field =
must be present, and the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; parameters field must contain =
NULL.&nbsp; Implementations may accept the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; MD5 AlgorithmIdentifiers with absent =
parameters as well as NULL</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; parameters.</FONT>
</P>

<P><FONT SIZE=3D2>4.2&nbsp; Signature Algorithms</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; TSA implementations MUST support =
DSA.&nbsp; TSA implementations MAY</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; include RSA.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Signature algorithm identifiers are =
located in the [CMS] SignerInfo</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; signatureAlgorithm field.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Signature values are located in the =
[CMS] SignerInfo signature</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; field.</FONT>
</P>

<P><FONT SIZE=3D2>4.2.1&nbsp; DSA</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The DSA signature algorithm is defined =
in FIPS Pub 186 [DSS].&nbsp; DSA</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; is always used with the SHA-1 message =
digest algorithm.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; algorithm identifier for DSA is:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id-dsa-with-sha1 =
OBJECT IDENTIFIER ::=3D&nbsp; { iso(1) member-body(2)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; us(840) =
x9-57 (10040) x9cm(4) 3 }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The AlgorithmIdentifier parameters field =
must not be present.</FONT>
</P>

<P><FONT SIZE=3D2>4.2.2&nbsp; RSA</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The RSA signature algorithm is defined =
in RFC 2347 [NEWPKCS#1]. RFC</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 2347 specifies the use of the RSA =
signature algorithm with the SHA-1</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; and MD5 message digest =
algorithms.&nbsp; The algorithm identifier for RSA</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; is:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rsaEncryption OBJECT =
IDENTIFIER ::=3D { iso(1) member-body(2)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; us(840) =
rsadsi(113549) pkcs(1) pkcs-1(1) 1 }</FONT>
</P>

<P><FONT SIZE=3D2>f.&nbsp; Under Section 6, you will have to add the =
[son of RFC 2459], which you are now referring under Section 2.3 for =
the Subject Information Access (SIA). You will also have to add all the =
references for the supported algorithms (i.e. [SHA1], [MD5], [DSS] and =
[NEWPKCS#1]) if you agree to add the new Section 4 above on Supported =
Algorithms.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD6EC.50BA7A8C--

From: [email-masked]
Date: Thu, 15 Jun 2000 12:48:36 EDT
Subject: Unsubscribe
To: [email-masked]

Unsubscribe

Date: Thu, 15 Jun 2000 16:21:21 +0500 (PAKST)
From: Venkateshwara Reddy A <[email-masked]>
To: [email-masked]

subscribe 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
Date: Thu, 15 Jun 2000 06:40:55 -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 Time Stamp Protocols (TSP)
	Author(s)	: C. Adams, D. Pinkas, P. Cain, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-08.txt
	Pages		: 22
	Date		: 14-Jun-00
	
A time stamping service allows to prove that a datum existed before 
a particular time and can be used by a Trusted Third Party (TTP) as 
one component in building reliable non-repudiation services (see 
[ISONR]). This document describes the format of a request sent to a 
Time Stamping Authority (TSA) and of the response that is returned.
An example of how to prove that a digital signature was generated 
during the validity period of a public key certificate is given 
in an annex.

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

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

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

--OtherAccess--

--NextPart--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Are there any TSAs out there?
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 15 Jun 2000 13:34:12 (NZST)

"Christopher Williams" <[email-masked]> writes:

>Does anybody know of any commercial / free implementations of Time Stamp
>Protocol server software?

I made some quiet inquiries about this a few months back, but there don't seem
to be any implementations around.  Does anyone have something to test against?

Peter.

Date: Wed, 14 Jun 2000 10:13:34 -0700
From: Ed Gerck <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: TSA Response serialNumber Field

Denis Pinkas wrote:

> Ed,
>
> Sorry for the delay to answer.

No problem, my comment was not timestamped ;-)

Let me retain the thread, for continuity.

> > Denis Pinkas wrote:
> >
> > > I propose that we all look back
> > > at the definition we have in the current document.
> > >
> > > " By adding the XXXX value to the GeneralizedTime, an upper limit of
> > > the time at which the timestamp has been created by the TSA can be
> > > obtained. In the same way, by subtracting the XXXX to the
> > > GeneralizedTime, a lower limit of the time at which the timestamp
> > > has been created by the TSA can be obtained."
> > >
> > > The single remaining question is how do you call XXXX, while
> > > sticking to THIS definition. It is currently called "accuracy". If
> > > this term is not adequate, please make a proposal. I would like to
> > > close this issue soon.
> > >
> >
> > Ed Gerck wrote:
> >
> > The question is not so much what it is called (even though it would be
> > nice to use an already accepted name for it) but that THIS definition is
> > broken.
>
> The *concept* is quite clear and is *not* broken. Since you have not
> proposed an alternative to define this concept, I assume that the
> word chosen to define the concept is acceptable.

Please see the WG archives -- the alternative I suggested and was
accepted by some is "uncertainty", and was also defined.

> > Pls see the former emails.  So, one should not stick to THIS
> > definition.
>
> The definition says what it says and is very clear. It might not be
> what you want (we are not making measurements of a value), but we
> are seeking 100 % GUARANTEES for the value we get, even if the
> "accuracy", as we call it, is pretty large. We are not seeking a
> probabilistic answer, even with 99,99 % confidence.

My comment is not whether you are seeking a probabilistic answer,
but that seeking 100% guarantees is moot in this case -- this is NOT
a digital signature, this represents a measurement of a value.  So, if the
standard wants to warrant that which cannot be warranted then I
suggest that this be made clear to this WG and in the standard itself
for those that might not have time to wade through all PKIX WG
messages.

IMO, though, this should NOT be done and the standard should
make clear that there is no 100% guarantee on the time stamp -- which
does not mean it is useless either, because if the deviation is known
(as I suggested must be) then it is possible to get assurances which
approach 100% as much as you please as a function of the error bar
you want to consider.

Cheers,

Ed Gerck

Date: Wed, 14 Jun 2000 16:55:59 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: TSP Draft 08

I take advantage of a pause on the mailing list about TSP, to post a
new draft and provide a summary of the main modifications performed
to produce draft 8:

1. serial number now matches with the definition of serial number
from RFC 2459.

2. The Authority Information Access (AIA) extension has been
replaced by a Subject Information Access (SIA) extension which
*should* appear in the son of RFC2459.

3. The field: 

extensions            [0] Extensions  OPTIONAL

has been replaced by:

extensions            [0] IMPLICIT Extensions  OPTIONAL

4. The explanations around the certReq field have been
corrected/clarified.

5. Time Stamps users must now be ready to accommodate serial number
integers up to 160 bits.

6. An additional field called ordering has been introduced in the
response after accuracy:

ordering                  BOOLEAN           DEFAULT FALSE,

This allows to build two categories of TSAs, whether ordering of
Time Stamp tokens from the same TSA within the accuracy of the
genTime (e.g. within the same second) is or is not a requirement.

7. The tagging of the two last parameters of the response has been
modified in the following way:

     tsa                   [0] GeneralName      OPTIONAL,
     extensions            [1] Extensions       OPTIONAL

8. The tagging of the three parameters of Accuracy has been
simplified:

Accuracy ::= SEQUENCE {
        seconds        INTEGER              OPTIONAL,
        millis     [0] INTEGER  (1..999)    OPTIONAL,
        micros     [1] INTEGER  (1..999)    OPTIONAL
}

9. A new item 6 has been added to the security considerations
section.

If you have any comment (I hope you have none. :-| ), please wait
until the new draft is made available.

Denis

Date: Wed, 14 Jun 2000 16:50:40 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Ed Gerck <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: TSA Response serialNumber Field

Ed,

Sorry for the delay to answer.

> Denis Pinkas wrote:
> 
> > I propose that we all look back
> > at the definition we have in the current document.
> >
> > " By adding the XXXX value to the GeneralizedTime, an upper limit of
> > the time at which the timestamp has been created by the TSA can be
> > obtained. In the same way, by subtracting the XXXX to the
> > GeneralizedTime, a lower limit of the time at which the timestamp
> > has been created by the TSA can be obtained."
> >
> > The single remaining question is how do you call XXXX, while
> > sticking to THIS definition. It is currently called "accuracy". If
> > this term is not adequate, please make a proposal. I would like to
> > close this issue soon.
> >
> 
> Dennis:
> 
> The question is not so much what it is called (even though it would be
> nice to use an already accepted name for it) but that THIS definition is
> broken.  

The *concept* is quite clear and is *not* broken. Since you have not
proposed an alternative to define this concept, I assume that the
word chosen to define the concept is acceptable.

> Pls see the former emails.  So, one should not stick to THIS
> definition.

The definition says what it says and is very clear. It might not be
what you want (we are not making measurements of a value), but we
are seeking 100 % GUARANTEES for the value we get, even if the
"accuracy", as we call it, is pretty large. We are not seeking a
probabilistic answer, even with 99,99 % confidence.

I have just posted a new draft to the web editor. This new draft
should be available soon. 

Regards,

Denis

> Cheers,
> Ed Gerck

Date: Wed, 14 Jun 2000 14:22:25 +0200
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: Christopher Williams <[email-masked]>
CC: PKIX Mailing List <[email-masked]>
Subject: Re: Are there any TSAs out there?

Hello,

it is not a software but hardware implementation, but timeproof is planning to
implement the time-stamp-protocol as soon as it's draft becomes stable. For
details please have a look at our website or contact or sales manager Mr.
Förster <[email-masked]>.

Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

Christopher Williams schrieb:
> 
> Does anybody know of any commercial / free implementations of Time Stamp
> Protocol server software?
> 
> 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: Are there any TSAs out there?
Date: Wed, 14 Jun 2000 10:00:39 +0100

Does anybody know of any commercial / free implementations of Time Stamp
Protocol server software?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

Date: Wed, 14 Jun 2000 00:34:45 -0700
To: OSI Directory List <[email-masked]>, [email-masked], ABA Information Security Committee <[email-masked]>
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: a new revision of the 4th edition of x.509 is on the server

we have recently made a critical fix to x.509. a ballot comment was 
not accurately captured in the text. the revised text has been placed 
on the server as
 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV4.doc

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV4.pdf

the change is to clause 15.1.2.2 Targeting information extension

Replace the 6th paragraph following the ASN.1, that currently reads 
"This extension is always non-critical." with "This extension is 
always critical."

this is likely to be the last change to the text before it ballots in 
ISO/IEC as a Final Draft International Standard. Once that ballot 
completes (a yes/no) and the standard can be purchased, this version 
will be removed from this server.

    hoyt

Date: Tue, 13 Jun 2000 17:39:28 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Paul Koning <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: TSA signing key?

Paul,

Please, before answering, take a look at the document:

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

Denis

> >>>>> "Denis" == Denis Pinkas <[email-masked]> writes:
> 
>  Denis> Martin,
> 
>  Denis> I guess that they are several arguments for that. Let me give
>  Denis> one.
> 
>  Denis> This allows you to build a black box, to place the TSA private
>  Denis> key in it and then to close the box, only making sure that the
>  Denis> clock inside is still synchronized with UTC (with respect to
>  Denis> the accuracy that is guaranted by the TSA). If not, the box
>  Denis> shall stop working.  The private key will not be used for
>  Denis> signing anything else which would require a management
>  Denis> interface. If the implementation is poor, this management
>  Denis> interface could possibly be used to sign, e.g. a wrong
>  Denis> token. :-(
> 
>  >> In draft is written that TSA cert must be used exclusively for
>  >> time stamp.  Why TSA certificate cann't be same as CA certificate?
> 
> If the intent is that the *key* should not be used for other purposes,
> it should say that -- restricting the cert doesn't necessarily
> constrain the use of the key.
> 
>           paul

From: Paul Koning <[email-masked]>
Date: Tue, 13 Jun 2000 11:24:04 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: TSA signing key?

>>>>> "Denis" == Denis Pinkas <[email-masked]> writes:

 Denis> Martin,

 Denis> I guess that they are several arguments for that. Let me give
 Denis> one.

 Denis> This allows you to build a black box, to place the TSA private
 Denis> key in it and then to close the box, only making sure that the
 Denis> clock inside is still synchronized with UTC (with respect to
 Denis> the accuracy that is guaranted by the TSA). If not, the box
 Denis> shall stop working.  The private key will not be used for
 Denis> signing anything else which would require a management
 Denis> interface. If the implementation is poor, this management
 Denis> interface could possibly be used to sign, e.g. a wrong
 Denis> token. :-(
 
 >> In draft is written that TSA cert must be used exclusively for
 >> time stamp.  Why TSA certificate cann't be same as CA certificate?

If the intent is that the *key* should not be used for other purposes,
it should say that -- restricting the cert doesn't necessarily
constrain the use of the key.

	  paul

Date: Tue, 13 Jun 2000 17:14:40 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Martin Szotkowski <[email-masked]>
CC: [email-masked]
Subject: Re: TSA signing key?

Martin,

I guess that they are several arguments for that. Let me give one.

This allows you to build a black box, to place the TSA private key
in it and then to close the box, only making sure that the clock
inside is still synchronized with UTC (with respect to the accuracy
that is guaranted by the TSA). If not, the box shall stop working.
The private key will not be used for signing anything else which
would require a management interface. If the implementation is poor,
this  management interface could possibly be used to sign, e.g. a
wrong token. :-(

Denis
 
> In draft is written that TSA cert must be used exclusively for time stamp.
> Why TSA certificate cann't be same as CA certificate?
> 
> thanks Martin

Date: Mon, 12 Jun 2000 17:58:20 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Ed Gerck <[email-masked]>, [email-masked]
Subject: Re: Correct approach to certificate validation?

Stephen Kent wrote:

> Ed Gerck wrote:
> >A checkbox with "Enforce name chaining" could take care of all cases
> >where name chaining is desired, much in the same way that the depth
> >of certificate signing can also be chosen by the user in Apache SSL for
> >example (or, do you really must trust a CA you don't trust just because it
> >chains with a CA you  trust?  -- maybe, possibly not).
>
> Based on this approach we could make all aspects of cert processing
> user selectable options.

No, this is not what I say -- this would be using my words to an extreme
limit where they are obviously false and never intended  to apply, with the
intent to "prove them wrong."  However, anything is wrong if taken out of
context. If we stay with the case at hand and don' try to outwit the
argument by such tricks, then we could recognize that there are cases
where a "one size fits all" does not apply.  Name chaining is, I suggest,
one such case.

Again, this does NOT mean that ALL cases are like it.  The name PKIX,
for example, should not be optional ;-)

> >Making name chaining mandatory, OTOH, still does not mean that
> >the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc.  So,
> >if constraints are placed on names this is still much weaker than the
> >nonce authentication constraints placed on keys -- where a principal
> >must have had use of the private-key in order to sign a nonce.  They
> >are like apples and speedboats, names and keys.  Why then should we
> >not differentiate between name validation and certificate validation?
> >Cert validation may include name validation but not necessarily and
> >there is no cryptographic value to be gained thereby.
>
> Nonce?  What syntax are you referring to?  Ed, we've all had the
> pleasure of your efforts to redefine X.509 on an ab initio basis.
> Please spare us a repeat of such efforts again.

I recall much of my efforts have been in the direction of avoding that some,
including oftentimes you, would needlessly redefine X.509. For example, as I
showed in my analysis of "non-repudiation" as it occurs in the X.509 text itself,
in contrast to what was being defined in PKIX.

Now, if that discussion left some sour tones as I see between the lines in your
text above, please recall that this is an open group based on consensus and that
there are no "winners" or "losers" here -- except our loss of time to go back to that
which is already closed. Unless, of course, you think that there was something in
your arguments then which were not clearly understood by this WG.

Regarding the term "nonce" --  in cryptography, "nonce" is a value used no more
than once for the same purpose.  In X.509, you will find it under the designation
"a non-repeating number" when "strong authentication" is defined.  To avoid
confusion and nitpicking, this what I said above:

 ...if constraints are placed on names this is still much weaker than the
 strong authentication constraints placed on keys -- where a principal
 must have had use of the private-key in order to sign the non-repeating
 number.  They are like apples and speedboats, names and keys.  Why then
 should we not differentiate between name validation and certificate validation?
 Cert validation may include name validation but not necessarily and there is no
 cryptographic value to be gained thereby.

> >Of course, some years ago everything was quite undifferentiated and
> >there was no distinction between different functions which we now
> >perceive as distinct. For example, the CA and the NA roles -- as well as
> >the CA and the TTP roles.
>
> the concept of a naming authority (vs. a CA or a directory service
> provider) have been recognized in the directory community that begat
> X.509, probably for about 15 years.  But, some of the names spaces we
> use, including DNs, don't have  universally recognized NAs, so the
> concept is not universally applicable.  CAs vs. TTPs?  I still think
> that a TTP is just one form of CA, so what's the issue here?

As you have shown with your own words, some issues do have more than
one universally recognized answer. Thus, where there is no bad security
consequence the standard must recognize them.

Cheers,

Ed Gerck

From: Michael Zolotarev <[email-masked]>
To: Martin Szotkowski <[email-masked]>, [email-masked]
Subject: RE: TSA signing key?
Date: Tue, 13 Jun 2000 10:26:45 +1000

Martin,

Not allowing using the same cert for CA and TSA is simply a matter of
clearly specifying what a TTP is doing.  An entity claiming that it is a TSA
(by putting a special value of extKeyUsage flag), accepts certain legal
responsibilities which makes it distinct in the PKI world. The
responsibilities of CA are 100% different from those of TSA, and you would
not generally expect the same physical(!) entity to operate as both a CA and
a TSA.
A CA which signs a TSA cert (if it is not a self-signed), is expected to
perform a diligent check that the subject (TSA) complies to whatever a TSA
must be compliant to.

For those very reasons, as a verifier of a timestamp, I'd never trust a TSA
cert which does not have the extKeyUsage set to "timestamping", and I would
be very suspicious about a TSA cert which has both "timestamping" and "CA"
flags set.

Also, in a TSA cert there may be certain extensions specific to TSA only.
And there are heaps of CA-specific extensions too. Mixing them in one
certificate will be just messy and more than confusing.

If a CA organisation wants to run a TSA, it won't be a problem to issue a
dedicated cert for the TSS, be it a self-signed or a CA-signed certificate.

Hope it answered your question.

Regards
Michael

> -----Original Message-----
> From: Martin Szotkowski [mailto:[email-masked]]
> Sent: Saturday, June 10, 2000 3:00 AM
> To: [email-masked]
> Subject: TSA signing key?
> 
> 
> In draft is written that TSA cert must be used exclusively 
> for time stamp.
> Why TSA certificate cann't be same as CA certificate?
> 
> thanks Martin
> 

Date: Mon, 12 Jun 2000 17:56:30 -0400
To: "william bamberg" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: HTTP over TLS: dNSName syntax question
Cc: <[email-masked]>

Will,

>Sorry if this is marginally off topic, but I'd like to know people's
>opinions...
>
>RFC 2818, 'HTTP over TLS', Section 3.1, 'Server Identity' describes how to
>compare the name in the server's certificate with the server domain name:
>
>'If a subjectAltName extension of type dNSName is present, that MUST be used
>as the identity. Otherwise, the (most specific) Common Name field in the
>Subject field of the certificate MUST be used...Matching is performed using
>the matching rules specified by [RFC2459].'
>
>RFC 2459 says that the dNSName 'MUST be in the "preferred name syntax," as
>specified by RFC 1034.'
>
>So, presumably the matching here is performed by comparing every subdomain
>in the dNSName against the corresponding subdomain in the server's domain
>name.
>
>But RFC 2818 goes on to say that 'Names may contain the wildcard character
>*'
>and goes on to specify how these names should be handled.
>
>The 'preferred name syntax' says nothing about wildcards, so my question
>really is, how can the dNSName component both be represented according to
>the 'preferred name syntax', and contain wildcards?

RFC 2459 does not allow wildcards in the dNSname attribute, as that 
would result in strings that are NOT DNS names.  The 2818 text refers 
to an historic convention employed when CAs put DNS names in the CN 
field of a DN.   In fact, the text you cite refers to this convention 
(that is disparaged in 2459).  Note the reference to "Common Name" in 
that text.  So, it seems that the 2818 text is a bit schizophrenic, 
based on what you say above.  (I have not read 2818, so I am taking 
your word for the relevant quote.)

Steve

Date: Mon, 12 Jun 2000 17:44:58 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Correct approach to certificate validation?
Cc: [email-masked]

Ed,

>Oscar Jacobsson wrote:
>
>  > Ed Gerck wrote:
>  > > So, now the name should trump the key? The tail wants to wag the
>  > > dog, we may as well say.
>  >
>
>  > However: if constraints are placed on subject names, they are most
>  > probably placed there for a reason. Ignoring said constraints, having
>  > been deemed important enough to distribute signed and in-band, could
>  > surely hardly be considered prudent?
>
>A checkbox with "Enforce name chaining" could take care of all cases
>where name chaining is desired, much in the same way that the depth
>of certificate signing can also be chosen by the user in Apache SSL for
>example (or, do you really must trust a CA you don't trust just because it
>chains with a CA you  trust?  -- maybe, possibly not).

Based on this approach we could make all aspects of cert processing 
user selectable options.  But, that's not what we have done. We have 
divided processing rules into those that are uniformly enforced (in 
principle), those under CA control, and those under user control. 
Given the difficulty of getting local configuration info right, it's 
preferable to minimize this last set.

>Making name chaining mandatory, OTOH, still does not mean that
>the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc.  So,
>if constraints are placed on names this is still much weaker than the
>nonce authentication constraints placed on keys -- where a principal
>must have had use of the private-key in order to sign a nonce.  They
>are like apples and speedboats, names and keys.  Why then should we
>not differentiate between name validation and certificate validation?
>Cert validation may include name validation but not necessarily and
>there is no cryptographic value to be gained thereby.

Nonce?  What syntax are you referring to?  Ed, we've all had the 
pleasure of your efforts to redefine X.509 on an ab initio basis. 
Please spare us a repeat of such efforts again.

>Of course, some years ago everything was quite undifferentiated and
>there was no distinction between different functions which we now
>perceive as distinct. For example, the CA and the NA roles -- as well as
>the CA and the TTP roles.

the concept of a naming authority (vs. a CA or a directory service 
provider) have been recognized in the directory community that begat 
X.509, probably for about 15 years.  But, some of the names spaces we 
use, including DNs, don't have  universally recognized NAs, so the 
concept is not universally applicable.  CAs vs. TTPs?  I still think 
that a TTP is just one form of CA, so what's the issue here?

Steve

Date: Mon, 12 Jun 2000 17:36:35 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Correct approach to certificate validation?
Cc: <[email-masked]>

Trevor,

>Steve,
>With the Internet today, if you are relying on directory lookup 
>based on a DN as you only solution to certificate discovery - I 
>think you will be disappointed. There will be "communities" who will 
>be able to get this to work, but there is no sign of a universal 
>solution equivalent to DNS where I can take any DN and find an 
>object in a directory with that name. Therefore failure to find a 
>certificate based on a issuer DN in a certificate is a reality that 
>will have to be dealt with - for much more fundamental reasons.

In general I agree if we're talking about most DNs, and that's why I 
alluded to use of AIA.  But, if one used DC-based DNs, we could 
leverage the DNS and that would be very powerful. So, for those who 
might choose to rely on this or analogous discovery approaches, 
mismatches between CA names in subject and issuer fields would pose a 
problem. Facilitating an environment in which such mismatches are 
tolerated by client software undermines the efforts of those who 
might be trying to use CA DNs for repository discovery.

>
>There are a couple of instances of by design behavior that have been 
>presented to me. There are mergers and acquisitions where names and 
>affiliation are changing. There are also instances where one CA does 
>not want to endorse the name of another when it cross certifies.

The first example does not seem very good; as someone else noted, I 
would want to reissue the EE certs as much as I want to change the CA 
cert.  I've gone through a bunch of business cards over the last few 
years as we wer bought, reorganized, bought again, etc.

>
>The search path mechanism is very similar to AIA, in that given a 
>set of URLs, you can access the URL looking for certificates. With 
>LDAP URLs, it's not difficult to construct a generic query. With 
>other, the underlying assumption is that you find a pkcs#7.

The "algorithm" you allude to seems a bit squishy :-), and its 
scaling features are not at all clear.

Steve

Date: Mon, 12 Jun 2000 16:17:56 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Correct approach to certificate validation?
Cc: [email-masked]

Ed,

>Stephen Kent wrote:
>
>  > Ed,
>  > >List:
>  > >
>  > >Why should we continue to confuse name validation with
>  > >certificate validation?  Name chaining should be optional IMO,
>  > >not expected behavior. 'Be liberal in what you expect' can be
>  > >applied here without  A N Y  decrease in cryptographic
>  > >authentication security.
>  > >
>  >
>  > Jon's protocol design advice is good in general, but inappropriate in
>  > security contexts, where liberal acceptance policies often lead to
>  > vulnerabilities.
>
>In this case, however, I see no vulnerability in what X.509/PKIX
>intend to provide -- a cryptographic authentication protocol.  In
>regard to name assignment vulnerabilities, I note that this is also
>declared out of scope in X.509/PKIX  and delegated to the CA/NA
>+ CPS.

My observation about the applicability of Jon's admonition to 
security protocols in general is true.  So far we don't have a killer 
example of a new vulnerability created by this deviation from the 
standards, just user confusion.
Someone suggested to me that if a user is examining the CA names in a 
path to make a trust judgement, then this inconsistency might cause 
the user to make a wrong trust decision.  I don't know if this is 
critical, because I doubt that many users would be so diligent, but 
it is an example of what might happen.  You state that our standards 
do not address name assignment vulnerabilities; we'll PKIX is trying 
to do this to some extent. There was already some text about a CA's 
responsibility to verify name data in  a cert, although that must be 
qualified by the CPS/policy.  As others have pointed out, there is a 
fine line here.  We don't want to usurp the CA's options here, yet we 
want to make a general statement about what an RP can expect in a 
cert.

>So, why should that which is declared out of scope trump that
>which is the only thing that the protocol verifies?  Logic would
>indicate that since name validation by name chaining verification
>is a weaker concept than the one it is blocking, then this should
>not be mandatory behavior.  Making it mandatory is what is
>confusing, IMO.

We disagree on fundamentals here.  Name verification in the context 
of chaining is what one would expect from reading ANY description of 
X.509 certificates for over a decade and a half.  There should be a 
very good reason to NOT do it before such a deviation from the 
standards is considered reasonable.

Steve

From: "Pawling, John" <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "'500 list'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Hoyt Kesterson'" <[email-masked]>
Subject: RE: New X.509 defect is 244
Date: Mon, 12 Jun 2000 11:04:17 -0400

All,

I strongly agree with the solutions proposed in X.509 defect report 244.
These changes are important to ensure that certification path verification
implementations process all non-critical extensions that they recognize and
are capable of processing.

============================================
John Pawling, [email-masked]
Wang Government Services, Inc.,
A Getronics Company
============================================ 

From: Sharon Boeyen <[email-masked]>
To: "'500 list'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Hoyt Kesterson'" <[email-masked]>
Subject: RE: New X.509 defect is 244
Date: Mon, 12 Jun 2000 10:58:22 -0400

Oops, we were actually more efficient that I thought. I did get the 
defect report number from Hoyt before I went on vacation. This is 
defect report number 244.

(Note that we may also probably should look at the conformance 
statements in X.519 and, duplicate appropriate material in 509 itself 
so that it can stand alone.

> -----Original Message-----
> From: Sharon Boeyen 
> Sent: Monday, June 12, 2000 10:41 AM
> To: '500 list'
> Cc: [email-masked]'; [email-masked]'; 'Hoyt Kesterson'
> Subject: New X.509 defect report
> 
> 
> This is a new defect report against X.509 (1997 and 2000 
> editions). It 
> emerged from the US Bridge CA project participants and indicates that 
> text regarding handling of non-critical extensions has flaws 
> and needs 
> to be fixed. 
> 
> I'm submitting this defect report but it represents the result of 
> discussion that occured among the Bridge CA project participants.
> 
> Also, I apologize for not including a defect report number but Hoyt 
> is away and I was unable to reach him to get one. 
> 
> Hoyt, can you tell us what DR number this will be?
> 
> Sharon
> 
> 
> DEFECT REPORT FORM
> 
> 1. Defect Report Number:  9594/XXX
> 
> 
> Title: Handling non-critical extensions
> 
> 2. Source:  X.509 Editor (on behalf of US Bridge CA project 
> participants)
> 
> 3. Addressed to:
> 4.  (a)
>     (b)
> 
> 5. Date circulated by WG Secretariat:
> 
> 6. Deadline for Response from Editor:
> 
> 7. Defect Report Concerning: 
> 
> ITU-T X.509 (1997 and 2000 editions) | ISO/IEC 9594-8:1997 
> and 2000 editions
> 
> 8. Qualifier:
> 
> Error/Clarification 
> 
> 9. References in Document:
> 
> Several, See solution proposed by source
> 
> 10. Nature of Defect:
> 
> X.509 clearly states what a certificate-using 
> system is do in the case where certificate extensions are present and 
> are are flagged critical. It also clearly states what a 
> certificate-using
> system is to do in the case where certificate extensions are 
> present, flagged
> non-critical, but are not recognized by a certificate-using 
> system. However, 
> there are errors, ambiguities and omissions about what a 
> certificate-using system 
> is to do when encountering a certificate extension flagged 
> non-critical, that it 
> does recognize and is capable of processing. To ensure that 
> the requirements of 
> certificate and CRL issuers, as well as requirements for 
> consistent treatment 
> of extensions by certificate-using systems, these errors must 
> be fixed.
> 
> 
> 11. Solution Proposed by the Source:
> 
> In ITU-T Rec. X.509 and ISO/IEC 9594-8:
> 
> Change 1:  In 1997 edition clause 8 and 2000 edition clause 7: 
> 
> In the paragraph that begins "The extensions field allows 
> addition of new ...",
> add the following two sentences to the end of the paragraph:
> 
> " When a certificate-using implementation recognizes and is 
> able to process an extension, then 
> the certificate-using implementation shall process the 
> extension regardless of the value 
> of the criticality flag. Note that any extension that is 
> flagged non-critical will cause 
> inconsistent behaviour between certificate-using systems that 
> will process the extension and 
> certificate-using that do not recognize the extension and 
> will ignore it."
> 
> Change 2: In 1997 edition clause 8 and 2000 edition clause 7:
> 
> Add the following immediately after the paragraph that begins "If 
> unknown elements appear within the extension ...":
> 
> A CA has three options with respect to an extension:
> i) it can exclude the extension from the certificate;
> ii) it can include the extension and flag it non-critical;
> iii) it can include the extension and flag it critical.
> 
> A validation engine has two possible actions to take with 
> respect to an extension:
> i) it can ignore the extension and accept the certificate 
> (all other things being equal);
> ii) it can process the extension and accept or reject the 
> certificate depending on the 
> content of the extension and the conditions under which 
> processing is occuring 
> (e.g. the current values of the path processing variables). 
> 
> Some extensions can ONLY be marked critical. In these cases a 
> validation engine that 
> understands the extension, processes it and 
> acceptance/rejection of the certificate 
> is dependent (at least in part) on the content of the 
> extension. A validation engine 
> that does not understand the extension rejects the certificate.
> 
> Some extensions can ONLY be marked non-critical. In these 
> cases a validation engine that 
> understands the extension processes it and 
> acceptance/rejection of the certificate is 
> dependent (at least in part) on the content of the extension. 
> A validation engine that 
> does not understand the extension accepts the certificate 
> (unless factors other than 
> this extension cause it to be rejected).
> 
> Some extensions can be marked critical or non-critical. In 
> these cases a validation engine 
> that understands the extension processes it and 
> acceptance/rejection of the certificate is 
> dependent (at least in part) on the content of the extension, 
> regardless of the criticality 
> flag. A validation engine that does not understand the 
> extension accepts the certificate if 
> the extension is marked non-critical (unless factors other 
> than this extension cause it to 
> be rejected) and rejects the certificate if the extension is 
> marked critical.
> 
> When a CA considers including an extension in a certificate 
> it does so with
> the expectation that its intent will be adhered to wherever 
> possible. If it
> is necessary that the content of the extension be considered 
> prior to ANY
> reliance on the certificate, a CA would flag the extension 
> critical. This
> must be done with the realization that any validation engine 
> that does not
> process the extension will reject the certificate (probably 
> limiting the set
> of applications that can verify the certificate). The a CA 
> may mark certain
> extensions non-critical to achieve backward compatibility 
> with validation
> applications that cannot process the extensions. Where the 
> need for backward
> compatibility and interoperability with validation 
> applications incapable of
> processing the extensions is more vital than the ability of the CA to
> enforce the extensions, then these optionally critical 
> extensions would be
> marked non-critical.  It is most likely that CAs would set 
> optionally critical 
> extensions as non-critical during a transition period while 
> the verifiers' 
> certificate processing applications are upgraded to ones that 
> can process the
> extensions.
> 
> Change 3:  In 1997 edition clause 12.1 and 2000 edition clause 8:
> 
> In the paragraph that begins "In a certificate or CRL, an 
> extension is flagged ...",
> add the following immediately after the third sentence that 
> ends with "...ignoring 
> the extension":
> 
> " If an extension is flagged non-critical, a 
> certificate-using system that does 
> recognize the extension, shall process the extension."
> 
> Change 4:  In 1997 edition clause 12.2.2.3 and 2000 edition 
> clause 8.2.2.3:
> 
> In the paragraph that begins "If the extension is flagged 
> non-critical ...", replace
> the second sentence with the following:
> 
> "If this extension is present, and the certificate-using 
> system recognizes and processes
> the keyUsage extension type, then the certificate using 
> system shall ensure that the 
> certificate shall be used only for a purpose for which the 
> corresponding key usage 
> bit is set to one."
> 
> Change 5:  In 1997 edition clause 12.2.2.4 and 2000 edition 
> clause 8.2.2.4:
> 
> In the paragraph that begins "If the extension is flagged 
> non-critical ...", replace
> the second and third sentences with the following:
> 
> "If this extension is present, and the certificate-using 
> system recognizes and processes
> the extendedKeyUsage extension type, then the certificate 
> using system shall ensure that the 
> certificate shall be used only for one of the purposes indicated."
> 
> Change 6:  In 1997 edition clause 12.4.2.1 and 2000 edition 
> clause 8.4.2.1:
> 
> In the 4th paragraph following the ASN.1, replace:
> "If this extension is present and is flagged critical then:" 
> with the following:
> "If this extension is present and is flagged critical, or is 
> flagged non-critical but is 
> recognized by the certificate-using system, then:"
> 
> Change 7:  In 1997 edition clause 12.4.2.2 and 2000 edition 
> clause 8.4.2.2:
> 
> Replace the last sentence "If this extension is present and 
> is flagged critical ..." with the 
> following:
> 
> "If this extension is present and is flagged critical, or is 
> flagged non-critical but 
> is recognized by the certificate-using system, then the 
> certificate-using system shall 
> check that the certification path being processed is 
> consistent with the value in this
> extension."
> 
> 
> 
> 12. Editor's Response:
> 
> tbd
> 
> 
> 
> Sharon Boeyen
> Entrust Technologies
> [email-masked]
> 

From: Sharon Boeyen <[email-masked]>
To: "'500 list'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Hoyt Kesterson'" <[email-masked]>
Subject: New X.509 defect report
Date: Mon, 12 Jun 2000 10:40:51 -0400

This is a new defect report against X.509 (1997 and 2000 editions). It 
emerged from the US Bridge CA project participants and indicates that 
text regarding handling of non-critical extensions has flaws and needs 
to be fixed. 

I'm submitting this defect report but it represents the result of 
discussion that occured among the Bridge CA project participants.

Also, I apologize for not including a defect report number but Hoyt 
is away and I was unable to reach him to get one. 

Hoyt, can you tell us what DR number this will be?

Sharon

DEFECT REPORT FORM

1. Defect Report Number:  9594/XXX

Title: Handling non-critical extensions

2. Source:  X.509 Editor (on behalf of US Bridge CA project participants)

3. Addressed to:
4.  (a)
    (b)

5. Date circulated by WG Secretariat:

6. Deadline for Response from Editor:

7. Defect Report Concerning: 

ITU-T X.509 (1997 and 2000 editions) | ISO/IEC 9594-8:1997 and 2000 editions

8. Qualifier:

Error/Clarification 

9. References in Document:

Several, See solution proposed by source

10. Nature of Defect:

X.509 clearly states what a certificate-using 
system is do in the case where certificate extensions are present and 
are are flagged critical. It also clearly states what a certificate-using
system is to do in the case where certificate extensions are present,
flagged
non-critical, but are not recognized by a certificate-using system. However,

there are errors, ambiguities and omissions about what a certificate-using
system 
is to do when encountering a certificate extension flagged non-critical,
that it 
does recognize and is capable of processing. To ensure that the requirements
of 
certificate and CRL issuers, as well as requirements for consistent
treatment 
of extensions by certificate-using systems, these errors must be fixed.

11. Solution Proposed by the Source:

In ITU-T Rec. X.509 and ISO/IEC 9594-8:

Change 1:  In 1997 edition clause 8 and 2000 edition clause 7: 

In the paragraph that begins "The extensions field allows addition of new
...",
add the following two sentences to the end of the paragraph:

" When a certificate-using implementation recognizes and is able to process
an extension, then 
the certificate-using implementation shall process the extension regardless
of the value 
of the criticality flag. Note that any extension that is flagged
non-critical will cause 
inconsistent behaviour between certificate-using systems that will process
the extension and 
certificate-using that do not recognize the extension and will ignore it."

Change 2: In 1997 edition clause 8 and 2000 edition clause 7:

Add the following immediately after the paragraph that begins "If 
unknown elements appear within the extension ...":

A CA has three options with respect to an extension:
i) it can exclude the extension from the certificate;
ii) it can include the extension and flag it non-critical;
iii) it can include the extension and flag it critical.

A validation engine has two possible actions to take with respect to an
extension:
i) it can ignore the extension and accept the certificate (all other things
being equal);
ii) it can process the extension and accept or reject the certificate
depending on the 
content of the extension and the conditions under which processing is
occuring 
(e.g. the current values of the path processing variables). 

Some extensions can ONLY be marked critical. In these cases a validation
engine that 
understands the extension, processes it and acceptance/rejection of the
certificate 
is dependent (at least in part) on the content of the extension. A
validation engine 
that does not understand the extension rejects the certificate.

Some extensions can ONLY be marked non-critical. In these cases a validation
engine that 
understands the extension processes it and acceptance/rejection of the
certificate is 
dependent (at least in part) on the content of the extension. A validation
engine that 
does not understand the extension accepts the certificate (unless factors
other than 
this extension cause it to be rejected).

Some extensions can be marked critical or non-critical. In these cases a
validation engine 
that understands the extension processes it and acceptance/rejection of the
certificate is 
dependent (at least in part) on the content of the extension, regardless of
the criticality 
flag. A validation engine that does not understand the extension accepts the
certificate if 
the extension is marked non-critical (unless factors other than this
extension cause it to 
be rejected) and rejects the certificate if the extension is marked
critical.

When a CA considers including an extension in a certificate it does so with
the expectation that its intent will be adhered to wherever possible. If it
is necessary that the content of the extension be considered prior to ANY
reliance on the certificate, a CA would flag the extension critical. This
must be done with the realization that any validation engine that does not
process the extension will reject the certificate (probably limiting the set
of applications that can verify the certificate). The a CA may mark certain
extensions non-critical to achieve backward compatibility with validation
applications that cannot process the extensions. Where the need for backward
compatibility and interoperability with validation applications incapable of
processing the extensions is more vital than the ability of the CA to
enforce the extensions, then these optionally critical extensions would be
marked non-critical.  It is most likely that CAs would set optionally
critical 
extensions as non-critical during a transition period while the verifiers' 
certificate processing applications are upgraded to ones that can process
the
extensions.

Change 3:  In 1997 edition clause 12.1 and 2000 edition clause 8:

In the paragraph that begins "In a certificate or CRL, an extension is
flagged ...",
add the following immediately after the third sentence that ends with
"...ignoring 
the extension":

" If an extension is flagged non-critical, a certificate-using system that
does 
recognize the extension, shall process the extension."

Change 4:  In 1997 edition clause 12.2.2.3 and 2000 edition clause 8.2.2.3:

In the paragraph that begins "If the extension is flagged non-critical ...",
replace
the second sentence with the following:

"If this extension is present, and the certificate-using system recognizes
and processes
the keyUsage extension type, then the certificate using system shall ensure
that the 
certificate shall be used only for a purpose for which the corresponding key
usage 
bit is set to one."

Change 5:  In 1997 edition clause 12.2.2.4 and 2000 edition clause 8.2.2.4:

In the paragraph that begins "If the extension is flagged non-critical ...",
replace
the second and third sentences with the following:

"If this extension is present, and the certificate-using system recognizes
and processes
the extendedKeyUsage extension type, then the certificate using system shall
ensure that the 
certificate shall be used only for one of the purposes indicated."

Change 6:  In 1997 edition clause 12.4.2.1 and 2000 edition clause 8.4.2.1:

In the 4th paragraph following the ASN.1, replace:
"If this extension is present and is flagged critical then:" with the
following:
"If this extension is present and is flagged critical, or is flagged
non-critical but is 
recognized by the certificate-using system, then:"

Change 7:  In 1997 edition clause 12.4.2.2 and 2000 edition clause 8.4.2.2:

Replace the last sentence "If this extension is present and is flagged
critical ..." with the 
following:

"If this extension is present and is flagged critical, or is flagged
non-critical but 
is recognized by the certificate-using system, then the certificate-using
system shall 
check that the certification path being processed is consistent with the
value in this
extension."

12. Editor's Response:

tbd

Sharon Boeyen
Entrust Technologies
[email-masked]

content-class: urn:content-classes:message
Subject: RE: Correct approach to certificate validation?
Date: Sun, 11 Jun 2000 18:36:53 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Al Arsenault" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD40E.AFF1AEB2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Al,
There are two players in this piece. CA and relying parties. THE only
point where the name chaining rule can be enforced reliably is when
building a self signed root certificate.=20
It you are asserting that if by some change a set of certificate was
built where the names did not chain, and that clients who enforced the
name chaining rule would consider the chain invalid, whereas clients
which did not enforce the rule would consider the chain as valid, then I
agree.=20
What I don't see is justification of the rule as being necessary.
Why is this rule considered necessary in the standard?
Trevor

 -----Original Message-----
From: 	Al Arsenault [mailto:[email-masked]]=20
Sent:	Thursday, June 08, 2000 7:32 PM
To:	Trevor Freeman
Cc:	David P. Kemp; [email-masked]
Subject:	Re: Correct approach to certificate validation?

Trevor,

	Here's the justification:

	Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign,
whomever) has been built to conform to existing/understood X.509/RFC2459
name chaining rules.  Suppose that such a system has been deployed for,
oh, say, a large Government department, or a large corporation, or...

	Now, suppose that a CA from some other corporation that follows
the
rules you suggest - i.e., name chaining doesn't matter.  We want to
integrate that CA into the existing PKI. =20

	Now, for whatever reason - human frailty, whatever - that new CA
is
used to create a certificate whose distinguish name is "C=3DAW,
O=3DGovernment, OU=3D Computers, CN=3D CA1", and then that CA creates =
user
certs where the issuer name is "C=3DAW, O=3DGovernment, OU=3DComputer,
CN=3DCA1".  Note that these names are not equivalent.*

	Suppose that all other information - AKI, AIA, etc. - is set up
properly.

	Now, whenever a cert path is validated using the new CA, it will
be
validated, because the fact that the end entity cert's issuer name and
the CA cert's subject name aren't the same doesn't matter.  However,
whenever that same cert path is validated by a node in the existing PKI,
validation will fail, because of the name chaining failure. The notion
of obtaining different results by different points in the system is
disconcerting, to say the least.

	That's the reason:  by building your system this way, you cause
the
multi-vendor interoperable PKI to fail.  If you were building your
system to not interoperate with any other existing products, then I
think we could probably agree that you were right; there is no real
reason that names have to chain.  However, lots of people do want your
system to interoperate with other products.  I'm fairly confident that
Dave wants them to.  I know that in some of the cases I'm dealing with
now, I need them to.  And they don't.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

*And yes, I have seen cases where name chaining failed - and thus
certificate validation failed when it shouldn't have - because of a
misplaced comma in a CN field.  I've also seen it fail because of an
extra space in an OU field, and several other situations.

> Trevor Freeman wrote:
>=20
> Life is complicated, but this is not so bad - Isaac Newton's rules
> where around a lot longer before they were found to be wrong.
> I am still waiting to here further justification (beyond the old
> ground of "its in the spec"). and so far you are confirming my
> suspicions that there are none.
>=20
>  -----Original Message-----
> From:   David P. Kemp [mailto:[email-masked]]
> Sent:   Thursday, June 08, 2000 8:35 AM
> To:     [email-masked]
> Subject:        RE: Correct approach to certificate validation?
>=20
> Trevor,
>=20
> > From: "Trevor Freeman" <[email-masked]>
> >
> > David,
> > Interoperability is a primary goal, however that is often scarified
> by
> > standards. It is very easy to produce a document with a set of do's
> and
> > don'ts  without any regard for the previous standard, the impact on
> the
> > deployed products or how migration is achieved between the old and
> new
> > standard. It is also unrealistic to think that all products deployed
> > would conform to a single standard. Most products have a lifetime of
> > years. The interoperability matrix is vast and getting worse every
> time
> > a new version of  a standard is released.
> > So to return to the original point, besides citing a 20 year old
> clause
> > in a standard, and saying we should do it because its in the
> standard,
> > and requiring administrators to have a faultless record, I have
> still
> > not hear any reasoned, argument as to what is actually achieved by
> this
> > behavior.
> > No standard or clause in a standard has a divine right of existence.
> > Trevor
>=20
> On the one hand, you seem to be decrying the ease of producing new
> specifications without regard for previous standards and deployed
> products.
>=20
> On the other, you seem to support discarding a 20 year old clause
> in a standard without regard for its impact on deployed products which
> have been built according to the standard.
>=20
> The "divine right" of any clause comes not from heaven or inheritance,
> but from the fact that it has been vetted internationally (in the ISO
> and the IETF) over a period of many years.  Over that time (whether
> it's
> 12 or 20 years is immaterial), the requirement that certificates point
> to the correct issuer has not only survived, it has not to my
> knowledge
> been even mildly controversial.   Now that there is discussion of
> the topic, the requirement will either survive or be discarded based
> on international consensus.   There is no divine right, just the
> stability (inertia?) of a consensus-based standard-setting
> process.
>=20
> You may present a case that the requirement should be removed from
> X.509
> and then from the PKIX profile of X.509.
> Or you may choose not to comply with X.509.
>=20
> But you can't both ignore the requirement and claim compliance.
>=20
> > Certificate discovery is not the issue here.
> >
> > For certificate discovery,  we have a domain push mechanism as well
> as
> > AIA. We are also adding a lookup by name, and a configurable URL
> search
> > path i.e. a set of URLs to search (LDAP, HTTP, FTP)
>=20
> Certificate discovery *is* the issue.
>=20
> If you are adding a "lookup by name" function to your products,
> how will that work if certificates do not have correct issuer
> names?  If I have someone's End Entity certificate, how do I find a
> path of CA certs that leads to my trust point (not necessarily the
> certificate subject's trust point), in the multi-vendor,
> multi-administrative-domain environment of the Internet.
>=20
> Products may support many certificate discovery mechanisms, both
> standards-based and differentiating.  But there needs to be at
> least one "Internet" interoperability mode which all products
> support.  That mode is defined by PKIX: the certificate profile
> and the LDAP schema.
>=20
> One "Internet mode" mechanism which follows the current PKIX
> specifications is for organizations to place public information,
> including CA and EE certificates, in border directories, and to link
> the border directories together using directory-to-directory chaining,
> LDAP referrals, or both.  If you propose to eliminate the X.509
> requirement for correct issuer names, you will need to address the
> impact on current applications built to the current standards,
> as well as the feasability of future applications built to an
> amended standard.
>=20
> Dave
>=20
> P.S.  I don't understand why you keep referring to "punishing
> administrators" and "requiring administrators to have a flawless
> record" and "eliminating imperfection".  A CA workstation has its own
> signing key and certificate.  If the workstation cannot correctly
> place
> its own name in the issuer field of every certificate it signs, that
> is
> a product flaw.  This X.509 requirement does not hinge upon human
> perfectability.

------_=_NextPart_001_01BFD40E.AFF1AEB2
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 =
6.0.4390.0">
<TITLE>RE: Correct approach to certificate validation?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Al,</FONT>

<BR><FONT SIZE=3D2>There are two players in this piece. CA and relying =
parties. THE only point where the name chaining rule can be enforced =
reliably is when building a self signed root certificate. </FONT></P>

<P><FONT SIZE=3D2>It you are asserting that if by some change a set of =
certificate was built where the names did not chain, and that clients =
who enforced the name chaining rule would consider the chain invalid, =
whereas clients which did not enforce the rule would consider the chain =
as valid, then I agree. </FONT></P>

<P><FONT SIZE=3D2>What I don't see is justification of the rule as being =
necessary.</FONT>

<BR><FONT SIZE=3D2>Why is this rule considered necessary in the =
standard?</FONT>

<BR><FONT SIZE=3D2>Trevor</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: &nbsp; Al Arsenault [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>

<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Thursday, June 08, 2000 7:32 =
PM</FONT>

<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Trevor Freeman</FONT>

<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; David P. Kemp; =
[email-masked]</FONT>

<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Re: Correct approach to certificate validation?</FONT>
</P>

<P><FONT SIZE=3D2>Trevor,</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Here's the =
justification:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Suppose =
that a CA system (by, e.g., Netscape, Entrust, VeriSign,</FONT>

<BR><FONT SIZE=3D2>whomever) has been built to conform to =
existing/understood X.509/RFC2459</FONT>

<BR><FONT SIZE=3D2>name chaining rules.&nbsp; Suppose that such a system =
has been deployed for,</FONT>

<BR><FONT SIZE=3D2>oh, say, a large Government department, or a large =
corporation, or...</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Now, =
suppose that a CA from some other corporation that follows the</FONT>

<BR><FONT SIZE=3D2>rules you suggest - i.e., name chaining doesn't =
matter.&nbsp; We want to</FONT>

<BR><FONT SIZE=3D2>integrate that CA into the existing PKI.&nbsp; =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Now, for =
whatever reason - human frailty, whatever - that new CA is</FONT>

<BR><FONT SIZE=3D2>used to create a certificate whose distinguish name =
is &quot;C=3DAW,</FONT>

<BR><FONT SIZE=3D2>O=3DGovernment, OU=3D Computers, CN=3D CA1&quot;, and =
then that CA creates user</FONT>

<BR><FONT SIZE=3D2>certs where the issuer name is &quot;C=3DAW, =
O=3DGovernment, OU=3DComputer,</FONT>

<BR><FONT SIZE=3D2>CN=3DCA1&quot;.&nbsp; Note that these names are not =
equivalent.*</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Suppose =
that all other information - AKI, AIA, etc. - is set up</FONT>

<BR><FONT SIZE=3D2>properly.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Now, =
whenever a cert path is validated using the new CA, it will be</FONT>

<BR><FONT SIZE=3D2>validated, because the fact that the end entity =
cert's issuer name and</FONT>

<BR><FONT SIZE=3D2>the CA cert's subject name aren't the same doesn't =
matter.&nbsp; However,</FONT>

<BR><FONT SIZE=3D2>whenever that same cert path is validated by a node =
in the existing PKI,</FONT>

<BR><FONT SIZE=3D2>validation will fail, because of the name chaining =
failure. The notion</FONT>

<BR><FONT SIZE=3D2>of obtaining different results by different points in =
the system is</FONT>

<BR><FONT SIZE=3D2>disconcerting, to say the least.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>That's the =
reason:&nbsp; by building your system this way, you cause the</FONT>

<BR><FONT SIZE=3D2>multi-vendor interoperable PKI to fail.&nbsp; If you =
were building your</FONT>

<BR><FONT SIZE=3D2>system to not interoperate with any other existing =
products, then I</FONT>

<BR><FONT SIZE=3D2>think we could probably agree that you were right; =
there is no real</FONT>

<BR><FONT SIZE=3D2>reason that names have to chain.&nbsp; However, lots =
of people do want your</FONT>

<BR><FONT SIZE=3D2>system to interoperate with other products.&nbsp; I'm =
fairly confident that</FONT>

<BR><FONT SIZE=3D2>Dave wants them to.&nbsp; I know that in some of the =
cases I'm dealing with</FONT>

<BR><FONT SIZE=3D2>now, I need them to.&nbsp; And they don't.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Al =
Arsenault</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Chief Security =
Architect</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Diversinet =
Corp.</FONT>
</P>

<P><FONT SIZE=3D2>*And yes, I have seen cases where name chaining failed =
- and thus</FONT>

<BR><FONT SIZE=3D2>certificate validation failed when it shouldn't have =
- because of a</FONT>

<BR><FONT SIZE=3D2>misplaced comma in a CN field.&nbsp; I've also seen =
it fail because of an</FONT>

<BR><FONT SIZE=3D2>extra space in an OU field, and several other =
situations.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Trevor Freeman wrote:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Life is complicated, but this is not so bad - =
Isaac Newton's rules</FONT>

<BR><FONT SIZE=3D2>&gt; where around a lot longer before they were found =
to be wrong.</FONT>

<BR><FONT SIZE=3D2>&gt; I am still waiting to here further justification =
(beyond the old</FONT>

<BR><FONT SIZE=3D2>&gt; ground of &quot;its in the spec&quot;). and so =
far you are confirming my</FONT>

<BR><FONT SIZE=3D2>&gt; suspicions that there are none.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From:&nbsp;&nbsp; David P. Kemp [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</=
FONT>

<BR><FONT SIZE=3D2>&gt; Sent:&nbsp;&nbsp; Thursday, June 08, 2000 8:35 =
AM</FONT>

<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Correct approach =
to certificate validation?</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Trevor,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; From: &quot;Trevor Freeman&quot; =
&lt;[email-masked]&gt;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; David,</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; Interoperability is a primary goal, however =
that is often scarified</FONT>

<BR><FONT SIZE=3D2>&gt; by</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; standards. It is very easy to produce a =
document with a set of do's</FONT>

<BR><FONT SIZE=3D2>&gt; and</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; don'ts&nbsp; without any regard for the =
previous standard, the impact on</FONT>

<BR><FONT SIZE=3D2>&gt; the</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; deployed products or how migration is =
achieved between the old and</FONT>

<BR><FONT SIZE=3D2>&gt; new</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; standard. It is also unrealistic to think =
that all products deployed</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; would conform to a single standard. Most =
products have a lifetime of</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; years. The interoperability matrix is vast =
and getting worse every</FONT>

<BR><FONT SIZE=3D2>&gt; time</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; a new version of&nbsp; a standard is =
released.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; So to return to the original point, besides =
citing a 20 year old</FONT>

<BR><FONT SIZE=3D2>&gt; clause</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; in a standard, and saying we should do it =
because its in the</FONT>

<BR><FONT SIZE=3D2>&gt; standard,</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; and requiring administrators to have a =
faultless record, I have</FONT>

<BR><FONT SIZE=3D2>&gt; still</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; not hear any reasoned, argument as to what =
is actually achieved by</FONT>

<BR><FONT SIZE=3D2>&gt; this</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; behavior.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; No standard or clause in a standard has a =
divine right of existence.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; Trevor</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; On the one hand, you seem to be decrying the =
ease of producing new</FONT>

<BR><FONT SIZE=3D2>&gt; specifications without regard for previous =
standards and deployed</FONT>

<BR><FONT SIZE=3D2>&gt; products.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; On the other, you seem to support discarding a =
20 year old clause</FONT>

<BR><FONT SIZE=3D2>&gt; in a standard without regard for its impact on =
deployed products which</FONT>

<BR><FONT SIZE=3D2>&gt; have been built according to the =
standard.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; The &quot;divine right&quot; of any clause comes =
not from heaven or inheritance,</FONT>

<BR><FONT SIZE=3D2>&gt; but from the fact that it has been vetted =
internationally (in the ISO</FONT>

<BR><FONT SIZE=3D2>&gt; and the IETF) over a period of many years.&nbsp; =
Over that time (whether</FONT>

<BR><FONT SIZE=3D2>&gt; it's</FONT>

<BR><FONT SIZE=3D2>&gt; 12 or 20 years is immaterial), the requirement =
that certificates point</FONT>

<BR><FONT SIZE=3D2>&gt; to the correct issuer has not only survived, it =
has not to my</FONT>

<BR><FONT SIZE=3D2>&gt; knowledge</FONT>

<BR><FONT SIZE=3D2>&gt; been even mildly controversial.&nbsp;&nbsp; Now =
that there is discussion of</FONT>

<BR><FONT SIZE=3D2>&gt; the topic, the requirement will either survive =
or be discarded based</FONT>

<BR><FONT SIZE=3D2>&gt; on international consensus.&nbsp;&nbsp; There is =
no divine right, just the</FONT>

<BR><FONT SIZE=3D2>&gt; stability (inertia?) of a consensus-based =
standard-setting</FONT>

<BR><FONT SIZE=3D2>&gt; process.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; You may present a case that the requirement =
should be removed from</FONT>

<BR><FONT SIZE=3D2>&gt; X.509</FONT>

<BR><FONT SIZE=3D2>&gt; and then from the PKIX profile of X.509.</FONT>

<BR><FONT SIZE=3D2>&gt; Or you may choose not to comply with =
X.509.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; But you can't both ignore the requirement and =
claim compliance.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; Certificate discovery is not the issue =
here.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; For certificate discovery,&nbsp; we have a =
domain push mechanism as well</FONT>

<BR><FONT SIZE=3D2>&gt; as</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; AIA. We are also adding a lookup by name, =
and a configurable URL</FONT>

<BR><FONT SIZE=3D2>&gt; search</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; path i.e. a set of URLs to search (LDAP, =
HTTP, FTP)</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Certificate discovery *is* the issue.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; If you are adding a &quot;lookup by name&quot; =
function to your products,</FONT>

<BR><FONT SIZE=3D2>&gt; how will that work if certificates do not have =
correct issuer</FONT>

<BR><FONT SIZE=3D2>&gt; names?&nbsp; If I have someone's End Entity =
certificate, how do I find a</FONT>

<BR><FONT SIZE=3D2>&gt; path of CA certs that leads to my trust point =
(not necessarily the</FONT>

<BR><FONT SIZE=3D2>&gt; certificate subject's trust point), in the =
multi-vendor,</FONT>

<BR><FONT SIZE=3D2>&gt; multi-administrative-domain environment of the =
Internet.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Products may support many certificate discovery =
mechanisms, both</FONT>

<BR><FONT SIZE=3D2>&gt; standards-based and differentiating.&nbsp; But =
there needs to be at</FONT>

<BR><FONT SIZE=3D2>&gt; least one &quot;Internet&quot; interoperability =
mode which all products</FONT>

<BR><FONT SIZE=3D2>&gt; support.&nbsp; That mode is defined by PKIX: the =
certificate profile</FONT>

<BR><FONT SIZE=3D2>&gt; and the LDAP schema.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; One &quot;Internet mode&quot; mechanism which =
follows the current PKIX</FONT>

<BR><FONT SIZE=3D2>&gt; specifications is for organizations to place =
public information,</FONT>

<BR><FONT SIZE=3D2>&gt; including CA and EE certificates, in border =
directories, and to link</FONT>

<BR><FONT SIZE=3D2>&gt; the border directories together using =
directory-to-directory chaining,</FONT>

<BR><FONT SIZE=3D2>&gt; LDAP referrals, or both.&nbsp; If you propose to =
eliminate the X.509</FONT>

<BR><FONT SIZE=3D2>&gt; requirement for correct issuer names, you will =
need to address the</FONT>

<BR><FONT SIZE=3D2>&gt; impact on current applications built to the =
current standards,</FONT>

<BR><FONT SIZE=3D2>&gt; as well as the feasability of future =
applications built to an</FONT>

<BR><FONT SIZE=3D2>&gt; amended standard.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Dave</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; P.S.&nbsp; I don't understand why you keep =
referring to &quot;punishing</FONT>

<BR><FONT SIZE=3D2>&gt; administrators&quot; and &quot;requiring =
administrators to have a flawless</FONT>

<BR><FONT SIZE=3D2>&gt; record&quot; and &quot;eliminating =
imperfection&quot;.&nbsp; A CA workstation has its own</FONT>

<BR><FONT SIZE=3D2>&gt; signing key and certificate.&nbsp; If the =
workstation cannot correctly</FONT>

<BR><FONT SIZE=3D2>&gt; place</FONT>

<BR><FONT SIZE=3D2>&gt; its own name in the issuer field of every =
certificate it signs, that</FONT>

<BR><FONT SIZE=3D2>&gt; is</FONT>

<BR><FONT SIZE=3D2>&gt; a product flaw.&nbsp; This X.509 requirement =
does not hinge upon human</FONT>

<BR><FONT SIZE=3D2>&gt; perfectability.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD40E.AFF1AEB2--

From: "Motoyuki J Suzuki" <[email-masked]>
To: [email-masked]
Date: Sun, 11 Jun 2000 23:11:27 +0900
Subject: unsubscribe

unsubscribe

Content-return: allowed
Date: Fri, 09 Jun 2000 14:21:15 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: Correct approach to certificate validation?
To: "[email-masked]'" <[email-masked]>, "'David P. Kemp'" <[email-masked]>, [email-masked]

Regarding a company changing its name, it is difficult for me to imagine a
scenario in which a company would need to change the subject in its
certificate but not need to change the issuer in the certificates that it
has issued.

Frank

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Thursday, June 08, 2000 9:36 PM
> To: 'David P. Kemp'; [email-masked]
> Subject: RE: Correct approach to certificate validation?
> 
> 
> David,
> 
> My draft has nothing to do with the fact that the name chaining may be
> incorrect but applies even in the cases where name chaining 
> is present and
> correct.
> 
> There are various cases where not going strictly on name 
> chaining can be
> benifitual.  For example, if a company changes names the CA 
> certificate can
> be updated without having to re-issue all subordiante 
> certificates at the
> same time.  (This may happen due to merges, splits, name 
> changes or court
> ordered actions.)
> 
> jim
> 
> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Wednesday, June 07, 2000 7:00 AM
> To: [email-masked]
> Subject: RE: Correct approach to certificate validation?
> 
> 
> Trevor,
> 
> It isn't about punishing administrators for minor errors, it is
> about achieving an overall system with the goals of being both
> secure and non-intrusive to the end user.  That may well mean that
> administrators have to do more thinking, planning, and 
> quality control,
> but that is what they (we, the providers of a PKI for our branch of
> Govt) are paid to do.
> 
> The specific case I'm referring to is Jim Schaad's assertion that an
> S/MIME-specific cert path attribute is needed because applications
> can't find CA certificates.  I didn't realize until now that that was
> because in your environment subject certificates are not required to
> have a correct issuer name!  It seemed obvious to me that the PKI is
> responsible for correctly binding names to keys.  But you are saying
> that Issuer names don't really matter, they're just a hint to help
> applications search for a cert with a signing key that validates the
> subject cert signature.  Well no wonder applications can't find CA
> certs in that environment!
> 
> That isn't necessarily a wrong theoretical approach - SPKI is based
> on the premise that only keys are important, names are simply optional
> attributes attached to keys.  But it is wrong in X.509 because X.509
> certificates are identified by and stored under Distinguished Names,
> not public keys or SubjectKeyIdentifiers.
> 
> Standards are about interworking in a multi-vendor environment; the
> testable requirements contained in standards are covenants between
> supplier and customer.  My goal is for a CMI purchased from vendor
> X and operated by company A to work with applications purchased from
> vendors Y and Z and operated by companies B and C.  I understand
> that that is not your primary goal, but I expect you to acknowledge
> that when as a result of non-conformance some applications work and
> others don't, it is NOT the fault of the conforming applications even
> when they are the ones that fail.  And that when someone from company
> X proposes as a Standard a workaround for a problem created somewhere
> else in company X, the IETF is entitled to disregard the
> company-specific rationale for that workaround.
> 
> Regards,
> Dave
> 
> 
> 
> > From: "Trevor Freeman" <[email-masked]>
> >
> > Hi David,
> > I am afraid I don't see it necessary to eradicate every little
> > imperfection because it is there. To err is human, and people make
> > mistakes. People also have a wide list of requires which 
> you may or may
> > not agree with, but it does not mean that it is less real to them.
> > So I don't see this as an error, simple a different point 
> of view, and
> > we will obviously disagree on this point.
> > At the end of the day it is up to any product vendor to 
> make the call as
> > to what is\is not in their product, regardless what is in 
> the standard.
> > It is up to the market place to decide. History certainly 
> tells us that
> > customers like robustness in a product.
> > If you can cite a specific issue, then we will obviously 
> reconsider, but
> > I don't find punishing minor infractions of administrators 
> a compelling
> > case.
> > Trevor
> 
> 

Date: Fri, 09 Jun 2000 14:05:04 -0700
From: Ed Gerck <[email-masked]>
To: [email-masked]
Subject: Re: Correct approach to certificate validation?

Oscar Jacobsson wrote:

> Ed Gerck wrote:
> > So, now the name should trump the key? The tail wants to wag the
> > dog, we may as well say.
>

> However: if constraints are placed on subject names, they are most
> probably placed there for a reason. Ignoring said constraints, having
> been deemed important enough to distribute signed and in-band, could
> surely hardly be considered prudent?

A checkbox with "Enforce name chaining" could take care of all cases
where name chaining is desired, much in the same way that the depth
of certificate signing can also be chosen by the user in Apache SSL for
example (or, do you really must trust a CA you don't trust just because it
chains with a CA you  trust?  -- maybe, possibly not).

Making name chaining mandatory, OTOH, still does not mean that
the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc.  So,
if constraints are placed on names this is still much weaker than the
nonce authentication constraints placed on keys -- where a principal
must have had use of the private-key in order to sign a nonce.  They
are like apples and speedboats, names and keys.  Why then should we
not differentiate between name validation and certificate validation?
Cert validation may include name validation but not necessarily and
there is no cryptographic value to be gained thereby.

Of course, some years ago everything was quite undifferentiated and
there was no distinction between different functions which we now
perceive as distinct. For example, the CA and the NA roles -- as well as
the CA and the TTP roles.

Cheers,

Ed Gerck

content-class: urn:content-classes:message
Subject: RE: Correct approach to certificate validation?
Date: Fri, 9 Jun 2000 11:36:12 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD241.964A9470
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,
With the Internet today, if you are relying on directory lookup based on
a DN as you only solution to certificate discovery - I think you will be
disappointed. There will be "communities" who will be able to get this
to work, but there is no sign of a universal solution equivalent to DNS
where I can take any DN and find an object in a directory with that
name. Therefore failure to find a certificate based on a issuer DN in a
certificate is a reality that will have to be dealt with - for much more
fundamental reasons.

There are a couple of instances of by design behavior that have been
presented to me. There are mergers and acquisitions where names and
affiliation are changing. There are also instances where one CA does not
want to endorse the name of another when it cross certifies.

The search path mechanism is very similar to AIA, in that given a set of
URLs, you can access the URL looking for certificates. With LDAP URLs,
it's not difficult to construct a generic query. With other, the
underlying assumption is that you find a pkcs#7.

Trevor

 -----Original Message-----
From: 	Stephen Kent [mailto:[email-masked]]=20
Sent:	Thursday, June 08, 2000 12:21 PM
To:	Trevor Freeman
Cc:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

>Certificate discovery is not the issue here.

I know that the focus of the discussion has been matching up subject=20
and issuer names when validating a cert path.  However, since cert=20
path discovery logically precedes validation, and since the nominal=20
model for discovery is based on looking for a CA cert that contains a=20
subject name that was the issuer name on the "lower" level cert, I=20
think it appropriate to ask the discovery question.

>The question is that if you have a certificate who's signature=20
>integrity can be traced up to a trusted root, containing acceptable=20
>policy as defined by that root, and  who's names lie within the=20
>allowed namespaces as defined by the name constraints in parent=20
>certificates to the certificate in question, what is the value in=20
>checking that the issuer-subject names chain?
>We have encountered such situations, by design, and by accident. In=20
>all cases, the cost\benefit analysis in our view is stacked in favor=20
>of not performing the name chaining check, and tolerating this=20
>situation.

Could you provide some examples of the "by design" situations you=20
have encountered?

>I agree that name constraints are important as the certificate is=20
>making those names available to the applications, so it is important=20
>that we can filter acceptable from not-acceptable names. We actually=20
>follow a methodology similar to one you mentioned in a previous=20
>thread which is to build all possible paths, then apply the name=20
>constraints to determine the quality of the path.

I don't recall suggesting the approach you mention here.  I would=20
guess that path discovery performed using subject/issuer name=20
matching and AIK/SIK discrimination would rarely yield multiple=20
paths. But, if it did, then I agree that application of the name=20
constraints extension as part of path validation would discard paths=20
that violated the constraints.

>For certificate discovery,  we have a domain push mechanism as well=20
>as AIA. We are also adding a lookup by name, and a configurable URL=20
>search path i.e. a set of URLs to search (LDAP, HTTP, FTP)

The domain push mechanism sounds local, perhaps MS specific?  AIA=20
would be definitive.  Does one look at the issuer name to select a=20
subset of the search search paths you allude to, or do you just try=20
to do lookups via ll of them?

Steve

------_=_NextPart_001_01BFD241.964A9470
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 =
6.0.4390.0">
<TITLE>RE: Correct approach to certificate validation?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Steve,</FONT>

<BR><FONT SIZE=3D2>With the Internet today, if you are relying on =
directory lookup based on a DN as you only solution to certificate =
discovery - I think you will be disappointed. There will be =
&quot;communities&quot; who will be able to get this to work, but there =
is no sign of a universal solution equivalent to DNS where I can take =
any DN and find an object in a directory with that name. Therefore =
failure to find a certificate based on a issuer DN in a certificate is a =
reality that will have to be dealt with - for much more fundamental =
reasons.</FONT></P>

<P><FONT SIZE=3D2>There are a couple of instances of by design behavior =
that have been presented to me. There are mergers and acquisitions where =
names and affiliation are changing. There are also instances where one =
CA does not want to endorse the name of another when it cross =
certifies.</FONT></P>

<P><FONT SIZE=3D2>The search path mechanism is very similar to AIA, in =
that given a set of URLs, you can access the URL looking for =
certificates. With LDAP URLs, it's not difficult to construct a generic =
query. With other, the underlying assumption is that you find a =
pkcs#7.</FONT></P>

<P><FONT SIZE=3D2>Trevor</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: &nbsp; Stephen Kent [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>

<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Thursday, June 08, 2000 12:21 =
PM</FONT>

<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Trevor Freeman</FONT>

<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]</FONT>

<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: Correct approach to certificate validation?</FONT>
</P>

<P><FONT SIZE=3D2>Trevor,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Certificate discovery is not the issue =
here.</FONT>
</P>

<P><FONT SIZE=3D2>I know that the focus of the discussion has been =
matching up subject </FONT>

<BR><FONT SIZE=3D2>and issuer names when validating a cert path.&nbsp; =
However, since cert </FONT>

<BR><FONT SIZE=3D2>path discovery logically precedes validation, and =
since the nominal </FONT>

<BR><FONT SIZE=3D2>model for discovery is based on looking for a CA cert =
that contains a </FONT>

<BR><FONT SIZE=3D2>subject name that was the issuer name on the =
&quot;lower&quot; level cert, I </FONT>

<BR><FONT SIZE=3D2>think it appropriate to ask the discovery =
question.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;The question is that if you have a certificate =
who's signature </FONT>

<BR><FONT SIZE=3D2>&gt;integrity can be traced up to a trusted root, =
containing acceptable </FONT>

<BR><FONT SIZE=3D2>&gt;policy as defined by that root, and&nbsp; who's =
names lie within the </FONT>

<BR><FONT SIZE=3D2>&gt;allowed namespaces as defined by the name =
constraints in parent </FONT>

<BR><FONT SIZE=3D2>&gt;certificates to the certificate in question, what =
is the value in </FONT>

<BR><FONT SIZE=3D2>&gt;checking that the issuer-subject names =
chain?</FONT>

<BR><FONT SIZE=3D2>&gt;We have encountered such situations, by design, =
and by accident. In </FONT>

<BR><FONT SIZE=3D2>&gt;all cases, the cost\benefit analysis in our view =
is stacked in favor </FONT>

<BR><FONT SIZE=3D2>&gt;of not performing the name chaining check, and =
tolerating this </FONT>

<BR><FONT SIZE=3D2>&gt;situation.</FONT>
</P>

<P><FONT SIZE=3D2>Could you provide some examples of the &quot;by =
design&quot; situations you </FONT>

<BR><FONT SIZE=3D2>have encountered?</FONT>
</P>

<P><FONT SIZE=3D2>&gt;I agree that name constraints are important as the =
certificate is </FONT>

<BR><FONT SIZE=3D2>&gt;making those names available to the applications, =
so it is important </FONT>

<BR><FONT SIZE=3D2>&gt;that we can filter acceptable from not-acceptable =
names. We actually </FONT>

<BR><FONT SIZE=3D2>&gt;follow a methodology similar to one you mentioned =
in a previous </FONT>

<BR><FONT SIZE=3D2>&gt;thread which is to build all possible paths, then =
apply the name </FONT>

<BR><FONT SIZE=3D2>&gt;constraints to determine the quality of the =
path.</FONT>
</P>

<P><FONT SIZE=3D2>I don't recall suggesting the approach you mention =
here.&nbsp; I would </FONT>

<BR><FONT SIZE=3D2>guess that path discovery performed using =
subject/issuer name </FONT>

<BR><FONT SIZE=3D2>matching and AIK/SIK discrimination would rarely =
yield multiple </FONT>

<BR><FONT SIZE=3D2>paths. But, if it did, then I agree that application =
of the name </FONT>

<BR><FONT SIZE=3D2>constraints extension as part of path validation =
would discard paths </FONT>

<BR><FONT SIZE=3D2>that violated the constraints.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;For certificate discovery,&nbsp; we have a domain =
push mechanism as well </FONT>

<BR><FONT SIZE=3D2>&gt;as AIA. We are also adding a lookup by name, and =
a configurable URL </FONT>

<BR><FONT SIZE=3D2>&gt;search path i.e. a set of URLs to search (LDAP, =
HTTP, FTP)</FONT>
</P>

<P><FONT SIZE=3D2>The domain push mechanism sounds local, perhaps MS =
specific?&nbsp; AIA </FONT>

<BR><FONT SIZE=3D2>would be definitive.&nbsp; Does one look at the =
issuer name to select a </FONT>

<BR><FONT SIZE=3D2>subset of the search search paths you allude to, or =
do you just try </FONT>

<BR><FONT SIZE=3D2>to do lookups via ll of them?</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFD241.964A9470--

Date: Fri, 09 Jun 2000 20:06:02 +0200
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications
To: Ed Gerck <[email-masked]>
CC: [email-masked]
Subject: Re: Correct approach to certificate validation?

This is a cryptographically signed message in MIME format.

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

Ed Gerck wrote:
> So, now the name should trump the key? The tail wants to wag the
> dog, we may as well say.

Neither name nor key would amount to much on their own, IMHO.

I agree that there is a great deal of ambiguity regarding how
certificate subjects are named. Naming conventions are decided on a
per-issuer basis, IIRC, which has confused quite a few of my countrymen,
being used to having access to a government-issued personal
identification number.

However: if constraints are placed on subject names, they are most
probably placed there for a reason. Ignoring said constraints, having
been deemed important enough to distribute signed and in-band, could
surely hardly be considered prudent?

//oscar
--------------msCE6C76DA8CA93233F3045CEB
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

--------------msCE6C76DA8CA93233F3045CEB--

From: "Martin Szotkowski" <[email-masked]>
To: <[email-masked]>
Subject: TSA signing key?
Date: Fri, 9 Jun 2000 19:00:10 +0200
Organization: PVT, a.s.

In draft is written that TSA cert must be used exclusively for time stamp.
Why TSA certificate cann't be same as CA certificate?

thanks Martin

Date: Fri, 09 Jun 2000 09:54:30 -0700
From: Ed Gerck <[email-masked]>
To: [email-masked]
Subject: Re: Correct approach to certificate validation?

Stephen Kent wrote:

> Ed,
> >List:
> >
> >Why should we continue to confuse name validation with
> >certificate validation?  Name chaining should be optional IMO,
> >not expected behavior. 'Be liberal in what you expect' can be
> >applied here without  A N Y  decrease in cryptographic
> >authentication security.
> >
>
> Jon's protocol design advice is good in general, but inappropriate in
> security contexts, where liberal acceptance policies often lead to
> vulnerabilities.

In this case, however, I see no vulnerability in what X.509/PKIX
intend to provide -- a cryptographic authentication protocol.  In
regard to name assignment vulnerabilities, I note that this is also
declared out of scope in X.509/PKIX  and delegated to the CA/NA
+ CPS.

So, why should that which is declared out of scope trump that
which is the only thing that the protocol verifies?  Logic would
indicate that since name validation by name chaining verification
is a weaker concept than the one it is blocking, then this should
not be mandatory behavior.  Making it mandatory is what is
confusing, IMO.

Cheers,

Ed Gerck

Date: Fri, 09 Jun 2000 09:36:44 -0700
From: Ed Gerck <[email-masked]>
To: [email-masked]
Subject: Re: Correct approach to certificate validation?

Oscar Jacobsson wrote:

> Ed Gerck wrote:
> > Why should we continue to confuse name validation with
> > certificate validation?  Name chaining should be optional IMO,
> > not expected behavior. 'Be liberal in what you expect' can be
> > applied here without  A N Y  decrease in cryptographic
> > authentication security.
>
> My personal opinion, and humble one at that, is that the issue is of
> greater importance than "simply" one of cryptographic security.
>
> The principals of X.509, as has been previously stated in this thread,
> are in the naming, and not in the cryptographic keys themselves.

But X.509 is moot on how to verify such names [1,2], which task it delegates
to the CA (and NA).  The ONLY verification procedure that X.509
specifies [2] is on the subject's key pair by requiring nonce authentication
-- the subject must prove possession of the private-key.

So, in X.509 (and PKIX) what we have are *two* pieces of data with
different validity levels:

1. the public-key was positively verified
2. the name was hearsay.

So, now the name should trump the key? The tail wants to wag the
dog, we may as well say.

Of course, I agree that an additional function COULD provide for
name validation according to chaining rules but satisfying such
a function should be optional, not expected.

Cheers,

Ed Gerck

[1] Section 11.2 of X.509v3, "Management of certificates", states that the
certificate allows an association between a name called "unique distinguished
name" or DN for the user and the user's public-key: "A  certificate  associates
the public key and unique distinguished name of the user it describes.", while
Section 7 explains that such DNs are essential to the security design of X.509:
"Authentication relies on each user possessing a unique distinguished name."
But, how are such DNs assigned? Where are they unique? The DN is denoted
by a NA (Naming Authority) and accepted by a CA (Certification Authority) as
unique within the CA's domain, where the CA can double as a NA. HOWEVER,
note that the same user can have different DNs in different CAs, or can use
the same DN in different CAs even if it is not the first one to use it in a CA --
so that different DNs for different CAs do not necessarily mean different users and
vice-versa. Further, a DN does not have to contain the user's real-world name or
location. Thus, semantically, the CA certificate refers to a name; however it does
not denote it.

[2] X.509 is moot on validation procedures for data included in a certificate such as
the user's name, with the exception of validation procedures for the user's public-key
which are suggested (not mandated) in Section 10 of X.509v3. For example, regarding
validation procedures for the user's identity, Section 11.2.a states that: "a certification
authority shall be satisfied of the identity of a user before creating a certificate for it",
which means that identity validation procedures are to be satisfied in the CA's frame of
reference by  following the CA's own self-defined rules (CPS), which are declared outside
the scope of X.509 and can be entirely different for different CAs.

From: "william bamberg" <[email-masked]>
To: <[email-masked]>
Subject: HTTP over TLS: dNSName syntax question
Date: Fri, 9 Jun 2000 17:00:53 +0100

Sorry if this is marginally off topic, but I'd like to know people's
opinions...

RFC 2818, 'HTTP over TLS', Section 3.1, 'Server Identity' describes how to
compare the name in the server's certificate with the server domain name:

'If a subjectAltName extension of type dNSName is present, that MUST be used
as the identity. Otherwise, the (most specific) Common Name field in the
Subject field of the certificate MUST be used...Matching is performed using
the matching rules specified by [RFC2459].'

RFC 2459 says that the dNSName 'MUST be in the "preferred name syntax," as
specified by RFC 1034.'

So, presumably the matching here is performed by comparing every subdomain
in the dNSName against the corresponding subdomain in the server's domain
name.

But RFC 2818 goes on to say that 'Names may contain the wildcard character
*'
and goes on to specify how these names should be handled.

The 'preferred name syntax' says nothing about wildcards, so my question
really is, how can the dNSName component both be represented according to
the 'preferred name syntax', and contain wildcards?

Thanks very much for any help you can offer.

Will

Date: Fri, 09 Jun 2000 18:03:24 +0200
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Correct approach to certificate validation?

This is a cryptographically signed message in MIME format.

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

Stephen Kent wrote:
> Actually, the "local" CA issues a cross cert to the "foreign" CA, and
> thus the local CA asserts in the name constraints extension the part
> of the portion of the name space for which it considers the foreign
> CA to be authoritative.  So, the foreign CA does not make the claim
> in terms of the name constraints.  But you are right in asserting
> that some OOB mechanism is used by the local CA to decide what set of
> name constraints are appropriate re the foreign CA.

Naming constraints in cross-certificates hadn't even begun to occur to
me. I seem to have missed the actual point. Again. :-(

My reasoning was along the line that it would not only be polite of a
Certification Authority to clearly define the limits of its intended
certification, both generally as in its Certification Practise Statement
and specifically as in its naming constraints, but would also, IMHO,
make the decision of the relying party to trust that CA less "critical".

I can't really see the current on/off trust mechanisms usually employed
as one that even attempts to approximate reality. There are completely
different levels of trust involved between, as an example, allowing
somone to fix your car and allowing someone to baby-sit (sp?) your
children. Even if the level of trust were the same, the level of
authority would differ. One would not necessarily expect one person to
be suitable to perform both roles, trusted or not.

Note to self: or am I just not a very trusting person?

//oscar
--------------ms5A69A9209B0A2DAD24DDBCF3
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

--------------ms5A69A9209B0A2DAD24DDBCF3--

Date: Fri, 09 Jun 2000 09:26:30 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Correct approach to certificate validation?

Trevor, putting aside for a moment the issue of what the standard says, 
doesn't say, or ought to say, I'm still not sure that I understand the issue 
that you are raising.

I thought that when you said that you were using the issuer name in a 
subordinate certificate as a "hint" in finding the correct certificate issuer,
you might referring to some kind of fancy heuristic algorithm that would try
to divine where the next certificate up the chain might actually be found -- 
something I would very much like to see.

But if Al's example is a correct presentation of what you are saying,
then I don't understand how or why the CA created the certificate 
in that manner in the first place.

I have a reasonable fertile imagination, and so I can imagine situations
where the issuer name might not match, deliberately -- for example
a merger or company name change, where the CA certificate is reissued 
with the new name, but all of the end-user certs haven't been rolled over yet.
(Why the old certificate with the old name would have been left in place 
escapes me, however.)

I tend to agree with the rest of the community -- if this is just the result of 
sloppy programming of the CA implementation in not enforcing reasonable
behavior when the certificates were created, then this is indefensible.

However, if you have a real reason or justification, I'd like to hear it.

It does disturb me just a little to be over-constraining the chaining relationship.
If name subordination really matters, then a constraint ought to be expressed.

If name subordination doesn't matter, then I suppose I could question why 
the reverse chaining issue is important, assuming the path can still be constructed 
somehow.

One example that might be interesting to consider would be a bilingual country
such as Canada, where the CA's certificate might be in English, and yet
the end-user's certificate might be in French, including the French version of 
the issuer's name.

Other multilingual examples might include certificates where the CA's DN
is written in one character set, and for reasons of national pride, local laws, 
custom, or merely comprehensibility by the consumer, the subject and issuer 
name are written in a different character set.

Generally speaking, accepted standards ought to be followed, unless there are
good reasons not to (not including programming bugs)..  If there is such a good 
reason, the standards ought to be revised.

I'm trying to understand where there is in fact a good reason.

Bob

<<<Al Arsenault <[email-masked]> 06/08/00 08:31PM >>>
Trevor,

	Here's the justification:

	Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign,
whomever) has been built to conform to existing/understood X.509/RFC2459
name chaining rules.  Suppose that such a system has been deployed for,
oh, say, a large Government department, or a large corporation, or...

	Now, suppose that a CA from some other corporation that follows the
rules you suggest - i.e., name chaining doesn't matter.  We want to
integrate that CA into the existing PKI.  

	Now, for whatever reason - human frailty, whatever - that new CA is
used to create a certificate whose distinguish name is "C=AW,
O=Government, OU= Computers, CN= CA1", and then that CA creates user
certs where the issuer name is "C=AW, O=Government, OU=Computer,
CN=CA1".  Note that these names are not equivalent.*

	Suppose that all other information - AKI, AIA, etc. - is set up
properly.

	Now, whenever a cert path is validated using the new CA, it will be
validated, because the fact that the end entity cert's issuer name and
the CA cert's subject name aren't the same doesn't matter.  However,
whenever that same cert path is validated by a node in the existing PKI,
validation will fail, because of the name chaining failure. The notion
of obtaining different results by different points in the system is
disconcerting, to say the least.

	That's the reason:  by building your system this way, you cause the
multi-vendor interoperable PKI to fail.  If you were building your
system to not interoperate with any other existing products, then I
think we could probably agree that you were right; there is no real
reason that names have to chain.  However, lots of people do want your
system to interoperate with other products.  I'm fairly confident that
Dave wants them to.  I know that in some of the cases I'm dealing with
now, I need them to.  And they don't.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

*And yes, I have seen cases where name chaining failed - and thus
certificate validation failed when it shouldn't have - because of a
misplaced comma in a CN field.  I've also seen it fail because of an
extra space in an OU field, and several other situations.

> Trevor Freeman wrote:
> 
> Life is complicated, but this is not so bad - Isaac Newton's rules
> where around a lot longer before they were found to be wrong.
> I am still waiting to here further justification (beyond the old
> ground of "its in the spec"). and so far you are confirming my
> suspicions that there are none.
> 
>  -----Original Message-----
> From:   David P. Kemp [mailto:[email-masked]] 
> Sent:   Thursday, June 08, 2000 8:35 AM
> To:     [email-masked] 
> Subject:        RE: Correct approach to certificate validation?
> 
> Trevor,
> 
> > From: "Trevor Freeman" <[email-masked]>
> >
> > David,
> > Interoperability is a primary goal, however that is often scarified
> by
> > standards. It is very easy to produce a document with a set of do's
> and
> > don'ts  without any regard for the previous standard, the impact on
> the
> > deployed products or how migration is achieved between the old and
> new
> > standard. It is also unrealistic to think that all products deployed
> > would conform to a single standard. Most products have a lifetime of
> > years. The interoperability matrix is vast and getting worse every
> time
> > a new version of  a standard is released.
> > So to return to the original point, besides citing a 20 year old
> clause
> > in a standard, and saying we should do it because its in the
> standard,
> > and requiring administrators to have a faultless record, I have
> still
> > not hear any reasoned, argument as to what is actually achieved by
> this
> > behavior.
> > No standard or clause in a standard has a divine right of existence.
> > Trevor
> 
> On the one hand, you seem to be decrying the ease of producing new
> specifications without regard for previous standards and deployed
> products.
> 
> On the other, you seem to support discarding a 20 year old clause
> in a standard without regard for its impact on deployed products which
> have been built according to the standard.
> 
> The "divine right" of any clause comes not from heaven or inheritance,
> but from the fact that it has been vetted internationally (in the ISO
> and the IETF) over a period of many years.  Over that time (whether
> it's
> 12 or 20 years is immaterial), the requirement that certificates point
> to the correct issuer has not only survived, it has not to my
> knowledge
> been even mildly controversial.   Now that there is discussion of
> the topic, the requirement will either survive or be discarded based
> on international consensus.   There is no divine right, just the
> stability (inertia?) of a consensus-based standard-setting
> process.
> 
> You may present a case that the requirement should be removed from
> X.509
> and then from the PKIX profile of X.509.
> Or you may choose not to comply with X.509.
> 
> But you can't both ignore the requirement and claim compliance.
> 
> > Certificate discovery is not the issue here.
> >
> > For certificate discovery,  we have a domain push mechanism as well
> as
> > AIA. We are also adding a lookup by name, and a configurable URL
> search
> > path i.e. a set of URLs to search (LDAP, HTTP, FTP)
> 
> Certificate discovery *is* the issue.
> 
> If you are adding a "lookup by name" function to your products,
> how will that work if certificates do not have correct issuer
> names?  If I have someone's End Entity certificate, how do I find a
> path of CA certs that leads to my trust point (not necessarily the
> certificate subject's trust point), in the multi-vendor,
> multi-administrative-domain environment of the Internet.
> 
> Products may support many certificate discovery mechanisms, both
> standards-based and differentiating.  But there needs to be at
> least one "Internet" interoperability mode which all products
> support.  That mode is defined by PKIX: the certificate profile
> and the LDAP schema.
> 
> One "Internet mode" mechanism which follows the current PKIX
> specifications is for organizations to place public information,
> including CA and EE certificates, in border directories, and to link
> the border directories together using directory-to-directory chaining,
> LDAP referrals, or both.  If you propose to eliminate the X.509
> requirement for correct issuer names, you will need to address the
> impact on current applications built to the current standards,
> as well as the feasability of future applications built to an
> amended standard.
> 
> Dave
> 
> P.S.  I don't understand why you keep referring to "punishing
> administrators" and "requiring administrators to have a flawless
> record" and "eliminating imperfection".  A CA workstation has its own
> signing key and certificate.  If the workstation cannot correctly
> place
> its own name in the issuer field of every certificate it signs, that
> is
> a product flaw.  This X.509 requirement does not hinge upon human
> perfectability.

Date: Fri, 09 Jun 2000 11:57:33 -0400
From: Michael Young <[email-masked]>
Organization: Xcert International
To: [email-masked]
Subject: remove

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

remove

--------------D27A8B7D42B16DA9DC4CB9B3
Content-Type: text/x-vcard; charset=us-ascii;
 name="myoung.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Michael Young
Content-Disposition: attachment;
 filename="myoung.vcf"

begin:vcard 
n:Young;Michael
tel;cell:1-914-572-2803
tel;work:1-203-969-2387
x-mozilla-html:FALSE
url:http://www.xcert.com
org:<a href="http://www.xcert.com"><img src="http://www.xcert.com/assets/images/addressbook.jpg" width=200 height=69 border=0 alt="Xcert International Inc."></a>
adr:;;463-3 Cove Road;Stamford;Connecticut;06902;USA
version:2.1
email;internet:[email-masked]
title:Sales Engineer
note:No notes at this time.
fn:Michael Young
end:vcard

--------------D27A8B7D42B16DA9DC4CB9B3--

Date: Fri, 9 Jun 2000 11:36:43 -0400
To: Oscar Jacobsson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Correct approach to certificate validation?
Cc: [email-masked]

Oscar,

>Oscar Jacobsson wrote:
>  > Besides, the notion of "authoritative CA" becomes a bit vague without
>  > some in-band method of communicating precisely what said CA claims to be
>  > an authority on.
>
>Oh dear.
>
>I'm still not entirely lucid, I guess. What I was referring to, which
>might not have been perfectly obvious, was the role of naming
>constraints in defining exactly which Authority a given CA is claiming.

Actually, the "local" CA issues a cross cert to the "foreign" CA, and 
thus the local CA asserts in the name constraints extension the part 
of the portion of the name space for which it considers the foreign 
CA to be authoritative.  So, the foreign CA does not make the claim 
in terms of the name constraints.  But you are right in asserting 
that some OOB mechanism is used by the local CA to decide what set of 
name constraints are appropriate re the foreign CA.

Steve

Date: Fri, 09 Jun 2000 17:24:05 +0200
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications
To: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Correct approach to certificate validation?

This is a cryptographically signed message in MIME format.

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

Oscar Jacobsson wrote:
> Besides, the notion of "authoritative CA" becomes a bit vague without
> some in-band method of communicating precisely what said CA claims to be
> an authority on.

Oh dear.

I'm still not entirely lucid, I guess. What I was referring to, which
might not have been perfectly obvious, was the role of naming
constraints in defining exactly which Authority a given CA is claiming.

//oscar
--------------msB956762982A67F23934ADFD8
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

--------------msB956762982A67F23934ADFD8--

Date: Fri, 09 Jun 2000 16:44:41 +0200
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Correct approach to certificate validation?

This is a cryptographically signed message in MIME format.

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

Stephen Kent wrote:
> I prefer this phrasing because it emphasizes the difference between TTPs where one has to trust the CA, vs. various types of authoritative CAs, where the trust is implicit.

A very good point.

Besides, the notion of "authoritative CA" becomes a bit vague without
some in-band method of communicating precisely what said CA claims to be
an authority on.

//oscar
--------------ms5ECF4F507BB3224147ED10B9
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

--------------ms5ECF4F507BB3224147ED10B9--

From: Paul Koning <[email-masked]>
Date: Fri, 9 Jun 2000 10:30:54 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: RE: Correct approach to certificate validation?

>>>>> "Trevor" == Trevor Freeman <[email-masked]> writes:

 Trevor> Life is complicated, but this is not so bad - Isaac Newton's
 Trevor> rules where around a lot longer before they were found to be
 Trevor> wrong.  I am still waiting to here further justification
 Trevor> (beyond the old ground of "its in the spec"). and so far you
 Trevor> are confirming my suspicions that there are none.

That's interesting.  It sounds to me like you're saying "Nothing in
any standard matters unless someone can come up with a specific
justification for each and every rule I've chosen to ignore".

That's comical.

In standardization, it often occurs that there are several
incompatible ways of doing something, and one has to be chosen.  And
it may well be that several of the alternatives are equally valid
technically.  In that case, when one is picked, you have to use that
one to interoperate, and the only justification for that one rather
than one of the alternatives is indeed "it's in the spec".

So are you now claiming that such a standards process is not
acceptable?  Bizarre.

Incidentally, your statement about Newton is incorrect, too.

      paul

Date: Fri, 9 Jun 2000 10:09:37 -0400
To: Oscar Jacobsson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Correct approach to certificate validation?
Cc: [email-masked]

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

Oscar,

><snip>
>
>To try to summarize:
>
>Constraining one's intended certification is essential, since it will
>allow for a much finer granularity in the delegation of trust than the
>current model with it's childish boolean trusted/not trusted mechanism.

Another way to state this is that use of name constraints allows one 
to recognize the authority of a CA for a portion of a name space, 
e.g., a company CA is responsible for issuing certs to employees, a 
university to faculty, staff and students, etc.  I prefer this 
phrasing because it emphasizes the difference between TTPs where one 
has to trust the CA, vs. various types of authoritative CAs, where 
the trust is implicit.

Steve

--============_-1251562280==_ma============
Content-Type: text/enriched; charset="us-ascii"

Oscar,

<excerpt><<snip>

To try to summarize:

Constraining one's intended certification is essential, since it will

allow for a much finer granularity in the delegation of trust than the

current model with it's childish boolean trusted/not trusted
mechanism.

</excerpt>

Another way to state this is that use of name constraints allows one to
recognize the authority of a CA for a portion of a name space, e.g., a
company CA is responsible for issuing certs to employees, a university
to faculty, staff and students, etc.  I prefer this phrasing because it
emphasizes the difference between TTPs where one has to
<underline>trust</underline> the CA, vs. various types of authoritative
CAs, where the trust is implicit.

Steve

--============_-1251562280==_ma============--

From: [email-masked]
To: [email-masked]
Date: Fri, 9 Jun 2000 09:56:39 -0400
Subject:  <draft-ietf-pkix-new-part1-01.txt>  March 10, 2000

In section 6.3.3 and the third paragraph from the end of that section.
"If all CRLs named in the crl distribution points extension have
      been exhausted, and the reasons_mask is not "all-reasons" and the
      cert_status is still UNREVOKED, the verifier must obtain addi-
      tional CRLs.  If the "

Is more intended to be here or should the "If the" be removed?

Edward J. Dobner
Network Security Products
Address: IBM;  3039 Cornwallis Drive; NGEA/B502;  Research Triangle Park, NC
27709
Telephone: 919-254-4169 (T/L 444-4169)
Email: [email-masked]
VM: [email-masked]
Lotus Notes: Edward Dobner/Tivoli Systems@Tivoli Systems

Date: Fri, 9 Jun 2000 09:48:17 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Correct approach to certificate validation?
Cc: [email-masked]

Ed,
>List:
>
>Why should we continue to confuse name validation with
>certificate validation?  Name chaining should be optional IMO,
>not expected behavior. 'Be liberal in what you expect' can be
>applied here without  A N Y  decrease in cryptographic
>authentication security.
>

Jon's protocol design advice is good in general, but inappropriate in 
security contexts, where liberal acceptance policies often lead to 
vulnerabilities.

Steve

Date: Fri, 09 Jun 2000 09:49:09 -0400
From: "Carol A. McNab" <[email-masked]>
To: [email-masked]
Subject: unsubscribe

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

unsubscribe

--------------1B086A00A26C151F0CF07A10
Content-Type: text/x-vcard; charset=us-ascii;
 name="cmcnab.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Carol A. McNab
Content-Disposition: attachment;
 filename="cmcnab.vcf"

begin:vcard 
n:McNab;Carol A.
tel;work:(201)836-6200  x1147
x-mozilla-html:TRUE
org:Syndata Technologies, Inc.
adr:;;500 Frank W. Burr Blvd.;Teaneck;NJ;07666;
version:2.1
email;internet:[email-masked]
title:Senior Software Engineer
x-mozilla-cpt:;15600
fn:Carol A. McNab
end:vcard

--------------1B086A00A26C151F0CF07A10--

From: [email-masked]
To: [email-masked]
Date: Fri, 9 Jun 2000 09:33:30 -0400
Subject: <draft-ietf-pkix-new-part1-01.txt> of March 10, 2000

I have a question.

In section 6.3.3 CRL Processing, is the following text
" (d) Perform the checks in step 1 (b) and (c):

            1. obtain and validate the certification path for the delta
            issuer

            2. validate the signature on the delta CRL"

I am assuming that steps 1 and 2 here are summarising what steps 1(b) and 1(c)
are.  But step 1 is not step 1(b) and step 2 is not step 1(c).  Should this be
"perform the checks in
step 1 (b), (c) and (d)" or something else.

I am working on the review of the java.cert.CertPath apis that are being
defined.  I work on IBM tools and API's that incorporate PKI technology in IBM
products.

Edward J. Dobner
Network Security Products
Address: IBM;  3039 Cornwallis Drive; NGEA/B502;  Research Triangle Park, NC
27709
Telephone: 919-254-4169 (T/L 444-4169)
Email: [email-masked]
VM: [email-masked]
Lotus Notes: Edward Dobner/Tivoli Systems@Tivoli Systems

Date: Fri, 9 Jun 2000 09:32:00 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Correct approach to certificate validation?
To: [email-masked]
Content-MD5: v/aXcAcK82QGq+2aKGRB0Q==

Peter,

No, I didn't realize that RFC 2459's name matching process is
a subset of X.509's.  What I read is:

  (a) Verify the basic certificate information, including:
       ...
      (4) the subject and issuer names chain correctly (that is,
          the issuer of this certificate was the subject of the
          previous certificate.)

Although I could understand the motivation for PKIX profiling a binary
match (identical RDN tags and values - much simpler to implement than
forming equivalence classes for all possible values of DirectoryString),
I don't see that PKIX has, in fact, required exact comparison.

>From reading requirement (4), I would assume that "X.509 name matching"
is permitted by RFC 2459.

What I object to, and what I am assuming Trevor is referring to, are
name chaining failures that would be failures under even the most
liberal and complex string matching rules.

The extent to which applications handle equivalent but not identical
names is an implementation detail, best handled by the "be conservative
in what you generate" rule - CA's should create certificates with
binary-exact chaining, and applications should do as much string matching
as the developer feels is appropriate for the targeted certificate
profiles.

Dave

> From: Peter Williams <[email-masked]>
> Subject: RE: Correct approach to certificate validation?
> To: "'David P. Kemp'" <[email-masked]>
> Cc: [email-masked]
> 
> Dave,
> 
> I agree that (1), (2) and (3) are true assertions. Perhaps you
> could be as clear for me...for the PKIX profile of X.509:
> 
> Do you realize, and agree, that
> the way NIST/NSA designers deliberately constructed
> RFC 2459's name matching process (during
> path validation of an intermediate or
> EE certificate) is such that implementations
> of the X.509 path processing algorithm produce a different
> validity result to the PKIX algorithm.
> 
> To keep your schema, I would suggest that it is not enough to 
> ask Q1.  In fact, one can be easily deceived by considering
> only Q1. You  must ask the PKIX-specific version of Q1,
> and then consider the ramifications on testable
> X.509 conformance. (Q3 seems irrelevant.)
> 
> Q1 refers to the rule:
> 
> "10.5	Certificate processing
> ...
> 
> The following checks are applied to a certificate:
> a)	Check that the signature verifies, that dates are valid, that 
> the certificate subject and certificate issuer names chain correctly, and 
> that the certificate has not been revoked."
> 
> PKIX Q1 refers to a particular definition of what
> chaining names "correctly" is. And the 2459 definition 
> of name matching in *PKIX-conforming* systems is not compatible 
> with systems tested/certified to be conforming to the X509 standard, by 
> specific intent of the NIST/NSA authors, evidently. 
> 
> As Trevor said, its all a big mess that requires practical
> treatment, not religious dogma, in today's products
> that are "based on RFC 2459". The list will no doubt
> diverge here between the paper-architects and product
> builders.
> 
> Why we cannot just implement X.509 name matching defeats me.
> 
> Peter.

Date: Fri, 09 Jun 2000 14:12:42 +0200
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications
To: [email-masked]
Subject: Re: Correct approach to certificate validation?

This is a cryptographically signed message in MIME format.

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

> Ed Gerck wrote:
> > 'Be liberal in what you expect' can be
> > applied here without  A N Y  decrease in cryptographic
> > authentication security.

I wasn't particularly lucid in my earlier response, so feel I should
probably try again. A few nights' worth of heavy drinking works all but
wonders on one's faculties for reason.

Being liberal should certainly remain an option, since potential
customers will no doubt continue to insist that one's applications be
interoperable with broken, or non-conformant if you prefer that term,
Public Key Infrastructures and their components.

I feel that name constraints are a valuable tool for delegating trust to
external parties. Rather than my current behavior, which is to trust
whomever AOL tells me to trust, I would be much more comfortable using a
certificate issued by a local administrator here at Celo.

Such a certificate would, hopefully, hold more worth to the recipient
than merely the ability to send me encrypted e-mail, by virtue of being
issued by my employer, who should be able to vouch for my identity with
a reasonably high degree of certainty.

Rather than expecting all recipients to blindly trust the Celo-local
issuer for any and all extents, which I personally consider rather rude,
an rfc822Name constraint could be included in order to inform the
relying party that this issuer intends to issue certificates to Celo
employees exclusively, thus requiring far less blind faith from the
relying party.

To try to summarize:

Constraining one's intended certification is essential, since it will
allow for a much finer granularity in the delegation of trust than the
current model with it's childish boolean trusted/not trusted mechanism.

//oscar
--------------msBE97078F8A0220D47D35FEB4
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

--------------msBE97078F8A0220D47D35FEB4--

From: <[email-masked]>
Sender: "denis bider" <[email-masked]>
To: "'Grant, Alistair'" <[email-masked]>, "'Trevor Freeman'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Correct approach to certificate validation?
Date: Fri, 9 Jun 2000 14:05:08 +0200
Importance: Normal

> Inconsistent behaviour amongst various components of a system simply
> makes tracking down a problem more difficult, as I expect Denis Bider
> can attest to.

Grant is correct on this issue. As a user/developer, I would have preferred
IE5 and Outlook to use the same validation scheme as is used in other
products out there.

(Simple example: if IE5/Outlook2000 did use the same validation technique as
the rest of the world, I would not have been misled into thinking that the
problem is at the IIS side, and, hence, would not have spent tens of hours
trying to find the problem where it did not exist. Of course, it was my
mistake that caused certificate names not to chain, and nor IE5 nor IIS can
be blamed for any of this. Essentially, the fault was mine entirely. But
still, where IE's behavior could be helpful, it was misleading. Personally,
I would have preferred it to be helpful.)

Regards,

denis

Date: Fri, 09 Jun 2000 11:28:27 +0200
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications
To: [email-masked]
Subject: Re: Correct approach to certificate validation?

This is a cryptographically signed message in MIME format.

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

Ed Gerck wrote:
> Why should we continue to confuse name validation with
> certificate validation?  Name chaining should be optional IMO,
> not expected behavior. 'Be liberal in what you expect' can be
> applied here without  A N Y  decrease in cryptographic
> authentication security.

My personal opinion, and humble one at that, is that the issue is of
greater importance than "simply" one of cryptographic security.

The principals of X.509, as has been previously stated in this thread,
are in the naming, and not in the cryptographic keys themselves.

The value of authentication, again IMHO, is in the degree of trust which
the Relying Party can hold as to the identity of the certificate subject
presented and not in the relative merits of the length and/or algorithm
employed for the cryptographic key.

My two crowns worth, anyway.

Cheers!

//oscar
--------------ms828A2011C597B02E3D4CF8A6
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

--------------ms828A2011C597B02E3D4CF8A6--

From: "Grant, Alistair" <[email-masked]>
To: Trevor Freeman <[email-masked]>
Cc: [email-masked]
Subject: RE: Correct approach to certificate validation?
Date: Fri, 9 Jun 2000 13:57:51 +1000 

Hi Trevor,

Trevor Freeman wrote:
> To err is human, and people make mistakes.
 
Which is one of the reasons why a certificate may be revoked and re-issued.
 
To add to the list of arguments for following the standard:
 
Inconsistent behaviour amongst various components of a system simply makes
tracking down a problem more difficult, as I expect Denis Bider can attest
to.  I doubt that this change has made the overall system more robust.  It
seems unlikely that all implementations are going to operate in the same
manner.  Based on Denis' experience, just taking Microsoft's various systems
results in inconsistent behaviour.

Cheers, 

Alistair Grant 
Project Manager - Development 
Computer Associates, OpenDirectory Lab 
Mooroolbark, Victoria, Australia 
Phone:    +61 3 9727 8912 
Mobile:   +61 408 565 080 
Fax:      +61 3 9727 3491 
E-Mail:   [email-masked] 

Date: Thu, 08 Jun 2000 23:10:42 -0400
From: Rich Salz <[email-masked]>
To: Al Arsenault <[email-masked]>
CC: Trevor Freeman <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Correct approach to certificate validation?

Al,

You're saying that the current deployed base of CA's ensures that
the issuer DN of certs they issue is exactly the same as the subject
DN of its own signing cert?  If my understanding is correct, not
only do I strongly concur, but I don't know of any product that
works otherwise, in the course of normal operation/default config.
Does anyone know of a product that doesn't?

Even if there is one, it doesn't matter.  And if the standard is 20
years old, it doesn't matter (heck, TCP's older than that).

Generally speaking, "that's what everyone else does" is the kind
of argument that, in the IETF, generally trumps anything else.
Trevor, I thought you've been around long enough to know this.
	/r$

Date: Thu, 08 Jun 2000 20:03:36 -0700
From: Ed Gerck <[email-masked]>
To: [email-masked]
Subject: Re: Correct approach to certificate validation?

List:

Why should we continue to confuse name validation with
certificate validation?  Name chaining should be optional IMO,
not expected behavior. 'Be liberal in what you expect' can be
applied here without  A N Y  decrease in cryptographic
authentication security.

Cheers,

Ed Gerck

Date: Thu, 08 Jun 2000 22:31:31 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Trevor Freeman <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Correct approach to certificate validation?

Trevor,

	Here's the justification:

	Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign,
whomever) has been built to conform to existing/understood X.509/RFC2459
name chaining rules.  Suppose that such a system has been deployed for,
oh, say, a large Government department, or a large corporation, or...

	Now, suppose that a CA from some other corporation that follows the
rules you suggest - i.e., name chaining doesn't matter.  We want to
integrate that CA into the existing PKI.  

	Now, for whatever reason - human frailty, whatever - that new CA is
used to create a certificate whose distinguish name is "C=AW,
O=Government, OU= Computers, CN= CA1", and then that CA creates user
certs where the issuer name is "C=AW, O=Government, OU=Computer,
CN=CA1".  Note that these names are not equivalent.*

	Suppose that all other information - AKI, AIA, etc. - is set up
properly.

	Now, whenever a cert path is validated using the new CA, it will be
validated, because the fact that the end entity cert's issuer name and
the CA cert's subject name aren't the same doesn't matter.  However,
whenever that same cert path is validated by a node in the existing PKI,
validation will fail, because of the name chaining failure. The notion
of obtaining different results by different points in the system is
disconcerting, to say the least.

	That's the reason:  by building your system this way, you cause the
multi-vendor interoperable PKI to fail.  If you were building your
system to not interoperate with any other existing products, then I
think we could probably agree that you were right; there is no real
reason that names have to chain.  However, lots of people do want your
system to interoperate with other products.  I'm fairly confident that
Dave wants them to.  I know that in some of the cases I'm dealing with
now, I need them to.  And they don't.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

*And yes, I have seen cases where name chaining failed - and thus
certificate validation failed when it shouldn't have - because of a
misplaced comma in a CN field.  I've also seen it fail because of an
extra space in an OU field, and several other situations.

> Trevor Freeman wrote:
> 
> Life is complicated, but this is not so bad - Isaac Newton's rules
> where around a lot longer before they were found to be wrong.
> I am still waiting to here further justification (beyond the old
> ground of "its in the spec"). and so far you are confirming my
> suspicions that there are none.
> 
>  -----Original Message-----
> From:   David P. Kemp [mailto:[email-masked]]
> Sent:   Thursday, June 08, 2000 8:35 AM
> To:     [email-masked]
> Subject:        RE: Correct approach to certificate validation?
> 
> Trevor,
> 
> > From: "Trevor Freeman" <[email-masked]>
> >
> > David,
> > Interoperability is a primary goal, however that is often scarified
> by
> > standards. It is very easy to produce a document with a set of do's
> and
> > don'ts  without any regard for the previous standard, the impact on
> the
> > deployed products or how migration is achieved between the old and
> new
> > standard. It is also unrealistic to think that all products deployed
> > would conform to a single standard. Most products have a lifetime of
> > years. The interoperability matrix is vast and getting worse every
> time
> > a new version of  a standard is released.
> > So to return to the original point, besides citing a 20 year old
> clause
> > in a standard, and saying we should do it because its in the
> standard,
> > and requiring administrators to have a faultless record, I have
> still
> > not hear any reasoned, argument as to what is actually achieved by
> this
> > behavior.
> > No standard or clause in a standard has a divine right of existence.
> > Trevor
> 
> On the one hand, you seem to be decrying the ease of producing new
> specifications without regard for previous standards and deployed
> products.
> 
> On the other, you seem to support discarding a 20 year old clause
> in a standard without regard for its impact on deployed products which
> have been built according to the standard.
> 
> The "divine right" of any clause comes not from heaven or inheritance,
> but from the fact that it has been vetted internationally (in the ISO
> and the IETF) over a period of many years.  Over that time (whether
> it's
> 12 or 20 years is immaterial), the requirement that certificates point
> to the correct issuer has not only survived, it has not to my
> knowledge
> been even mildly controversial.   Now that there is discussion of
> the topic, the requirement will either survive or be discarded based
> on international consensus.   There is no divine right, just the
> stability (inertia?) of a consensus-based standard-setting
> process.
> 
> You may present a case that the requirement should be removed from
> X.509
> and then from the PKIX profile of X.509.
> Or you may choose not to comply with X.509.
> 
> But you can't both ignore the requirement and claim compliance.
> 
> > Certificate discovery is not the issue here.
> >
> > For certificate discovery,  we have a domain push mechanism as well
> as
> > AIA. We are also adding a lookup by name, and a configurable URL
> search
> > path i.e. a set of URLs to search (LDAP, HTTP, FTP)
> 
> Certificate discovery *is* the issue.
> 
> If you are adding a "lookup by name" function to your products,
> how will that work if certificates do not have correct issuer
> names?  If I have someone's End Entity certificate, how do I find a
> path of CA certs that leads to my trust point (not necessarily the
> certificate subject's trust point), in the multi-vendor,
> multi-administrative-domain environment of the Internet.
> 
> Products may support many certificate discovery mechanisms, both
> standards-based and differentiating.  But there needs to be at
> least one "Internet" interoperability mode which all products
> support.  That mode is defined by PKIX: the certificate profile
> and the LDAP schema.
> 
> One "Internet mode" mechanism which follows the current PKIX
> specifications is for organizations to place public information,
> including CA and EE certificates, in border directories, and to link
> the border directories together using directory-to-directory chaining,
> LDAP referrals, or both.  If you propose to eliminate the X.509
> requirement for correct issuer names, you will need to address the
> impact on current applications built to the current standards,
> as well as the feasability of future applications built to an
> amended standard.
> 
> Dave
> 
> P.S.  I don't understand why you keep referring to "punishing
> administrators" and "requiring administrators to have a flawless
> record" and "eliminating imperfection".  A CA workstation has its own
> signing key and certificate.  If the workstation cannot correctly
> place
> its own name in the issuer field of every certificate it signs, that
> is
> a product flaw.  This X.509 requirement does not hinge upon human
> perfectability.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, <[email-masked]>
Subject: RE: Correct approach to certificate validation?
Date: Thu, 8 Jun 2000 18:35:43 -0700
Importance: Normal

David,

My draft has nothing to do with the fact that the name chaining may be
incorrect but applies even in the cases where name chaining is present and
correct.

There are various cases where not going strictly on name chaining can be
benifitual.  For example, if a company changes names the CA certificate can
be updated without having to re-issue all subordiante certificates at the
same time.  (This may happen due to merges, splits, name changes or court
ordered actions.)

jim

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 7:00 AM
To: [email-masked]
Subject: RE: Correct approach to certificate validation?

Trevor,

It isn't about punishing administrators for minor errors, it is
about achieving an overall system with the goals of being both
secure and non-intrusive to the end user.  That may well mean that
administrators have to do more thinking, planning, and quality control,
but that is what they (we, the providers of a PKI for our branch of
Govt) are paid to do.

The specific case I'm referring to is Jim Schaad's assertion that an
S/MIME-specific cert path attribute is needed because applications
can't find CA certificates.  I didn't realize until now that that was
because in your environment subject certificates are not required to
have a correct issuer name!  It seemed obvious to me that the PKI is
responsible for correctly binding names to keys.  But you are saying
that Issuer names don't really matter, they're just a hint to help
applications search for a cert with a signing key that validates the
subject cert signature.  Well no wonder applications can't find CA
certs in that environment!

That isn't necessarily a wrong theoretical approach - SPKI is based
on the premise that only keys are important, names are simply optional
attributes attached to keys.  But it is wrong in X.509 because X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers.

Standards are about interworking in a multi-vendor environment; the
testable requirements contained in standards are covenants between
supplier and customer.  My goal is for a CMI purchased from vendor
X and operated by company A to work with applications purchased from
vendors Y and Z and operated by companies B and C.  I understand
that that is not your primary goal, but I expect you to acknowledge
that when as a result of non-conformance some applications work and
others don't, it is NOT the fault of the conforming applications even
when they are the ones that fail.  And that when someone from company
X proposes as a Standard a workaround for a problem created somewhere
else in company X, the IETF is entitled to disregard the
company-specific rationale for that workaround.

Regards,
Dave

> From: "Trevor Freeman" <[email-masked]>
>
> Hi David,
> I am afraid I don't see it necessary to eradicate every little
> imperfection because it is there. To err is human, and people make
> mistakes. People also have a wide list of requires which you may or may
> not agree with, but it does not mean that it is less real to them.
> So I don't see this as an error, simple a different point of view, and
> we will obviously disagree on this point.
> At the end of the day it is up to any product vendor to make the call as
> to what is\is not in their product, regardless what is in the standard.
> It is up to the market place to decide. History certainly tells us that
> customers like robustness in a product.
> If you can cite a specific issue, then we will obviously reconsider, but
> I don't find punishing minor infractions of administrators a compelling
> case.
> Trevor

Content-Class: urn:content-classes:message
Subject: RE: Correct approach to certificate validation?
Date: Thu, 8 Jun 2000 15:39:12 -0700
From: "Trevor Freeman" <[email-masked]>
To: "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD19A.5E79C38C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Life is complicated, but this is not so bad - Isaac Newton's rules
where around a lot longer before they were found to be wrong.
I am still waiting to here further justification (beyond the old ground
of "its in the spec"). and so far you are confirming my suspicions that
there are none.

 -----Original Message-----
From: 	David P. Kemp [mailto:[email-masked]]=20
Sent:	Thursday, June 08, 2000 8:35 AM
To:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

> From: "Trevor Freeman" <[email-masked]>
>=20
> David,
> Interoperability is a primary goal, however that is often scarified by
> standards. It is very easy to produce a document with a set of do's
and
> don'ts  without any regard for the previous standard, the impact on
the
> deployed products or how migration is achieved between the old and new
> standard. It is also unrealistic to think that all products deployed
> would conform to a single standard. Most products have a lifetime of
> years. The interoperability matrix is vast and getting worse every
time
> a new version of  a standard is released.
> So to return to the original point, besides citing a 20 year old
clause
> in a standard, and saying we should do it because its in the standard,
> and requiring administrators to have a faultless record, I have still
> not hear any reasoned, argument as to what is actually achieved by
this
> behavior.
> No standard or clause in a standard has a divine right of existence.
> Trevor

On the one hand, you seem to be decrying the ease of producing new
specifications without regard for previous standards and deployed
products.

On the other, you seem to support discarding a 20 year old clause
in a standard without regard for its impact on deployed products which
have been built according to the standard.

The "divine right" of any clause comes not from heaven or inheritance,
but from the fact that it has been vetted internationally (in the ISO
and the IETF) over a period of many years.  Over that time (whether it's
12 or 20 years is immaterial), the requirement that certificates point
to the correct issuer has not only survived, it has not to my knowledge
been even mildly controversial.   Now that there is discussion of
the topic, the requirement will either survive or be discarded based
on international consensus.   There is no divine right, just the
stability (inertia?) of a consensus-based standard-setting
process.

You may present a case that the requirement should be removed from X.509
and then from the PKIX profile of X.509.
Or you may choose not to comply with X.509.

But you can't both ignore the requirement and claim compliance.

> Certificate discovery is not the issue here.
>
> For certificate discovery,  we have a domain push mechanism as well as
> AIA. We are also adding a lookup by name, and a configurable URL
search
> path i.e. a set of URLs to search (LDAP, HTTP, FTP)

Certificate discovery *is* the issue.

If you are adding a "lookup by name" function to your products,
how will that work if certificates do not have correct issuer
names?  If I have someone's End Entity certificate, how do I find a
path of CA certs that leads to my trust point (not necessarily the
certificate subject's trust point), in the multi-vendor,
multi-administrative-domain environment of the Internet.

Products may support many certificate discovery mechanisms, both
standards-based and differentiating.  But there needs to be at
least one "Internet" interoperability mode which all products
support.  That mode is defined by PKIX: the certificate profile
and the LDAP schema.

One "Internet mode" mechanism which follows the current PKIX
specifications is for organizations to place public information,
including CA and EE certificates, in border directories, and to link
the border directories together using directory-to-directory chaining,
LDAP referrals, or both.  If you propose to eliminate the X.509
requirement for correct issuer names, you will need to address the
impact on current applications built to the current standards,
as well as the feasability of future applications built to an
amended standard.

Dave

P.S.  I don't understand why you keep referring to "punishing
administrators" and "requiring administrators to have a flawless
record" and "eliminating imperfection".  A CA workstation has its own
signing key and certificate.  If the workstation cannot correctly place
its own name in the issuer field of every certificate it signs, that is
a product flaw.  This X.509 requirement does not hinge upon human
perfectability.

------_=_NextPart_001_01BFD19A.5E79C38C
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 =
6.0.4384.0">
<TITLE>RE: Correct approach to certificate validation?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Life is complicated, but this is not so bad - Isaac =
Newton's rules&nbsp; where around a lot longer before they were found to =
be wrong.<BR>
I am still waiting to here further justification (beyond the old ground =
of &quot;its in the spec&quot;). and so far you are confirming my =
suspicions that there are none.<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; David P. Kemp [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
Sent:&nbsp;&nbsp; Thursday, June 08, 2000 8:35 AM<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Correct approach =
to certificate validation?<BR>
<BR>
Trevor,<BR>
<BR>
&gt; From: &quot;Trevor Freeman&quot; =
&lt;[email-masked]&gt;<BR>
&gt;<BR>
&gt; David,<BR>
&gt; Interoperability is a primary goal, however that is often scarified =
by<BR>
&gt; standards. It is very easy to produce a document with a set of do's =
and<BR>
&gt; don'ts&nbsp; without any regard for the previous standard, the =
impact on the<BR>
&gt; deployed products or how migration is achieved between the old and =
new<BR>
&gt; standard. It is also unrealistic to think that all products =
deployed<BR>
&gt; would conform to a single standard. Most products have a lifetime =
of<BR>
&gt; years. The interoperability matrix is vast and getting worse every =
time<BR>
&gt; a new version of&nbsp; a standard is released.<BR>
&gt; So to return to the original point, besides citing a 20 year old =
clause<BR>
&gt; in a standard, and saying we should do it because its in the =
standard,<BR>
&gt; and requiring administrators to have a faultless record, I have =
still<BR>
&gt; not hear any reasoned, argument as to what is actually achieved by =
this<BR>
&gt; behavior.<BR>
&gt; No standard or clause in a standard has a divine right of =
existence.<BR>
&gt; Trevor<BR>
<BR>
On the one hand, you seem to be decrying the ease of producing new<BR>
specifications without regard for previous standards and deployed<BR>
products.<BR>
<BR>
On the other, you seem to support discarding a 20 year old clause<BR>
in a standard without regard for its impact on deployed products =
which<BR>
have been built according to the standard.<BR>
<BR>
The &quot;divine right&quot; of any clause comes not from heaven or =
inheritance,<BR>
but from the fact that it has been vetted internationally (in the =
ISO<BR>
and the IETF) over a period of many years.&nbsp; Over that time (whether =
it's<BR>
12 or 20 years is immaterial), the requirement that certificates =
point<BR>
to the correct issuer has not only survived, it has not to my =
knowledge<BR>
been even mildly controversial.&nbsp;&nbsp; Now that there is discussion =
of<BR>
the topic, the requirement will either survive or be discarded based<BR>
on international consensus.&nbsp;&nbsp; There is no divine right, just =
the<BR>
stability (inertia?) of a consensus-based standard-setting<BR>
process.<BR>
<BR>
You may present a case that the requirement should be removed from =
X.509<BR>
and then from the PKIX profile of X.509.<BR>
Or you may choose not to comply with X.509.<BR>
<BR>
But you can't both ignore the requirement and claim compliance.<BR>
<BR>
<BR>
<BR>
<BR>
&gt; Certificate discovery is not the issue here.<BR>
&gt;<BR>
&gt; For certificate discovery,&nbsp; we have a domain push mechanism as =
well as<BR>
&gt; AIA. We are also adding a lookup by name, and a configurable URL =
search<BR>
&gt; path i.e. a set of URLs to search (LDAP, HTTP, FTP)<BR>
<BR>
Certificate discovery *is* the issue.<BR>
<BR>
If you are adding a &quot;lookup by name&quot; function to your =
products,<BR>
how will that work if certificates do not have correct issuer<BR>
names?&nbsp; If I have someone's End Entity certificate, how do I find =
a<BR>
path of CA certs that leads to my trust point (not necessarily the<BR>
certificate subject's trust point), in the multi-vendor,<BR>
multi-administrative-domain environment of the Internet.<BR>
<BR>
Products may support many certificate discovery mechanisms, both<BR>
standards-based and differentiating.&nbsp; But there needs to be at<BR>
least one &quot;Internet&quot; interoperability mode which all =
products<BR>
support.&nbsp; That mode is defined by PKIX: the certificate profile<BR>
and the LDAP schema.<BR>
<BR>
One &quot;Internet mode&quot; mechanism which follows the current =
PKIX<BR>
specifications is for organizations to place public information,<BR>
including CA and EE certificates, in border directories, and to link<BR>
the border directories together using directory-to-directory =
chaining,<BR>
LDAP referrals, or both.&nbsp; If you propose to eliminate the X.509<BR>
requirement for correct issuer names, you will need to address the<BR>
impact on current applications built to the current standards,<BR>
as well as the feasability of future applications built to an<BR>
amended standard.<BR>
<BR>
Dave<BR>
<BR>
<BR>
P.S.&nbsp; I don't understand why you keep referring to =
&quot;punishing<BR>
administrators&quot; and &quot;requiring administrators to have a =
flawless<BR>
record&quot; and &quot;eliminating imperfection&quot;.&nbsp; A CA =
workstation has its own<BR>
signing key and certificate.&nbsp; If the workstation cannot correctly =
place<BR>
its own name in the issuer field of every certificate it signs, that =
is<BR>
a product flaw.&nbsp; This X.509 requirement does not hinge upon =
human<BR>
perfectability.<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD19A.5E79C38C--

Content-return: allowed
Date: Thu, 08 Jun 2000 14:47:27 -0700
From: Peter Williams <[email-masked]>
Subject: RE: Correct approach to certificate validation?
To: "'David P. Kemp'" <[email-masked]>
Cc: [email-masked]

Dave,

I agree that (1), (2) and (3) are true assertions. Perhaps you
could be as clear for me...for the PKIX profile of X.509:

Do you realize, and agree, that
the way NIST/NSA designers deliberately constructed
RFC 2459's name matching process (during
path validation of an intermediate or
EE certificate) is such that implementations
of the X.509 path processing algorithm produce a different
validity result to the PKIX algorithm.

To keep your schema, I would suggest that it is not enough to 
ask Q1.  In fact, one can be easily deceived by considering
only Q1. You  must ask the PKIX-specific version of Q1,
and then consider the ramifications on testable
X.509 conformance. (Q3 seems irrelevant.)

Q1 refers to the rule:

"10.5	Certificate processing
...

The following checks are applied to a certificate:
a)	Check that the signature verifies, that dates are valid, that 
the certificate subject and certificate issuer names chain correctly, and 
that the certificate has not been revoked."

PKIX Q1 refers to a particular definition of what
chaining names "correctly" is. And the 2459 definition 
of name matching in *PKIX-conforming* systems is not compatible 
with systems tested/certified to be conforming to the X509 standard, by 
specific intent of the NIST/NSA authors, evidently. 

As Trevor said, its all a big mess that requires practical
treatment, not religious dogma, in today's products
that are "based on RFC 2459". The list will no doubt
diverge here between the paper-architects and product
builders.

Why we cannot just implement X.509 name matching defeats me.

Peter.

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 2:24 PM
To: [email-masked]
Subject: RE: Correct approach to certificate validation?

Peter,

Do you agree that:

1) path validation requirement "a" of X.509 requires name chaining?

2) if the subject of a certificate is a CA then the subject field
   MUST be populated with a non-empty distinguished name matching the
   contents of the issuer field in all certificates issued by the
   CA (RFC 2459 section 4.2.1.6)

3) A certificate may use a null DN iff the subject/issuer alternative
   name extension is flagged critical *and* for every name form used
   in the GeneralName type, there shall be a name registration system
   that ensures that any name used unambiguously identifies one entity
   to both certificate issuer and certificate users.
   (X.509 section 12.3.2.1)

Dave

Date: Thu, 8 Jun 2000 15:20:47 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Correct approach to certificate validation?
Cc: <[email-masked]>

Trevor,

>Certificate discovery is not the issue here.

I know that the focus of the discussion has been matching up subject 
and issuer names when validating a cert path.  However, since cert 
path discovery logically precedes validation, and since the nominal 
model for discovery is based on looking for a CA cert that contains a 
subject name that was the issuer name on the "lower" level cert, I 
think it appropriate to ask the discovery question.

>The question is that if you have a certificate who's signature 
>integrity can be traced up to a trusted root, containing acceptable 
>policy as defined by that root, and  who's names lie within the 
>allowed namespaces as defined by the name constraints in parent 
>certificates to the certificate in question, what is the value in 
>checking that the issuer-subject names chain?
>We have encountered such situations, by design, and by accident. In 
>all cases, the cost\benefit analysis in our view is stacked in favor 
>of not performing the name chaining check, and tolerating this 
>situation.

Could you provide some examples of the "by design" situations you 
have encountered?

>I agree that name constraints are important as the certificate is 
>making those names available to the applications, so it is important 
>that we can filter acceptable from not-acceptable names. We actually 
>follow a methodology similar to one you mentioned in a previous 
>thread which is to build all possible paths, then apply the name 
>constraints to determine the quality of the path.

I don't recall suggesting the approach you mention here.  I would 
guess that path discovery performed using subject/issuer name 
matching and AIK/SIK discrimination would rarely yield multiple 
paths. But, if it did, then I agree that application of the name 
constraints extension as part of path validation would discard paths 
that violated the constraints.

>For certificate discovery,  we have a domain push mechanism as well 
>as AIA. We are also adding a lookup by name, and a configurable URL 
>search path i.e. a set of URLs to search (LDAP, HTTP, FTP)

The domain push mechanism sounds local, perhaps MS specific?  AIA 
would be definitive.  Does one look at the issuer name to select a 
subset of the search search paths you allude to, or do you just try 
to do lookups via ll of them?

Steve

From: [email-masked]
Date: Thu, 08 Jun 2000 11:06:01 -0500 (CDT)
Date-warning: Date header was inserted by mta5.rcsntx.swbell.net
Subject: Shocking LOSE 10-100lbs. DESTINY
To: [email-masked]

Hello From Destiny,

You will LOOSE 20-100 pounds easy!
Do to Such a high demand for Destiny, we are able
To Dramatically reduce our price for the entire System!
You will LOVE our incredible offer on this
Scientific Breakthrough in Weight Loss.
Now with a 105% Money Back Guarantee!   
LOOK! http://home.swbell.net/zainprov/destiny.htm

We hope things are going well for you.  Good luck, God Bless, and 
HAVE A GREAT DAY!

Either you are someone else subscribed to our list.  To be removed
Simply reply with a blank email.  

Thank you,

Sherry Wilson

Date: Thu, 8 Jun 2000 11:34:52 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Correct approach to certificate validation?
To: [email-masked]
Content-MD5: 066FyQiZQm4F+lXgEhbL+w==

Trevor,

> From: "Trevor Freeman" <[email-masked]>
> 
> David,
> Interoperability is a primary goal, however that is often scarified by
> standards. It is very easy to produce a document with a set of do's and
> don'ts  without any regard for the previous standard, the impact on the
> deployed products or how migration is achieved between the old and new
> standard. It is also unrealistic to think that all products deployed
> would conform to a single standard. Most products have a lifetime of
> years. The interoperability matrix is vast and getting worse every time
> a new version of  a standard is released.
> So to return to the original point, besides citing a 20 year old clause
> in a standard, and saying we should do it because its in the standard,
> and requiring administrators to have a faultless record, I have still
> not hear any reasoned, argument as to what is actually achieved by this
> behavior.
> No standard or clause in a standard has a divine right of existence.
> Trevor

On the one hand, you seem to be decrying the ease of producing new
specifications without regard for previous standards and deployed
products.

On the other, you seem to support discarding a 20 year old clause
in a standard without regard for its impact on deployed products which
have been built according to the standard.

The "divine right" of any clause comes not from heaven or inheritance,
but from the fact that it has been vetted internationally (in the ISO
and the IETF) over a period of many years.  Over that time (whether it's
12 or 20 years is immaterial), the requirement that certificates point
to the correct issuer has not only survived, it has not to my knowledge
been even mildly controversial.   Now that there is discussion of
the topic, the requirement will either survive or be discarded based
on international consensus.   There is no divine right, just the
stability (inertia?) of a consensus-based standard-setting
process.

You may present a case that the requirement should be removed from X.509
and then from the PKIX profile of X.509.
Or you may choose not to comply with X.509.

But you can't both ignore the requirement and claim compliance.

> Certificate discovery is not the issue here.
>
> For certificate discovery,  we have a domain push mechanism as well as
> AIA. We are also adding a lookup by name, and a configurable URL search
> path i.e. a set of URLs to search (LDAP, HTTP, FTP)

Certificate discovery *is* the issue.

If you are adding a "lookup by name" function to your products,
how will that work if certificates do not have correct issuer
names?  If I have someone's End Entity certificate, how do I find a
path of CA certs that leads to my trust point (not necessarily the
certificate subject's trust point), in the multi-vendor,
multi-administrative-domain environment of the Internet.

Products may support many certificate discovery mechanisms, both
standards-based and differentiating.  But there needs to be at
least one "Internet" interoperability mode which all products
support.  That mode is defined by PKIX: the certificate profile
and the LDAP schema.

One "Internet mode" mechanism which follows the current PKIX
specifications is for organizations to place public information,
including CA and EE certificates, in border directories, and to link
the border directories together using directory-to-directory chaining,
LDAP referrals, or both.  If you propose to eliminate the X.509
requirement for correct issuer names, you will need to address the
impact on current applications built to the current standards,
as well as the feasability of future applications built to an
amended standard.

Dave

P.S.  I don't understand why you keep referring to "punishing
administrators" and "requiring administrators to have a flawless
record" and "eliminating imperfection".  A CA workstation has its own
signing key and certificate.  If the workstation cannot correctly place
its own name in the issuer field of every certificate it signs, that is
a product flaw.  This X.509 requirement does not hinge upon human
perfectability.

Content-Class: urn:content-classes:message
Subject: RE: Correct approach to certificate validation?
Date: Wed, 7 Jun 2000 16:54:53 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD0DB.C6A84F29
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Certificate discovery is not the issue here.=20

The question is that if you have a certificate who's signature integrity
can be traced up to a trusted root, containing acceptable policy as
defined by that root, and  who's names lie within the allowed namespaces
as defined by the name constraints in parent certificates to the
certificate in question, what is the value in checking that the
issuer-subject names chain?
We have encountered such situations, by design, and by accident. In all
cases, the cost\benefit analysis in our view is stacked in favor of not
performing the name chaining check, and tolerating this situation.

I agree that name constraints are important as the certificate is making
those names available to the applications, so it is important that we
can filter acceptable from not-acceptable names. We actually follow a
methodology similar to one you mentioned in a previous thread which is
to build all possible paths, then apply the name constraints to
determine the quality of the path.

For certificate discovery,  we have a domain push mechanism as well as
AIA. We are also adding a lookup by name, and a configurable URL search
path i.e. a set of URLs to search (LDAP, HTTP, FTP)

Trevor
 -----Original Message-----
From: 	Stephen Kent [mailto:[email-masked]]=20
Sent:	Wednesday, June 07, 2000 3:42 PM
To:	Trevor Freeman
Cc:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

Two observations:

	- path construction (going up toward a root) is nominally=20
based on the use of the issuer name to find the right CA certificate,=20
with the AKI/SKI used to disambiguate among multiple valid CA certs.=20
I recall that the list discussed the potential problems of using just=20
the AKI to locate a CA certificate.  I expressed concern then that=20
the AKI didn't provide a means of locating a CA certificate when it=20
was not local, i.e., one would need to have a database that was a=20
flat file for all possible CA certificates to do the lookup.  My=20
concern was that we were creating a situation where people might=20
build systems that had all the shortcomings of LAN e-mail systems,=20
e.g., they worked well locally, but did not scale across the=20
Internet. Of course, if one uses the AIA extension this problem might=20
be ameliorated.  So, my question is how do MS products locate a CA=20
cert that is not available in a local cache or local LDAP directory,=20
using just the AKI?

	- name constraints are critical to secure use of certs, so I=20
do hope that you are correctly enforcing this extension, when it is=20
present.  Contrary to what  Amir said, this is PKIX, not SPKI.  We=20
don't buy into the notion that keys are principals here :-).  If one=20
always uses name constraints in cross certs that link to other=20
administrative domains, something that a local CA or  can enforce=20
unilaterally, then names are reasonably safe to employ for access=20
control purposes. (Of course, one can't do this with TTP, but maybe=20
that's another good reason for not using them when identification for=20
access control is important.)  But, if you're violating the standards=20
to accommodate administrative sloppiness in managing CA names for=20
chaining, then maybe you're assuming an environment where one can=20
never rely on names for ACLs anyway. That's a scary environment.

Steve

------_=_NextPart_001_01BFD0DB.C6A84F29
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 =
6.0.4384.0">
<TITLE>RE: Correct approach to certificate validation?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Certificate discovery is not the issue here.<BR>
<BR>
The question is that if you have a certificate who's signature integrity =
can be traced up to a trusted root, containing acceptable policy as =
defined by that root, and&nbsp; who's names lie within the allowed =
namespaces as defined by the name constraints in parent certificates to =
the certificate in question, what is the value in checking that the =
issuer-subject names chain?<BR>
We have encountered such situations, by design, and by accident. In all =
cases, the cost\benefit analysis in our view is stacked in favor of not =
performing the name chaining check, and tolerating this situation.<BR>
<BR>
I agree that name constraints are important as the certificate is making =
those names available to the applications, so it is important that we =
can filter acceptable from not-acceptable names. We actually follow a =
methodology similar to one you mentioned in a previous thread which is =
to build all possible paths, then apply the name constraints to =
determine the quality of the path.<BR>
<BR>
For certificate discovery,&nbsp; we have a domain push mechanism as well =
as AIA. We are also adding a lookup by name, and a configurable URL =
search path i.e. a set of URLs to search (LDAP, HTTP, FTP)<BR>
<BR>
Trevor<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Stephen Kent [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent:&nbsp;&nbsp; Wednesday, June 07, 2000 3:42 PM<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Trevor Freeman<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Correct approach =
to certificate validation?<BR>
<BR>
Trevor,<BR>
<BR>
Two observations:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - path construction (going up =
toward a root) is nominally<BR>
based on the use of the issuer name to find the right CA =
certificate,<BR>
with the AKI/SKI used to disambiguate among multiple valid CA certs.<BR>
I recall that the list discussed the potential problems of using =
just<BR>
the AKI to locate a CA certificate.&nbsp; I expressed concern then =
that<BR>
the AKI didn't provide a means of locating a CA certificate when it<BR>
was not local, i.e., one would need to have a database that was a<BR>
flat file for all possible CA certificates to do the lookup.&nbsp; =
My<BR>
concern was that we were creating a situation where people might<BR>
build systems that had all the shortcomings of LAN e-mail systems,<BR>
e.g., they worked well locally, but did not scale across the<BR>
Internet. Of course, if one uses the AIA extension this problem =
might<BR>
be ameliorated.&nbsp; So, my question is how do MS products locate a =
CA<BR>
cert that is not available in a local cache or local LDAP directory,<BR>
using just the AKI?<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name constraints are =
critical to secure use of certs, so I<BR>
do hope that you are correctly enforcing this extension, when it is<BR>
present.&nbsp; Contrary to what&nbsp; Amir said, this is PKIX, not =
SPKI.&nbsp; We<BR>
don't buy into the notion that keys are principals here :-).&nbsp; If =
one<BR>
always uses name constraints in cross certs that link to other<BR>
administrative domains, something that a local CA or&nbsp; can =
enforce<BR>
unilaterally, then names are reasonably safe to employ for access<BR>
control purposes. (Of course, one can't do this with TTP, but maybe<BR>
that's another good reason for not using them when identification =
for<BR>
access control is important.)&nbsp; But, if you're violating the =
standards<BR>
to accommodate administrative sloppiness in managing CA names for<BR>
chaining, then maybe you're assuming an environment where one can<BR>
never rely on names for ACLs anyway. That's a scary environment.<BR>
<BR>
Steve<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD0DB.C6A84F29--

Content-Class: urn:content-classes:message
Subject: RE: Correct approach to certificate validation?
Date: Wed, 7 Jun 2000 16:00:16 -0700
From: "Trevor Freeman" <[email-masked]>
To: "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD0D4.253A6B56
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

David,
Interoperability is a primary goal, however that is often scarified by
standards. It is very easy to produce a document with a set of do's and
don'ts  without any regard for the previous standard, the impact on the
deployed products or how migration is achieved between the old and new
standard. It is also unrealistic to think that all products deployed
would conform to a single standard. Most products have a lifetime of
years. The interoperability matrix is vast and getting worse every time
a new version of  a standard is released.=20
So to return to the original point, besides citing a 20 year old clause
in a standard, and saying we should do it because its in the standard,
and requiring administrators to have a faultless record, I have still
not hear any reasoned, argument as to what is actually achieved by this
behavior.
No standard or clause in a standard has a divine right of existence.
Trevor
 -----Original Message-----
From: 	David P. Kemp [mailto:[email-masked]]=20
Sent:	Wednesday, June 07, 2000 7:00 AM
To:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

It isn't about punishing administrators for minor errors, it is
about achieving an overall system with the goals of being both
secure and non-intrusive to the end user.  That may well mean that
administrators have to do more thinking, planning, and quality control,
but that is what they (we, the providers of a PKI for our branch of
Govt) are paid to do.

The specific case I'm referring to is Jim Schaad's assertion that an
S/MIME-specific cert path attribute is needed because applications
can't find CA certificates.  I didn't realize until now that that was
because in your environment subject certificates are not required to
have a correct issuer name!  It seemed obvious to me that the PKI is
responsible for correctly binding names to keys.  But you are saying
that Issuer names don't really matter, they're just a hint to help
applications search for a cert with a signing key that validates the
subject cert signature.  Well no wonder applications can't find CA
certs in that environment!

That isn't necessarily a wrong theoretical approach - SPKI is based
on the premise that only keys are important, names are simply optional
attributes attached to keys.  But it is wrong in X.509 because X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers.

Standards are about interworking in a multi-vendor environment; the
testable requirements contained in standards are covenants between
supplier and customer.  My goal is for a CMI purchased from vendor
X and operated by company A to work with applications purchased from
vendors Y and Z and operated by companies B and C.  I understand
that that is not your primary goal, but I expect you to acknowledge
that when as a result of non-conformance some applications work and
others don't, it is NOT the fault of the conforming applications even
when they are the ones that fail.  And that when someone from company
X proposes as a Standard a workaround for a problem created somewhere
else in company X, the IETF is entitled to disregard the
company-specific rationale for that workaround.

Regards,
Dave

> From: "Trevor Freeman" <[email-masked]>
>=20
> Hi David,
> I am afraid I don't see it necessary to eradicate every little
> imperfection because it is there. To err is human, and people make
> mistakes. People also have a wide list of requires which you may or
may
> not agree with, but it does not mean that it is less real to them.
> So I don't see this as an error, simple a different point of view, and
> we will obviously disagree on this point.
> At the end of the day it is up to any product vendor to make the call
as
> to what is\is not in their product, regardless what is in the
standard.
> It is up to the market place to decide. History certainly tells us
that
> customers like robustness in a product.
> If you can cite a specific issue, then we will obviously reconsider,
but
> I don't find punishing minor infractions of administrators a
compelling
> case.
> Trevor

------_=_NextPart_001_01BFD0D4.253A6B56
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 =
6.0.4384.0">
<TITLE>RE: Correct approach to certificate validation?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>David,<BR>
Interoperability is a primary goal, however that is often scarified by =
standards. It is very easy to produce a document with a set of do's and =
don'ts&nbsp; without any regard for the previous standard, the impact on =
the deployed products or how migration is achieved between the old and =
new standard. It is also unrealistic to think that all products deployed =
would conform to a single standard. Most products have a lifetime of =
years. The interoperability matrix is vast and getting worse every time =
a new version of&nbsp; a standard is released.<BR>
So to return to the original point, besides citing a 20 year old clause =
in a standard, and saying we should do it because its in the standard, =
and requiring administrators to have a faultless record, I have still =
not hear any reasoned, argument as to what is actually achieved by this =
behavior.<BR>
No standard or clause in a standard has a divine right of existence.<BR>
Trevor<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; David P. Kemp [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
Sent:&nbsp;&nbsp; Wednesday, June 07, 2000 7:00 AM<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Correct approach =
to certificate validation?<BR>
<BR>
Trevor,<BR>
<BR>
It isn't about punishing administrators for minor errors, it is<BR>
about achieving an overall system with the goals of being both<BR>
secure and non-intrusive to the end user.&nbsp; That may well mean =
that<BR>
administrators have to do more thinking, planning, and quality =
control,<BR>
but that is what they (we, the providers of a PKI for our branch of<BR>
Govt) are paid to do.<BR>
<BR>
The specific case I'm referring to is Jim Schaad's assertion that an<BR>
S/MIME-specific cert path attribute is needed because applications<BR>
can't find CA certificates.&nbsp; I didn't realize until now that that =
was<BR>
because in your environment subject certificates are not required to<BR>
have a correct issuer name!&nbsp; It seemed obvious to me that the PKI =
is<BR>
responsible for correctly binding names to keys.&nbsp; But you are =
saying<BR>
that Issuer names don't really matter, they're just a hint to help<BR>
applications search for a cert with a signing key that validates the<BR>
subject cert signature.&nbsp; Well no wonder applications can't find =
CA<BR>
certs in that environment!<BR>
<BR>
That isn't necessarily a wrong theoretical approach - SPKI is based<BR>
on the premise that only keys are important, names are simply =
optional<BR>
attributes attached to keys.&nbsp; But it is wrong in X.509 because =
X.509<BR>
certificates are identified by and stored under Distinguished Names,<BR>
not public keys or SubjectKeyIdentifiers.<BR>
<BR>
Standards are about interworking in a multi-vendor environment; the<BR>
testable requirements contained in standards are covenants between<BR>
supplier and customer.&nbsp; My goal is for a CMI purchased from =
vendor<BR>
X and operated by company A to work with applications purchased from<BR>
vendors Y and Z and operated by companies B and C.&nbsp; I =
understand<BR>
that that is not your primary goal, but I expect you to acknowledge<BR>
that when as a result of non-conformance some applications work and<BR>
others don't, it is NOT the fault of the conforming applications =
even<BR>
when they are the ones that fail.&nbsp; And that when someone from =
company<BR>
X proposes as a Standard a workaround for a problem created =
somewhere<BR>
else in company X, the IETF is entitled to disregard the<BR>
company-specific rationale for that workaround.<BR>
<BR>
Regards,<BR>
Dave<BR>
<BR>
<BR>
<BR>
&gt; From: &quot;Trevor Freeman&quot; =
&lt;[email-masked]&gt;<BR>
&gt;<BR>
&gt; Hi David,<BR>
&gt; I am afraid I don't see it necessary to eradicate every little<BR>
&gt; imperfection because it is there. To err is human, and people =
make<BR>
&gt; mistakes. People also have a wide list of requires which you may or =
may<BR>
&gt; not agree with, but it does not mean that it is less real to =
them.<BR>
&gt; So I don't see this as an error, simple a different point of view, =
and<BR>
&gt; we will obviously disagree on this point.<BR>
&gt; At the end of the day it is up to any product vendor to make the =
call as<BR>
&gt; to what is\is not in their product, regardless what is in the =
standard.<BR>
&gt; It is up to the market place to decide. History certainly tells us =
that<BR>
&gt; customers like robustness in a product.<BR>
&gt; If you can cite a specific issue, then we will obviously =
reconsider, but<BR>
&gt; I don't find punishing minor infractions of administrators a =
compelling<BR>
&gt; case.<BR>
&gt; Trevor<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD0D4.253A6B56--

Date: Wed, 07 Jun 2000 17:26:01 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Correct approach to certificate validation?

At this point I am mightily confused, and would appreciate it if someone 
would clarify the issue, as I apparently tuned in late.

Trevor says that they enforce name constraints, but that they don't support
name chaining.  I must be missing something important here -- how
do the two differ, and/or how is one possible without the other?

Are we talking about CA names only, end-entity names, or what?

Some concrete examples pro and con would be very helpful.

Regards,

Bob

>>> "Trevor Freeman" <[email-masked]> 06/06/00 08:42PM >>>
We use AKI, but don't require it, as the field can be calculated on the
fly so to speak.
I am not linking the enforcement of name constrains with the enforcement
of name chaining in any. We will enforce name constraints as this is a
security issue, we don't enforce name chaining. 
We trust the CA because we have built a chain of certificate to a
trusted root, with valid policy and name constraints.

 -----Original Message-----
From: 	Denis Pinkas [mailto:[email-masked]] 
Sent:	Tuesday, June 06, 2000 1:33 AM
To:	Trevor Freeman
Cc:	[email-masked]; [email-masked] 
Subject:	Re: Correct approach to certificate validation?

> Hi Denis,

Now there are two Denis on the list. Don't be confused, the one
above is not me ! :-)

It seems that we are starting a very interesting threat.

> We have found that enforcing name chaining in path construction,
> causes more problems than it solves. We therefore have reverted to
> using the name as just a hint, rather than a critical factor and
> will as you have found, use a certificate signed with the right
> key as a valid parent in that chain. 

To be more precise, do you mean that you are using the authority key
identifier extension ?

This extension provides a means of identifying the public key
corresponding to the private key used to sign a certificate. The
keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to
facilitate chain building. 

If this is what you use, this means that you use a field that must
be present but does not need to be understood, since this extension
is marked NON critical. If your implementation relies on that field,
which options of that field are you using (since this is a sequence
of three optional fields) ? If I misunderstood what you are using,
please clarify.

> This applies to intermediate
> as well as self signed certificates. We have seen customer
> scenarios where you need to deliberately build certificates which
> don't chain on names so enforcing name chaining would cause
> problems.

It is true that enforcing name constraints within certificates
themselves provides limitations and causes problems. Enforcing name
chaining outside the certificates is much morer flexible ... and
should be recognized as a valid additional check in the
"son-of-RFC2459". 

> I know this is at odds with RFC2459, but as this behaviour does
> not in our view cause a security problem, but does make the
> overall process more robust, we have and will continue to opt for
> the more robust solution.

It seems to early at this stage to conclude that there are no
security problems with such an approach (there are not enough
information at this stage to make any conclusion). Just a remainder.
The basic principle is the following: it is not because a CA
certificate exists that it should be trusted. 

Denis
 
> I have also posted previously on the list that mandating name
> chaining, in addition to signatures and policy chaining is a bad
> idea.
> 
> Trevor
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, June 04, 2000 11:19 AM
> To: [email-masked] 
> Subject: Correct approach to certificate validation?
> 
> Now, based on my previous message, my question for this workgroup:
> 
> Which of these approaches is correct?
>   - the approach of IE5 and Outlook, which, if an Authority Key
> Identifier
> extension is present, does not perform a comparison of the
> issuer-DN in the
> subject-cert to the subject-DN of the root-cert?
>   - or the approach of Netscape and IIS4, which, even if an
> Authority Key
> Identifier extension is present, DOES still perform a comparison
> of the
> subject-cert-issuer-DN to the root-cert-subject-DN?
> 
> Regards,
> 
> denis bider
> 
> PS. I would like to thank Ace Swerling from Microsoft Consulting
> Services
> for the fact that he bothered to look into my problem, and
> especially to
> Peter Williams from Valicert who devoted much of his time to help
> me solve
> this issue. I appreciate your feedback very much.
> 
>  -----Original Message-----
> From:   denis bider [mailto:[email-masked]]  On Behalf Of
> [email-masked] 
> Sent:   Sunday, June 04, 2000 20:08
> To:     [email-masked]' 
> Subject:        Report - certificate validation in IE5, Outlook,
> IIS4, Netscape
> 4.72
> 
> Hello,
> 
> a while ago I sent to this list an enquiry regarding Microsoft's
> certificate
> validation code in IIS4. I have now resolved the problem that was
> the reason
> for my enquiry. Since the solution to the problem produced some
> interesting
> insight into how certificate chains are handled in IE5 and Outlook
> / IIS4
> and Netscape, and since the behavior in question should be covered
> by
> RFC2459, but does not seem to be, I am forwarding my findings to
> you.
> 
> I produced my own certificate generating utility, the intention of
> which was
> to generate certificates which could be used by IE5 to login into
> an
> SSL-protected web site running on IIS4. My problem was that,
> although IE5
> claimed my root-cert/subject-cert certificate chain to be valid,
> and
> although Outlook properly signed and verified messages signed by
> these
> certificates, IIS4 rejected all attempts to use the subject
> certificate for
> SSL client authentication. Also, when the subject certificate was
> imported
> into Netscape, Netscape didn't even show it as an elligible choice
> for SSL
> client authentication.
> 
> To sum it up, the problem was that there was a glitch in my code
> that caused
> the subject-DN in root-cert to be slightly different from the
> issuer-DN in
> the subject-cert. It seems that the certificate verification code
> in IE5 and
> Outlook2000 is somewhat easy-going, since both of these products
> validated
> the pair of certificates as valid (they performed cert-chain
> validation
> solely on the grounds of the key identifier in the Authority Key
> Identifier
> extension, they did not compare the sub-cert-issuerDN to the
> root-cert-subjectDN). IIS4 and Netscape Communicator, on the other
> hand,
> seem to have a more stringent policy, since they both rejected
> these
> certificates.
> 
> denis bider

Date: Wed, 7 Jun 2000 18:42:12 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Correct approach to certificate validation?
Cc: <[email-masked]>

Trevor,

Two observations:

	- path construction (going up toward a root) is nominally 
based on the use of the issuer name to find the right CA certificate, 
with the AKI/SKI used to disambiguate among multiple valid CA certs. 
I recall that the list discussed the potential problems of using just 
the AKI to locate a CA certificate.  I expressed concern then that 
the AKI didn't provide a means of locating a CA certificate when it 
was not local, i.e., one would need to have a database that was a 
flat file for all possible CA certificates to do the lookup.  My 
concern was that we were creating a situation where people might 
build systems that had all the shortcomings of LAN e-mail systems, 
e.g., they worked well locally, but did not scale across the 
Internet. Of course, if one uses the AIA extension this problem might 
be ameliorated.  So, my question is how do MS products locate a CA 
cert that is not available in a local cache or local LDAP directory, 
using just the AKI?

	- name constraints are critical to secure use of certs, so I 
do hope that you are correctly enforcing this extension, when it is 
present.  Contrary to what  Amir said, this is PKIX, not SPKI.  We 
don't buy into the notion that keys are principals here :-).  If one 
always uses name constraints in cross certs that link to other 
administrative domains, something that a local CA or  can enforce 
unilaterally, then names are reasonably safe to employ for access 
control purposes. (Of course, one can't do this with TTP, but maybe 
that's another good reason for not using them when identification for 
access control is important.)  But, if you're violating the standards 
to accommodate administrative sloppiness in managing CA names for 
chaining, then maybe you're assuming an environment where one can 
never rely on names for ACLs anyway. That's a scary environment.

Steve

Date: Wed, 7 Jun 2000 17:23:39 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Correct approach to certificate validation?
To: [email-masked]
Content-MD5: o906YrGPIOvV6INslRpnPw==

Peter,

Do you agree that:

1) path validation requirement "a" of X.509 requires name chaining?

2) if the subject of a certificate is a CA then the subject field
   MUST be populated with a non-empty distinguished name matching the
   contents of the issuer field in all certificates issued by the
   CA (RFC 2459 section 4.2.1.6)

3) A certificate may use a null DN iff the subject/issuer alternative
   name extension is flagged critical *and* for every name form used
   in the GeneralName type, there shall be a name registration system
   that ensures that any name used unambiguously identifies one entity
   to both certificate issuer and certificate users.
   (X.509 section 12.3.2.1)

Dave

From: Peter Williams <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Correct approach to certificate validation?
Date: Wed, 7 Jun 2000 13:45:25 -0700 

David,

"But it is wrong in X.509 because X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers."

X.509 does not require one to identify a storage
location for a cert at all, locate storage using a 
DN, nor does it require that the DN be used as the 
subject identity element bound to a key.

You should be aware, in further support of my
earlier statement, that PKIX certificates need contain no 
subject DN information. Nor need there be a DN name form populated
in the standard alternative name field for subjects,
as RFC 2459 authors and chairs declare to the Internet:

   "The subject alternative names extension allows additional identities
   to be bound to the subject of the certificate.  Defined options
   include an Internet electronic mail address, a DNS name, an IP
   address, and a uniform resource identifier (URI).  Other options
   exist, including completely local definitions [...]"

   "Further, if the only subject identity included in the certificate is
   an alternative name form (e.g., an electronic mail address), then the
   subject distinguished name MUST be empty (an empty sequence), and the
   subjectAltName extension MUST be present. If the subject field
   contains an empty sequence, the subjectAltName extension MUST be
   marked critical."

Do you assert that PKIX profile is not aligned
with X.509, when you make your various
claims concerning DNs?

Does a PKIX cert conform to X.509 literally
or in spirit, if the actual exampled option stated 
above in RFC 2459 is used?

PS.

The PKIX authors' name comparison rules already make
PKIX path processing non-conforming against
X.509 (i.e. the result of path processing
using the PKIX name chaining rule is not the same as
if one were to use the X.509 path
processing and name matching rule. X.509 conformance
is really not an issue in PKIX WG! 2459 already
built in the situation that even
two PKIX implementations may not process
paths the same! A cert chain can be
valid in one implementation, and invalid
in another; its not clear it the X.509
rules, though permitted by PKIX, make
for a conforming path processing implementation.

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 7:00 AM
To: [email-masked]
Subject: RE: Correct approach to certificate validation?

Trevor,

It isn't about punishing administrators for minor errors, it is
about achieving an overall system with the goals of being both
secure and non-intrusive to the end user.  That may well mean that
administrators have to do more thinking, planning, and quality control,
but that is what they (we, the providers of a PKI for our branch of
Govt) are paid to do.

The specific case I'm referring to is Jim Schaad's assertion that an
S/MIME-specific cert path attribute is needed because applications
can't find CA certificates.  I didn't realize until now that that was
because in your environment subject certificates are not required to
have a correct issuer name!  It seemed obvious to me that the PKI is
responsible for correctly binding names to keys.  But you are saying
that Issuer names don't really matter, they're just a hint to help
applications search for a cert with a signing key that validates the
subject cert signature.  Well no wonder applications can't find CA
certs in that environment!

That isn't necessarily a wrong theoretical approach - SPKI is based
on the premise that only keys are important, names are simply optional
attributes attached to keys.  

But it is wrong in X.509 because X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers.

Standards are about interworking in a multi-vendor environment; the
testable requirements contained in standards are covenants between
supplier and customer.  My goal is for a CMI purchased from vendor
X and operated by company A to work with applications purchased from
vendors Y and Z and operated by companies B and C.  I understand
that that is not your primary goal, but I expect you to acknowledge
that when as a result of non-conformance some applications work and
others don't, it is NOT the fault of the conforming applications even
when they are the ones that fail.  And that when someone from company
X proposes as a Standard a workaround for a problem created somewhere
else in company X, the IETF is entitled to disregard the
company-specific rationale for that workaround.

Regards,
Dave

> From: "Trevor Freeman" <[email-masked]>
> 
> Hi David,
> I am afraid I don't see it necessary to eradicate every little
> imperfection because it is there. To err is human, and people make
> mistakes. People also have a wide list of requires which you may or may
> not agree with, but it does not mean that it is less real to them.
> So I don't see this as an error, simple a different point of view, and
> we will obviously disagree on this point.
> At the end of the day it is up to any product vendor to make the call as
> to what is\is not in their product, regardless what is in the standard.
> It is up to the market place to decide. History certainly tells us that
> customers like robustness in a product.
> If you can cite a specific issue, then we will obviously reconsider, but
> I don't find punishing minor infractions of administrators a compelling
> case.
> Trevor

From: Carlisle Adams <[email-masked]>
To: [email-masked], "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Attribute Certificate Request
Date: Wed, 7 Jun 2000 15:53:00 -0400 

Hi Stephen, Pedro,

> ----------
> From: 	Stephen Farrell[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, June 05, 2000 3:46 PM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	Re: Attribute Certificate Request
> 
> Pedro,
> 
> Since the use cases for ACs aren't as well understood as for 
> public key certificates, there is, as yet, no equivalent to 
> CMP/CMC for AC requests. I would expect that, in future, we 
> might get around to writing one.
 
Actually, the future is not that far away...  :-)

The draft rfc2510bis puts in place a framework that allows CMP to be used as
a general protocol for management (including, of course, an initial request)
of any kind of certificate.  (Note that this was accomplished without
requiring any bits-on-the-wire changes to the RFC 2510 syntax.)  Formats
that have already been envisioned include attribute certificates and WTLS
certificates.  This strikes me as a very powerful and useful generalization,
and should serve to make this PKIX protocol potentially applicable to a
number of environments.

All that is required is a very short document listing the certificate types
of interest and providing a syntax for their corresponding templates.  Look
for this Internet Draft to appear shortly (within the next 2-3 weeks, I
hope).

Carlisle.

> Meanwhile, there is draft-ietf-pkix-laap-00.txt which describes
> an alternative to LDAP for AC retrieval, though this deliberately
> doesn't try to provide the equivalent of a CMP certification
> request.
> 
> Regards,
> Stephen.
> 
> Pedro Miguel Pereira Borges wrote:
> > 
> >    Hi all,
> > 
> >         I'm currently reading the "An Internet Attribute Certificate
> Profile
> > for Authorization" draft...
> >         However, there is a question that I would like to see answered:
> is
> > there a definition (ASN.1 or not) of what an attribute certificate
> request
> > should contain like there is one for the "normal" X.509 ID certificates
> ?
> > 
> >     Thanks in advance,
> > 
> >         Pedro Borges
> 

Date: Wed, 7 Jun 2000 10:00:12 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Correct approach to certificate validation?
To: [email-masked]
Content-MD5: BNyxfe4iNnIIbfsREL1EMg==

Trevor,

It isn't about punishing administrators for minor errors, it is
about achieving an overall system with the goals of being both
secure and non-intrusive to the end user.  That may well mean that
administrators have to do more thinking, planning, and quality control,
but that is what they (we, the providers of a PKI for our branch of
Govt) are paid to do.

The specific case I'm referring to is Jim Schaad's assertion that an
S/MIME-specific cert path attribute is needed because applications
can't find CA certificates.  I didn't realize until now that that was
because in your environment subject certificates are not required to
have a correct issuer name!  It seemed obvious to me that the PKI is
responsible for correctly binding names to keys.  But you are saying
that Issuer names don't really matter, they're just a hint to help
applications search for a cert with a signing key that validates the
subject cert signature.  Well no wonder applications can't find CA
certs in that environment!

That isn't necessarily a wrong theoretical approach - SPKI is based
on the premise that only keys are important, names are simply optional
attributes attached to keys.  But it is wrong in X.509 because X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers.

Standards are about interworking in a multi-vendor environment; the
testable requirements contained in standards are covenants between
supplier and customer.  My goal is for a CMI purchased from vendor
X and operated by company A to work with applications purchased from
vendors Y and Z and operated by companies B and C.  I understand
that that is not your primary goal, but I expect you to acknowledge
that when as a result of non-conformance some applications work and
others don't, it is NOT the fault of the conforming applications even
when they are the ones that fail.  And that when someone from company
X proposes as a Standard a workaround for a problem created somewhere
else in company X, the IETF is entitled to disregard the
company-specific rationale for that workaround.

Regards,
Dave

> From: "Trevor Freeman" <[email-masked]>
> 
> Hi David,
> I am afraid I don't see it necessary to eradicate every little
> imperfection because it is there. To err is human, and people make
> mistakes. People also have a wide list of requires which you may or may
> not agree with, but it does not mean that it is less real to them.
> So I don't see this as an error, simple a different point of view, and
> we will obviously disagree on this point.
> At the end of the day it is up to any product vendor to make the call as
> to what is\is not in their product, regardless what is in the standard.
> It is up to the market place to decide. History certainly tells us that
> customers like robustness in a product.
> If you can cite a specific issue, then we will obviously reconsider, but
> I don't find punishing minor infractions of administrators a compelling
> case.
> Trevor

From: "Ramsay, Ron" <[email-masked]>
To: Trevor Freeman <[email-masked]>, "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: RE: Correct approach to certificate validation?
Date: Wed, 7 Jun 2000 14:21:04 +1000 

Trevor,
 
I don't think David was saying you can't go your own way. In fact, RFC 2459
has a funny statement in it where it recognises that vendors may produce
non-conforming products.
 
I think the point he is making is that customers should be made aware that
your product conforms neither to RFC 2459 nor to X.509. And I think you
agree that it doesn't.
 
Ron.
 
PS These are my views and not those of my employer.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Wednesday, 7 June 2000 13:00
To: David P. Kemp
Cc: [email-masked]
Subject: RE: Correct approach to certificate validation?

Hi David,
I am afraid I don't see it necessary to eradicate every little imperfection
because it is there. To err is human, and people make mistakes. People also
have a wide list of requires which you may or may not agree with, but it
does not mean that it is less real to them.
So I don't see this as an error, simple a different point of view, and we
will obviously disagree on this point.
At the end of the day it is up to any product vendor to make the call as to
what is\is not in their product, regardless what is in the standard. It is
up to the market place to decide. History certainly tells us that customers
like robustness in a product.
If you can cite a specific issue, then we will obviously reconsider, but I
don't find punishing minor infractions of administrators a compelling case.
Trevor

 -----Original Message-----
From:   David P. Kemp [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent:   Tuesday, June 06, 2000 11:20 AM
To:     [email-masked]
Subject:        RE: Correct approach to certificate validation?

Trevor,

Could you describe a customer scenario which requires deliberate
non-chaining of names?  I can't envision any circumstance where a
CA 1) does not have a certificate containing the CA's signing key
and a subject name for the CA, or 2) cannot populate the issuer and
signature-value fields of certificates it issues with values matching
the subject name and public key from its own cert.

Enforcing name chaining during path construction does not cause
problems; it highlights existing problems.  When a system continues
to function in an environment with errors over which it has no control
(transmission bit errors, for example), it is called "robust".  But
when a system continues to function normally in the face of correctable
errors without providing any indication of a problem, "oblivious" is a
better term than "robust".  Like fixing an engine problem by removing
the offending indicator lamp from the dashboard.

I agree that ignoring name chaining errors during path construction
or validation does not cause a "security" problem, using a sufficiently
limited definition of security.  But the real security of a system
depends on (among other things) correct administration, and anything
which promotes sloppy administration promotes sloppy security.
I therefore disagree that applications should ignore the path
validation requirements of X.509:

  "a) Check that the signature verifies, that dates are valid, that
      the certificate subject and certificate issuer names chain
      correctly, and that the certificate has not been revoked."

This name chaining requirement wasn't inserted willy-nilly into RFC
2459, it has been a fundamental part of an International Standard for
twelve years. Saying "we don't like this requirement, so we are going
to ignore it" is undoubtedly an option for a company with the market
cap of MSFT.  But customers for whom standards conformance is a
checklist item should be fully informed that you have chosen not
to conform to either X.509 or RFC 2459.

Dave

> From: "Trevor Freeman" <[email-masked]>
>
> Hi Denis,
> We have found that enforcing name chaining in path construction, causes
> more problems than it solves. We therefore have reverted to using the
> name as just a hint, rather than a critical factor and will as you have
> found, use a certificate signed with the right key as a valid parent in
> that chain. This applies to intermediate as well as self signed
> certificates. We have seen customer scenarios where you need to
> deliberately build certificates which don't chain on names so enforcing
> name chaining would cause problems.

Content-Class: urn:content-classes:message
Subject: RE: Correct approach to certificate validation?
Date: Tue, 6 Jun 2000 19:42:06 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD029.F8666240
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We use AKI, but don't require it, as the field can be calculated on the
fly so to speak.
I am not linking the enforcement of name constrains with the enforcement
of name chaining in any. We will enforce name constraints as this is a
security issue, we don't enforce name chaining.=20
We trust the CA because we have built a chain of certificate to a
trusted root, with valid policy and name constraints.

 -----Original Message-----
From: 	Denis Pinkas [mailto:[email-masked]]=20
Sent:	Tuesday, June 06, 2000 1:33 AM
To:	Trevor Freeman
Cc:	[email-masked]; [email-masked]
Subject:	Re: Correct approach to certificate validation?

> Hi Denis,

Now there are two Denis on the list. Don't be confused, the one
above is not me ! :-)

It seems that we are starting a very interesting threat.

> We have found that enforcing name chaining in path construction,
> causes more problems than it solves. We therefore have reverted to
> using the name as just a hint, rather than a critical factor and
> will as you have found, use a certificate signed with the right
> key as a valid parent in that chain.=20

To be more precise, do you mean that you are using the authority key
identifier extension ?

This extension provides a means of identifying the public key
corresponding to the private key used to sign a certificate. The
keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to
facilitate chain building.=20

If this is what you use, this means that you use a field that must
be present but does not need to be understood, since this extension
is marked NON critical. If your implementation relies on that field,
which options of that field are you using (since this is a sequence
of three optional fields) ? If I misunderstood what you are using,
please clarify.

> This applies to intermediate
> as well as self signed certificates. We have seen customer
> scenarios where you need to deliberately build certificates which
> don't chain on names so enforcing name chaining would cause
> problems.

It is true that enforcing name constraints within certificates
themselves provides limitations and causes problems. Enforcing name
chaining outside the certificates is much morer flexible ... and
should be recognized as a valid additional check in the
"son-of-RFC2459".=20

> I know this is at odds with RFC2459, but as this behaviour does
> not in our view cause a security problem, but does make the
> overall process more robust, we have and will continue to opt for
> the more robust solution.

It seems to early at this stage to conclude that there are no
security problems with such an approach (there are not enough
information at this stage to make any conclusion). Just a remainder.
The basic principle is the following: it is not because a CA
certificate exists that it should be trusted.=20

Denis
=20
> I have also posted previously on the list that mandating name
> chaining, in addition to signatures and policy chaining is a bad
> idea.
>=20
> Trevor
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, June 04, 2000 11:19 AM
> To: [email-masked]
> Subject: Correct approach to certificate validation?
>=20
> Now, based on my previous message, my question for this workgroup:
>=20
> Which of these approaches is correct?
>   - the approach of IE5 and Outlook, which, if an Authority Key
> Identifier
> extension is present, does not perform a comparison of the
> issuer-DN in the
> subject-cert to the subject-DN of the root-cert?
>   - or the approach of Netscape and IIS4, which, even if an
> Authority Key
> Identifier extension is present, DOES still perform a comparison
> of the
> subject-cert-issuer-DN to the root-cert-subject-DN?
>=20
> Regards,
>=20
> denis bider
>=20
> PS. I would like to thank Ace Swerling from Microsoft Consulting
> Services
> for the fact that he bothered to look into my problem, and
> especially to
> Peter Williams from Valicert who devoted much of his time to help
> me solve
> this issue. I appreciate your feedback very much.
>=20
>  -----Original Message-----
> From:   denis bider [mailto:[email-masked]]  On Behalf Of
> [email-masked]
> Sent:   Sunday, June 04, 2000 20:08
> To:     [email-masked]'
> Subject:        Report - certificate validation in IE5, Outlook,
> IIS4, Netscape
> 4.72
>=20
> Hello,
>=20
> a while ago I sent to this list an enquiry regarding Microsoft's
> certificate
> validation code in IIS4. I have now resolved the problem that was
> the reason
> for my enquiry. Since the solution to the problem produced some
> interesting
> insight into how certificate chains are handled in IE5 and Outlook
> / IIS4
> and Netscape, and since the behavior in question should be covered
> by
> RFC2459, but does not seem to be, I am forwarding my findings to
> you.
>=20
> I produced my own certificate generating utility, the intention of
> which was
> to generate certificates which could be used by IE5 to login into
> an
> SSL-protected web site running on IIS4. My problem was that,
> although IE5
> claimed my root-cert/subject-cert certificate chain to be valid,
> and
> although Outlook properly signed and verified messages signed by
> these
> certificates, IIS4 rejected all attempts to use the subject
> certificate for
> SSL client authentication. Also, when the subject certificate was
> imported
> into Netscape, Netscape didn't even show it as an elligible choice
> for SSL
> client authentication.
>=20
> To sum it up, the problem was that there was a glitch in my code
> that caused
> the subject-DN in root-cert to be slightly different from the
> issuer-DN in
> the subject-cert. It seems that the certificate verification code
> in IE5 and
> Outlook2000 is somewhat easy-going, since both of these products
> validated
> the pair of certificates as valid (they performed cert-chain
> validation
> solely on the grounds of the key identifier in the Authority Key
> Identifier
> extension, they did not compare the sub-cert-issuerDN to the
> root-cert-subjectDN). IIS4 and Netscape Communicator, on the other
> hand,
> seem to have a more stringent policy, since they both rejected
> these
> certificates.
>=20
> denis bider

------_=_NextPart_001_01BFD029.F8666240
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 =
6.0.4384.0">
<TITLE>RE: Correct approach to certificate validation?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>We use AKI, but don't require it, as the field can be =
calculated on the fly so to speak.<BR>
I am not linking the enforcement of name constrains with the enforcement =
of name chaining in any. We will enforce name constraints as this is a =
security issue, we don't enforce name chaining.<BR>
We trust the CA because we have built a chain of certificate to a =
trusted root, with valid policy and name constraints.<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Denis Pinkas [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
Sent:&nbsp;&nbsp; Tuesday, June 06, 2000 1:33 AM<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Trevor Freeman<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: Correct approach =
to certificate validation?<BR>
<BR>
&gt; Hi Denis,<BR>
<BR>
Now there are two Denis on the list. Don't be confused, the one<BR>
above is not me ! :-)<BR>
<BR>
It seems that we are starting a very interesting threat.<BR>
<BR>
&gt; We have found that enforcing name chaining in path =
construction,<BR>
&gt; causes more problems than it solves. We therefore have reverted =
to<BR>
&gt; using the name as just a hint, rather than a critical factor =
and<BR>
&gt; will as you have found, use a certificate signed with the right<BR>
&gt; key as a valid parent in that chain.<BR>
<BR>
To be more precise, do you mean that you are using the authority key<BR>
identifier extension ?<BR>
<BR>
This extension provides a means of identifying the public key<BR>
corresponding to the private key used to sign a certificate. The<BR>
keyIdentifier field of the authorityKeyIdentifier extension MUST be<BR>
included in all certificates generated by conforming CAs to<BR>
facilitate chain building.<BR>
<BR>
If this is what you use, this means that you use a field that must<BR>
be present but does not need to be understood, since this extension<BR>
is marked NON critical. If your implementation relies on that field,<BR>
which options of that field are you using (since this is a sequence<BR>
of three optional fields) ? If I misunderstood what you are using,<BR>
please clarify.<BR>
<BR>
&gt; This applies to intermediate<BR>
&gt; as well as self signed certificates. We have seen customer<BR>
&gt; scenarios where you need to deliberately build certificates =
which<BR>
&gt; don't chain on names so enforcing name chaining would cause<BR>
&gt; problems.<BR>
<BR>
It is true that enforcing name constraints within certificates<BR>
themselves provides limitations and causes problems. Enforcing name<BR>
chaining outside the certificates is much morer flexible ... and<BR>
should be recognized as a valid additional check in the<BR>
&quot;son-of-RFC2459&quot;.<BR>
<BR>
&gt; I know this is at odds with RFC2459, but as this behaviour does<BR>
&gt; not in our view cause a security problem, but does make the<BR>
&gt; overall process more robust, we have and will continue to opt =
for<BR>
&gt; the more robust solution.<BR>
<BR>
It seems to early at this stage to conclude that there are no<BR>
security problems with such an approach (there are not enough<BR>
information at this stage to make any conclusion). Just a remainder.<BR>
The basic principle is the following: it is not because a CA<BR>
certificate exists that it should be trusted.<BR>
<BR>
Denis<BR>
<BR>
&gt; I have also posted previously on the list that mandating name<BR>
&gt; chaining, in addition to signatures and policy chaining is a =
bad<BR>
&gt; idea.<BR>
&gt;<BR>
&gt; Trevor<BR>
&gt;<BR>
&gt; -----Original Message-----<BR>
&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>=

&gt; Sent: Sunday, June 04, 2000 11:19 AM<BR>
&gt; To: [email-masked]<BR>
&gt; Subject: Correct approach to certificate validation?<BR>
&gt;<BR>
&gt; Now, based on my previous message, my question for this =
workgroup:<BR>
&gt;<BR>
&gt; Which of these approaches is correct?<BR>
&gt;&nbsp;&nbsp; - the approach of IE5 and Outlook, which, if an =
Authority Key<BR>
&gt; Identifier<BR>
&gt; extension is present, does not perform a comparison of the<BR>
&gt; issuer-DN in the<BR>
&gt; subject-cert to the subject-DN of the root-cert?<BR>
&gt;&nbsp;&nbsp; - or the approach of Netscape and IIS4, which, even if =
an<BR>
&gt; Authority Key<BR>
&gt; Identifier extension is present, DOES still perform a =
comparison<BR>
&gt; of the<BR>
&gt; subject-cert-issuer-DN to the root-cert-subject-DN?<BR>
&gt;<BR>
&gt; Regards,<BR>
&gt;<BR>
&gt; denis bider<BR>
&gt;<BR>
&gt; PS. I would like to thank Ace Swerling from Microsoft =
Consulting<BR>
&gt; Services<BR>
&gt; for the fact that he bothered to look into my problem, and<BR>
&gt; especially to<BR>
&gt; Peter Williams from Valicert who devoted much of his time to =
help<BR>
&gt; me solve<BR>
&gt; this issue. I appreciate your feedback very much.<BR>
&gt;<BR>
&gt;&nbsp; -----Original Message-----<BR>
&gt; From:&nbsp;&nbsp; denis bider [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]&nbs=
p; On Behalf Of<BR>
&gt; [email-masked]<BR>
&gt; Sent:&nbsp;&nbsp; Sunday, June 04, 2000 20:08<BR>
&gt; To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]'<BR>
&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Report - =
certificate validation in IE5, Outlook,<BR>
&gt; IIS4, Netscape<BR>
&gt; 4.72<BR>
&gt;<BR>
&gt; Hello,<BR>
&gt;<BR>
&gt; a while ago I sent to this list an enquiry regarding =
Microsoft's<BR>
&gt; certificate<BR>
&gt; validation code in IIS4. I have now resolved the problem that =
was<BR>
&gt; the reason<BR>
&gt; for my enquiry. Since the solution to the problem produced some<BR>
&gt; interesting<BR>
&gt; insight into how certificate chains are handled in IE5 and =
Outlook<BR>
&gt; / IIS4<BR>
&gt; and Netscape, and since the behavior in question should be =
covered<BR>
&gt; by<BR>
&gt; RFC2459, but does not seem to be, I am forwarding my findings =
to<BR>
&gt; you.<BR>
&gt;<BR>
&gt; I produced my own certificate generating utility, the intention =
of<BR>
&gt; which was<BR>
&gt; to generate certificates which could be used by IE5 to login =
into<BR>
&gt; an<BR>
&gt; SSL-protected web site running on IIS4. My problem was that,<BR>
&gt; although IE5<BR>
&gt; claimed my root-cert/subject-cert certificate chain to be =
valid,<BR>
&gt; and<BR>
&gt; although Outlook properly signed and verified messages signed =
by<BR>
&gt; these<BR>
&gt; certificates, IIS4 rejected all attempts to use the subject<BR>
&gt; certificate for<BR>
&gt; SSL client authentication. Also, when the subject certificate =
was<BR>
&gt; imported<BR>
&gt; into Netscape, Netscape didn't even show it as an elligible =
choice<BR>
&gt; for SSL<BR>
&gt; client authentication.<BR>
&gt;<BR>
&gt; To sum it up, the problem was that there was a glitch in my =
code<BR>
&gt; that caused<BR>
&gt; the subject-DN in root-cert to be slightly different from the<BR>
&gt; issuer-DN in<BR>
&gt; the subject-cert. It seems that the certificate verification =
code<BR>
&gt; in IE5 and<BR>
&gt; Outlook2000 is somewhat easy-going, since both of these =
products<BR>
&gt; validated<BR>
&gt; the pair of certificates as valid (they performed cert-chain<BR>
&gt; validation<BR>
&gt; solely on the grounds of the key identifier in the Authority =
Key<BR>
&gt; Identifier<BR>
&gt; extension, they did not compare the sub-cert-issuerDN to the<BR>
&gt; root-cert-subjectDN). IIS4 and Netscape Communicator, on the =
other<BR>
&gt; hand,<BR>
&gt; seem to have a more stringent policy, since they both rejected<BR>
&gt; these<BR>
&gt; certificates.<BR>
&gt;<BR>
&gt; denis bider<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD029.F8666240--

Content-Class: urn:content-classes:message
Subject: RE: Correct approach to certificate validation?
Date: Tue, 6 Jun 2000 20:00:24 -0700
From: "Trevor Freeman" <[email-masked]>
To: "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD02C.86E28F9E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi David,
I am afraid I don't see it necessary to eradicate every little
imperfection because it is there. To err is human, and people make
mistakes. People also have a wide list of requires which you may or may
not agree with, but it does not mean that it is less real to them.=20
So I don't see this as an error, simple a different point of view, and
we will obviously disagree on this point.
At the end of the day it is up to any product vendor to make the call as
to what is\is not in their product, regardless what is in the standard.
It is up to the market place to decide. History certainly tells us that
customers like robustness in a product.
If you can cite a specific issue, then we will obviously reconsider, but
I don't find punishing minor infractions of administrators a compelling
case.
Trevor

 -----Original Message-----
From: 	David P. Kemp [mailto:[email-masked]]=20
Sent:	Tuesday, June 06, 2000 11:20 AM
To:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

Could you describe a customer scenario which requires deliberate
non-chaining of names?  I can't envision any circumstance where a
CA 1) does not have a certificate containing the CA's signing key
and a subject name for the CA, or 2) cannot populate the issuer and
signature-value fields of certificates it issues with values matching
the subject name and public key from its own cert.

Enforcing name chaining during path construction does not cause
problems; it highlights existing problems.  When a system continues
to function in an environment with errors over which it has no control
(transmission bit errors, for example), it is called "robust".  But
when a system continues to function normally in the face of correctable
errors without providing any indication of a problem, "oblivious" is a
better term than "robust".  Like fixing an engine problem by removing
the offending indicator lamp from the dashboard.

I agree that ignoring name chaining errors during path construction
or validation does not cause a "security" problem, using a sufficiently
limited definition of security.  But the real security of a system
depends on (among other things) correct administration, and anything
which promotes sloppy administration promotes sloppy security.
I therefore disagree that applications should ignore the path
validation requirements of X.509:

  "a) Check that the signature verifies, that dates are valid, that
      the certificate subject and certificate issuer names chain
      correctly, and that the certificate has not been revoked."

This name chaining requirement wasn't inserted willy-nilly into RFC
2459, it has been a fundamental part of an International Standard for
twelve years. Saying "we don't like this requirement, so we are going
to ignore it" is undoubtedly an option for a company with the market
cap of MSFT.  But customers for whom standards conformance is a
checklist item should be fully informed that you have chosen not
to conform to either X.509 or RFC 2459.

Dave

> From: "Trevor Freeman" <[email-masked]>
>=20
> Hi Denis,=20
> We have found that enforcing name chaining in path construction,
causes
> more problems than it solves. We therefore have reverted to using the
> name as just a hint, rather than a critical factor and will as you
have
> found, use a certificate signed with the right key as a valid parent
in
> that chain. This applies to intermediate as well as self signed
> certificates. We have seen customer scenarios where you need to
> deliberately build certificates which don't chain on names so
enforcing
> name chaining would cause problems.

------_=_NextPart_001_01BFD02C.86E28F9E
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 =
6.0.4384.0">
<TITLE>RE: Correct approach to certificate validation?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi David,<BR>
I am afraid I don't see it necessary to eradicate every little =
imperfection because it is there. To err is human, and people make =
mistakes. People also have a wide list of requires which you may or may =
not agree with, but it does not mean that it is less real to them.<BR>
So I don't see this as an error, simple a different point of view, and =
we will obviously disagree on this point.<BR>
At the end of the day it is up to any product vendor to make the call as =
to what is\is not in their product, regardless what is in the standard. =
It is up to the market place to decide. History certainly tells us that =
customers like robustness in a product.<BR>
If you can cite a specific issue, then we will obviously reconsider, but =
I don't find punishing minor infractions of administrators a compelling =
case.<BR>
Trevor<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; David P. Kemp [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
Sent:&nbsp;&nbsp; Tuesday, June 06, 2000 11:20 AM<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Correct approach =
to certificate validation?<BR>
<BR>
Trevor,<BR>
<BR>
Could you describe a customer scenario which requires deliberate<BR>
non-chaining of names?&nbsp; I can't envision any circumstance where =
a<BR>
CA 1) does not have a certificate containing the CA's signing key<BR>
and a subject name for the CA, or 2) cannot populate the issuer and<BR>
signature-value fields of certificates it issues with values =
matching<BR>
the subject name and public key from its own cert.<BR>
<BR>
Enforcing name chaining during path construction does not cause<BR>
problems; it highlights existing problems.&nbsp; When a system =
continues<BR>
to function in an environment with errors over which it has no =
control<BR>
(transmission bit errors, for example), it is called =
&quot;robust&quot;.&nbsp; But<BR>
when a system continues to function normally in the face of =
correctable<BR>
errors without providing any indication of a problem, =
&quot;oblivious&quot; is a<BR>
better term than &quot;robust&quot;.&nbsp; Like fixing an engine problem =
by removing<BR>
the offending indicator lamp from the dashboard.<BR>
<BR>
I agree that ignoring name chaining errors during path construction<BR>
or validation does not cause a &quot;security&quot; problem, using a =
sufficiently<BR>
limited definition of security.&nbsp; But the real security of a =
system<BR>
depends on (among other things) correct administration, and anything<BR>
which promotes sloppy administration promotes sloppy security.<BR>
I therefore disagree that applications should ignore the path<BR>
validation requirements of X.509:<BR>
<BR>
&nbsp; &quot;a) Check that the signature verifies, that dates are valid, =
that<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the certificate subject and certificate =
issuer names chain<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; correctly, and that the certificate has =
not been revoked.&quot;<BR>
<BR>
This name chaining requirement wasn't inserted willy-nilly into RFC<BR>
2459, it has been a fundamental part of an International Standard =
for<BR>
twelve years. Saying &quot;we don't like this requirement, so we are =
going<BR>
to ignore it&quot; is undoubtedly an option for a company with the =
market<BR>
cap of MSFT.&nbsp; But customers for whom standards conformance is a<BR>
checklist item should be fully informed that you have chosen not<BR>
to conform to either X.509 or RFC 2459.<BR>
<BR>
Dave<BR>
<BR>
<BR>
<BR>
&gt; From: &quot;Trevor Freeman&quot; =
&lt;[email-masked]&gt;<BR>
&gt;<BR>
&gt; Hi Denis,<BR>
&gt; We have found that enforcing name chaining in path construction, =
causes<BR>
&gt; more problems than it solves. We therefore have reverted to using =
the<BR>
&gt; name as just a hint, rather than a critical factor and will as you =
have<BR>
&gt; found, use a certificate signed with the right key as a valid =
parent in<BR>
&gt; that chain. This applies to intermediate as well as self signed<BR>
&gt; certificates. We have seen customer scenarios where you need to<BR>
&gt; deliberately build certificates which don't chain on names so =
enforcing<BR>
&gt; name chaining would cause problems.<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD02C.86E28F9E--

Date: Tue, 6 Jun 2000 14:19:35 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Correct approach to certificate validation?
To: [email-masked]
Content-MD5: 0LuwLJjq80ZHj0Whgd4ZSQ==

Trevor,

Could you describe a customer scenario which requires deliberate
non-chaining of names?  I can't envision any circumstance where a
CA 1) does not have a certificate containing the CA's signing key
and a subject name for the CA, or 2) cannot populate the issuer and
signature-value fields of certificates it issues with values matching
the subject name and public key from its own cert.

Enforcing name chaining during path construction does not cause
problems; it highlights existing problems.  When a system continues
to function in an environment with errors over which it has no control
(transmission bit errors, for example), it is called "robust".  But
when a system continues to function normally in the face of correctable
errors without providing any indication of a problem, "oblivious" is a
better term than "robust".  Like fixing an engine problem by removing
the offending indicator lamp from the dashboard.

I agree that ignoring name chaining errors during path construction
or validation does not cause a "security" problem, using a sufficiently
limited definition of security.  But the real security of a system
depends on (among other things) correct administration, and anything
which promotes sloppy administration promotes sloppy security.
I therefore disagree that applications should ignore the path
validation requirements of X.509:

  "a) Check that the signature verifies, that dates are valid, that
      the certificate subject and certificate issuer names chain
      correctly, and that the certificate has not been revoked."

This name chaining requirement wasn't inserted willy-nilly into RFC
2459, it has been a fundamental part of an International Standard for
twelve years. Saying "we don't like this requirement, so we are going
to ignore it" is undoubtedly an option for a company with the market
cap of MSFT.  But customers for whom standards conformance is a
checklist item should be fully informed that you have chosen not
to conform to either X.509 or RFC 2459.

Dave

> From: "Trevor Freeman" <[email-masked]>
> 
> Hi Denis, 
> We have found that enforcing name chaining in path construction, causes
> more problems than it solves. We therefore have reverted to using the
> name as just a hint, rather than a critical factor and will as you have
> found, use a certificate signed with the right key as a valid parent in
> that chain. This applies to intermediate as well as self signed
> certificates. We have seen customer scenarios where you need to
> deliberately build certificates which don't chain on names so enforcing
> name chaining would cause problems.

From: Carlisle Adams <[email-masked]>
To: "'Alan Shepherd'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithm s to Proposed Standard
Date: Tue, 6 Jun 2000 10:14:11 -0400 

Hi Alan,

I make no claim to be "someone wiser", but I will point out that
proof-of-possession threads have been both long and numerous on this list in
the past.

The basic principle is that POP is not primarily done to avoid security
problems.  A basic underlying assumption in any certificate-using
environment is that the entity bound to the certificate actually holds the
corresponding private key.  POP ensures that this assumption is valid (at
least at the time of certificate creation).  If I can't assume that you hold
the private key, why in the world would I use your certificate?  If I have
no fundamental reason to use your certificate, why does the certificate
(and, through generalization, the PKI) exist?

POP is done by a CA (or occasionally as part of an operational protocol
between parties) to try and ensure that certificates have some meaning and
value and are not just worthless strings of bits.  If a particular security
problem can be avoided in some cases by doing POP, that's just a useful side
benefit.

Carlisle.

> ----------
> From: 	Alan Shepherd[SMTP:[email-masked]]
> Sent: 	Monday, June 05, 2000 11:58 AM
> To: 	[email-masked]'
> Subject: 	RE: Protocol Action: Diffie-Hellman Proof-of-Possession
> Algorithm s to Proposed Standard
> 
> Please forgive me if this is a terribly naive question, but I would like
> to
> know what problems arise if a public key is certified erroneously.  I can
> not see what security problems arise through this and would very much
> appreciate someone wiser explaining it!
> 
> Thanks for you help.
> 
> Alan
> 
> 
> > -----Original Message-----
> > From: The IESG [mailto:[email-masked]]
> > Sent: 31 May 2000 14:03
> > Cc: RFC Editor; RFC Editor; RFC Editor
> > Subject: Protocol Action: Diffie-Hellman Proof-of-Possession 
> > Algorithms
> > to Proposed Standard
> > 
> > 
> > 
> > 
> > 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.
> > 
> 
> --------------------------------------------------------------------------
> ----------------
> This message is for the named person's use only.  It may contain
> confidential, proprietary or legally privileged information.  No
> confidentiality or privilege is waived or lost by any mistransmission.  If
> you receive this message in error, please immediately delete it and all
> copies of it from your system, destroy any hard copies of it and notify
> the sender.  You must not, directly or indirectly, use, disclose,
> distribute, print, or copy any part of this message if you are not the
> intended recipient. PROTEK Network Management Group and each of its
> subsidiaries reserve the right to monitor all e-mail communications
> through its networks.  Any views expressed in this message are those of
> the individual sender, except where the message states otherwise and the
> sender is authorised to state them to be the views of any such entity.
> 
> 
> 
> 

From: AFlyak <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Subscribe
Date: Tue, 6 Jun 2000 08:55:32 -0400 

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

------_=_NextPart_001_01BFCFB6.82FC6A80
Content-Type: text/plain

------_=_NextPart_001_01BFCFB6.82FC6A80
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>Subscribe</TITLE>
</HEAD>
<BODY>

</BODY>
</HTML>
------_=_NextPart_001_01BFCFB6.82FC6A80--

Date: Tue, 06 Jun 2000 18:20:42 +0900
From: TAKIGUCHI Naruhito <[email-masked]>
To: [email-masked]
Subject: certificate policies extension in RFC2459 and son of RFC2459

Hi, all.

It seems to me that there is an inconsistency between RFC2459 and 
son of RFC2459 about verifying the certificate policies extension.

In RFC2459, if the certificate policies extension is marked as 
non-critical, it is not processed. 
But in son of RFC2459, the certificate policies extension is 
processed regardless of its critical flag.

For example, consider there is a certificate path such below, 
and the acceptable policy set is (A). In RFC2459, this path's validation
processing will succeed. But in son of RFC2459, this path's validation
processing will be failed.

    +------------------------+
    | root CA cert           |
    |                        |
    | critical policy(A)     |
    +------------------------+
                |
    +------------------------+
    | end entity cert        |
    |                        |
    | non-critical policy(B) |
    +------------------------+

And, son of RFC2459 requires that certificate must have a certificate
policies extension?

Thus, son of RFC2459 doesn't have compatibility with a certificate
which was issued based on RFC2459?
Do I misunderstand?

Could anyone advice me?

Thanks in advance.

-----
Naruhito TAKIGUCHI
FUJITSU HOKURIKU SYSTEMS LTD.

Date: Tue, 06 Jun 2000 10:33:14 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Trevor Freeman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Correct approach to certificate validation?

> Hi Denis,

Now there are two Denis on the list. Don't be confused, the one
above is not me ! :-)

It seems that we are starting a very interesting threat.

> We have found that enforcing name chaining in path construction,
> causes more problems than it solves. We therefore have reverted to
> using the name as just a hint, rather than a critical factor and
> will as you have found, use a certificate signed with the right
> key as a valid parent in that chain. 

To be more precise, do you mean that you are using the authority key
identifier extension ?

This extension provides a means of identifying the public key
corresponding to the private key used to sign a certificate. The
keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to
facilitate chain building. 

If this is what you use, this means that you use a field that must
be present but does not need to be understood, since this extension
is marked NON critical. If your implementation relies on that field,
which options of that field are you using (since this is a sequence
of three optional fields) ? If I misunderstood what you are using,
please clarify.

> This applies to intermediate
> as well as self signed certificates. We have seen customer
> scenarios where you need to deliberately build certificates which
> don't chain on names so enforcing name chaining would cause
> problems.

It is true that enforcing name constraints within certificates
themselves provides limitations and causes problems. Enforcing name
chaining outside the certificates is much morer flexible ... and
should be recognized as a valid additional check in the
"son-of-RFC2459". 

> I know this is at odds with RFC2459, but as this behaviour does
> not in our view cause a security problem, but does make the
> overall process more robust, we have and will continue to opt for
> the more robust solution.

It seems to early at this stage to conclude that there are no
security problems with such an approach (there are not enough
information at this stage to make any conclusion). Just a remainder.
The basic principle is the following: it is not because a CA
certificate exists that it should be trusted. 

Denis
 
> I have also posted previously on the list that mandating name
> chaining, in addition to signatures and policy chaining is a bad
> idea.
> 
> Trevor
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, June 04, 2000 11:19 AM
> To: [email-masked]
> Subject: Correct approach to certificate validation?
> 
> Now, based on my previous message, my question for this workgroup:
> 
> Which of these approaches is correct?
>   - the approach of IE5 and Outlook, which, if an Authority Key
> Identifier
> extension is present, does not perform a comparison of the
> issuer-DN in the
> subject-cert to the subject-DN of the root-cert?
>   - or the approach of Netscape and IIS4, which, even if an
> Authority Key
> Identifier extension is present, DOES still perform a comparison
> of the
> subject-cert-issuer-DN to the root-cert-subject-DN?
> 
> Regards,
> 
> denis bider
> 
> PS. I would like to thank Ace Swerling from Microsoft Consulting
> Services
> for the fact that he bothered to look into my problem, and
> especially to
> Peter Williams from Valicert who devoted much of his time to help
> me solve
> this issue. I appreciate your feedback very much.
> 
>  -----Original Message-----
> From:   denis bider [mailto:[email-masked]]  On Behalf Of
> [email-masked]
> Sent:   Sunday, June 04, 2000 20:08
> To:     [email-masked]'
> Subject:        Report - certificate validation in IE5, Outlook,
> IIS4, Netscape
> 4.72
> 
> Hello,
> 
> a while ago I sent to this list an enquiry regarding Microsoft's
> certificate
> validation code in IIS4. I have now resolved the problem that was
> the reason
> for my enquiry. Since the solution to the problem produced some
> interesting
> insight into how certificate chains are handled in IE5 and Outlook
> / IIS4
> and Netscape, and since the behavior in question should be covered
> by
> RFC2459, but does not seem to be, I am forwarding my findings to
> you.
> 
> I produced my own certificate generating utility, the intention of
> which was
> to generate certificates which could be used by IE5 to login into
> an
> SSL-protected web site running on IIS4. My problem was that,
> although IE5
> claimed my root-cert/subject-cert certificate chain to be valid,
> and
> although Outlook properly signed and verified messages signed by
> these
> certificates, IIS4 rejected all attempts to use the subject
> certificate for
> SSL client authentication. Also, when the subject certificate was
> imported
> into Netscape, Netscape didn't even show it as an elligible choice
> for SSL
> client authentication.
> 
> To sum it up, the problem was that there was a glitch in my code
> that caused
> the subject-DN in root-cert to be slightly different from the
> issuer-DN in
> the subject-cert. It seems that the certificate verification code
> in IE5 and
> Outlook2000 is somewhat easy-going, since both of these products
> validated
> the pair of certificates as valid (they performed cert-chain
> validation
> solely on the grounds of the key identifier in the Authority Key
> Identifier
> extension, they did not compare the sub-cert-issuerDN to the
> root-cert-subjectDN). IIS4 and Netscape Communicator, on the other
> hand,
> seem to have a more stringent policy, since they both rejected
> these
> certificates.
> 
> denis bider

From: [email-masked]
To: "Trevor Freeman" <[email-masked]>
cc: [email-masked], [email-masked]
Date: Tue, 6 Jun 2000 09:11:21 +0300
Subject: RE: Correct approach to certificate validation?

Trevor says,

> We have found that enforcing name chaining in path construction, causes
> more problems than it solves. We therefore have reverted to using the
> name as just a hint, rather than a critical factor and will as you have
<skip>
> I know this is at odds with RFC2459, but as this behaviour does not in
> our view cause a security problem, but does make the overall process
> more robust, we have and will continue to opt for the more robust

I agree. Names are just one of the potential attributes for the holder of
the secret key certified; they should not be used for chaining decisions.
Also the use of names for access control is dangerous, as the policy makers
may not realize that the names are not necessarily secure and they must
depend on the proper chain of trust.

Best, Amir Herzberg

Date: Mon, 05 Jun 2000 20:25:38 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: TSA Response serialNumber Field
To: Denis Pinkas <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Denis Pinkas wrote:

> I propose that we all look back
> at the definition we have in the current document.
>
> " By adding the XXXX value to the GeneralizedTime, an upper limit of
> the time at which the timestamp has been created by the TSA can be
> obtained. In the same way, by subtracting the XXXX to the
> GeneralizedTime, a lower limit of the time at which the timestamp
> has been created by the TSA can be obtained."
>
> The single remaining question is how do you call XXXX, while
> sticking to THIS definition. It is currently called "accuracy". If
> this term is not adequate, please make a proposal. I would like to
> close this issue soon.
>

Dennis:

The question is not so much what it is called (even though it would be
nice to use an already accepted name for it) but that THIS definition is
broken.  Pls see the former emails.  So, one should not stick to THIS
definition.

Cheers,

Ed Gerck

Content-Class: urn:content-classes:message
Subject: RE: Correct approach to certificate validation?
Date: Mon, 5 Jun 2000 19:06:58 -0700
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFCF5B.E53BE647
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Denis,
We have found that enforcing name chaining in path construction, causes
more problems than it solves. We therefore have reverted to using the
name as just a hint, rather than a critical factor and will as you have
found, use a certificate signed with the right key as a valid parent in
that chain. This applies to intermediate as well as self signed
certificates. We have seen customer scenarios where you need to
deliberately build certificates which don't chain on names so enforcing
name chaining would cause problems.=20
I know this is at odds with RFC2459, but as this behaviour does not in
our view cause a security problem, but does make the overall process
more robust, we have and will continue to opt for the more robust
solution.=20
I have also posted previously on the list that mandating name chaining,
in addition to signatures and policy chaining is a bad idea.
Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, June 04, 2000 11:19 AM
To: [email-masked]
Subject: Correct approach to certificate validation?

Now, based on my previous message, my question for this workgroup:

Which of these approaches is correct?
  - the approach of IE5 and Outlook, which, if an Authority Key
Identifier
extension is present, does not perform a comparison of the issuer-DN in
the
subject-cert to the subject-DN of the root-cert?
  - or the approach of Netscape and IIS4, which, even if an Authority
Key
Identifier extension is present, DOES still perform a comparison of the
subject-cert-issuer-DN to the root-cert-subject-DN?

Regards,

denis bider

PS. I would like to thank Ace Swerling from Microsoft Consulting
Services
for the fact that he bothered to look into my problem, and especially to
Peter Williams from Valicert who devoted much of his time to help me
solve
this issue. I appreciate your feedback very much.

 -----Original Message-----
From: 	denis bider [mailto:[email-masked]]  On Behalf Of
[email-masked]
Sent:	Sunday, June 04, 2000 20:08
To:	[email-masked]'
Subject:	Report - certificate validation in IE5, Outlook, IIS4,
Netscape
4.72

Hello,

a while ago I sent to this list an enquiry regarding Microsoft's
certificate
validation code in IIS4. I have now resolved the problem that was the
reason
for my enquiry. Since the solution to the problem produced some
interesting
insight into how certificate chains are handled in IE5 and Outlook /
IIS4
and Netscape, and since the behavior in question should be covered by
RFC2459, but does not seem to be, I am forwarding my findings to you.

I produced my own certificate generating utility, the intention of which
was
to generate certificates which could be used by IE5 to login into an
SSL-protected web site running on IIS4. My problem was that, although
IE5
claimed my root-cert/subject-cert certificate chain to be valid, and
although Outlook properly signed and verified messages signed by these
certificates, IIS4 rejected all attempts to use the subject certificate
for
SSL client authentication. Also, when the subject certificate was
imported
into Netscape, Netscape didn't even show it as an elligible choice for
SSL
client authentication.

To sum it up, the problem was that there was a glitch in my code that
caused
the subject-DN in root-cert to be slightly different from the issuer-DN
in
the subject-cert. It seems that the certificate verification code in IE5
and
Outlook2000 is somewhat easy-going, since both of these products
validated
the pair of certificates as valid (they performed cert-chain validation
solely on the grounds of the key identifier in the Authority Key
Identifier
extension, they did not compare the sub-cert-issuerDN to the
root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand,
seem to have a more stringent policy, since they both rejected these
certificates.

denis bider

------_=_NextPart_001_01BFCF5B.E53BE647
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 =
6.0.4384.0">
<TITLE>RE: Correct approach to certificate validation?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi Denis,</FONT>

<BR><FONT SIZE=3D2>We have found that enforcing name chaining in path =
construction, causes more problems than it solves. We therefore have =
reverted to using the name as just a hint, rather than a critical factor =
and will as you have found, use a certificate signed with the right key =
as a valid parent in that chain. This applies to intermediate as well as =
self signed certificates. We have seen customer scenarios where you need =
to deliberately build certificates which don't chain on names so =
enforcing name chaining would cause problems. </FONT></P>

<P><FONT SIZE=3D2>I know this is at odds with RFC2459, but as this =
behaviour does not in our view cause a security problem, but does make =
the overall process more robust, we have and will continue to opt for =
the more robust solution. </FONT></P>

<P><FONT SIZE=3D2>I have also posted previously on the list that =
mandating name chaining, in addition to signatures and policy chaining =
is a bad idea.</FONT></P>

<P><FONT SIZE=3D2>Trevor</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FO=
NT>

<BR><FONT SIZE=3D2>Sent: Sunday, June 04, 2000 11:19 AM</FONT>

<BR><FONT SIZE=3D2>To: [email-masked]</FONT>

<BR><FONT SIZE=3D2>Subject: Correct approach to certificate =
validation?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Now, based on my previous message, my question for =
this workgroup:</FONT>
</P>

<P><FONT SIZE=3D2>Which of these approaches is correct?</FONT>

<BR><FONT SIZE=3D2>&nbsp; - the approach of IE5 and Outlook, which, if =
an Authority Key Identifier</FONT>

<BR><FONT SIZE=3D2>extension is present, does not perform a comparison =
of the issuer-DN in the</FONT>

<BR><FONT SIZE=3D2>subject-cert to the subject-DN of the =
root-cert?</FONT>

<BR><FONT SIZE=3D2>&nbsp; - or the approach of Netscape and IIS4, which, =
even if an Authority Key</FONT>

<BR><FONT SIZE=3D2>Identifier extension is present, DOES still perform a =
comparison of the</FONT>

<BR><FONT SIZE=3D2>subject-cert-issuer-DN to the =
root-cert-subject-DN?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>denis bider</FONT>
</P>

<P><FONT SIZE=3D2>PS. I would like to thank Ace Swerling from Microsoft =
Consulting Services</FONT>

<BR><FONT SIZE=3D2>for the fact that he bothered to look into my =
problem, and especially to</FONT>

<BR><FONT SIZE=3D2>Peter Williams from Valicert who devoted much of his =
time to help me solve</FONT>

<BR><FONT SIZE=3D2>this issue. I appreciate your feedback very =
much.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: &nbsp; denis bider [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]&nbs=
p; On Behalf Of</FONT>

<BR><FONT SIZE=3D2>[email-masked]</FONT>

<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Sunday, June 04, 2000 20:08</FONT>

<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]'</FONT>

<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Report - certificate validation in IE5, Outlook, IIS4, Netscape</FONT>

<BR><FONT SIZE=3D2>4.72</FONT>
</P>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>a while ago I sent to this list an enquiry regarding =
Microsoft's certificate</FONT>

<BR><FONT SIZE=3D2>validation code in IIS4. I have now resolved the =
problem that was the reason</FONT>

<BR><FONT SIZE=3D2>for my enquiry. Since the solution to the problem =
produced some interesting</FONT>

<BR><FONT SIZE=3D2>insight into how certificate chains are handled in =
IE5 and Outlook / IIS4</FONT>

<BR><FONT SIZE=3D2>and Netscape, and since the behavior in question =
should be covered by</FONT>

<BR><FONT SIZE=3D2>RFC2459, but does not seem to be, I am forwarding my =
findings to you.</FONT>
</P>

<P><FONT SIZE=3D2>I produced my own certificate generating utility, the =
intention of which was</FONT>

<BR><FONT SIZE=3D2>to generate certificates which could be used by IE5 =
to login into an</FONT>

<BR><FONT SIZE=3D2>SSL-protected web site running on IIS4. My problem =
was that, although IE5</FONT>

<BR><FONT SIZE=3D2>claimed my root-cert/subject-cert certificate chain =
to be valid, and</FONT>

<BR><FONT SIZE=3D2>although Outlook properly signed and verified =
messages signed by these</FONT>

<BR><FONT SIZE=3D2>certificates, IIS4 rejected all attempts to use the =
subject certificate for</FONT>

<BR><FONT SIZE=3D2>SSL client authentication. Also, when the subject =
certificate was imported</FONT>

<BR><FONT SIZE=3D2>into Netscape, Netscape didn't even show it as an =
elligible choice for SSL</FONT>

<BR><FONT SIZE=3D2>client authentication.</FONT>
</P>

<P><FONT SIZE=3D2>To sum it up, the problem was that there was a glitch =
in my code that caused</FONT>

<BR><FONT SIZE=3D2>the subject-DN in root-cert to be slightly different =
from the issuer-DN in</FONT>

<BR><FONT SIZE=3D2>the subject-cert. It seems that the certificate =
verification code in IE5 and</FONT>

<BR><FONT SIZE=3D2>Outlook2000 is somewhat easy-going, since both of =
these products validated</FONT>

<BR><FONT SIZE=3D2>the pair of certificates as valid (they performed =
cert-chain validation</FONT>

<BR><FONT SIZE=3D2>solely on the grounds of the key identifier in the =
Authority Key Identifier</FONT>

<BR><FONT SIZE=3D2>extension, they did not compare the sub-cert-issuerDN =
to the</FONT>

<BR><FONT SIZE=3D2>root-cert-subjectDN). IIS4 and Netscape Communicator, =
on the other hand,</FONT>

<BR><FONT SIZE=3D2>seem to have a more stringent policy, since they both =
rejected these</FONT>

<BR><FONT SIZE=3D2>certificates.</FONT>
</P>

<P><FONT SIZE=3D2>denis bider</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFCF5B.E53BE647--

Date: Mon, 5 Jun 2000 19:16:09 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SubjectAltName verification
Cc: "'Denis Pinkas'" <[email-masked]>, [email-masked]

Peter,

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

The claim that this text would be "{very damaging to the current 
Internet PKI" is an overstatement, at best.  See below for details.

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

I think most people have an informal understanding of what it means 
to verify information in a cert, even allowing for latitude in a CA's 
policy on the extent and nature of the verification.  I agree that we 
can debate the details of this forever, especially considering past 
experience with analogous topics on this list.

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

VeriSign Class 1 certs have been non-conforming in several respects 
in the past, e.g., the insertion of e-mail addresses into CN 
attributes.  Maybe this, and other practices have ceased; I don't 
know.  Are you seriously saying that that Class 1 certs from VeriSign 
would be completely PKIX compliant if only we paid not attention to 
the procedures used to verify the accuracy of their contents?  Maybe. 
But, if so, what are they worth (vs. what do they cost)?

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

That sounds like a good example of what one would NOT want in a 
certificate.  Are you sure you're arguing against my position :-)? 
Still, you seem to have jumped to a conclusion, based on just this 
example.

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

Says who?  The point I, and several others are trying to make, is 
that it is negligent for a CA to include data in a cert without 
making some effort to verify that data, either directly or via some 
RA(s).  Also, if sending the challenge to the e-mail address does not 
complete the registration procedure, but rather the recipient must 
respond, then that does represent some effort at verification.  It's 
not perfect, but it is a credible effort for a low assurance 
certificate, IF the Subject name or Subject alt name is an e-mail 
address.  If it's some pseudo DN, then NO, this does not count as 
verification.

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

Personally I'm not comfortable with that, because the level of 
verification is pretty low, but that's just my opinion, and it's one 
reason I'm not a VeriSign Class 1 certificate holder.  (Another 
reason is that it doesn't seem to be a very useful thing to have, 
i.e., I don't seem to have much use for one of those certs, 
personally.)

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

There may be other reasons that it is non-conforming, e.g., other 
attributes for which VeriSign makes no effort to verify the data, but 
what you cited above would not rule it out based on the proposed text 
(if the other constraints I cited above were not violated).

Steve

Date: Mon, 05 Jun 2000 13:09:05 -0400
To: <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72
Cc: <[email-masked]>

Denis:

I do not belive that RFC 2459 is silent on this subject.  See 6.1, path 
processing action (a) (4).

Russ

At 08:08 PM 06/04/2000 +0200, [email-masked] wrote:
>Hello,
>
>a while ago I sent to this list an enquiry regarding Microsoft's certificate
>validation code in IIS4. I have now resolved the problem that was the reason
>for my enquiry. Since the solution to the problem produced some interesting
>insight into how certificate chains are handled in IE5 and Outlook / IIS4
>and Netscape, and since the behavior in question should be covered by
>RFC2459, but does not seem to be, I am forwarding my findings to you.
>
>I produced my own certificate generating utility, the intention of which was
>to generate certificates which could be used by IE5 to login into an
>SSL-protected web site running on IIS4. My problem was that, although IE5
>claimed my root-cert/subject-cert certificate chain to be valid, and
>although Outlook properly signed and verified messages signed by these
>certificates, IIS4 rejected all attempts to use the subject certificate for
>SSL client authentication. Also, when the subject certificate was imported
>into Netscape, Netscape didn't even show it as an elligible choice for SSL
>client authentication.
>
>To sum it up, the problem was that there was a glitch in my code that caused
>the subject-DN in root-cert to be slightly different from the issuer-DN in
>the subject-cert. It seems that the certificate verification code in IE5 and
>Outlook2000 is somewhat easy-going, since both of these products validated
>the pair of certificates as valid (they performed cert-chain validation
>solely on the grounds of the key identifier in the Authority Key Identifier
>extension, they did not compare the sub-cert-issuerDN to the
>root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand,
>seem to have a more stringent policy, since they both rejected these
>certificates.
>
>denis bider

From: "Rene G. Eberhard (keyon)" <[email-masked]>
To: "A.Lakshminarayanan" <[email-masked]>, <[email-masked]>
Subject: RE: WTLS Certificate format....
Date: Mon, 5 Jun 2000 22:41:44 +0200
Importance: Normal

> Hi, 
> 
> 	I am looking for specs on the WTLS Certificate format. Is it 
> publicly available? Is it similar to the format specified by the PKIX 
> working group? Are there any similarities? 

Take a look at http://www.wapforum.org/what/technical.htm and read the 
latest WTLS document. You may also take a look at www.freecerts.com
which offers free WAP certificates for testing purposes.

We also offer a public accessible WTLS secured WAPGateway for
testing purposes. We run our keyon / WTLSGateway with kannel 
as WAP Gateway on our internet server at 194.148.57.155. 
The Nokia 7110 will connect secure just fine and you can download 
the root certificate at www.freecerts.com. Note that you cannot 
"escape" our web server but you can display the security parameters 
of the connection which is quite interesting. This does also work 
with the Nokia 1.3b 7110 simulator btw. I hope your firewall (if 
there's any) supports UDP maskerading for accessing our services....

Kind regards

	Rene Eberhard

--
Rene G. Eberhard <[email-masked]>
keyon
Herrenberg 35, CH-8640 Rapperswil, Switzerland
Phone +41 (0)55 220 71 63, Fax +41 (0)55 220 71 61
www.keyon.ch - applying security to your e-business

Get your WAP certificate for free: www.freecerts.com

Date: Mon, 05 Jun 2000 20:46:48 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: [email-masked]
Subject: Re: Attribute Certificate Request

Pedro,

Since the use cases for ACs aren't as well understood as for 
public key certificates, there is, as yet, no equivalent to 
CMP/CMC for AC requests. I would expect that, in future, we 
might get around to writing one.

Meanwhile, there is draft-ietf-pkix-laap-00.txt which describes
an alternative to LDAP for AC retrieval, though this deliberately
doesn't try to provide the equivalent of a CMP certification
request.

Regards,
Stephen.

Pedro Miguel Pereira Borges wrote:
> 
>    Hi all,
> 
>         I'm currently reading the "An Internet Attribute Certificate Profile
> for Authorization" draft...
>         However, there is a question that I would like to see answered: is
> there a definition (ASN.1 or not) of what an attribute certificate request
> should contain like there is one for the "normal" X.509 ID certificates ?
> 
>     Thanks in advance,
> 
>         Pedro Borges

-- 
____________________________________________________________
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: "Alan Shepherd" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithm s to Proposed Standard
Date: Mon, 5 Jun 2000 16:58:41 +0100

Please forgive me if this is a terribly naive question, but I would like to
know what problems arise if a public key is certified erroneously.  I can
not see what security problems arise through this and would very much
appreciate someone wiser explaining it!

Thanks for you help.

Alan

> -----Original Message-----
> From: The IESG [mailto:[email-masked]]
> Sent: 31 May 2000 14:03
> Cc: RFC Editor; RFC Editor; RFC Editor
> Subject: Protocol Action: Diffie-Hellman Proof-of-Possession 
> Algorithms
> to Proposed Standard
> 
> 
> 
> 
> 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.
> 

------------------------------------------------------------------------------------------
This message is for the named person’s use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.

From: "Sikac,John E.(NXI)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: UNSUBSCRIBE
Date: Mon, 5 Jun 2000 08:58:41 -0500 

UNSUBSCRIBE

Date: Mon, 05 Jun 2000 15:16:23 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked], "Manger, James H" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: TSA Response serialNumber Field

I have not followed all the rational for using or not using
Chebyshev's inequality and since a relying party will NOT be happy
with a 95% confidence (nor 99,99%), I propose that we all look back
at the definition we have in the current document.
 
" By adding the XXXX value to the GeneralizedTime, an upper limit of
the time at which the timestamp has been created by the TSA can be
obtained. In the same way, by subtracting the XXXX to the
GeneralizedTime, a lower limit of the time at which the timestamp 
has been created by the TSA can be obtained."

The single remaining question is how do you call XXXX, while
sticking to THIS definition. It is currently called "accuracy". If
this term is not adequate, please make a proposal. I would like to
close this issue soon.

Denis

>      One can recast Chebyshev's  inequality from
>     Pr(|x - mean| >= n * sd) <= 1/n**2
>      to
>      Pr(|x - mean| >= (sd / (1 - c)**.5)) <= (1 - c)
>      or
>      Pr(|x - mean| < (sd / (1 - c)**.5)) > c
> 
>      Where c is just 1 - 1/n**2.
> 
>      If c can be described as a confidence level, this answers your
> question 2) below.  I am not sure that one would describe c here as a
> confidence level, but I think it's reasonable to say that if one has
> probability > C that a measurement actually lies within a range R, then one
> has at least confidence C that the measurement lies within that range.
> 
>           Tom Gindin
> 
> "Manger, James H" <[email-masked]> on 06/02/2000 01:13:25
> AM
> 
> To:   "[email-masked]'" <[email-masked]>
> cc:
> Subject:  RE: TSA Response serialNumber Field
> 
> Thanks Ed,
> 
> (snip)
> 
> If a relying party is happy with a 95% confidence interval it does not need
> to know the exact distribution.  If a relying party wants a better
> confidence level than the standard specifies (e.g. 99.7% instead of 95%) it
> has a couple of choices:
> (1) assume, say, a normal distribution and adjust the uncertainty
> accordingly (e.g. multiple by 3/2); or
> (2) use Chebyshev's inequality to get an upper bound of the required
> adjustment [can Chebyshev's inequality be reformulated for this, i.e. for
> confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?];
> or
> (3) determine the actual distribution from the TSA's policy document and
> adjust the uncertainty by the amount appropriate to that distribution.
> We can leave the choice to the relying party.

Date: Mon, 05 Jun 2000 12:36:58 +0100
From: Pedro Miguel Pereira Borges <[email-masked]>
Reply-To: [email-masked]
Organization: SIBS
To: [email-masked]
Subject: Attribute Certificate Request

   Hi all,

        I'm currently reading the "An Internet Attribute Certificate Profile
for Authorization" draft...
        However, there is a question that I would like to see answered: is
there a definition (ASN.1 or not) of what an attribute certificate request
should contain like there is one for the "normal" X.509 ID certificates ?

    Thanks in advance,

        Pedro Borges

From: [email-masked]
To: [email-masked] (A.Lakshminarayanan)
cc: [email-masked]
Date: Mon, 5 Jun 2000 13:48:52 +0300
Subject: Re: WTLS Certificate format....

Lux asked,

>    I am looking for specs on the WTLS Certificate format. Is it
> publicly available? Is it similar to the format specified by the PKIX
> working group? Are there any similarities?

Look at http://www.wapforum.org/what/technical.htm
Do `find` for WTLS. btw, some other security stuff as well at that page.

I think the format takes a lot from PKIX but judge for yourself...

Best Regards,
Amir Herzberg

IBM Research Lab in Haifa (Tel Aviv Office)
http://www.hrl.il.ibm.com

From: [email-masked] (A.Lakshminarayanan)
Subject: WTLS Certificate format....
To: [email-masked]
Date: Mon, 5 Jun 2000 17:33:17 +0800 (SGT)

Hi, 

	I am looking for specs on the WTLS Certificate format. Is it 
publicly available? Is it similar to the format specified by the PKIX 
working group? Are there any similarities? 

Cheers
Lux 

Kent Ridge Digital Labs
Singapore

From: <[email-masked]>
Sender: "denis bider" <[email-masked]>
To: <[email-masked]>
Subject: Correct approach to certificate validation?
Date: Sun, 4 Jun 2000 20:18:43 +0200
Importance: Normal

Now, based on my previous message, my question for this workgroup:

Which of these approaches is correct?
  - the approach of IE5 and Outlook, which, if an Authority Key Identifier
extension is present, does not perform a comparison of the issuer-DN in the
subject-cert to the subject-DN of the root-cert?
  - or the approach of Netscape and IIS4, which, even if an Authority Key
Identifier extension is present, DOES still perform a comparison of the
subject-cert-issuer-DN to the root-cert-subject-DN?

Regards,

denis bider

PS. I would like to thank Ace Swerling from Microsoft Consulting Services
for the fact that he bothered to look into my problem, and especially to
Peter Williams from Valicert who devoted much of his time to help me solve
this issue. I appreciate your feedback very much.

 -----Original Message-----
From: 	denis bider [mailto:[email-masked]]  On Behalf Of
[email-masked]
Sent:	Sunday, June 04, 2000 20:08
To:	[email-masked]'
Subject:	Report - certificate validation in IE5, Outlook, IIS4, Netscape
4.72

Hello,

a while ago I sent to this list an enquiry regarding Microsoft's certificate
validation code in IIS4. I have now resolved the problem that was the reason
for my enquiry. Since the solution to the problem produced some interesting
insight into how certificate chains are handled in IE5 and Outlook / IIS4
and Netscape, and since the behavior in question should be covered by
RFC2459, but does not seem to be, I am forwarding my findings to you.

I produced my own certificate generating utility, the intention of which was
to generate certificates which could be used by IE5 to login into an
SSL-protected web site running on IIS4. My problem was that, although IE5
claimed my root-cert/subject-cert certificate chain to be valid, and
although Outlook properly signed and verified messages signed by these
certificates, IIS4 rejected all attempts to use the subject certificate for
SSL client authentication. Also, when the subject certificate was imported
into Netscape, Netscape didn't even show it as an elligible choice for SSL
client authentication.

To sum it up, the problem was that there was a glitch in my code that caused
the subject-DN in root-cert to be slightly different from the issuer-DN in
the subject-cert. It seems that the certificate verification code in IE5 and
Outlook2000 is somewhat easy-going, since both of these products validated
the pair of certificates as valid (they performed cert-chain validation
solely on the grounds of the key identifier in the Authority Key Identifier
extension, they did not compare the sub-cert-issuerDN to the
root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand,
seem to have a more stringent policy, since they both rejected these
certificates.

denis bider

From: <[email-masked]>
Sender: "denis bider" <[email-masked]>
To: <[email-masked]>
Subject: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72
Date: Sun, 4 Jun 2000 20:08:21 +0200
Importance: Normal

Hello,

a while ago I sent to this list an enquiry regarding Microsoft's certificate
validation code in IIS4. I have now resolved the problem that was the reason
for my enquiry. Since the solution to the problem produced some interesting
insight into how certificate chains are handled in IE5 and Outlook / IIS4
and Netscape, and since the behavior in question should be covered by
RFC2459, but does not seem to be, I am forwarding my findings to you.

I produced my own certificate generating utility, the intention of which was
to generate certificates which could be used by IE5 to login into an
SSL-protected web site running on IIS4. My problem was that, although IE5
claimed my root-cert/subject-cert certificate chain to be valid, and
although Outlook properly signed and verified messages signed by these
certificates, IIS4 rejected all attempts to use the subject certificate for
SSL client authentication. Also, when the subject certificate was imported
into Netscape, Netscape didn't even show it as an elligible choice for SSL
client authentication.

To sum it up, the problem was that there was a glitch in my code that caused
the subject-DN in root-cert to be slightly different from the issuer-DN in
the subject-cert. It seems that the certificate verification code in IE5 and
Outlook2000 is somewhat easy-going, since both of these products validated
the pair of certificates as valid (they performed cert-chain validation
solely on the grounds of the key identifier in the Authority Key Identifier
extension, they did not compare the sub-cert-issuerDN to the
root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand,
seem to have a more stringent policy, since they both rejected these
certificates.

denis bider

Date: Fri, 2 Jun 2000 16:23:05 +0100
From: "Christopher R. Ryan" <[email-masked]>
Subject: unsubscribe
To: [email-masked]

unsubscribe

*******************************************************************************
Note:          The information contained in this message may be privileged and confidential and protected from disclosure.  If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.  Ernst & Young LLP
*******************************************************************************

From: Tim Moses <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Criticality marking of the policy mappings extension
Date: Fri, 2 Jun 2000 16:26:01 -0400 

Colleagues - I have just reviewed the path processing procedure specified in
the certificate and CRL profile Internet draft.  I have the following
observations.  Let's start with very minor ones ...

1.  In 6.1.3 (b) it says "If certificate i is not self-issued, verify that
the subject name is within one of the permitted_subtrees for X.500
distinguished names, ...".  This rule applies to end-user certificates, as
well as CA certificates.  So, perhaps it should be explicitly stated that a
null subject is within all permitted_subtrees, including a null one.

2.  There appears to be something missing from 6.1.3 (d) (3).  It reads ...
"The two nodes at depth i-1 that are marked with an to the resulting tree
will cause the node at depth i-2 that is marked with a Y to be deleted."

3.  Sub-paras (1) and (2) of 6.1.4 (g) should be indented.

4.  Para 6.1.4 (m) should say "If pathLengthConstraint is present in the
basic constraints extension of the certificate ..."

5.	The reference at the very end of 6.1.4 should be to para 6.1.3, not
6.1.2.

6.	The extended path validation described in Para 6.2 deals with the
case of multiple trust anchors.  In this case it says: "Limitations in the
trust path for any particular key may be incorporated into the self-signed
certificate's extensions.  In this way, the self-signed certificates permit
the path validation module to automatically incorporate local security
policy and requirements."  Setting aside the questions of whether this is a
good thing or a bad thing and whether or not it is consistent with X.509.  I
wonder whether it is appropriate to have different behaviour depending upon
the number of trust anchors.

7.  The final comment relates to the criticality marking on the policy
mappings extension.  If an (admittedly non-conformant) client were to
encounter a PKIX certificate with a non-critical policy mappings extension,
then it could accept the path, when the issuer of the certificate intended
it to reject the path.

Consider this example.  A CA issues a certificate to another CA.  The
certificate policies extension identifies Policy A, and the non-critical
policy mappings extension maps Policy A to Policy B.  The other CA issues a
certificate under Policy A.  The intention of the first CA is that the
certificate user would reject this certificate.  But, a client that
understood certificate policies, but not policy mapping would accept the
certificate. Therefore, it should be permissible to mark the policy mappings
extension critical.  But, this is disallowed by Para 4.2.1.6, which requires
the extension to be marked non-critical.

The 2000 version of X.509 allows and recommends that the policy mappings
extension be marked critical.  So, the PKIX profile should make the same
recommendation.

----------------------------------------------------------------------------
-----------
Tim Moses
Tel: 613.247.3183

Date: Fri, 02 Jun 2000 10:02:49 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: TSA Response serialNumber Field
To: Peter Sylvester <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

Peter Sylvester wrote:

> The question was whether the actual text of requiring a strict monotonically
> increasing serial could be replaced by something else or not in order
> to allow unique identification, and whether or whether not ordering
> among time stamps of one TSA is defined.

But the specs were broken, as it is rather obvious now, and what was
supposed to be a timestamp was actually a nothing.  I guess your examples
would be much worse if the TSA did NOT inform the reliability level
and did NOT inform the expected distribution, because in such a case
instead of saying -- "gee, we may be wrong 5% of the time", the TSA
would be saying "gee, we do not know what we are saying".

BTW, the only *minor* quibble I still have with Manger is that
I do not favor a set reliability level in the standard but we should be making
that a variable to be specified by the TSA. The main reason for this is not
only to avoid fast obsolescence but also to provide room for improvement.
I will not copy again my other arguments, but they are in the archives.

Cheers,

Ed Gerck

PS: I enjoyed your "Dear user of a time stamp " declaration and I have
a similar one for digital certificates -- and this is EXACTLY what I am
trying to avoid by calling attention to the fact that just supplying
what WAS going to be supplied was simply not enough -- as  it
is clear now after much effort, I suppose.

> PS

From: "Golod, Alex" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Would like to subscribe
Date: Fri, 2 Jun 2000 11:36:14 -0400 

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

------_=_NextPart_000_01BFCCA8.48BBF8D6
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

PKI is my area of interest.
I would like  to subscribe. Please, let me know if I need to do something
else to get there.

Thanks,
Alex Golod
(248) 265-6048

 <<Golod, Alex.vcf>> 

------_=_NextPart_000_01BFCCA8.48BBF8D6
Content-Type: application/octet-stream;
	name="Golod, Alex.vcf"
Content-Disposition: attachment;
	filename="Golod, Alex.vcf"

BEGIN:VCARD
VERSION:2.1
N:Golod;Aleksander
FN:Golod, Alex
ORG:EDS;GLOBAL DELIV I.SOLUTIONS
TEL;WORK;VOICE:001 248 265 6048
TEL;WORK;VOICE:8 365 6048
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;AUTHENTICATION/ENCRYPTION SECURI 266112;4198=0D=0A800 TOWER DR=0D=0A;TROY;M=
I;48098;US
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:AUTHENTICATION/ENCRYPTION SECURI 266112=0D=0A4198=0D=0A800 TOWER DR=0D=0A=
=0D=0ATROY, MI 48098=0D=0AUS
EMAIL;PREF;INTERNET:[email-masked]
REV:20000518T131425Z
END:VCARD

------_=_NextPart_000_01BFCCA8.48BBF8D6--

From: Boulos Dib <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Microsoft
Date: Fri, 2 Jun 2000 07:44:27 -0700 

Denis,

I take it you need to understand how IIS and Outlook perform certification
path validation which includes certificate status checking.  If you need to
learn more path validation in general, RFC2459 is the official document.
PKIX uses the term validation not verification and RFC2459 section 6 defines
the details of certification path validation.

I am not an expert on the internals of IIS and Outlook, but I understand
that they both use Microsoft's CryptoAPI (CAPI) certificate functions.  CAPI
includes a number of APIs to deal with certificates, certificate stores, and
what CAPI calls "Certificate Verification Functions" which use Certificate
Revocation Lists (CRLs) and Certificate Trust Lists (CTLs).  There is also a
way for third party vendors (i.e. Validation Authorities) to plug-in their
own implementation of certain APIs to extend the validation to use other
protocols such as Online Certificate Status Protocol (OCSP).  Check out
http://www.valicert.com for information about Email, Web Browser and Web
server validators.  Microsoft's CryptoAPI documentation is available online
on MSDN http://msdn.microsoft.com/library/psdk/crypto/portalapi_3351.htm

I hope the above helps to get you started.

Boulos.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 31, 2000 6:42 PM
To: [email-masked]
Subject: Microsoft

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: [email-masked]
To: "Manger, James H" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Date: Fri, 2 Jun 2000 10:36:50 -0400
Subject: RE: TSA Response serialNumber Field

     One can recast Chebyshev's  inequality from
    Pr(|x - mean| >= n * sd) <= 1/n**2
     to
     Pr(|x - mean| >= (sd / (1 - c)**.5)) <= (1 - c)
     or
     Pr(|x - mean| < (sd / (1 - c)**.5)) > c

     Where c is just 1 - 1/n**2.

     If c can be described as a confidence level, this answers your
question 2) below.  I am not sure that one would describe c here as a
confidence level, but I think it's reasonable to say that if one has
probability > C that a measurement actually lies within a range R, then one
has at least confidence C that the measurement lies within that range.

          Tom Gindin

"Manger, James H" <[email-masked]> on 06/02/2000 01:13:25
AM

To:   "[email-masked]'" <[email-masked]>
cc:
Subject:  RE: TSA Response serialNumber Field

Thanks Ed,

(snip)

If a relying party is happy with a 95% confidence interval it does not need
to know the exact distribution.  If a relying party wants a better
confidence level than the standard specifies (e.g. 99.7% instead of 95%) it
has a couple of choices:
(1) assume, say, a normal distribution and adjust the uncertainty
accordingly (e.g. multiple by 3/2); or
(2) use Chebyshev's inequality to get an upper bound of the required
adjustment [can Chebyshev's inequality be reformulated for this, i.e. for
confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?];
or
(3) determine the actual distribution from the TSA's policy document and
adjust the uncertainty by the amount appropriate to that distribution.
We can leave the choice to the relying party.

From: Peter Sylvester <[email-masked]>
Date: Fri, 2 Jun 2000 10:11:25 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field
Cc: [email-masked], [email-masked]

> That is up to each TSA to specify, according to my suggestion.  And
> I recall that it always makes sense to talk about "mean" and "standard
> deviation" for *any* distribution of like things (apples with apples)
>  -- even if the distribution is not Normal (Gauss).

I wonder how the note of the post office etc would look like (flame waring on):

  Dear user of a time stamp :
  We are giving you this time stamp, you know, we do our best (95%) to have
  a good time, but well, it might happen that, so we just tell 95% and then
  well, if you don't need it better than 1 second, then it is 99% but still
  there is something left, so we are really sorry, but we can't tell you
  more, and obviously we do not know how a relying party may interprete this
  anyway. You know, the background of this is that unfortunately the machine
  that is reading the atomic clock and the atomic clock are made by unperfect
  material, it's similar like the 3 of 5687 nails don't have the right size. 
  Actually we look after the values from time to time, so next time, please
  remember that we highly recommend to arrive at the airport two hours before
  the plane leaves...

A relying party (for example a fiscal authority that verifies whether
you met the deadline):

  - Your declaration is due before midnight. 
  - You've got a time stamp that is shortly (n hours) after midnight ==>
      no technical decision is made, 
  - A clerk is inspecting your declaration, your previous declarations
    etc; whether you pay correctly etc., an explanation from you why
    you think you are late, etc. the clerk obviously has seen the
    info at the TV which just explained that a huge thunderstorm has
    destroyed one third of the electric network of the country just
    during that night. 
  - The cleark acts or doesn't act according the rule that each rule
    has an exception.
 
> 
> BTW, just taking a look at the new IETF "glossary" should convince us
> that we may have already gone too far in our solipsistic phantasies as we
> start to rename that which we ourselves named ;-)

Fortunately the dodo in question is marked OPTIONAL, so a TSA doesn't
have to implement it at all. 

One might consider to look back at the Subject of this thread or should 
one call it threat :-)

The question was whether the actual text of requiring a strict monotonically
increasing serial could be replaced by something else or not in order
to allow unique identification, and whether or whether not ordering
among time stamps of one TSA is defined. 

PS

Date: Thu, 01 Jun 2000 23:56:27 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: TSA Response serialNumber Field
To: "Manger, James H" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

James:

We are in violent agreement.

Cheers,

Ed Gerck

"Manger, James H" wrote:

> Thanks Ed,
>
> I was ignoring the incorrect labelling of the uncertainty field (hoping the
> next draft would fix it).  I was assuming the quoted uncertainty was 1
> standard deviation (hoping the next draft would explicitly state this).
>
> I was assuming the mapping between number of standard deviations and
> confidence level was vaguely independent of the exact distribution, at least
> independent enough for practical timestamping purposes, so I could use the
> mapping that the normal distribution gives.  I knew there were some
> theoretical bounds on this mapping, though I could not remember the
> specifics.  I was also assuming that converting from one confidence level to
> another was possible (e.g. if uncertainty for 68% confidence level is quoted
> just double the uncertainty to get a 95% confidence level).
>
> After finding a statistics text book..
>
> Chebyshev's inequality says the probability of being further than n standard
> deviations from the mean is always less than or equal to 1 / n^2, regardless
> of the distribution.
>     Pr(|x - mean| >= n.sd) <= 1/n^2
>
> [I think there are some distribution that don't have a finite standard
> deviation so Chebyshev's inequality does not hold.  I hope this does not
> apply to practical distribution for TSA time measurements.]
>
> Hence the probability that a sample is not within [mean - n.sd, mean + n.sd]
> is:
> n    normal    upper bound
> 1    32%    <= 100%
> 2    5%    <= 25%
> 3    0.3%    <= 11%
>
> Now I can repeat my calculations from my previous e-mail using Cebyshev's
> inequality instead of a normal distribution.  Instead of calculating the
> probability that T2 occurred after T1 the calculation gives an upper bound
> on this probability.  In that example the upper bound turns out to be 100%
> which is useless.  This highlights the problem with using Cebyshev's
> inequality.  It gives a very weak bound, particularly as you get further
> from the mean (use a higher confidence level).
>
> Back to the timestamp standard..
>
> For comparing a timestamp to another clock we need time, uncertainty,
> confidence level and distribution.  Put the time and uncertainty in the
> timestamp (as now), put the confidence level in the standard and the
> distribution in the TSA's policy document [in future, if required, a policy
> qualifier or extension could be added to describe the distribution in the
> actual timestamp].
>
> The standard could state that the uncertainty field is a given number of
> standard deviations (e.g. 2) or a given confidence interval (e.g. 95%).
> Previous I suggested the former, but (after reading this thread) I can see
> advantages with the latter, though I would be happy either way.  Suggested
> text (after changing the field name from 'accuracy' to 'uncertainty'):
>   "The 'uncertainty' value represents the time deviation, in seconds,
> between the 'genTime' value and UTC at a 95% confidence level.  That is,
> there is a 95% chance that the 'genTime' value is within +/-'uncertainty'
> seconds of UTC.  If the time measurement has a Normal (Gaussian)
> Distribution the 'uncertainty' value is approximately 2 standard
> deviations."
>
> If a relying party is happy with a 95% confidence interval it does not need
> to know the exact distribution.  If a relying party wants a better
> confidence level than the standard specifies (e.g. 99.7% instead of 95%) it
> has a couple of choices:
> (1) assume, say, a normal distribution and adjust the uncertainty
> accordingly (e.g. multiple by 3/2); or
> (2) use Chebyshev's inequality to get an upper bound of the required
> adjustment [can Chebyshev's inequality be reformulated for this, i.e. for
> confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?];
> or
> (3) determine the actual distribution from the TSA's policy document and
> adjust the uncertainty by the amount appropriate to that distribution.
> We can leave the choice to the relying party.

Date: Thu, 01 Jun 2000 23:51:28 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: TSA Response serialNumber Field
To: William Lattin <[email-masked]>
Cc: Paul Koning <[email-masked]>, [email-masked], [email-masked]

William Lattin wrote:

> Another place to look for the treatment of time accuracy and deviation is
> RFC 1305 - NTP has attempted to deal with these very issues (albeit for NTP
> purposes :-)).  NTP introduces the concept of dispersion (see Appendix H)
> which, I believe, addresses the issues being discussed.

No. Appendix H has to do with corrections for delays and offsets in
 NTP communication paths -- roundtrip delay, synch dispersion, etc.
The TSAs timestamps we are talking about have nothing to do with
this model  -- the timestamps here represent static numbers for which
communication delay and synch dispersion is irrelevant after they are
issued by the TSA (and before they are issued we as r-ps do not care --
it is the TSA's business).

So, not only the issues are different but also the consequences. To our
case, what is relevant is a simple question. What does a TSA need to inform
together with a timestamp to a relying-party so that the r-p can rely on that
timestamp for:

(i) a value by itself;
(ii) comparison between timestamps from that TSA;  and
(iii) comparison between timestamps from different TSAs.

My suggestion was that the TSDA needs to inform four quantities besides
the timestamp itself to the r-p, at least.  Otherwise the information may not
allow (i), or (ii, or (iii).

Cheers,

Ed Gerck

From: "Manger, James H" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: TSA Response serialNumber Field
Date: Fri, 2 Jun 2000 15:13:25 +1000 

Thanks Ed,

I was ignoring the incorrect labelling of the uncertainty field (hoping the
next draft would fix it).  I was assuming the quoted uncertainty was 1
standard deviation (hoping the next draft would explicitly state this).

I was assuming the mapping between number of standard deviations and
confidence level was vaguely independent of the exact distribution, at least
independent enough for practical timestamping purposes, so I could use the
mapping that the normal distribution gives.  I knew there were some
theoretical bounds on this mapping, though I could not remember the
specifics.  I was also assuming that converting from one confidence level to
another was possible (e.g. if uncertainty for 68% confidence level is quoted
just double the uncertainty to get a 95% confidence level).

After finding a statistics text book..

Chebyshev's inequality says the probability of being further than n standard
deviations from the mean is always less than or equal to 1 / n^2, regardless
of the distribution.
    Pr(|x - mean| >= n.sd) <= 1/n^2

[I think there are some distribution that don't have a finite standard
deviation so Chebyshev's inequality does not hold.  I hope this does not
apply to practical distribution for TSA time measurements.]

Hence the probability that a sample is not within [mean - n.sd, mean + n.sd]
is:
n    normal    upper bound
1    32%    <= 100%
2    5%    <= 25%
3    0.3%    <= 11%

Now I can repeat my calculations from my previous e-mail using Cebyshev's
inequality instead of a normal distribution.  Instead of calculating the
probability that T2 occurred after T1 the calculation gives an upper bound
on this probability.  In that example the upper bound turns out to be 100%
which is useless.  This highlights the problem with using Cebyshev's
inequality.  It gives a very weak bound, particularly as you get further
from the mean (use a higher confidence level).

Back to the timestamp standard..

For comparing a timestamp to another clock we need time, uncertainty,
confidence level and distribution.  Put the time and uncertainty in the
timestamp (as now), put the confidence level in the standard and the
distribution in the TSA's policy document [in future, if required, a policy
qualifier or extension could be added to describe the distribution in the
actual timestamp].

The standard could state that the uncertainty field is a given number of
standard deviations (e.g. 2) or a given confidence interval (e.g. 95%).
Previous I suggested the former, but (after reading this thread) I can see
advantages with the latter, though I would be happy either way.  Suggested
text (after changing the field name from 'accuracy' to 'uncertainty'):
  "The 'uncertainty' value represents the time deviation, in seconds,
between the 'genTime' value and UTC at a 95% confidence level.  That is,
there is a 95% chance that the 'genTime' value is within +/-'uncertainty'
seconds of UTC.  If the time measurement has a Normal (Gaussian)
Distribution the 'uncertainty' value is approximately 2 standard
deviations."

If a relying party is happy with a 95% confidence interval it does not need
to know the exact distribution.  If a relying party wants a better
confidence level than the standard specifies (e.g. 99.7% instead of 95%) it
has a couple of choices:
(1) assume, say, a normal distribution and adjust the uncertainty
accordingly (e.g. multiple by 3/2); or
(2) use Chebyshev's inequality to get an upper bound of the required
adjustment [can Chebyshev's inequality be reformulated for this, i.e. for
confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?];
or
(3) determine the actual distribution from the TSA's policy document and
adjust the uncertainty by the amount appropriate to that distribution.
We can leave the choice to the relying party.

From: "William Lattin" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "Paul Koning" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: TSA Response serialNumber Field
Date: Thu, 1 Jun 2000 17:03:23 -0700
Importance: Normal

Another place to look for the treatment of time accuracy and deviation is
RFC 1305 - NTP has attempted to deal with these very issues (albeit for NTP
purposes :-)).  NTP introduces the concept of dispersion (see Appendix H)
which, I believe, addresses the issues being discussed.

Bill

> -----Original Message-----
> From: Ed Gerck [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 15:17
> To: Paul Koning
> Cc: [email-masked]; [email-masked]
> Subject: Re: TSA Response serialNumber Field
>
>
>
>
> Paul Koning wrote:
>
> >
> >  Ed> That is up to each TSA to specify, according to my suggestion.
> >  Ed> And I recall that it always makes sense to talk about "mean" and
> >  Ed> "standard deviation" for *any* distribution of like things
> >  Ed> (apples with apples) -- even if the distribution is not Normal
> >  Ed> (Gauss).
> >
> > Suppose we define that the timestamp will contain the mean and
> > standard deviation.  What will that actually tell you?
> >
> > If you know the distribution (e.g., Normal) you can answer the
> > question "with 0.999999 confidence, what are the bounds".  With an
> > unknown distribution, you cannot do that.  So clearly standard
> > deviation is not useful.
>
> Let me recall that you can indeed compare reliability values by using the
> standard  deviation for statistics other than gaussian (normal).
> This shows
> why it is useful to include the *four* types of information I
> suggested for the
> TSA (and not just that "accuracy"  -- which is a meaningless number by
> itself, and misleadingly named as it was):
>
> 1. accuracy: that rather arbitrary fine precision that the TSA sets for
>    its timestamp ordering purposes.
>
> 2. uncertainty: set and guaranteed by the TSA, as given above.
>
> 3. reliability: set and guaranteed by the TSA, as given above.
>
> 4. statistics: set and guaranteed by the TSA, as given above.
>
> For example ([2] in my posting before),  in the case of  gaussian
> statistics,
> 95% reliability corresponds to an uncertainty which is twice the standard
> deviation.
>
> On these matters, to save cyber trees, I looked for some
> references on the web
> that could help provide some examples for each concept. I found
> the ones below,
> which can be helpful (I am sure there are many others):
>
http://bjmath.com/bjmath/Stats/sd.htm
http://bjmath.com/bjmath/Stats/sd.htm
http://bjmath.com/bjmath/Stats/confide.htm

> That leaves two possibilities:
>
> a. What I suggested before: mean plus bound chosen so the confidence
> is "very high".

these numbers cannot be taken out of the blue yonder, but must be
based on a sound and objective basis -- mean, bound and confidence
cannot be arbitrary.  Further, "very high" confidence (ie, reliability) may
indeed mean 60% in some cases and this may be as good as 99% in
other cases -- as I exemplified in my previous posting with 95% and 99%.

> b. Mean plus bound plus confidence value -- preferably with the
> recommendation that the confidence value should be a number quite
> close to 1.  (I don't think I want to do business with a TSA that
> reports intervals with "confidence 0.68"...)
>

Would it surprise you to know that a confidence (reliability) level of
68% for an uncertainty of 0.2 s is much better than 99% for an
uncertainty of 1 s, in terms of gauss distributions?

Further, without specifying to which statistical distribution the value
(mean), the uncertainty (bound) and the reliability (confidence) apply to,
the TSA is essentially selling snake oil.  Let's keep this in mind --
statistics is quite useless unless the terms are well defined, as politics
exemplifies all the time ;-)

As another example, I wish to recall the case of that guy who drowned in
a lake that had one inch depth on average -- he fell in a 40 ft deep hole.

Cheers,

Ed Gerck

Date: Thu, 01 Jun 2000 15:17:11 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: TSA Response serialNumber Field
To: Paul Koning <[email-masked]>
Cc: [email-masked], [email-masked]

Paul Koning wrote:

>
>  Ed> That is up to each TSA to specify, according to my suggestion.
>  Ed> And I recall that it always makes sense to talk about "mean" and
>  Ed> "standard deviation" for *any* distribution of like things
>  Ed> (apples with apples) -- even if the distribution is not Normal
>  Ed> (Gauss).
>
> Suppose we define that the timestamp will contain the mean and
> standard deviation.  What will that actually tell you?
>
> If you know the distribution (e.g., Normal) you can answer the
> question "with 0.999999 confidence, what are the bounds".  With an
> unknown distribution, you cannot do that.  So clearly standard
> deviation is not useful.

Let me recall that you can indeed compare reliability values by using the
standard  deviation for statistics other than gaussian (normal). This shows
why it is useful to include the *four* types of information I suggested for the
TSA (and not just that "accuracy"  -- which is a meaningless number by
itself, and misleadingly named as it was):

1. accuracy: that rather arbitrary fine precision that the TSA sets for
   its timestamp ordering purposes.

2. uncertainty: set and guaranteed by the TSA, as given above.

3. reliability: set and guaranteed by the TSA, as given above.

4. statistics: set and guaranteed by the TSA, as given above.

For example ([2] in my posting before),  in the case of  gaussian statistics,
95% reliability corresponds to an uncertainty which is twice the standard
deviation.

On these matters, to save cyber trees, I looked for some references on the web
that could help provide some examples for each concept. I found the ones below,
which can be helpful (I am sure there are many others):

http://bjmath.com/bjmath/Stats/sd.htm
http://bjmath.com/bjmath/Stats/sd.htm
http://bjmath.com/bjmath/Stats/confide.htm

> That leaves two possibilities:
>
> a. What I suggested before: mean plus bound chosen so the confidence
> is "very high".

these numbers cannot be taken out of the blue yonder, but must be
based on a sound and objective basis -- mean, bound and confidence
cannot be arbitrary.  Further, "very high" confidence (ie, reliability) may
indeed mean 60% in some cases and this may be as good as 99% in
other cases -- as I exemplified in my previous posting with 95% and 99%.

> b. Mean plus bound plus confidence value -- preferably with the
> recommendation that the confidence value should be a number quite
> close to 1.  (I don't think I want to do business with a TSA that
> reports intervals with "confidence 0.68"...)
>

Would it surprise you to know that a confidence (reliability) level of
68% for an uncertainty of 0.2 s is much better than 99% for an
uncertainty of 1 s, in terms of gauss distributions?

Further, without specifying to which statistical distribution the value
(mean), the uncertainty (bound) and the reliability (confidence) apply to,
the TSA is essentially selling snake oil.  Let's keep this in mind --
statistics is quite useless unless the terms are well defined, as politics
exemplifies all the time ;-)

As another example, I wish to recall the case of that guy who drowned in
a lake that had one inch depth on average -- he fell in a 40 ft deep hole.

Cheers,

Ed Gerck

From: Paul Koning <[email-masked]>
Date: Thu, 1 Jun 2000 17:15:48 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field

>>>>> "Ed" == Ed Gerck <[email-masked]> writes:

 Ed> Paul Koning wrote:

 >> If we had a well defined distribution of the random variable, we
 >> could talk about mean and standard deviation.  But I don't believe
 >> we do; in particular I do know that it is a mistake to think that
 >> the distribution is Normal.

 Ed> That is up to each TSA to specify, according to my suggestion.
 Ed> And I recall that it always makes sense to talk about "mean" and
 Ed> "standard deviation" for *any* distribution of like things
 Ed> (apples with apples) -- even if the distribution is not Normal
 Ed> (Gauss).

Well, I never got very far in that area of Math.

Here's why I brought up the issue:

Suppose we define that the timestamp will contain the mean and
standard deviation.  What will that actually tell you?

If you know the distribution (e.g., Normal) you can answer the
question "with 0.999999 confidence, what are the bounds".  With an
unknown distribution, you cannot do that.  So clearly standard
deviation is not useful.

That leaves two possibilities:

a. What I suggested before: mean plus bound chosen so the confidence
is "very high".

b. Mean plus bound plus confidence value -- preferably with the
recommendation that the confidence value should be a number quite
close to 1.  (I don't think I want to do business with a TSA that
reports intervals with "confidence 0.68"...)

	paul

Date: Thu, 01 Jun 2000 13:49:33 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: TSA Response serialNumber Field
To: Paul Koning <[email-masked]>
Cc: [email-masked], [email-masked]

Paul Koning wrote:

> Whenever someone creates a discussion like this where "reliability"
> and "accuracy" (or, similarly, "accuracy" and "tolerance" or
> "accuracy" and "precision") are used with the intent of describing
> quite *different* things, alarms go off.

;-) My alarms too -- especially when such terms are used to mean quite
*different* things than usage in the corresponding technical field.

> If we had a well defined distribution of the random variable, we could
> talk about mean and standard deviation.  But I don't believe we do; in
> particular I do know that it is a mistake to think that the
> distribution is Normal.

That is up to each TSA to specify, according to my suggestion.  And
I recall that it always makes sense to talk about "mean" and "standard
deviation" for *any* distribution of like things (apples with apples)
 -- even if the distribution is not Normal (Gauss).

> Also, consider the intended usage.  One major reason we want to have
> TSAs is so we can timestamp information with legally convincing
> timestamps.  In other words, we want to be able to answer the question
> "did T1 occur before T2" well enough that we can stand up in court and
> give that answer.  Not just here on this list... :-)
>

That is why we need: (i) to call a dodo a dodo,  (ii) to make sure that we are
comparing dodos to dodos and not to platipus.

Of course, this WG is free to create all sorts of names and concepts de
novo, as well as to rename the entire corpus of engineering and law.
I suggest this is not in our best interest, though.

BTW, just taking a look at the new IETF "glossary" should convince us
that we may have already gone too far in our solipsistic phantasies as we
start to rename that which we ourselves named ;-)

> This gives me a criterion for chosing the bounds I would advertise in
> a timestamp: they are chosen reasonably tightly, but such that I am
> willing to stand up in court and testify to the effect that an event
> timestamped as [t - a .. t + a] did indeed occur within a of UTC t.
> In other words, I pick "a" large enough that I am not worried about
> the likelihood of being shown wrong when I make that testimony.
>
> Does that mean that I'm implicitly setting "reliability" as Ed

and engineering textbooks

> uses
> the term, to the value "high enough for legal work"?

well, that means you *wish* to do so -- and you may not suceed if
the other side can show with *equal* reliability that you are wrong.
Perhaps, even less than equal would suffice -- reasonable doubt is
enough.

To exemplify why the concept of reliability is important, and quite
disticnt from uncertainty and accuracy, pls read my former email
when I wrote:

 Clearly, just saying "uncertainty = 2.4 s" is not enough, without the
 reliability.  If the reliability would be 99% then the standard deviation
 for the *same* uncertainty of 2.4 s would be 0.8 s [2]. (and not 1.2 s)

Cheers,

Ed Gerck

From: Paul Koning <[email-masked]>
Date: Thu, 1 Jun 2000 15:50:10 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: TSA Response serialNumber Field

Whenever someone creates a discussion like this where "reliability"
and "accuracy" (or, similarly, "accuracy" and "tolerance" or
"accuracy" and "precision") are used with the intent of describing
quite *different* things, alarms go off.  I find that such discussions
tend to be difficult if not impossible to understand, and it isn't at
all clear whether the conclusions are meaningful.

Take the case discussed here.  Since we're dealing with variables
having some statistical distribution (though very likely *not* one of
the mathematically tractable ones statisticians like to work with) it
is clear that any bounds specified have some probability associated
with them.

If I specify bounds such that the probability of being outside those
bounds is high, I suppose one might speak of this as "low
reliability".  I'd rather not, because to me reliability is a term
that describes the lack of brokenness.  (Or do you want to say that
specifying overly optimistic bounds means you're broken?  I guess I
could go for that...)

If we had a well defined distribution of the random variable, we could
talk about mean and standard deviation.  But I don't believe we do; in
particular I do know that it is a mistake to think that the
distribution is Normal.

Also, consider the intended usage.  One major reason we want to have
TSAs is so we can timestamp information with legally convincing
timestamps.  In other words, we want to be able to answer the question
"did T1 occur before T2" well enough that we can stand up in court and
give that answer.  Not just here on this list... :-)

This gives me a criterion for chosing the bounds I would advertise in
a timestamp: they are chosen reasonably tightly, but such that I am
willing to stand up in court and testify to the effect that an event
timestamped as [t - a .. t + a] did indeed occur within a of UTC t.
In other words, I pick "a" large enough that I am not worried about
the likelihood of being shown wrong when I make that testimony.

Does that mean that I'm implicitly setting "reliability" as Ed uses
the term, to the value "high enough for legal work"?

    paul

Date: Thu, 01 Jun 2000 12:34:57 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: TSA Response serialNumber Field
To: "Manger, James H" <[email-masked]>
Cc: [email-masked]

"Manger, James H" wrote:

> Ed,
>
> The TSTInfo ASN.1 type has a field labelled "accuracy" that "represents the
> time deviation around the UTC time contained in GeneralizedTime" (quoting
> from the draft) [a misleading label & poorly worded sentence].  Its function
> is to indicate how close the stated time is likely to be to UTC.  The field
> is meant to be useful to a relying party when they compare the time in the
> timestamp to any other time (e.g. a deadline, a revocation date in a CRL,
> validity dates in a certificate, another timestamp).  I think the field
> should be labelled "uncertainty" and I suspect you would label it
> "reliability".

I would label it "uncertainty" -- so we are in agreement on this change, but
would rewrite the quote also. I initially suggest:

 "uncertainty" -- represents the time deviation around the UTC time 
  contained in GeneralizedTime, with high reliability.

which, btw, explains why I would NOT name it "reliability" [1].  The draft 
must also define "high reliability" and the allowed statistics (see [1] 
and my comments below). 

Using this definition, we may say that with a reliability of 95% the 
UTC time lies between [To - 1.2] and [To + 1.2] s -- when we are given
an uncertainty of 2.4 s and consider "high reliability" defined as 95%
for a gaussian distribution. With gaussian distributions, this directly 
means that the standard deviation is 1.2 s [2].

Clearly, just saying "uncertainty = 2.4 s" is not enough, without the 
reliability.  If the reliability would be 99% then the standard deviation
for the *same* uncertainty of 2.4 s would be 0.8 s [2].

About "high reliability" in my suggested definition change -- I know that defining
high reliability may be tricky (and soon, outdated) -- but this can be done well by
reference. The draft could define a parameter called "reliability level" (for example)
which the TSA associates to a statistic distribution and sets as high as it can put its 
money to it ;-) -- for  example, 99,9997% [2].  This limit will also provide a useful
parameter  to estimate the quality of service, to calculate risks, to estimate 
insurance costs, etc. Note that the TSA bears a risk not only in setting the 
reliability level but also in declaring that its data follows a statistic distribution
-- for example, if we use gaussian statistics to model the stock market there is a 
tail that significantly exceeds that expected from Gaussian statistics, where the 1929
and 1987 stock market crashes were each about a 10 sigma event (ie, 10 times than the
standard deviation), which would only happen once in the lifetime of the planet
under Gaussian statistics [2].

It is also interesting to note that even if "high reliability" is 70% it might 
still be useful if the uncertainty is low enough -- and the price. It is a
one sigma event [2].

> Now, given that the "accuracy" field actually conveys uncertainty, do I
> really need to know the accuracy as well?  How would a comparison work if
> you knew the uncertainty and accuracy?

;-) let's make clear which is which, first.

We have four quantitites:

1. accuracy: that rather arbitrary fine precision that the TSA sets for 
   its timestamp ordering purposes.  

2. uncertainty: set and guaranteed by the TSA, as given above. 

3. reliability: set and guaranteed by the TSA, as given above.

4. statistics: set and guaranteed by the TSA, as given above.

Thus, just having uncertainty and even accuracy does not allow you to 
compare time between two different TSAs for which you know nothing
about their reliability nor about their statistics (as was the case in 
that example [3])

So, how would a comparison work for two timestamps T1 and T2, each one 
from a different TSA -- with different accuracies, uncertainties, 
reliabilities and statistics?

For each timestamp, you have the uncertainty AND the reliability 
as given by each TSA. You would use a statistical model that both TSAs
agree with (eg, gaussian) with each value in respective full accuracy
and compute the probability that T1 >= T2. If this probability is larger 
than 50%, then T1 >- T2, otherwise it is T1 < T2.

Let me build an example using data from Michaels':

T1. Stamp from TSA_1: 20000529053138.34509878Z. 
accuracy = 8 digits
uncertainty = 1 s
reliability = 95%
statistics: gauss

T2. Stamp from TSA_2: 20000529053138.876Z. 
accuracy = 3 digits
uncertainty = 1.5 s
reliability = 99%
statistics: gauss

How do I do it [compare the stamps]?

Even though the uncertainties are different, the sigmas are the same 
for each case, as we see from [2]. The sigma is 0.5 s and we see
that T2 - T1 > sigma. Thus we may directly compare T1 with T2 and say
that T2 > T1. Otherwise, we would need to calculate using the appropriate
gaussian statistics for each.

Now, if we had (with an added "9" in the timestamp for ordering purposes):

T1'. Stamp from TSA_1: 20000529053138.345098789Z. 
accuracy = 8 digits
uncertainty = 1 s
reliability = 95%
statistics: gauss

then we could NOT say that T1' > T1 even if we take into account that they 
came from the same TSA. We could only say that the TSA issued T1' AFTER 
issuing T1.

Further, if we had:

T2'. Stamp from TSA_2: 20000529053138.345098789Z. 
accuracy = 3 digits
uncertainty = 1.5 s
reliability = 99%
statistics: gauss

then we could say nothing about T2' being issued before or after T1,
much less whether T1' > T1 or not.

Cheers,

Ed Gerck

[1] When estimating the mean of a normal distribution, the sample average
provides a point estimate or best guess about the value of the mean. However, 
this estimate is almost surely not exactly correct. A confidence interval 
provides a range of values around that estimate to show how precise the 
estimate is. The reliability level (also called confidence level) associated 
with the interval, usually 90%, 95%, or 99%, is the percentage of times in 
repeated sampling that the intervals will contain the true value of the 
unknown parameter. See [2].

[2] A gaussian distribution with a standard deviation value "sigma" has,
approximately: 69% of all events within one sigma, 95% of all events 
within two sigma, 99% of all events within three sigma. Nearly 100% 
(exactly: 99,9997%) of all events are covered in the range of  six sigma
-- in other words: out of an amount of 1 Million events only 3 events
are outside the range of six sigma.

[3]
> -----Original Message-----
> From: Ed Gerck [  <mailto:[email-masked]> mailto:[email-masked]]
> Sent: Wednesday, 31 May 2000 13:42
>
> ..
> 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.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Rationale for Nonce in Time Stamp Protocol
Date: Thu, 1 Jun 2000 13:18:51 -0400 

Saying only "or" instead of "and/or" would be fine with me.

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 10:52 AM
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

From: "Manger, James H" <[email-masked]>
To: "'Ed Gerck'" <[email-masked]>
Cc: [email-masked]
Subject: RE: TSA Response serialNumber Field
Date: Thu, 1 Jun 2000 19:20:07 +1000 

Ed,
 
The TSTInfo ASN.1 type has a field labelled "accuracy" that "represents the
time deviation around the UTC time contained in GeneralizedTime" (quoting
from the draft) [a misleading label & poorly worded sentence].  Its function
is to indicate how close the stated time is likely to be to UTC.  The field
is meant to be useful to a relying party when they compare the time in the
timestamp to any other time (e.g. a deadline, a revocation date in a CRL,
validity dates in a certificate, another timestamp).  I think the field
should be labelled "uncertainty" and I suspect you would label it
"reliability".
 
A TSA would determine the value of the field from historical measurements of
how much adjustment was required when synchronising with other clocks,
perhaps factoring in the clock drift specification from the manufacture
(e.g. +/-3 milliseconds/day) plus a safety margin (to err on the
conservative side).
 
Now, given that the "accuracy" field actually conveys uncertainty, do I
really need to know the accuracy as well?  How would a comparison work if
you knew the uncertainty and accuracy?
 
-----Original Message-----
From: Ed Gerck [  <mailto:[email-masked]> mailto:[email-masked]]
Sent: Wednesday, 31 May 2000 13:42

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