Subject: [sidr] Certificate policy -- new draft (version 12 or 13)

From: Karen Seo <[email-masked]>
Date: Sat, 2 Oct 2010 17:21:04 -0400

Folks,

Please note that draft 12 is the same as draft 13 except for the 
end-of-line characters. So you should compare 13 to 11 (or an earlier 
version depending on when you last reviewed the document.)

NOTE: Version 13 has end-of-line characters (linefeeds) that Rfcdiff 
will handle. However, as uploaded, versions 9, 10, 11, and 12 have 
carriage returns as their end-of-line characters and don't work with 
Rfcdiff. I believe that if you substitute LF for all the CRs, Rfcdiff 
will work with them. I'm told that downloading with IE automatically 
does the end-of-line changes. And Word let me select the end-of-line 
terminator when I used it to open and then save the files.

In addition to some clarifications, addition of references, and 
correction of typos and minor errors, the following revisions were 
made between draft 11 and 12/13 to address feedback from Tim Polk and 
Sean Turner.

Karen

1. Introduction

From: Note: This document is based on the template specified in the
    Internet Engineering Task Force (IETF) standards document RFC 3647.
    A number of sections contained in the template were omitted from
    this policy because they did not apply to this PKI. However, we have
    retained the section numbering scheme employed in the RFC to
    facilitate comparison with the outline in Section 6 of the RFC.

To:   Note: This document is based on the template specified in the
    Internet Engineering Task Force (IETF) standards document RFC 3647
    [RFC3647].  In the interest of keeping the document as short as
    reasonable, a number of sections contained in the template are
    omitted from this policy because they did not apply to this PKI.
    However, we have retained the section numbering scheme employed in
    the RFC to facilitate comparison with the outline in Section 6 of
    the RFC. Each of these omitted sections should be read as "No
    stipulation" in CP/CPS parlance.

1.2. Overview -- replaced 2nd paragraph with 2 paragraphs

From: This PKI parallels the existing INR distribution hierarchy. These
    resources are distributed by the Internet Assigned Numbers Authority
    (IANA) to the Regional Internet Registries. In some regions,
    National Internet Registries (NIRs) form a tier of the hierarchy
    below the RIRs for internet number resource (INR) distribution. ISPs
    and network subscribers form additional tiers below registries.

To:   The structure of the RPKI is modeled on the existing organizational
    structure that is already responsible for IP address and AS number
    resource allocation. In this allocation hierarchy, IANA allocates
    resources to five Regional Internet Registries (RIRs), each of which
    manages address and AS number allocation within a defined
    geopolitical region. The RIRs in turn allocate resources to Internet
    Service Providers, to subscribers with so-called provider-
    independent ("portable") allocations, and in some regions, to
    National Internet Registries (NIRs). (The term LIR is used in some
    regions to refer to what other regions define as an ISP. Throughout
    the rest of this document we will use the term ISP to simplify
    references to these entities.)

    As noted in the RPKI architecture document [ARCH], although IANA
    and/or the five RIRs are obvious candidates to be default TAs for
    the RPKI, each RP ultimately chooses the set of trust anchors it
    will use for certificate validation. For example, an RP (e.g., an
    LIR/ISP) could create a trust anchor to which all address space
    and/or all AS numbers are assigned, and for which the RP knows the
    corresponding private key. The RP could then issue certificates
    under this trust anchor to whatever entities in the PKI it wishes,
    with the result that the certification paths terminating at this
    locally-installed trust anchor will satisfy the RFC 3779 validation
    requirements.

1.4.1. Certification authorities -- 2nd paragraph

From: Organizations that do not distribute INRs, but hold such resources
    also act as CAs when they create EE certificates.

To:   Organizations that do not distribute INRs, but hold such resources
    also act as CAs when they create EE certificates. Subscribers with
    PI space are the principle examples of this class of CAs.

1.6.4. CP approval procedures

From: IESG MUST approve a replacement BCP, following the procedures of the
    IETF Standards Process as defined in RFC 2026.

To:   The IESG MUST approve a replacement BCP that either updates or
    obsoletes this BCP, following the procedures of the IETF Standards
    Process as defined in RFC 2026 [RFC2026].

1.7 Definitions and acronyms

Added:
        LIR -  In some regions, the term Local Internet Registry (LIR) is
     used to refer to what is called an ISP in other regions.

        Provider-independent (PI) address space - PI address space is
     allocated directly by an Internet Registry to a subscriber. This space
     cannot be further allocated by the subscriber to other entities. The
     subscriber must contract with an ISP to obtain routing of the address
     block within the Internet. PI space enables the subscriber to change
     service providers without renumbering its networks and to use multiple
     ISPs in a multi-homed configuration.

2.2 Publication of certification information

Added:
     Each CA MUST publish its CPS.

3.1.2 Need for names to be meaningful

From: The Subject name in each certificate MUST be unique relative to all
    Subject names certified by the same Issuer, but the name does not
    need to be meaningful. There is no requirement, and no guarantee,
    that subject names are globally unique in this PKI. The certificates
    issued under this PKI are used for authorization in support of
    applications that make use of attestations of Internet resource
    holding, 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".

To:   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".

3.1.5. Uniqueness of names

From: Each CA certifies Subject names that MUST be unique among the
    certificates that it issues. Although it is desirable that these
    Subject names be unique throughout the PKI, to facilitate
    certificate path discovery, such uniqueness is neither mandated nor
    enforced through technical means.

To:   There is no guarantee that subject names are globally unique in this
    PKI. Each CA certifies Subject names that MUST be unique among the
    certificates that it issues. Although it is desirable that these
    Subject names be unique throughout the PKI, name uniqueness within
    the RPKI cannot be guaranteed.

    However, Subject names in certificates SHOULD be constructed in a
    way that minimizes the chances that two entities in the RPKI will be
    assigned the same name.

3.1.6. Recognition, authentication, and role of trademarks

From: Because the Subject names are not intended to be meaningful, there
    is no provision to recognize or authenticate trademarks, service
    marks, etc.

To:   Since Subject names are not intended to be meaningful, there is no
    provision to recognize or authenticate trademarks, service marks,
    etc. 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.

4.2. Certificate application processing

From: CAs SHOULD make use of existing standards for certificate
    application processing.  Relevant standards include RFC 4210,
    Internet X.509 Public Key Infrastructure Certificate Management
    Protocol (CMP), RFC 2797, Certificate Management Messages over CMS,
    and RSA Labs standards PKCS #7 and PKCS #10. Each CA MUST define the
    certificate request/response standards that it employs, via its CPS.

To:   CAs SHOULD make use of existing standards for certificate
    application processing. Section 6 of the resource certificate
    profile [RFCyyyy] defines the standard certificate request formats
    that MUST be supported

    Each CA MUST define the certificate request/response standards that
    it employs, via its CPS.

4.5.2. Relying party public key and certificate usage -- last paragraph

From: If a relying party determines that use of the certificate is
    appropriate, the relying party must utilize appropriate software
    and/or hardware to perform digital signature verification as a
    condition of relying on the certificate. Moreover the relying party
    MUST validate the certificate in a manner consistent with the
    algorithms specified in RFC 5280 and RFC 3779.

To:   If a relying party determines that use of the certificate is
    appropriate, the relying party must utilize appropriate software
    and/or hardware to perform digital signature verification as a
    condition of relying on the certificate. Moreover the relying party
    MUST validate the certificate in a manner consistent with the RPKI
    certificate profile [RFCyyyy], which specifies the extended
    validation algorithm for RPKI certificates.

4.6 Certificate renewal

Added: This section describes the procedures for certificate renewal. 
Certificate renewal is the issuance of a new certificate to replace 
an old one prior to its expiration. Only the validity dates and the 
serial number are changed. The public key and all other information 
remain the same.

4.6.1. Circumstance for certificate renewal -- first paragraph.

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

Sections 4.X.4, 4.X.5, 4.X.6, 4.X.7

Made consistent with each other as follows:

4.6.4, 4.7.4, 4.8.4 Notification of new certificate issuance to subscriber
	No additional stipulations beyond those of section 4.3.2.

4.6.5, 4.7.5, 4.8.5 Conduct constituting acceptance of a [renewal, 
re-keyed, modified] certificate
	No additional stipulations beyond those of section 4.4.1.

4.6.6, 4.7.6, 4.8.6 Publication of the [renewal, rekeyed, modified] 
certificate by the CA
	No additional stipulations beyond those of section 4.4.2.

4.6.7, 4.7.7, 4.8.7 Notification of certificate issuance by the CA to 
other entities
	No additional stipulations beyond those of section 4.3.3.

4.7. Certificate re-key

Added: This section describes the procedures for certificate re-key. 
Certificate re-key is the issuance of a new certificate to replace an 
old one because the key needs to be replaced. Unlike with certificate 
renewal, the public key is changed.

4.7.1. Circumstance for certificate re-key -- 3rd paragraph

From: Note that if a certificate is revoked to replace the RFC 3779
    extensions, the replacement certificate MUST incorporate the same
    public key rather than a new key.

To:    Note that if a certificate is revoked to replace the RFC 3779
    extensions, the replacement certificate MUST incorporate the same
    public key rather than a new key.  This applies to when one is
    adding INRs (revocation not required) and to when one is removing
    INRs (revocation required (see Section 4.8.1).

4.9.3. Procedure for revocation request

From: A subscriber MAY submit a request to the certificate issuer for a
    revocation. A certificate issuer MUST notify the subscriber when
    revoking a certificate, however this notification requirement MAY be
    satisfied by publication of a CRL by the issuer. If means other than
    CRL publication are employed, the CPS for a CA MUST indicate by what
    means the CA will inform a subscriber of certificate revocation,

To:   A subscriber MAY submit a request to the certificate issuer for a
    revocation. This request MUST identify the certificate to be revoked
    and MUST be authenticated. The procedures for making the request
    MUST be described in the CPS for each CA. The RPKI provisioning
    document [PROV] describes a protocol that MAY be used to make
    revocation requests.

    A certificate issuer MUST notify the subscriber when revoking a
    certificate. The notification requirement is satisfied by CRL
    publication. The CPS for a CA MUST indicate the means by which the
    CA will inform a subscriber of certificate revocation.

4.10. Certificate status services

From: This PKI does not make provision for use of OCSP or SCVP, because it
    is anticipated that the primary relying parties (ISPs) will acquire
    and validate certificates for all participating resource holders on
    a daily basis. These protocols are not designed for such large-
    scale, bulk certificate status checking. Instead, retrieval of all
    changed or new certificates and CRLs on a daily basis is the
    anticipated mode of certificate status verification.

To:   This PKI does not make provision for use of OCSP or SCVP, because it
    is anticipated that the primary RPs (ISPs) will acquire and validate
    certificates for all participating resource holders. These protocols
    are not designed for such large-scale, bulk certificate status
    checking. RPs MUST check for new CRLs at least daily. It is
    RECOMMENDED that RPs perform this check several times per day, but
    no more than 8-12 times per day (to avoid excessive repository
    accesses).

5.1. Physical controls

Added:  Possible topics include:

      .  Site location and construction, such as the construction
         requirements for high-security zones and the use of locked
         rooms, cages, safes, and cabinets

      .  Physical access, i.e., mechanisms to control access from one
         area of the facility to another or access into high-security
         zones, such as locating CA operations in a secure computer room
         monitored by guards or security alarms and requiring movement
         from zone to zone to be accomplished using a token, biometric
         readers, and/or access control lists

      .  Power and air conditioning

      .  Water exposures

      .  Fire prevention and protection

      .  Media storage, for example, requiring the storage of backup
         media in a separate location that is physically secure and
         protected from fire and water damage

      .  Waste disposal

      .  Off-site backup

5.2. Procedural controls

Added:  Topics covered SHOULD include:

      .  Requirements for recognizing trusted roles

      .  Responsibilities for each role (Examples of trusted roles
         include system administrators, security officers, and system
         auditors.)

      .  For each task identified, the number of individuals required
         to perform the task (n out of m rule) for each role.

      .  Identification and authentication requirements for each role

      .  When role separation is employed and how it is effected (if
         employed)

5.4.1. Types of events recorded -- 2nd sentence

From:  Audit records SHOULD include the date, time, responsible user
    or process, and summary content data relating to the event. 

To:    Audit records MUST include the date, time, responsible user
    or process, and summary content data relating to the event. 

Also added the following auditable events:

   . Key generation

   . Software and/or configuration updates to the CA

   . Clock adjustments

5.8. CA or RA termination

From: In the RPKI, each subscriber acts as a CA authoritative for the
    specified INRs that were distributed to that entity. Procedures
    associated with the termination of a CA MUST be described in the CPS
    for that CA.

To:  In the RPKI, each subscriber acts as a CA authoritative for the
    specified INRs that were distributed to that entity. Procedures
    associated with the termination of a CA MUST be described in the CPS
    for that CA. These procedures MUST include a provision to notify
    each entity that issued a certificate to the organization that is
    operating the CA that is terminating.

    Since the RA function MUST be provided by the same entity operating
    as the CA (see Section 1.4.2), there are no separate stipulations
    for RAs.

6.1.1. Key pair generation

Added sentence in the middle of the paragraph:
    (The CA has to check the quality of the keys only if it generates
    them (see 6.1.6)).

6.1.6. Public key parameters generation and quality checking

From: The public key parameters used in the RPKI are specified in RFC ZZZZ
    [RFCzzzz]. Each subscriber is responsible for performing checks on
    the quality of its key pair. CAs are not responsible for performing
    such checks for subscribers.

To:   The public key parameters used in the RPKI are specified in RFC ZZZZ
    [RFCzzzz]. Each subscriber is responsible for performing checks on
    the quality of its key pair. A CA is not responsible for performing
    such checks for subscribers except in the case where the CA
    generates the key pair on behalf of the subscriber.

6.3.2. Certificate operational periods and key pair usage periods

From: The INRs held by RIRs and the NIRs periodically change because these
    registries receive new distributions. Therefore it is appropriate for
    their certificates to hae lifetimes that match the periodicity of these
    changes

To:   The INRs held by a CA may periodically change because it receives
    new distributions. Therefore it is appropriate for its certificate to
    hae a lifetime that matches the periodicity of these changes.

9.12.2. Notification mechanism and period

From: The IESG MUST provide at least a six month advance notice of a
    change to this CP.

To:   Successive versions of the CP will be published with the statement
    "This CP takes effect on MM/DD/YYYY." MM/DD/YYYY MUST be a minimum
    of 6 months from the date of publication.

10. Security Considerations

Added: Since name uniqueness within the RPKI cannot be guaranteed, there is
    a risk that two or more CAs in the RPKI will issue certificates and
    CRLs under the same Issuer name. Path validation implementations
    that conform to the resource certification path validation algorithm
    [see RFCyyyy] verify that the same key was used to sign both the
    target (the resource certificate) and the corresponding CRL. So a
    name collision will not change the result. Use of the basic X.509
    path validation algorithm, which assumes name uniqueness, could
    result in a revoked certificate being accepted as valid or a valid
    certificate being rejected as revoked. Relying parties must ensure
    that the software they use to validate certificates issued under
    this policy verifies that the same key was used to sign both the
    certificate and the corresponding CRL, as specified in [RFCyyyy].

13.1. Normative References

Added:

[RFC2026]   Bradner, S., "The Internet Standards Process - Revision 3,"
        BCP 9, RFC 2026, October 1996.

[RFC3779]   Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP
        Addresses and AS Identifiers," RFC 3779, June 2004.

13.2. Informative References

Added:

[PROV] Huston, G., Loomans, R., Ellacott, B., Austein, R., "A Protocol
        for Provisioning Resource Certificates," work in progress.

[RFC3647]   Chokhani, S., Ford, W., Sabett, R., Merrill, C., Wu, S.,
        "Internet X.509 Public Key Infrastructure Certificate Policy and
        Certification Practices Framework," RFC 3647, November 2003.

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Oct 2010 10:18:36 +0900

>     resources to five Regional Internet Registries (RIRs), each of

the iana has, and will continue to have, direct allocations to others
than the rirs

>     Process as defined in RFC 2026 [RFC2026].

the ietf must approve, by whatever means it currently uses as an
approval process.  do not forget 1992, and we seem to have bread
massively more process wonks.

>      cannot be further allocated by the subscriber to other entities.

i do not believe that last condition is firm, especially for legacy
space.  as a well-known example, 135.whatever was split when bell split.

>      The subscriber must contract with an ISP to obtain routing of the
>      address block within the Internet.

the holder of pi space may very well be an isp

>      Each CA MUST publish its CPS.

and up above, you say a ca is someone who makes an ee to sign a roa.
most of them just ain't gonna publish a cps.

and when an rir or large isp acts as a proxy privatekey/cert holder for
a customer and generates a roa for them (the current rir model), who
specifically is the ca that will publish their policy?

>     intended to be "meaningful".

i am confused on the status of this.  once upon a time it was must not
be meainingful.  then there was a move to make it meaningful for rirs
but no one else.  and now?  can uu issue child certs with customer
subnect names?  should they?

>     way that minimizes the chances that two entities in the RPKI will be

and how they heck will that be done?  and why?

>     infringes on the trademark of another individual or organization.

great!  and my sn generator should check the 200+ trademark databases of
the world to be sure blorzlpktz is not trademarked?  like hell.  how
about just the stuff from the beginning, do try not to generate
meaningful names, period.  taking a position on enforcing trademarks is
something we learned to stay many kms away from dns registries.

> renewal, the public key is changed.

s/with//

>     no more than 8-12 times per day (to avoid excessive repository

i am not sure i am comfortable with the timing here.  

first, does this cover where a local relying cache pulls and validates
from a 'parent' trusted cache (note these are not publication points)?

secondly, this places a lower bound on repairing a hijack or mistake.
while, admittedly, the 12 times a day might not be an even distribution,
it is sure to be interpreted that way.

but i am not sure i see a fix.

> 5.1. Physical controls

come on.  this is a bit of a pita for widget corp who has a cert for
their space and wants to issue a roa.  and i am not sure a ca with
security or privacy concerns is gonna want to say anything.

> Added:  Topics covered SHOULD include:

same issues as 5.1 for folk with security or privacy concerns.

> 5.4.1. Types of events recorded -- 2nd sentence

got a logging ntpd?

>     specified INRs that were distributed to that entity.

which answers my question above.  if i am a holder with a parent (isp or
ror) acting as my key/cert proxy, then i am still a ca.  i do not
disagree with this.  but note that puts all the cp obligations on
jillions of end holders.

randy

---

From: Sean Turner <[email-masked]>
Date: Sun, 03 Oct 2010 10:06:48 -0400

Randy,

Some thoughts below.

spt

> security or privacy concerns is gonna want to say anything.

The text I suggested adding is really about giving hints on what might 
be included that section.  Before it just said the CPS must say 
something about physical controls and didn't really give any hint 
about what kind of things might be there. Now it says "Possible topics 
include: ..."

There are many CAs that have privacy and security concerns that post CPSs:

http://www.verisign.com/repository/CPS/
http://www.identrust.com/certificates/index.html (there's 4 lists on 
the right)

I'm sure comodo also publishes their CPSs too.

> same issues as 5.1 for folk with security or privacy concerns.

See above.

>> 5.4.1. Types of events recorded -- 2nd sentence

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.

spt

---

From: Geoff Huston <[email-masked]>
Date: Mon, 4 Oct 2010 05:20:08 +1100

Here are my comments on the CP. I do not believe that this document is ready for the IESG at this stage.

>   locally-installed trust anchor will satisfy the RFC 3779 validation

there is much to be said for brevity and simplicity and the original section 1.2 had both - the expanded version of this description is not a good fit, and the introduction of the TA considerations into the CP does not appear to sit easily in the context of this document, in my opinion - I prefer the original words!

>   PI space are the principle examples of this class of CAs.

I'd drop this change - the distinction between PI space and otherwise is poorly made here. Again. I prefer the original words,

>    ISPs in a multi-homed configuration.

I'd drop reference to PI space altogether - again it sits uncomfortably in the context of the CP and the distinction is unclear here. 

section 2.3 

please change the formatting to make the list explicit (use bullets or similar?)

Also that is the purpose of "Also, please note" in para 3 - are the other sentences in this section not worthy of noting? :-)

This is still unclear for me.

The first sentence says that a subject "does not need to be meaningful". yet sentence 4 states that the name is "not intended to be meaningful". I'm no wiser whether meaningful subject names are permitted or not by this text.

>   infringes on the trademark of another individual or organization.

is that a "should" or a "SHOULD" in sentence 2?

Again my preference is for the original text - the revised text is an unrealistic imposition on the CA and is discordant with section 3.1.2

3.2.2: s/bedescribed/be described/

3.2.3: Could you explain the purpose of 3.2.3? It does not appear to be referenced elsewhere, nor is there any statement relating to the currency of such individuals so identified. It seems out of place to me and I would recommend dropping this section.

> 
> 
> 4.6 Certificate renewal
> 
> Added: This section describes the procedures for certificate renewal. Certificate renewal is the issuance of a new certificate to replace an old one prior to its expiration. Only the validity dates and the serial number are changed. The public key and all other information remain the same.
> 
> 

if the name of the renewed certificate at the repository publication point is the same as that of the previous certificate then this "overlap" recommendation is confusing. If this section is limited to referring to the valid times in the certificates, and that a renewed certificate SHOULD be issued prior to 24 hours before the validto time, then why not say so?

4.8.1. Circumstance for certificate modification

  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.

what if the subject wishes to change their SIA?

4.8.1 ..." 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."

but if the INR shrinks, then revocation of the previous cert IS required (section 4.9.1). I'm confused by what this says.

5.6 This certificate SHOULD have a validity period that is at
  least as long as that of any certificate being issued under that
  certificate.

I believe that this is not correct, and that certificate lifetimes reflect business relationships. It is admissible in the RPKI for a subordinate CA to issue a cert with valid to times in excess of the CA cert of the issuers.

>   hae a lifetime that matches the periodicity of these changes.

I would like to see the CP accommodate an operating practice where the issued certificate has a lifetime that reflects the nature of the business relationship between the INR distributor and the INR recipient.

Geoff

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Oct 2010 07:46:44 +0900

> I'd drop this change - the distinction between PI space and otherwise
> is poorly made here. Again. I prefer the original words,

the pa/pa distinction is irrelevant.  if i have pa space and want to
announce it bgp, the parent still has to cut a cert for me and i still
have to cut a roa.

> I would like to see the CP accommodate an operating practice where the
> issued certificate has a lifetime that reflects the nature of the
> business relationship between the INR distributor and the INR
> recipient.

i suggest not getting into business relationships.  surely we can deal
with expiry without crossing that line.

randy

---

From: Geoff Huston <[email-masked]>
Date: Mon, 4 Oct 2010 11:21:58 +1100

> announce it bgp, the parent still has to cut a cert for me and i still

agreed

> with expiry without crossing that line.

While it's a personal preference of mine, at the same time its not a strongly held personal conviction such that I'm prepared to advocate that this needs to be chiseled into a CP document. I can pass on this.

  Geoff

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Oct 2010 09:26:52 +0900

> While it's a personal preference of mine, at the same time its not a
> strongly held personal conviction such that I'm prepared to advocate
> that this needs to be chiseled into a CP document. I can pass on this.

if you did not get serious jet lag, perhaps you can whack me enough to
understand how to go down this path a very short way without entering a
deep swamp?

randy

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 05 Oct 2010 13:07:26 +0200

Thank you Karen for this work.

I have a question regarding 1.6.3., a section that was always confusing
to me.

It says:

> 1.6.3. Person determining CP suitability for the policy
> 
>    The IESG MUST judge consensus of the IETF community for changes to
>    this policy.

But from my reading of RFC3647 the suitability that is meant here is
"whether a CA should be allowed to operate within or interoperate with a
PKI". If that is indeed the case, I am not sure if the IESG plays any
role here.

If we look at the current INR distribution system, such determination is
done by a parent registry by establishing business relationships and
allocating resources downstream. Usually, there are certain checks and
conditions in place and checking for all the MUSTS in the CPS and
approving it might be included. That would be, IMO, the most natural way
of building a compliant RPKI.

However, I don't think we need this in the CP, at least not at this
stage of RPKI development. I'd recommend that we make 1.6.3. "not
applicable" and relax the requirements for the CPS, by removing all
"MUST"s that must be in there, including the requirement that each CA
MUST publish a CPS.

In general, I agree with most of the previous comments and think that
the CP itself won't make routing more secure. I'd prefer to have this
document as lightweight and simple as possible and hope it can be
published as an RFC before the RIRs start issuing production certificates.

Thanks,

Andrei

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 06 Oct 2010 15:59:29 -0400

I presented several examples of methods that CAs may use to create 
Subject names in a way that minimizes the chances that two entities will 
be assigned the same name in a previous email 
(http://www.ietf.org/mail-archive/web/sidr/current/msg01739.html).