Subject: Re: Certificate Suspension
From: Stephen Kent <[email-masked]>
To: Mike Smith <[email-masked]>
Cc: [email-masked]
Date: Tue, 30 Sep 1997 21:20:46 -0400

Mike,

	A good CA revocation policy can specify an authentication mechanism
used to verify that a revocation request is genuine.  The examples you cite
don't exhibit such a mechanism.  I hate to see this justification for the
suspension facility, but I'm beyond complaining about this CRL feature.

Steve

Date: Tue, 30 Sep 1997 17:05:55 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: VeriSign
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

<html><HTML>
Carlisle,:
<BR>Carlisle,
<BR>&nbsp;

<P>OK. I am going away from this exchange with two beliefs:

<P>(a) no Appendix B message (set) specified needs to be necessarily
<BR>sent, or handled if received; there is no state or sequence of messages
(sets) implied
<BR>to be conforming. PKIInformation need not even be sent, and can
<BR>be ignored in any case by an EE.

<P>(b) If an EE&nbsp; implementation wants to ignore PKIInfo, it they can;
if they
<BR>want to ignore InitReq they can. They can deem information and
<BR>initialization to have occured by other means, and go straight to cr
<BR>whose protection mechanism may use signing (MSG_SIG_ALG ).

<P>Just set me right if they are wrong.

<P>--------

<P>On other matters, you may want to clean up fast:-
<BR>&nbsp;
<UL>&lt;&lt;Later versions of this document may extend the above to include
<BR>profiles for the operations listed below (along with other operations,
<BR>if desired).>></UL>

<P>the oids for:-
<BR>&nbsp;
<UL>- Example InfoTypeAndValue contents include, but are not limited to:
<BR>&nbsp; --&nbsp;&nbsp; { CAProtEncCert&nbsp;&nbsp;&nbsp; = { xx }, Certificate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
}
<BR>&nbsp; --&nbsp;&nbsp; { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier
}
<BR>&nbsp; --&nbsp;&nbsp; { EncKeyPairTypes&nbsp; = { xx }, SEQUENCE OF
AlgorithmIdentifier }
<BR>&nbsp; --&nbsp;&nbsp; { PreferredSymmAlg = { xx }, AlgorithmIdentifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
}
<BR>&nbsp; --&nbsp;&nbsp; { CAKeyUpdateInfo&nbsp; = { xx }, CAKeyUpdAnnContent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
}</UL>
&nbsp; --&nbsp;&nbsp; { CurrentCRL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= { xx }, CertificateList

<P>and
<BR>&nbsp;
<UL>SinglePubInfo ::= SEQUENCE {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pubMethod&nbsp;&nbsp;&nbsp;
INTEGER {
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dontCare&nbsp;&nbsp;&nbsp;
(0),&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x500&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1),&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; web&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(2)</UL>

<P>shoud include ldap
<BR>&nbsp;
<UL>B1. General Rules for interpretation of these profiles.
<BR>&nbsp;1.Where OPTIONAL or DEFAULT fields are not mentioned in individual
<BR>&nbsp;&nbsp; profiles, they should be absent from the relevant message.
<BR>&nbsp;&nbsp; Mandatory fields are not mentioned if they have an obvious
value
<BR>&nbsp;&nbsp; (e.g., pvno).
<BR>&nbsp;</UL>
State whether a receiver doing type checking has&nbsp; reasonable basis
for rejecting
<BR>an inbound msg which has a present, not-mentioned-by-profile OPTIONAL
or DEFAULT
<BR>field.
<BR>&nbsp;

<P>You may want to revisit, and ensure its generically compatible with
the actual
<BR>profiles for the various operations.
<UL>

<P>&nbsp;9.All PKI message exchanges in this profile require a PKIConfirm
<BR>&nbsp;&nbsp; message to be sent by the initiating entity.&nbsp; This
message is not
<BR>&nbsp;&nbsp; included in many of the profiles given below since its
body is
<BR>&nbsp;&nbsp; NULL and its header contents are clear from the context.&nbsp;
Any
<BR>&nbsp;&nbsp; authenticated means can be used for the protectionAlg
(e.g.,
<BR>&nbsp;&nbsp; password-based MAC, if shared secret information is known,
or&nbsp;&nbsp;&nbsp; signature).
<BR>&nbsp;
<BR>&nbsp;</UL>
Thats all I have. I can say that only with these recent dialogues do I,
<BR>for one, mostly understand the subtleties. Hopefully lots
<BR>of implementors now intepret things similarly, and multi-vendor
<BR>interworking will actually happen!

<P>Peter.
<BR>&nbsp;
<BR>&nbsp;
<BR>&nbsp;
<BR>&nbsp;
<UL>

<P>Hi Peter,

<P>>----------
<BR>>From:&nbsp; Peter Williams[SMTP:[email-masked]]
<BR>>Sent:&nbsp; Tuesday, September 30, 1997 3:46 PM
<BR>>To:&nbsp;&nbsp;&nbsp; Carlisle Adams
<BR>>Cc:&nbsp;&nbsp;&nbsp; [email-masked]'
<BR>>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: Comments on [MANDATORY
cert discovery capabiity]
<BR>>
<BR>>Carlisle Adams wrote:
<BR>>
<BR>>>&nbsp; But, to answer your question, the CA must respond with an
error message
<BR>>> (a response that should be expected by any EE that goes outside
the
<BR>>> mandatory spec.).&nbsp; This does not hamper the EE's abilities
or future
<BR>>> actions in any way, because it can always send another request with
an
<BR>>> empty SET (to get whatever the CA does know), or get the required
<BR>>> information in any other fashion (recall that PKIMessages do not
need to
<BR>>> be used for this information exchange), or decide that it really
didn't
<BR>>> need this particular information after all and simply send an InitReq
<BR>>> message.
<BR>>
<BR>>Should we mandate that an EE be required to send a PKIInformation
"with
<BR>an empty set of requirements" msg if it gets an error msg to its
<BR>>previous attempt
<BR>>to synchronise PKI information before entering the initialization
or
<BR>>certification states wheree real work gets done?

<P>I'm not sure why this would need to be mandated...

<P>>Im imagining in a Microsoft implementation of this PKIInformation exchange
<BR>>in which&nbsp; the activeX enrollment control, which implements the
<BR>>more elaborate B.x profiles using RSA, would be supplied to the EE
in
<BR>>response to
<BR>>PKInformation object {ms 1}. Where the CA is not a activeX
<BR>>CA (i.e. it sends an error msg), then that same browser needs to fall
<BR>>back to non-activeX mechanisms by syncing on initialization information
they
<BR>>can agree on (i.e. that which the CA optionally provides) and using
a
<BR>>barebones PKIX-3 minimal, default implementation with DSA cipherSuites,
say.

<P>I would assume that falling back to guaranteed interoperable messages
<BR>would be normal behavior for any well-designed protocol engine.
<BR>Bringing up my previous analogy again, if one side can't communicate
<BR>with the other using 3-DES / RC5 / IDEA / CAST-128, it should fall
back
<BR>to DES because it knows this will work.&nbsp; Do we need to mandate
such
<BR>common-sense behavior?&nbsp; I don't think so&nbsp; --&nbsp; as I said,
the EE may
<BR>decide to do the information exchange in some out-of-band way or may
<BR>decide it doesn't really need the information.&nbsp; Also, protocol
<BR>implementors seem pretty familiar with this style of protocol (where
<BR>certain messages, options, algorithms, etc., are mandated so that
<BR>interoperability can be guaranteed), so it seems unnecessary to mandate
<BR>this particular flowchart ("try this; if it doesn't work, go with
<BR>that").

<P>Your example is interesting, but I'm a bit surprised by your conclusion.
<BR>&nbsp;I thought you were keen to mandate fewer things rather than more...
?

<P>--------------------------------------------
<BR>Carlisle Adams
<BR>Entrust Technologies
<BR>[email-masked]
<BR>--------------------------------------------</UL>
&nbsp;</HTML>

</html>Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Williams
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 15 (TEXT/R*ch) (0001C140)

Date: Tue, 30 Sep 1997 17:13:16 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: VeriSign
To: [email-masked]
Subject: PKIX-2 http
Status:

We do need to agree the mime type for returning an http resource, still.

I note that the introduction also allows the http mechanism to be used
for pushing the cert/CRL to the directory. Perhaps its best
that the objects we are pulling/pushing are indeed simply
regarded as files. When pulling a .crt file the object
is labelled application/octet-string. When pushing files,
the file objects are transferred in a classical http push operation's
multipart mime type.

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

Attachment converted: Lutefisk:vcard.vcf 14 (TEXT/R*ch) (0001C13F)

Date: Tue, 30 Sep 1997 18:53:29 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Last Call
Status:

Folks,

We have several revised I-Ds that have been posted recently and I'd like to
begin the WG last call process.  We discussed which I-Ds seemed to be ready
for progression during the Munich meeting, as reported in the meeting
minutes distributed to this list immediately after the meeting.  New
versions of several of the documents have been posted and are now ready for
a final review.

	- PKIX Part 1, X.509 certificate and CRL syntax,
(draft-ietf-pkix-ipki-part1-05.txt),  has been in process for a long while.
Although I saw a couple of minor syntax changes proposed recently, I assume
that we're ready to close the books on this one, modulo resolution of the
proposed changes by the authors.

	- PKIX Part 2 has been split into several pieces.  The LDAP portion
(draft-ietf-pkix-ipki2opp-03.txt) is now under consideration and I've seen
no substantial comments on it. The FTP and HTTP portion,
(draft-ietf-pkix-opp-ftp-http-00.txt), is also posted, and the only
comments I've seen there are relatively minor ones re choice of MIME
context types.  I'd like to move forward on this one as well.

	- PKIX Part 3, on certificate management protocols
(draft-ietf-pkix-ipki3cmp-04.txt) has also been debated extensively and I
would progress this document as well.

	- PKIX Part IV, certificatecertification practices framework,
(draft-ietf-pkix-ipki-part4-01.txt ) is up for review as an Informational
RFC, not standards track.  Although not strictly necessary, I would like to
get Wg approval to forward this document to the IESG as well.

Please send any comments on these I-Ds to the list so that we can determine
if any further changes need to to made prior to forwarding the documents to
the IESG for IETF-wide last call.

Steve

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on [MANDATORY cert discovery capabiity]
Date: Tue, 30 Sep 1997 16:27:26 -0400
Status:

Hi Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Tuesday, September 30, 1997 3:46 PM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'
>Subject: 	Re: Comments on [MANDATORY cert discovery capabiity]
>
>Carlisle Adams wrote:
>
>>  But, to answer your question, the CA must respond with an error message
>> (a response that should be expected by any EE that goes outside the
>> mandatory spec.).  This does not hamper the EE's abilities or future
>> actions in any way, because it can always send another request with an
>> empty SET (to get whatever the CA does know), or get the required
>> information in any other fashion (recall that PKIMessages do not need to
>> be used for this information exchange), or decide that it really didn't
>> need this particular information after all and simply send an InitReq
>> message.
>
>Should we mandate that an EE be required to send a PKIInformation "with
an empty set of requirements" msg if it gets an error msg to its
>previous attempt
>to synchronise PKI information before entering the initialization or
>certification states wheree real work gets done?

I'm not sure why this would need to be mandated...

>Im imagining in a Microsoft implementation of this PKIInformation exchange
>in which  the activeX enrollment control, which implements the
>more elaborate B.x profiles using RSA, would be supplied to the EE in
>response to
>PKInformation object {ms 1}. Where the CA is not a activeX
>CA (i.e. it sends an error msg), then that same browser needs to fall
>back to non-activeX mechanisms by syncing on initialization information they
>can agree on (i.e. that which the CA optionally provides) and using a
>barebones PKIX-3 minimal, default implementation with DSA cipherSuites, say.

I would assume that falling back to guaranteed interoperable messages
would be normal behavior for any well-designed protocol engine.
Bringing up my previous analogy again, if one side can't communicate
with the other using 3-DES / RC5 / IDEA / CAST-128, it should fall back
to DES because it knows this will work.  Do we need to mandate such
common-sense behavior?  I don't think so  --  as I said, the EE may
decide to do the information exchange in some out-of-band way or may
decide it doesn't really need the information.  Also, protocol
implementors seem pretty familiar with this style of protocol (where
certain messages, options, algorithms, etc., are mandated so that
interoperability can be guaranteed), so it seems unnecessary to mandate
this particular flowchart ("try this; if it doesn't work, go with
that").

Your example is interesting, but I'm a bit surprised by your conclusion.
 I thought you were keen to mandate fewer things rather than more... ?

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

Date: Tue, 30 Sep 1997 12:46:51 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: VeriSign
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

Carlisle Adams wrote:

>  But, to answer your question, the CA must respond with an error message
> (a response that should be expected by any EE that goes outside the
> mandatory spec.).  This does not hamper the EE's abilities or future
> actions in any way, because it can always send another request with an
> empty SET (to get whatever the CA does know), or get the required
> information in any other fashion (recall that PKIMessages do not need to
> be used for this information exchange), or decide that it really didn't
> need this particular information after all and simply send an InitReq
> message.

Should we mandate that an EE be required to send a PKIInformation "with
an empty set of requirements" msg if it gets an error msg to its previous
attempt
to synchronise PKI information before entering the initialization or
certification states wheree real work gets done?

Im imagining in a Microsoft implementation of this PKIInformation exchange
in which  the activeX enrollment control, which implements the
more elaborate B.x profiles using RSA, would be supplied to the EE in response
to
PKInformation object {ms 1}. Where the CA is not a activeX
CA (i.e. it sends an error msg), then that same browser needs to fall
back to non-activeX mechanisms by syncing on initialization information they
can agree on (i.e. that which the CA optionally provides) and using a
barebones PKIX-3 minimal, default implementation with DSA cipherSuites, say.

(Take this example figuratively, only.)

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

Attachment converted: Lutefisk:vcard.vcf 13 (TEXT/R*ch) (0001C10E)

From: Carlisle Adams <[email-masked]>
To: "'Stef Hoeben'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: questions about ipki3cmp-04.txt (fwd)
Date: Tue, 30 Sep 1997 10:07:46 -0400
Status:

Hi Stef,

>----------
>From: 	Stef Hoeben[SMTP:[email-masked]]
>Sent: 	Tuesday, September 30, 1997 3:34 AM
>To: 	[email-masked]
>Subject: 	questions about ipki3cmp-04.txt (fwd)
>
>Sorry to bother you all, but here are two questions
>about the creation of certs (cmp draft):
>
>* a bit is said about CertReqContent and CertRepContent, 
>but I don't know in which case to use these messages
>and what exactly is the difference with InitReqContent 
>and InitRepContent?

A couple of people have asked this over the past few months so I tried
to be a bit more explicit in this latest draft with the wording in
Appendix B (specifically, B8 and B9).  InitReq / InitRep are intended to
be used when an EE is first getting initialized (i.e., just getting
started in the system and requesting its first certificate), whereas
CertReq / CertRep are intended to be used by EEs that are already
initialized (i.e., they are already in the system and are requesting
subsequent certificates).  Supporting this is the fact that for InitReq
/ InitRep the protectionAlg can only be a MAC (based on a key derived
from shared secret information) and for CertReq / CertRep the
protectionAlg can be a MAC or a signature (since the EE may already have
a valid verification certificate and is presumed to hold a valid copy of
the CA's verification certificate).

Syntactically there is very little difference between the two, except
that InitReq allows the EE to send to the CA a protocol encryption key
(this is to be used to encrypt the private key coming back to the EE, if
centralized key generation was requested and is supported by the CA).

>* for the Centralised scheme (2.2.2.1), the message sent 
>to the user is a CertRepContent or a InitRepContent, right?

Yes (although since the centralized scheme is an initialization scheme,
InitRep is semantically more appropriate).

>Greetings, Stef
>
>PS  I'd like to congratiulate Peter and Carlisle for
>    cheering up this list, I'm always looking forward
>    to reading their discussions.

Thank you, but all the credit really should go to Peter...

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

Date: Tue, 30 Sep 1997 08:02:07 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Certificate Suspension
Status:

Dwight:

A CA may, in its own interest to limit liability, take a warning of a signing key compromise from a third party and suspend the suspected compromised signing key while confirming with the private key holder ("subscriber "in Utah) whether or not to revoke the private key.  If the issue is not resolved in 24 hrs, then the key is revoked.

In industries  like yours, a "denial of service" attack would be easy if a trading entity was able to report a competitor's key as compromised then the CA would automatically revoke the competitor's key.  If the CA did not revoke the reportedly compromised key when notified, then the CA would probably incur liability for NOT revoking if a compromised key is actually used for fraudulent purposes.

Michael

>>> Dwight Arthur <[email-masked]> 09/29/97 01:01PM >>>
Peter Williams wrote:
> The suspension action can be logically undone.
> 
> A revocation action cannot be undone.
> 
> If one advises a VISA bank that is possible that one has lost one's
> visacard, then they can suspend its use (for three days most
> issuing policies). When you find the card, account activity can be
> resumed as if nothing had happened.  <...>

In the world of securities trading, where people profit on good news and
bad but uncertainty causes panics, there is nothing more expensive than
a transaction that can neither be cancelled nor completed. In this
industry, I believe that suspensions will be deprecated and revocation
used instead.

-Dwight

Organization: ESAT, K.U.Leuven, Belgium
Date: Tue, 30 Sep 1997 08:34:55 +0100 (MET)
From: Stef Hoeben <[email-masked]>
To: [email-masked]
Subject: questions about ipki3cmp-04.txt (fwd)
Status:

Sorry to bother you all, but here are two questions
about the creation of certs (cmp draft):

* a bit is said about CertReqContent and CertRepContent, 
but I don't know in which case to use these messages
and what exactly is the difference with InitReqContent 
and InitRepContent?

* for the Centralised scheme (2.2.2.1), the message sent 
to the user is a CertRepContent or a InitRepContent, right?

Greetings, Stef

PS  I'd like to congratiulate Peter and Carlisle for
    cheering up this list, I'm always looking forward
    to reading their discussions.

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on [MANDATORY cert discovery capabiity]
Date: Mon, 29 Sep 1997 17:49:48 -0400
Status:

Hi Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Monday, September 29, 1997 4:47 PM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'
>Subject: 	Re: Comments on [MANDATORY cert discovery capabiity]
>
>Carlisle Adams wrote:
>
>> Two comments here.  Firstly, it is true that a requestor may ask for any
>> number of particular things (the request is, after all, a SET of
>> {OID,value} pairs).  However, the only request that MUST be supported
>> according to B.6 is the empty SET, which corresponds to "give me
>> whatever information you think I need to know" (see 3.3.18).  Thus,
>> there is nothing explicit in the request that forces the CA to supply
>> any particular piece of information.  More relevant to your concern is
>> the fact that B.6 currently mandates that the CA include the current CRL
>> in the response.  The thinking here was that the CA would have this
>> information anyway (since it's the one that created the CRL) and an
>> initializing EE would probably want to see this (it's a useful part of
>> the start-up information).  However, it doesn't really need to be
>> mandatory, so I will change the top line of p.53 to "optionally present,
>> with relevant value".  [I assume this will make you happier.]
>
>(The CRL matter is news to me, and Ill have to think aboutwhy this CRL or
>similar flow during initalization was possibly rationalised to be
>*mandatory* in the first place... Are there any other mandatory objects
>to be provided, btw?)

It shouldn't have been "news to you", since it was in one of the
excerpts you yourself quoted in your line of thinking in your previous
post.  As for why it was "possibly rationalised to be mandatory in the
first place", I already answered that in the text above.  As for other
"mandatory objects to be provided", how many times do I have to say
"look at Appendix B"?  (That's what this appendix is there for!)  In
this case, B.6 says what must be present in the response message.

>But to the protocol issue:-
>
>I'm contemplating the situation where as a value-added feature, a given
>EE implementation presets the requested particular-options to include
>"{private-oid 1}".
This the vendors synced-up CA software will know how to handle. All
>other vendors
>software seem to be required to present error returns. Effectively,
>the EE is locked down to a given vendor's system at initialization
time & consequently  thereafter, with a mere configuration option.
>Normally, open
>systems protocol extensibility schemes are designed not cause such raw
>interworking failure when used.

I don't really understand your concern here.  Let's say there is a
protocol somewhere that says DES is the mandatory algorithm (and
everything else is optional).  As a "value-added feature, a given EE
implementation presets the requested particular-options" to be 3-DES, or
IDEA, or RC5, or CAST-128.  Does this mean it is "locked down to a given
vendor's system ... with a mere configuration option"?  Yes.  Once you
go outside the mandatory, you cannot guarantee interoperability.  People
seem to know and understand this aspect of protocol design very well.
What, exactly, is your objection here?

>My suggestion is that this element of service  be amended to have
>the EE set a "required" bit on a per-oid basis, to signal
>that the reply must contain the requested information. By
>default, a particular-option "required" bit  is to be not-set  i.e. the
>per-item
>request may be optionally satisfied by the responder. EEs are
>expected to continue the enrollment protocol should the requested
>(but not-required) option be returned empty.

I have to admit that I can't see much value in modifying the protocol to
allow EEs to say, "I'd like this information, but I don't really care if
you send it to me or not."  Instead of having a "required" bit, why not
simply have EEs only ask for the information they really want (which is
what we have already)?

>Let me ask a direct question to have you clarify positively for
>the case in question:-
>
>If EE sends a msg asking for information identified by {private-oid 1}
>where {private-oid 1} is not an object known to the CA, may
>the CA reply anyway with what it does know, and thereby enable
>the EE to choose to continue on with the msg flow of the msg sequences
>indicated in the part 4, and appendix B?

>From the EE's point of view, there is no difference between an error
message and the CA replying with what it does know (which doesn't
include {private-oid 1}).  In both cases the EE does not have what it
asked for.  Furthermore, in both cases the EE can subsequently send
whatever PKIMessage it wants (i.e., an error message does not prevent it
from sending an InitReq message at any time in the future  --  did you
think it did?).

But, to answer your question, the CA must respond with an error message
(a response that should be expected by any EE that goes outside the
mandatory spec.).  This does not hamper the EE's abilities or future
actions in any way, because it can always send another request with an
empty SET (to get whatever the CA does know), or get the required
information in any other fashion (recall that PKIMessages do not need to
be used for this information exchange), or decide that it really didn't
need this particular information after all and simply send an InitReq
message.

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

Date: Mon, 29 Sep 1997 13:47:47 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: VeriSign
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

Thanks for your reply.

Carlisle Adams wrote:

>>  (...much of the "line of thinking" deleted to save space...)
>>
>>     I note that a requestor may ask for any material indicated by the
>> options supported in
>> B.6, including those elements which seem (to me) to be one of the
>> instantiations of 3.3.14 / 3.3.16 operations.
>
> Two comments here.  Firstly, it is true that a requestor may ask for any
> number of particular things (the request is, after all, a SET of
> {OID,value} pairs).  However, the only request that MUST be supported
> according to B.6 is the empty SET, which corresponds to "give me
> whatever information you think I need to know" (see 3.3.18).  Thus,
> there is nothing explicit in the request that forces the CA to supply
> any particular piece of information.  More relevant to your concern is
> the fact that B.6 currently mandates that the CA include the current CRL
> in the response.  The thinking here was that the CA would have this
> information anyway (since it's the one that created the CRL) and an
> initializing EE would probably want to see this (it's a useful part of
> the start-up information).  However, it doesn't really need to be
> mandatory, so I will change the top line of p.53 to "optionally present,
> with relevant value".  [I assume this will make you happier.]

(The CRL matter is news to me, and Ill have to think aboutwhy this CRL or
similar flow during initalization was possibly rationalised to be
*mandatory* in the first place... Are there any other mandatory objects
to be provided, btw?)

But to the protocol issue:-

I'm contemplating the situation where as a value-added feature, a given
EE implementation presets the requested particular-options to include
"{private-oid 1}".
This the vendors synced-up CA software will know how to handle. All other
vendors
software seem to be required to present error returns. Effectively,
the EE is locked down to a given vendor's system at initialization
time & consequently  thereafter, with a mere configuration option. Normally,
open
systems protocol extensibility schemes are designed not cause such raw
interworking failure when used.

There may be a more acceptable requirement for the EE to say, please
send information X, but please do not return an error just because you do
not
have it available (or are unwilling to supply..)

My suggestion is that this element of service  be amended to have
the EE set a "required" bit on a per-oid basis, to signal
that the reply must contain the requested information. By
default, a particular-option "required" bit  is to be not-set  i.e. the
per-item
request may be optionally satisfied by the responder. EEs are
expected to continue the enrollment protocol should the requested
(but not-required) option be returned empty.

The PKIX conformance statements  might  strongly
urge that, by default, EE's do not ask for any required
particular-options.  this will help get multi-vendor interworking
up faster. Once operational needs are determined, then (of course)
locally-required behaviour may be tweaked by administrators.

>
>
> If the EE indicates a particular option, such a message is outside the
> mandatory set of messages and options specified in B.6, so a
> PKIX-compliant CA is free to take whatever action it wants (including
> throwing away the message because it doesn't understand it).  Again,
> there is no way an EE can use this request to force the CA to distribute
> certificates.
>

This I had not understood ; I had understood the required
processing to be: if an unknown PKIinformation particular-option is
presented by
the user then the CA/RA must return an error msg (being unable to
fulfill the request totally.)

I was assuming, given the text, that this procedure  was mandatory:
i.e. all CA/RA implementations must adopt this very specific failure mode
processing.

Let me ask a direct question to have you clarify positively for
the case in question:-

If EE sends a msg asking for information identified by {private-oid 1}
where {private-oid 1} is not an object known to the CA, may
the CA reply anyway with what it does know, and thereby enable
the EE to choose to continue on with the msg flow of the msg sequences
indicated in the part 4, and appendix B?

If the answer is no, can we introduce the "required bit" per
particular-object
oid as suggested above so that error returns are only mandated only when
its a "required" information unit that a CA/RA cannot, or is unwilling
to,  provide?

If the answer is yes, perhaps add one phrase of clarification. (I
certainly read the spec as requiring CA/RA to return an
error response...)

Peter.

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

Attachment converted: Lutefisk:vcard.vcf 12 (TEXT/R*ch) (0001C105)

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on [MANDATORY cert discovery capabiity]
Date: Mon, 29 Sep 1997 15:41:12 -0400
Status:

Hi Peter,

Sorry I was called away for several days on other things, but now I'm
back and thinking about PKIX again...

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Monday, September 22, 1997 3:49 PM
>To: 	Carlisle Adams
>Cc: 	[email-masked]
>Subject: 	Re: Comments on [MANDATORY cert discovery capabiity]
>
I *am* reading and relating one section with another. I have one
aim in mind: to determine what is the minimum functionality one must
implement. (Then, laterm I can perform an analysis of whether it is
acceptable
to be required (as an operator) to enact those procedures, individually
and in tandem. )

>Can you reproduce (and defend) the line of reasoning that led you to
>believe that 3.3.14 and 3.3.16 are mandatory?  I would be willing to
>correct any text that leads to such a conclusion, but at the moment I
>can't find any text that needs correction...

This was my line of thinking:

(...much of the "line of thinking" deleted to save space...)

    I note that a requestor may ask for any material indicated by the
options supported in
B.6, including those elements which seem (to me) to be one of the
instantiations of 3.3.14 / 3.3.16 operations.

Two comments here.  Firstly, it is true that a requestor may ask for any
number of particular things (the request is, after all, a SET of
{OID,value} pairs).  However, the only request that MUST be supported
according to B.6 is the empty SET, which corresponds to "give me
whatever information you think I need to know" (see 3.3.18).  Thus,
there is nothing explicit in the request that forces the CA to supply
any particular piece of information.  More relevant to your concern is
the fact that B.6 currently mandates that the CA include the current CRL
in the response.  The thinking here was that the CA would have this
information anyway (since it's the one that created the CRL) and an
initializing EE would probably want to see this (it's a useful part of
the start-up information).  However, it doesn't really need to be
mandatory, so I will change the top line of p.53 to "optionally present,
with relevant value".  [I assume this will make you happier.]

Secondly, 3.3.14 and 3.3.16 are different PKIBody structures (i.e., they
correspond to totally different PKIMessages from 3.3.18 and 3.3.19) so I
don't really know what you mean by "one of the instantiations of 3.3.14
/ 3.3.16 operations".  As I said before, 3.3.14 and 3.3.16 are optional
PKIMessages and need not be supported by PKIX-conformant EEs, RAs, or
CAs.

Thus I reasoned, that the document seemed to be mandating that CAs must
perform
the CA-based certificate distribution mechanism to conform to the spec
if the
relevevant option is indicated by the EE, else they must return error
messages during
intial registration./certification.

If the EE indicates a particular option, such a message is outside the
mandatory set of messages and options specified in B.6, so a
PKIX-compliant CA is free to take whatever action it wants (including
throwing away the message because it doesn't understand it).  Again,
there is no way an EE can use this request to force the CA to distribute
certificates.

that is: a CA implementation must either implement (to conform) an
unerring error
return, or it must satisfy the options requested. It cannont say:  here
is your
certificate dear subscriber, but I do not wish to engage in the
requested
CA-based distribution/management mechanism; please use
the LDAP directory instead.

Again, the "here is your certificate dear subscriber" message is not
related in any way to the general request / response messages, so I
don't understand why you are trying to tie them together.

------

Please do not merely argue with my reasoning if you respond ; my
reasoning
may be right or wrong. Perhaps, just add a specific
section which defines the minimum PKIX-3 conformance position in
terms of the management operations, message formats, and options
required,  rather than having people deduce what it is (wrongly,
half-wrong, or correctly)
from a set of statements and procedure, optional messages and
(optional) message element interactions spread all over a 70-page
document.

You would like a "specific section which defines the minimum PKIX-3
conformance position in terms of the management operations" (this is
Section 4) "message formats, and options required" (this is Appendix B).

Sections 1 and 2 talk in general terms about the certificate management
functionality that an Internet PKI may have and Section 3 defines
messages that can achieve that functionality.  Section 4 specifies the
subset of the operations from Sections 1 and 2 that MUST be supported
and Appendix B specifies the subset of the messages from Section 3 that
MUST be supported (to achieve the requirements of Section 4).  The
PKIX-3 conformance position is not "spread all over a 70-page document";
it is contained (explicitly) in one section and one appendix.  I really
don't know what you're asking for beyond this.

(I intend after this comment threat to send a note on two other
(hopefully
simple) issues to do with conformance requirements, your choice
of language and the indirect signals they send to me -- whose currrent
expression may impact actual interworking.)

I assume you mean "thread" above   :-)

I haven't seen your two other issues yet.  Have they been resolved with
further reading, or are you just trying to heighten my curiosity by
waiting before you post them?

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

Date: Mon, 29 Sep 1997 14:59:49 -0400
To: [email-masked]
From: "Robert W. Shirey" <[email-masked]>
Subject: PKI Modeling
Status:

Request For Correspondence

I'd like to exchange ideas and information with people who are involved in
or thinking about building a quantitative, analytical model of PKI for the
purpose of estimating costs and predicting other aspects of system
performance.

Regards, -Rob-

[email-masked], Phone 703-284-4641, Reception 284-4600, Fax 284-2766
Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200
1300 North Seventeenth Street, Arlington, Virginia   22209-3801   USA

Date: Mon, 29 Sep 1997 15:01:33 -0400
From: Dwight Arthur <[email-masked]>
To: Peter Williams <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate Suspension
Status:

Peter Williams wrote:
> The suspension action can be logically undone.
> 
> A revocation action cannot be undone.
> 
> If one advises a VISA bank that is possible that one has lost one's
> visacard, then they can suspend its use (for three days most
> issuing policies). When you find the card, account activity can be
> resumed as if nothing had happened.  <...>

In the world of securities trading, where people profit on good news and
bad but uncertainty causes panics, there is nothing more expensive than
a transaction that can neither be cancelled nor completed. In this
industry, I believe that suspensions will be deprecated and revocation
used instead.

-Dwight

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: Errors in the 88 ASN.1 of PKIX pt 1
Date: Mon, 29 Sep 97 10:43:50 +1000
Status:

Hi all,

I've just been debugging the '88 ASN.1 and have run across the following 
problems:

The following types and values are defined more than once:

Version, Extensions, Extension, CertificateSerialNumber, id-ce-cRLNumber,
id-pkix-authorityInfoAccess, Dss-Sig-Value 

I think the following are typos:

+ PolicyQualifierId has a trailing {
+ id-pkix-authorityInfoAccess OBJECT-IDENTIFIER should be OBJECT IDENTIFIER
+ certificateIssuer EXTENSION ... should be: CertificateIssuer ::= GeneralNames
+ sizE(1..ub-pds-parameter-length... should be SIZE

In addition, I think the convention of using uppercase first character for
types and lowercase for values should be adhered to (it chokes my ASN.1 
compiler
if it isn't used):

anotherName -> AnotherName, certificateIssuer -> CertificateIssuer, 
ExtensionAttributeTable -> extensionAttributeTable

Should the string types in Directory string have SIZE(1..MAX) rather than
SIZE(1..maxSize)?

That's about it :-)

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-opp-ftp-http-00.txt
Date: Fri, 26 Sep 1997 14:26:45 -0400
Sender: [email-masked]
Status:

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
                          Operational Protocols:  FTP and HTTP
	Author(s)	: R. Housley
	Filename	: draft-ietf-pkix-opp-ftp-http-00.txt
	Pages		: 5
	Date		: 23-Sep-97
	
   The protocol conventions described in this document satisfy some of
   the operational requirements of the Internet Public Key
   Infrastructure (PKI).  This document specifies the conventions for
   using the File Transfer Protocol (FTP) and the Hypertext Transfer
   Protocol (HTTP) to obtain certificates and certificate revocation
   lists (CRLs) from PKI repositories.  Additional mechanisms addressing
   PKIX operational requirements are specified in separate documents.
 
   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-opp-ftp-http-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-opp-ftp-http-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-opp-ftp-http-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.

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 3 (EuSn/CSOm) (0001BF78)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-opp-ftp-http-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-opp-ftp-htt (AURL/Arch) (0001BF79)
Content-Type: text/plain
Content-ID:	<[email-masked]>

Date: Fri, 26 Sep 1997 09:10:53 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Comments about Part 2
Status:

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

On Fri, 26 Sep 1997, Peter Whittaker wrote:
> 
> >3.2.1 CertTemplate definition
> >
> >Why are issuer and Subject defined as Name instead of GeneralName?
> 
> The definition of Certificate in X.509 uses Name for subject and issuer.
>  Unless we wish for PKIX to be incompatible with X.509 (and that would
> be bad, by definition of PKIX, right?  :->), we should continue to use
> Name instead of GeneralName for these fields.  Note that PKIX pt1
> describes an accomodation that works as well, and that is to have null
> subject or issuer, with their identity being carried in the
> subjectAltName or issuerAltName extension.

I get it now, thanks...

> >
> >3.2.4 Certificate Identification
> >
> >Shouldn't serialNumber be a CertificateSerialNumber?
> 
> That seems right, for the sake of complete accuracy (in the end, they
> are the same thing, as CertificateSerialNumber is defined as INTEGER).
> 

Yeah, it's just a nit.  I noticed it because it made me stop to wonder if
it was different from a certificate's serial number.  No big deal,
though...

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

From: <[email-masked]>
Date: Fri, 26 Sep 97 16:44:53 +0200
Subject: SV: Re:  SV: Re: Coding of national characters?
To: [email-masked]
Cc: [email-masked]
Status:

<[email-masked]> wrote:
>
> The (rather complex) issues surrounding this are explained in the 
X.509 style
> guide (with some recent updates to cover character set issues), 
available from
> http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt.  Apologies to 
people who
> already know about the guide, but these sorts of questions seem to come up a
> fair bit so I've cc'd the message back to the list in case anyone else wants
> to know how to handle character set issues.
>
> I've also written some code which should be able to take virtually any input
> text and convert it to an X.509-kosher form, if anyone wants to test this
> (especially with multibyte and widechar character sets) please let me know -
> I've only really got access to ASCII and 8859-1 environments so some of the
> stuff is guesswork.

Thanx Peter,

your guide is very helpful. I was already aware of it but I've noticed that
it's been updated since the last time I went through it.

However, it's still NOT a solution to the problem (unless of course your
guide is incorporated into the standard ;-)

Can we please have this fixed in PKIX-1?

BMPString sounds like a much better alternative than teletexString so one
possibility would be to change the definition to:

DirectoryString ::= CHOICE {
    printableString         PrintableString (SIZE (1..maxSize)),  --if 
it's sufficient otherwise...
    bmpString                  BMPString (SIZE (1..maxSize)),         
--if it's sufficient otherwise...
    universalString         UniversalString (SIZE (1..maxSize)) --otherwise
    }

Nevertheless, ISO 8859-1 is a lot better solution than BMPString
for most european languages in terms of efficiency.

So what's the tag 'visibleString' from the SET definition? Is that ISO 8859-1?
In that case, can we use it?

Do I sound desperate?

/Lars Johansson

From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Marc Branchaud'" <[email-masked]>
Cc: Carlisle Adams <[email-masked]>
Subject: RE: Comments about Part 2
Date: Fri, 26 Sep 1997 08:42:16 -0400
Status:

>3.2.1 CertTemplate definition
>
>Why are issuer and Subject defined as Name instead of GeneralName?

The definition of Certificate in X.509 uses Name for subject and issuer.
 Unless we wish for PKIX to be incompatible with X.509 (and that would
be bad, by definition of PKIX, right?  :->), we should continue to use
Name instead of GeneralName for these fields.  Note that PKIX pt1
describes an accomodation that works as well, and that is to have null
subject or issuer, with their identity being carried in the
subjectAltName or issuerAltName extension.
>
>3.2.4 Certificate Identification
>
>Shouldn't serialNumber be a CertificateSerialNumber?

That seems right, for the sake of complete accuracy (in the end, they
are the same thing, as CertificateSerialNumber is defined as INTEGER).

pww

Date: Thu, 25 Sep 1997 18:10:11 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: Marc Branchaud <[email-masked]>
CC: [email-masked]
Subject: Re: Question about Part 1...
Status:

Marc Branchaud wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> On Thu, 25 Sep 1997, Brian Korver wrote:
> >
> > Marc Branchaud writes:
> > >
> > > 4.2.1.1 Authority Key Identifier
> > >
> > > Does the authorityCertIssuer field indicate the CA that signed the
> > > certificate, or the CA that issued a certificate for the CA that
> signed
> > > the certificate (i.e. the CA's parent CA)?
> >
> > The later.  For instance, here's a 3-level cert hierarchy (with a
> self-signed
> > root):
> >
> >     Serial:   1
> >     Issuer:   Root CA
> >     Subject:  Root CA
> >
> >     Serial:   2
> >     Issuer:   Root CA
> >     Subject:  UnderRoot CA
> >     AuthorityCertIssuer:  Root CA
> >     AuthorityCertSerial:  1
> >
> >     Serial:   3
> >     Issuer:   UnderRoot CA
> >     Subject:  EndEntity
> >     AuthorityCertIssuer:  Root CA
> >     AuthorityCertSerial:  2
> >
> 
> I suggest that the draft clarify this.  Including this example would
> be
> most helpful.  At the least, change the first sentence of the second
> paragraph from
> 
> "The identification can be based on either the key identifier (the
> subject
> key identifier in the issuer's certificate) or on the issuer name and
> serial number."
> 
> to
> 
> "The identification information is obtained from the issuer's
> certificate
> (i.e. the certificate for the issuer's key, signed by a parent CA).
> The
> identification can be based on either the key identifier, or the
> issuer's name and serial number, from that certificate."
> 
>                 Marc

Yes, this needs careful clarification.  It may be helpful
to clarify how it is intended to be used in chain formation
together matching either the (explicit or implicit) subject key 
identifier in the immediate parent cert or matching the
issuer and serial number in the immediate parent cert.

In addition, one might want to note that the use
of the authorityCertIssuer and authorityCertSerial fields
rather than the keyIdentifier field precludes later
re-rooting (or extension upward) of an existing CA 
hierarchy, which is often desirable.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

Date: Thu, 25 Sep 1997 15:43:05 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: Question about Part 1...
Status:

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

On Thu, 25 Sep 1997, Brian Korver wrote:
> 
> Marc Branchaud writes:
> > 
> > 4.2.1.1 Authority Key Identifier
> > 
> > Does the authorityCertIssuer field indicate the CA that signed the
> > certificate, or the CA that issued a certificate for the CA that signed
> > the certificate (i.e. the CA's parent CA)?
> 
> The later.  For instance, here's a 3-level cert hierarchy (with a self-signed
> root):
> 
>     Serial:   1
>     Issuer:   Root CA
>     Subject:  Root CA
>     
>     Serial:   2
>     Issuer:   Root CA
>     Subject:  UnderRoot CA
>     AuthorityCertIssuer:  Root CA
>     AuthorityCertSerial:  1
> 
>     Serial:   3
>     Issuer:   UnderRoot CA
>     Subject:  EndEntity
>     AuthorityCertIssuer:  Root CA
>     AuthorityCertSerial:  2
> 

I suggest that the draft clarify this.  Including this example would be
most helpful.  At the least, change the first sentence of the second
paragraph from

"The identification can be based on either the key identifier (the subject
key identifier in the issuer's certificate) or on the issuer name and
serial number."

to

"The identification information is obtained from the issuer's certificate
(i.e. the certificate for the issuer's key, signed by a parent CA).  The
identification can be based on either the key identifier, or the
issuer's name and serial number, from that certificate."

		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: Thu, 25 Sep 1997 14:30:59 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Question about Part 1...
Status:

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

4.2.1.1 Authority Key Identifier

Does the authorityCertIssuer field indicate the CA that signed the
certificate, or the CA that issued a certificate for the CA that signed
the certificate (i.e. the CA's parent CA)?

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

From: Brian Korver <[email-masked]>
Subject: Re: Question about Part 1...
To: [email-masked]
Date: Thu, 25 Sep 1997 15:09:21 -0700 (PDT)
Cc: [email-masked]
Status:

Marc Branchaud writes:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> 4.2.1.1 Authority Key Identifier
> 
> Does the authorityCertIssuer field indicate the CA that signed the
> certificate, or the CA that issued a certificate for the CA that signed
> the certificate (i.e. the CA's parent CA)?

The later.  For instance, here's a 3-level cert hierarchy (with a self-signed
root):

    Serial:   1
    Issuer:   Root CA
    Subject:  Root CA
    
    Serial:   2
    Issuer:   Root CA
    Subject:  UnderRoot CA
    AuthorityCertIssuer:  Root CA
    AuthorityCertSerial:  1

    Serial:   3
    Issuer:   UnderRoot CA
    Subject:  EndEntity
    AuthorityCertIssuer:  Root CA
    AuthorityCertSerial:  2

brian
[email-masked]

Date: Thu, 25 Sep 1997 14:29:51 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Comments about Part 2
Status:

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

Just a couple of brief points...

3.2.1 CertTemplate definition

Why are issuer and Subject defined as Name instead of GeneralName?

3.2.4 Certificate Identification

Shouldn't serialNumber be a CertificateSerialNumber?

		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: Thu, 25 Sep 1997 07:10:49 -0600
To: "Peter Williams" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKIX1 definition of a certificate
Cc: "IETF PKIX List" <[email-masked]>
Status:

Peter,

	The defintion cited is not appropriate since, as you note, it
unenecssarily and inappropriately brings encrytpion into the picture.  Our
definition should cite only the use of a signature algorithm to bind a
public key to a set of attributes, specifically the attributes defined in
the spec (including extensions).

Steve

Date: Wed, 24 Sep 1997 23:28:31 -0400
From: George Capehart <[email-masked]>
Organization: Capehart Associates
To: [email-masked]
CC: [email-masked]
Subject: Re: PKIX1 definition of a certificate
Status:

Peter Williams wrote:
> 
>  "(4) the term 'public key certificates' means a certification of
>    the determination of the origin of encrypted information through
>    verification of a persons public key by identifying the unique
>    characteristics of the key;"
> 
> Should we alter PKIX-1 to have this as the definition of a
> PKIX public key certificate (assuming someone knows what
> the above means).

Though I have no voting rights, I *do* have a strong interest in this
discussion.  I work for a large bank and we are in the process of
creating our CPS and are therefore wrestling with this issue.  IMHO, a
_public_key_certificate_ is an object that contains the EE's public key
along with some representation of degree of certainty the CA has that
the EE who presented the public key to be certified is also in
possession of the private part of the key pair and really is who they
represent themselves to be.

It seems to me that a cert is an object and "certification of the
determination of origin of . . ." is an action . . . at least
grammatically.  As far as what the phrase actually means, I'm not really
sure.  I diagrammed the sentence and working backwards, I get the
statement that, based on unique characteristics of some public key, that
key can be identified and through that identification, the origin of
some encrypted information can be determined.  Shortening that somewhat,
I get:  That by knowing the fingerprint of some public key, I can
determine and certify the origin of some encrypted data.  If that's what
is meant by a digital certificate, that doesn't get me where I want to
be.

> (One notes that the above would not seem to cover a PKIX
> DSA or ECC-DSA certificate validating a DSA/ECC-DSA digital
> signature.)

Or most anything else.  I still haven't figured out how something can be
a noun and a verb at the same time . . .

> 
> Peter.
-- 
/*
 *  George Capehart     email:  [email-masked]     phone:  +1 704.866.9151
 *
 *  "If you push something hard enough, it will fall over."
 *                          Fudd's First Law of Opposition
 */

Date: Wed, 24 Sep 1997 12:13:06 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: "Sheedy, E.C.C." <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Certificate Suspension
Status:

I believe Certificate Suspension is where the certifiate is not
considered valid for some time and then considered valid again
after that.

For example, if you go on leave for 6 months, your company may
want to suspend your certificate for those 6 months without
revoking it.

A

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (408) 738-2040
ValiCert, Inc.				        [email-masked]
333 W. El Camino Real, Suite 270              http://www.valicert.com
Sunnyvale, CA 94087

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Subject: Re: FTP and HTTP
Date: Wed, 24 Sep 1997 11:06:42 -0700
Status:

Russ,

The use of application/octet-string would seem suitable if
the object is truely a file.

I do not believe one intends, however, to deny other
objects transferred using http. Consider adding
language which explicitely allows other mime
types to be used, without standarizating their
form.

To your paragrah 

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

One might add a phrase: 'Other http resources usable with
this mechanism may have alternative formats and naming conventions."

--------

Consider, by way of example, this msg. There is
an electronic vard attachment. Within, I have hopefully placed
an http URL, which points to an interactive page
which parties may used to download my cert in
a variety of formats used by various security applications.
This action is intended to replace the need to attach
my cert chain to each signed message, which is
rather a waste of resources particularly for those
who do not bother to verify signatures.

 Peter.

-----Original Message-----
From: Russ Housley <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, September 23, 1997 2:55 PM
Subject: FTP and HTTP

>Here is FTP/HTTP document that was slit out from PKIX Part 2.
>It is also being sent to the I-D repository.
>
>There is one detail to complete before last call: the assignement
>of MIME types for use with HTTP.  Does anyone have a preference?
>
>Russ

Attachment converted: Lutefisk:Peter Williams.vcf 3 (TEXT/R*ch) (0001BF3B)
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 19 (????/----) (0001BF3C)

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: "IETF PKIX List" <[email-masked]>
Subject: PKIX1 definition of a certificate
Date: Wed, 24 Sep 1997 10:55:30 -0700
Status:

 "(4) the term 'public key certificates' means a certification of
   the determination of the origin of encrypted information through
   verification of a persons public key by identifying the unique
   characteristics of the key;"

Should we alter PKIX-1 to have this as the definition of a 
PKIX public key certificate (assuming someone knows what 
the above means).

(One notes that the above would not seem to cover a PKIX
DSA or ECC-DSA certificate validating a DSA/ECC-DSA digital
signature.)
 
Peter.

Notice: This message is not signed.

Attachment converted: Lutefisk:Peter Williams.vcf 2 (TEXT/R*ch) (0001BF39)
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 18 (????/----) (0001BF3A)

From: "Peter Williams" <[email-masked]>
To: "Sheedy, E.C.C." <[email-masked]>, <[email-masked]>
Subject: Re: Certificate Suspension
Date: Wed, 24 Sep 1997 10:09:12 -0700
Status:

-----Original Message-----
From: Sheedy, E.C.C. <[email-masked]>
To: [email-masked]' <[email-masked]>
Date: Wednesday, September 24, 1997 8:56 AM
Subject: Certificate Suspension

>Hi,
>Whilst attempting to negotiate my way through the various PKIX documents
>i came across two terms which seem quite similar but have been made
>distinct. The two tersm are
>1. Certificate Revocation and
>2. Certificate Suspension.
>
>Cert. revocation is quite clear and needs no further explanation but
>cert. suspension i am quite unsure about. The two seem to have the same
>effects thus could someone please clarify the exact difference between
>them and the resulting actions taken which makes suspension different
>from Revocation.

The suspension action can be logically undone.

A revocation action cannot be undone.

If one advises a VISA bank that is possible that one has lost one's
visacard,
then they can suspend its use (for three days most issuing policies). When
you find the card, account activity can be resumed as if nothing
had happened. If you do not find it, the card is revoked, and you get
a new one. The consequences of revocation [request] are laid out
in the issuing policy; for example, you may be responsible for
reporting loss of the card to the police, in some countries.

>
>Cheers
>Colm Sheedy
>KPN Research
>

Attachment converted: Lutefisk:Peter Williams.vcf 1 (TEXT/R*ch) (0001BF38)

Date: Wed, 24 Sep 1997 17:34:45 +0100
From: "Sheedy, E.C.C." <[email-masked]>
Subject: Certificate Suspension
To: "[email-masked]'" <[email-masked]>
Status:

Hi,
Whilst attempting to negotiate my way through the various PKIX documents
i came across two terms which seem quite similar but have been made
distinct. The two tersm are 
1. Certificate Revocation and
2. Certificate Suspension.

Cert. revocation is quite clear and needs no further explanation but
cert. suspension i am quite unsure about. The two seem to have the same
effects thus could someone please clarify the exact difference between
them and the resulting actions taken which makes suspension different
from Revocation.

Cheers
Colm Sheedy
KPN Research 

Date: Tue, 23 Sep 1997 17:04:48 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: FTP and HTTP
Status:

Here is FTP/HTTP document that was slit out from PKIX Part 2.
It is also being sent to the I-D repository.

There is one detail to complete before last call: the assignement
of MIME types for use with HTTP.  Does anyone have a preference?

Russ
Attachment converted: Lutefisk:PKIX2OP3.TXT (TEXT/MSIE) (0001BF2E)

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  SV: Re: Coding of national characters?
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 24 Sep 1997 05:12:04 (NZST)
Status:

>It looks to me that BMPString is actually defined in the later version
>of the ASN.1 specification (ISO/IEC 8824) as a subset of UniversalString
>(with a different tag!). I have only the 88 version so I haven't been able
>to check this. Does that mean that BMPString can replace UniversalString
>wherever it appears (e.g. the DirectoryString definition of X.520)?
 
The (rather complex) issues surrounding this are explained in the X.509 style 
guide (with some recent updates to cover character set issues), available from 
http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt.  Apologies to people who 
already know about the guide, but these sorts of questions seem to come up a 
fair bit so I've cc'd the message back to the list in case anyone else wants 
to know how to handle character set issues.

I've also written some code which should be able to take virtually any input 
text and convert it to an X.509-kosher form, if anyone wants to test this 
(especially with multibyte and widechar character sets) please let me know - 
I've only really got access to ASCII and 8859-1 environments so some of the 
stuff is guesswork.
 
Peter.

From: <[email-masked]>
Date: Tue, 23 Sep 97 16:28:16 +0200
Subject: SV: Re: Coding of national characters?
To: [email-masked]
Cc: [email-masked]
Status:

[email-masked] wrote:
>
> [email-masked] wrote:
> >
> > We have a problem...
> >
> > In PKIX part 1, chapter 4.1.2.4  "Issuer Name" the issuer field
> > (and the subject field similarly) is defined. There are no
> > mandatory X.520 attributes (like country or commonName etc)
> > but the the DirectoryString is defined in ASN.1 as:
> >
> > >  DirectoryString ::= CHOICE {
> > >           teletexString           TeletexString (SIZE (1..maxSize)),
> > >           printableString         PrintableString (SIZE
> > (1..maxSize)),
> > >           universalString         UniversalString (SIZE
> > (1..maxSize))
>
>
> I agree with Lars.
>
> First, I believe the most current X.520 allows BMPString in this
> choice.

I have a version of X.520 from Nov 93 (is there a later version?)
which doesn't include BMPString in the choice. However, in the
appendix A to PKIX-1 I found the following lines:

   -- UNIVERSAL Types defined in '93 ASN.1
   -- but required by this specification

   UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
           -- UniversalString is defined in ASN.1:1993

   BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
           -- BMPString is the subtype of
           -- UniversalString and models the Basic Multilingual Plane
           -- of ISO/IEC 10646-1

It looks to me that BMPString is actually defined in the later version
of the ASN.1 specification (ISO/IEC 8824) as a subset of UniversalString
(with a different tag!). I have only the 88 version so I haven't been able
to check this. Does that mean that BMPString can replace UniversalString
wherever it appears (e.g. the DirectoryString definition of X.520)?

If anyone on this list have a specification of the character set in BMPString
I would appreciate a copy. Please respond to me privately.

> Second, I believe we should just avoid encoding as TeletexString
> (T61String)
> altogether.
>
> I'd like to see the precedence go:
>
> - PrintableString  if it "fits"
> - BMPString if it "fits"
> - UniversalString

I think this would be in line with the SET specification.

Regards,
/Lars J

Sender: [email-masked]
Date: Tue, 23 Sep 1997 14:32:54 +0200
From: Max VALLOT <[email-masked]>
Organization: BULL Worldwide Information Systems
To: [email-masked]
Subject: subscribe
Status:

subscribe
-- 
____________________________________________________________

Max VALLOT			Phone: +33 (0)1.30.80.60.62
 Bull SA       			Fax:   +33 (0)1.30.80.77.99
 FRCL-A5/146			mailto:[email-masked]
 rue Jean Jaures, BP68,    	
 78340 Les Clayes sous Bois,
 FRANCE
____________________________________________________________

Date: Tue, 23 Sep 1997 09:01:01 +0200 (DFT)
From: "J.Lebastard" <[email-masked]>
To: [email-masked]
Status:

subscribe

From: "Peter Williams" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Date: Mon, 22 Sep 1997 12:49:24 -0700
Status:

Attachment converted: Lutefisk:smime.p7m (????/----) (0001BF16)

Date: Mon, 22 Sep 1997 10:43:58 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: [email-masked]
CC: [email-masked]
Subject: Re: Coding of national characters?
Status:

[email-masked] wrote:
> 
> We have a problem...
> 
> In PKIX part 1, chapter 4.1.2.4  "Issuer Name" the issuer field
> (and the subject field similarly) is defined. There are no
> mandatory X.520 attributes (like country or commonName etc)
> but the the DirectoryString is defined in ASN.1 as:
> 
> >  DirectoryString ::= CHOICE {
> >           teletexString           TeletexString (SIZE (1..maxSize)),
> >           printableString         PrintableString (SIZE
> (1..maxSize)),
> >           universalString         UniversalString (SIZE
> (1..maxSize))

I agree with Lars.

First, I believe the most current X.520 allows BMPString in this
choice.

Second, I believe we should just avoid encoding as TeletexString
(T61String)
altogether.

I'd like to see the precedence go:

- PrintableString  if it "fits"
- BMPString if it "fits"
- UniversalString

--a.

> 
> Below this definition it is stated that:
> 
> >   The directoryString is defined as a choice of PrintableString,
> >   TeletexString and UniversalString.  Conforming CAs shall choose
> from
> >   these options as follows:
> >
> >      (a) if the character set is sufficient, the string will be
> >      represented as a PrintableString;
> >
> >      (b) failing (a), if the teletexString charater set is
> sufficient,
> >      the string string will be represented as a TeletexString;
> >
> >      (c) failing (a) and (b), the string shall be represented as a
> >      UniversalString.
> 
> The problem for us outside the US is how to encode national
> characters.
> In Sweden for example, PrintableString which is equivalent to 7-bit
> ASCII
> is not sufficient. According to the standard we would then make use of
> teletexString which is equivalent to the T.61 character set.
> 
> Now, T.61 is an old standard that is very seldomly used nowadays. In
> particular neither Netscape Navigator nor Microsoft Internet Explorer
> make use of T.61.
> 
> Instead both Navigator and Explorer uses the character set in ISO
> 8859-1
> (Latin-1 which is equivalent to 8-bit ASCII). This character set is
> used for
> both the PrintableString tag and the teletexString tag.
> 
> Clearly the use of ISO 8859-1 in conjuction with the teletexString tag
> is an
> error and some X.500 directories won't accept this. The effect would
> be
> that searching these directories becomes impossible.
> 
> The other alternative (ISO 8859-1 with the PrintableString tag) looks
> very
> attractive IMHO and I would prefer that this solution were
> incorporated into
> the standard. There are still problems however: many complilers based
> on ASN.1 doesn't accept 8-bit characters in a PrintableString.
> 
> Can anyone on this list see a solution to this problem? If so, I would
> suggest
> that the PKIX-1 draft is updated accordinly.
> 
> Regards,
> /Lars Johansson
> Sweden Post

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

From: "Arsenault, Al W." <[email-masked]>
To: Carlisle Adams <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on [MANDATORY cert discovery capabiity]
Date: Mon, 22 Sep 97 13:39:00 EDT
Encoding: 24 TEXT
Status:

On closer review, I confirmed that I like the document as it now stands.

There is the ability to use PKIX-CMP to distribute certificates, CRLs, etc. 
to users upon initial registration.  (For some set of users, it's easier to 
get the signed certificate, the CA's current CRL, and other ancillary 
information in a message - possibly contained on a floppy-disk for an 
off-line CA -  than to be told to get them from a repository.)  There is no 
need for this to be mandatory; I recognize that many CA providers will not 
want to provide this service and I don't wish to require them to.

Additionally, I can use PKIX-CMP (vice PKIX-OPP) to distribute new CRLs on 
occasions where a push is deemed necessary.  The messages I need to do this 
are all there in the protocol now.   Again, there is no need for these 
messages to be mandatory for PKIX conformance  - not everybody wants to/has 
to implement a similar service.  All I ask is that somebody providing such a 
service not be deemed non-conformant with PKIX.

          Al Arsenault

          - speaking only for myself

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-03.txt (re-send)
Date: Mon, 22 Sep 1997 12:17:19 -0400
Sender: [email-masked]
Status:

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  
                          Operational Protocols - LDAP
	Author(s)	: S. Boeyen, T. Howes, P. Richard
	Filename	: draft-ietf-pkix-ipki2opp-03.txt
	Pages		: 11
	Date		: 1997-09-17
	
The protocol described in this document is designed to satisfy  some  of
the  operational requirements within the Internet Public Key Infrastruc-
ture (IPKI).  Specifically, this document addresses requirements to pro-
vide access to Public Key Infrastructure (PKI) repositories for the pur-
poses of retrieving PKI information and managing that same  information.
The  mechanism  described  in  this document is based on the Lightweight
Directory Access Protocol (LDAP) version 2, defined  in  RFC  1777,  and
defines  a  profile of that protocol for use within the IPKI. Additional
mechanisms addressing PKIX  operational  requirements  are  specified  in
separate documents.

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-ipki2opp-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-03.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-ipki2opp-03.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.

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 2 (EuSn/CSOm) (0001BF0C)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki2opp-03.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki2opp-03 (AURL/Arch) (0001BF0D)
Content-Type: text/plain
Content-ID:	<[email-masked]>

From: <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>
Subject: FW: Coding of national characters?
Date: Mon, 22 Sep 1997 19:19:12 +0200
Status:

>As a European I understand your problem.  But 2 wrongs don't make a right!
>PrintableString is well-defined and shouldn't be misused either.  ISO 8859-1
>is a good solution for European languages, but the question is: How should it
>be coded?
>
>When will the Americans learn that there is a Rest-of-the-World?
>Mit freundlichen GrŸssen a Meilleures salutations w Kind regards
>Viktor Steiner
>[ [email-masked]  |  [email-masked] ]
>
>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	22 September 1997 10:58
>To: 	[email-masked]
>Subject: 	Coding of national characters?
>
>We have a problem...
>
>In PKIX part 1, chapter 4.1.2.4  "Issuer Name" the issuer field
>(and the subject field similarly) is defined. There are no
>mandatory X.520 attributes (like country or commonName etc)
>but the the DirectoryString is defined in ASN.1 as:
>
>>  DirectoryString ::= CHOICE {
>>           teletexString           TeletexString (SIZE (1..maxSize)),
>>           printableString         PrintableString (SIZE (1..maxSize)),
>>           universalString         UniversalString (SIZE (1..maxSize))
>
>Below this definition it is stated that:
>
>>   The directoryString is defined as a choice of PrintableString,
>>   TeletexString and UniversalString.  Conforming CAs shall choose from
>>   these options as follows:
>>
>>      (a) if the character set is sufficient, the string will be
>>      represented as a PrintableString;
>>
>>      (b) failing (a), if the teletexString charater set is sufficient,
>>      the string string will be represented as a TeletexString;
>>
>>      (c) failing (a) and (b), the string shall be represented as a
>>      UniversalString.
>
>The problem for us outside the US is how to encode national characters.
>In Sweden for example, PrintableString which is equivalent to 7-bit ASCII
>is not sufficient. According to the standard we would then make use of
>teletexString which is equivalent to the T.61 character set.
>
>Now, T.61 is an old standard that is very seldomly used nowadays. In
>particular neither Netscape Navigator nor Microsoft Internet Explorer
>make use of T.61.
>
>Instead both Navigator and Explorer uses the character set in ISO 8859-1
>(Latin-1 which is equivalent to 8-bit ASCII). This character set is used for
>both the PrintableString tag and the teletexString tag.
>
>Clearly the use of ISO 8859-1 in conjuction with the teletexString tag is an
>error and some X.500 directories won't accept this. The effect would be
>that searching these directories becomes impossible.
>
>The other alternative (ISO 8859-1 with the PrintableString tag) looks very
>attractive IMHO and I would prefer that this solution were incorporated into
>the standard. There are still problems however: many complilers based
>on ASN.1 doesn't accept 8-bit characters in a PrintableString.
>
>Can anyone on this list see a solution to this problem? If so, I would
>suggest
>that the PKIX-1 draft is updated accordinly.
>
>Regards,
>/Lars Johansson
>Sweden Post
>
>

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on [MANDATORY cert discovery capabiity]
Date: Mon, 22 Sep 1997 11:30:45 -0400
Status:

Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Friday, September 19, 1997 5:46 PM
>To: 	Arsenault, Al W.
>Cc: 	[email-masked]
>Subject: 	Re: Comments on [MANDATORY cert discovery capabiity]
>
I would personally remove from PKIX-III the "alternative directory
>protocol" and
>certificate/CRL distribution service it evidently forces on the world,
>where said messeging is not for the above purposes.
>
>At least make it non-mandatory. 
>
>"  4 Certificate/CRL discovery operations: some PKI management
>operations result in the publication of certificates or CRLs:
>  4.1 certificate publication: Having gone to the trouble of producing
>a certificate some means for publishing it is needed.  The "means"
>defined in PKIX may involve the messages specified in Sections
>3.3.13 - 3.3.16, or may involve other methods (LDAP, for example) as
>described in the "Operational Protocols" part of this series (see
>[PKIX-OP]).
>  4.2 CRL publication: As for certificate publication. "
>
>But thankyou - I had never previously understood the relevance of
>these messages to internet clients other than for simple notice/alert of
>future status. I had never realised the capability
>could be diverted for use to administering centralised access control
>(and uses therefore) to keys at remote EEs via its management of compromise
>status, and its mandatory status.
>
>yes - it seems that the 3.3.13 - 3.3.16 are attempting to
>force PKIX-3 conforming implementations to adopt a
>capability for users to use a non-directory mechanism for
>certificate and CRL distribution.
>
>I argue  hat this must be optional, for reasons along
>many of the same lines that centralised key gen was made
>optional. 
>
>I am not in major disagreement; however certificate discovery support
>should be removed from mandatory requirements. 
>
>This is good discussion - we can now seemingly remove another mandatory
>service element
>designed for an atypical environment, though allow it to be optional.
>
>Anyone disagree with a motion to remove mandatory status from cert discovery
>service elements current required for conformance to PKIX-3?

I can't emphasize enough how helpful it would be to all of us if you
would read what the document actually says before inventing something
and repeating it at least seven times (as in the excerpts above from
your previous posting).

Nothing in the document states or even suggests that the certificate or
CRL announcement PKIMessages are mandatory.  Again I point you to
Section 4 and Appendix B which profile the PKI management functionality,
and corresponding PKIMessages, that MUST be supported.  Again I ask you
to notice that certificate announcement and CRL announcement are not
there (i.e., they do not need to be supported by conforming
implementations).

Perhaps you might also look at 3.3.14 and 3.3.16, which specifically use
the word "may" rather than "must".  Perhaps you might also read the note
given in 3.3.14, which says that the only reason the certificate
announcement message exists at all is to cover those environments (if
any!) in which there is no other way to publish certificates  --  in
other words, if you have another way to publish certificates, use it
instead of this.  Perhaps you might even look more carefully at the
bullet points 4.1 and 4.2 from Section 1.3 (which you quoted above) that
say that either 3.3.14 / 3.3.16 *or* the methods given in PKIX-OP can be
used for certificate and CRL announcement (and in fact even this text
uses the word "may", thus allowing for other options as well).

Can you reproduce (and defend) the line of reasoning that led you to
believe that 3.3.14 and 3.3.16 are mandatory?  I would be willing to
correct any text that leads to such a conclusion, but at the moment I
can't find any text that needs correction...

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

Date: Mon, 22 Sep 1997 10:35:00 -0400
From: "Shah, Jay" <[email-masked]>
Subject: unsubscribe
To: [email-masked]
Status:

unsubscribe

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Simonetti David <[email-masked]>
Date: Mon, 22 Sep 1997 11:08:06 +0000
Subject: Re: encipherOnly and decipherOnly Key Usages
CC: [email-masked]
Priority: normal
Status:

In reply to your message of 19 Sep 97, 10:30:

As someone who was involved in the inital definition of this field in 
X.509, it was the intention to be able to use the key agreement key to 
encrypt a token.  I don't believe that it was intended to place further 
restictions on how the data encrypted (in this case the token) may be 
used.

I'm not sure I totally understand your question. If you are asking can 
a (preumeably symmetric) key held in the token be used for 
purposes other than encrypting a message, where the token was 
encrypted using the other parties public key agreement key provided
though a certificate with the encipherOnly bit set, probably yes.

If you can say a bit more about what you had in mind I will be happy to 
give my views.

Nick Pope

> I have a question on usage of the encipherOnly and decipherOnly key
> usages. 
>  Assume I use the pulic key agreement key to protect a token.  The
>  token in 
> turn houses the message key that was used to encrypt the message. 
> Taking X.509 literally, setting encipherOnly means that the public key
> agreement key shall only be used to encrypt the token.
> 
> In my example, is it possible (is it correct) to interpret the
> definition of encipherOnly to mean that I may only use the public key
> of that certificate as part of the process to encrypt a message,
> eventhough I am not directly using the public key agreement key to do
> so?  (And ditto for decipherOnly.)
> 
> Dave Simonetti
> Booz-Allen & Hamilton Inc.

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

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

From: <[email-masked]>
Date: Mon, 22 Sep 97 10:58:13 +0200
Subject: Coding of national characters?
To: [email-masked]
Status:

We have a problem...

In PKIX part 1, chapter 4.1.2.4  "Issuer Name" the issuer field
(and the subject field similarly) is defined. There are no
mandatory X.520 attributes (like country or commonName etc)
but the the DirectoryString is defined in ASN.1 as:

>  DirectoryString ::= CHOICE {
>           teletexString           TeletexString (SIZE (1..maxSize)),
>           printableString         PrintableString (SIZE (1..maxSize)),
>           universalString         UniversalString (SIZE (1..maxSize))

Below this definition it is stated that:

>   The directoryString is defined as a choice of PrintableString,
>   TeletexString and UniversalString.  Conforming CAs shall choose from
>   these options as follows:
>
>      (a) if the character set is sufficient, the string will be
>      represented as a PrintableString;
>
>      (b) failing (a), if the teletexString charater set is sufficient,
>      the string string will be represented as a TeletexString;
>
>      (c) failing (a) and (b), the string shall be represented as a
>      UniversalString.

The problem for us outside the US is how to encode national characters.
In Sweden for example, PrintableString which is equivalent to 7-bit ASCII
is not sufficient. According to the standard we would then make use of
teletexString which is equivalent to the T.61 character set.

Now, T.61 is an old standard that is very seldomly used nowadays. In
particular neither Netscape Navigator nor Microsoft Internet Explorer
make use of T.61.

Instead both Navigator and Explorer uses the character set in ISO 8859-1
(Latin-1 which is equivalent to 8-bit ASCII). This character set is used for
both the PrintableString tag and the teletexString tag.

Clearly the use of ISO 8859-1 in conjuction with the teletexString tag is an
error and some X.500 directories won't accept this. The effect would be
that searching these directories becomes impossible.

The other alternative (ISO 8859-1 with the PrintableString tag) looks very
attractive IMHO and I would prefer that this solution were incorporated into
the standard. There are still problems however: many complilers based
on ASN.1 doesn't accept 8-bit characters in a PrintableString.

Can anyone on this list see a solution to this problem? If so, I would suggest
that the PKIX-1 draft is updated accordinly.

Regards,
/Lars Johansson
Sweden Post

From: "Peter Williams" <[email-masked]>
To: "Arsenault, Al W." <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Date: Fri, 19 Sep 1997 14:46:39 -0700
Status:

-----Original Message-----
From: Arsenault, Al W. <[email-masked]>
To: Arsenault, Al W. <[email-masked]>; Peter Williams
<[email-masked]>
Cc: Carlisle Adams <[email-masked]>; 'Charles Moore'
<[email-masked]>; [email-masked]' <[email-masked]>
Date: Friday, September 19, 1997 1:13 PM
Subject: Re: Comments on

>
>Peter Williams wrote:
>
>>We should be clear that PKIX-CMP is not a scheme for managing certificate
>>or CRL distribution. This is the function of part II wherein operational
>>requirements are considered; different solutions are part of
>>the concept of part II, precisly as operational enviornments are
>>so different even on the public internet.
>
>>We have already discussed CRL push a few times. Many parties
>>are working on models/systems for CRL push over microsoft and marimba
>>channels. One expects these underlying transports to become true (versus
>>simulated)  push over time...
>
>>One can imagine IETF standardizing in part II a set of message formats
>>for CRL push which are transport independent, and perhaps profile
>>for transport over modern channel-distribution technologies, much
>>as PKIX-3 specifies information objects, and a number of
>>transport technologies.
>
>
>Then would you ban from PKIX-CMP ALL:
>
>          cert announcement messages
>          revocation announcement messages
>          CRL announcement messages
>          CA Key Update announcement messages
>
>or just unsolicited ones?

I would do as we agreed - operational protocols concerning status go into
PKIX-II, and management (mainly certification) protocols go into PKIX-III
(CMP,
and other bits of a multi-part document). Management of predicatable,
periodic
management operations for CA certs, and even notice concerning a user's
own about-to-expire cert, is reasonable for PKIX-III. This alert/notice
concerning
predictable future-status is reasonable use of "management channels".

I would personally remove from PKIX-III the "alternative directory protocol"
and
certificate/CRL distribution service it evidently forces on the world,
where said messeging is not for the above purposes.

At least make it non-mandatory. One can allow "PKIX-3's online-directory" to
be overloaded on the definition of a "CA" (making
such entities rather more like an permanently online Key management Center,
than
a largely offline X.509 CA)  only where highly centralised admin needs
happen
to prevail in the intended operational environment.

"  4 Certificate/CRL discovery operations: some PKI management
operations result in the publication of certificates or CRLs:
  4.1 certificate publication: Having gone to the trouble of producing
a certificate some means for publishing it is needed.  The "means"
defined in PKIX may involve the messages specified in Sections
3.3.13 - 3.3.16, or may involve other methods (LDAP, for example) as
described in the "Operational Protocols" part of this series (see
[PKIX-OP]).
  4.2 CRL publication: As for certificate publication. "

But thankyou - I had never previously understood the relevance of
these messages to internet clients other than for simple notice/alert of
future status. I had never realised the capability
could be diverted for use to administering centralised access control
(and uses therefore) to keys at remote EEs via its management of compromise
status, and its mandatory status.

>
>If you want them all banned, then how does that affect the functionality of
>PKIX-CMP?  Would PKIX-CMP by itself still be sufficient for its purposes,
or
>would you require PKIX-CMP plus some (sub)set of PKIX-2?

Your labelling of the issue as "banning" clearly deserves a comment about
the
legitimate purpose and scope of PKIX-III - which is
defined to be a cert management service and accompanying protocol
framework. It is surely not a key management service, nor a key recovery
service per se; though it can clearly work in conjunction with such services
particularly when, sometimes, the issued certs are addressing
confidentiality
and data flow control problems. Such problems are not the only problem set,
however; many
CAs in the Internet PKI are quite likely to serve authentication needs only.

We clearly cannot make a cert mgt service which suits every operational
need, those
with rigorous requirements for unifed key/cert management are one group, and
those which
are using persona-fun certificates are another, for example. Nor, from the
style
of the comments received on the issue of previously-mandatory centralised
key generation
support, would the WG seems to favour a general direction to FORCE a link
and mandatory deployed capability between cert management and other related
key-management functions, including online CA-based revocation/comrpomised
alerting.

Certificates and their management service need to roam free to serve purely
authentication-only
purposes, and their CA may well be accessed only via offline transports.

>
>If you just want unsolicited announcements banned (i.e., these messages
>would still be supported for use in specific circumstances during the
>certificate management process), how can that be efficient?  You would be
>duplicating functionality by having the same things - cert announcements,
>CRL announcements, etc. - implemented twice just to support some notion of
>"protocol purity".

Lets deal with this language, and consider internet standards goals.

We have to recall that standards evolve and some parts are used in
one environment and other parts in other enviornments. Its a
toolkit. We are not designing here a national PKI/KMI/KRI. Rather
we are setting standards for an "internet-management-cultured" PK
infrastructure
whose precise use and enviornment is rather unknown. Interworking
is the goal, not uniformity of acess, or some particular quality(s) of
service;
this will evolve over time as residential/organizational/personal/ ...
usage patterns are determined. Many EEs will also use
propiretary or USgovt specified KM I or KRI protocols, also.

We have to recall that we are fundamentally a X.509 group. The model of that
standard
is directory-centric, with offline CAs. One performs certificate management
at the outset
of a relationship with a CA, then one uses a directory to manage
the certs thereafter. This model is built into the semantics; they
are wholly cert-centric servifng to distribute authentication
keys; not key-centric to control key usage by application protocols.

In PKIX architcture, this comes down to a separtion of function -
part III for initialization/registration/certification, and use of Part II
to embrace various kinds of directories (ldap, http, and "real-time"
so far). If one is renewing ones encryption cert, sure the CA should
be able to alert you that your signature key expires next week. (Many
CA-linked directories may well do the same as part of their competitive
value-add.)

yes - it seems that the 3.3.13 - 3.3.16 are attempting to
force PKIX-3 conforming implementations to adopt a
capability for users to use a non-directory mechanism for
certificate and CRL distribution.

I argue  hat this must be optional, for reasons along
many of the same lines that centralised key gen was made
optional. Such interaction with a common cert discovery/alert
services  more naturally happens at layer protocols - e.g. SKIP, S/MIME, SSL
 etc if these implementations do not use directories for the same. SKIPs
interface to a notice databased maintained by the CA concerning
status of CA-cert foo, should happen in the natural SKIP way,
protected via IPSEC. Similarly SSL, etc.

>
>Personally, I'd rather let those who want to support these announcements
>using PKIX-CMP do so, if it simplifies their software architecture.  Then
>use the appropriate PKIX-2 delivery mechanism to distribute these
>announcements.

I am not in major disagreement; however certificate discovery support
should be removed from mandatory requirements. Those entities
which maintain constant online contact with a CA, can use that CA's
PKIX-3 object discovery/announcement sub-protocol to determine (pending)
status of certs and CRLs.

An offline news reader program checking
signature on mails should not be forced to implement such
capability, however, for nothing; a CA which only offers weekly certs
again should not be forced to provide the communications port
for this online element of service. Many CAs will be wholly offline, and
based
on email or floppy transport only for the interaction with the CA.

This is good discussion - we can now seemingly remove another mandatory
service element
designed for an atypical environment, though allow it to be optional.

Anyone disagree with a motion to remove mandatory status from cert discovery
service elements current required for conformance to PKIX-3?

>
>
>               Al Arsenault
>
>     - speaking only for myself
>
>
>

Peter.

Attachment converted: Lutefisk:Peter Williams.vcf (TEXT/R*ch) (0001BEDC)

From: "Arsenault, Al W." <[email-masked]>
To: "Arsenault, Al W." <[email-masked]>, Peter Williams <[email-masked]>
Cc: Carlisle Adams <[email-masked]>, "'Charles Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Comments on
Date: Fri, 19 Sep 97 16:13:00 EDT
Encoding: 53 TEXT
Status:

Peter Williams wrote:

>We should be clear that PKIX-CMP is not a scheme for managing certificate
>or CRL distribution. This is the function of part II wherein operational
>requirements are considered; different solutions are part of
>the concept of part II, precisly as operational enviornments are
>so different even on the public internet.

>We have already discussed CRL push a few times. Many parties
>are working on models/systems for CRL push over microsoft and marimba
>channels. One expects these underlying transports to become true (versus 
>simulated)  push over time...

>One can imagine IETF standardizing in part II a set of message formats
>for CRL push which are transport independent, and perhaps profile
>for transport over modern channel-distribution technologies, much
>as PKIX-3 specifies information objects, and a number of
>transport technologies.

Then would you ban from PKIX-CMP ALL:

          cert announcement messages
          revocation announcement messages
          CRL announcement messages
          CA Key Update announcement messages

or just unsolicited ones?

If you want them all banned, then how does that affect the functionality of 
PKIX-CMP?  Would PKIX-CMP by itself still be sufficient for its purposes, or 
would you require PKIX-CMP plus some (sub)set of PKIX-2?

If you just want unsolicited announcements banned (i.e., these messages 
would still be supported for use in specific circumstances during the 
certificate management process), how can that be efficient?  You would be 
duplicating functionality by having the same things - cert announcements, 
CRL announcements, etc. - implemented twice just to support some notion of 
"protocol purity".

Personally, I'd rather let those who want to support these announcements 
using PKIX-CMP do so, if it simplifies their software architecture.  Then 
use the appropriate PKIX-2 delivery mechanism to distribute these 
announcements.

               Al Arsenault

     - speaking only for myself

Date: Fri, 19 Sep 1997 11:50:42 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: verisign
To: "Arsenault, Al W." <[email-masked]>
CC: Carlisle Adams <[email-masked]>, "'Charles Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Comments on
Status:

Arsenault, Al W. wrote:

>
>
> This may be a matter of semantics, but we'll see.  I believe that there is a
> need for a CA, RA, other entity to send out "unsolicited response" messages.
>  That is, a CA may want to send a CRLannounce message to users, even though
> users have not asked for them, because local policy dictates that you push a
> new CRL out whenever a key has been determined to be compromised.  If one
> regards such messages to be "response" messages, then the current PKIX-CMP
> is acceptable.  If one regards such a message to be a "distribution message
> that was not a request or response", then that concept needs to be
> supported.

We should be clear that PKIX-CMP is not a scheme for managing certificate
or CRL distribution. This is the function of part II wherein operational
requirements are considered; different solutions are part of
the concept of part II, precisly as operational enviornments are
so different even on the public internet.

We have already discussed CRL push a few times. Many parties
are working on models/systems for CRL push over microsoft and marimba channels.
One expects these underlying transports to become true (versus simulated) push
over
time...

One can imagine IETF standardizing in part II a set of message formats
for CRL push which are transport independent, and perhaps profile
for transport over modern channel-distribution technologies, much
as PKIX-3 specifies information objects, and a number of
transport technologies.

From: "Arsenault, Al W." <[email-masked]>
To: Carlisle Adams <[email-masked]>, "'Charles Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Comments on
Date: Fri, 19 Sep 97 12:45:00 EDT
Encoding: 96 TEXT
Status:

Responding to Charles Moore, Carlisle Adams wrote:

>Hi Charles,

<large snip>

>>ADD to 3.1.2 PKI Message Body
>>Add an additional  branch be added to the CHOICE.  The
>>additional branch would be:
>>
>>   other [48] SEQUENCE {
>>             oid  OBJECT IDENTIFIER,
>>             value     ANY DEFINED BY oid  }
>>
>>The tag number does not concern me.
>>
>>RATIONAL: Missed in update

>I didn't mean to overlay too much semantic intent on my choice of the
>name "GenReq" in this submission; I simply meant "request" to represent
>any unsolicited message going out from an entity ("response", on the
>other hand, was a solicited message, a reply to a message that was
>received).

>In any case, I can see why this might not be clear, so I'm willing to
>add another branch to CHOICE.  Can I make it perfectly general and
>specify it as a SET OF {OID,value} pairs (as was added to PKIHeader)?

For what it's worth, I agree with the suggestions from Charles and Russ.
I'm in the process of trying to plan a migration of my hierarchy  from an 
existing "custom" certificate management protocol to PKIX-CMP.  My current 
protocol has (and my users will continue to need) a variety of messages 
dealing with things like firmware updates for hardware tokens, special 
"lists" of compromised keys, etc.  These are almost certainly of no interest 
to most PKIX-CMP users.  However, from my somewhat selfish viewpoint, it's a 
heck of a lot easier to implement PKIX-CMP, plus a few locally-defined 
"other" message, than it is to implement PKIX-CMP, and then add an extra 
protocol to do the rest of the stuff.  I believe that the format that 
Charles and Russ suggested is the best/easiest/clearest way to do this.

Re:  SET OF {OID, value} pairs:  I don't care about this.  I'm going to 
implement as "one PKIX-CMP-extended message at a time".  If you want to have 
the ability to send "multiple locally-defined messages at a single time", 
fine.  I don't see any need for it, but others might.

>By the way, one comment from your posting yesterday.  You said "The
>requested extension had the ability to define the symantics of the
>operation, such as a distribution message that was not a request or
>response."  Note that PKIX-CMP is inherently a point-to-point protocol
>for the explicit purpose of doing certificate management functions; I
>don't think that distribution messages fit within this framework.

This may be a matter of semantics, but we'll see.  I believe that there is a 
need for a CA, RA, other entity to send out "unsolicited response" messages. 
 That is, a CA may want to send a CRLannounce message to users, even though 
users have not asked for them, because local policy dictates that you push a 
new CRL out whenever a key has been determined to be compromised.  If one 
regards such messages to be "response" messages, then the current PKIX-CMP 
is acceptable.  If one regards such a message to be a "distribution message 
that was not a request or response", then that concept needs to be 
supported.

>>REPLACE
>>CertificateValidityDate ::= CHOICE {
>>      utcTime        UTCTime,
>>      generalTime    GeneralizedTime
>>  }
>>
>>WITH
>>CertificateValidityDate ::= GeneralizedTime
>>
>>RATIONAL: There is no need to support the legacy UTCTime in the request.

>This is only used in the certificate template and it's only there
>because that's the way certificates are currently specified.  In other
>words, it was specified that way so that the template could be
>constructed to look exactly like the requester wanted the certificate to
>look.

>I believe someone on the list requested this.

If nobody has previously requested this, I'll make such a request now.   I 
want to support the operational scenario where a new user creates his own 
to-be-signed-certificate, in the exact format (to include the user-generated 
public key :-) that the user desires the end product to look like - the only 
thing missing would be the CA's signature.  The CA will then examine the 
certificate, determine that it is acceptable, sign it, and send it back.  If 
the CA has to do a time-format change, that's an unnecessary burden that 
just slows down processing.

                    Al Arsenault

     - speaking only for myself.

Date: Fri, 19 Sep 1997 07:54:35 -0700
To: [email-masked]
From: Fred Baker <[email-masked]>
Subject: Costs of Mandatory Key Recovery
Status:

If you could email any hard numbers as to expected costs to Don Heath
<[email-masked]>, it would be helpful.

>>Date: Wed, 17 Sep 1997 10:55:55 -0400
>>From: Philip Webre <[email-masked]>
>>To: [email-masked]
>>Subject: Costs of Mandatory Key Recovery
>>Content-Disposition: inline
>>
>>As I explained over the telephone, we are trying to estimate
>>the private sector costs associated with mandatory key
>>recovery in the US.  Thursday the House Intelligence
>>Committees passed an amended version of HR 695 that
>>would mandate immediate key recovery in all encryption
>>products sold, imported or distributed in the US after
>>January 31, 2000.  It further imposes this requirement
>>on Internet service providers who provide encryption
>>services when presented by a warrant from a duly authorized
>>law enforcement official.
>>
>>We expect that within an organization like a corporate
>>LAN, key recovery can be mandated in a straight forward
>>manner.  But since the relationship between an ISP
>>and its client is more distant, very different mechanisms
>>and cost structure would surface.  I would be very
>>interested in any information you could provide regarding
>>the costs associated with such a mandate.
>>
>>Address:
>>Philip Webre
>>Congressional Budget Office
>>Natural Resources and Commerce Division
>>495 Ford House Office Bldg.
>>Washington, D.C. 20515
>>Fax Number:  202-226-0207
>>Voice:       202-226-2940
>>Internet:    [email-masked]
>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Planning is bringing the future into the present so that you can do
something about it now." Alan Lakein

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-04.txt
Date: Fri, 19 Sep 1997 09:46:19 -0400
Sender: [email-masked]
Status:

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     
                          Certificate Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-ipki3cmp-04.txt
	Pages		: 69
	Date		: 1997-09-17
	
This is a draft of the Internet Public Key Infrastructure (X.509)
Certificate Management Protocols. Protocol messages are defined for all
relevant aspects of certificate creation and management.

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-ipki3cmp-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-04.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-ipki3cmp-04.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.

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 1 (EuSn/CSOm) (0001BE9F)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki3cmp-04.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki3cmp- 1 (AURL/Arch) (0001BEA0)
Content-Type: text/plain
Content-ID:	<[email-masked]>

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Charles Moore'" <[email-masked]>
Subject: RE: Comments on 
Date: Fri, 19 Sep 1997 10:22:36 -0400
Status:

Hi Charles,

>----------
>From: 	Charles Moore[SMTP:[email-masked]]
>Sent: 	Thursday, September 18, 1997 5:11 PM
>To: 	[email-masked]
>Subject: 	Comments on 
>
>REPLACE:
>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, RA equipment, and EE equipment must support the second 
>scheme listed below. Any entity may additionally support other schemes,
>if desired.
>
>WITH
>The criteria above allow for a number of initial registration / 
>certification schemes. This specification does not mandate a particular
>scheme, but describes two schemes in the following sections. Any entity
>may support these or other schemes, if desired.
>A future PKIX specification will support key generation protocol
>requirements.
>
>RATIONAL: Document agreements.

This is analogous to the discussions on algorithms heard so often in
various IETF Working Groups, and the reasoning here is identical.  There
must be at least one mandatory method otherwise you lose guaranteed
interoperability.  Just like every WG has had to pick a particular
algorithm and say "you can support a million algs if you want, but you
MUST support this one", I think we have to do the same with
initialization schemes.

>REPLACE
>2.2.2.1 Centralized scheme
>
>In terms of the classification above, this scheme is, in some ways, 
>the simplest possible, where:
>
>- initiation occurs at the certifying CA;
>- no on-line message authentication is required;
>- "key generation" occurs at the certifying CA (see Section 2.2.1.3);
>- no confirmation message is required.
>
>WITH
>2.2.2.1 Centralized scheme
>
>In this scheme:
>
>- initiation occurs at the CA or RA entity;
>- no on-line message authentication is required;
>- "key generation" occurs at the RA or CA entity;
>- no confirmation message is required.
>
>RATIONAL: Changes to align with stated requirements in previous sections
>to allow generation at the RA.

This scheme is chosen to represent the "simplest possible" scheme, where
only one PKIMessage is sent in the initialization process.  As soon as
you expand it to allow an RA, you break this and go back to at least 3
(possibly 4) messages.  Previous sections of course talk about key
generation at the RA (or elsewhere), but this particular scheme, like
the basic authenticate scheme, is one specific configuration out of all
the ones that could have been chosen.

>ADD to 3.1.2 PKI Message Body 
>Add an additional  branch be added to the CHOICE.  The
>additional branch would be:
>
>	other [48] SEQUENCE {
>			oid	OBJECT IDENTIFIER,
>			value	ANY DEFINED BY oid  }
>
>The tag number does not concern me.
>
>RATIONAL: Missed in update

I didn't mean to overlay too much semantic intent on my choice of the
name "GenReq" in this submission; I simply meant "request" to represent
any unsolicited message going out from an entity ("response", on the
other hand, was a solicited message, a reply to a message that was
received).

In any case, I can see why this might not be clear, so I'm willing to
add another branch to CHOICE.  Can I make it perfectly general and
specify it as a SET OF {OID,value} pairs (as was added to PKIHeader)?

By the way, one comment from your posting yesterday.  You said "The
requested extension had the ability to define the symantics of the
operation, such as a distribution message that was not a request or
response."  Note that PKIX-CMP is inherently a point-to-point protocol
for the explicit purpose of doing certificate management functions; I
don't think that distribution messages fit within this framework.

>REPLACE 
>CertificateValidityDate ::= CHOICE {
>      utcTime        UTCTime,
>      generalTime    GeneralizedTime
>  }
>
>WITH
>CertificateValidityDate ::= GeneralizedTime
>
>RATIONAL: There is no need to support the legacy UTCTime in the request.

This is only used in the certificate template and it's only there
because that's the way certificates are currently specified.  In other
words, it was specified that way so that the template could be
constructed to look exactly like the requester wanted the certificate to
look.

I believe someone on the list requested this.

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

Date: Fri, 19 Sep 1997 10:30 -0500
From: "Simonetti David" <[email-masked]>
To: [email-masked]
Subject: encipherOnly and decipherOnly Key Usages
Status:

I have a question on usage of the encipherOnly and decipherOnly key usages. 
 Assume I use the pulic key agreement key to protect a token.  The token in 
turn houses the message key that was used to encrypt the message.  Taking 
X.509 literally, setting encipherOnly means that the public key agreement 
key shall only be used to encrypt the token.

In my example, is it possible (is it correct) to interpret the definition of 
encipherOnly to mean that I may only use the public key of that certificate 
as part of the process to encrypt a message, eventhough I am not directly 
using the public key agreement key to do so?  (And ditto for decipherOnly.)

Dave Simonetti
Booz-Allen & Hamilton Inc.

From: Charles Moore <[email-masked]>
To: [email-masked]
Subject: Comments on 
Date: Fri, 19 Sep 1997 07:11:23 +1000
Status:

REPLACE:
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, RA equipment, and EE equipment must support the second 
scheme listed below. Any entity may additionally support other schemes,
if desired.

WITH
The criteria above allow for a number of initial registration / 
certification schemes. This specification does not mandate a particular
scheme, but describes two schemes in the following sections. Any entity
may support these or other schemes, if desired.
A future PKIX specification will support key generation protocol
requirements.

RATIONAL: Document agreements.

REPLACE
2.2.2.1 Centralized scheme

In terms of the classification above, this scheme is, in some ways, 
the simplest possible, where:

- initiation occurs at the certifying CA;
- no on-line message authentication is required;
- "key generation" occurs at the certifying CA (see Section 2.2.1.3);
- no confirmation message is required.

WITH
2.2.2.1 Centralized scheme

In this scheme:

- initiation occurs at the CA or RA entity;
- no on-line message authentication is required;
- "key generation" occurs at the RA or CA entity;
- no confirmation message is required.

RATIONAL: Changes to align with stated requirements in previous sections
to allow generation at the RA.

ADD to 3.1.2 PKI Message Body 
Add an additional  branch be added to the CHOICE.  The
additional branch would be:

	other [48] SEQUENCE {
			oid	OBJECT IDENTIFIER,
			value	ANY DEFINED BY oid  }

The tag number does not concern me.

RATIONAL: Missed in update

REPLACE 
CertificateValidityDate ::= CHOICE {
      utcTime        UTCTime,
      generalTime    GeneralizedTime
  }

WITH
CertificateValidityDate ::= GeneralizedTime

RATIONAL: There is no need to support the legacy UTCTime in the request.

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

From: Charles Moore <[email-masked]>
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: PKIX-CMP
Date: Fri, 19 Sep 1997 06:35:45 +1000
Status:

> -----Original Message-----
> From:	Carlisle Adams [SMTP:[email-masked]]
> Sent:	Thursday, 18 September 1997 2:03
> To:	[email-masked]'
> Subject:	PKIX-CMP
> 
> Hi,
> 
> I [Charles Moore]  --deleted
>  5) Charles Moore requested hooks for extensibility in the PKIBody
> (this
> was also requested by Russ Housley in a later message to the list).
> It
> turns out that the extensibility was already there; it just wasn't
> obvious.  (The PKIInfoReqContent and PKIInfoRepContent bodies are SETs
> of {OID,value} pairs and so immediately fill the requirement.)
> [Charles Moore]  This is a different solution to what was requested.
> Your solution has fixed symantics of request and response.
> The requested extension had the ability to define the symantics of the
> operation, such as a distribution message that was not a request or
> response.
> 
>   I have
> renamed these to GenReqContent and GenRepContent to emphasize their
> general nature and have explicitly stated (see p.35) that these may be
> used to define new request and response messages for future needs or
> for
> specific environments.
> [Charles Moore]  That is good, but is not related to the requested
> change. 
> If the original request ( Russ solution is ok) could be added that
> would be great.
> 
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------
> 
> >

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-04.txt
Date: Thu, 18 Sep 1997 09:50:03 -0400
Sender: [email-masked]
Status:

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     
                          Certificate Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-ipki3cmp-04.txt
	Pages		: 69
	Date		: 1997-09-17
	
This is a draft of the Internet Public Key Infrastructure (X.509)
Certificate Management Protocols. Protocol messages are defined for all
relevant aspects of certificate creation and management.

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-ipki3cmp-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-04.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-ipki3cmp-04.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.

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pkix- (EuSn/CSOm) (0001BE92)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki3cmp-04.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki3cmp-04 (AURL/Arch) (0001BE93)
Content-Type: text/plain
Content-ID:	<[email-masked]>

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: RE: PKIX-CMP
Date: Wed, 17 Sep 1997 16:07:24 -0400
Status:

Hi Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Wednesday, September 17, 1997 2:28 PM
>To: 	Carlisle Adams; [email-masked]
>Subject: 	Re: PKIX-CMP
>
><<File: smime.p7s>>
>
>>1) Centralized key generation (i.e., at the CA) is now optional; the
>>"basic authenticated scheme" is the only mandatory initialization
>>scheme.
>
>Please explain this. What does it mean, and what are the consequences
>and the rationale?
>
>What is an initialization scheme?

Re-read Section 1.3 item 3.1, Section 2.2.1.1, Section 2.2.1.2, and
Section 2.2.2.2 (they're all short) and see if this helps.  If not, ask
again.  All we're saying is that out-of-band means are used to bootstrap
the process.

>Preconditions:
>1. The end entity can authenticate the CA=92s signature based on out-of-
>band means
>2. The end entity and the CA share a symmetric MACing key"
>
>And I ask myself (and hopefully it will be answered in response to
>my non-leading question) how does one bootstrap the PKIX-CMP?
>
>I.E. How does one obtain satisfaction of the pre-conditions?
>
>Are these non-standard mechanisms shared between particular
>entities using one bit of software, and some subsection of the
>operational CAs also using that bit of software?

"Out-of-band" simply means out of band.  That is, information is passed
between the EE (that wants to join the PKI) and the PKI entity (CA or
RA) in a way not specified in this document.  It might be a physical
visit; it might be physical mail; it might be a telephone call; it might
be e-mail; it might be a guy in a trenchcoat with a briefcase handcuffed
to his wrist.  [Whatever policy dictates.]  As long as that information
exchange is separate from the PKIX-CMP protocols, and is "trustable" by
both sides, that's fine.

Part of that out-of-band information might be the CA's public key (to
satisfy precondition 1).  Alternatively, the out-of-band information
might only be secret information (a password) from which each side can
derive a MACing key using PasswordBasedMac (this satisfies precondition
2, and when this key is used to protect the CMP initialization messages,
then the CA can send its public key in the response, which satisfies
precondition 1).

I guess I'm not sure which part of all this you're questioning or not
understanding...

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

From: "Peter Williams" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>, <[email-masked]>
Subject: Re: PKIX-CMP
Date: Wed, 17 Sep 1997 11:28:53 -0700
Status:

>1) Centralized key generation (i.e., at the CA) is now optional; the
>"basic authenticated scheme" is the only mandatory initialization
>scheme.

Please explain this. What does it mean, and what are the consequences
and the rationale?

What is an initialization scheme?

(Im trying to ask open, non-leading questions; please do not abuse the
questioner
for so asking; assume the list requires tutoring)

------

Here is my understanding, and why Im bothering to comment.

"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).
Certification may only be requested for one locally generated public key
(for more, use separate PKIMessages).

The end entity must support proof-of-possession of the private key
associated with the locally-generated public key.

Preconditions:
1. The end entity can authenticate the CA=92s signature based on out-of-
band means
2. The end entity and the CA share a symmetric MACing key"

And I ask myself (and hopefully it will be answered in response to
my non-leading question) how does one bootstrap the PKIX-CMP?

I.E. How does one obtain satisfaction of the pre-conditions?

Are these non-standard mechanisms shared between particular
entities using one bit of software, and some subsection of the
operational CAs also using that bit of software?

Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 11 (????/----) (0001BE7C)

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: PKIX-CMP
Date: Wed, 17 Sep 1997 12:02:45 -0400
Status:

Hi,

I have just submitted PKIX Certificate Management Protocols (used to be
PKIX-3, but it was agreed in Munich that part numbers were to be removed
from the various documents) to the Internet-Drafts address  -- it should
show up soon at the usual repositories.

I believe this draft is now ready for last call, as agreed in Munich and
reiterated (after some debate) recently on this list, and have asked the
chairs to issue this call once the document is readily available.

The changes incorporated are as follows.

1) Centralized key generation (i.e., at the CA) is now optional; the
"basic authenticated scheme" is the only mandatory initialization
scheme.

2) It is noted (see pages 10 and 21) that a general key generation
request/response protocol, and that a PKCS #7 protection mechanism, may
be specified in separate documents.

3) AlgIDs, references, and modulus lengths (where appropriate) have been
given for all mandatory algorithms in Appendix B; see p.49.

4) In re-reading Section 4, I discovered that we were mandating
"certificate update" (a new certificate for an existing key) as opposed
to "key update" (a new certificate for a new key); see p.40 of the
previous draft.
[A slight cut-and-paste error that must have happened ages ago  --  I'm
surprised no one noticed this earlier...]  This has been fixed (and
Appendix B has been updated to support this).

5) Charles Moore requested hooks for extensibility in the PKIBody (this
was also requested by Russ Housley in a later message to the list).  It
turns out that the extensibility was already there; it just wasn't
obvious.  (The PKIInfoReqContent and PKIInfoRepContent bodies are SETs
of {OID,value} pairs and so immediately fill the requirement.)  I have
renamed these to GenReqContent and GenRepContent to emphasize their
general nature and have explicitly stated (see p.35) that these may be
used to define new request and response messages for future needs or for
specific environments.

6) Rich Ankney, in conjunction with the above, requested extensibility
in the individual messages as well, either in PKIHeader or in each
PKIBody.  It seemed to make more sense to put it in the header, so I
have added an OPTIONAL SET OF {OID,value} pairs there.

That's it, other than general editing/formatting/typo cleanup.

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

>

From: Charles Moore <[email-masked]>
To: Russ Housley <[email-masked]>, Warwick Ford <[email-masked]>
Cc: [email-masked]
Subject: RE: PKIX Part I - Name Constraints
Date: Tue, 16 Sep 1997 15:06:46 +1000
Status:

> -----Original Message-----
> From:	Russ Housley [SMTP:[email-masked]]
> Sent:	Tuesday, 16 September 1997 0:34
> To:	Warwick Ford
> Cc:	[email-masked]
> Subject:	Re: PKIX Part I - Name Constraints
> 
> At 08:07 PM 9/13/97 -0400, Warwick Ford wrote:
> >>2.  To deal with the exception that you propose, we need to add a
> >>dependency between rfc822 alt names and X.500 Distinguished Names.
> I do
> >>not like this if we can avoide it.
> >
> >RFC822 names in altnames are not impacted.  They are treated exactly
> as in
> >the standard.  In fact, nothing related to the standard is impacted.
> What
> >I am proposing is simply one additional rule that PKIX imposes, which
> is a
> >perfectly reasonable thing for a profile to do.  If there is an
> RFC822 name
> >constraint in force, we just impose one further check on the Subject
> field.
> > Very straightforward to implement (if you are already implementing
> name
> >constraint logic).
> >
> >Without this rule, I believe that many early Name Constraints
> >implementations will have a major loophole.  I think it is a PKIX
> >obligation to provide the rules to secure the migration from the old
> ways
> >to the new ways.
> 
> [Charles Moore]  I think there are two separate issues here a) the
> attribute support within the DN and b) the support for name forms.
> 
> With regard to the first, PKIX should NOT limit support, all
> implementations should be able to support any attributes here ( it
> really not a big deal). The support for RSA SMIME is but one example
> and should not be singled out within PKIX. But I would agree that if
> there is support for the PKCS9 e-mail attribute then these should be
> constant with RFC822, but others may have a different view.
> 
> With regard to b) DN's are ok, altnames are ok as well, PKIX should
> not force a particular implementation choice, just ensure support for
> both forms is available.
> 
> 
> 
> I would like to encourage the fastest possible migration to the use of
> alt
> names.  And, I agree that we need to accomodate fielded solutions
> during
> that transition.
> 
> In addition to changes in the name constraints section, a forward
> pointer
> should probably be added to section 4.1.2.6 too.
> 
> Do you have proposed text?
> 
> Russ

Date: Mon, 15 Sep 1997 10:34:25 -0400
To: Warwick Ford <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PKIX Part I - Name Constraints
Cc: [email-masked]
Status:

At 08:07 PM 9/13/97 -0400, Warwick Ford wrote:
>>2.  To deal with the exception that you propose, we need to add a
>>dependency between rfc822 alt names and X.500 Distinguished Names.  I do
>>not like this if we can avoide it.
>
>RFC822 names in altnames are not impacted.  They are treated exactly as in
>the standard.  In fact, nothing related to the standard is impacted.  What
>I am proposing is simply one additional rule that PKIX imposes, which is a
>perfectly reasonable thing for a profile to do.  If there is an RFC822 name
>constraint in force, we just impose one further check on the Subject field.
> Very straightforward to implement (if you are already implementing name
>constraint logic).
>
>Without this rule, I believe that many early Name Constraints
>implementations will have a major loophole.  I think it is a PKIX
>obligation to provide the rules to secure the migration from the old ways
>to the new ways.

I would like to encourage the fastest possible migration to the use of alt
names.  And, I agree that we need to accomodate fielded solutions during
that transition.

In addition to changes in the name constraints section, a forward pointer
should probably be added to section 4.1.2.6 too.

Do you have proposed text?

Russ

From: "Peter Williams" <[email-masked]>
To: "Mike Smith" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Policy Contraints Object Identifier
Date: Mon, 15 Sep 1997 12:42:42 -0700
Status:

<html><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.71.1703.0"' name=GENERATOR>
</HEAD>
<BODY>
<DIV>&nbsp; &nbsp;</DIV>
<DIV><BR>&nbsp;</DIV>
<DIV>-----Original Message-----<BR>From: Mike Smith &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;<BR>To: <A 
href="mailto:[email-masked]">[email-masked]</A> &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;; <A 
href="mailto:[email-masked]">[email-masked]</A> &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;<BR>Cc: <A 
href="mailto:[email-masked]">[email-masked]</A> &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;<BR>Date: Friday, 
September 12, 1997 8:04 AM<BR>Subject: Re: Policy Contraints Object 
Identifier<BR><BR></DIV>
<DIV>&gt;Policy mapping would imply re-issuance to get the new mappings onto the 
required certs.&nbsp; I believe this is a classic case for cross certification 
for each (BBN and GTE) authority, recognizing the root public key as a CA in 
their own hierarchy (if they have a hierarchy) or chain (web) of 
trust.<BR>&gt;<BR>&gt;Michael&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<P><FONT face=Courier>Mike,</FONT></P>
<P><FONT face=Courier>In the last 7 years, I have heard that offline 
cross-certification will<BR>seemingly &quot;solve&quot; any cert domain- or 
management problem one cares to<BR>characterise; its a magic bullet to be loaded 
&amp; fired whenever a trust or<BR>recovery (vs issuing) scenario is 
encountered. Under controlled management,<BR>I'm not so sure this 
one-stop-shopping experience is quite so<BR>sound as many make out. Lets look 
more deeply based on v. large-scale<BR>environments which have received much 
actual analysis. (Just<BR>as 1422 contained a domain-model and rationale, 
perhaps PKIX 1 (or 3)<BR>needs to embrace some guidance on the authority/naming 
structures<BR>anticipated for <STRONG>Internet PKI 
</STRONG>scenarios.)</FONT></P>
<P><FONT face=Courier>I was (indirectly) thinking about a DoD ops concept when I 
wrote the<BR>problem statement. It is expected that, every ~2 years, service men 
and<BR>women will become based in new localities, even though their 
home<BR>regiment, or core, or other organizational unit, stays 
constant<BR>during the move, as does their personal rank and 
title.</FONT>&nbsp;</P>
<P><FONT face=Courier>This is a lot of regular name changing, either in the 
directory indexes,<BR>or the names in certs, if cert subject-names convey 
any<BR>locality info.</FONT>&nbsp;</P>
<P><FONT face=Courier>In a token-centric world, this means given your 
troops<BR>a (re)new(ed) Fortezza-card (or RSA smartcard) every two years. 
<BR>While you are at this expensive task, issue them a new cert (or<BR>two) when 
they get to the new base and commence their<BR>new job in a new 
command.</FONT>&nbsp;</P>
<P><FONT face=Courier>I do not imagine a cross-certification scenario here. 
Rather,<BR>its more of a periodic re-org, where everyone gets new names/tokens, 
and<BR>any associated privileges due to the change in their 
enviornment/job.</FONT>&nbsp;</P>
<P><FONT face=Courier>Many corporate mergers are re-orgs (and sometimes mass 
<BR>layoffs/revocations) versus friendly merging of assets, know-how, etc. 
<BR>Firing 2000 people overnight makes for a large CRL in the morning<BR>even if 
you rehire 1900 of them next day on new contracts<BR>with a new corporate 
identity.</FONT>&nbsp;</P>
<P><FONT face=Courier>As I say, this second-order domain management control is a 
fun topic. The<BR>more you regulate it with complex name schemas, and perform 
key management,<BR>based upon name-management dynamics, the more intractable it 
becomes even<BR>with the support of a well-managed centralised and ubiquitous 
directory<BR>performing name management (not certificate/CRL 
distribution).</FONT>&nbsp;</P>
<P><FONT face=Courier>In a &quot;prototype&quot; &quot;Internet PKI&quot; we 
have been running in<BR>the PKI industry for 2 years now we had a philosophy of 
- keep names out<BR>of the picture until momentum has built to undersatnd the 
obvious value of<BR>certs per se: name management debates are endless! When its 
time (i.e the <BR></FONT><FONT face=Courier>market expects more and greater 
discretionay control) move to<BR>schematise naming as an option to those local 
domains who desire<BR>name-based controls.</FONT>&nbsp;</P>
<P><FONT face=Courier>It may be time to clean up all our acts generally on 
names, now that there <BR>is a discerning corporate/organizational market 
attaching itself to the<BR>residential PKI and the evolving, open management 
infrastructure for<BR>inter-domain secured interworking.</FONT>&nbsp;</P>
<P><FONT face=Courier>Peter.</FONT></P>
<P><BR>&gt;<BR>&gt;&gt;&gt;&gt; Peter Williams &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt; 09/11/97 03:55PM 
&gt;&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt; &gt;Thanks,<BR>&gt;&gt; &gt;Jean 
Duffy<BR>&gt;&gt; &gt;<BR>&gt;&gt; &gt;GTE Internetworking<BR>&gt;&gt; 
&gt;Powered by BBN<BR>&gt;<BR>&gt;<BR>&gt;I know BBN an GTE have been off and on 
friends for years; but<BR>&gt;its still a little sad for us Internet types to 
see any diminishment<BR>&gt;of the BBN name!<BR>&gt;<BR>&gt;Corporate mergers of 
this sort are, of course, common.<BR>&gt;<BR>&gt;Lets say BBN has issued 50,000 
certs to employees, and GTE corporate<BR>&gt;dictum now wanted to change 
everyone over to [a-z][email-masked]. (I<BR>&gt;do not know if they do or do 
not.)<BR>&gt;<BR>&gt;Obviously one way to do it is to revoke and reissue all 
certs (and<BR>&gt;handle 50,000 tokens if token-based).<BR>&gt;<BR>&gt;Another 
way is to revoke the BBN CA(s), and start again with<BR>&gt;new trust 
points.<BR>&gt;<BR>&gt;How would PKIX technology migrate folk intelligently? A 
policy mapping, or<BR>&gt;name mapping in a renewed BBN CA certificate, 
perhaps?<BR>&gt;<BR>&gt;This is a fun topic, after all the recent fuss. It 
will<BR>&gt;not be long before someone has to deal with precisely<BR>&gt;this 
scenario.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
!<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<BR>&gt;&nbsp;</P></BODY></HTML>

</html>Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 9 (????/----) (0001BDF7)

Date: Mon, 15 Sep 1997 09:53:07 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX Part I - Name Constraints
Status:

> From: Warwick Ford <[email-masked]>
> 
> I wish to propose a minor addition to 4.2.1.11 (Name Constraints) of PKIX
> Part I.  
> 
> Regarding RFC822Name, the most common way to convey an e-mail address today
> is as a PKCS#9 e-mail attribute in the subject DN.  Migration to
> subjectAltNames will undoubtedly occcur in time, and the profile correctly
> covers that future.  However, to ensure that the intent of Name Constraints
> is met given current styles of naming, I propose that we additionally state
> that "Restrictions for the rfc822 name form shall also apply to any
> instance of the PKCS#9 E-mail Name attribute type present in a subject DN."

I agree with the proposal.

But that brings up the question of which name representations are "better"
from a design perspective.

My uninformed intuition suggests that name forms like email addresses,
locally-defined (SDSI-type) names, the "persistent IDs" discussed here
a few months back, as well as other AltName forms such as IP
addresses/DNS names/URIs, would be most cleanly represented as
Distinguished Names, with AttributeType OIDs (such as the PKCS#9 email
attribute) defined for each type.  This would:

 1) put all name forms in a common data structure, reducing the need to
    parse separate data structures depending on the name type,

 2) eliminate the "null-DN" problem,

 3) allow directory operations (search & retrieval) based on alternative
    name forms to make use of the existing DN search machinery,

 4) eliminate the need for the above suggestion on consistent email
    name form restrictions, since there would be only one place an
    email name could occur (a DN attribute), and

 5) eliminate the need for changing the GeneralName structure to add
    additional name types (such as SDSI names) to the existing 9 types.
    Alternatively, if all future naming requirements are to be satisfied
    by lumping them into "otherName" and registering OIDs for new
    otherName types, then I don't see why the same effect cannot be
    better achieved by registering the new OIDs as DN attributes instead.

Can someone explain the rationale for preferring the GeneralName
extension over DN attributes, and in particular why new applications
should migrate away from including email addresses in DNs?

For the case where multiple different names are needed for a single
entity, a structure like:

  Names ::= SEQUENCE OF Name

could replace the need for GeneralNames.

In fact, if the "subjectAltName" and "issuerAltName" extensions were
replaced by new versions that used  "SYNTAX Names" instead of
"SYNTAX GeneralNames", then the extension would be needed ONLY in the
case where a subject had 2 or more name forms.  Entities such as
PGP subjects who have only an RFC822 name would not be relegated to
second-class status, using a null DN and the subjectAltName
extension.

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKCS 7/10 Security Issues
Date: Mon, 15 Sep 1997 09:41:50 -0400
Status:

Mike,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, September 11, 1997 11:34 AM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'
>Subject: 	RE: PKCS 7/10 Security Issues
>
>Carlisle--
>
>In any case, I've read through your
>comments and arrive at different interpretations of the requirements and
>the essential issues surrounding them.

"Different interpretations" is putting it fairly mildly  --  on some of
these issues I don't think we're understanding each other at all...  

However, it is probably not productive to continue this thread until
there is something concrete to talk about.  As soon as we all have in
front of us a new PKCS #7 (*), a new PKCS #10, and a new 7/10
certificate management proposal, we'll begin these discussions again and
see if we can all progress to a solution with acceptable security and
generality.

Fair enough?

(*) Again, as I said in Munich, this is *not* PKCS #7 v2; this is some
other version of PKCS #7 that adequately addresses the bootstrapping
requirements.

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

Date: Mon, 15 Sep 1997 09:53:07 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX Part I - Name Constraints

> From: Warwick Ford <[email-masked]>
> 
> I wish to propose a minor addition to 4.2.1.11 (Name Constraints) of PKIX
> Part I.  
> 
> Regarding RFC822Name, the most common way to convey an e-mail address today
> is as a PKCS#9 e-mail attribute in the subject DN.  Migration to
> subjectAltNames will undoubtedly occcur in time, and the profile correctly
> covers that future.  However, to ensure that the intent of Name Constraints
> is met given current styles of naming, I propose that we additionally state
> that "Restrictions for the rfc822 name form shall also apply to any
> instance of the PKCS#9 E-mail Name attribute type present in a subject DN."

I agree with the proposal.

But that brings up the question of which name representations are "better"
from a design perspective.

My uninformed intuition suggests that name forms like email addresses,
locally-defined (SDSI-type) names, the "persistent IDs" discussed here
a few months back, as well as other AltName forms such as IP
addresses/DNS names/URIs, would be most cleanly represented as
Distinguished Names, with AttributeType OIDs (such as the PKCS#9 email
attribute) defined for each type.  This would:

 1) put all name forms in a common data structure, reducing the need to
    parse separate data structures depending on the name type,

 2) eliminate the "null-DN" problem,

 3) allow directory operations (search & retrieval) based on alternative
    name forms to make use of the existing DN search machinery,

 4) eliminate the need for the above suggestion on consistent email
    name form restrictions, since there would be only one place an
    email name could occur (a DN attribute), and

 5) eliminate the need for changing the GeneralName structure to add
    additional name types (such as SDSI names) to the existing 9 types.
    Alternatively, if all future naming requirements are to be satisfied
    by lumping them into "otherName" and registering OIDs for new
    otherName types, then I don't see why the same effect cannot be
    better achieved by registering the new OIDs as DN attributes instead.

Can someone explain the rationale for preferring the GeneralName
extension over DN attributes, and in particular why new applications
should migrate away from including email addresses in DNs?

For the case where multiple different names are needed for a single
entity, a structure like:

  Names ::= SEQUENCE OF Name

could replace the need for GeneralNames.

In fact, if the "subjectAltName" and "issuerAltName" extensions were
replaced by new versions that used  "SYNTAX Names" instead of
"SYNTAX GeneralNames", then the extension would be needed ONLY in the
case where a subject had 2 or more name forms.  Entities such as
PGP subjects who have only an RFC822 name would not be relegated to
second-class status, using a null DN and the subjectAltName
extension.

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKCS 7/10 Security Issues
Date: Mon, 15 Sep 1997 09:41:50 -0400

Mike,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, September 11, 1997 11:34 AM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'
>Subject: 	RE: PKCS 7/10 Security Issues
>
>Carlisle--
>
>In any case, I've read through your
>comments and arrive at different interpretations of the requirements and
>the essential issues surrounding them.

"Different interpretations" is putting it fairly mildly  --  on some of
these issues I don't think we're understanding each other at all...  

However, it is probably not productive to continue this thread until
there is something concrete to talk about.  As soon as we all have in
front of us a new PKCS #7 (*), a new PKCS #10, and a new 7/10
certificate management proposal, we'll begin these discussions again and
see if we can all progress to a solution with acceptable security and
generality.

Fair enough?

(*) Again, as I said in Munich, this is *not* PKCS #7 v2; this is some
other version of PKCS #7 that adequately addresses the bootstrapping
requirements.

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

Date: Fri, 12 Sep 1997 13:07:33 -0400
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: resolution
Cc: [email-masked]

Steve and Carlisle:

I think this is a good resolution.

1.  I agree that CA key generations should be optional.  And, I agree with
Steve that EE key generations should also be optional.  Clearly, some
entity needs to generate the key, but the protocol does not need to dictate
which one.

2.  I look forward to the I-D from Bob and Peter.  But, I would like to see
it written as an optional extenstion to PKIX-3.  I do not think we need
another whole protocol between the same entities.

Russ

At 11:43 AM 9/10/97 -0400, Stephen Kent wrote:
>Carlisle,
>
>>>The co-chairs could perhaps now call for final arguments, and
>>>then decide the concensus position, and the actions.
>>
>>Given that over a week has gone by since you sent your message, and
>>given that not a single response has been submitted, I would guess that
>>we already have consensus:
>>
>>- CA key generation will be downgraded from mandatory to optional (which
>>means that EE key generation will be upgraded from optional to
>>mandatory, although this may be accomplished as described next);
>
>OK, downgrade CA key gen to optional.  However, let's not make EE key gen
>mandatory.  You and others gave good arguments why that is not always
>desirable from a security perspective, and how it increases EE cost.  Let's
>leave it optional and let users and CAs worry about ensuring apporpriate
>matching.
>
>>- Bob and Peter will submit an I-D (separate from PKIX-3) specifying a
>>request/response (possibly request/response/confirm) protocol for key
>>generation.  This protocol may be supported by EEs, CAs, RAs, or any
>>other entity in the PKI.
>
>OK.
>
>>Peter, Bob, Steve/Warwick, Everyone-Else:  does this sound reasonable?
>>Can I make the relevant changes in PKIX-3 and submit it for Last Call?
>
>Yes.
>
>Steve
>
>

Date: Sat, 13 Sep 1997 20:07:53 -0400
To: Russ Housley <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: PKIX Part I - Name Constraints
Cc: [email-masked]

Russ:

At 08:56 PM 9/11/97 -0400, Russ Housley wrote:
>1.  I would like to encourage the use of alt names.  In my mind, they are
>highly preferable to the alternatives.  I'm sure you agree.

I do.

>2.  To deal with the exception that you propose, we need to add a
>dependency between rfc822 alt names and X.500 Distinguished Names.  I do
>not like this if we can avoide it.

RFC822 names in altnames are not impacted.  They are treated exactly as in
the standard.  In fact, nothing related to the standard is impacted.  What
I am proposing is simply one additional rule that PKIX imposes, which is a
perfectly reasonable thing for a profile to do.  If there is an RFC822 name
constraint in force, we just impose one further check on the Subject field.
 Very straightforward to implement (if you are already implementing name
constraint logic).

Without this rule, I believe that many early Name Constraints
implementations will have a major loophole.  I think it is a PKIX
obligation to provide the rules to secure the migration from the old ways
to the new ways.

Warwick

>Russ
>
>At 05:44 PM 9/11/97 -0400, Warwick Ford wrote:
>>I wish to propose a minor addition to 4.2.1.11 (Name Constraints) of PKIX
>>Part I.  
>>
>>Regarding RFC822Name, the most common way to convey an e-mail address today
>>is as a PKCS#9 e-mail attribute in the subject DN.  Migration to
>>subjectAltNames will undoubtedly occcur in time, and the profile correctly
>>covers that future.  However, to ensure that the intent of Name Constraints
>>is met given current styles of naming, I propose that we additionally state
>>that "Restrictions for the rfc822 name form shall also apply to any
>>instance of the PKCS#9 E-mail Name attribute type present in a subject DN."
>>
>>Warwick
>>
>>---------------------------------------------------------------------
>>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>>---------------------------------------------------------------------
>> 
>>
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date: Fri, 12 Sep 1997 08:31:05 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Policy Contraints Object Identifier

Policy mapping would imply re-issuance to get the new mappings onto the required certs.  I believe this is a classic case for cross certification for each (BBN and GTE) authority, recognizing the root public key as a CA in their own hierarchy (if they have a hierarchy) or chain (web) of trust.

Michael

>>> Peter Williams <[email-masked]> 09/11/97 03:55PM >>>
>
> >Thanks,
> >Jean Duffy
> >
> >GTE Internetworking
> >Powered by BBN

I know BBN an GTE have been off and on friends for years; but
its still a little sad for us Internet types to see any diminishment
of the BBN name!

Corporate mergers of this sort are, of course, common.

Lets say BBN has issued 50,000 certs to employees, and GTE corporate
dictum now wanted to change everyone over to [a-z][email-masked]. (I
do not know if they do or do not.)

Obviously one way to do it is to revoke and reissue all certs (and
handle 50,000 tokens if token-based).

Another way is to revoke the BBN CA(s), and start again with
new trust points.

How would PKIX technology migrate folk intelligently? A policy mapping, or
name mapping in a renewed BBN CA certificate, perhaps?

This is a fun topic, after all the recent fuss. It will
not be long before someone has to deal with precisely
this scenario.

Date: Fri, 12 Sep 1997 08:08:18 -0400
To: [email-masked], Jean Duffy <[email-masked]>
From: John Lowry <[email-masked]>
Subject: Re: Policy Contraints Object Identifier
Cc: "[email-masked]'" <[email-masked]>

Peter,

The obvious choice in a friendly merger is to cross-certify ...

Just as our corporations have merged and (we expect) become stonger,
so too will the PKI offering.  

So a reasonable approach is to cross-certify and then
let the name of one of the CA's expire gracefully.

Regards,

John Lowry

Principal Engineer
GTE Internetworking
BBN Technologies

At 02:55 PM 9/11/97 -0700, Peter Williams wrote:
>>
>> >Thanks,
>> >Jean Duffy
>> >
>> >GTE Internetworking
>> >Powered by BBN
>
>
>I know BBN an GTE have been off and on friends for years; but
>its still a little sad for us Internet types to see any diminishment
>of the BBN name!
>
>Corporate mergers of this sort are, of course, common.
>
>Lets say BBN has issued 50,000 certs to employees, and GTE corporate
>dictum now wanted to change everyone over to [a-z][email-masked]. (I
>do not know if they do or do not.)
>
>Obviously one way to do it is to revoke and reissue all certs (and
>handle 50,000 tokens if token-based).
>
>Another way is to revoke the BBN CA(s), and start again with
>new trust points.
>
>How would PKIX technology migrate folk intelligently? A policy mapping, or
>name mapping in a renewed BBN CA certificate, perhaps?
>
>This is a fun topic, after all the recent fuss. It will
>not be long before someone has to deal with precisely
>this scenario.
>
>

Date: Thu, 11 Sep 1997 20:56:24 -0400
To: Warwick Ford <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PKIX Part I - Name Constraints
Cc: [email-masked]

Warwick:

1.  I would like to encourage the use of alt names.  In my mind, they are
highly preferable to the alternatives.  I'm sure you agree.

2.  To deal with the exception that you propose, we need to add a
dependency between rfc822 alt names and X.500 Distinguished Names.  I do
not like this if we can avoide it.

Russ

At 05:44 PM 9/11/97 -0400, Warwick Ford wrote:
>I wish to propose a minor addition to 4.2.1.11 (Name Constraints) of PKIX
>Part I.  
>
>Regarding RFC822Name, the most common way to convey an e-mail address today
>is as a PKCS#9 e-mail attribute in the subject DN.  Migration to
>subjectAltNames will undoubtedly occcur in time, and the profile correctly
>covers that future.  However, to ensure that the intent of Name Constraints
>is met given current styles of naming, I propose that we additionally state
>that "Restrictions for the rfc822 name form shall also apply to any
>instance of the PKCS#9 E-mail Name attribute type present in a subject DN."
>
>Warwick
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
> 
>

From: "Charles Moore" <[email-masked]>
To: <[email-masked]>
Subject: Re: PKIX-3 Extensibility
Date: Fri, 12 Sep 1997 11:23:10 +1000

 This meets  my original posted change  requirements as well.

-----Original Message-----
From: Russ Housley <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, 12 September 1997 11:14
Subject: PKIX-3 Extensibility

>I think that there are messages that are specific to particular
>environments, and I cannot find a place for such messages in PKIX-3.  For
>example, a particular community might use hardware tokens, and they might
>need messages to transfer PINs associated with those tokens.  I am sure
>that there are many, many more such examples.  The PKIX working group
>cannot add a message type for every environment. Yet, the current CHOICE is
>hopeless for extensibility.
>
>I propose that an additional  branch be added to the CHOICE.  The
>additional branch would be:
>
> other [48] SEQUENCE {
> oid OBJECT IDENTIFIER,
> value ANY DEFINED BY oid  }
>
>In this way, particular communities can extend PKIX-3 to handle their
>specific needs without having to annoy the working group to add brances to
>the choice that are usefult to a small set of users.
>
>Russ

Date: Thu, 11 Sep 1997 18:36:09 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: PKIX-3 Extensibility

I think that there are messages that are specific to particular
environments, and I cannot find a place for such messages in PKIX-3.  For
example, a particular community might use hardware tokens, and they might
need messages to transfer PINs associated with those tokens.  I am sure
that there are many, many more such examples.  The PKIX working group
cannot add a message type for every environment. Yet, the current CHOICE is
hopeless for extensibility.

I propose that an additional  branch be added to the CHOICE.  The
additional branch would be:

	other [48] SEQUENCE {
			oid	OBJECT IDENTIFIER,
			value	ANY DEFINED BY oid  }

In this way, particular communities can extend PKIX-3 to handle their
specific needs without having to annoy the working group to add brances to
the choice that are usefult to a small set of users.

Russ

Date: Thu, 11 Sep 1997 16:19:51 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Name changes and certificates

>Corporate mergers of this sort are, of course, common.

Been there, done that!  Remember Contel?  Unfortunately, all too often, once
the pig passes through the python, there isn't much left of the pig. It will
be interesting to see what happens.

>Lets say BBN has issued 50,000 certs to employees, and GTE corporate
>dictum now wanted to change everyone over to [a-z][email-masked]. (I
>do not know if they do or do not.)
>
>Obviously one way to do it is to revoke and reissue all certs (and
>handle 50,000 tokens if token-based).

First of all, there is no particularly good reason (other than perhaps
image) to revoke any of the existing certificates.  Whatever legal
implications might have existed would be carried forward under the
successors and assigns clause in any case.
>
>Another way is to revoke the BBN CA(s), and start again with
>new trust points.
>
>How would PKIX technology migrate folk intelligently? A policy mapping, or
>name mapping in a renewed BBN CA certificate, perhaps?
>
>This is a fun topic, after all the recent fuss. It will
>not be long before someone has to deal with precisely
>this scenario.
>
In general, I am highly suspicious of any attempt to reuse a key pair by
including a previously used public key in a certificate.

But mergers are one particular example where this is harmless and cost
effective.  Assuming, as I stated without proof, that there is no legal
difference (just as there is no legal difference that I know of whether a
woman uses her maiden name or married name -- she is still the same person,
and still liable for her personal signature), all that would be required
would be for the root CA to issue a new certificate to BBN/GTE containing
the old BBN CA's key. Then the BBN/GTE CA would run a batch process to
extract all of the public keys from all of the old certificates and issue
new certificates containing the same public keys.

The users could pick them up at their leisure from a convenient directory
(we'd be happy to sell them NDS, for example :-) or other distribution
point, and start using them whenever.

You really wouldn't want to revoke the old certificates, because of the
possible ambiguity and confusion that would be caused with respect to
previously signed documents.  You probably don't throw out all of the
letterhead and business cards overnight either, and you certainly don't tear
up the existing contracts.

I would assume that anyone who aspires to be in the CA business, and
especially anyone who aspires to be in the corporate CA-toolkit business,
would include a mechanism for more or less automatically reissuing
certificates when corporations, divisions, departments, and individuals
change names.

Note that in particular this approach doesn't require anything be done to
the tokens at all, since the private keys haven't changed.

Change is the only steady-state condition!

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 11 Sep 1997 17:44:18 -0400
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: PKIX Part I - Name Constraints

I wish to propose a minor addition to 4.2.1.11 (Name Constraints) of PKIX
Part I.  

Regarding RFC822Name, the most common way to convey an e-mail address today
is as a PKCS#9 e-mail attribute in the subject DN.  Migration to
subjectAltNames will undoubtedly occcur in time, and the profile correctly
covers that future.  However, to ensure that the intent of Name Constraints
is met given current styles of naming, I propose that we additionally state
that "Restrictions for the rfc822 name form shall also apply to any
instance of the PKCS#9 E-mail Name attribute type present in a subject DN."

Warwick

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

Date: Thu, 11 Sep 1997 14:55:32 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: verisign
To: Jean Duffy <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Policy Contraints Object Identifier

>
> >Thanks,
> >Jean Duffy
> >
> >GTE Internetworking
> >Powered by BBN

I know BBN an GTE have been off and on friends for years; but
its still a little sad for us Internet types to see any diminishment
of the BBN name!

Corporate mergers of this sort are, of course, common.

Lets say BBN has issued 50,000 certs to employees, and GTE corporate
dictum now wanted to change everyone over to [a-z][email-masked]. (I
do not know if they do or do not.)

Obviously one way to do it is to revoke and reissue all certs (and
handle 50,000 tokens if token-based).

Another way is to revoke the BBN CA(s), and start again with
new trust points.

How would PKIX technology migrate folk intelligently? A policy mapping, or
name mapping in a renewed BBN CA certificate, perhaps?

This is a fun topic, after all the recent fuss. It will
not be long before someone has to deal with precisely
this scenario.

Date: Thu, 11 Sep 1997 17:17:11 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: PKCS 7/10 Security Issues
Cc: "[email-masked]'" <[email-masked]>

Mike,

	I received the slides and am forwarding them to the IETF
secretariat for posting.  I didn't send them to the list as it makes for a
lot of bytes ...

Steve

Date: Thu, 11 Sep 1997 16:48:00 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Policy Contraints Object Identifier

> From: Warwick Ford <[email-masked]>
> 
> The OID for policy constraints in the X.509 DAM was, at one stage, 34, but
> the ASN.1 was changed at a later stage and the new number 36 was assigned
> for the final X.509 text.  The current PKIX document is therefore correct.
> The 12/96 version of PKIX presumably erroneously took its ASN.1 from an
> obsolete X.509 draft.

The current draft is correct on Pages 30, 67, 86, and incorrect on Page 88.

Some other corrections:

Page 88 neglects to include the definition of id-ce-extKeyUsage
(extension number 37).

On Page 86, an extraneous definition of CertPolicySet should be deleted,
since that item was removed from the PolicyConstraints extension

On Pages 63 and 80, the definition of Attribute has "type AttributeValue"
instead of "type AttributeType".

On Pages 65 and 83, KeyUsage is missing definitions for bits 7 and 8.  The
definitions are present on Page 21.

From: "Stephen Underhill" <[email-masked]>
To: <[email-masked]>
Subject: Unsubscribe
Date: Thu, 11 Sep 1997 16:13:51 -0400

Unsubscribe [email-masked] [email-masked]

Date: Thu, 11 Sep 1997 15:45:01 -0400
To: Jean Duffy <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: Policy Contraints Object Identifier
Cc: [email-masked]

Jean:

The OID for policy constraints in the X.509 DAM was, at one stage, 34, but
the ASN.1 was changed at a later stage and the new number 36 was assigned
for the final X.509 text.  The current PKIX document is therefore correct.
The 12/96 version of PKIX presumably erroneously took its ASN.1 from an
obsolete X.509 draft.

Warwick

At 06:31 AM 9/11/97 -0400, Jean Duffy wrote:
>
>
>The July '97 PKIX draft for X.509 certificates lists the object identifier
>for Policy Contraints is 36.  In the 12/1996 version it was 34.  Has this
>value really changed or is it a mistake?
>
>Thanks,
>Jean Duffy
>
>GTE Internetworking
>Powered by BBN
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

From: Rob Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Question on Time Stamp Protocols 
Date: Thu, 11 Sep 1997 14:27:46 -0400

Olivier;

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, September 11, 1997 2:33 AM
>To: 	[email-masked]
>Subject: 	Question on Time Stamp Protocols 
>
>I have a very basic question about PKIX Part V Time Stamp Protocols:

Okay, I will try and answer it.  You should be aware though that at the
Munich meeting the group decided that we wouldn't discuss Parts V and VI
until significant progress had been made on Parts I-IV.  So any further
discussion at this point should probably take place offline.
>
>Why must the data to be time-stamped have the form
>
>MessageImprint ::= SEQUENCE { 
>     hashAlgorithm AlgorithmIdentifier,
>     hashedMessage OCTET STRING} 
>
>What is the benefit, that an AlgorithmIdentifier must be specified and the
>data must
>be hashed ?
>
>MessageImprint could have the form: MessageImprint ::= OCTET STRING
>
>In this case, the requesting entity is responsible for the data it transmits.
>The data contained in the OCTET STRING may be the hash of something, or
>the signature of something, or something which was not modify by a
>hash-function. 
>
>The Time Stamping authority may refuse data which are too big or not, and
>would not have
>to decide wether or not the given hash algorithm is "sufficient" !

Let me try to answer all of this at once.  It was considered undesirable
to reproduce the entire document in the Time Stamp Token.  If it was
reproduced, this could possibly cause problems with bandwidth and
storage.  For this reason we decided that only a hash of the message
should appear in the token.  Once you decide this, you are left with the
decision of who should compute the hash, the requester or the TSA.  

If the TSA computes the hash, it should compute the hash for every token
it receives, regardless of if it is already the hash of something, a
signature or anything else, since we do not want the TSA making any sort
of judgments about the message itself.  If the TSA did compute the hash
for every message, it could create some problems.  Let me give an
example to illustrate.  I hash a message, M, using my favourite hash
algorithm h_1 and send h_1(M) to the TSA to be time stamped.  The TSA
now uses it's favourite hash algorithm, h_2 to hash what I send it, and
produces a Time Stamp Token containing h_2(h_1(M)).  Now, in order to
prove the time at which M was supposed to have existed, I provide the
message M and the token containing h_2(h_1(M)).  Well, h_2 would be
indicated in the token, but h_1 won't be (even if it is sent along in
the request, it's OID would be hashed along with h_1(M)).  So, some
additional information is needed to bind M to the token.

If we do it the way we have, the requester computes the hash and sends
that along with the OID in the request.  These two pieces of information
are then copied into the time stamp token.  Now if we are given just M
and the token then the hash value and the algorithm appear in the token
and should bind the message to the token.  This way no additional
information is needed, we save bandwidth and storage, and the TSA
doesn't have to examine the message in any way.  Granted, the TSA does
still have to decide whether or not to accept the hash algorithm, but we
>felt that this was better than the alternatives.
>
>How can the Time Stamping authority check (in the current version),
>that the hash-data were produced by the requesting entity using the specified
>algorithm (and not using another algorithm as the one specified) ?

It can't, and doesn't have to.  But, if the hash algorithm is
"sufficient" (one-way and collision resistant) it should not be possible
to create some other message M' that hashes to the given value.  So, if
I send some random value h and the OID of a "sufficient" hash algorithm
to be time stamped, I will get a perfectly good time stamp token back.
I don't however have a message M' to bind to the token, and finding
would is computationally infeasible.  So, the token is useless.  Also,
if the hash was produced with some other hash algorithm, the OID of the
algorithm specified in the request would appear in the token, and again
since the algorithm is "sufficient", the token would be useless.  

I hope that this helps to clear up any confusion.

	Robert Zuccherato
>
>
>
>

From: <[email-masked]>
Date: Thu, 11 Sep 1997 09:34:33 -0600
To: Carlisle Adams <[email-masked]>
Subject: RE: PKCS 7/10 Security Issues
Cc: "[email-masked]'" <[email-masked]>

Carlisle--

Yes, the slides and text would have been useful.  I kept looking for them
but they never showed up.  Warwick didn't receive them either.  I don't
know if Steve received  them or not.  In any case, I've read through your
comments and arrive at different interpretations of the requirements and
the essential issues surrounding them.

--Mike

At 06:03 PM 9/9/97 -0400, Carlisle Adams wrote:
>Mike,
>
>After being out of the office (and away from e-mail) for over a week, I
>returned to find your message regarding security issues in the PKCS 7/10
>Certificate Management proposal.  I have several comments, but to keep
>this short, I'll just mention the places where I think you forgot or
>misinterpreted what I said in Munich (so that we can all work from the
>same starting point).
>
>>----------
>>From: 	[email-masked][SMTP:[email-masked]]
>>Sent: 	Sunday, August 31, 1997 3:13 AM
>>To: 	[email-masked]
>>Subject: 	PKCS 7/10 Security Issues
>>
>>All--
>>
>>In order to properly bound the security work in particular, it's
>>essential we understand and agree to the security requirements of the 7/10
>>supplement's intended client audience.  We have a good start along those
>>lines from Munich.  It's important however to conclude which among those
>>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:
>
>Precisely in order to avoid the situation you describe in your last
>sentence above, I sent you (on Wed., Aug. 20th) a copy of the slides and
>associated notes that I used in Munich.  [I sent this to Warwick & Steve
>for inclusion in the minutes, and copied you and a few others who had
>specifically asked for the slides.]
>
>I can only assume that you somehow never received that message...
>
>
>
>
>>Secure Boostrap
>>---------------
>>It was observed that the 7/10 proposal lacks specification of the means by
>>which vendors are required to establish a trusted public key. While
>>accurate in fact, the analysis failed to acknowledge the utility of simple
>>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 is
>>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.
>
>It's not clear to me how the procedure for getting an end entity
>initialized in the PKI can be relegated to some "general guidance" in
>the Security Considerations section.  This is a critical function (if
>EEs can't get securely initialized in the PKI, you don't have a PKI).
>It must be specified in a way that is interoperable across the Internet.
> That's why Part 3 provides several examples, but mandates one (used to
>be two :-).

Remember, we seek to establish the basis for interoperable implementations,
not assert key management policy.  Mandatory key management requirements
should be beyond the scope of a protocol specification.  It is however very
relevant to an enclave's security policy.  Given the abundant number of
alternatives to establishing a trusted public key (including those
suggested in Part 3), I would strengthen the proposed language to reflect
"critical assumptions" regarding the security of the process by which a
trusted public key is established.

>
>
>
>
>>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 the
>>CA that the required proof has been received (and validated!). For example,
>>an end entity wishing to have a signing key certified could send the
>>appropriate signature to the RA which then simply notifies the relevant CA
>>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't seem to
>>be a compelling need to create additional complexity where none is required.
>
>The difference between this proposal and Part 3 is that the Part 3
>messages, as defined, can be used between an EE and an RA as well as
>between an RA and a CA (this is why Part 3 accommodates RAs).  The
>messages defined in this proposal cannot be used between an RA and a CA
>(on behalf of some other EE).
>
>I therefore disagree with the statement that no additional work is
>required.

While it may be natural to think of the RA as brokering all exchanges
between a subscriber and a CA, extensive discussions with potential RAs
suggest practical alternatives.  An RA's most important role is to affirm
to a CA the authenticity of a proposed subscriber's attributes.  To this
end, an RA could easily connect to a CA via an SSL-secured channel and
exchange application status information in whatever means is convenient to
the RA and the CA.  Given the ease with which this can be done--and it's
inherent flexibility--a standard to this effect does not add primary value.
 I must restate an opposition to complex solutions where simple
alternatives exist.  I can get the RA job done without reference to a
standard--or is it Part 3's assertion that no RA can go online on the
Internet and interact with a CA unless it uses a Part 3 interface?

>
>
>
>
>>CA Specification of Subject DN
>>------------------------------
>>It was claimed the draft requires CAs to specify subject DNs. It is however
>>difficult to detect a firm basis for this observation.
>
>I'm not surprised that you found this difficult, because this was not
>the observation at all.
>
>>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.
>
>This is where you having the slides from Munich would have been helpful.
> My point was exactly the opposite:  it is not that the 7/10 protocol
>requires the CA to decide DNs; it is that the 7/10 protocol requires EEs
>to decide DNs (because PKCS #7 and PKCS #10 require DNs in their
>messages).  An EE cannot, by definition, choose its DN because there is
>no guarantee of uniqueness; you *need* someone else (perhaps the CA) to
>make this choice.
>

So by inference, 7/10 is faulted because it leads to the conclusion that CA
(or some other entity) must assign DNs to users.  This is where we started
so I doubt the slides would have done much good.  Let us then call it a
"conclusion" vs. an "observation".

7/10 makes no assertions about what specific Attributes must be present in
a DN, nor does it constrain any specific Attribute to a subset of values.
Requirements on the AVAs that form a DN are implementation and operational
concerns, not protocol specification issues.

>This gets back to the point I keep making:  in their present form, PKCS
>#7 and #10 make use of an *existing* PKI (including the DNs already
>assigned) to secure messages and to request new certificates.  They
>cannot be used to *create* that PKI in the first place.
>
>
>>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's paper as a baseline and reflect
>>comments that propose to overcome noted limitations in parameter
>>dependencies.
>
>Again, this is where the slides would have come in handy for you.  I
>discussed Hemma's proposal and showed why it could not be used in the
>7/10 proposal as it stands.  [Even if you could somehow kludge things to
>make it work, however, I also discussed why the limitations are too
>severe and cannot be overcome  --  there is no good reason to force the
>CA to have a DH certificate and even less reason to force all EEs to use
>the parameters chosen by the CA.]
>
>

The issues here are readily apparent even in the absence of the slides.  It
is a false assumption that the 7 and 10 specifications can't or won't be
changed to reflect emerging market requirements.  I strongly suspect they
will be--perhaps within an IETF context.  I would welcome any comments that
contribute constructively to this evolution.

>
>>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.  Working
>>within these constraints, a self-signed certificate is included in the
>>PKCSReq message.
>
>Again, the slides would have helped you here.  I discussed this
>alternate mechanism and noted that this still doesn't work with existing
>toolkits.  Certainly the self-signed certificate allows the CA to get
>the public key without digging into the message content, but the CA has
>no reason to trust this key (because it can't possibly build a trust
>path from itself to this self-signed certificate).  Existing toolkits
>will therefore have to be modified to accept as valid a message signed
>with an untrusted key (a pretty undesirable situation).  [Furthermore,
>this is why Hemma's proposal for PKCS #10 DH won't work; the EE will not
>be able to construct a self-signed cert. using DH.]
>

Actually, the slides (would) mislead the casually attentive.  A moment's
thought to the issues at hand would conclude that one should place little
trust in this self-signed certificate--it's an artifact of existing toolkit
restrictions.  Trust is established by the CA's authentication and
certificate acceptance policies.  The focus is on the public key and DN in
the PKCS 10, not the self-signed certificate.  There is no constructive
issue here.

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

Date: Thu, 11 Sep 1997 10:48:25 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Access Descriptors Object Identifier

PKIX Part 1 defines four private OID arcs:

id-pe	OID ::= { id-pkix 1 }	-- certificate extensions
id-qt	OID ::= { id-pkix 2 }	-- policy qualifier types
id-kp	OID ::= { id-pkix 3 }	-- extended key purpose OIDs
id-ad	OID ::= { id-pkix 48 }	-- access descriptors

Question: is id-ad really supposed to be { id-pkix 4 }?  That would make
more sense, but the "48" is consistent throughout the document
(section 4.2.2.1, Appendix A, and Appendix B), which casts some doubt on
the theory that it was just a typo.

To: "[email-masked]'" <[email-masked]>
cc: [email-masked]
Subject: Policy Contraints Object Identifier
Date: Thu, 11 Sep 1997 06:31:17 -0400
From: Jean Duffy <[email-masked]>

The July '97 PKIX draft for X.509 certificates lists the object identifier
for Policy Contraints is 36.  In the 12/1996 version it was 34.  Has this
value really changed or is it a mistake?

Thanks,
Jean Duffy

GTE Internetworking
Powered by BBN

Date: Thu, 11 Sep 1997 08:33:14 +0200
To: [email-masked]
From: [email-masked] (Olivier Onimus)
Subject: Question on Time Stamp Protocols

Hi,

I have a very basic question about PKIX Part V Time Stamp Protocols:

Why must the data to be time-stamped have the form

MessageImprint ::= SEQUENCE { 
     hashAlgorithm AlgorithmIdentifier,
     hashedMessage OCTET STRING} 

What is the benefit, that an AlgorithmIdentifier must be specified and the
data must
be hashed ?

MessageImprint could have the form: MessageImprint ::= OCTET STRING

In this case, the requesting entity is responsible for the data it transmits. 
The data contained in the OCTET STRING may be the hash of something, or
the signature of something, or something which was not modify by a
hash-function. 

The Time Stamping authority may refuse data which are too big or not, and
would not have
to decide wether or not the given hash algorithm is "sufficient" !

How can the Time Stamping authority check (in the current version),
that the hash-data were produced by the requesting entity using the specified
algorithm (and not using another algorithm as the one specified) ?

Maybe I did not understand a "basic" of the whole and all the remarks I made are
not correct ! If it is so, excuse me ! If not, please help me to understand !

Thank's in advance

Olivier
+-----------------------------------------------------------+
| Olivier Onimus                                            |
| Danet GmbH, Business Unit Telecommunications Technology   |
| Gutenbergstrasse 10, D-64331 Weiterstadt, Germany         |
| Tel:    +49-6151-868-127                                  |
| Fax:    +49-6151-868-264                                  |
| e-mail: [email-masked]                                   |
+-----------------------------------------------------------+

Date: Thu, 11 Sep 1997 08:32:06 +0200
To: [email-masked]
From: [email-masked] (Olivier Onimus)
Subject: Re: Key Usage Extension Encoding

>I am canvassing opinion on how the key usage field should be encoded.  I
>have heard some divergence of opinion which seems to be rooted in
>differing interpretations of the ASN encoding rules as well as the
>actual pkix usage.  ASN rules state any unused bits are set to zero.
>There are now 9 bits defined in the key usage extension in pkix part 1
>v5. If I wanted to set digital signatures and key agreement (bit 0 and
>bit 4), what would the encoded bit string look like and how many bits
>are encoded to be in use 2 or 9?
>Thanks
>Dr Trevor Freeman
>Senior Consultant
>Microsoft Consulting Services
>Microsoft Ltd ECU
>> Tel:  UK(+44) 1734 270412 
>Fax: UK(+44) 1734 270435
>
>
>

>    I believe that DER requires that the BIT STRING contain (starting with the
>tag):
>
>    0x03020388
>
>where the '88' is bits 0 and 4 and the '03' arises because there are 3 bits at
>the end which are named but not set, i.e. not used.
>
>
>

I think this coding 03020388 is correct:

    DER-Encoding of a "NamedBitString"
         According to X.680, Chapter 19.7, the trailing bits which are
         0 can be removed from the coding (and are not relevant anymore)
 
        In X.690,Chapter 11.2.2 (DER-encoding): 
        the bitstring shall have all trailing 0 bits
        removed before it is encoded 
        It means, the bitstring '10001' represents:
                     digitalSignature  ON
                     nonRepudiation    OFF
                     keyEncipherment   OFF
                     dataEncipherment  OFF
                     keyAgreement      ON
                     keyCertSign       OFF
                     cRLSign           OFF
                     encipherOnly      OFF
                     decipherOnly      OFF

       and it is the only correct DER-encoding for this.

Olivier.
+-----------------------------------------------------------+
| Olivier Onimus                                            |
| Danet GmbH, Business Unit Telecommunications Technology   |
| Gutenbergstrasse 10, D-64331 Weiterstadt, Germany         |
| Tel:    +49-6151-868-127                                  |
| Fax:    +49-6151-868-264                                  |
| e-mail: [email-masked]                                   |
+-----------------------------------------------------------+

From: Xiaoyi Liu <[email-masked]>
Subject: Re: PKCS 7/10 Security Issues
To: [email-masked] (Carlisle Adams)
Date: Wed, 10 Sep 1997 15:21:50 -0700 (PDT)
Cc: [email-masked], [email-masked]
Content-Length: 1860

> 
> >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.  Working
> >within these constraints, a self-signed certificate is included in the
> >PKCSReq message.
> 
> Again, the slides would have helped you here.  I discussed this
> alternate mechanism and noted that this still doesn't work with existing
> toolkits.  Certainly the self-signed certificate allows the CA to get
> the public key without digging into the message content, but the CA has
> no reason to trust this key (because it can't possibly build a trust
> path from itself to this self-signed certificate).  Existing toolkits
> will therefore have to be modified to accept as valid a message signed
> with an untrusted key (a pretty undesirable situation). 

I just want to point out that, with Tipem 2.0, there is no need to modify the
existing toolkit. The self-signed certificate can be used to verify the 
signature, with the warning message from the toolkit. 

Generally, the key is untrusted in this case. That is why there is out of 
band user authentication. This protocol can also be extended to include 
the usage of pre-shared secret so the authentication can be in-band.

Xiaoyi
 [Furthermore,
> this is why Hemma's proposal for PKCS #10 DH won't work; the EE will not
> be able to construct a self-signed cert. using DH.]
> 
> 
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------
> 
> 
> 

Date: Wed, 10 Sep 1997 11:43:23 -0400
To: Carlisle Adams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: resolution
Cc: "[email-masked]'" <[email-masked]>

Carlisle,

>>The co-chairs could perhaps now call for final arguments, and
>>then decide the concensus position, and the actions.
>
>Given that over a week has gone by since you sent your message, and
>given that not a single response has been submitted, I would guess that
>we already have consensus:
>
>- CA key generation will be downgraded from mandatory to optional (which
>means that EE key generation will be upgraded from optional to
>mandatory, although this may be accomplished as described next);

OK, downgrade CA key gen to optional.  However, let's not make EE key gen
mandatory.  You and others gave good arguments why that is not always
desirable from a security perspective, and how it increases EE cost.  Let's
leave it optional and let users and CAs worry about ensuring apporpriate
matching.

>- Bob and Peter will submit an I-D (separate from PKIX-3) specifying a
>request/response (possibly request/response/confirm) protocol for key
>generation.  This protocol may be supported by EEs, CAs, RAs, or any
>other entity in the PKI.

OK.

>Peter, Bob, Steve/Warwick, Everyone-Else:  does this sound reasonable?
>Can I make the relevant changes in PKIX-3 and submit it for Last Call?

Yes.

Steve

From: "Charles Moore" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>, <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: Re: resolution
Date: Wed, 10 Sep 1997 08:24:27 +1000

>
>Peter, Bob, Steve/Warwick, Everyone-Else:  does this sound reasonable?
>Can I make the relevant changes in PKIX-3 and submit it for Last Call?
>
>
As there has been no disagreement, I will assume that the extensions
submitted will also be also included before the last call.

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKCS 7/10 Security Issues
Date: Tue, 9 Sep 1997 18:03:06 -0400

Mike,

After being out of the office (and away from e-mail) for over a week, I
returned to find your message regarding security issues in the PKCS 7/10
Certificate Management proposal.  I have several comments, but to keep
this short, I'll just mention the places where I think you forgot or
misinterpreted what I said in Munich (so that we can all work from the
same starting point).

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Sunday, August 31, 1997 3:13 AM
>To: 	[email-masked]
>Subject: 	PKCS 7/10 Security Issues
>
>All--
>
>In order to properly bound the security work in particular, it's
>essential we understand and agree to the security requirements of the 7/10
>supplement's intended client audience.  We have a good start along those
>lines from Munich.  It's important however to conclude which among those
>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:

Precisely in order to avoid the situation you describe in your last
sentence above, I sent you (on Wed., Aug. 20th) a copy of the slides and
associated notes that I used in Munich.  [I sent this to Warwick & Steve
for inclusion in the minutes, and copied you and a few others who had
specifically asked for the slides.]

I can only assume that you somehow never received that message...

>Secure Boostrap
>---------------
>It was observed that the 7/10 proposal lacks specification of the means by
>which vendors are required to establish a trusted public key. While
>accurate in fact, the analysis failed to acknowledge the utility of simple
>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 is
>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.

It's not clear to me how the procedure for getting an end entity
initialized in the PKI can be relegated to some "general guidance" in
the Security Considerations section.  This is a critical function (if
EEs can't get securely initialized in the PKI, you don't have a PKI).
It must be specified in a way that is interoperable across the Internet.
 That's why Part 3 provides several examples, but mandates one (used to
be two :-).

>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 the
>CA that the required proof has been received (and validated!). For example,
>an end entity wishing to have a signing key certified could send the
>appropriate signature to the RA which then simply notifies the relevant CA
>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't seem to
>be a compelling need to create additional complexity where none is required.

The difference between this proposal and Part 3 is that the Part 3
messages, as defined, can be used between an EE and an RA as well as
between an RA and a CA (this is why Part 3 accommodates RAs).  The
messages defined in this proposal cannot be used between an RA and a CA
(on behalf of some other EE).

I therefore disagree with the statement that no additional work is
required.

>CA Specification of Subject DN
>------------------------------
>It was claimed the draft requires CAs to specify subject DNs. It is however
>difficult to detect a firm basis for this observation.

I'm not surprised that you found this difficult, because this was not
the observation at all.

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

This is where you having the slides from Munich would have been helpful.
 My point was exactly the opposite:  it is not that the 7/10 protocol
requires the CA to decide DNs; it is that the 7/10 protocol requires EEs
to decide DNs (because PKCS #7 and PKCS #10 require DNs in their
messages).  An EE cannot, by definition, choose its DN because there is
no guarantee of uniqueness; you *need* someone else (perhaps the CA) to
make this choice.

This gets back to the point I keep making:  in their present form, PKCS
#7 and #10 make use of an *existing* PKI (including the DNs already
assigned) to secure messages and to request new certificates.  They
cannot be used to *create* that PKI in the first place.

>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's paper as a baseline and reflect
>comments that propose to overcome noted limitations in parameter
>dependencies.

Again, this is where the slides would have come in handy for you.  I
discussed Hemma's proposal and showed why it could not be used in the
7/10 proposal as it stands.  [Even if you could somehow kludge things to
make it work, however, I also discussed why the limitations are too
severe and cannot be overcome  --  there is no good reason to force the
CA to have a DH certificate and even less reason to force all EEs to use
the parameters chosen by the CA.]

>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.  Working
>within these constraints, a self-signed certificate is included in the
>PKCSReq message.

Again, the slides would have helped you here.  I discussed this
alternate mechanism and noted that this still doesn't work with existing
toolkits.  Certainly the self-signed certificate allows the CA to get
the public key without digging into the message content, but the CA has
no reason to trust this key (because it can't possibly build a trust
path from itself to this self-signed certificate).  Existing toolkits
will therefore have to be modified to accept as valid a message signed
with an untrusted key (a pretty undesirable situation).  [Furthermore,
this is why Hemma's proposal for PKCS #10 DH won't work; the EE will not
be able to construct a self-signed cert. using DH.]

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

Date: Tue, 9 Sep 1997 17:25:56 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: misc PKIX-1 comments

Here are a few observations on the (newly-reformatted -- thanks!)
draft-ietf-pkix-ipki-part1-05.txt:

* the definition of RelativeDistinguishedName in section 4.1.2.4 is
  still incorrect -- it uses AttributeValueAssertion instead of
  AttributeTypeAndValue.  Although the syntax of AVA and AT&V are the
  same, their meaning is different.

  From X.501 section 8.7.2: "An attribute value assertion (AVA) is a
  proposition ... concerning the presence in an entry of an attribute
  value of a particular type.", i.e. AVAs are used in matching rules
  to select entries from the Directory.

  From X.501 section 9.3: "An RDN ... consistes of a set of attribute 
  type and value pairs ...", and notes that "the attribute syntax and
  the assertion syntax of the equality matching rule are the same".

  Change the PKIX definition to be consistent with the X.501 definition:

     RelativeDistinguishedName ::= SET OF AttributeTypeAndValue

  (the correct definition appears in Appendices A and B, but section 4.1.2.4
  wasn't fixed.  The now-unneeded definitions of AVA can be removed from
  the appendices.)

* In Section 4.2, replace occurrences of "altSubjectName", "altIssuerName",
  and "the alternative subject name" with "subjectAltName", etc.  It's
  not an alternative subject, just an alternative name for the same
  subject :-).

* In Section 4.2.2.1, delete the text beginning with:
  "The authorityInfoAccess extension may be included in a PKCS 7
  encapsulation as an X.501 ATTRIBUTE.",
  as it is out of scope for the certificate profile.

  Descriptions of attributes to be included in PKCS 7 messages and
  details for forming filenames for HTTP certificate retrieval
  mechanisms have nothing to do with the X.509 certificate profile,
  which defines the contents of the certificate itself.  The description
  of specific message encapsulation formats and retrieval mechanisms
  belongs in Part 2.

* Section 5.1 contains duplicate definitions of Version, AlgorithmIdentifier,
  CertificateSerialNumber, Extensions, etc.  For example, the comment
  after Version says:

    "-- v3 does not apply to CRLs but appears for consistency with
     -- definition of Version for certs"

  There would not be an issue of consistency if there were not multiple
  definitions.  Additionally, how do ASN.1 compilers handle multiple
  definitions with the same name in a single module?  X.509 does not
  contain duplicate definitions, the CRL section just contains the
  macrofied definition of CertificateList.

  Delete the duplicate definitions from Section 5.1 and Appendix A.
  Appendix B is already correct.

* Replace all occurrences of "ChoiceOfTime" (used in Validity, thisUpdate,
  and nextUpdate) with "Time", to be consistent with the name used in X.509.

* The mail attachment headers ("X-Sun-xxx") and command lines should be
  stripped from the examples in Appendix D.

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: RE: resolution
Date: Tue, 9 Sep 1997 16:28:50 -0400

Hi,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Thursday, August 28, 1997 1:27 PM
>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.

Peter, is it really that difficult for you to state something without
publicly attempting to tarnish someone's motives?  If you remove the
word "disclosed" from the above, I agree with you.

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

Agreed.

>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 mostly agree...  I am reluctant to remove the option of a request for
central key generation completely from the cert. request message (which
was Bob's preference for reasons of "parsimony").  If an EE knows that
the CA will generate its encryption key pair (which will be the case in
many large organizations), I see no reason why the standard should
mandate that two separate message exchanges be used for this.

Given that the cert. request message is already a SEQUENCE of
FullCertTemplate, there is no extra effort for the EE or the CA to
understand the format of this combined request (the Appendix B profile
simply says that the first FullCertTemplate is to be used for an
EE-generated key pair and the second FullCertTemplate, if used, is for a
centrally-generated key pair).  I therefore see no simplification in
removing this optional request and, on the contrary, see removal as
being more cumbersome (i.e., more messages to support, more code to
implement) for the environments where this will be needed.

Other than that, as I have said, I agree to Bob's proposal.

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

It will be wonderful to see your name in the list of authors on an
Internet Draft.

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

Given that over a week has gone by since you sent your message, and
given that not a single response has been submitted, I would guess that
we already have consensus:

- CA key generation will be downgraded from mandatory to optional (which
means that EE key generation will be upgraded from optional to
mandatory, although this may be accomplished as described next);

- Bob and Peter will submit an I-D (separate from PKIX-3) specifying a
request/response (possibly request/response/confirm) protocol for key
generation.  This protocol may be supported by EEs, CAs, RAs, or any
other entity in the PKI.

Peter, Bob, Steve/Warwick, Everyone-Else:  does this sound reasonable?
Can I make the relevant changes in PKIX-3 and submit it for Last Call?

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

To: Trevor Freeman <[email-masked]>
cc: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: Key Usage Extension Encoding 
Date: Mon, 08 Sep 1997 16:55:35 -0400
From: "Charles W. Gardiner" <[email-masked]>

    I believe that DER requires that the BIT STRING contain (starting with the
tag):

    0x03020388

where the '88' is bits 0 and 4 and the '03' arises because there are 3 bits at
the end which are named but not set, i.e. not used.

Charlie Gardiner

Date: Mon, 8 Sep 1997 22:14:55 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Trevor Freeman <[email-masked]>
cc: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: Key Usage Extension Encoding

> actual pkix usage.  ASN rules state any unused bits are set to zero.
> There are now 9 bits defined in the key usage extension in pkix part 1
> v5. If I wanted to set digital signatures and key agreement (bit 0 and

I believe DER requires unused high bits set to zero.

--
Mark Shuttleworth
Thawte Consulting

Date: Mon, 08 Sep 1997 03:30:57 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: verisign
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX-1 key purpose

Steve,

there is no intented contradiction between my line on mandatory CA keygen,
and (part-4-like) policy-defined semantics of key purpose or key usage,
or ISO-defined semantics of "proof of origin with NR" or "peer
entity authentication" ("strong authentication").

X.509 conforms to the standards-writer's standard "X.800", whose model
assigns no assurnace semantics to mere security mechanisms such as a
digital signature, or encipherment. Assurances are reserved for security
service specifications. (I suspect  I'm preaching here to a crowd containing
folk who may have written these documents.)

I am saying, as we have a strong and extensible policy-enforcement signal
and enforcement mechanism in PKIX, we use it to instrument the
diversity of Internet operational culture. Such culture will inevitable
evolve, even after we close this WG next year.

Explicit  policy fields allow a CA (or its prevailing certification domain) to
mandate
that its users will use its (logically optionally- available, and optionally-
procured
from PKIX- conforming system vendors) central keygen.

Explicit  policy fields allow a CA (or its prevailing certification domain) to
mandate
that its an subscriber using a digital signature mechanism  whose verification
must be supported by reliance on a CA service (e.g. an issued certificate)
shall
accept that the semantics for that usage shall be "for solmen signing
purposes recognised by law").

Explicit  policy fields allow a CA (or its prevailing certification domain) to
mandate
that its an subscriber using a digital signature mechanism supported by
reliance on a CA service (e.g. an issued certificate) shall accept that the
semantics for the accompanying non-repudiation bit, when NOT set, shall
mean that no party shall have expectation of recourse of an authoritative
dispute resolution mechanism considering the refutability of the intent
of affixing a signature to a message, or the intent or strong authenticating
a virtual-channel's datagrams.

Explicit policy fields allow a CA to design anything else that one can
imagine...including the contrary positions to the above semantics.

-----

If indeed there are, as you have asserted many times "know better"
elements of policy which ouught to become std elements of service, then
the appropriate form to express these is in a PKIX part n "Common
Certification Policy", to which internet CAs can (optionally) conform.

The policy rules built into PKIX (dual key, separation of function, mandatory
this, mandatory that) which seem to be the designers' beliefs in
their "know better" world, should be stripped from PKIX 1-4, and placed
in such a document, along with a rationale. A convincing  rationale will
pursuade public and organizational CAs to adopt that logical policy, at least
as a starting point for their own specific service definition.

I, perhaps, see a world where most certs will contain two certificate policy
values  - the IPKI Common Certificate policy, and the CAs'
overloading or overriding of specific elements of std IPKI service for
diverse reasons.

Stephen Kent wrote:

> Peter,
>
> Your messages always provide so much food for thought ...
>
> Yes, in a legal context, one can declare authentication to be equivalent to
> non-repudiation, but as technologists, we know better.  We can choose, as
> you suggest, to remain silent on this point, and allow any interpretation
> to be imposed the bits we provide, or we can take a stand that we believe
> is supportable in terms of good technical practice.  I don't question the
> likelihood of your example, but I do question whether we ought to be
> willing accomplices in such uses.
>
> You have argued fervently against CA key gen, but the basis of those
> arguments is precisly a policy argument, not a technical one.  If we make
> this facility an option, vs. a mandatory option, that will be a prime
> example of shaping the spec based on a policy for which there appears to be
> WG concensus.  So, why is the notion of declaring a limited scope for usage
> bits, based on a policy perspective that has general support within the WG,
> out of scope?
>
> Steve

From: Brian Korver <[email-masked]>
Subject: Re: Key Usage Extension Encoding
To: [email-masked] (Trevor Freeman)
Date: Mon, 8 Sep 1997 10:03:47 -0700 (PDT)
Cc: [email-masked]

Trevor Freeman writes:
> 
> I am canvassing opinion on how the key usage field should be encoded.  I
> have heard some divergence of opinion which seems to be rooted in
> differing interpretations of the ASN encoding rules as well as the
> actual pkix usage.  ASN rules state any unused bits are set to zero.
> There are now 9 bits defined in the key usage extension in pkix part 1
> v5. If I wanted to set digital signatures and key agreement (bit 0 and
> bit 4), what would the encoded bit string look like and how many bits
> are encoded to be in use 2 or 9?

The DER encoding would be 03 02 03 88; that is, with 5 bits in use. 
The trailing 0 bits are truncated, per DER.

> Thanks
> Dr Trevor Freeman
> Senior Consultant
> Microsoft Consulting Services
> Microsoft Ltd ECU
> > Tel:  UK(+44) 1734 270412 
> Fax: UK(+44) 1734 270435
> 
> 

brian
[email-masked]

Date: Mon, 8 Sep 1997 09:56:52 -0700
To: Stephen Kent <[email-masked]>
From: [email-masked] (Tony Bartoletti)
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

(apologies if message received twice, mailer complained of congestion - TB)
Stephen Kent wrote:

>Tony,
>
>        I do not question the plausibility of the scenario you described;
>it'salways useful to examine possibe worst case scenarios in evaluating
>systems.  Your point, and that of some others who object to making CA key
>gen a mandatory option, is that this would significantly facilitate
>government imposition of the controls you describe.  However, since the CA
>key gen feature does NOT call for the CA to retain the private key, the
>example is flawed.  That is, a compliant CA would not have to retain the
>private key it generated (nor an ability to regenerate it).  So, licensing
>PKIX part 3 compliant CAs, the year 2000 event in your example, does not
>achieve the effect you cited.  To achieve the predicted effect, vendors
>would have to choose to retain this data, a design "feature" outside the
>scope of the standard.  In that case, your wrath should be directed against
>any vendor who chooses to take this approach.  However, if we predict
>vendors adopting this tact, wny not assume that they will do so
>irrespective of the standard?  This seems to be a typical slippery slope.
>
>        I'll assume that the smoke-filled room allusion was in reference to
>something other than the deliberations taking place on this list. Besides,
>I don't smoke and always request non-smoking seating in restaurants,
>airplanes, etc. :-).
>
>Steve

Steve,

Sorry about the "smoke-filled room", I was conjuring up the nameless forces
over which we have little knowledge or control.  But on that subject...

I find little comfort with "key gen feature does NOT call for the CA to
retain the private key..."  I *would* be satisfied with "key gen feature
makes it provably impossible for CA to retain the private key" but I don't
believe such technology exists in software, and why should I trust hardware
where the blueprints, circuit masks and detailed algorithms are not available
for public review? (regard my reply to Al Arsenault.)

If and when my private transmissions are compromised, either to government or
business rivals (how might I know this directly?) my main interest would not
be to excoriate the CA, or to bring legal action, but rather turn back the clock
and erase the unwanted exposure, (an impossible task.)  In lieu of this, I would
wish to rely upon processes where I remain the master of my destiny, to the
degree that this is still possible.

If a warrant is issued that I must turn over a given secret key or face jail,
I prefer to make the choice myself, rather than have it made for me.

I know I am pushing the left edge of the envelope with this position, but the
powers that would push it the other way are larger (and certainly better
organized) than I am, so please pardon the stridency of my statements.

___TONY___ (speaking only for myself)

Date: Mon, 8 Sep 1997 09:55:29 -0700
To: "Arsenault, Al W." <[email-masked]>
From: [email-masked] (Tony Bartoletti)
Subject: Re: Too many options
Cc: [email-masked]

(apologies if message received twice, mailer complained of congestion - TB)
Al Arsenault wrote
>
>From: Mark Shuttleworth
>
>
>>> doing in addition to signing her certificate.  (Maybe he's creating
>another
>>> certificate with her name/user id and a different key, which he'll use
>later
>>> on.)  She either trusts the organizational process, or she doesn't.
>
>>A CA could do that anyway. But getting the CA to generate the key creates
>>a new potential problem - that more than one entity has had access to a
>>supposedly private key.
>
>Please refer to my original scenario, in which the only way the CA could
>have gotten access to the private key was to physically attack the token.
> (I would hope we're working in an environment in which that's pretty tough
>to do without being detected.)  In that scenario, I assert that the real
>problem is the CA generating a separate certificate with a separate key, and
>that this doesn't change, regardless of whether the token is commanded to
>generate the key by the user or the CA.
>
>(Tokens which meet my criteria include the FORTEZZA card, when the key is
>generated with the user PIN enabled, and the EES-Lynks card, when extraction
>privileges are properly set.)
>
>               Al Arsenault

Are the internal blueprints to the FORTEZZA or EES-Lynks cards available for
public review, so that independent bodies of researchers can verify that they
contain no backdoors?  Or must we simply trust the people who have designed
and produced these cards?  I don't know the answer, I'm curious.

___TONY___

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Key Usage Extension Encoding
Date: Mon, 8 Sep 1997 08:50:20 -0700

I am canvassing opinion on how the key usage field should be encoded.  I
have heard some divergence of opinion which seems to be rooted in
differing interpretations of the ASN encoding rules as well as the
actual pkix usage.  ASN rules state any unused bits are set to zero.
There are now 9 bits defined in the key usage extension in pkix part 1
v5. If I wanted to set digital signatures and key agreement (bit 0 and
bit 4), what would the encoded bit string look like and how many bits
are encoded to be in use 2 or 9?
Thanks
Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel:  UK(+44) 1734 270412 
Fax: UK(+44) 1734 270435

Date: Fri, 5 Sep 1997 16:22:46 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Too many options
Cc: "[email-masked]" <[email-masked]>

John,

>IMHO the difference between these 2 scenarios can be explained in one
>word - TRUST.  Not that these 2 systems can't be trusted, but the
>perception of trust by the those that must buy into a system - the end
>users and owners of these types of systems.  Any system that is to be
>used widely and effectively must be able to be trusted beyond a shadow
>of a doubt by everyone.
>
>Scenario A provides Alice an opportunity to actively participate,
>therefore allowing buy-in and building the trust factor.
>
>Scenario B removes Bob from any involvement, thereby creating doubt and
>the possibility of misperceptions about the trustworthiness and
>integrity of the system.

The context Al described involves an employer and employee relationship,
not a client and a public CA.  The employer in the example is the only CA
that will certify this individual as an employee.  The token is probably
owned by the employer, not the employee.  This is analogous to employee ID
badges.  When my company changed from analog photos to digital ones and
reissued the badges, the employees didn't have a say in the matter.  This
example is not a free market one inn which the employee gets to choose the
CA.  While your comments are appropriate in some contexts, they do not
apply in all CA examples, including the specific one Al described.

Steve

Date: Fri, 5 Sep 1997 16:14:28 -0400
To: Ambarish Malpani <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Too many options
Cc: "[email-masked]" <[email-masked]>

Ambarish,

>Another possibility along these lines, is the case where a user
>wants to have multiple certificates for a single public/private key.
>In that case, I might not trust a particular CA all that much. If
>at a later date, I decide not to trust a particular CA, I still want
>my private key to stay private and I don't care about what certs
>that particular CA issues.

Yes, if you choose to use the same key in multiple certificates, it might
be inappropriate to have had that key generated by one of the CAs.
However, the flip side is that some CAs don't want to certify a key that
has been used in other certs, for reasons that have been extensively
discussed previously, and CA key gen is a means of enforcing that policy.

>I hope the discussion is just to allow a CA the option of generating
>the private key and nobody is planning to make that mandatory.

If you were following this thread, or if you read with the PKIX Part 3 I-D
that is the focus of the discussion, you would know that the discussion is
precisely about whether this option should be mandatory.

Steve

Date: Fri, 5 Sep 1997 14:30:36 -0700
To: [email-masked]
From: [email-masked] (Tony Bartoletti)
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Stephen Kent wrote:

>Tony,
>
>        I do not question the plausibility of the scenario you described;
>it'salways useful to examine possibe worst case scenarios in evaluating
>systems.  Your point, and that of some others who object to making CA key
>gen a mandatory option, is that this would significantly facilitate
>government imposition of the controls you describe.  However, since the CA
>key gen feature does NOT call for the CA to retain the private key, the
>example is flawed.  That is, a compliant CA would not have to retain the
>private key it generated (nor an ability to regenerate it).  So, licensing
>PKIX part 3 compliant CAs, the year 2000 event in your example, does not
>achieve the effect you cited.  To achieve the predicted effect, vendors
>would have to choose to retain this data, a design "feature" outside the
>scope of the standard.  In that case, your wrath should be directed against
>any vendor who chooses to take this approach.  However, if we predict
>vendors adopting this tact, wny not assume that they will do so
>irrespective of the standard?  This seems to be a typical slippery slope.
>
>        I'll assume that the smoke-filled room allusion was in reference to
>something other than the deliberations taking place on this list. Besides,
>I don't smoke and always request non-smoking seating in restaurants,
>airplanes, etc. :-).
>
>Steve

Steve,

Sorry about the "smoke-filled room", I was conjuring up the nameless forces
over which we have little knowledge or control.  But on that subject...

I find little comfort with "key gen feature does NOT call for the CA to
retain the private key..."  I *would* be satisfied with "key gen feature
makes it provably impossible for CA to retain the private key" but I don't
believe such technology exists in software, and why should I trust hardware
where the blueprints, circuit masks and detailed algorithms are not available
for public review? (regard my reply to Al Arsenault.)

If and when my private transmissions are compromised, either to government or
business rivals (how might I know this directly?) my main interest would not
be to excoriate the CA, or to bring legal action, but rather turn back the clock
and erase the unwanted exposure, (an impossible task.)  In lieu of this, I would
wish to rely upon processes where I remain the master of my destiny, to the
degree that this is still possible.

If a warrant is issued that I must turn over a given secret key or face jail,
I prefer to make the choice myself, rather than have it made for me.

I know I am pushing the left edge of the envelope with this position, but the
powers that would push it the other way are larger (and certainly better
organized) than I am, so please pardon the stridency of my statements.

___TONY___ (speaking only for myself)

Date: Fri, 5 Sep 1997 13:32:45 -0700
To: "Arsenault, Al W." <[email-masked]>
From: [email-masked] (Tony Bartoletti)
Subject: Re: Too many options
Cc: [email-masked]

Al Arsenault wrote
>
>From: Mark Shuttleworth
>
>
>>> doing in addition to signing her certificate.  (Maybe he's creating
>another
>>> certificate with her name/user id and a different key, which he'll use
>later
>>> on.)  She either trusts the organizational process, or she doesn't.
>
>>A CA could do that anyway. But getting the CA to generate the key creates
>>a new potential problem - that more than one entity has had access to a
>>supposedly private key.
>
>Please refer to my original scenario, in which the only way the CA could
>have gotten access to the private key was to physically attack the token.
> (I would hope we're working in an environment in which that's pretty tough
>to do without being detected.)  In that scenario, I assert that the real
>problem is the CA generating a separate certificate with a separate key, and
>that this doesn't change, regardless of whether the token is commanded to
>generate the key by the user or the CA.
>
>(Tokens which meet my criteria include the FORTEZZA card, when the key is
>generated with the user PIN enabled, and the EES-Lynks card, when extraction
>privileges are properly set.)
>
>               Al Arsenault

Are the internal blueprints to the FORTEZZA or EES-Lynks cards available for
public review, so that independent bodies of researchers can verify that they
contain no backdoors?  Or must we simply trust the people who have designed
and produced these cards?  I don't know the answer, I'm curious.

___TONY___

Date: Fri, 05 Sep 1997 14:22:36 -0400
To: "William Allen Simpson" <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: Possible SPKI simplifications
Cc: [email-masked], [email-masked]

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

At 02:43 AM 9/3/97 GMT, William Allen Simpson wrote:
>> From: Peter Williams <[email-masked]>
>> Im not willing to wait several years; Im planning for a world of three standards:
>> X.509 id certs, X.509 attribute certs, and SPKI-certs acting as an openCapability.
>>
>That's odd, I'm also planning for a world of three standards: SPKI certs,
>DNS Key/Sig, and PGP certs.
>
>I was hoping to make sure the SPKI effort can describe and link with
>both PGP and DNS.

re. my immediately previous answer to Peter, you can use PGP cert chains as a SDSI
name just as you could use VeriSign cert chains that way.  Both PGP and X.509
bind names to keys.  What we can't express that way is the PGP web of trust rules
(by which multiple, independent paths constitute more assurance that the binding
is correct) -- unless we implement k-of-n up front.  However, I believe the
consensus was to leave K-of-N out for now.

>I don't think SPKI is anywhere close to ready.  (heavy sigh)

I disagree.

 - 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, 05 Sep 1997 14:19:37 -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]

Peter,

	I think we're thinking along the same lines.  Let me try it in my
words.

	In SPKI, if you want to issue a permission to a given subject, you can
do 

that by late or early binding.

That is, you can issue:

(cert

  (issuer <<mykey>)

  (subject <<yourkey>)

  (tag <<permission>)

  (not-after <<date>)

  etc.?

)

(signature ...)

which is early binding to your key.

I can issue you a cert with late binding to your key, assuming you have a 

name in my name space:

(cert

  (issuer <<mykey>)

  (subject (name "Peter Williams"))

  (tag <<permission>)

  (not-after <<date>)

  etc.?

)

(signature ...)

However, if you have a cert already issued by VeriSign (likely, in your 

case), I could also issue you that permission via the SPKI cert:

(cert

  (issuer <<mykey>)

  (subject (name VeriSign CA1 ... CAn "Peter Williams"))

  (tag <<permission>)

  (not-after <<date>)

  etc.?

)

(signature ...)

where VeriSign is my name for your root key.  I don't know how many CAs
you 

have been the VeriSign root key and your own cert, or what they're named,
so 

I indicated those by

	CA1 ... CAn

This last cert has the side effect that I can be sure you have complied
with 

VeriSign's practices.  I believe that's the same thing you were saying 

below.  Am I correct?

 - Carl

At 04:06 AM 9/2/97 -0700, Peter Williams wrote: 

>>>>

<excerpt>  

<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>Im not willing to wait several years; Im planning for a world
of three standards: 

X.509 id certs, X.509 attribute certs, and SPKI-certs acting as an
openCapability. 

X.509 att-certs and id-certs instances are currently  linked via the
commonality 

of name forms (whichever name-form is chosen.) and the correpondence of 

a given value. 

I would now like to link SPKI-certs and (X.509 id-certs and X.509
att-certs) 

similarly. 

This is not a proposal for SPKI-certs to change their format: rather 

it is a proposal for there to be a standard linkage mechanism, basedon
use of the SDSINameForm and the role it plays in its namemanagement
model. 

I would like your consent to reference the SPK cert document's <<name>
form 

definition, and an approval that this would make such an X.509 cert 

conform to the ideas of SPKI local-naming and security concepts (when
used in 

consort with an SPKI-chain reduction). 

 ----- 

Here is my example of a practical and useful intersection between the two 

worlds, whicih are otherwise independently managed except for 

mutual use of a name-form and values:- 

bob, alice and freda are all subscribers to a single X.509 certification 

domain, and its formal policy obligations on all. 

skywalker is a portending SPKI verifier who receives an SPKI cert chain 

vouching for the name "bob's alice's freda" 

Skywalker, wishing to reduce the SPKI cert chain for classical 

security controls , and during this process (below) wishing to optionally 

obtain third-party control benefits, 

(a) uses the X.509 id-certs from third-party (CA) to 

establish that 'bob is bob' and <bold>is indeed bound to the CA
policy</bold>. Similary for 

alice, and freda. 

(b) obtains a CA-issued cert for the reduced-name "skywalker's (bob's
alice's freda)" 

in order that skywalker can demonstrate the acceptance of the act 

and consequences of auth-fields reduction to a third-party during dispute
handling, and that 

all four parties are <bold>indeed agreeing to be bound to the [disputed
resolution elements</bold> 

<bold>of the] policy, in the context of the reduced the auth
field.</bold> 

<excerpt>

- Carl 

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

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

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

|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | 

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

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

</excerpt>  

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

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

|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, 05 Sep 1997 11:16:43 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Mark Shuttleworth <[email-masked]>
CC: "Arsenault, Al W." <[email-masked]>, "[email-masked]" <[email-masked]>, John Horton <[email-masked]>
Subject: Re: Too many options

Another possibility along these lines, is the case where a user
wants to have multiple certificates for a single public/private key.
In that case, I might not trust a particular CA all that much. If
at a later date, I decide not to trust a particular CA, I still want
my private key to stay private and I don't care about what certs
that particular CA issues.

I hope the discussion is just to allow a CA the option of generating
the private key and nobody is planning to make that mandatory.

Ambarish

Mark Shuttleworth wrote:
> 
> > doing in addition to signing her certificate.  (Maybe he's creating another
> > certificate with her name/user id and a different key, which he'll use later
> > on.)  She either trusts the organizational process, or she doesn't.
> 
> A CA could do that anyway. But getting the CA to generate the key creates
> a new potential problem - that more than one entity has had access to a
> supposedly private key.
> 
> --
> Mark Shuttleworth
> Thawte Consulting

-- 

---------------------------------------------------------------------
Ambarish Malpani
Architect					       (408) 738-2040
ValiCert, Inc.				      http://www.valicert.com
333 W. El Camino Real, Suite 270
Sunnyvale, CA 94087

Date: Fri, 05 Sep 1997 11:50:44 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Authentication vs. nonrepudiation, and other legal issues.

>>>> Stephen Kent <[email-masked]> 09/04 10:46 AM >>>
>Peter,
>
>Your messages always provide so much food for thought ...
>
>Yes, in a legal context, one can declare authentication to be equivalent to
>non-repudiation, but as technologists, we know better.  We can choose, as
>you suggest, to remain silent on this point, and allow any interpretation
>to be imposed the bits we provide, or we can take a stand that we believe
>is supportable in terms of good technical practice.  I don't question the
>likelihood of your example, but I do question whether we ought to be
>willing accomplices in such uses.
>

Peter and Steve,

I confess that I have not followed this particular thread as closely as I
perhaps should have, so I would appreciate a reprise of the arguments.

But on Monday I will be attending a drafting session for the Illinois
Electronic Commerce Security Act, and I expect that some of these issues
will come up. The current Illinois draft is by far the best and most
comprehensive draft digital signature legislation yet developed, IMHO --
they have had the benefit of some 39 other state's successes and mistakes to
draw upon. The latest draft, dated September 2, is available on www.mbc.com.

(That web site is maintained by Tom Smedinghoff of McBride Baker & Coles,
Chairman of the Illinois Commission on Electronic commerce and Crime, and
Chair of  the ABA Electronic Commerce Division within the Science and
Technology Section. It also has a number of other interesting articles,
including an excellent short piece entitled "Analyzing State Digital
Signature Legislation," which is well worth reading --
http://www.mbc.com/ds_rev.html.  Another useful and frequently updated
article summarizes the status of digital signature legislation on a
jurisdiction by jurisdiction basis within the US and foreign countries --
http://www.mbc.com/ds_sum.html.)

In the Illinois act, they attempt to differentiate between an electronic
signature, which can be a mark or security procedure that is analogous to
the UCC's concept of a mark as a signature, vs. a digital signature which is
affixed to a document in a nonrepudiable manner. As Smedinghoff says in his
"Analyzing" article:

  "Legislation that has been enacted or proposed addresses two different
categories of signatures -- electronic signatures and digital signatures.
The more general term "electronic signature" is generally defined as any
letters, characters, or symbols manifested by electronic or similar means
and executed or adopted by a party with an intent to authenticate a writing.
A "digital signature," on the other hand, is a subset of electronic
signatures that is defined by the use of asymmetric cryptography to create
the mark used to manifest intent by the signer. Typically, however, the
legislation in each state addresses either electronic signatures (23 states)
or digital signatures (15 states), but not both. The only exception is the
proposed Illinois legislation, which seeks to thoroughly address issues
raised by both electronic signatures and digital signatures. The legislation
in Florida, Indiana, Mississippi, and New Hampshire includes definitions of
both electronic and digital signatures, but only addresses issues raised by
one of the two categories."

        "In many cases, confusion is also created because the legislation
fails to properly distinguish between electronic signatures and digital
signatures. Thus, several statutes use the specific term "digital signature"
when what is meant is the more general term "electronic signature." States
in this category include California, Georgia, and Nebraska. Further 
confusion is introduced by some statutes that use, but make no attempt to
define, the subject of the legislation. States in this category include
Arizona (digital signature),  Connecticut (electronic signature), Hawaii
(digital signature), Kansas (digital signature), and Massachusetts
(electronic signature)."

  "States with legislation limited to electronic signatures differ on the
question of what qualifies as an electronic signature. The current
definition of signature in the UCC includes "any mark made with an intent to
authenticate". There is no requirement as to the nature of the mark that
qualifies, and indeed, courts have found quite a wide variety of marks will
qualify in addition to the traditional handwritten signature. Several states
have taken the same approach with respect to electronic signatures -- that
is, any form of electronic "mark" on a message can qualify as an electronic
signature. Legislation taking this approach includes Colorado, Florida,
Illinois, Indiana, Mississippi, New Hampshire, North Carolina, Rhode Island,
Texas, and Virginia." 

       "In other states, however, the legislation imposes significant
limitations on the type of electronic signature that will be considered
acceptable. Virtually all of the states that take this position impose the
same five requirements, which derive from the California legislation enacted
in late 1995. In these states, an electronic signature is effective only if
it is (1) unique to the person using it; (2) capable of verification; (3)
under the sole control of the person using it; (4) linked to the data in
such a manner that if the data is changed the signature is invalidated; and
(5) conforms to regulations adopted by the Secretary of State. This approach
is somewhat interesting, in that it requires attributes of security as a
precondition to the validity of the signature itself, something not required
for paper-based signatures. States that have adopted this approach include
California, Georgia, Kansas, and Nebraska."

  "Of the 39 states actively addressing electronic and digital signature
issues, 16 of those states deal specifically with pki-based digital
signatures, and the legal infrastructure necessary to utilize digital
signatures. Of those 16 states, seven have enacted statutes."

    "Most of the states that have sought to address the issues raised by the
use of PKI digital signatures have concluded that it is necessary for a
state agency (typically the Secretary of State) to issue regulations
governing the implementation and use of a digital signature infrastructure,
and most of those states have also concluded that licensing of certification
authorities is appropriate. In all such states, however, the licensing of
certification authorities is voluntary, although there are
statutorily-granted advantages to the use of a certificate issued by a
licensed certification authority. Moreover, all of the PKI digital signature
statutes are based primarily on the model initially enacted in Utah, the
first state to enact digital signature legislation. The only exceptions are
Florida, Illinois, and Mississippi."

  "Another interesting element of digital and electronic signature
legislation is the legal effect of using a signature. All of the electronic
signature statutes simply provide that use of an electronic signature on an
electronic record will be treated in the same manner as handwritten
signature on paper -- that is, it meets applicable legal writing and
signature  requirements. Thus, the burden remains on the plaintiff to
authenticate the signature on an electronic record, a burden that might be
somewhat difficult to meet in an electronic environment."

   "Most of the pki-based digital signature statutes, on the other hand,
provide that digitally signed messages, assuming they are properly verified
by reference to a certificate issued by a licensed certification authority,
will be treated as self-authenticating documents. That is, there will be a
legal presumption that the person whose name is associated with the
signature is, in fact, the person who signed the document, thereby shifting
the burden to the defendant to deny that he or she signed the document."

With that as background, the issue that presently needs to be addressed
within the Illinois statute is to clearly distinguish between an
authenticated document vs. a signed document.

As I see it, the transmission of a document over an authenticated SSL
session might be the electronic equivalent of a doodle, it might be a draft
for review only, or it might constitute a legally signed document.  However,
as Smedinghoff makes clear, there is a difference in who has the burden of
proof, and what the presumptions are.

We'll see what the attorneys have to say, but my viewpoint would be that a
document transmitted over an authenticated SSL session could be legally
binding, but if and only if the following conditions were present:

1.  The intent of the originator to be bound by the transmission, message,
or document is clearly indicated within the text of the transmission itself,
either explicitly (preferably) or implicitly, by custom or context.

2.  The SSL session is authenticated by a certificate which identifies the
originator, or at a minimum the originator's client workstation or employer
-- something that sufficiently closely attached to the originator to
reasonably imply a binding or nexus.

3.  The recipient of the transmission saves both the contents of the
transmission and the context of the SSL session in such a manner as to
reasonably establish a connection between them, under the business records
exemption to the hearsay rule.
Although I'm never quite sure what the latest politically correct jargon is
for these terms within X.509 or ISO, to me the above scenario technically
constitutes authentication without nonrepudiation, because the transmission
is not permanently linked to the originator of the transmission, message or
document, but only transiently. The burden of proof therefore should be on
the plaintiff, to prove that his record of what clearly constitutes a
security procedure under the UCC definition of a signature can be relied on.

On the other hand, at least within those states that have addressed a
PKI-based digital signature and conferred self-authenticating status on
digitally signed documents, the burden of proof is transferred to the
defendant to prove that she did not sign the document, assuming that the
digital signature was validated by use of a certificate issued by an
approved (licensed, accredited, etc.) CA.

There is still the possibility that someone digitally signed a doodle or a
draft, and did not intend to connote a legally binding approval thereby, and
that is one reason why I wish that we had incorporated some of the reason
codes specified by X9 into the signature itself.  Trying to indicate intent
through the use of key usage bits is a very clumsy alternative, and having
to read and understand the text of the document itself, especially if it is
a preliminary draft of what is ultimately intended to be a binding contract,
is likely to be difficult.

In a sense, we need a "digitally initialed" indicator, which would specify
that the document came from or was reviewed by the originator, but is not
intended to convey any intent to create final, legally binding approval. 
Maybe authentication without nonrepudiation conveys that sense, but having
to use two different certificates with two different key usage bits is
certainly clumsy.

There is another issue which I am almost afraid to raise, but it involves
the intended use and any caveats and limitations that a subscriber might
wish to impose on his use of his public/private key pair.

Suppose I go to VeriSign and get a Class 3 certificate, intending to use it
for signing routine e-mail and making purchases via the web, etc. When I
generated the key pair, the private key was stored on a floppy disk,
encrypted in my password so that a thief could not reasonably gain access to
it.  But what about my spouse, child, or significant other?

If I thought enough about it, when I requested the certificate in the first
place, I should have taken it out in joint name -- Mr. John and/or Mrs. Jane
Doe.  Then either of us could use the private key (by sharing the password)
to do home banking,. home shopping, etc.,  and it would be quite clear under
UCC rules that we had a joint liability for anything that was so signed.

Even if I took out the certificate in my own name only, but allowed my wife
to use my private key, as I understand the law I would be liable for her
purchases.  That seems only reasonable -- I understand that I have a
positive duty to exercise reasonable care over my private key, and to the
extent that I do not, the burden of proof is on me to prove that I did not
make those purchases. And even if I can prove that I didn't make them, I may
still be financially responsible for them.

But now what happens if my significant other decides that he or she doesn't
particularly like the terms of my last will and testament, and during the
validity period of the certificate *(prior to my death), rewrites the will
or adds a codicil that names him or her as the sole beneficiary, keeping the
revised document a secret to me?

Under some state's statutes or drafts, a digitally signed document would be
considered self-authenticating, i.e., the legal equivalent of a notarized
document. So my "revised" will might very well be accepted as at least the
equivalent of a holographic will, and might very well trump my real will,
which was typed, initialed on each page, signed, and witnessed.

The Illinois statute will probably exclude such documents as wills, trusts,
living wills, heath care powers of attorney, durable powers of attorney and
other documents where the importance of ceremony (including the need for
counsel and due deliberation), the attestation to sobriety and mental
capacity and the absence of obvious compulsion that is provided by a third
party witness, and the inability of the alleged originator to repudiate the
document post mortem is of obvious importance.

But what about other states and jurisdictions?

After much discussion, we have finally accepted the notion of a
Certification Practice Statement that is incorporated by reference in the
certificate. But this is clearly intended primarily to protect the CA.
Although conceivably I could negotiate such things as reliance limits and
other aspects with my CA, as an individual subscriber I'm likely to be in
the position of a mosquito attacking an elephant.

How can I as a subscriber include a reasonable set of caveat and limitations
within any certificate that is issued to me?  Things that I might want to
include is my own choice of law state in the event my digital signature is
challenged, certain forbidden uses (I can't and won't use it to sign
documents urging the overthrow of the Government, or to agree to anything
illegal, or to sign a will, etc.) and an exclusion for any transaction
having a value in excess of $10,000, etc.

Seems to me that we collectively need to pressure the various public CAs to
include such caveats and limitations in their CPS or policy statements, or
we need to have the equivalent of a CPS for the individual subscriber. 
Given the extent to which the 39 different states which have passed or are
considering digital signature legislation are all over the map with respect
to some of these issues, I don't feel very comfortable with these kinds of
ambiguities.

Bob

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

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: "Arsenault, Al W." <[email-masked]>
To: "Arsenault, Al W." <[email-masked]>, Mark Shuttleworth <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, John Horton <[email-masked]>
Subject: Re: Too many options
Date: Fri, 05 Sep 97 13:20:00 EDT
Encoding: 32 TEXT

From: Mark Shuttleworth

>> doing in addition to signing her certificate.  (Maybe he's creating
another
>> certificate with her name/user id and a different key, which he'll use
later
>> on.)  She either trusts the organizational process, or she doesn't.

>A CA could do that anyway. But getting the CA to generate the key creates
>a new potential problem - that more than one entity has had access to a
>supposedly private key.

Please refer to my original scenario, in which the only way the CA could 
have gotten access to the private key was to physically attack the token. 
 (I would hope we're working in an environment in which that's pretty tough 
to do without being detected.)  In that scenario, I assert that the real 
problem is the CA generating a separate certificate with a separate key, and 
that this doesn't change, regardless of whether the token is commanded to 
generate the key by the user or the CA.

(Tokens which meet my criteria include the FORTEZZA card, when the key is 
generated with the user PIN enabled, and the EES-Lynks card, when extraction 
privileges are properly set.)

               Al Arsenault

          

Date: Fri, 5 Sep 1997 11:05:34 -0400 (EDT)
From: Bancroft Scott <[email-masked]>
To: Rich Ankney <[email-masked]>
Cc: [email-masked]
Subject: Re: BMPString
Content-Length: 654

On Fri, 5 Sep 1997, Rich Ankney wrote:

> Wasn't there a change to X.520 to include BMPString as an additional choice
> in the DirectoryString construct?  PKIX-1 still reflects the old construct.

Yes.  The inclusion of BMPString was made to X.520 about three or so
years ago.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-908-249-5107
http://www.oss.com                            Fax          :1-908-249-4636

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: BMPString
Date: Fri, 5 Sep 1997 09:50:42 -0400

Wasn't there a change to X.520 to include BMPString as an additional choice
in the DirectoryString construct?  PKIX-1 still reflects the old construct.

Regards,
Rich

Date: Thu, 4 Sep 1997 18:14:32 -0500
To: [email-masked] (Tony Bartoletti)
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Tony,

	I do not question the plausibility of the scenario you described;
it'salways useful to examine possibe worst case scenarios in evaluating
systems.  Your point, and that of some others who object to making CA key
gen a mandatory option, is that this would significantly facilitate
government imposition of the controls you describe.  However, since the CA
key gen feature does NOT call for the CA to retain the private key, the
example is flawed.  That is, a compliant CA would not have to retain the
private key it generated (nor an ability to regenerate it).  So, licensing
PKIX part 3 compliant CAs, the year 2000 event in your example, does not
achieve the effect you cited.  To achieve the predicted effect, vendors
would have to choose to retain this data, a design "feature" outside the
scope of the standard.  In that case, your wrath should be directed against
any vendor who chooses to take this approach.  However, if we predict
vendors adopting this tact, wny not assume that they will do so
irrespective of the standard?  This seems to be a typical slippery slope.

	I'll assume that the smoke-filled room allusion was in reference to
something other than the deliberations taking place on this list. Besides,
I don't smoke and always request non-smoking seating in restaurants,
airplanes, etc. :-).

Steve

Date: Thu, 4 Sep 1997 11:46:40 -0500
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: PKIX-1 key purpose
Cc: [email-masked]

Peter,

Your messages always provide so much food for thought ...

Yes, in a legal context, one can declare authentication to be equivalent to
non-repudiation, but as technologists, we know better.  We can choose, as
you suggest, to remain silent on this point, and allow any interpretation
to be imposed the bits we provide, or we can take a stand that we believe
is supportable in terms of good technical practice.  I don't question the
likelihood of your example, but I do question whether we ought to be
willing accomplices in such uses.

You have argued fervently against CA key gen, but the basis of those
arguments is precisly a policy argument, not a technical one.  If we make
this facility an option, vs. a mandatory option, that will be a prime
example of shaping the spec based on a policy for which there appears to be
WG concensus.  So, why is the notion of declaring a limited scope for usage
bits, based on a policy perspective that has general support within the WG,
out of scope?

Steve

From: Trevor Freeman <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked]
Subject: RE: CA enforcement of centralized key generation?
Date: Fri, 5 Sep 1997 04:07:36 -0700

Hi Bob,
I am NOT advocating that with the key generation function being split
from the CA, it is mandatory for a CA to enforce the fact that central
key generation has occurred. I can see that my original email can be
interpreted that way, but that was not my intent, so let me try and
clarify things. 
The CA is a policy animal. Its policy may want it to find out more about
the keys following a certificate request. When it generates
certificates, this generation occurs under the policy of the CA
operator. In this new world where key management is separate from
certificate management, we are in agreement that by default, the CA will
not know from the certificate request where the keys were generated, and
in many environments that's fine. The CA MAY operate a policy where its
wants to find out more about the keys, like where the keys generated by
key management system? where they generated with a good random seed? are
they backed up \ escrowed?. It's policy may or may not choose to issue
the certificate based on information it finds out about the keys. Its
policy may or may not add policy OIDs to the certificate, reflecting
information it finds out about the keys. As all these considerations are
all policy based, then they should form no part of a mandatory protocol
profile.

Hope this clears things up.
Trevor

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Thursday, September 04, 1997 3:50 PM
> To:	Trevor Freeman; [email-masked]
> Subject:	CA enforcement of centralized key generation?
> 
> Trevor,
> 
> >Separating key generation and key management from certificate
> management
> >seems the best solution all round. How keys are generated and managed
> is
> >an implementation issue which has lots of technical/political/legal
> >baggage which will vary by implementation, by country and by  lots of
> >other things. The CA can now get on with its job of managing
> >certificates without being tainted by these other considerations. 
> 
> We're certainly in agreement here.
> 
> >If
> >someone wants to implement a central key generation scheme, then the
> CA
> >will just have to check with the key management system before it
> issues
> >the certificate. This may mean that some key management to CA
> management
> >messages are required. This can be accommodated by existing pkix3
> >messages as the key management system only has to do a proof of
> >possession for the CA.
> >Trevor
> >.
> 
> You seem to be bringing up a point I hadn't thought of. You seem to be
> suggesting that there may be a requirement within some organizations
> to
> PREVENT the use of other than centralized key generation, and more
> importantly, that the CA should play a role in enforcing such a
> restriction.
> 
> I had envisioned a system where the user/client would send off a
> request for
> key generation to some designated server, and would receive a reply
> consisting of the private key plus the public key.  Depending on the
> environment, it may be necessary for the key generation facility to
> digitally sign the public key (or at least a separate message digest
> of it)
> in order to establish its "political correctness".  But I had assumed
> that
> it would be sufficient to merely extract the public key and include it
> in
> the prototype certificate to be sent to the CA.  The CA would require
> proof
> of possession of the private key, of course, but in my original
> thinking the
> certificate request would have been indistinguishable from one where
> the
> keys were generated locally.
> 
> I really don't want to start down the slippery slope of having the CA
> refuse
> to issue a certificate unless a government-approved key recovery
> center has
> generated or otherwise approved a public/private key, but I am willing
> to
> discuss whether corporations might have a legitimate need to ensure
> that
> keys were generated using their central system prior to that corporate
> CA
> issuing the individual a certificate.
> 
> Could you say a little more about what you think the requirement is,
> before
> we 
> jumping into discussing potential mechanisms?
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                                   

Date: Fri, 5 Sep 1997 10:58:45 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: "Arsenault, Al W." <[email-masked]>
cc: "[email-masked]" <[email-masked]>, John Horton <[email-masked]>
Subject: Re: Too many options

> doing in addition to signing her certificate.  (Maybe he's creating another 
> certificate with her name/user id and a different key, which he'll use later 
> on.)  She either trusts the organizational process, or she doesn't.

A CA could do that anyway. But getting the CA to generate the key creates
a new potential problem - that more than one entity has had access to a
supposedly private key.

--
Mark Shuttleworth
Thawte Consulting

Date: Thu, 04 Sep 1997 19:54:16 -0400
From: John Horton <[email-masked]>
Reply-To: [email-masked]
To: "Arsenault, Al W." <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Too many options

Arsenault, Al W. wrote:
> =

> I must respectfully disagree with your conclusions.
> =

> >I guess now that Bob has written a response, I would like to throw in =
my
> >$.02 to this discussion.
> =

> >IMHO the difference between these 2 scenarios can be explained in one
> >word - TRUST.  Not that these 2 systems can't be trusted, but the
> >perception of trust by the those that must buy into a system - the end=

> >users and owners of these types of systems.  Any system that is to be
> >used widely and effectively must be able to be trusted beyond a shadow=

> >of a doubt by everyone.
> =

> This part I agree with.
> =

> >Scenario A provides Alice an opportunity to actively participate,
> >therefore allowing buy-in and building the trust factor.
> =

> True, it allows Alice the opportunity to actively participate.  True, t=
his
> may give
> her some reason to "trust" the system.  But let's face it, unless Alice=
 is a
> highly-skilled user (and I wish they all were, but all too few users ar=
e so
> highly skilled), she doesn't really understand what's going on behind a=
ll of
> this, anyway.  She doesn't know how good the card she's using is at
> generating public/private key pairs, and she doesn't know what the CA i=
s
> doing in addition to signing her certificate.  (Maybe he's creating ano=
ther
> certificate with her name/user id and a different key, which he'll use =
later
> on.)  She either trusts the organizational process, or she doesn't.

IMHO you have accidently hit upon the reason for the differences in the
2 systems.  =

Because Alice and Bob may not understand what is going on behind all of
this, they both need to have some involvement.  The initial involvement
becomes incremental learning, that may quite possibly remove their
suspicions because they (Alice and Bob) develop an understanding of the
system.  =

In general, when people are initially presented with an unknown, some
are curious, some are suspicious, some blanketly accept, and some are a
combination of the aforementioned.  Some people attempt to learn and
gain an understanding of the system so that it does not pose a threat. =

The information they learn about the system is passed on to those by
word of mouth, and based on this information, the system is accepted or
rejected.  It happens all the time.  Vendors educate customers about
their products.  The IETF educates us with published RFCs and list
servers.

People today are inherently suspicious of organizational processes and
systems that they don't understand until the smoke is cleared away.

> =

> >Scenario B removes Bob from any involvement, thereby creating doubt an=
d
> >the possibility of misperceptions about the trustworthiness and
> >integrity of the system.
> =

> Bob is probably at about the same skill level as Alice.  His involvemen=
t (or
> lack thereof) most likely doesn't affect his trust in the system.  His =
trust
> is based on his perception of how the organization operates in general.=
  If
> he perceives it to be intrusive or incompetent, he likely doesn't trust=
 the
> system.  If perceives it to be competent and caring, he probably does t=
rust
> it.
> =

> >Regards,
> >John Horton
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> =

>                      Al Arsenault
> =

>  "I speak only for myself.  My opinions do not necessarily represent th=
ose
> of  my employer."

-- =

          ___
        _|___|_
         (=F6 =F6)
O------ooO-( )-Ooo------------------------O
|   John Horton                           |
|   VPNet Technologies, Inc.              |
|   <Mailto:[email-masked]>           |
|   http://www.vpnet.com                  |
|   tel:  1 888 VPNET-88 (876-3888) x603  |
|   fax:  1 301 428-3270                  |
O------(___)--(___)-----------------------O

Date: Wed, 03 Sep 1997 23:02:33 -0400
From: John Horton <[email-masked]>
Reply-To: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: Re: Too many options

I guess now that Bob has written a response, I would like to throw in my
$.02 to this discussion.  

IMHO the difference between these 2 scenarios can be explained in one
word - TRUST.  Not that these 2 systems can't be trusted, but the
perception of trust by the those that must buy into a system - the end
users and owners of these types of systems.  Any system that is to be
used widely and effectively must be able to be trusted beyond a shadow
of a doubt by everyone.  

Scenario A provides Alice an opportunity to actively participate,
therefore allowing buy-in and building the trust factor.  

Scenario B removes Bob from any involvement, thereby creating doubt and
the possibility of misperceptions about the trustworthiness and
integrity of the system.

Regards,
John Horton
===============================================================================

Arsenault, Al W. wrote:
> 
> 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: Wed, 03 Sep 1997 23:02:33 -0400
From: John Horton <[email-masked]>
Reply-To: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: Re: Too many options

I guess now that Bob has written a response, I would like to throw in my
$.02 to this discussion.  

IMHO the difference between these 2 scenarios can be explained in one
word - TRUST.  Not that these 2 systems can't be trusted, but the
perception of trust by the those that must buy into a system - the end
users and owners of these types of systems.  Any system that is to be
used widely and effectively must be able to be trusted beyond a shadow
of a doubt by everyone.  

Scenario A provides Alice an opportunity to actively participate,
therefore allowing buy-in and building the trust factor.  

Scenario B removes Bob from any involvement, thereby creating doubt and
the possibility of misperceptions about the trustworthiness and
integrity of the system.

Regards,
John Horton
===============================================================================

Arsenault, Al W. wrote:
> 
> 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."

From: "Arsenault, Al W." <[email-masked]>
To: "[email-masked]" <[email-masked]>, John Horton <[email-masked]>
Subject: Re: Too many options
Date: Thu, 04 Sep 97 15:56:00 EDT
Encoding: 52 TEXT

I must respectfully disagree with your conclusions.

>I guess now that Bob has written a response, I would like to throw in my
>$.02 to this discussion.

>IMHO the difference between these 2 scenarios can be explained in one
>word - TRUST.  Not that these 2 systems can't be trusted, but the
>perception of trust by the those that must buy into a system - the end
>users and owners of these types of systems.  Any system that is to be
>used widely and effectively must be able to be trusted beyond a shadow
>of a doubt by everyone.

This part I agree with.

>Scenario A provides Alice an opportunity to actively participate,
>therefore allowing buy-in and building the trust factor.

True, it allows Alice the opportunity to actively participate.  True, this 
may give
her some reason to "trust" the system.  But let's face it, unless Alice is a 
highly-skilled user (and I wish they all were, but all too few users are so 
highly skilled), she doesn't really understand what's going on behind all of 
this, anyway.  She doesn't know how good the card she's using is at 
generating public/private key pairs, and she doesn't know what the CA is 
doing in addition to signing her certificate.  (Maybe he's creating another 
certificate with her name/user id and a different key, which he'll use later 
on.)  She either trusts the organizational process, or she doesn't.

>Scenario B removes Bob from any involvement, thereby creating doubt and
>the possibility of misperceptions about the trustworthiness and
>integrity of the system.

Bob is probably at about the same skill level as Alice.  His involvement (or 
lack thereof) most likely doesn't affect his trust in the system.  His trust 
is based on his perception of how the organization operates in general.  If 
he perceives it to be intrusive or incompetent, he likely doesn't trust the 
system.  If perceives it to be competent and caring, he probably does trust 
it.

>Regards,
>John Horton
============================================================================ 

                     Al Arsenault

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

Date: Thu, 04 Sep 1997 08:49:50 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: CA enforcement of centralized key generation?

Trevor,

>Separating key generation and key management from certificate management
>seems the best solution all round. How keys are generated and managed is
>an implementation issue which has lots of technical/political/legal
>baggage which will vary by implementation, by country and by  lots of
>other things. The CA can now get on with its job of managing
>certificates without being tainted by these other considerations. 

We're certainly in agreement here.

>If
>someone wants to implement a central key generation scheme, then the CA
>will just have to check with the key management system before it issues
>the certificate. This may mean that some key management to CA management
>messages are required. This can be accommodated by existing pkix3
>messages as the key management system only has to do a proof of
>possession for the CA.
>Trevor
>.

You seem to be bringing up a point I hadn't thought of. You seem to be
suggesting that there may be a requirement within some organizations to
PREVENT the use of other than centralized key generation, and more
importantly, that the CA should play a role in enforcing such a restriction.

I had envisioned a system where the user/client would send off a request for
key generation to some designated server, and would receive a reply
consisting of the private key plus the public key.  Depending on the
environment, it may be necessary for the key generation facility to
digitally sign the public key (or at least a separate message digest of it)
in order to establish its "political correctness".  But I had assumed that
it would be sufficient to merely extract the public key and include it in
the prototype certificate to be sent to the CA.  The CA would require proof
of possession of the private key, of course, but in my original thinking the
certificate request would have been indistinguishable from one where the
keys were generated locally.

I really don't want to start down the slippery slope of having the CA refuse
to issue a certificate unless a government-approved key recovery center has
generated or otherwise approved a public/private key, but I am willing to
discuss whether corporations might have a legitimate need to ensure that
keys were generated using their central system prior to that corporate CA
issuing the individual a certificate.

Could you say a little more about what you think the requirement is, before
we 
jumping into discussing potential mechanisms?

Bob

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

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                  

From: Trevor Freeman <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: RE: Too many options
Date: Thu, 4 Sep 1997 04:03:53 -0700

Separating key generation and key management from certificate management
seems the best solution all round. How keys are generated and managed is
an implementation issue which has lots of technical/political/legal
baggage which will vary by implementation, by country and by  lots of
other things. The CA can now get on with its job of managing
certificates without being tainted by these other considerations. If
someone wants to implement a central key generation scheme, then the CA
will just have to check with the key management system before it issues
the certificate. This may mean that some key management to CA management
messages are required. This can be accommodated by existing pkix3
messages as the key management system only has to do a proof of
possession for the CA.
Trevor

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Wednesday, September 03, 1997 4:40 PM
> To:	[email-masked]; [email-masked];
> [email-masked]
> Subject:	Re: RE: Too many options
> 
> Hi, Al -- it's been a long time.
> 
> I don't know whether you saw all of the previous correspondence, but I
> will
> try to synopsize it.
> 
> The reasons why I think that combining key generation with the CA
> function
> is a bad idea has nothing to do with any possible security flaw, but
> is
> instead based on a political/business observation, and on parsimony.
> 
> The political/business argument is that to date no support from the CA
> community for this particular option has emerged, which at a minimum
> argues
> for a lack of enthusiasm.  In addition, there is a perception that is
> almost
> surely not unimimous but none the less needs to be address, that
> having your
> Certification Authority have access to your private signing key or
> even your
> private encryption key would result in a very unfortunate blurring of
> the
> two roles of key recovery and certificate issuance. The American BAr
> Association's Information Security Committee, whose chairman is
> Michael
> Baum, VP of External Relations and Practices at VeriSign, recently
> based a
> resolution effectively condeming the McCain/Kerrey bill for attempting
> to
> commingle those two functions. given that lack of support and arguably
> active opposition to the concept, I don't feel that we should end up
> mandating that the CAs have to provide such a capability -- especialy
> if
> there is even the slightest possibility that it might detract from the
> emergence of a robust electronic commerce infrastructure, as I am
> afraid it
> might.
> 
> The parsimony argument is essentially the flip side of the issue.
> Without
> wanting to necessarily get involved in the emotional issue of
> government
> access to encryption keys and possible mandatory key recovery systems,
> I
> merely observe that there is a growing demand for centralized key
> generation
> -- either for reasons of convenience (more or less along the lines you
> discussed), for improved security (perhaps because a hardware key
> generator
> is used and/or a high security platform), or to provide key recovery
> for the
> individual enterprise, if not government access.
> 
> All of those requirements tend to dictate the use of a centralized key
> generation service, so we do need a protocol which would accommodate
> that. 
> But given one such protocol, which the CAs could also use if desired,
> I
> don't believe that we should implement the function twice -- once to
> support
> CAs and once for everyone else.
> 
> A single remote key generation request and response protocol will
> handle all
> of the possibilities for non-local key generation, ranging from an
> application calling another application on the same machine, to a
> server
> generating keys for a client, to a corporate key generation (and/or
> key
> recovery center, to some kind of a national key generation and
> recovery
> center, e.g., along the Royal-Hollaway lines. CAs, of course, would
> also be
> free to use this same protocol, if they decide they want to be in that
> business.
> 
> In summary:
> 
> 1.  There is an emerging requirement for distributed and/or
> centralized
> (non-local) key generation, which may or may not include some form of
> key
> recovery.
> 
> 2.  There does not seem to be any kind of a strong requirement or even
> desire for the CAs to actually perform this function, but if they
> really
> wish to they could use the general purpose key generation request and
> response referred to in 1.
> 
> 3.  Presupposing one general-purpose key generation request/response,.
> there
> does not seem to be any convincing reason to architect or implement a
> special purpose combined key generation/certificate issuing protocol,
> much
> less even think about making it mandatory.
> 
> 4. It is probably too soon to talk about making the key request
> function
> mandatory, when we haven't seen any details as to how this would be
> done. We
> can bring that subject back up again when the time comes, but at the
> moment
> I am included to say that it sould not be mandatory.
> 
> Hope that answers your questions.
> 
> Regards,
> 
> Bob
> 
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
> 
> 
> >>> "Arsenault, Al W." <[email-masked]> 08/28/97 08:11AM >>>
> 
> 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: Wed, 03 Sep 1997 23:02:33 -0400
From: John Horton <[email-masked]>
Reply-To: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: Re: Too many options

I guess now that Bob has written a response, I would like to throw in my
$.02 to this discussion.  

IMHO the difference between these 2 scenarios can be explained in one
word - TRUST.  Not that these 2 systems can't be trusted, but the
perception of trust by the those that must buy into a system - the end
users and owners of these types of systems.  Any system that is to be
used widely and effectively must be able to be trusted beyond a shadow
of a doubt by everyone.  

Scenario A provides Alice an opportunity to actively participate,
therefore allowing buy-in and building the trust factor.  

Scenario B removes Bob from any involvement, thereby creating doubt and
the possibility of misperceptions about the trustworthiness and
integrity of the system.

Regards,
John Horton
===============================================================================

Arsenault, Al W. wrote:
> 
> 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: Wed, 03 Sep 1997 05:15:09 -0700
From: Peter Williams <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: PKIX-1 key purpose

>
>
> > >  [for 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.
>
> I think I agree.  My inclination is to reserve "non-repudiation" exclusively
> for keys intended to be interpreted as legally binding upon the signer

I believe a *CA policy* **could** ask a subscriber to conform to such an
obgliation when using a private key. There is nothing technically
one can, or should do, to enforce such a semantic however
when claiming conforming status to the X.509 standard.

The ISO defnition of non-repudiation services is clear; you cannot alter
it in the PKIX-1 technical profile. Under the rules of the third party resolving
repudiation disputes,  the crypto evidence must be irrefutable, and, by
implication, the strength of the mechanisms used must be sufficient. It
says nothing about the proof standard being that of one countries
law system or another countries/group's law system. Access to
a PKIX-1 dispute resplution mechanism may for example cause
one to agree to cede rights to subsequently contest the same dispute
in court ("mandatory final arbitaration, for example, rule set").

We must not build policy into technical standards. Forcing folk
into legal-standards of proof when using a bit signal denies
other legitimate uses of the arbitration mechanism which
are less stringent than legal process, but are non the less useful
for perhaps 95% of cases.

Take an example of a competition in which poems are  submitted
over S/MIME  to Cadbury Chocolate company. Often the rules in the wrapper
will  say, the decision of Cadbury judges regarding submission deadlines, or
poem quality, is final. When enrolling for a Cadbury-competiion cert
so as to register for the competition, and thereupon agreeing to abide by the
competition rules, the resulting subscriber cert will have the NR bit set signalling
Cadbury is the third-party final arbiter. No lawyers involved - whatsoever.

Date: Wed, 03 Sep 1997 09:39:52 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Too many options

Hi, Al -- it's been a long time.

I don't know whether you saw all of the previous correspondence, but I will
try to synopsize it.

The reasons why I think that combining key generation with the CA function
is a bad idea has nothing to do with any possible security flaw, but is
instead based on a political/business observation, and on parsimony.

The political/business argument is that to date no support from the CA
community for this particular option has emerged, which at a minimum argues
for a lack of enthusiasm.  In addition, there is a perception that is almost
surely not unimimous but none the less needs to be address, that having your
Certification Authority have access to your private signing key or even your
private encryption key would result in a very unfortunate blurring of the
two roles of key recovery and certificate issuance. The American BAr
Association's Information Security Committee, whose chairman is Michael
Baum, VP of External Relations and Practices at VeriSign, recently based a
resolution effectively condeming the McCain/Kerrey bill for attempting to
commingle those two functions. given that lack of support and arguably
active opposition to the concept, I don't feel that we should end up
mandating that the CAs have to provide such a capability -- especialy if
there is even the slightest possibility that it might detract from the
emergence of a robust electronic commerce infrastructure, as I am afraid it
might.

The parsimony argument is essentially the flip side of the issue.  Without
wanting to necessarily get involved in the emotional issue of government
access to encryption keys and possible mandatory key recovery systems, I
merely observe that there is a growing demand for centralized key generation
-- either for reasons of convenience (more or less along the lines you
discussed), for improved security (perhaps because a hardware key generator
is used and/or a high security platform), or to provide key recovery for the
individual enterprise, if not government access.

All of those requirements tend to dictate the use of a centralized key
generation service, so we do need a protocol which would accommodate that. 
But given one such protocol, which the CAs could also use if desired, I
don't believe that we should implement the function twice -- once to support
CAs and once for everyone else.

A single remote key generation request and response protocol will handle all
of the possibilities for non-local key generation, ranging from an
application calling another application on the same machine, to a server
generating keys for a client, to a corporate key generation (and/or key
recovery center, to some kind of a national key generation and recovery
center, e.g., along the Royal-Hollaway lines. CAs, of course, would also be
free to use this same protocol, if they decide they want to be in that
business.

In summary:

1.  There is an emerging requirement for distributed and/or centralized
(non-local) key generation, which may or may not include some form of key
recovery.

2.  There does not seem to be any kind of a strong requirement or even
desire for the CAs to actually perform this function, but if they really
wish to they could use the general purpose key generation request and
response referred to in 1.

3.  Presupposing one general-purpose key generation request/response,. there
does not seem to be any convincing reason to architect or implement a
special purpose combined key generation/certificate issuing protocol, much
less even think about making it mandatory.

4. It is probably too soon to talk about making the key request function
mandatory, when we haven't seen any details as to how this would be done. We
can bring that subject back up again when the time comes, but at the moment
I am included to say that it sould not be mandatory.

Hope that answers your questions.

Regards,

Bob

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

>>> "Arsenault, Al W." <[email-masked]> 08/28/97 08:11AM >>>

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: Wed, 3 Sep 1997 11:59:28 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: William Allen Simpson <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Possible SPKI simplifications

> That's odd, I'm also planning for a world of three standards: SPKI certs,
> DNS Key/Sig, and PGP certs.

As someone who has just gone through the traumatic process of reverse
engineering PGP's signature format, I speak from experience when I say you
need your head read.

Philosophically, PGP's stuff is great.  But if OpenPGP is just PGP RFC'd,
it won't stand a chance.  It's inconsistent, ugly, and a whole lot of
other things.  An implementor spends a lot of time catering to vagaries
rather than adding valuable functionality.

BUT I think there's a lot that S/MIME could learn from it...
RSA-independence, thumbprint embedding rather than whole-cert-embedding,
canonicalising text for message signature purposes...  If we had the
consistency of S/MIME with the pragmatism of PGP we'd have a winner.

--
Mark Shuttleworth
Thawte Consulting

Date: Wed, 3 Sep 97 02:43:55 GMT
From: "William Allen Simpson" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Possible SPKI simplifications

> From: Peter Williams <[email-masked]>
> Im not willing to wait several years; Im planning for a world of three standards:
> X.509 id certs, X.509 attribute certs, and SPKI-certs acting as an openCapability.
>
That's odd, I'm also planning for a world of three standards: SPKI certs,
DNS Key/Sig, and PGP certs.

I was hoping to make sure the SPKI effort can describe and link with
both PGP and DNS.

I don't think SPKI is anywhere close to ready.  (heavy sigh)

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
[email-masked]
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Date: Tue, 2 Sep 1997 17:36:23 -0700
To: Stephen Kent <[email-masked]>
From: [email-masked] (Tony Bartoletti)
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Steve,

>Tony,
>
>
>>If a CA receives a "generate central keys" type of request, are they to be
>>viewed compliant if they can say (in effect):
>>
>>1.  This CA has chosen not to implement the requested service, or
>>
>>2.  This CA has chosen not to honor such requests (although required to
>>    implement full support for reasons of compliance.)
>>
>>Requiring (1) seems completely reasonable, independent of whether (the dark
>>side of) key recovery ever becomes a *real* issue.  The CA need only be able
>>to process the requests to the point of appropriate response (not hang, crash,
>>burn, etc.)
>>
>>Requiring (2) seems positively Orwellian.
>>
>>Clarification and comments wellcome.
>
>The second statement is exactly what a mandatory option calls for, i.e.,
>any product sold as compliant would have to be capable of supporting the
>request, but it is up to the operator of the CA service to decide whether
>to turn this feature on.  This is no more Orwellian than any other
>mandatory option.  For example, the current discussion in TLS is whether to
>require compliant browsers and servers to support D-H and DSA, even though
>almost all such systems currebtly make use of RSA.  No browser would be
>required to turn on support for the algorithms, but no implementation would
>be consiedred compliant unless these algorithms could be turned on.
>
>Steve

Well, that was clear enough, thank you.

I can certainly understand and appreciate the need among many for either or
both centralized keygen and key recovery.  I can even understand how certain
efficiencies may be gained by embedding such support in the certificate
protocols.

However, I hope that you also understand why many view such a tight coupling
with some alarm.  The scenario:

1999:  Terrorists wreak havok.  "If we'd had those keys we cound have
prevented this!" said presidential advisor.

2000:  CA licensing granted only to CA's that support keygen/key-recovery.
(No, actually only PKIX-3 compliance is required :-)

2001:  Certify digital keys without a licence, go to jail.

2002:  Another terrorist attack.

2003:  Centralized keygen/key-recovery mandatory by federal law.

2005:  Copies of all network traffic duplicated via high speed network to
NSA intelligent processors for political review...

OK, pardon the excess paranoia.

It certainly makes sense to standardize the form and content of centralized
key generation and key recovery for purposes of interoperability.  But to
embed it in the only network-wide key infrastructure per-se seems more than
just a convenience.

If I were to be a completely PKIX-3 compliant CA, EXCEPT for the keygen and
key recovery part, then I am not "mostly compliant", or "PKIX-3 compliant
but not PKIX-3+kg compliant, I am simply, starkly NOT COMPLIANT, which will
gain connotations of "flawed implementation", "poor interoperability", etc.

There are many other "key-related" services a CA may expand into offering,
such as "trusted timestamping", "notary public", etc.  These services can
(and likely will) be offered by many CAs, just as will keygen/recovery.
But they are not embedded into the protocol, and are certainly not required
for PKIX-3 compliance.

I do not mean to cast aversions, but I can't help envisioning the "smoke-
filled back rooms" where one imagines some of these decisions being crafted.

___TONY___

Date: Tue, 2 Sep 1997 19:13:26 -0400
To: [email-masked] (Tony Bartoletti)
From: Stephen Kent <[email-masked]>
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: [email-masked]

Tony,

>If a CA receives a "generate central keys" type of request, are they to be
>viewed compliant if they can say (in effect):
>
>1.  This CA has chosen not to implement the requested service, or
>
>2.  This CA has chosen not to honor such requests (although required to
>    implement full support for reasons of compliance.)
>
>Requiring (1) seems completely reasonable, independent of whether (the dark
>side of) key recovery ever becomes a *real* issue.  The CA need only be able
>to process the requests to the point of appropriate response (not hang, crash,
>burn, etc.)
>
>Requiring (2) seems positively Orwellian.
>
>Clarification and comments wellcome.

The second statement is exactly what a mandatory option calls for, i.e.,
any product sold as compliant would have to be capable of supporting the
request, but it is up to the operator of the CA service to decide whether
to turn this feature on.  This is no more Orwellian than any other
mandatory option.  For example, the current discussion in TLS is whether to
require compliant browsers and servers to support D-H and DSA, even though
almost all such systems currebtly make use of RSA.  No browser would be
required to turn on support for the algorithms, but no implementation would
be consiedred compliant unless these algorithms could be turned on.

Steve

Date: Tue, 2 Sep 1997 14:40:27 -0700
To: [email-masked]
From: [email-masked] (Tony Bartoletti)
Subject: Re: key recovery options for PKIX-3 CAs?
Cc: Stephen Kent <[email-masked]>

Steve (et al)

>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

I recall several score messages back, someone suggesting, or perhaps asking,
whether PKIX-3 compliance with respect to key recovery and/or centralized
key generation need require a CA to "implement support" for the given service,
or simply support recognition and appropriate response to these requests.

If a CA receives a "generate central keys" type of request, are they to be
viewed compliant if they can say (in effect):

1.  This CA has chosen not to implement the requested service, or

2.  This CA has chosen not to honor such requests (although required to
    implement full support for reasons of compliance.)

Requiring (1) seems completely reasonable, independent of whether (the dark
side of) key recovery ever becomes a *real* issue.  The CA need only be able
to process the requests to the point of appropriate response (not hang, crash,
burn, etc.)

Requiring (2) seems positively Orwellian.

Clarification and comments wellcome.

___TONY___

(speaking for myself, and not as...)

Tony Bartoletti                                             LL
SPI Project Leader                                       LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Tue, 02 Sep 1997 04:06:50 -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

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

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

Im not willing to wait several years; Im planning for a world of three standards:
X.509 id certs, X.509 attribute certs, and SPKI-certs acting as an openCapability.

X.509 att-certs and id-certs instances are currently  linked via the commonality
of name forms (whichever name-form is chosen.) and the correpondence of
a given value.

I would now like to link SPKI-certs and (X.509 id-certs and X.509 att-certs)
similarly.

This is not a proposal for SPKI-certs to change their format: rather
it is a proposal for there to be a standard linkage mechanism, basedon use of the SDSINameForm and
the role it plays in its namemanagement model.

I would like your consent to reference the SPK cert document's <name> form
definition, and an approval that this would make such an X.509 cert
conform to the ideas of SPKI local-naming and security concepts (when used in
consort with an SPKI-chain reduction).

 -----

Here is my example of a practical and useful intersection between the two
worlds, whicih are otherwise independently managed except for
mutual use of a name-form and values:-

bob, alice and freda are all subscribers to a single X.509 certification
domain, and its formal policy obligations on all.

skywalker is a portending SPKI verifier who receives an SPKI cert chain
vouching for the name "bob's alice's freda"

Skywalker, wishing to reduce the SPKI cert chain for classical
security controls , and during this process (below) wishing to optionally
obtain third-party control benefits,

(a) uses the X.509 id-certs from third-party (CA) to
establish that 'bob is bob' and is indeed bound to the CA policy. Similary for
alice, and freda.

(b) obtains a CA-issued cert for the reduced-name "skywalker's (bob's alice's freda)"
in order that skywalker can demonstrate the acceptance of the act
and consequences of auth-fields reduction to a third-party during dispute handling, and that
all four parties are indeed agreeing to be bound to the [disputed resolution elements
of the] policy, in the context of the reduced the auth field.

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

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

<HTML>
&nbsp;
<BR>&nbsp;
<BLOCKQUOTE TYPE=CITE>&nbsp;

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

<P>Needless to say, I think PKIX would benefit from eliminating all DN
fields
<BR>and even the definition of DN in the certificates to be proposed (X.509v4?).
<BR>That would be a good start towards unification of the efforts (which
will
<BR>probably happen at some point, many years from now, since we're both
<BR>pursuing the truth, not matter how much old baggage we are carrying).</BLOCKQUOTE>
Im not willing to wait several years; Im planning for a world of three
standards:
<BR>X.509 id certs, X.509 attribute certs, and SPKI-certs acting as an
openCapability.

<P>X.509 att-certs and id-certs instances are currently&nbsp; linked via
the commonality
<BR>of name forms (whichever name-form is chosen.) and the correpondence
of
<BR>a given value.

<P>I would now like to link SPKI-certs and (X.509 id-certs and X.509 att-certs)
<BR>similarly.

<P>This is not a proposal for SPKI-certs to change their format: rather
<BR>it is a proposal for there to be a standard linkage mechanism, basedon
use of the SDSINameForm and the role it plays in its namemanagement model.

<P>I would like your consent to reference the SPK cert document's &lt;name>
form
<BR>definition, and an approval that this would make such an X.509 cert
<BR>conform to the ideas of SPKI local-naming and security concepts (when
used in
<BR>consort with an SPKI-chain reduction).

<P>&nbsp;-----

<P>Here is my example of a practical and useful intersection between the
two
<BR>worlds, whicih are otherwise independently managed except for
<BR>mutual use of a name-form and values:-

<P>bob, alice and freda are all subscribers to a single X.509 certification
<BR>domain, and its formal policy obligations on all.

<P>skywalker is a portending SPKI verifier who receives an SPKI cert chain
<BR>vouching for the name "bob's alice's freda"

<P>Skywalker, wishing to reduce the SPKI cert chain for classical
<BR>security controls , and during this process (below) wishing to optionally
<BR>obtain third-party control benefits,

<P>(a) uses the X.509 id-certs from third-party (CA) to
<BR>establish that 'bob is bob' and <B>is indeed bound to the CA policy</B>.
Similary for
<BR>alice, and freda.

<P>(b) obtains a CA-issued cert for the reduced-name "skywalker's (bob's
alice's freda)"
<BR>in order that skywalker can demonstrate the acceptance of the act
<BR>and consequences of auth-fields reduction to a third-party during dispute
handling, and that
<BR>all four parties are <B>indeed agreeing to be bound to the [disputed
resolution elements</B>
<BR><B>of the] policy, in the context of the reduced the auth field.</B>
<BLOCKQUOTE TYPE=CITE>

<P>- Carl

<P>+------------------------------------------------------------------+
<BR>|Carl M. Ellison [email-masked] <A HREF="http://www.clark.net/pub/cme">http://www.clark.net/pub/cme</A>
|
<BR>|CyberCash, Inc. <A HREF="http://www.cybercash.com/">http://www.cybercash.com/</A>
|
<BR>|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
<BR>|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
<BR>+------------------------------------------------------------------+</BLOCKQUOTE>
&nbsp;</HTML>

--------------6114F3FF450611F566CA54A7--

Date: Tue, 2 Sep 1997 09:17:01 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX-1 key purpose

> From: Russ Housley <[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....

I'll have to agree with Peter on this one.  "Web objects" includes
more than just "code" or "object code" -- it's not just java applets but
also text and images and metadata and manifests -- anything that can be
conveyed in an html page.

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

Agree.

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

I think I agree.  My inclination is to reserve "non-repudiation" exclusively
for keys intended to be interpreted as legally binding upon the signer,
in which case most email signing keys should be regarded as "data origin
authentication", not NR.   But given that signed email is currently
designated as NR, certainly signed objects should be regarded as NR too.
There is at least as much deliberate user action involved in signing an
object, and at least as much intent to vouch for the content.

From: "Rich Ankney" <[email-masked]>
To: "Charles Moore" <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ipki3cmp-03.txt
Date: Mon, 1 Sep 1997 09:43:03 -0400

I would favor, in addition to this, the ability to add extensions to
existing
messages.  This could be in the form of extensions (similar to the X.509
v3 extensions) in the PKIHeader, or added to the PKIMessage, or
whatever.  This would allow the messages to carry (of particular interest
to some of us in ANSI X9) billing-related info, among other things.

Regards,
Rich
----------
> From: Charles Moore <[email-masked]>
> To: [email-masked]
> Subject: Comments on draft-ietf-pkix-ipki3cmp-03.txt
> Date: Sunday, August 31, 1997 7:17 PM
> 
> 
> 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
> 

Date: Mon, 1 Sep 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].