Subject: [Sidr] Minutes of the SIDR WG session at IETF 69

From: Geoff Huston <[email-masked]>
Date: Fri, 27 Jul 2007 06:20:05 +1000

As attached - in the absence of any comment these will be submitted to 
the proceedings

Thanks indeed Paul for taking the minutes

    Geoff & Sandy

SIDR WG
June 26, 2007, 9AM
Minutes by Paul Hoffman
(Read the slides for more depth)

Agenda was bashed

1. Action items left over from IETF68 SIDR WG meeting

  Steve Kent to consider CAs issuing overalpping certificated to
  different entities: considered

  Sandy Murphy to consider rsync as a registered URI Type: would
  ential direct or third party registration

  Paul Hoffman had the comment about being specific as to CPS text
  that should be changed. Noted that provided clear indication where
  text is to be provided.

  Joe Abley investigated RIPE database structure vs use in other RIRs
  (posted 20 Jan 2007)

  Paul: Question as to architecture as informational or standards
  track: no clear resolution so far.

  Steve Kent to add test for 4-byte ASN in ROA format. done.

  All: match of NLRI to ROA? done.

  All: Document use cases in architecutre draft.

2. CP/CPS update - Steve Kent presenting

    Changed in the draft:
        ERX: how it is represented
        Added discussion of manifests
        Added local cache maintenance for RPs
    Gave overview of the protocol
    Added:
        Subject name conventions
        Discussion of default trust anchors (IANA? RIRs?)
        ERX
            How RIRs deal with early registration
    Need to add discussion of how to match prefixes and ranges by algorithm
    Need to create a separate document on repository operations
    Added semantics and syntax for manifest
        Per-CA signed blob use to detect active attacks against the repository
    Local cache management for RPs
        Suggestions for how to manage
    Operations section
        Added discussion of when you don't need a cert
        Dealing with 4-byte ASs and 2-byte ASs
    Question about matching ROAs to BGP updates
    Maybe we need to break the one-to-one mapping between the ROA and signing certificate
    example case of a /19 announcement based on /20 prefixes with different validation paths
    revise the ROA spec  to allow ROAs to be signed by 2 or more EE certificates.
    Lots of people have read the draft

3. CP & CPS for RIRs & CPS for ISP - Steve Kent

    Removed references to certificate acceptance by Subject
        Certificates are being issued as a side-effect
        Subjects don't even ask for a particular name
        No commitment process
    CPSs are usually written from a template
    Suggestion to not take anything else
    Steve is concerned that not enough people are reading the CP
        Wants each RIR to review the document

4. Resource Certificate Profile - George Michaelson

    Humorous comment on bordellos and the meeting room
    Background overview
    Most important: do not give out more than you have authorization to give
    Lots of language cleanup in -07
    Suggestions for revision
        Remove SubjectAltName
        Require PKCS#10, allow CRMF for interactive
        Issuer determines the subject name
        Rsync is mandatory?
    Question about why Subject CommonName vs AltName
    Can the name be present but NULL?
        No; at least stick in maybe a hash of the public key
        Yes; it doesn't matter because the issued cert will have a unique name
    Made a bunch of normative changes (see the slides)
    Next steps
        One more round, then WG last call
    Not as many people have read this document as the architecture document

5. ROA Format - Matt Lepinski

    Overview of ROA design and use
    Changes since -00
        Now only include IP address prefixes, not ranges
        Added an "exact match" flag for how the owner can announce
        Described how a ROA is validated
    Open issues
        Need more detail about how to compare IP address ranges
        Maybe requiring exact match on prefixes is too restrictive
            Proposal to add a boolean flag for ExactMatch
            Discussion of use cases and needs for range matching for smaller ranges
            Discussion of pushing RPSL into a ROA
                Where do we stop? RPSL is very expressive
            Is this enough for the policies we want, or do we need more?
            Balance complication vs. expressiveness  
          General view that existing boolean allows for particular
          policies to be expressed by the set of enumerated of exact
          match permit ROAs, so that min/max prefix size constraint in
          the ROA is not required - the boolean flag is considered to
          be adequate here

6. Private Address Space - Sandy Murphy

 What should people do with RFC 1918 address space?
        1) Don't announce it at all
        2) Use a local trust anchor and SIDR

    For IPv6, the issues are similar but different due to unique local addresses (ULAs)
        IPv6 WG is discussing registering ULAs
        Maybe these will be chosen by RIRs

    Should we add this to the architecture draft?
    Do we want to wait for ULA to finish?
    Question about why this is even a question
    Should the architecture document even cover this?
    Maybe IANA needs to leave it as an unsigned delegation    Related question: does IANA sign 0/0 or not?
    More consideration needed on this topic

7. Open discussion

    Steve Kent suggested that there where three new drafts that might be written:
        Repository structure?
        Manifest?
        Up down protocol from the RIR?&nbsp;
        APNIC author group volunteered to edit the repository structure draft
        Manifest is already described in architecture document, and no clear support from the WG to
        work on this as a separate document
        Further consideration fo the UP/DOWN protocol as this is not necessarily part of the SIDR charter per se.
        
    Noted that DNSSEC has similar issue as 0/0
        Specify in your config file "Space X is covered by trust anchor A" and so on
        It's a pruned tree
        Good to be able to specify scoping in a standardized way

    Comparison of IANA assertions:
        1) Everything (and you know what are private), or:
        2) Public addresses only

        Note that the latter allows someone else to claim they are
        authoritative for some of the private space in local
        contexts. This may be a feature.

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jul 2007 16:03:30 -0400

Geoff & Sandy,

The meeting minutes labeled item #2 as "CP/CPS update" but it was 
really an update on the Architecture document.

I'd also like to add some additional comments to the discussion of 
local and reserved addresses and the representation of these address 
types in the PKI.

I have previously suggested that IANA issued certs for RFC 1918 
addresses.  If IANA has a cert with the 0/0 address space extension, 
certs for these 1918 address blocks will verify properly under the 
RFC 3779 rules. If IANA destroys/forgets the private keys for these 
certs, then nobody will be able to generate valid certs for them 
under the default set of trust anchors.

If an ISP or enterprise uses 1918 addresses, then it can configure a 
trust anchor for them and issue certs for these address blocks under 
that TA. Because the certs would be issued under that TA, standard 
cert chaining (based on Issuer/Subject name matching) will 
automatically cause these certs to be traced to that locally 
controlled TA. I believe the same analysis will apply to ULA address 
in IPv6 (in response to Sandy's question).

The bottom line is that use of locally-controlled TAs allows an ISP 
or enterprise to make use of RFC 1918 IPv4 and IPv6 ULA addresses in 
a way that is completely consistent with the proposed architecture, 
and with standard cert path discovery and validation mechanisms. Thus 
IANA can have a 0/0 address extension in its cert and can issue certs 
for the 1918 addresses to preclude accidental validation via the 
default TA set without impinging on the ability of nets to use local 
addresses.

Finally, If we choose to adopt IANA as the default TA for the PKI, it 
can have the 0/0 address space extension, to make its allocations to 
the RIRs consistent with the RFC 3779 path validation model. Of 
course this last topic is a separate decision form the others 
described above.

Steve