[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on [MANDATORY cert discovery capabiity]
<html><HTML>
Carlisle,:
<BR>Carlisle,
<BR>
<P>OK. I am going away from this exchange with two beliefs:
<P>(a) no Appendix B message (set) specified needs to be necessarily
<BR>sent, or handled if received; there is no state or sequence of messages
(sets) implied
<BR>to be conforming. PKIInformation need not even be sent, and can
<BR>be ignored in any case by an EE.
<P>(b) If an EE implementation wants to ignore PKIInfo, it they can;
if they
<BR>want to ignore InitReq they can. They can deem information and
<BR>initialization to have occured by other means, and go straight to cr
<BR>whose protection mechanism may use signing (MSG_SIG_ALG ).
<P>Just set me right if they are wrong.
<P>--------
<P>On other matters, you may want to clean up fast:-
<BR>
<UL><<Later versions of this document may extend the above to include
<BR>profiles for the operations listed below (along with other operations,
<BR>if desired).>></UL>
<P>the oids for:-
<BR>
<UL>- Example InfoTypeAndValue contents include, but are not limited to:
<BR> -- { CAProtEncCert = { xx }, Certificate
}
<BR> -- { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier
}
<BR> -- { EncKeyPairTypes = { xx }, SEQUENCE OF
AlgorithmIdentifier }
<BR> -- { PreferredSymmAlg = { xx }, AlgorithmIdentifier
}
<BR> -- { CAKeyUpdateInfo = { xx }, CAKeyUpdAnnContent
}</UL>
-- { CurrentCRL
= { xx }, CertificateList
<P>and
<BR>
<UL>SinglePubInfo ::= SEQUENCE { pubMethod
INTEGER {
<BR> dontCare
(0), x500
(1), web
(2)</UL>
<P>shoud include ldap
<BR>
<UL>B1. General Rules for interpretation of these profiles.
<BR> 1.Where OPTIONAL or DEFAULT fields are not mentioned in individual
<BR> profiles, they should be absent from the relevant message.
<BR> Mandatory fields are not mentioned if they have an obvious
value
<BR> (e.g., pvno).
<BR> </UL>
State whether a receiver doing type checking has reasonable basis
for rejecting
<BR>an inbound msg which has a present, not-mentioned-by-profile OPTIONAL
or DEFAULT
<BR>field.
<BR>
<P>You may want to revisit, and ensure its generically compatible with
the actual
<BR>profiles for the various operations.
<UL>
<P> 9.All PKI message exchanges in this profile require a PKIConfirm
<BR> message to be sent by the initiating entity. This
message is not
<BR> included in many of the profiles given below since its
body is
<BR> NULL and its header contents are clear from the context.
Any
<BR> authenticated means can be used for the protectionAlg
(e.g.,
<BR> password-based MAC, if shared secret information is known,
or signature).
<BR>
<BR> </UL>
Thats all I have. I can say that only with these recent dialogues do I,
<BR>for one, mostly understand the subtleties. Hopefully lots
<BR>of implementors now intepret things similarly, and multi-vendor
<BR>interworking will actually happen!
<P>Peter.
<BR>
<BR>
<BR>
<BR>
<UL>
<P>Hi Peter,
<P>>----------
<BR>>From: Peter Williams[SMTP:peter@verisign.com]
<BR>>Sent: Tuesday, September 30, 1997 3:46 PM
<BR>>To: Carlisle Adams
<BR>>Cc: 'ietf-pkix@tandem.com'
<BR>>Subject: Re: Comments on [MANDATORY
cert discovery capabiity]
<BR>>
<BR>>Carlisle Adams wrote:
<BR>>
<BR>>> But, to answer your question, the CA must respond with an
error message
<BR>>> (a response that should be expected by any EE that goes outside
the
<BR>>> mandatory spec.). This does not hamper the EE's abilities
or future
<BR>>> actions in any way, because it can always send another request with
an
<BR>>> empty SET (to get whatever the CA does know), or get the required
<BR>>> information in any other fashion (recall that PKIMessages do not
need to
<BR>>> be used for this information exchange), or decide that it really
didn't
<BR>>> need this particular information after all and simply send an InitReq
<BR>>> message.
<BR>>
<BR>>Should we mandate that an EE be required to send a PKIInformation
"with
<BR>an empty set of requirements" msg if it gets an error msg to its
<BR>>previous attempt
<BR>>to synchronise PKI information before entering the initialization
or
<BR>>certification states wheree real work gets done?
<P>I'm not sure why this would need to be mandated...
<P>>Im imagining in a Microsoft implementation of this PKIInformation exchange
<BR>>in which the activeX enrollment control, which implements the
<BR>>more elaborate B.x profiles using RSA, would be supplied to the EE
in
<BR>>response to
<BR>>PKInformation object {ms 1}. Where the CA is not a activeX
<BR>>CA (i.e. it sends an error msg), then that same browser needs to fall
<BR>>back to non-activeX mechanisms by syncing on initialization information
they
<BR>>can agree on (i.e. that which the CA optionally provides) and using
a
<BR>>barebones PKIX-3 minimal, default implementation with DSA cipherSuites,
say.
<P>I would assume that falling back to guaranteed interoperable messages
<BR>would be normal behavior for any well-designed protocol engine.
<BR>Bringing up my previous analogy again, if one side can't communicate
<BR>with the other using 3-DES / RC5 / IDEA / CAST-128, it should fall
back
<BR>to DES because it knows this will work. Do we need to mandate
such
<BR>common-sense behavior? I don't think so -- as I said,
the EE may
<BR>decide to do the information exchange in some out-of-band way or may
<BR>decide it doesn't really need the information. Also, protocol
<BR>implementors seem pretty familiar with this style of protocol (where
<BR>certain messages, options, algorithms, etc., are mandated so that
<BR>interoperability can be guaranteed), so it seems unnecessary to mandate
<BR>this particular flowchart ("try this; if it doesn't work, go with
<BR>that").
<P>Your example is interesting, but I'm a bit surprised by your conclusion.
<BR> I thought you were keen to mandate fewer things rather than more...
?
<P>--------------------------------------------
<BR>Carlisle Adams
<BR>Entrust Technologies
<BR>cadams@entrust.com
<BR>--------------------------------------------</UL>
</HTML>
</html>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 15 (TEXT/R*ch) (0001C140)