Thanks. I think ACP has no specific encoding preference for the exchanged certificates, but we do of course MUST support BRSKI enrolled certificate (chains), and i think PKS#7 is MTI there (Michael ?).
Can PKS#7 certificate chains be converted locally into any potential other possible IKEv2 supported encoding format ? Then i think ACP is open to pick any encoding you could suggest to us. Othewise PKCS#7 is the safe ACP requirement. More inline. On Thu, Feb 27, 2020 at 11:58:53AM +0300, Valery Smyslov wrote: > Hi Paul, > > > > 1. The > > > Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be > > > supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter > > > names used in this text. > > > > > > ???PKCS #7 wrapped X.509 certificate??? certificate encoding is > > > deprecated and is not used in IKEv2 > > > (see > > > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters- > > 11). > > > Generally, I see no need for the text that imposes requirements on > > > certificate encoding at all ??? > > > we never run into the interoperability problems with this? as far as > > > I remember. I suggest to remove > > > this text. > > > > Actually we do. We had to add pkcs7 to ikev2 to be compatible with some > > windows deployments when intermediate certificates were being sent. On > > top of that, Microsoft did it wrong, as the format does not allow a > > chain but they added more than one anyway. So if anything, we DO NOT > > want to see more pkcs7 in IKEv2. > > We do support PKCS#7 too, but officially it's not specified for IKEv2 and > thus must not be specified in the profile. Ok. Great. I read this as you think this requirement is necessary to ensure peers can interoperate in exchaning their cert chains during IKEv2. > > > 2. If certificate chains are used, all intermediate certificates up to, > > > and including the locally provisioned trust anchor certificate MUST > > > be signaled. See Section 6.10.7 for the sub-CA example in which > > > certificate chains are used. > > > > > > This is confusing. I read this text as the ???MUST??? is imposed only > > > if > > > ???certificate chains are used???. Does it mean that implementations > > > may skip this ???MUST??? if EE certificate is directly signed by CA > > > certificate > > > and there is no intermediate certificates? Or is it still a chain > > > and ???if??? is relevant to the case when there is no CA and there is > > > a direct trust to EE certificates > > > (in which case PKI is not needed at all and you can use RAW public > > > keys)? > > > > I agree it should not try to dictate how certificate based IKE > > certification works, but just reference to IKEv2 and its updates for > > that. > > That was my point :-) There are two things here: -> Originally i wrote the text without need to include TA in the signaled cert chain. Reason: I worked with IPsc implementations that did not signal/verify cert chains, and i also think to remember that i discussed and was told that the specs do not mandate this, so that behavor was a valid option. If you can confirm, that compliance with IKEv2 MANDATES the need to signal cert chain (eg: through MUST in one of the MANDATORY normative PKI references), then i could remove the text if we wanted just to have "standard behavior". -> Michael wanted the additional signaling of the TA for diagnostic purposes. When this was added, the original text was not correctly adjusted, so now it sounds as if this all only applies IF there is more than the node cert and a root (no intermediate CA). That of course is wrong. We would always want to signal the cert chain including TA (remove "if..." condition). > > > Another point: trust anchors certificates usually are not included > > > in CERT payload in IKEv2. > > > I see draft???s a reasoning that this inclusion would allow better > > > network debugging, > > > but I???m not sure I can buy this argument. Probably more detailed > > > explanation is needed. > > > > They could suggest that for easier debuggint a CERTREQ payload is > > included. That has the hash of the CA, which should be good enough. > > But again, IKEv2 already specifies this. Why is this document trying > > to change IKEv2 certificate processing? > > Agree. It seems to me as if standard cert processing is primarily concerned with the minimum mandatory signaling for security. Maybe there is even the thinking that its a possible security feature that if you don't know the TA hash, you can not learn the TA cert. In the case of ACP, we do not care about such possible strange TA cert hiding security feature. An ACP can potentially have a bunch of TAs, for example under mergers & aquisitions. And especially if BRSKI is not used, these may be provisioned by all type of flawed mechanisms, like broken SDN controllers. Or incorrectly refreshed. Just think of the simple local diagnostics when a peer fails to connect and it for example has the correct TA, but unfortunately an expired cert for it. TA cert hash mismatch, but easily diagnosed when the TA cert iss signaled. Without having to go to a possible non-existant archive of prior TE certs from a company just aquired 9 months ago, where ACPs where merged. > > > 3. IKEv2 authentication MUST use authentication method 14 ("Digital > > > Signature") for ACP certificates; this authentication method can be > > > used with both RSA and ECDSA certificates, as indicated by a PKIX- > > > style OID. > > > > > > I think it???s better to rephrase this more accurately: ???indicated > > > by an ASN.1 object > > > AlgorithmIdentifier??? > > > > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo > > (SPKI) ASN.1 object" ? > > No, as far as I understand the text, it tells that the particular > signing algorithm is indicated in the AUTH payload by inclusion its OID. > That's partially true, it is indicated by inclusion AlgorithmIdentifier ASN.1 > object > (and not SubjectPublicKeyInfo or pure OID). > > It's probably better to just delete the text in the last sentence "as > indicated by a PKIX-style OID". ;-) Going once, going twice ? ... If not, i'll follow this advice Thanks! Toerless > Regards, > Valery. > > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
