Closed GoogleCodeExporter closed 9 years ago
Diff1:
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-nourse-scep-22.txt
Original comment by davidgrant41
on 8 Mar 2011 at 8:35
Diff2: http://tools.ietf.org/rfcdiff?url2=draft-nourse-scep-22.txt
Original comment by davidgrant41
on 8 Mar 2011 at 8:36
Enable:
The requester generates a SHA-1, SHA-256, SHA-512, or MD5 'fingerprint' of the
PKCS#10 [RFC2986] (before PKCS#7 [RFC2315] enveloping and signing). This
fingerprint is sent to the CA operator using an out-of-band method. The CA
operator MUST compared this fingerprint to a locally generated fingerprint
based on the message received during the SCEP exchange.
Original comment by davidgrant41
on 15 Apr 2011 at 2:19
Further to comment 3:
SCEP clients and CAs (or RAs, if appropriate) MUST support display of this
fingerprint to the operator to enable this authorization method. The
out-of-band distribution and comparison of fingerprints is not covered by this
document.
Original comment by davidgrant41
on 15 Apr 2011 at 2:20
Section 2.4:
Clients MUST verify the authorization of the RA certificates. The
authorization mechanism is specified by the CA administrator and is out of
scope for this document.
[Does this mean authorization to act as a SCEP peer?]
Original comment by davidgrant41
on 15 Apr 2011 at 2:26
Section 2.4:
Since the optional RA certificates are signed by the CA there is no need to
authenticate them against the out-of-band data
[GetCACert must return a chain]
Original comment by davidgrant41
on 15 Apr 2011 at 2:27
Original comment by davidgrant41
on 7 Jun 2011 at 12:07
Original comment by da...@grant.org.uk
on 13 Jul 2011 at 6:37
Original issue reported on code.google.com by
davidgrant41
on 8 Mar 2011 at 8:35