Michael Richardson writes: > I am not really following this discussion very well. > I'm not sure if this is general advice or ACP specific advince.
This discussion was not ACP specific, this was just generic reasons why CERTREQ etc are usuful in general. Anyways I think most ACP cases do not need CERTREQ, but on the other hand there might be cases where it is still useful there, and thats why I would hate to see profile that forbits its use. I.e., it is fine to say in profile, that CERTREQs might not be needed, but saying that they should/must not be sent is bad idea. > 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) If you have proper management, then you can do almost instanteneous changes, but CERTREQ allows you do do similar things even when you do not have any kind of management system configuring devices, with much longer overlaps in configuration. > 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. Sometimes the problem is that there are devices there which do not support ECDSA at all, which means you are stuck with RSA for both root and EE for all devices. With CERTREQ some parts of the network can start use full ECDSA TA and EE and still interoperate with those devices which support both and get the "coolness" factor of not using RSA at all :-) Other similar cases comes when you merge authorization domains together, i.e., two companies merge and they both had their own CAs before, and not all devices support both CAs, so you need to pick correct certificate one when talking to one or another device. > 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? The text I provided earlier was just general IPsec case, I have not checked out situation in this specific case, so I cannot comment on that before I read that document... > >> 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 :-( No, you are not forced to use anything. Your ID could be KEY_ID with just random 128-bit binary blob, and you could find your policy entry based on that. Then in the policy entry there might be information what should be present in the certificate, or even just hash of the raw public key (which could be also be sent inside the certificate in some cases). IDi and IDr are used to find the policy, policy information is used to verify that the authorization information provided are correct. That information usually includes trust anchors, and information what should be in the certificate signed by those trust anchors. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
