draft-ietf-sidr-res-certs-06.txt

[Rob Austein <sra@hactrn.net>]

Some comments on draft-ietf-sidr-res-certs-06.txt, based primarily on
an htmlwdiff comparision against -02 as I have vague memories of
having read that version last summer.

- There's some text in section 3.9.6 that makes no sense to me.  As
  far as I can tell, it attempts to allow a child to disagree with its
  parent about whether the parent uses persistant URIs, perhaps to
  avoid forcing reissuance all the way down the tree when the parent's
  key changes.  This makes no sense to me because it appears to depend
  on having the child fiddle with the AIA URI of a certificate that
  the parent has to sign.  What am I misunderstanding here?

- There's new text saying that requests may be in either PKCS#10 or
  CRMF, that there's no requirement for an issuer to support both
  formats, and that the choice of formats is a private matter for
  subject and issuer to resolve.   This seems like a recipe for
  compliant non-interoperability to me.

- The certificate policy extension is now set by the issuer; this is a
  change, it used to be set by the subject.  I haven't yet figured out
  whether this is a good change.

- The RFC 3779 extensions used to be set by the issuer and were not
  allowed in requests.  This has changed to allow the subject to
  request a certificate that covers only a subset of the total set of
  resources.  This appears to duplicate functionality in the up-down
  protocol; I haven't yet figured out whether there's a good reason
  for this duplication.

- There's some new text stating that the issuer is not allowed to muck
  with the subject's SIA extension.  This seems reasonable at first
  glance, but the issuer is allowed to muck with -everything- else
  except for the subject's public key; in this context, excepting just
  the SIA seems strange and suggests that I'm not understanding the
  motivation behind this change.

- With no offense intended, I was not able to understand or even parse
  the Security Considerations section.  If I were reviewing this
  document for the security directorate, I would have to bounce it on
  these grounds, as I am required to assume that if I can't make any
  sense of this section, other readers might also be confused.

- Terminology in this draft is a bit messy, in particular the string
  "CA" sometimes means a CA, sometimes an issuer, and sometimes a
  certificate.  I also expect somebody to object to the phrase
  "self-signed certificate", so it'd be simplest to clean that up
  before kicking the draft to the IESG.

- I still think we need some kind of signed manifest, which would
  probably have to go in this document.

I have not yet done a pass over -06 as it stands (as opposed to with
comparision markup against -02 -- don't know about anybody else, but I
see different things with these two different review methodologies).
If I find anything worth reporting, I'll send it along.