Deb Cooley has entered the following ballot position for
draft-ietf-anima-brski-ae-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm leaving my old discuss text below, just because I can.

The authors pointed me to RFC8995 section 5.6 and 11.4, which nicely explains
how the chain between pledge, MASA, and registrar works to ensure that the
registrar is the legit registrar.  In the process, one of the authors suggested
that the voucher process could be added to figure 2, which I'd be happy to see,
if and only if it doesn't make the figure unweildy.

Thanks to the authors for the quick response and for politely pointing me to
the referenced RFCs.

----------------------------------------------------------------------
old DISCUSS:
----------------------------------------------------------------------

While this draft clearly outlines the requirements for proof of possession and
integrity/authentication of the pledge, I did not see any discussion on
integrity/authentication of the RA/CA.  How can the pledge determine if it is
requesting certificates (either its own or CA) from the proper RA/CA?  One of
the advantages of EST is that the pledge can verify the EST server certificate,
and an on-path attack is harder when there is an adequate TLS session.  Is that
the case with CMP (or SCEP)?  If so, either point me to where that is
documented or add a couple of sentences on how that is done.  If not, please
add a section to the Security Considerations.



_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to