[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CERT_REQ_PAYLOAD usage
Brian Swander writes:
> Unless I'm missing something, it seems pretty hacky to send multiple end
> entity cert chains. Say my peer sends me 3 CRPs for different roots,
> root A,B,C. I have 3 cert chains that chain to these roots. Chain1:
> A0,A1,A Chain2: B0,B1,B2,B Chain3: C0,C1,C where A0, B0, and C0 are
> the end entity certs.
>
> Say I send all of these certs in random order (A0,B1,A1,B0,C0 etc).
> Now, the peer has to pick out the chains, and piece them back together.
Yes. So what? If you are using real certificate manager that takes
care of that that is not an issue. As the IKE is currently defined you
have to do that anyways.
> Worse yet, I also have to send 3 sig payloads since in general A0,B0 and
> C0 will all have different private keys. There is no way in IKE to map
No. If those certificates does not share the private key then you only
send ONE chain. If they all share private key then you can send
multiple chains. You SHOULD NOT send multiple certificates matching
your ID payload that have different private key. You MAY send multiple
certificates matching your ID payload if they have same private key.
> the chain to the sig payload, so IKE has to guess what the chains are,
> guess what the end entity certs are, and go with trial and error to find
> the correct sig payloads.
Or you could simple find out all certificates matching the ID payload
and try to verify the signature with all of them. This might also be
the case when you have overlapping validity periods while you get a
new certificate to replace old one.
The other end might already have your old certificate in its
certificate cache, and you are using the new certificate when you
create the SIG, thus the other end might end up checking the signature
with wrong public key.
> Thus, sending a single chain and a single sig payload seem to me to be
> the only reasonable alternative. Of course, if we mandated that people
> sent an individual chain as its own PKCS7 and that all end entity certs
> MUST have the basic constraint saying that they are end entity, and
> defined some way in IKE to map PKCS blobs to sig payloads (maybe with
> mandatory payload ordering), then perhaps we could build an
> interoperable way to send multiple chains. But as William points out,
> we'd still have the problem of fragmented IKE payloads.
What is the problem with fragmented IKE payloads? You have to be able
to process them anyways, as there might be some ppp lines that has MTU
of 128 bytes between you and the other end. If you don't know how to
handle fragmented IKE payloads then your implementation is broken and
it should be fixed.
--
kivinen@ssh.fi Work : +358 303 9870
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: