Hi Tim,

> Hi all,
> 
> I wanted to ask how others feel about having resource certificates that
> say: "no resources certified."
> 
> We have a use case for this at the RIPE NCC. It may happen (for various
> reasons) that a member who formerly had a resource certificate issued by
> us no longer holds any certifiable resources.
> 
> We can of course revoke all existing resource certificate and not issue
> a new one. But.. I feel this is confusing to RPs. In particular RPs may
> assume, wrongly, that we just forgot to issue a new cert. It's a much
> more clear to have a new certificate that says "no resources".
> 

(Roque) 
In the RPKI context, a certificate without resources would be an attestation of 
what exactly? How can you validate it ? (see section 7.1 of the same document)

I do not think we should model bizarre RP behaviors. What I believe you are 
trying to do is similar to the idea of using CRL reason code, a debate we 
already had. 


Regards,
Roque


> But it seems this is not allowed by the res-cert draft:
> 
> We MUST include at least one of "an IP Resources extension, an AS
> Resources extension", as described here:
> http://tools.ietf.org/html/draft-ietf-sidr-res-certs-18#section-4.9.10
> 
> And that inclusion of an "IPAddressFamily" only gives us the option to
> either: (1) include a specific resource(range) of that type, or (2)
> inherit from the issuer, as described here:
> http://tools.ietf.org/html/rfc3779#section-2.2.3
> 
> So, we can not legally issue a new resource certificate that says: "no
> resources". As far as I can tell this is perfectly legal to do under
> rfc3779: just don't include any "IPAddressFamily"; use a "SEQUENCE OF"
> with length 0.
> 
> So, to re-state my question: do others also see a use-case for resource
> certs that have no resources? And if so, could section 4.9.10 of the
> res-cert draft be reworded: MUST -> MAY.
> 
> 
> Regards,
> 
> Tim Bruijnzeels
> 
> Senior Software Developer
> RIPE NCC
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to