Subject: [stir] application/tnauthlist and TN Auth List comments

From: Sean Leonard <[email-masked]>
Date: Wed, 15 Nov 2017 13:07:14 +0800

Hello STIR world:

As a “media type guy” (whatever you called us…), I took some interest in Change #3 media type with respect to the slide deck slides-100-stir-draft-ietf-stir-certificates, aka draft-ietf-stir-certificates-14.

You should send it to media-types for a full review, but here are some comments/observations about the media type, as well as the underlying thing:

The registration looks acceptable. I do not see showstoppers. Personally I would like to see “Published Specification:” say Section(s) XXX of this specification, rather than the specification as a whole, since really only Sections 9 and 10 are relevant.

It’s not clear why you need it to be DER. What if it’s BER? Is that a fatal error if it’s BER but not DER? (Since DER is a subset of BER.)

According to RFC 6839 you MAY use a structured syntax suffix, namely +ber or +der. However, the use of +ber and +der are just MAYs and are not required. There are two reasons:
1) A lot of ASN.1 X.690 registrations predate RFC 6838/6839, so there was no structured syntax suffix at the time.
2) Section 2 of RFC 6839 says:

   At the same time, using the suffix allows receivers of the media
   types to do generic processing of the underlying representation in
   cases where

      they do not need to perform special handling of the particular
      semantics of the exact media type, and

      there is no special knowledge needed by such a generic processor
      in order to parse that underlying representation other than what
      would be needed to parse any example of that underlying
      representation.

For 99.9999% of ASN.1 / X.690 encoded material, a blob of data is useless without the complete ASN.1 module defining the data (due to contextual remapping, implicit vs. explicit tagging, etc.). Therefore +ber and +der are, to my mind, never really required.

Therefore, I find the media subtype name application/tnauthlist acceptable.

~~~~~~~~~~~~~~~

I am a bit late to the party (just joined this mailing list), so maybe these issues have been discussed already; nevertheless:

It appears that a TN Auth List appears in a subject’s certificate extensions to constrain the subject. (Therefore the issuing CA “imposes” the TN Auth List upon the subject.) Section 9. In that case, I believe that Subject Information Access is the appropriate extension to refer to these things by reference, not Authority Information Access (Section 10.1).

If you intend to constrain a CA certificate [why?], then that CA’s certificate should have a Subject Information Access item to constrain itself.

Section 10.1 says: “The document returned by dereferencing that URI will contain the complete TN Authorization List (see Section 9) for the certificate.” 

Okay, but what if there is both a certificate extension and an id-ad-stirTNList? Is that an error, or does one take precedence over the other?

What if there are multiple id-ad-stirTNList items? Is it a fallback mechanism, so if one server goes down, you go with a secondary server? Or, do you need to dereference all URIs/retrieve all items, and then take the union, or the intersection? Or is it a syntax error to have multiple id-ad-stirTNList items?

What if the end entity certificate (aka subject certificate) contains a TN auth list, whether by value or by reference, and a CA certificate also contains a TN auth list? Do they merge? Do you take the intersection, or the union? Do you ignore TN auth lists on CA certificates because TN auth lists are not designed to constrain CA certificates?

To my mind, it would seem very useful to be able to delegate a country code or area code, but *only* that country code or area code, to a subordinate CA. This suggests something that behaves similarly to RFC 5280 name constraints. Since I am new to the party, I don’t know how much you talked about using name constraints machinery to accomplish the same purposes.

If those things were considered and rejected, the TN Auth List sections ought to say something about that.

~~~~~~~~~~~

I noticed that application/tnauthlist is not a signed entity: it’s just SEQUENCE OF TNEntry. Okay, so that raises the interesting possibility that these things can be dynamically generated...even dynamically generated on a split-horizon basis (i.e., different lists for different IP addresses, or different times of day). Very interesting business implications.

Are you sure it is okay not to sign the thing? Is it intended to be a static artifact that is fixed at the time of certificate issuance, or not? If it is fixed, then a way to enforce the fixation (without requiring that it be digitally signed by the CA issuer, like a CRL) is to encode a hash of the DER-encoded TNAuthorizationList in the certificate in an appropriate way.

If it is intended not to be static all the time, then DER should definitely not be a requirement, because you may well want to stream these lists out of some dynamic database or whatever: DER would require much more memory usage to rearrange and count up the octets comprising the list. In that case, BER is better.

In either case, it could be a signed artifact, such as the way that RFC 5280 certificates and CRLs are signed (as an intrinsic part of the data item), or as a CMS SignedData PDU.

Regards,

Sean

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 Nov 2017 10:22:12 -0500

Sean and I talked a little bit about these in person so I’m just closing the loop with the mailing list.

> On Nov 15, 2017, at 13:07, Sean Leonard <[email-masked]> wrote:
> 
> Hello STIR world:
> 

Glad we got your thumbs up.  I sent the registration in for review (let me know if you saw it).  I already got a couple of editorial tweaks to the media-type registration that I can incorporate once IETF LC ends.

So this extension is admittedly a little weird in that the same extension is used to constrain both the CA and the EE.  So sure if we were being purists we’d have two one for the CA and one for the EE, but we didn’t.  We’ve been on this path for a bit and we’ve been through WGLC/IETFLC already so I’m not planning on making this change.

> Okay, but what if there is both a certificate extension and an id-ad-stirTNList? Is that an error, or does one take precedence over the other?

This is not specified, but I could see including both.  For some set of numbers they go in the TNAuthList extension and others go in the stirTNList AIA. Both mechanism constrain the TNs that the caller has been authorized for so I do not think that we need to say one takes precedence over the other.

> What if there are multiple id-ad-stirTNList items? Is it a fallback mechanism, so if one server goes down, you go with a secondary server? Or, do you need to dereference all URIs/retrieve all items…

I envision one, but I don’t think we should preclude more.  Remember this isn’t the only document that’s need to implement this and those other specifications may have something to say about this.

> What if the end entity certificate (aka subject certificate) contains a TN auth list, whether by value or by reference, and a CA certificate also contains a TN auth list? Do they merge? Do you take…

The EE is constrained by the CA as noted in s9: "In a CA certificate, the TN Authorization List limits the set of TNs for certification paths that include this certificate.
"
> If those things were considered and rejected, the TN Auth List sections ought to say something about that.

We did consider something like Name Constraints but as you know it’s implementation is, well, not uniformly implemented.  If we had a design considerations section, we could add something about all the choices that were considered and discarded, but we don’t so I won’t ;)  

So it could be a signed artifact, but if that’s needed then use the TNAuthList extension.  You are correct this AIA mechanism allows the list to change without changing the certificate - that was the point.  In thinking about the implementation details (that I do not think need to specified in this draft), I envision the Service Provider either directly controlling or contracting out where the AIA points so I’m not concerned about having it be a signed artifact (again using the TNAuthList allows that if desired).

spt

---

From: Sean Leonard <[email-masked]>
Date: Wed, 22 Nov 2017 03:02:34 -0800

On 11/21/2017 7:22 AM, Sean Turner wrote:
>> [...]

Okay. I am okay with/willing to let this go. I just want to reiterate or 
amplify my concern about BER vs. DER. Since application/tnauthlist does 
not contain signed content (presumably, one could negotiate for signed 
content, such as Accept: application/cms or application/pkcs7-mime), and 
since it may well be streamed out of a database, I think that BER is 
acceptable, and probably better for the media type definition. A point 
between Sean and I offline that was discussed was that if the data on 
the server served as application/tnauthlist is "always" in DER form, 
then it's easy to put it in a certificate (no reprocessing required, 
just blit the bytes). BUT: the certificate's existence always predates 
this dynamically served application/tnauthlist! So, that is a poor 
reason to keep it in DER form.

The other justification to my mind is because you want to hash the 
binary content of application/tnauthlist and get a consistent result. 
This is good for certificates, for example, because then they can be 
referred to by hash, so it makes sense for the certificate to always be 
serialized in DER. Basically I am not convinced that people really need 
to hash all of the bytes of an application/tnauthlist PDU for any real 
purpose.

Finally, if the media type is defined as in DER, it is reasonable for 
software on either end to reject the data if it is not in DER. (Compare 
with RFC 2585: application/pkix-cert is implicitly in DER, so some level 
of compliance/enforcement is warranted. But when it's not, that does not 
mean that an application needs to fail on such an input.) If you do not 
want the data to be rejected, it would be better to soften the media 
type registration to say that it should be, or is expected to be, in 
DER, but it does not have to be so a receiver needs to prepare for such 
a possibility.

Sean

---

From: Sean Turner <[email-masked]>
Date: Wed, 29 Nov 2017 10:18:26 -0500

> On Nov 22, 2017, at 06:02, Sean Leonard <[email-masked]> wrote:
> 
> Okay. I am okay with/willing to let this go. I just want to reiterate or amplify my concern about BER vs. DER. Since application/tnauthlist does not contain signed content (presumably, one could negotiate for signed content, such as Accept: application/cms or application/pkcs7-mime), and since it may well be streamed out of a database, I think that BER is acceptable, and probably better for the media type definition. A point between Sean and I offline that was discussed was that if the data on the server served as application/tnauthlist is "always" in DER form, then it's easy to put it in a certificate (no reprocessing required, just blit the bytes). BUT: the certificate's existence always predates this dynamically served application/tnauthlist! So, that is a poor reason to keep it in DER form.
> 
> The other justification to my mind is because you want to hash the binary content of application/tnauthlist and get a consistent result. This is good for certificates, for example, because then they can be referred to by hash, so it makes sense for the certificate to always be serialized in DER. Basically I am not convinced that people really need to hash all of the bytes of an application/tnauthlist PDU for any real purpose.
> 
> Finally, if the media type is defined as in DER, it is reasonable for software on either end to reject the data if it is not in DER. (Compare with RFC 2585: application/pkix-cert is implicitly in DER, so some level of compliance/enforcement is warranted. But when it's not, that does not mean that an application needs to fail on such an input.) If you do not want the data to be rejected, it would be better to soften the media type registration to say that it should be, or is expected to be, in DER, but it does not have to be so a receiver needs to prepare for such a possibility.

Sean,

Saying you’re letting it go and then reiterating/amplifying your “concern" is pretty much the opposite of letting it go :/  I suspect I won’t be able to convince you that DER is fine but here I go anyway:

RFC2585: Thanks for reminding me about RFC 2585 because I think you actually made part of my point for me.  First, I disagree with your assessment that the encoding is implicitly in DER.  What the RFC says is that "Each ".cer" file contains exactly one certificate, encoded in DER format” and that “Each ".crl” file contains exactly one CRL, encoded in DER format.”  Just because the word “MUST" doesn’t appear in those sentences doesn’t mean the encoding is implied - if there is but one way to do something there’s no reason to put a MUST it just is what it is.  If you’re saying that storing a DER encoded file and then re-encoding it using BER is what’s going on, I’d say you were from the 90s when DAP/LDAP messed up things up badly for certificate users by doing exactly that re-encoding.  Second, RFC5280 slams home the DER point in multiple places when referring to RFC2585 (s4.2.2.1, s4.2.2.2, s5.2.5., and s5.2.7, s5.2.5) by saying it’s a DER encoded certificate/CRL.

Dynamically served content: I was wondering if we have such a thing in the PKI space that is served via certificates? We sure do and it’s the CA’s CRL. Most enterprises have small CRLs, but some have huuuuge CRLs and they seem to cope with AIA-provided URIs to DER encodings just fine.

DER vs BER: Based on the actual ASN.1 we use in TNAuthorizationList (i.e., INTEGER, IA5String, SEQUENCE OF, and SEQUENCE), you’re not just arguing for indefinite length you’re also arguing for a multitude of ways to encode (and subsequently decode) IA5String; IA5String it’s a restricted character string.  Look at s8.21.6 of X.690, there’s but “3 of the (many) possible forms available as a sender's option” for a restricted character string. To take it to the extreme with a 15 digit phone number the string can be anywhere from 17 bytes long (DER) to 49 bytes long (constructor form, indefinite length with each character in it’s own octet string).  This reminds me of Shakespeare's Lear who said "O, that way madness lies; let me shun that; No more of that.”  So if maximum variability isn’t your cup of tea (note it certainly shouldn’t be if you’re the one getting billed for extra call set-up time required to support these options) and you want to just do indefinite length, then you’re arbitrarily picking constraints and should instead go with the constraint set used most - DER.

From a recovering ASN.1-fanboy, I fully understand your “concerns" but I think your blowing them a bit out of proportion.

spt