How to encode a chain of certs?

[kwatsen]

The draft currently states that the owner-certificate is just a single certificate

      container owner-certificate {
        leaf certificate {
            "An X.509 v3 certificate structure as specified by RFC
             5280, Section 4 encoded using the ASN.1 distinguished
             encoding rules (DER), as specified in ITU-T X.690.";
        }
        leaf issuer-crl {
          type binary;
          description
            "An CRL structure as specified by RFC 5280, Section 5
             encoded using the ASN.1 distinguished encoding rules
             (DER), as specified in ITU-T X.690.";
        }
      }

But the owner certificate actually needs to be presented along with its chain of intermediate certificates leading up to the trust anchor certificate known the to manufacturer's devices. Here are some options:

1. use an ordered-by-user leaf-list of the X.509v3 structures encoded using DER
2. use a PEM file (string) that can encode multiple certificate
3. use a PKCS#12 structure from RFC 7292 to encode a bundle of certs?

Thoughts?

Notes:

• Option #1 is what we current use in system-keychain model, but I think that it’s clunky and should be replaced.
• OpenSSL can convert between #2 and #3 well enough.

Kent

FWIW, here's how the text might look like with a PKCS#12 structure:

        leaf certificate {
          type binary;
          mandatory true;
          description
            "A PFU PDU structure as specified by RFC 7292, Section 4 
             encoded using the ASN.1 distinguished encoding rules 
             (DER), as specified in ITU-T X.690.  This is structure
             encodes the owner ceritifcate and any intermediate 
             certificates leading up to the trust anchor certificate
             known to the manufacture's devices.  The owner certificate
             itself encodes a manufacturer-assigned value identifying
             the owner.  This identifier must match the owner 
             identifier encoded in the ownership voucher.";
          reference
            "RFC 7292:
               Personal Information Exchange Syntax v1.1.
             ITU-T X.690:
                Information technology – ASN.1 encoding rules:
                Specification of Basic Encoding Rules (BER),
                Canonical Encoding Rules (CER) and Distinguished
                Encoding Rules (DER).";
        }

[kwatsen]

From: "Ersue, Mehmet (Nokia - DE/Munich)" mehmet.ersue@nokia.com Date: Saturday, August 13, 2016 at 8:57 AM To: Kent Watsen kwatsen@juniper.net, "netconf@ietf.org" netconf@ietf.org Subject: RE: [Netconf] zerotouch/16: How to encode a chain of certs?

Dear All,   technical spoken I’m in favor of supporting all formats with a ‘format’ leaf.   @All: Please comment on the proposal from Kent below.   Mehmet   From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Saturday, August 13, 2016 1:00 AM To: netconf@ietf.org Subject: Re: [Netconf] zerotouch/16: How to encode a chain of certs?     This issue was discussed in Berlin, but no decision was reached.   Here are my current thoughts:  

1. use an ordered-by-user leaf-list of the X.509v3 structures encoded using DER         I don’t think this is a good solution.  In fact, this is the current solution in       the ietf-system-keychain module, for which there already is an open issue       to replace it with better solution.  The reason this approach isn’t a       good one is because tools generally use file formats that encode multiple       certs into a single file (e.g., a .pem or .p12 file) - that is, one blob (not many)    
2. concatenate multiple PEM together to encode a bundle of certs        Encoding a single certificate into a PEM encoding is defined in RFC 7468,      Section 8.    I am not able locate a reference concatenating multiple PEM      encodings into a single message/string.   Without a normative reference,      I’m hesitant to recommend going this route.    
3. use a PKCS#12 structure from RFC 7292 to encode a bundle of certs         PKCS#12 is a flexible format that can encode many objects, including       what is calls a “CertBag” (i.e. a bag of certificates) defined in Section       4.2.3.  OpenSSL can convert to and from a file containing multiple       PEMs and a PKCS#12 as follows:         #  cat rightful_owner/owner_cert.pem intermediate/ca_cert.pem > owner_bundle.pem       #  openssl pkcs12 -export -in owner_bundle.pem -nokeys -out owner_bundle.p12       #  openssl pkcs12 -in owner_bundle.p12 -nodes -out owner_bundle.pem.2      #  diff ownerbundle.pem  // there’s a small difference (comments only)    
4. use a degenerate PKCS #7 structure from RFC 2315 to encode a bundle of certs         While PKCS#7 is primarily used to encode signed data, there is a       degenerate form of it that has no signatures, which according to       Section 9 “provides a means for disseminating certificates”. OpenSSL       can convert to and from a file containing multiple PEMs and a       PKCS#7 as follows:         # cat rightful_owner/owner_cert.pem intermediate/ca_cert.pem > owner_bundle.pem       # openssl crl2pkcs7 -nocrl -certfile owner_bundle.pem -out owner_bundle.p7b       # openssl pkcs7 -print_certs -in owner_bundle.p7b -out owner_bundle.pem.2       # diff ownerbundle.pem  // there’s a small difference (comments only)    
5. use a ‘choice’ around all of the PEM and PKCS#7 and PKCS#12 formats           choice {           leaf certificate-pem {             type binary;           }           leaf certificate-pk7 {             type binary;           }           leaf certificate-p12 {             type binary;           }         }    
6. use a ‘format’ leaf to indicate if           container certificate {           leaf format {             type enumeration {               enum pem;               enum pk7;               enum p12;             }           }           leaf data {             type binary;           }         }       Recommendations:   - If we have to pick just one, I’d ask security experts to pick between     pk7 and p12.  Note: pk7 was a bit easier on the command line, in     that it didn’t prompt for password.  Also, pk7 round-tripping     stabilized faster.   - If we’re okay with devices having to support all formats, then I     think solution #6 is better than #5.     Does anyone else have any thoughts on this?   Kent  

[kwatsen]

[moving to edit state, following posted to list]

So both Mahesh and Mehmet (as contributors I believe) selected option #6.  No other responses were received.  Thus I will move forward with option #6.   Thanks, Kent

[kwatsen]

The PKCS#12 format is giving me trouble. I dumped its ASN.1 content to ensure I was documenting the structure correctly, only to discover that it was password-encrypted, even though I hit for the password (note: this is because it’s using a salt value). I spent over an hour looking for a way to remove the password completely, but to no avail. Unless anyone has an idea, I think we should give up on the pkcs#12 format.

So now it’s just PEM and PKCS#7, but between the two, PKCS#7 is by far the better choice. The idea of supporting more than one format was only really interesting when pkcs#12 was in the mix. Now I’m not sure if it’s worth it any more. So, should we stick with:

          +--ro certificate
              +--ro format    enumeration    <-- choices are “pem” and “pkcs7”
              +--ro data      binary                   <-- encoding depends on ‘format’ field

or

          +--ro certificate  binary                <-- hardcoded to pkcs#7

Mehmet/Mahesh, since you two selected option #6 (see below) before, I’m especially interested in your opinions.

Thanks, Kent