Tero Kivinen <kivi...@iki.fi> wrote:
Tero> Note, that initiator might not have any certificate from CA1 or CA2,
Tero> it might actually use completely different CAs, i.e., the list of
Tero> certificate authorities can be asymmetric.
Toerless> Good explanation. So, whats the most simple example for this ?
Toerless> I have a single VPN but multiple geographic headends and
Toerless> there is an obfuscated logic what certs each headends accepts,
Toerless> so i do have multiple and certreq helps me to choose ?
> I would assume most common case will be when certificates are being
> renewed in non-compatible way. I.e., you initially have rsa certs for
> both client and server, then someone decides rsa is weak, and we must
> move to ecdsa in the future. They will first install new TA certs on
> the some servers (lets say they have 1000 of those, and they do not
> want to do all of them immediately). Now some of the servers do have
> TA1, and some have both TA1, and TA2.
I am not really following this discussion very well.
I'm not sure if this is general advice or ACP specific advince.
In the case that you describe (RSA->ECDSA), I think that we would sign TA1
with TA2, or vice-versa. (probably one and then the other a month later).
We can feed/update the trust anchors when certificates are renewed, or we can
use draft-ietf-netconf-trust-anchors to change things (the advantages of
having really good security for in-band management)
I prefer relatively short expiries for certificates in the ACP because <STAR
reasons>.
I think that all systems have to support both RSA and ECDSA for a big
overlapping period. I don't think this is a problem.
I think that there is not a problem having a RSA key (TA1) sign an ECDSA EE
cert.
I know that I've done it, but I know that some think it uncool.
> Next clients needs to get new certificates from TA2. This process can
> m^Htake months, as it is possible that some of the clients are not
> connecting to the server for long time.
That's true in general, particularly for remote access situations, but ACP
nodes are mostly always reachable. If they get turned off and put in a box,
then when they return, they have a valid certificate, or they have to
bootstrap again, and that's okay.
> If you have client which has only TA1, there is no problem, it can
> connect to any server which still supports TA1. If you have client
> which has both TA1, and TA2, and it connects to old server which only
> supports TA1, it needs to recognize this and use TA1 in that case. If
> it connects to server using both TA1, and TA2, it most likely wants to
> prefer TA2, as that is the direction the transition is going, so TA2
> should be preferred if both are supported.
> When all servers have been updated to support both TA1, and TA2, then
> there is no longer issues, as now all clients which do have TA2, use
> it for all servers, and those which have not yet updated to TA1, still
> use that.
You are imagining a period of time where we are installing the trust anchors,
and I don't see it has to be like that.
Have TA1 sign TA2 as a sub-CA, and then pass out TA1->TA2->EE(ecdsa) chain to
the
new nodes. Once this is done for all nodes, you can drop TA1.
In reality, there are probably at least an extra level of CA, possibly two.
Do you think that I should include this situation into
draft-richardson-registrar-operational-considerations?
> So the idea is to allow iterative updating of the system, without the
> need of flag days or configuration settings to specify things. I.e.,
> IKEv2 will automatically detect which TA is supposed to be used, and
> use it.
Agreed.
>> The full name of a node was so far an rfc822Name, now i need to
>> fix it to become what i think is going to be a GeneralName,
>> and hence it might best be to signal IDi/IDr as ID_DER_ASN1_GN
> Note, that the IDi and IDr are what is matched against the IPsec
> policy, i.e., nothing in the certificate will cause policy to be
> selected, only IDi and IDr does that. After IDi and IDr identifies the
> suitable policy, we can go and match the information in the policy
> against the certificate. That policy might include information like
> how to match the certificate subject alt name or subject name to
> identity or information in the policy.
So, we've been forced to use otherName, and this will cause new code in some
of the IKEv2 daemon that we need to use :-(
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
