Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Benjamin Kaduk <> Sat, 07 September 2019 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DA9D120E13; Fri, 6 Sep 2019 17:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vcnt0MtXxnpl; Fri, 6 Sep 2019 17:29:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 886F7120B4E; Fri, 6 Sep 2019 17:29:26 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x870TH6o031677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Sep 2019 20:29:20 -0400
Date: Fri, 6 Sep 2019 19:29:17 -0500
From: Benjamin Kaduk <>
Cc: Jim Schaad <>,,
Message-ID: <>
References: <> <027701d55ebf$994184b0$cbc48e10$> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Sep 2019 00:29:29 -0000

On Tue, Sep 03, 2019 at 02:18:22PM +0200, Peter van der Stok wrote:
>    [RFC7030] recommends the use of additional encryption of the returned
>    private key.  For the context of this specification, clients and
>    servers that choose to support server-side key generation MUST
>    support unprotected (PKCS#8) private keys (Content-Format 284).
>    Symmetric or asymmetric encryption of the private key (CMS
>    EnvelopedData, Content-Format 280) SHOULD be supported for
>    deployments where end-to-end encryption needs to be provided between
>    the client and a server.  Such cases could include architectures
>    where an entity between the client and the CA terminates the DTLS
>    connection (Registrar in Figure 4).
> This carefully says nothing about recommendations for use, only for
> software support.  Are we letting 7030's recommendation for use of
> encryption stand?  It's probably worth being explicit, either way. 
> <pvds> I did not find any recommendation for use in RFC7030 apart the
> responsibility of the server for generating random numbers. The
> recommendations at the top of section 5.8 of the draft seem adequate in
> my opinion. The alternative is classifying the applications; unless you
> see a better way to do this. 

I think the 7030 text I was thinking of is this:

   It is strongly RECOMMENDED that the clients request that the returned
   private key be afforded the additional security of the Cryptographic
   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
   security to protect against unauthorized disclosure.

> </pvds>
>    It is recommended, based on experiments, to follow the default CoAP
>    configuration parameters ([RFC7252]).  However, depending on the
>    implementation scenario, retransmissions and timeouts can also occur
>    on other networking layers, governed by other configuration
>    parameters.  A change in a server parameter MUST ensure the adjusted
>    value is also available to all the endpoints with which these
>    adjusted values are to be used to communicate.
> I don't understand who this is a normative requirement upon.  Is it the
> network operator's, to propagate configuration changes?  Or is there
> supposed to be some automated protocol that makes adjusted values
> available? 
> <pvds> 
> It is meant as reminder to anyone doing the configuration of a given
> installation; you want to suppress the text? 

I don't want to suppress it, no.

Maybe "A configuration change in a server parameter MUST be coordinated
with all the endpoints with which these adjusted values are to be used to
communicate"?  Though I guess "coordinate" does not necessarily force the
other endpoint to be using the identical value, just to know about it.

> </pvds>
> Appendix A.1
>      Option (Uri-Port)
>         Option Delta = 0x4  (option# 3+4=7)
>         Option Length = 0x4
>         Option Value = 9085
>       Option (Uri-Path)
>         Option Delta = 0x4   (option# 7+4=11)
>         Option Length = 0x5
>         Option Value = "est"
> This is more for my own edification than the document's sake, so thank
> you for your time, but what accounts for the "extra" length here?  The
> "est" is three bytes, and what makes up for the other two?  Also, I
> assume that the port value of 9805 is the decimal value, which gets
> CBOR encoded into two bytes  of integer encoding plus the byte with
> additional information 25 to indicate the two-byte integer, and another
> byte that I need help accounting for. 
> <pvds> 
> Many thanks; an old misreading of an example in 7252. 
> For the option length of URI-Path we included the quotations as well;
> That is WRONG. 
> Repaired it everywhere. 
> Options are not CBOR encoded. 

Well, now I'm glad I asked -- thanks!

> </pvds>
> Appendix A.2
> Do we want to say anything about the IDevID in the CSR/cert?
> I note that the breakdown in Appendix C.2 (looks like openssl output)
> does not decode the otherName (though asn1parse can be convinced to do
> so). 
> <pvds> 
> What do you suggest for IDevID? 

If we were going to add something (which remains unclear to me), it could
be after the sentence "[...] the CSR contains a ChallengePassword which is
used for POP linking (Section 4).", and be something like "This CSR also
contains an RFC 7299 id-on-hardwareModuleName hardware identifier to
customize the returned certificate to the requesting device."
(The actual identifier here is the same one mentioned in, from Bob
Moskowitz's OID arc.)

> Actually openssl was used extensively for generating the examples. 
> Will be happy to learn about otherName 

otherName is an OID-indexed generic name container for the cert; it's a
form of subjectAltName.  What I did here was:

~$ unhex|openssl asn1parse -inform der
    0:d=0  hl=4 l= 395 cons: SEQUENCE          
  271:d=7  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative
  276:d=7  hl=2 l=  35 prim: OCTET STRING      [HEX
  313:d=1  hl=2 l=  10 cons: SEQUENCE          
  315:d=2  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
  325:d=1  hl=2 l=  72 prim: BIT STRING        

to note that there's a SAN that's not decoded automatically, and then

~$ unhex|openssl asn1parse -inform der -strparse 276
    0:d=0  hl=2 l=  33 cons: SEQUENCE          
    2:d=1  hl=2 l=  31 cons: cont [ 0 ]        
    4:d=2  hl=2 l=   8 prim: OBJECT            :
   14:d=2  hl=2 l=  19 cons: cont [ 0 ]        
   16:d=3  hl=2 l=  17 cons: SEQUENCE          
   18:d=4  hl=2 l=   9 prim: OBJECT            :
   29:d=4  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:01020304

to look at the contents. (with the symbolic name in my
suggested text) is the type of the otherName, here.

I'm pretty sure there's not a more-"automatic" way to get openssl to peek
inside otherName.

> </pvds>
> Section A.4
> I'm not sure how useful repeating the RFC 7030 csrattrs is: do we expect
> (e.g.) brainpoolP384r1 to be relevant for our readers? 
> <pvds> 
> It was added for completeness sake; nothing more. 
> Suppressing it may provoke other questions like: Why is it not there? 


> </pvds>
>    tenth packet of 63 bytes.  The client sends an IPv6 packet containing
>    the UDP datagram with the DTLS record that encapsulates the CoAP
>    request 10 times.  The server returns an IPv6 packet containing the
>    UDP datagram with the DTLS record that encapsulates the CoAP
>    response.  The CoAP request-response exchange with block option is
> The definite vs. indefinite articles here don't seem quite right, and
> each of the 10 datagrams do not encapsulate the entire CoAP request. 
> <pvds> 
> I don't understand your meaning. 

I'm complaining that the "an"s and "the"s don't match up.
I think I also misunderstood the sense of what was happening, so my "do not
encapsualte the entire CoAP request" is not quite right.


   tenth packet of 63 bytes.  The client sends an IPv6 packet containing
   a UDP datagram with DTLS record protection that encapsulates a block
   of the CoAP request 10 times (one packet per block).  The server returns
   an IPv6 packet containing the UDP datagram with the DTLS record that
   encapsulates the CoAP response.  The CoAP request-response exchange
   with block option is [...]

> </pvds>
> Appendix C.2
> [I mentioned otherName's non-decoding earlier]

Specifically, in crypto/x509/v3_alt.c:

                                       GENERAL_NAME *gen,
                                       STACK_OF(CONF_VALUE) *ret)
    switch (gen->type) {
        if (!X509V3_add_value("othername", "<unsupported>", &ret))
            return NULL;

So openssl is explicitly just punting on all otherNames.

> Appendix C.3
> I find it kind of amusing that we have a "Netscape Comment" in the
> generated cert :) 
> <pvds> 
> This was the result of a lengthy openssl struggle. 
> Any suggestions for improvement are very welcome indeed. 

Do you have a line with a "nsComment" in any config file (e.g., openssl.cfg)
floating around (i.e., the -config <filename> argument to openssl req)?  It
*sounds* from the documentation like this is not supposed to be added by
default (though many of the apps/ and demos/ config files in the tree do
include it).


> </pvds>
> _