[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on [MANDATORY cert discovery capabiity]
Hi Peter,
[Russ, there's a question for you below.]
>----------
>From: Peter Williams[SMTP:peter@verisign.com]
>Sent: Tuesday, September 30, 1997 8:05 PM
>To: Carlisle Adams
>Cc: 'ietf-pkix@tandem.com'
>Subject: Re: Comments on [MANDATORY cert discovery capabiity]
>
>Carlisle,
>
>OK. I am going away from this exchange with two beliefs:
>
>(a) no Appendix B message (set) specified needs to be necessarily
>sent, or handled if received; there is no state or sequence of messages
>(sets) implied
>to be conforming. PKIInformation need not even be sent, and can
>be ignored in any case by an EE.
This is correct. The model is that *if* you want to achieve a
particular function using a PKIMessage, Appendix B specifies the message
to use, including the particular fields and their semantics. It is not
essential that you use a PKIMessage to achieve any function (though
using other methods is likely to hurt interoperability).
Having said that, however, I think normal procedure will be that if a
request message is sent, the protocol engine will expect a response
message (or error), and will then reply with a confirm message. In
other words, I suspect most implementations will have "state" within a
message set. "State" *between* different message sets is not implied by
Appendix B.
>(b) If an EE implementation wants to ignore PKIInfo, it they can; if they
>want to ignore InitReq they can. They can deem information and
>initialization to have occured by other means, and go straight to cr
>whose protection mechanism may use signing (MSG_SIG_ALG ).
Again correct. Note, however, that even if initialization has occurred
by other means, the resulting certificate must be verifiable by the CA
that is being sent the "cr" message (otherwise it won't be able to
verify the signature protection on the request).
Furthermore, we need to be a bit cautious about doing initialization "by
other means". This is, of course, allowed, but keep in mind that
getting EEs securely initialized into the PKI is one of the most
important steps in creating a PKI that can be trusted and used. The
"basic authenticated scheme" in PKIX-CMP provides a solid, implementable
method for doing this properly. Many other proposals (and current
practices) that I've seen are not quite as careful. I'm not so
enthusiastic about EEs getting initialized elsewhere and then using
PKIX-CMP for subsequent certificate management functions...
>--------
>
>On other matters, you may want to clean up fast:-
>
>the oids for:-
>
> - Example InfoTypeAndValue contents include, but are not limited to:
> -- { CAProtEncCert = { xx }, Certificate }
> -- { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier }
> -- { EncKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier }
> -- { PreferredSymmAlg = { xx }, AlgorithmIdentifier }
> -- { CAKeyUpdateInfo = { xx }, CAKeyUpdAnnContent }
> -- { CurrentCRL = { xx }, CertificateList
Probably the fastest way to get numbers reserved here is to assign these
under the "id-pkix" arc. I see (from the most recent Part 1 draft) that
this is defined to be:
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) }
and that under this, the values 1, 2, 3, and 48 have already been
assigned. I hereby propose that we reserve
{ id-pkix 4 } for "id-pkix-cmp-infoType" and, under this, reserve the
values 1 through 6 for the examples given above (in the order given).
Are there any objections to this (specifically, has { id-pkix 4 } been
assigned already for something I didn't notice)? I see that IANA has
Russ Housley's name beside "id-pkix". Russ, does this mean that I can
simply ask you to reserve these numbers, or do I have to go through IANA
anyway (from what I understand, I think the former is the case)?
>and
>
>
> SinglePubInfo ::= SEQUENCE { pubMethod INTEGER {
> dontCare (0), x500 (1), web
> (2)
>
>shoud include ldap
I'm not sure what you mean here. LDAP is not a publication method; it's
a protocol. All we really had in mind with this was "publish in an
X.500 directory", or "publish on a web page", etc., with the "location"
field giving more specific information, if desired. Maybe the name
"pubMethod" is not clear enough -- suggestions?
> B1. General Rules for interpretation of these profiles.
> 1.Where OPTIONAL or DEFAULT fields are not mentioned in individual
> profiles, they should be absent from the relevant message.
> Mandatory fields are not mentioned if they have an obvious value
> (e.g., pvno).
>
>State whether a receiver doing type checking has reasonable basis for
>rejecting
>an inbound msg which has a present, not-mentioned-by-profile OPTIONAL or
>DEFAULT
>field.
Yes, a receiver that implements only the PKIX-CMP mandatory stuff should
not expect any such field and may freely reject such an inbound message
as syntactically incorrect. A receiver that goes beyond the mandatory
might be able to syntactically parse the message properly, but may or
may not actually understand (i.e., support) these fields; hence, it too
may reject such an inbound message or it may return a more satisfying
(to the sender!) response (depending on how far beyond the mandatory it
has implemented).
I will try to clarify this point.
>You may want to revisit, and ensure its generically compatible with the
>actual
>profiles for the various operations.
>
> 9.All PKI message exchanges in this profile require a PKIConfirm
> message to be sent by the initiating entity. This message is not
> included in many of the profiles given below since its body is
> NULL and its header contents are clear from the context. Any
> authenticated means can be used for the protectionAlg (e.g.,
> password-based MAC, if shared secret information is known, or
> signature).
I see what you mean. I will check this and fix up where necessary.
>Thats all I have. I can say that only with these recent dialogues do I,
>for one, mostly understand the subtleties. Hopefully lots
>of implementors now intepret things similarly, and multi-vendor
>interworking will actually happen!
I hope so too!
--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------