Subject: [sidr] Question about manifest document

From: Geoff Huston <[email-masked]>
Date: Wed, 18 Nov 2009 11:39:17 +1100

WG co-chair hat OFF

This is a posting made in my role as a document co-author, and not as a co-chair of the WG

In reviewing the manifest document I notice that the document in its current version defines a manifest as an RPKI construct. I have two questions about  this:

1. Should the manifest document be constrained in this manner as being exclusively an RPKI construct, or should the reference to exclusive use by the RPKI be removed such that the manifest is defined in a manner that is agnostic to the context of the PKI in which the manifest may be used, so that any CA may use a manifest?

2. In the context of the RPKI should the manifest document used a SHOULD to specify that the resources in the RPKI EE certificate used to validate the manifest's signature be specified using the inherit bit setting of the RFC3779 extensions?

Do any of the document's co-authors, or any WG folk, have an opinion of either or both of these questions that they'd like to share?

thanks,

  Geoff

WG co-chair hat OFF

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 18 Nov 2009 12:26:08 +0100

Geoff Huston wrote:
> In reviewing the manifest document I notice that the document in its
> current version defines a manifest as an RPKI construct. I have two
> questions about  this:
> 
> 1. Should the manifest document be constrained in this manner as being
> exclusively an RPKI construct, or should the reference to exclusive use
> by the RPKI be removed such that the manifest is defined in a manner that
> is agnostic to the context of the PKI in which the manifest may be used,
> so that any CA may use a manifest?
> 
> 2. In the context of the RPKI should the manifest document used a SHOULD
> to specify that the resources in the RPKI EE certificate used to validate
> the manifest's signature be specified using the inherit bit setting of
> the RFC3779 extensions?
> 
> Do any of the document's co-authors, or any WG folk, have an opinion of
> either or both of these questions that they'd like to share?
> 
> thanks,
> 
> Geoff
> 
> WG co-chair hat OFF

I think there's a benefit of allowing this construct to be used in an RPKI 
related, but not strictly RPKI repository, or even in an RPKI unrelated 
context. So I'd be in favor of making it more generic (see 1), which also 
means relaxing the rules on the EE cert (see 2).

Robert

---

From: Robert Loomans <[email-masked]>
Date: Thu, 19 Nov 2009 09:19:13 +1000

Geoff Huston wrote:
> 2. In the context of the RPKI should the manifest document used a
> SHOULD to specify that the resources in the RPKI EE certificate used
> to validate the manifest's signature be specified using the inherit
> bit setting of the RFC3779 extensions?

I agree with this: A MUST would be too strong here; I believe that a
SHOULD is appropriate.

Rob

-- 
Robert Loomans                         email:       [email-masked]
Senior Software Engineer, APNIC        sip:    [email-masked]
http://www.apnic.net/                  phone:         +61 7 3858 3100

---

From: George Michaelson <[email-masked]>
Date: Thu, 19 Nov 2009 13:30:18 +1000

Not wanting to put words in his mouth, I believe Steve has said that the manifest, or something very similar in terms of a formally signed statement of what IS in a repository, as opposed to a CRL as a mechanism to deprecate what should NOT be in a repository, was a concept raised during early phases of X509 design, and dropped for various reasons. So, there is some sense that this is a general purpose, useful thing, and in that context, I am attracted to generalizing words around it in SIDR drafts, so that should it become more common in other PKI contexts, there is good support for it from tools.

Therefore, I think it would be best to remove strong normative requirements for RFC3779 extensions in EE certificates from the manifest, unless there is a clear reason relating to RPKI facing context, in which case it would be nice to find words which make it plain that an OID, or Version, or some other reference clarifies why the RPKI Manifest Certificate has mandatory elements which a more general manifest might not have.

Maybe a mechanism like tying the OID of the certificate used to an OID in the Manifest itself, so that its clear the certificates context defines why 3779 is relevant? Thats a reasonably low-level cost in ASN.1.

-George

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Nov 2009 16:51:45 -0500

At 11:39 AM +1100 11/18/09, Geoff Huston wrote:
>1. Should the manifest document be constrained in this manner as 
>being exclusively an RPKI construct, or should the reference to 
>exclusive use by the RPKI be removed such that the manifest is 
>defined in a manner that is agnostic to the context of the PKI in 
>which the manifest may be used, so that any CA may use a manifest?
>
>Do any of the document's co-authors, or any WG folk, have an opinion 
>of either or both of these questions that they'd like to share?
>
>thanks,
>
>   Geoff
>
>WG co-chair hat OFF

I agree that the manifest structure is more general than the RPKI context.

However, if we choose to make the manifest document generic, we 
probably need another document that profiles it for the RPKI.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Sat, 21 Nov 2009 11:18:17 +1100

On 21/11/2009, at 8:51 AM, Stephen Kent wrote:

> However, if we choose to make the manifest document generic, we probably need another document that profiles it for the RPKI.
> 
> Steve

WG co-chair hat OFF

This is a posting made in my role as a document co-author, and not as a co-chair of the WG.

Thanks for this comment Steve. I am happy to attempt to redraft the manifest as a more generic document that describes a manifest in terms of a list of published products of a CA, with a signature that is verified using an EE certificate that is a subordinate product of that CA.

At this stage I'm of the view that the only RPKI-specific profile would be to say that the RPKI EE cert SHOULD use the inherit bit in the RFC3779 extension, and this seeems such a small profile component that it could fit into the res-cert profile draft in its own section.

regards,

   Geoff

WG co-chair hat OFF

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 Nov 2009 09:41:15 +0900

> I agree that the manifest structure is more general than the RPKI

is that a problem for this wg?  i.e. should this, rather narrowly
focused wg, be doing this work.  we could miss a lot and step on others'
toes.

randy

---

From: Stephen Kent <[email-masked]>
Date: Sat, 21 Nov 2009 08:05:25 -0500

>focused wg, be doing this work.  we could miss a lot and step on others'

In principle I agree, but since the toes in question would be in PKIX, I
feel comfortable with a more generic version of manifests. Nonetheless,
if we pursue this path, I will bring the document to the attention of 
PKIX and ask that folks review it and comment during IETF LC.

Steve

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 Nov 2009 23:49:31 +0900

>> focused wg, be doing this work.  we could miss a lot and step on
>> others' toes.

let me be less subtle

it might be polite to run that plan by at least tim  and stefan

randy

---

From: Stephen Kent <[email-masked]>
Date: Sun, 22 Nov 2009 09:02:44 -0500

>it might be polite to run that plan by at least tim  and stefan

Thanks for the clarification.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 23 Nov 2009 09:28:20 +0100

Hi,

>> I agree that the manifest structure is more general than the RPKI context.

As one of the developers working on the RPKI solution at RIPE NCC I agree with this.

> At this stage I'm of the view that the only RPKI-specific profile would be to say that the RPKI EE cert SHOULD use the inherit bit in the RFC3779 extension, and this seeems such a small profile com…

I agree. In effect this would allow for a more generic use of the manifests without impacting the rpki structure that was envisioned.

As others suggested cooperation with the PKIX wg is probably advised. But since I have not (yet) been very actively involved in the IETF WGs and processes I will leave this discussion to the more experienced people among us.

Regards,

Tim

> regards,
> 
>   Geoff
> 
> WG co-chair hat OFF
> 
> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

Tim Bruijnzeels
Senior Software Developer
RIPE NCC

[email-masked]
+31 20 535 4309

---

From: Rob Austein <[email-masked]>
Date: Tue, 24 Nov 2009 15:31:06 -0500

Speaking as one of Geoff's co-authors, and with no intention of
offending anyone: I would be ok with minor changes to the current doc
that made it possible for others to reuse this work if they so desire,
but I am not all that thrilled by the idea of pushing this work into
the PKIX WG as a solution in search of additional problems, and I
don't want to do anything to the current spec that would complicate
RPKI use of it.

I think my last point (not wanting to complicate RPKI use) can be
addressed by nailing down the RPKI profile of the mechanism, if we go
that way.  I am more concerned with why we are attempting to
generalize this spec at this point in time: has anybody outside the
SIDR WG requested generalization?  Who's the customer here, and what
are the customer's requirements?

Bottom line: I don't want the SIDR work to get bogged down a
well-intentioned attempt to save some unspecified party from a problem
that party is not aware of having.  If there's some trivial change we
can make that costs us nothing and makes life easier for hypothetical
others fine, but not if it's going to slow us down.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Nov 2009 15:46:25 -0500

>don't want to do anything to the current spec that would complicate

I don't anticipate that we would move the doc to PKIX.  I have 
alerted my co-chair and the cognizant AD of this discussion, and am 
awaiting responses
from them.  I too do not want to delay this document in any 
significant fashion,
as a side-effect of making it more generic.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 24 Nov 2009 16:21:48 -0500 (Eastern Standard Time)

On Tue, 24 Nov 2009, Stephen Kent wrote:

> I don't anticipate that we would move the doc to PKIX.  I have alerted my 
> co-chair and the cognizant AD of this discussion, and am awaiting responses
> from them.  I too do not want to delay this document in any significant 
> fashion,

Is there any reason why a more general/generic document could not be 
produced later, with back references to the existing document as a 
profile?

That presumes of course that the generalization maintains backward 
compatibility to the existing document.

I also am reluctant to tread water waiting on this.

--Sandy

---

From: Terry Manderson <[email-masked]>
Date: Tue, 24 Nov 2009 16:29:34 -0800

> don't want to do anything to the current spec that would complicate

I'm in agreement with Rob on this. Best to not go looking for more problems
that the manifest _might_ fix in the future.

If such problems arise, then the PKIX chairs are clearly aware of this work
(noting Steve's response) and can advise accordingly.

Cheers
Terry

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 25 Nov 2009 09:55:39 +0100

Hi,

> that the manifest _might_ fix in the future.

To be specific I see a potential use of these manifests without the RFC3779 extension in the context of the compound trust anchor as described in the draft-ietf-sidr-ta. This would allow the 'eta' to publish a manifest for the rtacms object(s).

However, I received signals that having this manifest there in the first place may not be desirable and I do agree that delays to get this document finalised should be avoided.

Cheers,
Tim

Tim Bruijnzeels

[email-masked]
+31 20 535 4309

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Nov 2009 09:18:10 -0500

Sandy,

I have already back from my PKIX co-chair, who said:

>Steve,
>
>I assume this was addressed primarily to Tim, but for the record, I have no
>objections to this.
>
>/Stefan

So  I don't believe that we will incur any significant delays from 
PKIX (or the cognizant SEC AD) if we choose to publish a more generic 
version of the manifest doc.  That said, I am amenable to either 
approach to publication.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Nov 2009 09:18:10 -0500

At 4:21 PM -0500 11/24/09, Sandra Murphy wrote:
>>...

One might try to do that, although it would be procedurally "backwards" :-).

>compatibility to the existing document.

Profiles are more specific, so the more general manifest would be a superset
of the RPKI manifest. Not sure if that would qualify as "backwards 
compatible" or not.

steve

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 25 Nov 2009 10:31:30 -0500 (Eastern Standard Time)

On Wed, 25 Nov 2009, Stephen Kent wrote:

>> produced later, with back references to the existing document as a profile?
>

I recognize that.  Perhaps we are not so interested in procedural purity 
than in procedural progress.

> of the RPKI manifest. Not sure if that would qualify as "backwards 

I was projecting in the future that work on a more general manifest might 
end up not quite being a superset of the current manifest.  WG are so 
unpredictable.  Hence my statement that the development of the general 
manifest might not retain compatibility with the current document. 
Hypothesizing only.

--Sandy