Re: Comments on [MANDATORY cert discovery capabiity]

[Peter Williams <peter@xxxxxxxxxxxx>]

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)