Pasi Eronen and Valtteri Niemi write: The certificate transport is relatively straight-forward, but the description of certificate chains could benefit from some clarifications and examples showing at least one valid certificate chain. Also, if certificates are used for both RD and non-CGA ND, any differences should be described (e.g., in the ND case, would a PKC chain ending in an iPAddress subjectAltName be sufficient, or do we also need the AC?) Especially the selection of Attribute Authorities (valid AC issuers) seems a bit strange. The "trusted root" refers to valid PKC issuers, right? And then all CAs (PKC issuers) in the PKC path (from the trust anchor to the router's PKC) are also considered AAs. Unfortunately, RFC 3281 (section 4.5) explicitly forbids this! If this is done anyway, it should be at least well explained and justified. Another aspect that requires clarification is the requirements placed on the PKC chain. At the minimum, the spec should say what requirements are placed on subjectName, subjectAltName, and keyUsage. Preferably the spec should also give some recommendations for interoperability (see draft-ietf-ipsec-pki-profile-02 for example). Also, when specifying this, the SEND spec should probably refer to the PKIX profile (RFC 3280) rather than X.509 itself. Several other points related to this section: o Section 6.3 (editorial): In PKIX-speak, the correct term would probably be "trust anchor", not "trusted root". o Sections 6.3 and 6.6 (technical): Presumably, the "trusted root" should contain the issuer of the first certificate in the chain? But for X.509 certs, that's a Distinguished Name, not FQDN. So, should the "trusted root" option contain a DER-encoded Issuer DN instead of FQDN? Using AltSubjectName (correct spelling is subjectAltName, BTW) seems to make it more difficult for the router to decide which certificate to send, since its own certificate doesn't necessarily have the CA's dNSName (though it may be included in issuerAltName extension). o Section 6.5.1: The definition of the Holder field is a bit vague, and goes against the recommendations of RFC3281 (if this is intentional, at least the reasons for doing so should be documented). Our interpretation is that RFC3281, in this particular scenario would strongly recommend using the baseCertificateID syntax (instead of entityName or objectDigestInfo). Also, even if entityName or objectDigestInfo is used, RFC3281 recommends using only one of them, and recommends using only one entityName (not multiple), and says that if entityName is used, it MUST match the PKC certificate. o Section 6.5.1: If objectDigestInfo is used with digestedObjectType=publicKey, RFC3281 already specifies how objectDigest field must be calculated (section 7.3). o Section 6.5.1: Normative reference to an expired Internet-Draft (for the AuthorizedSubnetPrefix) probably isn't a good idea. Since it seems that the pkix-x509-ipaddr-as-extn draft is dead, either the relevant definitions should be copied here, or documented in a new, separate internet draft. --------------- Jari Arkko responds: > The certificate transport is relatively straight-forward, but the > description of certificate chains could benefit from some > clarifications and examples showing at least one valid certificate > chain. Also, if certificates are used for both RD and non-CGA ND, any Ok. > differences should be described (e.g., in the ND case, would a PKC > chain ending in an iPAddress subjectAltName be sufficient, or do we > also need the AC?) I don't know. Perhaps Pekka and James could say something about this. > Especially the selection of Attribute Authorities (valid AC issuers) > seems a bit strange. The "trusted root" refers to valid PKC issuers, > right? And then all CAs (PKC issuers) in the PKC path (from the trust > anchor to the router's PKC) are also considered AAs. Unfortunately, > RFC 3281 (section 4.5) explicitly forbids this! If this is done > anyway, it should be at least well explained and justified. Right. I think Pekka who wrote this part of the text is aware of this problem, and its being discussed. > Another aspect that requires clarification is the requirements placed > on the PKC chain. At the minimum, the spec should say what > requirements are placed on subjectName, subjectAltName, and > keyUsage. Preferably the spec should also give some recommendations > for interoperability (see draft-ietf-ipsec-pki-profile-02 for > example). Also, when specifying this, the SEND spec should probably > refer to the PKIX profile (RFC 3280) rather than X.509 itself. I agree. > Several other points related to this section: > > o Section 6.3 (editorial): In PKIX-speak, the correct > term would probably be "trust anchor", not "trusted root". Yes. > o Sections 6.3 and 6.6 (technical): Presumably, the "trusted root" > should contain the issuer of the first certificate in the chain? > But for X.509 certs, that's a Distinguished Name, not FQDN. So, > should the "trusted root" option contain a DER-encoded Issuer DN > instead of FQDN? > > Using AltSubjectName (correct spelling is subjectAltName, BTW) > seems to make it more difficult for the router to decide which > certificate to send, since its own certificate doesn't necessarily > have the CA's dNSName (though it may be included in issuerAltName > extension). Ah yes. Hmm... I guess we just wanted to stay away from DNs altogether. But maybe that is not possible. Pekka? > o Section 6.5.1: The definition of the Holder field is a bit vague, > and goes against the recommendations of RFC3281 (if this is > intentional, at least the reasons for doing so should be > documented). Our interpretation is that RFC3281, in this particular > scenario would strongly recommend using the baseCertificateID > syntax (instead of entityName or objectDigestInfo). > > Also, even if entityName or objectDigestInfo is used, RFC3281 > recommends using only one of them, and recommends using only one > entityName (not multiple), and says that if entityName is used, it > MUST match the PKC certificate. > > o Section 6.5.1: If objectDigestInfo is used with > digestedObjectType=publicKey, RFC3281 already specifies how > objectDigest field must be calculated (section 7.3). > > o Section 6.5.1: Normative reference to an expired Internet-Draft > (for the AuthorizedSubnetPrefix) probably isn't a good idea. Since > it seems that the pkix-x509-ipaddr-as-extn draft is dead, either > the relevant definitions should be copied here, or documented in a > new, separate internet draft. Agreed. I believe some off-list discussions were going around on this subject, with the PKIX folks. > o Section 7.2 (technical) > > This section actually proposes quite a radical change to IPsec > processing! The destination-agnostic SAs are indeed covered by > the (uncontroversial) changes in ESPv3/AHv3. However, selecting > an inbound SA based on ICMPv6 type code is not. But wait. The inbound SA is selected purely by the SPI. After decryption it is matched with the SA's selectors. There's nothing controversial about this part. The only question is if SPDs/selectors can use ICMPv6 type codes. Based on recent discussion in IPsec WG, this will likely happen. > The SPD selectors indeed contain a field for port number where this > could be stored. However, in normal IPsec processing, the SPD is > checked only after the packet has been authenticated -- so it can't > be used to select an SA for inbound packets (the example policy > entries in Sections 8.4 and 9.5 also assume that SPD is consulted > before selecting SA). But using the ICMPv6 type for selecting > inbound SA would also be some sort of protocol layering > violation.... > > Fixing this might be possible rather easily. One > possible way to refactor this would be the following: > > - Always create exactly two special inbound SAs (with two > different special SPIs), one for plain AH_RSA_Sig and other > one for AH_RSA_Sig+CGA verification (hosts which don't support > CGA can treat these two identically; sender can select which > to use). This should remove the need to have a separate > CGA flag. > - Move most of the fields from the inbound SAs to inbound > SPD entries (except CGA flag). Ah yes now I see what you are getting at. Yes, separate SPIs appear to be needed. --------------- IETF-57 minutes: Comments from review board - problems using attribute certificates. RFC3281 is a fairly New spec, not a lot of infrastructure in place as with PKC certs. A disadvantage of using PKC certs is that we need a new extension. We would have certificate chain mirroring prefix delegation. Unfortunately, attribute certificate chains not permitted by RFC 3281. However, there seems to be some interest for doing this in BGP or SBGP. Distinguished Names to identify trusted roots. Michael: New code is needed, period. Every single thing requires new code in their CAs. ASN.1 is not that extensible in the real life, as you know if you have written any code. "There is no infrastructure" is a red herring. Reality is that someone is going to write code. Let's write code that the X.509 people have suggested, authorization certs. DNs are not useful. Let's use FQDNs, because we should tell them what to do. Pekka: No opinion about DN vs FQDN, but regarding certs, strongly agree with Michael that we should go with authorization certificates. Use object hash as an issuer (i.e. PK instead of name). Simple change, already there in RFC3281 ASN.1 specification, just need to remove 2 lines from the RFC (the statement that using an object hash as an issuer explicitly forbidden). Russ Housley: I put those lines there; so far I haven't heard a reasonable justification for removing them. I agree with attribute certs, but not convinced that constructing hierarchy is the answer. What structure are you trying to create? What are you trying to find tha attribute certificate to? PK and things you're binding to PK have different lifetimes. So, extension to PKC certs is not good; use attribute certificates. Pekka: Scheme we would like to support is chain of ISPs, with higher-level and lower level ISPs, or even users running their own routers. Chain of attribute certificates based on prefix, sub-prefixes can be delegated down the chain. Name of ISPs doesn't matter to the party doing the verification, just that there's a secure chain of PKs, and that the prefixes properly nest so that the router is authorized to advertise the prefix. Russ: We'll have to talk later. James: Let's take it to the list and talk about it more. I'll generate proposal for options with Jari. No one wants to use PKCs. Anyone support getting rid of attribute certs and going to PKCs? (no). We'll talk about attribute certificates later. --------------- James Kempf: Issue 8 concerns feedback from review board members Pasi and Valtteri, and it contains a variety of subissues. Considering we've decided to go with draft-ietf-pkix-x509-as-extn-01.txt instead of attribute certificates, some of the subissues have been superceded. I list the subissues below together with suggested resolutions. Please send comments and preferences if you have any. If you want to have deeper discussion on a particular subissue, please start a separate thread with the subissue number in the title. Issue 8a: "The certificate transport is relatively straight-forward, but the description of certificate chains could benefit from some clarifications and examples showing at least one valid certificate chain." Suggested resolution: Since jak has been primarily been handling certificates, he will try to come up with an example. Issue 8b: "Also, if certificates are used for both RD and non-CGA ND, any differences should be described (e.g., in the ND case, would a PKC chain ending in an iPAddress subjectAltName be sufficient, or do we also need the AC?)" Suggested resolution: 1) The example doesn't apply, since PKCs with the IP prefix and address range extensions as per draft-ietf-pkix-x509-as-extn will be used. 2) At the Vienna meeting, the WG decided to move non-CGA ND out of the base spec, since there are no longer any IPR considerations for CGA, so the issue doesn't apply to the base spec. Issue 8c: "Especially the selection of Attribute Authorities (valid AC issuers) seems a bit strange. The "trusted root" refers to valid PKC issuers, right? And then all CAs (PKC issuers) in the PKC path (from the trust anchor to the router's PKC) are also considered AAs. Unfortunately, RFC 3281 (section 4.5) explicitly forbids this! If this is done anyway, it should be at least well explained and justified. Another aspect that requires clarification is the requirements placed on the PKC chain. At the minimum, the spec should say what requirements are placed on subjectName, subjectAltName, and keyUsage. Preferably the spec should also give some recommendations for interoperability (see draft-ietf-ipsec-pki-profile-02 for example). Also, when specifying this, the SEND spec should probably refer to the PKIX profile (RFC 3280) rather than X.509 itself." Suggested resolution: Superceded by using draft-ietf-pkix-x509-as-extn. Issue 8d: "o Section 6.3 (editorial): In PKIX-speak, the correct term would probably be 'trust anchor', not 'trusted root'." Suggested resolution: Jari has said in an initial followup email that he will make the change. Issue 8e: "o Sections 6.3 and 6.6 (technical): Presumably, the 'trusted root' should contain the issuer of the first certificate in the chain But for X.509 certs, that's a Distinguished Name, not FQDN. So should the "trusted root" option contain a DER-encoded Issuer DN instead of FQDN? Using AltSubjectName (correct spelling is subjectAltName, BTW) seems to make it more difficult for the router to decide which certificate to send, since its own certificate doesn't necessarily have the CA's dNSName (though it may be included in issuerAltName extension). o Section 6.5.1: The definition of the Holder field is a bit vague, and goes against the recommendations of RFC3281 (if this intentional, at least the reasons for doing so should be documented). Our interpretation is that RFC3281, in this particular scenario would strongly recommend using the baseCertificateID syntax (instead of entityName or objectDigestInfo). Also, even if entityName or objectDigestInfo is used, RFC3281 recommends using only one of them, and recommends using only one entityName (not multiple), and says that if entityName is used, it MUST match the PKC certificate. o Section 6.5.1: If objectDigestInfo is used with digestedObjectType=publicKey, RFC3281 already specifies how objectDigest field must be calculated (section 7.3)." Suggested resolution: These issues are superceded by use of draft-ietf-pkix-x509-as-extn. Issue 8f: "o Section 6.5.1: Normative reference to an expired Internet-Draft (for the AuthorizedSubnetPrefix) probably isn't a good idea. Since it seems that the pkix-x509-ipaddr-as-extn draft is dead, either the relevant definitions should be copied here, or documented in a new, separate internet draft." Suggested resolution: The draft is not dead, it just passed through WG Last Call in the PKIX WG, and will be the basis for a certificate hierarchy for routing address range delegations, including for SEND, when it is approved by the IESG. --------------- Pekka Nikander: I have now processed the subissues in issue #08, and acted mostly as James suggested in his message on Sep 15th. Some specific comments: > Issue 8a: > "The certificate transport is relatively straight-forward, but the > description of certificate chains could benefit from some clarifications and > examples showing at least one valid certificate chain." > > Suggested resolution: > Since jak has been primarily been handling certificates, he will try to come > up with an example. So far I haven't received any examples. James, could you produce one today? I need to have the example by Friday morning my time to get it included. If not possible, I guess we need to leave addition of any such examples for the -01 version of the draft. > Issue 8d: > "o Section 6.3 (editorial): In PKIX-speak, the correct term would probably > be 'trust anchor', not 'trusted root'." > > Suggested resolution: Jari has said in an initial followup email that he > will make the change. I performed a global replace for this, even renaming the Trusted Root option as Trust Anchor option. The document doesn't contain the word "root" any more. > Issue 8e: > "o Sections 6.3 and 6.6 (technical): Presumably, the 'trusted root' should > contain the issuer of the first certificate in the chain But for X.509 > certs, that's a Distinguished Name, not FQDN. So should the "trusted root" > option contain a DER-encoded Issuer DN instead of FQDN? > > Using AltSubjectName (correct spelling is subjectAltName, BTW) seems to make > it more difficult for the router to decide which certificate to send, since > its own certificate doesn't necessarily have the CA's dNSName (though it may > be included in issuerAltName extension). ... > Suggested resolution: These issues are superceded by use of > draft-ietf-pkix-x509-as-extn. Actually the trust anchor name issue is not superceded. The document now allows both FQDM and DER-encoded X.509 Name, as requested by Jon Wood yesterday. Unless there are any more comments, I will consider this issue to close together with issue #20. ---------------