[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Latest ipsec-pki-req-04.txt
Hi,
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.
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.
So don't send cert-req in 6.
I agree that it only makes sense to send the certs in 5 or 6 to enforce
identity protection.
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. 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. IPSec client initiates IKE with gateway,
certificate repository is behind gateway and client does not have access to
it. IPSec client sends cert request, gets back chain, crl, and is happy.
Gateway sends cert request, client if conforming to section 6.3 would not
respond with its certificate instead with a NONE and negotiation fails. As
it would work today, client would send back as much of the chain as it can,
which in this case would only be its certificate. Gateway having access to
repository builds chain from clients CA to its CA and validates certificate.
Negotiation proceeds.
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. I don't see the need for this
restriction. I believe the subject can be modified by the CA in CMP
(rfc2510).
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.
Bye
Greg Carter
Entrust Technologies - http://www.entrust.com
http://www.ford-trucks.com/articles/buildup/dana60.html
Follow-Ups: