[lamps] AD Review of draft-ietf-lamps-cert-binding-for-multi-auth-03

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-lamps-cert-binding-for-multi-auth-03.  Thanks for this document.  My feedback is as follows:

** Section 1.1.  Editorial.
        … perhaps as part of
   an organization’s update strategy.

Consider clarifying what “update strategy” means – what is this an update from and to?

** Section 3 and 4.  The snippets of ASN.1 definition include multiple “TBD” placeholders.  Replace these with either TBD1 or TBD2 as defined in the IANA considerations section.

** Section 3.1.  Editorial.  
    IssuerAndSerialNumber is repeated
      here for convenience:

   IssuerAndSerialNumber ::= SEQUENCE {
           issuer       Name,
           serialNumber CertificateSerialNumber }

   CertificateSerialNumber ::= INTEGER

In this repetition for convenience only CertificateSerialNumber is defined.  Why not Name?

** Section 3.1
   The UniformResourceIdentifier is a pointer to a location via HTTP/
   HTTPS, or a dataURI.  This field can contain one of two acceptable
   values:

   *  - If the request for (new) Cert B is to the same CA organization
      as issued (existing) Cert A, then the UniformResourceIdentifier
      value SHOULD be available
...
     - If the request for (new) Cert B is to a CA organization
      different to the CA organization that issued the certifacte
      (existing) Cert A referenced in the CSR, then the
      UniformResourceIdentifier value MAY be a dataURI

Based on how this normative language is written isn’t the end result that either a URL and dataURI can be used for both scenarios?  Saying HTTP/HTTPs is a SHOULD when employed for two certificates from the same CA seems to imply that this is the recommended practice.  Saying the dataURI MAY be used for different CAs is silent on the preferred mechanism.  Could this be language be more prescriptive?

** Section 3.1.  Typo. s/certifacte/certificate/

** Section 3.1.  
    ... then the
      UniformResourceIdentifier value MAY be a dataURI [RFC2397]
      containing inline degenerate PKCS#7 consisting of all the
      certificates and CRLs required to validate the traditional
      certificate.

What is a an “inline degenerate PKCS#7”?  Is there a reference for that?

** Section 3.2
   *  MUST retrieve and validate the certificate identified in the
      relatedCertRequest using the information provided in
      UniformResourceIdentifier.

What is the scope of that validation?  Is that covered by locally policy?  For example, how would an expired certificate be handled?

** Section 3.2
   *  MUST check that the BinaryTime indicated in the requestTime field
      is sufficiently fresh.

With “sufficiently fresh” be determined by local policy?  Are there any recommended values of freshness?  Please be clear on what’s in scope for this document to define.

** Section 4.2.
  If an endpoint has indicated that it is willing to do non-composite
   hybrid authentication and receives the appropriate authentication
   data, it SHOULD check end-entity certificates (Cert A and Cert B) for
   the RelatedCertificate extension. If present in one certificate, for
   example Cert B, it SHOULD:


What is the alternative to these procedures (i.e., if the SHOULD is not followed) Is this normative language needed?

** Section 5.
   and a
   signature field in which the requesting entity produces a digital
   signature over the certID and a nonce

For consistency, consider substituting nonce with timestamp as this is how it is framed in Section 3.1.

** Section 5. Typo. s/alos/also/

** Section 7.
   All hybrid implementations are vulnerable to a downgrade attack in
   which a malicious peer does not express support for PQ algorithms,
   resulting in an exchange that can only rely upon traditional
   algorithms for security.

Consider generalizing this text.  As I read it, hybrid defined in this document doesn’t preclude two traditional algorithms but the text here presupposes traditional+PQ.

** Section 7.
   Implementors should be aware of risks that arise from the retrieval
   of a related certificate via the UniformResourceIdentifier provided
   in the relatedCertRequest CSR attribute, if the URI points to
   malicious code.

Isn’t there also the privacy/confidentiality risk in an on-path attacker observing HTTP traffic between the RA and the resource serving UniformResourceIdentifier?  Maybe traffic analysis if HTTPS is used too?

** Section 8.  Please provide RFC Editor guidance to replace TBD1, TBD2 and TBD3 with the IANA assigned values in Section 3, Section 8 and Appendix A.

Thanks,
Roman