RE: Comments on [MANDATORY cert discovery capabiity]

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi Peter,

>----------
>From: 	Peter Williams[SMTP:peter@verisign.com]
>Sent: 	Tuesday, September 30, 1997 3:46 PM
>To: 	Carlisle Adams
>Cc: 	'ietf-pkix@tandem.com'
>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
cadams@entrust.com
--------------------------------------------