Re: [Sidrops] Manifest entry filename validation

Hi Russ,

> On 24 Nov 2020, at 16:12, Russ Housley <housley@vigilsec.com> wrote:
> 
> Tim:
> 
> RFC 2585 is the document that specifies the conventions of ".cer" and ".crl" for X.509 certificates and X,509 CRLs, respectively.

That may well be, but I still think it would be useful, in the context of RPKI, to be able to differentiate between different types of .cer *before* parsing rather than differentiate while parsing. And if we did, then an entry in the IANA registry "RPKI Repository Naming Scheme" could be appropriate. Anyway, I don't want to complicate things - if RP implementers don't speak up that they want this, then I would say we just leave it as an aside..

The other more important reason for bringing up that registry is because it already defines the extensions one can expect. So I would suggest that the following in item 2

  extension defined for the object type

Becomes:

  extension defined for the object type in the IANA registry "RPKI Repository Name Scheme" 

Tim

> 
> Russ
> 
> 
>> On Nov 24, 2020, at 3:21 AM, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
>> 
>> Hi Job, Steve, all,
>> 
>> I am losing track a bit, but I believe this text below was the latest suggestion by Job to Steve, right?
>> 
>> Question / suggestion on extensions below.
>> 
>>> On 23 Nov 2020, at 16:10, Job Snijders <job@ntt.net> wrote:
>>> 
>>> Thanks Ties, how about:
>>> 
>>> --------------------
>>> 
>>> Section 4.2.2 "Names in FileAndHash objects"
>>> 
>>> The following restrictions are imposed on the names that appear in the
>>> fileList:
>>> 
>>> 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE).
>>> 
>>> 2. Each name MUST be suffixed with the appropriate filename extension defined for the object type, and the filename extension MUST be lowercase, e.g., '.cer' or '.roa'.
>> 
>> I think we should probably have a normative reference here to section 7.2 of RFC 6481 (Repository Structure), or better yet to the "RPKI Repository Naming Scheme" registry maintained by IANA:
>> 
>> https://www.iana.org/assignments/rpki/rpki.xhtml
>> 
>> As that section says the extensions are supposed to be "three-letter", presumably to make file name parsing safe. Not sure if that needs to be repeated here explicitly.
>> 
>> As a side note, while I am here.. I would also like to note that it's a bit unfortunate that '.cer' can be _any_ resource certificate. So it could be:
>> - An RPKI CA certificate used for delegations
>> - A 'naked' EE certificate (as possibly used by RFC 7909)
>> - A BGPSec Router certificate
>> 
>> At least my quick scanning of RFC 6481 seems to imply this, as it uses the term 'certificate' without applying further constraints. However, it would be nicer for RPs if these cases used different extensions. This could simplify parsing quite a bit. And while this would be a breaking change in theory, I think it could be done without impact in practice since currently *all* .cer files found in the wild are CA certificates.
>> 
>>> 
>>> 3. The . (DOT) character MUST appear exactly once.
>>> 
>>> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.
>> 
>> Looks good to me.
>> 
>> Tim
>> 
>>> 
>>> _______________________________________________
>>> Sidrops mailing list
>>> Sidrops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidrops
>> 
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops