Subject: [media-types] request for review of application/tnauthlist media type

From: Sean Turner <[email-masked]>
Date: Thu, 16 Nov 2017 13:57:28 +0800

Hi!  This is a request for review of the media type registration found in https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/.  It is copied below for convenience:

  Type name: application
    Subtype name: tnauthlist
    Required parameters: None.
    Optional parameters: None.
    Encoding considerations: Binary.
    Security considerations:  See Section 12 of this specification.
    Interoperability considerations:
       The TN Authorization List inside this media type MUST be
       DER-encoded TNAuthorizationList.
    Published specification: This specification.
    Applications that use this media type:
    Additional information:
       Magic number(s): None
       File extension(s): None
       Macintosh File Type Code(s): None
    Person & email address to contact for further information:
       Jon Peterson <[email-masked]>
    Intended usage: COMMON
    Restrictions on usage: none
    Author: Sean Turner <[email-masked]>
    Change controller: The IESG <[email-masked]>

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 16 Nov 2017 14:09:13 +0800

A friendly modification:

> On Nov 16, 2017, at 13:57, Sean Turner <[email-masked]> wrote:
> 

     Issuers and relying parties of secure telephone identity certificates,
     to limit the subject’s authority to a particular telephone number or
     number range.

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 16 Nov 2017 16:44:55 +0900

Hello Sean,

>      Security considerations:  See Section 12 of this specification.

"this specification" works as long as it's in context. But the 
registration will be taken out of context, and you have to rewrite it so 
that it works even then.

I suggest something like "RFC XXXX", with some instructions to the RFC 
editor to replace XXXX with the number of the actual RFC once issued. 
Don't worry about RFC Editor <-> IANA coordination, that will work out, 
they are used to coordinate such stuff.

Regards,   Martin.

> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types
> .
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 16 Nov 2017 15:53:41 +0800

> On Nov 16, 2017, at 15:44, Martin J. Dürst <[email-masked]> wrote:
> 
> Hello Sean,
> 
> "this specification" works as long as it's in context. But the registration will be taken out of context, and you have to rewrite it so that it works even then.
> 
> I suggest something like "RFC XXXX", with some instructions to the RFC editor to replace XXXX with the number of the actual RFC once issued. Don't worry about RFC Editor <-> IANA coordination, that will work out, they are used to coordinate such stuff.

Roger I can do:

See Section 12 of [RFCTBD].

and then add:

[RFC editor’s instruction: Please replace RFCTBD with the RFC number when this document is published.]

spt

---

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

Comments of mine were originally posted on the STIR mailing list.

I believe that since that posting, the comments has been addressed. I am 
reposting an excerpt of my comments specific to the registration (but, 
as I pointed out, they have already been addressed on the STIR mailing 
list):

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 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