Subject: [sidr] responses to CP comments

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Oct 2010 18:20:38 -0400

Folks,

Based on feedback from Randy, Geoff and Andrei, plus comments from Sean,
we plan to make the following changes to the CP:

- 1.2: we will delete the 3rd paragraph, but keep the first, as it
parallels the Arch doc (as Sean noted).  Randy, can you elaborate on 
the nature of current IANA allocations made to non-RIRs? Legacy 
allocations are not addressed in this paragraph, just the current 
allocation system.

- 1.4.1: we will remove the reference to PI space here (i.e., delete 
the last sentence in the second paragraph).

- 1.6.3: we will delete this (equivalent to "not applicable") 
section, since 3647 really focuses on the suitability of a CPS 
relative to the policy expressed by a CP.

Andrei: I do not agree with your suggestion to remove the CPS MUSTs 
in the CP. The intent is to help ensure that each CA (as amended 
below, in 2.2) has a CPS, and that the CPS covers certain basic info. 
If each parent registry were to act as an approver for a subordinate 
CPS, this would not encourage RPKI-wide uniformity re CPS's.

- 1.7: we will remove the definition of PI space from this section.

- 2.2: it is the norm in a CP to require every CA covered by
the CP to publish a CPS. For orgs that avail themselves of managed CA 
services, that burden is accepted by the supplier of that service. 
However, we agree that a CA in the RPKI that does not issue 
certificates to other subscribers really need not have to publish a 
CPS (since it has no "subjects" outside of its own administrative 
domain).  So, how about the following change:

OLD :	Each CA MUST publish its CPS.

NEW:		Each CA that issues certificates to entities outside
of its administrative domain MUST create and publish a CPS that meets 
the requirements set forth in this CP. Publication
	means that the entities to which the CA issues certificates MUST
	be able to acquire a copy of the CPS, and MUST be able to
	ascertain when the CPS changes. (An organization that does not
	allocate or assign INRs need not create nor publish a CPS.)

- 3.1.2: I disagree with Randy's recollection of the history of this
requirement. First it was no meaningful names for any subject other than IANA
and the RIRs. Then, at Randy's request (a reasonable one :-)) it was 
changed to the current form, i.e., NO meaningful names for any 
subject. It's now uniform and egalitarian. If, in Randy's question, 
"uu" is uunet, then the answer is no, they ought not issue 
certificates with customer subject names.

	Geoff had a different concern here, i.e., that the text was 
not clear.  We propose the following change:

OLD:	The Subject name in each certificate does not need to be meaningful.
   	The certificates issued under this PKI are used for authorization in
   	support of applications that make use of attestations of Internet
   	resource holdings, not for identification. The PKI binds a public
   	key to sets of INRs. The name of the holder of the INR is not
  	intended to be "meaningful".

NEW:	The Subject name in each certificate SHOULD not be "meaningful", i.e.,
	the name is NOT intended to convey the identity of the Subject
	to relying parties. The rationale here is that certificates 
issued under
	this PKI are used for authorization in support of 
applications that make
	use of attestations of INRs. They are not used for to 
identify Subjects.

- 3.1.5: we will add a reference to the cert profile here. That doc 
includes an example of how to generate (meaningless) subject names in 
a way that minimizes the likelihood of collisions. I understand that 
this is what several instances of RIR software do anyway.

- 3.1.6: The new text re trademarks is typical for a CP, but it does 
seem a bit harsh.  The Subject name generation mechanisms described 
in the
revised cert profile doc makes it unlikely that one would generate a 
name that would conflict with a trademark, but nothing is impossible. 
How about the following:

OLD:	When generating subject names, CAs should use a mechanism that
   	is unlikely to result in Subject names that include trademarks,
   	service marks, etc. CAs MUST NOT knowingly issue a certificate with
   	a Subject name that a court of competent jurisdiction has determined
   	infringes on the trademark of another individual or organization.

NEW:	When generating subject names, CAs SHOULD use a mechanism (such as
	those described [cert-profile]) to minimize the likelihood that
	the subject name is a trademark, service mark, etc. There is no
	requirement that a CA perform a search to verify that a subject name
	generated in this fashion does not infringe on a trademark, service
	mark, etc.

	- 4.10: The intent of this paragraph is to establish a minimum
	interval for an RP to check the repository system (not a local
	copy thereof), and to recommend a max rate of checking.  The minimum
	interval is tied to the timing established in Geoff's key rollover
	document, the "staging period."  The max is also a suggestion from
	Geoff.  I'm open to a better wording here, but, like, you, I don't
	see a good fix.

	- 3.2.3: The purpose of this section is to require a CA to have a
means of identifying and authenticating a person who acts as a 
representative for the organization that is responsible for the INRs 
for which the RPKI cert is issued. This is a typical requirement for 
a CA, i.e., there needs to be someone at an organization who acts as 
the liaison to the CA. Geoff is right that there is no explicit 
mention of whether the liaison info is current. However, the final 
sentence establishes the standard for satisfying this requirement, 
i.e., whatever the organization operating the CA already does for INR 
relationships.

- 4.6.1: Geoff, by definition, certificate renewal does not entail a 
name change, so your first comment is not applicable. To clarify that 
we want the new certificate to be issued at least 24 hours before 
expiration of the old certificate, we propose the following change:

OLD: 	An overlap period of at least 24 hours is RECOMMENDED.

NEW:	It is RECOMMENDED that the renewed certificate be issued and
	published at least 24 hours prior to the expiration of the
	certificate that it replaces.

- 4.8.1: Here is our proposed text modification:

OLD:    Modification of a certificate occurs to implement changes to
	selected attribute values in a certificate. In the context of this
	PKI, the only changes that are accommodated by certificate
	modification are additions to the INR holdings described by the RFC
	3779 extension.

	When previously distributed INRs are removed from a certificate,
    	then the old certificate MUST be revoked and a new certificate MUST
    	be issued.

    	When a certificate modification is approved, a new certificate is
    	issued. The new certificate MUST contain the same public key and the
    	same expiration date as the original certificate, but with the
	incidental information corrected and/or the INRs expanded.
	Revocation of the previous certificate is not required.

NEW:    Modification of a certificate occurs to implement changes to
	selected attribute values in a certificate. In the context of the
	RPKI, the only changes that are accommodated by certificate
	modification are changes to the INR holdings described by the RFC
	3779 extension and changes to the SIA extension.

	When a certificate modification is approved, a new certificate is
	issued. If no INR holdings are removed from the certificate, the new
	certificate MUST contain the same public key and the same expiration
	date as the original certificate (but with the SIA extension and/or
	and/or the INR set expanded). In this case, revocation of the previous
	certificate is not required.

	When previously distributed INRs are removed from a certificate,
	then the old certificate MUST be revoked and a new certificate MUST
	be issued, reflecting the changed INR holdings. (The SIA extension
	also may be changed during this action, if requested.)

- 5.1: These are possible topics; their inclusion in a CPS is not 
mandated. Also, , I reworded 2.2 to make it clear that a 
non-registry/ISP need not publish a CPS, so the CPS mandates affect 
fewer folks.

- 5.2: How about the following rewording:

OLD:	Each CA MUST maintain procedural security controls that are
   	commensurate with those employed by the organization in the
   	management of INR distribution. The details for each CA MUST be
  	specified in its CPS. Topics covered SHOULD include:

NEW:	Each CA MUST maintain procedural security controls that are
   	commensurate with those employed by the organization in the
   	management of INR distribution. The procedural security controls
	employed for CA operation MUST be specified in its CPS. Possible
	topics to be covered in the CPS include:

- 5.4.1: I think Sean addressed Randy's question here.

- 5.6: I'll reference the key rollover document and delete the second 
sentence, I suggest the following text:

OLD:	When a CA wishes to change keys, it MUST acquire a new certificate
	containing its new public key, well in advance of the scheduled
    	change. This certificate SHOULD have a validity period that is at
    	least as long as that of any certificate being issued under that
    	certificate.

NEW:	When a CA wishes to change keys, it MUST acquire a new certificate
	containing its new public key. See [key-rollover] for a description
	of how key changeover is effected on the RPKI.

- 6.3.2: Randy and Geoff do not agree on whether/how to change this. 
I will delete the offending sentence, since it was not precise enough 
to be normative anyway. Also, the next sentence is not consistent 
with what we said in 4.8.1. I propose the following text for the 1st 
paragraph:

OLD:	The INRs held by a CA may periodically change because it receives
    	new distributions. Therefore it is appropriate for its certificate
   	to have a lifetime that matches the periodicity of these changes.
    	However, to minimize disruption, the key pairs SHOULD be maintained
    	across certificate changes (if no INRs are removed as a result of
    	the certificate change).

NEW:	The INRs held by a CA may periodically change when it receives
    	new distributions. To minimize disruption, the CA key MUST NOT
	change when INRs are added to it's certificate.

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Oct 2010 09:12:34 +0900

> Randy, can you elaborate on the nature of current IANA allocations
> made to non-RIRs? Legacy allocations are not addressed in this
> paragraph, just the current allocation system.

we're talking about certs.  iana will be issuing certs for those
allocations, whether legacy, strawberry, or cowboy junkies.

> The intent is to help ensure that each CA (as amended below, in 2.2)
> has a CPS

nice intent.  i am not sure it will be met and not sure it MUST be for
the internet to keep working.  maybe a SHOULD is more realistic.

> requirement. First it was no meaningful names for any subject other
> than IANA and the RIRs.

then you came in late.  the IANA/RIR was a wg proposal you made in san
fran, i think, about two years into this.

> NEW: The Subject name in each certificate SHOULD not be "meaningful",
> 	i.e., the name is NOT intended to convey the identity of the
> 	Subject to relying parties. The rationale here is that
> 	certificates issued under this PKI are used for authorization in
> 	support of applications that make use of attestations of
> 	INRs. They are not used for to identify Subjects.

wfm

> 	the subject name is a trademark, service mark, etc.

why not stick to has no meaning?  mentioning trade/service marks is an
unnecessary invitation to people we would rather not have to talk to
about this stuff.

> 	certificate that it replaces.

and hopefully considerably earlier.

if i am four down the chain, and someone a hop or two up has a cert soon
to expire, that 24 hour window is a great cause of unnecessary
adrenaline.  if you have a time there, i would prefer a week, especially
considering long processing cycles discussed by rirs.

> - 5.4.1: I think Sean addressed Randy's question here.

not to my satisfaction

> - 6.3.2: Randy and Geoff do not agree on whether/how to change this. 

hmmm, i honestly do not remember.  but i must be right because geoff is
more jet lagged.  :)

> 	change when INRs are added to it's certificate.

i do not have enough coffee (and it is dishwater here in the icnp conf
hotel) to think this through.  but isn't my parent the one who adds the
new resources to my cert?  so you are telling me that i need to
coordinate submitting a req to change my key with an unknown time when
my parent decides to give me resources?  as i said, need caffeine.

randy

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 08 Oct 2010 09:20:27 +0200

Steve,

Stephen Kent wrote on 7/10/10 12:20 AM:
[...]
> Andrei: I do not agree with your suggestion to remove the CPS MUSTs in
> the CP. The intent is to help ensure that each CA (as amended below, in
> 2.2) has a CPS, and that the CPS covers certain basic info. If each
> parent registry were to act as an approver for a subordinate CPS, this
> would not encourage RPKI-wide uniformity re CPS's.
> 
The third parties are machines in the PKI. No one will ever read a CPS,
not check if it is there (with an exception of RIRs and IANA, maybe).
The only way to make it less pro forma is to request the parent to sign
off on the compliance of the child CA (hence my comment re 1.6.3.). But,
IMO, this will be an overkill at this stage. I understand the intention,
but suggest relaxing it to at least SHOULD to make it more realistic.

Andrei

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Oct 2010 11:15:08 -0400

Randy,

Thanks for the quick feedback.  I'll reply on,y to what appear to be 

>allocations, whether legacy, strawberry, or cowboy junkies.

I don't mean to seem dense, but I still don't see a characterization here
that I could cite in  the CP.

>the internet to keep working.  maybe a SHOULD is more realistic.

We'll change this to a SHOULD, which also is consistent with Andrei's 
most recent message as well.

>unnecessary invitation to people we would rather not have to talk to

Sean asked us to add the trademark text, because it is common in CPs. 
I agree that it is inappropriate to impose a burden of this sort on 
the orgs that we are asking to act as CAs here. Not mentioning this 
issue does not provide "cover" for these orgs. Saying that a CA that 
employs the recommended name gen technique, or an analogous 
mechanism, gets a pass, may provide cover, so I think it is 
worthwhile.  But, if most WG members are more comfortable with 
deleting this, let us know, and we'll remove it.

>considering long processing cycles discussed by rirs.

At first I though this interacted with the key rollover doc, but this 
text talks about cert renewal, so we can make the recommended renewal 
interval "at least 1 week" instead of "at lest 24 hours."

>>  - 5.4.1: I think Sean addressed Randy's question here.

You asked about the requirement to audit clock adjustments, and 
mentioned ntpd. Sean said:

I don't think you have to go that far.  If you look in the logs of 
say a mac (because I've got one), you can see that I tweaked the time 
this morning:

Oct  3 09:49:54 computername SecurityAgent[2165]:
		 system.preferences|2010-10-03 09:49:54 -0400
Oct  3 08:50:48 computername SecurityAgent[2165]:
		 system.preferences|2010-10-03 09:50:48 -0400

That's pretty much what you need.

So, what would you like to see here re this topic? Are you saying 
that it's too hard to log clock adjustments on a machine acting as a 
CA, and that we should omit this item, or are you asking for more 
guidance re how to perform the logging?

>my parent decides to give me resources?  as i said, need caffeine.

Yes, it is your parent that inserts new INRs into your cert. This 
text says that when this operation is done, your key stays the same, 
so that all of the objects that you signed do NOT have to be 
re-signed. So, the effect is the opposite of what you are worried 
about, i.e., when your parent adds resources to your cert, you do not 
have to do anything, until you decide to issue ROAs (or subordinate 
CA certs) that make use of the newly added resources. Are we OK on 
this?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Oct 2010 11:19:14 -0400

>but suggest relaxing it to at least SHOULD to make it more realistic.

Andrei,

A CA is not a machine. A CA is an entity, usually an organizational 
entity, that uses people to execute procedures and uses a computer to 
perform algorithmic functions.  If a registry (at any tier) offers a 
managed CA service for folks to whom it has allocates resources, it 
is the registry that is acting as a CA in conjunction with the org 
that took advantage of the managed service offer. (pardon the overly 
long sentence.)

Noentheless, we'll change the text from MUST to SHOULD.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Sat, 9 Oct 2010 02:31:13 +1100

On 09/10/2010, at 2:15 AM, Stephen Kent wrote:
> Sean asked us to add the trademark text, because it is common in CPs. I agree that it is inappropriate to impose a burden of this sort on the orgs that we are asking to act as CAs here. Not mentioning this issue does not provide "cover" for these orgs. Saying that a CA that employs the recommended name gen technique, or an analogous mechanism, gets a pass, may provide cover, so I think it is worthwhile.  But, if most WG members are more comfortable with deleting this, let us know, and we'll remove it.
> 

I, for one, am more comfortable with deleting this.

thanks

  Geoff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Oct 2010 17:47:58 -0400

At 2:31 AM +1100 10/9/10, Geoff Huston wrote:
>...
>>  Sean asked us to add the trademark text, because it is common in 
>>CPs. I agree that it is inappropriate to impose a burden of this 
>>sort on the orgs that we are asking to act as CAs here. Not 
>>mentioning this issue does not provide "cover" for these orgs. 
>>Saying that a CA that employs the recommended name gen technique, 
>>or an analogous mechanism, gets a pass, may provide cover, so I 
>>think it is worthwhile.  But, if most WG members are more 
>>comfortable with deleting this, let us know, and we'll remove it.
>>
>

OK, by popular demand (since Randy and Geoff are unarguably popular) 
we'll remove the paragraph that talks about trademarks in names.

Steve

p.s. I reserve the right to say "I told you so" later :-).