Subject: Comments on draft-ietf-pkix-ipki3cmp-03.txt
From: Charles Moore <[email-masked]>
To: [email-masked]
Date: Mon, 1 Sep 1997 09:17:44 +1000

Proposal:
Add extensibility to the PKIBody has been defined in an non extensible
form, the following addition should be added to the PKIBody structure.

Rational:
The message sets needed to support a operational PKI , will need to
mature with experience. Creating non-extensible definitions,  limits the
usefulness of PKIX to support changing requirements. Addition of a
extensibility mechanism will support timely changes.

Change:
 PKIBody ::=3D CHOICE {       -- message-specific body elements
      ir      [0]  InitReqContent,
      ip      [1]  InitRepContent,
      cr      [2]  CertReqContent,
      cp      [3]  CertRepContent,
      p10cr   [4]  CertificationRequest,
        -- the PKCS #10 certification request (see [PKCS10])
      popdecc [5]  POPODecKeyChallContent,
      popdecr [6]  POPODecKeyRespContent,
      kur     [7]  KeyUpdReqContent,
      kup     [8]  KeyUpdRepContent,
      krr     [9]  KeyRecReqContent,
      krp     [10] KeyRecRepContent,
      rr      [11] RevReqContent,
      rp      [12] RevRepContent,
      ccr     [13] CrossCertReqContent,
      ccp     [14] CrossCertRepContent,
      ckuann  [15] CAKeyUpdAnnContent,
      cann    [16] CertAnnContent,
      rann    [17] RevAnnContent,
      crlann  [18] CRLAnnContent,
      conf    [19] PKIConfirmContent,
      nested  [20] NestedMessageContent,
      infor   [21] PKIInfoReqContent,
      infop   [22] PKIInfoRepContent,
      error   [23] ErrorMsgContent,
  	extension   [24] Extensions 
		-- from draft-ietf-pkix-ipki-part1-04.txt
  }

Charles Moore
Signet Systems Pty Ltd
Phone: +61 7 3256 7465 Fax: +61 7 3256 6794

From: <[email-masked]>
Date: Sun, 31 Aug 1997 01:13:46 -0600
To: [email-masked]
Subject: PKCS 7/10 Security Issues

All--

Given that the outcome in Munich favors continued work on the 7/10 draft,
we have some work ahead of us to prepare a draft suitable for PKIX and IE=
SG
approval.  Part of that work will better align the submitted draft as a
supplement to Part 3;  some will deal with current and planned PKCS 7 and
PKCS 10 evolution; and clearly some additional work will address security
issues.  In order to properly bound the security work in particular, it=92=
s
essential we understand and agree to the security requirements of the 7/1=
0
supplement=92s intended client audience.  We have a good start along thos=
e
lines from Munich.  It=92s important however to conclude which among thos=
e
observations establish the basis for further work.   Having not received =
an
advanced copy of the analysis, the following is based on my best
recollection of the points raised during the meeting:

Secure Boostrap
---------------
It was observed that the 7/10 proposal lacks specification of the means b=
y
which vendors are required to establish a trusted public key. While
accurate in fact, the analysis failed to acknowledge the utility of simpl=
e
out-of-band measures (indeed, Part 3 provides many examples of how to do =
so.)

It is only necessary to note that out-of-band establishment of a trusted
public key meets the need for simplicity. Under many circumstances this i=
s
a perfectly valid approach.  Security environments that rely on hardware
tokens are a prime example.

Proposed Resolution: The exact means by which clients of the 7/10
supplement establish trusted public keys are out of scope of the draft.
The Security Considerations section will provide some general guidance on
the topic.

Support for RAs
---------------
It was claimed that the draft provides no means to accommodate RAs.  This
too is an accurate observation but again we need to consider the full
context. We take for guidance this excerpt from Part 3:

"This specification explicitly allows for cases where an end entity
supplies the relevant proof to an RA and the RA subsequently attests to t=
he
CA that the required proof has been received (and validated!). For exampl=
e,
an end entity wishing to have a signing key certified could send the
appropriate signature to the RA which then simply notifies the relevant C=
A
that the end entity has supplied the required proof. Of course, such a
situation may be disallowed by some policies."

Proposed Resolution:  No additional work required, other than perhaps to
reiterate the above guidance in the 7/10 supplement.  There doesn=92t see=
m to
be a compelling need to create additional complexity where none is requir=
ed.

Sender and Recipient Nonces
---------------------------
It was claimed the nonce mechanism fails to provide complete replay
protection. A confirmation message would resolve the issue, but we were
also cognizant of a requirement, put forward in Memphis, for a simple
two-pass protocol.  A two-pass protocol would enable transactions to be
exchanged off the wire (i.e. via floppy disk) in a reasonable manner.

Proposed Resolution: A confirmation message would provide perfect replay
protection, but only at the cost of additional complexity.  The residual
security risks need to be carefully evaluated with this in mind. We=92re
developing an analysis of the tradeoffs. Comments and opinions to the lis=
t
along these lines are also most welcome.

CA Specification of Subject DN
------------------------------
It was claimed the draft requires CAs to specify subject DNs. It is howev=
er
difficult to detect a firm basis for this observation.  It certainly cann=
ot
be on the basis of PKCS 7 usage since that protocol is unaware of the
certification request it carries.  It cannot be on the basis of use of PK=
CS
10 because that syntax is being used today to convey subject names to CAs.
It is true that these names may be combined with other, common naming
information to form a DN, but there exists no requirement to do so.

Proposed Resolution:  There appears to be a misunderstanding here. There =
is
no such limitation in 7/10 protocol to require the CA to decide the DNs.
What a CA chooses to do with the naming information provided it in the PK=
CS
10 is a practices issue between the CA, its subscribers and relying
parties.  It is beyond the scope of the 7/10 supplement to address the
topic.  If text in the draft states or can be read to suggest otherwise, =
it
needs to be corrected.

Optional Profiles and Use of Authenticated Attributes
-----------------------------------------------------
Appendix B of Part 3 identifies profiles across the Part 3 messaging
protocol that are to be considered characteristic of conformant
applications.  Optional profiles are presumably within bounds.  In
particular, one could exclude all but pvno, and sender and recipient name=
s
in PKIHeader.  Given this small amount of remaining syntax, and the expre=
ss
requirement to use an alternate security protocol, one is naturally led t=
o
consider what if any improvements can be gained.

It seems a reasonable tradeoff to replicate some PKIHeader information in=
to
PKCS 7=92s Authenticate Attributes section. It was noted by some that suc=
h
replication has precedence.  We gain in trade a clearer separation betwee=
n
general messaging handling information and specific message data
processing, which in turn favors a more modular, layered architecture.
Lastly, and perhaps most importantly, an integrated use of Authenticated
Attributes enables extensibility in much the same way X.509 is extensible.

Given the extensibility mechanism, CAs are thus able to quickly implement
value-added capabilities using a system interface that still meets the
lowest common denominator needs of its more general subscriber population.
Vendors are similarly able to implement a more flexible product capable o=
f
meeting the needs of a broader customer base.

Proposed Resolution:  Maintain the use of Authenticated Attributes.  The
usage provides substantial benefit to clients of the 7/10 supplement.

Use of Encryption
-----------------
A point was raised that the use of encryption seemed based on subjective
judgment.  Again, the draft presented one interpretation of PKCS 7/10 for
the purposes of open discussion on the merits of its primary intent. =20

Proposed Resolution:  The use of encryption should be specified in an
OPTIONAL fashion, deferring its specific use to local security policy.
Since a challenge-password is used in the certificate request, optional
implementation of encryption implies the existence of a pre-placed secret
to protect certain fields.  PKIX-3 specifies such a technique.

D-H Certification
-----------------
It is true the submitted preliminary draft gave no discussion towards the
certification of a D-H key.  However, the group would recall Dave Solo's
delivery of Hemma Prafulchandra's paper on this topic in San Jose.  The
7/10 draft was submitted with this work in mind.

Proposed Resolution:  Adopt Hemma=92s paper as a baseline and reflect
comments that propose to overcome noted limitations in parameter dependen=
cies.

Mandatory Cipersuites
---------------------
It seemed apparent the debate on the list regarding a mandatory ciphersui=
te
could only be resolved in Munich.  Until such resolution it seemed
premature to co-opt the WG's decision-making process.  Jeff has now
provided us direction.  Clearly, the draft can be updated for mandatory a=
nd
optional cipersuites.  There exists several means to do so.  It remains a
matter of follow-up work from Munich to define the approach.

Proposed Resolution:  An area for further immediate analysis.  We have
three options:
1.  Use PKCS 7 v2.0 exclusively.
2.  Use PKCS 7 v2.0 when other than a single RSA key is used to both
encrypt and sign; use PKCS 7 v1.0 in its current form otherwise.
3.  Propose a hack to PKCS 7 v1.0 to handle other than a single RSA key;
use v1.0 in its current form otherwise.

In all cases, DSA is the mandatory requirement and RSA an optional capabi=
lity.

Access to Public in PKCS 10 to validate message signature
---------------------------------------------------------
A point was raised that the only way one can implement the protocol is
through a modification of known toolkits in order to prove possession of
the private key.

Proposed Resolution: To the contrary, the draft specifically proposes an
alternate mechanism that enables use of off-the-shelf components.  Workin=
g
within these constraints, a self-signed certificate is included in the
PKCSReq message.

--Mike

Michael Myers, VeriSign
(415) 429-3402

From: "Rich Ankney" <[email-masked]>
To: "Carl Ellison" <[email-masked]>
Cc: "Peter Williams" <[email-masked]>, "David Black" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Possible SPKI simplifications
Date: Sat, 30 Aug 1997 18:56:24 -0400

At 2:50 PM 8/30/97 -0400, Carl Ellison wrote:

> I will have to re-read the standard.  As I recall, there are large
sections 
> about CAs and hierarchy.  There is also a firm statement that the purpose
of 
> the certificate is to tie a name to a key and that one is to use
attribute 
> certificates in order to tie permissions (to use my word) to that 
> distinguished name.
> 
> Am I completely misreading the standard?
> 

There's actually not that much about hierarchies anymore.  As to tying a
name
to a key, and using attribute certificates for other permissions, that is
absolutely
correct. 

>  - Carl

Regards,
Rich

Date: Sat, 30 Aug 1997 14:50:01 -0400
To: "Rich Ankney" <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: Possible SPKI simplifications
Cc: "Peter Williams" <[email-masked]>, "David Black" <[email-masked]>, <[email-masked]>, <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

At 02:06 PM 8/30/97 -0400, Rich Ankney wrote:
>X9.57 does not force a hierarchical model either, although it does
>describe it as a possibility.

I will have to re-read the standard.  As I recall, there are large sections 
about CAs and hierarchy.  There is also a firm statement that the purpose of 
the certificate is to tie a name to a key and that one is to use attribute 
certificates in order to tie permissions (to use my word) to that 
distinguished name.

Am I completely misreading the standard?

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison  [email-masked]   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+

From: "Rich Ankney" <[email-masked]>
To: "Peter Williams" <[email-masked]>, "Carl Ellison" <[email-masked]>
Cc: "David Black" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Possible SPKI simplifications
Date: Sat, 30 Aug 1997 14:06:45 -0400

> Carl Ellison wrote: 
> 
> 
> I believe you that the certificate format is agnostic on the subject of 
> hierarchy.  When I talk about hierarchy (in the last year or so), I'm 
> careful to refer to X.500 or PEM rather than X.509.  Of course, the 
> hierarchy is enshrined elsewhere (X9.57, for example) and remains in the 
> minds of the reader from years of PEM talk.

X9.57 does not force a hierarchical model either, although it does
describe it as a possibility.

Regards,
Rich

Date: Sat, 30 Aug 1997 11:21:32 -0400
To: Peter Williams <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: Possible SPKI simplifications
Cc: David Black <[email-masked]>, [email-masked], [email-masked]

At 02:46 AM 8/29/97 -0700, Peter Williams wrote: 

>>>>

<excerpt>  

>>>>

Carl Ellison wrote: 

 There are significant differences between the X.509 naming and SPKI
naming. 

It is true that one can, if one chooses, employ names and issue a delayed 

binding cert binding a named principal to a permission.  To that extent, 

SPKI/SDSI captures what some people wanted to do via X9.57.  However, if
you 

draw the certificate loops for these two cases, you'll see that the 

SPKI/SDSI example uses one loop with one authorization at the left (from
an 

ACL) empowering the loop -- while the X9.57 example uses two loops, one
for 

naming and one for authorization.  The two loops have different code, 

because the certs involved are different -- but in the SPKI/SDSI case
there 

is one 5-tuple evaluator that reduces the single loop whether or not the 

issuers have chosen to use names.  That structure is the significant 

difference to which I referred. 

This is apart from what I consider to be the most important difference --
as 

Peter noted -- that global names (a la X.500 or PEM) are a security
flaw.

<<<<<<<<

This last view I feel politicises IETF. Its so old-fashioned, and does
not 

reflect 

what has happened in the last two years in the X.509 groups in IETF. 

X.509 certs profiled by the PKIX-1 group  no longer need to convey global 

names 

(a la X.500 or PEM). The PKIX1 and PKIX-3 drafts specifically allows a
NULL-DN 

convention in order to exclude X.500 notions. The IETF-version of X.509
DOES 

allow 

SPKI/SDSI-names, as it allows any naming scheme, global or 

non-global. 

</excerpt><<<<<<<<

I believe you that the certificate format is agnostic on the subject of 

hierarchy.  When I talk about hierarchy (in the last year or so), I'm 

careful to refer to X.500 or PEM rather than X.509.  Of course, the 

hierarchy is enshrined elsewhere (X9.57, for example) and remains in the 

minds of the reader from years of PEM talk.

Needless to say, I think PKIX would benefit from eliminating all DN
fields 

and even the definition of DN in the certificates to be proposed
(X.509v4?). 

That would be a good start towards unification of the efforts (which will 

probably happen at some point, many years from now, since we're both 

pursuing the truth, not matter how much old baggage we are carrying).

>>>>

<excerpt>[proposal]  

Carl, this would remove the political issue of global names, and allow
the 

two worlds of capability-centric authorization and certificate-centric 

identity to coexist nicely, and share infrastructure  and defintions. 

</excerpt><<<<<<<<

Even PEM style names can be accepted by the SPKI 5-tuple mechanism, so
I'm 

sure that if PKIX were to divorce itself from DNs, we'd have an even
closer 

mesh.  However, I don't want to argue this on emotional ("political", in 

your words) grounds.  I have a case that global names (whether X.500/PEM
or 

PGP) are a security flaw.  This isn't a rant against X.509.  My problems 

with X.509 itself come from the definition of DN, the definition of
validity 

dates (with a year 2000 problem and non-DER encoding, at least a while
ago), 

the use of ASN.1 (a huge mistake), ....  These are minor problems, to
some, 

and should not stand in the way of an SPKI verifier (5-tuple reducing 

engine) accepting information from X.509 certificates (and therefore
using 

them) as part of a trust management decision.  They are problems which
cause 

me, as a developer, to choose not to use X.509 if there is any
alternative.

 - Carl

+------------------------------------------------------------------+

|Carl M. Ellison  [email-masked]   http://www.clark.net/pub/cme |

|CyberCash, Inc.                      http://www.cybercash.com/    |

|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |

|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |

+------------------------------------------------------------------+

Date: Fri, 29 Aug 1997 14:10:22 -0500
To: Mark Shuttleworth <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Mark,

>When key recovery becomes a *real* issue, it will be harder to say no if
>all the CA's out there built centralised key generation capability for
>PKIX compliance.

So your suggestion is that we not mandate support for a technical facility
(that has legitimate uses other than key recovery) in order to prevent its
use in support of key recovery, in an upcoming political battle.  That's a
slippery slope, since one might identify other features of protocols that,
despite having valid uses, might also be supportive of some function that
we view as objectionable.  For example, source routing in IP can cause
security problems, but it also has legitimate uses.  Support for source
routing is mandated in IP, even though not everyone needs/wants it, and
even though we know if can result in security problems.

Steve

Date: Fri, 29 Aug 1997 16:31:41 -0400
To: Peter Williams <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PKIX-1 key purpose 
Cc: [email-masked]

Peter:

I think that ObjectSigning could be more confusing that CodeSigning.
Object Oriented Programming has nothing to do with the kind og Object you
are proposing.  Maybe ObjectCodeSigning is better than either of the
earlier choices....

Russ

At 04:02 AM 8/29/97 -0700, Peter Williams wrote:
>PKIX-1 says, in repsect of the use of TLS to support http:-
>
>"id-kp-clientAuth              OBJECT IDENTIFIER ::=   {id-kp 2}
>   -- TLS Web client authentication
>   -- Key usage bits that may be consistent: digitalSignature
>
>
>To support TLS cipherSuite in which persistent D-H certificates
>are issued to UAs (and thereby client authentication is not
>performed using digital signature mechanisms) id-kp-clientAuth
>should be extended in the bits that may be consistent:-
>   -- Key usage bits that may be consistent: digitalSignature
>should be augmented to include keyAgreement.
>
>   id-kp-codeSigning             OBJECT IDENTIFIER ::=   {id-kp 3}
>   -- Signing of downloadable executable code
>   -- Key usage bits that may be consistent: digitalSignature"
>
>"CodeSigning" should be renamed ObjectSigning.
>
>The consistent usage bits should be augmented to include
>non-repudiation. There is is no less non-repudiable
>grade service requirements for signing an interpreted install script,
>HTML page, or an exe/dll/class file, then for signing an email.
>

Date: Fri, 29 Aug 1997 15:23:30 -0400
From: Dwight Arthur <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: PKIX List <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

Carlisle Adams wrote:
> From an end entity's point of view, it only really has the option of
> choosing centralized key generation *if* it is mandated that CAs must
> support this function.

Why? If there is in fact a demand for centralized key generation, market
forces will ensure that it is met, no? Why is it necessary for a
standards body to presume this rather than to let the end entities
decide for themselves whether it is needed?

In cases where PKIX is used to support financial transactions that
aspire to nonrepudiation, I question the viability of central keygen.
The is not yet a reliable basis in case law to establish minimum
requirements for nonrepudiation, but I would expect that eventually,
centrally generated private signing keys will be challenged on the basis
that the organization that managed the generation of the key cannot
prove beyond any doubt that the key could not have been misappropriated
during the generation process. Even if this issue is never raised, I
would suggest that the most prudent course would be to avoid the issue
where possible through distributed generation of (at least) signing
keys.

If a party sends me a signed message offering to do business, and I am
willing to accept this offer only if I believe that my acceptance will
form an enforcable contract backed by PKIX-enabled nonrepudiation, I may
wish to accept only where I can verify that the signature used a locally
generated key. How would I determine this? I am not aware of anything in
the X509 certificate that would help me. If every CA is bound to accept
both centralized and distributed key generation, then even prior
scrutiny of the CPS will not help me. If centralized keygen is optional
for the CA, then I can reject any transactions except those tied to a
CPS that affirms that centralized keygen is *NOT* supported. PKIX-3
should allow market forces to determine whether this is a valid or
important scenario.

I agree that from the point of view of protocol standards, every CA
should understand that a message contains a request for *generation* and
certification of a keypair and that another message contains a request
for *certification* only, of a keypair generated in a distributed
fashion. However, the CA should have the option of responding to a
request for central keygen: "rejected: function not available"
--------------------------------------------------
p:(212) 412-8687                     Dwight Arthur
f:(212) 908-2345        Managing Director: Systems
b:(917) 646-6682      National Securities Clearing
[email-masked]                   55 Water Street
http://www.nscc.com        New York, NY 10041-0082

Date: Fri, 29 Aug 1997 14:55:12 -0400
From: Dwight Arthur <[email-masked]>
To: Charles Blauner <[email-masked]>
CC: Ietf-Pkix <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

Charles Blauner wrote:
> I can describe at least one environment where I would need to support
> centralized key generation. It is my corporate environment. Our
> intent is to deploy our PKI leveraging smartcards as the employee
> badge. The badges and all the keying information is generated by our
> corporate security group when a person joins the firm. Additionally,
> for business continuity purposes, we need to safely store all of
> our long term encryption keys which is only easily managed in a
> centralized model.

Hi, Charles, how've you been?

Are you talking about several different private keys and certs on the
smartcard? For example, from your message I could envision a signing
key, a long term encryption key, and perhaps a short term encryption
key, each with its own cert. If you had a smartcard able to do
acceptable onboard keygen, I would envision that the signing private key
would never leave the card, would you agree? If I am to do transactions
with your colleagues, in an environment that aspires to achieve
nonrepudiation, I would like to be assured their private signing keys
are as immune as possible to interception, misappropriation, etc. 

In my personal opinion not reflecting a position of my employer, I would
be concerned if the key were being generated in one location and passed
(in a presumed secure manner) through some number of nodes to a second
location where its owner received it. I would be even further concerned
if this private signing key were archived (either where it were
generated or at an external archive) for any reason, and this concern
stands even if there were a regulatory requirement for such an archive.

I can understand the need for remote generation (and archive) of long
term encryption keys, although I am not certain of why long term
encryption needs to be tied to a person, but that is another matter. I
am uncertain about what I think about short term encryption. But I
believe that remote generation of private signing keys seriously weakens
nonrepudiation and I would be interested to know if you agree.

From: "Arsenault, Al W." <[email-masked]>
To: Bob Jueneman <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Too many options
Date: Thu, 28 Aug 97 10:11:00 EDT
Encoding: 59 TEXT

Okay, I'll bite.

Bob Juenman wrote:

>And as I have previously stated, I think
>that combining centralized key generation with certificate management is a
>bad idea for several reasons.

What are those reasons?

Consider the following scenarios.

     Suppose that a company is using hardware tokens (e.g., smart cards, PC 
cards, etc.) to provide signature and encryption services for its employees. 
 The architecture of these tokens is such that removing a private key is not 
supported; e.g., there's no way for someone to find out the private key 
without physically attacking the token.

Scenario A:  A new employee, Alice, gets a new, uninitialized token from the 
supply system.  Alice commands the token to generate signature and 
encryption key pairs.  She takes the public keys off the token, puts them in 
certificate request messages, and sends them to the company CA.  The CA will 
put the public keys in certificates, sign the certificates, and send them 
back to Alice.  Alice will load the certificates onto her token, and start 
working.

Scenario B:  A new employee, Bob, sends a request to the CA for certificates 
AND KEY GENERATION.  The CA gets a new, uninitialized token from the supply 
system.  The CA commands the token to generate signature and encryption key 
pairs.  The CA takes the public keys off the token, puts them in 
certificates, signs the certificates, and then loads the signed certificates 
onto the token.  The CA then distributes the token to Bob.

Question 1:  from a security standpoint, why is Scenario B worse than 
Scenario A?  Why does B facilitate key recovery, allow the private signature 
key to be surreptitiously duplicated, etc. any more than A?  To me, they are 
approximately equal.  Yes, there are logistical reasons why an organization 
might choose A over B, or vice versa, such as controlling the stock of cards 
(they cost money), preventing the CA from learning the PIN of the token, 
etc., but they can all be dealt with.

Question 2:  if A and B provide approximately equal levels of protection for 
the cryptographic keys, should not both be supported in PKIX?  I agree with 
Steve Kent in that we should discuss whether support for A should be 
mandatory or optional, and whether support for B should be mandatory or 
optional.

 I don't think that support for B should be eliminated from PKIX because of 
a perception that CA generation of keys is inherently a bad thing, or that 
it facilitates key recovery, to which the IETF is opposed,...

                    Al Arsenault

"I speak only for myself.  My opinions do not necessarily represent those of 
my employer."

Date: Fri, 29 Aug 1997 04:02:31 -0700
From: Peter Williams <[email-masked]>
To: [email-masked]
Subject: PKIX-1 key purpose 

PKIX-1 says, in repsect of the use of TLS to support http:-

"id-kp-clientAuth              OBJECT IDENTIFIER ::=   {id-kp 2}
   -- TLS Web client authentication
   -- Key usage bits that may be consistent: digitalSignature

To support TLS cipherSuite in which persistent D-H certificates
are issued to UAs (and thereby client authentication is not
performed using digital signature mechanisms) id-kp-clientAuth
should be extended in the bits that may be consistent:-
   -- Key usage bits that may be consistent: digitalSignature
should be augmented to include keyAgreement.

   id-kp-codeSigning             OBJECT IDENTIFIER ::=   {id-kp 3}
   -- Signing of downloadable executable code
   -- Key usage bits that may be consistent: digitalSignature"

"CodeSigning" should be renamed ObjectSigning.

The consistent usage bits should be augmented to include
non-repudiation. There is is no less non-repudiable
grade service requirements for signing an interpreted install script,
HTML page, or an exe/dll/class file, then for signing an email.

Date: Fri, 29 Aug 1997 02:46:39 -0700
From: Peter Williams <[email-masked]>
To: Carl Ellison <[email-masked]>
CC: David Black <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Possible SPKI simplifications

--------------6DA3E1AEE84FACBB2BD066D1
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by caladan.verisign.com id KAA22632

Carl Ellison wrote:

>  There are significant differences between the X.509 naming and SPKI na=
ming.
> It is true that one can, if one chooses, employ names and issue a delay=
ed
> binding cert binding a named principal to a permission.  To that extent=
,
> SPKI/SDSI captures what some people wanted to do via X9.57.  However, i=
f you
> draw the certificate loops for these two cases, you'll see that the
> SPKI/SDSI example uses one loop with one authorization at the left (fro=
m an
> ACL) empowering the loop -- while the X9.57 example uses two loops, one=
 for
> naming and one for authorization.  The two loops have different code,
> because the certs involved are different -- but in the SPKI/SDSI case t=
here
> is one 5-tuple evaluator that reduces the single loop whether or not th=
e
> issuers have chosen to use names.  That structure is the significant
> difference to which I referred.
>
> This is apart from what I consider to be the most important difference =
-- as
> Peter noted -- that global names (a la X.500 or PEM) are a security fla=
w.

This last view I feel politicises IETF. Its so old-fashioned, and does no=
t reflect
what has happened in the last two years in the X.509 groups in IETF.

X.509 certs profiled by the PKIX-1 group  no longer need to convey global=
 names
(a la X.500 or PEM). The PKIX1 and PKIX-3 drafts specifically allows a NU=
LL-DN
convention in order to exclude X.500 notions. The IETF-version of X.509 D=
OES allow
SPKI/SDSI-names, as it allows any naming scheme, global or
non-global.

Resistance to accepting reality on this nameing thing is skewing SPKI, I =
feel, in some
religious rants.

Let me propose a practical solution to Tim Polk, editor of PKIX-1 and
to you Carl, as main author of "SPK Certificate" I-D:

PROPOSAL

To align the PKIX and SPKI efforts (each dealing with one slice of the
infrastructure problem) the PKIX-1 draft could then define a SPKI/SDSI Na=
me-Form for
PKIX-1 certs. This can be specified in the PKIX-1 draft  along the lines =
of:-

     Using the authority vested in profiling groups by ITU indicated in X=
.509 ("The values
     in the alternatives of the GeneralName type are names of various for=
ms as follows:
     =97 otherName is a name of any form defined as an instance of the OT=
HER-NAME information
     object class") PKIX should define a SDSI name-form.

     PKIX-1 section 4.2.1.8   might include text along the lines of:-

     "When the subjectAltName extension contains a SDSIName, the value
       shall be stored as an instance of other-name. That  is, an instanc=
e of
      other-name shall be represented consistent with the sDSIName type:

          sDSIName OTHER-NAME ::=3D
                    { SDSINameString IDENTIFIED BY {pkix  x}}

          SDSINameString ::=3D IA5STRING
          -- a SDSINameString has <name> syntax, where <name> is defined
          -- 4.3.2.2.1 of  "Simple Public Key Certificate" - draft-ietf-s=
pki-cert-structure-02.txt"

Carl, this would remove the political issue of global names, and allow th=
e
two worlds of capability-centric authorization and certificate-centric
identity to coexist nicely, and share infrastructure  and defintions.

>
>
>  - Carl

--------------6DA3E1AEE84FACBB2BD066D1
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by caladan.verisign.com id KAA22632

<HTML>
&nbsp;

<P>Carl Ellison wrote:
<BLOCKQUOTE TYPE=3DCITE>&nbsp;There are significant differences between t=
he
X.509 naming and SPKI naming.
<BR>It is true that one can, if one chooses, employ names and issue a del=
ayed
<BR>binding cert binding a named principal to a permission.&nbsp; To that
extent,
<BR>SPKI/SDSI captures what some people wanted to do via X9.57.&nbsp; How=
ever,
if you
<BR>draw the certificate loops for these two cases, you'll see that the
<BR>SPKI/SDSI example uses one loop with one authorization at the left
(from an
<BR>ACL) empowering the loop -- while the X9.57 example uses two loops,
one for
<BR>naming and one for authorization.&nbsp; The two loops have different
code,
<BR>because the certs involved are different -- but in the SPKI/SDSI case
there
<BR>is one 5-tuple evaluator that reduces the single loop whether or not
the
<BR>issuers have chosen to use names.&nbsp; That structure is the signifi=
cant
<BR>difference to which I referred.

<P>This is apart from what I consider to be the most important difference
-- as
<BR>Peter noted -- that global names (a la X.500 or PEM) are a security
flaw.</BLOCKQUOTE>
This last view I feel politicises IETF. Its so old-fashioned, and does
not reflect
<BR>what has happened in the last two years in the X.509 groups in IETF.

<P>X.509 certs profiled by the PKIX-1 group&nbsp; no longer need to conve=
y
global names
<BR>(a la X.500 or PEM). The PKIX1 and PKIX-3 drafts specifically allows
a NULL-DN
<BR>convention in order to exclude X.500 notions. The IETF-version of X.5=
09
DOES allow
<BR>SPKI/SDSI-names, as it allows any naming scheme, global or
<BR>non-global.

<P>Resistance to accepting reality on this nameing thing is skewing SPKI,
I feel, in some
<BR>religious rants.

<P>Let me propose a practical solution to Tim Polk, editor of PKIX-1 and
<BR>to you Carl, as main author of "SPK Certificate" I-D:

<P>&nbsp;
<BR>PROPOSAL

<P>To align the PKIX and SPKI efforts (each dealing with one slice of the
<BR>infrastructure problem) the PKIX-1 draft could then define a SPKI/SDS=
I
Name-Form for
<BR>PKIX-1 certs. This can be specified in the PKIX-1 draft&nbsp; along
the lines of:-
<BR>&nbsp;
<UL>Using the authority vested in profiling groups by ITU indicated in
X.509 ("The values
<BR>in the alternatives of the GeneralName type are names of various form=
s
as follows:
<BR>=97 otherName is a name of any form defined as an instance of the OTH=
ER-NAME
information
<BR>object class") PKIX should define a SDSI name-form.

<P>PKIX-1 section 4.2.1.8&nbsp;&nbsp; might include text along the lines
of:-

<P>"When the subjectAltName extension contains a SDSIName, the value
<BR>&nbsp; shall be stored as an instance of other-name. That&nbsp; is,
an instance of
<BR>&nbsp;other-name shall be represented consistent with the sDSIName
type:
<BR>&nbsp;
<UL>sDSIName OTHER-NAME ::=3D
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { SDSINameStri=
ng
IDENTIFIED BY {pkix&nbsp; x}}

<P>SDSINameString ::=3D IA5STRING
<BR>-- a SDSINameString has &lt;name> syntax, where &lt;name> is defined
<BR>-- 4.3.2.2.1 of&nbsp; "Simple Public Key Certificate" - draft-ietf-sp=
ki-cert-structure-02.txt"</UL>
</UL>
&nbsp;
<BR>&nbsp;
<BR>Carl, this would remove the political issue of global names, and allo=
w
the
<BR>two worlds of capability-centric authorization and certificate-centri=
c
<BR>identity to coexist nicely, and share infrastructure&nbsp; and defint=
ions.
<BLOCKQUOTE TYPE=3DCITE>&nbsp;

<P>&nbsp;- Carl</BLOCKQUOTE>
&nbsp;</HTML>

--------------6DA3E1AEE84FACBB2BD066D1--

Date: Thu, 28 Aug 1997 10:27:07 -0700
From: Peter Williams <[email-masked]>
To: [email-masked]
Subject: resolution

I have heard noone support centralised key generation as a mandatory option,
except the author and David Kemp. David would allow sites to not-install
this feature; this defeats the only disclosed purpose, however, of Carlisle's/Steven's
rationale for requiring mandatory support - to engender universal service
to any requesting user.

I have heard at least 5 different, and I believe uncoordinated parties
call for the downgrading of the capability to optional. The calls
criticise both centralisation per se, and its mandatory imposition.

I have  heard a competent and supported position lead by Bob Jueneman
to address the fallout of removing the mandatory nature of centralised
key generation by CAs. I also support Bob's general direction for
both keygen and the KRI. I have noone object to his proposal
which represnts a number of technical and policy compromises.

I am willing to aid Bob in the writing task for his proposed I-D
as a secondary author.

The co-chairs could perhaps now call for final arguments, and
then decide the concensus position, and the actions.

Date: Thu, 28 Aug 1997 19:52:30 -0500
To: Charles Moore <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Charles,

>>>> Perhaps a misunderstanding here. I understand mandatory would mean that
>I
>>>as a CA builder would have to provide a facility for >centralised key
>>>generation. Independent if no-one uses it.
>>
>>That is correct.  A mandatory option is a feature of a protocol that must
>>be supported by a compliant implementation, but that need not be invoked by
>>the users.  Many protocols contain such features, e.g., IP mandates support
>>for various options, yet not all users make use of these options.
>>
>This is not JUST a protocol issue, the PKIX protocols does not do key
>generation it supports request for key generation, the statements on this
>thread are about the MANDATORY support for centralised key generation to be
>provided by ALL CA's.
>
>But anyway, I support the approach to seperate out the key generation
>requests from the certification requests and make the supprt optional.  This
>is a way forward that seems acceptable to most.

Protocols are not just the format of bits on the wire.  They also entail
the processing required by sender and receiver to generate the messages.
Thus the requirement for a CA to be able to generate keys is a part of the
protocol in question.

Steve

Date: Thu, 28 Aug 1997 19:55:09 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: IETF Meeting Minutes
Cc: [email-masked]

Denis,

	I don't have the patent numbers readily available.  We found them
when we were doing a R&D project for DARPA 3 or 4 years ago, involving
timestamping.

Steve

Date: Thu, 28 Aug 1997 17:15:18 -0700
From: NetWorld <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Subject: Search Engines  

I saw your listing on the internet.  I work for a company that 
submits web sites to search engines.  We can submit your site
to 200 search engines for only $29.95.  If you would like to 
increase the visits to your web site please e-mail us back at
the below e-mail address.  For more information, see our web
site.  All orders can receive printout of the search engines their web
site was submitted to.

Sincerely,

NetWorld
E-mail: [email-masked]
Web Page: http://www.a-1.org/net.htm

Date: Thu, 28 Aug 1997 14:29:08 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Key Generation Request/Response...

I think we are getting close to a consensus, so let me propose something
specific in hopes that the issue can be resolved:

1.  Subject to our co-chair's approval, I propose we begin a new work item
to develop a key  generation request response that can be directed to any of
a number of possible sources for keys.  I do agree that this function should
probably go into a new section of the document, TBD. I suppose that having
raised the issue originally I am the most likely stuckee to draft such a
section, but I'm not sure whether I will have the bandwidth to complete the
effort in a timely manner.  Anyone else who would like to help out would be
welcomed with open arms.

2.  I believe that there is a reasonable consensus that the certificate
request protocol  should not include a MANDATORY requirement for supporting
centralized key generation at the CA, i.e., neither the client software nor
the CA software should be required to support this option. 

3. I have no strong objection, other than parsimony, for leaving the
existing CA/keygen protocol as an option if someone wants to implement it. 
However, in Novell's case, I doubt that we would implement such a feature
for our 60 million some odd users, and I would certainly not like to have to
do it twice. And if I read Peter's remarks correctly it doesn't sound like
VeriSign is particularly enthusiastic about it either.  So unless there are
other client software vendors and/or CAs (or CA wannabees or CA-tool
vendors) out there who feel strongly about supporting the function within
the CA, there may not be sufficient demand to warrant including the
capability within the current PKIX-3 protocol.  In other words, I am not
convinced by Carlisle's argument about saving network bandwidth for those
companies that intend to generate keys and enroll a million users all at
once, although it would certainly be a nice problem to have.  I therefore
think that additional comments as to the issue of leave it in vs. take it
out (of the PKIX 3 certificate request protocol) are in order.

4.  I believe we should defer the question of whether a
centralized/distributed/non-local key generation request/response should be
a mandatory feature until we have defined the protocol. Otherwise, we would
simply be debating religion/politics in the absence of any facts.  My hope
and intent, however, is that a protocol could be defined that would be
suitable for local key generation (between a client application, e.g.,
Novell's GroupWise e-mail package, and an operating system function or
adjunct) via a very simple API; as well as being useful for requesting a key
from a remote server, whether located on a corporate Intranet server or even
more remotely, at some centralized location, potentially including a Key
Recovery Center or a CA, via the Internet.  We also need to think through
how this might work in the case of a smart card or hardware token. 

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

>>> Carlisle Adams <[email-masked]> 08/27/97 03:26PM >>>
Hi Bob,

>----------
>From:  Bob Jueneman[SMTP:[email-masked]] 
>Sent:  Tuesday, August 26, 1997 6:26 PM
>To:  [email-masked] 
>Cc:  [email-masked] 
>Subject:  Re: key recovery options for PKIX-3 CAs?
>
>What would you think of removing the function from the certificate request,
>and making it a separate key generation request that could be sent to
>whomever, and would return a public/private key pair (perhaps signed by the
>KRC if and as appropriate.)

I have no real objection to a separate key generation request / response
/ (probably confirm) protocol, except for the obvious:  this is not a
"certificate management protocol" and so does not belong in PKIX-3.  The
reason this functionality was put in the certification request message
is that, in this particular instance, it is part of the certification
request (because the CA is also being asked to generate the key).

A separate key generation request that can be sent to any of a million
different places may well be a useful concept and, I think, fits well
within PKIX.  I just don't think it fits in Part 3.  

[Recall that Part 3 defines messages for certificate management that
travel between CAs, RAs, and EEs.  Other generally useful messages that
do things other than certificate management and that can be sent to
arbitrary other entities are not addressed within this document.]

>Then the certificate request would remain the same, regardless of where the
>public key was generated.  It would take two requests if the CA is
>generating the key, one to generate the key and return it, and the other to
>send the public key back for inclusion in a certificate, but so what?

Given that this may form part of end entity initialization, I wouldn't
be quite so quick to say "so what?".  If a large corporation (using CA
key generation for encryption key pairs) is getting its PKI
up-and-running and initializing tens of thousands of users, I'm guessing
they won't be so keen on doubling network traffic.  They're much more
likely to say "Look, the CA is generating the keys and you're going to
the CA anyway for certification.  Why couldn't you standards people have
combined these messages and saved a lot of bandwidth?"

My preference would be to leave the functionality in the certification
request to save traffic when the CA generates keys.  As well, define a
separate request/response/confirm protocol for key generation in another
PKIX document.  (Note that this does not preclude CAs from recognizing
this separate protocol so that you can still have what you suggest above
when network traffic is not an issue.  Furthermore, this allows an EE to
request key generation from one CA and certification from another CA, if
it wishes.)

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked] 
--------------------------------------------

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 28 Aug 1997 11:23:56 -0400
To: [email-masked] (Olivier Onimus)
From: Russ Housley <[email-masked]>
Subject: Re: Encoding of "iPAddress" in X.509-Certificates
Cc: [email-masked]

I believe that the first format that you describe is intended.  The octet
string contains exactly four octets.

Russ

Olivier Onimus wrote:
>Hi !
>
>
>The following statement  concerning
>the coding of the element "iPAddress" in GeneralName (Chapter 12.3.2.1) is
>mentioned in the X.509-standard:
>
>"?	iPAddress is an Internet Protocol address defined in accordance with
>Internet RFC 791, represented as a binary string."
>
>
>
>GeneralName ::= CHOICE {
>	otherName			[0]	INSTANCE OF OTHER-NAME,
>	rfc822Name			[1]	IA5String,
>	dNSName			        [2]	IA5String,
>	x400Address	   	        [3]	ORAddress,
>	directoryName		        [4]	Name,
>	ediPartyName		        [5]	EDIPartyName,
>	uniformResourceIdentifier	[6]	IA5String,
>	iPAddress			[7]	OCTET STRING,
>	registeredID			[8]	OBJECT IDENTIFIER }
>
>
>
>Does it mean the content of the OCTET STRING containing the IP-Address
>"123.124.125.126" should be coded like:
>'7B7C7D7E'H (that's what I understand under "represented as a binary
string"). 
>  | | | |
>123 | | | 
>  124 | |
>    125 |
>       126
>
>
>
>or (as we have seen in in certificates that we have downloaded from internet
>to test our decode-software !) like:
>
>'3132332E3132342E3132352E313236'H
>  1 2 3 . 1 2 4 . 1 2 5 . 1 2 6
>
>
>
>Thanks in advance for your response !
>
>
>Olivier
>                        
>Olivier Onimus
>Danet GmbH, Business Unit Telecommunications Technology
>P.O.Box 10 04 03, D-64204 Darmstadt
>Tel:    +49-6151-868-127  
>Fax:    +49-6151-868-264
>X.400:  C=de;A=d400;P=Danet;O=Danet-GmbH;S=Onimus
>e-mail: [email-masked]
>
>
>                        
>Olivier Onimus
>Danet GmbH, Business Unit Telecommunications Technology
>P.O.Box 10 04 03, D-64204 Darmstadt
>Tel:    +49-6151-868-127  
>Fax:    +49-6151-868-264
>X.400:  C=de;A=d400;P=Danet;O=Danet-GmbH;S=Onimus
>e-mail: [email-masked]
>

Date: Thu, 28 Aug 1997 13:06:15 -0400
From: patrick duroseau <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: unsubscribe 

unsubscribe [email-masked]

To: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?
From: "C. Harald Koch" <[email-masked]>
Date: Thu, 28 Aug 1997 12:59:08 -0400
Sender: [email-masked]

I don't know if this has been mentioned or not, but (at least with RSA) it
is possible for a black-box key generator to generate compromised keys.

Specifically, it is possible to "choose" the two primes in an RSA
public/private pair, such that the "public" value is really an RSA encrypted
version of the private value, which is encrypted using the public key of the
bad guy.

The SETUP attacks are described in detail in:

http://www.cs.columbia.edu/~ayoung/crypto96.ps

Depending on who you are and your relationship with your CA, this is either
an argument for *or* against the CA doing the key generation...

-- 
Harald Koch <[email-masked]>

Date: Wed, 27 Aug 1997 16:47:13 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: IETF Meeting Minutes

Stephen Kent wrote:

(..)

> Part 5: Time Stamping (Robert Zuccherato, Entrust)
> 
> Brief presentation of what a Time Stamp Authority (TSA) does, and a
> proposed protocol (format and message flow). See PowerPoint slides in
> on-line minutes. Concern expressed over possible patents in this area,
> e.g., by Pitney-Bowes and Fischer International.

Would you, or would someone else, have the number of the patents that
might be relevant ?

Thanks,

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Charles Moore" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Key Generation Request/Response...
Date: Thu, 28 Aug 1997 08:13:06 +1000

 >I have no real objection to a separate key generation request / response
>/ (probably confirm) protocol, except for the obvious:  this is not a
>"certificate management protocol" and so does not belong in PKIX-3.  The
>reason this functionality was put in the certification request message
>is that, in this particular instance, it is part of the certification
>request (because the CA is also being asked to generate the key).
>
>A separate key generation request that can be sent to any of a million
>different places may well be a useful concept and, I think, fits well
>within PKIX.  I just don't think it fits in Part 3.
>
Ok, then remove it from part three and address in another (furure) document.

It all depends if you are looking for a solution or looking for problems.
I thought we had reached a level of agreement.

From: Carlisle Adams <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Key Generation Request/Response...
Date: Wed, 27 Aug 1997 17:26:39 -0400

Hi Bob,

>----------
>From: 	Bob Jueneman[SMTP:[email-masked]]
>Sent: 	Tuesday, August 26, 1997 6:26 PM
>To: 	[email-masked]
>Cc: 	[email-masked]
>Subject: 	Re: key recovery options for PKIX-3 CAs?
>
>What would you think of removing the function from the certificate request,
>and making it a separate key generation request that could be sent to
>whomever, and would return a public/private key pair (perhaps signed by the
>KRC if and as appropriate.)

I have no real objection to a separate key generation request / response
/ (probably confirm) protocol, except for the obvious:  this is not a
"certificate management protocol" and so does not belong in PKIX-3.  The
reason this functionality was put in the certification request message
is that, in this particular instance, it is part of the certification
request (because the CA is also being asked to generate the key).

A separate key generation request that can be sent to any of a million
different places may well be a useful concept and, I think, fits well
within PKIX.  I just don't think it fits in Part 3.  

[Recall that Part 3 defines messages for certificate management that
travel between CAs, RAs, and EEs.  Other generally useful messages that
do things other than certificate management and that can be sent to
arbitrary other entities are not addressed within this document.]

>Then the certificate request would remain the same, regardless of where the
>public key was generated.  It would take two requests if the CA is
>generating the key, one to generate the key and return it, and the other to
>send the public key back for inclusion in a certificate, but so what?

Given that this may form part of end entity initialization, I wouldn't
be quite so quick to say "so what?".  If a large corporation (using CA
key generation for encryption key pairs) is getting its PKI
up-and-running and initializing tens of thousands of users, I'm guessing
they won't be so keen on doubling network traffic.  They're much more
likely to say "Look, the CA is generating the keys and you're going to
the CA anyway for certification.  Why couldn't you standards people have
combined these messages and saved a lot of bandwidth?"

My preference would be to leave the functionality in the certification
request to save traffic when the CA generates keys.  As well, define a
separate request/response/confirm protocol for key generation in another
PKIX document.  (Note that this does not preclude CAs from recognizing
this separate protocol so that you can still have what you suggest above
when network traffic is not an issue.  Furthermore, this allows an EE to
request key generation from one CA and certification from another CA, if
it wishes.)

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: "Charles Moore" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Date: Thu, 28 Aug 1997 06:55:34 +1000

>>> Perhaps a misunderstanding here. I understand mandatory would mean that
I
>>as a CA builder would have to provide a facility for >centralised key
>>generation. Independent if no-one uses it.
>
>That is correct.  A mandatory option is a feature of a protocol that must
>be supported by a compliant implementation, but that need not be invoked by
>the users.  Many protocols contain such features, e.g., IP mandates support
>for various options, yet not all users make use of these options.
>
This is not JUST a protocol issue, the PKIX protocols does not do key
generation it supports request for key generation, the statements on this
thread are about the MANDATORY support for centralised key generation to be
provided by ALL CA's.

But anyway, I support the approach to seperate out the key generation
requests from the certification requests and make the supprt optional.  This
is a way forward that seems acceptable to most.

From: [email-masked] (Tom Kennedy)
Date: Wed, 27 Aug 1997 15:36:47 -0500 (CDT)
To: [email-masked]
Subject: unsubscribe

=============================================================
Tom A. Kennedy
Chisolm Technology
512-418-9962 x6029
=============================================================

Date: Wed, 27 Aug 1997 13:02:53 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Sound like Bob is on the right (one of many?) track here with the separation if only for clarity.

Michael

>>> David P. Kemp <[email-masked]> 08/27/97 09:52AM >>>
> From: Bob Jueneman <[email-masked]>
> 
> What would you think of removing the function from the certificate request,
> and making it a separate key generation request that could be sent to
> whomever, and would return a public/private key pair (perhaps signed by the
> KRC if and as appropriate.)
> 
> Then the certificate request would remain the same, regardless of where the
> public key was generated.  It would take two requests if the CA is
> generating the key, one to generate the key and return it, and the other to
> send the public key back for inclusion in a certificate, but so what?

This sounds like a good solution for reasons of, as you say, parsimony.
I hate to advocate doing major surgery on Part 3 at this late date, but
if the working group endorses making this change, I agree that it is
technically attractive.

Mandating support for both centralized and distributed formats of the
current PKIX-3 certification request ensures that all clients and
servers will recognize the messages - it does not mandate that they
will act on them.

If keypair generation and private key transport is moved to a separate
PKImessage, then it seems likely that clients and servers which support
only a subset of PKIX-3 will nonetheless be smart enough to decode all
PKImessages to the point of recognizing that they have an unsupported
option and being able to return an appropriate error message.  As has
been noted in other protocol working groups, "not supported" is a
legitimate, interoperable response to protocol options which are not
supported due to either implementation constraints or local policy
choices.  { Hanging | core dumping | silently ignoring }, on the other
hand, is not a legitimate response.  I believe that PKIX-3 should
require that all messages, even those designated as optional, be
supported to the extent of recognizing and replying intelligently to
them.

There are organizations which will require centrally-generated
keys for cryptographic strength reasons and/or require archiving of
encryption private keys for business-continuity reasons, and will not
buy products which do not support these operations.  As Steve Kent
notes, the working group's decision on the mandatory/optional status
of each operation is a tradeoff between the size of the constituency
and the cost of implementation.   The IETF tends to be over-represented
by developers and individual users and under-represented by corporate
customers, so it's possible that WG consensus will reflect that
participant pool.

As a large consumer of PKIX products, the DoD will require any products
it buys/uses to support both centralized keypair generation and private
key archiving (of encryption keys only!).  The specific message formats
used to support those operations, and whether the IETF designates the
messages as mandatory or optional, is immaterial.  For straw poll
purposes, I vote that these capabilities be designated as mandatory.
But the more important vote, the one with dollars attached to purchase
requests, will go to vendors who support the business needs of the
customers, regardless of whether that support is required for compliance
with the standard.

Purely for curiosity's sake, is Verisign bidding for corporate accounts
which require key archive capability?  Are Peter's statements on this
topic somewhat akin to hypothetical Japanese automakers, in 1972,
lobbying against CAFE fuel mileage standards so that American
automakers would have the "freedom" to continue to build gas guzzlers,
thereby shooting themselves in the marketplace?

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

Date: Wed, 27 Aug 1997 20:05:03 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Bob Jueneman <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Too many options, was Re: key recovery options for PKIX-3 CAs?

> But what would you think about architecting an optional protocol for a
> separate key generation request/response, that could be sent to any desired
> key generation facility?  

That sounds very reasonable.

--
Mark Shuttleworth
Thawte Consulting

Date: Wed, 27 Aug 1997 19:58:48 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Hi Stephen et al

When key recovery becomes a *real* issue, it will be harder to say no if
all the CA's out there built centralised key generation capability for
PKIX compliance.

--
Mark Shuttleworth
Thawte Consulting

Date: Wed, 27 Aug 1997 11:52:41 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

> From: Bob Jueneman <[email-masked]>
> 
> What would you think of removing the function from the certificate request,
> and making it a separate key generation request that could be sent to
> whomever, and would return a public/private key pair (perhaps signed by the
> KRC if and as appropriate.)
> 
> Then the certificate request would remain the same, regardless of where the
> public key was generated.  It would take two requests if the CA is
> generating the key, one to generate the key and return it, and the other to
> send the public key back for inclusion in a certificate, but so what?

This sounds like a good solution for reasons of, as you say, parsimony.
I hate to advocate doing major surgery on Part 3 at this late date, but
if the working group endorses making this change, I agree that it is
technically attractive.

Mandating support for both centralized and distributed formats of the
current PKIX-3 certification request ensures that all clients and
servers will recognize the messages - it does not mandate that they
will act on them.

If keypair generation and private key transport is moved to a separate
PKImessage, then it seems likely that clients and servers which support
only a subset of PKIX-3 will nonetheless be smart enough to decode all
PKImessages to the point of recognizing that they have an unsupported
option and being able to return an appropriate error message.  As has
been noted in other protocol working groups, "not supported" is a
legitimate, interoperable response to protocol options which are not
supported due to either implementation constraints or local policy
choices.  { Hanging | core dumping | silently ignoring }, on the other
hand, is not a legitimate response.  I believe that PKIX-3 should
require that all messages, even those designated as optional, be
supported to the extent of recognizing and replying intelligently to
them.

There are organizations which will require centrally-generated
keys for cryptographic strength reasons and/or require archiving of
encryption private keys for business-continuity reasons, and will not
buy products which do not support these operations.  As Steve Kent
notes, the working group's decision on the mandatory/optional status
of each operation is a tradeoff between the size of the constituency
and the cost of implementation.   The IETF tends to be over-represented
by developers and individual users and under-represented by corporate
customers, so it's possible that WG consensus will reflect that
participant pool.

As a large consumer of PKIX products, the DoD will require any products
it buys/uses to support both centralized keypair generation and private
key archiving (of encryption keys only!).  The specific message formats
used to support those operations, and whether the IETF designates the
messages as mandatory or optional, is immaterial.  For straw poll
purposes, I vote that these capabilities be designated as mandatory.
But the more important vote, the one with dollars attached to purchase
requests, will go to vendors who support the business needs of the
customers, regardless of whether that support is required for compliance
with the standard.

Purely for curiosity's sake, is Verisign bidding for corporate accounts
which require key archive capability?  Are Peter's statements on this
topic somewhat akin to hypothetical Japanese automakers, in 1972,
lobbying against CAFE fuel mileage standards so that American
automakers would have the "freedom" to continue to build gas guzzlers,
thereby shooting themselves in the marketplace?

Date: Wed, 27 Aug 1997 11:24:36 -0500
To: Charles Moore <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Charles,

>Standards include various "mandatory options" that must be
>supported, but may not be used by all consumers of the standard.  It is
>legitimate to debate whether the CA key gen feature should be a mandatory
>option or just an option.
>
>> Perhaps a misunderstanding here. I understand manadatory would mean that I
>as a CA builder would have to provide a facility for >centralised key
>generation. Independent if no-one uses it.

That is correct.  A mandatory option is a feature of a protocol that must
be supported by a compliant implementation, but that need not be invoked by
the users.  Many protocols contain such features, e.g., IP mandates support
for various options, yet not all users make use of these options.

>> My comment was for business and our liability reasons we will NOT support
>a centralised ( read CA) key generation capability.
>> in our products.

>> If the PKIX text means that we MUST than it is WRONG, we dont have any
>customers demanding this.

Other vendors paint a different picture.  See Carlisle's messages.
Historically, we have not required that all vendors see a feature as
required by their customers in order to make it a mandatory option.
However, if there is significant disagreement in the vendor community about
a feature, and it it appears to be a significant burden to implement, then
there is a tendency to not make such a feature mandatory.

>> I ma happy to allow CA that have a need to do this but this means it is
>optional.

>> PS: I hav no idea what a "mandatory option" might mean?

See above.

Date: Wed, 27 Aug 1997 11:05:06 -0500
To: Mark Shuttleworth <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Mark,

>> option or just an option.  Decisions of this sort usually are based on
>> arguments about the burden imposed on implementations to accommodate a
>> fetaure that is not universally required, versus perceptions about the
>> extent of the market for the feature.  Whether your particular PKI
>
>This is an unusual case, Stephen, because it has implications beyond the
>merely technical.  PKI goes to the core of security and privacy on the
>net, something the IETF has voiced strong opinions on.  Are you suggesting
>that vendors who wish to implement these particular features would be
>unwilling and unable to agree on the necessary standards outside of the
>ambit of the IETF?  Are you suggesting that PKI *on the net* would be
>significantly prejudiced without these features?
>
>If not, why should the IETF compromise stated opinions for their sake?

Yes, we are all in favor of better, not worse, security.  However, CA
generation of keys is not necessarily worse than user key generation.
Carlisle has given several examples that motivate the CA key gen option,
and these are ones in which better security argues for CA key gen.  So this
is not a situation in which the proposed mandatory option will generally
result in poorer security, which I believe ois the thrust of your argument.

While it is true that vendors could go outside the IETF to develop this
standard, that is not consistent with IETF policy, which tries to bring
into the standards process as much as possible, if it will foster
interoperability.  Moreover, most of the arguments I have heard focus on
the narrower question of whether this facility should be a
mandatory-to-support option, or just an option.  In either case it would be
part of the spec.

Steve

Date: Wed, 27 Aug 1997 08:55:42 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Too many options, was Re: key recovery options for PKIX-3 CAs?

Hi, Paul,

I agree that centralized key generation may not be of sufficient interest to
make its implementation mandatory. And as I have previously stated, I think
that combining centralized key generation with certificate management is a
bad idea for several reasons.

But what would you think about architecting an optional protocol for a
separate key generation request/response, that could be sent to any desired
key generation facility?  

Bob

>
>
>>>> "PALAMBER.US.ORACLE.COM" <[email-masked]> 08/26/97 
>05:59PM >>>
> 
> 
>>What (Internet Relevant) environment requires  
>>centralized key generation? 
> 
>I've helped build systems that use both centralized and local (to the
client) 
>key generation.  Centralized key generation is useful for large
organizations 
>that enroll many users from an existing employee database in a single batch

>operation.  Some smart card systems require the loading of a public key
from a 
>centralized administration system.  These examples are not compelling
reasons 
>to mandate centralized key generation.   
> 
>The working group should limit options in the specification and mandate
only 
>one approach (local key generation).  Other interesting enrollment models 
>should be left as value added options. 
> 
>Paul 

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                      

Date: 26 Aug 97 16:59:17 -0700
From: "PALAMBER.US.ORACLE.COM" <[email-masked]>
To: [email-masked]
Subject: Too many options, was Re: key recovery options for PKIX-3 CAs?

 
>What (Internet Relevant) environment requires  
>centralized key generation? 
 
I've helped build systems that use both centralized and local (to the client) 
key generation.  Centralized key generation is useful for large organizations 
that enroll many users from an existing employee database in a single batch 
operation.  Some smart card systems require the loading of a public key from a 
centralized administration system.  These examples are not compelling reasons 
to mandate centralized key generation.   
 
The working group should limit options in the specification and mandate only 
one approach (local key generation).  Other interesting enrollment models 
should be left as value added options. 
 
Paul 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Paul Lambert                     Director of Security Products 
Oracle Corporation               Phone:         (650) 506-0370 
500 Oracle Parkway, Box 659410     Fax:         (650) 633-2963 
Redwood Shores, CA  94065       E-Mail: [email-masked] 
PGP:	    F4 B9 3B 17 BD 49 3B 0C    9E B9 95 E2 42 CA 02 E3 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

Date: Tue, 26 Aug 1997 16:53:08 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX Part 2 - Revised Draft

Denis:

In those cases where disputes may arise about signatures being valid at the time of signing or at time of initial validation, an archive of revocations and suspensions is necessary.  If this need is met other than through the "current" revocation list, then a collection of time-stamped and signed lists needs to be maintained somewhere (most likely at the CA or their repository or publication authority.

Michael

>>> Denis Pinkas <[email-masked]> 08/26/97 04:50PM >>>
Sharon,

I am trying to catch up with 406 messages, coming back from holidays. I
address messages in sequence so, may be, some others have commented on
this one aleready.

I would like to add some details around one of your sentences.

You wrote:

> I agree that leaving revocation entries on a revocation list past the
> expiry date doesn't achieve non-repudiation, nor is it intended to.

I would like to recall that some revocation entries MUST stay a few days
past the end of the validity period mentionned within the certificate.
This is to handle the case of revocation of certificates close to the
end of that validity period. However, I agree that beyond these few
days, there is no reason to maintain them.

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked] 
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Charles Moore" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Date: Wed, 27 Aug 1997 08:36:04 +1000

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, 27 August 1997 8:30
Subject: Re: key recovery options for PKIX-3 CAs?

Charles, did you see my original message?  I think we are in agreement.

> Our time zone difference makes it a bit hard for message flow.
And, yes I believe we are in agreement.

deleted stuff---

What would you think of removing the function from the certificate request,
and making it a separate key generation request that could be sent to
whomever, and would return a public/private key pair (perhaps signed by the
KRC if and as appropriate.)

Sounds fine, as long as it is not mandatory.

Then the certificate request would remain the same, regardless of where the
public key was generated.  It would take two requests if the CA is
generating the key, one to generate the key and return it, and the other to
send the public key back for inclusion in a certificate, but so what?

Sounds even better.

Date: Tue, 26 Aug 1997 16:26:09 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Charles, did you see my original message?  I think we are in agreement.

Centralized key generation may be a requirement for a number of different
reasons, including key quality and security of storage. Key recovery may be
another, quite independent reason, and one that we are surely going to have
to deal with sooner or later, if only for corporate key recovery. (Assuming
that all of the governments in the world suddenly blow over and/or decide
that issues of national sovereignty and crime control don't matter any more
isn't at all likely, but that isn't a politically correct view on this
forum, I suppose.)

Of the various approaches to centralized key generation, I like CA generated
keys the least, but have no objection if some CA and/or client software
vendor chooses to implement it. 

In fact, I'm not convinced that CA key generation should even be part of the
certificate management function, much less a mandatory feature.

What would you think of removing the function from the certificate request,
and making it a separate key generation request that could be sent to
whomever, and would return a public/private key pair (perhaps signed by the
KRC if and as appropriate.)

Then the certificate request would remain the same, regardless of where the
public key was generated.  It would take two requests if the CA is
generating the key, one to generate the key and return it, and the other to
send the public key back for inclusion in a certificate, but so what?

>
>A considerable number of commercial users do not feel that existing client
>software/operating systems are either sufficiently secure or
>cryptographically sound enough to entrust them with the key generation
>function.  They may prefer to use a high-quality hardware random number
>generator, rather than risk some of the problems uncovered by the Netscape
>key generation problem, for example.  This is completely independent of the
>issue of key recovery, but only has to do with the quality of the key
>generation process.
>
>This also has nothing to do with mandatory CA key generation, there are
many
>solutions to this problem. CA key generation is but one of them.

Correct.
>
> >Since these same commercial users are rapidly migrating
>>to the Internet, I assume the Internet-relevancy is obvious.
>>
>>In addition, regardless of what stance various governments might take,
some
>>corporations have strong requirements for their own key recovery, to
ensure
>>the survivability of the business. Depending on the circumstances, they
may
>>choose not to trust the user to perform his own key recovery, but may
>insist
>>on mandatory key recovery being performed at the server (or elsewhere).

>Do it in a key recovery server, not mandating it be done in a CA.

Agreed!
>
>>Some
>>have even expressed the desire that such key recovery NOT be configurable,
>>as they don't even want to have to trust their system administrators.
>>
>>(This might sound paranoid, but remember that corporate officers and the
>>directors may be PERSONALLY liable to the stockholders if a disaster
occurs
>>that they could have anticipated as a reasonable possibility, and if they
>>knew of, but failed to exercise, suitable precautions to prevent it.  We
>are
>>talking about megabucks of personal liability here -- not something to
>>dismiss lightly.)

>The problem is not in debate -- only the single solution being proposed.

Agreed.

>>
>>As I noted in my previous message, "centralised" does not necessarily
imply
>>that key generation is done at the CA.

>I like this.

Good. Me too!
>
>> It could be done at lots of different
>>places that are remote from the client software. The key generation
>>protocols should be generalised to support a request for key generation at
>a
>>remote site, regardless of where that site happens to be -- a KRC, a CA,
or
>>on a corporate server.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: "Charles Moore" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Date: Wed, 27 Aug 1997 08:00:38 +1000

 >
>So that's the history.  Personally, I have no objection to making basic
>authenticated the only mandatory scheme if that's what the list prefers
>(i.e., if we're willing to just say "too bad" to users who are not able
>to generate their own key pairs).  I still think it makes sense to put
>the burden for ubiquitous access on CAs rather than EEs, but either
>decision is fine with me.
If there is a market for CAs to support key generation it will happen
independent of what PKIX may say.
But I disagree that PKIX should mandate something for which there is clearly
NO universal support.

From: "Charles Moore" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Date: Wed, 27 Aug 1997 07:52:35 +1000

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Wednesday, 27 August 1997 2:59
Subject: Re: key recovery options for PKIX-3 CAs?

>>*Not speaking ex-cathedra*
>>
>>   Yes, centralized generation and certification of a key pair must be
>>   supported by CAs (this is an important requirement for some
>>   environments).  Key archival and key recovery services are optional and
>>   need not be supported by PKIX-3-conformant CAs.
>>
>>What (Internet Relevant) environment requires centralized key generation?
>>What benefit (over client generated keys) does it provide?
>>
>>    -Jeff
>
>
>A considerable number of commercial users do not feel that existing client
>software/operating systems are either sufficiently secure or
>cryptographically sound enough to entrust them with the key generation
>function.  They may prefer to use a high-quality hardware random number
>generator, rather than risk some of the problems uncovered by the Netscape
>key generation problem for example.  This is completely independent of the
>issue of key recovery, but only has to do with the quality of the key
>generation process.
This also has nothing to do with mandatory CA key generation, there are many
solutions to this problem. CA key generation is but one of them.

 >Since these same commercial users are rapidly migrating
>to the Internet, I assume the Internet-relevancy is obvious.
>
>In addition, regardless of what stance various governments might take, some
>corporations have strong requirements for their own key recovery, to ensure
>the survivability of the business. Depending on the circumstances, they may
>choose not to trust the user to perform his own key recovery, but may
insist
>on mandatory key recovery being performed at the server (or elsewhere).
Do, it in a key revocery server not mandating it be done in a CA.

>Some
>have even expressed the desire that such key recovery NOT be configurable,
>as they don't even want to have to trust their system administrators.
>
>(This might sound paranoid, bu remember that corporate officers and the
>directors may be PERSONALLY liable to the stockholders if a disaster occurs
>that they could have anticipated as a reasonable possibility, and if they
>knew of, but failed to exercise, suitable precautions to prevent it.  We
are
>talking about megabucks of personal liability here -- not something to
>dismiss lightly.)
The problem is not in bebate only the single solution being proposed.

>
>As I noted in my previous message, "centralised" does not necessarily imply
>that key generation is done at the CA.
I like this.

> It could be done at lots of different
>places that are remote from the client software. The key generation
>protocols should be generalised to support a request for key generation at
a
>remote site, regardless of where that site happens to be -- a KRC, a CA, or
>on a corporate server.
>
>Bob
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Date: Tue, 26 Aug 1997 14:52:03 -0700
To: [email-masked]
From: David Kurn <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

But Charles...

You don't need key centralized key generation for this, you only need:

 Centralized storage of private encryption keys (independent of where they
are generated) under suitable protection.  This protects the legitimate
rights of a corporation or other institution that has rights to your stored
data.

 NO centralized storage or generation of signature/verification keys.

At 02:37 PM 8/26/97 -0800, you wrote:
>Jeff;
>
>I can describe at least one environment where I would need to support
>centralized key generation.
>It is my corporate environment. Our intent is to deploy our PKI leveraging
>smartcards as the employee
>badge. The badges and all the keying information is generated by our
corporate
>security group when
>a person joins the firm.
>Additionally, for business continuity purposes, we need to safely store
all of
>our long term encryption
>keys which is only easily managed in a centralized model.
>
>Charles Blauner
>JP Morgan - Security & Internet Architecture
>
>Note - These are my personal views and do not necessarily represent the views
>of JP Morgan.
>
>
>
>
>        jis @ mit.edu ("Jeffrey I. Schiller")
>08/26/97 10:49 AM
>To: Cadams @ entrust.com @ SMTP
>cc: peter @ verisign.com @ SMTP, ietf-pkix @ tandem.com @ SMTP
>Subject: Re: key recovery options for PKIX-3 CAs?
>
>
>
>*Not speaking ex-cathedra*
>
>   Yes, centralised generation and certification of a key pair must be
>   supported by CAs (this is an important requirement for some
>   environments).  Key archival and key recovery services are optional and
>   need not be supported by PKIX-3-conformant CAs.
>
>What (Internet Relevant) environment requires centralized key generation?
>What benefit (over client generated keys) does it provide?
>
>    -Jeff
>
>
>
>
>
>
>------------------------  Something else Attachment
------------------------
> Sent: 1997-08-26  14:37:01     From SMTPGATE @POST
([email-masked]) : 
>smtp_headers_component
>Received: by POST.TANDEM.COM (4.14/4.5)
>        id AA32057; 26 Aug 97 14:36:08 -0700
>Received: by suntan.tandem.com (8.6.12/suntan5.970212)  for ietf-pkix-relay
>        id NAA24601; Tue, 26 Aug 1997 13:44:19 -0700
>Received: from jpmorgan.com by suntan.tandem.com (8.6.12/suntan5.970212)
for <[email-masked]>
>        id NAA24587; Tue, 26 Aug 1997 13:44:16 -0700
>Received: (from root@localhost)
>        by jpmorgan.com (8.8.5/8.8.5) id QAA09706
>        for <[email-masked]>; Tue, 26 Aug 1997 16:44:07 -0400 (EDT)
>Received: from mrzip.ny.jpmorgan.com(146.149.1.2) by
threshold.jpmorgan.com via smap (3.2)
>        id xma009691; Tue, 26 Aug 97 16:43:45 -0400
>Received: from NYC-NTGW-N02.ny.jpmorgan.com (nyc_ntgw_n02.ny.jpmorgan.com
[198.75.84.103]) by mrzip.ny.jpmorgan.com (8.8.4/8.7.6) with SMTP id
QAA08750 for <@mrzip.ny.jpmorgan.com:[email-masked]>; Tue, 26 Aug
1997 16:43:37 -0400 (EDT)
>Received: by NYC-NTGW-N02.ny.jpmorgan.com (IBM OS/2 SENDMAIL VERSION
1.3.17/1.0)
>          id AA9457; Tue, 26 Aug 97 16:43:33 -0700
>Message-Id: <[email-masked]>
>Received: by JPMORGAN (Lotus Notes Mail Gateway for SMTP V1.1) id
>      12C2DEBD8D0B13B2852564FF0058032F; Tue, 26 Aug 97 16:43:03 EDT
>To: "Jeffrey I. Schiller" <[email-masked]>
>Cc: Cadams <[email-masked]>, Peter <[email-masked]>,
>        Ietf-Pkix
>
>     <Ietf-Pkix>
>From: Charles Blauner
>
>      <[email-masked]>
>Date: 26 Aug 97 16:38:53 EDT
>Subject: Re: key recovery options for PKIX-3 CAs?
>Mime-Version: 1.0
>Content-Type: Text/Plain
>

From: "Charles Moore" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Date: Wed, 27 Aug 1997 07:44:06 +1000

-----Original Message-----
From: Stephen Kent <[email-masked]>
To: Charles Moore <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, 27 August 1997 1:38
Subject: Re: key recovery options for PKIX-3 CAs?

Charles,

Standards include various "mandatory options" that must be
supported, but may not be used by all consumers of the standard.  It is
legitimate to debate whether the CA key gen feature should be a mandatory
option or just an option.

> Perhaps a misunderstanding here. I understand manadatory would mean that I
as a CA builder would have to provide a facility for >centralised key
generation. Independent if no-one uses it.

> My comment was for business and our liability reasons we will NOT support
a centralised ( read CA) key generation capability.
> in our products.
> If the PKIX text means that we MUST than it is WRONG, we dont have any
customers demanding this.
> I ma happy to allow CA that have a need to do this but this means it is
optional.

> PS: I hav no idea what a "mandatory option" might mean?

 Decisions of this sort usually are based on
arguments about the burden imposed on implementations to accommodate a
fetaure that is not universally required, versus perceptions about the
extent of the market for the feature.  Whether your particular PKI
environment views this as an attractive option or not is another input to
the debate.
> Thanks

Steve

Date: Tue, 26 Aug 1997 15:35:24 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: RE: key recovery options for PKIX-3 CAs?

Carlisle,

I'm happy enough with what you have proposed. It doesn't solve my problem of
needing a protocol for an explicit request for key generation outside of the
context of a CA, but it presumably doesn't preclude it, either.

I would have preferred a protocol which uses one common format for a key
generation request, rather than combining it with the certificate request,
but I have no overwhelming objection to the combined approach.

However, because the combined approach only solves part of the overall
problem, I would vote against making it a mandatory feature for either the
client or CA software -- not because of the key recovery implications, but
just for parsimony.

Bob

>Hi Bob,
>>
>>I can imagine about five different scenarios under which public/private
keys
>>could be generated:
>>

[snip]
>
>Everything you ask for above is already accommodated.  Note item 6 at
>the bottom of page 4 of the current draft:
>
>"PKI management protocols must not preclude the generation of key pairs
>by the end-entity concerned, by an RA, or by a CA -- key generation may
>also occur elsewhere, but for the purposes of PKI management we can
>regard key generation as occurring wherever the key is first present at
>an end entity, RA or CA."
>
>The first four things on your list above (from the perspective of the
>PKI messages defined in PKIX-3) have key generation occurring "at the
>end entity" since that is where the key first shows up (i.e., the key
>generation messages to and from a remote server or a Key Recovery Center
>are allowed, but do not need to be explicitly defined in this document
>because they are not part of "Certificate Management Protocols").  The
>fifth has key generation occurring at the CA.  Here, the method for
>requesting this needs to be specified in this document because it is
>part of an InitReq message.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked] 
>--------------------------------------------
>
>

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                      

Date: Tue, 26 Aug 1997 23:10:20 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Stephen Kent <[email-masked]>
cc: Charles Moore <[email-masked]>, [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

> option or just an option.  Decisions of this sort usually are based on
> arguments about the burden imposed on implementations to accommodate a
> fetaure that is not universally required, versus perceptions about the
> extent of the market for the feature.  Whether your particular PKI

This is an unusual case, Stephen, because it has implications beyond the
merely technical.  PKI goes to the core of security and privacy on the 
net, something the IETF has voiced strong opinions on.  Are you suggesting
that vendors who wish to implement these particular features would be
unwilling and unable to agree on the necessary standards outside of the
ambit of the IETF?  Are you suggesting that PKI *on the net* would be
significantly prejudiced without these features?

If not, why should the IETF compromise stated opinions for their sake? 

--
Mark Shuttleworth
Thawte Consulting

To: "Jeffrey I. Schiller" <[email-masked]>
Cc: Cadams <[email-masked]>, Peter <[email-masked]>, Ietf-Pkix <[email-masked]>
From: Charles Blauner <[email-masked]>
Date: 26 Aug 97 16:38:53 EDT
Subject: Re: key recovery options for PKIX-3 CAs?

Jeff;

I can describe at least one environment where I would need to support 
centralized key generation.
It is my corporate environment. Our intent is to deploy our PKI leveraging 
smartcards as the employee
badge. The badges and all the keying information is generated by our corporate 
security group when 
a person joins the firm. 
Additionally, for business continuity purposes, we need to safely store all of 
our long term encryption
keys which is only easily managed in a centralized model.

Charles Blauner
JP Morgan - Security & Internet Architecture

Note - These are my personal views and do not necessarily represent the views 
of JP Morgan.

	jis @ mit.edu ("Jeffrey I. Schiller") 
08/26/97 10:49 AM
To: Cadams @ entrust.com @ SMTP
cc: peter @ verisign.com @ SMTP, ietf-pkix @ tandem.com @ SMTP
Subject: Re: key recovery options for PKIX-3 CAs?

*Not speaking ex-cathedra*

   Yes, centralised generation and certification of a key pair must be
   supported by CAs (this is an important requirement for some
   environments).  Key archival and key recovery services are optional and
   need not be supported by PKIX-3-conformant CAs.  

What (Internet Relevant) environment requires centralized key generation?
What benefit (over client generated keys) does it provide?

    -Jeff

From: Carlisle Adams <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: key recovery options for PKIX-3 CAs?
Date: Tue, 26 Aug 1997 14:30:23 -0400

Hi Bob,

>----------
>From: 	Bob Jueneman[SMTP:[email-masked]]
>Sent: 	Tuesday, August 26, 1997 12:01 PM
>To: 	[email-masked]; [email-masked]
>Subject: 	Re: key recovery options for PKIX-3 CAs?
>
>I can imagine about five different scenarios under which public/private keys
>could be generated:
>
>1.  Generated locally in secure hardware...
>
>2. Generated locally on a client workstation or stand-alone PC...
>
>3. Generated on a server on behalf of the client, using either hardware or
>software.  The private key is then securely communicated to the client...
>
>4.  Generated at an approved Key Recovery Center, and sent securely to the
>requestor...
>
>5. Generated by a Certification Authority in combination with a request to
>certify the public key.  The private key would be securely returned to the
>user..
>
>Having the ability for client software to accommodate any or all of these
>scenarios would be quite beneficial, because of the differences that exist
>today and are certainly expected to exist in the future, both from
>organization to organization and from country to country.

Everything you ask for above is already accommodated.  Note item 6 at
the bottom of page 4 of the current draft:

"PKI management protocols must not preclude the generation of key pairs
by the end-entity concerned, by an RA, or by a CA -- key generation may
also occur elsewhere, but for the purposes of PKI management we can
regard key generation as occurring wherever the key is first present at
an end entity, RA or CA."

The first four things on your list above (from the perspective of the
PKI messages defined in PKIX-3) have key generation occurring "at the
end entity" since that is where the key first shows up (i.e., the key
generation messages to and from a remote server or a Key Recovery Center
are allowed, but do not need to be explicitly defined in this document
because they are not part of "Certificate Management Protocols").  The
fifth has key generation occurring at the CA.  Here, the method for
requesting this needs to be specified in this document because it is
part of an InitReq message.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: key recovery options for PKIX-3 CAs?
Date: Tue, 26 Aug 1997 12:44:38 -0400

Peter,

Yes, the specification mandates that CAs support centralized key
generation as well as end-entity key generation.  This has appeared
quite plainly on about page 11 of the document for over a year now (so
I'm somewhat surprised that you just "uncovered" this "secret" through
your clever and relentless detective work).

In any case, as has been stated numerous times, key generation is not
equivalent to key archive / recovery.  Furthermore, PKIX-3-conformant
end entities have the choice regarding whether or not to ever use CA key
generation. 

Let me give the history of this decision.  When Stephen Farrell and I
were discussing end entity initialization, we concluded that there were
many ways in which this could be done (see the first two pages of
Section 2); we needed to narrow it down to one or two schemes so that
this stuff was implementable and we finally settled on "centralised" and
"basic authenticated" as the simplest.  Then, of course, came the
question of what to make mandatory.  It made no sense whatsoever to make
centralised the only mandatory scheme (not good for non-repudiation,
etc., etc.), so it was either basic authenticated or both.

The following reasoning led us to choose "both".  If basic authenticated
is the only mandatory scheme, then all end entities are forced to
support local key generation.  There are cases in which this is
undesirable (because there is much lower confidence that end entity
software will do this properly (e.g., using cryptographically good
pseudorandom number generators and key generation routines) than that CA
software will do this properly), and there are cases in which this is
impossible (because end entities will not have the capability to install
keying material on a hardware token, for example).  For these types of
cases, it seemed reasonable to allow the option of centralised key
generation so that everyone has the opportunity to get initialized in
the PKI.

>From an end entity's point of view, it only really has the option of
choosing centralized key generation *if* it is mandated that CAs must
support this function.  In short, we decided to put the extra burden on
CA providers (i.e., they must support two schemes instead of one) in
order to provide ubiquitous access to the PKI for end entities.  It
seemed to make sense to put the burden on CAs rather than on end
entities (i.e., EEs must support key generation) because CA providers
are very likely to be fewer in number and are likely to have readier
access to sophisticated resources then Josephine-Internet-user in her
basement.

So that's the history.  Personally, I have no objection to making basic
authenticated the only mandatory scheme if that's what the list prefers
(i.e., if we're willing to just say "too bad" to users who are not able
to generate their own key pairs).  I still think it makes sense to put
the burden for ubiquitous access on CAs rather than EEs, but either
decision is fine with me.

You have a couple of other (inflammatory, though vacuous) comments that
I'd like to ignore but can't.

>"By mandate of IAB", assuming PKIX-3 moves on, every CA product to
>be shipped as conforming to PKIX-3 MUST provide for the option
>of centralised generation of assymmetric keying material. (This nicely
>eliminates Microsoft (beta)  and Netscape current CA products one
>notes which cannot even claim to be "based" on PKIX-3
>with such a rule.)
>
>(This nicely elimiates the 30,000 sites now using PEM-CA
>style SSL certificates, one notes and the existing CAs (public and Netscape
>certserver sites) which support them
>from even claiming to have system based on PKIX-3. (Nice
>bit of standards marketing and/or policy rigging.)

You are clearly suggesting that this feature (centralised key
generation) prevents huge installed bases of CA products and certificate
users from claiming to have systems "based" on PKIX-3.  How about the
fact that not one of these implementations even support a single PKIX-3
PKIMessage?  Wouldn't that *alone* rule them out from claiming any kind
of conformance whatsoever?  In what way, exactly, could they claim their
products were "based" on PKIX-3 if this key generation issue was
removed?

>All you are doing, along with the procedure specified in
>B.8.2  "PKIArchival" is building in one
>of serveral key-recovery capabilitoes into
>the Internet PKI whether CA vendors want
>to provide  it or not.  Its hidden in the
>form of MANDATORY centralised capability
>deployment and vague mandatory/optional support for
>all the encryption-key POP procedures of B.8.2
>which allow for PKI-archival of private-keys.

Peter, you know, I know, and everyone who has been following this thread
knows that proof-of-possession has nothing whatsoever to do with this
issue.  POP is mandatory in PKIX-3, but this can be satisfied for both
signing keys and decryption keys whether or not the CA ever has access
to these keys (and how to do this is spelled out very clearly in the
document).  It is entirely orthogonal to where the key generation
occurs.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Tue, 26 Aug 1997 10:19:17 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

>*Not speaking ex-cathedra*
>
>   Yes, centralized generation and certification of a key pair must be
>   supported by CAs (this is an important requirement for some
>   environments).  Key archival and key recovery services are optional and
>   need not be supported by PKIX-3-conformant CAs.  
>
>What (Internet Relevant) environment requires centralized key generation?
>What benefit (over client generated keys) does it provide?
>
>    -Jeff

A considerable number of commercial users do not feel that existing client
software/operating systems are either sufficiently secure or
cryptographically sound enough to entrust them with the key generation
function.  They may prefer to use a high-quality hardware random number
generator, rather than risk some of the problems uncovered by the Netscape
key generation problem for example.  This is completely independent of the
issue of key recovery, but only has to do with the quality of the key
generation process.  Since these same commercial users are rapidly migrating
to the Internet, I assume the Internet-relevancy is obvious.

In addition, regardless of what stance various governments might take, some
corporations have strong requirements for their own key recovery, to ensure
the survivability of the business. Depending on the circumstances, they may
choose not to trust the user to perform his own key recovery, but may insist
on mandatory key recovery being performed at the server (or elsewhere). Some
have even expressed the desire that such key recovery NOT be configurable,
as they don't even want to have to trust their system administrators.

(This might sound paranoid, bu remember that corporate officers and the
directors may be PERSONALLY liable to the stockholders if a disaster occurs
that they could have anticipated as a reasonable possibility, and if they
knew of, but failed to exercise, suitable precautions to prevent it.  We are
talking about megabucks of personal liability here -- not something to
dismiss lightly.)

As I noted in my previous message, "centralized" does not necessarily imply
that key generation is done at the CA. It could be done at lots of different
places that are remote from the client software. The key generation
protocols should be generalized to support a request for key generation at a
remote site, regardless of where that site happens to be -- a KRC, a CA, or
on a corporate server.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Tue, 26 Aug 1997 10:01:03 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

I'm jumping into this late, having been preoccupied with some other issues.

My bottom line is that support for remote key generation is likely to be a
strong requirement, but that having the CA perform such key generation is
the least desirable option.  I would therefore prefer to decouple a remote
key generation request from any certificate request functions, at least as a
mandatory feature.

I can imagine about five different scenarios under which public/private keys
could be generated:

1.  Generated locally in secure hardware, e.g., a tamper-proof smart card. 
In this case key recovery will presumably only be possible if the hardware
device permits exporting a (suitably wrapped) key.

2. Generated locally on a client workstation or stand-alone PC. Key recovery
may or may not be supported, depending on the software options implemented
and/or chosen.

3. Generated on a server on behalf of the client, using either hardware or
software.  The private key is then securely communicated to the client,
either for storage (presumably password protected or otherwise encrypted),
or securely stored on the server and retrieved after the client is logged
in. Key recovery, if implemented, would presumably be the responsibility of
the server.

4.  Generated at an approved Key Recovery Center, and sent securely to the
requestor for storage.  Note that the KRC may be operated by the user's
organization, or by some Trusted Third Party, or by some government.
(Whether the government is a TTP is a different issue! :-) Key recovery
would be performed by the KRC. The KRC would not issue a conventional CA
certificate, although it might sign the public key in such as way as to
indicate that it was generated "properly".

5. Generated by a Certification Authority in combination with a request to
certify the public key.  The private key would be securely returned to the
user for storage. The CA might choose to divorce itself from any key
recovery, leaving that to the user's software, or it might act as a combined
CA/KRC.  (This is clearly the thrust of the current S.909 McCain/Kerrey bill
in the US Senate.)

Having the ability for client software to accommodate any or all of these
scenarios would be quite beneficial, because of the differences that exist
today and are certainly expected to exist in the future, both from
organization to organization and from country to country.  

Although my crystal ball is probably no better than anyone else's in the
area of politics, I expect that as the US begins to liberalize some of the
previous restrictions on cryptographic exports, that key recovery
requirements of all different kinds will begin to proliferate, whether we in
the IETF think that is a good idea or not. In particular, to the extent that
the US export controls no longer serve as de facto import controls for other
countries around the world, those countries are going to start passing their
own import and perhaps usage controls. The diversity of these different
kinds of control regimes will require great flexibility on the part of
client software, especially for mass-market software that is sold around the
world.

There is another factor to consider, and that is the extent to which
software in different import/export/usage regimes will be allow to
interoperate.

What policies might be imposed by a given country is anyone's guess, but
there are several  schemes that range from proposals to firm requirements
that would prohibit interoperability of encryption if both the outgoing AND
INCOMING traffic does not provide for government key recovery via approved
key recovery centers.

Although not all plans might go this far, we have to be prepared for the
possibility that more or less incontrovertible proof might be required that
a given private (or even secret) key was suitably archived or otherwise made
available for key recovery, where "suitably" is interpreted in accordance
with the regulations imposed by the two governments at both ends of the
link. (Multicast is obviously even worse.)

In other words, before my software is allowed to send an e-mail message or
encrypt a session to you, it will have to see a special gold-star attribute
associated with your public key (and hence by inference your private key)
that says it is acceptable to the government  in my country (and perhaps to
the government of the exporting country).

Hopefully protocols and schemes can be developed that will convey these
attributes more compactly and efficiently, but for the sake of argument,
let's assume that the digital signature of an approved Key Recovery Center
is required. In other words, the KRC in your country must have been approved
by my government before I can send you an encrypted message, OR (presumably)
the necessary key recovery information must flow with the message or session
itself so that my government can recover the individual session key(s).

Returning to the five cases I described at the beginning, it is certainly
possible that trusted hardware or software at the client or at the server
could sign the public key after it was generated, acting as a delegated
agent for the KRC in whatever countries that KRC was approved for. Likewise,
the KRC could return a digitally signed public key along with the private
key if it generates the key pair.

If a CA is simultaneously acting as a KRC, then a single signature -- the
one attached to the  certificate -- would suffice. Presumably the
export/import approved user's software would recognize the root of that the
CA's chain as trustworthy and accept any such certificate as satisfactory
for import/export purposes, in addition to whatever normal CA functionality
was implied.

But if the CA is not accredited as a KRC, which will probably be the case
more often than not, then it may very well be necessary for the user's
software to construct a prototype certificate which CONTAINS A DIGITALLY
SIGNED ATTRIBUTE -- in effect a mini-certificate within a certificate.

In effect, then, a certificate issued by the CA would contain two completely
independent trust hierarchies -- one for purposes of liability and binding
of the user's identity to the public key, and the other attesting to the
acceptability of the public/private key pair by certain governments.  

Although this type of scheme would certainly represent a significant degree
of additional complexity over what we have now, the alternative -- that CAs
would almost be forced to act as government-approved KRCs is equally
unpalatable.

The essence of a CA's function is trust, and users (and relying parties)
should be allowed to contract with whatever CAs best serve their needs,
wherever in the world they find them. If someone in France or Russia, or
Singapore believes that their electronic commerce will be facilitated and
better accepted by using a US CA such as VeriSign or CertCo, they should be
allowed to use them, irrespective of their country's crypto policy.  

Whether true or not, there will inevitably be some shadow of doubt cast upon
those CAs which are certified as government-approved KRCs as well, just
because of the simple fact that they are serving two masters -- the
subscriber and the government.  I don't mean to say that such CAs could not
or should not be trusted -- only that I would prefer (to use a Biblical
metaphor) to render unto Caesar that which is Caesar's, and render unto the
Lord that which is the Lord's.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: <[email-masked]>
To: [email-masked]
Subject: unsubscribe
Date: Tue, 26 Aug 97 11:43:36 -0400

Date: Tue, 26 Aug 1997 11:09:49 -0500
To: Mark Shuttleworth <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: "[email-masked]'" <[email-masked]>

Mark,

	This WG has a charter that includes development of management
protocols in support of PKIs.  The argument put forth by Carlisle is that
CA generation of user keys (which is not key escrow, despite your
persistant characterization of it as such) is a management function for
which there is a constituency.  The only valid argument is whether it is
appropriate to mandate support (not use) for such features, or whether to
specify the provision of such features as an option.  We not not require
explicit IAB or IESG approval to include this feature of this management
protocol in the standard. The IESG may choose to remand the document back
to the WG if it feels that mandating support is inappropriate, just as it
returned the TLS spec because of concerns over default algorithm
specifications.

Steve

Date: Tue, 26 Aug 1997 11:18:37 -0500
To: Charles Moore <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Charles,

	Standards include various "mandatory options" that must be
supported, but may not be used by all consumers of the standard.  It is
legitimate to debate whether the CA key gen feature should be a mandatory
option or just an option.  Decisions of this sort usually are based on
arguments about the burden imposed on implementations to accommodate a
fetaure that is not universally required, versus perceptions about the
extent of the market for the feature.  Whether your particular PKI
environment views this as an attractive option or not is another input to
the debate.

Steve

Date: Tue, 26 Aug 1997 10:49:03 -0400
From: "Jeffrey I. Schiller" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

*Not speaking ex-cathedra*

   Yes, centralised generation and certification of a key pair must be
   supported by CAs (this is an important requirement for some
   environments).  Key archival and key recovery services are optional and
   need not be supported by PKIX-3-conformant CAs.  

What (Internet Relevant) environment requires centralized key generation?
What benefit (over client generated keys) does it provide?

				-Jeff

Date: Tue, 26 Aug 1997 15:50:49 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Sharon Boeyen <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Mike Smith'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: PKIX Part 2 - Revised Draft

Sharon,

I am trying to catch up with 406 messages, coming back from holidays. I
address messages in sequence so, may be, some others have commented on
this one aleready.

I would like to add some details around one of your sentences.

You wrote:

> I agree that leaving revocation entries on a revocation list past the
> expiry date doesn't achieve non-repudiation, nor is it intended to.

I would like to recall that some revocation entries MUST stay a few days
past the end of the validity period mentionned within the certificate.
This is to handle the case of revocation of certificates close to the
end of that validity period. However, I agree that beyond these few
days, there is no reason to maintain them.

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: X.509 profile for ElGamal signatures
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 27 Aug 1997 01:32:50 (NZST)

Attached below is a draft X.509 profile for ElGamal signatures.  I asked about 
this a week ago and found out that it might be appearing as part of P1363 in 
the future, however it's unlikely that it'll be finished within a fortnight, 
and I think there'll be a real need for this at about that time :-).  If noone 
can find any problems with this, I'll submit it as an RFC draft.
 
Peter.
 
-- Snip --
 
Internet Draft                                          Peter Gutmann
draft-rfced-info-gutmann-elgamal-00.txt
August 24, 1997
Expires six months later
 
                  ElGamal Profile for X.509 Certificates
 
Status of this Memo
 
This document is an Internet-Draft. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.
 
Internet-Drafts are draft documents valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite them
other than as "work in progress."
 
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories
on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
         
Abstract 
 
This document describes the ASN.1 encoding for an X.509 certificate profiled 
for use with the ElGamal public key cryptosystem [1].  It is intended to 
provide guidelines for those developing software that will be used to issue 
and use ElGamal certificates, and to ensure that ElGamal certificate and key
information will be handled consistently throughout the public key 
infrastructure.

1. ASN.1 Definition of Certificate Elements
 
The abstract definition of X.509 certificates is given in [2].  The elements 
specific to ElGamal are the algorithm identifier, the public key information, 
and the signature data.  These are as follows:
       
-- ElGamal may be used in conjunction with the SHA-1 and RIPEMD-160
-- hash algorithms.  The ASN.1 object identifiers used to identify 
-- the ElGamal signature algorithm when used with these two hash 
-- algorithms is:
 
elGamalWithSHA-1 OBJECT IDENTIFIER ::= {
    {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029)
     signature(3) 1}
    }
 
elGamalWithRIPEMD-160 OBJECT IDENTIFIER :;= {
    {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029)
     signature(3) 2}
    }
 
-- Some of the ElGamal parameters may be shared among a number of
-- users.  These are conveyed in the parameters component of the
-- ElGamal AlgorithmIdentifier, and are as follows:
 
elGamal-Params ::= SEQUENCE {
    p           INTEGER,
    g           INTEGER
    }                               
                                                  
-- The remaining ElGamal parameter is the users public key:
 
elGamalPublicKey ::= SEQUENCE {
    y           INTEGER,
    }
 
-- The AlgorithmIdentifier and public key are then encoded into a
-- standard X.509 SubjectPublicKeyInfo:
 
SubjectPublicKeyInfo ::= SEQUENCE {
    algorithm   AlgorithmIdentifier,
    subjectPublicKey    BIT STRING
    }
 
-- Prior to the bitstring encoding of an ElGamal signature, the
-- signature components are encoded  as follows:
 
elGamal-Sig ::= SEQUENCE {
    r           INTEGER,
    s           INTEGER
    }

2. Use of ElGamal for Encryption
 
The ElGamal algorithm may also be used for encryption.  In this case the 
message formatting rules follow the rules for RSA encryption as set out in 
PKCS #1 [3], and use a message block type of 01.  The object identifier for 
ElGamal encryption is:
 
elGamalEncryption OBJECT IDENTIFIER ::= {
    {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029)
     asymmetric-encryption(2) 1}
    }
 
The encrypted message consists of two components, the integers a = g^k mod p 
and b = My^k mod p (this is not intended as an explanation of the ElGamal 
algorithm, but merely to indicate which integer is which).  The encoding of 
these integers is:
 
elGamalEncryptedMessage ::= SEQUENCE {
    a           INTEGER,
    b           INTEGER
    }
 
Decryption follows the ElGamal algorithm, and the decrypted message is again 
handled as per PKCS #1.

3. Security considerations
 
Although the use of the ElGamal algorithm for digital signature generation is 
not directly addressed in this document, it should be pointed out that some 
care needs to be taken with both the choice of keys and the use of the 
algorithm.  Details on the safe use of ElGamal are given in [4].  A weakness 
of ElGamal when used for digital signatures, and workarounds to avoid the 
weakness, are given in [5].

3. References
 
[1] "A public-key cryptosystem based on discrete logarithms", Taher ElGamal, 
    IEEE Transactions on Information Theory, Vol.31, No.4 (1985), p.469.
 
[2] ITU Recommendation X.509 (1993).
                                                                    
[3] Public-Key Cryptography Standard #1 (PKCS #1) v1.5, RSA Data Security Inc, 
    November 1993.
 
[4] "Handbook of Applied Cryptography", Alfred Menezes, Paul van Oorschot, and 
    Scott Vanstone, CRC Press, 1996.
 
[5] "Generating ElGamal signatures without knowing the secret key", Daniel 
    Bleichenbacher, presented at EuroCrypt'96.

Author's Address
 
Peter Gutmann
University of Auckland
Private Bag 92019
Auckland
New Zealand
 
Phone: +64 9 373-7599
Email: [email-masked]

Date: Tue, 26 Aug 1997 09:19:40 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

> 
> The fact that the end entity may choose to request certification of
> either locally- or centrally-generated keys is a feature, not a bug.
> There is no implication that a CA service provider must honor either
> type of request -- that is a matter to be decided by agreement/contract
> between the end entity and the CA.
> 

Then WHY have it as part of PKIX?  Yes, a standard for this would be nice,
because standards are nice in general.  But the IETF has taken a strong
security + privacy stance, and centralised key generation does NOT fit.
I'm sure those vendors wanting this feature can agree of a better forum
for hammering out the specifications rather than PKIX.

--
Mark Shuttleworth
Thawte Consulting

Date: Tue, 26 Aug 1997 01:05:29 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Peter Williams <[email-masked]>
cc: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

Carlisle,

Is there an official statement from the IETF that says key
recovery/generation/escrow should be part of PKIX?

--
Mark Shuttleworth
Thawte Consulting

Date: Mon, 25 Aug 1997 16:34:59 -0400
From: Bill Buffam <[email-masked]>
Reply-To: [email-masked]
Organization: Unisys
To: Peter Williams <[email-masked]>
CC: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

I have been observing this brawl with interest. I tend to side with
Peter, in finding a mandatory requirement for centralized key pair
generation particularly distasteful. Carlisle, could you give us
specific examples of scenarios where this is desirable?

-- 

Bill Buffam
Unisys, Malvern PA
[email-masked]

From: "Charles Moore" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Date: Tue, 26 Aug 1997 06:33:39 +1000

Deleted -stuff-----
>Yes, centralised generation and certification of a key pair must be
>supported by CAs (this is an important requirement for some
>environments).
While it may be important for some environments it is NOT a mandatory for
requirement for all environments or CAs.
Any mandatory requirement for centralised key generation MUST be removed, it
can remain as a option.
It is the non preferred option in our Aus PKAF for a number of reasons, that
should be obvious.

Date: Mon, 25 Aug 1997 10:36:08 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

> From: Peter Williams <[email-masked]>
> 
> I suggest you conspicuously add to PKIX-3, allowing for David's
> objection and to overcome the unacceptable mandatory nature of B.8.2
> sentence 5.

Sorry for posting a second followup, but ...

Contrary to having an "unacceptable mandatory nature", I believe section
B8.2 captures precisely the intent of the PKIX profile:

   "This scheme allows the end entity to request certification of a
    locally-generated public key (...).  The end entity may also choose
    to request the centralized generation and certification of another
    key pair (...)."

The fact that the end entity may choose to request certification of
either locally- or centrally-generated keys is a feature, not a bug.
There is no implication that a CA service provider must honor either
type of request -- that is a matter to be decided by agreement/contract
between the end entity and the CA.

The present wording of the above two sentences seems pretty unambiguous,
but if you feel clarification is needed, I wouldn't object to a sentence
saying, in effect, "This profile requires CAs to recognize both types of
request, but imposes no requirements as to whether any particular
request will be honored."

Date: Mon, 25 Aug 1997 10:05:53 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

> From: Peter Williams <[email-masked]>
> 
> "CAs/LRAs are not required to support PKI Archival or key backup
> procedures specified in this document. No mandatory profiles specified
> by PKIX-3 require or imply support of these optional messages and
> procedures, nor mandate support for centralised key generation. See
> RFC1984 for information when designing  PKIX-3  operational profiles
> considering the requirements for archival or backup of private keys, or
> centralised key generation."

Construed literally, I can't find fault with the narrow wording of this
statement*.  But it is potentially misleading to those not
familiar with the technicalities of IETF conformance requirements.

CA, LRA, and end user software MUST support the use of the required
messages.  If you purchase a PKIX-conformant client or server software
package, you MUST be able to configure it to do either centralized or
distributed keygen.

CA/LRA service providers, as well as human end users (as distinguished
from their agent software) are of course not required by the IETF to use
any particular model for key generation and archiving - they are able to
configure the software to do whatever is in accordance with their own
policy.  This is perhaps stating the obvious, but it can't hurt to be
explicit.

I'd support the inclusion of clarifying wording in the PKIX-3 RFC as
long as it is clear that REQUIRED messages must be supported by
conforming software, and that service providers and end users are,
as always, free to configure the software as they see fit.  The thrust
of the clarifying wording should be that PKIX compliance ensures that
software will support varied usage models but does not mandate the
operational use of any particular model.

----
* it does seem self-contradictory to say "mandatory profiles" in the
same sentence as "optional messages" if you don't define "support" to
mean two different things when applied to each.  But don't let that
word-quibble get in the way of the higher-level discussion.

Date: Mon, 25 Aug 1997 12:04:48 +0100
From: Peter Williams <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

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

Carlisle Adams wrote:

> Peter,
>
> Thanks for this message; now it is clear where your logic fell through.
>
> >once again I am understanding this to mean that if/when the CA offers B.8.2
> >mode, it MUST provide service for a user choice of centralised
> >generation and certification of ...an encryption key.
> >
> >If , upon appropriate installation, it does not respond
> >to the procedures specified, it is non-conforming, due to incompleteness.
>
> Yes, centralised generation and certification of a key pair must be
> supported by CAs (this is an important requirement for some
> environments).  Key archival and key recovery services are optional and
> need not be supported by PKIX-3-conformant CAs.
>
> Stephen Kent has argued previously on this list (correctly, of course)
> that key generation and key recovery are not identical.  It is certainly
> possible for a CA to support the former without the latter.
>
> Finally, note (as always) that just because CAs must support key
> generation, there is no requirement that end entities ever have to use
> this.  If they happen to trust their CAs to do certification but not key
> generation, then, as PKIX-3-conformant end entities, they need never ask
> for this.
>
> Thanks for making this distinction clear in everyone's mind.  Are there
> any other red herrings you would like to raise?

So

We have now  2 objectionable issues. A clever attempt
to hide conformance requirements upon All PKIX-3 CAs is
may main thrust in what follows. Built into PKIX-3
evidently is an attempt to deploy a key recovery infrastructure
*capability*; this is masked in various ways through
optional procedures.

"By mandate of IAB", assuming PKIX-3 moves on, every CA product to
be shipped as conforming to PKIX-3 MUST provide for the option
of centralised generation of assymmetric keying material. (This nicely
eliminates Microsoft (beta)  and Netscape current CA products one
notes which cannot even claim to be "based" on PKIX-3
with such a rule.)

All CAs products MUST provide centralised keygen capability for
ALL environments of potential use; they may NOT include such
centralised functionality in (1) one product package (for one market) an
then include it in another (2) product package (for
the domestic US key recovery market, say).

 The first mode (1)  is NON-conforming, despite being
the prevailing practice in the SSL world and S/MIME world,
and being a mode based on RFC 1422 which made no mandatory
requirement upon its CAs for centralised keygen,  and whose (updated) modes of
operation falls within the legitimate scope of this PKIX WG.

(This nicely elimiates the 30,000 sites now using PEM-CA
style SSL certificates, one notes and the existing CAs (public and Netscape
certserver sites) which support them
from even claiming to have system based on PKIX-3. (Nice
bit of standards marketing and/or policy rigging.)

We (PKIX charter respecting members) require 1422-like modes of PKI,
Carlisle; support for the logic of such designs and modes of legitmate
operation, was a promise of participation in this WG; as
evidenced by the charter. See below. There can
be no argument for forcing CA to adopt policies which are
not becoming to their markets, via rigged conformance regulations.

All you are doing, along with the procedure specified in
B.8.2  "PKIArchival" is building in one
of serveral key-recovery capabilitoes into
the Internet PKI whether CA vendors want
to provide  it or not.  Its hidden in the
form of MANDATORY centralised capability
deployment and vague mandatory/optional support for
all the encryption-key POP procedures of B.8.2
which allow for PKI-archival of private-keys.

This requirements policy causes IETFand ABA to be in direct
policy guideline conflict, as it places
CA in the unenviable position of having
to manage private keys merely to certify a public key,
and (potentially) to perform subscriber key generation, merely to certify
a public key. These are fine as deployment options for CAs
and/or subscribers; they are not fine as mandatory features, or conformance
requirements, however indirect.

There is no technical logic in forcing CA to do things which are not required
to certify public keys. Certificate issuing does not technically require
either provision of an archival service, nor does it technically require
provision of a keygen capability for subscriber keys. Period. The
charter does not force any such mode; rathert it allows
for freedom.

I recommend that all and any key recovery and centralised keygen policy be
removed from IETF PKIX-3 technical standards, however indirectly they are
embedded.

We now have two outstanding comments on PKIX-3 :

(1) statement that key recovery is not mandatory (ttest already suggested,
and acceded to in principle)

(2) remove of centralised keygen capability as a MANDATORY implement/ship
(in debate). (Note charter design on this topic.)

--------

Public-Key Infrastructure (X.509) (pkix)

Last Modified: 26-Oct-95

Chair(s):

Stephen Kent <[email-masked]>
Warwick Ford <[email-masked]>

Security Area Director(s):

Mailing Lists:

General Discussion:[email-masked]
To Subscribe: [email-masked]
In Body: subscribe <email address> ietf-pkix
Archive: ftp://ftp.tandem.com/ietf/mailing-lists/current

Description of Working Group:

Many Internet protocols and applications which use the Internet employ public-key technology for
security purposes and require a public-key infrastructure (PKI) to
securely manage public keys for widely-distributed users or systems. The X.509 standard constitutes
a widely-accepted basis for such an infrastructure, defining data
formats and procedures related to distribution of public keys via certificates digitally signed by
certification authorities (CAs). RFC 1422 specified the basis of an
X.509-based PKI, targeted primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).
Since RFC 1422 was issued, application requirements for an
Internet PKI have broadened tremendously, and the capabilities of X.509 have advanced with the
development of standards defining the X.509 version 3 certificate and
version 2 certificate revocation list (CRL).

The task of the working group will be to develop Internet standards needed to support an X.509-based
PKI. The goal of this PKI will be to facilitate the use of X.509
certificates in multiple applications which make use of the Internet and to promote interoperability
between different implementations choosing to make use of X.509
certificates. The resulting PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments
(RFC1422 is an example of one such model).

Candidate applications to be served by this PKI include, but are not limited to, PEM, MOSS, GSS-API
mechanisms (e.g., SPKM), ipsec protocols, Internet payment
protocols, and www protocols. This project will not preclude use of non-infrastructural public-key
distribution techniques nor of non-X.509 PKIs by such applications.
Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++) project.

The group will focus on tailoring and profiling the features available in the v3 X.509 certificate
to best match the requirements and characteristics of the Internet
environment. Other topics to be addressed potentially include:

o Alternatives for CA-to-CA certification links and structures, including guidelines for constraints

o Revocation alternatives, including profiling of X.509 v2 CRL extensions

o Certificate and CRL distribution options (X.500-based, non-X.500-based)

o Guidelines for policy definition and registration

o Administrative protocols and procedures, including certificate generation, revocation
notification, cross-certification, and key-pair updating

o Naming and name forms (how entities are identified, e.g., email address, URN, DN, misc.)

o Generation of client key pairs by the PKI

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

<HTML>
&nbsp;

<P>Carlisle Adams wrote:
<BLOCKQUOTE TYPE=CITE>Peter,

<P>Thanks for this message; now it is clear where your logic fell through.

<P>>once again I am understanding this to mean that if/when the CA offers
B.8.2
<BR>>mode, it MUST provide service for a user choice of centralised
<BR>>generation and certification of ...an encryption key.
<BR>>
<BR>>If , upon appropriate installation, it does not respond
<BR>>to the procedures specified, it is non-conforming, due to incompleteness.

<P>Yes, centralised generation and certification of a key pair must be
<BR>supported by CAs (this is an important requirement for some
<BR>environments).&nbsp; Key archival and key recovery services are optional
and
<BR>need not be supported by PKIX-3-conformant CAs.

<P>Stephen Kent has argued previously on this list (correctly, of course)
<BR>that key generation and key recovery are not identical.&nbsp; It is
certainly
<BR>possible for a CA to support the former without the latter.

<P>Finally, note (as always) that just because CAs must support key
<BR>generation, there is no requirement that end entities ever have to
use
<BR>this.&nbsp; If they happen to trust their CAs to do certification but
not key
<BR>generation, then, as PKIX-3-conformant end entities, they need never
ask
<BR>for this.

<P>Thanks for making this distinction clear in everyone's mind.&nbsp; Are
there
<BR>any other red herrings you would like to raise?</BLOCKQUOTE>
So

<P>We have now&nbsp; 2 objectionable issues. A clever attempt
<BR>to hide conformance requirements upon All PKIX-3 CAs is
<BR>may main thrust in what follows. Built into PKIX-3
<BR>evidently is an attempt to deploy a key recovery infrastructure
<BR>*capability*; this is masked in various ways through
<BR>optional procedures.

<P>&nbsp;<BR>
"By mandate of IAB", assuming PKIX-3 moves on, every CA product to
<BR>be shipped as conforming to PKIX-3 MUST provide for the option
<BR>of centralised generation of assymmetric keying material. (This nicely
<BR>eliminates Microsoft (beta)&nbsp; and Netscape current CA products
one
<BR>notes which cannot even claim to be "based" on PKIX-3
<BR>with such a rule.)

<P>All CAs products MUST provide centralised keygen capability for
<BR>ALL environments of potential use; they may NOT include such
<BR>centralised functionality in (1) one product package (for one market)
an
<BR>then include it in another (2) product package (for
<BR>the domestic US key recovery market, say).
<BR><BR>
&nbsp;The first mode (1)&nbsp; is NON-conforming, despite being
<BR>the prevailing practice in the SSL world and S/MIME world,
<BR>and being a mode based on RFC 1422 which made no mandatory
<BR>requirement upon its CAs for centralised keygen,&nbsp; and whose (updated)
modes of
<BR>operation falls within the legitimate scope of this PKIX WG.

<P>(This nicely elimiates the 30,000 sites now using PEM-CA
<BR>style SSL certificates, one notes and the existing CAs (public and
Netscape
<BR>certserver sites) which support them
<BR>from even claiming to have system based on PKIX-3. (Nice
<BR>bit of standards marketing and/or policy rigging.)

<P>We (PKIX charter respecting members) require 1422-like modes of PKI,
<BR>Carlisle; support for the logic of such designs and modes of legitmate
<BR>operation, was a promise of participation in this WG; as
<BR>evidenced by the charter. See below. There can
<BR>be no argument for forcing CA to adopt policies which are
<BR>not becoming to their markets, via rigged conformance regulations.

<P>All you are doing, along with the procedure specified in
<BR>B.8.2&nbsp; "PKIArchival" is building in one
<BR>of serveral key-recovery capabilitoes into
<BR>the Internet PKI whether CA vendors want
<BR>to provide&nbsp; it or not.&nbsp; Its hidden in the
<BR>form of MANDATORY centralised capability
<BR>deployment and vague mandatory/optional support for
<BR>all the encryption-key POP procedures of B.8.2
<BR>which allow for PKI-archival of private-keys.

<P>This requirements policy causes IETFand ABA to be in direct
<BR>policy guideline conflict, as it places
<BR>CA in the unenviable position of <B>having</B>
<BR><B>to manage private keys merely to certify a public key</B>,
<BR>and (potentially)<B> to perform subscriber key generation, merely to
certify</B>
<BR><B>a public key</B>. These are fine as deployment options for CAs
<BR>and/or subscribers; they are not fine as mandatory features, or conformance
<BR>requirements, however indirect.

<P>There is no technical logic in forcing CA to do things which are not
required
<BR>to certify public keys. Certificate issuing does not technically require
<BR>either provision of an archival service, nor does it technically require
<BR>provision of a keygen capability for subscriber keys. Period. The
<BR>charter does not force any such mode; rathert it allows
<BR>for freedom.

<P>I recommend that all and any key recovery and centralised keygen policy
be
<BR>removed from IETF PKIX-3 technical standards, however indirectly they
are
<BR>embedded.
<BR>&nbsp;

<P>We now have two outstanding comments on PKIX-3 :

<P>(1) statement that key recovery is not mandatory (ttest already suggested,
<BR>and acceded to in principle)

<P>(2) remove of centralised keygen capability as a MANDATORY implement/ship
<BR>(in debate). (Note charter design on this topic.)

<P>--------
<BR>&nbsp;
<BR>&nbsp;

<P>Public-Key Infrastructure (X.509) (pkix)

<P>Last Modified: 26-Oct-95

<P>Chair(s):

<P>Stephen Kent &lt;[email-masked]>
<BR>Warwick Ford &lt;[email-masked]>

<P>Security Area Director(s):

<P>Mailing Lists:

<P>General Discussion:[email-masked]
<BR>To Subscribe: [email-masked]
<BR>In Body: subscribe &lt;email address> ietf-pkix
<BR>Archive: <A HREF="ftp://ftp.tandem.com/ietf/mailing-lists/current">ftp://ftp.tandem.com/ietf/mailing-lists/current</A>

<P>Description of Working Group:

<P>Many Internet protocols and applications which use the Internet employ
public-key technology for security purposes and require a public-key infrastructure
(PKI) to
<BR>securely manage public keys for widely-distributed users or systems.
The X.509 standard constitutes a widely-accepted basis for such an infrastructure,
defining data
<BR>formats and procedures related to distribution of public keys via certificates
digitally signed by certification authorities (CAs). RFC 1422 specified
the basis of an
<BR>X.509-based PKI, targeted primarily at satisfying the needs of Internet
Privacy Enhanced Mail (PEM). Since RFC 1422 was issued, application requirements
for an
<BR>Internet PKI have broadened tremendously, and the capabilities of X.509
have advanced with the development of standards defining the X.509 version
3 certificate and
<BR>version 2 certificate revocation list (CRL).

<P>The task of the working group will be to develop Internet standards
needed to support an X.509-based PKI. The goal of this PKI will be to facilitate
the use of X.509
<BR>certificates in multiple applications which make use of the Internet
and to promote interoperability between different implementations choosing
to make use of X.509
<BR>certificates. The resulting PKI is intended to provide a framework
which will support a range of trust/hierarchy environments and a range
of usage environments
<BR>(RFC1422 is an example of one such model).

<P>Candidate applications to be served by this PKI include, but are not
limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols,
Internet payment
<BR>protocols, and www protocols. This project will not preclude use of
non-infrastructural public-key distribution techniques nor of non-X.509
PKIs by such applications.
<BR>Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++)
project.

<P>The group will focus on tailoring and profiling the features available
in the v3 X.509 certificate to best match the requirements and characteristics
of the Internet
<BR>environment. Other topics to be addressed potentially include:

<P>o Alternatives for CA-to-CA certification links and structures, including
guidelines for constraints

<P>o Revocation alternatives, including profiling of X.509 v2 CRL extensions

<P>o Certificate and CRL distribution options (X.500-based, non-X.500-based)

<P>o Guidelines for policy definition and registration

<P>o Administrative protocols and procedures, including certificate generation,
revocation notification, cross-certification, and key-pair updating

<P>o Naming and name forms (how entities are identified, e.g., email address,
URN, DN, misc.)

<P>o Generation of client key pairs by the PKI</HTML>

--------------4E62195EFA4241217DA07C2B--

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: key recovery options for PKIX-3 CAs?
Date: Mon, 25 Aug 1997 11:40:24 -0400

Peter,

Thanks for this message; now it is clear where your logic fell through.

>once again I am understanding this to mean that if/when the CA offers B.8.2
>mode, it MUST provide service for a user choice of centralised
>generation and certification of ...an encryption key.
>
>If , upon appropriate installation, it does not respond
>to the procedures specified, it is non-conforming, due to incompleteness.

Yes, centralised generation and certification of a key pair must be
supported by CAs (this is an important requirement for some
environments).  Key archival and key recovery services are optional and
need not be supported by PKIX-3-conformant CAs.  

Stephen Kent has argued previously on this list (correctly, of course)
that key generation and key recovery are not identical.  It is certainly
possible for a CA to support the former without the latter.

Finally, note (as always) that just because CAs must support key
generation, there is no requirement that end entities ever have to use
this.  If they happen to trust their CAs to do certification but not key
generation, then, as PKIX-3-conformant end entities, they need never ask
for this.

Thanks for making this distinction clear in everyone's mind.  Are there
any other red herrings you would like to raise?

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Sender: [email-masked]
Date: Mon, 25 Aug 1997 14:03:06 +0200
From: Hans Schupp <[email-masked]>
Organization: GMD - TKT.SIT
To: [email-masked]
CC: [email-masked]
Subject: Re: [Fwd: X.509-Certificate-Decoder]

Ingmar Camphausen wrote:

> Furthermore, you could get the beta version of the security software
> toolkit "SECUDE" from the German Research Center for Information
> Technology (GMD), Darmstadt, via
> http://www.darmstadt.gmd.de/secude/51b/
> (Sorry, no source code, but binaries for the most common platforms are
> available.) It comprises -- among others -- the utilities 'asn1show'
> and 'asn1dump' which could be useful for you.

I just wanted to announce, that in the newest preview release
(http://www.darmstadt.gmd.de/secude/51pr2/), additional to the asn1dump
and asn1show utilities, there is also a new utility ("asn1wrap"), that
allows to construct ASN.1 BER/DER encodings from the command line or
from scripts.

I found this really useful, when experimenting with prototype decoding
functions.

Together with asn1dump, it is quite powerful also for constructing and
manipulating larger structures (see documentation at
http://www.darmstadt.gmd.de/secude/51pr2/Doc/htm/utasn1wr.htm and
http://www.darmstadt.gmd.de/secude/51pr2/Doc/htm/utasn1du.htm)

best regards, Hans Schupp
-- 
===============================================================================
 Hans Schupp, GMD - German National		eMail: [email-masked]
 Research Center for Information Technology,	
 Institute for Telecooperation Technology	Tel:  +49-6151-869-715
 Dolivostrasse 15, D-64293 Darmstadt, GERMANY	Fax:  +49-6151-869-704
===============================================================================

Date: Sun, 24 Aug 1997 16:47:34 -0400
From: Dwight Arthur <[email-masked]>
To: Mike Smith <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: manual keying and IPSEC conformance

Mike Smith wrote:
> 
> "Trust chains Always begin at the verifier".  In a situation where a
> corporation has established (or outsourced) a CA function, the
> "verifiers" would be in the trust hierarchy of the corporation, not at
> the individual.  I believe that the corporate CA would be the entity
> specifying or allowing THEIR trust to be extended to extrnal entities
> (such as authorized vendors' CAs, etc.)
> 
> Michael
> 
> >>> David P. Kemp <[email-masked]> 08/21/97 08:31AM >>>
> > From: Ran Atkinson  <[email-masked]>
> >
> > In the X.509 arena there are MANY folks in the CA business competing
> with
> > each other, but cross-certification is not yet an element of the
> real world.
> > What if I want to talk with user FOO, but I use CA==X, FOO uses
> CA==Y
> > where (Y!=X) and (X,Y don't cross certify each other) -- result, no
> secure packets.
> 
> This is a common misperception about X.509.  The ISO/ITU X.509
> standard
> has always explicitly supported arbitrary trust chaining paths (a.k.a.
> "web-of-trust") but, perhaps due to the PEM experience, most IETF'ers
> seem to regard X.509 as requiring strict single-rooted or
> cross-certified multiply-rooted hierarchies.
> 
> Kudos to the SPKI folks for making explicit the notion that trust
> chains
> always begin at the verifier.  The PKIX folks perhaps should add some
> verbiage that makes it clearer that the verifier can choose to trust
> whomever it wants.  That verbiage shouldn't be necessary, but there is
> apparently a huge PEM legacy-of-perception that needs to be erased.
> 
> In the IPsec case, if Ran "uses" (has a certificate issued by) CA==X,
> and FOO has a certificate from CA==Y, there is not necessarily a
> problem.
> As long as Ran's machine has a Ran-issued cert for CA==Y
> stating that Ran trusts Y to certify IPsec nodes (perhaps with
> name space or policy constraints), then there is no need for X and Y
> to be cross certified.
> 
> More generally, each administrative domain would have a single
> root public key, each node within the domain would trust *only* that
> root key, and the domain root would certify *all* CAs which are to be
> trusted by nodes within the domain.  The same mechanism is used to
> address the privilege side of the compartmented information problem
> that was recently brought up.  (The other side of the problem is
> data labelling.)
> 
> 
The American Bar Association is discussing nine models of PKI, including
"open pki" where all trust chains lead to a CA doing business with the
public, like Verisign or Thawte, "closed pki" where my CA issues certs
that are usable only in my systems (eg Bank X certs usable only to
access Bank X accounts via Bank X websites) and "membership pki" which I
think is close to what Mike is discussing.

Date: Fri, 22 Aug 1997 16:50:47 +0100
From: Peter Williams <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

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

Carlisle Adams wrote:

> I am intrigued by your long and complicated line of reasoning.  I am
> also wondering just where it is that you went wrong (for your conclusion
> is most certainly wrong).  Key recovery is not mandated, period.  For
> CAs/RAs or for end entities.  The text I quoted is very clear about this
> and the process you went through does not contradict this.

     "2.2.2 Mandatory schemes

     The criteria above allow for a large number of initial registration /
     certification schemes. This specification mandates that conforming CA
     equipment must support both of the schemes listed below and conforming
     RA equipment must support the second scheme listed below. Conforming
     end entity equipment must support at least one of the schemes listed
     below.

     2.2.2.1 Centralised scheme
     2.2.2.2 Basic authenticated scheme"

Then,

      "Appendix B. PKI management message profiles.

     This appendix contains detailed profiles for those PKIMessages which
     must be supported by conforming implementations.

     [...]

     - - initial registration and certification
             - centralised scheme
             - basic authenticated scheme"

I am understanding this all to say (and believe me I am reading very carefully, perhaps
too carefully!)  - A conforming CA product will have to support all these profiles,
and with each of the procedures specified for them. In the case of the quoted profile,
(intial registration and certification) this is seriously reinforced by earlier text, quoted above.

A CA product which does not offer the site the option to install a "centralised scheme"
(offering only the basic authenticated scheme) will be non-conforming (due
to incompleteness) when tested against a conformance suite.

Perhaps this is where I am misunderstanding. What it says, and what it means
are possibly different things.

     B8.2 Basic authenticated scheme

     The end entity requests a certificate from a CA. When the CA responds
     with a message containing a certificate the end entity replies with a
     confirmation. All messages are authenticated.

     This scheme allows the end entity to request certification of a locally-
     generated public key (typically a signature key). The end entity may
     also choose to request the centralised generation and certification of
     another key pair (typically an encryption key pair).

once again I am understanding this to mean that if/when the CA offers B.8.2
mode, it MUST provide service for a user choice of centralised
generation and certification of ...an encryption key.

If , upon appropriate installation, it does not respond
to the procedures specified, it is non-conforming, due to incompleteness.

Perhaps this is where I am misunderstanding. 'If the PKIX-3
conformance test suite starts doing its B8.2 PKIArchive procedure
during basic authenticated procedure, with a CA
responder which does not offer it, the CA system will be deemed
non-conforming.'

-----------

By the way, it is a really *good* sign when folk start arguing about mandatory
and optional stuff. It means the mechanisms per se are seen
as satisfying the requirements, and that the requirement set is sufficient
for the scoped problem.

Making a swath of multi-vendor products interwork now is of course a
completely different issue.

Peter.

Peter.

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

<HTML>
&nbsp;

<P>Carlisle Adams wrote:
<BLOCKQUOTE TYPE=CITE>I am intrigued by your long and complicated line
of reasoning.&nbsp; I am
<BR>also wondering just where it is that you went wrong (for your conclusion
<BR>is most certainly wrong).&nbsp; Key recovery is not mandated, period.&nbsp;
For
<BR>CAs/RAs or for end entities.&nbsp; The text I quoted is very clear
about this
<BR>and the process you went through does not contradict this.</BLOCKQUOTE>
&nbsp;
<UL>"2.2.2 Mandatory schemes&nbsp;

<P>The criteria above allow for a large number of initial registration
/
<BR>certification schemes. <B>This specification mandates that conforming
CA</B>
<BR><B>equipment <U>must support</U></B><U> <B>both</B></U><B> of the schemes
listed below</B> and conforming
<BR>RA equipment must support the second scheme listed below. Conforming
<BR>end entity equipment must support at least one of the schemes listed
<BR>below.

<P>2.2.2.1 Centralised scheme
<BR>2.2.2.2 Basic authenticated scheme"
<BR>&nbsp;</UL>
Then,
<UL>&nbsp;"Appendix B. PKI management message profiles.

<P>This appendix contains detailed profiles for<B> those PKIMessage</B>s
which
<BR><B>must be supported by conforming implementations</B>.

<P>[...]

<P>- - initial registration and certification
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - centralised scheme
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - <B>basic authenticated
scheme</B>"</UL>
I am understanding this all to say (and believe me I am reading very carefully,
perhaps
<BR>too carefully!)&nbsp; - A conforming CA product will have to support
all these profiles,
<BR>and with each of the procedures specified for them. In the case of
the quoted profile,
<BR>(intial registration and certification) this is seriously reinforced
by earlier text, quoted above.

<P>A CA product which does not offer the site the option to install a "centralised
scheme"
<BR>(offering only the basic authenticated scheme) will be non-conforming
(due
<BR>to incompleteness) when tested against a conformance suite.

<P>Perhaps this is where I am misunderstanding. What it says, and what
it means
<BR>are possibly different things.
<BR>&nbsp;
<UL>B8.2 Basic authenticated scheme

<P>The end entity requests a certificate from a CA. When the CA responds
<BR>with a message containing a certificate the end entity replies with
a
<BR>confirmation. All messages are authenticated.

<P>This scheme allows the end entity to request certification of a locally-
<BR>generated public key (typically a signature key).<B> The end entity
may</B>
<BR><B>also choose to request </B>the centralised generation and certification
of
<BR>another key pair (typically an encryption key pair).
<BR>&nbsp;</UL>
once again I am understanding this to mean that if/when the CA offers B.8.2
<BR>mode, it MUST provide service for a user choice of centralised
<BR>generation and certification of ...an encryption key.

<P>If , upon appropriate installation, it does not respond
<BR>to the procedures specified, it is non-conforming, due to incompleteness.

<P>Perhaps this is where I am misunderstanding. 'If the PKIX-3
<BR>conformance test suite starts doing its B8.2 PKIArchive procedure
<BR>during basic authenticated procedure, with a CA
<BR>responder which does not offer it, the CA system will be deemed
<BR>non-conforming.'
<BR>&nbsp;
<BR>-----------

<P>By the way, it is a really *good* sign when folk start arguing about
mandatory
<BR>and optional stuff. It means the mechanisms per se are seen
<BR>as satisfying the requirements, and that the requirement set is sufficient
<BR>for the scoped problem.

<P>Making a swath of multi-vendor products interwork now is of course a
<BR>completely different issue.

<P>Peter.

<P>Peter.</HTML>

--------------D26F75B6C7C97595251B5045--

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: key recovery options for PKIX-3 CAs?
Date: Fri, 22 Aug 1997 17:56:14 -0400

Hi Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Friday, August 22, 1997 7:31 AM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'
>Subject: 	Re: key recovery options for PKIX-3 CAs?
>
>Lets do some classical analysis and commenting, then, particular
>on text which is reputed to have nothing to do with key
>recovery, or mandatory requirements on CAs, by you own (implied) admission.

I am intrigued by your long and complicated line of reasoning.  I am
also wondering just where it is that you went wrong (for your conclusion
is most certainly wrong).  Key recovery is not mandated, period.  For
CAs/RAs or for end entities.  The text I quoted is very clear about this
and the process you went through does not contradict this.

Let me make some guesses about where you might have missed something
important.

1) PKIArchiveOptions is OPTIONAL everywhere in the document (including
the profiles in Appendix B).  In other words, it never needs to be used
(unless an end entity wants its private key archived AND the CA/RA
happens to support this function).

2) Proof of Possession (even of the private decryption key) does not
require that the CA/RA know or have access to the private key.  The
method for doing this for encryption key pairs is detailed on page 29.
One of the three methods given allows for the case in which the CA/RA
receives the private key; the other two handle the case in which the
CA/RA does not know the private key.

3) The "basic authenticate scheme" in Appendix B is intended to cover
the case in which a locally-generated key is sent to the CA for
certification.  It can also (optionally) allow the end entity to request
that the CA generate a key pair and return the certificate and private
key.

Note very carefully what is said (p. 56):

"This scheme allows the end entity to request certification of a
locally-generated public key (typically a signature key).  The end
entity may also choose to request the centralised generation and
certification of another key pair (typically an encryption key pair)."

It is not mandated that the locally-generated key pair is for signing;
we simply note that this will typically be the case.  It is also not
mandated that the centrally-generated key pair is for encryption, though
I doubt that many environments will choose to generate signing key pairs
at the CA.  Thus, you conform perfectly well to the basic authenticated
scheme if your certification request is for a locally-generated
encryption key pair and you don't ask for a centrally-generated key pair
/ certificate.  Since proof-of-possession can then be done for this
encryption key pair without the CA/RA knowing the private decryption
key, there is no mandated key recovery.

>Its clear the profile is prejudiced towards centralised generation of
>encryption
>keys/certs (though less so than in B8.1) and this sub-profile is a mandatory
>support feature, note.

Absolutely wrong.  The protocol allows for centralised generation of
encryption keys/certs because it has to (in order to be useful in some
environments).  It does not mandate it; it does not even encourage it.
It is not clear to me how you can argue from this that there is a
prejudice in this direction.

>As far as I can judge, key recovery capability (and centralised keygen) by CA
>products/services is  effectively mandatory in PKIX-3. (via the configuration
>of protocol, the
>bias towards separation of signing/encryption keys,
>the difficulty of doing POP with non-reversible algorithms in such cases, the
>general design-bias towards centralised encryption key maintenance clear in
>the
>authors minds.
>
>Conclusion:
>
>PKIX-3seems to require CAs to offer centralised keygen, in its base profile,
>and effectively
>forces CAs to know the value of subscribers private keys
>when a mandatory conforming option is requested.

Unfortunately your analysis was faulty, or your reasoning was flawed, or
you misread something, or you skimmed over some important detail.  In
any case, your conclusion is wrong.

>Carlisle; I am not seeking to impute any intent other than your endeavoring
>to
>ensure technical adequacy in this work. I recommend you make an explicit
>statement
>that key-archival/recovery etc is not a mandatory feature for conformance, to
>be 100% clear,
>through explicit language.
>
>I suggest you conspicuously add to PKIX-3, allowing for David's objection
>and to overcome the unacceptable mandatory nature of B.8.2 sentence 5.
>
>consider adding:-
>
>"CAs/LRAs are not required to support PKI Archival or key backup
>procedures specified in this document. No mandatory profiles specified by
>PKIX-3 require
>or imply support of these optional messages and procedures, nor mandate
>support for centralised key generation. See RFC1984 for information
>when designing  PKIX-3  operational profiles considering the requirements
>for archival or backup of private keys, or centralised key generation."
>
>I for one will then be happy with PKIX-3 on this key recovery issue.

I think we all know that few things will make me happier than to make
you happy...  I truly believe that the document is perfectly clear on
this issue, but I will consider adding the text above if I hear from
others on this list supporting this addition.  Any suggestion as to
where it should go (so no one misses it and comes to the conclusion that
I was trying to hide it)?

>This exercise has demonstrated to me a serious problem of complexity of
>PKIX-3
>by the way. The side-effects and reliance upon signals to support all the
>modes of
>operation, most of which are security critical,  are very hard to analyse,
>speaking
>as a reviewer and potential implementor, even for the base profiles.

The protocol is complex (because of all the requirements and
environments it is trying to satisfy).  The profiling in Appendix B
helps, but cannot make it "simple".  Unfortunately this is a necessary
side-effect of trying to define a Public-Key Infrastructure for the
Internet.  We have done our best to make PKIX-3 as general, and yet as
usable, as possible.  I think we, as a Working Group, have achieved a
good balance, but the document still requires a few careful readings to
avoid faulty assumptions and conclusions.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Fri, 22 Aug 1997 12:31:31 +0100
From: Peter Williams <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

Carlisle Adams wrote:

>
>
> Let's see what the current spec. has to say on this topic.  Section 4:
> Mandatory PKI Management functions (p.36):
>
> "This section deals with functions that are "mandatory" in the sense
> that all end entity and CA/RA implementations must be able to provide
> functionality described via one of the transport mechanisms defined in
> section 5.  This part is effectively the profile of the PKI management
> functionality that must be supported."
>
> As you look at the operations listed in Section 4 you discover that key
> recovery is not there.  I would find it surprising if anyone needed more
> clarity than this.
>
> Honestly, Peter, I sometimes wonder if you've read this document at all.

I need more clarity, given the following:-

-----------

I *am* reading PKIX-3 most carefully, along with the interpretations given in the
WG minutes, the list archive, and some IETF-related-public external forums which
strongly signal intended meaning.

I note you say, the key recovery/backup is neither mentioned in other than
2 lines, and is not a part of the (current set) of mandatory profiles for
conformance.

Lets do some classical analysis and commenting, then, particular
on text which is reputed to have nothing to do with key
recovery, or mandatory requirements on CAs, by you own (implied) admission.

"3.2.6 Archive Options

Requesters may indicate that they wish the PKI to archive a private key
value using the following structure:

  PKIArchiveOptions ::=3D CHOICE {
      encryptedPrivKey     [0] EncryptedValue,
      -- the actual value of the private key
      keyGenParameters     [1] KeyGenParameters,
      -- parameters which allow the private key to be re-generated
      archiveRemGenPrivKey [2] BOOLEAN
      -- set to TRUE if sender wishes receiver to archive the private
      -- key of a key pair which the receiver generates in response to
      -- this request; set to FALSE if no archival is desired.
  }"

turns out to be an interesting piece of specification. Not only is
this structure about archival of private keys by "PKIs", its a vital piece of the
mandatory procedures section along with the FullCertTemplate message
design. it seems, PKIX-3 also allows via this structure the recovery
of the archived key by any (authenticated) third party.

The apparent purpose of this protocol element is two fold, it appears to me:

(1) do key backup of local keygen (PKI archival seems another name for the same thing)
(2) do POP when a policy separates signing and encryption certs/keys, and
encryption certs need to demo POP.

Lets look at the mandatory conformance requirements:-

"B4. Proof of Possession Profile

"popo" fields for use when proving possession of a private signing key
which corresponds to a public verification key for which a certificate
has been requested.

 Field               Value         Comment

 alg                 MSG_SIG_ALG   only signature protection is
                                   allowed for this proof
 signature           present       bits calculated using MSG_SIG_ALG

<<Proof of possession of a private decryption key which corresponds to a

public encryption key for which a certificate has been requested does
not use this profile; instead the method given in protectionAlg for
PKIConfirm in Section B.8.2 is used.>>"

(NB: this does not cover the case where a key is multi-use, as allowed
in PKIX-1 if I understand Tim's pre-Munich PKIX-1
changes summary message, wholly).

Lets look at B.8.2 (which seems not to allow CAs who only
certify encryption keys: seem to force subscribers to have BOTH
a signature and encryption capability)

"[..]" its too long to quote. Read it folks.

This makes PKIArchive mandatory, and to enable encryption cert POP
makes the "basic authentication" proof mechanism of POP be
mandatory.

Its clear the profile is prejudiced towards centralised generation of encryption
keys/certs (though less so than in B8.1) and this sub-profile is a mandatory
support feature, note.

As far as I can judge, key recovery capability (and centralised keygen) by CA
products/services is  effectively mandatory in PKIX-3. (via the configuration of protocol, the
bias towards separation of signing/encryption keys,
the difficulty of doing POP with non-reversible algorithms in such cases, the
general design-bias towards centralised encryption key maintenance clear in the
authors minds.

Conclusion:

PKIX-3seems to require CAs to offer centralised keygen, in its base profile, and effectively
forces CAs to know the value of subscribers private keys
when a mandatory conforming option is requested.

Effectively PKIX-3 contains protocol and procedures for key recovery.
There are no requirements that CA only respond to archival request
by subcribers, for example: an FBI agent could be the party
who is authenticated during recovery from archive.

As I suspected, it seems that PKIX-3 CAs are being forced to support
key recovery/backup/archival/escrow, by mandatory profile options, and
the construction of the data flows and procedures.

Carlisle; I am not seeking to impute any intent other than your endeavoring to
ensure technical adequacy in this work. I recommend you make an explicit statement
that key-archival/recovery etc is not a mandatory feature for conformance, to be 100% clear,
through explicit language.

I suggest you conspicuously add to PKIX-3, allowing for David's objection
and to overcome the unacceptable mandatory nature of B.8.2 sentence 5.

consider adding:-

"CAs/LRAs are not required to support PKI Archival or key backup
procedures specified in this document. No mandatory profiles specified by PKIX-3 require
or imply support of these optional messages and procedures, nor mandate
support for centralised key generation. See RFC1984 for information
when designing  PKIX-3  operational profiles considering the requirements
for archival or backup of private keys, or centralised key generation."

I for one will then be happy with PKIX-3 on this key recovery issue.

-----

This exercise has demonstrated to me a serious problem of complexity of PKIX-3
by the way. The side-effects and reliance upon signals to support all the modes of
operation, most of which are security critical,  are very hard to analyse, speaking
as a reviewer and potential implementor, even for the base profiles.

Its a tremendous accomplishment intellectually, though.

Peter.

Date: Fri, 22 Aug 1997 12:57:11 -0500 (CDT)
From: "Brian M. Thomas" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: manual keying and IPSEC conformance

The verifier is the entity making the trust decision.  Truly enough, it
must decide in accordance with the corporate policy, as expressed by the
corporate CA.  However, the dumb little program doesn't have any way of
knowing that the expression of that policy it works with is valid, absent
some verifiable assertion of the fact.  The only key the program can trust
ultimately is its own.  The verifier is therefore the root of the trust
chain.  This is true whether the trust is implicit, via a configuration
file or the compiling in of the CA's key (as in your example), or explicit,
via a certificate.

The analogy to the human world is direct.  If my signature on a
document is binding on the corporation, I am under obligation to follow
the policies of the corporation in signing it.  However, there is no
way to force me to follow policies in my signing of documents; only to
punish me if I don't.  I still must choose to trust whomever the
corporate decision-makers say they trust, even though your point is
valid in that they have extended trust to me to act in accordance with
their wishes.  

brian

Brian Thomas, CISSP - Distributed Systems Architect  [email-masked]
Southwestern Bell                                    [email-masked]
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: key recovery options for PKIX-3 CAs?
Date: Fri, 22 Aug 1997 13:06:41 -0400

Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Thursday, August 21, 1997 5:53 AM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'
>Subject: 	Re: key recovery options for PKIX-3 CAs?
>
>
>
>Carlisle Adams wrote:
>
>> Hi,
>>
>> I'm sorry Peter, but David makes an excellent point here.  I think we'll
>> have to leave PKIX-3 unchanged on this issue...
>
>Does he indeed? 

Yes, he does.

>-------
>
>Tell us - must a CA product (or an Internet service derived from that
>product) provide a capability to do client key backup
>to be a conforming implementation of PKIX-3?
>
>If the answer is no: make a clear, conspicuous statement in the document.
>
>If the answer is yes: propose such a clear statement for the document.
>
>--------
>
>tell us - must as UA product doing PKIX-3 provide a capability
>to interface to a CA/LRA's key backup capability
>to be a conforming implementation of PKIX-3?
>
>If the answer is no: make a clear, conspicuous statement in the document.
>
>If the answer is yes: propose such a clear statement for the document.
>
>-------------
>
>All I am asking, is ; is the conformance/optionaliy structure being
>rigged to force CA folk to provide key recovery - by one
>political means or another?
>
>Its easy to ensure this is not the case, note. mere clarity
>and 2 sentences is all it requires.

Let's see what the current spec. has to say on this topic.  Section 4:
Mandatory PKI Management functions (p.36):

"This section deals with functions that are "mandatory" in the sense
that all end entity and CA/RA implementations must be able to provide
functionality described via one of the transport mechanisms defined in
section 5.  This part is effectively the profile of the PKI management
functionality that must be supported."

As you look at the operations listed in Section 4 you discover that key
recovery is not there.  I would find it surprising if anyone needed more
clarity than this.

Honestly, Peter, I sometimes wonder if you've read this document at all.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Fri, 22 Aug 1997 18:51:19 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Peter Williams <[email-masked]>
cc: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

Hiya

Damn!  I have to agree with Peter ;-)

--
Mark Shuttleworth
Thawte Consulting

Date: Fri, 22 Aug 1997 10:49:16 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: manual keying and IPSEC conformance

"Trust chains Always begin at the verifier".  In a situation where a corporation has established (or outsourced) a CA function, the "verifiers" would be in the trust hierarchy of the corporation, not at the individual.  I believe that the corporate CA would be the entity specifying or allowing THEIR trust to be extended to extrnal entities (such as authorized vendors' CAs, etc.)

Michael

>>> David P. Kemp <[email-masked]> 08/21/97 08:31AM >>>
> From: Ran Atkinson  <[email-masked]>
>
> In the X.509 arena there are MANY folks in the CA business competing with 
> each other, but cross-certification is not yet an element of the real world.
> What if I want to talk with user FOO, but I use CA==X, FOO uses CA==Y 
> where (Y!=X) and (X,Y don't cross certify each other) -- result, no secure packets.

This is a common misperception about X.509.  The ISO/ITU X.509 standard
has always explicitly supported arbitrary trust chaining paths (a.k.a.
"web-of-trust") but, perhaps due to the PEM experience, most IETF'ers
seem to regard X.509 as requiring strict single-rooted or
cross-certified multiply-rooted hierarchies.

Kudos to the SPKI folks for making explicit the notion that trust chains
always begin at the verifier.  The PKIX folks perhaps should add some
verbiage that makes it clearer that the verifier can choose to trust
whomever it wants.  That verbiage shouldn't be necessary, but there is
apparently a huge PEM legacy-of-perception that needs to be erased.

In the IPsec case, if Ran "uses" (has a certificate issued by) CA==X,
and FOO has a certificate from CA==Y, there is not necessarily a problem.
As long as Ran's machine has a Ran-issued cert for CA==Y
stating that Ran trusts Y to certify IPsec nodes (perhaps with
name space or policy constraints), then there is no need for X and Y
to be cross certified.

More generally, each administrative domain would have a single
root public key, each node within the domain would trust *only* that
root key, and the domain root would certify *all* CAs which are to be
trusted by nodes within the domain.  The same mechanism is used to
address the privilege side of the compartmented information problem
that was recently brought up.  (The other side of the problem is
data labelling.)

                                                                      

Date: Thu, 21 Aug 1997 16:02:02 +0100
From: Peter Williams <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX-3 and PKCS7/10

David P. Kemp wrote:      PKIMessage ContentInfo ::= SEQUENCE {

>       contentType OBJECT IDENTIFIER,
>       content [0]
>     }
>
> (I'm not an ASN.1 expert, so I don't quite grok this definition with
> two LHS expressions on the first line.)

The values of the type you quote are polymorphic values - or abstract values, as
ISO would say. The sub-type value are  the PKIX-3 information object
class members - or object from any  key management protocol elements in
other protocols which may accompany PKIX-3 in the application context. \

This is how we here would extend PKIX to do
commercial/billing and other functions, rather than break interoperability.. A coherent
extensibility model is a requirement of commercial grade protocols which can
still create an open systems, multi-vendor, infrastructure.

The ContentInfo is essentially a header (info about content) for an opaque binary
string contained in content, and tagged with [context 0]. That is, you stuff
the existing serialised PKIX-3 information object into the value component
of the [context 0]-tagged BER TLV, at the leaf of such an encapsulation
tree.

If one uses the PKCS7 protection types (which would in ISO
quality specs be written as parameterised types), then the type
introduces the protection mechanism, which envelops the payload.

Perhaps we should reuse the textual material from SET spec, where this
technology and a PKCS7 PKI is already specified more
formally ? I hate to force ASN.1 on the IETF, though.

The leaf object identifier of a series
of content-info types can signal either the specific PKIX-3 object,
or PKIX-3. The latter case requires UA to support certain options
in the PKIX-3 specification which allow payload  messages  to self-identify the
abstract syntax using look-ahead parsing, or
require all PKCS7 UAs to use the authenticated attributes approach
to signalling, or assume the context has the transaction info.

The best approach was left open for now, being far to subtle an technical issue to
discuss, when one is still discussing basic roles. The issue prejudices open component
markets,  as the PKCS7 modules would have to know to allow for look-ahead
parsing, rather than opaque message handing; some design & old vs new
infrastructure rollout and reuse tradeoff issues present here. On the other
hand, restricting PKCS7 when used as an external bodypart
to only those modes which provide authenticated attributes is not desirable
when we move to elliptic curves variants of PKCS7, and want to  use
the SignedAndEnveloped parameterised type.

IN some cases the Adams.PKIMessage.PKIHeader control information
will infact be handled by the session layer using application
entity titles, and thus I didnt want to prejudice forcing PKCS7 to handle transaction-centric
data when the stack service may perform these roles, and
the session layer may manage the transactioning and recovery.

Hope this helps understanding.

Id like to hold off discussion of this kind of detail and subjective
judgement until we get scope and basic structure
sorted, and elementary requirements agreed.

Lets deal with Carlise's "Flaws" first. These fundamental PKCS7 "flaws" must also
be apparent in SET protocol. So indirect SET certificate management
protocol review is a benefit of this IETF activity.

Peter.

Date: Thu, 21 Aug 1997 17:23:07 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX-3 and PKCS7/10

> From: Peter Williams <[email-masked]>
> 
> All that is happening is that a toolkit of external protection mechanisms
> is being advanced. One raw PKCS7 example already comes with the PKIX-3, David;
> Another is being advanced as an ID. Technical comments are
> most welcome on the ID, though, and its relationship model.

Let me be concrete, and discuss a 3-layer model.

1) The innermost layer is a set of unprotected messages.
2) The next layer applies cryptographic protection to those messages.
3) The third layer transports the protected messages over some protocol
    (smtp, http, ftp, tcp/ip, ldap, etc).

PKIX-3 defines a PKIMessage as:

   PKIMessage ::= SEQUENCE {
      header         PKIHeader,
      body           PKIBody,
      protection [0] PKIProtection OPTIONAL,
      extraCerts [1] SEQUENCE OF Certificate OPTIONAL
   }

A raw (unprotected) message consists of a PKIHeader and a PKIBody.

Protecting the message would either add the PKIProtection field (if using
internal protection), or would encode the raw message into a format such
as PKCS-7 (if using external protection).

> > The key question is: once the IETF process is finished, do we wind up with
> > a single specification of PKI messages, or two incompatible specifications?
> 
> You wind up with what what is already architected and agreed,
> assuming you dont continue imputing Im lying.
> 
> Where operational detemination is allowed, such profile options
> will make two (profiled) operational scenarios incompatible. This is
> inherent in PKIX-3: a PKIX-3 CA product which only
> accepts email transport, will clearly not work operationally
> with the http transport-only PKIX-3 client. An CA with
> no key-recovery feature, cannot accept key-recovery meessages...

I'm sorry, but I do not see in the Myers I-D where, after the
transport layer is stripped off, and after the protection layer
is stripped off, you are left with a basic PKIHeader and PKIBody.

That is the incompatibility I am referring to.

Obviously, email transport cannot interoperate with http transport,
and internal protection cannot interoperate with external protection.

But if the Myers I-D does not explicitly state how one begins with a
raw PKIX-3 message, encodes it for protection and transport, decodes
it, and ends up with a raw PKIX-3 message at the other end, then it
isn't "compatible" with PKIX-3.   Perhaps I am just being dense, but
I can't find the data structures PKIHeader and PKIBody, as defined
in PKIX-3, *anywhere* in the Myers I-D.  PKIMessage does appear in the
I-D, but it's definition is completely different from the one shown
above:

    PKIMessage ContentInfo ::= SEQUENCE {
      contentType OBJECT IDENTIFIER,
      content [0]
    }

(I'm not an ASN.1 expert, so I don't quite grok this definition with
two LHS expressions on the first line.)

This is not a matter of tweaking mismatched constants here and there,
it's a total incompatibility of data structures.

Can we agree on this definition of a 3 layer model, and this definition
of what it means to provide external protection to PKIX-3 messages?

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Warwick Ford'" <[email-masked]>
Subject: RE: PKIX-3 and PKCS7/10
Date: Thu, 21 Aug 1997 15:41:09 -0400

Hi,

I think that Warwick has provided a fair (and much-needed, for those
that weren't in Munich) description of the current understanding of the
interplay between PKIX-3 and the PKCS 7/10 proposal, along with the
agreed path forward.

One slight point of further clarification, again for the benefit of
those who were not party to the full background.  One might be tempted
to wonder, given some of the text of Warwick's summary, why I had any
real opposition to the proposal at all.  If it was simply a way of
protecting the PKIX-3 messages (in particular, if it was a protection
mechanism that was already explicitly allowed in the PKIX-3
specification), then what was the problem?  Furthermore, if the flaws in
7 and 10 were already well known and if any brand new I-D is expected to
have some flaws, then why go to Munich to give a presentation on the
flaws in the proposal?

The answer is that where we ended up is quite different from where we
started out.  When this proposal was sent out two and a half weeks ago,
people were talking about it as *replacing* PKIX-3.  It was being
positioned as *another way* of doing Certificate Management Protocols
(not as one of several possible ways of *protecting* the PKIX-3
messages).  This view was heard and seen in a number of places, not the
least of which was the abstract of the proposal itself:  "This draft
combines PKIX Part 3 concepts and PKCS10 in the context of PKCS7
security encapsulation to propose an *alternative* Certificate
Management Protocol (CMP)."  [Emphasis mine.]

This view was quite at variance with the work that the group had done
over the past two years to define Part 3 and threatened to stall (or at
least slow down considerably) the specification of a stable protocol in
this area (no small setback since if you haven't got CMP, you can't
build a PKI).  The fact that there were real, significant flaws with the
proposal, coupled with the fact that people were still saying "I've
already got PKCS #7 and #10 toolkits; why can't I just use them to build
my PKI?", made it more imperative that this issue be addressed.  [For
those not at Munich, the short answer to the above question is that it
is very, very clear that PKCS #7 was designed to make use of an
*existing* PKI to secure messages; it was *not* designed to build that
PKI in the first place and, in its present form, is fundamentally
incapable of doing so.]

In any case, that's where we started out and why I was initially opposed
to this proposal.  After much discussion, we ended up as Warwick
described it in his final paragraph:  "Proponents of the PKCS protection
alternative have been encouraged to proceed with the development of a
PKIX-3 supplement which is an interpretation of PKIX-3 messages over
PKCS7 (using the Myers et al I-D as a starting point), in conjunction
with resolving the various technical and administrative issues
surrounding PKCS7 and PKCS10 themselves." 

This is the position espoused in the current Part 3 document (see the
first paragraph of page 21) and I think this is the position with which
we all feel comfortable (as evidenced at the Memphis meeting).

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Thu, 21 Aug 1997 12:22:29 +0100
From: Peter Williams <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX-3 and PKCS7/10

David P. Kemp wrote:

> I don't agree that the Myers I-D is an appropriate starting point, because
> it does *not* profile PKIX-3 over PKCS-7, it proposes an entirely
> different, incompatible Certificate Management Protocol.

Sure the ID is imperfect; and needs lots of structural work, and content
revision as the PKIX document series settles down.

>
>
> If a new Verisign proposal comes out which does indeed profile a small
> subset of the PKIX-3-defined PKIMessage, then it would be an
> appropriate starting point.

Each of the PKIX-3 information objects can be profiled into or excluded
from a profile, such as MISPC. MISPC has already (apparently) made
its determinations from US govt usage, unbeknown to most of us.

The inband protection mechanism can be be profiled into or excluded
from a profile, such as MISPC. MISPC has already (apparently)...

An external protection mechanism, such as PKCS7 specified in
PKIX-3, can be be profiled into or excluded from a profile, such as MISPC.

Another external protection mechanism, such as Myer's draft's can be be profiled into
or excluded from a profile, such as "X9Profile". This is the whole architectural point,
David.

All that is happening is that a toolkit of external protection mechanisms
is being advanced. One raw PKCS7 example already comes with the PKIX-3, David;
Another is being advanced as an ID. Technical comments are
most welcome on the ID, though, and its relationship model.

>
>
> The key question is: once the IETF process is finished, do we wind up with
> a single specification of PKI messages, or two incompatible specifications?

You wind up with what what is already architected and agreed,
assuming you dont continue imputing Im lying.

Where operational detemination is allowed, such profile options
will make two (profiled) operational scenarios incompatible. This is
inherent in PKIX-3: a PKIX-3 CA product which only
accepts email transport, will clearly not work operationally
with the http transport-only PKIX-3 client. An CA with
no key-recovery feature, cannot accept key-recovery meessages...

Yes, I believe (as a non-author) the Myers et al ID needs to be split
up more carefully into its profile choices, and its exernal protection specification.
This is excellent feedback.. Yes there needs
to be alignment with the information objects specs as
they are deemed reasonably stable; A final call for PKIX-3 will
help that alot!

The choice of tag values is historical; they intersected
PKIX-3 at some period, and also intersected
with an early version of MISPC which we (designers)
had access to. Quite happy to change to support
Myers et al in changing integer 2 to 3
or whatever value PKIX-3 says, once it reaches Final Call,
and is clearly proceeding onto IESG.

At this early stage, its a real nit. It'll fall out as PKIX
docs fall out into final versions.

On your substantive points:

"It is interesting.  But it is not what you and Peter claim it to be:
"a subset of PKIX-3 messages over PKCS7".

yes; it goes a touch beyond that: the PKIX-3 makes reference
to Carlisle's problems with PKCS7 as a mechanism,
and these additional messages are a first attempt
to deal with the bootstrap "problems". yes they
are sub-protocol internal to the external protection mechanism.

"It is a completely different protocol from PKIX-3.  It has two messages
which have functionality similar to PKIX-3, one with no equivalent, and
two which have functionality similar to PKIX-2:"

See above. Once the external protection channel has safely bootstrapped itself,
then PKIX3 information objects take over for provide the layer 7 key
management service. This is the design intent, and is entirely consistent with
PKIX-3, David. Am I to have one hand tied behind my back and not
be allowed to address the documented defiencies "in safe  bootstrapping"
by outlawing definition of a safe bootstrap sub-protocol (local to Myers-ID)
for the external protection mechanism, assuming such is not
pre-keyed with smartcard hardware approaches, or SSL mechanism?

Peter.

Date: Thu, 21 Aug 1997 14:24:59 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX-3 and PKCS7/10

> From: Warwick Ford <[email-masked]>
> 
> Folks:
> 
> I believe we are not all on the same page regarding PKIX-3 and PKCS7/10.

Apparently :-).

> 4.  Over the past few months, VeriSign and Cisco worked on the exercise of
> trying to specify a complete protocol using a subset of the PKIX-3 messages
> over PKCS7.  The result of this exercise is reflected in the Myers et al
> I-D, published with the belief that this result may be of interest/benefit
> to others.

It is interesting.  But it is not what you and Peter claim it to be:
"a subset of PKIX-3 messages over PKCS7".

It is a completely different protocol from PKIX-3.  It has two messages
which have functionality similar to PKIX-3, one with no equivalent, and
two which have functionality similar to PKIX-2:

 PKCSReq, message type 19, has functionality similar to
   PKIX-3 message p10cr, context tag 4

 CertRep, message type 3, has functionality similar to
   PKIX-3 message cp, context tag 3

 GetCertInitial, message type 20, allows polling for a pending (not yet
   issued) certificate.  Although PKIX-3 defines a PKIStatus value of
   3 (waiting) and a Certificate Announcement message, it apparently does
   not have a message that can poll for status of a pending cert (except
   as an intrinsic part of the Socket-based Management Protocol of section
   5.2).

 GetCert, message type 21, and
 GetCRL, message type 22, have functionality similar to the Operational
   protocols of PKIX-2 - they are used to retrieve information from a
   repository.

> 5.  In Munich, there were various informal discussions on how we might best
> move forward to fill in this needed additional specification material,
> without impeding the progression to proposed standard of the other part of
> PKIX-3, i.e., the message formats and built-in protection protocol
> combination, which is considered by its proponents and implementors to be
> stable and mature.  Clearly, a multi-stage process would be needed.  The
> PKCS issues need yet to be thought out fully, the PKCS7 and PKCS10 specs
> themselves need to evolve to support all PKIX-1 certificate signing
> algoirithms, and progress in this area may be delayed by such activities as
> RSA's own current enhancement work on PKCS7. Therefore, the generally
> favored approach was to progress core PKIX-3 quickly, while making sure
> that appropriate hooks are in place to subsequently link in full PKCS
> support, as a separate document.

I fully agree with this approach.

> 6. One observation was that, editorially, the resultant documentation would
> be more manageable if PKIX-3 better separated the descriptions of the two
> layers - in retrospect, it would have been better to structure PKIX-3 as
> two documents.  Carlisle, as editor, opposes any major editorial
> reorganization at this stage of progression and, from my own experiences in
> editing such documents, I well appreciate his position.  While opinions on
> this point differ, we should note that the present structure does not
> preclude addition of the needed specification - we can achieve the desired
> result technically (with a small compromise in document usability) by
> producing another document which is an "interpretation" of PKIX-3 for use
> in a PKCS10/7 environment.

I agree that it would be clearer to structure the PKIX specifications
into "message" and "transport" layers instead of the current split
between "management" and "operational" message types.  The current structure
results in duplication of various transport methods (ftp, http, email,
online, etc) in both part 2 and part 3.

I would support stripping out all of section 5 (Transport) from PKIX-3,
perhaps merging the Socket protocol into PKIX-2's OCSP.  I would
support adding two operational messages to PKIX-3 (GetCert and GetCRL).
I don't believe there is a need for an additional polling message
(GetCertInitial), since GetCert would return either the cert or an
appropriate error, but would support a separate polling message if
GetCert couldn't do the job.

> So, that's where we are.  PKIX-3 appears technically ready to at least be
> issued for WG last call. (Editorial and, possibly, technical improvements
> are not ruled out in the last call stage.)  Proponents of the PKCS
> protection alternative have been encouraged to proceed with the development
> of a PKIX-3 supplement which is an interpretation of PKIX-3 messages over
> PKCS7 (using the Myers et al I-D as a starting point), in conjunction with
> resolving the various technical and administrative issues surrounding PKCS7
> and PKCS10 themselves.

I agree with the approach of proceeding PKIX-3 on to last call, and
developing a separate supplement for external protection.

I don't agree that the Myers I-D is an appropriate starting point, because
it does *not* profile PKIX-3 over PKCS-7, it proposes an entirely
different, incompatible Certificate Management Protocol.

If a new Verisign proposal comes out which does indeed profile a small
subset of the PKIX-3-defined PKIMessage, then it would be an
appropriate starting point.

The key question is: once the IETF process is finished, do we wind up with
a single specification of PKI messages, or two incompatible specifications?

Date: Thu, 21 Aug 1997 10:53:55 +0100
From: Peter Williams <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

Carlisle Adams wrote:

> Hi,
>
> I'm sorry Peter, but David makes an excellent point here.  I think we'll
> have to leave PKIX-3 unchanged on this issue...

Does he indeed? Lets look as wider PKIX-3 (and MISPC profile)
conformance issues, which are rather more important than purity of denotational
models in my mind:-

Because of the sensitivity of the key backup issue (does
it really represent govt/corporate spying on their people? etc. etc.)
and GIVEN the IAB line of RFC 1984,  this conformance
issue should be crystal clear, and be explicitly stated, positively
or negatively. There can be no rationale for refusing
to improve clarity and remove ambuguity, or scope
for interpretation; surely?So, in standards terms, and bearing in mind RFC 1984:-

-------

Tell us - must a CA product (or an Internet service derived from that
product) provide a capability to do client key backup
to be a conforming implementation of PKIX-3?

If the answer is no: make a clear, conspicuous statement in the document.

If the answer is yes: propose such a clear statement for the document.

--------

tell us - must as UA product doing PKIX-3 provide a capability
to interface to a CA/LRA's key backup capability
to be a conforming implementation of PKIX-3?

If the answer is no: make a clear, conspicuous statement in the document.

If the answer is yes: propose such a clear statement for the document.

-------------

Lets deal now with MISPC - a mostly closed US national process hidden
from most trans-national IETFers and internet users which is likely to
affect their lives.

Assuming no to both the above questions:-

Does the  MISPC profile of PKIX-3 make the "optional"
key recovery/backup feature of PKIX-3  a *mandatory* feature for
procurement - by US govt, for example?

All I am asking, is ; is the conformance/optionaliy structure being
rigged to force CA folk to provide key recovery - by one
political means or another?

Its easy to ensure this is not the case, note. mere clarity
and 2 sentences is all it requires.

Whats your own opinion, and Entrust's opinion?
Are you determined to force CAs to offer key recovery by
one means or another? Or do folks have real operational
choice?

As always, Im for real choice where its agreed to be
an operational determinate, and reject most
initiatives to embed policy in technical standards,
however indirectly. I hope I'm consistent on that.

Date: Thu, 21 Aug 1997 11:58:02 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: PKIX-3 and PKCS7/10

Folks:

I believe we are not all on the same page regarding PKIX-3 and PKCS7/10.
For the benefit, in particular, of those on the list who were not at
Munich, let me try to summarize where we are, what happened at Munich, and
where we are going from here. (Given my affiliation, you should probably
consider this a personal posting - not a statement as Co-Chair.)

1.  Many PKIX participants have expressed their desire to have a
standardized certificate enrolment protocol built by incrementally
enhancing the PKCS10 protocol (in some cases in combination with PKCS7)
they are currently using.  This desire was still highly apparent at last
week's meeting.  At the same time, Carlisle has designed a full-featured
certificate management protocol, the features of which many participants
also want or shall want some day.

2.  Our approach to dealing with these not-fully-aligned requirements has,
for a long time, been to have a "two-layer" model.  We define, at one
layer, a set of management transaction messages.  At another layer we have
a choice of protection protocols used to protect such messages in transit.
The basis of this two-layer model is reflected in PKIX-3.  PKCS10 is
expressly recognized as one of the transaction messages.  There can be
different protection protocols - one option is built-in to PKIX-3.  The
document expressly recognizes that PKCS7 could be another option as a
protection protocol.

3.  The transaction messages and the built-in protection protocol are
well-defined in PKIX-3.  Note, however, that the ubiquitous use of OPTIONAL
syntax requires additional profiling to ensure interoperability.

4.  Over the past few months, VeriSign and Cisco worked on the exercise of
trying to specify a complete protocol using a subset of the PKIX-3 messages
over PKCS7.  The result of this exercise is reflected in the Myers et al
I-D, published with the belief that this result may be of interest/benefit
to others.  In addition to developing a profile, this activity uncovered
some other interesting issues regarding the mapping of PKIX-3 messages to
PKCS7.  For example, in the PKCS7 environment, it can be of benefit to the
implementor to convey some of the PKIX header information in PKCS7
attribute fields, rather than as part of the message body.  It became clear
that the mapping of PKIX-3 to PKCS7 needs further specification work.

5.  In Munich, there were various informal discussions on how we might best
move forward to fill in this needed additional specification material,
without impeding the progression to proposed standard of the other part of
PKIX-3, i.e., the message formats and built-in protection protocol
combination, which is considered by its proponents and implementors to be
stable and mature.  Clearly, a multi-stage process would be needed.  The
PKCS issues need yet to be thought out fully, the PKCS7 and PKCS10 specs
themselves need to evolve to support all PKIX-1 certificate signing
algoirithms, and progress in this area may be delayed by such activities as
RSA's own current enhancement work on PKCS7. Therefore, the generally
favored approach was to progress core PKIX-3 quickly, while making sure
that appropriate hooks are in place to subsequently link in full PKCS
support, as a separate document.

6. One observation was that, editorially, the resultant documentation would
be more manageable if PKIX-3 better separated the descriptions of the two
layers - in retrospect, it would have been better to structure PKIX-3 as
two documents.  Carlisle, as editor, opposes any major editorial
reorganization at this stage of progression and, from my own experiences in
editing such documents, I well appreciate his position.  While opinions on
this point differ, we should note that the present structure does not
preclude addition of the needed specification - we can achieve the desired
result technically (with a small compromise in document usability) by
producing another document which is an "interpretation" of PKIX-3 for use
in a PKCS10/7 environment.

7. At Munich, Carlisle gave a presentation claiming several "flaws" in
PKCS10, PKCS7, and in the Myers et al I-D.  The existence of deficiencies
in current PKCS7 and 10 has been discussed many times before - clearly some
work needs to be done on these specifications for them to satisfy the full
range of expectations of an IETF standard.  Furthermore, that any brand new
I-D has "flaws" is not very surprising - I would imagine the I-D authors
will welcome Carlisle's comments, and, as soon as the "flaws" are
documented will respond to them on the list.

So, that's where we are.  PKIX-3 appears technically ready to at least be
issued for WG last call. (Editorial and, possibly, technical improvements
are not ruled out in the last call stage.)  Proponents of the PKCS
protection alternative have been encouraged to proceed with the development
of a PKIX-3 supplement which is an interpretation of PKIX-3 messages over
PKCS7 (using the Myers et al I-D as a starting point), in conjunction with
resolving the various technical and administrative issues surrounding PKCS7
and PKCS10 themselves.

Hope this helps fill in the picture,
Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: key recovery options for PKIX-3 CAs?
Date: Thu, 21 Aug 1997 10:51:12 -0400

Hi,

I'm sorry Peter, but David makes an excellent point here.  I think we'll
have to leave PKIX-3 unchanged on this issue...

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Wednesday, August 20, 1997 5:01 PM
>To: 	[email-masked]
>Subject: 	Re: key recovery options for PKIX-3 CAs?
>
>> From: Peter Williams <[email-masked]>
>>
>> > The following sentence is the only thing that the current draft has to
>> > say on this particular topic:
>> >
>> >    "As an option, user client key materials (e.g., a user's private key
>> > used for decryption purposes) may be backed up by a CA, an RA, or a key
>> > backup system associated with a CA or RA."
>> >
>> 
>> Seems exclusionary.
>> 
>> Unless there is objection, after the final RA
>> 
>> add "or other external entities. See RFC 1984 for information."
>
>
>Objection.
>
>PKIX-3 defines a Certificate Management Protocol (CMP), and defines three
>entities which participate in that protocol: CA, RA, and End User.
>The CMP-defined messages contain fields which enable keys to be "backed
>up by a CA, an RA, or a backup system..."  The CMP does not define any
>protocol messages which would support interaction with "other external
>entities" simply because such other entities are outside the scope of the
>protocol.
>
>There is no intent to prohibit all other forms of communication between
>CA, RA, End User, and other external entities.  Not even a perverse
>reading of the spec would equate "out-of-scope" with "exclusionary".
>
>Show me *any* example of an IETF protocol specification which has
>ever been interpreted to mean:
>
>   "if it's not expressly defined in <RFCxxx>, then it
>    may not be done in any other manner."
>
>
>It would be unrealistic to try to identify every capability provided by
>CMP and add the caveat "or it could be done using some other protocol".
>And it would be inconsistent to add such a caveat to just one particular
>capability.
>

Date: Thu, 21 Aug 1997 10:31:12 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: manual keying and IPSEC conformance
Cc: [email-masked]

> From: Ran Atkinson  <[email-masked]>
>
> In the X.509 arena there are MANY folks in the CA business competing with 
> each other, but cross-certification is not yet an element of the real world.
> What if I want to talk with user FOO, but I use CA==X, FOO uses CA==Y 
> where (Y!=X) and (X,Y don't cross certify each other) -- result, no secure packets.

This is a common misperception about X.509.  The ISO/ITU X.509 standard
has always explicitly supported arbitrary trust chaining paths (a.k.a.
"web-of-trust") but, perhaps due to the PEM experience, most IETF'ers
seem to regard X.509 as requiring strict single-rooted or
cross-certified multiply-rooted hierarchies.

Kudos to the SPKI folks for making explicit the notion that trust chains
always begin at the verifier.  The PKIX folks perhaps should add some
verbiage that makes it clearer that the verifier can choose to trust
whomever it wants.  That verbiage shouldn't be necessary, but there is
apparently a huge PEM legacy-of-perception that needs to be erased.

In the IPsec case, if Ran "uses" (has a certificate issued by) CA==X,
and FOO has a certificate from CA==Y, there is not necessarily a problem.
As long as Ran's machine has a Ran-issued cert for CA==Y
stating that Ran trusts Y to certify IPsec nodes (perhaps with
name space or policy constraints), then there is no need for X and Y
to be cross certified.

More generally, each administrative domain would have a single
root public key, each node within the domain would trust *only* that
root key, and the domain root would certify *all* CAs which are to be
trusted by nodes within the domain.  The same mechanism is used to
address the privilege side of the compartmented information problem
that was recently brought up.  (The other side of the problem is
data labelling.)

From: "Carl Binding"<[email-masked]>
To: [email-masked]
Date: Thu, 21 Aug 1997 08:28:22 +0100
Subject: draft-ietf-pkix-ipki2opp-00.txt

     Comments on Internet Public Key Infrastructure Operational Protocols
     part 2 dated March 1997.

     In reviewing the draft PKIX operational protocols I think the group
     has done an excellent job in addressing the problem associated with
     CRLs, in particular providing an alternative solution... OCSP.  This
     office, for the past two years, has believed this model to be the only
     near real-time certificate status indicator.

     I would like to suggest that the group consider authenticated online
     certificated status requests from users/applications.  Authenticating
     access to the CA will provide valuble audit trail information that
     could be useful for security requirements as well as providing a means
     to bill users based upon validation transactions.

     Additional information regarding this approach can be obtained from
     the GSA Sources Sought CBD announcement dated 8/11/97 (PSA#1906).

     Stanley J. Choffrey
     General Services Administration
     Office of Information Security
     (202) 708-7943
     [email-masked]

From: "Carl Binding"<[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 21 Aug 1997 08:28:23 +0100
Subject: Re: key recovery options for PKIX-3 CAs?

Stephen Kent wrote:

> Peter,
>
>         I have a simple, real answer to your scenario:  there are lots of
> other means by which the user's medical records might have been
> inappropriately released by the company.  Showing that on this release
> using the SSL mechanism was authorized would only "prove" that the
company > did not inappropriately release the data in this fashion in this
instance.

And this is all its supposed to do, and we want it to do, here in
PKIX (and SSL) communities!

Assuming the law suit for negligence asks for punitive damages (they
all do), the company has means to argue, based on authenticated evidence
of actions and precautions (arguably.)

To the PKIX  issue: to be used in court/arbitration, the (SSL) records
evidence must be authenticated as a signed writing, or similar
designation. The PKIX certs will be dragged in, and argued over by
technical experts, as will the security technology : sure: but irrelevant
here.

SSL/TLS clearly has no classical non-repudiation properties, and makes
no claim thereof, and the certs from the CA
for https end-systems make no allusion to such properties of
SSL services. Non-repudiation is really off-topic, expect by way
of contrast; and this is my main point for the semantics of
PKIX-1 certs which should be clear in the document when used in
other than non-repudiation-grade security services. Perhaps I am
getting ahead of the final-call process, though.

The SSL/TLS records will inevitably be used in evidence one day, and the
court will have to decide whether there is a signed writing, or other
authenticated instrument. (Incidental  arguments to deny such status
(Inadequate FIPS crypto boxes, inadequate personel, inadequate tamperpoof
records storage) will address (legal) non-repudiation situations similarly,
note, as all such technology and process is shared between strong
authentication and non-repudiation services.)

I will encourage the courts to pay you to argue the
the following from what you said :-) :-

" Showing that on this release [that]
using the SSL mechanism was authorized would only "prove" that the company
did not inappropriately release the data in this fashion in this instance."

I intend to quote it at the first test case available :-) I recognise
the use of quotes as a signal that  you would intend to  allow the
court to make the detemination of evidentiary status, and then
proof validity, for the case in question. All we need is
one SSL records-evidence base case to obtain a determination
and the beginning of a jurisprudence chain on such  issues.

It would seem likely that a strong authentication test case
involving PKIX certs will happen before a non-repudiation test case,
given actual commercial use of the specifically strong-authentication-grade
SSL technology, now.

From: "Carl Binding"<[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 21 Aug 1997 08:28:19 +0100
Subject: Signed directory ops

A hacked-up version of what Peter Williams wrote:
>
> I'm a long term promoter of Directory signed-results for its
> operations.

Yup.

I think it might be interesting for the pkix community to know that I
raised the addition of signed operations and results to the LDAPv3
protocol (using the extension mechanism) at Munich and as a result a
draft for the ldap extension WG is being prepared. Note that this has
nothing to do with secure transport.

This lines up nicely with many concerns voiced on this list,
and some other stuff too (for other PKIs not including X.509 ones).

Sorry to interrupt,
Pat
--
Pat Richard - [email-masked]
Public Key Available via LDAP
http://www.xcert.com

"Every information object known to modern man is a candidate for
PKI-based ACL" - Young Etheridge

Date: Wed, 20 Aug 1997 15:31:48 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Well argued, Peter, although I warn you that you are on a slippery slope. If
you continue in this vein, someone might conclude that you were me, just
using a different ID! :-)

I believe that the law recognizes more or less of a continuum of signed
writings, ranging from a simple X (hopefully witnessed) up to the most
ironclad of notarized, witnessed, and arhived public documents.

Particularly under the UCC and similar rules, there is broad latitude for
what constitutes a signed writing, including trade practices, letterhead,
standard forms, etc.

As far as I can tell, there isn't any law or rule for when something
suddenly becomes repudiable or nonrepudiable. All of these "rules" are in
the form of a rebutable presumption, and the primary issue is how hard you
have to work to rebut them.

But it worth observing that the notion of a writing which is authenticated
using a security procedure is fairly high up on the list. Banks use test
keys (really elaborate checksums), others use call-back precautions, etc. so
I have little doubt that an authenticated session, a la SSL, could be used
to establish signed riting status, so long as WITTING, KNOWLEDGABLE INTENT
can clearly be established.

In reality, an SSL session could convey anything from a doodle to a signed
copy of the Declaration of Independence. The real difference is intent.

Of course, it is also possible to digitally sign a rough draft, or even
something that you think is totally preposterous, merely to assure against
tampering while in transit.

So although there MAY be a someone greater recognition of the ceremonial and
evidentiary aspects of a signature in the case of a digitally signed message
vs. an authenticated session, that isn't necessarily or obviously so.

Arguing by analogies, I think of an authenticated and optionally encrypted
SSL session as the equivalent of a sealed envelope bearing a return address.
Absent any explicit indication of intent, a sealed envelope, even one
bearing a handwritten return address, is not a signed document, yet it
certainly has some evidentiary value.

Likewise, a signature might be just a doodle, or someone trying out a new
pen, but if you affix that particular doodle at the end of what appears to
be a contract, you'ld better be prepared to argue awfully hard as to why
that doodle shouldn't be viewed as your legally binding signature.

To my way of thinking, trying to impute too much meaning to the key usage
bits in a certificate is probably fruitless. We would have been a whole lot
better off including some explicit intent/reason codes (along the lines X9
has suggested) within the digital signature itself

Bob

>
>Stephen Kent wrote:
>
>> Peter,
>>
>>         I have a simple, real answer to your scenario:  there are lots of
>> other means by which the user's medical records might have been
>> inappropriately released by the company.  Showing that on this release
>> using the SSL mechanism was authorized would only "prove" that the
company
>> did not inappropriately release the data in this fashion in this
instance.
>
>And this is all its supposed to do, and we want it to do, here in
>PKIX (and SSL) communities!
>
>Assuming the law suit for negligence asks for punitive damages (they
>all do), the company has means to argue, based on authenticated evidence
>of actions and precautions (arguably.)
>
>To the PKIX  issue: to be used in court/arbitration, the (SSL) records
>evidence must be authenticated as a signed writing, or similar
>designation. The PKIX certs will be dragged in, and argued over by
technical
>experts, as will the security technology : sure: but irrelevant here.
>
>SSL/TLS clearly has no classical non-repudiation properties, and makes
>no claim thereof, and the certs from the CA
>for https end-systems make no allusion to such properties of
>SSL services. Non-repudiation is really off-topic, expect by way
>of contrast; and this is my main point for the semantics of
>PKIX-1 certs which should be clear in the document when used in
>other than non-repudiation-grade security services. Perhaps I am
>getting ahead of the final-call process, though.
>
>The SSL/TLS records will inevitably be used in evidence one day, and the
court
>will have to decide whether there is a signed writing, or other
authenticated
>instrument. (Incidental  arguments to deny such status (Inadequate FIPS
>crypto boxes, inadequate personel, inadequate tamperpoof records storage)
>will address (legal) non-repudiation situations similarly, note, as all
>such technology and process is shared between strong authentication and
>non-repudiation services.)
>
>I will encourage the courts to pay you to argue the
>the following from what you said :-) :-
>
>" Showing that on this release [that]
>using the SSL mechanism was authorized would only "prove" that the company
>did not inappropriately release the data in this fashion in this instance."
>
>I intend to quote it at the first test case available :-) I recognise
>the use of quotes as a signal that  you would intend to  allow the
>court to make the detemination of evidentiary status, and then
>proof validity, for the case in question. All we need is
>one SSL records-evidence base case to obtain a determination
>and the beginning of a jurisprudence chain on such  issues.
>
>It would seem likely that a strong authentication test case
>involving PKIX certs will happen before a non-repudiation test case,
>given actual commercial use of the specifically strong-authentication-grade
>SSL technology, now.
>
>
>
>
>

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Wed, 20 Aug 1997 17:01:02 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

> From: Peter Williams <[email-masked]>
>
> > The following sentence is the only thing that the current draft has to
> > say on this particular topic:
> >
> >    "As an option, user client key materials (e.g., a user's private key
> > used for decryption purposes) may be backed up by a CA, an RA, or a key
> > backup system associated with a CA or RA."
> >
> 
> Seems exclusionary.
> 
> Unless there is objection, after the final RA
> 
> add "or other external entities. See RFC 1984 for information."

Objection.

PKIX-3 defines a Certificate Management Protocol (CMP), and defines three
entities which participate in that protocol: CA, RA, and End User.
The CMP-defined messages contain fields which enable keys to be "backed
up by a CA, an RA, or a backup system..."  The CMP does not define any
protocol messages which would support interaction with "other external
entities" simply because such other entities are outside the scope of the
protocol.

There is no intent to prohibit all other forms of communication between
CA, RA, End User, and other external entities.  Not even a perverse
reading of the spec would equate "out-of-scope" with "exclusionary".

Show me *any* example of an IETF protocol specification which has
ever been interpreted to mean:

   "if it's not expressly defined in <RFCxxx>, then it
    may not be done in any other manner."

It would be unrealistic to try to identify every capability provided by
CMP and add the caveat "or it could be done using some other protocol".
And it would be inconsistent to add such a caveat to just one particular
capability.

Date: Wed, 20 Aug 1997 12:36:49 +0100
From: Peter Williams <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

Carlisle Adams wrote:

> Hi Peter,
>
> >----------
> >From:  Peter Williams[SMTP:[email-masked]]
> >Sent:  Tuesday, August 12, 1997 7:31 AM
> >To:    [email-masked]
> >Subject:       key recovery options for PKIX-3 CAs?
> >
> >PKIX-3 seems to imply that only CAs and LRA can perform key recovery
> >duties. Surely this language should be amended such that
> >
> >(a) non-PKI elements can do key recovery ("KMI Agents", perhaps)
> >
> >(b) PKIX CAs may support/enforce key recovery options which do not depend
> >upon access to private-keying material of subscribers.
> >
> >There seems an assumption in PKIX that the PKI/CAs will perform key
> >recovery, and Im not sure that this is true, and even it if true to the
> >extent that
> >you cannot have a cert until some key-recovery option is
> >known to be in place, such key-recovery and data-recovery
> >mechanisms may be CSP-provided and not even necesssairly involve
> >the CA in direct protocol terms.
> >
> >we may want to amend PKIX-3 to assign additional options and
> >freedoms in line with (a) and (b) on the key-recovery front.
>
> The following sentence is the only thing that the current draft has to
> say on this particular topic:
>
>    "As an option, user client key materials (e.g., a user's private key
> used for decryption purposes) may be backed up by a CA, an RA, or a key
> backup system associated with a CA or RA."
>

Seems exclusionary.

Unless there is objection, after the final RA

add "or other external entities. See RFC 1984 for information."

Add "RFC 1984: http://ds.internic.net/rfc/rfc1984.txt" to the references.

The basis for this change is the ABA declaration; PKIX-3 can
address the (indirect) comment from ABA by ensuring  it
affirms that  non-CA parties (and non-LRA) parties are
legitimate in this role.

 The reference to RFC 1984 would allow readers to lookup
such information as follows, when choosing which features to provide
or procure-

"ESCROW OF PRIVATE KEYS WON'T NECESSARILY ALLOW DATA DECRYPTION

   A major threat to users of cryptographic systems is the theft of
   long-term keys (perhaps by a hacker), either before or after a
   sensitive conversation.  To counter this threat, schemes with
   "perfect forward secrecy" are often employed.  If PFS is used, the
   attacker must be in control of the machine during the actual
   conversation.  But PFS is generally incompatible with schemes
   involving escrow of private keys.  (This is an oversimplification,
   but a full analysis would be too lengthy for this document.)"

Date: Wed, 20 Aug 1997 11:46:18 +0100
From: Peter Williams <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Stephen Kent wrote:

> Peter,
>
>         I have a simple, real answer to your scenario:  there are lots of
> other means by which the user's medical records might have been
> inappropriately released by the company.  Showing that on this release
> using the SSL mechanism was authorized would only "prove" that the company
> did not inappropriately release the data in this fashion in this instance.

And this is all its supposed to do, and we want it to do, here in
PKIX (and SSL) communities!

Assuming the law suit for negligence asks for punitive damages (they
all do), the company has means to argue, based on authenticated evidence
of actions and precautions (arguably.)

To the PKIX  issue: to be used in court/arbitration, the (SSL) records
evidence must be authenticated as a signed writing, or similar
designation. The PKIX certs will be dragged in, and argued over by technical
experts, as will the security technology : sure: but irrelevant here.

SSL/TLS clearly has no classical non-repudiation properties, and makes
no claim thereof, and the certs from the CA
for https end-systems make no allusion to such properties of
SSL services. Non-repudiation is really off-topic, expect by way
of contrast; and this is my main point for the semantics of
PKIX-1 certs which should be clear in the document when used in
other than non-repudiation-grade security services. Perhaps I am
getting ahead of the final-call process, though.

The SSL/TLS records will inevitably be used in evidence one day, and the court
will have to decide whether there is a signed writing, or other authenticated
instrument. (Incidental  arguments to deny such status (Inadequate FIPS
crypto boxes, inadequate personel, inadequate tamperpoof records storage)
will address (legal) non-repudiation situations similarly, note, as all
such technology and process is shared between strong authentication and
non-repudiation services.)

I will encourage the courts to pay you to argue the
the following from what you said :-) :-

" Showing that on this release [that]
using the SSL mechanism was authorized would only "prove" that the company
did not inappropriately release the data in this fashion in this instance."

I intend to quote it at the first test case available :-) I recognise
the use of quotes as a signal that  you would intend to  allow the
court to make the detemination of evidentiary status, and then
proof validity, for the case in question. All we need is
one SSL records-evidence base case to obtain a determination
and the beginning of a jurisprudence chain on such  issues.

It would seem likely that a strong authentication test case
involving PKIX certs will happen before a non-repudiation test case,
given actual commercial use of the specifically strong-authentication-grade
SSL technology, now.

From: <[email-masked]>
Date: 20 Aug 97 13:36:00 (-0400)
Subject: draft-ietf-pkix-ipki2opp-00.txt
To: [email-masked]

--UNS_gsauns2_2680295478
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

     Comments on Internet Public Key Infrastructure Operational Protocols 
     part 2 dated March 1997.
     
     In reviewing the draft PKIX operational protocols I think the group 
     has done an excellent job in addressing the problem associated with 
     CRLs, in particular providing an alternative solution... OCSP.  This 
     office, for the past two years, has believed this model to be the only 
     near real-time certificate status indicator.
     
     I would like to suggest that the group consider authenticated online 
     certificated status requests from users/applications.  Authenticating 
     access to the CA will provide valuble audit trail information that 
     could be useful for security requirements as well as providing a means 
     to bill users based upon validation transactions.
     
     Additional information regarding this approach can be obtained from 
     the GSA Sources Sought CBD announcement dated 8/11/97 (PSA#1906).
     
     Stanley J. Choffrey
     General Services Administration
     Office of Information Security
     (202) 708-7943
     [email-masked] 

--UNS_gsauns2_2680295478--

Date: Wed, 20 Aug 1997 06:24:56 -0700
From: Pat Richard <[email-masked]>
To: Peter Williams <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Signed directory ops

A hacked-up version of what Peter Williams wrote:
> 
> I'm a long term promoter of Directory signed-results for its
> operations. 

Yup.

I think it might be interesting for the pkix community to know that I
raised the addition of signed operations and results to the LDAPv3
protocol (using the extension mechanism) at Munich and as a result a
draft for the ldap extension WG is being prepared. Note that this has
nothing to do with secure transport.

This lines up nicely with many concerns voiced on this list, 
and some other stuff too (for other PKIs not including X.509 ones).

Sorry to interrupt,
Pat
-- 
Pat Richard - [email-masked]
Public Key Available via LDAP
http://www.xcert.com

"Every information object known to modern man is a candidate for
PKI-based ACL" - Young Etheridge

Date: Tue, 19 Aug 1997 17:22:29 -0700
From: MH <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Subject: Student Financing  

I saw your listing on the internet.  I work for a finance company
that Finances Technical and Vocational Students that can't
afford to pay their tuition up front.  We advance you (the school)
your money and the student makes payments back to us.  If you
would like to offer your students financing or just need another
funding source, please e-mail me at the below e-mail address.
We offer financing for students up to 42 mo. and purchase 
in-house portfolios.  Billing and collection services are
also available.

Sincerely,

Mark Hofman
A/R Financial Solutions
E-mail: [email-masked]
Web Site: http://www.a-1.org

Date: Tue, 19 Aug 1997 16:52:59 -0400
To: Mark Shuttleworth <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?
Cc: [email-masked]

Mark,

>> resulting private key.  I also provided an example of why one might want to
>> have a CA generate a key pair for a user, irrespective of key recovery.
>
>If you're talking about ensuring good RNG, then surely Java, which runs on
>the client machine and thus keeps the private key private, is a better
>answer?  Sure, no quantum effect randomness, but one can get pretty good.
>Even then I wonder at the opportunities for Java apps that generate the
>key on a client platform and then send a copy elsewhere.

Client RNG capabilities vary greatly, and have traditionally proved to be
poor.  A CA can more easily justify investing in a hardware RNG.

>> Defining message formats to suppprt key recovery is also a possibility, if
>> the WG elects to address that issue.  There is also a group developing key
>> recovery standards for a Federal Information Processing Standard, a part of
>> which will encompass the sort of user - key recovery/registration agent
>> interaction.
>
>So the vendors can adopt that standard.  Does the IETF want to endorse key
>recovery or escrow even tacitly?

C'mon now, Mark.  CA generation of a key is not equivalent to key recovery,
period.  If we require support for a CA key gen feature in CAs, which does
not imply that it will alway be used, that is not an endorsement of key
recovery.

Steve

Date: Tue, 19 Aug 1997 13:58:24 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

>
>> resulting private key.  I also provided an example of why one might want
to
>> have a CA generate a key pair for a user, irrespective of key recovery.
>
>If you're talking about ensuring good RNG, then surely Java, which runs on
>the client machine and thus keeps the private key private, is a better
>answer?  Sure, no quantum effect randomness, but one can get pretty good.

Almost surely, NOT!  You've got who-knows-what quality of code, running on
an untrusted interpreter, running on an untrusted platform.  The IETF might
just as well devote its efforts to finding a high-quality key, and than
standardize on it! :-)

Granted, Novell is traditionally a server-oriented company, but we would
generally prefer to see both public/private and where possible even session
and other secret keys generated on the user's server, in what is presumably
a more physically secure and constrained environment, at least until secure
smart cards accredited under FIPS140-1) become affordable and ubiquitous.

Depending on the particular environment, having high quality keys generated
by the CA is not at all unreasonable -- especially in the case of a
corporate CA.  After all, an untrustworthy CA could potentially sign a
certificate containing your name and your alleged public key, keeping your
private key, any time it wanted to.

Whether a reputable CA would be willing to sign up for the additional
liability, etc., that may be implied is a different issue, of course.

>Even then I wonder at the opportunities for Java apps that generate the
>key on a client platform and then send a copy elsewhere.

Exactly.  In some circles, Java applets are viewed as being another name for
information warfare!
>
>> Defining message formats to support key recovery is also a possibility,
if
>> the WG elects to address that issue.  There is also a group developing
key
>> recovery standards for a Federal Information Processing Standard, a part
of
>> which will encompass the sort of user - key recovery/registration agent
>> interaction.
>
>So the vendors can adopt that standard.  Does the IETF want to endorse key
>recovery or escrow even tacitly?

Good question.

With respect to commercial key recovery, I believe the answer should
certainly be yes.  Commercial key recovery is a firm requirement from many
of our customers, so the IETF has to make a choice as to whether to deal
with these issues forthrightly, or to become irrelevant in the marketplace. 
(One might note the complete failure of the IETF to define an commercially
acceptable secure e-mail protocol, and the emergence of S/MIME as a
proprietary standard in the resulting vacuum.)

With respect to government-mandated key recovery/encapsulation/escrow, the
issue may be somewhat less clear, as there is clearly no commercial
requirement. However, there is strong pressure on existing vendors to do
something in this area, both from an export standpoint (particularly in the
US) and in some cases an import/usage standpoint (particularly wrt the
French).  Which way the law in individual countries is going to zig or zag
seems to change on any given day, and individual IETF members should make
their views known to their legislators in their respective countries. (I
assume, but don't know for sure,  that the IETF charter prohibits direct
lobbying efforts.)

Since the Key Recovery Alliance is actively examining business scenarios and
requirements (a document should be available on www.kra.org in the
relatively near future) as well as a technical framework and
meta-architecture, it would probably be reasonable for the IETF to defer
dealing with government access to keys at this time, but that should not be
viewed as a prohibition against eventual consideration of this issue.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Tue, 19 Aug 1997 20:39:40 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Stephen Kent <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

> resulting private key.  I also provided an example of why one might want to
> have a CA generate a key pair for a user, irrespective of key recovery.

If you're talking about ensuring good RNG, then surely Java, which runs on
the client machine and thus keeps the private key private, is a better
answer?  Sure, no quantum effect randomness, but one can get pretty good.
Even then I wonder at the opportunities for Java apps that generate the
key on a client platform and then send a copy elsewhere.

> Defining message formats to suppprt key recovery is also a possibility, if
> the WG elects to address that issue.  There is also a group developing key
> recovery standards for a Federal Information Processing Standard, a part of
> which will encompass the sort of user - key recovery/registration agent
> interaction.

So the vendors can adopt that standard.  Does the IETF want to endorse key
recovery or escrow even tacitly?

--
Mark Shuttleworth
Thawte Consulting

Date: Tue, 19 Aug 1997 13:24:24 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Peter,

	I have a simple, real answer to your scenario:  there are lots of
other means by which the user's medical records might have been
inappropriately released by the company.  Showing that on this release
using the SSL mechanism was authorized would only "prove" that the company
did not inappropriately release the data in this fashion in this instance.
Of course the company will use its records to substabtiate its case, but
that is not the whole answer.

In a more narrow sense, the critical question should be whether the company
could forge its records to support its claim.  If not, then presumably the
combination of crypto and other controls provides a basis for
non-repudiation.  If so, then I'll offer to be an expert witness, for a
suitable fee :-), against the company.

Steve

Date: Tue, 19 Aug 1997 11:30:49 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?
Cc: [email-masked]

At 3:00 PM -0700 8/18/97, Anil R. Gangolli wrote:

>Mark Shuttleworth's second point about separating the CA and the
>Key Escrow/Recovery Agent is still a valid and important one.
>
>The model I have advocated earlier is that there be a standardized
>format for a "key escrow receipt".   This would be a message effectively
>asserting that "the private key associated with public key X has been
>escrowed with me and will be kept by me until at least date D, signed
><escrow agent>".
>
>A CA or other entity (e.g. RA) may enforce a requirement that
>clients present such a receipt from an approved agent (as determined
>by its policy) as part of any request for a certificate in which certain
>key usage indications are present.  (e.g. A CA may require this
>to certify key exchange keys but not signing only keys).
>
>Consider for example a company who wishes to use a CA
>administered by an outside agency but wishes to keep
>its own keys, or run its own internal recovery
>(or generation) service.

The ability to separate key recovery and CA functions is a good one, and it
is not precluded by the current rerquirements.  As I said earlier, the
function cited in PKIX Part 3, allowing CA generation of a key pair, is NOT
equivalent to key recovery, e.g., it does not require the CA to RETAIN the
resulting private key.  I also provided an example of why one might want to
have a CA generate a key pair for a user, irrespective of key recovery.

Defining message formats to suppprt key recovery is also a possibility, if
the WG elects to address that issue.  There is also a group developing key
recovery standards for a Federal Information Processing Standard, a part of
which will encompass the sort of user - key recovery/registration agent
interaction.

Steve

Date: Tue, 19 Aug 1997 10:46:58 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

> From: "Anil R. Gangolli" <[email-masked]>
> 
> Mark Shuttleworth's second point about separating the CA and the
> Key Escrow/Recovery Agent is still a valid and important one.
> 
> The model I have advocated earlier is that there be a standardized
> format for a "key escrow receipt".   This would be a message effectively
> asserting that "the private key associated with public key X has been
> escrowed with me and will be kept by me until at least date D, signed
> <escrow agent>".

That is a fine idea, along the lines of CertCo's impending standardized
formats for things like billing information.

But it is not clear what Mark wants to eliminate from the protocol in an
effort to separate the duties of CA and KR Agent.

PKIX-3 section 2.2.1.3, "Location of key generation", says:

  "In this specification, key generation is regarded as occurring wherever
   either the public or private component of a key pair first occurs in a
   PKI message.  Note that this does not preclude a centralized key
   generation service - the actual key pair may have been generated
   elsewhere and transported to the end entity, RA, or CA."

For generation and distribution of classified keying material, we use
a centralized facility and a mechanism based entirely on symmetric
encryption.  We are under intense pressure to integrate the centralized
symmetric key distribution system with the decentralized public-key-based
infrastructure.  But even if we weren't, there would still be advantages
to generating keypairs in a highly secure central facility and distributing
them to CAs, RAs, and end users.  This is totally unrelated to "Key Recovery"
for evesdropping purposes, although it does facilitate replacement of a
user's lost/destroyed keys - a capability which is a business
requirement of any prudent organization.

PKIX 3 requires support for key generation at (effectively) the CA, RA,
and end entity.  This is appropriate in and of itself, for reasons
unrelated to third-party Key Recovery.  In a commercial setting, I
could easily envision a CA with a good hardware random number generator
and lots of clients without them.  If the CA's policy is "generate the
key pair, send them to the client, then destroy everything related to
the private key", and the client doesn't trust the CA to follow it's
policy, then the client should get another CA.

Additional third-party-Key-Recovery-specific functionality such as what
you suggest would be good to standardize as an option, but doesn't have
to be required for PKIX compliance.

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: key recovery options for PKIX-3 CAs?
Date: Tue, 19 Aug 1997 10:29:06 -0400

Hi Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Tuesday, August 12, 1997 7:31 AM
>To: 	[email-masked]
>Subject: 	key recovery options for PKIX-3 CAs?
>
>PKIX-3 seems to imply that only CAs and LRA can perform key recovery
>duties. Surely this language should be amended such that
>
>(a) non-PKI elements can do key recovery ("KMI Agents", perhaps)
>
>(b) PKIX CAs may support/enforce key recovery options which do not depend
>upon access to private-keying material of subscribers.
>
>There seems an assumption in PKIX that the PKI/CAs will perform key
>recovery, and Im not sure that this is true, and even it if true to the
>extent that
>you cannot have a cert until some key-recovery option is
>known to be in place, such key-recovery and data-recovery
>mechanisms may be CSP-provided and not even necesssairly involve
>the CA in direct protocol terms.
>
>we may want to amend PKIX-3 to assign additional options and
>freedoms in line with (a) and (b) on the key-recovery front.

The following sentence is the only thing that the current draft has to
say on this particular topic:

   "As an option, user client key materials (e.g., a user's private key
used for decryption purposes) may be backed up by a CA, an RA, or a key
backup system associated with a CA or RA."

[Fortunately, this sentence was quite early on in the document (Section
1.3, page 8), so I didn't have to look hard to find it.  Note that this
sentence has been in a number of the previous drafts as well, so I
didn't even have to look in the current draft to find it.]  I see no
conflict whatsoever between this sentence and what has been asked for in
the text above.  Observe that "associated with" is not defined and may
therefore be as tight or as loose an association as is required by the
environment  --  in particular, it nicely accommodates the specific
requirement given above (where a certificate is not created by the CA
until a key-recovery option is known to be in place).

In another e-mail, Peter made the following comment.

>One of my worries for PKIX-3 which I intend
>to bring up during a final call process, when called, is that no two
independent
>vendor implementations  will likely work together - there are just so
>many options for supported  ASN.1 fields, transports modes, models of flow,
>optionality of functional groups etc. Some considerable text  will have to be
appended,
>prosuambly in appendices, to ensure that at least there is some  minimal
probability
>of multi-vendor material working together at some feature set, without their
being
>bilateral knowledge of the products particular implementation choices.

Although I'm a bit curious as to what defensible, standards-only reason
there could possibly be for waiting until last call to bring up such an
issue, I will note that what Peter really seems to be asking for here is
not a change to the document (which would likely limit the generality
we've all worked so hard to achieve), but essentially a profiling
activity that will ensure that two independent implementations will work
together.  An Interoperability Specification for PKI Components, if you
will.  By a happy coincidence, this happens to be precisely what most of
the letters in MISPC stand for!  In other words, this profiling activity
has already been done for one specific large-scale environment (and this
work can serve as a good model for similar activity for other
environments, if required).

Peter, I can't help but get the impression that your goal in these
e-mails is to indirectly show your full support for the PKIX-3
specification in its current form by highlighting its generality and its
acceptance in important environments (which the rest of us had either
failed to notice or forgotten to mention).  Although I must admit that
I'm a tiny bit surprised by this, I certainly thank you for your support
of the current PKIX-3.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Tue, 19 Aug 1997 09:43:20 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX and PKCS7/10

> From: Peter Williams <[email-masked]>
> 
> Try to understand that the I-D is effectively a PKCS7-stylised profile of
> PKIX-3; its got some way to go yet!

I don't think so, at least not according to the abstract:

 "this draft combines PKIX-3 concepts and PKCS10 in the context of
  PKCS7 security encapsulation to propose an alternative Certificate
  Management Protocol."

Profiling the use of PKIX-3 with an external protection mechanism is
quite useful, and in fact Appendix C of PKIX-3 is a suggestion for just
such a mechanism.   The Myers draft is not - it proposes an *alternative*
protocol which is incompatible with PKIX-3.

I fundamentally disagree with the notion that the IETF should sponsor
two incompatible protocols which perform essentially the same
function.  So does the IESG.  Even if the PKIX working group decided
to pursue an approach based on the Myers draft, the IESG would likely
not allow it to proceed to the standards track.

If a protocol is needed which:

  a) is simple to specify and implement, (but does not address most of
     the requirements of section 1.3: subscriber bootstrapping, key updating,
     repository publication, certificate revocation, CA key rollover,
     cross-certification, etc.), and

  b) leverages existing investment in PKCS-7 and PKCS-10 software

then that protocol should be a minimal, limited-functionality,
strictly specified, *compatible* subset of PKIX-3.  Since PKIX-3
already includes an alternative certificate request based on PKCS-10
and an external protection mechanism based on PKCS-7, and PKIProtection
is already OPTIONAL, all that is needed is to define a minimum
essential profile which strips out all of the "unnecessary" features
and optional alternative mechanisms.

Would not such a compatible subset satisfy the goals of the Myers
draft, and in addition allow implementors to incrementally add
functionality from full PKIX-3 as market requirements dictate?
Isn't Revocation (which the Myers draft does not address) already
part of the minimum essential subset demanded by the current
marketplace?

> Other can enter here an MSP-stylised profile
> of that same PKIX-3 framework. Get writing David! If we can put
> a PKIX-sponsored ID for further profiling PKIX-1 to enable NSA-classified KEA
> math, we can surely also bend to accomondate NSA's MSP3 (or MSP4)
> (or MSP5) if there is a sizeable pro community. Or an IPSEC w/ISAKMP
> wth a NSA domain of interpretation and algorithm suite profile...

Despite the fact that we think MSP4 is the greatest thing since
sliced bread :-), we were unable to convince the rest of the world
to go with it.  Therefore, if everything goes according
to plan, MSP5 will be identically S/MIME, based on PKCS-7 v2.0.

The disadvantages of having two incompatible protocols are too great.
We are working to standardize a single protocol that supports
functionality we regard as essential, even though it's not based on
"our" protocol.

---

Michael prefaced the draft with:

  "The question naturally emerges: How does this relate to PKIX Part 3,
   considering that PKIX Part 3 accepted changes at the last IETF which
   accommodate PKCS 7 and PKCS 10?"

But as far as I could tell, the question was never answered in the
draft -- it doesn't relate to Part 3, it is an incompatible alternative.
That is the wrong direction.

Date: Mon, 18 Aug 1997 17:25:43 +0100
From: Peter Williams <[email-masked]>
To: Mike Smith <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Mike Smith wrote:

> In this thread, there seems to be (by some) an assumption that if a "private" key is used to identify an individual by signing a session or key or during an exchange, then one "automatically" has non-repudiation with regard to all said in the encrypted electronic conversation.  The follow-on to this is that the "courts" could always be called upon to sort things out in the end.

I have heard noone affirmatively suggest such, until now. I have heard the proposition that the private
key usage can authenticate a party's acts, such that evidence is generated of sufficent stature  to
substantiate signed-writing status for such data during legal discovery and subsequent presentation
of (acceptable) evidence used as purported proof of action/intent.

(In my and Bob's messages, non-repudiation terminology -or concept - did not appear, except
as a contrasting security service to the subject matter.)

Peter.

Peter Williams <[email-masked]> 08/14/97 05:41AM

>
>Personally, I find the separation of key escrow for encryption keys from
signing
>keys to be a bogus argument. D-H and KEA Encryption keys particularly, &
arguably,
>provide for excellent data origin authentication, and thus such
authentication can be
>fraudulently used (by the escrow agent) when such a security service is
deemed
>adequate to
>construe signed-writing status on an (encrypted) message or transaction.
Baum explains
>the notion of official security-procedure conferring signed-writing status
nicely in his
>and Warwick's e-commerce book, covering UN model laws, and existing EDI
practice,
>etc.
>
>Signed-writing status is not  limited to"digital signature" security
mechanisms! if its
>inappropriate to allow FBI to forge your signatures, its similarly
inappropriate to
>allow FBI to forge signed-writings due to encryption security mechanisms.
>
>Peter.

Very thought-provoking comment, Peter

This is a level of difficulty that is in addition to the obvious problem of
how a crypto product, especially a mass-market operating system level
product, can enforce such key usage distinctions at a general API level.

Although I haven't yet acquired the Baum/Ford book, there is certainly no
doubt that a privately agreed-upon security service can confer
signed-writing status on a document. It may or may not provide some measure
of third party nonrepudiation -- for example the use of a DES keyed Message
Authentication Code presumably wouldn't. But clearly you don't want some
third party having access to "signed-writing" keys, whether digital
signature keys or some other parameters.

Hmm. Gotta think about this some more.

Bob

Date: Mon, 18 Aug 1997 17:09:51 +0100
From: Peter Williams <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Dan Geer <[email-masked]>, [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Stephen Kent wrote:

> Peter,
>

>  However, just because

> someone creates a regulation doesn't mean that they got it right, nor that
> it will ultimately be viewed as valid in later court challenges.  I would
> not like to see the PKIX work be skewed by such concerns, and I especially
> would not like to see it worded in a fashion that could be construed as
> supporting questionable use of authentictaion technology.
>
> Steve

 I have a very simple question then. Its very real.

A TLS client uses an RSA PKIX cert to bind to an https server; full RSA
only SSL handshake occurs with exchange of both server and client certificates. Lets
assume the key usage extension of the client certificate has only the digital signature bit set.
Lets assume the key usage extension of the server certificate has only the
key transport bit set.

I now use my client cert to logon to a medical records company's
https server, and I start persuing my confidential medical records online
over an encrypted SSL session. the company asks me: with
a click screen, are you Peter Williams of <address> and
do you authorise use to release medical data?" I duely
say yes, browse and save the HTML page. I happen to forward it
to my friend over email. Said friend years later abuses my trust, and publishes
the data in some yellow-journalism newspaper:

Are we saying that, despite their being no non-repudiation service
anywhere in SSL/TLS, the medical records provider has
no evidence it can present to prove that it released the information
only to an authorised party - based upon its recording
of the SSL session information?

Surely, in this very case, or in a case where parties
are obtaining credit reports, say, authentication evidence
rather than signature evidence would be presented
to the court by the medical records company to
demonstrate that *it* released the information only
to a given party, and the technical countermeasures
(SSL), reasonable trustworthy software, the keying
material, and the confirmation language, all vouch for this.

Sure this is not, and cannot be, a classical
non-repudiation scenario. The whole question the court will answer
is : did SSL ensure that the stream's intended recipient was reasonably
knows to be authenticated to Peter  - a legitimate
user, and only to that recipient was the stream delivered.

The question of evidence will be about authentication,
not non-repudiation. To demonstate that the company
took reasonable care to maintain the confidentiality
of the data, it will surely rely upon SSL data-records
as evidence of its acts to safeguard against
unauthorised access to the data, similarly,
whilst under its control, or on the wire.

Perhaps the court would be asked:

Did the complete SSL handshake and subsequent security
services and confirmation of identity over https constitue a signed-writing
(not a signature , note) authorising release of the requested data?

Its only a matter of time before precisly such a dispute
is now raised as SSL client auth spreads. The question
will be entirely about authentication and its legal
meaning.

Lets forget about MSP ( my error for introduction!), and concentrate
entirely where there are no "Proof of Origin
with Non-Repudiation" mechanisms present whatsoever
to cloud the analysis. Surely PKIX certs will play
an evidentiary role, as will SSL stored session data?

Date: Mon, 18 Aug 1997 17:57:06 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

In this thread, there seems to be (by some) an assumption that if a "private" key is used to identify an individual by signing a session or key or during an exchange, then one "automatically" has non-repudiation with regard to all said in the encrypted electronic conversation.  The follow-on to this is that the "courts" could always be called upon to sort things out in the end.  

I posit that one does not have non-repudiation unless explicated during the conversation with transaction integrity and user authentication tied to the actual transaction in a (computationally unfeasible) secure manner (i.e., by use of a "traditional" digital signature of the encrypted hash of the object).  Furthermore, I posit that, if "key usage" is not set to digital signature with non-repudiation, then courts will not automatically accept such claims.  

Knowing who is in a conversation and what was said does not constitute a contract or agreement - even under common law - unless the "intent" to commit to an agreement is made.  "Non-repudiation" comes in if it is accepted that every entity that made the commitment was known and their intent was noted (in writing, electronically or verbally) and that what they committed to was unalterable after the fact by any of the parties involved or a third party.  

If asked to sign a contract in the real world, everything said before, during and after a contract signing does not enter into the contract that was signed by implication, unless the "intent" to add verbally committed items is specifically acknowledged.  Use of encryption would bring all the conversation into discussion, not the specific transaction (i.e., authorization to Broker to buy "x" shares of stock)

Digital signatures are an attempt, I believe, to reduce litigation and explicate what acceptance of an agreement could be, with integrity and non-repudiation.  As the ABA discussions about common law and signatures says (my interpretation), any mark or no mark can imply a "signature" or acceptance of an agreement, written or not.  The digital signature process and usage was designed to explicate the acceptance and unalteration of the object signed (agreement entered).  

Example:  One establishes an encrypted session wherein the originating party (or both parties) has "signed" (encrypted) the session's crypto key with a "private" key of some sort and this is validated by the "other" party. Any contesting party should then be able to state that "my key was not set to usage = non-repudiation and/or digital signature, so that you should not be able to enforce any transactions inside that encrypted session.  You may know who began the conversation, but can not prove what either of us did during that session, since no integrity checks were done (e.g., your representative could have "forged" a transaction in the record that was hidden from me or that was said to have originated with me".   One would not get any integrity checks (encrypted transaction hash or "signature") on each transaction consummated during that session. Resolution would come only for a contested session after court review or arbitration.  

I do not feel that even if both parties recorded all the activity during that session under the "signed" session key would constitute "non-repudiation" and would lead to or even necessitate court intervention even where law or administrative rules defined digital signatures for non-repudiation.  Also, if this usage is "allowed" via PKIX, then shouldn't this record keeping be required for any potential non-repudiation process wherein the intent is to use this session key as a "signature"?

The PKIX public key infrastructure is being designed to support multiple objectives, including some of the shared secret systems (no "public" keys), asymmetric cryptographic and digital signature systems, and I agree with those inclusions for completion, but keep them separate within the overall framework

Thanks for your patience on this rant.

Michael

>>> Peter Williams <[email-masked]> 08/18/97 05:36AM >>>
Stephen Kent wrote:

> Dan,

>         If I understand Peter's comments re escrow of encryption keys, I
> don't agree with his conclusion.  Yes, legally, one can use encryption or
> MAC technology and have it be considered equivalent to signing.  However,
> we all know that this is technically inappropriate, and the inclusion of
> usage bits in X.509 certificates allows us to make explicit just how
> inappropriate this is.

I do not know that it is wholly inappropriate, technically.

Do you agree that, as you use of the world "legally" might  imply, that
a court, presumably operating under common law, would likely not fail
to recognise the authentication value of a ciphered stream identifying the
originator of the stream (with no digital signature), given
the labelling of the stream with id, categories and sensitivity
markings derived from those same markings
attached to the (encryption) certificate assigned to the
duely authorised originating party?

(I'm thinking here precisely of MSP3 protocol as currently
deployed by DoD and NSA for ensuring access control
via cryptographic separation, originator identity, and label
markings)

The X.509 usage bits in a cert are intended for use by the relying party.
They signal the CA's intention for use of the key in association
with a trusted security mechanism. Nothing more.

They do not convey commerce or legal semantics; that
is the function of policy extensions. Should a policy
choose to explicitely enable the legal validity of
encryption-derived authentication, there is
no basis in X.509 (v3) for disallowing this that
I can see.

I can see no basis in PKIX scope or requirements
to deny authentication-only-semantics, when applying
PKIX-certs, over digital-signature semantics,
or confidentiality-semantics - once such are
expressed clearly via policy.

One can imagine one day seeing the
"ABA Authentication Guidelines" emerging
alongside the ABA Digital Signature Guidelines,
and the "ABA Confidentiality Guidelines", as
frameworks for legalistic policy expression
in support of PKIX CA operators providing
third-party assurances in those spheres.

>
>
> Steve

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

Date: Mon, 18 Aug 1997 16:21:19 +0100
From: Peter Williams <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

Using today's RSA SSL enrollment infrastructure, this is very simple to achieve
as I'm sure you know. User contacts CA, generates key, makes cert request,
request is pending. User goes to escrow agent, presents private key over 128bit channel,
obtains escrow-issued client-auth cert for said key, with policy extensions constraining its use
for presentation to regulated CAs.. User goes to one of nominated CAs and
over SSL presents escrow-authority's client-auth cert to signal previous desposit
of private key for named public key in client-auth cert. CA
has proofs it needs; deposit has occured. Issues cert as normal; software
replaces existing escrow-issued temp client-auth cert with CA-issued
cert.

Key escrow receipt, and acceptance of escrow policy by the subscriber,
with all attendent legal stuff, and dates, is the  "receipt".

This may be actually doable today, if Netscape browsers for example
allow the cert chain standing for a user's private key authority to be substituted
(under  appropriate controls) in the platforms key/cert store. The original cert chain
is the receipt; its replaced by the CA chain once issued; receipt
is discarded or sent to audit log.

----------

Now, to PKIX:

In the brand new PKIX-3 way of doing the same thing, surely all one needs to
do is have a split of responsibility. The CA functional groups of PKIX-3 are
performed by PKI entities; the same PLUS the key recovery functional group are
performed by the organizational or national Key Recovery agent.

Policy over forcing CAs to be controlled by escrow policy is then
instrumented by regulation/contract governing verification keys used by CAs
to validate the key escrow receipt and confirm its operational status, with
confirmation being ordained by regulation/contract prior to CA cert issuance.

There would seem to be lots of PKIX ways to instrument the unbundling of
CAs and key-recovery agents, yet enforce a key-desposit policy
prioir to issuance of a cert. The use of signed-receipts obviously
allows juridicitional controls to be imposed by the escrow authority -
thou shalt only issue names with leading RDN c=US, for example.

Apart from altering PKIX-3 language to allow this separation, do we
need to standardize anything? Surely all it needs is local management
policies to configure such mechanisms together if certs themselves
serve as the receipt mechanism.

Peter.

Anil R. Gangolli wrote:

> Mark Shuttleworth's second point about separating the CA and the
> Key Escrow/Recovery Agent is still a valid and important one.
>
> The model I have advocated earlier is that there be a standardized
> format for a "key escrow receipt".   This would be a message effectively
> asserting that "the private key associated with public key X has been
> escrowed with me and will be kept by me until at least date D, signed
> <escrow agent>".
>
> A CA or other entity (e.g. RA) may enforce a requirement that
> clients present such a receipt from an approved agent (as determined
> by its policy) as part of any request for a certificate in which certain
> key usage indications are present.  (e.g. A CA may require this
> to certify key exchange keys but not signing only keys).
>
> Consider for example a company who wishes to use a CA
> administered by an outside agency but wishes to keep
> its own keys, or run its own internal recovery
> (or generation) service.
>
> --a.
>
> --
> Anil R. Gangolli
> Structured Arts Consulting Group
> mailto:[email-masked]
> http://www.StructuredArts.com

Date: Mon, 18 Aug 1997 18:41:43 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: Dan Geer <[email-masked]>, [email-masked]

Peter,

	Let me address the examples you cite, first.

	MSP provides distinct mechanisms for authentication vs.
non-repudiation, precisely to minimize the confusion that could arise from
using one mechanism instead of another.  (This is unlike other secure
e-mail protocols, that tend to require use of signatures to provide
authentication, even if NR was not desired.)  The distinction is important.
If I sign the message, then I have explicitly invoked the NR service and I
should have to stand behind what I sent if there is a later dispute.  If I
don't sign it, then the receiver will probably rely on the authentication
provided, but is not able to prove to a third party that I sent the message
in question.

	For use in the DMS, all organizational messages are signed, with
the explicit intent that this provide a basis for NR.  The sensitivity
labels etc. stike me as irrelevant to this discussion.  They are intended
to help control handling of the data contained within the system,
irrespective of the identity of the sender. In fact, in many systems, the
sender will not be able to select the labels to be applied; they are
mandatory labels applied by the system itself.

	I used the term "legally" to suggest that a court might recognize
the use of an authentication technology as a "signature," which is
technically inappropriate.  In fact we have examples of regulations in the
government environment that do just that.  The banking community has long
viewed MACs as providing NR, even though we know they do not.  (In
fariness, the banks rely on a number of other procedural security
mechanisms to support this NR claim, but ...)   However, just because
someone creates a regulation doesn't mean that they got it right, nor that
it will ultimately be viewed as valid in later court challenges.  I would
not like to see the PKIX work be skewed by such concerns, and I especially
would not like to see it worded in a fashion that could be construed as
supporting questionable use of authentictaion technology.

Steve

Date: Mon, 18 Aug 1997 15:00:07 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

Mark Shuttleworth's second point about separating the CA and the
Key Escrow/Recovery Agent is still a valid and important one.

The model I have advocated earlier is that there be a standardized
format for a "key escrow receipt".   This would be a message effectively
asserting that "the private key associated with public key X has been
escrowed with me and will be kept by me until at least date D, signed
<escrow agent>".

A CA or other entity (e.g. RA) may enforce a requirement that
clients present such a receipt from an approved agent (as determined
by its policy) as part of any request for a certificate in which certain
key usage indications are present.  (e.g. A CA may require this
to certify key exchange keys but not signing only keys).

Consider for example a company who wishes to use a CA
administered by an outside agency but wishes to keep
its own keys, or run its own internal recovery
(or generation) service.

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

Date: Mon, 18 Aug 1997 12:36:21 +0100
From: Peter Williams <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Dan Geer <[email-masked]>, [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Stephen Kent wrote:

> Dan,

>         If I understand Peter's comments re escrow of encryption keys, I
> don't agree with his conclusion.  Yes, legally, one can use encryption or
> MAC technology and have it be considered equivalent to signing.  However,
> we all know that this is technically inappropriate, and the inclusion of
> usage bits in X.509 certificates allows us to make explicit just how
> inappropriate this is.

I do not know that it is wholly inappropriate, technically.

Do you agree that, as you use of the world "legally" might  imply, that
a court, presumably operating under common law, would likely not fail
to recognise the authentication value of a ciphered stream identifying the
originator of the stream (with no digital signature), given
the labelling of the stream with id, categories and sensitivity
markings derived from those same markings
attached to the (encryption) certificate assigned to the
duely authorised originating party?

(I'm thinking here precisely of MSP3 protocol as currently
deployed by DoD and NSA for ensuring access control
via cryptographic separation, originator identity, and label
markings)

The X.509 usage bits in a cert are intended for use by the relying party.
They signal the CA's intention for use of the key in association
with a trusted security mechanism. Nothing more.

They do not convey commerce or legal semantics; that
is the function of policy extensions. Should a policy
choose to explicitely enable the legal validity of
encryption-derived authentication, there is
no basis in X.509 (v3) for disallowing this that
I can see.

I can see no basis in PKIX scope or requirements
to deny authentication-only-semantics, when applying
PKIX-certs, over digital-signature semantics,
or confidentiality-semantics - once such are
expressed clearly via policy.

One can imagine one day seeing the
"ABA Authentication Guidelines" emerging
alongside the ABA Digital Signature Guidelines,
and the "ABA Confidentiality Guidelines", as
frameworks for legalistic policy expression
in support of PKIX CA operators providing
third-party assurances in those spheres.

>
>
> Steve

Date: Mon, 18 Aug 1997 11:14:52 +0100
From: Peter Williams <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX and PKCS7/10

David P. Kemp wrote:

> > From: "Rich Ankney" <[email-masked]>
> >
> > I understand where you're coming from.  OTOH, there are quite a few of us
> > who have big investments in PKCS-7/10.  I'd like to treat the two
> > alternatives as separate but equal, but ONLY if PKCS-7/10 can be tweaked to
> > do EVERYTHING that PKIX-3 does (this is not at all obvious).
>
> That brings up the question of what exactly is the purpose of the
> separate PKCS-7 proposal?  Does Michael intend it to:
>
> 1) replace (eliminate) PKIX part 3,
> 2) be a separate-but-equal-functionality alternative to PKIX-3, or
> 3) be a minimal protocol that performs just the "essential subset"
>     required for issuing certs?
>
> I would oppose any attempt to modify the working group's charter
> to do anything other than option 3, i.e. recognize existing practice.
>
> Specifically, it *doesn't* make sense to spend a lot of time and energy
> tweaking PKCS-7/10 to duplicate everything that is already done by PKIX-3.
>
> (Incidentally, I still haven't heard an answer as to whether the
> proposal is going to change to track the development of PKCS-7 and S/MIME,
> or whether it is frozen using PKCS-7 version 1.5.)
>
> > CertCo's
> > motivation in all of this is that PKCS-7 lets us "append" stuff (which must
> > remain nameless right now) to the original message.  This is demonstrated
> > really well in the Myers draft, where the whole PKIX header is conveyed as
> > authenticated attributes...
>
> If your "stuff" is "nameless", how can it be standardized to guarantee
> interoperability between different providers?  I find it hard to reconcile
> Peter's claim that PKIX-3 is so flexible that interworking is not assured
> with your claim that PKCS-7 is flexible enough to allow private "stuff".
>
> And is there any reason that you could not use PKIX-3 and put your
> information into the PKIFreeText field of the PKIHeader structure?
> (or if it's not human-readable, propose the addition to PKIX-3 of a new
> uninterpreted "PKIFreeData" field just after PKIFreeText?)

David,

PKCS7 (and other external protection conventions) is already part of PKIX-3;
the PKCS7 formats are self-standing, and yet  PKCS7 is architecturally bound in
an  external-protection model which was reasoned to benefit PKIX-3.

Do you accept the thrust of this statement?

If so, we can usefully proceed.

Do you understand that the PKIX-3 "external protection model"  is a placeholder for
a whole class of local mechanisms, and bundling options?

Should MISSI clients procure a PKIX-3 commercial system, and turn
off its support for that "low-grade" RSA/DES internal protection stuff, then they
can use the existing infrastructure of MSP/Fortezza instead, via
MIME security multiparts, or SSL w/Fortezza, with
local NSA-grade administration and context management on this crucial
part of the remote key management bootstrapping users with automatically
assigned keys.

Try to understand that the I-D is effectively a PKCS7-stylised profile of
PKIX-3; its got some way to go yet! Other can enter here an MSP-stylised profile
of that same PKIX-3 framework. Get writing David! If we can put
a PKIX-sponsored ID for further profiling PKIX-1 to enable NSA-classified KEA
math, we can surely also bend to accomondate NSA's MSP3 (or MSP4)
(or MSP5) if there is a sizeable pro community. Or an IPSEC w/ISAKMP
wth a NSA domain of interpretation and algorithm suite profile...

etc.

Date: Mon, 18 Aug 1997 09:33:11 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 15 Aug 1997, Stephen Kent wrote:
> 
> Rodney,
> 
> 	There are reasons for having a CA generate a key pair for its
> users, other than key recovery.

Absolutely, but that doesn't mean that PKIX should mandate key-generation
by the CA.

> For example, a CA may insist on generating
> keys to ensure that the keys are generated using a good RNG, or to prevent
> a user from putting the same key in multiple certificates.

The first example is good and fine, but again there's no reason to make it
mandatory.  The same goes for the second example, and I don't see how
it prevents key re-use in a multi-CA environment anyway.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6210x227      www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

Date: Mon, 18 Aug 1997 11:52:51 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

> Date: Sun, 17 Aug 1997 09:58:07 +0200 (SAT)
> From: Mark Shuttleworth <[email-masked]>
> 
> Nonsense, Stephen.  A key that has been known to more than one entitity is
> not a private key, period.
> 
> I have no doubt that key recovery will be a commercial requirement in some
> cases, and that the PKIX effort should address it to provide
> standardisation of interfaces and protocols.  But it should be a
> COMPLETELY separate thing to key certification.  Yes, players may choose
> to do both.  That is natural.  As someone said, a CA is already in a
> position of trust, and hence would be in a good position to enter the key
> management market if it so chose.  But to make it a required portion of
> the CA-compliant PKIX interface goes against stated IETF goals (RFC1984).

Nonsense, Mark :-).  There is a difference between
REQUIRED-to-implement and REQUIRED-to-use.

The IETF interpretation of REQUIRED is that software must support a
feature if the user chooses to enable it.  It is purely a matter of
individual policy between users and CAs whether private keys are
transported in PKIX messages or known to anyone other than the end
entity.

(From one perspective, the IETF interpretation doesn't make a lot of
sense - there is no way for a user at one end of a protocol pipe to
determine whether a REQUIRED feature of *any* protocol is turned off at
the other end or simply not implemented.  So compliance cannot be
determined simply by probing or examining the protocol datastream.  But
that's the IETF way, and it's not likely to change.)

Requiring PKIX implementations to allow private key transport does
not require anyone to do key recovery, both because there are non-KR
uses for key transport and because the feature can be turned off
by anyone who chooses not to use it.

Date: Sun, 17 Aug 1997 09:58:07 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Stephen Kent <[email-masked]>
cc: Rodney Thayer <[email-masked]>, [email-masked]
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

> 	There are reasons for having a CA generate a key pair for its
> users, other than key recovery.  For example, a CA may insist on generating
> keys to ensure that the keys are generated using a good RNG, or to prevent
> a user from putting the same key in multiple certificates.  If the CA does
> not retain the private key after providing it to the user, or save a copy
> in some form with other PKI components, then it is not performing key
> recovery.

Nonsense, Stephen.  A key that has been known to more than one entitity is
not a private key, period.

I have no doubt that key recovery will be a commercial requirement in some
cases, and that the PKIX effort should address it to provide
standardisation of interfaces and protocols.  But it should be a
COMPLETELY separate thing to key certification.  Yes, players may choose
to do both.  That is natural.  As someone said, a CA is already in a
position of trust, and hence would be in a good position to enter the key
management market if it so chose.  But to make it a required portion of
the CA-compliant PKIX interface goes against stated IETF goals (RFC1984).

IMO you will only end up with many non-compliant CA's.

--
Mark Shuttleworth
Thawte Consulting

Date: Fri, 15 Aug 1997 09:13:56 -0500
To: Rodney Thayer <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?
Cc: [email-masked]

Rodney,

	There are reasons for having a CA generate a key pair for its
users, other than key recovery.  For example, a CA may insist on generating
keys to ensure that the keys are generated using a good RNG, or to prevent
a user from putting the same key in multiple certificates.  If the CA does
not retain the private key after providing it to the user, or save a copy
in some form with other PKI components, then it is not performing key
recovery.

Steve

Date: Fri, 15 Aug 1997 05:19:51 -0500
To: Dan Geer <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Dan,

	Escrowing signature keys is a bad idea, period.  None of the U.S.
government initiatives calls for such escrow, and the FIPS that is under
development for key recovery expressly states that it does NOT apply to
signature keys.

	If I understand Peter's comments re escrow of encryption keys, I
don't agree with his conclusion.  Yes, legally, one can use encryption or
MAC technology and have it be considered equivalent to signing.  However,
we all know that this is technically inappropriate, and the inclusion of
usage bits in X.509 certificates allows us to make explicit just how
inappropriate this is.

Steve

From: <[email-masked]>
To: [email-masked]
Date: Fri, 15 Aug 1997 18:37:06 -0400
Subject: Re: Definitions and design criteria for message digest functions

Take a look at chapter 9 of the Menezes, Oorschot, and Vanstone, book,
Handbook of Applied Cryptography, which contains an excellent compilation
of definitions, taxonomy, and facts about hash functions.  It draws heavily
on B. Preneel's 1993 PhD thesis, Analysis and Design of Cryptographic Hash
Functions.

Relevant to this discussion, they give a "pathological" counter-example (p
330) that proves that, technically, collision resistance does not guarantee
preimage resistance, and hence does not guarantee one-wayness.  But they
also say that for most collision-resistent hash functions arising in
practice it is usually a safe assumption that preimage resistance is also
true.

-Gene Hilborn

Date: Fri, 15 Aug 1997 13:50:59 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX and PKCS7/10

I would like to echo the sentiment that it is good to see CertCo participating in the public forums and standards arenas.

As you know, we would like to also see standardized time stamping and time stamping authority identified in the PKCS 7/10 wrappers, but as part of a signed element.

Michael

>>> "Rich Ankney" <[email-masked]> 08/15/97 11:55AM >>>
----------
> From: David P. Kemp <[email-masked]>
> To: [email-masked] 
> Subject: Re: PKIX and PKCS7/10
> Date: Friday, August 15, 1997 10:43 AM
> 
> > From: "Rich Ankney" <[email-masked]>
> > 
> > I understand where you're coming from.  OTOH, there are quite a few of
us
> > who have big investments in PKCS-7/10.  I'd like to treat the two
> > alternatives as separate but equal, but ONLY if PKCS-7/10 can be
tweaked to
> > do EVERYTHING that PKIX-3 does (this is not at all obvious).
> 
> 
> That brings up the question of what exactly is the purpose of the
> separate PKCS-7 proposal?  Does Michael intend it to:
> 
> 1) replace (eliminate) PKIX part 3,
> 2) be a separate-but-equal-functionality alternative to PKIX-3, or
> 3) be a minimal protocol that performs just the "essential subset"
>     required for issuing certs?
> 
> I would oppose any attempt to modify the working group's charter
> to do anything other than option 3, i.e. recognize existing practice.
> 

I had figured (3), or even (2) if it works out that way.

> Specifically, it *doesn't* make sense to spend a lot of time and energy
> tweaking PKCS-7/10 to duplicate everything that is already done by
PKIX-3.
> 

IMHO, it's worth a LITTLE effort to do that, though.

> (Incidentally, I still haven't heard an answer as to whether the
> proposal is going to change to track the development of PKCS-7 and
S/MIME,
> or whether it is frozen using PKCS-7 version 1.5.)
> 
> 
> 
> > CertCo's
> > motivation in all of this is that PKCS-7 lets us "append" stuff (which
must
> > remain nameless right now) to the original message.  This is
demonstrated
> > really well in the Myers draft, where the whole PKIX header is conveyed
as
> > authenticated attributes...
> 
> 
> If your "stuff" is "nameless", how can it be standardized to guarantee
> interoperability between different providers?  I find it hard to
reconcile
> Peter's claim that PKIX-3 is so flexible that interworking is not assured
> with your claim that PKCS-7 is flexible enough to allow private "stuff".
> 

PKIX-3 is flexible in that there are a lot of options that both sides might
not support.  PKCS-7 goes beyond that in allowing the message to contain
"authenticated attributes", which seems like a nice extension mechanism to
me.  One could encapsulate a PKIX-3 message (header and body with no
protection bits) in a PKCS-7 SignedData, and include other stuff as
attributes.  This is what the latest PKCS-7/10 proposal does with the
PKIHeader fields, as a matter of fact.

> And is there any reason that you could not use PKIX-3 and put your
> information into the PKIFreeText field of the PKIHeader structure?
> (or if it's not human-readable, propose the addition to PKIX-3 of a new
> uninterpreted "PKIFreeData" field just after PKIFreeText?)

We'll have some suggestions on what else would be useful (e.g. billing
info) soon (in the next week or so).  I could certainly live with a
PKIFreeData field, as well (preferably as an OID + ANY (or OCTET STRING)
structure).  I guess the real question is, is there a need for really
private extensions to PKIX-3, vs. defining everything up front?  

Comments?

/ Rich

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

Date: Fri, 15 Aug 1997 18:58:24 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Digital Ltd.
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Definitions and design criteria for message digest functions, etc.

David P. Kemp wrote:
> Collision resistance is definitly different from one-wayness.  I'm
> still pondering Ben's proof that collision-resistance implies
> one-wayness.  It seems obviously true, but you'd think it would have
> been explicitly mentioned in the literature.  I may be missing
> something.

Woo! Did I do something new? (I haven't seen it anywhere either, but
then I'm not as widely read as I'm sure others here are).

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: [email-masked] |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

From: "Rich Ankney" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: PKIX and PKCS7/10
Date: Fri, 15 Aug 1997 13:55:09 -0400

----------
> From: David P. Kemp <[email-masked]>
> To: [email-masked]
> Subject: Re: PKIX and PKCS7/10
> Date: Friday, August 15, 1997 10:43 AM
> 
> > From: "Rich Ankney" <[email-masked]>
> > 
> > I understand where you're coming from.  OTOH, there are quite a few of
us
> > who have big investments in PKCS-7/10.  I'd like to treat the two
> > alternatives as separate but equal, but ONLY if PKCS-7/10 can be
tweaked to
> > do EVERYTHING that PKIX-3 does (this is not at all obvious).
> 
> 
> That brings up the question of what exactly is the purpose of the
> separate PKCS-7 proposal?  Does Michael intend it to:
> 
> 1) replace (eliminate) PKIX part 3,
> 2) be a separate-but-equal-functionality alternative to PKIX-3, or
> 3) be a minimal protocol that performs just the "essential subset"
>     required for issuing certs?
> 
> I would oppose any attempt to modify the working group's charter
> to do anything other than option 3, i.e. recognize existing practice.
> 

I had figured (3), or even (2) if it works out that way.

> Specifically, it *doesn't* make sense to spend a lot of time and energy
> tweaking PKCS-7/10 to duplicate everything that is already done by
PKIX-3.
> 

IMHO, it's worth a LITTLE effort to do that, though.

> (Incidentally, I still haven't heard an answer as to whether the
> proposal is going to change to track the development of PKCS-7 and
S/MIME,
> or whether it is frozen using PKCS-7 version 1.5.)
> 
> 
> 
> > CertCo's
> > motivation in all of this is that PKCS-7 lets us "append" stuff (which
must
> > remain nameless right now) to the original message.  This is
demonstrated
> > really well in the Myers draft, where the whole PKIX header is conveyed
as
> > authenticated attributes...
> 
> 
> If your "stuff" is "nameless", how can it be standardized to guarantee
> interoperability between different providers?  I find it hard to
reconcile
> Peter's claim that PKIX-3 is so flexible that interworking is not assured
> with your claim that PKCS-7 is flexible enough to allow private "stuff".
> 

PKIX-3 is flexible in that there are a lot of options that both sides might
not support.  PKCS-7 goes beyond that in allowing the message to contain
"authenticated attributes", which seems like a nice extension mechanism to
me.  One could encapsulate a PKIX-3 message (header and body with no
protection bits) in a PKCS-7 SignedData, and include other stuff as
attributes.  This is what the latest PKCS-7/10 proposal does with the
PKIHeader fields, as a matter of fact.

> And is there any reason that you could not use PKIX-3 and put your
> information into the PKIFreeText field of the PKIHeader structure?
> (or if it's not human-readable, propose the addition to PKIX-3 of a new
> uninterpreted "PKIFreeData" field just after PKIFreeText?)

We'll have some suggestions on what else would be useful (e.g. billing
info) soon (in the next week or so).  I could certainly live with a
PKIFreeData field, as well (preferably as an OID + ANY (or OCTET STRING)
structure).  I guess the real question is, is there a need for really
private extensions to PKIX-3, vs. defining everything up front?  

Comments?

/ Rich

From: <[email-masked]>
X400-Received: by mta switchgate.switch.ch in /ADMD=SWITCHgate/C=ch/; Relayed; Fri, 15 Aug 1997 18:23:25 +0200
X400-Received: by mta UNIWORLD-SAT05 in /ADMD=SWITCHHOP/C=CH/; Relayed; Fri, 15 Aug 1997 18:24:36 +0200
X400-Received: by /ADMD=400NET/C=NL/; Relayed; Fri, 15 Aug 1997 18:23:03 +0200
X400-Received: by /ADMD=400NET/C=SE/; Relayed; Fri, 15 Aug 1997 18:22:58 +0200
Date: Fri, 15 Aug 1997 18:22:58 +0200
X400-Originator: [email-masked]
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/ADMD=400NET/C=SE/;MHSP25MHBB R0014000871662177176]
Original-Encoded-Information-Types: teletex
X400-Content-Type: P2-1984 (2)
To: Wolfgang Schneider <[email-masked]> (Non Receipt Notification  Requested), [email-masked] (Non Receipt Notification Requested)
Subject: RE: Padding in the context of signature algorithms

=0D=0CYes, the padding has to be defined.
Do anyone have a well deployed padding for SHA-1?

/Bengt Ackzell

Date: Fri, 15 Aug 1997 11:12:06 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: Definitions and design criteria for message digest functions,etc.

At 09:56 AM 8/15/97 -0400, David P. Kemp wrote:

>Collision resistance is definitly different from one-wayness.  I'm
>still pondering Ben's proof that collision-resistance implies
>one-wayness.  It seems obviously true, but you'd think it would have
>been explicitly mentioned in the literature.  I may be missing
>something.
>
>But as noted in the Handbook and your quotes from Rivest and Snow,
>collision resistance is the property required for hash functions used
>as part of a digital signature.  One-wayness is (may be?) just a side
>effect.

I have resisting adding to a thread that at first seemed longer than
justified by the subject, however this has now gotten interesting.

The point is that the term "one-wayness" is misleading, since, as someone
else pointed out, there are two types of "one-wayness" which we might call
weak and strong.

Weak one-wayness means it is hard to find the exact message that was used to
generate the hash.  Because of information loss, this applies to any hash as
long as the message is (substantially) larger than the hash.

Stong one-wayness means that it is hard to find *any* message that matches
the hash.  There are security related situations where this is sufficient
without the non-collision property.  For example, I might compute hash
values for all of my disk files and store the hashes offline, for later
comparison.

This is not merely academic, as the published weaknesses in MD2 and MD5 are
attacks on the non-collision property, not the strong one-wayness.

Even in the case of digital signatures, the insistence on non-collision is
prudent, but does involve a somewhat unlikely attack. The attacker must
generate two messages that hash the same, with the additional property that
the victim can be induced to sign one and that the attacker will receive
some benefit from the perception that the other was signed.  In most common
cases, signed objects will have been generated (at least in part) by the signer.

Hal
  
=================================================================
Harold W. Lockhart Jr.            PLATINUM technology, Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (617)273-6406              Fax: (617)229-2969
=================================================================

Date: Fri, 15 Aug 1997 10:43:25 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX and PKCS7/10

> From: "Rich Ankney" <[email-masked]>
> 
> I understand where you're coming from.  OTOH, there are quite a few of us
> who have big investments in PKCS-7/10.  I'd like to treat the two
> alternatives as separate but equal, but ONLY if PKCS-7/10 can be tweaked to
> do EVERYTHING that PKIX-3 does (this is not at all obvious).

That brings up the question of what exactly is the purpose of the
separate PKCS-7 proposal?  Does Michael intend it to:

1) replace (eliminate) PKIX part 3,
2) be a separate-but-equal-functionality alternative to PKIX-3, or
3) be a minimal protocol that performs just the "essential subset"
    required for issuing certs?

I would oppose any attempt to modify the working group's charter
to do anything other than option 3, i.e. recognize existing practice.

Specifically, it *doesn't* make sense to spend a lot of time and energy
tweaking PKCS-7/10 to duplicate everything that is already done by PKIX-3.

(Incidentally, I still haven't heard an answer as to whether the
proposal is going to change to track the development of PKCS-7 and S/MIME,
or whether it is frozen using PKCS-7 version 1.5.)

> CertCo's
> motivation in all of this is that PKCS-7 lets us "append" stuff (which must
> remain nameless right now) to the original message.  This is demonstrated
> really well in the Myers draft, where the whole PKIX header is conveyed as
> authenticated attributes...

If your "stuff" is "nameless", how can it be standardized to guarantee
interoperability between different providers?  I find it hard to reconcile
Peter's claim that PKIX-3 is so flexible that interworking is not assured
with your claim that PKCS-7 is flexible enough to allow private "stuff".

And is there any reason that you could not use PKIX-3 and put your
information into the PKIFreeText field of the PKIHeader structure?
(or if it's not human-readable, propose the addition to PKIX-3 of a new
uninterpreted "PKIFreeData" field just after PKIFreeText?)

Date: Thu, 14 Aug 1997 12:07:15 +0100
From: Peter Williams <[email-masked]>
To: Rich Ankney <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX and PKCS7/10

Rich Ankney wrote:

> I understand where you're coming from.  OTOH, there are quite a few of us
> who have big investments in PKCS-7/10.  I'd like to treat the two
> alternatives as separate but equal, but ONLY if PKCS-7/10 can be tweaked to
> do EVERYTHING that PKIX-3 does (this is not at all obvious).  CertCo's
> motivation in all of this is that PKCS-7 lets us "append" stuff (which must
> remain nameless right now) to the original message.  This is demonstrated
> really well in the Myers draft, where the whole PKIX header is conveyed as
> authenticated attributes...

Glad you like the mechanism; its really cute, semantically. And its great for
ensuring access to keys, or unenciphered info, only occurs when strictly necessary in
a distributed transaction processing system serving as a PKIX-3 cert server
and CA..

The external bodypart mechanism in PKIX-3 clearly allows everything
that PKIX-3 allows, by definition; all it is intended to do is substitute an inband
protection envelope, with an external protection envelope, provided
by sub-protocol or lower layer services.

Appending proprietary stuff unless the protocol is architected for
vendor-extensibility is really not good Internet behaviour, though, Rich. If
you have a requirement, declare it now, so we can make a standard mechanism
available to all, fairly.

What is your nameless CertCo stuff, and motivations? Now is your chance to reveal all
requirements for the WG scope and influence the standard according to IETF
pre-competitive, non-commercial process. Having recently promised
to fully take part in PKIX, and wth your disclosure of new requirements, CertCo
is really now obliged under the prevailing  traditions to come clean and be wholly
open on technical requirements, and engineering adequacy of the specified
mechanisms.

Is there anything critically missing in PKIX-3, Rich?

Date: Fri, 15 Aug 1997 09:56:26 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Definitions and design criteria for message digest functions, etc.

> From: Bob Jueneman <[email-masked]>
> 
> After I had sent my original reply to Ben's message, I checked Bruce
> Schneier's book (Applied Cryptography, edition 2) to see what his definition
> of a one-way function was. And now I know why we may not all be on the same
> page.

Another data point:

The Handbook of Applied Cryptography says (on p.33):

  "A hash function is a computationally efficient function mapping
  binary strings of arbitrary length to binary strings of some fixed
  length, called hash-values.

  ... To be of cryptographic use, a hash function h is typically chosen
  such that it is computationally infeasible to find ... colliding inputs
  x and y such that h(x) = h(y), and that given a specific hash value y
  it is computationally infeasible to find an input x such that h(x) = y.

  The most common cryptographic uses of hash functions are with digital
  signatures and for data integrity. ... [for digital signatures] the
  inability to find two messages with the same hash-value is a security
  requirement, since otherwise, the signature on one message would be
  the same as that on another.

  Has functions as discussed above are typically publicly known and involve
  no secret keys.  When used to detect whether the message input has been
  altered, they are called modification detection codes (MDCs).  Related
  to these are hash functions which involve a secret key, and provide
  data origin authentication as well as data integrity; these are called
  message authentication codes (MACs)."

>From the above definitions, it doesn't sound like hash functions used
as part of a digital signature should be called MDCs, since the hash is
not really a standalone component and the purpose of the signature as a
unit is to provide both integrity and authentication, not just
integrity.

> Footnoting Merkle's dissertation, he states that one-way hash functions have
> the following additional characteristics that make them one-way:
> 
> 1.  Given M, it is easy to compute h.  [This is obvious, and no problem.]
> 
> 2.  Given h, it is hard to compute M such that H(M) = h.  
> 
> 3.  Given M, it is hard to find another message, M', such that H(M) = H(M').
>  [Surprise! ]
> 
> At least to me, this property isn't implied or at all obvious from the
> English-language term "one-way," and therefore I don't feel that term is
> particularly appropriate for this definition. Warwick Ford's book, Computer
> Communication Security, p. 113, includes property 2, but does not mention
> property 3.

3 is obvious simply by substitution of 1 into 2.  If you are given
M then you are in effect given h.  3 hardly deserves mention as a separate
property, it is just a corollary of the first two.

> Schneier then goes on to talk about an additional property that is
> "sometimes" (?) required, collision-resistance:
> 
> 4. It is hard to find two random messages, M and M' such that H(M) = H(M').
> 
> It isn't clear from the book whether he considers this to be a defined
> property of a one-way hash function, or an additional requirement over and
> above one-wayness.

Collision resistance is definitly different from one-wayness.  I'm
still pondering Ben's proof that collision-resistance implies
one-wayness.  It seems obviously true, but you'd think it would have
been explicitly mentioned in the literature.  I may be missing
something.

But as noted in the Handbook and your quotes from Rivest and Snow,
collision resistance is the property required for hash functions used
as part of a digital signature.  One-wayness is (may be?) just a side
effect.

> My personal preference would be to define and use the term "Manipulation
> Detection Code" as the clearest expression of what is required, but that is
> admittedly a mouthful. Since that term hasn't stuck after almost 20 years,
> perhaps due to the lack of a suitable verb, my suggestion would be to
> appropriately define and use either "message digest" or "secure hash." 
> 
> The prevailing using seems to be message digest, so I would echo Bill Burr
> and suggest we go with that in all PKIX documents.

OK with me.

Date: Fri, 15 Aug 1997 09:37:26 -0400
To: Dan Geer <[email-masked]>, [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

At 05:24 PM 8/14/97 -0400, Dan Geer wrote:
>
>question:  if a key is officially seized from an escrow agent,
>           should the key so seized be revoked retroactively to the
>           moment of seizure at such time as the official use is
>           complete?
>
>otherwise: to whom does the risk devolve for relying upon signature
>           made by a key now known to be (have been) in hands other
>           than its rightful owner?
>
>and variations on the above similarly

This is one of several reasons that many people believe that it will not be
possible to engineer a PKI that meets law enforcement requirements for key
recovery (as opposed to commercial requirements) at a resonable level of
cost and risk.  [see "The Risks of Key Recovery, Key Escrow, and Trusted
Third-Party Encryption" by Alberson, et. al.]

1) Law enforcement requirements include: a) recovery within 4 hours, b) no
notice to the subject, and c) non-bypassable mechanisms.

2) There is no value to being able to recover identity keys and significant
risk introduced by the possibility that there is an additional means by
which they might be compromised.

Therefore, the "best" answer to Dan's question is: recovery of identity keys
should not be possible.  

However, if the design rules this out, the answer becomes: the key cannot be
revoked before the official need for recovery has ended (which could be
years), because it would give notice to the subject.

In this case, the answer to Dan's second question becomes "there is no risk,
because the recovery process is trusted" (just as the escrow agent is).
Therefore the risk is no greater than that of having the escrow agent in the
first place.

[By the way, this raises the question: can a CA (or a subject for that
matter) retroactively revoke a key farther back in time than the grace
period?  If so, a) what does the grace period actually signify (from the
point of view of a relying party) and b) how does one achieve
non-repudiation when a subject can revoke his or her key for any period at
any time?]

Regards,

Hal
=================================================================
Harold W. Lockhart Jr.            PLATINUM technology, Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (617)273-6406              Fax: (617)229-2969
=================================================================

From: Trevor Freeman <[email-masked]>
To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: key recovery options for PKIX-3 CAs?
Date: Fri, 15 Aug 1997 05:49:43 -0700

There was a big debate in the UK following the governments publication
of their key escrow proposals. Some of the highlights from that debate
where:
	The distinction between signing and key exchange keys is to
simplistic to be relied upon to define a set of keys which are the one
required to be escrowed/recovered.
	You could not prevent the "incorrect" use of a un-escrowed key
being used for some encryption transformation. I can just imaging the
police interview... "Excuse me sir. Can you tell me what you where doing
with this key last Tuesday at 8:00pm"(sorry my British sense of humour).
	New transformations make any attempt to define a set of keys
that require escrow/recovery quickly obsolete.
	Any access to a key used to provide authentication or signing
has the potential to cause more problems than the escrow/recovery
solves.
	There are may unanswered legal questions on third parties access
to key material as the implied access to data can be in conflict with
other legislation. Doctors and Lawyers are easy examples of this, but
even in a conservative country like the UK, someone successfully sued
their employer for breach of privacy by tapping their work phone.
Bottom line seems to suggest that commercial key escrow/recovery will
work in most situations but it is naive to think it is guaranteed to
work.
Trevor

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Thursday, August 14, 1997 8:57 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	Re: key recovery options for PKIX-3 CAs?
> 
> >>> Peter Williams <[email-masked]> 08/14/97 05:41AM >>>
> >
> >Personally, I find the separation of key escrow for encryption keys
> from
> signing
> >keys to be a bogus argument. D-H and KEA Encryption keys
> particularly, &
> arguably,
> >provide for excellent data origin authentication, and thus such
> authentication can be
> >fraudulently used (by the escrow agent) when such a security service
> is
> deemed 
> >adequate to
> >construe signed-writing status on an (encrypted) message or
> transaction.
> Baum explains
> >the notion of official security-procedure conferring signed-writing
> status
> nicely in his
> >and Warwick's e-commerce book, covering UN model laws, and existing
> EDI
> practice, 
> >etc.
> >
> >Signed-writing status is not  limited to"digital signature" security
> mechanisms! if its
> >inappropriate to allow FBI to forge your signatures, its similarly
> inappropriate to
> >allow FBI to forge signed-writings due to encryption security
> mechanisms.
> >
> >Peter.
> 
> Very thought-provoking comment, Peter
> 
> This is a level of difficulty that is in addition to the obvious
> problem of
> how a crypto product, especially a mass-market operating system level
> product, can enforce such key usage distinctions at a general API
> level.
> 
> Although I haven't yet acquired the Baum/Ford book, there is certainly
> no
> doubt that a privately agreed-upon security service can confer
> signed-writing status on a document. It may or may not provide some
> measure
> of third party nonrepudiation -- for example the use of a DES keyed
> Message
> Authentication Code presumably wouldn't. But clearly you don't want
> some
> third party having access to "signed-writing" keys, whether digital
> signature keys or some other parameters.
> 
> Hmm. Gotta think about this some more.
> 
> Bob
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                   

Date: Fri, 15 Aug 1997 02:23:31 -0400
To: [email-masked]
From: Michele Rubenstein <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?

Supposing self doesn't care to store the keys?

At 04:59 PM 8/14/97 -0600, you wrote:
>Yet another reason not to turn over identity keys to other than self.
>
>I know that their are concerns and problems with using "identitiy" keys to
encrypt session keys or exchange information and these may come under some
government access rules (European or other) if so used.
>
>Michael
>
>>>> Dan Geer <[email-masked]> 08/14/97 03:24PM >>>
>
>question:  if a key is officially seized from an escrow agent,
>           should the key so seized be revoked retroactively to the
>           moment of seizure at such time as the official use is
>           complete?
>
>otherwise: to whom does the risk devolve for relying upon signature
>           made by a key now known to be (have been) in hands other
>           than its rightful owner?
>
>and variations on the above similarly
>
>--dan
>
>

                                              
>
>

Date: Thu, 14 Aug 1997 18:22:45 -0600
From: John Kennedy <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: ElGamal in X.509

Peter,

I think the things you are looking for might be found in the current IEEE
P1363 draft.  It has not gone to ballot yet
but I suspect the definitions you want might be stable enough to use.

-John Kennedy
Novell

>>> Peter Gutmann <[email-masked]> 08/15/97 02:50AM >>>
Does anyone know of any definitions for ElGamal objects (keys, signatures,
and 
OIDs) and DSA OIDs other than dsaWithSHA1?  There's an old OIW document
which 
has an OID for ElGamal with MD2 (which also shows the things vintage :-) and

an ElGamal signature (which just to be confusing is the opposite to DSA, so 
where a DSA signature has { r, s }, the ElGamal equivalent has { s, r }).  
However apart from these very sketchy and somewhat questionable items I
can't 
find anything else.  Is there any way to use ElGamal with X.509?  
 
As a related question, are there OIDs which allow the use of DSA with
anything 
other than SHA1?  I know it's supposed to work with SHA1, but the ability to

switch in RIPEMD-160 would be nice.
 
If noone knows of any plans to define structures and OIDs for ElGamal, and
if 
there's a demand for them, I might throw together an ElGamal profile for
X.509 
certs, perhaps:
 
ElGamal-Params ::= SEQUENCE {
    p   INTEGER,
    g   INTEGER
    }
 
ElGamal-Sig ::= SEQUENCE {
    r   INTEGER,
    s   INTEGER
    }
 
with the public key being the integer x (I think the idea of splitting the 
public key into algorithm parameters which hang off the OID and an integer 
value which is stored/communicated seperately is rather awkward, but that's 
what DSA does so I'll copy that).
 
If anyone knows of a reason to not do this, please let me know, otherwise
I'll 
put together a draft profile and get it submitted.
 
Peter.

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 14 Aug 1997 16:59:53 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Yet another reason not to turn over identity keys to other than self.

I know that their are concerns and problems with using "identitiy" keys to encrypt session keys or exchange information and these may come under some government access rules (European or other) if so used.

Michael

>>> Dan Geer <[email-masked]> 08/14/97 03:24PM >>>

question:  if a key is officially seized from an escrow agent,
           should the key so seized be revoked retroactively to the
           moment of seizure at such time as the official use is
           complete?

otherwise: to whom does the risk devolve for relying upon signature
           made by a key now known to be (have been) in hands other
           than its rightful owner?

and variations on the above similarly

--dan

Date: Fri, 15 Aug 1997 00:58:07 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: PKIX Part 3 REQUIRES SUPPORT OF KEY RECOVERY?

-----BEGIN PGP SIGNED MESSAGE-----

It seems to me that PKIX Part 3, section 2.2.2.1 "Centralised scheme" 
requires that a conformant implementation support the capability of 
generating the private key at the CA.  This means that a conformant 
implementation essentially is required to implement key recovery.

I do not think that this conforms to IETF practice and I certainly do 
not want to require CA implementations to support this capability.  
If for some reason someone wants to implement this I can see it being 
an optional feature but I do not think it is an acceptable mandatory 
requirement.

To: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs? 
Date: Thu, 14 Aug 1997 17:24:39 -0400
From: Dan Geer <[email-masked]>

question:  if a key is officially seized from an escrow agent,
           should the key so seized be revoked retroactively to the
           moment of seizure at such time as the official use is
           complete?

otherwise: to whom does the risk devolve for relying upon signature
           made by a key now known to be (have been) in hands other
           than its rightful owner?

and variations on the above similarly

--dan

Date: Thu, 14 Aug 1997 11:41:01 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: IETF Meeting Minutes
Cc: [email-masked]

Folks,

	The following text is the first draft of the minutes from the two days
of WG meetings that took place at the 39th IETF, in Munich.  I'd like
attendees to comment on the minutes by Friday, 8/22, so that I can make
revisions as appropriate and submit the minutes to the IETF
Secretariat.

Thanks, 

Steve

--------------------------------------------

PKIX WG Meeting Minutes: 8/13-14/97

The PKIX Working Group met twice at the 39th IETF.  A total of about
200 IETF attendees participated in these two meetings.  The primary
focus of the meetings were status reports on the six PKIX documents. 
(Note that the last two of these are new documents, outside the scope
of the original WG charter, and work was initiated on them as a result
of discussion at the Memphis meeting. Hence Parts 5 and 6 are trailing
the other documents and are not critical to the base set of functions
for an Internet PKI.)  Additional discussion focused on the topic of
choosing default cryptographic algorithms.

Part 1:  X.509 Profile (Tim Polk, NIST)

Ready to go after a few minor editing changes for clarification.  Plan
to go to last call in September.

Part 2: Operational Protocols (Sharon Boeyen, Entrust) 

Major changes from Memphis include LDAP modification profile, HTTP
mechanisms (not complete), and e-mail (very new, not complete).  Other
refinements include several OCSP changes and additions. 

Outstanding issues: 

	- e-mail appendix is very new and requires review

	- OCSP questions about path validation

	- retention of historical CRLs

	- OCSP caching

	- LDAP responses should be signed, not just SSL protected, but this is
not currently supported in LDAP

	- need HTTP content type label assignment

	- do we still need FTP support, given HTTP availability?

	- has the document grown too big? 

A suggestion was made to split apart the mechanisms by mechanism, e.g.,
LDAP, HTTP, OCSP, and FTP.  Volunteers available for all the parts,
except maybe FTP, so we decide to do this, subject to list approval.
Plan to go to last call next month on LDAP. HTTP and OCSP documents not
yet ready.  We assume that the FTP portion will be ready soon, but need
confirmation from author (who was not present).  Relative to the
recently introduced requirement for default algorithms, some of these
documents will have to adopt such algorithms, e.g., OCSP. PowerPoint
slides will be available in the IETF on-line minutes.

Part 3: Management Protocols (Carlisle Adams, Entrust)

Carlisle presented an evaluation of the Meyers proposal (discussed
below), arguing that the proposal is currently incomplete and that it
calls for processing not compatible with deployed PKCS 7/10
implementations.  He provided several examples of the incompatibility,
e.g., the need to extract a key from within a PKCS 10 structure inside
a PKCS 7 envelope, in order to validate the signature on the envelope.
Mike Meyers expressed concern that Part 3 contains some ambiguities
with regard to how to map certificate management messages into the PKCS
7 format.  At lunch after the meeting, Carlisle and Mike, in discussion
with the WG co-chairs, agreed to move the discussion of the use of PKCS
7 and 10 to a new standards track document (edited by Mike), and PKIX
Part 3 will progress to last call with this modification. Because of
the need to define default algorithms (see below), this document also
will be amended to define the requisite default algorithms for
signatures, hashes, and encryption. PowerPoint slides will be available
in the IETF on-line minutes.

Part 4: Policy Framework (Warwick Ford)

Not a standards track document, but rather an Informational or BCP RFC.
Document is ready for last call after next revision, with minor
changes, next month.  

Part 5: Time Stamping (Robert Zuccherato, Entrust) 

Brief presentation of what a Time Stamp Authority (TSA) does, and a
proposed protocol (format and message flow).  See PowerPoint slides in
on-line minutes.  Concern expressed over possible patents in this area,
e.g., by Pitney-Bowes and Fischer International.  Need to resolve these
concerns.  Also, a concern was expressed over the extent to which the
proposed protocol is amenable to various techniques that can be
employed to protect against the TSA corruption.  Suggestion to consider
alternative time stamping approaches, e.g., Surety technique, is
rejected as out of scope for this WG.  Instead, the WG chairs direct
the document to explicitly state the intended scope, i.e., time
stamping in an X.509 PKI context (hence, using public-key digital
signature technology). PowerPoint slides will be available in the IETF
on-line minutes.

Part 6: Notary Protocols (Robert Zuccherato, Entrust)

Not so well defined as TSA document (Part 5).  In the digital signature
and security literature, the notarization function is tightly tied to
the time stamping function, and one could easily imagine making the TSA
a part of the larger notary function. The distinctions between this
function and the TSA function, as presented here, are binding proof of
possession of the data to the submittor and, possibly, vouching for
validity or truth of the data submitted for notarization. Thus this
function entails signature and certificate path validation by the
notary, including CRLs and ARLs, and might entail other, more complex
assertions about the data.  This is clearly not a critical function for
general, Internet PKI use, and thus not part of the base PKIX
standards. See PowerPoint slides in on-line minutes.

Meyers Certificate Management Protocol: (Tim Polk, NIST)

Discussion lead by Tim, but the submission in question is authored by
Meyers et al. (VeriSign).  The proposal calls for use of PKCS 7 as
security encapsulation protocol and PKCS 10 as certificate management
protocol. The current version of PKCS 10 is primarily oriented toward
RSA support, which is not consistent with the algorithm independence
goals of PKIX, and it does not support the full range of certificate
management functions defined in PKIX Part 3.  It is argued that future
versions of these RSA standards will be capable of supporting all of
these requirements, but the current proposal does not address these
concerns.  Similar concerns arise with regard to PKCS 7 as a secure
encapsulation protocol.  Moreover, the PKCS series are not under IETF
control and thus there are concerns about making the PKIX management
protocols too dependent on these standards.   Still, there is
significant support for use of PKCS 7 and 10 because of the installed
base and availability of supporting toolkits.  See the discussion of
PKIX Part 3 above for further details.

KEA: (Tim Polk, NIST)

KEA, because it is a classified algorithm, is not part of the base
specs and will be covered by a separate

Default algorithm suite: (Steve Kent, BBN & Jeff Schiller, MIT)

There is a recent trend by the IESG to encourage WGs to define a
default (MUST implement) algorithm suite to enable interoperability.
For example, the TLS proto-RFC were rejected by the IESG because of the
use of a proprietary encryption algorithm (RC4) and a patented public
key algorithm (RSA).  The emerging pattern (in TLS and SSH) is to use
DSA (vs. RSA) as a public key signature algorithm and to use
Diffie-Hellman as a key agreement algorithm, to avoid patent issues.

However, we note that most of the deployed certificate technology is
RSA-based, making this deployed this technology non-compliant if we
mandate DSA.  Also, European attendees expressed concern over the
patent status of DSA in Europe (vis a vis Schnoor patent).  Jeff will
ask the ISOC attorneys to evaluate the patent status of DSA on an
international basis, relative to possible adoption of DSA as the
default digital signature algorithm for use in some parts of PKIX.

Jeff suggests that the PKIX management protocols WILL need to adopt a
default set of algorithms for hash, signature, encryption key
management, and encryption.  The current trend would be to call for use
of DSA for signatures.  Jeff is not prepared to state that the IESG
will require PKIX to mandate DSA as the default algorithm for
certificate signatures.  Thus, it would seem that Part 1 need not
mandate any signature and hash algorithm, but that Part 3 and some
parts of Part 2 will require the addition of such default algorithms.

Reply-To: [email-masked]
Date: Thu, 14 Aug 1997 16:11:02 -0400
To: David Kurn <[email-masked]>, [email-masked]
From: Robert Moskowitz <[email-masked]>
Subject: Re: PKIX and PKCS7/10 

At 04:02 PM 8/13/97 -0700, David Kurn wrote:

I have not lived the PKIX fights, only the IPsec fights.  I do have some
problems following David's lines of reasoning, based on so many wgs that I
have participated in...

>The current PKIX work is the result of a lot of hard work by very skilled
>people for the past two years.  It has been done in the best traditions of
>the IETF - through open discussion and evolution.  Many contrary ideas have
>been suggested, some accepted, some modified, and some rejected.  But, on
>the whole, the work has been co-operative AND open.  It may not be the best
>solution possible, but does satisfy the principle of "rough-consensus", and
>is a good place to stop, document, implement, and think of evolutionary
>changes for the future.  There will always be proposals that are better,
>but if we wait to absorb all of them, we won't make any progress.

The PKCS7/10 proposal was not offered as a 'better' solution.  Rather a
specific sub-solution for some valid universes of users.

>The newly submited alternatives, by Meyers, Deacon and Liu, involving PKCS7
>and PKCS10 appear to have few of the usual properties that make the IETF
>work.  The work (and clearly there was quite a bit) was done in a closed
>manner, or at least, not in a manner that was visible to the community.

In many wgs, such proposals are ALWAYS submitted as drafts so that they can
be well reviewed and everyone knows (by ID name) what is being talked about.

>The work relies upon proprietary algorithms.  There has been little or no

A point against them, depending on licensing issues.

>chance for the community to absorb it, consider its implications, and
>contribute feedback.  

And thus a draft is presented as the mechinism for the above.  The use of
IDs is for community consideration is well founded in the IETF.

>And, it was submitted not to the working-group for
>discussion and debate, but intead as an document, but as an Internet Draft
>whose title page flags it as a submission from the PKIX working group.

This is a wg chair desision.  Wether an ID is published as a wg doc or a
private.  The chair frequently calls it based on the connection of the doc
to the wg's charter.  In this case (as Peter pointed out) it is in line
with the PKCS7 discussions in PKIX-3, thus the chairs could tell the
authors to publish as a wg doc.  Of course if the authors acted
independently, and the chairs disagree with the action, they can instruct
the secretariat to re-issue the ID as an independent doc (been there, done
that).

>Working implementations of PKIX protocols exist today.  We believe that
>Entrust Technologies Inc is currently shipping a version of their software
>that employs PKIX protocols (you should check with the Entrust folks for
>details).  We at Tandem intend to ship products using PKIX protocols shortly.

Bravo.  Can I tell my colleagues here to get their act in gear :)

>In raising this objection, we agree with the position advocated by Carlisle
>and his associates that this newly submitted proposal should not cause any
>delay in the advancement of the PKIX documents (in particular, Part 3) as
>they stand today, through the normal IETF progression.

No need for this to occur, if there is a valid case for a special
sub-solution that PKCS7/10 represents.  This is what I really want to hear.

Sorry I could not attend Munich.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Date: Thu, 14 Aug 1997 13:57:01 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

>>> Peter Williams <[email-masked]> 08/14/97 05:41AM >>>
>
>Personally, I find the separation of key escrow for encryption keys from
signing
>keys to be a bogus argument. D-H and KEA Encryption keys particularly, &
arguably,
>provide for excellent data origin authentication, and thus such
authentication can be
>fraudulently used (by the escrow agent) when such a security service is
deemed 
>adequate to
>construe signed-writing status on an (encrypted) message or transaction.
Baum explains
>the notion of official security-procedure conferring signed-writing status
nicely in his
>and Warwick's e-commerce book, covering UN model laws, and existing EDI
practice, 
>etc.
>
>Signed-writing status is not  limited to"digital signature" security
mechanisms! if its
>inappropriate to allow FBI to forge your signatures, its similarly
inappropriate to
>allow FBI to forge signed-writings due to encryption security mechanisms.
>
>Peter.

Very thought-provoking comment, Peter

This is a level of difficulty that is in addition to the obvious problem of
how a crypto product, especially a mass-market operating system level
product, can enforce such key usage distinctions at a general API level.

Although I haven't yet acquired the Baum/Ford book, there is certainly no
doubt that a privately agreed-upon security service can confer
signed-writing status on a document. It may or may not provide some measure
of third party nonrepudiation -- for example the use of a DES keyed Message
Authentication Code presumably wouldn't. But clearly you don't want some
third party having access to "signed-writing" keys, whether digital
signature keys or some other parameters.

Hmm. Gotta think about this some more.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 14 Aug 1997 12:41:04 +0100
From: Peter Williams <[email-masked]>
To: Mike Smith <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

Mike,

Which of

    "(a) non-PKI elements can do key recovery ("KMI Agents", perhaps)

    (b) PKIX CAs may support/enforce key recovery options which do not depend
          upon access to private-keying material of subscribers."

do you object to as a augmentation of concept to the current PKIX-3 text (which *excludes*
non-CA or  non-LRA key recovery parties)?

The suggestion is to augment the scope to enable non-CA/LRA parties to take part
in key recovery, not to particularly deny the legitimacy of ancillary
service provided by a PKIX-CA operating company.

It is true than many policies may well  require separation of duties (VeriSign performs
authentication, whereas FBI stores your key; abusive potential being balanced) and
others may require combination (Motorola pre-generates/stores your corporate key, and provides
you a cert while you are an employee). This is for policy documents to declare and
instrument, along the lines of PKIX-4.

------

Personally, I find the separation of key escrow for encryption keys from signing
keys to be a bogus argument. D-H and KEA Encryption keys particularly, & arguably,
provide for excellent data origin authentication, and thus such authentication can be
fraudulently used (by the escrow agent) when such a security service is deemed adequate to
construe signed-writing status on an (encrypted) message or transaction. Baum explains
the notion of official security-procedure confering signed-writing status nicely in his
and Warwick's e-commerce book, covering UN model laws, and existing EDI practice, etc.

Signed-writing status is not  limited to"digital signature" security mechanisms! if its
inappropriate to allow FBI to forge your signatures, its similarly inappropriate to
allow FBI to forge signed-writings due to encryption security mechanisms.

Peter.

Mike Smith wrote:

> I've read articles by halway informed reporters confusing California requirements for decryption
> key recovery with signing key recovery.  As these misunderstandings become popularized, the more
> fear will grow.
>
> In discussions with others in industry, the consensus is that corproations will need key recovery
> for the corporate decryption keys used by their employees in recovery centers operated by
> themselves or an entity that they trust.  The better the encryption algorithms and their strength,
> the more this need becomes apparent.  We have all heard of corporations held hostage by someone
> encrypting the corporate mission critical data.
>
> Bob, as you know, I believe that the "trust" necessary for key recovery has to be earned AND
> explicated in contracts between the parties relying on such trust.  Since the role of
> Certification Authorities is that of trusted agent, they would be natural as key/data recovery
> center operators if entities do not wish to host a recovery center of their own.
>
> Of course, this will only work if "identity" keys (signing keys) are specifically excluded.  With
> clearly defined revocation processes and certificate issuance systems, I can not forsee ANY
> practical situation where one would need to recovery a lost or compromised signing key.
>
> Michael

Date: Thu, 14 Aug 1997 19:48:09 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Digital Ltd.
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: Definitions and design criteria for message digest functions, etc.

Bob Jueneman wrote:
> 1.  Given M, it is easy to compute h.  [This is obvious, and no problem.]
> 
> 2.  Given h, it is hard to compute M such that H(M) = h.
> 
> [This was what seemed to be the essence of the definition, at least to me.
> Assuming that M is longer than length m there is obviously information loss,
> so that couldn't be what made the function one way, ergo this is the obvious
> definition, at least for short Ms. and presumably for longer Ms, this
> implies that knowing h shouldn't give you any particular clue that would
> minimize your search for M.  But at least for a message digest function used
> within a digital signature calculation, this property is neither necessary
> nor sufficient.]

I think the property is necessary, but not sufficient. I thought I'd
sent a proof of this already, but it seems to have gone AWOL, so I'll
send it again:

If it is easy, given h, to calculate M s.t. H(M)=h, then, given N (some
other message), we can violate property 3 by doing N'=H'(H(N)). N'
cannot, in general, equal N, since there is a loss of information when
doing H(N). Hence, we have found another message N', s.t. H(N')=H(N).

So, actually, you only need properties 1 & 3 - 2 is a consequence. And
one-wayness is a consequence of collision-resistance.

> 3.  Given M, it is hard to find another message, M', such that H(M) = H(M').
>  [Surprise! ]

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: [email-masked] |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Date: Thu, 14 Aug 1997 11:36:09 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Subject: Definitions and design criteria for message digest functions, etc.

>
>How about "one-way hash". (I know that isn't strictly true, but it is
>less of a mouthful than "easy one way, hard the other hash").
>
>Cheers,
>
>Ben.
>

After I had sent my original reply to Ben's message, I checked Bruce
Schneier's book (Applied Cryptography, edition 2) to see what his definition
of a one-way function was. And now I know why we may not all be on the same
page.

(Interestingly, in his introduction on page 30, he uses the term
Manipulation Detection Code. I used that term in some of the original papers
on the subject, but I have also used the term Modification Detection Code,
to the point where I am unable to remember which term I meant by "MDC"
without going back to check. But Manipulation Detection Code is certainly a
superior term, because although modifications to a message may occur by
happenstance, manipulation connotes deliberate intent, and that is what we
are trying to detect with these codes. So when I'm talking about a generic
function definition, I'll use MDC, meaning Manipulation Detection Code.)

Schneier defines (p. 429) a hash function H(M), operating on an arbitrary
message M. It returns a fixed length hash value, h = H(M), where h is of
length m (bits).

Footnoting Merkle's dissertation, he states that one-way hash functions have
the following additional characteristics that make them one-way:

1.  Given M, it is easy to compute h.  [This is obvious, and no problem.]

2.  Given h, it is hard to compute M such that H(M) = h.  

[This was what seemed to be the essence of the definition, at least to me.
Assuming that M is longer than length m there is obviously information loss,
so that couldn't be what made the function one way, ergo this is the obvious
definition, at least for short Ms. and presumably for longer Ms, this
implies that knowing h shouldn't give you any particular clue that would
minimize your search for M.  But at least for a message digest function used
within a digital signature calculation, this property is neither necessary
nor sufficient.]

3.  Given M, it is hard to find another message, M', such that H(M) = H(M').
 [Surprise! ]

At least to me, this property isn't implied or at all obvious from the
English-language term "one-way," and therefore I don't feel that term is
particularly appropriate for this definition. Warwick Ford's book, Computer
Communication Security, p. 113, includes property 2, but does not mention
property 3.

Schneier then goes on to talk about an additional property that is
"sometimes" (?) required, collision-resistance:

4. It is hard to find two random messages, M and M' such that H(M) = H(M').

It isn't clear from the book whether he considers this to be a defined
property of a one-way hash function, or an additional requirement over and
above one-wayness.

Later, he implicitly adds another criteria, by suggesting that the
"pre-image" of the message should contain some kind of binary representation
of the length of the entire message, to overcome a potential security
problem resulting from messages of different lengths possibly hashing to the
same value.  He calls that "MD-strengthening," after Lai and Massey. 

To my way of thinking, if two entirely different messages just happen to
produce a collision of their one-way hash or message digest values, and if
the probability of that happening is statistically independent of the
message and equal to 1/2^m, that is perfectly acceptable and no security
flaw, although certainly unexpected for any reasonable value of m.

If, however, M' is not independent of M, and for example consists of M plus
some kind of a deliberate extension or modification, e.g., a concatenated
string of binary zeros, and the same value of h results from using an
insufficiently strong H(M'), then that is clearly not acceptable.

But in that case I would argue that the security problem isn't the absence
of a length function, but rather an insufficiently precise definition of the
requirements.

We should therefore have a more formal definition of such terms as "hard"
and "find."  

"Hard" in the case of Schneier's property (2) should mean that the expected
number of random trials necessary to find H(M) = h should be 2^m/2, for all
possible values of h. And presumably "find" means that no deliberate
construction techniques or other manipulation approaches (including linear
or differential cryptanalysis and/or other techniques as suggested by Hans
Dobbertin recent analysis) will be any more efficient than a brute force
random search for M, for all values of h. 

Likewise, for property (3), "hard" should mean that the expected number of
random messages M' that must be tried in order to find M' such that H(M') =
H(M) should be 2^m/2, for all possible values of M. And also, no deliberate
construction or other approaches should be any more efficient than a brute
force random search for M', for all possible values of M.

Property 4 is also not good enough, for merely dealing with random messages
isn't sufficient.  

What we are really concerned about is the possibility that given any
arbitrarily chosen message M, it is impossible to find or deliberately
construct two variants of that message M' and M'' (including the case where
M = M' or M = M''), such that H(M') = H(M'') with a probability greater than
that given by a Birthday Problem analysis.  I.e., for suitably large values
of m, approximately 2^(m/2) trials of M' and 2^(m/2) trials of M'' must be
generated and sorted or otherwise compared in order to find H(M') = H(M'')
with a probability approaching 50%. (This is an approximation of the
Birthday Problem analysis, not a specification.)

I don't mean to suggest that Schneier is God, or that his book is the only
definitive source of such definitions -- it just happens to be the first one
I checked.

But since his definition of a one-way hash function as including property 3
seems to fly in the face of the English language connotation; since Warwick
Ford, the esteemed co-chair of the PKIX group doesn't include that property
in his definition; since property 2 is not necessary for the intended use of
a message digest within a digital signature; since it isn't clear whether
property 4 is part of the definition or not; and since none of these
definitions seem to have enough rigor to deal with the deliberate
construction of MDC function collisions, I would argue that the term
"one-way hash function" is not sufficiently well defined, and in addition
overly constrained for use as a message digest within a digital signature. 
(That doesn't mean that if the definitions were cleaned up that such
functions might have perfectly good application in other circumstances.)

Finally, the reason for spending so much bandwidth on this issue, in
addition to the desire expressed by Bill Burr for an appropriate degree of
rigor and specificity in any standard, is that these terms are beginning to
be included in various state and even international legislation.  It would
obviously be quite undesirable for a technically valid digital signature to
be attacked and overturned in court just because the message digest function
was legally required to be a "one-way hash function" and the particular
function used did not satisfy that definition. Unfortunately, since the ABA
Digital Signature Guidelines included (despite my objections) the "one-way
hash function" language, and since those Guidelines are often used as a
reference when preparing legislation, this is not a completely impossible
scenario.

My personal preference would be to define and use the term "Manipulation
Detection Code" as the clearest expression of what is required, but that is
admittedly a mouthful. Since that term hasn't stuck after almost 20 years,
perhaps due to the lack of a suitable verb, my suggestion would be to
appropriately define and use either "message digest" or "secure hash." 

The prevailing using seems to be message digest, so I would echo Bill Burr
and suggest we go with that in all PKIX documents.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                

Date: Thu, 14 Aug 1997 08:22:20 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

I've read articles by halway informed reporters confusing California requirements for decryption key recovery with signing key recovery.  As these misunderstandings become popularized, the more fear will grow.

In discussions with others in industry, the consensus is that corproations will need key recovery for the corporate decryption keys used by their employees in recovery centers operated by themselves or an entity that they trust.  The better the encryption algorithms and their strength, the more this need becomes apparent.  We have all heard of corporations held hostage by someone encrypting the corporate mission critical data.

Bob, as you know, I believe that the "trust" necessary for key recovery has to be earned AND explicated in contracts between the parties relying on such trust.  Since the role of Certification Authorities is that of trusted agent, they would be natural as key/data recovery center operators if entities do not wish to host a recovery center of their own.

Of course, this will only work if "identity" keys (signing keys) are specifically excluded.  With clearly defined revocation processes and certificate issuance systems, I can not forsee ANY practical situation where one would need to recovery a lost or compromised signing key.

Michael

>>> Bob Jueneman <[email-masked]> 08/12/97 04:54PM >>>
I strongly agree.

At the recent American Bar Association's Information Security Committee
meeting, an official committee resolution was passed which effectively
deplored the coupling of CA and KMI functionality a la that proposed by
McCain/Kerrey (S.909) as being generally destructive of the trust required
in CAs for electronic commerce if they are also in possession of the user's
private key.

So although CAs might choose to get into the key recovery business, it
doesn't seem terribly likely, and we should certainly remove any language
that implies or requires that only CAs or LRAs would perform such functions.

We've had to learn the hard way about the necessity of separating encryption
keys from signature keys -- let's not compound that original error by
reintroducing such assumptions in the key recovery area.

Bob

>>> Peter Williams <[email-masked]> 08/12/97 05:31AM >>>
PKIX-3 seems to imply that only CAs and LRA can perform key recovery
duties. Surely this language should be amended such that

(a) non-PKI elements can do key recovery ("KMI Agents", perhaps)

(b) PKIX CAs may support/enforce key recovery options which do not depend
upon access to private-keying material of subscribers.

take the example products/PRs:

http://www.querisoft.com/commonHtml/sf071497.html 

http://www.querisoft.com/commonHtml/tis071597.html 

Here, and based on exploiting the Microsoft security framework, you get to
choose hardware tokens, you get to choose CA, and you get to choose whether
to require TIS-based key/data recovery (and other schemes), and well-written
application code never changes! It should not be too hard to make all
this PKIX-1 conforming, at least.

There seems an assumption in PKIX that the PKI/CAs will perform key
recovery, and Im not sure that this is true, and even it if true to the
extent that
you cannot have a cert until some key-recovery option is
known to be in place, such key-recovery and data-recovery
mechanisms may be CSP-provided and not even necesssairly involve
the CA in direct protocol terms.

we may want to amend PKIX-3 to assign additional options and
freedoms in line with (a) and (b) on the key-recovery front.

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

         

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: ElGamal in X.509
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 15 Aug 1997 01:50:02 (NZST)

Does anyone know of any definitions for ElGamal objects (keys, signatures, and 
OIDs) and DSA OIDs other than dsaWithSHA1?  There's an old OIW document which 
has an OID for ElGamal with MD2 (which also shows the things vintage :-) and 
an ElGamal signature (which just to be confusing is the opposite to DSA, so 
where a DSA signature has { r, s }, the ElGamal equivalent has { s, r }).  
However apart from these very sketchy and somewhat questionable items I can't 
find anything else.  Is there any way to use ElGamal with X.509?  
 
As a related question, are there OIDs which allow the use of DSA with anything 
other than SHA1?  I know it's supposed to work with SHA1, but the ability to 
switch in RIPEMD-160 would be nice.
 
If noone knows of any plans to define structures and OIDs for ElGamal, and if 
there's a demand for them, I might throw together an ElGamal profile for X.509 
certs, perhaps:
 
ElGamal-Params ::= SEQUENCE {
    p   INTEGER,
    g   INTEGER
    }
 
ElGamal-Sig ::= SEQUENCE {
    r   INTEGER,
    s   INTEGER
    }
 
with the public key being the integer x (I think the idea of splitting the 
public key into algorithm parameters which hang off the OID and an integer 
value which is stored/communicated seperately is rather awkward, but that's 
what DSA does so I'll copy that).
 
If anyone knows of a reason to not do this, please let me know, otherwise I'll 
put together a draft profile and get it submitted.
 
Peter.

To: [email-masked]
Subject: Signature Algorithm 
Date: Thu, 14 Aug 1997 16:48:30 +0900
From: Mine Sakurai <[email-masked]>

I have some comments to PKIX part1 draft 
<draft-ietf-pkix-ipki-part1-05.txt>.

>7.2.1  RSA Signature Algorithm

(omitted)

>  The data to be signed (e.g., the one-way hash function output value)
>  is first ASN.1 encoded as an OCTET STRING and the result is encrypted
>  (e.g., using RSA Encryption) to form the signed quantity. When
>  signing, the RSA algorithm generates an integer y. This signature
>  value is then ASN.1 encoded as a BIT STRING, such that the most
>  significant bit in y is the first bit in the bit string and the least
>  significant bit in y is the last bit in the bit string, and included
>  in the Certificate or CertificateList (in the signature field).

Though this signing method conforms to X.509 (1993 Edition), 
it's bit different from PKCS#1 description, I think.
In case of "md2WithRSAEncryption" or "md5WithRSAEncryption", 
many implementors will refer to PKCS#1, which defines those algorithm
identifiers themselves. So, why don't you change the description here
to that of PKCS#1 not to be confused ??

---From PKCS#1 (1993)
10.1.2 Data encoding

The message digest MD and a message-digest algorithm
identifier shall be combined into an ASN.1 value of type
DigestInfo, described below, which shall be BER-encoded to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
give an octet string D, the data.
^^^^^^^^^^^^^^^^^^^^^^^

DigestInfo ::= SEQUENCE {
  digestAlgorithm DigestAlgorithmIdentifier,
  digest Digest }

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

Digest ::= OCTET STRING

(中略)

10.1.3 RSA encryption

The data D shall be encrypted with the signer's RSA private
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
key as described in Section 7 to give an octet string ED,
the encrypted data. The block type shall be 01. (See Section
8.1.)
----------

>7.2.2  DSA Signature Algorithm

(omitted)
 
>  The Digital Signature Algorithm (DSA) is also called the Digital
>  Signature Standard (DSS).  DSA was developed by the U.S. Government,
>  and DSA is used in conjunction with the the SHA-1 one-way hash
>  function.  DSA is fully described in FIPS 186 [FIPS 186].  The ASN.1
>  object identifiers used to identify this signature algorithm are:

>          id-dsa-with-sha1 ID  ::=  {
>                  iso(1) member-body(2) us(840) x9-57 (10040)
>                  x9cm(4) 3 }

(omitted)

I heard that the data to be signed (the one-way hash function output
value) was *not* ASN.1 BER encoded with id-dsa-with-sha1. 
In X.509 based certificates, the data to be signed is ASN.1 BER
encoded (as described in X.509), and I was confusing. 
I understand now that signing method defined in X.509 doesn't
fit for using public-key cryptosystems with short key lengths, such as
DSA and ECC(Elliptic Curve cryptosystem), but
I think we need the description about "data to be signed" in this
section. 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mine Sakurai          E-mail: [email-masked]
Internet Engineering Laboratory
Networking Systems Lab. NEC Corp., Tokyo, JAPAN

Date: Wed, 13 Aug 1997 18:01:37 +0100
From: Peter Williams <[email-masked]>
To: David Kurn <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX and PKCS7/10

David,

"The newly submited alternatives, by Meyers, Deacon and Liu, involving PKCS7
and PKCS10 appear to have few of the usual properties that make the IETF
work.  The work (and clearly there was quite a bit) was done in a closed
manner, or at least, not in a manner that was visible to the community.
The work relies upon proprietary algorithms.  There has been little or no
chance for the community to absorb it, consider its implications, and
contribute feedback.  And, it was submitted not to the working-group for
discussion and debate, but intead as an document, but as an Internet Draft
whose title page flags it as a submission from the PKIX working group."

The PKCS7/10 proposal is wholly in accord with PKIX-3. If you note, PKIX-3
already allows for integration with external protection mechanisms, and already gives
an example  mechanism which profiles PKCS7/10 (!) to this end. I have argued and debated
this general mode HERE for at least 12 months, and the archives and WG minutes show it
was an entirely open, collaborative process, which only led to an ID specification
very recently. No VeriSign or CISCO party is an author of PKIX-3, note
and has had no opportunity to unfairly control the text to suit proprietary goals, say.

Everything which is currently in the document on this issue, was publicly
argued, and  hard fought on objective merits. I fought quite alone for
most of this period!

>  However, we are quite bothered by several non-technical aspects of the
> proposal (at least non-crypto-technical):

Everything which is currently in the document on this issue, was publiclyargued, and  hard fought on
objective merits.

But, I do apologise; but is your seeming  imputation of improper conduct fair? I
certainly do not believe so, given the effort I (and Carlisle) personally went through
to argue the issues, over 12 months HERE in full public exposure,
and in the public WG session when we argued and agreed the
precise wording of the text lines. Were you in Memphis WG?
Or Ottawa? Or Dallas where the subject was first discussed
in open WG session, minuted, and labored over since then?

Lets take a historical view; and one which is true, and supportable
via the archives, and WG minutes:-

The PKCS7 issue (really the external protection issue)  has been argued
here for 12+ months. it was even voted on by two working groups (and
reviewed line by line, word by word, by Carlise in Memphis IN
FULL PUBLIC disclosure)

The result was the framework text you should know, and the PKCS7 example.
The PKCS 7 example is merely that, an example. Prekeyed MIME/PGP and
IPSEC VPNn are just as viable sub-protocol. Its really quite respectable
pragmatic text, in this area.

So, David, if you are imputing improper conduct, please take into
account my slice of history. I lived it, and there is considerable
public evidence to show for it.

-------

to more dutiful matters:-

Here are some early PKIX-3 Final Call comments, pending the process (such a
good, fair and open IETF citizen am I...I was  holding my categories of comments
for the proper time, despite my worries)

One of my worries for PKIX-3 which I intend
to bring up during a final call process, when called, is that no two independent
vendor implementations  will likely work together - there are just so
many options for supported  ASN.1 fields, transports modes, models of flow,
optionality of functional groups etc. Some considerable text  will have to be appended,
prosuambly in appendices, to ensure that at least there is some  minimal probability
of multi-vendor material working together at some feature set, without their being
bilateral knowledge of the products particular implementation choices.

I suspect there are three declared implementors all now
working on our individual mental model of what PKIX-3 is : for
Entrust folk, its likely to be the monolithic system; for Tandem is another slice of the
specified pie;  and for us its another open systems component in need
of multi-vendor interworking tests and profiling. Im sure there are 10 others
with distinct opinions. And this is what I  want to comment on, when the we hit
the process phase  for detailed  documentation-quality and standards-track
issues affecting viability of PKIX-3 - to drive a multi-vendor, open-standards industry
for remote key managementacross disparate infrastructure elements.

Peter.

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, "David Kurn" <[email-masked]>
Subject: Re: PKIX and PKCS7/10 
Date: Wed, 13 Aug 1997 20:52:20 -0400

I understand where you're coming from.  OTOH, there are quite a few of us
who have big investments in PKCS-7/10.  I'd like to treat the two
alternatives as separate but equal, but ONLY if PKCS-7/10 can be tweaked to
do EVERYTHING that PKIX-3 does (this is not at all obvious).  CertCo's
motivation in all of this is that PKCS-7 lets us "append" stuff (which must
remain nameless right now) to the original message.  This is demonstrated
really well in the Myers draft, where the whole PKIX header is conveyed as
authenticated attributes...

Regards,
Rich

----------
> From: David Kurn <[email-masked]>
> To: [email-masked]
> Subject: PKIX and PKCS7/10 
> Date: Wednesday, August 13, 1997 7:02 PM
> 
> Folks
> 
> We at Tandem Computers Inc (Cupertino California) have been watching the
> recent discussions on the PKIX mail-list, dealing with an alternate
> proposal for the material covered in PKIX-Part3.  We have observed the
> technical pros-and-cons, and need a bit more time to really understand
them.
> 
> However, we are quite bothered by several non-technical aspects of the
> proposal (at least non-crypto-technical):
>  
> The current PKIX work is the result of a lot of hard work by very skilled
> people for the past two years.  It has been done in the best traditions
of
> the IETF - through open discussion and evolution.  Many contrary ideas
have
> been suggested, some accepted, some modified, and some rejected.  But, on
> the whole, the work has been co-operative AND open.  It may not be the
best
> solution possible, but does satisfy the principle of "rough-consensus",
and
> is a good place to stop, document, implement, and think of evolutionary
> changes for the future.  There will always be proposals that are better,
> but if we wait to absorb all of them, we won't make any progress.
> 
> The newly submited alternatives, by Meyers, Deacon and Liu, involving
PKCS7
> and PKCS10 appear to have few of the usual properties that make the IETF
> work.  The work (and clearly there was quite a bit) was done in a closed
> manner, or at least, not in a manner that was visible to the community.
> The work relies upon proprietary algorithms.  There has been little or no
> chance for the community to absorb it, consider its implications, and
> contribute feedback.  And, it was submitted not to the working-group for
> discussion and debate, but intead as an document, but as an Internet
Draft
> whose title page flags it as a submission from the PKIX working group.
> 
> Working implementations of PKIX protocols exist today.  We believe that
> Entrust Technologies Inc is currently shipping a version of their
software
> that employs PKIX protocols (you should check with the Entrust folks for
> details).  We at Tandem intend to ship products using PKIX protocols
shortly.
> 
> In raising this objection, we agree with the position advocated by
Carlisle
> and his associates that this newly submitted proposal should not cause
any
> delay in the advancement of the PKIX documents (in particular, Part 3) as
> they stand today, through the normal IETF progression.
> 
> David Kurn
> Tandem Computers Inc
> Email: [email-masked]
> 
> Kent Salmond
> Tandem Computers Inc
> Email: [email-masked]

Date: Wed, 13 Aug 1997 18:16:42 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

>
>How about "one-way hash". (I know that isn't strictly true, but it is
>less of a mouthful than "easy one way, hard the other hash").
>
>Cheers,
>
>Ben.
>

Ben, I thought of a gedanken experiment that would be a perfectly good
one-way function, in that it does not leak information from the hash result
back to the input, yet would not be at all suitable as a suitable message
digest.

Take my DES one-way function, where the first eight bytes of the message is
used as both the key and the input.  Then take the next eight bytes of the
message and do the same thing, and simply XOR the two results. Continue to
accumulate an XOR result for every additional block, padding at the end with
a constant as necessary.

Not only is this a good one-way function because there is more information
going in than is coming out, but it presumably cannot be broken without
breaking DES, and hence does not reveal anything about the input given the
output. (It is left as a proof to the reader to demonstrate whether or not
there exist any two 8 byte blocks which would produce the same output in
this scheme.)

This would be a terrible message digest function, because the transposition
of two blocks would result in precisely the same output. Likewise, if two
identical blocks (on block boundaries) occur anywhere in the message, those
two blocks could be deleted from the message without any effect on the hash
result.

I suppose that collision-avoidance is one way of expressing the necessary
property, but it isn't sufficient that collision avoidance happen more or
less randomly -- a CRC check does that much. Instead, the property has to be
that it is computationally infeasible to find or to artificially produce any
two messages which would produce an identical message digest, regardless of
bit twiddling, additions, deletions, transpositions, etc., unless the two
messages are in fact identical. Moreover, like a good Knuth-type hash
function, the message digest produced should be statistically flat in its
distribution, so that a Birthday Problem attack is the most efficient way to
attempt to generate such a collision. 

BTW, has a description of this property ever been included in any of the
PKIX documents? I can't think of where we might have expressed it.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Wed, 13 Aug 1997 17:42:29 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: "Hash" versus "Message Digest"

I agree.

Peter's semantic issues with "message" have some merit, and the lawyers tend
to think of a "digest" as a precis, but the implicitly hyphenated term is
well-understood and accepted by all, and I would recommend we use it.

If changing all of the documentation is too much work, perhaps a note
somewhere in the beginning to the effect that "when we say 'hash" we really
mean a message digest function, and not a simple Knuth-type of hash
function, nor necessarily a one-way hash function.

Bob>
>
>>>> Bill Burr <[email-masked]> 08/13/97 01:15PM >>>
>I think Bob is right, "message digest" is probably the best, most widely
>accepted generic term for the representation of a message that is actually
>input to a digital signature algorithm to sign the message. "Hash" and "one
>way hash" are probably too broad.  I note that FIPS 180 and FIPS 186 refer
>to the output of the output of the Secure Hash Algorithm, as a "Message
>Digest," so I don't think that the term is too closely tied to any
>particular algorithm, or tainted by association with Ron Rivest.  And, at
>least according to my understanding of the terms, a "hash" or "one way
>hash" function is not necessarily a suitable function for use in a digital
>signature.
>
>This isn't a big issue, but I think that message digest is the most
>precise, time honored term, and I don't think there is any political
>correctness issue here, so why not use it.  After all, precise expression
>is of some concern in standards.
>Regards,
>
>Bill Burr

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                  

Date: Wed, 13 Aug 1997 16:02:12 -0700
To: [email-masked]
From: David Kurn <[email-masked]>
Subject: PKIX and PKCS7/10 

Folks

We at Tandem Computers Inc (Cupertino California) have been watching the
recent discussions on the PKIX mail-list, dealing with an alternate
proposal for the material covered in PKIX-Part3.  We have observed the
technical pros-and-cons, and need a bit more time to really understand them.

However, we are quite bothered by several non-technical aspects of the
proposal (at least non-crypto-technical):
 
The current PKIX work is the result of a lot of hard work by very skilled
people for the past two years.  It has been done in the best traditions of
the IETF - through open discussion and evolution.  Many contrary ideas have
been suggested, some accepted, some modified, and some rejected.  But, on
the whole, the work has been co-operative AND open.  It may not be the best
solution possible, but does satisfy the principle of "rough-consensus", and
is a good place to stop, document, implement, and think of evolutionary
changes for the future.  There will always be proposals that are better,
but if we wait to absorb all of them, we won't make any progress.

The newly submited alternatives, by Meyers, Deacon and Liu, involving PKCS7
and PKCS10 appear to have few of the usual properties that make the IETF
work.  The work (and clearly there was quite a bit) was done in a closed
manner, or at least, not in a manner that was visible to the community.
The work relies upon proprietary algorithms.  There has been little or no
chance for the community to absorb it, consider its implications, and
contribute feedback.  And, it was submitted not to the working-group for
discussion and debate, but intead as an document, but as an Internet Draft
whose title page flags it as a submission from the PKIX working group.

Working implementations of PKIX protocols exist today.  We believe that
Entrust Technologies Inc is currently shipping a version of their software
that employs PKIX protocols (you should check with the Entrust folks for
details).  We at Tandem intend to ship products using PKIX protocols shortly.

In raising this objection, we agree with the position advocated by Carlisle
and his associates that this newly submitted proposal should not cause any
delay in the advancement of the PKIX documents (in particular, Part 3) as
they stand today, through the normal IETF progression.

David Kurn
Tandem Computers Inc
Email: [email-masked]

Kent Salmond
Tandem Computers Inc
Email: [email-masked]

Date: Wed, 13 Aug 1997 15:15:52 -0400
To: [email-masked]
From: Bill Burr <[email-masked]>
Subject: Re: "Hash" versus "Message Digest"

I think Bob is right, "message digest" is probably the best, most widely
accepted generic term for the representation of a message that is actually
input to a digital signature algorithm to sign the message. "Hash" and "one
way hash" are probably too broad.  I note that FIPS 180 and FIPS 186 refer
to the output of the output of the Secure Hash Algorithm, as a "Message
Digest," so I don't think that the term is too closely tied to any
particular algorithm, or tainted by association with Ron Rivest.  And, at
least according to my understanding of the terms, a "hash" or "one way
hash" function is not necessarily a suitable function for use in a digital
signature.

This isn't a big issue, but I think that message digest is the most
precise, time honored term, and I don't think there is any political
correctness issue here, so why not use it.  After all, precise expression
is of some concern in standards.
Regards,

Bill Burr

Date: Wed, 13 Aug 1997 09:39:51 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

> From: Bob Jueneman <[email-masked]>
> 
> I don't want to get wrapped around the axle about the precise definition of
> cryptography, but if a process doesn't involve a cryptographic key, or at
> least a secret algorithm, then I would say it was really just obfuscation or
> at best steganography.

Well, since the term "key" has also been around since Knuth was a pup,
you'll have to go around changing all occurrences of that too if you
want to avoid confusion with it's database context :-).

More seriously, where do you draw the line between "Knuth" hash functions
and the kind you want to call Message Digests?  Crc32, md4, md5, and sha
all fall along a continuum of security.  And although md4 stands for
"message digest", I doubt that anyone today believes md4 meets the criteria
you had in mind for that term.

I don't have a problem with any of the names "hash", "cryptographic hash",
"secure hash", or "message digest", but since the first is easiest to
type and pronounce, I'll continue to use it unless the context admits
both interpretations and requires a disambiguator.

I don't think PKIX needs to change it's terminology.

Date: Wed, 13 Aug 1997 12:43:57 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Digital Ltd.
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

Bob Jueneman wrote:
> 
> Steve and Ben,
> >
> >
> >>>> Stephen Kent <[email-masked]> 08/12/97 06:32AM >>>
> >Bob,
> >
> > The term "one-way hash function" or "one-way hash" is well accepted
> >in the literature and should be fine for our purposes.  I prefer not to go
> >with "message digest" as it might connote the RSADSI set of hash functions.
> 
> One-way hash functions are indeed a well accepted term in the literature,
> and are quite useful for what they were designed for, e.g., hiding
> information such as passwords, where it is important that the algorithm not
> be reversible and thereby disclose the original information.  One of the
> best one-way hash functions I can think of would be to use DES, with the
> input to the hash fed into both the key and the input block. It only works
> for 8-byte blocks, but it is truly one way, at least to the extent that
> breaking its one-wayness requires breaking DES.
> 
> However, that isn't what we are using these beasties (message digest by any
> politically correct name) for, and implicitly requiring the one-way property
> is overkill.
> 
> In particular, according to Ron Rivest, inventor of MD-5 message digest; and
> Brian Snow, the inventor of the SHA-1 secure hash algorithm, neither
> algorithm had as a specific design principle the one-wayness property.
> Indeed, as Hugo Krawczyk has pointed out, there may be some very real issues
> with using either MD-5 or SHA-1 for such purposes, and he and I have
> suggested using salted hash functions or even double hashing with two
> independent algorithms when such secrecy-preserving hashes are required.

Good point. The design principle, I assume, was "collision-resistant"
(can't think of the PC term for that right now). However, I would've
thought that this implied one-way (proof: if H is a non-one-way hash, m
is a message and H(m) is its hash, then invert H, generate H'(H(m))=m'.
m' cannot, in general, be m, because H contains less information than m.
m' is therefore a collision for m). But perhaps I'm missing something.
Anyway, I agree that one-wayness is not the property we are looking for.
Is "collision-resistance"? Or something else?

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: [email-masked] |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Date: Wed, 13 Aug 1997 04:35:20 -0500
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKIX 2: use of the term "hash"
Cc: [email-masked]

Bob,

	I think we are on different wavelengths!  One way hash functions
like MDx and SHA were designed precisely for support of digital signatures.
They were NOT designed to hide information and thus their use as "keyed
hashes" is what is suspect.  That's why the HMAC construct was developed.
Perhaps I lost track of the original context of the discussion.  If you
were referring to functions used with secret keys for authentication, then
we ought to refer to hashed MACs, if that is the subset of the algorithm
space in question, or we might use the term you coined long ago,
manipulation detection codes (MDCs).  If we are talking about functions
used to generate a compact value representative of data to be signed, than
I think the term "one way hash" is appropriate.

Steve

Date: Tue, 12 Aug 1997 16:54:46 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: key recovery options for PKIX-3 CAs?

I strongly agree.

At the recent American Bar Association's Information Security Committee
meeting, an official committee resolution was passed which effectively
deplored the coupling of CA and KMI functionality a la that proposed by
McCain/Kerrey (S.909) as being generally destructive of the trust required
in CAs for electronic commerce if they are also in possession of the user's
private key.

So although CAs might choose to get into the key recovery business, it
doesn't seem terribly likely, and we should certainly remove any language
that implies or requires that only CAs or LRAs would perform such functions.

We've had to learn the hard way about the necessity of separating encryption
keys from signature keys -- let's not compound that original error by
reintroducing such assumptions in the key recovery area.

Bob

>>> Peter Williams <[email-masked]> 08/12/97 05:31AM >>>
PKIX-3 seems to imply that only CAs and LRA can perform key recovery
duties. Surely this language should be amended such that

(a) non-PKI elements can do key recovery ("KMI Agents", perhaps)

(b) PKIX CAs may support/enforce key recovery options which do not depend
upon access to private-keying material of subscribers.

take the example products/PRs:

http://www.querisoft.com/commonHtml/sf071497.html 

http://www.querisoft.com/commonHtml/tis071597.html 

Here, and based on exploiting the Microsoft security framework, you get to
choose hardware tokens, you get to choose CA, and you get to choose whether
to require TIS-based key/data recovery (and other schemes), and well-written
application code never changes! It should not be too hard to make all
this PKIX-1 conforming, at least.

There seems an assumption in PKIX that the PKI/CAs will perform key
recovery, and Im not sure that this is true, and even it if true to the
extent that
you cannot have a cert until some key-recovery option is
known to be in place, such key-recovery and data-recovery
mechanisms may be CSP-provided and not even necesssairly involve
the CA in direct protocol terms.

we may want to amend PKIX-3 to assign additional options and
freedoms in line with (a) and (b) on the key-recovery front.

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

         

Date: Tue, 12 Aug 1997 16:01:10 -0600
From: Bob Jueneman <[email-masked]>
To: Ben Laurie <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

Steve and Ben,
>
>
>>>> Stephen Kent <[email-masked]> 08/12/97 06:32AM >>>
>Bob,
>
> The term "one-way hash function" or "one-way hash" is well accepted
>in the literature and should be fine for our purposes.  I prefer not to go
>with "message digest" as it might connote the RSADSI set of hash functions.

One-way hash functions are indeed a well accepted term in the literature,
and are quite useful for what they were designed for, e.g., hiding
information such as passwords, where it is important that the algorithm not
be reversible and thereby disclose the original information.  One of the
best one-way hash functions I can think of would be to use DES, with the
input to the hash fed into both the key and the input block. It only works
for 8-byte blocks, but it is truly one way, at least to the extent that
breaking its one-wayness requires breaking DES.

However, that isn't what we are using these beasties (message digest by any
politically correct name) for, and implicitly requiring the one-way property
is overkill.

In particular, according to Ron Rivest, inventor of MD-5 message digest; and
Brian Snow, the inventor of the SHA-1 secure hash algorithm, neither
algorithm had as a specific design principle the one-wayness property.
Indeed, as Hugo Krawczyk has pointed out, there may be some very real issues
with using either MD-5 or SHA-1 for such purposes, and he and I have
suggested using salted hash functions or even double hashing with two
independent algorithms when such secrecy-preserving hashes are required.

Not only that, but one-way hash functions are not necessarily secure from
the standpoint of detecting all possible forms of bit twiddling and other
manipulations. They might turn out to be, just as "message digest" functions
such as MD-5 or SHA-1 might turn out to be good one-way hash functions, but
they weren't necessarily designed to be.

If "message digest" is viewed as coming too close to endorsing a particular
algorithm by RSADSI (which is free, and otherwise meets the test of IETF
political correctness as far as I can see, although it may have some
possible (as yet unproven) technical deficiencies), then would "secure hash"
be acceptable? Or does that too strongly connote SHA-1?

I'm beginning to like my original "Modification Detection Code" name more
and more. At least it clearly states the principle objective of the
function, and "MDC" even has fewer characters than "hash"! And since there
is no word that can't be verbed, "MDCed" can be used  without the alimentary
concerns for the (message) digestibility of various kinds of hash. :-)

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                          

Date: Tue, 12 Aug 1997 12:31:58 +0100
From: Peter Williams <[email-masked]>
To: [email-masked]
Subject: key recovery options for PKIX-3 CAs?

PKIX-3 seems to imply that only CAs and LRA can perform key recovery
duties. Surely this language should be amended such that

(a) non-PKI elements can do key recovery ("KMI Agents", perhaps)

(b) PKIX CAs may support/enforce key recovery options which do not depend
upon access to private-keying material of subscribers.

take the example products/PRs:

http://www.querisoft.com/commonHtml/sf071497.html

http://www.querisoft.com/commonHtml/tis071597.html

Here, and based on exploiting the Microsoft security framework, you get to
choose hardware tokens, you get to choose CA, and you get to choose whether
to require TIS-based key/data recovery (and other schemes), and well-written
application code never changes! It should not be too hard to make all
this PKIX-1 conforming, at least.

There seems an assumption in PKIX that the PKI/CAs will perform key
recovery, and Im not sure that this is true, and even it if true to the extent that
you cannot have a cert until some key-recovery option is
known to be in place, such key-recovery and data-recovery
mechanisms may be CSP-provided and not even necesssairly involve
the CA in direct protocol terms.

we may want to amend PKIX-3 to assign additional options and
freedoms in line with (a) and (b) on the key-recovery front.

Date: Tue, 12 Aug 1997 12:15:23 +0100
From: Peter Williams <[email-masked]>
To: Paul Turner <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX Part 2 - Revised Draft

>

Paul,

Ill let others comment on the details of OCSP you mention. Ive got
some other comments which seem to be raised by your topic which
may give understanding to the OCSP service (in PKIX), in general :-(a) Acocuntability of
Directories/Repositories, in a PKIX environment

>
>
> Hunting around for an old CRL is perfectly acceptable, as long as publicly
> available directories have copies of old CRLs, of course.  As an additional
> requirement, the relying party may want the directory to sign the response
> (which includes the CRL) attesting that this was in fact the valid CRL at
> that time.

I'm a long term promoter of Directory signed-results for its operations. Thougha conventional
directory accepts anonymous binds, even for supplying security tokens,
when a reliable *commercial* directory engages in a subscriber contract with
a DUA, signed-results can mean necesarrily *more* that that which
the X.500 Directory DAP-service defines  (ISO defined service of  "Proof of origin with
Non-Repudiation" - a raw, militaristic, security notion)

Whereas conventionally in IT *business*, bilateral paper contracts or paper
subscriber agreements would be used to denote and agree the "quality of
telco value-added service" being commercially provided/guaranteed by the
Telco-like Directory provider (and would define the legal significance of the
signed-results digital signature) the nature of PKI perhaps helps automate
the creation of on-line contracts for "commercial-grade" subscription
of such a value-enhanced PKI management service via Directories. Lets
see how, *Internet* relationship-building style

If the Directory DSA signs a result,quoting a cert from a private-management domain
CA, and requires the DUA to sign its request, quoting a user-cert from
that same domain, then issuance and use of the valid certs and roots  can
signal acceptance of the terms-and-conditions for use of the service, as disclosed
and presented (and logically negotiated) at user-cert enrollment time.
Clearly, such T&C can require parties to cease reliance on a DSA result
signature (or historical signatures), and its supporting cert, the moment they no
longer choose to accept the binding contract. All sorts of usage conditions can
be negotiated, and agreed, during the acceptance of keying
material (CA root keys, and user-certs), by any party. Being
a PKIX CA will  perhaps be "a way of business" for any
e-commerce business on the net, not an exercise
is centralised key management and control.

OK, now substitute OCSP technology instead
of the signed-result service of Directory X.500 DAP...

(b) Support for Different Assurance models, and limits of PKIX

"All of this [business stuff] assumes that PKIX is being designed to scale to high value
transactions, which may not be the case.  Obviously, all of this is a bit
of overkill for Granny sending an email to little Johnny. " you say, later.

PKIX claims to be designed for multiple Internet uses; there are things that the
*Internet* is good for, and there are things it just aint no good for. High-value, real time
transactions may well be pushing the scope, given the assumed reliability model
of the underlying open, semi-managed transport infrastructure. This
design is for the Internet andits management culture, not some other
networking infrastructure, recall.

This is not to say, the same base PKI technology & standards
in a different open systems architecture cannot be re-purposed with ease,
when some lower-layer deployment assumptions are made.

(c) CRLs, and accountable CRL-distributors

> For example, CRLs are scheduled to be sent out every five days but for some
> odd reason a CRL had to be sent out on day two of five.  A relying party is
> checking to see if a certificate was valid on day three of five (he/she may
> be doing this several months later).

[...]

> The relying party wants the directory
> provider/repository to be accountable for the CRL that they return

[...]

> Assuming that this is a high
> value transaction, such as a funds transfer, the relying party may want to
> keep proof that the revocation status was checked.

I think we have to be careful in PKIX - in which the underlyingmodel relies upon the assumptions
X.509 and X.500 Directory.
In said model, notarization services are expected to be specified
by application protocols using directory services (see 1988
X.400 notarization service definitions, for example) and its
tokens (signed-results, certs, and CRLs (and now auth-certs)).

While I can imagine Directory and PKIX protocols specfyig
additional third-party services to do with notarization (and
time-stamping etc) one need to note that the high-end
*on-line* requirements which drive for these features are perhaps
not the general case for use of the Internet. Of course such
environments should apply the internet, but other Internet
uses can take advantage of the 95% suitability rule, in which
having an offline notary counter-sign your contract document/offer/...,
as valid in terms of security infrastructure (CRL
collection, attestation of validity) , may well suffice
to get the legal assurnaces many, many parties are after.

Such a simple notarization regime may not suit real-time,
high-value financial networks, but then this is not the
traditional use of the Internet, either!

(d) Futures

We have to beware of falling into the "ISDN trap"  which
planned for the whole world to  migrate to a next-generation
telco infrastructure - an Internet, perhaps, full of intelligent
mixed-mode, multi-media, broadband terminals with
high-end, payment-grade and legal-grade, security -- and
subscribers willing to pay $200 a month personal
networking costs.

There is nothing wrong with that requirement set,
in business environments but...

lets recall that this technoloy (PKIX) also has to work in
some of older third-world phone infrastructure also,
and in rural areas (currently without wireless!) and
in non-online circumstances (offline browsing
of your signed web-pages, email etc). All these folk
should be able to trust each other for a reasonablly
authenticated email, or logon to a Disney web server
channel with a $10 a month user cert (= access privilege),
no?

I honestly believe, even with OCSP (in PKIX) we have to be careful
not to get too carried away with ultra-high-end security and assurance,
when the raw Internet enviornment is perhaps not suitable for some categories
of usage whose security risk models cannot tolerate non-PKI-related
Internet assumptions in any case. "Putting a new pump in an old car
just breaks something else next week, unless you treat the
entire system with respect"

Of course, running OCSP on a fast, private, modern inter-bank network
will work just fine. But thats not the Internet!

Peter.

Date: Tue, 12 Aug 1997 11:03:33 +0100
From: Peter Williams <[email-masked]>
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

Bob,

Ive learned a great deal from you over the last 5 years; IMO you tend
to be 12-18 months ahead of the market in your (90% correct)
understanding of reality, for mass-market commercial uptake of crypto
infrastructure stuff.

Lets perhaps look at the bigger PKIX picture, and what I was driving
at in my message, and see if you have any wisdom to share:-

Bob Jueneman wrote:

>
> >
> >The obvious case to consider is an RSA/DSA SSL client authenitcation
> >token providing evidence of possesion of the private key during
> >real-time peer entity authentication using strong-authentication
> >procedures.
> >
> >In the case of DSA, there, neither the token value, which
> >was SIGNED(), nor the hash  value, are represented/recorded/conveyed!
> >
> >Lets remember PKIX supports more than just ISO-defined
> >digital signature security mechanisms.
>
> OK, but so what?  Would you simply add or XOR the bytes and divide by 997?
> That's a perfectly good hash if you are implementing a symbol table lookup
> for a compiler, but it certainly isn't very secure for our purposes.

Lets look at the phrase (generally) "isn't very secure for our purposes"Your argument suggested
objection to the term "hash" because of confusion
it would cause legal types; I pointed out to you that other legal types
might got hot and bothered about use of the term "message". PKIX
does not, and surely should not, get into strength isssues for its standardized
mechanisms; where will it end? mandated requirements for 4096 RSA keys,
32bit hash, and 256bit RC5?

The really important facts here are that PKIX-1 certs are not limited to
legal-grade  (intending) digital signature mechanisms; it can be used in
enviornments which are not intending to confer status of signed-writings. It thus
should not address environmental strength requirements, which when
issues as guidelines are inevitably prejudicial towards lower-end assurance
requirements.

(Looking at PKIX-1, PKIX is validly a little weighted against such legal
grade use, until augmented by *optional* stringent administrative
policy procedures during PKIX-3-like message handling, as enforced by
a strong implementation of subscriber key management procedures.)

The nature of a PKIX certificate is such that, whilst I find it nowhere stated, the
result of SIGNED() on its body is *intended* to be of signed-writing
status, in lawyerly terms. However the security mechanism(s) that
the distributed key(s) support(s) need not so be intended, nor
may they even necessarily act in support of a digital signature mechanism
or a non-repudiation mechanism, or some combination of mechanisms
and assigned key usages and purposes as required by the subscriber
or keyholder.

I believed you were seeking to change terms on grounds of easing "legal
acceptability" of PKIX-2  certs;  and, as historically, I object in principle *to
such* as legal-grade signed-writings are by no mean the *only* environment
to be supported by the PKIX key distribution infrastructure. (PKIX Policies
necessarily upgrade dominating terms to suit lawyers; so noone is disadvantaged.)

"Those of us in the technical community would know the difference, and I'm
not opposed to using "hash" in vernacular discussions, but I think that
there is a significant chance of misleading the legal and other communities
if we use the term in a formal document."

I know if I am to commence using S/MIME say with a PKIX cert
on each and every mail, I will want the usage semantics to clearly
be one of "initialling" and "mere authentication" (and will choose
my CA appropriately to ensure I get what I want from its policy)
versus solemn creation of  "a binding, valid, enforceable, agreement". When
I want such an effect, Ill use an appropriate cert, carefully; when I dont
want such an effect (99.999% of the time), I want a PKIX CA to enable
me to reasonably  say "its me folks (not that ABC journalist who
sometimes comments on security issues)".

The difference in stringency and assurnace regimes are very signficant,
for such totally opposed purposes, no?

Changing terms to suit lawyers is not perhaps where we want to go
with a technical document designed for many Internet uses, not only
the lawyers protocols.

Its clear to many that with solid PKIX-IV-type policies, PKIX-1 can indeed be
used to control the risks such "lawyers protocols" supporting
e-commerce can validly proceed to use public-key crypto, and
PKIX certs from conforming CAs; but this is surely NOT the only use
of this infrastructure we we are here striving to engineer, here?

From: "Paul Turner"<[email-masked]>
To: [email-masked]
Date: Tue, 12 Aug 1997 03:41:01 -0600
Subject: Re: PKIX Part 2 - Revised Draft

Earlier, I wrote the following, which may not have been clear:

> Since the relying party is going to be interested in knowing what the
> revocation status of a certificate status was at a given time, based on
> when the document that they are verifying was signed with the private
key,
> OCSP requests should include a "DateToCheckRevocationStatus" parameter.
> This will allow a relying party who is verifying the signature on a
> document that may have been signed months or years ago to determine
whether
> the private key used to sign the document was valid at the time the
> signature was applied.  This capability is crucial from a legal and
> business perspective since old digitally signed documents are undoubtedly
> going to need to be relied upon, and individuals/organizations will
> probably not want to go around hunting for an old CRL.

Let me attempt to clarify further:

Hunting around for an old CRL is perfectly acceptable, as long as publicly
available directories have copies of old CRLs, of course.  As an additional
requirement, the relying party may want the directory to sign the response
(which includes the CRL) attesting that this was in fact the valid CRL at
that time.

For example, CRLs are scheduled to be sent out every five days but for some
odd reason a CRL had to be sent out on day two of five.  A relying party is
checking to see if a certificate was valid on day three of five (he/she may
be doing this several months later).  The relying party wants the directory
provider/repository to be accountable for the CRL that they return, just in
case the repository returns the CRL issued at the beginning of the five day
period instead of the one issued on day two.  Assuming that this is a high
value transaction, such as a funds transfer, the relying party may want to
keep proof that the revocation status was checked.  This means that they
have to store the complete CRL response message, which becomes inefficient
if you're performing a lot of high value transactions.  CRLs are perfectly
acceptable for this type of application, though, and will probably be used
in many cases.

As an alternative, if the relying party can simply request the specific
status of a certificate from a OCSP service provider, they can be returned
a very small, signed message that is much more efficient to store but still
provides the accountability that the relying party wants the repository to
bear.  (Probably better not to get into the rathole of what exactly that
accountability is.)

All of this assumes that PKIX is being designed to scale to high value
transactions, which may not be the case.  Obviously, all of this is a bit
of overkill for Granny sending an email to little Johnny.  But it doesn't
seem overly cumbersome to enable the protocol to support higher value
applications, if that is in fact a goal of the PKIX working group.  Again,
it should not be mandated that all OCSP service providers make backdated
status checks available.

Thanks,

Paul

Paul Turner
CertCo LLC - www.certco.com

[email-masked]
801.553.0615
FAX 801.553.1764

Date: Tue, 12 Aug 1997 07:32:18 -0500
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKIX 2: use of the term "hash"
Cc: [email-masked]

Bob,

	The term "one-way hash function" or "one-way hash" is well accepted
in the literature and should be fine for out purposes.  I perfer not to go
with "message digest" as it might connote the RSADSI set of hash functions.

Steve

Date: Tue, 12 Aug 1997 09:02:53 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Digital Ltd.
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

Bob Jueneman wrote:
> 
> It would be better.  The only real problem I have is that certain parties
> might equate the use of a "cryptographic hash" with "cryptography" for the
> protection of information across insecure media, causing further confusion
> among the technically unsophisticated.  (And no, I am not referring to
> so-called salted hash techniques, which might more legitimately called a
> cryptographic hash, as they involve the use of a secret.)
> 
> I don't want to get wrapped around the axle about the precise definition of
> cryptography, but if a process doesn't involve a cryptographic key, or at
> least a secret algorithm, then I would say it was really just obfuscation or
> at best steganography.  A message digest such as MD-5 or SHA-1 doesn't
> involve a key, and certainly doesn't involve a secret algorithm, and hence
> doesn't deserve the term "crypographic", at least IMHO.

How about "one-way hash". (I know that isn't strictly true, but it is
less of a mouthful than "easy one way, hard the other hash").

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: [email-masked] |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Date: Mon, 11 Aug 1997 19:40:07 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

It would be better.  The only real problem I have is that certain parties
might equate the use of a "cryptographic hash" with "cryptography" for the
protection of information across insecure media, causing further confusion
among the technically unsophisticated.  (And no, I am not referring to
so-called salted hash techniques, which might more legitimately called a
cryptographic hash, as they involve the use of a secret.)

I don't want to get wrapped around the axle about the precise definition of
cryptography, but if a process doesn't involve a cryptographic key, or at
least a secret algorithm, then I would say it was really just obfuscation or
at best steganography.  A message digest such as MD-5 or SHA-1 doesn't
involve a key, and certainly doesn't involve a secret algorithm, and hence
doesn't deserve the term "crypographic", at least IMHO.

Bob

>>> "Rich Ankney" <[email-masked]> 08/11/97 06:19PM >>>
Would "cryptographic hash" (w/ appropriate definitions) be a better
choice?

Regards,
Rich

----------
> From: Bob Jueneman <[email-masked]>
> To: [email-masked]; [email-masked] 
> Subject: PKIX 2: use of the term "hash"
> Date: Monday, August 11, 1997 2:59 PM
> 
> This has nothing to do with Paul's comment, but I would like to deprecate
> the term "hash" and use "message digest" throughout the LKIX documents.
> 
> Hash functions are well understood, and have been since Knuth was a pup
> (well almost). But although all message digest functions would be
prefectly
> useful as a general purpose hash function (although perhaps slow), it is
> certainly not the case that all hash functions would be a suitable
message
> digest. In fact, designing a good message digest is a very difficult task

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                             

Date: Mon, 11 Aug 1997 17:04:57 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

>Bob Jueneman wrote:
>
>> This has nothing to do with Paul's comment, but I would like to deprecate
>> the term "hash" and use "message digest" throughout the LKIX documents.
>
>But, Bob, not all matters which are to be technically "one-way hashed"
>and whose hash is then subjected to a private-key operation are even
>half-legally entitled to be  known as a "message", assuming some fictional
>system of law.

Peter, I didn't invent the term "message digest," Ron Rivest did. So I won't
try to defend his terminology.  In fact, I would prefer my original term
"Modification Detection Code (MDC)" (but not my orignal algorithm), but
message digest is the term that has survived in the literature. So be it.

But I wasn't attempting to imply anything about the legal or other meaning
of the stream of bits that is being digested (non-sequitors about
indigestion omitted :-). I was merely trying to differentiate between a weak
hash function and a strong one.  (I also don't want to call a message digest
a cryptographic hash function, as some have done.)
>
>The obvious case to consider is an RSA/DSA SSL client authenitcation
>token providing evidence of possesion of the private key during
>real-time peer entity authentication using strong-authentication
>procedures.
>
>In the case of DSA, there, neither the token value, which
>was SIGNED(), nor the hash  value, are represented/recorded/conveyed!
>
>Lets remember PKIX supports more than just ISO-defined
>digital signature security mechanisms.

OK, but so what?  Would you simply add or XOR the bytes and divide by 997?
That's a perfectly good hash if you are implementing a symbol table lookup
for a compiler, but it certainly isn't very secure for our purposes.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: "Rich Ankney" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: PKIX 2: use of the term "hash"
Date: Mon, 11 Aug 1997 20:19:35 -0400

Would "cryptographic hash" (w/ appropriate definitions) be a better
choice?

Regards,
Rich

----------
> From: Bob Jueneman <[email-masked]>
> To: [email-masked]; [email-masked]
> Subject: PKIX 2: use of the term "hash"
> Date: Monday, August 11, 1997 2:59 PM
> 
> This has nothing to do with Paul's comment, but I would like to deprecate
> the term "hash" and use "message digest" throughout the LKIX documents.
> 
> Hash functions are well understood, and have been since Knuth was a pup
> (well almost). But although all message digest functions would be
prefectly
> useful as a general purpose hash function (although perhaps slow), it is
> certainly not the case that all hash functions would be a suitable
message
> digest. In fact, designing a good message digest is a very difficult task
--
> having tried several times, only to have people like Don Coppersmith
break
> them, I am very appreciative of the difficutly.
> 
> Those of us in the technical community would know the difference, and I'm
> not opposed to using "hash" in vernacular discussions, but I think that
> there is a significant chance of misleading the legal and other
communities
> if we use the term in a formal document.  The ABA Digital Signature
> Guidelines, for example, includes a "definition" of a hash function as a
> one-way function that is perhaps applicable to a password obfuscating
hash,
> but is neither necessary nor sufficient for use in digital signature
> applications.
> 
> Can we try to straighten out the terminology, please?
> 
> Bob
> 
> 
> 
> >
> 
> >
> >
> >
> >The latest PKIX Part 2 draft has the following text:
> >
> >"The hash-based option presumes the recipient
> >is the issuer of the certificate.   In the event OCSP server
> >receives a service request using the hash-based option to identify
> >the subject certificate but the recipient did not issue the subject
> >certificate, the server shall respond with an error message. If the
> >server is configured to provide signed error responses, this error
> >situation shall be indicated by a NO MY CERT response."
> >
> >Why is it presumed that the recipient is the issuer of the cert? 
Shouldn't
> >any OCSP service provider, whether the certifier or a third party acting
on
> >behalf of one or more certifiers, be able to respond properly to a
> >hash-based request since the hash includes the issuer DN?
> >
> >**Note the typo (NO MY CERT) in the last sentence, which was cut and
pasted
> >directly from the draft.
> >
> >Paul Turner
> >CertCo LLC - www.certco.com 
> >
> >[email-masked] 
> >801.553.0615
> >FAX 801.553.1764
> >
> >
> 
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
> 
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                                                                          
  
>                               

Date: Mon, 11 Aug 1997 13:20:14 +0100
From: Peter Williams <[email-masked]>
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX 2: use of the term "hash"

Bob Jueneman wrote:

> This has nothing to do with Paul's comment, but I would like to deprecate
> the term "hash" and use "message digest" throughout the LKIX documents.

But, Bob, not all matters which are to be technically "one-way hashed"
and whose hash is then subjected to a private-key operation are even
half-legally entitled to be  known as a "message", assuming some fictional
system of law.

The obvious case to consider is an RSA/DSA SSL client authenitcation
token providing evidence of possesion of the private key during
real-time peer entity authentication using strong-authentication
procedures.

In the case of DSA, there, neither the token value, which
was SIGNED(), nor the hash  value, are represented/recorded/conveyed!

Lets remember PKIX supports more than just ISO-defined
digital signature security mechanisms.

Date: Mon, 11 Aug 1997 12:59:12 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: PKIX 2: use of the term "hash"

This has nothing to do with Paul's comment, but I would like to deprecate
the term "hash" and use "message digest" throughout the LKIX documents.

Hash functions are well understood, and have been since Knuth was a pup
(well almost). But although all message digest functions would be prefectly
useful as a general purpose hash function (although perhaps slow), it is
certainly not the case that all hash functions would be a suitable message
digest. In fact, designing a good message digest is a very difficult task --
having tried several times, only to have people like Don Coppersmith break
them, I am very appreciative of the difficutly.

Those of us in the technical community would know the difference, and I'm
not opposed to using "hash" in vernacular discussions, but I think that
there is a significant chance of misleading the legal and other communities
if we use the term in a formal document.  The ABA Digital Signature
Guidelines, for example, includes a "definition" of a hash function as a
one-way function that is perhaps applicable to a password obfuscating hash,
but is neither necessary nor sufficient for use in digital signature
applications.

Can we try to straighten out the terminology, please?

Bob

>

>
>
>
>The latest PKIX Part 2 draft has the following text:
>
>"The hash-based option presumes the recipient
>is the issuer of the certificate.   In the event OCSP server
>receives a service request using the hash-based option to identify
>the subject certificate but the recipient did not issue the subject
>certificate, the server shall respond with an error message. If the
>server is configured to provide signed error responses, this error
>situation shall be indicated by a NO MY CERT response."
>
>Why is it presumed that the recipient is the issuer of the cert?  Shouldn't
>any OCSP service provider, whether the certifier or a third party acting on
>behalf of one or more certifiers, be able to respond properly to a
>hash-based request since the hash includes the issuer DN?
>
>**Note the typo (NO MY CERT) in the last sentence, which was cut and pasted
>directly from the draft.
>
>Paul Turner
>CertCo LLC - www.certco.com 
>
>[email-masked] 
>801.553.0615
>FAX 801.553.1764
>
>

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: "Paul Turner"<[email-masked]>
To: [email-masked]
Date: Mon, 11 Aug 1997 07:32:49 -0600
Subject: PKIX 2: OCSP Syntax

The latest PKIX Part 2 draft contains the following text:

"Since the task of certificate management is
largely unaffected by the mode of a certificate?s use, it is
preferable that a single OCSP implementation would meet the needs
of IPSEC, S/MIME, EDI and other diverse applications.  Recognizing
that this goal may not be achievable, the semantics of the OCSP
transaction model should remain invariant against the syntactic
constraints of the transport protocol used to convey the OCSP.  For
example, it?s easily forseeable that use of SMTP as a transport
model is the path of least resistance for e-mail User Agents, while
HTTP is an optimal choice for Web browsers.  The OCSP syntax for
each may differ according to each transport protocol?s usage
patterns; the semantic constructs should not."

The draft goes on the define OCSP in a syntax which is essentially foreign
to the rest of the PKIX standards suite.  In other words, while practically
all of PKIX parts 1,2 (LDAP), and 3 are defined in ASN.1 (it's assumed that
this was done to maximize interoperability), OCSP uses another syntax.
Why?

I've tried to go through some of the possible reasons below:
o  Transport.  BER and DER are used over SMTP and HTTP to transfer
certificates and the like--addressing one of the points in the quoted text
above.
o  Bandwidth Requirements.  Careful comparison of the proposed syntax and
an ASN.1 version shows that the size difference of request and response
messages is negligible, especially when you compare it to the documents
that are currently being sent across the Net.
o  Ability for a Human to Read Responses.  First of all, this would assume
that the person did not have an application to create a request for them so
they would have to know how to do that by hand.  Second, they have to be
able to parse through "#" signs with their magic decoder ring to figure out
what each field means.  It's assumed that any OCSP service provider who is
providing a human-readable revocation status response will want to put it
in paragraph form so that they can include all sorts of disclaimers.  It's
easy enough for them to automate this for both SMTP and HTTP.
o  Friend to Developers.   It seems that after implementing all or part of
the rest of the PKIX suite, developers will be ASN.1 pros.  If they relied
on toolkits for encoding/decoding messages, we would hope that the toolkits
would include OCSP encoding/decoding.
o  Performance.   It seems that a server provider shooting for good
performance should be able to optimize the tag-length-value format of both
DER and BER to be fairly fast.

It seems that revocation status and validity checking is normally going to
be performed by merchants and corporations.  Most consumers shouldn't know
what a certificate is, let alone be worried about it's status.  Many
corporations processing messages from consumers or other corporations will
probably be using automated systems to do so.  It seems crucial to make
sure that all of these systems be interoperable.  Considering all of the
pain and suffering that we're going through to make sure that our
ASN.1-based encoding is interoperable, couldn't we leverage some of the
bandages and splints?

Sorry for the rant.  There's probably a great reason that the current
syntax was used instead of ASN.1.  Could somebody provide some enlightment?
If by chance ASN.1 would be acceptable or desirable, we'd be happy to
suggest an ASN.1 alternative.

Paul

Paul Turner
CertCo LLC - www.certco.com

[email-masked]
801.553.0615
FAX 801.553.1764

From: "Paul Turner"<[email-masked]>
To: [email-masked]
Date: Mon, 11 Aug 1997 06:27:22 -0600
Subject: RE: RE: PKIX Part 2 - Revised Draft

Since the relying party is going to be interested in knowing what the
revocation status of a certificate status was at a given time, based on
when the document that they are verifying was signed with the private key,
OCSP requests should include a "DateToCheckRevocationStatus" parameter.
This will allow a relying party who is verifying the signature on a
document that may have been signed months or years ago to determine whether
the private key used to sign the document was valid at the time the
signature was applied.  This capability is crucial from a legal and
business perspective since old digitally signed documents are undoubtedly
going to need to be relied upon, and individuals/organizations will
probably not want to go around hunting for an old CRL.

True, some OCSP service providers will not want to archive all of the old
CRLs to provide this level of service but they can simply respond with
"SERVICE UNAVAILABLE".

In addition, OCSP responses should probably include a
"DateCheckedForRevocationStatus" so that the relying party has a signed
response from the OCSP service provider attesting the revocation status and
the date that the status was checked.

Paul Turner
CertCo LLC - www.certco.com

[email-masked]
801.553.7709
FAX 801.553.1764

[email-masked] on 08/07/97 06:00:37 AM

To:   [email-masked], [email-masked], [email-masked]
cc:   [email-masked], [email-masked] (bcc: Paul
      Turner/CERTCO/US)
Subject:  RE: RE: PKIX Part 2 - Revised Draft

I agree that leaving revocation entries on a revocation list past the
expiry date doesn't achieve non-repudiation, nor is it intended to.
Notary and timestamping services are required in non-repudiation and the
new parts of PKIX are addressing this. It is worth looking at the use of
these new parts in the context of part 2 however.

Enabling revocation entries to remain on revocation lists beyond their
expiry date is a useful feature in many current environments where
timestamping and notary services are not deployed. As indicated by Peter
in his earlier message, this requires no additional standardization and
can be achieved within the existing set. There is no intention that this
any substitute for notary services though and on that I believe we are
all agreed.
------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:    Mike Smith[SMTP:[email-masked]]
>Sent:    August 6, 1997 3:10 PM
>To:      [email-masked]; [email-masked]
>Cc:      [email-masked]; [email-masked]
>Subject:      Re: RE: PKIX Part 2 - Revised Draft
>
>Note:  the time and date (notarization in previous message) would also
need
>to be attached securely to
>
>>>> David P. Kemp <[email-masked]> 08/06/97 10:04AM >>>
>> From: Sharon Boeyen <[email-masked]>
>>
>> Peter, there's another to handle it as well without any standardization.
>> Using distribution points, once all the certs pointing to a certain
>> distribution point have passed their expiry date, you can consider that
>> distribution point an "old" crl.
>
>Am I missing something?  Isn't there more to non-repudiation than
>just archiving old CRLs?
>
>There must be some evidence that the certificates and CRLs were valid
>as of the signature date - notarizing them is one method of achieving
>this.  But if you have a notarized copy of the old CRL, why do you need
>an archived (unprotected) copy?
>
>(A CRL archive might be necessary with a "publish-the-hash-tree-in-a-
>newspaper" type scheme, but is that what is being discussed here?)
>
>
>
>
>
>
>
>
>
>
>
>
>                                                     !
>
>
>
>
>
>

From: "Paul Turner"<[email-masked]>
To: [email-masked]
Date: Mon, 11 Aug 1997 06:40:27 -0600
Subject: PKIX 2: OCSP Hash-based option

The latest PKIX Part 2 draft has the following text:

"The hash-based option presumes the recipient
is the issuer of the certificate.   In the event OCSP server
receives a service request using the hash-based option to identify
the subject certificate but the recipient did not issue the subject
certificate, the server shall respond with an error message. If the
server is configured to provide signed error responses, this error
situation shall be indicated by a NO MY CERT response."

Why is it presumed that the recipient is the issuer of the cert?  Shouldn't
any OCSP service provider, whether the certifier or a third party acting on
behalf of one or more certifiers, be able to respond properly to a
hash-based request since the hash includes the issuer DN?

**Note the typo (NO MY CERT) in the last sentence, which was cut and pasted
directly from the draft.

Paul Turner
CertCo LLC - www.certco.com

[email-masked]
801.553.0615
FAX 801.553.1764

Date: Sun, 03 Aug 1997 22:17:48 +0200
From: Paolo Da Ros <[email-masked]>
Organization: CryptoNet Srl
To: [email-masked]
CC: Stefano Taino <[email-masked]>
Subject: (no subject)

subscribe

Date: Sun, 10 Aug 1997 17:17:59 -0400
To: plipp <[email-masked]>
From: Santosh Chokhani <[email-masked]>
Subject: Re: PKIX Part 4 I-D
Cc: [email-masked]

We are working on some stuff.  Warwick Ford has also used the guideline.

Revocation grace period is the time subscriber has to report the potential
loss or compromise of the private key.

At 11:05 AM 8/7/97, plipp wrote:
>I am currently trying to work out a policy and CPS following
>the Part 4-draft. I wondered, if there was anybody who has already
>published an implementation of such a policy following that draft?
>
>One point that was unclear to me just now: what is the "revocation grace
period"?=20
>
>Peter
>
>
>
>Dr. Peter Lipp, IAIK, University of Technology, Graz
>Institute for Applied Information Processing and Communications
>Klosterwiesgasse 32/I, A-8010 Graz, +43 316 873 5513
>________________________________________________________________________
>Was n=FCtzt die beste Erziehung, die Kinder machen uns ja doch alles nach.
>
>

-------------------------------------------------
Santosh Chokhani
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, Virginia 22102-3305
(703) 848 - 0883
[email-masked]

From: Xiaoyi Liu <[email-masked]>
Subject: PKI draft based on PKCS#10 and PKCS#7
To: [email-masked]
Date: Fri, 8 Aug 1997 14:31:01 -0700 (PDT)
Cc: [email-masked] (Xiaoyi Liu)
Content-Length: 2219

 Recently, there are several issues raised for the certificate management 
 protocol based on PKCS#7 and PKCS#10. We like to address those issues
 here and open a discussion.
 
 1) The draft does not cover all the functions required for a certificate
 management protocol.
 
 The most important functions of a certificate management protocol, the 
 enrollment operations, have been designed, implemented and tested, and these
 are what we feel the most important pieces needed to get a functional PKI 
 solution into the marketplace in the very near future. It is also clear that, 
 the proposed protocol does not precluse other functionality required of 
 certificate management protocols. It is open ended and extensible. 

 We believe the proposed draft has its merit not only because it proposes a 
 solution to the existing certificate enrollment problem, but also because it 
 leverages the existing PKCS#7 and PKCS#10 technology and can be developed in a 
 relatively short time with the existing toolkit. It is certainly our 
 direction to futher improve the protocol, based on the standard requirement
 and the actual customer experience.
 
 2) The draft does not address effectively the authentication between the
 end entity and the CA.
 
 There are different models to carry out the authentication between the end
 entity and the CA. The customers should be given the choices to make their
 decision. In the current draft, the authentication between the end entity
 and the CA is specified as out-of-band manual authentication, which is one
 kind of model which satisfies certain customer need. However, there is no
 restriction to integrate other authentication model into the protocol. It is
 important to note that, since we are discussing the authentication at the
 bootstrapping phase, out-of-band operation is required for any proposed method
 at different stage.
 
 3) The draft proposes a single key system
 
 It is true the draft at the current state utilize a single key system. However,
 PKCS#7 is a protocol which does not exclude the dual-key system. We are 
 working at various solutions which can expand the current protocol to handle 
 the dual-key system. 

 Xiaoyi Liu, Cisco System

Date: Fri, 8 Aug 1997 13:50:49 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: RE: PKCS 7 + PKCS 10 Proposal

> > From:  [email-masked][SMTP:[email-masked]]
> >
> >To the last point, I would observe that the draft is intended to address
> >only the most essential elements of a PKI service, with the thought in
> >mind that additional work would be needed to expand upon these basic
> >services.

What would this additional work entail?

* The addition of features not currently addressed by the draft which
are already addressed by the existing PKIX-3?

* Modification of the protocol to track development of PKCS #7?
I note that the draft (section 3.6) uses the signedData and envelopedData
constructs, so it is apparently based on version 1.5 of PKCS7.
PKCS7 version 2.0 combines these and several other constructs into two
generic items - IntegrityProtectionInfo and EncryptionInfo.
Will your proposal stick with the old PKCS7 to allow the installed base
of code to continue to be used, or will it use current PKCS7, maintaining
synchronism with S/MIME but requiring new code development?

If new code is required, why shouldn't it be based on PKIX-3?

> From: Carlisle Adams <[email-masked]>
> 
> In other words, the plan seems to be to essentially re-do everything
> that has already been done in the past 1-1/2 to 2 years with PKIX-3.
> Mike has repeatedly said to me that a lot of effort and thinking has
> gone into PKIX-3 to construct a secure, general set of protocols for
> certificate management.  Does it make sense to do this all again for
> this new proposal (and wait another 1-1/2 to 2 years to get something
> that is strong enough and general enough to be useful)?  My personal
> feeling is, "No".
> 
> Ultimately, what PKIX is all about is the definition and standardization
> of a Public-Key Infrastructure for the Internet.  The proposal given
> here cannot (and does not) claim to build such an infrastructure.  It
> may provide *some* of the necessary functionality for *some*
> environments (although I still worry about not being able to securely
> initialize entities), but this limited focus is clearly inadequate for
> an IPKI.  Considering that this work has already been done in PKIX-3,
> and that it is ready to go to Working Group Last Call, it seems to me
> that the proposal given here may be suitable as a (standardized or
> proprietary) protocol in some other context, but not within the stated
> scope of the PKIX Working Group.

I agree completely with this summary.  It is perfectly reasonable
for PKI providers to continue to use and support a suboptimal but
working legacy protocol for as long as there is a market for it.
This doesn't require any action by the IETF - just do it.

But it is not reasonable for PKIX to devote resources to standardizing
a partial solution when a well-specified complete solution has already
gone through the long process and is ready to proceed to Proposed Standard.

> From: Robert Moskowitz <[email-masked]>
>
> Is PKIX-3 (showing my lack of energy to cover it too) codeable?  Are
> there any implimentations out there that we can see in action?

It is certainly codeable.  PKIX-3 bears a striking resemblance to the
MISSI Management Protocol (MMP), which provides certificate and key
life-cycle support, audit, and additional Government-specific
functionality related to the initialization of Fortezza(R) cards.  MMP is
running today (and has been for several years) in BBN (GTE) and
Motorola products - if you stripped out all the non-certificate-related
messages you would have something that looks pretty similar to PKIX-3.

Date: Fri, 08 Aug 1997 10:55:52 +0100
From: Peter Williams <[email-masked]>
To: Tim Polk <[email-masked]>
CC: [email-masked]
Subject: Re: incomplete paragraph in ipki-part1-05 ?

Tim Polk wrote:

>  At 04:50 PM 8/7/97 +0200, Ingmar Camphausen wrote:
> >4.2.1.7  "Subject Alternative Name" (on page 27 of ipki-part1-05):
> >
> >>    If the subjectAltName extension is present, the sequence must
> contain
> >>    at least one entry.  Unlike the subject field, conforming CAs
> shall
> >>    not issue certificates with subjectAltNames containing empty
> >>    GeneralName fields. For example, an rfc822Name is represented as
> an
> >>    IA5String. While an empty string is a valid IA5String, such an
> >>    rfc822Name is not permitted by this profile.  The behavior of
> clients
> >>    that encounter such a certificate when processing a
> certificication
> >>    path is
> >>
> >>       id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
> >>
> >>       SubjectAltName ::= GeneralNames
> >[...]
>

Tim,

In this "internet profile" should one perhaps allow, or even mandate,
that the
strings in rfc822Name be (semantically and lexically) legal RFC1522
strings? This
would remove an "incomplete" piece of specification, and ambiguous
implementation
situation.

"=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>" for example.

An increasing number of parties can now process extended SMTP, and such
a move is backwards compatible with parties who only handle US-ASCII
(IA5STRING with IRV codeset).

This would allow rather more internationalism into cert names, using
internet
technology traditions, and email vendors doing signed mail applying PKIX
certs
using the rfc822Name name-form in place of, or alongside, X.500
Directory
names, and DNs, would surely benefit.

http://ds.internic.net/rfc/rfc1522.txt

Date: Fri, 08 Aug 1997 11:32:02 -0400
To: [email-masked], [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: incomplete paragraph in ipki-part1-05 ?

Ingmar,

You are absolutely correct.  I will add "undefined." to the end of the
offending paragraph.  Thanks for the thorough review!

Thanks,

Tim Polk

At 04:50 PM 8/7/97 +0200, Ingmar Camphausen wrote:
>4.2.1.7  "Subject Alternative Name" (on page 27 of ipki-part1-05):
>
>>    If the subjectAltName extension is present, the sequence must contain
>>    at least one entry.  Unlike the subject field, conforming CAs shall
>>    not issue certificates with subjectAltNames containing empty
>>    GeneralName fields. For example, an rfc822Name is represented as an
>>    IA5String. While an empty string is a valid IA5String, such an
>>    rfc822Name is not permitted by this profile.  The behavior of clients
>>    that encounter such a certificate when processing a certificication
>>    path is
>>
>>       id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
>>
>>       SubjectAltName ::= GeneralNames
>[...]
>
>
>I seems to me that the end of the paragraph before the ASN.1 definition  
>is incomplete (likely to me, for it has been added after version 4 of the  
>draft).
>
>Maybe there is only an "undefined." missing to cure this?
>

From: [email-masked]
X400-Originator: [email-masked]
X400-Recipients: [email-masked]
X400-Mts-Identifier: [/PRMD=DEUTSCHE-BANK/ADMD=DBP/C=DE/;0033800001193041000002]
X400-Content-Type: P2-1988 (22)
To: <[email-masked]>
Reply-To: "        -         (052)chandras(a)loc201.tandem.com" <[email-masked]>
Date: Fri, 8 Aug 1997 13:22:40 +0200

unsubscribe [email-masked]

Subject: unsubscribe
From: Gertraud Unterreitmeier <[email-masked]>
To: [email-masked]
Date: 	Fri, 8 Aug 1997 10:07:31 +0200 (METDST)
Content-Length: 47        

unsubscribe [email-masked]

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: PKCS 7 + PKCS 10 Proposal
Date: Thu, 7 Aug 1997 17:44:52 -0400

Hi,

I posted the following reply yesterday but haven't seen it show up on
the PKIX list yet, so I wondered if it got lost somewhere.  In any case,
here we go again...

>----------
>From: 	Carlisle Adams
>Sent: 	Wednesday, August 06, 1997 5:57 PM
>To: 	'Peter Williams'
>Cc: 	[email-masked]'; [email-masked]'
>Subject: 	RE: PKCS 7 + PKCS 10 Proposal
>
>Peter,
>
>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Wednesday, August 06, 1997 9:38 AM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'; [email-masked]'
>Subject: 	Re: PKCS 7 + PKCS 10 Proposal
>
>Carlisle Adams wrote:
>
>>  The draft does not simply promote the notion that one need only have a
>> single key.  Rather, it fundamentally relies on that notion.  [See, for
>> example, the first sentence of Section 5.1.1.2 which says, "Because the
>> response is encrypted with the user's public key....  This is the
>> response to the certification request, which (being a PKCS #10 request)
>> was signed with the user's private key.  One key pair for both signing
>> and encryption.  
>
>Im a little annoyed (a mild IETF level of rebuke!) as you
>know there is no such intent, as evidenced by your own companies
>actions.
>
>When we specified the S/MIME profile of PKCS7 ,we specifically
>decided that dual cert models (often proposed by Entrust) should
>not be excluded. To this end, Entrust endorsed PKCS7, knowing
>full well the protocol allows dual-cert solutions. I can point
>folks to your website for product  information, if you like.
>
>Since the last thing anyone would want to do is to annoy you, let me
>highlight what I said (and what I did not say).  I did *not* say that PKCS #7
>excludes the dual-key model.  We all know that it allows single-key and
>dual-key models.  What I *did* say, however, was that this specific proposal
>fundamentally relies on a single-key model, as evidenced quite clearly by the
>quote I gave from Section 5.1.1.2.  Yes, this proposal is based on PKCS #7,
>but it does not allow the richness of PKCS #7 in this respect because it
>assumes that a single key pair can be used for signing and encryption.
>
>Can we both agree with this without either party getting annoyed?
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>P.S., Any time you feel compelled to point folks to our web site for product
>information, feel free to go ahead and do so.
>
>

Date: Thu, 07 Aug 1997 11:57:52 +0100
From: Peter Williams <[email-masked]>
To: [email-masked]
CC: PKIX working group <[email-masked]>
Subject: Re: IssuerAltName - pointer to what kind of sequence of certs?

Ingmar Camphausen wrote:

> draft-ietf-pkix-ipki-part1-05 says in 4.2.1.8 "Issuer Alternative
> Name":
>
>    Where the issuerAltName extension contains a URI, the following
>    semantics shall be assumed: the URI is a pointer to a sequence of
>                                                          ~~~~~~~~
>    certificates issued to this CA (and optionally other CAs).
>
> Is that 'sequence' meant in the ASN.1 sense, i.e. are those
> certificates
> a "SEQUENCE SIZE (1..MAX) of Certificate", or "Certificates" (as
> defined
> in X.509v3), or is it meant as a concatenation of single
> (PEM-encoded?)
> certificates?

Great question.

Buts lets hold on one moment - the name here is a name, not a link
pointer.
Semantically, this profile text is entirely suspect. Its a URI field,
not just a URL field
pointing to an ancilliary resource which then contains the name or some
collection of other CA stuff.

I know URI are a semantic superset of URLs, but URIs are being used here
in
their naming function, not their resource locating (addressing)
function. Even should
a URL value be used as a URI name, there are no intention to use this
except as a convenient self-standing (or directory) name, in this
construct, surely?

take another example: if the altIssuerName used the OID option, and the
issuer was nominally "Verisign CA#1", one would simply expect the oid
for that CA#1 in the field, signalling the (numeric) name for
the registered CA object being denoted. If it was an organizational CA,
one
could naturally use the DUNS number, alternatively, or the
EDI-Identifier
number  many companies already have registered when doing signed
EDI over Internet X.435 or S/MIME, when applying PKIX certs.

Would one expect to find the CA cert sequence (or otherwise)  in the
OID registry? Surely not.

---------

To the question:-

The ability in X.509 to signal the cert's parent's chain of certs was
surely given
over to the authorityKeyId extension. A GeneralName there can also be a
URI,
and could sensibly be a URL to a collection of certs for that CA party
(one
for cert issuing, another for CRL issuing, another for auth-cert
issuing;
and each of which can be supported by its own path.)

(NB Access to this data is what I keep trying to have the URL/http
element
of PKIX-2 support - one cert at a time is not too interesting to real
address-book software; its the complete cert/CRL path(s) one  wants!)

This would indeed suggest that  "SEQUENCE OF
AuthenticationFramework.Certificates" syntax as
the form for the URL resource in (advanced) use of GeneralName
used in  the authorityKeyId context (only) is 100% right.

ftp://ftp.bull.com/pub/OSIdirectory/ITU/X.509/ for Hoyt's  resources.

Now these matters are what Internet-specific profiling of the X.509
standard are really all about!

Peter.

From: Ingmar Camphausen <[email-masked]>
Date: Thu,  7 Aug 97 19:53:50 +0200
To: [email-masked] (PKIX working group)
Subject: IssuerAltName - pointer to what kind of sequence of certs?
Reply-To: [email-masked]
Priority: normal

draft-ietf-pkix-ipki-part1-05 says in 4.2.1.8 "Issuer Alternative Name":

   Where the issuerAltName extension contains a URI, the following
   semantics shall be assumed: the URI is a pointer to a sequence of
                                                         ~~~~~~~~
   certificates issued to this CA (and optionally other CAs).

Is that 'sequence' meant in the ASN.1 sense, i.e. are those certificates  
a "SEQUENCE SIZE (1..MAX) of Certificate", or "Certificates" (as defined  
in X.509v3), or is it meant as a concatenation of single (PEM-encoded?)  
certificates?

	Ingmar Camphausen

__________________________________________________________________
Internet : [email-masked]
Phone    : ++49 / (0)30 / 34 63 - 73 57
Fax      : ++49 / (0)30 / 34 63 - 83 57
Address  : Research Institute for Open Communication Systems
PLEASE NOTE: We move! New adress from 11/8/97 on:
           GMD FOKUS, Kaiserin-Augusta-Allee 31, D-10589 Berlin, Germany

From: Ingmar Camphausen <[email-masked]>
Date: Thu,  7 Aug 97 16:50:57 +0200
To: [email-masked]
Subject: incomplete paragraph in ipki-part1-05 ?
Reply-To: [email-masked]
Priority: normal

4.2.1.7  "Subject Alternative Name" (on page 27 of ipki-part1-05):

>    If the subjectAltName extension is present, the sequence must contain
>    at least one entry.  Unlike the subject field, conforming CAs shall
>    not issue certificates with subjectAltNames containing empty
>    GeneralName fields. For example, an rfc822Name is represented as an
>    IA5String. While an empty string is a valid IA5String, such an
>    rfc822Name is not permitted by this profile.  The behavior of clients
>    that encounter such a certificate when processing a certificication
>    path is
>
>       id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
>
>       SubjectAltName ::= GeneralNames
[...]

I seems to me that the end of the paragraph before the ASN.1 definition  
is incomplete (likely to me, for it has been added after version 4 of the  
draft).

Maybe there is only an "undefined." missing to cure this?

	Ingmar Camphausen

__________________________________________________________________
Internet : [email-masked]
Phone    : ++49 / (0)30 / 25 499 - 357
Fax      : ++49 / (0)30 / 25 499 - 202
Address  : Research Institute for Open Communication Systems
           GMD FOKUS, Hardenbergplatz 2, D-10623 Berlin, Germany

PLEASE NOTE: WE MOVE! New adress from 18/7/97 on:
           GMD FOKUS, Kaiserin-Augusta-Allee 31, D-10589 Berlin, Germany
Phone    : ++49 / (0)30 / 34 63 - 72 08
Fax      : ++49 / (0)30 / 34 63 - 82 08
           (The Internet mail address remains valid.)

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Mike Smith'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: RE: PKIX Part 2 - Revised Draft
Date: Thu, 7 Aug 1997 08:00:37 -0400

I agree that leaving revocation entries on a revocation list past the
expiry date doesn't achieve non-repudiation, nor is it intended to.
Notary and timestamping services are required in non-repudiation and the
new parts of PKIX are addressing this. It is worth looking at the use of
these new parts in the context of part 2 however. 

Enabling revocation entries to remain on revocation lists beyond their
expiry date is a useful feature in many current environments where
timestamping and notary services are not deployed. As indicated by Peter
in his earlier message, this requires no additional standardization and
can be achieved within the existing set. There is no intention that this
any substitute for notary services though and on that I believe we are
all agreed.
------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

>----------
>From: 	Mike Smith[SMTP:[email-masked]]
>Sent: 	August 6, 1997 3:10 PM
>To: 	[email-masked]; [email-masked]
>Cc: 	[email-masked]; [email-masked]
>Subject: 	Re: RE: PKIX Part 2 - Revised Draft
>
>Note:  the time and date (notarization in previous message) would also need
>to be attached securely to
>
>>>> David P. Kemp <[email-masked]> 08/06/97 10:04AM >>>
>> From: Sharon Boeyen <[email-masked]>
>> 
>> Peter, there's another to handle it as well without any standardization.
>> Using distribution points, once all the certs pointing to a certain
>> distribution point have passed their expiry date, you can consider that
>> distribution point an "old" crl.
>
>Am I missing something?  Isn't there more to non-repudiation than
>just archiving old CRLs?
>
>There must be some evidence that the certificates and CRLs were valid
>as of the signature date - notarizing them is one method of achieving
>this.  But if you have a notarized copy of the old CRL, why do you need
>an archived (unprotected) copy?
>
>(A CRL archive might be necessary with a "publish-the-hash-tree-in-a-
>newspaper" type scheme, but is that what is being discussed here?)
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                     !
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>   
>

Date: Thu, 7 Aug 1997 14:03:57 +0200
To: [email-masked]
From: [email-masked] (Olivier Onimus)
Subject: Encoding of "iPAddress" in X.509-Certificates

Hi !

The following statement  concerning
the coding of the element "iPAddress" in GeneralName (Chapter 12.3.2.1) is
mentioned in the X.509-standard:

"=97	iPAddress is an Internet Protocol address defined in accordance with
Internet RFC 791, represented as a binary string."

GeneralName ::=3D CHOICE {
	otherName			[0]	INSTANCE OF OTHER-NAME,
	rfc822Name			[1]	IA5String,
	dNSName			        [2]	IA5String,
	x400Address	   	        [3]	ORAddress,
	directoryName		        [4]	Name,
	ediPartyName		        [5]	EDIPartyName,
	uniformResourceIdentifier	[6]	IA5String,
	iPAddress			[7]	OCTET STRING,
	registeredID			[8]	OBJECT IDENTIFIER }

Does it mean the content of the OCTET STRING containing the IP-Address
"123.124.125.126" should be coded like:
'7B7C7D7E'H (that's what I understand under "represented as a binary=
 string").=20
  | | | |
123 | | |=20
  124 | |
    125 |
       126

or (as we have seen in in certificates that we have downloaded from internet
to test our decode-software !) like:

'3132332E3132342E3132352E313236'H
  1 2 3 . 1 2 4 . 1 2 5 . 1 2 6

Thanks in advance for your response !

Olivier
                       =20
Olivier Onimus
Danet GmbH, Business Unit Telecommunications Technology
P.O.Box 10 04 03, D-64204 Darmstadt
Tel:    +49-6151-868-127 =20
Fax:    +49-6151-868-264
X.400:  C=3Dde;A=3Dd400;P=3DDanet;O=3DDanet-GmbH;S=3DOnimus
e-mail: [email-masked]

                       =20
Olivier Onimus
Danet GmbH, Business Unit Telecommunications Technology
P.O.Box 10 04 03, D-64204 Darmstadt
Tel:    +49-6151-868-127 =20
Fax:    +49-6151-868-264
X.400:  C=3Dde;A=3Dd400;P=3DDanet;O=3DDanet-GmbH;S=3DOnimus
e-mail: [email-masked]

Date: Thu, 07 Aug 1997 11:05:34
From: plipp <[email-masked]>
To: [email-masked]
Subject: PKIX Part 4 I-D

I am currently trying to work out a policy and CPS following
the Part 4-draft. I wondered, if there was anybody who has already
published an implementation of such a policy following that draft?

One point that was unclear to me just now: what is the "revocation grace =
period"? 

Peter

Dr. Peter Lipp, IAIK, University of Technology, Graz
Institute for Applied Information Processing and Communications
Klosterwiesgasse 32/I, A-8010 Graz, +43 316 873 5513
________________________________________________________________________
Was n=FCtzt die beste Erziehung, die Kinder machen uns ja doch alles nach.

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: PKCS 7 + PKCS 10 Proposal
Date: Wed, 6 Aug 1997 17:57:57 -0400

Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Wednesday, August 06, 1997 9:38 AM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'; [email-masked]'
>Subject: 	Re: PKCS 7 + PKCS 10 Proposal
>
>Carlisle Adams wrote:
>
>>  The draft does not simply promote the notion that one need only have a
>> single key.  Rather, it fundamentally relies on that notion.  [See, for
>> example, the first sentence of Section 5.1.1.2 which says, "Because the
>> response is encrypted with the user's public key....  This is the
>> response to the certification request, which (being a PKCS #10 request)
>> was signed with the user's private key.  One key pair for both signing
>> and encryption.  
>
>Im a little annoyed (a mild IETF level of rebuke!) as you
>know there is no such intent, as evidenced by your own companies
>actions.
>
>When we specified the S/MIME profile of PKCS7 ,we specifically
>decided that dual cert models (often proposed by Entrust) should
>not be excluded. To this end, Entrust endorsed PKCS7, knowing
>full well the protocol allows dual-cert solutions. I can point
>folks to your website for product  information, if you like.

Since the last thing anyone would want to do is to annoy you, let me
highlight what I said (and what I did not say).  I did *not* say that
PKCS #7 excludes the dual-key model.  We all know that it allows
single-key and dual-key models.  What I *did* say, however, was that
this specific proposal fundamentally relies on a single-key model, as
evidenced quite clearly by the quote I gave from Section 5.1.1.2.  Yes,
this proposal is based on PKCS #7, but it does not allow the richness of
PKCS #7 in this respect because it assumes that a single key pair can be
used for signing and encryption.

Can we both agree with this without either party getting annoyed?

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

P.S., Any time you feel compelled to point folks to our web site for
product information, feel free to go ahead and do so.

Date: Wed, 06 Aug 1997 14:38:10 +0100
From: Peter Williams <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: PKCS 7 + PKCS 10 Proposal

Carlisle Adams wrote:

>  The draft does not simply promote the notion that one need only have
> a
> single key.  Rather, it fundamentally relies on that notion.  [See,
> for
> example, the first sentence of Section 5.1.1.2 which says, "Because
> the
> response is encrypted with the user's public key....  This is the
> response to the certification request, which (being a PKCS #10
> request)
> was signed with the user's private key.  One key pair for both signing
>
> and encryption.  Didn't I hear a (loud) call from the group recently
> saying that DSA should be mandatory for the PKIX protocols and that
> RSA
> should be optional?]
>
> The impression I get from many, many quarters is that, collectively,
> we
> have (or should have) put this issue to rest by now.  Of course there
> are a number of systems out there that operate as single-key systems
> for
> historical and backward-compatibility reasons.  However, there is no
> valid argument for fundamentally building in a single-key assumption
> in
> new protocols that we propose.  I suspect there will be no shortage of
>
> people who oppose this if we try to promote such a limited and flawed
> design.

Im a little annoyed (a mild IETF level of rebuke!) as you
know there is no such intent, as evidenced by your own companies
actions.

When we specified the S/MIME profile of PKCS7 ,we specifically
decided that dual cert models (often proposed by Entrust) should
not be excluded. To this end, Entrust endorsed PKCS7, knowing
full well the protocol allows dual-cert solutions. I can point
folks to your website for product  information, if you like.

When we specified the SET profile of PKCS7 we specifically
decided that dual cert models (often proposed by Entrust) should
not be excluded.... i

When we specified the PKIX profile of PKCS7 to refine
the options provided in PKIX-1 we specifically
decided that dual cert models (often proposed by Entrust) ...

When we established the PKIX-1 profile, we all specifically
allowed operational management domains to choose
how many certs and keys they want to administer.
PKIX WG scope endorsed RFC 1422 ( a single key
design) and one must not forget this assumption of need
to enable domains to do as they wish. S/MIME is working
currently fine with some domains having two keys,
other having one key. Lets users choose freely, and without
pressure.

Anything is better than everyone being forced to buy a
product from a single vendor, or developers being forced to
buy the same toolkit, or be subject to a trademark
regime! Even RSA does not have any of those properties!

Reply-To: [email-masked]
Date: Wed, 06 Aug 1997 15:50:31 -0400
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: RE: PKCS 7 + PKCS 10 Proposal
Cc: "[email-masked]'" <[email-masked]>

At 03:00 PM 8/6/97 -0400, Carlisle Adams wrote:
>
>I have a number of major concerns with the proposal that was submitted
>to these lists recently, along with several serious, but less critical,
>concerns.  I'll only mention the major ones here.

Thank you, Carlisle for this analysis.

>
>The draft does not simply promote the notion that one need only have a
>single key.  Rather, it fundamentally relies on that notion.  [See, for
>example, the first sentence of Section 5.1.1.2 which says, "Because the
>response is encrypted with the user's public key....  This is the
>response to the certification request, which (being a PKCS #10 request)
>was signed with the user's private key.  One key pair for both signing
>and encryption.  Didn't I hear a (loud) call from the group recently
>saying that DSA should be mandatory for the PKIX protocols and that RSA
>should be optional?]

In an environment where there is operationally only a need for an identity
key (Oakley RSA Sig), is putting a requirement that there be an encrypting
key to be used only for the 'registering' of the identity key valuable?

Of course, this focuses my mind on the construct of Oakley RSA encrypt and
the new Oakley enhanced RSA encrypt.  Is its design based on a single
key-pair RSA environment?  And if so, what would a duo-key-pair RSA encrypt
exchange look like?

BTW, for systems that have an operational need for public key encryption
(EMail as one), my position is that duo-key-pair is the right model, and
single key-pair is fatally, legally flawed.

>>2.  It provides no means to certify a D-H key.  Recognizing that the WG
>>has received a proposal to do so using PKCS 10 constructs, there still
>>remains a problem of coordinating parameters between the client and the
>>CA.

This is facinating and needs to be addressed.  When will it impact IPsec?

>>3.  It does not adequately address the subscriber bootstrapping 
>>problem.
>
>"Does not adequately address" is a little understated.  It does not
>address this problem at all.  In other words, there is no
>(cryptographically secure) way for a brand-new end entity to get

Important for scaling, as you point out.  Better than current method of
sending Email.  Is leap-frogging possible within 3 months?

>an IPKI.  Considering that this work has already been done in PKIX-3,
>and that it is ready to go to Working Group Last Call, it seems to me
>that the proposal given here may be suitable as a (standardized or
>proprietary) protocol in some other context, but not within the stated
>scope of the PKIX Working Group.

Is PKIX-3 (showing my lack of energy to cover it too) codeable?  Are there
any implimentations out there that we can see in action?  When can we
schedule an interoperablity workshop (is one needed?)?

I've got some cars to build.

Thank you all for the on-going education.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Date: Wed, 06 Aug 1997 13:14:20 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RE: PKIX Part 2 - Revised Draft

Note:  the time and date (notarization in previous message) would also need to be attached securely to the signature from a reliable source ("time stamp authority") at time of signing or at time of validation (depending on the role of the individual requiring the non-repudiation).  Archiving these records then at the time stamp authority (central repository) would then enable non-repudiation dispute resolution.

Michael

>>> David P. Kemp <[email-masked]> 08/06/97 10:04AM >>>
> From: Sharon Boeyen <[email-masked]>
> 
> Peter, there's another to handle it as well without any standardization.
> Using distribution points, once all the certs pointing to a certain
> distribution point have passed their expiry date, you can consider that
> distribution point an "old" crl.

Am I missing something?  Isn't there more to non-repudiation than
just archiving old CRLs?

There must be some evidence that the certificates and CRLs were valid
as of the signature date - notarizing them is one method of achieving
this.  But if you have a notarized copy of the old CRL, why do you need
an archived (unprotected) copy?

(A CRL archive might be necessary with a "publish-the-hash-tree-in-a-
newspaper" type scheme, but is that what is being discussed here?)

Date: Wed, 06 Aug 1997 13:10:30 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: RE: PKIX Part 2 - Revised Draft

Note:  the time and date (notarization in previous message) would also need to be attached securely to

>>> David P. Kemp <[email-masked]> 08/06/97 10:04AM >>>
> From: Sharon Boeyen <[email-masked]>
> 
> Peter, there's another to handle it as well without any standardization.
> Using distribution points, once all the certs pointing to a certain
> distribution point have passed their expiry date, you can consider that
> distribution point an "old" crl.

Am I missing something?  Isn't there more to non-repudiation than
just archiving old CRLs?

There must be some evidence that the certificates and CRLs were valid
as of the signature date - notarizing them is one method of achieving
this.  But if you have a notarized copy of the old CRL, why do you need
an archived (unprotected) copy?

(A CRL archive might be necessary with a "publish-the-hash-tree-in-a-
newspaper" type scheme, but is that what is being discussed here?)

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKCS 7 + PKCS 10 Proposal
Date: Wed, 6 Aug 1997 15:00:29 -0400

Hi,

I have a number of major concerns with the proposal that was submitted
to these lists recently, along with several serious, but less critical,
concerns.  I'll only mention the major ones here.

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, July 31, 1997 9:39 PM
>To: 	[email-masked]
>Cc: 	[email-masked]
>Subject: 	PKCS 7 + PKCS 10 Proposal
>
>All--
>
>
>Back in San Jose and again in Memphis the PKIX WG expressed interest in
>considering the use of PKCS 7 and PKCS 10 for PKI administrative
>messaging.  The draft below follows up on this topic from Memphis.
>
>
>The question naturally emerges:  How does this relate to PKIX Part 3,
>considering that PKIX Part 3 accepted changes at the last IETF which
>accomodate PKCS 7 and PKCS 10?
>
>
>(Carlisle, if I've misrepresented your position, I'm sure you'll have no
>reservation whatsoever in correcting the public record!)

Now that I'm back in town, I will take Mike up on his generous offer!
:-)

>Carlisle and I today discussed the issues surrounding this question, in
>the context of the draft below.  We concluded it proposes a reasonable
>approach towards leveraging the installed base of PKCS 7 capabilities. 
>To that end, I propose we consider this framework in Munich and determine
>if and how it should move forward.

This puts a slightly more positive spin on my position than I think is
warranted.  What I actually concluded was that if you wanted to take
advantage of the installed base of PKCS #7 and #10, this approach was
probably about the best you could do.  However, it has significant
disadvantages and security problems and (at best) solves a limited
subset of the required functionality for limited, very specific,
environments.

>The authors also feel that this work merits attention within the IPSEC
>Working Group, hence it cross-posting to that list.
>
>
>
>Carlisle had the following specific observations:

Let me re-word that slightly:  "Carlisle had the following specific
reservations with respect to the usefulness of this proposed protocol:"

>1.  The draft continues to promote the notion that one need only have a
>single key.

The draft does not simply promote the notion that one need only have a
single key.  Rather, it fundamentally relies on that notion.  [See, for
example, the first sentence of Section 5.1.1.2 which says, "Because the
response is encrypted with the user's public key....  This is the
response to the certification request, which (being a PKCS #10 request)
was signed with the user's private key.  One key pair for both signing
and encryption.  Didn't I hear a (loud) call from the group recently
saying that DSA should be mandatory for the PKIX protocols and that RSA
should be optional?]

The impression I get from many, many quarters is that, collectively, we
have (or should have) put this issue to rest by now.  Of course there
are a number of systems out there that operate as single-key systems for
historical and backward-compatibility reasons.  However, there is no
valid argument for fundamentally building in a single-key assumption in
new protocols that we propose.  I suspect there will be no shortage of
people who oppose this if we try to promote such a limited and flawed
design.

>2.  It provides no means to certify a D-H key.  Recognizing that the WG
>has received a proposal to do so using PKCS 10 constructs, there still
>remains a problem of coordinating parameters between the client and the
>CA.

It is not a "problem of coordinating parameters".  It is that trying to
force-fit D-H certification into PKCS #10 requires two things:  (a) it
requires that the CA has a D-H certificate for this purpose; and (b) it
requires that the end entity be content to use the specific parameters
in the CA's D-H certificate for its own D-H key pair.  Condition (a)
seems like an unnecessary extra burden to place on CAs, but this is not
a serious problem.  Condition (b), on the other hand, seems far too
limiting for a general solution.  If an end entity wants to create its
own key pair it should be free to create it in any way it likes, for
whatever purposes it likes, and get the resulting public key certified
(subject to policy, etc.).

>3.  It does not adequately address the subscriber bootstrapping 
>problem.

"Does not adequately address" is a little understated.  It does not
address this problem at all.  In other words, there is no
(cryptographically secure) way for a brand-new end entity to get
initialized and begin functioning in the system.  I don't want to sound
extremist here, but this is not a small shortcoming.  What you end up
with in this proposal is an infrastructure full of certificates that you
can't trust.  [Note that the "most secure", manual mode, where a phone
call is made and hashes are read out, is prone to user error.  More
significantly, it does not scale:  requiring CA administrators to
contact end users by telephone when organizations span multiple
continents, time zones, and languages will prove challenging and will
almost certainly lead to (at least the occasional) use of
unauthenticated certificates.  Since unauthenticated certificates cannot
be distinguished from properly-authenticated certificates, you end up in
a situation where you can't really trust any certificate.]

>4.  More generally, the current draft clearly falls short of addressing
>the entire set of capabilities provided by Part 3.

This point is worded exactly as I would wish, except that I might have
started with "More importantly, ..."

>For each of these there exists a reasonable counter position.  It's
>tempting to rebut each, but in the interest of brevity I will address
>only the last point, leaving the others to the list and Munich.

I would be interested in seeing the rebuttals, but I am not optimistic
that they can be made to be convincing with respect to the actual needs
for general certificate management protocols.

>To the last point, I would observe that the draft is intended to address
>only the most essential elements of a PKI service, with the thought in
>mind that additional work would be needed to expand upon these basic
>services.

In other words, the plan seems to be to essentially re-do everything
that has already been done in the past 1-1/2 to 2 years with PKIX-3.
Mike has repeatedly said to me that a lot of effort and thinking has
gone into PKIX-3 to construct a secure, general set of protocols for
certificate management.  Does it make sense to do this all again for
this new proposal (and wait another 1-1/2 to 2 years to get something
that is strong enough and general enough to be useful)?  My personal
feeling is, "No".

Ultimately, what PKIX is all about is the definition and standardization
of a Public-Key Infrastructure for the Internet.  The proposal given
here cannot (and does not) claim to build such an infrastructure.  It
may provide *some* of the necessary functionality for *some*
environments (although I still worry about not being able to securely
initialize entities), but this limited focus is clearly inadequate for
an IPKI.  Considering that this work has already been done in PKIX-3,
and that it is ready to go to Working Group Last Call, it seems to me
that the proposal given here may be suitable as a (standardized or
proprietary) protocol in some other context, but not within the stated
scope of the PKIX Working Group.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Wed, 06 Aug 1997 10:35:08 +0100
From: Peter Williams <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX Part 2 - Revised Draft

David P. Kemp wrote:

> > From: Sharon Boeyen <[email-masked]>
> >
> > Peter, there's another to handle it as well without any
> standardization.
> > Using distribution points, once all the certs pointing to a certain
> > distribution point have passed their expiry date, you can consider
> that
> > distribution point an "old" crl.
>
> Am I missing something?  Isn't there more to non-repudiation than
> just archiving old CRLs?
>
> There must be some evidence that the certificates and CRLs were valid
> as of the signature date - notarizing them is one method of achieving
> this.  But if you have a notarized copy of the old CRL, why do you
> need
> an archived (unprotected) copy?
>
> (A CRL archive might be necessary with a "publish-the-hash-tree-in-a-
> newspaper" type scheme, but is that what is being discussed here?)

The purpose of accessing the archive of older CRLs was not recently
discussed,
I fear. Lets take a look at the technical infrastructure possibilities,
and the
some of the technical risks due to potentially  improper or inadequate
administrative
procedure.

Assuming your scenario, assuming an e-notary is collecting together all
the data
necessary for future revalidation by a court of a client's "current
message authentication
status", and said notary is notarizing 100 messages a second, it may be
sensible to have
the "old" CRLd contained in the notary output stream represented as a
pointers, rather than
as explicit values; especially if the CRL(s) (including next-period
CRLs) are large.

In my comment, I made indirect note that, in traditional designs, the
archive of CRLs
on an 'OldCRL' attributes makes it straight-forward to safely replicate
and distribute,
under bilateral contract, that entire attribute in many locations (due
to the wonders of
X.500's distribution/replication service, and similar schemes in other
directory products).

Whilst a competent notary service would certain wish to have the archive
datasource
not only  be *available* locally (via a Directory Access point), should
one use CRL
pointers in the notarised message stream, but also it would surely wish
the data to be safely *stored* locally also. (Who knows if the client's
CA or
directory/repository provider will actually still be around...in 10
years time). Part of the
competence of the notary is that, in availability terms, the firm is
wholly independent of
CAs, Directory providers, repository maintainers, etc except in regard
to its *own*
(periodically-updated) operational status of its (versus its client's
notarised) signatures
on the notarised-message stream..

Such a scenario surely calls for secured distribution of the archive,
not centralisation.

A careful user of a notary service for significant assets will in any
case surely have
the message notarised by several parties, to minimise impact of failures
of any
centeralised system element, or infrastructure and record failure at
notary sites, etc
all of which the user inherenly will need to rely upon at a future date.
Jurisidictional
and national issues may also require multiple notarizations,
particularly for multi-national
companies, or international trading enteprises.

Its been my experience that you must check notarial & professional
conduct just as much
as you check for yourselves, and guard against, misconduct by
non-professionals.
It was only through my insistence of multi-party, failsafe confirmation
procedures,
my own house title and grant deeds for mortage were not screwed up, for
example,
in a notarial procedure in the paper world. As my single most important
asset,
I just could not afford to let "professional salesmanship" cloud my
judgement
as to the risks of their error; suing notaries after the fact, in a
protracted
liability claim, under profesional or insurance regulations, doesnt do
anything for my
house title's inadequacy such that I cannot sell, meantime! So, surely,
the e-notary world
will need to be fault-tolerant; digital signatures make this much easier
than with
paper notarizations/certifications, of course, and should balance
evidence value more
to the user of such a service during (inevitable) disputes about message
status validity.

From: <[email-masked]>
Date: Wed, 06 Aug 1997 10:15:36 -0600
To: [email-masked]
Subject: URL for PKCS 7&10 Draft

All--

Due to the kind efforts of Rodney Thayer, the post-deadline draft I posted
regarding PKCS 7&10 is available at:

ftp://research.ftp.com/pub/ipsec/post_munich_deadline/draft-myers-pkix.txt

--Mike

Date: Wed, 6 Aug 1997 12:04:53 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: PKIX Part 2 - Revised Draft

> From: Sharon Boeyen <[email-masked]>
> 
> Peter, there's another to handle it as well without any standardization.
> Using distribution points, once all the certs pointing to a certain
> distribution point have passed their expiry date, you can consider that
> distribution point an "old" crl.

Am I missing something?  Isn't there more to non-repudiation than
just archiving old CRLs?

There must be some evidence that the certificates and CRLs were valid
as of the signature date - notarizing them is one method of achieving
this.  But if you have a notarized copy of the old CRL, why do you need
an archived (unprotected) copy?

(A CRL archive might be necessary with a "publish-the-hash-tree-in-a-
newspaper" type scheme, but is that what is being discussed here?)

From: <[email-masked]>
Date: Wed, 06 Aug 1997 07:42:38 -0600
To: [email-masked]
Subject: Re: Extended Key Usage Extension

All--

Due to the kind efforts of Rodney Thayer, the post-deadline draft I posted
regarding PKCS 7&10 is available at:

ftp://research.ftp.com/pub/ipsec/post_munich_deadline/draft-myers-pkix.txt

--Mike

Date: Wed, 06 Aug 1997 15:59:23 +0200
From: Wolfgang Schneider <[email-masked]>
Organization: GMD
To: [email-masked]
Subject: Padding in the context of signature algorithms

I came accross the following detail: The part 1 draft defines
{md2,md5,sha-1}WithRSAEncryption as signature algorithms in
conjunction with RSA, for example. In case of md2 and md5,
reference is made to PKCS#1. PKCS#1 describes in detail how the
RSA-input is to be padded to the length of the RSA modulus. 
In case of sha-1, reference is made to OIW. I can't remember 
that anything is said there about padding. Shouldn't this be 
addressed somewhere? 

The reason I ask is that people here are going to specify a 
signature producing smartcard (in the context of the German 
digital signature law) where they require that the smartcard
itself produces a random padding in order to obtain unique
signatures. Such a smartcard would obviously not be able to 
generate a PKCS#1-formatted signature. But I'm not quite sure 
whether it could be used for other algorithms in the context
of PKIX. I would like to argue with these people whether or not
such a requirement would be in contradiction to current internet
practises and specifications, but I can't draw the arguments from 
the current specs. In general, I think that any specification
of use of algorithms in PKIX should have the same level of detail 
as PKCS#1.

I also lost the track to the OIW activities, and no reference 
is given in the draft. The latest I have is the stable agreement 
from 06-95. Does anyone know where I can find the latest OIW 
specs?

Regards

Wolfgang Schneider

Date: Tue, 05 Aug 1997 15:33:55 +0100
From: Peter Williams <[email-masked]>
To: Sharon Boeyen <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: PKIX Part 2 - Revised Draft

Sharon,

In regard to the edits made to section 3:

"3. Hypertext Transfer Protocol and File Transfer Protocol

Some CAs mandate the use of on-line validation services, while
others distribute CRLs to allow certificate users to perform
certificate validation themselves.  In general, CAs make CRLs
available to certificate users by posting them in the Directory.
The Directory is also the normal distribution mechanism for
certificates.  However, Directory Services are not available in
many parts of the Internet today. The Hypertext Transfer Protocol
(HTTP) defined in RFC 2068 and the File Transfer Protocol (FTP)
defined in RFC 959,  offer alternate methods for certificate and
CRL distribution.

Within certificate extensions and CRL extensions, URI form of
GeneralName is used to specify the location where issuer
certificates and CRL may be obtained.  For instance, a URI
identifying the subject of a certificate may be carried in
subjectAltName certificate extension. An IA5String describes the
use of anonymous, or authenticated HTTP or FTP to fetch certificate
or CRL information.
For example:

   http://www.netcom.com/sp/spyrus/housley.cer
   http://www.your.org/pki/id48.cer
   http://www.your.org/pki/id48.no42.crl
   ftp://ftp.netcom.com/sp/spyrus/housley.cer
   ftp://ftp.your.org/pki/id48.cer
   ftp://ftp.your.org/pki/id48.no42.crl

Internet users may publish the URI reference to a file that
contains their certificate on their business card.  This practice
is useful when there is no Directory entry for that user. HTTP and
FTP are widely deployed, and anonymous HTTP and FTP are
accommodated by many firewalls.  Thus, HTTP and FTP are attractive

alternatives to Directory access protocols for certificate and CRL
distribution.

In the case of FTP, for convenience, the names of files that
contain certificates should have a suffix of ".cer".  Each .cer
file contains exactly one certificate, encoded in DER format.
Likewise, the names of files that contain CRLs should have a suffix
of ".crl". Each .crl file contains exactly one CRL, encoded in DER
format.

**(Note - still outstanding for the HTTP case is the definition of
specific content type label (mime type) with content in specific
syntax.)"

I would like to comment on the last paragraph. I suggest the
following language:-

"In the case of HTTP, for convenience, the HTTP-response should
provide a MIME application/octet-string header when serving
file resources. The MIME type descriptor shall be accompanied
by a mandatory "name" parameter whose value is the name of the
retrieved file, with ".cer" or ".crl" suffix.

Should the HTTP URI refer to a non file resource which is
conventionally denoted by a particular MIME type (e.g. a PKCS7
certs-only
object used in popular SSL-capable browsers is
often denoted by "application/x-pkcs7-user-cert") then
the customary MIME headers for that resource shall be returned in
the HTTP-response in place of  application/octet-string. (see
Appendix A for  examples)"

Id like to suggest this is a short, minimalist  summary of existing
submissions
made by others to the list. One can tweak my language at will, of
course.

The specification is compatible with ftp URIs, where required, enables
current
practice for S/MIME and SSL browsers/servers, and is flexible to allow
new
MIME types to be defined if needed to extend the http mechanism for
new varieties of simple URI-based lookup over time, without need
for PKIX-2 change..

(http://digitalid.verisign.com/query.htm is an example provision of the
basic validity of this http approach for a variety
of commercial download formats, including the CRL file-centric approach,
if
we are in doubt of its implementability. Downgrading this
*interactive-query*
service to the URI *lookup* model intended by section 3 for use
in address books or vcard attachements is, of course, a simple task)

I think given the evidence, such a flexible http service will be highly
valued
by many products using the simpler, but wholly functional, end of the
PKIX
infrastructure.

Peter.

Date: Tue, 05 Aug 1997 18:23:36 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-part1-05.txt

Folks,

As far as I can tell, the file loaded 8/01 is still the one on the web site.
Please continue to retrieve from
	http://csrc.nist.gov/pki/temp
until further notice.

Thanks,

Tim Polk

At 03:25 PM 8/5/97 -0400, [email-masked] wrote:
>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 Public Key Infrastructure   Part I:  X.509 Certificate
and CRL Profile
>	Author(s)	: D. Solo, R. Housley, W. Ford, T. Polk
>	Filename	: draft-ietf-pkix-ipki-part1-05.txt
>	Pages		: 107
>	Date		: 1997-08-01
>	
>This is the fifth draft of the Internet Public Key Infrastructure
>X.509 Certificate and CRL Profile.  This draft is a complete
>specification.  This text adds a new ISO-defined certificate
>extension, extended key usage, and clarifies the semantics of the
>validity fields. Other modifications and enhancements which appear in
>this draft include a reduced set of private extensions, conformance
>requirements for CAs and clients, and new examples of certificates
>and a CRL. This draft also defines object identifiers for use with
>the extended key usage certificate extension.  Please send comments
>on this document to the [email-masked] mail list.
>
>Internet-Drafts are available by anonymous FTP.  Login wih the username
>"anonymous" and a password of your e-mail address.  After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-pkix-ipki-part1-05.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part1-05.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nis.garr.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ds.internic.net
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[email-masked].  In the body type:
>	"FILE /internet-drafts/draft-ietf-pkix-ipki-part1-05.txt".
>	
>NOTE:	The mail server at ds.internic.net 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.
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-ipki-part1-05.txt

From: Sharon Boeyen <[email-masked]>
To: "'Wolfgang Schneider'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKIX Part 2 - Revised Draft
Date: Tue, 5 Aug 1997 18:07:41 -0400

Peter, there's another to handle it as well without any standardization.
Using distribution points, once all the certs pointing to a certain
distribution point have passed their expiry date, you can consider that
distribution point an "old" crl. It can remain in its place in the
directory and the only change you'd likely want to make is to change the
schedule on which that dist point got updated, so as not to continually
send the same info to the directory. Perhaps scheduling updates on an
annual basis may be useful or even less frequent than that. Comments?

------------------
NOTE: WE'VE MOVED 

Sharon Boeyen                  
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario Canada K1V 1A7

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	August 5, 1997 9:46 AM
>To: 	Sharon Boeyen; Wolfgang Schneider
>Cc: 	[email-masked]'
>Subject: 	Re: PKIX Part 2 - Revised Draft
>
>Wolfgang,
>
>If I remember work GMD lead, in partnership with other
>multi-vendor, international folk some 5 years ago now, did GMD not
>mount  an X.509 and directory pilot in which expiring CRLs were
>moved to a "oldCRL" attribute in the directory entry once they
>were expired?
>
>In those days, when we were all doing opaque-cert and
>opaque-CRL handling under the 1988 protocols for X.500,
>there was little a UA could do expect download the entire
>multi-valued oldCRL attribute, and search it locally to obtain
>the one, of otentially many, it wanted. These days, with the newer
>matchingCriteria and rules specifically for CRLs, it would be
>a simple directory function to give search-based access to a
>historical CRL archive represented by in one or more
>CRL-history entries appended off the main entry for an
>entity acting as a CA. Perhaps, should years of archived
>CRLs be eventually created, conventional yellow pages listing
>entries can be made in the directory enabling fast searching/indexing
>of the data according to various listing criteria.
>
>Im not sure this is in any need of formal standardization (folks just
>go  off and do their standard directories...) other than perhaps the
>name and type of the attribute, and a PKIX-2 note in the general
>section that such modes of use of "the directory" are "expected and
>conventional." As with most directory attributes, the values can
>be replicated and distributed as required across multiple access
>points.
>
>Do you have the registration of that oldCRL attribute handy?
>
>Perhaps we could just use that one?
>
>>
>>  3 Historical revocation status - the requirement for this was
>> questioned
>> although
>>    it seems to be agreed that there is a valid requirement for
>> maintaining
>>    revocation information long after expiration.
>
>

Date: Tue, 05 Aug 1997 14:46:00 +0100
From: Peter Williams <[email-masked]>
To: Sharon Boeyen <[email-masked]>, Wolfgang Schneider <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: PKIX Part 2 - Revised Draft

Wolfgang,

If I remember work GMD lead, in partnership with other
multi-vendor, international folk some 5 years ago now, did GMD not
mount  an X.509 and directory pilot in which expiring CRLs were
moved to a "oldCRL" attribute in the directory entry once they
were expired?

In those days, when we were all doing opaque-cert and
opaque-CRL handling under the 1988 protocols for X.500,
there was little a UA could do expect download the entire
multi-valued oldCRL attribute, and search it locally to obtain
the one, of otentially many, it wanted. These days, with the newer
matchingCriteria and rules specifically for CRLs, it would be
a simple directory function to give search-based access to a
historical CRL archive represented by in one or more
CRL-history entries appended off the main entry for an
entity acting as a CA. Perhaps, should years of archived
CRLs be eventually created, conventional yellow pages listing
entries can be made in the directory enabling fast searching/indexing
of the data according to various listing criteria.

Im not sure this is in any need of formal standardization (folks just
go  off and do their standard directories...) other than perhaps the
name and type of the attribute, and a PKIX-2 note in the general
section that such modes of use of "the directory" are "expected and
conventional." As with most directory attributes, the values can
be replicated and distributed as required across multiple access
points.

Do you have the registration of that oldCRL attribute handy?

Perhaps we could just use that one?

>
>  3 Historical revocation status - the requirement for this was
> questioned
> although
>    it seems to be agreed that there is a valid requirement for
> maintaining
>    revocation information long after expiration.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-05.txt
Date: Tue, 05 Aug 1997 15:25:45 -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 Public Key Infrastructure   Part I:  X.509 Certificate and CRL Profile
	Author(s)	: D. Solo, R. Housley, W. Ford, T. Polk
	Filename	: draft-ietf-pkix-ipki-part1-05.txt
	Pages		: 107
	Date		: 1997-08-01
	
This is the fifth draft of the Internet Public Key Infrastructure
X.509 Certificate and CRL Profile.  This draft is a complete
specification.  This text adds a new ISO-defined certificate
extension, extended key usage, and clarifies the semantics of the
validity fields. Other modifications and enhancements which appear in
this draft include a reduced set of private extensions, conformance
requirements for CAs and clients, and new examples of certificates
and a CRL. This draft also defines object identifiers for use with
the extended key usage certificate extension.  Please send comments
on this document to the [email-masked] mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-part1-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part1-05.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-part1-05.txt".
	
NOTE:	The mail server at ds.internic.net 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-ipki-part1-05.txt

--OtherAccess
Content-Type:	Message/External-body;
	name="draft-ietf-pkix-ipki-part1-05.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"
	
Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: PKIX Part 2 - Revised Draft
Date: Tue, 5 Aug 1997 15:40:45 -0400

I was following up this morning to find out why the revised part 2
wasn't on the server yet, since I submitted it  before the deadline. I
discovered the reason and apologize to all of you for my mistake.
Instead of sending to "@ietf.org" I keyed in "@iesg.org" and since I
received no non-delivery notice - I had assumed it was properly
submitted. I've resubmitted today - hoping that they'll accept it, but
in the meantime, I've posted the revised draft on our web site at :

http://www.entrust.com/downloads/pkix-2.txt

An overview of the major 
changes since the first draft follows:

- Addition of the modify LDAP operations for "putting" certificate and
crl info in the 
  repository.
- Addition of text in 4.1.2 re caching of signed responses in OCSP
- Addition of text in 3 re specific contents of .cer and .crl files
- Some rewording of 2.4 indicating some access control requirements for
the 
  LDAP write operations 
- Added the missing text on encoding octet strings for certs & crls in
LDAP
- Changes to section 3 adding http along with the ftp mechanism
- Addition of an appendix with the email proposal submitted by Trevor
Freeman
- Changes to section 4 allowing an OCSP server to field requests on
behalf 
  of a CA
- Changes to part 4 to allow a full certificate to be included in the
request
- Some enhancements to the response syntax and text strings in part 4
- Addition of a trasnaction_id to OCSP query and response syntaxes

Here's a snapshot of some of the issues that have been raised by various
parties and where final resolution is still pending, at least in my mind
(if I've forgotten any, please let me know and I'll pull together a
comprehensive list for the meeting):

1 OCSP and caching - although it was agreed in Memphis to add some text
to    4.1.2, some have questioned this since the meeting so it probably
can use       some more discussion.

2  OCSP and path validation - The relationship between PKIX Part 1
discussion of
    and what needs to be said in PKIX Part 2 OCSP on this issue is still
a bit up 
    in the air. If I can paraphrase some of the comments I've received
on this, 
    concerns and questions are related to how the model for path
validation works 
    in an OCSP environment compared to others, where the crls from all
relevant
    CAs are provided to the user. 

3 Historical revocation status - the requirement for this was questioned
although 
   it seems to be agreed that there is a valid requirement for
maintaining 
   revocation information long after expiration.  The issue of crl size
bounding was 
   mentioned as a problem if you don't set a finite period of time after
the expiry 
   date of a cert by which time it should be removed from a crl.
However, if crl 
   distribution points are used and the grouping of certs assigned to
dist pts is 
   aligned with their expiry date, this becomes a non issue. Further
discussion is
   required on this point. I would also note that a defect report was
raised during 
   the X.509 defect meeting a few weeks ago on the topic of leaving
certs on 
   crls past their revocation date. Hopefully, these documents will be
available 
   soon.

4 Signed LDAP operations - This topic has been raised on a number of
occasions
   and discussion of TLS/SSL versus LDAP security has probably taken us
to a 
   point where we want to look at adding digital signatures to LDAP
operations (at
   least the write operations). If the requirements are agreed in PKIX
group we can
   probably punt this to the asid group where LDAP work is done.

5 E-mail mechanism - as agreed back in April/May and after much debate
on 
   the list, Trevor Freeman submitted the email proposal for inclusion
in PKIX 2. 
   Since the group of authors on this I-D didn't get enough discussion
before 
   the document was to be submitted I elected to add the submission as
an 
   Appendix. After more people have a chance to review it we can decide 
   whether to integrate it, modify it, create a new document etc.

6  Too many mechanisms - we now have LDAP, FTP, HTTP, OCSP and email. It
   was mentioned that with the addition of http, perhaps we can drop
FTP. 
   Comments? 

7 Split the document - it is agreed, at least among the authors, that
the LDAP 
  section is stable and mature. Also, the HTTP (and FTP) are very simple
  sections. There is not agreement among the authors that OCSP is mature
  and solid. The email mechanism is currently an appendix and needs
further 
  review and discussion before adding it to the mainstream of the
document.

  At Memphis we agreed to keep things together as a single document at
  least until the next meeting at which time we should rethink that
decision 
  and either confirm it or change it. This needs to be discussed in
Munich. 

-------------------
Once again, I'm sorry for screwing up on the I-D submission and if
anyone has
trouble getting this from our web site, let me know and I'll email it. 

Sharon

------------------
NOTE: WE'VE MOVED 

Sharon Boeyen                  
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario Canada K1V 1A7

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

From: Carlisle Adams <[email-masked]>
To: "'Warwick Ford'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKIX Part 5
Date: Tue, 5 Aug 1997 13:49:29 -0400

Hi Warwick (and any others who may be experiencing the same problem),

>----------
>From: 	Warwick Ford[SMTP:[email-masked]]
>Sent: 	Tuesday, August 05, 1997 4:37 PM
>To: 	Carlisle Adams
>Subject: 	PKIX Part 5
>
>Carlisle:
>
>I can't fetch the Part V I-D from its link on ietf.org.  Is the link
>screwed up or the file?  What is the correct URL?

It looks like the link is bad.  The URL 

   ftp://ietf.org/internet-drafts/draft-ietf-pkix-ipki5tsp-00.txt

seems to work.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Tue, 05 Aug 1997 13:23:58 -0400
To: Wolfgang Schneider <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-kea-00.txt
Cc: [email-masked], [email-masked]

At 01:05 PM 8/5/97 +0200, Wolfgang Schneider wrote:
>This text obviously has been produced with a wrong line wrap option.
>It is fairly mutilated. The same is true for other new PKIX drafts
>as well (e.g. part 1).
>
>Regards
>
>Wolfgang Schneider

Wolfgang,

I inadvertently damaged the formatting when I re-submitted the drafts late
Friday night.  (My original submission had a few lines of length > 72.  The
cure was worse than the original problem, I'm afraid.)

I resubmitted the drafts again, but they haven't posted them yet.

In the meantime, the corrected drafts are available from

http://csrc.nist.gov/pki/temp

with the file ipki.zip containing both drafts.  (The unzipped files are
also available with the usual names.)

Hope that helps.

Tim Polk

P.S.  This seems bizarre to me, but I don't seem to have anonymous ftp
service that I can use here at NIST.  If someone could download the files
and make them available for anonymous ftp, I would appreciate it.

Date: Tue, 05 Aug 1997 13:49:37 UT
From: Michael Leahy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: How to use Cross Certificates

Hi=20

I'm trying to figure out how an end-user actually uses Cross Certificates=
.=20

- Is the basic premise that If I have a CA-Certificate from whoever and I=
 receive your user certificate (issued by a different CA) I will search i=
n our directory (X500 or whatever) for your CA Certificate AND if I can n=
ot find the CA Cert then find a cross-certificate issued by our CA to you=
r CA to find the public key so that I can verify your certificate and tru=
st the signature ? Is this correct ?

I would appreciate hearing how other products deal/use Cross Certificates=
 in there end-user software (I would appreciate a a step wise description=
) ?

Regards
Michael Leahy
ISOCOR

Also I haven't found any good explanation (I have found very terse statem=
ents) on the various issues on Cross Certificates in any book so if someb=
ody can suggest some futher reading - let me know

Date: Tue, 05 Aug 1997 13:05:49 +0200
From: Wolfgang Schneider <[email-masked]>
Organization: GMD
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-kea-00.txt

This text obviously has been produced with a wrong line wrap option.
It is fairly mutilated. The same is true for other new PKIX drafts
as well (e.g. part 1).

Regards

Wolfgang Schneider

[email-masked] wrote:
> 
>         Title           : Representation of Key Exchange
>                           Algorithm (KEA) Keys in Internet
>                           Public Key Infrastructure Certificates
>         Author(s)       : R. Housley, W. Polk
>         Filename        : draft-ietf-pkix-ipki-kea-00.txt
>         Pages           : 5
>         Date            : 01-Aug-97
> 
> This is the initial draft of a profile for specification of Key
> Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure
> X.509 certificates. Please send comments on this document to the
> [email-masked] mail list.
> 
> Internet-Drafts are available by anonymous FTP.  Login wih the
> username
> "anonymous" and a password of your e-mail address.  After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-pkix-ipki-kea-00.txt".
> A URL for the Internet-Draft is:
> ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-kea-00.txt
> 
> Internet-Drafts directories are located at:
> 
>         Africa: ftp.is.co.za
> 
>         Europe: ftp.nordu.net
>                 ftp.nis.garr.it
> 
>         Pacific Rim: munnari.oz.au
> 
>         US East Coast: ds.internic.net
> 
>         US West Coast: ftp.isi.edu
> 
> Internet-Drafts are also available by mail.
> 
> Send a message to:      [email-masked].  In the body type:
>         "FILE /internet-drafts/draft-ietf-pkix-ipki-kea-00.txt".
> 
> NOTE:   The mail server at ds.internic.net 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.
> 
>     ---------------------------------------------------------------
> 
>                       Access-Type: anon-ftp
>    Link to Document          Site: ds.internic.net
>                         Directory: internet-drafts
>                              Name: draft-ietf-pkix-ipki-kea-00.txt

Date: Mon, 04 Aug 1997 13:44:18 -0600
From: Robert Jueneman <[email-masked]>
To: [email-masked]
Subject: Forged e-mail from sheriff?

I recently heard of a case where someone apparently forged an e-mail message
from a sheriff, more or less to the effect that there were no charges
pending against a particular suspect, so the arresting officer let the man
go.

This would be an excellent illustration for an article I'm writing, but I
can't find any specific citation or record.  Can anyone help me out? I would
need the newspaper or other article, date, and page number.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Support Division
122 East 1700 South
Provo, UT 84606
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-kea-00.txt
Date: Sat, 02 Aug 1997 11:39:30 -0400

--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		: Representation of Key Exchange 
                          Algorithm (KEA) Keys in Internet 
                          Public Key Infrastructure Certificates
	Author(s)	: R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-kea-00.txt
	Pages		: 5
	Date		: 01-Aug-97
	
This is the initial draft of a profile for specification of Key 
Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure
X.509 certificates. Please send comments on this document to the
[email-masked] mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-kea-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-kea-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-kea-00.txt".
	
NOTE:	The mail server at ds.internic.net 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-ipki-kea-00.txt

--OtherAccess
Content-Type:	Message/External-body;
	name="draft-ietf-pkix-ipki-kea-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"
	
Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-kea-00.txt
Date: Sat, 02 Aug 1997 11:39:30 -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		: Representation of Key Exchange 
                          Algorithm (KEA) Keys in Internet 
                          Public Key Infrastructure Certificates
	Author(s)	: R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-kea-00.txt
	Pages		: 5
	Date		: 01-Aug-97
	
This is the initial draft of a profile for specification of Key 
Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure
X.509 certificates. Please send comments on this document to the
[email-masked] mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-kea-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-kea-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-kea-00.txt".
	
NOTE:	The mail server at ds.internic.net 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-ipki-kea-00.txt

--OtherAccess
Content-Type:	Message/External-body;
	name="draft-ietf-pkix-ipki-kea-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"
	
Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 1 Aug 1997 11:31:42 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Combo DSS/ElGamal keys

> From: Carlisle Adams <[email-masked]>
>
> Maybe I haven't seen the full details of this proposal, but what you've
> written here doesn't make sense to me.  If the DH public value is in a
> *certificate*, why would another public value (in this case a DSS value)
> _in_the_same_certificate_ be useful for authenticating the DH exchange?
> 
> In other words, if you trust the certificate to tie the DSS public value
> to an entity, why can you not trust the certificate to tie the DH public
> value to an entity?  What further authentication assurance does the DSS
> key (in the same certificate as the DH value) have?

One situation where this is needed is in email, where you have only one
message to establish the key, not a two or three message interactive
handshake.

"Paul's book :-)" (the Handbook of Applied Cryptograpy) describes El Gamal
key agreement in section 12.6 and calls it "half-certified Diffie-Hellman".
In it, the recipient is authenticated to the originator by the D-H
certificate, but if the recipient wants to authenticate the originator,
some other mechanism (such as a signature certificate) is needed.
So 1-message protocols which use CAs to certify key establishment keys
might find a DH-with-DSS certificate (to be used only for an atomic key
establishment algorithm) to be appropriate.

But specifically for PGP, if an issuer certifies the user's DSS key and
the user signs his own DH public key, then the issue of multiple-key
certificates does not even come up - the DH and DSS keys are signed by
different entities, even if they do happen to be aggregated together in
some larger certificate-containing structure.

Date: Fri, 01 Aug 1997 09:43:40 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: PKIX-1 new draft/Last Call?
Cc: Frank Acker <[email-masked]>

Apparently there were a lot of last-minute submissions.  Neither the PKIX-1
or KEA drafts have made it onto the ietf site yet.  For the interim, I have
put copies on our web site.

Part 1:

http://csrc.nist.gov/pki/temp/draft-ietf-pkix-ipki-part1-05.txt

KEA:
http://csrc.nist.gov/pki/temp/draft-ietf-pkix-ipki-kea-00.txt

or both in one zip file:
http://csrc.nist.gov/pki/temp/ipki.zip

The zip file is only 59K; the uncompressed part1 is 233K, so I recommend
you retrieve the zip file.

Unfortunately, the web site doesn't seem to support ftp access. I am
looking for an anonymous ftp site here, and will send another message when
the files are available with that protocol.

Thanks,

Tim Polk

At 04:35 PM 7/30/97 -0700, you wrote:
>At 04:26 PM 7/30/97 -0400, you wrote:
>>
>>I have submitted a new draft of PKIX Part 1.  I will attempt to summarize
>>the changes in the document.
>>
>
>Tim:
>
>Where can I get a copy for review?
>
>Regards,
>
>Frank Acker
>[email-masked]
>
>

Date: 1 Aug 97 06:51:05 -0500
From: "Harrington Ed" <[email-masked]>
Subject: unsubscribe
To: [email-masked]

unsubscribe

Date: Fri, 1 Aug 1997 00:00:04 -0700
From: Operator - SUNTAN <[email-masked]>
To: [email-masked], [email-masked]
Subject: Monthly reminder (IETF-PKIX list)

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 

                Warwick Ford at [email-masked]  
                             or 
                Jean Pawluk at [email-masked].

If you have any questions about this list service in general, you
can contact [email-masked].