Jon Wood: I'm not sure that using a FQDN (i.e. hostname) to represent a trusted root is a good thing, since intermediate and root authorities might not be hosts. Also, if we want to use FQDNs in SEND in this fasion, won't we need to also mandate a certificate profile that requires the inclusion of DNS alt subj names in each cert? I would rather that we stuck with using the basic subject field in a cert. If we do, we would need some changes in the trusted root option: the name should probably be DER-encoded X501 Name type (which is how it is encoded in a cert), and we would not need the pad length any more, since the DER-encoding would give us that information. Section 6.6 would also need to change references to subjectAltName. --------------- Pekka Nikander: We discussed this issue at the DT for some length, but I don't remember any more all of the details. In any case, I would have liked to use a hash of the root public key to represent the root, but that was not considered as a good choice since it would be fairly hard to use such a hash as a search key. I think it was mostly James who prefererred the FQDN, and if I remember right, the main reason was the ease of using it as a search key. That is, if we use the FQDN to represent the root, we can use either LDAP or DNS to store the keys and to retrieve them. Anyway, for me it is OK to define a new type of the name field, as an alternativity to the FQDN, both being equally acceptable (and both being mandatory to implement). Here is the suggestion: When the Name Type field is set to 2, the Name field contains a DER encoded X.501 certificate Name, represented and encoded exactly as in the matching X.509v3 root certificate. What comes to Section 6.6, you are right. It needs to be revised so that the FQDN is not really mentioned, but the text should be more generic. Here is my suggestion, presuming that we define a DER encoded subject format. Old text: In a solicited-for advertisement, the router SHOULD include suitable Certificate options so that a delegation chain to the solicited root can be established. The root is identified by the FQDN from the Trusted Root option being equal to an FQDN in the subjectAltName field of the root's certificate. The router SHOULD include the Trusted Root option(s) in the advertisement for which the delegation chain was found. New text: In a solicited-for advertisement, the router SHOULD include suitable Certificate options so that a delegation chain to the solicited root can be established. The root is identified by the Trusted Root option. If the Trusted Root option is represented as an FQDN, the FQDN must be equal to an FQDN in the subjectAltName field of the root's certificate. If the Trusted Root option is represented as a DER Encoded X.501 Name, then the Name must be equal to the Subject field in the root's certificate. The router SHOULD include the Trusted Root option(s) in the advertisement for which the delegation chain was found. --------------- James Kempf: I don't have any problem with using a DN for this. From talking with some people about it, it seems as if a DN is used for SSL as well, so this seems to be standard practice. Also, from a simplicity standpoint, I think it makes sense to minimize the diffs between this and the PKIX IP Address extension, to avoid implementation and deployment complexity. As for obtaining a key in the DNS, I recall we did discuss this in the DT, but given the current design, I am not sure whether there is any benefit in adding an additional field to the certificate for that purpose if it requires the network operator to modify how they would utilize the standard PKIX router certs. The assumed use case here is that the host has the cert chain for the trusted root preloaded rather than opportunistically being able to get the key from the DNS. I think this use case is likely for the near future. So, I'd suggest that rather than having both the DN and FQDN be required to implement, the former be required and the latter be optional. This would simplify the most likely current deployment base design. When SEND goes from PS to DS, the design can be re-examined based on deployment experience. --------------- Jon Wood: This is better. However I'm now concerned that this may cause interop issues, in that unless the rest of the PKI infrastructure is set up to handle each case, nodes may not be able to find delegation chains. For example, if a node sends a DCS with a DNS name trust anchor option, and either the PKI supports only lookups by DNs or the trust anchor certificate doesn't have a DNS alt name extension, then no routers will be able to provide a DC for the requested trust anchor (even though one might exist if indexed by the DN). I guess my discomfort with the DNS alt name stems primarily from my concern that DNS alt names may not always be there in certs and lookup tables, whereas I feel it more likely that DNs will be there. However, I am no PKI expert, so I will happily yield to a counter argument based on more solid information :) --------------- James Kempf: Well, I suppose I agree on this. Even having the DNS alt name in as an option has the potential to lead to additional implementation and deployment complexity. Keeping SEND simple is more likely to cause people to want to implement it (a viewpoint from Randy Bush that I am beginning to appreciate). Perhaps the best course, for now, would be to simply require the DN and leave any mention of the DNS alt name out. If DNS keys become widely deployed, the spec can be revised at that time to include it as an alternative. --------------- Pekka Nikander: Having the FQDN there as an OPTIONAL feature doesn't add much implementation complexity. The deployment complexity may be a real issue, though. > Perhaps the best course, for now, would be to simply require the DN > and leave any mention of the DNS alt name out. If DNS keys become > widely deployed, the spec can be revised at that time to include it > as an alternative. Well, for the current version of the draft, I did the following: - reordered the names so that DER Encoded X.501 Name is number 1 and FQDN is number 2 - made FQDN support OPTIONAL - added a requirement that a each Delegation Chain Solitiation MUST have at the first (or only) Trust Anchor option a DER Encoded X.501 Name. I think that this is more future proof, taking even care of the situation where people are using new types of Trust Anchors. --------------- Jon Wood: I am happy with this. --------------- James Kempf: Fine by me as well. --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------