Subject: [sidr] draft-ietf-sidr-repos-struct to Standards Track

From: Stewart Bryant <[email-masked]>
Date: Fri, 15 Jul 2011 20:53:45 +0100

SIDR WG,

During IESG review the there was a preference for
draft-ietf-sidr-repos-struct to be Standards Track
rather than BCP.

Making this change does not require a new IETF LC.

I want to get sense of whether the WG would be OK
with this change of track.

If anyone has a reason not to change to Standards
Track, please let me know by 29th July.

Thanks

Stewart

---

From: Stephen Kent <[email-masked]>
Date: Sat, 16 Jul 2011 10:19:13 -0400

>Track, please let me know by 29th July.

I'm comfortable with standard (instead of BCP).

Steve

---

From: Geoff Huston <[email-masked]>
Date: Sun, 17 Jul 2011 11:33:35 +1000

> Track, please let me know by 29th July.

The draft is ambivalent - it has a bunch of standards-type normative terms of MUSTs and SHOULDs, yet the introduction states that these are just recommendations. 

As far as I understand it, as long as a CA conformed to the res-cert profile draft and related standards track specs, the CA can do pretty much whatever it wants in terms of the structure of their repository publication point and a cautious Relying Party would still be able to synchronise with it. So as far as I can see the draft is logically a BCP in so far as it is saying "this is good practice for a CA in terms of management of its publication point" and, quite properly, the drtaft falls short of saying "this is a necessary set of constraints that are necessary for interoperability." 

I suspect that either way the draft should be edited. If it were to be standards track the introductory text that refers to recommendations should be altered to say that this is a mandatory part of the specification of a CA's publication (but in such a case I do not believe that there is clear technical justification for such a restriction), and if it were left as a BCP then it would be more consistent if the use of normative terms were to be excised from the draft.

Personally I feel that Standards Track is using a sledge hammer to crack a nut - I think its overkill and has no clear technical justification in my view.

Geoff

---

From: Rob Austein <[email-masked]>
Date: Sun, 17 Jul 2011 10:53:23 -0400

This draft defines the mappings from filename extension (.cer, .roa,
.crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc).

Without this mapping, relying party tools have no way of knowing what
they're looking at in most cases, and would have to attempt to decode
every object in various ways to see which (if any) worked.  This would
be tedious, error prone, and generally a bad idea.

For this reason, I think the document that defines the filename
mappings should be Standards Track; at present, that's this document,
so I agree with the change of track.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 18 Jul 2011 07:41:40 +1000

> be tedious, error prone, and generally a bad idea.

But wouldn't the CMS (and ASN.1 for that matter) effectively tell the RP what the object was intended to be? It strikes me that the file name extension is a bit of syntactic sugar rather than an essential and necessary component, so I'm curious to understand what has changed in this particular PKI that makes the filename extension such a necessary attribute. If this is the case would a rogue CA be able to mount an effective DOS attack for all RPs by deliberately mis-naming objects? 

Geoff

---

From: Rob Austein <[email-masked]>
Date: Sun, 17 Jul 2011 19:40:28 -0400

At Mon, 18 Jul 2011 07:41:40 +1000, Geoff Huston wrote:
> But wouldn't the CMS (and ASN.1 for that matter) effectively tell
> the RP what the object was intended to be?

As I said: "attempt to decode every object in various ways to see
which (if any) worked".  Not all objects are CMS.  The outermost
layers of ASN.1 on most of them are sequences of sequences of blah
blah blah.  Yes, if one peers at these things long enough it becomes
obvious what they are, assuming no encoding errors, but it's not like
there's a trivial tag in each one saying "this an X.509 certificate",
"this is a CMS object", or "this is a CRL".

> It strikes me that the file name extension is a bit of syntactic
> sugar rather than an essential and necessary component, so I'm
> curious to understand what has changed in this particular PKI that
> makes the filename extension such a necessary attribute.

Most PKIs aren't deep trees distributed over an arbitrarily large
number of distinct servers and directories, in most cases one knows
exactly what an object purports to be when one attempts to validate
it, and in most cases one is not attempting to validate tens of
thousands of objects at once.

> If this is the case would a rogue CA be able to mount an effective
> DOS attack for all RPs by deliberately mis-naming objects?

No.  The names are hints as to the intended decoding.  If the encoding
doesn't match the hint, the decode fails pretty quickly.  The
difference here is that the RP tries exactly one decode, and if that
doesn't work, the object is toast.

A MITM attack on rsync could of course whack the filenames, but it
could also corrupt the objects themselves, with pretty much the same
effect, so it's not a new threat.

---

From: Terry Manderson <[email-masked]>
Date: Sun, 17 Jul 2011 16:42:51 -0700

Hi Stewart,

I'm struggling to see how draft-ietf-sidr-repos-struct could exist as a
Standards Track document without a significant rewrite and then passing back
through both WG and IETF last calls.

The document at this stage is structured as a _recommendation_ to RPKI
participants on one particular RPKI naming scheme.

While I think that having the files in the RPKI have particular extensions
helps relying parties decode the structure, I'm not convinced that turning
that into a standards action is a healthy option.

At this stage I feel more comfortable leaving it as BCP.

Cheers
Terry

On 16/07/11 5:53 AM, "Stewart Bryant" <[email-masked]> wrote:

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

---

From: Terry Manderson <[email-masked]>
Date: Sun, 17 Jul 2011 16:42:54 -0700

> be tedious, error prone, and generally a bad idea.

This actually makes me wonder why the manifest (
draft-ietf-sidr-rpki-manifests) in:

FileAndHash ::=     SEQUENCE {
      file            IA5String,
      hash            BIT STRING
      }

Doesn't have a RPKIObjectIdentifier that tells the relying party what the
object it has just retrieved is in terms of ROA/CERT/etc, as a signed
attestation.

(and then an appropriate IANA registry for RPKIObjectIdentifier could then
be created and populated as a standards track)

If repos-struct was standards track and the naming scheme was the prime
mapping system then if a RPKI repository publication [1] point is
compromised (or even MiTM!) it would be a trivial exercise to perform some
substitutions on the filename to confuse (routing security downgrade DoS)
the relying party.

[1] Remember that the publication point is _just_ an rsync server (at this
stage).

Cheers
Terry

---

From: Geoff Huston <[email-masked]>
Date: Mon, 18 Jul 2011 11:29:27 +1000

> object it has just retrieved is in terms of ROA/CERT/etc, as a signed

I don't have an answer - it's a good question.

> [1] Remember that the publication point is _just_ an rsync server (at this

I personally feel uncomfortable on standardising a naming scheme from the dim dark prehistory of mainframe filesystems  as an intrinsic part of the RPKI - it seems so retrograde! I thought a BCP represented a slightly softer approach, but your question about the manifest contents and type flagging in there is an interesting approach. At one stage there was the though that the manifest would be optional for a CA, but somewhere along the path I think they were made mandatory, but in the forest of SIDR drafts I have no idea which one says that manifests are REQUIRED.

  Geoff

---

From: Stephen Kent <[email-masked]>
Date: Sun, 17 Jul 2011 22:32:02 -0400

At 7:41 AM +1000 7/18/11, Geoff Huston wrote:
>the RP what the object was intended to be? It strikes me that the 
>file name extension is a bit of syntactic sugar rather than an 
>essential and necessary component, so I'm curious to understand what 
>has changed in this particular PKI that makes the filename extension 
>such a necessary attribute. If this is the case would a rogue CA be 
>able to mount an effective DOS attack for all RPs by deliberately 
>mis-naming objects?

If youy want to compare the RPKI to the general PKI repository model 
(X.500), note that in an X.500 directory, every object is tagged in a 
fashion analogous to the filename extension. LDAP tags objects as 
well. So why is it not appropriate to do so, in a normative fashion 
here?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sun, 17 Jul 2011 22:42:29 -0400

At 4:42 PM -0700 7/17/11, Terry Manderson wrote:
>...

the filename extension, which is part of the "file" data type above, 
conveys the needed info. yes, one could add an OID here, but 
ultimately an RP will check the syntax and know which file is what 
type. Som, adding an OID doesn't seem to help much in a manifest.

>substitutions on the filename to confuse (routing security downgrade DoS)

if there are no mandated filename extensions, then every pub point is 
a mini-DoS attack, as Rob noted. We can't prevent a rogue pub point 
manager (or CA) from mislabelling files relative to the 3-char 
extension, but why invite chaos :-)?

An earlier draft of this doc called the extensions mere 
recommendations.  I persuaded Geoff to make them mandatory. The 
arguments I made then still
apply, which is why STD vs. BCP seems appropriate, to me.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Mon, 18 Jul 2011 12:53:11 +1000

On 18/07/2011, at 12:32 PM, Stephen Kent wrote:

> If youy want to compare the RPKI to the general PKI repository model (X.500), note that in an X.500 directory, every object is tagged in a fashion analogous to the filename extension. LDAP tags objects as well. So why is it not appropriate to do so, in a normative fashion here?

How is this X.500 directory "tagging" achieved in other PKIs? Three letter filename extension conventions? Or some other tag mechanism?

---

From: Terry Manderson <[email-masked]>
Date: Sun, 17 Jul 2011 20:30:02 -0700

> I don't have an answer - it's a good question.

Certainly one to consider, and touches more on my personal philosophical
point that while the 'directory and file' structure that is promulgated in
the RPKI work at this stage has utility, primarily based on 'what works now'
design choices - longer term I am far more comfortable in thinking toward an
object structure.

whereas now we see RSYNC://rpki.blah.org/something/xyzzy.roa one day in the
future when it is palatable to think along such lines something like
HTTPS://rpki.blah.org/something/subject?ROA might also validly exist.

<climbs down from soapbox>
 
> 
> I personally feel uncomfortable on standardising a naming scheme from the dim
> dark prehistory of mainframe filesystems  as an intrinsic part of the RPKI -
> it seems so retrograde! I thought a BCP represented a slightly softer
> approach, but your question about the manifest contents and type flagging in
> there is an interesting approach. At one stage there was the though that the
> manifest would be optional for a CA, but somewhere along the path I think they
> were made mandatory, but in the forest of SIDR drafts I have no idea which one
> says that manifests are REQUIRED.

I believe draft-ietf-sidr-res-certs section 4.8.8.1.

"This extension MUST have an instance of an AccessDescription with an
   accessMethod of id-ad-rpkiManifest"

Terry

---

From: Terry Manderson <[email-masked]>
Date: Sun, 17 Jul 2011 20:50:19 -0700

>From what little I know about LDAP/X.500 directories, the tagging is driven
from the DIT. Surely that is more analogous to the RPKI manifest than a
filename based extension. Or am I missing your point or some key
example/information?

I'm happy to see things tagged in a normative fashion, I just think putting
the eggs into the filename/directory basket as a standards action is
worrying.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Sun, 17 Jul 2011 21:08:41 -0700

> type. Som, adding an OID doesn't seem to help much in a manifest.

So, I'm confused.. if the RP ultimately checks the syntax, why is tagging
needed at all?

> extension, but why invite chaos :-)?

Right, so its a processing issue.

So through the hierarchy (loosely speaking TA points to CA, CA points to
Rescert, Rescert points to publication point and manifest) the lesser of the
chaos scenarios would be to put the 'labeling' in the highest possible
location within the publication point. I'm guessing the most sane is the
Manifest, if it is truly a standards action requirement.

As the manifest is a signed object, it has the benefit of being tightly
interpreted as an attestation by the issuer that this 'file' with a
specified hash is a ROA. How much clearer do you need to be? or want to be?

> apply, which is why STD vs. BCP seems appropriate, to me.

Were those arguments made on list? if so I will go hunting and reflect on
them with a Merlot in hand this evening.

Terry

---

From: Randy Bush <[email-masked]>
Date: Sun, 17 Jul 2011 22:05:41 -0700

> well. So why is it not appropriate to do so, in a normative fashion 

it is appropriate.  imiho, those should be MUSTs.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 17 Jul 2011 22:06:39 -0700

> So, I'm confused.. if the RP ultimately checks the syntax, why is tagging

think tlv.  that's the t

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 18 Jul 2011 13:39:06 +0200

Hi,

> so I agree with the change of track.

+1

I agree that not having this mapping is tedious and error prone for RPs.

Example:
- ROA that isn't strictly standard compliant / validator has bug in ROA recognition

Validator tries to parse as roa, cer, crl, mft; then gives up...

This is not only ugly code to maintain, it also makes it difficult to debug problems. The happy flow case, while cumbersome, is not the biggest problem here I think..

How do we work out, in this example, what caused the actual problem? From the software side it's rather involved to build something like: this looks 99% like I ROA, one I don't understand, but it's probably what they meant or something like that... so our tool just says: I don't understand this *object*.

If we do have the mapping the validator can give a far more informed error message. For starters it can say: "I don't understand this *ROA*.". But also, since it knows it should be a ROA it can report why it rejected it as a ROA. If we had no clues about the intent we would also have to tell the users why we rejected it as any other object.. The less noise we produce here the easier it will be for RPs and publishers to work out where the real problem is and fix it.

Whether this mapping strictly needs to be in this draft may be another question.

Regards,

Tim Bruijnzeels

Implementing stuff @RIPE NCC

---

From: Terry Manderson <[email-masked]>
Date: Mon, 18 Jul 2011 18:57:34 -0700

> I agree that not having this mapping is tedious and error prone for RPs.

I can agree that a mapping system is useful. It may just be that living unix
world for far too long has seen me move away from the mandatory dos-like
suffixes to the voluntary use of extensions in a unix file system as a
*hint* to the file contents and nothing more.

And I'm happy to see it written as a hint. A validated mapping should come,
in my opinion from something more robust which also transcends the
technology used in the repository.

> Validator tries to parse as roa, cer, crl, mft; then gives up...

So the validator has a bug. fix the validator?

> This is not only ugly code to maintain, it also makes it difficult to debug
> problems. The happy flow case, while cumbersome, is not the biggest problem
> here I think..
> 
> How do we work out, in this example, what caused the actual problem? From the
> software side it's rather involved to build something like: this looks 99%
> like I ROA, one I don't understand, but it's probably what they meant or
> something like that... so our tool just says: I don't understand this
> *object*.
> 

Same goes for a misname (malicious or otherwise) of the file. A robust
mechanism as I see it doesn't live in three letter extensions.

> Whether this mapping strictly needs to be in this draft may be another

Agree with that point.

Cheers
Terry

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Jul 2011 21:23:15 -0700

> And I'm happy to see it written as a hint. A validated mapping should
> come, in my opinion from something more robust which also transcends
> the technology used in the repository.

easy.  throw away the entire structure and code to date and do it as a
collection of tlvs.

i suspect no one else wants to go there, at least no one with code in
the game.

randy

---

From: Terry Manderson <[email-masked]>
Date: Mon, 18 Jul 2011 21:37:13 -0700

> easy.  throw away the entire structure and code to date and do it as a

I think there is an easier way, as already suggested. Add the object type to
the manifest in FileandHash.

1) the rescert points to the publication point and manifest
2) the manifest is mandatory
3) the manifest is signed
4) the manifest is nicely(?) readable ASN.1

Really its a much nicer and more robust solution than either throwing the
entire structure out or using filename extensions to 'mandate' file/object
content.

Then if hints, for human readable reasons, are still required then maintain
the extensions as they are as a BCP.

> i suspect no one else wants to go there, at least no one with code in

Really... that is a shame. I always thought that coders wanted to make their
code less susceptible to adverse external influence.

T.

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jul 2011 04:15:46 -0700

> I think there is an easier way, as already suggested. Add the object
> type to the manifest in FileandHash.
> 

so move the deck chairs from coding the type in a directory maintained
by the operating system to one the spec and the programmers write and
maintain?  big win there, eh?

> entire structure out or using filename extensions to 'mandate' file/object

we've a long tradition of using the file name extensions, formalities
for registering them, ...  do we really need to reinvent the wheel?
where is the win?

> Really... that is a shame. I always thought that coders wanted to make
> their code less susceptible to adverse external influence.

luckily for me, i do not have to think.  they already supported the move
from bcp to ps on this very list.

a principal goal of this little ietf thing is interoperability.  the
iesg noted we were being a little weak in ensuring interoperability in a
spec that has already been written, coded multiple times, mildly
deployed, approved by the wg, gone through ietf last call, and passed by
the iesg.

for this to be changed now is not impossible.  it just needs some really
solid reasoning and really solid documentation of how and why it should
be changed.

randy

---

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2011 05:51:50 -0700

> maintain?  big win there, eh?

The win is to eliminate a threat that has already been identified on the
list.

Is that not worthwhile?

Perhaps consider it from a view of security requirement, than coding ease.

> for registering them, ...  do we really need to reinvent the wheel?

In the case of a repository system that may over time represent some worth,
and looking at this from a point of eventually operating such a repository
high up in the tree I have a concern of injecting 2 more paragraphs of text
into a organisational risk analysis that could raise eyebrows given a simple
solution to an identified threat has been proposed.

I can tell now I'll be answering "What the!?!" type questions from people
with significantly more influence than I for weeks, if not months. :(

> from bcp to ps on this very list.

And I can only hope they rethink their position.

> solid reasoning and really solid documentation of how and why it should

So both Steve and Rob identified that mapping is required to remove a mini
DoS threat (and I'm fine with that). Geoff and I have the belief that a
mapping based on the extension exposes a CA/Repository related threat given
the objects are supposed to be secure in nature. The suggestion of adding
the mapping/type into the Manifest (while awkward in ietf processing) gives
both the mapping result, and removes the CA/Repository threat identified.

What other documentation are you looking for?

If it helps, I can also propose the ASN.1 substitution for the manifest and
the necessary paragraph for the IANA considerations section.

Cheers
Terry

---

From: Rob Austein <[email-masked]>
Date: Tue, 19 Jul 2011 09:59:56 -0400

> The win is to eliminate a threat that has already been identified on the

What threat?  Please describe it.

The only "threat" I saw discussed is, in my opinion, a non-issue: an
attacker can mangle filenames in the unprotected data stream, thus
causing objects to fail validation.  An attacker who can do that can
also mangle the objects themselves in the unprotected data stream,
which will also cause the objects to fail validation, so being able to
change the filenames doesn't give the attacker anything new.

> The suggestion of adding the mapping/type into the Manifest (while
> awkward in ietf processing) gives both the mapping result, and
> removes the CA/Repository threat identified.

The file types are already in the manifest, because the file types are
encoded in the filenames, which are in the manifest.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 19 Jul 2011 16:25:27 +0200

> encoded in the filenames, which are in the manifest.

and to add to this:
Objects may appear in the repository but not on the manifest (manifest doc 8.5).
So having the type as a field in the manifest does not help.

I am sorry if I am oversimplifying or missing the point but my impression is that:
- some people don't like file extension mapping for reasons that are not technically convincing to me.
- other people say that having them will actually make it much easier to solve problems between RPs and publishers.

Like I said I am happy to have this mapping as a standard elsewhere if the repos-struct draft has other stuff in it preventing this from going to standards track.

And if we can't have standard I suppose we will just trial-error-parse-it-all and say 'Can't understand your "object"', instead of something useful...

Regards,

Tim

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 19 Jul 2011 10:37:46 -0400 (Eastern Daylight Time)

> Like I said I am happy to have this mapping as a standard elsewhere if the repos-struct draft has other stuff in it preventing this from going to standards track.

A process reminder here.  Several other documents point to the 
repos-struct draft, some of them specifically regarding the file 
extensions.  Separating out the tagging into a separate document could 
mean some serious review of multiple documents.

--Sandy, speaking as wg chair

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 19 Jul 2011 10:41:50 -0400 (Eastern Daylight Time)

> The win is to eliminate a threat that has already been identified on the

I see that someone else has already responded to this statement, but I'd 
like to chime in that I'd like to see an explicit statement of the threat 
and how the OID mechanism you suggest would counter it.

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 19 Jul 2011 11:02:27 -0400 (Eastern Daylight Time)

> technology used in the repository.

There was a brief discussion of the use of file names extensions when the 
repos-struct document came up for last call.  See the following messages:

http://www.ietf.org/mail-archive/web/sidr/current/msg02281.html
http://www.ietf.org/mail-archive/web/sidr/current/msg02282.html
http://www.ietf.org/mail-archive/web/sidr/current/msg02283.html
http://www.ietf.org/mail-archive/web/sidr/current/msg02284.html

To summarize: George Michaelson spoke against extensions when we were 
considering a registry (and Terry mildly supports them), I asked George if 
he as author was suggesting the draft needed to change and he said no and 
added that rsync can filter objects only on the basis of the file name.

So we've been around this barn already.

The point about the rsync filtering abilities has not come up this time.

I ask for review and consideration of that exchange (and the registry 
discussion context).

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jul 2011 08:48:07 -0700

> The win is to eliminate a threat that has already been identified on the

and is based on a weak premise.  rpki security is based on object, not
transport, security.  stuff might be garbled in transport.

and please remember that the manifest may be a proper subset of the
directory.

randy

---

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2011 13:40:47 -0700

> change the filenames doesn't give the attacker anything new.

I see those two as having a subtle difference. I guess I'm alone in that
observation.

> encoded in the filenames, which are in the manifest.

ok. So in which case before I give in to making repos-struct a PS, I would
want to see words somewhere that say that the validation choice for an RPKI
object file is to based on the filename in the manifest and not on the
transferred filename. Do such words already exist? If so, where? And is that
how validation implementations are already coded?

For some reason all I can think about with this extensions discussion is the
.txt.vbs windows worm exploit.. its all just so 1990's..

T.

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jul 2011 13:43:41 -0700

> transferred filename.

again, the manifest may represent a proper subset of the valid objects in the
directory

randy

---

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2011 13:45:47 -0700

> mean some serious review of multiple documents.

I think the question might be if the authors of repos-struct are willing to
rewrite parts (slabs?) of the document to be more in line with a PS?

As it stands now, I not so sure that repo-struct is structured as a ps,
despite many people's willingness to see it become that.

'Just because you drive a mini like a race car, doesn't actually mean it is
a race car."

T.

---

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2011 14:03:18 -0700

> considering a registry (and Terry mildly supports them), I asked George if

What I said was "and hint nicely". So happy to see it as the hint. That
hasn't changed, and create a registry if you so desire. I'm still not
comfortable in leading to a point where it is the
way (and it seems only way) an objects validation regime is chosen.

Rob's observation that the extension exists in the manifest file name is a
close approximation provided words exist as highlighted which gives clear
instruction to implementers as to
1) make the first approximation of validation regime on the filename in the
_manifest_
2) then try all others
3) give up.

T.

---

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2011 14:06:17 -0700

> again, the manifest may represent a proper subset of the valid objects in the

Which I think is sloppy behaviour.

T.

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 19 Jul 2011 17:20:37 -0400 (Eastern Daylight Time)

> What I said was "and hint nicely". So happy to see it as the hint. That

That's the "mildly" part.  George was speaking against file extensions at 
all, you said they had "special meaning" and were in favor of a registry.

--Sandy, explaining a former message sent when speaking as wg chair

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 19 Jul 2011 17:29:10 -0400 (Eastern Daylight Time)

> Which I think is sloppy behaviour.

It is a fundamental part of the proposed repository structure.

The following text from section 2.2 of the repos-struct draft:

    The RPKI design requires that a CA be uniquely associated with a
    single key pair.  Thus, the administrative entity that is a CA
    performs key rollover by generating a new CA certificate with a new
    Subject name, as well as a new key pair [I-D.ietf-sidr-keyroll].
    (The reason for the new Subject name is that in the context of the
    RPKI the Subject names in all certificates issued by a CA are
    intended to be unique, and because the RPKI key rollover procedure
    creates a new instance of a CA with the new key, the name constraint
    implies the need for a new Subject name for the CA with the new key.)
    In such cases the entity SHOULD continue to use the same repository
    publication point for both CA instances during the key rollover,
    ensuring that the value of the AIA extension in indirect subordinate
    objects that refer to the certificates issued by this CA remain valid
    across the key rollover, and that the re-issuance of subordinate
    certificates in a key rollover is limited to the collection of
    immediate subordinate products of this CA.  In such cases the
    repository publication point will contain the CRL, manifest and
    subordinate certificates of both CA instances.

says that in times of CA key rollover, the publication point directory 
should contain two manifests and all the files from both manifests.  So 
neither manifest contains all the files names in the directory.

---

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2011 15:07:33 -0700

> It is a fundamental part of the proposed repository structure.
[..] 
> neither manifest contains all the files names in the directory.

So long as a file appears in at least one manifest, I'm good.

Randy's email lead me to think that a file (valid rpki object) can exist in
a repository and not appear in a manifest at all. Is that the case?

Cheers
Terry

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Jul 2011 11:34:33 -0400

>the eggs into the filename/directory basket as a standards action is

Since we're using basic file systems for the repository (e.g., vs. 
LDAP), I think file names are an obvious candidate for labeling the 
object types in an easy fashion, for an RP's initial processing. 
Ultimately, an RP will check
the OID for each object and verify the signature on each object (for 
the critical, signed objects). But with the file name extension we 
allow an RP to rely on that top level declaration by a CA, and then 
see if that declaration holds up when more detailed checks are made.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Jul 2011 11:34:29 -0400

>So, I'm confused.. if the RP ultimately checks the syntax, why is tagging

see my reply to you message (now in flight :-)).

>Right, so its a processing issue.

yes.

>specified hash is a ROA. How much clearer do you need to be? or want to be?

yes, publication of a manifest is mandatory. But, if you read the 
manifest spec closely, especially the error case discussion, you'll 
see that RPs are encouraged to accept objects that do not appear on a 
manifest, under certain circumstances. Thus, if we were to rely 
exclusively on the manifest contents to direct RP processing we would 
degrade the functionality  currently specified.

>them with a Merlot in hand this evening.

I don't recall. I may have sent them directly to Geoff.

Steve

---

From: Rob Austein <[email-masked]>
Date: Wed, 20 Jul 2011 12:15:15 -0400

> 1) make the first approximation of validation regime on the filename in the

Sorry, wrong.  Attempt validation based on the filename type; if that
fails, the object is toast regardless of whether the filename appears
in the manifest or not.  Don't expect the RP to play guessing games.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Jul 2011 13:47:16 -0400

At 12:53 PM +1000 7/18/11, Geoff Huston wrote:
>...
>How is this X.500 directory "tagging" achieved in other PKIs? Three 
>letter filename extension conventions? Or some other tag mechanism?

I was referring specifically to the X.500 directory, which tags via 
its ASN.1 encoding for data types. But, in reality nobody uses X.500. 
LDAP is used instead, and it is based on X.500 (more precisely, 
X.501).

LDAP directories are accessed using the LDAP protocol, so file names 
don't enter into the picture. One identifies the entry (by 
distinguished name) and the object type (class) within the entry by 
OID, and the requests that value of the object (speaking about 
retrieval).  It is up to the implementation of the LDAP protocol to 
find the right type of object based on the search parameters 
provided, and to update or retrieve the objects accordingly.

The RPKI repository design is very different. it is not intended to 
support searching the way X.500 or LDAP does. Our operational model 
says that every RP needs to retrieve the current version of every 
object at every pub point (to first order), periodically. We selected 
rsync as the access protocol, and it uses directory and file names to 
locate objects. So, given our access model and our choice of access 
protocol, I think we ought to assume that filenames are the 
appropriate object names, and filename extensions are a convenient 
object type indicator, for use with this protocol.

Some RPs might, for example decide to not download GB files because 
these files are not critical to ROA validation. I am told that one 
can use rsync to perform selective retrieval based on a filename 
extension, so the use of such extensions seems very reasonable, as a 
means of enabling such selective retrieval.

Steve

---

From: Terry Manderson <[email-masked]>
Date: Wed, 20 Jul 2011 20:03:37 -0700

> in the manifest or not.  Don't expect the RP to play guessing games.

You wouldn't check the manifest? The manifest seems like the hinge point to
me.

I think I'll have to reflect on why you select that direction.

Cheers
Terry

---

From: Andrew Chi <[email-masked]>
Date: Thu, 21 Jul 2011 10:25:04 -0400

On 7/20/2011 11:03 PM, Terry Manderson wrote:
>
> On 21/07/11 2:15 AM, "Rob Austein"<[email-masked]>  wrote:
>

As another implementer, I agree with Rob.

Manifests cannot solve everything.  They detect when an expected file is 
NOT present.  If you try to use them as a comprehensive listing, you run 
into tons of gray areas.  I'll refrain from rehashing the discussion in 
the other thread about manifests, but you can insert that here.

Therefore, the BBN validator does the only thing sensible, which is 
validate based on filename and certificate chain.  After that, we check 
against the manifest and emit a warning if it doesn't look right.  And 
we provide the user with configuration flags to control the output of 
validator: does he want output from the "perfect" ROAs only (with 
perfect manifests all the way up the chain), or is some level of 
grayness acceptable.

Manifests are murky, especially when you misuse them.  Filename 
extensions are not.

-Andrew

---

From: Terry Manderson <[email-masked]>
Date: Thu, 21 Jul 2011 19:16:40 -0700

Hi Andrew,

> Manifests are murky, especially when you misuse them.  Filename

Maybe the repository should have been constructed in LDAP with a manifest
object there to confirm the ldap search returned all the roa objects.

I am, and still, remain uncomfortable about RPKI using filename extensions
as the only mechanism to select the validation regime. It might be a
flippant statement but even Microsoft office can tell a word document from
an excel document without the extension.

Perhaps Randy's terse statement about starting again with TLVs isn't
actually bad advice given that getting stuff from a repository isn't
actually a specific question/answer model.

Cheers
Terry

---

From: "t.petch" <[email-masked]>
Date: Fri, 22 Jul 2011 18:12:53 +0200

----- Original Message -----
From: "Terry Manderson" <[email-masked]>
To: "Andrew Chi" <[email-masked]>
Cc: "Rob Austein" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, July 22, 2011 4:16 AM

> an excel document without the extension.

Indeed; file extensions only work - and they have been working very well for a
long time - in and around PC systems because they are part of a belt and braces.
Almost all file formats also say what they are in the first line - GIF, jpeg,
PDF, Wordpro etc - so the file extension gets you to the application that can
then easily verify that what is has been passed is plausibly correct and not go
mad because eg Wordpro is trying to parse a PDF.

Given the distributed nature of the dynamic database that is RPKI, I would have
thought a self identifying first line would be essential.

Tom Petch

---

From: Stephen Kent <[email-masked]>
Date: Sat, 23 Jul 2011 09:22:40 -0400

>object there to confirm the ldap search returned all the roa objects.

LDAP would be terrible in this context. It is not well suited to
the "I want everything that has changed since this time" model of
repository access that RPs need here.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sat, 23 Jul 2011 09:37:17 -0400

>thought a self identifying first line would be essential.

Repository objects are not text files.  They are binary (CMS). Each 
object DOES begin with its context type (and OID).  So, in the binary 
space, we do just what you suggested. But, it is still very helpful 
to make use of filename extensions, e.g., to allow different types of 
RPs to filter what they retrieve.

Steve

---

From: "t.petch" <[email-masked]>
Date: Sat, 23 Jul 2011 21:02:53 +0200

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Terry Manderson" <[email-masked]>; "Rob Austein" <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Saturday, July 23, 2011 3:37 PM
> RPs to filter what they retrieve.

Yes, I am well familiar with OIDs and their encoding and assume that
Terry is as well, so I was endorsing what I take to be his disquiet about only
using file extensions before assuming that there is an OID there and
presenting it to the validation regime on the assumption that there is one
to decode.

Tom Petch

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 27 Jul 2011 18:54:07 +0100

Having reviewed the discussion on how to
proceed with this document, I believe that
there is a rough consensus to publish
draft-ietf-sidr-repos-struct as a Standards Track
document.

Please will the editor make the necessary changes.

Regards

Stewart