RE: Comments on [MANDATORY cert discovery capabiity]

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi Peter,

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