Subject: Re: [sidr] WG LC on draft-ietf-sidr-rpki-manifests-02.txt

From: Rob Austein <[email-masked]>
Date: Tue, 02 Sep 2008 17:51:54 -0400

Just finished paper and red pencil WGLC review of rpki-manifests-02.
This may seem a little odd, given that I'm a co-author, but it's how I
usually review my own documents for WGLC anyway, and in this case the
responsible WG chair asked me to post my comments to the list rather
than just sending them to my co-authors.

I found one substantive issue: an incorrect (IMHO) requirement to use
one-off EE certs to sign manifests associated with CA certificates.
Allowing one-off EE certificates is fine, mandating them is wrong.
The manifest must be regenerated every time that something in the
collection changes, so if there are a lot of non-batched changes
within one manifest thisUpdate/nextUpdate cycle, requiring one-off EE
certificates requires listing a lot of old EE certificates in the CRL.
Given that the CA certificates do not cycle anywhere near that
quickly, this seems like an unreasonable requirement.

Rest of review is clarification, no major substantive issues unless
people get worked up about SHOULD vs MUST clarifications.

===

Section 2.1: First paragraph is confusing and flat wrong in a few
places.  I think this stems from attempting to talk about a "CA's"
publication point rather than a "CA certificate's" publication point.
Second paragraph has minor issues along the same lines.  Suggested
rewrite of the entire section:

   In the case of a CA certificate's manifest of its associated
   publication repository in the scope of the Resource Certificate PKI
   (RPKI), the manifest contains the current published certificates
   issued by this CA certificate, the most recent CRL associated with
   the CA certificate, and all objects that are signed using a
   "single-use" EE certificate issued by this CA certificate.

   In the case where an EE certificate has a defined publication
   repository, the EE certificate's manifest contains all published
   objects that have been signed by the EE certificate's key pair.

===

Section 2.2.1.3.2.1: Last sentence of first paragraph assumes one-off
EE cert and is wrong anyway.  Rewrite:

   Any revoked EE certificates used to sign previous manifests will be
   removed from the CRL upon expiration.

===

Section 2.2.1.3.2.1.4: Last sentence requires one-off EE certs.
Rewrite:

   In such a case, if one-off manifest EE certificates are being used,
   when the authority issues the new manifest, it MUST also issue a
   new CRL that includes the EE certificate corresponding to the old
   manifest.

===

Section 2.2.1.4: This could probably be relaxed slightly.  The MUST
requirement is there to ease validation of manifests for CA
certificates; it's not really necessary for manifest of EE
certificates, as the validator already has the EE certificate in hand
by the time it gets to the manifest in that case.  The requirement is
harmless in any case, so I'm ok with leaving this as it stands.

===

Section 3.1: This is is where my fundamental disagreement with the
one-off EE certificate requirement shows up.

Steps 1 and 2 should only require new keypair and EE certificate if
none already exists or if the CA has chosen to use one-off EE
certificates.  Rewrite:

   1.  If no keypair exists, or if using one-off manifest EE
       certificates, generate a key pair, then generate an EE
       certificate for this key pair to enable relying parties to
       verify the signature on the manifest.

Then renumber following steps, since I just collapsed two steps into
one (easier to read than spreading a conditional across two steps). 

Step 2 bullet list:

  First bullet requires an id-ad-signedobject SIA extension in the EE
  certificate.  This is harmless, and could conceivably be useful, but
  is not really required given that the EE certificate will be bundled
  into the CMS anyway.  I'm ok with leaving this as it stands, am just
  pointing it out in case it's an oversight from a previous edit.

  Second bullet mentions IP resources but omits ASN resources.  Both
  should be handled via RFC 3779 inheritance, so rewrite:

       *  This EE certificate SHOULD describe its RFC 3779 address and
          ASN resources using the "inherit" attribute rather than
          explicit description of a resource set.

  Third bullet once again pushes for one-off EE certificates.
  Rewrite:

       *  The validity times of the EE certificate SHOULD exactly match
          the thisUpdate and nextUpdate times of the manifest when
          using a one-off EE certificate.  The validity times of the
          EE certificate MUST encompass the interval from thisUpdate
          to nextUpdate in any case.

Step 6 assumes one-off EE certificates.  Rewrite:

   6.  If using one-off EE certificates, the private key associated
       with the EE certificate SHOULD now be destroyed.

You will no doubt have noted that I'm using the term "one-off" instead
of "single-use" here.  This is not an accident.  "Single-use" has
proven to be ambiguous, in that it could mean a certificate that's
used to sign multiple generations of a single object or a certificate
that's used to sign exactly one generation of that same object.   A
better term than either might be "throw-away certificate", but that
might be perceived as pejorative (which it's not, the technique is
clever when used appropriately).

For an example of the other meaning of "single-use" within this same
document, see the last paragraph of section 3.2.

===

Section 3.2, last paragraph.  Other sense of term "single-use", as
noted above.  In this case it appears to mean "an EE certificate that
has no id-ad-signedObjectRepository accessMethod in its SIA
extension" (ie, the first sentence is a tautology).  Rewrite:

   EE certificates that do not contain an id-ad-signedObjectRepository
   accessMethod in their SIA extensions do not have repository
   publication points.  The object signed by such an EE certificate is
   published in the repository publication point of the CA certificate
   that issued the EE certificate, and is listed in the corresponding
   manifest for this CA certificate.

More generally, at this point I consider all occurances of the term
"single use" (or variants such as "single-use") in this document to be
suspect; in each case I think it's clear from context which meaning
was intended, but given that the same term can be understood in either
of two very different ways, I think it's best to avoid it entirely.

===

Section 3.3:

Fourth bullet item is dead wrong.  Manifest scope is all objects
signed by a particular certificate, not all objects signed by a
particular authority.  A persistant name is indeed required, but it
certainly can derived in part from the public key value, and probably
should be to minimize the risk of manifest collision during key
rollover.  I'd just remove the fourth bullet item entirely.

Fifth bullet item: s/the old CA associated/the old CA certificate
associated/ (the distinction matters, particularly in this paragraph).

===

Section 4:  There are several occurance of a rather odd phrase:

   The issuer SHOULD honour these values in the issued certificate or
   MUST reject the Certificate Request.

I don't know what this means.  Either it's a SHOULD or it's a MUST,
can't have it both ways.  If there's something more subtle going on
here, somebody's going to have to explain it to me, preferably by
rephrasing all of the occurances of this incantation, because it's
totally opaque to me.

===

Section 6.2, last sentence: s/undetected deletions/undetected
deletions or replays/.

===

Section 6.3, second paragraph: s/valid manifest is also/valid manifest
covering the signed objects is also/.

===

Section 6.4: Interaction between manifests and CRLs is complex.  It's
discussed briefly in section 6.6, this section and 6.6 should
reference each other.

Section 6.4, last paragraph: this is not not necessarily publisher
error, the relying party's clock might be wrong.  Absent other data,
either explanation is plausible.

===

Section 6.6: I find the discussion of the interaction between manifest
and CRL here a bit disturbing for the case where the manifest is stale
and the CRL is current.  Everything this section says is correct, but
one could easily come away with the belief that it's better to believe
an old stale copy of the CRL than to believe the current CRL, just
because the (stale) manifest matches the (old, stale) CRL.  I don't
think we want to prefer stale CRLs over current ones when we have both
and both are valid, so there's some clarification needed here.

I haven't figured out yet whether this interaction is complicated
enough to merit its own subsection with inbound pointers from both
section 6.4 and section 6.6.

===

That's it.
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Fri, 19 Sep 2008 16:09:46 +1000

Hi Rob

wg chair hat off comments follow

> quickly, this seems like an unreasonable requirement.

I think this is a valid comment and we should alter the spec to allow  
this reuse of the EE cert in this fashion

As usual, though, this does raise another question: If, at all times,  
the EE cert is only used to sign the "current" manifest, then does the  
EE cert require its own SIA and publication area? My inclination is to  
say that any point in time it looks like a single use EE cert, its  
just that you MAY keep the private key on hand, and MAY reuse the cert  
to sign a sequence of manifests..

Is this consistent with your view?

>   objects that have been signed by the EE certificate's key pair.

Now i'm in a terminology soup too.

I thought that it was appropriate to talk about a CA, where CA stands  
for "Certification Authority", which is an entity that issues digital  
certificates for use by other parties, so it was appropriate to talk  
about a CA's manifest, CRLs issued by a CA and certificates issued by  
a CA,

You are proposing to use the term "CA certificate" instead.

Now for me the "CA certificate" is not the active entity, its the "CA".

I looked arounf in RFC5280 and did not find any use of "CA  
certificate" and heading off into wiki-land also found use of the term  
"CA", but not "CA Certificate" as an activity entity.

So I'll hold off on this and see if others could offer views on what  
is usual here in terms of accepted terminology.

>   removed from the CRL upon expiration.

yep, agreed

> -===

yep, agreed

> harmless in any case, so I'm ok with leaving this as it stands.

this was a topic of a discussion some time back and the MUST was a  
result of that conversation. Its not necessarily the case that the  
validator has the EE certificate in hand - the CA MAY elect not to  
publish the EE certificate separately and publish it ONLY in the form  
of including it in the CMS wrapper of the manifest. So I thought that  
the outcome was that the EE cert MUSt be in the CMS wrapper of the  
manifest and MAY be separately published in a repository publication  
point.

So I propose to leave this as it stands, which I assume from your  
comment above is still ok with you.

> one (easier to read than spreading a conditional across two steps).

agreed

>  pointing it out in case it's an oversight from a previous edit.

this is not so straightforward, as it now impacts on the res-cert  
draft, section 3.9.7

Assuming that a sequence of manifests issued by a CA (and a CA has a  
single key value) has a single publication point object name then the  
id-as-signedobject SIA points to this object and all works fine. But  
this assumption is a stipulation in the third bukket point of section  
3.3, so I guess that this  is a long winded way of saying that even  
with an EE certificate being used to sign multiple manifests in  
sequence the id-ad-signedobject text is stillvalid and I propose to  
leave that part of the text as it stands.

Again, I assume from your comment above that this is ok with you.

>          explicit description of a resource set.

agreed

>          to nextUpdate in any case.

agreed

>       with the EE certificate SHOULD now be destroyed.

agreed

> clever when used appropriately).

again I agree that this concept, that a certificate is in use once at  
any time, but is used multiple times in series is indeed ambigiuous  
with the term "single use"

I too would be loathe to use "throwaway" certificate, and I would liek  
to keep the term "single use" in a fashion that is consistent with res- 
certs, but I will think about this some more and see if there is some  
text at the start of the manifest draft that could draw the  
distinction between "single-use, used once only", and "single-use, but  
could be reused multiple times" EE certificates

> document, see the last paragraph of section 3.2.

and that last paragraph actually holds in both these cases for manifests

> of two very different ways, I think it's best to avoid it entirely.

again, I agree, and it needs more thought as to getting the words  
clear - I think we both agree what's going on here.

> rollover.  I'd just remove the fourth bullet item entirely.

yes - with the definition of a CA as one that is boiund to a single  
key pair this is dead wrong.

so I agree

> associated/ (the distinction matters, particularly in this paragraph).

well I'm still having trouble with this one, terminology-wise!

> rephrasing all of the occurances of this incantation, because it's

ok - the ISSUER MUST honor the values in the issued certificate says  
that the issuer has no choice but to honor them. = i.e. the issuer  
cannot reject the request if the MUST truly is a MUST. The proposed  
wording says - either issue the certificate as requested (SHOULD  
honor) OR reject (MUSt reject). No other option is possible

So I would say that SHOULD honour or MUST reject is appropriate. But I  
would be interested to hear your suggestion of alternate wording that  
conveys the same intent more clearly.

> Section 6.2, last sentence: s/undetected deletions/undetected

agreed

> covering the signed objects is also/.

agreed

> discussed briefly in section 6.6, this section and 6.6 should

good point - agreed

> either explanation is plausible.

agreed

> and both are valid, so there's some clarification needed here.

Does the "this is a matter of local policy" apply in such cases?

> section 6.4 and section 6.6.

I'm not sure either, and I'll think about this some more

> That's it.

wow - excellent - many thanks!

Geoff

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 19 Sep 2008 10:48:24 -0400

Geoff,

Here are the definitions from X.509:

X.509, Clause 3.3 (Definitions):

      certification authority (CA): An authority trusted by one or more 
users to
      create and assign public-key certificates. Optionally the 
certification
      authority may create the users' keys.

      authority: An entity, responsible for the issuance of 
certificates. Two types
      are defined in this Specification; certification authority which 
issues public-key
      certificates and attribute authority which issues attribute 
certificates.

      CA-certificate: A certificate for one CA issued by another CA.

X.509, Clause 7 (Public-keys and public-key certificates):

      An end-entity certificate is a certificate issued by a CA to a 
subject that is
      not an issuer of other public-key certificates.

      A CA-certificate is a certificate issued by a CA to a subject that 
is itself a
      CA and therefore is capable of issuing public-key certificates. 
CA-certificates
      can be themselves categorized by the following types: [ ... 
self-issued certificate,
      self-signed certificate, cross-certificate].

Dave

---

From: Geoff Huston <[email-masked]>
Date: Sat, 20 Sep 2008 06:56:41 +1000

(wg chair hat somewhere in the corner, and nowhere near my head)

Many thanks for this clarification David.

I think in the context of use here, where the text refers to an "an  
entity, responsible for the issuance of certificates" and in  
particular a CA, meaning an "an entity, responsible for the issuance  
of certificates" "trusted by one or more users to create and assign  
public-key certificates" then the term "CA", standing for  
"certification authority" is precisely the correct term to use.

Rob, are you ok with this now?

   Geoff

On 20/09/2008, at 12:48 AM, David A. Cooper wrote:

>     certification authority (CA): An authority trusted by one or  
> more users to
>     A CA-certificate is a certificate issued by a CA to a subject  
> that is itself a
>     can be themselves categorized by the following types: [ ... self- 
> issued certificate,
>> I thought that it was appropriate to talk about a CA, where CA  
>> stands  for "Certification Authority", which is an entity that  
>> issues digital  certificates for use by other parties, so it was  
>> appropriate to talk  about a CA's manifest, CRLs issued by a CA and  
>> certificates issued by  a CA,
>>
>> certificate" and heading off into wiki-land also found use of the  
>> term  "CA", but not "CA Certificate" as an activity entity.
>>
>> So I'll hold off on this and see if others could offer views on  
>> what  is usual here in terms of accepted terminology.
>>

---

From: Rob Austein <[email-masked]>
Date: Fri, 19 Sep 2008 18:51:49 -0400

At Fri, 19 Sep 2008 16:09:46 +1000, Geoff Huston wrote:
> EE cert require its own SIA and publication area?

No.

> My inclination is to say that any point in time it looks like a
> single use EE cert, its just that you MAY keep the private key on
> hand, and MAY reuse the cert to sign a sequence of manifests..
> 

Except for my continued confusion about the overloaded term "single
use", yes. :)

> Now for me the "CA certificate" is not the active entity, its the "CA".

The problem is that the manifest is a not a listing of the active
entity's outputs, it's a listing of the outputs issued by a particular
CA certificate.  Now that David has finished beating us up about the
term "rollover", the mapping from CA to CA certificate is 1:1, just to
further confuse matters, and we lack a good term for the entity that
controls a publication point and maps 1:1 with the publication point.

There's a subtlety here that may not be obvious (thanks to Sandy for
asking about it): the publication point, in the sense of a filesystem
directory, is common to all current CA certificates in use by this
nameless entity that we used to call a CA.  Normally that's exactly
one CA certificate, except during rollover, when both the old and new
CA certificates are valid; now that David has whacked us with proper
PKI terminology, the process that we call rollover is really a process
of generating a new CA and reissuing all of the old CA's products
under the new CA.

The manifest, however, is specific to a particular CA certificate.
This means that during rollover the manifest will not cover the entire
content of the directory; instead, there will be two certificates,
each with its own manifest, and the two manifests between them will
cover the content of the directory.  As the unnamed entity reissues
subordinate objects under the new CA certificate, subordinate objects
will move from the old CA certificate's mannifest to the new CA
certificate's manifest, until the only thing left in the old CA
certificate's manifest is the old CA certificate's CRL.  In the
fullness of time, the old CA certificate, its manifest, and its CRL
all go away, the rollover event completes, and we're back to a single
manifest that covers the entire directory.

This model in which the directory is shared but the manifest is not
may seem complicated, but it turns out to be straightforward to
implement, and is necessary to keep the URIs in the SIA and AIA
extensions stable in a hierarchical repository layout

So the mapping from publication point to manifest is not 1:1, but
everything in a publication point is covered by a manifest.

In post-David terminology, the publication point is shared by the old
CA and its successor (thus, necessarily by their respective CA
certificates); the manifests are per-CA (thus, necessarily by their
respective CA certificates).  This should be the only case of shared
publication points: an old CA and its successor(s), all of which are
under the control of the unnamed entity that we used to call a CA.
It's really the same thing we've been doing all along, with the
terminology tweaked.

I dunno if this puts us on the same page, but perhaps it helps to
clarify the source of our confusion.

Part of the reason why I prefer to phrase things in terms of "CA
certificates" instead of "CAs" wherever possible is that a "CA
certificate" is a small concrete object, while a "CA" is a complex
entity with many moving parts and somewhat fuzzy around the edges.

> manifest and MAY be separately published in a repository publication  

I completely agree with the above for the case of a CA certificate's
manifest, but this section was talking about EE certificates that sign
multiple objects, including manifests.  I'm having a hard time
picturing not having the EE certificate in hand in such a case, but
then we don't currently have anything that uses this particular
capability so it hasn't yet passed the running code test.

> comment above is still ok with you.

Yep.

> Again, I assume from your comment above that this is ok with you.

Yep.

> could be reused multiple times" EE certificates

If you think you can salvage the term, go for it.  I doubt it can be
done, since the term has two different meanings, each of which is
self-evident to the reader, depending on context and the reader's
preconceptions.  That can be fun when writing poetry but is usually a
bad sign in technical writing.

> well I'm still having trouble with this one, terminology-wise!

Substance covered above, I hope.

Terminology usage details will require another review pass now that
David has made us change terminology (not a complaint, just an
observation).

> conveys the same intent more clearly.

Ok, I think I see what you're trying to say.  Try:

  The issuer MUST either honor these values in the issued certificate
  or reject the request entirely.

If that's too terse, try:

  The issuer MUST either honor these values in the issued certificate
  or reject the request entirely; the issuer MUST NOT issue a
  certificate that does not honor these values.

I prefer the first of these, but either would be ok.

I don't think the SHOULD is really necessary at all, since it's really
just saying that the issuer SHOULD issue certificates when it can.

> Does the "this is a matter of local policy" apply in such cases?

Sounds right.  It's a tradeoff between currency and consistancy.
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr