At 12:54 PM -0700 6/6/08, Nelson B Bolyard wrote: >I recall a long discussion on this list in which certain people observed >(or opined) that the cert path validation algorithm defined in RFC 3280 >has the characteristics you describe above. That is, the claim was made >that RFC 3280's algorithm does not require a trust anchor to be anything >more than a public key, and does not impose any checks on it for validity >dates, key usages, extended keys usages, name constraints, etc. etc.
This is correct, I opine. >In other words, the claim was that RFC 3280 considers a trust anchor to >be absolutely trusted in all respects for all purposes at all times. These "other words" are not correct, I opine. RFC 3280, and now RFC 5280, explicitly allow for limits on the trust, such as name constraints. >(Put another way, the criteria for selection of a trust anchor are outside >the scope of the algorithms defined in RFC 3280, and any such criteria >have already been applied to the trust anchor before the algorithm defined >in RFC 3280 begins.) Also, not correct, I opine. What I believe 3280/5280 say is that the metadata in the trust anchor certificate itself are not themselves part of the path processing. Instead, a trust anchor has metadata that the process doing the path processing assigns to the trust anchor. That could come from metadata that is in the cert (if it is a cert), or it can be outside. The fact that a trust anchor might be loaded in the form of a certificate is not inherently interesting to path processing. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
