[Drip] Comments on draft-ietf-drip-registries-10

[Robert Moskowitz <[e-mail]>]

Here is my review of the changes in -10

     4.3.  Hierarchial HIT Domain Authority (HDA)

r/parties to obtain./parties to obtain it./

The Serial Number SHOULD be  encrypted in a way only the authorized 
party can decrypt.

replace with

The Serial Number MUST be  protected in a way only the authorized party 
can gain access.

this is talking to USS store of SN; out of scope to tell them how to 
protect their store.

     4.3.1.  Manufacturer Unmanned Aircraft Authority (MAA)

The Manufacturer Code character set is defined in [CTA2063A] with the   
values (0-9, A-Z in that order) being set as integers from 0 to 33.

This is confusing.  It does not add up.  You need to be explicit on the 
alpha set.  Perhaps use regexp format

[0-9,A-H,J-N,P-Z]

Or state exclude alpha I and O.

6.1.  Serial Number

recommended DNS RR.

Include some text at the beginning about which RR is the recommendation 
DeJour (or what ever the term is).

State that DET RR is recommended, but others may be needed for specific 
application support.  For example, TLSA RR for D/TLS and HIP RR for HIP.

10.1.  Certificate Policy and Certificate Stores

It has been pointed out to me, that at least in the US, "general 
aviation" is private crewed aircraft only, whereas "civil aviation" is 
for commercial carrier crewed aircraft.

I am not sure how to fix:

Finally  there is a profile to directly add DET support into the 
general  aviation certificates as discussed below.

perhaps expand "general" to "civil/general".

Got to love this stuff.  Would not give it the time of day otherwise....

10.2.  Certificate Management

actually a X.509 registration

"an X.509"

Check for any other occurrences of "a X.509", as I believe proper style 
is "an X.509".

And if this was a direct copy of what I sent, I erred!

Add a 2nd para:

Note that CSRs do not include the certificate validityDate; adding that 
is done by the CA.  If in the registration process, the EE is the source 
of notBefore and notAfter dates, they need to be sent along with the CSR.

Or maybe not as this is "common knowledge" by PKIX developers/users.  I 
just forgot about it at the time.  Maybe that is why to include it, as 
one does tend to forget these sorts of details.

10.3.  Examples

[drip-dki] is full of examples.  Pages of them.  Point the reader there.

I am not reviewing Appendix C at this time.  Rather I will try and make 
DNS examples and see how things line up.

So this completes ver -10 review.

Bob