[lamps] AD review of draft-ietf-lamps-rfc3709bis-04

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-lamps-rfc3709bis-04.  My feedback is below.

Thanks for the clean diff from RFC3709.

** Section 1.  Editorial. Given the wide use of PKIs in OT, in addition to IT, consider:

OLD
   However, the art of Public Key
   Infrastructure (PKI) has developed certificates far beyond this
   functionality in order to meet the needs of modern global networks
   and heterogeneous information technology structures.

NEW
   However, the art of Public Key
   Infrastructure (PKI) has developed certificates far beyond this
   functionality in order to meet the needs of modern global networks
   and heterogeneous information and operational technology structures.

** Section 2.  Editorial.  Being explicit of what the URI provides and s/one-way hash/hash/

OLD
   Image and audio data for logotypes can be remote by including a URI
   that identifies the location to the logotype data and a one-way hash
   of the referenced data in the certificate.  

NEW
Image and audio data for logotypes can be provided by reference by including a URI that identifies the location of the logotype data and a hash of the referenced data in the certificate.

** Section 3.

   If a logotype of a certain type (as defined in Section 2) is
   represented by more than one image object, then each image objects
   MUST contain variants of roughly the same visual content.  Likewise,
   if a logotype of a certain type is represented by more than one audio
   object, then the audio objects MUST contain variants of the same
   audio information.

What is the mechanism to assess "roughly the same visual content" and that the "audio objects ... contain[s] [a] variant of the same audio information"?  Will that be subject to the issuer's local policy?

Section 4.1
   Client applications SHOULD support both direct and
   indirect addressing.  Certificate issuing applications MUST support
   direct addressing, and certificate issuing applications SHOULD
   support indirect addressing.

Isn't the first sentence redundant to the next two?  The second sentence already says direct addressing is required and the third sentence strongly encourages it.

** Section 4.1
   All direct addressing URIs SHOULD
   use either the HTTP scheme (http://...) or the HTTPS scheme
   (https://...) or the DATA scheme (data://...) [RFC3986].

-- Is support for HTTP needed?  If so, why?  If it is unavoidable, could some preference be expressed for choosing HTTPS schemes in the sequence before HTTP?
-- Editorial.  "Either" is intended to choose between two things, three options are presented here

** Section 4.1

ASN.1 definition:
   LogotypeDetails ::= SEQUENCE {
      mediaType       IA5String, -- MIME media type name and optional
                                 -- parameters
      logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
      logotypeURI     SEQUENCE SIZE (1..MAX) OF IA5String }


Corresponding text:
   CAs SHOULD
   include a hash value that computed with the one-way hash function
   associated with the certificate signature, and CAs MAY include other
   hash values.  Clients MUST compute a one-way hash value using one of
   the identified functions, and clients MUST discard the logotype data
   if the computed hash value does not match the hash value in the
   certificate extension.

-- Typo. s/CA SHOULD include a hash value that computed/CA SHOULD include a hash value that is computed/

-- Per "CAs SHOULD include a hash value that computed with the one-way hash function associated with the certificate signature", it would be clearer to say that "CAs SHOULD use the hash function associated with the certificate signature to compute the hash value ..."

-- Per "... and CAs MAY include other hash values", if other hash values are included where are they represented?

-- The text doesn't explicitly say that the positional value of the logotypeHash value lines up with the logotypeURI (i.e., hash #3 is for the data at URI #3)

** Section 4.1
   Clients MUST compute a one-way hash value using one of
   the identified functions, 

Why does the client have to choose between "one of the identified functions?"  For validation, isn't the exact hash algorithm specified in the function supposed to be used?

** Section 4.1
ASN.1
   LogotypeInfo ::= CHOICE {
      direct          [0] LogotypeData,
      indirect        [1] LogotypeReference }

...
   LogotypeReference ::= SEQUENCE {
      refStructHash   SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
      refStructURI    SEQUENCE SIZE (1..MAX) OF IA5String }

Text
   The indirect addressing includes one reference to an external hashed
   data structure that contains information on the type, content, and
   location of each image and audio object.  Indirect addressing
   supports cases where each logotype is represented by many alternative
   audio or image objects.
         ...
   When using indirect addressing, the URI (refStructURI) pointing to
   the external data structure MUST point to a resource that contains
   the DER-encoded data with the syntax LogotypeData.
   
If I'm reading my ASN.1 correctly, LogotypeReference is used only to implement the indirect functionality.  The explanatory text says that indirect is "one reference to an external hash data structure."  If only one reference is supported, why is does LogotypeReference support a SEQUENCE of refStructHash and refStructURI?

** Section 4.2
   The xSize and ySize fields represent the recommended display size for
   the logotype image.  When a value of 0 (zero) is present, no
   recommended display size is specified.  When non-zero values are
   present and these values differ from corresponding size values in the
   referenced image object, then the referenced image SHOULD be scaled
   to fit within the size parameters of LogotypeImageInfo, while
   preserving the x and y ratio.

Per the idea of preserving the x and y ratio, what is the prescribed behavior when the supplied XSize and ySize would suggest scaling the image in a way where the x and y ratio is not respected.  For example, if the source image is 320x240 and the xSize=640 x ySize=480, the ratio is easy to preserve.  How would the same image be treated if the xSize=640 and ySize=600.

** Section 4.3
   However, the visual
   representation of Certificate Subject and Certificate Issuer
   information from the certificate MUST have the same meaning as the
   textual representation of that information in the certificate itself.

Can the visual representation of the Certificate Context conflict with the key usage or basic constraints?

** Section 7
   Whether the SVG image is GZIP-compressed or uncompressed, the hash
   value for the SVG image is calculated over the uncompressed SVG
   content with canonicalized EOL characters as specified above.

   When a SVG image is embedded in the certificate extension using the
   "data" URL scheme, the SVG image data MUST be provided in GZIP-
   compressed form, and the XML structure, prior to compression, SHOULD
   use linefeed (0x0A) as the end-of-line (EOL) character.

What is the thinking behind the design choice of not hashing the GZIPed file, and instead doing the integrity check against the uncompressed file?

** Section 9
   This also underlines the general necessity for relying parties to use
   up-to-date software libraries to render or dereference data from
   external sources, including logotype data in certificates, to
   minimize risks related to processing potentially malicious data
   before it has been adequately verified and validated.

Perhaps add that implementers should heed the guidance in Section 7 of RFC 3986.

** Section 10
   Since clients are expected to locally cache logotype
   data, network traffic to the server containing the logotype data will
   not be generated every time the certificate is used.

Where was this expectation to cache the logotype set?  

** Section 10.  In addition to the recommendation to use HTTPS and pad HTTPs, would using an encrypted DNS mechanism also help?

Regards,
Roman