RE: Comments on [MANDATORY cert discovery capabiity]

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

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:peter@verisign.com]
>Sent: 	Monday, September 22, 1997 3:49 PM
>To: 	Carlisle Adams
>Cc: 	ietf-pkix@tandem.com
>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
cadams@entrust.com
--------------------------------------------