Perché la RFC 5280 impone alle CA di non emettere certificati con numeri seriali negativi?

3

Ho provato a emettere un certificato che inizia da 8 a F, ma ho trovato che è impossibile, principalmente a causa della RFC:

The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer.

Quindi mi piacerebbe sapere se esiste un motivo valido per non farlo al di là della "buggata implementazione ASN.1"?

    
posta kiBytes 18.02.2014 - 17:06
fonte

3 risposte

5

Risposta breve: perché RFC 3280 , il suo predecessore, lo dice.

Risposta più lunga: perché storicamente i codificatori / decodificatori ASN.1 hanno avuto problemi con la codifica e la decodifica corretta degli interi.

X.509 utilizza codificato ASN.1 , che, tra le altre cose, significa che i dati deve essere codificato nella sua forma minima (più corta). Poiché gli interi sono memorizzati in una forma a due complementi di lunghezza variabile, per codificare correttamente un numero intero non negativo che ha il suo bit di riferimento (MSB) impostato, deve essere riempito con uno zero iniziale, che in altre circostanze non è consentito. . La dicitura di X.690 ( link ) è tale che i 9 bit iniziali di un intero devono essere controllati per verificare la forma minima, consentendo così a tali numeri interi positivi di avere 0 byte iniziali.

Per quote Peter Gutmann

There's a second but: Historically many encoders have gotten the signedness of integers wrong, which means that (a) if you get a negative number (at least in the area of crypto, which I'm most familiar with) it's always an encoding error and never a deliberate use of a negative value, and (b) because of the widespread use of incorrect encoders, many decoders treat all integer values as unsigned. So while you can use negative values in theory, it's not a good idea in practice.

La corretta determinazione dei numeri di serie è critica quando si tratta di controlli di revoca. L'ambiguità è un nemico.

Mi sembra che questo sia esattamente il problema che sta avendo il codificatore ...

    
risposta data 18.02.2014 - 22:44
fonte
2

ASN.1 definisce l'OID serialNumber di 2.5.4.5 come PrintableString. Non è definito come un attributo numerico, quindi tutti i caratteri stampabili sono consentiti e non è richiesto o interpretato alcun segno.

link

serialNumber ATTRIBUTE ::= {
  WITH SYNTAX               PrintableString(SIZE (1..MAX))
  EQUALITY MATCHING RULE    caseIgnoreMatch
  SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch
  LDAP-SYNTAX               printableString.&id
  LDAP-NAME                 {"serialNumber"}
  ID                        id-at-serialNumber
}

Tuttavia, RFC 2459 definisce CertificateSerialNumber come INTEGER.

link

Qualifica i numeri seriali in questo modo:

4.1.2.2  Serial number

The serial number is an integer assigned by the CA to each
certificate.  It MUST be unique for each certificate issued by a
given CA (i.e., the issuer name and serial number identify a unique
certificate).

Quindi la restrizione proviene dalle RFC, non da ASN.1

    
risposta data 18.02.2014 - 19:43
fonte
0

Perché un numero di serie è progettato per essere un numero progressivo non negativo.

È fondamentalmente un codice di controllo dello spazio pubblicitario per una CA e sono numeri incrementali non negativi nella maggior parte dei sistemi di inventario.

    
risposta data 18.02.2014 - 18:22
fonte

Leggi altre domande sui tag