[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Latest ipsec-pki-req-04.txt
At 02:15 PM 12/15/99 -0500, Greg Carter wrote:
>3.1 The extendedKeyUsage field
>
>Maybe I missed it, but did anybody respond why the extendedKeyUsage MUST
>contain only the
>object identifier iKEIntermediate?
>
>This now means all ipsec entities require a special ipsec cert.
This was discussed at DC with no consensus and small numbers of people
arguing vocally in different directions. It would be good to get clarity on
this topic soon.
Should any old cert be useful for IKE identification? If not, is there
something between "any" and "IKE only" that makes sense?
>6.1 Signature-based authentication
>Main Mode - Certificate Request
>I would much prefer that we specify only which parts of the exchange where
>it does not make sense to send these payloads rather than trying to restrict
>where they are sent. To me it makes perfect sense to send a cert request in
>2(responder), 3(initiator), 4(responder) or 5(initiator). Since after the
>SA is agree you will know if you want a cert.
But doing so in messages 2, 3, and 4 are not described in the message
formats in the IKE document. The ISAKMP document says it's OK to put them
there (and in step 1, for that matter), but IKE only has slots for them in
5 and 6. What you're proposing is that we change IKE. I think that's fine,
but we have to do it somewhere other than the PKI document.
>6.3 Content of Certificate payloads
>"If a responding device is not offering a certificate that will chain to
>the certificate authority named in the Certificate Request payload, the
>Certificate payload offered in response to a Certificate Request
>payload MUST specify a certificate encoding of type NONE."
>
>This is completely new behavior. And not very flexible.
Disagree. Agree.
> I'll give an
>example. IPSec Client is attempting to setup IKE with a Gateway. The
>client and gateway do not share the same CA, however the CA's are cross
>certified and a chain from one to the other can be made but requires access
>to a certificate repository.
What you're asking for is that both sides, when given a certificate request
for a root that they do not know, should guess and send a bunch of certs
that weren't requested. There is no way for the responder to the request to
know whether the request might have cross-certs with any of its roots, or
any of its intermediate certs, for that matter. I propose that this is a
bad solution that will cause IKE to fail more often due to much longer
responses.
Your problem is real, but it is not common (one might say "extremely rare
except for Entrust customers"). I think what is proposed here is OK
*except* for the case of cross-certification, and that if we want to deal
with that problem, we need a solution specific to cross-certs.
>A. Obtaining a Certificate for a Device
>"Regardless of the protocol used, a CA who gets an IKE system's
>enrollment request that includes the subject and subjectAltName desired
>for the device MUST include exactly the same subject and subjectAltName
>in the certificate."
>
>As I have said before this will require that a user type in the DN at some
>console somewhere and get it right.
Maybe not true 100% of the time, but certainly often enough to make
fat-fingering errors common.
> I don't see the need for this
>restriction. I believe the subject can be modified by the CA in CMP
>(rfc2510).
I'll defer to Rodney to defend this requirement. What do other folks say?
>A.1 Enrollment requests with PKCS10 plus out of band information
>
>I am glad this has been spelt out, however it should be mentioned here or in
>the security considerations section that a hash (fingerprint) of the ASN.1
>DER encoded p10 message be done and made available to the operator for
>verification with the CA.
This seems to me to be an operational issue, not a protocol issue.
--Paul Hoffman, Director
--VPN Consortium
Follow-Ups:
References: