Carlos,
Hello,
I think what we need to discuss is which certificate validation rules
apply to our problem domain, basically securing origin and/or securing path.
Current specs refer that RFC 3779 validation rules should be applied to
SIDR's problem domain. I couldn´t find any justification for this, other
than 'RFC 3779 was already there by the time SIDR started'. Maybe I'm
wrong and this discussion indeed took place. I'd appreciate any pointers.
3779 was developed for the RPKI context (when S-BGP was the encompassing
term);
that's why it was adopted by SIDR. The extension was developed by folks with
considerable PKI expertise, as a way to make minimal changes to standard PKI
path validation.,
Regarding our draft, maybe we can split the discussion about possible
solutions to the problem (as I understand from our last meeting there
was rough consensus that there is indeed a problem to be solved here) in
two parts:
- Unbundling: For example, a wrong ASN list currently invalidates both
IPv4 and IPv6 resources in the same cert and down below. It doesn´t seem
to make much sense to have a mistake in one resource type invalidate the
other two. Discuss #1!
The original S-BGP design had 2, essentially parallel PKIs, one for ASNs
and one for address blocks. We elected to consolidate the two into
one because the CAs are the same in most cases, and it saves space,
bandwidth, etc., even though the extensions are distinct. Combining the two
trees was seen as a good engineering decision, even though the
resources are separate.
But, then, so are IPv4 and v6 address prefixes. Do you propose creating
separate PKIs
for IPv4 and IPv6 addresses?
- Managing mistakes within the same resource type: Should a mistake in
one IPv4 prefix invalidate the whole cert and down below for *all*
prefixes? Discuss #2!
Should revocation of a cert with a set of prefixes invalidate all
the certs below? (hint, the answer is yes.) The examples cited by
you and your fellow authors focus only on errors in 3779 extensions,
but why are revocation errors not equally important to address?
A PKI based on X.509 yields a binary validity outcome for path validation,
plus a set of ancillary info that may be used by an app. One might
imagine
treating 3779 extensions as ancillary data, but that won't affect the
revocation
error situation.
I agree on keeping the discussion to real world problems and not
perceptions. So the 'encouraging sloppiness' argument, whether perhaps
having some merit, is not really about a threat or a specific attack or
a about a specific problem.
The sloppiness argument is very much a real world issue, based on two
decades
of experience in the Web PKI environment. Certs used in the Web PKI
frequently do
not adhere to PKIX specs, validation is sometimes sloppy, and the
results have led
to real attacks. (For example, a major vendor failed to enforce the CA
flag in the
Basic Constraints extension, and that allowed attacker to forge certs.)
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
