IETF Logo Mail Archive

RE: Certificate Requesting

Greg Carter <greg.carter@entrust.com> Sat, 07 March 1998 04:03 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA08887 for ipsec-outgoing; Fri, 6 Mar 1998 23:03:22 -0500 (EST)
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=APOLLO-980307041353Z-9461@mail.entrust.com>
From: Greg Carter <greg.carter@entrust.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: Certificate Requesting
Date: Fri, 06 Mar 1998 23:13:53 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Sounds good to me.
----
Greg Carter, Entrust Technologies
greg.carter@entrust.com

>----------
>From: 	Theodore Y. Ts'o[SMTP:tytso@MIT.EDU]
>Sent: 	Thursday, March 05, 1998 2:07 PM
>To: 	wdm@epoch.ncsc.mil; ipsec@tis.com
>Subject: 	Re: Certificate Requesting
>
>
>Accordingly, Dan was going to modify the IKE spec to remove this point
>of ambiguity by stating that within the IKE DOI, implementations are not
>allowed to send a CERTREQ if doing so would extend the number of
>messages beyond the six specified by the IKE.  If either side doesn't
>have a certificate, they can send a notify message and abort the
>exchange.  
>
>If we assume this strategy, the only thing we are missing is to have the
>ISAKMP spec define a notify message which is "MISSING CERTIFICATE",
>with the data field having the same information as is contained in the
>CERTREQ message.  Notify messages are optional to implement, so
>implementations wouldn't have to do this; however, smart implementations
>would be able note this information and then send the appropriate
>certificate when they retry the IKE negotiation.  Doug, is this
>something you can add to the ISAKMP draft?
>
>

v2.46.0 | Report a Bug | By Email | System Status