David A. Cooper wrote:
Sean,
The SIDR WG has defined its own certificate validation algorithm in
Section 7 of draft-ietf-sidr-res-certs-18. Steps 3 and 4 in Section 7.2
require the client to check that:
Dave,
Thanks for the heads up. I'm still learning all the ins and outs of
these specs.
3. The certificate contains all fields that MUST be present and
contains field values as specified in this profile for all
field values that MUST be present.
4. No field value that MUST NOT be present in this profile is
present in the certificate.
So, for a client to conform to draft-ietf-sidr-res-certs-18 it MUST
check (for example) that certificates include a subject key identifier
extension, that the extension is marked as non-critical, and that its
value is the SHA-1 hash of the subject public key.
A couple of years ago I pointed out that these checks were unnecessary,
that RFC 5280 discourages including checks during path validation for
the sole purpose of verifying that the certificates were issued in
conformance with the profile, and that requiring the checks to be
performed would preclude the use of off-the-shelf path validation
software in the RPKI. While no one explained the reason for mandating
these checks, I was told that "the requirements of steps 3 and 4 very
definitely are intended to be applied" and the requirements were kept in
the document.
Are we doing these checks to slow the validation process down? ;)
Like I said I don't see the need to check some of the information in
the certificate during validation. I agree with you that it is
unnecessary to check a few of things during path validation that are
required to be in some certificates: AKI, SKI, AIA, SIA, and CRLDP.
If these checks can't be explained and it's causing problems for key
rollover, then maybe we should drop the checks.
spt
Dave
On 06/15/2010 03:14 PM, Sean Turner wrote:
Did you see something in Section 6.1 of RFC 5280 that made you think
AIA should be used during path validation? If you use the
id-caIssuers method in the AIA, then it is useful to locate the
certificates needed to build the path, but I don't think you need to
use it during path validation. There are a couple of pieces of
information in the certificate that are useful for building the path
but don't need to be checked during validation. I think AKI, SKI, and
AIA fall in to that category. I guess you're free to add any checks
you like, but if a check causes the path validation to fail that
should have otherwise passed - then that's a bad thing.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
